Positive Technologies: Без эффективных процессов реагирования никакой защитный софт не будет эффективен

Специалисты экспертного центра безопасности Positive Technologies (PT Expert Security Center) на Standoff 10 рассказали порталу Cyber Media о том, как выглядят киберучения глазами Security Operations Center (SOC), а также о типичных особенностях в работе Red Team и Blue Team.

Константин Грищенко, руководитель отдела мониторинга информационной безопасности экспертного центра безопасности Positive Technologies. Имеет профильное образование по специальности «Организация и технология защиты информации», 19 лет опыта работы в ИБ, участие в разработке программных продуктов ИБ, исследовании программно-аппаратных решений, работал в SOC на различных должностях.

Екатерина Никулина, специалист отдела мониторинга информационной безопасности экспертного центра безопасности Positive Technologies. ВУЗ — МГТУ им. Н.Э. Баумана по специальности «Информационная безопасность автоматизированных систем». Опыт работы в SOC; участие во внутренних проектах компании в составе Blue Team, в работах с внешними заказчиками по мониторингу и разработке экспертных детектов, в подготовке и проведении стажировок в SOC.

Red Team (атакующие, красные) — команда исследователей безопасности, которые осуществляют комплексную имитацию реальных атак с целью оценки кибербезопасности IT-систем.

Blue Team (защитники, синие) — сотрудники ИБ-подразделений компаний, которые отвечают за мониторинг безопасности сетевой инфраструктуры, выявляют любые возможные уязвимости и реагируют на все атаки

Cyber Media: Какие маркеры чаще всего оставляют представители Red Team во время киберучений, по которым их можно обнаружить?

Екатерина Никулина: Наиболее распространенные оплошности, как правило, связаны с тем, что Red Team чересчур форсирует атаку на компанию, и уделяет мало времени изучению существующих в ней процессов. Например, атакующие часто оставляют следы в виде нестандартного (отличного от принятого в компании) нейминга учетных записей или хостов, что сильно бросается в глаза Blue Team. Другой пример — нетипичное поведение в инфраструктуре компании; когда от имени учетной записи бухгалтера или HR-специалиста редтимер начинает заходить на ресурсы разработчиков, использовать специфический софт или технические утилиты — это также привлекает внимание специалистов SOC.

Также, я бы отметила, что опрометчивые действия «красных команд» зачастую позволяют Blue Team обнаружить их на самых ранних этапах атаки. В частности, многие редтимеры, которые пытаются проникнуть во внутреннюю инфраструктуру при помощи рассылки фишинговых писем, быстро выявляются SOC-ом из-за недостаточной подготовки к фишинговой атаке. У крупных компаний, существующих на рынке долгое время, как правило, уже есть сложившиеся корпоративные правила и стилистика оформления писем. Если атакующие при подготовке рассылки их не знают или не учитывают, получившееся письмо может легко быть идентифицировано как попытка фишинга практически любым сотрудником компании.

Еще один класс действий атакующих, которые часто их выдают, связан с доставкой и запуском инструментария. После того, как злоумышленникам удается проникнуть во внутреннюю сеть компании, они начинают загружать и запускать различные дополнительные инструменты — исследовательские утилиты, инструменты для проведения разведки и повышения привилегий. При этом, дабы не попасть в поле зрения Blue Team, атакующие прибегают к разнообразным техникам уклонения от обнаружения, включающим маскировку инструментария под системные процессы, легитимные программы и т.д. Но практически всегда любая подобная мимикрия имеет недочеты. Запуск атакующими своих утилит часто оставляет такие следы, как: нестандартное расположение этих утилит, подозрительные аргументы командной строки, аргументы командной строки, характерные для известных хакерских инструментов, несогласованное изменение признаков утилит при попытках маскировки (например, переименование исполняемого файла без соответствующего изменения метаинформации).

Cyber Media: В свою очередь, какие недочеты при реагировании встречаются у Blue Team?

Константин Грищенко: У Blue Team иногда возникают сложности с идентификацией инцидентов (не разработаны детекты, не покрыты мониторингом необходимые части инфраструктуры, не организован процесс ретроспективного анализа) — невозможно в полной мере отреагировать на инцидент, если даже не удалось его заметить.
Другой случай — отсутствие продуманного сценария, описывающего необходимые шаги по сдерживанию атакующих, ликвидации последствий атаки, возвращению к нормальной работе систем, затронутых инцидентом.

Даже если какие-то сценарии существуют, довольно часто можно выделить три проблемы:

• сценарий недостаточно продуман;
• не в полной мере обеспечено взаимодействие;
• не автоматизировано то, что нужно автоматизировать.

В результате, в тех случаях, когда нападающим удается проникнуть в инфраструктуру, даже тогда, когда действия атакующих быстро выявляются специалистами SOC, много времени может уходить на непосредственное реагирование: сдерживание атакующих, ликвидацию угрозы, возвращение к работе. Чем больше это время, тем больше шансов у атакующих закрепиться, развить атаку и достичь планируемых целей. А значит одна из основных задач SOC — выстраивание внутренних процессов таким образом, чтобы постараться это время минимизировать.

Cyber Media: На ваш взгляд, что нужно учитывать при организации киберучений?

Екатерина Никулина: В первую очередь, наша задача — бороться с хакерами. И, на самом деле, нам в SOC не так важно, идут учения или не идут. Скажу больше: в большинстве случаев мы можем даже и не знать о том, что руководство пригласило стороннюю команду пентестеров, и что в настоящий момент они эмулируют хакерскую активность «рядом» с реальными злоумышленниками. Мы продолжаем работать в рамках выстроенных у нас процессов.

При этом, сами киберучения могут быть разными: тайными (Blue Team не информируется о начале работ) или открытыми, с противодействием или без и т.д. Выбор формата зависит от целей учений, которые также варьируются.

Иногда основной целью бывает проверить непосредственно технические средства защиты: оценить работу внедренных продуктов, глубину покрытия разработанных правил обнаружения. В таких случаях киберучения проводятся в открытом формате, и SOC не противодействует команде пентестеров. То есть, мы вообще не блокируем их активность, просто наблюдаем и фиксируем срабатывания средства защиты информации (СЗИ). 

Другой случай — когда необходима комплексная оценка защищенности компании, предусматривающая в том числе проверку работы SOC. При таком раскладе киберучения проходят в тайном формате, и мы о них узнаем постфактум, когда нам в конце месяца приносят отчет Red Team и говорят: «Смотрите, вот отчет: вас атаковали. Принесите ваш отчет за месяц, мы сравним и оценим, насколько хорошо вы справились».

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

• проверка «тонуса» SOC;
• проверка функционирования СЗИ;
• проверка «чистоты» инфраструктуры с точки зрения уязвимостей.

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

Cyber Media: Возникают ли какие-то сложности при обсуждении прошедшего тестирования между командами и подведении итогов, формулировке выводов?

Константин Грищенко: Бывает, что у нападающей команды и организваторов киберучений с защищающейся стороны возникают разночтения, каким образом интерпретировать достигнутые командой атакующих результаты. Для того, чтобы не было неоднозначности обычно на этапе подготовки киберучений предельно четко формулируются задачи и критерии для команды Red Team. Но сотрудники SOC обычно не участвуют в подобном разборе. Мы просим отчет нападающей команды для того, чтобы самим произвести работу над ошибками.

Если было что-то, чего мы не видели, мы разбираемся почему такое могло произойти? Важно понять, что стало причиной: мы где-то не увидели, не обратили внимания, пропустили, сработал человеческий фактор или техника где-то не сработала, правила были недостаточно хорошие, пентестеры использовали какую-то новую технику, о которой мы не подозревали или же у нас в инфраструктуре что-то сломалось.

Эта информация нам нужна, в том числе и для того, чтобы учения не прошли впустую, даже если пентестеры не сумели реализовать никаких серьезных рисков.