SOT

SOT

SOAR
Security Orchestration, Automation and Response

Автоматизация реагирования на инциденты информационной безопасности при помощи динамических плейбуков с применением СЗИ, выстраиванием цепочки атаки и объектно-ориентированным подходом

NG SOAR
Next Generation SOAR

Автоматизация реагирования на инциденты ИБ со встроенной базовой корреляцией, сбором сырых событий непосредственно с СЗИ, динамическими плейбуками, выстраиванием цепочки атаки и объектно-ориентированным подходом

AM
Asset Management

Описание ИТ-ландшафта, обнаружение новых объектов в сети, категорирование активов, инвентаризации и управления жизненным циклом оборудования и ПО на АРМ и серверах организаций

VM
Vulnerability Management

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

ГосСОПКА
Государственная Система Обнаружения Предупреждения и Ликвидации Последствий Компьютерных Атак

Двустороннее взаимодействие с Национальным координационным центром по компьютерным инцидентам (НКЦКИ), а именно передача информации об инцидентах и получение оперативных уведомлений/бюллетеней от регулятора

FinCERT
Financial Computer Emergency Response Team

Двустороннее взаимодействие с Центральным Банком (ЦБ РФ, ЦБ РБ и др.), а именно передача информации об инцидентах и получение оперативных уведомлений/бюллетеней от регулятора

Напишите нам на sales@securityvision.ru или закажите демонстрацию

GRC

GRC

КИИ
Критическая Информационная Инфраструктура

Аудит и исполнение требований ФЗ-187 «О безопасности критической информационной инфраструктуры Российской Федерации» и других нормативных документов

RM
Risk Management

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

ORM
Operational Risk Management

Учёт и фиксация событий операционных рисков (СОР), мониторинг ключевых индикаторов рисков (КИР) и проведение самооценки /контроля согласно положению №716-П ЦБ РФ

CM
Compliance Management

Аудит соответствия и комплаенса различным методологиям и стандартам

BCP
Business Continuity Plan

Автоматизация процесса обеспечения непрерывности и восстановления деятельности (ОНиВД) после наступления чрезвычайных ситуаций

Напишите нам на sales@securityvision.ru или закажите демонстрацию

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

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

  |  Слушать на Google Podcasts  |   Слушать на Mave  |   Слушать на Яндекс Музыке  |  


Руслан Рахметов, 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. Поддержка уровня внутренних компетенций: в различных ситуациях услуги аутсорсеров могут стать недоступными, и в таком случае компании важно иметь собственных сотрудников, которые смогут сами корректно отреагировать на инцидент.

Подкасты ИБ NIST Стандарты ИБ Управление ИБ

Рекомендуем

Нормативные документы по ИБ. Часть 7. Обзор российского законодательства в области защиты критической информационной инфраструктуры
Нормативные документы по ИБ. Часть 7. Обзор российского законодательства в области защиты критической информационной инфраструктуры
Зачем нужен мониторинг пользователей и как он работает
Зачем нужен мониторинг пользователей и как он работает
Публикация MITRE «11 стратегий SOC-центра мирового уровня». Стратегия №3 «Выстраивайте структуру SOC в соответствии с потребностями компании». Часть 2
Публикация MITRE «11 стратегий SOC-центра мирового уровня». Стратегия №3 «Выстраивайте структуру SOC в соответствии с потребностями компании». Часть 2
Вебинары о конструкторах объектов, меню и ролей на платформе Security Vision
Вебинары о конструкторах объектов, меню и ролей на платформе Security Vision
«Фишки» Security Vision: совместная работа
«Фишки» Security Vision: совместная работа
Анализ угроз и киберразведка: какие проблемы решает обновленная Security Vision TIP
Анализ угроз и киберразведка: какие проблемы решает обновленная Security Vision TIP
Обзор средств информационной безопасности: защита конечных точек
Обзор средств информационной безопасности: защита конечных точек
Кибератаки. Часть 2: Продвинутые техники и манипуляции
Кибератаки. Часть 2: Продвинутые техники и манипуляции
Положение Банка России № 716-П и управление операционными рисками
Положение Банка России № 716-П и управление операционными рисками
Этичный хакер и его роль в безопасности
Этичный хакер и его роль в безопасности
Отчеты нового поколения
Отчеты нового поколения
Взаимодействие субъектов критической информационной инфраструктуры с ГосСОПКА в рамках 187-ФЗ. Приказы ФСБ России № 366, 367, 368 и 282
Взаимодействие субъектов критической информационной инфраструктуры с ГосСОПКА в рамках 187-ФЗ. Приказы ФСБ России № 366, 367, 368 и 282

Рекомендуем

Нормативные документы по ИБ. Часть 7. Обзор российского законодательства в области защиты критической информационной инфраструктуры
Нормативные документы по ИБ. Часть 7. Обзор российского законодательства в области защиты критической информационной инфраструктуры
Зачем нужен мониторинг пользователей и как он работает
Зачем нужен мониторинг пользователей и как он работает
Публикация MITRE «11 стратегий SOC-центра мирового уровня». Стратегия №3 «Выстраивайте структуру SOC в соответствии с потребностями компании». Часть 2
Публикация MITRE «11 стратегий SOC-центра мирового уровня». Стратегия №3 «Выстраивайте структуру SOC в соответствии с потребностями компании». Часть 2
Вебинары о конструкторах объектов, меню и ролей на платформе Security Vision
Вебинары о конструкторах объектов, меню и ролей на платформе Security Vision
«Фишки» Security Vision: совместная работа
«Фишки» Security Vision: совместная работа
Анализ угроз и киберразведка: какие проблемы решает обновленная Security Vision TIP
Анализ угроз и киберразведка: какие проблемы решает обновленная Security Vision TIP
Обзор средств информационной безопасности: защита конечных точек
Обзор средств информационной безопасности: защита конечных точек
Кибератаки. Часть 2: Продвинутые техники и манипуляции
Кибератаки. Часть 2: Продвинутые техники и манипуляции
Положение Банка России № 716-П и управление операционными рисками
Положение Банка России № 716-П и управление операционными рисками
Этичный хакер и его роль в безопасности
Этичный хакер и его роль в безопасности
Отчеты нового поколения
Отчеты нового поколения
Взаимодействие субъектов критической информационной инфраструктуры с ГосСОПКА в рамках 187-ФЗ. Приказы ФСБ России № 366, 367, 368 и 282
Взаимодействие субъектов критической информационной инфраструктуры с ГосСОПКА в рамках 187-ФЗ. Приказы ФСБ России № 366, 367, 368 и 282

Похожие статьи

Нормативные документы по ИБ. Часть 12. Обзор российского законодательства в области информационной безопасности финансовых организаций
Нормативные документы по ИБ. Часть 12. Обзор российского законодательства в области информационной безопасности финансовых организаций
DDoS-атаки: что это такое и способы защиты от них
DDoS-атаки: что это такое и способы защиты от них
Обзор публикаций NIST SP 800-213 "IoT Device Cybersecurity Guidance for the Federal Government: Establishing IoT Device Cybersecurity Requirements"
Обзор публикаций NIST SP 800-213 "IoT Device Cybersecurity Guidance for the Federal Government: Establishing IoT Device Cybersecurity Requirements"
Импортозамещение
Импортозамещение
Публикация MITRE «11 стратегий SOC-центра мирового уровня». Введение (Стратегия №0)
Публикация MITRE «11 стратегий SOC-центра мирового уровня». Введение (Стратегия №0)
Публикация MITRE «11 стратегий SOC-центра мирового уровня». Стратегия №10 «Применяйте метрики оценки эффективности для улучшения работы SOC»
Публикация MITRE «11 стратегий SOC-центра мирового уровня». Стратегия №10 «Применяйте метрики оценки эффективности для улучшения работы SOC»
SIEM системы (Security Information and Event Management) - что это и зачем нужно?
SIEM системы (Security Information and Event Management) - что это и зачем нужно?
Защита персональных данных (конспект лекции)
Защита персональных данных (конспект лекции)
Не доверяй и семь раз проверяй: как устроен Zero Trust
Не доверяй и семь раз проверяй: как устроен Zero Trust

Похожие статьи

Нормативные документы по ИБ. Часть 12. Обзор российского законодательства в области информационной безопасности финансовых организаций
Нормативные документы по ИБ. Часть 12. Обзор российского законодательства в области информационной безопасности финансовых организаций
DDoS-атаки: что это такое и способы защиты от них
DDoS-атаки: что это такое и способы защиты от них
Обзор публикаций NIST SP 800-213 "IoT Device Cybersecurity Guidance for the Federal Government: Establishing IoT Device Cybersecurity Requirements"
Обзор публикаций NIST SP 800-213 "IoT Device Cybersecurity Guidance for the Federal Government: Establishing IoT Device Cybersecurity Requirements"
Импортозамещение
Импортозамещение
Публикация MITRE «11 стратегий SOC-центра мирового уровня». Введение (Стратегия №0)
Публикация MITRE «11 стратегий SOC-центра мирового уровня». Введение (Стратегия №0)
Публикация MITRE «11 стратегий SOC-центра мирового уровня». Стратегия №10 «Применяйте метрики оценки эффективности для улучшения работы SOC»
Публикация MITRE «11 стратегий SOC-центра мирового уровня». Стратегия №10 «Применяйте метрики оценки эффективности для улучшения работы SOC»
SIEM системы (Security Information and Event Management) - что это и зачем нужно?
SIEM системы (Security Information and Event Management) - что это и зачем нужно?
Защита персональных данных (конспект лекции)
Защита персональных данных (конспект лекции)
Не доверяй и семь раз проверяй: как устроен Zero Trust
Не доверяй и семь раз проверяй: как устроен Zero Trust