Методические рекомендации по созданию центров ГосСОПКИ (часть 3)

Продолжим рассмотрение функций центров ГосСОПКИ согласно методических рекомендаций НКЦКИ. На очереди у нас этап анализа данных о событиях безопасности, целью которого является регистрация инцидентов. Но тут у меня возник еще один вопрос. Ведь есть еще одна функция - прием сообщений о возможных инцидентах от персонала и пользователей информационных ресурсов. И в рамках нее тоже говорится о приеме сообщений об инцидентах. Некоторая путаница возникает. На самом деле на данном этапе речь идет о SIEM, которые в автоматизированном режиме должны собирать события безопасности. Правда, написано все общими словами. Про обогащение событий с помощью Threat Intelligence, про приоритезацию и классификацию событий и другие важные аспекты работы SIEM документ не упоминает.

Следующая функция называется "Регистрация инцидентов" и у меня вновь появляется вопрос. А предыдущие две функции "анализ событий безопасности" и "прием сообщений об инцидентах" для чего? Ну да ладно. Не так уж это и важно. Функция опирается на необходимость вести карточки инцидентов, которые рассылаются по центрам ГосСОПКИ. Это предполагает унифицированный формат ведения карточек и обмена ими. Какой? STIX, TAXII, CyBOX?.. Вопросы стандартизации, к сожалению, в документе не учтены совсем и похоже авторы просто пока не знают, что брать за основу. Та же проблема и у FinCERT, который рассылает свои бюллетени в PDF/Word и которые нельзя в автоматическом режиме подцепить к SIEM/IDS/МСЭ и другим средствам защиты. На мой взгляд тут очень важно уже сейчас определяться со стандартами обмена информацией, чтобы не получилась ситуация, когда ведомственные и корпоративные центры ГосСОПКИ созданы и начинают функционировать, а обмениваться данными между собой не могут, так как используют разные форматы карточек инцидентов и разные протоколы для их обмена. Из стандартов методичка упоминает только стандарт TLP для "раскраски" информации об инцидентах, означающую круг лиц, которым эту информацию можно рассылать.

Документ ни слова не говорит о том, сколько хранятся карточки инцидентов? 3 года, как и уязвимости? А вот трафик, в котором была обнаружена атака, а также все события средств защиты и средств ГосСОПКА, включая и прикладные логи, должны храниться не менее 6 месяцев. Я надеюсь трафик DDoS хранить не придется, а то накладно будет.

По функциям "реагирование на инциденты и ликвидация последствий", "установление причин инцидентов" и "анализ результатов устранения последствий инцидентов" сказать особо нечего - все по делу. Интересно, что в функции "установление причин инцидентов" не говорится об атрибуции нарушителей. Задача эта непростая и хорошо, что ее не навесили на владельцев центром ГосСОПКИ. Не каждый день нарушитель подставляются так, чтобы их можно было идентифицировать (как в кейсе с информационной атакой на Infowatch).

Технические средств для ГосСОПКИ совпадают с перечнем техсредств, необходимых для оказания услуг по мониторингу ИБ ФСТЭК. Первоначально второй перечень был больше, но после последней итерации его сократиил и, о, чудо, он случайно совпал с вариантом ФСБ :-) Техсредства должны быть интегрированными между собой и между вышестоящими и нижестоящими центрами ГосСОПКИ. Опять возникает вопрос стандартизации интерфейсов. STIX, TAXII, Cybox?..

В отличие от требований ФСТЭК к лицензиатам SOC, ФСБ не устанавливает требований к защите самих центров ГосСОПКИ, что, на мой взгляд вполне логично. Также не говорится ничего и про сертификацию средств защиты ГосСОПКИ. Исключением является только взаимодействие центров через Интернет, которое должно обеспечиваться только сертифицированными СКЗИ. Но именно взаимодействие центров, а не связь центра с сегментом мониторинга, как у ФСТЭК. ФСТЭК, как мне кажется, сильно перегнула палку в этом вопросе.

В 7-м разделе методички приводится иерархия специалистов центров ГосСОПКИ. Выделяется 3 линии специалистов, реализующих 11 функций, описанных в трех заметках. Это достаточно распространенная схема, принятая в многих SOCах и службах реагирования на инциденты. Например, в Cisco это выглядит так (кстати, на 66 страниц методички нет ни одной картинки - не любят у нас регуляторы визуализацию, ох, не любят):

В заключении перечислю еще несколько вопросов, которые я бы включил в новую версию этой методички:

• Резервирование способов взаимодействия персонала и что они могут стать мишенью сами по себе.
• Регистрация и учет не только информации, получаемой центром ГосСОПКИ через Интернет, но и по телефону. В тех же рекомендациях NIPC или CERT/CC как раз приоритет отдается телефонной связи, как основному каналу взаимодействия при инциденте (так как Интернет-канал может быть под контролем).
• Лаборатория (стенд) по расследованию скомпрометированных/зараженных узлов.
• Взаимодействие с правоохранительными органами (инциденты же могут затрагивать интересы не только ФСБ, но и МВД).
• Доказательная сила собираемых доказательств. Понятно, что для ГосСОПКИ может быть достаточно того, что было собрано в рамках рекомендаций. Но что делать, если пострадавшая сторона захочет обратиться в правоохранительные органы? Допускаю, что именно под расследование будет отдельная методичка; просто включил этот пункт, чтобы не забыть.
• Эскалация инцидентов.
• Особенности сбора доказательств в случае зарубежного инцидента (в рамках ближнего зарубежья, например, в рамках ОДКБ или СНГ, где есть определенное налаженное взаимодействие, или в рамках дальнего зарубежья). Особенно актуальна эта тема для российских компаний и организаций, имеющих зарубежные представительства или дочерние компании.
• Более четкая систематизация действий в рамках инцидента. Не просто 11 функций, а пошаговая процедура (по сути некий аналог workflow). Например, в очень старой методичке SANS по реагированию на инциденты (еще 90-х годов) было прописано 6 процессов, 31 детальная процедура и 97 конкретных действий, которые необходимо было реализовать для управления инцидентами, на что и заточены центры ГосСОПКИ.
• ...

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

В любом случае, разработанный документ получился очень неплохим, если рассматривать его как первую попытку регулятора замахнуться на такую непростую тему, как национальная система обнаружения, предотвращения и ликвидации компьютерных атак. И я бы не стал его пока сравнивать с той же корейской KISA или американской EINSTEIN, которые действуют чenm дольше и немного в иных условиях. Еще бы чуть оперативнее все это выпускать...