Друзья, в предыдущей публикации мы проанализировали международные документы по управлению рисками информационной безопасности, а в более ранних статьях рассмотрели основы информационной безопасности, обсудили законодательство в области защиты персональных данных и критической информационной инфраструктуры. В этой статье мы переходим в практическую плоскость и поговорим о системах IRP, призванных упростить и автоматизировать процедуры реагирования на инциденты ИБ. Начнем!
Как мы знаем, на текущий момент количество инцидентов ИБ, особенно в крупных компаниях, достаточно велико, и при реагировании на них счет идет буквально на минуты. При этом далеко не все могут позволить себе нанять большое количество высококлассных специалистов.
Возникает вопрос: как помочь аналитикам ИБ (прежде всего на L1 и L2) при реагировании на инциденты и снять с них рутинную нагрузку по выполнению однотипных операций?
Представим себе ситуацию, когда SIEM-система показывает, что происходит возможная атака на финансовую систему дистанционного банковского обслуживания. Злоумышленники могут похитить деньги со счетов фирмы с минуты на минуту, и после этого вернуть денежные средства будет затруднительно. Аналитик SOC, увидев такой инцидент, должен по сценарию реагирования собрать большой объем вспомогательной информации, такой как имя атакованного сервера, название финансовой системы, уточнить фамилию и контактные данные ответственного, получить у него дополнительную информацию. Если не осталось сомнений в том, что этот инцидент — «боевой», а не ложноположительный, то аналитику нужно как можно быстрее изолировать атакованный сервер от сети компании, заблокировать скомпрометированную учетную запись, сообщить об инциденте руководителю и прочим лицам в соответствии с матрицей коммуникации.
Как видим, задач — масса, и все их следует выполнить за строго отведенное нормативами и KPI время, например, за 10 минут. И как раз тут на помощь нашему аналитику может прийти платформа Incident Response Platform (IRP) — система автоматизации реагирования на инциденты информационной безопасности. Система IRP помогает выполнить ряд рутинных операций по сбору дополнительной информации, осуществить неотложные действия по сдерживанию (англ. contain) и устранению (англ. eradicate) угрозы, восстановить (англ. recover) атакованную систему, оповестить заинтересованных лиц, а также собрать и структурировать данные о расследованных инцидентах информационной безопасности. Кроме того, IRP позволяет роботизировать и автоматизировать однотипные действия оператора-специалиста ИБ, которые он производит при реагировании на инциденты информационной безопасности, что помогает снизить нагрузку сотрудника в части выполнения рутинных операций. Давайте подробнее остановимся на задачах реагирования на инциденты информационной безопасности, выполняемых IRP-системами.
Для того, чтобы понять, как и где корректно применять и внедрять системы IRP, нам следует увидеть процесс реагирования на инциденты информационной безопасности в целом и подумать, как можно его автоматизировать. Для этого обратимся к документу NIST SP 800-61 "Computer Security Incident Handling Guide" («Руководство по обработке инцидентов компьютерной безопасности»). В соответствии с ним, реагирование на инциденты ИБ состоит из нескольких взаимосвязанных процессов:
Рассмотрим эти процессы подробнее в контексте применения IRP-систем для их автоматизации.
Этап подготовки является предварительным и одним из ключевых. На данном этапе следует проделать всю организационную работу, чтобы действия команды реагирования на инциденты ИБ были документально подтверждены и согласованы. Политики, процедуры и инструкции по реагированию должны быть максимально четкими, подробными и удобными, чтобы в случае высокоприоритетного инцидента у аналитиков команды реагирования было точное понимание того, что следует предпринять в той или иной ситуации. Следует регулярно проводить тренировки по отработке шагов, определенных в написанных документах, а также обучать персонал компании и команду реагирования корректным техническим и организационным действиям во время инцидента.
На этапе подготовки также создаются и настраиваются playbooks или runbooks — сценарии реагирования, в соответствии с которыми команда реагирования и IRP-система будут предпринимать заранее заданные действия в зависимости от деталей инцидента. Например, в случае наступления высокоприоритетного инцидента ИБ на особо критичной системе в соответствии с playbook член группы реагирования должен связаться с руководителем и ответственным за систему лицом, а IRP-платформа должна дать команду на изоляцию этой системы от сети компании для проведения дальнейших разбирательств.
Кроме того, на этапе подготовки следует обеспечить группу реагирования на инциденты всем необходимым программным и аппаратным обеспечением (т.е. выдать ноутбуки, смартфоны, установить на них необходимые утилиты), а также выполнить превентивные действия по предотвращению инцидентов (защитить сеть и устройства компании, установить средства защиты информации, провести обучение сотрудников основам ИБ). В это время платформа IRP настраивается для эффективного применения: к ней подключаются ИТ-системы и средства защиты, с которыми предстоит взаимодействовать при реагировании на инциденты. Как правило, обеспечивают подключение тех систем, которые способны представить специалисту дополнительную информацию в контексте инцидента, например, сведения о затронутых инцидентом пользователях (контактные данные, должность, структурное подразделение, полномочия) и устройствах (тип операционной системы, установленное ПО, выполняемая функция). Кроме этого, подключаются и средства защиты, которые в рамках реагирования на инцидент будут выполнять задачи по сдерживанию и устранению угроз, например, средства защиты конечных точек, межсетевые экраны и системы управления сетью.
Таким образом, к моменту возникновения инцидента информационной безопасности в компании следует приходить во всеоружии: специалисты по реагированию и система IRP должны находиться в полной боевой готовности. Это является залогом того, что, даже если инцидент случится, его можно будет быстро локализовать, и его последствия не будут чрезмерно разрушительными.
На этапе детектирования следует определить список возможных типов инцидентов ИБ и сформулировать перечень признаков возможных инцидентов. Признаки можно условно разделить на прекурсоры и индикаторы инцидентов информационной безопасности:
Примерами прекурсоров инцидента информационной безопасности могут быть зафиксированное интернет-сканирование открытых портов веб-серверов компании или выявление уязвимости в какой-то ИТ-системе. Примерами индикаторов инцидента информационной безопасности могут быть появление сообщений от средств защиты (антивируса, межсетевого экрана и т.д.) о возможной атаке, несанкционированное удаление или модификация данных, появление ошибок и сбоев в работе ИТ-систем. Следует внимательно относиться к аномалиям в сетевом трафике: неожиданные всплески определенного типа трафика (например, DNS) могут свидетельствовать о вредоносной активности. Нетипичное поведение пользователей также следует анализировать: удаленное подключение в нерабочее время из необычной локации может быть признаком компрометации учетной записи. Для того, чтобы максимально эффективно задействовать систему IRP на этапе детектирования, следует интегрировать IRP-платформу с SIEM-системой: такая связка обеспечит «бесшовную» передачу прекурсоров и индикаторов инцидента от ИТ-систем и средств защиты компании через SIEM напрямую в IRP-систему, что позволит ей оперативно обнаруживать инциденты и в дальнейшем предпринимать адекватные меры по реагированию на них.
Во время этапа анализа инцидента основная нагрузка ложится на опыт и экспертизу аналитика — ему предстоит принять решение, был ли зафиксированный инцидент «боевым» или всё же это было ложноположительное срабатывание. Следует провести идентификацию и первичную обработку (триаж, англ. triage): определить тип инцидента и категорировать его. Далее определяются индикаторы копрометации (англ. Indicators of Compromise, IoCs), анализируется возможный масштаб инцидента и затронутые им компоненты инфраструктуры, проводится ограниченное форензик-обследование для уточнения типа инцидента и возможных дальнейших шагов по реагированию.
На этом этапе бесценную помощь окажет IRP-платформа — благодаря тому, что она может предоставить важную контекстную информацию, относящуюся к инциденту. Приведем пример: SIEM-система сообщает о том, что веб-сервер компании подвергся атаке, при этом использовавшаяся уязвимость применима только к ОС Windows. Аналитик, посмотрев в консоль IRP, сразу увидит, что атакованный веб-сервер работает на ОС Linux, следовательно, атака не могла быть успешной. Другой пример: антивирусная система на одном из ноутбуков сообщила о вирусном заражении и о последовавшим за этим обращением к определенным IP-адресам. Аналитик, воспользовавшись данными IRP-системы, увидит, что аналогичная сетевая активность наблюдается и на нескольких других устройствах в сети компании, что говорит не о единичном вирусе, а о массированном заражении. Инциденту будет присвоен более приоритетный статус, он будет эскалирован в соответствии с матрицей эскалации, и на его устранение будут направлены дополнительные ресурсы. Платформа IRP поможет запротоколировать все действия, выполненные в рамках реагирования, а также автоматизирует действия по коммуницированию и эскалации инцидента.
На этапе сдерживания (или локализации) инцидента главной задачей является оперативная минимизация потенциального ущерба от инцидента ИБ и предоставление временного окна для принятия решения об устранении угрозы. Этого можно достичь, например, оперативно включив более строгие запретительные правила на межсетевом экране для зараженного устройства, изолировав зараженный хост от локальной сети компании, отключив часть сервисов и функций, или, наконец, полностью выключив зараженное устройство.
На данном этапе используются сведения об инциденте, полученные на этапе анализа, а также данные о том, какую функцию выполняет затронутый инцидентом ИТ-актив, поскольку, например, выключение критически важного сервера может привести к более существенным негативным последствиям для компании, чем простая перезагрузка некритичного сервиса на нём. В данной ситуации IRP-платформа опять же подскажет, какие функции выполняет сервер, как и когда его можно выключать или изолировать (при условии, что на этапе подготовки данная информация была занесена в IRP). Кроме этого, в playbooks IRP-системы на этапе подготовки также должны быть заложены сценарии сдерживания, применимые для каждого конкретного типа инцидента. Например, в случае DDoS-атаки, возможно, не имеет смысла выключать атакуемые сервера, а в случае вирусного заражения внутри одного сегмента сети можно не изолировать устройства в другом сегменте. На этапе сдерживания также проводится анализ подробностей атаки: какая система была первой атакована, какими тактиками, техниками и процедурами пользовались атакующие, какие командные серверы используются в данной атаке и т.д. Указанную информацию поможет собрать IRP-система: интеграция с источниками киберразведки (англ. Threat Intelligence feeds) и специализированными поисковыми системами (например, VirusTotal, Shodan, Censys и т.д.) даст более чёткую и обогащенную картину произошедшего инцидента, что поможет эффективнее справиться с ним. В некоторых случаях может потребоваться также получить форензик-данные для последующего проведения компьютерной криминалистической экспертизы, и IRP-платформа поможет собрать такую информацию с атакованных устройств.
На этапе устранения инцидента производятся уже активные действия по удалению угрозы из сети и предотвращению повторной атаки: удаляется вредоносное ПО, изменяются взломанные учетные записи (их можно временно заблокировать, сменить пароль или, например, переименовать), устанавливаются обновления и патчи для проэксплуатированных уязвимостей, изменяются настройки средств защиты (например, для блокировки IP-адреса взломщиков). Указанные действия выполняются для всех затронутых инцидентом сущностей — и для устройств, и для учетных записей, и для программ.
Чрезвычайно важно тщательно устранить уязвимости, которые использовались злоумышленниками, поскольку чаще всего, успешно взломав какую-либо компанию, хакеры возвращаются в надежде использовать всё те же недостатки её защиты. При выполнении данного процесса платформа IRP даст необходимые команды средствам защиты и соберет недостающие данные обо всех затронутых инцидентом устройствах. Таким образом, скорость реагирования на инцидент информационной безопасности в части устранения самой угрозы существенно возрастает при использовании IRP-системы, которая будет отличным подспорьем аналитику ИБ.
На этапе восстановления следует проверить надежность предпринятых мер защиты, вернуть системы в нормальный режим работы (англ. business as usual), возможно, восстановив какие-то системы из резервных копий или установив и настроив их заново. На данном этапе системы IRP помогут не забыть все участвовавшие в инциденте устройства и хронологию событий, поскольку эти данные хранятся и накапливаются в IRP на протяжении всего цикла расследования инцидента.
На этапе пост-инцидентных действий (англ. post-incident activities) следует проанализировать причины инцидента (англ. root cause analysis) для того, чтобы свести к минимуму вероятность повторного аналогичного инцидента в будущем, а также оценить корректность и своевременность действий персонала и средств защиты, и, возможно, оптимизировать какие-то процедуры реагирования и политики ИБ. В случае серьезного инцидента следует провести внеочередное сканирование инфраструктуры на наличие уязвимостей, пен-тест и/или внеплановый аудит информационной безопасности.
Будет логично использовать агрегированную базу знаний для ведения накопленного опыта реагирования, что также можно сделать в IRP-платформе, в которой уже хранится подробная информация о произошедших инцидентах ИБ и о предпринятых мерах реагирования. В некоторых случаях требуется составление официального отчета по инциденту, особенно если он был серьезным или затронул важные данные: например, информацию по компьютерным инцидентам в критической информационной инфраструктуре следует отправлять в государственную систему ГосСОПКА. Для таких целей в некоторых отечественных IRP-системах есть как API для работы с ГосСОПКА, так и возможность автоматизированного составления отчетов по инцидентам на основе заранее созданных шаблонов. Как видим, IRP – это еще и универсальное хранилище сведений об инцидентах информационной безопасности с возможностью роботизации рутинных действий специалиста по информационной безопасности.
Подведем итог. Системы IRP являются автоматизированными средствами реагирования на инциденты информационной безопасности, реализующими контрмеры для противодействия угрозам информационной безопасности в соответствии с заранее заданными сценариями реагирования. Сценарии реагирования называются playbooks или runbooks и представляют собой набор автоматизированных задач по детектированию угроз и аномалий в защищаемой инфраструктуре, реагированию и сдерживанию угроз в режиме реального времени. Сценарии реагирования действуют на основании настраиваемых правил и типов инцидентов, выполняя те или иные действия в зависимости от поступающих данных со средств защиты или информационных систем. Платформы IRP помогают проводить структурированное и журналируемое реагирование на инциденты информационной безопасности на основании правил и политик. По окончании реагирования на инцидент IRP-платформа поможет создать отчет об инциденте и предпринятых действиях по его устранению.
Обобщая сказанное, можно сделать вывод, что система IRP – это платформа реагирования на инциденты кибербезопасности, предназначенная для защиты информации путем систематизации данных об инцидентах информационной безопасности и роботизации действий оператора-аналитика ИБ. Благодаря IRP-платформам команды реагирования на инциденты информационной безопасности могут существенно сэкономить время и усилия при расследовании инцидентов ИБ, что напрямую повышает операционную эффективность деятельности департаментов ИБ и SOC-Центров.
Введение
Как мы знаем, на текущий момент количество инцидентов ИБ, особенно в крупных компаниях, достаточно велико, и при реагировании на них счет идет буквально на минуты. При этом далеко не все могут позволить себе нанять большое количество высококлассных специалистов.
Возникает вопрос: как помочь аналитикам ИБ (прежде всего на L1 и L2) при реагировании на инциденты и снять с них рутинную нагрузку по выполнению однотипных операций?
Представим себе ситуацию, когда SIEM-система показывает, что происходит возможная атака на финансовую систему дистанционного банковского обслуживания. Злоумышленники могут похитить деньги со счетов фирмы с минуты на минуту, и после этого вернуть денежные средства будет затруднительно. Аналитик SOC, увидев такой инцидент, должен по сценарию реагирования собрать большой объем вспомогательной информации, такой как имя атакованного сервера, название финансовой системы, уточнить фамилию и контактные данные ответственного, получить у него дополнительную информацию. Если не осталось сомнений в том, что этот инцидент — «боевой», а не ложноположительный, то аналитику нужно как можно быстрее изолировать атакованный сервер от сети компании, заблокировать скомпрометированную учетную запись, сообщить об инциденте руководителю и прочим лицам в соответствии с матрицей коммуникации.
Как видим, задач — масса, и все их следует выполнить за строго отведенное нормативами и KPI время, например, за 10 минут. И как раз тут на помощь нашему аналитику может прийти платформа Incident Response Platform (IRP) — система автоматизации реагирования на инциденты информационной безопасности. Система IRP помогает выполнить ряд рутинных операций по сбору дополнительной информации, осуществить неотложные действия по сдерживанию (англ. contain) и устранению (англ. eradicate) угрозы, восстановить (англ. recover) атакованную систему, оповестить заинтересованных лиц, а также собрать и структурировать данные о расследованных инцидентах информационной безопасности. Кроме того, IRP позволяет роботизировать и автоматизировать однотипные действия оператора-специалиста ИБ, которые он производит при реагировании на инциденты информационной безопасности, что помогает снизить нагрузку сотрудника в части выполнения рутинных операций. Давайте подробнее остановимся на задачах реагирования на инциденты информационной безопасности, выполняемых IRP-системами.
Процессы реагирования на инциденты ИБ
Для того, чтобы понять, как и где корректно применять и внедрять системы IRP, нам следует увидеть процесс реагирования на инциденты информационной безопасности в целом и подумать, как можно его автоматизировать. Для этого обратимся к документу NIST SP 800-61 "Computer Security Incident Handling Guide" («Руководство по обработке инцидентов компьютерной безопасности»). В соответствии с ним, реагирование на инциденты ИБ состоит из нескольких взаимосвязанных процессов:
- Подготовка
- Детектирование
- Анализ
- Сдерживание/локализация
- Устранение
- Восстановление
- Пост-инцидентные действия
Рассмотрим эти процессы подробнее в контексте применения IRP-систем для их автоматизации.
1. Подготовка
Этап подготовки является предварительным и одним из ключевых. На данном этапе следует проделать всю организационную работу, чтобы действия команды реагирования на инциденты ИБ были документально подтверждены и согласованы. Политики, процедуры и инструкции по реагированию должны быть максимально четкими, подробными и удобными, чтобы в случае высокоприоритетного инцидента у аналитиков команды реагирования было точное понимание того, что следует предпринять в той или иной ситуации. Следует регулярно проводить тренировки по отработке шагов, определенных в написанных документах, а также обучать персонал компании и команду реагирования корректным техническим и организационным действиям во время инцидента.
На этапе подготовки также создаются и настраиваются playbooks или runbooks — сценарии реагирования, в соответствии с которыми команда реагирования и IRP-система будут предпринимать заранее заданные действия в зависимости от деталей инцидента. Например, в случае наступления высокоприоритетного инцидента ИБ на особо критичной системе в соответствии с playbook член группы реагирования должен связаться с руководителем и ответственным за систему лицом, а IRP-платформа должна дать команду на изоляцию этой системы от сети компании для проведения дальнейших разбирательств.
Кроме того, на этапе подготовки следует обеспечить группу реагирования на инциденты всем необходимым программным и аппаратным обеспечением (т.е. выдать ноутбуки, смартфоны, установить на них необходимые утилиты), а также выполнить превентивные действия по предотвращению инцидентов (защитить сеть и устройства компании, установить средства защиты информации, провести обучение сотрудников основам ИБ). В это время платформа IRP настраивается для эффективного применения: к ней подключаются ИТ-системы и средства защиты, с которыми предстоит взаимодействовать при реагировании на инциденты. Как правило, обеспечивают подключение тех систем, которые способны представить специалисту дополнительную информацию в контексте инцидента, например, сведения о затронутых инцидентом пользователях (контактные данные, должность, структурное подразделение, полномочия) и устройствах (тип операционной системы, установленное ПО, выполняемая функция). Кроме этого, подключаются и средства защиты, которые в рамках реагирования на инцидент будут выполнять задачи по сдерживанию и устранению угроз, например, средства защиты конечных точек, межсетевые экраны и системы управления сетью.
Таким образом, к моменту возникновения инцидента информационной безопасности в компании следует приходить во всеоружии: специалисты по реагированию и система IRP должны находиться в полной боевой готовности. Это является залогом того, что, даже если инцидент случится, его можно будет быстро локализовать, и его последствия не будут чрезмерно разрушительными.
2. Детектирование
На этапе детектирования следует определить список возможных типов инцидентов ИБ и сформулировать перечень признаков возможных инцидентов. Признаки можно условно разделить на прекурсоры и индикаторы инцидентов информационной безопасности:
- прекурсор — это признак того, что инцидент ИБ может произойти в будущем;
- индикатор — это признак того, что инцидент уже произошел или происходит прямо сейчас.
Примерами прекурсоров инцидента информационной безопасности могут быть зафиксированное интернет-сканирование открытых портов веб-серверов компании или выявление уязвимости в какой-то ИТ-системе. Примерами индикаторов инцидента информационной безопасности могут быть появление сообщений от средств защиты (антивируса, межсетевого экрана и т.д.) о возможной атаке, несанкционированное удаление или модификация данных, появление ошибок и сбоев в работе ИТ-систем. Следует внимательно относиться к аномалиям в сетевом трафике: неожиданные всплески определенного типа трафика (например, DNS) могут свидетельствовать о вредоносной активности. Нетипичное поведение пользователей также следует анализировать: удаленное подключение в нерабочее время из необычной локации может быть признаком компрометации учетной записи. Для того, чтобы максимально эффективно задействовать систему IRP на этапе детектирования, следует интегрировать IRP-платформу с SIEM-системой: такая связка обеспечит «бесшовную» передачу прекурсоров и индикаторов инцидента от ИТ-систем и средств защиты компании через SIEM напрямую в IRP-систему, что позволит ей оперативно обнаруживать инциденты и в дальнейшем предпринимать адекватные меры по реагированию на них.
3. Анализ
Во время этапа анализа инцидента основная нагрузка ложится на опыт и экспертизу аналитика — ему предстоит принять решение, был ли зафиксированный инцидент «боевым» или всё же это было ложноположительное срабатывание. Следует провести идентификацию и первичную обработку (триаж, англ. triage): определить тип инцидента и категорировать его. Далее определяются индикаторы копрометации (англ. Indicators of Compromise, IoCs), анализируется возможный масштаб инцидента и затронутые им компоненты инфраструктуры, проводится ограниченное форензик-обследование для уточнения типа инцидента и возможных дальнейших шагов по реагированию.
На этом этапе бесценную помощь окажет IRP-платформа — благодаря тому, что она может предоставить важную контекстную информацию, относящуюся к инциденту. Приведем пример: SIEM-система сообщает о том, что веб-сервер компании подвергся атаке, при этом использовавшаяся уязвимость применима только к ОС Windows. Аналитик, посмотрев в консоль IRP, сразу увидит, что атакованный веб-сервер работает на ОС Linux, следовательно, атака не могла быть успешной. Другой пример: антивирусная система на одном из ноутбуков сообщила о вирусном заражении и о последовавшим за этим обращением к определенным IP-адресам. Аналитик, воспользовавшись данными IRP-системы, увидит, что аналогичная сетевая активность наблюдается и на нескольких других устройствах в сети компании, что говорит не о единичном вирусе, а о массированном заражении. Инциденту будет присвоен более приоритетный статус, он будет эскалирован в соответствии с матрицей эскалации, и на его устранение будут направлены дополнительные ресурсы. Платформа IRP поможет запротоколировать все действия, выполненные в рамках реагирования, а также автоматизирует действия по коммуницированию и эскалации инцидента.
4. Сдерживание/локализация
На этапе сдерживания (или локализации) инцидента главной задачей является оперативная минимизация потенциального ущерба от инцидента ИБ и предоставление временного окна для принятия решения об устранении угрозы. Этого можно достичь, например, оперативно включив более строгие запретительные правила на межсетевом экране для зараженного устройства, изолировав зараженный хост от локальной сети компании, отключив часть сервисов и функций, или, наконец, полностью выключив зараженное устройство.
На данном этапе используются сведения об инциденте, полученные на этапе анализа, а также данные о том, какую функцию выполняет затронутый инцидентом ИТ-актив, поскольку, например, выключение критически важного сервера может привести к более существенным негативным последствиям для компании, чем простая перезагрузка некритичного сервиса на нём. В данной ситуации IRP-платформа опять же подскажет, какие функции выполняет сервер, как и когда его можно выключать или изолировать (при условии, что на этапе подготовки данная информация была занесена в IRP). Кроме этого, в playbooks IRP-системы на этапе подготовки также должны быть заложены сценарии сдерживания, применимые для каждого конкретного типа инцидента. Например, в случае DDoS-атаки, возможно, не имеет смысла выключать атакуемые сервера, а в случае вирусного заражения внутри одного сегмента сети можно не изолировать устройства в другом сегменте. На этапе сдерживания также проводится анализ подробностей атаки: какая система была первой атакована, какими тактиками, техниками и процедурами пользовались атакующие, какие командные серверы используются в данной атаке и т.д. Указанную информацию поможет собрать IRP-система: интеграция с источниками киберразведки (англ. Threat Intelligence feeds) и специализированными поисковыми системами (например, VirusTotal, Shodan, Censys и т.д.) даст более чёткую и обогащенную картину произошедшего инцидента, что поможет эффективнее справиться с ним. В некоторых случаях может потребоваться также получить форензик-данные для последующего проведения компьютерной криминалистической экспертизы, и IRP-платформа поможет собрать такую информацию с атакованных устройств.
5. Устранение
На этапе устранения инцидента производятся уже активные действия по удалению угрозы из сети и предотвращению повторной атаки: удаляется вредоносное ПО, изменяются взломанные учетные записи (их можно временно заблокировать, сменить пароль или, например, переименовать), устанавливаются обновления и патчи для проэксплуатированных уязвимостей, изменяются настройки средств защиты (например, для блокировки IP-адреса взломщиков). Указанные действия выполняются для всех затронутых инцидентом сущностей — и для устройств, и для учетных записей, и для программ.
Чрезвычайно важно тщательно устранить уязвимости, которые использовались злоумышленниками, поскольку чаще всего, успешно взломав какую-либо компанию, хакеры возвращаются в надежде использовать всё те же недостатки её защиты. При выполнении данного процесса платформа IRP даст необходимые команды средствам защиты и соберет недостающие данные обо всех затронутых инцидентом устройствах. Таким образом, скорость реагирования на инцидент информационной безопасности в части устранения самой угрозы существенно возрастает при использовании IRP-системы, которая будет отличным подспорьем аналитику ИБ.
6. Восстановление
На этапе восстановления следует проверить надежность предпринятых мер защиты, вернуть системы в нормальный режим работы (англ. business as usual), возможно, восстановив какие-то системы из резервных копий или установив и настроив их заново. На данном этапе системы IRP помогут не забыть все участвовавшие в инциденте устройства и хронологию событий, поскольку эти данные хранятся и накапливаются в IRP на протяжении всего цикла расследования инцидента.
7. Пост-инцидентные действия
На этапе пост-инцидентных действий (англ. post-incident activities) следует проанализировать причины инцидента (англ. root cause analysis) для того, чтобы свести к минимуму вероятность повторного аналогичного инцидента в будущем, а также оценить корректность и своевременность действий персонала и средств защиты, и, возможно, оптимизировать какие-то процедуры реагирования и политики ИБ. В случае серьезного инцидента следует провести внеочередное сканирование инфраструктуры на наличие уязвимостей, пен-тест и/или внеплановый аудит информационной безопасности.
Будет логично использовать агрегированную базу знаний для ведения накопленного опыта реагирования, что также можно сделать в IRP-платформе, в которой уже хранится подробная информация о произошедших инцидентах ИБ и о предпринятых мерах реагирования. В некоторых случаях требуется составление официального отчета по инциденту, особенно если он был серьезным или затронул важные данные: например, информацию по компьютерным инцидентам в критической информационной инфраструктуре следует отправлять в государственную систему ГосСОПКА. Для таких целей в некоторых отечественных IRP-системах есть как API для работы с ГосСОПКА, так и возможность автоматизированного составления отчетов по инцидентам на основе заранее созданных шаблонов. Как видим, IRP – это еще и универсальное хранилище сведений об инцидентах информационной безопасности с возможностью роботизации рутинных действий специалиста по информационной безопасности.
Выводы
Подведем итог. Системы IRP являются автоматизированными средствами реагирования на инциденты информационной безопасности, реализующими контрмеры для противодействия угрозам информационной безопасности в соответствии с заранее заданными сценариями реагирования. Сценарии реагирования называются playbooks или runbooks и представляют собой набор автоматизированных задач по детектированию угроз и аномалий в защищаемой инфраструктуре, реагированию и сдерживанию угроз в режиме реального времени. Сценарии реагирования действуют на основании настраиваемых правил и типов инцидентов, выполняя те или иные действия в зависимости от поступающих данных со средств защиты или информационных систем. Платформы IRP помогают проводить структурированное и журналируемое реагирование на инциденты информационной безопасности на основании правил и политик. По окончании реагирования на инцидент IRP-платформа поможет создать отчет об инциденте и предпринятых действиях по его устранению.
Обобщая сказанное, можно сделать вывод, что система IRP – это платформа реагирования на инциденты кибербезопасности, предназначенная для защиты информации путем систематизации данных об инцидентах информационной безопасности и роботизации действий оператора-аналитика ИБ. Благодаря IRP-платформам команды реагирования на инциденты информационной безопасности могут существенно сэкономить время и усилия при расследовании инцидентов ИБ, что напрямую повышает операционную эффективность деятельности департаментов ИБ и SOC-Центров.
