В последнее время для разных типов центров реагирования на события информационной безопасности используются аббревиатуры, в частности SOC и CERT. Но что в действительности отличает SOC от CERT? По мнению многих, SOC и CERT выполняют одинаковую задачу – обеспечивают какую-либо реакцию на инциденты. О сходствах и различиях этих центров мы расскажем в данной статье.
Введение
В последнее время часто стали использоваться аббревиатуры для разных типов центров реагирования на события информационной безопасности. Они упоминаются как в тематических специализированных докладах на конференциях (например, в рамках Уральского банковского форума в Магнитогорске), так и в маркетинговых материалах интеграторов, которые ответственно заявляют о наличии собственного SOC.
Что же кроется за этими названиями? По мнению многих, SOC и CERT выполняют одинаковую задачу – обеспечивают какую-либо реакцию на инциденты. Но почему сходные действия именуются по-разному? Что отличает SOC от CERT?
SOC: мифы и реальность
SOC — Security Operations Center, или Центр оперативного управления, основными задачами которого являются консолидация событий из множества источников, проведение определенной аналитики и оповещение уполномоченных сотрудников об инцидентах информационной безопасности или иных происшествиях. На основе полученных данных сотрудники центра проводят расследование, принимают меры, чтобы исключить возможность повторения события, минимизируют потери.
Распространено ошибочное мнение, что термин SOC эквивалентен SIEM (Security Information and Event Management) с небольшими дополнениями в виде постоянного штата специалистов, наблюдающих за событиями. Безусловно, SIEM-решение остается одной из основополагающих составляющих центра оперативного управления, но SOC — это совокупность технических и организационных мер, направленных на выявление, анализ и предотвращение инцидентов. Он не может считаться полноценным, если у него нет SLA (Service Level Agreement), подразумевающего гарантированное время реагирования на различные события ИБ.
Зрелость SOС оценивается с помощью методики SOMM (Security Operations Maturity Model), включающей пять основных уровней.
Таблица 1. Уровни SOMM
|
SOMM-уровень |
SOC-описание |
Детализация |
|
Уровень 0 |
Отсутствует |
Ключевые составляющие SOC (мониторинг, документирование, SLA) отсутствуют. |
|
Уровень 1 |
Начальный |
«Реагирование по ситуации» (есть мониторинг, нет документированных процессов). |
|
Уровень 2 |
Базовый |
Выполняются все основные нормативные требования с учетом актуальных бизнес-требований. Большая часть процессов документирована, пересматривается по ситуации. |
|
Уровень 3 |
Надлежащий |
Процессы полностью документированы, регулярно актуализируются с учетом «лучших практик». |
|
Уровень 4 |
Осмысленный |
Проводится регулярная оценка эффективности SOC, производится выстраивание процессов для достижения максимальных ключевых показателей эффективности (KPI) бизнеса. |
|
Уровень 5 |
Максимальный (экстремальный) |
Максимальная конкретизация процессов, есть план дальнейшего развития SOC. |
При создании SOC обычно уходят от чисто технического понимания задачи, включающего только установку и настройку SIEM, а обращают внимание на организационные моменты: документирование наиболее очевидных процессов и формализацию требований на соответствие каким-либо стандартам (как внутренним, так и внешним), составление SLA и другие. Хорошо настроенную и поддерживаемую SIEM-систему (если в службе безопасности существуют регламенты реагирования на инциденты) теоретически можно считать SOC первого уровня. Однако сейчас таких внедрений, работающих в полную силу, в нашей стране сравнительно немного.
Рисунок 1. Основные процессы, необходимые для полноценного SOC
Условиями существования успешного SOC можно считать совокупность следующих систем и нормативных документов: внедренная и настроенная система класса SIEM и Help-Desk для организации назначения задач группе реагирования и контроля выполнения задач; разработанные соглашения SLA; регламенты реагирования на типовые инциденты; метрики эффективности.
На данный момент в России есть несколько организаций, предоставляющих SOC как услугу. Следует отметить, что далеко не все потенциальные клиенты ею пользуются из-за опасений утечки своих данных или событий ИБ, предпочитая строить собственные центры реагирования.
Зона ответственности CERT
Аббревиатура CERT расшифровывается как Computer Emergency Response Team. Иногда она принимает значение Компьютерной команды безопасности по реагированию на инциденты — CSIRT (Computer Security Incident Response Team). Слово «команда» в данном случае часто заменяется словом «центр».
Образно говоря, CERT/CSIRT — это МЧС в цифровом мире, в число основных задач которого входят сбор информации о событиях ИБ, их классификация и нейтрализация. Примерами таких CERT являются соответствующие структуры при Управлении «К» МВД России и ЦИБ ФСБ России, включая созданный при участии ФСБ России сайт gov-cert.ru.
Для каждого CERT очерчивается круг ответственности. Например, обработка только инцидентов, направленных на государственные информационные системы, или тех событий ИБ, которые связаны с финансовой сферой. Также различаются и способы получения данных: прямая связь с общественностью через электронную почту или телефон, автоматизированный сбор информации из открытых источников с помощью специализированных средств, запуск «своих» SOC и подключение к уже существующим.
Чтобы усовершенствовать процессы нейтрализации инцидентов и обнаруженных уязвимостей, объединяются несколько CERT и обработанные результаты анализа одного центра передаются в специализирующийся на данном направлении CERT. Один из результатов работы таких центров — формирование рекомендаций по минимизации риска или регламентов действий при возникновении событий ИБ, которые могут использоваться при обработке аналогичных инцидентов в SOC. Таким образом, зачастую CERT является «вышестоящим» по отношению к SOC, но его наличие вовсе не обязательно.
Что же составляет основу CERT? С технической точки зрения, это в большинстве случаев SOC, но «кадры решают все». Чтобы называться CERT/CSIRT, нужно иметь команду аналитиков, обладающих экспертными знаниями в области обнаружения и нейтрализации событий ИБ, находящихся в сфере интересов данного CERT. Это позволяет вовремя выявлять и нейтрализовать инциденты, составляя базы данных угроз, характерных для направления работы CERT. (Пример: принадлежащий ФСТЭК России БНД УБИ). Помимо этого, специалисты могут принимать участие в процессе ликвидации обнаруженных центром событий ИБ либо посредством оказания консультационной, методической и иной поддержки, либо через передачу данных в соответствующие государственные органы, занимающиеся кибербезопасностью.
CERT — это, скорее, прерогатива очень крупных специализированных компаний, желающих повысить оперативность реагирования на собственные инциденты ИБ и продающих аналитику более мелким организациям, или государственного центра реагирования на угрозы, направленного на их минимизацию в рамках отрасли или направления. Существуют такие международные объединения CERT, как FIRST и Trusted Introducer, официальное включение в которые стало весьма неплохим показателем доверия.
Создание CERT особенно актуально для государственной отрасли или направления, где ущерб от проигнорированной угрозы может оказать сильное негативное влияние. Исключительно для нужд даже крупной компании подобные работы экономического смысла не имеют, требуя больших затрат без последующих свидетельств о возвращении вложений (показатель ROI близок к нулю). Отдельной непростой задачей становится технический запуск SOC, входящего в состав CERT.
Для представителей крупного бизнеса стоимость создания такого центра может превысить уровень дохода от основной деятельности компании. В данном случае лучше обратиться за помощью к интегратору и построить SOC, окупающийся в разумные сроки и имеющий приемлемую стоимость содержания, или отдать его на аутсорсинг, чтобы избавиться от затрат на содержание. Экспертов тоже проще взять на аутсорсинг с целью снижения расходов на персонал. Таким способом можно решить задачу подключения к CERT специализированных организаций, для которых это является основным видом деятельности. При указанном сценарии придется делиться частью собранной вашим SOC информации с центром CERT, но организация получит приемлемый уровень безопасности по доступной цене.
В заключение стоит отметить, что сегодня в России большинство организаций не дозрели даже до внедрения SIEM. По этой причине необходимо заранее получить ответ на вопрос о необходимости системы управления инцидентами, а также собственного или арендованного SOC.
Авторы:
Владислав Ершов, Дмитрий Махаев, эксперты департамента информационной безопасности компании «Ай-Теко»
