Если вы работаете в компании, которая попадает под действие №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 в отношении инструментов и технологий, которыми необходимо оснащать центр ГосСОПКА. Теперь у каждого заказчика есть формальный список требований, который пригодится как для сравнения вендоров, так и для принятия решения об покупке/замене технологии. А появление ясности в таких вопросах всегда положительно влияет на эффективность и скорость шагов, предпринимаемых конкретными субъектами для подключения, равно как и на общую защищенность критических информационных инфраструктур.
