Информационная безопасность и защищенность информации: концептуальный базис

Защищенность информации — это фактическая способность системы противостоять актуальным угрозам, а не наличие купленных средств защиты. Разница принципиальна: можно иметь дорогой межсетевой экран и оставаться уязвимым из-за незакрытой CVE на публичном сервисе. Защищенность измеряется тем, насколько быстро организация обнаруживает и закрывает бреши, а не тем, сколько СЗИ стоит в стойке.

Что такое защищенность информации и как она измеряется на практике

Защищенность информации — это измеримая характеристика, показывающая, насколько триада «конфиденциальность-целостность-доступность» реально обеспечена против конкретной модели угроз. На практике её оценивают не абстрактно, а через операционные метрики службы ИБ:

• скорость реакции — сколько времени проходит от публикации CVE до её закрытия на ваших активах;
• полнота видимости — какая доля инфраструктуры под контролем сканеров, DLP и мониторинга; невидимое не защитить;
• обнаружение атак — способность выявить активность атакующего по индикаторам компрометации (IoC) до достижения цели;
• устойчивость к человеческому фактору — насколько барьеры компенсируют ошибки и злой умысел сотрудников.

Ключевой сдвиг зрелого подхода: обеспечение защищенности информации это не «поставили и забыли», а операционный цикл, где каждый день выявляются новые бреши и закрываются по приоритету. Информационная безопасность и защищенность информации в этой логике измеряются не бюджетом, а скоростью реакции.

Критерии и метрики защищенности корпоративной инфраструктуры от современных угроз

Защищенность инфраструктуры оценивается набором операционных метрик, привязанных к реальным угрозам, а не к формальному наличию СЗИ. Базовый набор для тактического контроля:

• покрытие сканированием — доля активов под регулярным анализом уязвимостей; «слепые зоны» это первый вектор атаки;
• MTTR по критичности — отдельно для Critical, High, Medium; критичные закрываются в жёстком SLA;
• возраст незакрытых уязвимостей — старая критичная брешь на периметре опаснее десятка свежих внутренних;
• MTTD (время обнаружения) — как быстро SOC замечает подозрительную активность;
• доля контролируемых каналов утечки — сколько путей вывода данных (почта, мессенджеры, USB, облака) под контролем DLP.

Best practice: оценивайте не абсолютное число уязвимостей, а «уязвимости на критичных активах, доступных извне». 500 уязвимостей на изолированном тестовом стенде менее опасны, чем одна Critical на публичном сервисе с ПДн клиентов.

Анализ угроз информационной безопасности и Threat Intelligence

Анализ угроз (Threat Intelligence) отвечает на вопрос «кто и как может нас атаковать» до того, как атака произойдет. Без понимания актуальных техник злоумышленников защита превращается в стрельбу вслепую: ресурсы тратятся на маловероятные угрозы, а реальные векторы остаются открытыми.

Анализ угроз информационной безопасности: работа с БДУ ФСТЭК и фреймворком MITRE ATT&CK

Анализ угроз информационной безопасности строится на двух опорных источниках: российском Банке данных угроз (БДУ) ФСТЭК и международной матрице MITRE ATT&CK. БДУ даёт нормативно признанный в РФ перечень угроз и уязвимостей, ATT&CK — детальную структуру тактик и техник реальных атак.

Как применяют на практике:

• БДУ ФСТЭК (bdu.fstec.ru) — основа модели угроз для ИСПДн, ГИС и КИИ; карточки угроз и уязвимостей с объектами воздействия и мерами, обязателен для регуляторных задач в РФ;
• MITRE ATT&CK — матрица тактик (разведка, закрепление, вывод данных) и техник, построенная на реальных атаках; служба ИБ проверяет по ней покрытие детектом и «слепые зоны»;
• связка обоих — БДУ закрывает регуляторную сторону (что требует ФСТЭК), ATT&CK — операционную (как атакуют на самом деле и что мониторить).

Практический приём: наложите техники ATT&CK, актуальные для вашей отрасли, на свои средства обнаружения и получите карту покрытия — где детект есть, где его надо строить.

Таблица 3. Тактика Exfiltration (вывод данных) в MITRE ATT&CK и меры обнаружения

Наложение этих техник на средства защиты показывает, где в контуре вывода данных есть детект, а где — «слепая зона», через которую утечка пройдёт незамеченной.

Выявление угроз информационной безопасности: проактивный Threat Hunting и мониторинг

Выявление угроз делится на реактивное (SIEM сработал по известному правилу) и проактивное (Threat Hunting — активный поиск следов атаки, которую не поймали автоматические средства). Threat Hunting исходит из презумпции компрометации: «нас уже могли взломать, ищем следы», а не «ждем срабатывания сигнатуры».

Базовые подходы проактивного поиска:

• гипотезо-ориентированный — аналитик выдвигает гипотезу («атакующий закрепился бы такой-то техникой ATT&CK») и ищет следы в логах;
• поиск по IoC — проверка инфраструктуры на известные индикаторы компрометации (хеши вредоносов, C2-адреса, аномальные процессы);
• поведенческий анализ — выявление отклонений от базовой линии: вход администратора в нетипичное время, всплеск исходящего трафика, обращение к данным, к которым сотрудник обычно не обращается.

Отдельная сложность — Living off the Land (LotL): атакующий использует легитимные админ-инструменты (PowerShell, WMI). Сигнатурный детект их не ловит — нужен поведенческий мониторинг: запуск утилиты нормален, аномальным его делает контекст.

Уязвимости систем информационной безопасности: от обнаружения до эксплуатации

Уязвимость — это слабость, которую злоумышленник может использовать; но не каждая уязвимость одинаково опасна. Задача службы ИБ — не «закрыть все», что нереально, а приоритизировать: сначала то, что критично и реально эксплуатируемо.

Уязвимости систем информационной безопасности: классификация по CVSS и специфика Zero-Day

Уязвимости систем информационной безопасности классифицируют по шкале CVSS (Common Vulnerability Scoring System), которая присваивает балл от 0 до 10 и качественный уровень критичности. Актуальная версия — CVSS v4.0 (выпущена в ноябре 2023, переход с v3.1 идёт в течение 2026 года), где вместо метрик Temporal введены Threat, убрана метрика Scope и добавлена оценка Safety для промышленных и IoT-систем.

Таблица 1. Классификация уязвимостей по CVSS v4.0 и SLA на устранение

Отдельная категория — Zero-Day: уязвимость, для которой ещё нет патча, а иногда и публичной информации, но которая уже эксплуатируется. Против нее CVSS-приоритизация не помогает — нужны компенсирующие меры: виртуальный патчинг на WAF/IPS, сегментация, усиленный мониторинг аномалий вокруг уязвимого сервиса.

Типовая ошибка:приоритизировать только по баллу CVSS в отрыве от контекста. Critical на изолированном стенде ждёт планового окна, а High на публичном сервисе с активной эксплуатацией (проверяется по CISA KEV и EPSS) закрывается немедленно. Балл — старт приоритизации, а не финал.

Уязвимость и угрозы информационной безопасности: как ошибки конфигурации и человеческий фактор становятся векторами атак

Большинство успешных атак используют не экзотические Zero-Day, а банальные ошибки: незакрытые уязвимости, слабые пароли, неверную конфигурацию и человеческий фактор. Связка «уязвимость + угроза» реализуется чаще всего через предсказуемые векторы:

• ошибки конфигурации — открытый порт управления, дефолтные учётки, публичный облачный бакет, избыточные права;
• необновленное ПО — известная уязвимость с готовым эксплойтом на непропатченном сервисе;
• человеческий фактор — фишинг, переиспользование паролей, отправка данных «не туда», игнор регламентов;
• цепочка поставок — уязвимость в стороннем компоненте, библиотеке или у подрядчика с доступом к вашим системам.

Практический вывод: базовая «гигиена» (управление конфигурациями, патч-менеджмент, MFA, минимизация прав, обучение персонала) закрывает больше реальных векторов, чем дорогие точечные средства. Атакующий идёт по пути наименьшего сопротивления — и это почти всегда известная незакрытая брешь, а не Zero-Day.

Утечки информации: анатомия инцидентов и методы предотвращения

Утечка данных — это финал цепочки атаки: злоумышленник (внешний или внутренний) выводит конфиденциальную информацию за периметр. Предотвращение утечек строится на контроле каналов вывода данных и способности отличить легитимную передачу от вредоносной.

Утечки информации и информационная безопасность: инсайдеры, взломы и ошибки интеграции API

Утечки информации делятся по источнику на три класса: инсайдерские (умышленные и случайные), результат внешнего взлома и технические ошибки (чаще всего незащищенные API и облачные хранилища). Каждый требует своих мер:

• инсайдеры умышленные — осознанный вынос данных (продажа базы, слив конкурентам); ловятся поведенческим анализом и DLP;
• инсайдеры случайные — документ не тому адресату, ошибочная публикация; DLP блокирует по контенту до отправки;
• внешние взломы — данные выводятся после компрометации; критична стадия Exfiltration в цепочке атаки (см. Таблицу 3);
• ошибки API — слабо защищённый интерфейс, отдающий данные без авторизации; частая причина массовых утечек последних лет.

Таблица 2. Топ-5 каналов утечек информации в 2025–2026 гг. и методы контроля

Архитектура DLP-систем и расследование фактов компрометации конфиденциальных данных

DLP-система (Data Loss Prevention) контролирует каналы передачи и блокирует вывод конфиденциальных данных по политикам. Архитектурно работает на нескольких уровнях: агенты на АРМ (конечные точки), контроль сетевого трафика (почта, веб), аудит хранилищ (DCAP). Ключевые компоненты:

• контентный анализ — распознавание конфиденциального контента по словарям, шаблонам (номера карт, паспорта), цифровым отпечаткам документов;
• контекстный анализ — кто, кому, по какому каналу, в какое время передаёт данные;
• режимы работы — мониторинг (фиксация без блокировки) и блокировка (превентивный запрет передачи);
• аналитика инцидентов — графы связей, профили поведения, доказательная база для расследования.

Для российских организаций в 2025–2026 годах DLP выбирается из реестра отечественного ПО с сертификатами ФСТЭК: на рынке представлены InfoWatch Traffic Monitor, Solar Dozor, СерчИнформ КИБ, «Гарда» и «Стахановец». При расследовании DLP даёт доказательную базу — что, когда и по какому каналу ушло — и для внутреннего разбирательства, и для взаимодействия с регулятором.

Услуга «Внедрение и настройка DLP-систем»

Операционный процесс: Vulnerability Management и Incident Response

Разовое сканирование не защищает — защищает процесс. Vulnerability Management (VM) и Incident Response (IR) превращают точечные находки в управляемый цикл: уязвимости планомерно закрываются, а инциденты обрабатываются по отработанному алгоритму, а не в панике.

Построение цикла управления уязвимостями (VM) с учетом SLA на устранение

Vulnerability Management — это непрерывный цикл: обнаружение → приоритизация → устранение → проверка, где каждой уязвимости назначен SLA исходя из критичности и контекста. Разовое «просканировали раз в год» это не VM. Этапы цикла:

1. Обнаружение (Discovery) — регулярное сканирование всех активов; полнота покрытия критична, невидимое не защищается.
2. Приоритизация (Triage) — не по «голому» CVSS, а с учётом контекста: доступность извне, наличие эксплойта (CISA KEV, EPSS), ценность актива.
3. Устранение (Remediation) — патч, а где невозможно быстро — компенсирующая мера (виртуальный патч, сегментация) в рамках SLA по критичности.
4. Проверка (Verification) — повторное сканирование, подтверждающее закрытие; уязвимость не считается закрытой без верификации.

Практика SLA: Critical — 24–48 часов, High — до 7 дней, Medium — до 30 дней, Low — плановый цикл. Для активов на периметре с активной эксплуатацией сроки жестче — вплоть до немедленного реагирования.

Алгоритм действий SOC при обнаружении активной фазы утечки или эксплуатации уязвимости

При активном инциденте счёт идёт на минуты, поэтому SOC действует по заранее отработанному алгоритму реагирования (Incident Response), а не импровизирует. Классический цикл IR (по модели NIST SP 800-61):

• Подготовка — плейбуки, роли, доступы и инструменты готовы заранее (до инцидента, не во время).
• Обнаружение и анализ — подтверждение инцидента, определение масштаба: какие системы, какие данные, какая стадия атаки.
• Сдерживание (Containment) — изоляция скомпрометированных узлов, блокировка каналов вывода, отзыв сессий; цель — остановить распространение и утечку.
• Устранение (Eradication) — удаление присутствия атакующего: закрытие использованной уязвимости, удаление вредоноса, смена скомпрометированных учетных данных.
• Восстановление (Recovery) — возврат систем в работу под усиленным мониторингом.
• Извлечение уроков (Lessons Learned) — разбор: как проникли, почему не заметили раньше, что изменить в защите.

Типовая ошибка:при обнаружении утечки сразу «выдергивать» серверы и стирать следы. Это уничтожает доказательную базу для расследования (форензики). Правильно — изолировать с сохранением состояния (снимки памяти, дисков, логов), фиксируя evidence по правилам DFIR.

Чек-лист: 10 шагов для экстренного закрытия критических уязвимостей в инфраструктуре

При обнаружении критической уязвимости на важном активе действовать нужно по алгоритму, а не хаотично. Последовательность экстренного реагирования, отработанная на инцидентах в финансовом секторе:

• Подтвердите уязвимость — исключите ложное срабатывание сканера, убедитесь, что она реально присутствует на активе.
• Оцените контекст, а не только балл — доступность извне, наличие эксплойта (CISA KEV, EPSS), ценность и связи актива.
• Определите масштаб — на скольких системах присутствует уязвимость, какие из них критичны и доступны снаружи.
• Проверьте признаки эксплуатации — не идёт ли уже атака: аномалии в логах, IoC, подозрительная активность.
• Изолируйте самое критичное — при риске активной эксплуатации ограничьте доступ к уязвимым активам (сегментация, правила МЭ).
• Примените компенсирующую меру — если патч недоступен немедленно: виртуальный патч на WAF/IPS, отключение уязвимого функционала.
• Установите патч по SLA — приоритет критичным и внешним активам; тестирование сокращается до минимально необходимого.
• Проверьте закрытие — повторное сканирование подтверждает устранение на всех затронутых системах.
• Проверьте, не было ли компрометации — если уязвимость могла эксплуатироваться, запустите поиск следов (Threat Hunting).
• Зафиксируйте и обновите процессы — внесите урок в VM-процесс: как ускорить обнаружение и закрытие подобного в будущем

Услуга «Тестирование на проникновение (пентест)», статья «Защита данных и 152-ФЗ»

FAQ: частые вопросы об уязвимостях, угрозах и утечках

Чем уязвимость (vulnerability) отличается от угрозы (threat) и эксплойта (exploit)?

Уязвимость — слабость в системе (например, незакрытая CVE). Угроза — потенциальное событие, использующее эту слабость (кто и зачем может атаковать). Эксплойт — конкретный инструмент или код, реализующий использование уязвимости. Аналогия: уязвимость — незапертая дверь, угроза — вор поблизости, эксплойт — отмычка. Риск возникает, когда все три сходятся.

Как правильно приоритизировать уязвимости, если сканер выдал тысячи CVE, а ресурсов на патчинг не хватает?

Не по «голому» баллу CVSS. Сначала фильтруйте по контексту: доступность актива извне, наличие публичного эксплойта и активной эксплуатации (списки CISA KEV, оценка вероятности эксплуатации EPSS), ценность актива и данных на нём. Критичная уязвимость на публичном сервисе с активной эксплуатацией — первый приоритет; такой же балл на изолированном стенде ждёт планового окна.

Какие индикаторы компрометации (IoC) указывают на то, что утечка данных уже началась?

Аномальный рост исходящего трафика, особенно в нерабочее время; обращения к большим объемам данных, к которым учётная запись обычно не обращается; соединения с неизвестными внешними адресами (потенциальные C2); использование инструментов архивирования и шифрования перед передачей; всплеск обращений к DLP-контролируемым каналам. Совокупность таких признаков — сигнал возможной активной фазы Exfiltration.

Помогает ли шифрование данных предотвратить утечку информации при компрометации учетных записей?

Частично. Шифрование защищает данные «при хранении» и «при передаче» от того, кто не имеет ключа. Но если скомпрометирована легитимная учётная запись с правами доступа, злоумышленник работает с уже расшифрованными данными — шифрование его не остановит. Против этого нужны разграничение прав, MFA, поведенческий мониторинг и DLP на каналах вывода. Шифрование — необходимый, но не достаточный барьер.

Как расследовать инцидент утечки, если злоумышленник использовал легитимные инструменты администрирования (Living off the Land)?

Сигнатурный детект тут бессилен, работает контекст. Анализируйте поведение: кто, когда и с какими параметрами запускал легитимные утилиты (PowerShell, WMI, встроенные средства), из-под какой учётной записи, с какого узла и куда шел трафик. Сопоставляйте с базовой линией нормального поведения и с техниками MITRE ATT&CK. Ключ к расследованию LotL — полнота логирования (командные строки, сетевые соединения) и сохраненные артефакты для DFIR.

Обязательно ли согласовывать процесс выявления угроз (Threat Hunting) с владельцами бизнес-процессов?

Да, в части доступа к системам и данным. Threat Hunting затрагивает продуктивные системы и логи, содержащие в том числе персональные данные, поэтому область поиска, права доступа охотников и правила работы с чувствительными данными согласуются заранее. Это защищает и от нарушения регламентов, и от ложной тревоги, когда легитимное действие бизнеса принимается за атаку.

Как БДУ ФСТЭК помогает в анализе угроз для объектов критической информационной инфраструктуры (КИИ)?

БДУ ФСТЭК — нормативно признанный в РФ источник угроз и уязвимостей, обязательный при построении модели угроз для объектов КИИ и ГИС. Он даёт структурированный перечень актуальных угроз с описанием объектов воздействия и мер, что позволяет обосновать выбор защитных мер перед регулятором. Для КИИ работа с БДУ — не рекомендация, а часть обязательных процедур обеспечения безопасности.

Какова роль DLP-системы в обеспечении защищенности информации: только контроль или еще и аналитика?

И то, и другое. Контрольная функция — мониторинг и блокировка передачи конфиденциальных данных по каналам вывода. Но зрелые DLP давно вышли за рамки «блокировщика»: они строят профили поведения сотрудников, выявляют аномалии и внутренние риски (People-Centric подход), формируют графы связей и доказательную базу для расследований. То есть DLP — это одновременно превентивный барьер и аналитический инструмент выявления инсайдерских угроз.

*Материал актуален на 2026 год: учтены CVSS v4.0 (2023, переход с v3.1 в течение 2026), актуальная матрица MITRE ATT&CK, БДУ ФСТЭК и статус российских DLP-решений в реестре отечественного ПО.*

Сообщение Уязвимости и утечки информации: анализ угроз, выявление и обеспечение защищенности информационных систем в 2025–2026 появились сначала на Сompliance Сontrol.

Оценка состояния информационной безопасности: подходы и цели

Оценка состояния информационной безопасности — это систематическое измерение того, насколько фактический уровень защищенности организации соответствует целевому, установленному исходя из рисков, регуляторных требований и бизнес-задач. Её цель — не «поставить оценку ради оценки», а получить основу для управленческих решений: где недофинансировано, что улучшать в первую очередь, окупаются ли вложения в защиту.

Что такое оценка состояния информационной безопасности и зачем она нужна бизнесу

Оценка состояния ИБ отвечает на три вопроса бизнеса: где мы сейчас, где должны быть и что стоит закрыть разрыв. Без неё бюджет на ИБ превращается в «чёрный ящик» — деньги тратятся, а руководство не понимает, снижается ли риск. Практическая польза оценки:

• обоснование бюджета — CISO приходит к совету директоров не с «дайте денег на безопасность», а с цифрами: текущий уровень зрелости 2,3 из 5, целевой 3,5, разрыв закрывается за N рублей и снижает ожидаемый годовой ущерб на M;
• приоритизация — ограниченный бюджет направляется туда, где разрыв между риском и защитой максимален;
• контроль эффективности — видно, дают ли внедренные меры результат или деньги ушли впустую;
• соответствие требованиям — регуляторы (ФСТЭК, ЦБ РФ) и стандарты требуют регулярной оценки как обязательного процесса.

Best practice: привязывайте каждую метрику ИБ к бизнес-риску. «У нас 200 незакрытых уязвимостей» ничего не говорит совету директоров. «40 уязвимостей на системах, обрабатывающих платежи, создают риск утечки с потенциальным штрафом до 15 млн рублей» — говорит всё.

Главная статья кластера «Аудит и оценка информационной безопасности: анализ уязвимостей, пентест и защита от НСД»

Анализ обеспечения информационной безопасности: от разовых проверок к непрерывному мониторингу

Анализ обеспечения информационной безопасности эволюционировал от ежегодных «фотографий» состояния к непрерывному мониторингу (Continuous Monitoring), где метрики собираются в реальном времени. Разовый аудит раз в год устарел: между проверками инфраструктура меняется десятки раз, появляются новые уязвимости и сервисы, а «бумажное» соответствие расходится с фактическим.

Три уровня зрелости подхода к анализу:

• реактивный — разовые проверки под требование регулятора или после инцидента; защищённость известна только в момент аудита;
• периодический — плановые оценки (ежеквартально) с фиксированным набором метрик; уже лучше, но между замерами остаются «слепые зоны»;
• непрерывный (Continuous Monitoring) — автоматический сбор метрик через SIEM, сканеры и GRC-платформы; дашборд состояния ИБ доступен в любой момент, отклонения видны сразу.

Целевая модель для зрелой организации — непрерывный мониторинг с периодическим глубоким аудитом процессов. Автоматика собирает технические метрики ежедневно, а раз в год-полугодие проводится качественная оценка процессов и зрелости, которую автоматизировать нельзя.

Методики оценки информационной безопасности: как измерить защищенность

Методика оценки информационной безопасности — это структурированный набор критериев, шкал и процедур, позволяющий получить воспроизводимый и сравнимый во времени результат. Выбор методики зависит от целей: соответствие регулятору РФ, международная сертификация, оценка процессной зрелости или управление киберрисками.

Популярные методики оценки информационной безопасности (ФСТЭК, ISO 27001, NIST CSF, COBIT)

Ни один фреймворк не универсален: российские методики ФСТЭК/ЦБ закрывают регуляторные требования, международные (ISO, NIST, COBIT) — управленческую зрелость и связь с бизнесом. Зрелые организации комбинируют их, накладывая через матрицу соответствий.

Таблица 1. Сравнение фреймворков и методик оценки ИБ

Практический подход: базовый контур строится на обязательных требованиях ФСТЭК/ЦБ, а сверху накладывается управленческая рамка (чаще NIST CSF 2.0 — в феврале 2024 в него добавили функцию Govern, прямо связывающую ИБ с корпоративным управлением). ISO 27001 подключают, когда нужна сертификация для контрагентов.

Оценка информационной безопасности организации: выбор критериев и шкал зрелости (CMMI)

Оценка зрелости показывает не «есть ли защита», а насколько процессы ИБ систематизированы, повторяемы и управляемы. Самая распространенная шкала — пятиуровневая модель зрелости CMMI, адаптированная под ИБ:

1. Начальный (Initial) — процессы хаотичны, ИБ держится на энтузиастах; результат зависит от конкретных людей.
2. Повторяемый (Managed) — базовые процессы описаны и повторяются, но не везде формализованы.
3. Определенный (Defined) — процессы стандартизированы, задокументированы, применяются единообразно во всей организации.
4. Управляемый (Quantitatively Managed) — процессы измеряются метриками, решения принимаются на основе данных.
5. Оптимизируемый (Optimizing) — непрерывное улучшение на основе анализа метрик и обратной связи.

Оценка проводится по каждому домену (управление доступом, реагирование на инциденты, управление уязвимостями и т. д.), результат — профиль зрелости. Практический ориентир: для большинства коммерческих организаций целевой уровень 3–4; уровень 5 оправдан только в критичных отраслях, так как поддержание оптимизируемого уровня дорого.

Показатели оценки информационной безопасности (KPI и KRI): как считать эффективность СЗИ

Показатели оценки информационной безопасности делятся на KPI (метрики эффективности — насколько хорошо работают процессы) и KRI (индикаторы риска — насколько близка организация к опасному порогу). Ключевое правило: метрика полезна, только если измерима, привязана к цели и на нее можно повлиять.

Базовые метрики с формулами расчета:

• MTTD (Mean Time To Detect) — среднее время обнаружения инцидента: сумма времен обнаружения ÷ число инцидентов. Цель — снижать; хороший ориентир для зрелого SOC — часы, не дни.
• MTTR (Mean Time To Respond/Remediate) — среднее время реагирования/устранения: сумма времён от обнаружения до закрытия ÷ число инцидентов.
• % закрытых критических уязвимостей в SLA — доля критичных уязвимостей, устраненных в срок: закрытые в SLA ÷ всего критичных × 100 %. Цель — стремиться к 95–100 %.
• % покрытия сканированием — доля активов под регулярным сканированием: просканированные активы ÷ всего активов × 100 %. Показывает «слепые зоны».
• % сотрудников, прошедших фишинг-тест — доля не поддавшихся на учебный фишинг; метрика человеческого фактора.

Таблица 2. Топ-10 метрик эффективности ИБ (KPI и KRI)

Типовая ошибка:гнаться за количеством метрик. 50 показателей в дашборде никто не читает. Совету директоров достаточно 5–7 верхнеуровневых KPI, привязанных к бизнес-риску; остальные — рабочий инструмент службы ИБ.

Системы анализа и инструменты аудита

Ручной сбор метрик по десяткам систем нежизнеспособен: к моменту сведе́ния в отчет данные устаревают. Системы анализа ИБ автоматизируют сбор, корреляцию и визуализацию, превращая разрозненные логи в управленческий дашборд.

Системы анализа информационной безопасности: автоматизация сбора данных и GRC-платформы

Системы анализа информационной безопасности делятся на технический и управленческий уровни: SIEM и сканеры собирают события и уязвимости, а SGRC/GRC-платформы агрегируют их в метрики, риски и статусы соответствия. Для российских организаций в 2025–2026 годах вопрос выбора почти всегда упирается в импортозамещение — нужны решения из реестра отечественного ПО с сертификатами ФСТЭК.

Логика связки уровней:

• сканеры уязвимостей (VA) и SIEM — технический фундамент: находят уязвимости и выявляют инциденты в потоке событий;
• SGRC-платформа — управленческая надстройка: ведет реестр активов, учёт СЗИ, политики, автоматизирует оценку соответствия и считает метрики;
• порядок внедрения для организации без зрелого SOC — сначала SGRC как фундамент (реестр активов и рисков), затем SIEM: без понимания, чей актив и какой у него риск, поток событий SIEM аналитику мало что дает.

Таблица 3. Классификация систем анализа ИБ

Для российских организаций критичны сертификаты ФСТЭК и наличие в реестре отечественного ПО: перечисленные SIEM и SGRC имеют сертификаты регуляторов и активно применяются в финансовом секторе.

Аудит безопасности информационных систем: этапы, чек-листы и артефакты (evidence)

Аудит безопасности информационных систем — это документированная проверка соответствия ИБ установленным критериям с обязательным сбором доказательств (evidence). Ключевое отличие аудита от «осмотра» — воспроизводимость: любой вывод подкреплен артефактом, который можно перепроверить. Классические этапы:

1 Планирование — определение области (scope), критериев (какой стандарт/требование), графика.

2 Сбор данных — интервью с владельцами процессов, запрос документов, выгрузки из систем, наблюдение.

3 Сбор доказательств (evidence collection) — скриншоты конфигураций, журналы, политики, записи тестов; каждое несоответствие фиксируется с доказательством.

4 Анализ и оценка — сопоставление факта с критерием, классификация несоответствий по критичности.

5 Отчётность — выводы, приоритизированные рекомендации, план устранения (remediation plan).

6 Контроль устранения — повторная проверка закрытия несоответствий.

Артефакты аудита (evidence) — не формальность, а страховка: при внешней проверке или расследовании инцидента именно доказательная база подтверждает, что мера действительно работала, а не только числилась в документах.

Услуги «Аудит процессов ИБ (GAP-анализ)», «Независимый комплаенс-аудит»

Практика: как провести внутренний аудит и презентовать результаты

Внутренний аудит проваливается не на технике, а на двух вещах: неполной доказательной базе и неумении донести результат до бизнеса. Разберем обе.

Подготовка к аудиту: сбор доказательной базы и интервьюирование владельцев процессов

Качество аудита определяется на этапе подготовки: чем полнее собрана доказательная база и чем честнее прошли интервью, тем ближе выводы к реальности. Практические принципы:

• начинайте с реестра активов и процессов — нельзя аудировать то, чего нет в описи; неучтенные системы это первая «слепая зона»;
• интервьюируйте владельцев процессов, а не только ИБ — как процесс работает на самом деле, знает тот, кто его выполняет; расхождение регламента и практики выявляется именно в разговоре;
• собирайте evidence сразу и структурировано — скриншот с датой, выгрузка с параметрами запроса, ссылка на документ с версией; доказательство «по памяти» не имеет силы;
• фиксируйте не только несоответствия, но и работающие контроли — аудит показывает и сильные стороны, это важно для объективной картины и для отчета руководству.

Отчетность: как перевести технические метрики ИБ на язык финансовых рисков для бизнеса

Совет директоров не покупает «снижение MTTR» — он покупает снижение вероятности убытка. Задача отчёта — перевести технические метрики в деньги и риск. Принципы «моста» между CISO и CFO:

• риск в деньгах — не «200 уязвимостей», а «ожидаемый годовой ущерб от текущего уровня риска — X рублей»; используйте оценку вероятного ущерба (например, по модели, где риск = вероятность × потенциальные потери);
• сравнение с целевым состоянием — где мы, где норма отрасли, где хотим быть; разрыв в цифрах;
• возврат на инвестиции в безопасность — во что обходится закрытие разрыва и какой риск это снимает;
• язык последствий, а не технологий — «простой процессинга на 4 часа = столько-то недополученной выручки + репутация + возможный штраф», а не «отказ кластера БД».

Практический формат для совета директоров: одна страница с 5–7 KPI в динамике (стрелки вверх/вниз к прошлому периоду), карта топ-рисков в деньгах и один вывод — что просим и зачем.

Чек-лист: 8 шагов для внедрения системы непрерывной оценки ИБ (Continuous Monitoring)

Непрерывная оценка внедряется поэтапно за 3–6 месяцев: сначала инвентаризация и выбор метрик, затем автоматизация сбора и отчётность. Последовательность, проверенная на проектах в финансовом секторе:

1 Инвентаризация активов и процессов. Полный реестр систем, данных и процессов ИБ — фундамент, без которого метрики считать не по чему.

2 Выбор фреймворка и целевого уровня зрелости. Базовый контур на требованиях ФСТЭК/ЦБ + управленческая рамка (NIST CSF 2.0 или ISO 27001); целевой уровень CMMI.

3 Определение набора метрик (KPI/KRI). 5–7 верхнеуровневых для руководства + рабочие для службы ИБ; для каждой — формула, цель, частота.

4 Выбор и внедрение систем анализа. SGRC как фундамент, затем SIEM и сканеры; для РФ — реестровые решения с сертификатами ФСТЭК.

5 Настройка автоматического сбора данных. Интеграция источников с SGRC/SIEM, чтобы метрики считались без ручного труда.

6 Построение дашбордов и отчётности. Технический дашборд для службы ИБ и управленческий для руководства на языке рисков.

7 Регламент реагирования на отклонения. Пороговые значения метрик и процедура действий при их превышении.

8 Цикл улучшения. Периодический пересмотр метрик и целей, глубокий аудит процессов, повышение уровня зрелости.

FAQ: частые вопросы об оценке и аудите ИБ

Как часто нужно проводить комплексную оценку состояния информационной безопасности?

Технические метрики (уязвимости, инциденты) собираются непрерывно или еженедельно, глубокая оценка процессов и зрелости — раз в год, а также после значимых изменений инфраструктуры и крупных инцидентов. Для регулируемых организаций частоту диктуют требования: например, оценка соответствия по ГОСТ Р 57580.1 для банков проводится с установленной регулятором периодичностью.

Чем внутренний аудит процессов ИБ отличается от внешнего независимого комплаенс-аудита?

Внутренний аудит проводит служба самой организации для управления и улучшения — он частый, гибкий, но не независим. Внешний комплаенс-аудит проводит сторонняя аккредитованная организация для подтверждения соответствия (сертификат, аттестат) — он независим и имеет вес для регуляторов, партнёров и в суде. Зрелая практика сочетает оба: внутренний для управления, внешний для подтверждения.

Какие 3–5 KPI лучше всего показывают реальную эффективность работы отдела ИБ совету директоров?

Оптимальный набор для верхнего уровня: MTTD и MTTR (скорость обнаружения и реагирования), % закрытых критических уязвимостей в SLA, % покрытия активов защитой/сканированием и результат фишинг-тестов как метрика человеческого фактора. Все пять — в динамике к прошлому периоду и с привязкой к риску в деньгах.

Можно ли полностью автоматизировать оценку соответствия требованиям ФСТЭК и ЦБ РФ с помощью GRC?

Частично. SGRC-платформа автоматизирует сбор доказательств, ведение реестров, отслеживание статусов контролей и подготовку отчетности, резко снижая ручной труд. Но качественную оценку процессов, интервью и профессиональное суждение аудитора автоматика не заменяет — GRC ускоряет и структурирует аудит, а не отменяет его.

Что делать, если технические показатели ИБ в норме, но происходят инциденты (проблема человеческого фактора)?

Это сигнал, что метрики не покрывают человеческий фактор. Добавьте поведенческие KPI: результаты фишинг-тренировок, охват и регулярность обучения, время реакции сотрудников на подозрительные события, соблюдение регламентов. Технические метрики в норме при инцидентах почти всегда означают, что вектор — социальная инженерия и процессы, а не техника.

Как оценить зрелость процессов ИБ по шкале CMMI (от 1 до 5 уровня)?

По каждому домену ИБ оценивается, насколько процесс формализован и управляем: 1 — хаотичный, 2 — повторяемый, 3 — стандартизированный и документированный, 4 — измеряемый метриками, 5 — непрерывно улучшаемый. Оценку даёт аудитор на основе доказательств (регламенты, записи, метрики); результат — профиль зрелости по доменам с целевыми уровнями. Для большинства коммерческих организаций цель — уровень 3–4.

Нужна ли лицензия ФСТЭК компании для проведения внутреннего аудита своей же инфраструктуры?

Нет. Лицензия ФСТЭК на деятельность по технической защите конфиденциальной информации нужна для оказания таких услуг третьим лицам. Аудит собственной инфраструктуры для внутренних нужд лицензирования не требует. Лицензия понадобится, если вы решите проводить аудиты для других организаций как услугу.

Какие системы анализа ИБ оптимальны для импортозамещения в 2025–2026 году?

Из реестра отечественного ПО с сертификатами ФСТЭК: в классе SIEM — MaxPatrol SIEM, KUMA, R-Vision SIEM, RuSIEM, Security Vision; в классе SGRC — платформы Security Vision, R-Vision и другие реестровые решения. Выбор зависит от масштаба, наличия SOC и бюджета; для организации без зрелого SOC рационально начинать с SGRC как фундамента, затем подключать SIEM.

*Материал актуален на 2026 год: учтены NIST CSF 2.0 (2024), ISO/IEC 27001:2022, COBIT 2019, Приказ ФСТЭК России № 117 (с 01.03.2026) и актуальный статус российских SIEM/SGRC-решений в реестре отечественного ПО.*

Сообщение Методика оценки и аудит информационной безопасности: показатели, системы анализа и состояние СЗИ в 2025–2026 появились сначала на Сompliance Сontrol.

Роль криптографии в современной информационной безопасности

Криптография — единственный класс защитных механизмов, который защищает саму информацию, а не инфраструктуру вокруг неё. Межсетевой экран можно обойти, сервер — украсть физически, но корректно зашифрованные данные остаются бесполезными для нарушителя без ключа.

Что такое криптографическое обеспечение информационной безопасности и его место в архитектуре СЗИ

Криптографическое обеспечение информационной безопасности — это комплекс алгоритмов, средств (СКЗИ) и организационных процедур, которые защищают данные преобразованием: шифрованием, электронной подписью, хешированием и имитозащитой. В архитектуре системы защиты криптография закрывает те угрозы, против которых бессильны «периметровые» средства:

• перехват данных в недоверенных каналах (интернет, связь между площадками);
• компрометация носителей — кража ноутбука, диска, резервной копии;
• подмена данных — целостность и авторство контролирует электронная подпись;
• доступ привилегированного персонала инфраструктуры (ЦОД, облачный провайдер) к содержимому.

В российской модели регулирования меры разведены между ведомствами: некриптографические средства сертифицирует ФСТЭК, всё связанное с шифрованием — исключительная зона ФСБ. Следствие для архитектора: криптографическая подсистема проектируется отдельным контуром со своими требованиями к сертификации, учёту и персоналу.

Конфиденциальность информации в информационной безопасности: как криптография обеспечивает триаду CIA

Конфиденциальность информации в информационной безопасности — первый элемент классической триады CIA (confidentiality, integrity, availability), и именно её криптография обеспечивает наиболее строго: доступ к содержимому получает только владелец ключа. Но криптографические механизмы закрывают все три элемента триады:

• конфиденциальность — шифрование данных при передаче (TLS, VPN с ГОСТ-криптографией) и при хранении (шифрование дисков, СУБД, резервных копий);
• целостность — хеш-функции (ГОСТ Р 34.11-2012 «Стрибог») и имитовставки гарантируют, что данные не изменены;
• доступность — косвенно: строгая криптографическая аутентификация отсекает несанкционированные подключения.

Best practice: проектируйте шифрование по модели «данные защищены всегда» — in transit (каналы), at rest (хранилища) и по возможности in use (криптоконтейнеры, HSM). Точечное шифрование «только канала до сайта» закрывает лишь малую часть ландшафта угроз.

Шифрование и криптографическая защита информации: методы и стандарты

Информационная безопасность и шифрование в корпоративной среде строятся на двух семействах алгоритмов — симметричных и асимметричных, а в России к ним добавляется обязательное измерение: национальные ГОСТ-алгоритмы, без которых невозможна сертификация СКЗИ.

Симметричное и асимметричное шифрование в корпоративной среде: плюсы и минусы

Симметричное шифрование использует один ключ для зашифрования и расшифрования и выигрывает в скорости; асимметричное использует пару «открытый/закрытый ключ» и решает проблему обмена ключами и подписи. В реальных системах они всегда работают в связке (гибридные схемы):

• симметричные алгоритмы (Кузнечик, Магма, AES) шифруют основной поток данных — быстро, аппаратно ускоряемо; слабое место — доставка ключа второй стороне;
• асимметричные алгоритмы (ГОСТ Р 34.10-2012, RSA, эллиптические кривые) работают как почтовый ящик: опустить письмо может кто угодно, достать — только владелец ключа. Решают обмен ключами и аутентификацию, но на 2–3 порядка медленнее — массивы данных ими не шифруют;
• гибридная схема — стандарт индустрии: асимметрика согласует сеансовый ключ, симметрика шифрует трафик. Так работают TLS и все ГОСТ-VPN.

Типовая ошибка — «самописная криптография»: стойкость обеспечивает не секретность алгоритма, а открытая экспертиза и корректная реализация. Используйте проверенные криптобиблиотеки и сертифицированные СКЗИ.

Информационная безопасность и криптографическая защита информации: российские ГОСТы vs зарубежные алгоритмы (AES, RSA)

В связке «информационная безопасность и криптографическая защита информации» российские и зарубежные алгоритмы по стойкости сопоставимы; различие — в регуляторном статусе: там, где закон требует сертифицированные СКЗИ, применяются только ГОСТ-алгоритмы. Действующая линейка национальных стандартов: блочные шифры «Кузнечик» и «Магма» (ГОСТ Р 34.12-2015), режимы работы (ГОСТ Р 34.13-2015), подпись (ГОСТ Р 34.10-2012) и хеширование «Стрибог» (ГОСТ Р 34.11-2012). Ветеран ГОСТ 28147-89 с 2019 года не рекомендован для новых систем и встречается только в legacy. Кстати, «Кузнечик» — не про насекомое: название собрано из фамилий разработчиков (Кузьмин, Нечаев и компания).

Таблица 1. Сравнение алгоритмов шифрования: российские ГОСТ vs зарубежные

*«Магма» — приведённый к новому стандарту вариант ГОСТ 28147-89 с фиксированными узлами замены.

Вывод для CISO: архитектура почти всегда двухконтурная — ГОСТ там, где этого требует регулятор (ГИС, ИСПДн с СКЗИ, госвзаимодействие, финсектор), AES/RSA — во внутренних системах без регуляторики.

Электронная подпись (ЭЦП) и средства удостоверения целостности

Электронная подпись (устаревшее название — ЭЦП) — криптографический механизм, юридически связывающий документ с его автором и фиксирующий неизменность содержимого. Правовой каркас задаёт 63-ФЗ «Об электронной подписи», который различает три вида: простую (ПЭП), усиленную неквалифицированную (УНЭП) и усиленную квалифицированную (УКЭП) — только последняя по умолчанию равнозначна собственноручной подписи.

Ключевые практические моменты 2025–2026 годов:

• УКЭП руководителей юрлиц и ИП выдаёт УЦ ФНС (финсектору — УЦ Банка России); сотрудники подписывают личными подписями физлиц с машиночитаемыми доверенностями (МЧД);
• средства ЭП должны быть сертифицированы ФСБ (класс не ниже КС1);
• закрытый ключ — главный актив: храните его на токенах с неизвлекаемым ключом, при компрометации или увольнении владельца — немедленный отзыв сертификата.

Криптографические средства защиты (СКЗИ): выбор и внедрение

СКЗИ — это программные, аппаратные и программно-аппаратные средства, реализующие криптографические алгоритмы: криптопровайдеры, VPN-шлюзы, HSM-модули, токены, средства электронной подписи. Криптографические средства обеспечения информационной безопасности в РФ выбираются не «по фичам», а от модели нарушителя — на ней построена вся классификация ФСБ.

Криптографические средства обеспечения информационной безопасности: классификация и архитектура

По архитектуре СКЗИ делятся на программные (криптопровайдеры, криптобиблиотеки), аппаратные (HSM, платы шифрования, токены) и программно-аппаратные (криптошлюзы). Типовой корпоративный контур включает четыре слоя:

• канальный — криптошлюзы и VPN с ГОСТ-шифрованием между площадками и для удалённого доступа;
• прикладной — криптопровайдер на АРМ и серверах: ГОСТ-TLS, подпись, шифрование почты;
• хранение — шифрование СУБД, дисков, резервных копий;
• доверенное ядро — HSM или токены, где ключи генерируются и живут, не покидая защищённой границы.

Криптографические средства защиты информационной безопасности: требования к сертификации ФСБ России

Сертификацию СКЗИ проводит ФСБ России, а класс средства (от КС1 до КА) подбирается под модель нарушителя: чем больше у потенциального противника возможностей, тем выше класс. Базовый документ отрасли — Положение ПКЗ-2005 (Приказ ФСБ № 66), требования к СКЗИ для персональных данных задаёт Приказ ФСБ № 378, для государственных информационных систем — Приказ ФСБ № 524.

Таблица 2. Классы защищённости СКЗИ и сценарии применения

Типовая ошибка: закупка СКЗИ класса «с запасом» (КС3 там, где достаточно КС1). Высокий класс — это не «лучше», а жёстче: требования к помещениям, учёту, персоналу и эксплуатации растут вместе с классом, и невыполнение эксплуатационных требований обнуляет юридическую силу сертификата.

Эксплуатацию сертифицированных СКЗИ регламентирует Инструкция ФАПСИ № 152: поэкземплярный учёт, ответственные пользователи криптосредств, контроль ключевых носителей, акты уничтожения. Журналы учёта — первое, что запрашивают проверяющие ФСБ.

Управление ключами шифрования (KMS): жизненный цикл и безопасное хранение

Управление ключами (Key Management System, KMS) — процессы и инфраструктура, контролирующие жизненный цикл ключа: генерацию, распределение, хранение, ротацию, отзыв, уничтожение. Взламывают не алгоритмы, а управление ключами: ключ в конфиге приложения, на общем диске или у уволившегося администратора.

Минимальный стандарт зрелого KMS-контура:

• генерация только в доверенной среде (HSM, сертифицированные датчики случайных чисел);
• master-ключи — в неизвлекаемом виде, рабочие ключи шифруются ключами уровнем выше (иерархия);
• ротация по регламенту, немедленная смена при компрометации или увольнении допущенных;
• разделение ролей: критичные операции — по принципу двух лиц;
• протоколирование операций с ключами; резервные копии ключей защищены не слабее оригиналов.
  

Услуга «Внедрение KMS»

Защита тайны: коммерческая и государственная

Шифрование — техника; тайна — правовой режим, и путать их дорого. Можно зашифровать всё до последнего файла, но если режим тайны не оформлен юридически, суд не признает сведения охраняемыми — и виновных в утечке не удастся привлечь к ответственности.

Коммерческая тайна и информационная безопасность: как защитить ноу-хау и финансовые показатели

Коммерческая тайна и информационная безопасность связаны через 98-ФЗ «О коммерческой тайне»: правовая защита возникает только после введения режима коммерческой тайны, а технические меры (включая шифрование) его подкрепляют. Обязательный минимум для введения режима (ст. 10 98-ФЗ):

1. Утвердить перечень сведений, составляющих коммерческую тайну.
2. Ограничить доступ: установить порядок обращения с информацией и контроль его соблюдения.
3. Вести учёт лиц, получивших доступ к охраняемым сведениям.
4. Включить обязательства о неразглашении в трудовые договоры и договоры с контрагентами (NDA).
5. Нанести гриф «Коммерческая тайна» с указанием обладателя на носители.

Без этих шагов режим юридически не существует: сотрудника, унёсшего клиентскую базу, не привлечь по ст. 183 УК РФ, если база не была грифована и учтена. Шифрование хранилищ, DLP и разграничение доступа — техническое исполнение пунктов 2–3.

Государственная тайна и информационная безопасность: специфика работы, допуски и аттестация объектов

Государственная тайна и информационная безопасность регулируются Законом РФ № 5485-1 «О государственной тайне»: это полностью закрытый контур с допусками персонала, лицензированием организаций и аттестацией объектов информатизации. Ключевые отличия от «гражданской» ИБ:

• три степени секретности («особой важности», «совершенно секретно», «секретно») и формы допуска сотрудников 1–3 с проверками ФСБ;
• лицензия ФСБ на работу с гостайной — до начала работ; для технической защиты — лицензии ФСТЭК;
• обязательная аттестация объектов информатизации; обработка — только на аттестованных объектах;
• исключительно сертифицированные средства, включая СКЗИ классов КВ/КА; сети с гостайной физически изолированы от сетей общего пользования.

Информационная безопасность и техническая защита конфиденциальной информации: отличие от защиты ПДн

Информационная безопасность и техническая защита конфиденциальной информации (ТЗКИ) — более широкий режим, чем защита персональных данных: под конфиденциальной информацией понимаются любые охраняемые сведения ограниченного доступа — служебная тайна, коммерческая тайна, ПДн, профессиональные тайны. Практические отличия:

• защита ПДн — жёстко регламентированный частный случай: уровни защищённости, меры по приказам ФСТЭК, надзор Роскомнадзора;
• ТЗКИ — рамочный режим: состав мер определяет обладатель по модели угроз; услуги ТЗКИ третьим лицам лицензирует ФСТЭК;
• один массив может попадать под несколько режимов сразу (клиентская база — и ПДн, и коммерческая тайна): применяется наиболее строгий.

Таблица 3. Режимы защиты: коммерческая тайна vs государственная тайна vs конфиденциальная информация

Лицензирование и compliance при работе с криптографией

Оборот криптографии в России лицензируется с 1995 года (Указ Президента № 334), и рамка не смягчается: разработка, производство, распространение и обслуживание шифровальных средств для третьих лиц без лицензии ФСБ незаконны. При этом использовать СКЗИ для собственных нужд лицензия не требуется — на этой границе чаще всего и ошибаются.

Лицензии ФСБ на разработку, производство и распространение шифровальных средств

Лицензирование криптографической деятельности регулируется Постановлением Правительства РФ № 313 от 16.04.2012: единая лицензия ФСБ покрывает до 28 видов работ — от разработки СКЗИ до их техобслуживания и услуг по шифрованию. Лицензия нужна, если компания:

• разрабатывает или производит шифровальные средства, включая ПО со встроенной криптографией на продажу;
• распространяет СКЗИ и ключевые документы (продажа токенов, выдача ключей ЭП клиентам);
• устанавливает и обслуживает СКЗИ для третьих лиц (интеграторы, сервисные компании);
• оказывает услуги по шифрованию, включая облачные сервисы ЭП.

Лицензионные требования: квалифицированный персонал (профильное образование или переподготовка по ИБ), помещения с контролем доступа, учёт СКЗИ, внутренняя нормативная база. Лицензии выдаёт ЦЛСЗ ФСБ и территориальные органы; процесс занимает 2–6 месяцев.

Типовая ошибка: ИТ-компания встраивает открытую криптобиблиотеку в свой продукт и продаёт его без лицензии и нотификации. Формально это распространение шифровального средства — деятельность лицензируемая; для товаров с криптографией при ввозе/обороте действует также механизм нотификации.

Ответственность за нарушение правил обращения с СКЗИ и разглашение тайны

Ответственность за нарушения в криптографической сфере разнесена по трём плоскостям: административная — за несертифицированные средства и нарушения правил, уголовная — за безлицензионную деятельность и разглашение тайны, гражданско-правовая — за причинённые убытки. Ключевые составы:

• ст. 13.12 КоАП РФ — использование несертифицированных СЗИ/СКЗИ там, где сертификация обязательна, и нарушение правил защиты информации;
• ст. 13.13 КоАП РФ — деятельность в области защиты информации без лицензии;
• ст. 171 УК РФ — незаконное предпринимательство при систематической безлицензионной деятельности с СКЗИ в крупном размере;
• ст. 183 УК РФ — незаконные получение и разглашение коммерческой, налоговой или банковской тайны: до 7 лет лишения свободы при тяжких последствиях;
• ст. 283 и 284 УК РФ — разглашение гостайны и утрата секретных документов: до 7 лет; ст. 283.1 — незаконное получение сведений, составляющих гостайну;
• утрата ключевых документов СКЗИ фиксируется актом и требует немедленного отзыва ключей, для аттестованных систем — уведомления регулятора.
  

Чек-лист: 7 шагов к внедрению системы криптографической защиты в компании

Внедрение криптографической защиты — проект на 3–6 месяцев, который начинается не с закупки СКЗИ, а с инвентаризации данных и правовых режимов. Последовательность, отработанная на проектах в финансовом секторе:

1. Инвентаризация информационных активов и режимов. Определите, какие данные обрабатываются (ПДн, коммерческая тайна, платёжные данные) и какие требования к криптографии предъявляет каждый режим.
2. Модель угроз и модель нарушителя. От неё зависит требуемый класс СКЗИ; для систем с обязательной сертификацией модель согласуется по методикам ФСБ.
3. Проектирование архитектуры шифрования. Разнесите контуры: где обязательны ГОСТ и сертифицированные СКЗИ, где допустима «гражданская» криптография; спроектируйте канальный, прикладной уровни и уровень хранения.
4. Выбор и закупка СКЗИ нужного класса. Проверяйте действующие сертификаты ФСБ и совместимость версий: сертификат распространяется на конкретные версии и конфигурации.
5. Построение KMS. Иерархия ключей, HSM или защищённые токены, регламенты генерации, ротации, отзыва и уничтожения ключей.
6. Организационный контур. Приказы о назначении ответственных пользователей криптосредств, журналы поэкземплярного учёта по Инструкции ФАПСИ № 152, обучение персонала, режим коммерческой тайны — если он нужен юридически.
7. Контроль и сопровождение. Периодический аудит криптографической подсистемы, контроль сроков сертификатов СКЗИ и ключей ЭП, тренировки реагирования на компрометацию ключей.

Услуга «Аудит криптографической защиты»

Статья «Защита ИСПДн»

FAQ: частые вопросы о криптографической защите информации

Обязательно ли использовать сертифицированные ФСБ СКЗИ для защиты коммерческой тайны?

Нет. Для коммерческой тайны состав мер определяет сам обладатель информации — допустимы и несертифицированные средства (AES, зарубежные продукты). Сертифицированные СКЗИ обязательны там, где это прямо требуют НПА: ГИС, защита ПДн при актуальных угрозах соответствующих типов, взаимодействие с госсистемами, гостайна.

Нужна ли лицензия ФСБ компании, если она использует шифрование только для внутренних нужд?

Нет. Использование СКЗИ для обеспечения собственных нужд организации прямо выведено из-под лицензирования (ПП РФ № 313). Лицензия нужна при разработке, производстве, распространении и обслуживании шифровальных средств для третьих лиц.

Чем криптографическая защита отличается от простого хеширования данных?

Хеширование — односторонняя функция: из хеша нельзя восстановить исходные данные, оно применяется для контроля целостности и хранения паролей. Шифрование обратимо при наличии ключа и защищает конфиденциальность. Хеширование — один из криптографических механизмов, но само по себе данные «в секрете» не хранит.

Как часто нужно менять ключи шифрования в корпоративной сети?

Сроки задаёт эксплуатационная документация конкретного СКЗИ и внутренний регламент: типично до 1–1,5 лет, сертификаты ЭП — 12–15 месяцев. Внеплановая смена — немедленно при компрометации (или подозрении) и при увольнении сотрудников с доступом к ключам.

Какие штрафы предусмотрены за утерю ключей ЭЦП или СКЗИ?

Отдельного штрафа «за утерю» нет, но это инцидент: отзыв сертификата через УЦ, акт о компрометации, перевыпуск ключей. Если утрата нарушила правила защиты в регулируемых системах — ст. 13.12 КоАП РФ, при ущербе третьим лицам — гражданские иски. В контуре гостайны утрата ключевых документов — основание для ст. 284 УК РФ.

Можно ли использовать зарубежные алгоритмы (AES-256) в государственных информационных системах (ГИС)?

Нет. С 1 марта 2026 года защита информации в ГИС строится по Приказу ФСТЭК № 117, криптографическая часть — по Приказу ФСБ № 524. Сертифицированных ФСБ средств на зарубежных алгоритмах не существует, поэтому AES допустим в ГИС только во вспомогательных функциях — обязательную ГОСТ-криптографию он не заменяет.

Как организовать безопасное резервное копирование зашифрованных данных?

Копии шифруются отдельными ключами (не продуктивными), а ключи хранятся отдельно от копий. Обязательно резервируйте и сами ключи в защищённом виде (иерархия KMS, HSM): зашифрованный бэкап без ключа — потерянные данные. Регулярно проверяйте восстановимость.

Что такое криптостойкость и как она оценивается регуляторами?

Криптостойкость — способность алгоритма и его реализации противостоять атакам: сложность взлома должна быть практически недостижимой. В России стойкость СКЗИ оценивают сертификационные исследования ФСБ по закрытым методикам — алгоритмы, корректность реализации, стойкость к атакам по побочным каналам; результат — присвоенный класс (КС1–КА).

*Материал актуален на 2026 год: учтены Приказ ФСТЭК России № 117 от 11.04.2025 (вступил в силу 01.03.2026), Приказы ФСБ России № 378 и № 524, ПП РФ № 313 и требования 63-ФЗ в действующей редакции.*

Сообщение Криптографическая защита информации и обеспечение тайны: шифрование, СКЗИ и требования ФСБ/ФСТЭК в 2025–2026 появились сначала на Сompliance Сontrol.

Обеспечение безопасности информационных систем персональных данных (ИСПДн) — комплекс правовых, организационных и технических мер, обязательных для оператора в силу ст. 19 Федерального закона № 152-ФЗ. С 30 мая 2025 года цена ошибки выросла на порядок: за утечки введены многомиллионные и оборотные штрафы. Информационная безопасность личных данных клиентов и сотрудников стала для бизнеса вопросом финансового выживания. В этом руководстве — пошаговый алгоритм: от классификации ИСПДн и модели угроз до выбора средств защиты и подготовки к проверке Роскомнадзора.

Что такое информационная система персональных данных (ИСПДн) и кто является оператором

ИСПДн — это совокупность персональных данных, содержащихся в базах данных, и обеспечивающих их обработку информационных технологий и технических средств (п. 10 ст. 3 152-ФЗ). Оператором признается любое юридическое или физическое лицо, которое самостоятельно или совместно с другими организует и (или) осуществляет обработку персональных данных и определяет её цели и состав, а также государственный, муниципальный орган. 

Определение ИСПДн и её ключевые компоненты

ИСПДн — это не «программа для работы с клиентами», а связка из трёх компонентов: самих персональных данных (ПДн), программного обеспечения для их обработки и технических средств, на которых всё это работает. Под определение попадает практически любая корпоративная система, где фигурируют данные физических лиц:

• CRM- и биллинговые системы с данными клиентов;
• кадровые системы с данными сотрудников;
• процессинговые платформы с данными держателей карт;
• сайт с формой обратной связи или личным кабинетом;
• СКУД и видеонаблюдение с распознаванием лиц, например биометрия.

В средней финансовой организации выделяется порядка 10 типовых ИСПДн. Типовая ошибка — объединять всё в одну «общую ИСПДн»: это завышает уровень защищённости и стоимость защиты для систем, которым хватило бы минимального набора мер.

Обязанности оператора ПДн по 152-ФЗ: что нужно знать

Оператор обязан обеспечить безопасность ПДн на всех этапах — от сбора до уничтожения (ст. 18.1 и 19 152-ФЗ). Ключевые обязанности:

• уведомить Роскомнадзор до начала обработки ПДн и, впоследствии, об изменении сведений, содержащихся в уведомлении (ст. 22 152-ФЗ) — штраф за неуведомление для юрлиц 100 000–300 000 ₽;
• определить угрозы безопасности ПДн при обработке в ИСПДн (ст19. 152 — ФЗ)
• установить уровни защищенности ИСПДн и обеспечить выполнение требований по ПП РФ № 1119 и Приказу ФСТЭК № 21;
• назначить ответственного за организацию обработки ПДн (ст 18.1, 22.1 152 -ФЗ);
• уведомлять Роскомнадзор об утечке в течение 24 часов, о результатах расследования  в течение 72 часов;
• проводить оценку вреда субъектам ПДн(ст.18.1 152 -ФЗ) и внутренний контроль соответствия требованиям нормативных актов.

Типовая ошибка операторов: ограничиться «бумажным комплаенсом». При проверке регуляторы смотрят на фактическую реализацию мер, а суды при утечках — на то, были ли внедрены заявленные в документах средства защиты.

Классификация ИСПДн по уровням защищенности (УЗ-1 – УЗ-4)

Уровень защищенности (УЗ) — степень требований к защите ПДн в конкретной ИСПДн, определяемая в соответствии ПП РФ № 1119 от 01.11.2012. Уровней четыре: от УЗ-4 (минимальные требования) до УЗ-1 (максимальные). От уровня напрямую зависит состав базовых мер установленных  Приказом у ФСТЭК № 21.

Порядок определения уровня защищенности ПДн
Для определения уровня защищенности необходимо установить: 

• категории обрабатываемых ПДн субъектов, 
• вид обработки по форме отношений между субъектами и организацией, 
• количество субъектов, 
• тип актуальных угроз.

Типы актуальных угроз:

• — угрозы 1-го типа связаны с наличием недекларированных (недокументированных) возможностей в системном ПО, используемом в ИСПДн;
• — угрозы 2-го типа связаны с наличием недекларированных (недокументированных) возможностей в прикладном ПО, используемом в ИСПДн;
• — угрозы 3-го типа с наличием недекларированных (недокументированных) возможностей не связаны.

Форма отношений между организацией и субъектами обработки ПДн:

• — обработка ПДн сотрудников (субъектов, с которыми организация связана трудовыми отношениями);
• — обработка ПДн субъектов, не являющихся сотрудниками организации, в т.ч. субъектов, трудоустроенных по договору ГПХ.
• Количество субъектов:
• — менее 100 000 субъектов;
• — более 100 000 субъектов. 

Для определения уровня защищенности можно воспользоваться таблицей 1.

Таблица 1. Уровни защищённости ИСПДн (УЗ-1 – УЗ-4)

Большинство коммерческих ИСПДн в ритейле и финансовом секторе классифицируются как УЗ-4,  УЗ-3, редко УЗ-2. УЗ-1 характерен для крупных систем с недокументированными (недекларированными ) возможностями системного ПО.

Как определить категорию обрабатываемых ПДн

Существует четыре категории обрабатываемых ПДн: 

• специальные категории — расовая и национальная принадлежности; религиозные, философские либо политических убеждениях; состояние здоровья; информация об интимной жизни (ст. 10 152-ФЗ);
• биометрические — биологические или физиологические особенности, по которым устанавливается личность, например фото или отпечатки пальцев (ст. 11 152-ФЗ);
• разрешенные для распространения — данные, доступ неограниченного круга лиц к которым предоставлен субъектом путем дачи согласия (ст.10.1 152-ФЗ);
• иные — всё остальное, например: ФИО, телефон, e-mail, паспортные данные, доходы и т.п.

Модель угроз информационной безопасности персональных данных

Модель угроз информационной безопасности персональных данных — документ, в котором оператор определяет актуальные для конкретной ИСПДн угрозы, потенциального нарушителя и его возможности. Без неё невозможно обоснованно выбрать меры защиты: именно модель угроз связывает требования 152-ФЗ и его подзаконных актов с реальным составом СЗИ. Модель угроз должна разрабатываться в соответствии с методическим документом «Методика оценки угроз безопасности информации» (утв. ФСТЭК России 5 февраля 2021 г.) (Методика ФСТЭК).

Зачем нужна актуальная модель угроз и как часто её пересматривать

Модель угроз обязательна для каждой ИСПДн (ч. 2 ст. 19 152-ФЗ). Формального срока пересмотра закон не устанавливает, но на практике он необходим:

• при изменении архитектуры ИСПДн (облако, новые модули, удалённый доступ и т.п.);
• при изменении уровня защищенности ПДн, обрабатываемых в ИСПДн;
• при появлении новых угроз безопасности информационных систем персональных данных в банке данных угроз (БДУ) ФСТЭК;
• после инцидентов информационной безопасности;
• планово — не реже одного раза в 3 года (рекомендуемая практика, которую ожидают увидеть проверяющие).

Устаревшая модель при проверке приравнивается к отсутствующей: например, если в документе 2022 года нет угроз удалённого доступа и облаков, которые фактически используются, выбранные меры защиты считаются необоснованными.

Типовые угрозы для ИСПДн: от внутренних нарушителей до целевых атак

Большинство угроз информационной безопасности персональных данных исходит не от внешних хакеров, но и от внутренних нарушителей — сотрудников с легитимным доступом. Типовой ландшафт угроз для финансовых организаций и процессинга:

Таблица 2. Топ-10 актуальных угроз для ПДн и компенсирующие меры

Методика ФСТЭК по разработке модели угроз 

Методология задаётся документом ФСТЭК, а именно: Методикой оценки угроз безопасности информации от 05.02.2021 (как выявлять и оценивать угрозы). Алгоритм:

1. Определить негативные последствия реализации угроз (ущерб субъектам, оператору и государству).
2. Определить возможные объекты воздействия и виды воздействий на них (информация, программно-аппаратные средства, ПО, МНИ и т.д.).
3. Определить источники угроз и актуальных нарушителей (уровни возможностей Н1–Н4).
4. Оценить способы реализации угроз по БДУ ФСТЭК (bdu.fstec.ru).
5. Оценить актуальность каждой угрозы и зафиксировать перечень актуальных угроз.

Итоговый документ утверждает руководитель оператора.

Услуга «Разработка модели угроз»

Обеспечение информационной безопасности и защита персональных данных: технические меры

Обеспечение информационной безопасности и защита персональных данных на техническом уровне строятся на мерах из состава Приказа ФСТЭК № 21, выбираемых исходя из уровня защищённости и актуальных угроз. Например, базовый набор для УЗ-3: защита от НСД, межсетевое экранирование, антивирус, регистрация событий безопасности, контроль носителей.

Системы обнаружения вторжений и межсетевое экранирование

Межсетевые экраны (МЭ) и системы обнаружения вторжений (СОВ) — первый эшелон защиты периметра ИСПДн. Для УЗ-3 и выше межсетевое экранирование обязательно. Рекомендации для финансовых организаций:

• сертифицированные ФСТЭК либо прошедшие иную процедуру оценки соответствия требованиям законодательства Российской Федерации в области обеспечения безопасности информации межсетевые экраны не ниже 5 класса для УЗ-3 (4 класса — для УЗ-2, УЗ-1);
• СОВ уровня сети и уровня узла с актуальными базами решающих правил;
• сегментация: выделение ИСПДн в отдельный сетевой сегмент — заодно сужает границы системы и снижает стоимость защиты.

Средства защиты от несанкционированного доступа (НСД)

СЗИ от НСД гарантируют, что доступ к ПДн получают только аутентифицированные пользователи в пределах назначенных полномочий. Обязательный функционал:

• идентификация и аутентификация (для УЗ-2 и выше — усиленная, включая двухфакторную);
• разграничение доступа по ролям и матрице полномочий;
• регистрация событий безопасности (кто, когда, к каким данным обращался);
• контроль целостности СЗИ и программной среды.

На практике именно журналы СЗИ от НСД становятся главным доказательством при расследовании утечек и защите позиции оператора в суде.

Антивирусная защита и контроль съёмных носителей

Средства антивирусной защиты (САВЗ) обязательны для всех уровней защищённости, включая УЗ-4. На практике требуются:

• САВЗ, сертифицированные ФСТЭК, с централизованным управлением и обновлением баз, либо прошедшие иную процедуру оценки соответствия требованиям законодательства Российской Федерации в области обеспечения безопасности информации;
• контроль съёмных носителей: запрет неучтённых USB-устройств, журнал учёта машинных носителей;
• шифрование носителей, выносимых за пределы контролируемой зоны.

Типовая ошибка операторов: не прошедшие оценку соответствия  «домашние» антивирусы или продукты вендоров, ушедших из РФ, — при проверке это невыполнение требований к оценке соответствия СЗИ.

Организационные меры защиты ПДн

Организационные меры — документированные правила и процессы, без которых технические средства не образуют систему защиты. Оператор обязан утвердить комплект организационно-распорядительной документации (ОРД) и обеспечить его фактическое исполнение (ст. 18.1 152-ФЗ).

Назначение ответственных и разработка ОРД (политики, регламенты)

Первый обязательный шаг — приказом назначить ответственного за организацию обработки ПДн и администратора безопасности ИСПДн (для УЗ-3 и выше). Минимальный комплект ОРД оператора включает:

• общедоступную политику обработки ПДн (публикуется на сайте, при его наличии, — её отсутствие Роскомнадзор выявляет дистанционно);
• положение об обработке и защите ПДн, перечни ПДн и допущенных лиц;
• акты классификации ИСПДн и модель угроз;
• регламенты доступа, резервного копирования, реагирования на инциденты;
• журналы учёта носителей, инструктажей, обращений субъектов;
• формы согласий по актуальной редакции ст. 9 152-ФЗ.

Обучение персонала и работа с инцидентами утечки ПДн

Человеческий фактор — источник большинства инцидентов, поэтому обучение и отработанное реагирование снижают риск сильнее любого отдельного СЗИ. Обязательные элементы:

• ознакомление допущенных сотрудников с ОРД под подпись и инструктажи не реже раза в год;
• регламент реагирования на инциденты с распределением ролей;
• соблюдение сроков уведомлений при утечке: 24 часа — о факте, 72 часа — о результатах расследования. Пропуск 24-часового срока — самостоятельный состав со штрафом для юрлиц 1–3 млн ₽, независимо от последствий утечки.
  

Оценка соответствия ИСПДн требованиям законодательства

Оценка соответствия — проверка того, что реализованные меры действительно обеспечивают установленный уровень защищённости. Для коммерческих ИСПДн допустимы две формы: оценка эффективности собственными силами и/или с привлечением на договорной основе юридических лиц и ИП, имеющих лицензию на осуществление деятельности по ТЗКИ  (не реже раза в 3 года, п. 6 Приказа ФСТЭК № 21 и п. 17 ПП РФ № 1119) либо аттестация лицензиатом ФСТЭК.

Оценка эффективности vs. аттестация силами лицензиата ФСТЭК

Для частных операторов аттестация ИСПДн — право, а не обязанность: обязательной она является для государственных информационных систем (Приказ ФСТЭК № 117). Как выбрать форму:

• Оценка эффективности своими силами — дешевле и быстрее, оформляется внутренним актом; подходит организациям с собственной службой ИБ;
• Оценка эффективности силами сторонних организаций — независимая проверка документации и конфигураций СЗИ перед проверкой регулятора; помогает посмотреть на систему защиты под другим углом;
• Аттестация лицензиатом ФСТЭК — обязательна для ГИС; даёт аттестат соответствия, снимающий вопросы при проверках.

Услуга «Аудит ИСПДн» и «Подготовка к проверке Роскомнадзора»

Что проверяет Роскомнадзор при плановых и внеплановых проверках

Роскомнадзор проверяет правовые и организационные аспекты обработки ПДн; техническую защиту (СЗИ, выполнение приказов ФСТЭК) контролируют ФСТЭК и ФСБ в своей части. В фокусе инспекторов Роскомнадзора:

• факт уведомления об обработке ПДн и актуальность сведений в реестре операторов;
• общедоступность политики обработки ПДн на сайте, законность целей и оснований обработки;
• согласия субъектов: форма, состав, отделимость от иных документов;
• локализация баз с ПДн граждан РФ (ч. 5 ст. 18 152-ФЗ) и уведомление о трансграничной передаче (при наличии);
• сроки ответов на запросы субъектов, сроки хранения и порядок уничтожения ПДн.

Внеплановые проверки чаще всего инициируются по жалобам субъектов и публикациям об утечках. Регулятор активно использует профилактические визиты и дистанционный мониторинг сайтов — нарушение можно получить, ни разу не увидев инспектора.

Ответственность за нарушение 152-ФЗ в 2025–2026 году

С 30 мая 2025 года действуют поправки ФЗ № 420-ФЗ от 30.11.2024: штрафы выросли в разы, появились составы за утечки с санкциями до 15 млн ₽ и оборотные штрафы до 500 млн ₽ за повторные крупные утечки. Это самое масштабное ужесточение за историю 152-ФЗ.

Административные штрафы по ст. 13.11 КоАП РФ

Статья 13.11 КоАП РФ содержит более полутора десятков составов; с 2026 года дела по ней рассматривают мировые судьи (ФЗ № 508-ФЗ от 28.12.2025). Ключевые санкции в действующей редакции:

Таблица 3. Штрафы по ст. 13.11 КоАП РФ (актуально на 2025–2026 гг.)

Отдельно действует ст. 13.11.3 КоАП РФ — нарушения при обработке биометрии, включая работу без аккредитации. Смягчение для оборотных штрафов: подтверждённое выполнение требований по защите ПДн в течение года до инцидента и добровольная компенсация вреда — тогда суд может назначить фиксированный штраф вместо оборотного.

Уголовная и гражданская ответственность операторов

С декабря 2024 года действует уголовная ответственность за незаконный оборот ПДн — ст. 272.1 УК РФ. Базовый состав — до 4 лет лишения свободы за незаконные сбор, хранение и передачу ПДн. При отягчающих обстоятельствах (спецкатегории, биометрия, трансграничная передача, тяжкие последствия) — до 10 лет. Статья нацелена на «пробив» и торговлю базами, но риски несут и инсайдеры — сотрудники операторов, передающие данные без правового основания.

Гражданско-правовая ответственность — иски субъектов о компенсации морального вреда (ст. 24 152-ФЗ): после крупных утечек практикуются массовые иски, и суды постепенно увеличивают присуждаемые суммы.

Чек-лист: 10 шагов к полному соответствию 152-ФЗ

Полное соответствие 152-ФЗ достижимо за 2–4 месяца системной работы по алгоритму: от инвентаризации данных к технической защите и регулярному контролю. Ниже — последовательность из практики проектов для банков и процессинговых компаний.

Пошаговый план для compliance-менеджера

1. Инвентаризация ПДн и процессов. Зафиксируйте, какие данные, в каких системах, для каких целей и на каком правовом основании обрабатываются. Результат — реестр процессов обработки.
2. Выделение и классификация ИСПДн. Определите границы каждой системы, категории и объём ПДн, тип актуальных угроз — присвойте уровни защищённости по ПП № 1119.
3. Уведомление Роскомнадзора. Подайте или актуализируйте уведомление об обработке ПДн; проверьте сведения о трансграничной передаче.
4. Разработка модели угроз по Методике ФСТЭК 2021 года с использованием БДУ для каждой ИСПДн.
5. Разработка комплекта ОРД: политика, положения, приказы о назначении ответственных, регламенты, журналы, формы согласий.
6. Выбор и внедрение мер защиты по Приказу ФСТЭК № 21: базовый набор для вашего УЗ, адаптированный под актуальные угрозы; закупка сертифицированных СЗИ.
7. Настройка процесса реагирования на инциденты с отработкой 24/72-часовых уведомлений Роскомнадзора — вплоть до готовых шаблонов и учебных тревог.
8. Обучение персонала: инструктажи под подпись, фишинг-тренировки, правила работы с носителями.
9. Оценка эффективности мер защиты (не реже раза в 3 года) либо аттестация лицензиатом ФСТЭК; устранение выявленных несоответствий.
10. Регулярный цикл контроля: актуализация модели угроз и ОРД при изменениях, мониторинг изменений законодательства, ежегодный внутренний аудит.

Пройдите шаги 1–5 до внедрения технических средств. Закупка СЗИ без классификации и модели угроз — самая дорогая ошибка: она ведёт к избыточным затратам либо к несоответствию установленному УЗ.

FAQ: частые вопросы об обеспечении безопасности ИСПДн

Нужно ли уведомлять Роскомнадзор о начале обработки ПДн в 2026 году?

Да, до начала обработки. Исключений нет: уведомление подают и те, кто обрабатывает только данные сотрудников. За неуведомление юрлицу грозит 100 000–300 000 ₽ (ч. 10 ст. 13.11 КоАП РФ).

Как часто нужно актуализировать модель угроз ИСПДн?

При каждом значимом изменении ИСПДн, после инцидентов и при появлении новых угроз в БДУ ФСТЭК. Планово — не реже раза в 3 года, синхронно с оценкой эффективности мер защиты.

Что делать, если ПДн обрабатываются без средств автоматизации?

При неавтоматизированной обработке ПП № 1119 и Приказ № 21 не применяются — действует ПП РФ № 687: учёт носителей, обособление ПДн, сохранность документов.

Чем отличается оператор ПДн от обработчика ПДн?

Оператор определяет цели и состав обработки; обработчик действует по его поручению в рамках договора (ст. 6 152-ФЗ). Перед субъектом отвечает оператор, обработчик — перед оператором. Пример: компания — оператор, облачный провайдер или аутсорсинговая бухгалтерия — обработчик.

Нужно ли получать отдельное согласие на обработку биометрических ПДн?

Да, требуется письменное согласие отдельным документом (ст. 11 152-ФЗ). Идентификация по биометрии в общем случае возможна только через Единую биометрическую систему, а работающие с биометрией организации подлежат аккредитации — нарушения караются по ст. 13.11.3 КоАП РФ.

Можно ли использовать несертифицированные ФСТЭК и ФСБ СЗИ для защиты ПД?

Да, но прошедших иную процедуру оценки соответствия требованиям законодательства Российской Федерации в области обеспечения безопасности информации

Каков срок хранения документов по защите ИСПДн?

Единого срока нет: согласия хранятся в течение срока обработки и по практике ещё 3 года после её прекращения; журналы и акты по ИБ — 3–5 лет; кадровые документы — до 50/75 лет по архивному законодательству. Сроки фиксируются в номенклатуре дел оператора.

Может ли оператор передать обработку ПДн третьему лицу без согласия субъекта?

Поручить обработку обработчику можно без согласия субъекта — на основании договора-поручения с обязательными условиями по ч. 3 ст. 6 152-ФЗ. А вот передача данных другому самостоятельному оператору для его собственных целей без правового основания — нарушение, вплоть до состава ст. 272.1 УК РФ.

*Материал актуален на 2026 год и учитывает изменения по ФЗ № 420-ФЗ, № 421-ФЗ от 30.11.2024 и № 508-ФЗ от 28.12.2025.*

Сообщение Обеспечение безопасности информационных систем персональных данных: модель угроз, уровни защищенности и требования 152-ФЗ в 2025–2026 появились сначала на Сompliance Сontrol.

Внутренняя защита организации, безусловно, должна быть выстроена на высоком уровне. Но не менее важен и взгляд извне: чтобы остановить злоумышленника, нужно понимать его логику, способы действий и возможные точки входа.

По результатам внутренних тестов на проникновение, проведённых компанией УЦСБ в 2025 году для организаций из разных отраслей, в 79% случаев компании оказались незащищёнными от атак потенциального злоумышленника. При этом в 94% случаев действия хотя бы одного сотрудника позволяли проникнуть во внутреннюю сеть, что могло привести к реализации критических рисков.

Как развивалось направление пентестов

Тестирование на проникновение — одно из ключевых направлений деятельности Compliance Control. Сегодня это крупная команда: в неё входят более 30 экспертов. История направления началась в 2015 году, когда специалисты выполняли базовые пентесты в рамках сертификации PCI DSS — одного из основных фокусов компании.

В 2015 году уровень зрелости корпоративных инфраструктур и приложений у многих заказчиков был заметно ниже, чем сейчас: защитой мобильных приложений и других элементов системы занимались далеко не все. Позже команда перешла к классическим инфраструктурным, внешним и внутренним пентестам, тестированию приложений и анализу кода для заказчиков из банковской сферы, финтеха и ритейла.

С 2024 года команда пентестеров Compliance Control активно участвует в российских и международных соревнованиях. За короткий срок она успела занять заметную позицию среди других команд: в октябре 2025 года вошла в топ-3 на ежегодной киберарене GIS Days 2025, в 2025 и 2026 годах – в топ-10 по итогам международной кибербитвы Standoff. До этого команда участвовала в турнирах CTFZone, VolgaCTF, BRICS+ CTF и других соревнованиях.

Эксперты Compliance Control также выступают на ИБ-мероприятиях и делятся опытом обнаружения уязвимостей, работы над проектами и разбора интересных кейсов. Доклады команды звучали на практикуме по кибербезопасности в Сколково, фестивале OFFZone, совместных практикоориентированных вебинарах с другими компаниями, а также в рамках мастер-классов и обучающих программ для вузов, включая МГТУ им. Н. Э. Баумана и Астраханский колледж вычислительной техники.

Зачем команде соревнования

Участие в соревнованиях и конференциях решает сразу несколько задач. Во-первых, это возможность делиться опытом с отраслью и начинающими специалистами. Во-вторых, способ получить новый практический опыт и улучшить навыки. В-третьих, возможность проявить экспертизу команды перед профессиональным сообществом.

Такая стратегия развития была сформирована в компании с самого начала: ценность участия в профессиональных мероприятиях понимали и руководители, и сами специалисты. Сегодня команда уже привыкла к соревнованиям и выступлениям, а каждый новый шанс проявить себя воспринимает как вызов и возможность.

Кроме того, участие  и особенно победы— в профильных соревнованиях высоко оцениваются во многих тендерах и конкурсах на проведение тестирований на проникновение. Для заказчика наличие корпоративной CTF-команды становится дополнительным подтверждением практической экспертизы исполнителя.

Как устроена команда

На соревнованиях команда Compliance Control выступает под названием Pwn3dP0ss3. В кибербитве Standoff специалисты участвуют в объединённом составе с командой SPACE, представляющей подразделение компании в Республике Казахстан. В объединённую команду входят специалисты по тестированию на проникновение разного уровня и профиля, включая капитана. Количество участников зависит от правил конкретного соревнования: например, на GIS Days допускается команда до пяти человек, поэтому Compliance Control представляет Pwn3dP0ss3.

Команда Compliance Control выступает на стороне нападения, в роли Red Team. Это команда, которая имитирует действия злоумышленников: ищет и эксплуатирует уязвимости, а также пытается добиться реализации недопустимых событий. Её противником становится Blue Team — команда защиты, которая мониторит события со стороны заказчика, предотвращает или останавливает действия атакующих и обеспечивает безопасность инфраструктуры объекта.

У каждого участника есть своя роль, которая определяется его компетенциями. Участие поддерживается и командой, и компанией: попробовать себя может каждый заинтересованный специалист, а постоянный состав формируется из тех, кто показывает высокий уровень подготовки, вовлечённость и готовность работать на результат.

Подготовка не ограничивается самими соревнованиями. Команда встречается раз в две недели. По сути, это полноценные тренировки. Список необходимых навыков внушительный: задания охватывают разные категории тестирования на проникновение, включая форензику, PWN, WEB, реверс-инжиниринг, криптографию, OSINT и другие направления. Перед каждой встречей участники разбирают конкретные задания, готовят вопросы, а затем вместе обсуждают результаты.

Для тренировок команда использует профильные площадки, в том числе ХакерЛаб, Hack The Box и Standoff Hackbase. На них есть онлайн-полигоны для отработки конкретных навыков и сценариев атаки: как в составе команды, так и индивидуально.

После подготовки команда подаёт заявку на участие в состязании. Обычно соревнования начинаются с отборочного этапа, но если команда ранее выходила в финал, этот этап можно пропустить.

Standoff 17: как проходит кибербитва

Чтобы наглядно показать, как проходит соревнование, рассмотрим недавний опыт участия SPACE x Pwn3dP0ss3 в кибербитве Standoff 17, которая проходила с 16 по 19 июня этого года.

Standoff проводится на киберполигоне — специальном цифровом пространстве, где моделируется инфраструктура отраслей экономики виртуального государства. В неё входят ИТ-системы, технологии промышленной автоматизации, бизнес-процессы и пользовательские сервисы энергетического, промышленного, финансового и ИТ-секторов. Каждый год для участников разрабатывают новый сценарий битвы, выбирают отдельные отрасли, создают задачи и закладывают новый набор уязвимостей. В отличие от CTF-соревнований, где участники решают отдельные задания, Standoff — это комплексное состязание Red Team и Blue Team, максимально приближенное к реальным условиям.

«В Standoff мы можем в ограниченные сроки отработать командное взаимодействие и проверить свои наработки, которые затем корректируем и используем уже в реальных проектах. Кроме того, атмосфера кибербитвы создаёт определённый стресс, что тоже ценно для опыта. На мой взгляд, главная цель участия — сплочение нас как профессионалов и работа на результат для повышения престижа компании», — поделился один из участников команды.

Битва длится несколько дней, в этом году четыре, с 10 утра до 8 вечера, и включает в себя несколько этапов. Сначала команды нападения эксплуатируют уязвимости во внешнем периметре, пытаются пробиться в промежуточную DMZ-зону, а затем переходят во внутренний периметр и реализуют недопустимые, или критические, события.

Под критическими событиями понимаются последствия инцидентов, которые несут серьёзный риск для объектов сектора: утечка данных, остановка оборудования, компрометация системы или бизнес-процессов. Именно за реализацию таких сценариев атакующие получают наибольшее количество баллов.

При этом одной реализации события недостаточно: нужно корректно заполнить отчёт. В нём подробно описывается каждое действие, указывается ресурс, где была выявлена уязвимость или реализовано событие, а также прикрепляются скриншоты. Жюри рассматривает отчёт и может принять его, отклонить или отправить на доработку.

Баллы начисляются и за эксплуатацию уязвимостей определённых классов, среди них:

• LPE — локальное повышение привилегий;
• RCE — удалённое выполнение кода;
• SQLi — внедрение SQL-кода;
• Path traversal — выход за пределы каталога;
• SSRF — подделка запроса со стороны сервера;
• XSS — межсайтовый скриптинг и др.

Подсчёт баллов зависит от условий конкретной битвы. Победители определяются по наибольшему количеству баллов за выявленные уязвимости и реализованные критические события.

В этом году команда SPACE x Pwn3dP0ss3 реализовала 10 недопустимых событий и выявила 25 уязвимостей. Наибольшее количество находок было обнаружено в банковской и телеком-сферах.

«В этом году на Standoff мы заняли 10-е место, и это хороший результат. В таких кибербитвах участвуешь прежде всего ради практики: это отличная возможность поработать с незнакомой инфраструктурой, максимально похожей на сети реальных компаний, и прокачать навыки в боевых условиях», — рассказал участник команды.

Все четыре дня команда была на связи в личных и общих каналах. Участники в реальном времени синхронизировали заметки и находки, чтобы видеть действия и наработки друг друга.

«Участвовать интересно, потому что ты постоянно учишься у коллег и других команд чему-то новому. За четыре дня непрерывных соревнований, конечно, устаёшь, но получаешь удовольствие от проделанной работы и такого результата, как место в топ-10», — добавил участник.

Командная работа и роль капитана

Формат удалённого участия в составе объединённой международной команды для экспертов Compliance Control пока остаётся относительно новым, но это не мешает участникам действовать слаженно и оперативно.

Командная работа во многом зависит от действий и настроя капитана. В случае с SPACE x Pwn3dP0ss3 эту роль взяла на себя специалистка, которая смогла объединить участников и удерживать общий фокус на результате.

«В капитане команды мы увидели качества, необходимые лидеру: экспертность, компетентность, умение направлять и вести за собой. Она с самого начала проявляла инициативу и удерживала лидерскую позицию на протяжении соревнований. Для нас важно, что лидерство в команде определяется профессионализмом, ответственностью и способностью вести людей к результату», — отметил руководитель направления пентестов Compliance Control Евгений Кудашов.

Теперь, когда Standoff позади, команда анализирует опыт этого года, готовится к будущим соревнованиям и продолжает оттачивать навыки для новых побед.

Сообщение Как CTF-команда Compliance Control готовится к кибербитвам появились сначала на Сompliance Сontrol.

Сегодня ритейл – как и любую отрасль – уже нельзя рассматривать в отрыве от других: и онлайн, и офлайн-торговля напрямую связаны с платёжной инфраструктурой и технологическим стеком, и функционирование взаимосвязанных бизнес-процессов должно быть максимально устойчивым и защищённым.

Compliance Control вошла в число ИБ-компаний, эксперты которых приняли участие в обсуждении текущих тенденций развития российского рынка ритейла и остро стоящих вопросов его безопасности.

Делегатом от лица компании стала директор по развитию бизнеса Compliance Control Елена Терехова, а в завершающий день форума, 25 июня, в экспертной сессии «Кибербезопасность: контроль и устранение уязвимостей» принял участие коммерческий директор консалтинговой группы Compliance Control & Rakasta Аркадий Прокудин.

В рамках экспертной сессии эксперты обсудили критические киберугрозы и риски этого года, регуляторные меры безопасности в отношении ритейла, проблемы импортозамещения ИБ-решений и многое другое. Центральное место в дискуссии заняли вопросы, связанные с защитой клиентов – их платёжных и персональных данных, — и сохранением их доверия. Эксперты поделились наблюдениями применительно к актуальным мошенническим схемам, связанным с картами лояльности и бонусными программами, опытом защиты приложений, сервисов и онлайн-платформ от хакерских атак.

«Говоря о взаимосвязи ритейла с другими сферами бизнеса и обеспечении его защиты, мы обращаемся к концепции «Вселенной безопасных платежей» — модели, которая помогает видеть не отдельные требования, стандарты или проверки, а всю экосистему целиком и понимать взаимосвязь между банками, платежными сервисами, ритейлом, технологиями и требованиями безопасности. Там, где есть платеж, есть данные, ответственность и доверие, а доверие начинается с безопасности», — отметил Аркадий Прокудин.

Сообщение Эксперты Compliance Control приняли участие в форуме «Неделя Российского Ритейла — 2026» появились сначала на Сompliance Сontrol.

В этом году в битве приняли участие 22 атакующие команды из разных стран мира, включая команду Compliance Control Pwn3dP0ss3, выступившую в коллаборации с казахской командой SPACE.

В составе объединённой команды: специалисты по тестированию на проникновение Александр Ястремской, Олег Конопьянов, Артём Ермаков, Темирлан Жолдасов, Бекзат Джангасиев, Амиржан Куаныш, Бейсебай Куандыков и старший специалист по тестированию на проникновение Владимир Савостин. Капитан команды — ведущий специалист по анализу защищенности Compliance Control Евгения Чуликова.

По словам участников, соревнование получилось очень показательным и интенсивным. Специалисты удалось реализовать 10 недопустимых событий и выявить 25 уязвимостей, наибольшее количество которых было обнаружено в банковской и телеком-сферах.

По итогам битвы команда SPACE x Pwn3dP0ss3 вошла в топ-10, заняв 10-е место. Эту позицию эксперты удерживают уже второй год подряд, и, несмотря ни на что, остаются среди сильнейших.

Тем временем 19 июня, в заключительный день Standoff 17, с докладом в рамках Standoff Talks для комьюнити выступил старший специалист по тестированию на проникновение Compliance Control Владимир Савостин. Эксперт подробно рассказал о механизме EvilPrinter – новом критическом векторе принудительной NTLM-аутентификации через протоколы печати Windows, обнаруженном Исследовательским центром компании. Владимир описал варианты развития сценариев атаки с использованием этого механизма и дал рекомендации, позволяющие снизить вероятность принуждённой аутентификации и сократить время обнаружения проблемы.

Поздравляем участников Standoff 17 с прекрасными результатами и желаем удачи на следующих соревнованиях!

Сообщение CTF-команда Compliance Control вошла в топ-10 по итогам международной кибербитвы Standoff 17 появились сначала на Сompliance Сontrol.

Конференция «Финтех в безопасности» — это профильное мероприятие, в рамках которого обсуждаются наиболее серьёзные вызовы и актуальные тренды отрасли. Ежегодно оно проводится не только в РФ, но и в нескольких странах СНГ: Республиках Таджикистан, Узбекистан и Казахстан, но именно в Москве оно набирает наибольший масштаб и собирает наибольшую аудиторию.

В этом году у конференции появился стратегический информационный партнёр – Anti-Malware. Партнёром деловой части – компания Damask.

Ещё одним значимым нововведением этого года стало разделение программы мероприятия на два параллельных трека, один из которых был посвящён бизнесу, другой – технологиям. Оба трека включали в себя экспертные сессии, разбор практических кейсов и выступления, освещающие отдельные вопросы и аспекты информационной и кибербезопасности.

На торжественном открытии конференции прозвучали выступления сооснователей Compliance Control & Rakasta Ивана Твердохлебова и Евгения Бабицкого, которые не только познакомили слушателей с историей развития и ключевыми направлениями деятельности своей группы компаний и дали экскурс в проблематику взаимосвязи финтеха, банков, ритейла, маркетплейсов, ИТ и ИБ, но и задали вектор всем дальнейшим дискуссиям и докладам, сформулировав цель конференции и работы Compliance Control & Rakasta в целом – выстраивание доверия между всеми игроками рынка и их клиентами.

Евгений Бабицкий начал свой доклад очень неожиданным образом – не перешёл сразу к рейтингам и достижениям, трендам в мире технологий и их безопасности, а заговорил о ещё не далёком прошлом, когда всё, о чём мы говорим сегодня, было непредставимым. Когда для детей предметами роскоши были карточки-вкладыши, а для взрослых деньги были ещё материальны, и каждый обмен или оплата были вещественны, но при этом строились на доверии – ценности, которая всегда была и остаётся на первом месте в любых отношениях и сделках. Сегодня мы живём в гораздо более непростом с технологической точки зрения мире, где всё происходит с невероятной скоростью – это касается бизнес-процессов, финансовых транзакций и всеобщего развития. Всё это напрямую связано с цифровой трансформацией – без неё такая скорость была бы недостижима. И обеспечение её безопасности становится первостепенной задачей. А безопасность, как отметил Евгений, начинается с доверия.

Следом за этим эксперты Compliance Control & Rakasta и приглашённые спикеры собрались на сцене главного зала для участия в пленарной дискуссии, посвящённой обсуждению главных трендов информационной и кибербезопасности в финтехе в России, СНГ и странах региона EMEA; угроз, представляющих наибольший риск для платёжных систем и финтех-компаний, а также практическим подходам к защите данных.

Модератором дискуссии выступил коммерческий директор группы компаний Compliance Control & Rakasta Аркадий Прокудин.

Александр Товстолип, руководитель управления информационной безопасности Ассоциации ФинТех, отметил, что тесное взаимодействие компаний из различных индустрий требует повышенного внимания к обеспечению их киберустойчивости. Он отметил, что бесшовное взаимодействие банковских, финтех- и ритейл-сервисов через интерфейсы, с одной стороны, открывает новые возможности для пользователей, а с другой – увеличивает поверхность атаки и создает соответствующие риски кибербезопасности.

«Самое слабое с точки зрения безопасности звено в этой цепочке может поставить под угрозу всю экосистему. Если рисками кибербезопасности не управлять в том числе на уровне экосистемы, доверие клиентов теряется не к одному из ее компонентов — не к отдельному банку или ритейл-компании, а ко всей экосистеме сразу», — отметил Александр Товстолип.

Вячеслав Касимов, директор по информационной безопасности Банка Точка, сфокусировал внимание участников на наиболее уязвимом участнике всех процессов – человеке, подчеркнув важность обучения сотрудников, а также личной ответственности и осознанности специалистов. Особая важность отводится при этом аспекту разработки решений, лежащих в основе этих процессов: для дальнейшей надёжности необходим безопасный фундамент. ИИ, который сегодня задействован практически во всём, может быть одновременно действенным инструментом защиты и уязвимостью.

Директор по информационной безопасности Hoff Tech Андрей Эли рассказал об автоматизации процессов и роли ИИ в ритейле. «Искусственный интеллект — это своего рода катализатор: он подчеркивает уже имеющиеся у вас сильные стороны, а слабые стороны из маленького, локального беспорядка превращает в большой хаос. Нельзя сказать, что внедрение ИИ полностью все изменило — риски, о которых мы говорим, будь то доступы или ключи, остались прежними. Просто появился еще один новый инструмент, который можно и нужно внедрять, но важно учитывать связанные с ним риски и уметь с ними справляться».

Ольга Миньзюк, руководитель направления оценки нефинансовых рисков Московской Биржи, подробнее развила тему значимости информационной безопасности для финтех-организаций, отметив, что, как бы маловероятно риски ни были, они никогда не равны нулю. Эксперт также отметила тренд на синергию: «Нужно принципиально улучшать подход к взаимодействию инфобезопасности, бизнеса и ИТ и стремиться к «коробочному» решению, когда ИБ не является отдельным компонентом процессов, а, наоборот, встраивается в них на протяжении всех этапов работы. Сделать это можно за счёт умения предоставлять измеримые результаты и риски. Обсуждение вероятных угроз и проблем уже недостаточно – нужны точные, измеримые показатели, с которыми можно работать».

Подводя итоги пленарной сессии, Аркадий Прокудин обобщил упомянутые тренды и вызовы, такие как: взаимовлияние и важность сплочённости разных сфер и индустрий, внедрение безопасности на начальном этапе работы с продуктом или услугой, ускорение процессов, рост сложности кибератак, и подчеркнул, что всё – и ответственность за надёжность бизнеса, и риски ошибок и просчётов, и возможности для развития и совершенствования – в наших руках. По словам эксперта, величайшие достижения человечества, например проведение расчётов для полёта в космос, были сделаны с помощью гораздо более простых и слабых технологий, по сравнению с которыми даже телефоны, которыми мы пользуемся сегодня, являются сверхкомпьютерами. Вопрос в том, заметил он, как и для чего их использует каждый из нас.

После пленарной сессии бизнес-трек продолжился экспертными докладами о роли и ценности экспертного консалтинга, нетехнических аспекты безопасной разработки (SSDLC), сертификации и аудите, инструментам защиты платёжных и персональных данных.

В рамках технологического трека прозвучали доклады, посвящённые стратегиям и методикам пентестов, результатам работы исследовательского центра Compliance Control & Rakasta, отдельным критическим уязвимостям, защите нестандартных сред, обучению и международным стандартам безопасности.

В конце трека прозвучало выступление основателя Compliance Control Ивана Твердохлебова о значимости аудита не как разовой проверки ради сертификата, но практики, направленной на поддержание высокого уровня защищённости и соответствия стандартам безопасности. Также эксперт представил аудитории платформу Compliance App – решение, призванное помочь CISO и compliance-менеджерам управлять задачами по соблюдению регуляторных и внутренних требований, координировать работу отдельных сотрудников и подразделений, и обеспечивающее вовлечённость аудитора в непосредственный процесс работы. В рамках доклада был продемонстрирован функционал платформы, её версии и их преимущества, а также планы на дальнейшее развитие продукта в соответствии с отзывами и пожеланиями клиентов.

Московский «Финтех в безопасности 2026» стал не просто конференцией, но масштабным событием в области ИБ, банков, финтеха и ритейла, на котором были продемонстрированы преимущества и вызовы взаимодействия экспертов из разных индустрий, а также результаты и достижения их совместной работы.

Сообщение Compliance Control & Rakasta провели ежегодную международную конференцию «Финтех в безопасности 2026» в Москве появились сначала на Сompliance Сontrol.

«Финтех в безопасности» — это профильное мероприятие, посвященное ключевым вопросам безопасности платёжной инфраструктуры и представляющее интерес для топ-менеджеров банков, маркейтплейсов, финтех- и ритейл-компаний, а также руководителей и технических экспертов в области ИБ/ИТ и искусственного интеллекта.

В рамках пленарной дискуссии и экспертных сессий представители международной консалтинговой группы Compliance Control & Rakasta и приглашённые спикеры обсудят:              

• тренды информационной и кибербезопасности в финтехе в России, СНГ и странах региона EMEA;
• угрозы, представляющие наибольший риск для платёжных систем и финтех-компаний;
• кейсы атак и защиты инфраструктуры на примере опыта участников рынка;
• роль и ценность экспертного ИБ-консалтинга;
• практические подходы к защите данных «чужими руками»;
• а также наиболее эффективные инструменты защиты данных и выполнение требований регуляторов.

Среди приглашённых спикеров конференции:

• Александр Товстолип, Ассоциация ФинТех;
• Сергей Демидов, Московская Биржа;
• Вячеслав Касимов, Банк Точка;
• Юрий Клочко, ДАМАСК – безопасность информации и цифровая независимость;
• Михаил Спиридонов, Два Пиэр.

Партнёр деловой программы – Damask и компания РЕСТАРТ – разработчик AI и защищенных корпоративных ИТ-систем. Стратегический информационный партнёр – Anti-Malware.

Сообщение «Финтех в безопасности 2026» — уже завтра! появились сначала на Сompliance Сontrol.

Кибербитва Standoff 17 будет проходить с 16 по 19 июня в Москве, в Кибердоме. Это крупнейшее ежегодное соревнование для ИБ-специалистов в формате Red Team vs Blue Team, в ходе которого команды атакующих и защищающихся моделируют реальные кибератаки и отрабатывают сценарии защиты в инфраструктуре цифрового города.

Наша команда Pwn3dP0ss3 в коллаборации с казахской командой SPACE выступит на стороне Red Team: в течение четырёх дней участники будут имитировать кибератаки на предприятия и организации ИТ-, банковского, промышленного и других секторов виртуального государства F, эксплуатируя их уязвимости. Цель участников – выстроить наиболее эффективную тактику нападения и добиться реализации недопустимых событий.

Команда нашей компании состоит из опытных специалистов по пентесту и AppSec, уже принимавших участие в различных профильных соревнованиях и турнирах — CTFZone, VolgaCTF, BRICS+ CTF и других. В 2025 году команда SPACE x Pwn3dP0ss3 вошла в топ-10 по результатам кибербитвы Standoff 15.

Помимо соревнования в Кибердоме пройдут и другие мероприятия Standoff – митапы, выставки, презентации ИБ-продуктов и решений.

19 июня с докладом на Standoff Talks выступит старший специалист по тестированию на проникновение Compliance Control Владимир Савостин.

Standoff Talks для комьюнити – это митап практикующих экспертов, хакеров и энтузиастов, технологическая сессия с обсуждением актуальных тем из области ИТ, ИБ и кибербезопасности, разбором кейсов, открытой дискуссией и нетворкингом.

Владимир Савостин расскажет об одном из последних кейсов Исследовательского центра Compliance Control – обнаружении нового критического вектора принудительной NTLM-аутентификации через протоколы печати Windows, получившего название «EvilPrinter».

Мы гордимся нашими экспертами и желаем им успешной игры и выступлений!

Сообщение Compliance Control примет участие в кибербитве Standoff 17 и на митапе Standoff Talks появились сначала на Сompliance Сontrol.