Годовой план информационной безопасности проваливается не из-за плохого планирования. Он проваливается из-за того, что его некому защитить. Без авторитета специалиста план остаётся документом, который никто не будет выполнять. Я видел десятки планов, которые умирали не потому что были плохо написаны, а потому что в нужный момент слова специалиста ничего не весили.
Почему проваливаются годовые планы информационной безопасности
Годовой план информационной безопасности проваливается не из-за плохого планирования. Он проваливается из-за того, что его некому защитить.
Специалист может составить идеальный план. Но когда бизнес спрашивает «зачем это нужно», от ответа зависит всё. Если в этот момент слова специалиста ничего не весят, бюджет сокращают, задачи откладывают, план остаётся на бумаге.
Авторитет не в знаниях. Авторитет в том, как ты используешь знания в критических моментах. Когда тебя спрашивают, а ты не знаешь точного ответа. Когда перебивают и требуют коротко. Когда отклоняют твоё предложение, а потом случается именно то, о чём предупреждал. В каждом из этих моментов ты либо укрепляешь доверие, либо теряешь его за раз. Эта статья о том, как распознавать такие ситуации и как вести себя, чтобы тебя начали слушать. А ещё о том, как построить план и дорожную карту, которые действительно можно выполнить.
Почему план информационной безопасности не работает
Проблема в том, что когда приходит время отстаивать ресурсы и приоритеты, мнение специалиста по информационной безопасности уже не имеет веса. Его либо не зовут на ключевые обсуждения, либо зовут, но не слушают. Бизнес решает сократить расходы. Специалист либо молча соглашается, либо пытается возразить, но его слова не доходят. Через несколько месяцев происходит инцидент, который должен был предотвратить один из отменённых пунктов плана. Руководство спрашивает, почему никто не предупреждал. Специалист отвечает, что предупреждал неоднократно. Однако либо забыли про его слова, либо тогда их восприняли как обычную перестраховку.
Разница между планом, который реально работает, и планом, который существует только как файл, заключается не в навыках планирования. Первого специалиста слушают, когда он говорит, что угроза требует немедленной реакции. Второго не слышат даже тогда, когда он оказывается абсолютно прав.
Авторитет нужно строить задолго до того момента, когда придётся защищать бюджет. Не во время защиты, а гораздо раньше.
Как заработать авторитет в информационной безопасности
Специалист может отлично знать уязвимости, векторы атак и требования стандартов. Но если он не может в разговоре с бизнесом объяснить, какую ценность приносят эти знания компании, они остаются бесполезными. Авторитет определяется не объёмом знаний, а тем, как ты их применяешь именно в момент, когда тебя проверяют.
Когда специалист говорит уверенно, конкретно и без лишних слов, показывает, что нужно сделать и что будет, если ничего не делать, бизнес обычно выделяет ресурсы. Когда же он начинает сильно упрощать, уходит от цифр, говорит общими фразами про важность для бизнеса или мямлит, его слова пропускают мимо ушей. Бизнес не обязан разбираться в технике. Но он отлично чувствует, когда перед ним человек, который действительно понимает предмет, а когда перед ним неуверенность или попытка продать идею.
Пять ситуаций в которых теряется доверие специалиста
Нет точного ответа прямо сейчас
Бизнес спрашивает, сколько займёт восстановление после инцидента. Если отвечать расплывчато и неуверенно, доверие сразу снижается. Гораздо лучше честно сказать, что сейчас точного ответа нет, объяснить, что именно нужно проверить, назвать конкретный срок и потом действительно дать ответ в обещанное время.
Тебя перебивают и требуют говорить короче
Ты начал объяснять проблему, а тебя спросили «сколько стоит». Если просто назвать цифру без контекста, позже спросят, почему деньги ушли не туда. Лучше спокойно ответить, что цифры сейчас будут, но без понимания сути защиты через месяц возникнут вопросы, почему ресурсы потрачены неэффективно. После такого ответа большинство перестают перебивать и начинают слушать.
Предложение отклонили а позже риск реализовался
Самый плохой вариант подойти с упрёком «я же говорил». Такой подход вызывает защитную реакцию и поиск виноватых. Гораздо эффективнее спокойно объяснить, что произошло именно то, о чём говорилось раньше, перечислить, какие шаги делаются сейчас для локализации последствий и указать, что нужно внедрить, чтобы ситуация не повторилась. Без обвинений, только факты и план действий.
Ошибка произошла по твоей вине
После внедрения системы возник сбой в важном сервисе и компания понесла убытки. Искать виноватых в поставщике, бюджете или сроках означает быстро потерять доверие. Лучше сразу признать свою ошибку, объяснить, какой момент не учли, описать, как сейчас исправляется ситуация и рассказать, как в будущем будешь проверять, чтобы такого не повторилось.
Несколько раз не послушали но риск остаётся актуальным
После нескольких отказов легко решить, что дальше говорить бесполезно, и промолчать. Когда инцидент всё-таки происходит, спросят, почему не предупреждали. Ответ «я думал, вы не дадите» воспринимается как уход от ответственности. Правильно продолжать предупреждать каждый раз, когда риск остаётся реальным.
Как правильно оценивать приоритеты угроз
Если каждое обращение начинать со слов «угроза высокого уровня», через несколько недель все перестают воспринимать такие слова всерьёз.
Поэтому приоритеты нужно разделять чётко. Высокий приоритет означает, что при реализации актуальной угрозы компания может столкнуться с остановкой ключевых процессов или потерей важных данных уже в ближайшую неделю. Средний приоритет означает, что риски существенно растут и восстановление сильно усложняется, но прямой остановки пока нет. Низкий приоритет означает, что мера улучшает общую защищённость, но без неё пока можно работать. Когда ты последовательно разделяешь эти уровни и говоришь прямо «вот высокий приоритет, вот средний, вот низкий», бизнес начинает воспринимать тебя как человека, который помогает принимать взвешенные решения, а не как того, кто постоянно требует дополнительных ресурсов.
Почему мнение команды важнее мнения руководства
Можно быть в отличных отношениях с руководством, но если команда тебя не уважает, авторитет остаётся неустойчивым.Руководитель почти никогда не принимает решение в одиночку. Он спрашивает мнение IT-директора, системных администраторов, разработчиков. Если они подтверждают, что человек разбирается и с ним уже работали, вес слов специалиста мгновенно растёт. Если же команда молчит или говорит, что он постоянно преувеличивает угрозы, его перестают слушать даже тогда, когда он прав. Поэтому перед любой крупной инициативой стоит сначала обсудить идею с командой и учесть их замечания. Потом показать, как предложение повлияет на их повседневную работу. А на встрече с руководством упомянуть, что администраторы готовы взять настройку, а разработчики подтвердили, что интеграция не затронет текущие проекты.
Если прийти наверх без такой подготовки, руководитель спросит мнение команды, а те ответят, что слышат об инициативе впервые. После такого предложение почти наверняка отклонят.
Как составить план информационной безопасности на год
План на двенадцать месяцев пытается предсказать будущее. К концу года меняется почти всё. Бюджет сокращается, люди уходят, появляются новые угрозы, приоритеты бизнеса смещаются. Жёстко расписанный на год вперёд план очень быстро теряет актуальность. Одно крупное изменение может разрушить всю последовательность задач.
Квартальное планирование устроено иначе. Детально расписываются только ближайшие три месяца с конкретными датами, ответственными и зависимостями между задачами. Всё, что дальше, остаётся общими направлениями без жёстких сроков и точного бюджета. Через три месяца план пересматривается с учётом того, что реально произошло за период. Такой подход позволяет гибко адаптироваться к изменениям, а не переписывать весь год каждый раз, когда что-то идёт не по плану.
Структура годовой дорожной карты
Дорожная карта состоит из четырёх крупных блоков, каждый на квартал. Внутри каждого блока задачи связаны зависимостями. Нельзя начать следующую, пока не закончена предыдущая. Нельзя запустить параллельные процессы без завершения подготовительного этапа.
Первый квартал — базовая основа
Инвентаризация активов, классификация данных, оценка рисков, защита бюджета. Без этого блока все остальные задачи теряют смысл. Если не понимаешь, что защищать и от чего, любые технические меры будут случайными.
Второй квартал — базовая защита
Закрытие уязвимостей, настройка периметра, внедрение систем мониторинга. Лучшее время для технических работ. Дальше начнутся отпуска, потом осенний аврал с закрытием года.
Третий квартал — человеческий фактор
Обучение сотрудников, фишинговые симуляции, проверка процедур реагирования. Технологии закрывают часть атак, но большинство инцидентов идут через людей.
Четвёртый квартал — проверка и отчётность
Аудит выполненного, сбор метрик, подготовка к внешним проверкам, защита бюджета на следующий год. Здесь показываешь бизнесу, что было сделано и какую ценность принесла работа.
Каждый квартал заканчивается контрольной точкой с измеримыми результатами. Без цифр невозможно понять, выполнен план или нет.
Дорожная карта информационной безопасности на 12 месяцев
Дорожная карта показывает не только что делать, но и в каком порядке. Некоторые задачи можно вести параллельно, другие блокируют друг друга и должны выполняться строго последовательно. Я разделил год на четыре квартала. Каждый квартал заканчивается контрольной точкой с измеримыми результатами. Если контрольная точка не пройдена, следующий квартал начинать бессмысленно.
Первый квартал строит фундамент. Инвентаризация активов в январе блокирует классификацию данных. Классификация данных блокирует построение модели угроз в феврале. Модель угроз блокирует оценку рисков. Оценка рисков блокирует защиту бюджета в марте. После защиты бюджета можно запускать параллельно закрытие внешних уязвимостей и внедрение многофакторной аутентификации.
Второй квартал опирается на результаты первого. Нельзя начать закрытие внутренних уязвимостей в апреле без полной инвентаризации из января. Параллельно с патч-менеджментом можно вести аудит правил межсетевых экранов. В мае выбор SIEM требует список критичных систем из первого квартала. Настройка сбора логов и корреляционных правил идёт последовательно. В июне аудит привилегированных учётных записей использует классификацию данных из января. Тестирование всех изменений квартала и проверка бэкапов завершают блок.
Третий квартал работает с людьми и процедурами. Базовое обучение в июле должно закончиться до первой волны фишинга. Нельзя запустить фишинговые симуляции, пока сотрудники не прошли минимальную подготовку. Анализ результатов фишинга и работа с группой риска идут последовательно. В августе углублённое обучение групп риска можно вести параллельно с двумя другими задачами. Учение по реагированию на инциденты требует работающую систему SIEM из второго квартала. Внедрение DLP требует классификацию данных из первого квартала. В сентябре настройка DLP продолжается, параллельно идёт вторая волна фишинга со сравнением результатов, тестовое восстановление из бэкапа и сбор промежуточных метрик года.
Четвёртый квартал собирает результаты. В октябре подготовка к внешнему аудиту и проверка хранения логов идут последовательно. В ноябре сбор всех метрик года блокирует анализ выполнения и подготовку презентации для бизнеса. Защита бюджета на следующий год основана на метриках и анализе текущего года. В декабре закрытие оставшихся высокоприоритетных задач можно вести параллельно с подготовкой финальной отчётности и наброском направлений на следующий квартал.
Путь проходит через инвентаризацию, классификацию данных, модель угроз, оценку рисков, защиту бюджета, внедрение SIEM, обучение сотрудников, сбор метрик и защиту бюджета на следующий год. Если любая из задач на критическом пути сорвётся, весь план сдвигается. Задачи вне критического пути можно переносить в пределах квартала без разрушения всей структуры.
Квартал 1. Инвентаризация и оценка рисков (январь–март)
Нужно понять полную картину защищаемой инфраструктуры, оценить актуальные риски и получить бюджет на год. Без завершения этого блока дальнейшие действия будут основаны на догадках, а не на реальных данных. Собрать полный список всех активов компании. Серверы (физические и виртуальные), рабочие станции, сетевое оборудование, облачные ресурсы (IaaS, PaaS, SaaS), мобильные устройства, базы данных, файловые хранилища. Для каждого актива зафиксировать владельца, местоположение, операционную систему, версию ПО, назначение. Помогут сканеры сети (Nmap, «Advanced IP Scanner), системы учёта активов (если есть), опрос администраторов и владельцев систем. Результат оформить в таблицу с обязательными полями — название, IP-адрес, ОС, владелец, критичность (пока предварительная), дата последнего обновления.
Классифицировать данные по уровню конфиденциальности. Публичные данные (можно публиковать без ограничений), внутренние данные (только для сотрудников компании), конфиденциальные данные (ограниченный круг лиц), персональные данные (регулируются законом). Провести встречи с владельцами бизнес-процессов. Выяснить, какие данные хранятся в каждой системе, кто должен иметь доступ, какие последствия будут при утечке или недоступности. Результат — матрица данных с привязкой к системам и уровнем критичности.
Актуализировать модель угроз. Взять за основу отраслевые отчёты (например, Verizon DBIR, отчёты антивирусных компаний), адаптировать под специфику компании. Выделить минимум 10 самых вероятных сценариев атак с учётом профиля компании, географии, размера.
Примеры сценариев фишинг с доставкой вредоносного ПО, эксплуатация уязвимостей публично доступных сервисов, компрометация учётных записей через слабые пароли, атаки на цепочку поставок через партнёров, инсайдерские действия, ransomware-атаки, DDoS на критичные сервисы, утечка данных через неправильно настроенные облачные хранилища.
Оценить риски для 5-7 самых важных систем. Использовать простую методологию вероятность реализации угрозы (низкая, средняя, высокая) умножить на потенциальный ущерб (финансовый, репутационный, операционный). Перевести каждый риск в денежное выражение. Например, остановка платёжной системы на сутки приведёт к потере N миллионов выручки плюс штрафы регулятора плюс репутационные потери.
Подготовить презентацию для руководства. Показать топ-5 рисков с цифрами потерь, сравнить стоимость защиты и стоимость реализации угрозы. Без эмоций, только цифры и факты.
Защитить бюджет на год. Представить план мероприятий с обоснованием каждой позиции через снижение конкретного риска. Показать, что будет, если не выделить ресурсы. Быть готовым к торгу и заранее разделить мероприятия на обязательные (без них компания под угрозой остановки), желательные (существенно снижают риски) и опциональные (улучшают общий уровень защиты). Если бюджет сократили, зафиксировать письменно, какие риски остаются непокрытыми и какие последствия возможны. Передать документ руководству на подпись.
Закрыть самые опасные внешние уязвимости. Запустить сканирование всех публично доступных систем (веб-серверы, почтовые серверы, VPN-шлюзы). Найти уязвимости с оценкой CVSS 9.0 и выше или те, для которых уже есть публичные эксплойты. Установить патчи немедленно, даже если это требует кратковременной остановки сервиса. Согласовать окна обслуживания с бизнесом заранее.
Внедрить многофакторную аутентификацию на все внешние точки входа. VPN, корпоративная почта, административные панели, облачные сервисы. Без MFA компрометация одного пароля приводит к полному доступу. Использовать аппаратные токены для администраторов, мобильные приложения (Google Authenticator, Microsoft Authenticator) для остальных.
[√] Инвентаризация активов завершена, каждый актив имеет владельца и уровень критичности
[ ] Данные классифицированы, понятно, где хранятся конфиденциальные и персональные данные
[ ] Модель угроз актуализирована, выделено минимум 10 сценариев атак
[ ] Риски оценены для ключевых систем, переведены в денежное выражение
[ ] Бюджет на год согласован, либо зафиксированы непокрытые риски
[ ] Внешние уязвимости высокого уровня закрыты
[ ] MFA внедрена на все внешние точки входа
Квартал 2. Техническая защита (апрель–июнь)
Закрыть уязвимости внутри периметра, настроить системы обнаружения, навести порядок в правах доступа. Квартал заканчивается летом, дальше начнутся отпуска и технические работы станут сложнее.
Закрыть уязвимости высокого и среднего уровня на всех серверах и рабочих станциях. Запустить полное сканирование внутренней инфраструктуры. Приоритизировать уязвимости не только по CVSS, но и по критичности системы. Уязвимость с CVSS 7.5 на сервере баз данных опаснее, чем уязвимость с CVSS 9.0 на тестовом стенде. Составить график установки патчей. Сначала тестовые среды (неделя на проверку совместимости), потом промышленные системы в порядке убывания критичности. Согласовать окна обслуживания с владельцами систем. Зафиксировать, какие системы нельзя патчить из-за legacy-приложений, и компенсировать другими мерами (сегментация сети, ограничение доступа).
Провести аудит правил на межсетевых экранах. За годы работы там накапливаются сотни правил, многие из которых уже не актуальны или противоречат друг другу. Выгрузить текущую конфигурацию, проанализировать каждое правило. Удалить правила для уже несуществующих систем, закрыть слишком широкие разрешения (any-any), оставить только минимально необходимые потоки.
Задокументировать назначение каждого оставшегося правила. Если через полгода спросят, зачем открыт порт 8080 между сегментами А и Б, должен быть письменный ответ. Без документации правила будут снова разрастаться хаотично.
Выбрать систему сбора и анализа событий. Если бюджет позволяет, рассмотреть коммерческие SIEM-решения (Splunk, ArcSight, QRadar, MaxPatrol SIEM). Если бюджет ограничен, начать с open-source вариантов (Wazuh, OSSIM, Graylog). Главное требование — возможность собирать логи с разнородных источников и настраивать корреляционные правила.
Не пытаться охватить всё сразу. Начать с критически важных систем, простой которых приведет к катастрофе — контроллеры домена, серверы баз данных, межсетевые экраны, VPN-шлюзы, почтовые серверы. Для каждого источника определить, какие события критичны (неудачные попытки входа, изменение прав, остановка сервисов, подозрительные сетевые подключения).
Настроить сбор логов с ключевых систем. Убедиться, что логи пишутся в достаточном объёме (уровень детализации должен позволять расследовать инциденты), передаются на централизованное хранилище в реальном времени (задержка не более 5 минут), хранятся положенный срок (минимум 6 месяцев, для некоторых систем до 3 лет по требованиям регуляторов).
Настроить 8-10 самых важных правил корреляции. Примеры: множественные неудачные попытки входа с одного IP за короткий период, успешный вход в нерабочее время для привилегированных учётных записей, одновременный вход одной учётной записи с разных географических локаций, изменение критичных групп безопасности, остановка антивирусных служб на рабочих станциях, подключение неизвестных устройств к сети, массовая рассылка почты с одного аккаунта.
Провести аудит привилегированных учётных записей. Выгрузить список всех администраторов домена, локальных администраторов серверов, владельцев баз данных, администраторов сетевого оборудования. Проверить, нужны ли всем этим людям такие права сейчас. Как правило, половина привилегированных учётных записей принадлежит людям, которые давно сменили должность или вообще ушли из компании.
Отозвать ненужные права, внедрить модель Just-in-Time Access (права выдаются временно под конкретную задачу, потом автоматически отзываются). Для оставшихся привилегированных учётных записей настроить усиленный мониторинг и обязательную MFA.
Протестировать все изменения, сделанные за квартал. Проверить, что патчи не сломали критичные приложения, правила на межсетевых экранах не блокируют легитимный трафик, SIEM корректно собирает события и генерирует алерты, привилегированные пользователи могут работать с новыми ограничениями.
Провести тестовое восстановление хотя бы одной важной системы из резервной копии. Выбрать, например, сервер баз данных или файловое хранилище. Развернуть копию на изолированном стенде, проверить целостность данных, убедиться, что процедура восстановления задокументирована и выполнима силами текущей команды. Зафиксировать время восстановления (RTO) и точку восстановления (RPO).
[ ] Уязвимости высокого и среднего уровня закрыты на всех серверах и рабочих станциях
[ ] Правила межсетевых экранов почищены и задокументированы
[ ] SIEM внедрена, настроен сбор логов с ключевых систем
[ ] Работает минимум 8 корреляционных правил для обнаружения подозрительной активности
[ ] Привилегированные учётные записи почищены, оставлены только необходимые
[ ] Проведено тестовое восстановление критичной системы из бэкапа
[ ] Все изменения протестированы, критичные сервисы работают стабильно
Квартал 3. Обучение и процедуры (июль–сентябрь)
Снизить вероятность успешных атак через социальную инженерию, научить сотрудников правильно реагировать на подозрительные ситуации, проверить процедуры реагирования на инциденты в условиях, близких к реальным.
Провести базовое обучение по кибергигиене для всех сотрудников. Формат — онлайн-курс или серия коротких видео (не более 5-7 минут каждое). Темы: как создавать и хранить пароли, как распознавать фишинговые письма, что делать при получении подозрительного сообщения, почему нельзя использовать рабочую почту для личных целей, как безопасно работать с публичным Wi-Fi, что делать при утере корпоративного устройства.
После прохождения курса провести короткий тест (10 вопросов) для проверки усвоения материала. Результаты теста использовать для выявления сотрудников, которым нужно дополнительное объяснение.
Отправить первую волну фишинговых писем. Использовать специализированные платформы (Gophish, KnowBe4) или подготовить письма вручную. Письма должны быть реалистичными, но не слишком очевидными. Темы: уведомление от HR о необходимости обновить данные, письмо от IT-отдела с просьбой сменить пароль, сообщение о доставке посылки, приглашение на вебинар.
Зафиксировать метрики: сколько процентов сотрудников открыли письмо, сколько кликнули на ссылку, сколько ввели учётные данные на фишинговой странице. Не наказывать попавшихся, а провести с ними короткую разъяснительную беседу. Показать, по каким признакам можно было распознать подделку.
Провести углублённое обучение для групп риска. Бухгалтерия, HR, казначейство, топ-менеджмент — те, кто имеет доступ к деньгам, конфиденциальным данным или принимает решения от лица компании.
Формат, очная встреча или вебинар с разбором реальных кейсов. Примеры: как мошенники выманивают деньги через письма от имени CEO (Business Email Compromise), как распознать поддельные счета на оплату, что делать при получении срочного запроса на перевод средств, как проверять подлинность контрагентов.
Дать участникам конкретные инструкции: при любом запросе на перевод денег всегда звонить инициатору по известному номеру телефона (не тому, что указан в письме), при получении счёта на оплату нового контрагента проверять его через открытые источники, не открывать вложения от неизвестных отправителей даже если тема письма кажется актуальной.
Организовать полноценное учение по реагированию на инцидент. Создать реалистичный сценарий (например, обнаружена вредоносная активность на нескольких рабочих станциях, есть признаки распространения по сети). Запустить учение без предупреждения команды за неделю, максимум за сутки.
Проверить, как команда действует в условиях стресса. Кто принимает решение об изоляции заражённых систем? Как быстро информируют руководство? Есть ли чёткое понимание, какие системы отключать можно, а какие нельзя? Как команда взаимодействует с внешними подрядчиками (если есть)? Кто отвечает за коммуникацию с бизнесом?
После учения провести разбор полётов. Зафиксировать, что сработало хорошо, где были задержки, какие процедуры оказались неработающими или непонятными. Обновить план реагирования на инциденты с учётом выявленных проблем.
Настроить контроль исходящих каналов. Внедрить систему предотвращения утечек данных (DLP) или хотя бы базовые меры контроля. Заблокировать отправку файлов через личную почту, мессенджеры, файлообменники. Настроить мониторинг попыток массовой выгрузки данных (например, сотрудник скачивает десятки гигабайт файлов с файлового сервера за короткий период).
Создать политики DLP для защиты конфиденциальных данных. Запретить отправку файлов, содержащих номера банковских карт, паспортные данные, коммерческую тайну (по ключевым словам или меткам конфиденциальности). Настроить алерты для службы безопасности при срабатывании правил.
Отправить вторую волну фишинговых писем. Использовать более сложные сценарии, чем в июле. Сравнить результаты с первой волной. Если процент кликнувших снизился — обучение работает. Если остался на том же уровне или вырос — нужно пересмотреть формат обучения.
Провести реальное восстановление тестовой системы из бэкапа. В июне проверяли процедуру на изолированном стенде, сейчас развернуть систему в промышленной среде. Убедиться, что резервные копии актуальные, процедура восстановления выполнима в стрессовых условиях, время восстановления укладывается в допустимые рамки.
Собрать промежуточные метрики года. Сколько уязвимостей закрыто, сколько инцидентов обнаружено и расследовано, какой процент сотрудников прошёл обучение, как изменилась статистика по фишингу, сколько систем покрыто мониторингом.
[ ] Базовое обучение по кибергигиене прошли все сотрудники
[ ] Проведены две волны фишинговых симуляций, метрики зафиксированы
[ ] Группы риска прошли углублённое обучение
[ ] Проведено учение по реагированию на инцидент, план реагирования обновлён
[ ] Система контроля исходящих каналов (DLP) настроена и работает
[ ] Проведено восстановление системы из бэкапа в промышленной среде
[ ] Промежуточные метрики года собраны
Квартал 4. Аудит и отчётность (октябрь–декабрь)
Показать бизнесу результаты года, подготовиться к внешним проверкам, защитить бюджет на следующий год. Декабрь неудачный месяц для любых изменений, поэтому технические работы сворачиваются, упор на документацию и метрики.
Подготовиться к внешнему аудиту или проверке регулятора. Проверить всю документацию: политики информационной безопасности актуальны и утверждены, инструкции для сотрудников доступны и понятны, регламенты реагирования на инциденты обновлены с учётом учений.
Провести внутренний аудит ключевых контролей. Проверить, что MFA действительно работает на всех внешних точках входа, логи собираются и хранятся положенный срок, резервные копии создаются по графику и проверены на возможность восстановления, права доступа соответствуют должностным обязанностям.
Проверить, что логи хранятся положенный срок и к ним есть быстрый доступ. Регуляторы часто запрашивают логи за последние 6-12 месяцев. Если логи потеряны, повреждены или недоступны, будут штрафы и дополнительные проверки.
Убедиться, что логи можно быстро извлечь и представить в читаемом формате. Провести тестовый запрос: найти все действия конкретного пользователя за последний месяц, найти все подключения к серверу баз данных за определённый период, найти все изменения в критичной группе безопасности.
Собрать все метрики года. Количественные показатели: сколько активов инвентаризировано, сколько уязвимостей обнаружено и закрыто (с разбивкой по уровням), сколько инцидентов зарегистрировано и расследовано, среднее время обнаружения инцидента, среднее время реагирования, сколько сотрудников прошло обучение, результаты фишинговых симуляций (первая волна vs вторая волна), процент систем, покрытых мониторингом.
Качественные показатели: какие новые системы внедрены, какие процедуры улучшены, какие риски снижены, что не удалось сделать и почему.
Проанализировать, что удалось сделать, что нет и по каким причинам. Честно признать, где были проблемы. Типичные причины невыполнения плана: нехватка людей (план был рассчитан на команду из трёх человек, а работал один), изменение приоритетов бизнеса (компания переключилась на новый проект, ресурсы перебросили туда), технические сложности (система не интегрировалась с существующей инфраструктурой, пришлось искать альтернативу), сопротивление команды (администраторы не хотели менять привычные процессы).
Подготовить презентацию для бизнеса. Не технический отчёт, а бизнес-кейс. Показать, какие риски были в начале года, что сделано для их снижения, какая ценность получена. Перевести технические метрики в понятные бизнесу термины. Например, не «внедрена система SIEM», а «время обнаружения инцидентов сокращено с 8 часов до 15 минут, что снижает потенциальный ущерб в 30 раз». Защитить бюджет на следующий год. Использовать метрики текущего года как обоснование. Показать, что было сделано с имеющимися ресурсами, какие риски остались непокрытыми, что нужно для их закрытия.
Разделить запрашиваемый бюджет на три категории: обязательный минимум (без этого компания под угрозой остановки или серьёзных штрафов), рекомендуемый уровень (существенно снижает риски и приводит защиту к отраслевому стандарту), опциональные улучшения (повышает общий уровень защищённости, но не критично).
Быть готовым к торгу. Если бюджет сократят, чётко зафиксировать, какие задачи не будут выполнены и какие риски остаются. Передать документ руководству на подпись.
Закрыть оставшиеся высокоприоритетные задачи. Установить патчи, которые вышли в конце года. Провести финальную проверку всех критичных систем перед новогодними праздниками (период повышенной активности злоумышленников, когда команды работают в сокращённом составе).
Подготовить финальную отчётность для регуляторов (если требуется). Сделать набросок общих направлений на январь-март следующего года. Не детальный план, а список приоритетов: на что обратить внимание в первую очередь, какие инициативы запустить, какие системы требуют замены или модернизации.
[ ] Вся документация проверена и актуализирована
[ ] Внутренний аудит ключевых контролей проведён
[ ] Логи доступны за положенный период, проверена возможность быстрого извлечения
[ ] Метрики года собраны, проанализированы, подготовлена презентация для бизнеса
[ ] Бюджет на следующий год защищён или зафиксированы непокрытые риски
[ ] Высокоприоритетные задачи закрыты
[ ] Набросок приоритетов на следующий квартал готов.
Как защитить бюджет на информационную безопасность
Приведу реальный пример. Специалист внедряет SIEM стоимостью около 800 тысяч. Бизнес вызывает его и спрашивает, зачем тратить почти миллион на систему. Если авторитета почти нет, специалист начинает объяснять, что такое SIEM, что стандарт отрасли и что его используют все крупные компании. Бизнес отвечает, что раньше обходились без него, и предлагает отложить. Ресурсы не выделяют, проект останавливается.
Если авторитет накоплен, специалист объясняет иначе. Он говорит, что сейчас инцидент обнаруживается в среднем через 4-8 часов. Такого времени достаточно, чтобы профессиональный нарушитель успел вывести данные или заблокировать системы. С системой SIEM время обнаружения сокращается до 15 минут. Стоимость восстановления после серьёзного инцидента может составить несколько миллионов. Система не даёт стопроцентной гарантии, но разница в ущербе огромная. Если сейчас не время внедрять, он готов зафиксировать текущий уровень риска письменно.
В большинстве случаев после такого разговора либо дают деньги, либо откладывают с пониманием последствий.
Первый подход защищает технологию. Второй защищает компанию. Первый рассказывает, что такое SIEM. Второй показывает, какую проблему решает SIEM и сколько будет стоить, если её не решать. Первый не может объяснить ценность. Второй сравнивает затраты сейчас и возможные потери потом. Первый теряется под давлением. Второй даёт бизнесу честный выбор между внедрением системы и официальной фиксацией риска.
Именно авторитет позволяет перевести разговор из плоскости «зачем тебе деньги» в плоскость «готовы ли мы принять такой риск».
Зависимости между задачами в дорожной карте
Дорожная карта работает только тогда, когда понятна последовательность действий. Нельзя начать внедрение SIEM, пока не проведена инвентаризация источников событий. Нельзя настроить правила корреляции, пока не определены критичные активы. Нельзя проверить процедуры реагирования, пока эти процедуры не написаны. Вот основные зависимости по кварталам.
Без инвентаризации активов невозможно понять, что сканировать на уязвимости. Без классификации данных невозможно настроить DLP. Без оценки рисков невозможно приоритизировать работы. Без защиты бюджета невозможно покупать системы и нанимать людей.
Патч-менеджмент требует полного списка активов. SIEM требует понимания, какие системы критичны и какие события важны. Аудит прав доступа требует классификации данных (кто должен иметь доступ к конфиденциальной информации).
Обучение сотрудников требует понимания актуальных угроз (модель угроз из квартала 1). Фишинговые симуляции требуют настроенного мониторинга почтового трафика (квартал 2). Учения по реагированию требуют работающих систем обнаружения (SIEM из квартала 2). DLP требует классификации данных (квартал 1) и настроенной сетевой инфраструктуры (квартал 2).
Аудит проверяет, что было сделано в кварталах 1-3. Метрики собираются по всем активностям года. Защита бюджета на следующий год основана на результатах текущего.
Если пропустить какой-то блок в середине года, весь план рассыпается. Можно попытаться наверстать упущенное, но это всегда дороже и дольше, чем делать последовательно.
Авторитет и план работают вместе
Авторитет и план существуют одновременно. Без авторитета план остаётся просто документом. Без плана авторитет превращается в пустые разговоры. Но если выбирать, с чего начинать, начинать нужно с авторитета. План можно составить за две недели. А доверие нарабатывается месяцами в десятках небольших ситуаций, где ты либо укрепляешь свою позицию, либо теряешь её за один разговор.
Планирование в информационной безопасности не про таблицы и даты. Планирование про людей и доверие.
#инфобезопасность #кибербезопасность #информационнаябезопасность #киберриски #безопасностьданных #киберзащита #лайфхаки