Аттестация по ИБ | 11 декабря 2025

Навигатор по кибер-законам РБ для Red Team и CISO: как превратить требования ОАЦ в сценарии для пентеста

Навигатор по кибер-законам РБ для Red Team и CISO: как превратить требования ОАЦ в сценарии для пентеста

От теории к боевой практике

В индустрии информационной безопасности существует опасный разрыв между тем, что написано в документах, и тем, что происходит в сети организации на самом деле. Нормативные требования часто воспринимаются IT-департаментами как скучные, бюрократические чек-листы: «установить firewall», «включить логирование», «проверить сложность паролей». Эти пункты механически закрываются перед аттестацией, создавая «бумажный щит».

Но настоящий смысл регуляторики раскрывается только в одном случае: когда CISO (Chief Information Security Officer) задает команде Red Team (этичным хакерам) прямой вопрос: «Сможете ли вы это взломать?». И когда ответ оказывается «Да», становится ясно, что требование закона выполнено формально, а защита не работает.

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


Три столпа белорусской ИБ-регуляции

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

  • Приказ ОАЦ №66 (включая актуальные редакции, в т.ч. №195) — «Техническая конституция». Документ определяет конкретные меры защиты: парольные политики, контроль доступа, антивирусную защиту, системы обнаружения вторжений. Это база для аттестации любой информационной системы (ИС).
  • Указ Президента №449 (от 09.12.2019) — Стратегический документ. Он ввел понятие критически важных объектов информатизации (КВОИ) и закрепил требования по киберустойчивости, включая обязательный аудит и оценку эффективности мер защиты.
  • Закон №99-З «О защите персональных данных» (от 07.05.2021) — Белорусский аналог GDPR. Регулирует всё, что касается данных граждан: от согласия на обработку до трансграничной передачи и шифрования каналов связи.

Три аналогии для тех, кто не профессионал

Чтобы обосновать бюджет на Red Team перед руководством, которое далеко от IT, используйте эти три метафоры.

1. Парольная политика как замок на двери

Требование: «Пароль должен быть сложным — минимум 8 символов, спецсимволы».
Аналогия: Это как требование установить замок на входную дверь. Можно поставить дешевый замок, который открывается скрепкой, а можно — сейфовый механизм.
Red Team: Хакер не смотрит на сертификат замка. Он просто пробует подобрать ключ. Если Red Team подбирает пароль за 30 минут — замок оказался муляжом, и аудитор фиксирует нарушение, несмотря на наличие политики на бумаге.

2. Аудит системы как техосмотр автомобиля

Требование: «Ежегодный аудит систем ИБ на соответствие Указу №449».
Аналогия: Это техосмотр машины. Вы можете получить штамп, что тормоза исправны. Но если на гололеде выяснится, что ABS не срабатывает — штамп вас не спасет от аварии.
Red Team: Это краш-тест на полигоне. Команда проверяет тормоза в экстремальных условиях. Если хакеры получают доступ к базе данных, значит, ваш ежегодный аудит был фикцией.

3. Защита данных как тайна письма

Требование: «Шифрование при передаче персональных данных».
Аналогия: Отправка письма. Вы можете положить секрет в прозрачный файл (открытый канал) или в запечатанный свинцовый конверт (шифрование).
Red Team: Хакер перехватывает почтальона. Если он может прочитать письмо без вскрытия конверта — закон нарушен.


Полная матрица: Требования ОАЦ и Сценарии Red Team

Ниже представлена детальная карта соответствия (Mapping), связывающая конкретные пункты законодательства с техниками MITRE ATT&CK и вердиктами аудита.

Таблица 1. Сопоставление требований кибербезопасности в Беларуси

Требование / Тип требованияСценарий атаки Red TeamРезультат аудита и Индикатор
Приказ ОАЦ №66, п. 3.5: Политика сложных паролей (мин. 8 символов, спецсимволы, без словарных слов).Password Spraying + Kerberoasting: Атакующий перебирает 1000+ учетных записей с паролями типа Minsk2025!, Winter123. Kerberoasting на SPN-аккаунты позволяет сбрутить пароли оффлайн.FAIL: Успешная компрометация 4-5% аккаунтов. Event ID 4768 в логах. Доказательство невыполнения требований сложности паролей на практике.
Указ №449, п. 16-19: Аудит ИБ КВОИ. Проведение ежегодной оценки эффективности в реальных условиях.Full Chain Attack (APT-like): Внешняя рекогносцировка → Фишинг → Lateral Movement. Цель: продемонстрировать, что текущий «бумажный» аудит не выявляет реальных векторов атак.CRITICAL: Red Team получил права Domain Admin. Это прямое доказательство несоответствия п. 19 Указа (система защиты неэффективна). Требуется пересоздание системы ИБ.
Закон о ПДн №99-З, ст. 4-7: Разграничение прав доступа, шифрование ПДн при передаче (обязательное).Network Sniffing / MiTM: Перехват трафика, если данные передаются по HTTP/FTP или используют устаревший TLS. Использование Wireshark для извлечения ФИО и телефонов.CRITICAL: Для регулятора (НЦЗПД) это явное свидетельство нарушения. Пакеты сохраняются как PCAP. Риск штрафа и запрета обработки ПДн.
Приказ ОАЦ №66, п. 2.1-2.3: Контроль несанкционированного доступа (НСД), разделение ролей, сегментация.Lateral Movement + Privilege Escalation: Пользователь из сегмента «Маркетинг» получает доступ к сегменту «Бухгалтерия» через «прыгающую» станцию (jump host) или открытый SMB.WARNING/FAIL: Red Team подтвердил, что сегментация неэффективна. В логах видны аномальные cross-segment попытки доступа. Рекомендация: внедрить Zero Trust, 802.1X.
Указ №449, п. 8: Защита КВОИ от деструктивных действий (целостность, доступность).Ransomware Simulation / Data Destruction: Симуляция работы шифровальщика. Проверка, изолированы ли резервные копии (immutable backups) от основной сети.FAIL: Если бэкапы зашифрованы вместе с основными данными — нарушение п. 8. Доказательство невозможности восстановления за регламентное время (RTO).
Закон о ПДн №99-З, ст. 10: Согласие субъекта ПДн; ст. 6-9 Обработка ПДн без согласия.Social Engineering + Data Extraction: Red Team связывается с сотрудниками под видом аудитора/клиента и запрашивает выгрузку базы без оснований. Проверка процедур верификации.CRITICAL: Невозможность предоставить реестр согласий или факт выдачи данных постороннему лицу. Red Team сохраняет скриншоты переписки.
Приказ ОАЦ №66, п. 3.3-3.4: Антивирусная защита, обновление ПО, управление уязвимостями.Vulnerability Scanning + Exploitation: Запуск Nessus/OpenVAS. Эксплуатация известных уязвимостей (напр., MS-17-010, Log4Shell) для компрометации хоста.FAIL: Наличие exploitable уязвимостей старше 30-60 дней (список CVE-202X-XXXX). Антивирус не заблокировал полезную нагрузку Metasploit. Требование: немедленный патчинг.
Приказ ОАЦ №66, п. 7.7-7.8, п. 9.4: Сбор и отправка в ОАЦ событий ИБ (мониторинг и реагирование).Incident Detection & Response Simulation: Red Team совершает контролируемый «шумный» инцидент (SQL-injection, brute-force). Проверяется: были ли события залогированы и отправлены в SIEM/ОАЦ.WARNING/FAIL: События не залогированы или категорированы неправильно. Нет интеграции с ОАЦ (п. 9.4 нарушен). Отчет: «Организация слепа». Требование: развернуть SIEM (ELK, Splunk).
Приказ ОАЦ №66, п. 1.2: Классификация информационной системы.System Misclassification Test: Red Team проверяет, правильно ли классифицирована ИС. Например, в системе обработки ПДн найдены данные, требующие класса защиты 3-ин, а система аттестована как 4-ин.CRITICAL: Система классифицирована неправильно. ОАЦ при проверке переклассифицирует ее выше, аннулирует текущий аттестат. Требуется полная переаттестация.
Закон о ПДн №99-З, ст. 1-3: Определение оператора, прозрачность для субъектов ПДн.Data Subject Privacy Violation: Red Team запрашивает (от имени субъекта) информацию о своих данных. Организация отказывает или нарушает сроки (15 дней).FAIL: Нарушение прав на информацию. НЦЗПД регистрирует жалобу. Red Team документирует нарушения сроков ответа.

Технический разбор ключевых атак

Понимание механики атаки необходимо для её предотвращения. Рассмотрим детально два сценария.

Сценарий 1: Password Spraying и Приказ ОАЦ №66

Требование: Организация обязана реализовать политику паролей, блокировать учетные записи при переборе.

Как это выглядит в Blue Team (Защита):
Администратор Active Directory настраивает Group Policy Object (GPO):

  • Минимальная длина пароля: 8
  • Блокировка на 30 минут после 5 неудачных попыток.

Как это взламывается Red Team:
Хакеры знают о блокировке после 5 попыток. Поэтому они не ломают одного пользователя, они ломают всех сразу, но аккуратно.

  • Recon: Получение списка 500 email-адресов сотрудников (OSINT).
  • Spraying: Red Team пробует один пароль Minsk2025! для всех 500 пользователей. Это всего 1 попытка на аккаунт — блокировка не срабатывает.
  • Статистика: Из 500 человек 5-10 гарантированно используют этот пароль.
  • Kerberoasting: Получив доступ к рядовому пользователю, атакующий запрашивает TGS-билеты для сервисных аккаунтов, выгружает их и расшифровывает хэши на видеокарте.

Что видит аудитор: В отчете Red Team — список паролей в открытом виде. Вывод: политика паролей неэффективна.

Сценарий 2: Утечка данных (MitM) и Закон о ПДн

Требование: Передача данных только по защищенным каналам (HTTPS/TLS).

Как это взламывается Red Team:
Атакующий подключается к той же Wi-Fi сети (или компрометирует маршрутизатор) и запускает Wireshark или Bettercap. Если мобильное приложение использует устаревший TLS или забытый HTTP endpoint, данные видны как на ладони.

Пример перехваченного HTTP-запроса (Proof of Concept):

GET /api/v1/user/profile?id=9942 HTTP/1.1
Host: api.legacy-system.by
User-Agent: AndroidApp/2.0
Accept: application/json
Authorization: Bearer eyJhbGciOiJIUzI1Ni...

HTTP/1.1 200 OK
Content-Type: application/json

{
  "full_name": "Петров Петр Петрович",
  "passport": "HB1234567",
  "phone": "+37529XXXXXXX",
  "address": "г. Минск, ул. Ленина, д. 1"
}

Наличие такого скриншота в отчете Red Team — это гарантированный штраф от НЦЗПД за нарушение ст. 4 Закона о защите персональных данных.


Комплексный сценарий: Red Team и CISO-чек-лист

Представим белорусский банк или ритейлера. Он должен соответствовать всем трем документам.

  • День 1 (Разведка): Red Team находит сервер с версией Apache 2.4.49 (уязвима к CVE-2021-41773).
  • День 2 (Nessus): Сканер показывает открытые порты 22, 80, 8080 и отсутствие MFA на RDP.
  • День 3 (Фишинг): Сотрудник бухгалтерии открывает файл "Сверка_актов.xlsx", запуская макрос.
  • День 5 (Lateral Movement): Red Team, используя украденную сессию, движется по сети. Обнаруживает папку \\Backup\SQL с полным дампом базы клиентов в открытом виде (нарушение правил резервного копирования).
  • День 6 (Эксфильтрация): Выгрузка 500 МБ данных.

Итоговый скоринг для аудита:

  • Приказ №66 (управление уязвимостями): FAIL
  • Указ №449 (мониторинг инцидентов): FAIL (атаку не заметили)
  • Закон о ПДн (защита данных): CRITICAL (утечка)

Как CISO использует результаты Red Team (Бизнес-обоснование)

Red Team отчет дает CISO цифры для финансового директора (CFO). Это не просто "нас взломали", это "мы предотвратили штраф".

Таблица 2. Матрица рисков и инвестиций

Требование / НарушениеРезультат атаки Red TeamРиск и последствияНеобходимая инвестиция
Сложные пароли (Приказ №66)Скомпрометировано 15 аккаунтов за 2 часа.Остановка бизнеса, доступ конкурентов.Внедрение MFA (Token/App). Бюджет: низкий.
Сегментация сети (Указ №449)Получен доступ из Wi-Fi для гостей в серверную зону.Заражение шифровальщиком всей сети.Настройка VLAN, NAC, 802.1X. Бюджет: средний.
Шифрование ПДн (Закон №99-З)Перехвачены данные 500 клиентов в открытом виде.Штраф до 200 БВ + репутация.Настройка TLS 1.3 на балансировщике. Бюджет: минимальный.
Логирование (Приказ №66)Атака шла 5 дней, SOC молчал.Невозможность расследования, отзыв аттестата.Внедрение/настройка SIEM. Бюджет: высокий.

Дорожная карта для организации

Для успешного прохождения проверок ОАЦ и НЦЗПД организации следует внедрить циклический процесс, где Red Team является валидатором защиты.

Шаг 1: Классификация (Неделя 1)
Определить, является ли ваша ИС КВОИ (согласно Указу №449) и какой объем ПДн она обрабатывает. От этого зависит класс типовой информационной системы.

Шаг 2: Внутренний Аудит (Недели 2-4)
Провести «санитарную» проверку по чек-листу Приказа №66. Устранить очевидные проблемы (открытые RDP, дефолтные пароли, отсутствие антивирусов).

Шаг 3: Red Team Пилот (Недели 5-8)
Пригласить внешнюю команду для отработки конкретных векторов (например, только Password Spraying и Network Segmentation Test). Получить отчет с доказательствами.

Шаг 4: Hardening (Недели 9-24)
Реализовать исправления: внедрить MFA, настроить SIEM, зашифровать бэкапы, перенастроить Firewall.

Шаг 5: Полномасштабный Red Team (Недели 25-26)
Провести полную эмуляцию атаки (APT simulation). Убедиться, что SOC видит атакующих, а средства защиты блокируют продвижение.

Шаг 6: Аттестация ОАЦ (По готовности)
Пригласить аттестующую лабораторию. Предоставить им отчеты Red Team как доказательство выполнения п. 27.3 Указа №449 («оценка эффективности в реальных условиях»). Получить аттестат соответствия.

Использование Red Team подхода превращает кибербезопасность из «бумажной работы» в реальный, измеримый бизнес-процесс. И именно этого требуют современные белорусские законы.

Как вам статья?

Следующий пост

Политики информационной безопасности, которые выдерживают удар Red Team: от «бумажной безопасности» к живым контролям

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

20 декабря 2025