SOC в действии

15 ноября 2021

Несколько слов о том, что такое SOC?

Security Operations Center (SOC) дословно оперативный центр безопасности, в практической деятельности получил название центр мониторинга и реагирования на инциденты информационной безопасности. Основной целью его деятельности является выявление и реагирование на инциденты информационной безопасности. Помимо SOC, на практике встречаются еще другие аббревиатуры, зачастую воспринимаемые как синонимы:

• CERT (Computer Emergency Response Team) – группа компьютерного реагирования на чрезвычайные ситуации;
• CSIRT (Computer Security Incident Response Team) – группа реагирования на инциденты компьютерной безопасности.

На практике, указанные структуры хоть и выполняют, по сути, одинаковые задачи, связанные с выявлением, реагированием и расследованием инцидентов, имеют всё таки некоторые различия. Так, CERTы ориентированы на определенную сферу, например FinCERT (кредитно-финансовая сфера), GovCERT (изначально ориентирован на сферу государственных информационных ресурсов, позже в него добавились сферы относящиеся к критической информационной инфраструктуре), CSIRTы на мониторинг актуальных угроз, формирование информационной базы инцидентов и обмен информацией между участниками, например CSIRT-RU (созданный для обмена информацией об инцидентах между службами информационной безопасности организаций различных форм собственности). В большинстве случаев CERT/CSIRT являются своего рода объединениями SOC.
Созданная в настоящее время Государственная система обнаружения, предупреждения и ликвидации последствий компьютерных атак (ГосСОПКА), по сути, также представляет собой CERT (главный центр ГосСОПКА), объединяющий различные SOC (ведомственные (корпоративные) центры (сегменты) ГосСОПКА).

Основные функции и процессы SOC

Структурно SOC можно представить в виде следующих блоков:

Как видно из схемы, основные процессы в рамках SOC связаны с обработкой инцидентов. Рассмотрим процесс обработки инцидентов более подробно. Общую модель обработки инцидента можно представить следующим образом (рисунок 2). Данная модель является компиляцией основных положений NIST 800-61 R2. Computer Security Icident Handling Guide и практического опыта автора:

1. Обнаружение и регистрация события. С целью своевременного выявления факторов, обуславливающих появление угроз информационной безопасности и их реализации, проводится внутренний контроль соблюдения требований по защите информации (т.н. «подготовка»), в ходе которого могут выявляться инциденты информационной безопасности. В постоянном режиме осуществляется мониторинг информационных ресурсов. Источниками информации об инцидентах служат журналы аудита, содержимое рабочих станций (хранящиеся на них файлы), сетевой трафик, журналы SIEM и DLP систем, данные инструментального контроля, обращения (жалобы) пользователей.
2. Выявление инцидента. В случае выявления события, указывающего на свершившуюся, предпринимаемую или вероятную реализацию угрозы информационной безопасности производится его фиксация.
3. Оперативное реагирование на событие/инцидент. При возникновении события, свидетельствующего о вероятной реализации угрозы информационной безопасности (индикатора инцидента), производится локализация источника вероятной угрозы.
4. Реагирование на инцидент. Как только становится понятным, что произошел инцидент, начинается документирование расследования и сбор доказательств. Определяются стратегии и процедуры для его нейтрализации, расставляются приоритеты при обработке инцидента на основе соответствующих факторов, информируются соответствующие лица.
5. Расследование инцидента. Расследование инцидента ведется до тех пор, пока не будут выявлены все причины инцидента. Сотрудники, задействованные в процессе расследования инцидента, должны собрать максимум информации о лицах, инициировавших атаку (сбой), порядке действий этих лиц, мотивах атаки, наличию сговора и иной информации, способствующей установлению степени участия тех или иных лиц. При необходимости осуществляется взаимодействие (обращение за помощью) к внешним ресурсам – другие SOC\CERT\CSIRT, подрядчики, обладающие экспертизой в расследовании инцидентов.
6. Анализ причин и факторов, подготовка рекомендаций. На данном этапе осуществляется анализ причин инцидентов, результатов устранения последствий инцидентов, получение, хранение, защита и документирование доказательств, извлечение уроков.
7. Закрытие инцидента. Фиксация факта прекращения работы по нему.

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

• Рутинные операции: процессы развития инфраструктуры, процессы эксплуатации инфраструктуры, процессы поддержки инфраструктуры.
• Техническое обеспечение: соответствие стандартам и законодательству, развитие и улучшение бизнес-процессов, показатели эффективности бизнеса.
• Бизнес-процессы: иные каждодневные бизнес-операции.

Следует отметить, что процессы не являются неизменными и требуют совершенствования. Для оценки зрелости процесса и определения необходимых действий по его совершенствованию можно использовать Process Assessment Model (PAM) методологии COBIT 5 (с учетом ГОСТ Р ИСО/МЭК 15504-2-2009 Информационная технология (ИТ). Оценка процесса. Часть 2. Проведение оценки). В основу данной методологии положена оценка того, насколько «возможно», что процессы будут приводить к ожидаемым и запланированным результатам. В соответствии с указанной моделью выделяются следующие уровни зрелости (Таблица 1).

Для совершенствования процессов используется цикл PDCA (Цикл Деминга): P – Plan (Планируй), D – Do (Делай), C – Control (Контролируй), A – Act (Совершенствуй). Классический цикл, используемый в системах менеджмента в том числе и информационной безопасности.

Особенности процесса создания SOC

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

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

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

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

Источник: журнал Информационная безопасность, №5, 2019