«Законы и стандарты по защите информации часто опираются на формальные, проверяемые процедуры. Но как быть с ситуациями, где нет чёткого «следуй инструкции»? Многие ИБ-решения, это выбор из серой зоны, где на замену интуиции и «ощущениям» должна прийти работающая модель данных.»
От интуиции к доказательной базе: зачем это нужно в ИБ
Специалист по безопасности регулярно сталкивается с вопросами, на которые нет готового ответа в документации регулятора. Нужно ли блокировать этот подозрительный, но не явно вредоносный домен? Достаточно ли контрмер после инцидента? Как расставить приоритеты в устранении сотен уязвимостей, если ресурсы ограничены? Часто решение принимается на основе опыта, косвенных признаков или внутреннего чувства — «у меня ощущение, что тут что-то не так». В малых дозах это нормально, но как системный подход не выдерживает критики. Это невоспроизводимо, недоказуемо при проверке и ведёт к ошибкам, когда масштаб или сложность системы растут.
Альтернатива — модель принятия решений на основе данных (Data-Driven Decision Making, DDDM). Её суть не в слепом следовании алгоритму, а в сознательном выстраивании цепочки: сбор релевантных данных → их обработка и анализ → формулировка проверяемых гипотез → принятие решения → оценка результата и обратная связь. В контексте российских требований ФСТЭК и 152-ФЗ такой подход трансформируется из хорошей практики в необходимость. Он обеспечивает объективность, прозрачность и, что критически важно, доказуемость принятых мер перед аудитором или регулятором.
Что считать данными в контексте информационной безопасности
Данные для ИБ-решений, это не только логи и алерты. Это любая информация, которую можно измерить, зафиксировать и проанализировать.
- Технические метрики: объём подозрительного сетевого трафика, частота срабатывания определённых правил WAF или IDS, время отклика систем после внедрения контроля.
- Операционные данные: количество инцидентов определённого типа за период, среднее время на реакцию и устранение (MTTR), загрузка сотрудников SOC.
- Контекстуальная информация: результаты оценки рисков для конкретных активов, данные о критичности бизнес-процессов, история проверок и предписаний надзорных органов.
- Данные о угрозах: актуальность известных уязвимостей (CVSS) для вашего стека, активность threat-актёров в вашей отрасли, данные из отраслевых ISAC.
Ключ в том, чтобы эти данные не просто собирались «в стол», а были структурированы и доступны для анализа. Часто проблема даже не в отсутствии данных, а в их разрозненности: логи сетевого экрана лежат в одной системе, тикеты по инцидентам — в другой, а оценка рисков — в третьей, в виде PDF-отчёта. Первый шаг к data-driven подходу — консолидация источников.
Базовые принципы построения модели
Модель, это не единая сложная формула, а скорее методология работы. Её можно разложить на несколько повторяющихся этапов.
1. От конкретного вопроса к измеримой гипотезе
Вместо расплывчатого «улучшить безопасность периметра» задаётся конкретный вопрос: «Снизит ли блокировка исходящих подключений на нестандартные порты для пользовательских рабочих станций количество успешных фишинговых инцидентов?». Гипотеза формулируется так, чтобы её можно было подтвердить или опровергнуть данными: «Внедрение правила блокировки исходящего трафика с рабочих станций на порты 8080, 8443 кроме утверждённого списка proxy-серверов снизит количество случаев успешной утечки данных через веб-шеллы на 40% в течение квартала».
2. Определение источников данных и KPI
Для проверки гипотезы нужны данные «до» и «после». Определите, какие метрики будут ключевыми показателями (KPI): количество алертов на подозрительные исходящие соединения, число инцидентов, классифицированных как «утечка через веб», статистика по блокировкам новым правилом. Убедитесь, что эти данные можно собрать.
3. Эксперимент и сбор данных
Изменение внедряется не сразу на всех системах, а, например, в пилотной группе. В идеале используется A/B-тестирование: одна группа рабочих станций работает с новым правилом (Группа А), контрольная группа (Б) — без него. Параллельно ведётся активный сбор и агрегация данных.
4. Анализ и интерпретация
Собранные данные анализируются. Упало ли число целевых инцидентов в Группе А по сравнению с Б и с её же историческими показателями? Возникли ли непредвиденные побочные эффекты — сбои в легитимных бизнес-процессах? Анализ должен ответить не только на вопрос «сработало ли?», но и «почему?» и «какой ценой?».
5. Решение и scaling
На основе анализа принимается решение: внедрять правило повсеместно, доработать его или отказаться. Решение документируется вместе с обоснованием — теми самыми данными и выводами. Это и есть артефакт для внутреннего аудита или проверяющего.
Инструменты и практические шаги для внедрения
Внедрение не требует сразу дорогих SIEM-платформ. Можно начать с малого.
- Инвентаризация данных. Составьте список всех источников ИБ-данных в организации (логи, тикеты, сканеры, отчеты). Оцените их доступность в машиночитаемом виде (API, syslog, базы данных).
- Выберите точку входа. Найдите одну частую, болезненную и измеримую проблему. Например, «длительное время реакции на инциденты типа «фишинг».
- Автоматизируйте сбор ключевых метрик. Настройте простые дашборды в Grafana, используйте ELK-стек для логов или даже сводные таблицы, если объёмы небольшие. Главное — видеть динамику в одном месте.
- Проведите цикл. Примените описанную модель к выбранной проблеме. Задокументируйте гипотезу, данные, анализ и итоговое решение (например, пересмотр playbook для SOC или закупку SOAR).
- Формализуйте процесс. Создайте простой внутренний регламент или шаблон отчёта для обоснования значимых ИБ-решений. В нём должны быть разделы для гипотезы, использованных данных, анализа и выводов.
Со временем простые скрипты и таблицы могут эволюционировать в более сложные системы, использующие методы статистики и machine learning для выявления аномалий или прогнозирования рисков.
Как это согласуется с требованиями регуляторов
Подход, основанный на данных, напрямую ложится на требования стандартов ФСТЭК и 152-ФЗ.
- Обоснованность мер защиты (ст. 16 152-ФЗ). Регулятор требует применения мер, соответствующих актуальным угрозам. Data-driven модель предоставляет именно это обоснование: мы внедрили контроль X, потому что данные показали, что угроза Y является самой частой/дорогостоящей для наших активов уровня Z.
- Управление инцидентами. Требования включают анализ причин инцидентов. Системный сбор данных по каждому инциденту (время, затронутые активы, использованные уязвимости, применённые контрмеры) превращает этот анализ из субъективного разбора полётов в статистическое исследование, выявляющее системные слабости.
- Оценка эффективности СЗИ. Проверяющие вправе спросить, как вы оцениваете, что ваши средства защиты информации работают. Ответ «по ощущениям» не пройдёт. Ответ «вот дашборд, показывающий, что после настройки правила сигнатур в IDS количество успешных атак на веб-приложение снизилось с N до M в месяц, а ложных срабатываний — на P%» — гораздо убедительнее.
- Документирование. Весь цикл принятия решения — гипотеза, данные, анализ, приказ о внедрении — формирует чёткую документальную цепочку. Это сильный аргумент при любой проверке, демонстрирующий зрелость процесса управления ИБ.
Ограничения и подводные камни
Подход не панацея. Слепо доверять данным так же опасно, как и игнорировать их.
- Качество данных. Модель работает только на достоверных и полных данных. Если логи пишутся не со всех критичных узлов или в них нет нужных полей, выводы будут ошибочными.
- «Измеряемо — значит важно». Есть риск концентрироваться только на том, что легко измерить (количество алертов), упуская сложные, но важные аспекты (качественное развитие команды, стратегические угрозы нулевого дня). Данные должны дополнять экспертизу, а не заменять её.
- Интерпретация. Одни и те же данные можно трактовать по-разному. Рост числа обнаруженных уязвимостей может говорить об ухудшении безопасности, а может — об улучшении работы сканера. Важен контекст и критическое мышление.
- Ресурсоёмкость. На первых порах настройка сбора и анализа данных требует времени и компетенций. Стартовать нужно с малого, чтобы получить быстрые wins и поддержку руководства.
Заключение: новая культура принятия решений
Переход от решений «по ощущению» к модели на основе данных, это не только про технологии, но и про культуру в отделе информационной безопасности. Это культура вопросов «на чём основано это решение?», «какие данные это подтверждают?», «как мы измерим результат?». Она делает работу команды прозрачной, предсказуемой и устойчивой к кадровым изменениям. В условиях ужесточения регуляторного давления и усложнения угроз такой подход перестаёт быть опциональным. Он становится основным способом строить защиту, которая не просто формально соответствует букве закона, но и реально, доказательно снижает риски для бизнеса. Начните с одного простого цикла — результаты и ясность, которые он принесёт, станут лучшим аргументом для движения дальше.