В предыдущей статье речь шла о поиске и обучении инженеров для первой линии центра мониторинга и реагирования на кибератаки. Сегодня мы поговорим о поиске и подготовке кадров для второй линии — аналитиков, которые занимаются расследованием нетиповых инцидентов и работой с контентом SIEM-системы, а также инженеров эксплуатации СЗИ, отвечающих за настройку средств защиты, анализ атак и разработку кастомных сигнатур.
Если спросить, какие требования мы предъявляем к кандидатам, ответ может показаться очень банальным: определенные технические компетенции, аналитический склад ума, внимательность… Однако как проверить эти качества, на что опираться, чтобы свести к нулю влияние субъективной оценки? Рассказываем, на что мы обращаем внимание и какие задания даем кандидатам.
На открывающиеся у нас вакансии аналитиков второй линии мы рассматриваем и внешних кандидатов с профильным опытом, но внутренним сотрудникам всегда предоставляем приоритет в переводе. Тем самым мы повышаем мотивацию ребят: у них перед глазами большое количество примеров коллег, проделавших путь от инженера первой линии до эксперта-аналитика (см. статью «SOC for beginners. Как организовать мониторинг инцидентов и реагирование на атаки в режиме 24х7») или матёрого администратора СЗИ. Да и на рынке труда явная нехватка компетентных специалистов ИБ, а уж людей с опытом работы в SOC днём с огнём не сыщешь. Чуть проще найти человека со знанием используемого в Solar JSOC инструментария, но и здесь выбор небогат.
Поэтому мы не просто поощряем в инженерах первой линии стремление к развитию, но и сами постоянно обучаем ребят. Например, среди прочего, у нас внедрена практика case review — вторая линия ежедневно отводит определенное количество времени на то, чтобы перепроверить часть инцидентов, разобранных первой. Разумеется, это касается не всех инцидентов — бессмысленно просто дублировать чужую работу, да и поток событий слишком большой. В первую очередь мы обращаем внимание на инциденты высокой критичности, которые были закрыты как ложные. Цель здесь не только в выявлении возможных ошибок, но и в том, чтобы дать аналитикам первой линии рекомендации по методам разбора инцидентов и развить их профессиональные навыки.
При должном отношении к работе инженер потенциально готов к переходу на следующий уровень через год работы на первой линии. Конечно, всё зависит от конкретного специалиста — кто-то «созревает» раньше, кто-то позже, но эмпирическим путём было установлено, что примерно за год инженер успевает влиться в коллектив, вникнуть в суть работы и получить навыки практической работы по разбору инцидентов — в общем, стать полноценной боевой единицей Solar JSOC.
Направление мониторинга
Инженер первой линии может развиваться в одном из двух направлений – мониторинг или эксплуатация СЗИ. В первой половине речь пойдет о специалистах направления мониторинга, которые денно и нощно бдят на страже информационной безопасности заказчиков Solar JSOC. Рассказываем, какие качества мы ищем в кандидатах и как проверяем их наличие.
Знание инструментария
Во-первых, кандидат во вторую линию должен в совершенстве владеть основным функционалом SIEM-системы. Важно то, что с определенного момента SIEM перестает быть для инженера программой, которая умеет собирать и фильтровать некие события, и становится инструментом, с помощью которого можно получить нужную информацию – своего рода Палантиром, видящим камнем, с помощью которого SOC узнаёт, что происходит в подконтрольных информационных системах заказчика.
Интерпретация событий
Из этого вытекает второе важное требование. Инженер второй линии должен уметь интерпретировать техническую информацию в человекочитаемое описание, понятное не ИТ-специалисту. Иногда для этого требуется дополнить его релевантными данными из сторонних источников. Сравните, например, два варианта оповещения об инциденте, которые можно отправить заказчику:
Чувствуете разницу? С технической точки зрения оба варианты корректны, но, как и всегда, дьявол кроется в деталях. Правило корреляции сработало на запуск процесса msiexec.exe, который с большой долей вероятности свидетельствует об установке нового ПО, что для критичного АРМ является поводом для анализа со стороны офицера ИБ. В первом оповещении инженер скопировал технические данные из наиболее важных полей события 4688 (хост, процесс, УЗ, параметры запуска процесса) и, в принципе, сделал всё правильно в соответствии с инструкцией.
НО второе оповещение — это то, чего мы ждём от опытного инженера. Верная техническая информация вкупе с бизнес-аналитикой несёт для заказчика гораздо более полезные сведения о произошедшем событии.
Чтобы достичь такого уровня погружения, инженер должен расследовать не одну сотню тикетов, изучить события основных инфраструктурных источников, осознать, в какую сторону начинать раскручивать клубок расследования, и какие паттерны событий интересны в первую очередь.
Опыт проведения углубленной аналитики
Взгляд хорошего инженера первой линии должен цепляться за нестандартные вещи. А специалист второй линии в случае обнаружения таких нетипичных инцидентов способен при необходимости отклониться от инструкции.
Например, на контроллере домена антивирус сработал на зловред в файле \\tsclient\C\Users\a.razumov\Desktop\shadow_miner_win.exe. Так как это заражение критичного сервера, по инструкции такой инцидент должен в любое время суток немедленно эскалироваться в сторону аналитика второй линии, сервис-менеджера и заказчика. Однако если инженер обратит внимание на расположение потенциально вредоносного файла и проведет углубленное расследование, он поймет, что пользователь с УЗ a.razumov подключился по RDP к контроллеру домена, причем в RDP-сессию был проброшен локальный диск «C» с юзерским каталогом, который и был проверен серверным антивирусом. Такой инцидент, конечно, также требует расследования, но уровень его критичности несколько ниже.
Внимательность
Опытный инженер первой линии должен не терять бдительности. На каждую сотню зарегистрированных событий ИБ приходится от силы 5-10 боевых инцидентов. Понятно, что все срабатывания анализируют живые люди, а человеку свойственно ошибаться, но критически важно не пропустить эти самые боевые инциденты, ведь ради этого и приобретаются услуги SOC.
Приведем пример: в арсенале Solar JSOC есть довольно простой сценарий по отслеживанию установки новых служб Windows. Создать исключения для данного сценария проблематично, так как легитимность той или иной службы зависит от роли сервера, прав запуска, контекста её установки и т.д. По этой причине специалистам первой линии мониторинга приходится отсматривать довольно большое количество срабатываний данного сценария, особенно в случае подключенных АРМов, и проводить первичную оценку легитимности службы. И тут очень важно, чтобы взгляд инженера не замылился.
Совсем недавно была ситуация, когда инженер-стажер обратился к ответственному аналитику с тикетом, в котором ему было непонятно, какой процесс запускает свежеустановленная служба. Это оказался процесс PowerShell с аргументом в виде обфусцированного скрипта. Установка этой службы являлась этапом Kill Chain, и ее целью было закрепление вредоноса, попавшего на хост. Внимательность стажера позволила остановить заражение на инфраструктуре заказчика.
Или вот другой пример, связанный с геолокацией входов по VPN. Стандартно в компаниях для каждого пользователя VPN-сервиса составляется белый список стран/городов, из которых им разрешен доступ. У одного из заказчиков была скомпрометирована доменная УЗ специалиста ИТ-отдела, причём двухфакторная аутентификация на VPN-шлюзе отсутствовала. В одну «прекрасную» ночь злоумышленники подключились по VPN под этой УЗ с прокси-сервера, расположенного в Германии. Согласно профилю, для данного сотрудника легитимным считался вход в любое время суток, но только с IP-адресов России. Изначально с заказчиком было согласовано, что о срабатывании данного сценария мы оповещаем его по электронной почте, даже без дублирования по телефону. Однако инженер решил проверить HR-систему и, увидев, что данный сотрудник не находится в отпуске, эскалировал инцидент, позвонив сервис-менеджеру, а тот, в свою очередь, оповестил заказчика. Скомпрометированная УЗ была немедленно отключена, а злоумышленники даже не успели толком разобраться, куда они вообще попали, не говоря уже о закреплении в инфраструктуре. Очевидно, что если бы специалисты заказчика изучили оповещение только утром, придя на работу, история могла бы получить совсем другое развитие.
Опыт работы с контентом
Опытный инженер должен иметь представление, как работает контент. Понимание логики работы сценариев значительно упрощает процесс проведения расследований, так как специалист знает, на какую именно цепочку событий завёлся инцидент. Критерии False Positive также часто завязаны на технические нюансы работы механизма корреляции, и для их детектирования инженеру необходимо уметь читать контент.
Переводные задачи
И вот мы нашли отличного кандидата для перевода на 2 линию. Инженер имеет положительную «кредитную историю» по результатам case review (выборочного контроля его заключений по инцидентам), соблюдает SLA при работе с тикетами, не опускается ниже некоторого, стабильно высокого, уровня при проведении расследований и обладает всеми качествами, перечисленными выше в статье. Какие задачи мы даем инженеру в качестве переводных?
Обычно у нас есть несколько запросов от заказчиков на подключение новых типов источников. Для этого необходимо провести аналитику существующих типов событий, определить оптимальный способ получения этих событий, создать коннектор для их сбора. И это отличная задача для инженера на вырост!
Вторая задача напрямую связана с первой: после подключения нового типа источника необходимо интегрировать его события в существующие сценарии. Например, после подключения антивирусного ПО в составе MS SCCM System Center Endpoint Protection производилась настройка категоризации событий таким образом, чтобы существующие сценарии по вирусной активности заработали для этого источника. В случае же, если это совершенно новый тип источника, инженер проводит анализ на предмет того, какие типы атак мы сможем детектировать по событиям с этого источника, и разрабатывает новые сценарии.
Третьей задачей обычно выступает оптимизация какого-либо блока контента SIEM-системы, т.е. правил корреляции, фильтров и т.д. Не стоит думать, что единожды написанный контент остаётся в неизменном виде. Постоянно происходят или мелкие доработки, или глобальные переосмысления того, как должно быть хорошо :). Соответственно, решение подобной задачи позволяет инженеру глубже погрузиться в концепцию написания контента Solar JSOC.
И, наконец, четвертая задача связана с процессом Threat Intelligence. Первичной обработкой поступающих данных, анализом их релевантности, добавлением в real-time мониторинг, сопровождением индикаторов компрометации занимается как раз вторая линия. На первую линию в свою очередь возложена задача по проведению ретроспективной проверки по индикаторам компрометации, и в рамках переводной задачи мы хотим услышать от кандидата, какие подводные камни и слабые места он видит в этом достаточно сложном с технической точки зрения процессе, находясь в нем на ступеньку ниже. Так сказать, просим дать взгляд человека «из поля».
Направление эксплуатации
Итак, поздравляем: мы успешно «вырастили» инженера мониторинга 2 линии. Но в Solar JSOC помимо мониторинга есть направление эксплуатации средств защиты информации, на котором также выстроена 1 и 2 линия специалистов. Каких же высот должен достичь инженер первой линии для получения level up?
Погруженность в тематику
Прежде всего, опытный инженер администрирования должен чётко понимать, от чего защищают те или иные СЗИ. Для этого он должен иметь представление об основных типах уязвимостей защищаемой системы, способах их эксплуатации и потенциальном воздействии на систему заказчика.
Специалист второй линии должен знать основные методы реализации угроз ИБ – наиболее распространённые типы атак на защищаемые системы. В частности, речь идет об атаках из Интернета на защищаемые веб-ресурсы заказчика (на которые в первую очередь направлено жало хакеров), а также на прочие ресурсы, доступные извне.
Знание инструментария
Для успешного противостояния сложным и изощрённым атакам инженер должен владеть своим инструментарием на 100%. Идея не нова и совпадает с утверждением из раздела про мониторинг, но от этого не становится менее актуальной. Знай то, с чем работаешь. В Solar JSOC на вооружении инженеров стоят различные IPS, WAF, AntiDDoS-решения, которые, по заявлениям вендоров, неплохо работают из коробки. Но мы стремимся к тому, чтобы наши инженеры владели полным функционалом этих продуктов: умели читать дефолтные политики, редактировать предустановленные сигнатуры, понимали, что скрывается «под капотом» красивого графического интерфейса.
Классическим кейсом для администратора WAF или IPS является разработка кастомной сигнатуры для зафиксированной long-term атаки на защищаемый веб-ресурс. Как раз с такой ситуацией недавно столкнулись наши инженеры: средства мониторинга зафиксировали продолжительный брутфорс учетных записей личного кабинета одного известного интернет-магазина. Предустановленные сигнатуры на брутфорс-атаки не срабатывали, так как не учитывали специфику конкретного веб-приложения. Мы собственными силами провели оперативный анализ опасных веб-запросов и на его основе создали сигнатуру WAF, блокирующую эту активность. Хакеры заметили изменения в системе защиты атакуемого ресурса и несколько раз незначительно меняли содержимое запросов, пытаясь обойти сигнатуру, но каждый раз наши инженеры успешно отслеживали эти манипуляции и корректировали политику защиты. Вендоры средств защиты предоставляют подобный сервис, но зачастую им может не хватать оперативности и погруженности в специфику защищаемой системы.
Анализ ретроспективы
Однако бывают неприятные ситуации, когда атака пропущена, и злоумышленник, проэксплуатировав уязвимость, попал на целевой хост. Через какое-то время проникновение детектировали, доступ закрыли, команда форензики проанализировала скомпрометированные хосты и нашла на файловой системе артефакты, являющиеся следами проведенной атаки. Это замечательно, но что с ними делать дальше? Прогнать индикаторы средствами сканера безопасности и самописных скриптов – это стандартная процедура, но в форензике всегда есть место и для уличной магии.
Инженер администрирования при помощи коллег-форензеров пытается разобраться, каким образом эту атаку можно было детектировать и заблокировать еще «на подходе» на эксплуатируемых средствах защиты. Для этого предпринимаются попытки реанимировать остатки боевого эксплойта для добавления его пейлоада в качестве сигнатуры, инженер отмечает специфические нюансы атаки, способные трансформироваться в триггеры мониторинга, определяются уязвимости ПО, успешно проэксплуатированные в рамках атаки. В общем, проводится работа, без которой невозможно вынести уроки из успешного взлома. И эта задача требует от инженера администрирования глубокого технического бэкграунда и достаточно высокой квалификации.
Архитекторский подход
Инженер второй линии должен уметь видеть на два шага вперед. Любая эксплуатация сложного продукта неизбежно связана с изменениями его конфигурации. С учетом же специфики ИБ-решений может оказаться, что любые изменения грозят потерей доступности не только самого средства защиты, но также и защищаемой системы, и как следствие – финансовым ущербом для заказчика. Именно поэтому администратор ИБ должен обладать архитекторским видением при подготовке RFC: уметь планировать проводимые работы, прогнозировать простои, оценивать риски и влияние изменений на остальные системы, а также всегда держать в запасе пути отступления – надежные методы отката конфигурации к рабочему состоянию продукта.
Также не стоит забывать о том, что защищаемые системы обычно не статичны, а находятся в состоянии непрерывных изменений. И единожды грамотно разработанная политика защиты может перестать адекватно работать уже через несколько дней после ее развертывания. Поэтому опытный инженер второй линии должен быть способен выстроить технический процесс, состоящий из этапов профилирования легитимной активности, тестирования и доработки адаптированной политики, запуска этой политики в блокирующем режиме в продуктив и т.д. Не будем останавливаться на этом, весьма подробно эта тема описана в статье «Проблема непрерывной защиты веб-приложений. Взгляд со стороны исследователей и эксплуатантов».
Вместо заключения
На клавиатуре уже начинают западать клавиши букв слова «инженер», поэтому будем закругляться :). Подводя итог, хотелось бы сказать, что технические скиллы для специалиста в нашей сфере – это очень важно, но в первую очередь мы обращаем внимание на людей с горящими глазами, которые «болеют» темой ИБ, причем в «белом» её проявлении. Увлеченность своей работой позволяет специалисту избежать застоя и является основным драйвером для профессионального роста, что немаловажно в нашей непрерывно меняющейся отрасли. Первая или вторая линия – это не так важно. Если специалист вступает на эту стезю с большим желанием, успех ему гарантирован. Как и печеньки :).
Если спросить, какие требования мы предъявляем к кандидатам, ответ может показаться очень банальным: определенные технические компетенции, аналитический склад ума, внимательность… Однако как проверить эти качества, на что опираться, чтобы свести к нулю влияние субъективной оценки? Рассказываем, на что мы обращаем внимание и какие задания даем кандидатам.
На открывающиеся у нас вакансии аналитиков второй линии мы рассматриваем и внешних кандидатов с профильным опытом, но внутренним сотрудникам всегда предоставляем приоритет в переводе. Тем самым мы повышаем мотивацию ребят: у них перед глазами большое количество примеров коллег, проделавших путь от инженера первой линии до эксперта-аналитика (см. статью «SOC for beginners. Как организовать мониторинг инцидентов и реагирование на атаки в режиме 24х7») или матёрого администратора СЗИ. Да и на рынке труда явная нехватка компетентных специалистов ИБ, а уж людей с опытом работы в SOC днём с огнём не сыщешь. Чуть проще найти человека со знанием используемого в Solar JSOC инструментария, но и здесь выбор небогат.
Поэтому мы не просто поощряем в инженерах первой линии стремление к развитию, но и сами постоянно обучаем ребят. Например, среди прочего, у нас внедрена практика case review — вторая линия ежедневно отводит определенное количество времени на то, чтобы перепроверить часть инцидентов, разобранных первой. Разумеется, это касается не всех инцидентов — бессмысленно просто дублировать чужую работу, да и поток событий слишком большой. В первую очередь мы обращаем внимание на инциденты высокой критичности, которые были закрыты как ложные. Цель здесь не только в выявлении возможных ошибок, но и в том, чтобы дать аналитикам первой линии рекомендации по методам разбора инцидентов и развить их профессиональные навыки.
При должном отношении к работе инженер потенциально готов к переходу на следующий уровень через год работы на первой линии. Конечно, всё зависит от конкретного специалиста — кто-то «созревает» раньше, кто-то позже, но эмпирическим путём было установлено, что примерно за год инженер успевает влиться в коллектив, вникнуть в суть работы и получить навыки практической работы по разбору инцидентов — в общем, стать полноценной боевой единицей Solar JSOC.
Направление мониторинга
Инженер первой линии может развиваться в одном из двух направлений – мониторинг или эксплуатация СЗИ. В первой половине речь пойдет о специалистах направления мониторинга, которые денно и нощно бдят на страже информационной безопасности заказчиков Solar JSOC. Рассказываем, какие качества мы ищем в кандидатах и как проверяем их наличие.
Знание инструментария
Во-первых, кандидат во вторую линию должен в совершенстве владеть основным функционалом SIEM-системы. Важно то, что с определенного момента SIEM перестает быть для инженера программой, которая умеет собирать и фильтровать некие события, и становится инструментом, с помощью которого можно получить нужную информацию – своего рода Палантиром, видящим камнем, с помощью которого SOC узнаёт, что происходит в подконтрольных информационных системах заказчика.
Интерпретация событий
Из этого вытекает второе важное требование. Инженер второй линии должен уметь интерпретировать техническую информацию в человекочитаемое описание, понятное не ИТ-специалисту. Иногда для этого требуется дополнить его релевантными данными из сторонних источников. Сравните, например, два варианта оповещения об инциденте, которые можно отправить заказчику:
На хосте NB-SIVANOV запущен процесс ««C:\Windows\System32\msiexec.exe» /i «Z:\Департамент разработки продуктов\Аналитический отдел\_Общая\ Enterprise_Architect\Sparx.Systems.Enterprise.Architect.13.0.1310.Corporate.Edition \easetupfull.msi» под учетной записью s.ivanov.или
Старший аналитик группы анализа продуктов Иванов Сергей установил прикладное ПО для моделирования бизнес-процессов Sparx Systems Enterprise Architect из дистрибутива, расположенного в общем каталоге Z:\Департамент разработки продуктов\Аналитический отдел\_Общая\Enterprise_Architect.
Чувствуете разницу? С технической точки зрения оба варианты корректны, но, как и всегда, дьявол кроется в деталях. Правило корреляции сработало на запуск процесса msiexec.exe, который с большой долей вероятности свидетельствует об установке нового ПО, что для критичного АРМ является поводом для анализа со стороны офицера ИБ. В первом оповещении инженер скопировал технические данные из наиболее важных полей события 4688 (хост, процесс, УЗ, параметры запуска процесса) и, в принципе, сделал всё правильно в соответствии с инструкцией.
НО второе оповещение — это то, чего мы ждём от опытного инженера. Верная техническая информация вкупе с бизнес-аналитикой несёт для заказчика гораздо более полезные сведения о произошедшем событии.
Чтобы достичь такого уровня погружения, инженер должен расследовать не одну сотню тикетов, изучить события основных инфраструктурных источников, осознать, в какую сторону начинать раскручивать клубок расследования, и какие паттерны событий интересны в первую очередь.
Опыт проведения углубленной аналитики
Взгляд хорошего инженера первой линии должен цепляться за нестандартные вещи. А специалист второй линии в случае обнаружения таких нетипичных инцидентов способен при необходимости отклониться от инструкции.
Например, на контроллере домена антивирус сработал на зловред в файле \\tsclient\C\Users\a.razumov\Desktop\shadow_miner_win.exe. Так как это заражение критичного сервера, по инструкции такой инцидент должен в любое время суток немедленно эскалироваться в сторону аналитика второй линии, сервис-менеджера и заказчика. Однако если инженер обратит внимание на расположение потенциально вредоносного файла и проведет углубленное расследование, он поймет, что пользователь с УЗ a.razumov подключился по RDP к контроллеру домена, причем в RDP-сессию был проброшен локальный диск «C» с юзерским каталогом, который и был проверен серверным антивирусом. Такой инцидент, конечно, также требует расследования, но уровень его критичности несколько ниже.
Внимательность
Опытный инженер первой линии должен не терять бдительности. На каждую сотню зарегистрированных событий ИБ приходится от силы 5-10 боевых инцидентов. Понятно, что все срабатывания анализируют живые люди, а человеку свойственно ошибаться, но критически важно не пропустить эти самые боевые инциденты, ведь ради этого и приобретаются услуги SOC.
Приведем пример: в арсенале Solar JSOC есть довольно простой сценарий по отслеживанию установки новых служб Windows. Создать исключения для данного сценария проблематично, так как легитимность той или иной службы зависит от роли сервера, прав запуска, контекста её установки и т.д. По этой причине специалистам первой линии мониторинга приходится отсматривать довольно большое количество срабатываний данного сценария, особенно в случае подключенных АРМов, и проводить первичную оценку легитимности службы. И тут очень важно, чтобы взгляд инженера не замылился.
Совсем недавно была ситуация, когда инженер-стажер обратился к ответственному аналитику с тикетом, в котором ему было непонятно, какой процесс запускает свежеустановленная служба. Это оказался процесс PowerShell с аргументом в виде обфусцированного скрипта. Установка этой службы являлась этапом Kill Chain, и ее целью было закрепление вредоноса, попавшего на хост. Внимательность стажера позволила остановить заражение на инфраструктуре заказчика.
Или вот другой пример, связанный с геолокацией входов по VPN. Стандартно в компаниях для каждого пользователя VPN-сервиса составляется белый список стран/городов, из которых им разрешен доступ. У одного из заказчиков была скомпрометирована доменная УЗ специалиста ИТ-отдела, причём двухфакторная аутентификация на VPN-шлюзе отсутствовала. В одну «прекрасную» ночь злоумышленники подключились по VPN под этой УЗ с прокси-сервера, расположенного в Германии. Согласно профилю, для данного сотрудника легитимным считался вход в любое время суток, но только с IP-адресов России. Изначально с заказчиком было согласовано, что о срабатывании данного сценария мы оповещаем его по электронной почте, даже без дублирования по телефону. Однако инженер решил проверить HR-систему и, увидев, что данный сотрудник не находится в отпуске, эскалировал инцидент, позвонив сервис-менеджеру, а тот, в свою очередь, оповестил заказчика. Скомпрометированная УЗ была немедленно отключена, а злоумышленники даже не успели толком разобраться, куда они вообще попали, не говоря уже о закреплении в инфраструктуре. Очевидно, что если бы специалисты заказчика изучили оповещение только утром, придя на работу, история могла бы получить совсем другое развитие.
Опыт работы с контентом
Опытный инженер должен иметь представление, как работает контент. Понимание логики работы сценариев значительно упрощает процесс проведения расследований, так как специалист знает, на какую именно цепочку событий завёлся инцидент. Критерии False Positive также часто завязаны на технические нюансы работы механизма корреляции, и для их детектирования инженеру необходимо уметь читать контент.
Переводные задачи
И вот мы нашли отличного кандидата для перевода на 2 линию. Инженер имеет положительную «кредитную историю» по результатам case review (выборочного контроля его заключений по инцидентам), соблюдает SLA при работе с тикетами, не опускается ниже некоторого, стабильно высокого, уровня при проведении расследований и обладает всеми качествами, перечисленными выше в статье. Какие задачи мы даем инженеру в качестве переводных?
Обычно у нас есть несколько запросов от заказчиков на подключение новых типов источников. Для этого необходимо провести аналитику существующих типов событий, определить оптимальный способ получения этих событий, создать коннектор для их сбора. И это отличная задача для инженера на вырост!
Вторая задача напрямую связана с первой: после подключения нового типа источника необходимо интегрировать его события в существующие сценарии. Например, после подключения антивирусного ПО в составе MS SCCM System Center Endpoint Protection производилась настройка категоризации событий таким образом, чтобы существующие сценарии по вирусной активности заработали для этого источника. В случае же, если это совершенно новый тип источника, инженер проводит анализ на предмет того, какие типы атак мы сможем детектировать по событиям с этого источника, и разрабатывает новые сценарии.
Третьей задачей обычно выступает оптимизация какого-либо блока контента SIEM-системы, т.е. правил корреляции, фильтров и т.д. Не стоит думать, что единожды написанный контент остаётся в неизменном виде. Постоянно происходят или мелкие доработки, или глобальные переосмысления того, как должно быть хорошо :). Соответственно, решение подобной задачи позволяет инженеру глубже погрузиться в концепцию написания контента Solar JSOC.
И, наконец, четвертая задача связана с процессом Threat Intelligence. Первичной обработкой поступающих данных, анализом их релевантности, добавлением в real-time мониторинг, сопровождением индикаторов компрометации занимается как раз вторая линия. На первую линию в свою очередь возложена задача по проведению ретроспективной проверки по индикаторам компрометации, и в рамках переводной задачи мы хотим услышать от кандидата, какие подводные камни и слабые места он видит в этом достаточно сложном с технической точки зрения процессе, находясь в нем на ступеньку ниже. Так сказать, просим дать взгляд человека «из поля».
Направление эксплуатации
Итак, поздравляем: мы успешно «вырастили» инженера мониторинга 2 линии. Но в Solar JSOC помимо мониторинга есть направление эксплуатации средств защиты информации, на котором также выстроена 1 и 2 линия специалистов. Каких же высот должен достичь инженер первой линии для получения level up?
Погруженность в тематику
Прежде всего, опытный инженер администрирования должен чётко понимать, от чего защищают те или иные СЗИ. Для этого он должен иметь представление об основных типах уязвимостей защищаемой системы, способах их эксплуатации и потенциальном воздействии на систему заказчика.
Специалист второй линии должен знать основные методы реализации угроз ИБ – наиболее распространённые типы атак на защищаемые системы. В частности, речь идет об атаках из Интернета на защищаемые веб-ресурсы заказчика (на которые в первую очередь направлено жало хакеров), а также на прочие ресурсы, доступные извне.
Знание инструментария
Для успешного противостояния сложным и изощрённым атакам инженер должен владеть своим инструментарием на 100%. Идея не нова и совпадает с утверждением из раздела про мониторинг, но от этого не становится менее актуальной. Знай то, с чем работаешь. В Solar JSOC на вооружении инженеров стоят различные IPS, WAF, AntiDDoS-решения, которые, по заявлениям вендоров, неплохо работают из коробки. Но мы стремимся к тому, чтобы наши инженеры владели полным функционалом этих продуктов: умели читать дефолтные политики, редактировать предустановленные сигнатуры, понимали, что скрывается «под капотом» красивого графического интерфейса.
Классическим кейсом для администратора WAF или IPS является разработка кастомной сигнатуры для зафиксированной long-term атаки на защищаемый веб-ресурс. Как раз с такой ситуацией недавно столкнулись наши инженеры: средства мониторинга зафиксировали продолжительный брутфорс учетных записей личного кабинета одного известного интернет-магазина. Предустановленные сигнатуры на брутфорс-атаки не срабатывали, так как не учитывали специфику конкретного веб-приложения. Мы собственными силами провели оперативный анализ опасных веб-запросов и на его основе создали сигнатуру WAF, блокирующую эту активность. Хакеры заметили изменения в системе защиты атакуемого ресурса и несколько раз незначительно меняли содержимое запросов, пытаясь обойти сигнатуру, но каждый раз наши инженеры успешно отслеживали эти манипуляции и корректировали политику защиты. Вендоры средств защиты предоставляют подобный сервис, но зачастую им может не хватать оперативности и погруженности в специфику защищаемой системы.
Анализ ретроспективы
Однако бывают неприятные ситуации, когда атака пропущена, и злоумышленник, проэксплуатировав уязвимость, попал на целевой хост. Через какое-то время проникновение детектировали, доступ закрыли, команда форензики проанализировала скомпрометированные хосты и нашла на файловой системе артефакты, являющиеся следами проведенной атаки. Это замечательно, но что с ними делать дальше? Прогнать индикаторы средствами сканера безопасности и самописных скриптов – это стандартная процедура, но в форензике всегда есть место и для уличной магии.
Инженер администрирования при помощи коллег-форензеров пытается разобраться, каким образом эту атаку можно было детектировать и заблокировать еще «на подходе» на эксплуатируемых средствах защиты. Для этого предпринимаются попытки реанимировать остатки боевого эксплойта для добавления его пейлоада в качестве сигнатуры, инженер отмечает специфические нюансы атаки, способные трансформироваться в триггеры мониторинга, определяются уязвимости ПО, успешно проэксплуатированные в рамках атаки. В общем, проводится работа, без которой невозможно вынести уроки из успешного взлома. И эта задача требует от инженера администрирования глубокого технического бэкграунда и достаточно высокой квалификации.
Архитекторский подход
Инженер второй линии должен уметь видеть на два шага вперед. Любая эксплуатация сложного продукта неизбежно связана с изменениями его конфигурации. С учетом же специфики ИБ-решений может оказаться, что любые изменения грозят потерей доступности не только самого средства защиты, но также и защищаемой системы, и как следствие – финансовым ущербом для заказчика. Именно поэтому администратор ИБ должен обладать архитекторским видением при подготовке RFC: уметь планировать проводимые работы, прогнозировать простои, оценивать риски и влияние изменений на остальные системы, а также всегда держать в запасе пути отступления – надежные методы отката конфигурации к рабочему состоянию продукта.
Также не стоит забывать о том, что защищаемые системы обычно не статичны, а находятся в состоянии непрерывных изменений. И единожды грамотно разработанная политика защиты может перестать адекватно работать уже через несколько дней после ее развертывания. Поэтому опытный инженер второй линии должен быть способен выстроить технический процесс, состоящий из этапов профилирования легитимной активности, тестирования и доработки адаптированной политики, запуска этой политики в блокирующем режиме в продуктив и т.д. Не будем останавливаться на этом, весьма подробно эта тема описана в статье «Проблема непрерывной защиты веб-приложений. Взгляд со стороны исследователей и эксплуатантов».
Вместо заключения
На клавиатуре уже начинают западать клавиши букв слова «инженер», поэтому будем закругляться :). Подводя итог, хотелось бы сказать, что технические скиллы для специалиста в нашей сфере – это очень важно, но в первую очередь мы обращаем внимание на людей с горящими глазами, которые «болеют» темой ИБ, причем в «белом» её проявлении. Увлеченность своей работой позволяет специалисту избежать застоя и является основным драйвером для профессионального роста, что немаловажно в нашей непрерывно меняющейся отрасли. Первая или вторая линия – это не так важно. Если специалист вступает на эту стезю с большим желанием, успех ему гарантирован. Как и печеньки :).
