Журнал "Information Security/ Информационная безопасность" #5, 2020

ся и используются для выявления подо- зрений на инцидент. При этом с помощью данных правил можно выявить только известные или проанализированные на этапе подготовки инциденты, а инци- денты, возникновение которых не пред- полагалось и для которых сценарии не были проработаны заранее, мы так не увидим. Эти правила важно поддержи- вать в актуальном состоянии, методоло- гически развивать подходы к ним, посто- янно дорабатывать их и адаптировать под изменяющиеся условия. 4. И наконец, аналитика и алерты. Это результат работы аналитиков, рабо- тающих в SOC и непосредственно рас- следующих инциденты. Она накаплива- ется у них в виде разнообразных прак- тик, и хорошо, если они документирова- ны. Есть и второй компонент – системы класса UEBA или платформы киберана- литики, откуда алерты также могут поступать в SOC в случае обнаружения девиантного поведения отслеживаемых активов. Отличие от правил корреляции здесь в том, что, получая алерты о какой-либо аномалии, нельзя быть полностью уве- ренным, что это действительно маркеры инцидента. Но они определенно свиде- тельствуют о чем-то подозрительном. Выявление аномалий, анализ и органи- зация обмена алертами – неотъемлемая часть подготовки к реагированию на неизвестные инциденты, не предусмот- ренные правилами корреляции. Использование данных После того как сырые данные заведе- ны в SOC, подготовлена экспертиза, делающая данные полезными, можно начинать их использование. Данные нор- мализованы, вокруг них есть ландшафт, сформировано понимание того, какое сочетание событий и маркеров в этих данных сигнализирует об инциденте. И когда инцидент выявлен, нужно начать на него реагировать, для чего использу- ется набор процессов и методик. 1. Сценарии реагирования. В SOC должна быть создана и накоплена экс- пертиза по конкретным шагам рассле- дования инцидента каждого типа, она может поступить из внешних источников (например, консалтинга) либо форми- роваться своими силами. Эта экспертиза в виде пошаговой инструкции и есть сценарий реагирования. Он может быть написан на бумаге, может существовать только в голове у аналитиков SOC или может присутствовать в автоматизиро- ванном виде, но сами знания о том, как реагировать на конкретные инциденты, должны быть выработаны до того, как наступил инцидент. Как правило, для этого методологически прорабатывают- ся сценарии атак, моделируются угрозы и нарушители, чтобы в дальнейшем уже смотреть, где, каким образом мы выявляем эти атаки по killchain, реаги- руем и пр. 2. Процесс обработки уязвимостей и угроз. Информация об уязвимостях пришла в SOC в виде сырых данных из NVD, сканеров уязвимостей или от пентестеров. SOC должен построить этот процесс как часть своей экспер- тизы. Аналогично он должен обрабо- тать, обогатить и распространить на средства защиты индикаторы компро- метации из внешних фидов, чтобы выявлять их в защищаемой инфра- структуре и оперативно реагировать. Результат – понимание, что делать с данными об уязвимостях и угрозах и четкий процесс применения этих данных, снижающий риск инцидентов и повышающий эффективность работы SOC. Для автоматизации этих процес- сов используются системы класса Vul- nerability Management (в том числе как часть SGRC/IRP) и Threat Intelligence Platform. 3. Отсеивание ложных срабатываний (False Positive). Это крайне важный тип знаний для аналитиков, ведь ложные срабатывания – бич любого SOC. Как бы качественно мы ни старались обра- батывать сырые данные, всегда будет присутствовать некоторый поток ложных срабатываний. Если не научиться их выявлять, группировать и отсеивать, то работа SOC будет быстро парализована: все будут заняты обработкой тысяч неактуальных инцидентов, а реальные инциденты останутся без внимания. Автоматизация После того как данные собраны, обра- ботаны и начато их использование для выявления инцидентов и реагирования на них, остался последний шаг – непо- средственная автоматизация построен- ных процессов и обработки подтвер- жденных инцидентов. В этом случае в игру вступают два типа знаний и экс- пертизы: коннекторы и скрипты, а также плейбуки и настройки систем автомати- зации. 1. Коннекторы и скрипты. Это про- граммные объекты, которые помогают автоматизировать взаимодействия между различными системами и участ- никами процесса для быстрого и каче- ственного обогащения данных и, воз- можно, активного автоматического реа- гирования на средствах защиты. Необхо- димо написать соответствующее коли- чество коннекторов и скриптов, которые оптимизируют внутреннее взаимодей- ствие в SOC и сделают расследование максимально быстрым и эффективным, а значит ущерб – минимальным. 2. Плейбуки. Это те самые сценарии реагирования, которые реализованы в виде настроенных автоматизированных процессов и в которых используются скрипты и коннекторы. Если сценарий реагирования – это логическая сущность, то плейбук – это уже программная сущ- ность, реализованная в системе класса SOAR (или IRP). Метрики и дашборды После того, как настроены процессы сбора данных, выявления инцидентов, реагирования и их автоматизация, важно не забыть, что обязательной частью экспертизы SOC являются каче- ственные метрики, отчеты и визуальные панели (дашборды), придумать которые не так уж просто. Как правило, это результат хорошего консалтинга: как емко отслеживать наиболее важные результаты работы SOC, видеть его операционную работу и управлять каче- ством выявления и реагирования на инциденты. Это же касается и разно- образной отчетности, которая необхо- дима в SOC для соответствия законо- дательным требованиям, если, напри- мер, это SOC, в котором обрабаты- ваются инциденты КИИ, или для соот- ветствия большому количеству раз- личных аудиторских и прочих требова- ний. Соответствие требованиям зако- нодательства может обеспечиваться, например, с помощью системы класса SGRC. Кстати, отчетность нужна и для того, чтобы делать процессы SOC и его работу прозрачной для руководства, поскольку оно, как правило, смотрит именно на отчеты и графики чтобы оценить, насколько качественно построен SOC, насколько хорошо он выполняет свою работу. В качестве заключения При построении SOC не стоит забы- вать и об общих знаниях и процессах организации, в том числе смежных. Есть верхнеуровневые регламенты и системы компании, которые рас- пространяются на SOC, например управление знаниями и системы клас- са Wiki. Они тоже должны фигуриро- вать в SOC и документироваться. Актуален и вопрос знаний по настройке систем автоматизации ИБ и СЗИ, которые помогают нам реаги- ровать на инциденты и обеспечивают информационную безопасность на тех- ническом уровне. SOC необходим набор данных и набор документиро- ванных знаний по тому, как должны быть сконфигурированы средства автоматизации и защиты и как они работают, ведь в случае инцидента времени на поиск нужной информации не остается. Таким образом, на основе экс- пертизы с наших проектов мы соста- вили достаточно объемную картинку того, какие данные и знания должны быть созданы, агрегированы, акку- мулированы в SOC, чтобы та самая триада "люди – процессы – техно- логии" обеспечила его эффективную работу. l • 21 SOC www.itsec.ru Ваше мнение и вопросы присылайте по адресу is@groteck.ru