«Служба безопасности, это не протокол, который можно проверить по RFC. Это люди, которые могут ошибаться, лениться или намеренно искажать реальность, чтобы соответствовать планам и отчётам. Их обман редко выглядит как прямая ложь. Чаще это полуправда, замалчивание, технический жаргон и создание иллюзии контроля. Ваша задача — научиться видеть разрыв между декларациями и реальным положением дел.»
Почему служба безопасности может вас обманывать
Обман со стороны службы информационной безопасности (СИБ), это не всегда злой умысел. Часто это системная проблема, возникающая из-за противоречивых требований, в которых оказывается отдел. Понимание этих причин помогает перейти от поиска виноватых к анализу процессов.
Во-первых, существует конфликт целей. Формальная цель СИБ — обеспечить безопасность. Фактическая, продиктованная руководством, — обеспечить формальное соответствие требованиям регуляторов (ФСТЭК, 152-ФЗ) с минимальными затратами и без остановки бизнес-процессов. Когда эти цели сталкиваются, служба безопасности вынуждена создавать видимость выполнения обеих. Отсюда появляются отчёты о «принятых мерах», которые на деле являются лишь настройкой базовых политик без оценки реальных рисков.
Во-вторых, давление отчётности. Регуляторная отчётность требует чётких, измеримых показателей. Невозможно отчитаться «мы повысили культуру безопасности» или «снизили неопределённость». Нужны цифры: «установлено 100% СЗИ», «проведено 5 учений», «обработано 100 инцидентов». Это приводит к тому, что деятельность подменяется сбором метрик. Установка средства защиты информации (СЗИ) становится важнее анализа, действительно ли оно закрывает уязвимость в вашем конкретном контуре. Количество обработанных инцидентов растёт за счёт автоматического закрытия ложных срабатываний, а их качественный разбор не проводится.
В-третьих, профессиональная изоляция. Специалисты по безопасности часто работают в парадигме «стандарт — внедрение — проверка». Они могут искренне верить, что следование руководящим документам ФСТЭК (РД) автоматически делает инфраструктуру безопасной. При этом они могут не понимать глубины бизнес-процессов, специфики разрабатываемого ПО или реальных схем работы сотрудников. Их уверенность в надёжности построенной системы основана на теоретической модели, а не на практике эксплуатации.
Признаки, которые должны вас насторожить
Обман редко бывает откровенным. Он проявляется в стиле коммуникации, качестве артефактов и реакции на неудобные вопросы.
1. Язык заменяет суть
Вместо понятных объяснений звучит поток аббревиатур и терминов: «ИСПДн», «ГИС», «СОВ», «МЭ», «НСД». На вопрос «как это защищает нас от утечки?» следует ответ не о механизмах контроля, а о соответствии пункту РД ФСТЭК. Если специалист не может объяснить суть защиты на пальцах, без ссылок на документы, возможно, он и сам не до конца понимает, как это работает в вашей среде.
2. Абсолютная уверенность и отсутствие инцидентов
Фраза «у нас всё под контролем, инцидентов не было» — красный флаг. В современной инфраструктуре инциденты есть всегда: подозрительная активность, срабатывания систем обнаружения вторжений (СОВ), попытки фишинга. Их отсутствие в отчётах чаще говорит не об идеальной защите, а о неработающих системах мониторинга, завышенных порогах срабатывания или политике замалчивания. Настоящая безопасность, это процесс постоянного обнаружения и реагирования, а не статичное состояние.
3. Акцент на периметре при игнорировании внутренних угроз
Если все презентации и отчёты СИБ вращаются вокруг межсетевых экранов (МЭ), VPN и защиты периметра, но при этом нет внятной модели внутренних угроз, сегментации сети, управления привилегированными доступами и мониторинга действий пользователей, это дисбаланс. Большинство серьёзных инцидентов начинается внутри сети, с компрометации обычной учётной записи. Игнорирование этого факта — либо наивность, либо нежелание браться за сложные организационные задачи.
4. Отсутствие прозрачности в оценке рисков
Вам представляют список из 10 критических уязвимостей, которые нужно срочно устранить. Спросите: на основании чего они определены как критические? Какая модель оценки рисков использовалась? Как учитывалась вероятность реализации угрозы и бизнес-последствия? Если ответы сводятся к «таковы рекомендации вендора» или «у этой уязвимости высокая оценка по CVSS», значит, оценка рисков для вашей компании не проводилась. CVSS оценивает техническую severity уязвимости в вакууме, но не риск для конкретного бизнеса.
5. Подмена аудита безопасности его симулякром
Проводится «аудит», результатом которого является отчёт на 100 страниц, содержащий исключительно выводы сканеров уязвимостей (типа OpenVAS) и формальные проверки настроек. Отсутствует анализ архитектуры, модели угроз, бизнес-процессов. Нет рекомендаций, приоритизированных по реальному бизнес-риску. Такой аудит, это техническая проверка на соответствие чек-листу, которая создаёт иллюзию деятельности, но не отвечает на главный вопрос: какие ключевые риски угрожают компании и как ими эффективно управлять?
Как проверить: вопросы, которые стоит задать
Переход от подозрений к проверке требует конкретных действий. Задавайте эти вопросы не с позиции обвинения, а с искренним желанием понять.
- О модели угроз: «Можете показать актуальную модель угроз для нашего основного сервиса? Какие топ-3 сценария атаки вы считаете наиболее вероятными и разрушительными для нас?» Если модели угроз нет или она представляет собой копию стандартного списка из методички, значит, защита строится не на ваших рисках, а на абстрактных.
- О метриках и мониторинге: «Какие ключевые метрики безопасности (KPI) вы отслеживаете ежедневно? Можете показать дашборд? Какова доля ложных срабатываний в наших СОВ?» Ответ «мы смотрим логи при необходимости» говорит об отсутствии proactive-мониторинга.
- О планах реагирования: «Что входит в наш план реагирования на инциденты ИБ? Когда в последний раз его отрабатывали на учениях? Можете показать отчёт по итогам учений?» Если учения не проводятся или их сценарий — формальная «утечка файла», план существует только на бумаге.
- О взаимодействии с разработкой: «Как ваша служба участвует в цикле разработки нашего ПО? Есть ли процесс security review для новых функций? Как учитываются требования безопасности в DevOps-процессах?» Разрыв между Sec и Dev — классический признак, что безопасность прикручивается постфактум, а не закладывается в продукт.
Что делать, если обман подтвердился
Обнаружив проблему, не спешите с громкими разоблачениями. Это системный сбой, который требует системного решения.
Первое — сменить фокус с соответствия на риск-ориентированный подход. Инициируйте обсуждение с руководством и СИБ: «Мы тратим ресурсы на формальное соответствие. Давайте определим, какие активы и процессы критичны для бизнеса, и сфокусируем защиту на них». Предложите начать с разработки или пересмотра модели угроз для ключевого сервиса.
Второе — требовать прозрачности и измеримости. Настаивайте на том, чтобы отчёты СИБ содержали не только перечень выполненных работ, но и показатели эффективности: среднее время обнаружения инцидента, среднее время реагирования, процент закрытых уязвимостей с критическим и высоким риском. Эти метрики должны быть достижимыми и привязанными к бизнес-целям.
Третье — интегрировать безопасность в процессы. Безопасность не должна быть отдельным «полицейским» подразделением. Её представители должны быть вовлечены в проекты по разработке, закупкам, изменению инфраструктуры на ранних этапах. Это снижает риски и превращает СИБ из контролёра в партнёра.
Главный итог: доверие к службе безопасности строится не на вере в их непогрешимость, а на прозрачности их методологии, измеримости результатов и способности говорить на языке бизнес-рисков, а не только регуляторных требований. Ваша задача — задавать правильные вопросы и требовать содержательных ответов, выходя за рамки формальных отчётов.