Что такое план реагирования на инциденты и как его составить

Защита данных

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

Представьте ситуацию. Пятница, день в офисе близится к концу, и после плодотворной рабочей недели ваши мысли заняты предвкушением просмотра любимого сериала под бутылочку вина. Но вдруг ваши мысли прерывает телефонный звонок. Возможно, еще один сотрудник хочет, чтобы вы сбросили его пароль? Однако, судя по панике в голосе звонящего, быстро становится понятно, что проблема не настолько тривиальная. Сотрудник жалуется, что не может открыть ни один свой файл. “Ничего страшного. Вредоносная программа на ноутбуке одного сотрудника — неприятно, но точно не конец света”, – думаете вы. Однако, когда со всех сторон посыпались звонки с аналогичными жалобами от остальных сотрудников, стало понятно, что ситуация «чуточку» сложнее. В довершение коллега говорит вам, что сервер с данными клиентов также заражен программой-вымогателем. Этот сценарий повторялся много раз по всему миру, и эффективность вашей реакции на эту ситуацию зависит от ответа на один вопрос: «Есть ли у вас план реагирования на инциденты?»

Зачем нужен план реагирования на инциденты

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

Чтобы эффективно справляться с инцидентами кибербезопасности, требуется команда, специализирующаяся на реагировании на инциденты. Некоторые организации называют такие команды группами реагирования на инциденты, связанные с компьютерной безопасностью (CSIRT). Существуют и другие варианты этой аббревиатуры, например «группа реагирования на инциденты безопасности» (SIRT) или «группа реагирования на компьютерные инциденты» (CIRT). Но как бы не называлась такая команда, ее миссия везде одинакова: ввести в действие установленный компанией план реагирования на инциденты, когда происходит инцидент.

Иногда незначительная проблема с безопасностью может привести к настоящей панике. Но будут ли все сотрудники знать, что делать в случае критической ситуации? Будет ли каждый член команды CSIRT знать свои обязанности и будет ли следовать утвержденному плану? Чем больше на кону, тем выше давление, и в таких условиях члены CSIRT будут действовать так, как они обучены. Если плана нет, то нет и гарантии, что они смогут должным образом отреагировать на инцидент.

Однако простого плана реагирования на инциденты недостаточно. Команда CSIRT должна иметь навыки и опыт, достаточные, чтобы эффективно действовать в стрессовых условиях. Эксперты в области цифровой криминалистики, аналитики вредоносных программ, менеджеры по инцидентам и аналитики центров мониторинга информационной безопасности будут активно участвовать в решении ситуации на местах. От них потребуется принятие ключевых решений, проведение углубленного расследования, предоставление обратной связи основным заинтересованным сторонам. Помимо этого, нехватка времени в такой ситуации — обычное дело. Требования регуляторов уведомлять об утечке данных встречаются всё чаще. Например, GDPR требует, чтобы компании сообщали о нарушениях безопасности данных в течение 72 часов после обнаружения. Наш опыт работы с инцидентами кибербезопасности говорит о необходимости плана реагирования на инциденты. План реагирования на инциденты означает, что в решении задачи устранения угрозы и ее последствий будут участвовать нужные люди с нужными навыками и опытом, и что каждый из них четко знает задачи и процедуры.

О планировании реагирования на инциденты

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

Поддержка высшего руководства имеет первостепенное значение. Создание плана реагирования на инциденты не должно делаться «для галочки». Без поддержки и внимания высшего руководства план может стать чистой формальностью и будет пылиться в архивах, пока не грянет гром. Высшее руководство должно обрисовывать в общих чертах, что требуется с точки зрения процесса и людей, и обеспечить любую необходимую поддержку.

Определите основные заинтересованные стороны. Контактные данные ключевых лиц и команд в рабочее и нерабочее время и должны быть задокументированы. Определите ответственных за рассылку сообщений, постановку задач и соответствующие действия. Подумайте, кого следует включать в сообщения об инцидентах и в какие детали посвящать тех или иных получателей. Задачи, возложенные на группы безопасности, должны быть точными и техническими, тогда как информация для правления компании должна быть четкой и свободной от технического жаргона. Определите суть инцидента. Укажите, какие события можно решать в обычном порядке, а в каких случаях требуются всеобщие усилия для защиты.

  • ВАЖНЫЙ СОВЕТ. Матрица классификации рисков позволит понять серьезность инцидента, быстро и точно расставить приоритеты.

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

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

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

Кто несет ответственность в рамках плана реагирования на инциденты

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

Центры мониторинга информационной безопасности — это первая линия защиты. Они стоят на страже ваших позиций 24 часа в день, 7 дней в неделю. Их роль — определить степень риска каждого оповещения от систем безопасности, собрать подтверждающую информацию и определить соответствующие действия по устранению. Работая посменно, аналитики центра мониторинга должны хорошо разбираться в угрозах кибербезопасности. Они будут иметь доступ к различным платформам и инструментам безопасности, таким как решения SIEM (системы управления информацией о безопасности и событиями безопасности) и EDR (системы обнаружения угроз и реагирования). Эти инструменты могут генерировать огромное число оповещений, от DDoS-атак до вредоносных команд, выполняемых на устройстве, и аналитикам из центра мониторинга необходимо понимать и интерпретировать эти данные. Если инцидент считается высокоприоритетным или выходит за рамки компетенции центра мониторинга информационной безопасности, то следующим звеном, которому передается расследование, является команда управления инцидентами. Роль менеджера по инцидентам можно описать как «искусство носить воду в решете». Их работа заключается в том, чтобы полностью охватить инцидент, собрать вместе основные заинтересованные стороны и провести обсуждение, чтобы определить лучший план действий.

Команда управления инцидентами — это генералы, им предоставляются доказательства, советы и мнения, и они определяют темп инцидента. Они определяют задачи для выполнения, назначают исполнителей и сроки.

Команда CIRT (группы реагирования на компьютерные инциденты) — это солдаты спецназа. Они участвуют только в серьезных и высокоприоритетных инцидентах, а в остальное время совершенствуют и развивают свои навыки. В то время как аналитики центра мониторинга информационной безопасности должны обладать широким набором навыков, в состав группы CIRT будут входить специалисты в узких областях, такие как аналитики по вредоносным программам или эксперты по цифровой криминалистике. Эта группа предоставляет экспертные технические консультации и анализ, а команда управления инцидентами поручает ей задачи, которые не может выполнять центр мониторинга.

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

6 шагов по созданию плана реагирования на инциденты

Несколько лет назад SANS опубликовала «Справочник специалиста по инцидентам», который по сей день остается стандартом для планов реагирования на инциденты. Этот справочник представляет собой модель из 6 шагов, которые вы можете использовать для построения плана вашей компании.

1. Подготовка

Подготовка к любому потенциальному инциденту безопасности — ключ к успешному реагированию. Я настоятельно рекомендую разработать инструкции, которые бы давали сотрудникам центра мониторинга руководство для определения степени риска инцидентов, содержали четкие инструкции по расстановке приоритетов и давали понимание, в каких случаях эти инциденты следует передавать выше. Они должны быть высокого уровня и ориентированы на конкретные области, такие как DDoS, вредоносные программы, внутренние угрозы, несанкционированный доступ и фишинг. Такие инструкции и процедуры необходимо протестировать с участием людей и команд, которые будут их использовать. Теоретические учения — отличный способ укрепить знания и определить потенциальные недостатки и способы улучшения.

2. Идентификация

Вы можете успешно справиться с угрозой безопасности только после того, как выясните масштаб инцидента. Начните идентификацию с «нулевого пациента» — устройства, которое было взломано первым. Ваша цель — понять основную причину взлома. Однако не сосредотачивайтесь только на одном устройстве, выясните, могла ли угроза распространиться на другие устройства внутри сети?

Настоящая идентификация инцидента происходит благодаря сбору полезных индикаторов компрометации. Вместо того чтобы просто восстанавливать исходное зараженное устройство, постарайтесь найти уникальные индикаторы компрометации, которые можно использовать для поиска на ваших устройствах дополнительных доказательств взлома. Если инцидент связан с заражением вредоносной программой, задайте следующие вопросы: какие сетевые подключения создает вредоносный объект? Подключается ли вредоносная программа к каким-либо доменам? Какие файлы создаются на диске? Какие процессы запущены? Были ли созданы какие-либо уникальные ключи реестра? Затем эти данные можно использовать для поиска дополнительных доказательств взлома и выявления любых других зараженных устройств в вашей организации.

3. Сдерживание

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

Кратковременное сдерживание может использоваться для изоляции устройства, являющегося целью атаки. Длительное сдерживание пригодится, если нужно провести глубокий анализ, требующий времени. Это может включать создание образа устройства и проведение криминалистической экспертизы жесткого диска. В результате могут появиться дополнительные индикаторы компрометации, после чего потребуется повторно провести этап идентификации.

4. Устранение

После успешного сдерживания угрозы можно приступать к ее устранению. Этот этап зависит от того, что послужило причиной взлома устройства. Установка на устройства обновлений и исправлений, обезвреживание вредоносных программ, отключение взломанных учетных записей — всё это варианты мер, которые могут потребоваться на этапе устранения.

5. Восстановление

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

6. Выводы и работа над ошибками

После того как угроза полностью устранена, следующим шагом будет поиск ответа на вопрос: «Как нам предотвратить повторение случившегося?» Необходимо провести встречу для обзора последствий инцидента, с участием представителей всех групп, вовлеченных в инцидент. Эта встреча — удобная платформа для обсуждения всех удачных и неудачных моментов, случившихся во время инцидента. По результатам этого этапа план реагирования на инциденты уточняется, а процедуры и инструкции корректируются в соответствии с тем, что было обговорено.

Рекомендации к составлению плана реагирования на инциденты

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

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

Занимайтесь поиском угроз. Ожидание срабатывания оповещения на новенькой сверкающей платформе — это одно, а упреждающий поиск подозрительной активности — совсем другое. Именно последний подход свидетельствует о зрелости группы реагирования на инциденты. Это не только позволит раньше найти потенциальный взлом или заражение, но и поможет сформировать соответствующий тип мышления специалистам, участвующим в расследовании. Эти навыки и такой тип мышления — именно то, что требуется на этапе идентификации инцидента, анализа сетевого трафика, изучения редко используемых портов и необычных процессов, чтобы понять масштабы инцидента. Если у центра мониторинга безопасности есть четкое представление о том, как выглядит «нормально», становится намного проще обнаружить вредоносную активность.

Шаблоны плана реагирования на инциденты

Создание плана реагирования на инциденты может показаться довольно сложной задачей. Однако использование шаблона обеспечит структуру и даст верное направление.

Руководство NCSC по планированию. NCSC (Национальный центр кибербезопасности) — это британская правительственная организация, которая обеспечивает поддержку информационной безопасности критически важным организациям Великобритании. Как основной государственный орган в области кибербезопасности, их рекомендации окажутся неоценимыми при планировании плана реагирования на инциденты.

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

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

Что делать после инцидента информационной безопасности?

Пыль оседает, плохие парни побеждены, а команда CSIRT строго следовала плану реагирования на инциденты. Что дальше? Подведите итоги и подготовьтесь для следующего случая. Внесите коррективы в план реагирования или постарайтесь улучшить уже существующий мониторинг. Существуют ли какие-либо дополнительные журналы, которые не были доступны во время инцидента, и которые необходимо добавить? Есть ли пробелы в навыках команды безопасности? Нужно ли пересмотреть политику компании по установке исправлений и обновлений? Постоянный анализ и уточнение процесса инцидента гарантирует, что будет не только улучшено реагирование на инцидент, но и сократится поверхность атаки. Если в систему безопасности компании вносятся дополнительные улучшения и меры контроля, это в конечном итоге приведет к меньшему количеству инцидентов. Эта статья призвана снабдить вас знаниями и ресурсами для успешного создания и развертывания плана реагирования на инциденты. Чтобы обеспечить защиту ваших данных, запустите пробную версию платформы кибербезопасности Varonis, чтобы добавить для всех ваших критически важных хранилищ данных и инфраструктуры лучший в своем классе поведенческий анализ.

 

Бесплатный аудит рисков кибербезопасности

Узнайте об уязвимостях вашей ИТ-инфраструктуры - мы проведем бесплатный аудит рисков и подготовим для вас отчет. Это займет около 90 минут вашего времени и никак не отразится на бизнес-процессах компании.