Rambler's Top100
Реклама
 
Статьи ИКС № 10 2014
Дмитрий КОСТРОВ  07 октября 2014

SOCратите ресурсы на борьбу с угрозами

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

Дмитрий КОСТРОВ, вице-председатель подгруппы LSG TEL APEC Азиатско-Тихоокеанского экономического сотрудничества, ассоциированный репортер ИК 17 (Безопасность) МСЭ-Т, директор департамента ИКТ, NVision GroupКонечно, холдинговые компании, синдикаты или концерны могут создавать собственные (внутрифирменные) подразделения информационной безопасности, оснащать их практически однотипными системами межсетевого экранирования, средствами обнаружения и предотвращения атак (IDPS), системами управления событиями безопасности (SIEM), системами построения виртуальных частных сетей и т.п. Однако если исходить из критерия цена/качество, то для многофилиальных компаний такие разбросанные и однотипные образования достаточно затратны. Полагаю, что наличие дублирующих технических специалистов, дублирующих систем или разнородных систем одного класса (от разных производителей) превращается в непозволительную роскошь.

В 20-м и в самом начале 21-го века считалось, что создание собственного операционного центра безопасности (Security Operational Center, SOC) – это единственно правильное решение. При таком подходе все остальные подразделения компании становятся клиентами SOC (обычно сформированного в виде специального подразделения в рамках службы информационной безопасности). Сейчас позиция меняется.

С другой стороны, наблюдается реинкарнация бизнес-модели предоставления внешних услуг инфобезопасности (Managed Security Service, MSS). В 2000 г. попытка развить на нашем рынке услуги MSS, по опыту автора, не увенчалась успехом. Отечественные предприятия не доверяли «чужому дяде», который должен их защищать, хотя понятие SLA уже существовало, правда, страхования рисков еще не было. Пользователями подобных услуг в подавляющем большинстве становились западные компании.

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

«Классический» SOC собирает и обрабатывает данные из корпоративной сети, систем типа SCADA, EMA и т.п. Данные также могут анализироваться в отраслевых центрах типа CIRT (Computer Incident Response Team) и/или ISAC (Information Sharing and Analysis Center) – центральных депозитариях информации, связанной с информационной безопасностью. Обычно для обеспечения приемлемого уровня безопасности несколько специализированных групп операторов независимо друг от друга собирают и анализируют информацию, относящуюся к разным базам данных различных систем защиты (физической, корпоративной ИС, контроля (датчиков)). При этом изучение существующего ландшафта угроз свидетельствует о необходимости жесткой увязки всех инцидентов, а не только инцидентов информационной безопасности. В противном случае конечное сообщение об атаке может быть выдано намного позже того, как атака успешно совершилась.


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

В качестве форматов взаимодействия подсистем можно использовать клише поддерживаемых МСЭ-Т стандартов обмена информацией о кибербезопасности (CYBEX). Эти клише могут включать структурирование информации о кибербезопасности в целях обмена; идентификацию и обнаружение информации о кибербезопасности и объектов кибербезопасности; заключение соглашения о доверии и политиках между объектами, осуществляющими обмен; запрашивание и предоставление информации о кибербезопасности; гарантирование целостности обмена информацией о кибербезопасности.

Могут применяться следующие шаблоны:

  • описание общеизвестных уязвимостей (Common Vulnerabilities and Exposures, CVE);

  • система оценки общеизвестных уязвимостей (Common Vulnerability Scoring System, CVSS);

  • перечень общеизвестных слабых мест (Common Weakness Enumeration, CWE);

  • система оценки общеизвестных слабых мест (Common Weakness Scoring System, CWSS);

  • открытый язык описания и оценки уязвимостей (Open Vulnerability Assessment Language, OVAL);

  • расширяемый формат описания списка проверки конфигурации (Extensible Configuration Checklist Description Format, XCCDF);

  • перечень общеизвестных платформ (Common Platform Enumeration, CPE);

  • перечень общеизвестных конфигураций (Common Configuration Enumeration, CCE);

  • формат обмена результатами оценки (Assessment Results Format, ARF);

  • описание общих событий (Common Events Enumeration, CEE);

  • формат обмена описаниями инцидентов (Incident Object Description and Exchange Format, IODEF);

  • перечень и классификация общеизвестных схем атак (Common Attack Pattern Enumeration and Classification, CAPEC).

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

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

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

Заметили неточность или опечатку в тексте? Выделите её мышкой и нажмите: Ctrl + Enter. Спасибо!