Почему зрелость ИБ зависит не только от продукта, но и от процессов, которым вы следуете?
Всем привет!
В последнее время моя работа сосредоточена на проектах, цель которых — максимально расширить охват источников событий, оптимизировать процессы и улучшить состояние уже внедрённых SIEM, VM и других решений, а также запустить изменения в инфраструктуре клиентов, для того чтобы существенно повысить шансы обнаружения и нейтрализации злоумышленников в сети.
«У нас стоит SIEM, но атаку не видели» — одна из самых частых проблем, с которой сталкиваются коллеги, использующие решения этого класса. Внедрение системы анализа событий информационной безопасности (SIEM) — лишь старт, но настоящая ценность появляется, когда система начинает эффективно обнаруживать угрозы и помогать их нейтрализовать. Для этого требуется не просто внедрение, а целая экосистема процессов, компетенций и вовлечённости.
В этой статье я делюсь опытом реализации масштабных проектов по повышению зрелости ИБ, включая сложные кейсы с жёсткими сроками и высокими ожиданиями. Расскажу о типичных ошибках, системных подходах, которые действительно работают.
Короткие рекомендации для тех, кто не любит читать:
Скрытый текст
Основные проблемы:
· Отсутствие вовлечённости заинтересованности руководителей высшего звена;
· Недостаточность собираемых и анализируемых событий с активов.
При должной подготовке одного Windows- или *NIX-актива вы можете ожидать увеличения потока событий на 1–10 EPS в зависимости от роли узла. Необходимо стремиться к 100% покрытия вашей инфраструктуры по событиям как от ОС, так и от приложений, увеличивать количество правил корреляции по мере появления в вашем окружении новых типов ОС, приложений, сервисов;
· Отсутствует культура управления инфраструктурой. Недостаточность знаний об объекте защиты у служб эксплуатации (ИТ) и ИБ. Необходимо выстраивать процесс управления активами, который позволит своевременно обнаруживать, категорировать и аудировать активы на предмет наличия новых приложений, открытых портов, уязвимостей или других изменений;
· Отсутствует процесс управления уязвимостями — нет информации по ним, активы не категорированы по важности для функционирования системы; как следствие — невозможность определить пути проникновения хакеров. Необходимо выстраивать процесс по обнаружению уязвимостей на активах и исправлять их, начиная с наиболее критичных активов: периметр, значимые для бизнеса активы, веб-серверы и т.д.;
· Сложность коммуникации между ИБ- и ИТ-отделами. Процесс может затянуться на недели или месяцы из-за бесконечных встреч и споров о том, в чью зону ответственности попадает тот или иной этап работ;
· Низкая достоверность отчётности. Часто ИТ-подразделение рапортует о выполнении задачи, когда по факту работа сделана лишь частично. Чтобы избежать этого, на старте работ необходимо чётко зафиксировать с руководителями смежных подразделений измеримые критерии приёмки работ, утверждённые на уровне топ-менеджмента.
· Низкая квалификация сотрудников увеличивает сроки и трудозатраты. Простая задача может надолго застрять на этапе согласования только потому, что сотрудник не может грамотно обосновать её для ИТ-отдела. К сожалению, без системной работы по обучению персонала ждать быстрого результата здесь не стоит.
· Смежная проблема — нехватка кадров. 90% задержек по проектам связаны с недостатком персонала.
Часть первая. FastTrack — как НЕ сделать инфраструктуру безопасной за три месяца
На прошлой работе мне выпала уникальная возможность принять ключевое участие в ряде сложнейших проектов, которые ранее казались невозможными для реализации. Один из таких проектов под кодовым названием FastTrack представлял собой серьёзный вызов: в весьма сжатые сроки (около трёх месяцев) нам предстояло вывести уровень зрелости информационной безопасности в компании на недосягаемую прежде высоту и подтвердить эффективность внедрённых мер через публичные или закрытые испытания, включая Red Team и Bug Bounty.
Для достижения этой цели мы задействовали полный арсенал средств — от комплексного внедрения СЗИ различных классов до привлечения экспертных групп по организации процессов и формирования специализированной команды мониторинга инцидентов ИБ. Проект включал всё, что могло помочь максимально быстро обнаружить и остановить злоумышленника.
В рамках проекта мы строили процессы буквально с нуля там, где раньше их просто не было. Мы внедряли управление активами и уязвимостями, патч-менеджмент, организовывали мониторинг и оперативное реагирование на инциденты, расширяли покрытие инфраструктуры, анализировали события внутри корпоративной сети и обеспечивали соблюдение всех требований регламентов информационной безопасности — все эти процессы создавались и внедрялись под конкретные условия и задачи клиента.
Очень амбициозный проект для амбициозной компании. На бумаге всё выглядело гладко, но в реальности мы столкнулись с несколькими узкими местами, наличие которых не предусмотрели изначально:
Ключевым сдерживающим фактором стал недостаток
низкооплачиваемыхквалифицированных и мотивированных инженеров у клиентов, которые непосредственно должны были реализовывать все предложенные нами меры в инфраструктуре. На 7000 активов всего два сотрудника службы ИБ;Несогласованность со службой ИТ, которая также не была готова эти изменения проводить.
Честно говоря, этот проект не удалось завершить в заявленные три месяца — работы растянулись на длительный период после дедлайна. Тем не менее, изначальная цель была достигнута, хоть и с опозданием, и сейчас компания успешно участвует в программе Bug Bounty.
По результатам проекта я сформировал несколько вопросов, ответы на которые прямо влияют на сроки реализации и успешность завершения.
✅ Что я проверяю перед стартом любого проекта:
Достаточно ли ресурсов и компетенций у отдела ИБ заказчика?
Насколько вовлечены CISO и руководство компании?
Есть ли договорённость с ИТ о проведении изменений?
Хватает ли у ИТ‑отдела ресурсов для организации и поддержки изменений и новых процессов?
Понимает ли клиент, что значительная часть работ проводится на его стороне?
Без ответов на эти вопросы любые сроки и KPI — иллюзия.
Таким образом, первые условия, требуемые для успешного развития информационной безопасности инфраструктуры:
Вовлечённость высшего руководства вплоть до уровня ГД;
Достаточность количества и компетенций непосредственных исполнителей как из отдела ИБ, так и из отдела ИТ;
· Готовность к затратам на проведение масштабных изменений.
Часть вторая. Достаточно ли только внедрения продукта?
Ну что же, урок был выучен, а я тем временем присоединился к разработке методологии, которая позволила бы аккумулировать все предыдущие наработки и масштабировать настройку SIEM + VM в соответствии с лучшими практиками и в измеримые сроки.
Тезисно методология укладывается в основные вехи, достижение которых определяет тот или иной уровень зрелости для множества процессов, используемых для эффективной эксплуатации СЗИ.
Для многих организаций, руководителей и ИБ-специалистов до сих пор открытием является тот факт, что покупка и корректное внедрение SIEM — это только первая ступень большого пути изменений, необходимых для того, чтобы сервис начал приносить реальную пользу. Недооценка реальных изменений после внедрения СЗИ крайне опасна. В крупных компаниях даже базовые настройки серверов и рабочих мест для полноценного и глубокого сбора событий могут занимать месяцы кропотливой работы и тестирования.
Без системного подхода и постоянного развития эксплуатация SIEM не сможет раскрыть свой потенциал и будет лишь создавать иллюзию защищённости.
Полноценная инвентаризация активов — это также бесспорно трудоёмкий и ответственный процесс, от которого зависит полнота покрытия вашего мониторинга. Если вы не знаете ваше окружение, неспособны оценить динамические изменения активов и НА активах, вы не контролируете вашу инфраструктуру.
Для устранения подобных проблем мы и разработали наше решение. Чуть подробнее расскажу о настройке SIEM в соответствии с лучшими практиками.
В парадигме результативных продуктов существует три универсальных уровня зрелости в каждой компании:
🟢 Уровень 1: Базовый
SIEM настроен и оптимизирован;
Подключены источники 1–2-го приоритета из 5 (например, активы на периметре, значимые для бизнеса активы и так далее);
Проведена работа по инвентаризации активов.
Данный этап характеризуется возможностью обнаруживать атаки с типовыми тактиками.
🟡 Уровень 2: Продвинутый
Настроена и полноценно используется вся доступная функциональность SIEM;
Подключены источники до 4-го приоритета (например, расширенные события всех ОС и софтов);
Проведён hardening;
Снижено количество слепых зон;
Проводится систематичная работа с исключениями для снижения некорректных срабатываний и ложных инцидентов.
На данном этапе вся доступная экспертиза выполняет полезную работу — для этого достаточно событий для анализа с большинства существующих источников. Появляется возможность обнаружить разнообразные техники, используемые злоумышленниками.
🔴 Уровень 3: Готовность к реальным испытаниям
Непрерывное улучшение процессов;
Стремление к всеобъемлющему покрытию всех важных источников событий;
Готовность к открытым испытаниям.
На данном уровне возможно эффективное противодействие подготовленным хакерским группировкам.
На каждом уровне оценивается восемь критериев, и в дальнейшем по ним проводятся работы:
— Health Check инсталляции;
— Security hardening инсталляции;
— Инвентаризация и контроль активов;
— Подключение источников;
— Мониторинг поступления событий от источников;
— Пакеты экспертизы;
— Работа с исключениями;
— Управление инцидентами и отчётность.
Основные рекомендации, которые вы можете выполнить самостоятельно:
Обеспечьте полноту инвентаризации активов, определите их важность. Создайте дерево активов в предпочитаемой вами структуре. Сделайте эти мероприятия регулярным, регламентированным по срокам проведения и анализу изменений процессом;
Обеспечьте полноту сбора событий со всех ранее найденных активов. События операционных систем необходимо собирать со всех активов. Для расширенного сбора событий в *NIX-системах рекомендуем использовать auditd. Для вашего удобства в этом году мы подготовим шаблон конфигурационного файла, распространяемый на пилотах.
Для эффективного анализа происходящего на Windows-активах вам потребуется собирать не только стандартные события безопасности, но и расширенный аудит политик безопасности, событий командной строки, установить и собирать события с Sysmon. В целом мы в своих работах используем информацию из 25 журналов событий.
Не забывайте про важность и необходимость собирать события со всех установленных приложений, которые создают события, интересные с точки зрения информационной безопасности (множество из них доступны в коробке). Это могут быть события с веб-серверов, VPN-серверов, серверов централизованного управления, например SCCM.Не игнорируйте сетевые устройства. Обращу внимание: если ваше оборудование, которое NATирует трафик, поддержано в SIEM, вы дополнительно можете отслеживать активы, доступные извне. Среди легитимных вы можете обнаружить забытые правила NAT, которые могут открывать непредполагаемые вами пути для атак злоумышленников.
Если вы используете решения класса SIEM, задайте себе вопросы:
«Что позволяет мне видеть существующие правила?»,
«Если я проведу пентест или воспользуюсь BaaS-решениями, увижу ли я следы нелегитимной активности и на всех ли затронутых активах?» и
«Сколько в��полненных тактик я оставил вне поля зрения SIEM?».
Ответы на эти вопросы смогут помочь вам оценить реальное состояние вашего сервиса и задать верное направление для проведения изменений.Вам необходимо регулярно оценивать подключение источников, скорость расширения и полноту покрытия в разрезе всех активов. Определите, например, обращаясь к матрице MITRE ATT&CK (https://usergate.com/ufactor/mitre) за примерами способов обнаружений, наиболее важные для вашего окружения события и отслеживайте поступление событий со всех активов, которые могут их генерировать.
Бонус-трек: Начните, наконец, обновлять операционные системы и используемые приложения. У вас никогда, повторюсь, НИКОГДА не будет достаточно ресурсов, чтобы доказать применимость каждой уязвимости в конкретных условиях вашего окружения. Нет другого решения для большинства компаний, кроме как начать регулярно проводить обновления для ВСЕХ ОС и для всех приложений. Позднее вы, вероятно, начнёте категорировать ваши активы по критичности и управлять приоритетами обновления, но для начала
просто добавь водыпримените патчи.
Часть третья. Мониторинг, которого нет
Этот раздел затрагивает самые болезненные темы для эго директоров SOC, CISO и сотрудников, обещающих полную прозрачность происходящего в вашей инфраструктуре. По моему опыту, на проектах в 85% крупных организаций реальная ситуация такова: «ваш мониторинг почти полностью слеп».
Несмотря на мощь инструмента и большие объёмы собираемых данных, большинств�� SIEM-систем страдает от перегруженности бесполезными событиями, отсутствия нормализации и фильтрации, что делает видимость угроз крайне ограниченной и вводит в заблуждение аналитиков вашего центра мониторинга. Это один из самых распространённых и серьёзных вызовов в эксплуатации современных систем безопасности.
Каждый раз, когда мы получаем вводные данные по покрытию источников событий и проверяем настройку активов и приложений на предмет выполнения всех необходимых мероприятий, которые хотя бы минимально обеспечивают сбор событий для Базового уровня, мы вынуждены принять горькую правду: в лучшем случае собираются лишь стандартные события, доступные по умолчанию, а в худшем — почти никакие события не собираются вовсе.
Это одна из ключевых типовых проблем в эксплуатации SIEM, связанная с отсутствием понимания защищаемого ландшафта, недостаточной поддержкой важных источников, а также сложностями настройки аудита и контроля непрерывности поступления событий.
Эффективное решение требует системного подхода, включающего рекомендации экспертов по обязательным источникам, использование автоматического обнаружения хостов и оценку необходимых ресурсов на разработку коннекторов и правил корреляции.
Ещё одной проблемой является то, что даже осознать недостаточность сбора информации коллеги очень часто не могут ввиду отсутствия компетенций и сформированных ожиданий, какие события необходимо собирать и анализировать с конкретного источника. Я даже не говорю о мониторинге происходящего в сети решениями класса NTA (Network Traffic Analyzer) — эти решения внедрены в небольшом количестве компаний, а эффективно используются ещё в меньшем.
Очень часто служба мониторинга ИБ уверена, что у них всё хорошо, покрытие источников как минимум на достойном уровне, но на поверку всё оказывается иначе:
SIEM обрабатывает огромный поток событий, при этом бо́льшая часть этих событий не нормализуется и не имеет никакого значения с точки зрения полезности при расследовании ИБ-инцидентов, однако сервис работает на пределе своих возможностей;
Поток ненормализованных событий невозможно анализировать, фильтровать или ещё каким-либо образом использовать в работе аналитиков;
Среднее количество инцидентов, формируемых в течение суток, достигает тысяч при 10–15K активах, но после анализа инцидентов оказывается, что 99% из них false positive, т.е. не была проведена минимальная работа по созданию исключений;
Событий расширенного аудита безопасности Windows, Sysmon, аудитов командной строки, событий от auditd *NIX-систем в большинстве случаев либо нет, либо есть с небольшого числа активов, да и то в недостаточном виде.
Данные по активам чаще всего предоставлены фрагментировано, а регулярное их обнаружение и аудит попросту не выполняются. В результате службы информационной безопасности могут даже не иметь представления о примерном количестве активов под своим контролем и их функциональной роли.
В эксплуатации используется лишь часть доступной экспертизы SIEM. Даже при корректно настроенных источниках событий вы рискуете не заметить значимые инциденты.
Теперь спросите себя: «Сколько из этих пунктов характерны для моей инфраструктуры?». Если вы согласны хотя бы с одним из пунктов, то стоит как можно скорее задуматься об изменении этой опасной ситуации.
Снижайте поток ненормализованных событий путём фильтрации неважных событий или разработкой новых правил нормализации для полезных событий систем;
Проведите работу по добавлению исключений — таким образом вы снизите бесполезную нагрузку на ваших аналитиков SOC 1-й линии, повысите их эффективность;
Регулярно выполняйте проверки качества покрытия — все ли ожидаемые события, для которых существуют правила, поступают с активов;
Разберитесь с вашими активами — когда нет полного понимания, что именно защищаешь, нет шанса обнаружить нелегитимную активность;
Собирайте события со всех источников, характерных для вашего окружения, и отслеживайте появление новых источников;
Читайте документацию по продукту — в ней в подробностях описаны все доступные возможности и рекомендации по настройке.
Описанные выше шаги позволяют превратить SIEM в мощный инструмент защиты, а не просто в экспонат на полке ваших СЗИ. Внедрение — это только начало, а зрелость ИБ строится на процессах, людях и культуре безопасности в той же степени, что и на технологиях.
