В этой статье я хотел бы рассмотреть вышедший буквально на днях стандарт NIST 800–61r3 «Incident Response Recommendations and Considerations for Cybersecurity Risk Management» (Рекомендации и соображения по реагированию на инциденты для управления рисками в сфере кибербезопасности). Замененный стандарт 800–61r2, выпущенный в далеком 2012 году, был полностью переработан и текущая версия существенно отличается по структуре и подходу к вопросу реагирования на компьютерные инциденты.
Дисклеймер
Хочу отметить, что в данной статье я привожу личные суждения и свой перевод выдержек из стандарта, которые могут отличаться от мнения и перевода других специалистов. В любом случае, готов обсуждать все спорные моменты в комментариях.
Постоянно изучая разные практики по организации процессов реагирования на компьютерные инциденты, я решил разобрать положения данного стандарта чтобы узнать как сейчас видят суть процесса реагирования в США и отметить основные изменения.
Предыдущий стандарт был самостоятельным документом, в котором последовательно и описательно излагались вопросы, которые авторы считали актуальными. В новой редакции стандарт переработали под методологию, описанную в NIST Cybersecurity Framework (CSF) 2.0 и все рекомендации по реагированию на инциденты теперь строго разделены по шести функциям. Авторы поясняют, что вместо статичного документа, описывающего актуальные на момент его выпуска технологии и методики, они в контексте системы по управлению рисками в сфере кибербезопасности описали принципы системы управления реагированием на компьютерные инциденты. В каком‑то смысле стандарт стал проще для специалистов по комплаенсу и тему реагирования встроили в методологию, но усложнили его для тех кто предпочитает читать профильную литературу в виде статей, руководств и книг.
Собственно, чтобы прочесть стандарт, нам сначала необходимо ознакомиться с изначальным фреймворком CSF 2.0. Опишу коротко его шесть основных функций:
Управлять
Функция управления направлена на определение контекста организации (ее целей, интересов, зависимостей и требований законодательства), определения приоритетов в деятельности организации и ее отношения к риску и задаче обработке риска, определения и утверждения ролей в области кибербезопасности и их обязанностей и полномочий, разработка стратегии кибербезопасности, управление рисками в цепочке поставок кибербезопасности.
Идентифицировать
Функция идентификации направлена на инвентаризацию — определение активов организации и управления ими, а также связанных с этими активами существующими рисками кибербезопасности. Включает категорию задач по улучшению политик, планов, процессов, процедур и практик, связанных с управлением рисками кибербезопасности.
Защищать
Функция защиты направлена на обеспечение мер защиты информации, в частности: управление идентификацией, аутентификация и контроль доступа; повышение осведомленности и профессиональная подготовка; безопасность данных; безопасность платформы (т. е. обеспечение безопасности оборудования, программного обеспечения и услуг, физических и виртуальных платформ); обеспечение устойчивости технологической инфраструктуры.
Обнаруживать
Функция обнаружения направлена на меры по своевременному обнаружению и анализу событий безопасности и определению факта наличия компьютерных инцидентов.
Реагировать
Функция реагирования направлена на управление инцидентом: его анализом и расследованием, реагированием на него, предотвращением развития и сдерживанием его последствий, устранением инцидента, отчетностью.
Восстановление
Функция восстановления направлена на обеспечение возврата инфраструктуры к нормальной работе и уменьшению последствий инцидентов кибербезопасности.
По сути, поменялась модель жизненного цикла процесса по реагированию на инциденты с классического «кругового» жизненного цикла («Подготовка» — «Обнаружение» — «Реагирование и восстановление» — «Анализ» — и снова на начало) на параллельную работу по отдельным задачам. Авторы поясняют, что с ростом количества инцидентов подход последовательного прохождения этапов обработки инцидента по кругу устарел и тормозит работу — к примеру, в том случае когда результаты анализа инцидента (индикаторы компрометации) нужно передавать сразу в два направления: для улучшения системы защиты (этап «Подготовка») и в SIEM (функция «Обнаружение»), а подробности о вредоносной активности — в планы реагирования (этап «Реагирование»).
Новая модель жизненного цикла подразумевает параллельную работу сразу по всем направлениям:
Здесь все функции разделены на два раздела: подготовительный, несущий вспомогательную роль для процесса реагирования на инциденты (Govern, Identify, Protect, (Identify) Improvement) и группу основных функций по реагированию (Detect, Respond, Recover). По сути, фреймворк CSF 2.0 описывает два основных аспекта работы службы безопасности, занимающейся информационной безопасностью во внутренней инфраструктуре:
разработка, внедрение, администрирование системы защиты информации
обнаружение и реагирование на инциденты
Следует отметить разницу в определениях, которая может быть интересна специалистам, занимающимся регуляторикой: когда наши стандарты опираются на определение компьютерного инцидента, сформулированного в законе «О безопасности критической информационной инфраструктуры Российской Федерации» от 26.07.2017 N 187-ФЗ:
Компьютерный инцидент — факт нарушения и (или) прекращения функционирования объекта критической информационной инфраструктуры, сети электросвязи, используемой для организации взаимодействия таких объектов, и (или) нарушения безопасности обрабатываемой таким объектом информации, в том числе произошедший в результате компьютерной атаки;
то в 800–61r3 приведено следующее определение компьютерного инцидента, прямо процитированное из FISMA 2014:
Инцидент кибербезопасности — событие, которое фактически или неизбежно ставит под угрозу, без законных полномочий, целостность, конфиденциальность или доступность информации или информационной системы; или представляет собой нарушение или неминуемую угрозу нарушения закона, политик безопасности, процедур безопасности или политик приемлемого использования.
В оригинале
Cybersecurity incident — an occurrence that actually or imminently jeopardizes, without lawful authority, the integrity, confidentiality, or availability of information or an information system; or constitutes a violation or imminent threat of violation of law, security policies, security procedures, or acceptable use policies.
Оба определения верны, но наше определение более конкретно, что в контексте работы по реагированию на компьютерные инциденты дает более четкие критерии по их определению, в отличие от конфиденциальности, целостности и доступности, которые являются понятиями теории и их понимание зависит от трактовки.
Также важно отметить, что основная цель фреймворка CSF 2.0 — управление рисками кибербезопасности и их уменьшение. Это направление проходит красной нитью через весь документ, и эта же цель прослеживается и в стандарте NIST 800–61r3, что, по сути, является более зрелым подходом, чем разработка системы защиты информации через моделирование угроз.
Сам набор рекомендаций, составленный в разделе 3 «CSF 2.0 Community Profile for Cyber Incident Risk Management» является базовым набором, который организациям предлагается доработать под конкретные условия. Тем не менее, изложенные задачи верхнего уровня изложены настолько абстрактно, что местами требуется искать уточнения — что имелось в виду под конкретной категорией. В этом помогает маппинг CSF 2.0 с, к примеру, «Security and Privacy Controls for Information Systems and Organizations» NIST 800–53r5:
Например, мера защиты из NIST 800–53 SI-3: Защита от вредоносного кода ссылается на категории PR.DS-01,PR.DS-02 и PR.DS-10 из CFS 2.0.
Другой пример, ближе к теме статьи: в фреймворке CSF 2.0 категория DE.AE-06 (Detect, Adverse Event Analysis) описывает необходимость в передаче информации о событиях безопасности уполномоченному персоналу и информационные системы (LM/SIEM‑решения).
В стандарте 800–61r3 устанавливается высокий приоритет данной категории задач (относительно темы стандарта) и дополняется следующими рекомендациями: должны создаваться оповещения, которые в дальнейшем передаются в информационные системы и команде, занимающимся реагированием на компьютерные инциденты (к примеру, команды SOC). Доступ к информации о событиях и их анализе должен быть у команды в любое время. Заявки на анализ по определенным типам событий должен создаваться автоматически.
Если обратим внимание на меры из NIST 800–53r5, связанные с DE.AE-06 через CSF Tool, то увидим следующий список:
IR-4: Процесс обработка инцидентов
PM-15: Обеспечение контактов с сообществом по информационной безопасности
PM-16: Обмен информацией о угрозах (threat awareness program)
RA-10: Процесс Threat Hunting
Здесь в первую очередь актуальна мера IR-4, для выполнения которой необходимо применение уже конкретных организационных и технических мер, в т.ч. IR-4(1) — «автоматизированные процессы обработки» — подразумевают применение SIEM.
Таким образом, постепенно, от «высоких» целей можно перейти к конкретным практическим задачам. Здесь роль стандарта NIST 800–61r3 — определить общий профиль из элементов структуры фреймворка CSF и расставить приоритеты. Чтобы не перегружать статью, приведу только функции с высоким приоритетом (в контексте стандарта) в виде списка:
Еще один из моментов, которые следует отметить как существенное изменение в новом стандарте — это изменение раздела, касающегося описания организации команды реагирования на инциденты. Поменялось даже название раздела — со «Структуры команды по реагированию на инциденты» на «Роли и обязанности по реагированию на инциденты».
Когда в прошлой версии стандарта речь шла про коллектив, который решает задачу реагирования самостоятельно, и который зависит от других подразделений, которые могут привлекаться для работы по инциденту, то в новом стандарте предмет рассмотрения — роли. На мой взгляд, это шаг к распределению ролей по работе, связанной с реагированием на инциденты, по всей организации и построению распределенных рабочих групп, распределению ответственности. Работа по реагированию на инциденты ложится не на одно подразделение, а на распределенную рабочую группу, что должно повышать успешность и скорость такой деятельности, что опять же, является более зрелым подходом чем тот, который был раньше.