Если вы работаете в компании, которая попадает под действие №187-ФЗ («О безопасности критической информационной инфраструктуры Российской Федерации»), то вам не нужно объяснять, что такое ГосСОПКА и зачем она нужна. Для остальных поясним: ГосСОПКА расшифровывается как Государственная система обнаружения, предупреждения и ликвидации последствий компьютерных атак. Архитектурно она представляет собой единый территориально распределенный комплекс центров различного масштаба, обменивающихся информацией о кибератаках. Такие центры обязаны создать все компании, которым принадлежат объекты критической информационной инфраструктуры (такие компании называют субъектами КИИ). Цель всей этой масштабной государственной инициативы – создать между важнейшими организациями страны систему обмена информацией о ведущихся кибератаках и тем самым обеспечить возможность превентивной защиты.
Достаточно долгое время основным документом, определяющим принципы функционирования центров ГосСОПКА и их взаимодействия с вышестоящим центром, были «Методические рекомендации по созданию и эксплуатации центров ГосСОПКА», разработанные ФСБ. Мы ранее делали обзор данного документа и отмечали, что основным фокусом его внимания было построение процессов по управлению инцидентами и контролю защищенности субъектов ГосСОПКА. Но в то же время этот подход оставлял достаточно большое поле для различного толкования того, какой объем задач должен решать центр ГосСОПКА и какие именно инструменты для этого требуются. Недавно вышли «Требования к средствам, предназначенным для обнаружения, предупреждения и ликвидации последствий компьютерных атак и реагирования на компьютерные инциденты». Попробуем разобраться, чего же ждет регулятор от компаний, строящих у себя центры ГосСОПКА, и исследовать этот вопрос.
Иерархия взаимодействия центров ГосСОПКА
Известны попытки построения центров ГосСОПКА исключительно на IDS-системах. Встречаются на рынке и вендоры, позиционирующие IDS или СОА как универсальное решение проблемы. У субъектов КИИ было много вопросов было относительно функционала и требований к SIEM-системам, которые многие компкании считали чуть ли не единственным инструментом, необходимым для создания центра ГосСОПКА.
Сейчас, с появлением документа «Требования к средствам, предназначенным для обнаружения, предупреждения и ликвидации последствий компьютерных атак и реагирования на компьютерные инциденты» появляется первая ясность в отношении фактических требований регулятора к инструментам центра.
В документе обозначены пять основных подсистем центра ГосСОПКА:
Попробуем пройтись по каждому из пунктов последовательно. Сразу оговоримся, что вопросы «православия» продукта и необходимости импортозамещения мы здесь не рассматриваем, речь пойдет исключительно о технических аспектах.
На наш взгляд, данный пункт является одним из наиболее важных с точки зрения урегулирования споров о средствах, которые можно использовать, поскольку дискуссии «а нужен ли SIEM, или достаточно просто подсистемы СОА» ведутся постоянно и не утихают.
Давайте же подробнее вчитаемся в документ:
В первую очередь речь идет о средстве, осуществляющем сбор событий информационной безопасности. Не инцидентов (итогов работы средств защиты), не сырого трафика или его копии, а именно событий. Это дает нам достаточно прозрачный намек на то, что необходим функционал обработки журналов.
В примечании к этому пункту еще и приведен достаточно детальный и широкий список потенциальных источников, которые должны эти события отдавать. В перечень попали не только классические средства защиты (межсетевые экраны, СОА, антивирусы), но и инфраструктурные источники (сетевое оборудование и операционные системы), а также прикладные системы управления сетевым оборудованиям, системами мониторинга качества обслуживания и т.д.
Все это, а также упоминаемые в функциональных требованиях слова «корреляция и аггрегация событий», на наш взгляд, достаточно точно определяет целевую технологию пункта как платформу SIEM.
Это достаточно полно следует вышедшим ранее методическим рекомендациям, ведь для того, чтобы в полной мере выявлять компьютерные инциденты категорий «несанкционированный доступ», «подбор пароля» и «ВПО», одного активного средства защиты будет недостаточно.
Любая ли платформа, позиционируемая на рынке как SIEM, будет одинаково подходящей? На наш взгляд, нет, так как в тексте обозначены еще, как минимум, два достаточно важных требования:
Интегрально эти требования демонстрируют очень серьезное отношение регулятора к функционалу системы обнаружения. На мой взгляд, они косвенно дают понять, что формальное исполнение исполнение методических рекомендаций (например, «инциденты ВПО можно ловить по сетевому трафику, антивирус нам не нужен�� или «нам достаточно подключить всего два источника для соответствия требованиям») вряд ли будут иметь право на существование. Потребуется серьезная проработка модели угроз и работа по настройке сценариев мониторинга.
Следующий раздел — средства предупреждения — значительно ближе и понятнее для безопасника и формулировками, и подходами. На средства предупреждения возлагаются следующие функции:
Описанный перечень функций чаще всего реализуется программными продуктами класса Vulnerability Scanner или сканеры защищенности. Казалось бы, неочевидное название «система предупреждения» несет в себе очень правильную логику: невозможно предупредить потенциальный вектор развития атаки и выявить слабые точки инфраструктуры, если ты не владеешь полной информацией об ее состоянии, используемых узлах, программных или процессных уязвимостях своих активов.
Задача управления активами и уязвимостями, при всей кажущейся простоте, таит в себе огромное количество подводных камней. Но обсуждение этих деталей не является частью текущего материала и, возможно, появится в наших дальнейших статьях. Хочется лишь отметить, что практически все компании оснащены средствами, требуемыми для решения задачи, поскольку схожие требования уже фигурировали и в разных распоряжениях и приказах ФСТЭК, и даже в законе о персональных данных. Ключевая задача – «оживить» существующее средство и запустить процессы в реальности, а не на бумаге.
Здесь и название средства, и требования к нему получили достаточно неожиданную интерпретацию. В качестве средства ликвидации мы решение, по функциональным задачам близкое к к платформе управления инцидентами, которая в ИТ-мире носит название service desk, а в ИБ горделиво именуется Incident Response Platform (правда у IRP есть и специализированный функционал). По сути, основные задачи подсистемы — это:
Исходя из этого, выстраивается и соответствие функционала названию системы. Ликвидации инцидента в первую очередь требует взаимодействия разных подразделений компании, и управление процессом ликвидации, контроль ее сроков и полноты в данном случае выходит на первый план. Поэтому центр ГосСОПКА, как ответственный за данный процесс, должен иметь соответствующий инструментарий.
Выбор решений и технологий, созданных специально для задач ИБ, на рынке еще весьма ограничен. Но в документе нет прямых ограничений на использование для этих целей общей IT системы (в стандартном или индивидуальном исполнении) с некоторыми доработками под задачи ИБ. Обычно системы service desk представляют собой хорошо кастомизируемый конструктор, поэтому доработка не должна составить труда.
Функционал и задачи подсистемы ППКА в первую очередь направлены на анализ сетевого трафика, причем как в real-time режиме (с целью выявления атак или попыток несанкционированного доступа к сетевому оборудованию), так и для записи и хранения сетевого трафика с целью его дальнейшего использования в ретроспективном анализе событий или расследовании инцидента. Данные требования не являются принципиально новыми. Задача записи сетевого трафика ставилась перед всеми владельцами государственных информационных систем еще с 2010 года в рамках совместного приказа ФСТЭК и ФСБ. Эти требования могут быть неожиданными для коммерческих компаний, но фактически их реализация также не несет особых сложностей.
Требования к подсистемам обмена и криптографической защите каналов связи также достаточно привычны и, наверное, не требуют дополнительных пояснений.
В качестве короткого резюме – выход данного документа расставил очень много точек над I в отношении инструментов и технологий, которыми необходимо оснащать центр ГосСОПКА. Теперь у каждого заказчика есть формальный список требований, который пригодится как для сравнения вендоров, так и для принятия решения об покупке/замене технологии. А появление ясности в таких вопросах всегда положительно влияет на эффективность и скорость шагов, предпринимаемых конкретными субъектами для подключения, равно как и на общую защищенность критических информационных инфраструктур.
Достаточно долгое время основным документом, определяющим принципы функционирования центров ГосСОПКА и их взаимодействия с вышестоящим центром, были «Методические рекомендации по созданию и эксплуатации центров ГосСОПКА», разработанные ФСБ. Мы ранее делали обзор данного документа и отмечали, что основным фокусом его внимания было построение процессов по управлению инцидентами и контролю защищенности субъектов ГосСОПКА. Но в то же время этот подход оставлял достаточно большое поле для различного толкования того, какой объем задач должен решать центр ГосСОПКА и какие именно инструменты для этого требуются. Недавно вышли «Требования к средствам, предназначенным для обнаружения, предупреждения и ликвидации последствий компьютерных атак и реагирования на компьютерные инциденты». Попробуем разобраться, чего же ждет регулятор от компаний, строящих у себя центры ГосСОПКА, и исследовать этот вопрос.
Иерархия взаимодействия центров ГосСОПКА
Известны попытки построения центров ГосСОПКА исключительно на IDS-системах. Встречаются на рынке и вендоры, позиционирующие IDS или СОА как универсальное решение проблемы. У субъектов КИИ было много вопросов было относительно функционала и требований к SIEM-системам, которые многие компкании считали чуть ли не единственным инструментом, необходимым для создания центра ГосСОПКА.
Сейчас, с появлением документа «Требования к средствам, предназначенным для обнаружения, предупреждения и ликвидации последствий компьютерных атак и реагирования на компьютерные инциденты» появляется первая ясность в отношении фактических требований регулятора к инструментам центра.
В документе обозначены пять основных подсистем центра ГосСОПКА:
- Средства обнаружения
- Средства предупреждения
- Средства ликвидации
- Средства расшифровки (ППКА)
- Средства обмена информацией
- Средства криптографической защиты каналов связи
Попробуем пройтись по каждому из пунктов последовательно. Сразу оговоримся, что вопросы «православия» продукта и необходимости импортозамещения мы здесь не рассматриваем, речь пойдет исключительно о технических аспектах.
Средства обнаружения, но не СОА. Четыре буквы
На наш взгляд, данный пункт является одним из наиболее важных с точки зрения урегулирования споров о средствах, которые можно использовать, поскольку дискуссии «а нужен ли SIEM, или достаточно просто подсистемы СОА» ведутся постоянно и не утихают.
Давайте же подробнее вчитаемся в документ:
В первую очередь речь идет о средстве, осуществляющем сбор событий информационной безопасности. Не инцидентов (итогов работы средств защиты), не сырого трафика или его копии, а именно событий. Это дает нам достаточно прозрачный намек на то, что необходим функционал обработки журналов.
В примечании к этому пункту еще и приведен достаточно детальный и широкий список потенциальных источников, которые должны эти события отдавать. В перечень попали не только классические средства защиты (межсетевые экраны, СОА, антивирусы), но и инфраструктурные источники (сетевое оборудование и операционные системы), а также прикладные системы управления сетевым оборудованиям, системами мониторинга качества обслуживания и т.д.
Все это, а также упоминаемые в функциональных требованиях слова «корреляция и аггрегация событий», на наш взгляд, достаточно точно определяет целевую технологию пункта как платформу SIEM.
Это достаточно полно следует вышедшим ранее методическим рекомендациям, ведь для того, чтобы в полной мере выявлять компьютерные инциденты категорий «несанкционированный доступ», «подбор пароля» и «ВПО», одного активного средства защиты будет недостаточно.
Любая ли платформа, позиционируемая на рынке как SIEM, будет одинаково подходящей? На наш взгляд, нет, так как в тексте обозначены еще, как минимум, два достаточно важных требования:
- Система обнаружения должна не только коррелировать и выявлять инциденты, но и сохранять итоги их обработки и «информацию об событиях ИБ, в том числе в исходном виде». Учитывая обозначенный выше список источников, а еще и рекомендуемую глубину хранения (не менее 6 месяцев), речь идет о полноценной платформе с расширенным функционалом Log Management и готовностью обрабатывать очень существенные потоки событий. Это достаточно сильно сокращает список потенциальных вариантов.
- Система обнаружения должна иметь «встроенную поддержку различных источников событий ИБ и возможность разработки дополнительных модулей, обеспечивающих получение информации от новых источников событий ИБ», то есть возможность оперативной доработки списка и состава подключаемых источников. Это накладывает требования по наличию открытого API для разработки таких способов подключения (в SIEM-сленге – коннекторов) либо возможности оперативно получить такую доработку от вендора.
Интегрально эти требования демонстрируют очень серьезное отношение регулятора к функционалу системы обнаружения. На мой взгляд, они косвенно дают понять, что формальное исполнение исполнение методических рекомендаций (например, «инциденты ВПО можно ловить по сетевому трафику, антивирус нам не нужен�� или «нам достаточно подключить всего два источника для соответствия требованиям») вряд ли будут иметь право на существование. Потребуется серьезная проработка модели угроз и работа по настройке сценариев мониторинга.
Предупреждай или инвентаризируй это
Следующий раздел — средства предупреждения — значительно ближе и понятнее для безопасника и формулировками, и подходами. На средства предупреждения возлагаются следующие функции:
- Инвентаризация активов инфраструктуры с возможностью хранения и дополнения информации.
- Сбор и оценка информации об уязвимостях информационных ресурсов.
- Сбор и оценка информации о недостатках (в нашем прочтении – ошибках конфигурирования) информационных ресурсов.
Описанный перечень функций чаще всего реализуется программными продуктами класса Vulnerability Scanner или сканеры защищенности. Казалось бы, неочевидное название «система предупреждения» несет в себе очень правильную логику: невозможно предупредить потенциальный вектор развития атаки и выявить слабые точки инфраструктуры, если ты не владеешь полной информацией об ее состоянии, используемых узлах, программных или процессных уязвимостях своих активов.
Задача управления активами и уязвимостями, при всей кажущейся простоте, таит в себе огромное количество подводных камней. Но обсуждение этих деталей не является частью текущего материала и, возможно, появится в наших дальнейших статьях. Хочется лишь отметить, что практически все компании оснащены средствами, требуемыми для решения задачи, поскольку схожие требования уже фигурировали и в разных распоряжениях и приказах ФСТЭК, и даже в законе о персональных данных. Ключевая задача – «оживить» существующее средство и запустить процессы в реальности, а не на бумаге.
Ликвидация как совместная работа по устранению
Здесь и название средства, и требования к нему получили достаточно неожиданную интерпретацию. В качестве средства ликвидации мы решение, по функциональным задачам близкое к к платформе управления инцидентами, которая в ИТ-мире носит название service desk, а в ИБ горделиво именуется Incident Response Platform (правда у IRP есть и специализированный функционал). По сути, основные задачи подсистемы — это:
- Регистрация инцидентов с возможностью редактирования и дополнения карточки инцидента.
- Возможность управления его жизненным циклом с переводом инцидента между ответственными и подразделениями.
- Возможность сбора итоговой карточки инцидента согласно форматам, утвержденным в НКЦКИ.
Исходя из этого, выстраивается и соответствие функционала названию системы. Ликвидации инцидента в первую очередь требует взаимодействия разных подразделений компании, и управление процессом ликвидации, контроль ее сроков и полноты в данном случае выходит на первый план. Поэтому центр ГосСОПКА, как ответственный за данный процесс, должен иметь соответствующий инструментарий.
Выбор решений и технологий, созданных специально для задач ИБ, на рынке еще весьма ограничен. Но в документе нет прямых ограничений на использование для этих целей общей IT системы (в стандартном или индивидуальном исполнении) с некоторыми доработками под задачи ИБ. Обычно системы service desk представляют собой хорошо кастомизируемый конструктор, поэтому доработка не должна составить труда.
Прочие средства центра ГосСОПКА
Функционал и задачи подсистемы ППКА в первую очередь направлены на анализ сетевого трафика, причем как в real-time режиме (с целью выявления атак или попыток несанкционированного доступа к сетевому оборудованию), так и для записи и хранения сетевого трафика с целью его дальнейшего использования в ретроспективном анализе событий или расследовании инцидента. Данные требования не являются принципиально новыми. Задача записи сетевого трафика ставилась перед всеми владельцами государственных информационных систем еще с 2010 года в рамках совместного приказа ФСТЭК и ФСБ. Эти требования могут быть неожиданными для коммерческих компаний, но фактически их реализация также не несет особых сложностей.
Требования к подсистемам обмена и криптографической защите каналов связи также достаточно привычны и, наверное, не требуют дополнительных пояснений.
В качестве короткого резюме – выход данного документа расставил очень много точек над I в отношении инструментов и технологий, которыми необходимо оснащать центр ГосСОПКА. Теперь у каждого заказчика есть формальный список требований, который пригодится как для сравнения вендоров, так и для принятия решения об покупке/замене технологии. А появление ясности в таких вопросах всегда положительно влияет на эффективность и скорость шагов, предпринимаемых конкретными субъектами для подключения, равно как и на общую защищенность критических информационных инфраструктур.
