Обзор публикации NIST SP 800-61 "Computer Security Incident Handling Guide". Часть 1.

Руслан Рахметов, Security Vision

Для эффективного реагирования на инциденты ИБ чрезвычайно важно заблаговременно выстроить четкий процесс управления киберинцидентами, поскольку именно в момент наступления инцидента, в условиях стресса и возможного отсутствия ресурсов, требуется максимально корректно выполнить все необходимые этапы реагирования. Для решения данной задачи можно воспользоваться методическими рекомендациями документа NIST SP 800-61 Rev. 2 "Computer Security Incident Handling Guide" ("Руководство по обработке инцидентов компьютерной безопасности", версия 2), который вышел в 2012 году, но концептуально не устарел, поскольку предложенный в нем фреймворк можно адаптировать под современные технологии и актуальные киберугрозы. В данном документе описываются организационные и технические аспекты реагирования на киберинциденты, и в сегодняшней публикации - обзор организационных рекомендаций документа NIST SP 800-61.

Документ NIST SP 800-61 предлагает использовать следующие определения:

· Событие — это любое зафиксированное явление в системе или сети (например, подключение пользователя к файловому серверу, обработка веб-запроса сервером, отправка email-сообщения, блокирование межсетевым экраном сетевого соединения).
· Неблагоприятное событие — это событие с негативными последствиями (например, преднамеренный сбой в работе ПО, несанкционированный доступ к данным, несанкционированное использование повышенных привилегий, запуск вредоносного ПО).
· Киберинцидент — это нарушение или неизбежная угроза нарушения политик ИБ, политик допустимого использования или стандартных практик ИБ.

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

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

1. Утверждение о вовлеченности руководства компании в процесс реагирования на киберинциденты и понимание его важности на всех уровнях компании;

2. Цели и задачи политики;

3. Термины и определения для создания единого понятийного аппарата;

4. Организационная структура и распределение ролей, ответственности, полномочий и уровней принятия решений;

5. Уровни критичности и приоритизация инцидентов;

6. Метрики эффективности процесса реагирования на киберинциденты;

7. Формы отчетности и отправки уведомлений.

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

1. Миссия, стратегия и цели плана реагирования на киберинциденты;

2. Согласование плана руководством компании;

3. Общий подход компании к реагированию на киберинциденты;

4. Структура команды реагирования на киберинциденты;

5. Способ взаимодействия команды реагирования с работниками компании и с другими компаниями;

6. Метрики оценки возможностей и эффективности функции реагирования на киберинциденты в компании;

7. «Дорожная карта» повышения уровня зрелости функции реагирования на киберинциденты в компании;

8. Взаимосвязь функции реагирования на киберинциденты с другими функциями в компании.

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

В рамках разработки документов по управлению киберинцидентами следует описать формат и способ взаимодействия со сторонними лицами в случае выявления инцидента: 

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

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

3. Взаимодействие с центрами реагирования на киберинциденты: обязательное предоставление информации о произошедшем киберинциденте в государственные центры реагирования на киберинциденты (в РФ это ФинЦЕРТ и НКЦКИ) или обмен информацией о произошедших инцидентах и получение помощи от отраслевых или коммерческих центров противодействия кибератакам.

4. Взаимодействие с интернет-провайдером: блокирование сетевого трафика (например, в случае DDoS-атаки), сохранение и получение логов сетевых соединений.

5. Взаимодействие с владельцем атакующего IP-адреса: в случае атаки можно взаимодействовать с Abuse-контактом внешнего провайдера или с владельцем автономной системы.

6. Взаимодействие с вендорами: взаимодействие с ИБ-вендором может помочь при возникновении вопросов по работе с СЗИ или при вероятных ложноположительных срабатываниях, а взаимодействие с производителем ПО поможет обменяться информацией о возможных уязвимостях или новых векторах атак на софт.

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

В документе NIST SP 800-61 рассматриваются также различные варианты структуры команды реагирования на киберинциденты, которые могут состоять из штатных сотрудников или быть частично / полностью на аутсорсе:
   

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

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

3. Координирующая команда: может использоваться для помощи и оказания услуг в случаях, когда между командами в различных филиалах нет прямого подчинения.

Следующие факторы следует учитывать при выборе структуры команды реагирования: 

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

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

3. Мотивация сотрудников: недостаток квалифицированных специалистов и сложность круглосуточной работы в команде реагирования приводят к ожидаемым сложностям при наборе кадров, поэтому рекомендуется снять с членов команды административную нагрузку и снизить количество рутинных операций, чего можно достичь, например, с помощью решений класса IRP/SOAR, таких как Security Vision Incident Response Platform.

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

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

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

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

2. Разделение обязанностей: некоторые критичные операции компания будет, вероятно, выполнять самостоятельно (например, изоляция хостов, отключение учетных записей и т.д.), поэтому следует заранее определить зоны ответственности и выполняемые действия.

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

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

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