SOT

SOT

SOAR
Security Orchestration, Automation and Response

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

NG SOAR
Next Generation SOAR

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

AM
Asset Management

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

VM
Vulnerability Management

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

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

GRC

GRC

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

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

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

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

FinCERT
Financial Computer Emergency Response Team

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

RM
Risks Management

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

ORM
Operational Risks Management

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

CM
Compliance Management

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

BCP
Business Continuity Plan

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

Напишите нам на marketing@securituvision.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 Стандарты ИБ Управление ИБ

Рекомендуем

Системы и средства защиты информации (конспект лекции)
Системы и средства защиты информации (конспект лекции)
Как управлять отарой овец с помощью одной собаки, или актуальные подходы к настройке сетевого оборудования
Как управлять отарой овец с помощью одной собаки, или актуальные подходы к настройке сетевого оборудования
Обзор средств информационной безопасности: сетевая защита
Обзор средств информационной безопасности: сетевая защита
Краткий обзор специальных публикаций NIST по информационной безопасности. Часть 2
Краткий обзор специальных публикаций NIST по информационной безопасности. Часть 2
Вебинары о конструкторах аналитики и отчетов на платформе Security Vision
Вебинары о конструкторах аналитики и отчетов на платформе Security Vision
Обзор публикации NIST SP 800-207 "Zero Trust Architecture"
Обзор публикации NIST SP 800-207 "Zero Trust Architecture"
Динамический анализ исходного кода
Динамический анализ исходного кода
«Фишки» Security Vision: объекты и процессы
«Фишки» Security Vision: объекты и процессы
Нормативные документы по ИБ. Часть 9. Обзор российского законодательства в области защиты критической информационной инфраструктуры - продолжение
Нормативные документы по ИБ. Часть 9. Обзор российского законодательства в области защиты критической информационной инфраструктуры - продолжение
Статический анализ исходного кода
Статический анализ исходного кода
Кибербезопасность, киберустойчивость, киберучения – что это?
Кибербезопасность, киберустойчивость, киберучения – что это?
Обзор средств информационной безопасности: данные и инциденты
Обзор средств информационной безопасности: данные и инциденты

Рекомендуем

Системы и средства защиты информации (конспект лекции)
Системы и средства защиты информации (конспект лекции)
Как управлять отарой овец с помощью одной собаки, или актуальные подходы к настройке сетевого оборудования
Как управлять отарой овец с помощью одной собаки, или актуальные подходы к настройке сетевого оборудования
Обзор средств информационной безопасности: сетевая защита
Обзор средств информационной безопасности: сетевая защита
Краткий обзор специальных публикаций NIST по информационной безопасности. Часть 2
Краткий обзор специальных публикаций NIST по информационной безопасности. Часть 2
Вебинары о конструкторах аналитики и отчетов на платформе Security Vision
Вебинары о конструкторах аналитики и отчетов на платформе Security Vision
Обзор публикации NIST SP 800-207 "Zero Trust Architecture"
Обзор публикации NIST SP 800-207 "Zero Trust Architecture"
Динамический анализ исходного кода
Динамический анализ исходного кода
«Фишки» Security Vision: объекты и процессы
«Фишки» Security Vision: объекты и процессы
Нормативные документы по ИБ. Часть 9. Обзор российского законодательства в области защиты критической информационной инфраструктуры - продолжение
Нормативные документы по ИБ. Часть 9. Обзор российского законодательства в области защиты критической информационной инфраструктуры - продолжение
Статический анализ исходного кода
Статический анализ исходного кода
Кибербезопасность, киберустойчивость, киберучения – что это?
Кибербезопасность, киберустойчивость, киберучения – что это?
Обзор средств информационной безопасности: данные и инциденты
Обзор средств информационной безопасности: данные и инциденты

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

Термины и определения в области информационной безопасности
Термины и определения в области информационной безопасности
Управление киберрисками с помощью Security Vision Cyber Risk System (CRS)
Управление киберрисками с помощью Security Vision Cyber Risk System (CRS)
Применение стандарта ISO 31000
Применение стандарта ISO 31000
Обзор публикации NIST SP 1800-5 "IT Asset Management"
Обзор публикации NIST SP 1800-5 "IT Asset Management"
Обзор Security Vision 3.4 — российской платформы SGRC
Обзор Security Vision 3.4 — российской платформы SGRC
TIP и TI (Threat Intelligence или Киберразведка), что это такое
TIP и TI (Threat Intelligence или Киберразведка), что это такое
Что такое фактор аутентификации, зачем нужен второй и сколько их всего
Что такое фактор аутентификации, зачем нужен второй и сколько их всего
«Фишки» Security Vision: отчеты и аналитика
«Фишки» Security Vision: отчеты и аналитика
ChatGPT на темной и светлой стороне
ChatGPT на темной и светлой стороне

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

Термины и определения в области информационной безопасности
Термины и определения в области информационной безопасности
Управление киберрисками с помощью Security Vision Cyber Risk System (CRS)
Управление киберрисками с помощью Security Vision Cyber Risk System (CRS)
Применение стандарта ISO 31000
Применение стандарта ISO 31000
Обзор публикации NIST SP 1800-5 "IT Asset Management"
Обзор публикации NIST SP 1800-5 "IT Asset Management"
Обзор Security Vision 3.4 — российской платформы SGRC
Обзор Security Vision 3.4 — российской платформы SGRC
TIP и TI (Threat Intelligence или Киберразведка), что это такое
TIP и TI (Threat Intelligence или Киберразведка), что это такое
Что такое фактор аутентификации, зачем нужен второй и сколько их всего
Что такое фактор аутентификации, зачем нужен второй и сколько их всего
«Фишки» Security Vision: отчеты и аналитика
«Фишки» Security Vision: отчеты и аналитика
ChatGPT на темной и светлой стороне
ChatGPT на темной и светлой стороне