Делать ставку исключительно на предотвращение киберинцидентов уже недостаточно. Информационные системы сегодня находятся под угрозой постоянно, и им необходимы непрерывный мониторинг и восстановление. Актуальной темой стало построение центров реагирования на инциденты информационной безопасности — Security Operation Center, или SOC.
SOC — это центр реагирования на критические инциденты информационной безопасности (ИБ), который позволяет осуществлять предотвращение атак и полный мониторинг на всех уровнях ИТ: сетевых пакетов, сетевых потоков, активности операционной системы, контента, поведения пользователей (рис. 1). Платформа SOC обычно базируется на отказоустойчивой конфигурации SIEM, к которой дополнительно подключены источники данных об актуальных угрозах информационной безопасности (не вызывающих доверия IP, URL, бот-сетях), получаемые от ведущих лабораторий, которые занимаются обнаружением атак и противодействием киберпреступности. Это даёт возможность агрегировать информацию об угрозах, выявлять больше инцидентов и обнаруживать атаки нулевого дня (zero day) в кратчайшие сроки.Система визуализации позволяет выводить операционную и сводную информацию заинтересованным лицам.
Цели SOC определяются в соответствии с бизнес-целями организации и должны быть зафиксированы документально. Можно использовать успешно зарекомендовавшую себя модель PDCA (Plan Do Check Act) (цикл Деминга-Шухарта). Она используется Международной организацией по стандартизации (ISO) как основа для формирования рекомендаций по различным направлениям обеспечения безопасности, в частности, в области управления инцидентами в стандарте ISO/ IEC 27035:2011 Information technology — Security techniques — Information security incident management. Согласно PDCA, деятельность SOC можно разделить на несколько процессов.
PLAN: планирование и подготовка деятельности:
• разработка политик и процедур;
• доработка существующих политик и процедур безопасности и управления рисками для обеспечения поддержки деятельности SOC;
• создание и обеспечение деятельности SOC как организационной единицы;
• повышение квалификации сотрудников SOC и осведомлённости персонала организации по вопросам деятельности SOC;
• обеспечение периодического тестирования функций SOC;
DO: использование SOC:
• обнаружение и оповещение о возникших событиях ИБ;
• сбор информации о произошедших событиях ИБ для выявления инцидентов ИБ;
• реагирование на инциденты ИБ;
• регистрация свидетельств инцидента ИБ для последующего анализа;
• устранение выявленных причин возникновения инцидента ИБ;
CHECK-анализ:
• правовая экспертиза инцидента ИБ;
• анализ инцидента и извлечение уроков;
• определение необходимых улучшений системы безопасности;
• определение необходимых улучшений деятельности SOC, в том числе на основе сформированных ключевых индикаторов эффективности;
ACT: корректирующие воздействия для устранения выявленных несоответствий:
• корректировка результатов анализа рисков безопасности и анализа менеджмента в организации;
• пересмотр документации и повышение эффективности программно-технических средств SOC;
• реализация улучшений в области безопасности, включая внедрение новых и/или обновлённых защитных мер.
Реалии современного информационного мира предъявляют к инструментарию SOC дополнительные требования. Важнейшее из них — это инфраструктура больших данных (big data). Объём информации, генерируемой всеми системами компании, уже давно может перешагивать терабайты данных, представляя собой плохо структурированную разрозненную массу. Сейчас недостаточно просто вести мониторинг событий — всё больше говорится о создании адаптивной архитектуры безопасности для защиты от целенаправленных атак. Аналитики исследовательской и консалтинговой компании Gartner рекомендуют больше инвестировать в системы обнаружения и быстрого реагирования, чем в защиту; отдавать предпочтения производителям, которые предлагают контекстно-ориентированные платформы для сетевой безопасности, безопасности рабочих станций и приложений, а также интегрированный подход к анализу, предотвращению, обнаружению и реагированию на атаки. До обнаружения инцидента трудно предсказать, какие данные понадобятся для его расследования. Важно собрать, проанализировать и сохранить огромное количество разнородной и, казалось бы, несвязанной информации. Таким образом, технический инструментарий SOC должен быть способен анализировать большие данные, превращаясь в единый инструмент, который объединяет все технологии и позволяет выявлять атаки или злонамеренную деятельность по косвенным признакам, собранным по крупицам с различного оборудования и информационных систем. Только при тесном взаимодействии всех трёх составляющих компонентов SOC (люди, технологии и процессы) возможно в кратчайшие сроки выявить и нейтрализовать угрозу. Так, SIEM выявляет инциденты ИБ из миллионов событий с сотен и тысяч устройств и систем. Сведения об этом автоматически дополняются связанной информацией, позволяющей аналитику экономить время на её сбор, определение контекста и установление факта нарушения.
Правильно выстроенный порядок работы даёт возможность определить взаимосвязь нескольких инцидентов, оперативно отображая более полную картину происходящего. Предоставленные аналитику
полномочия и заранее утверждённые сценарии действий позволяют в кратчайшие сроки противодействовать угрозе и организовать дальнейшее расследование.
Построение SOC — непростая комплексная задача. Его невозможно просто купить, его нужно органично встроить в уже работающую экосистему бизнеса, не навредив основным процессам
На начальной стадии эволюции SOC служба ИБ покупает и внедряет слабо интегрированную в ИТ-инфраструктуру SIEM-систему. При этом анализ собираемой информации и выявление нарушений ИБ осуществляются бессистемно. Впоследствии сбор и анализ становятся более формализованными, появляется дополнительный инструментарий аудита, устанавливаются процессы выявления, реагирования и предупреждения появления инцидентов. По мере дальнейшего развития применяется более широкий спектр средств автоматизации, накапливаются экспертный опыт и компетенции, появляется возможность контроля метрик эффективности деятельности SOC и разработки соглашения о качестве обслуживания (рис. 2). Порядок создания SOC начинается с анализа существующей ИТ-инфраструктуры и документации, изучения бизнес-процессов организации, а также определения активов, их уязвимостей и связанных с ними угроз. При необходимости адаптируется или создаётся политика информационной безопасности, частные политики и процедуры, определяющие функции SOC. Качественное проектирование является основой успешного внедрения технических средств в существующую инфраструктуру организации. Особо важную роль играет корректность интеграции внутренних систем SOC между собой и с внешними информационными системами. Одновременно с внедрением, как правило, проводится обучение сотрудников, т.к. используемые в SOC технические средства (такие как SIEM, сканеры уязвимостей, GRC и др.) достаточно сложны, и опыт работы с ними есть далеко не у всех специалистов. При обучении нужно уделить внимание вопросу выполнения разработанных инструкций и процедур.
Построение SOC — непростая комплексная задача. Его невозможно просто купить, его нужно органично встроить в уже работающую экосистему бизнеса, не навредив основным процессам. Можно привести множество факторов, без учёта которых легко потерпеть неудачу. Например, это низкий уровень зрелости персонала, когда люди просто не готовы к работе с такой системой ни ментально, ни технически. Сотрудники не всегда следуют лучшим практикам: специалист SOC может не инициировать разбор инцидента, если результат негативно повлияет на его друга, или просто потому, что у него на это нет времени. Очень важно, чтобы команда SOC была технически грамотной. В числе проблем можно назвать отсутствие ресурсов для выполнения работ, а также установленных целей или приоритетов. Проблемой может стать как излишняя концентрация на технологиях в ущерб процессам и людям, так и отсутствие инфраструктуры безопасности. Как говорится, современные технологии в руках профана — груда металлолома. То же самое происходит, когда квалифицированные ИТ-специалисты пытаются что-то сделать с помощью «молотка и зубила». Если же не выстроены процессы, то эксперты с передовыми технологиями могут
только всё запутать, за что скажет спасибо потенциальный взломщик.
Очень важно взаимодействие SOC с другими участниками процесса управления ИБ, включая внутренние подразделения (ИТ, HR). В SOC предусмотрены шесть этапов принятия ответных мер при возникновении нарушений (рис. 3).
Этап 1
ПОДГОТОВКА
• привлечение опытных дипломированных специалистов;
• разработка и оформление плана обеспечения ИБ;
• разработка договоров SLA с клиентами и организациями-партнёрами;
• приобретение необходимых инструментов;
• внедрение процедур обеспечения ИБ;
• обучение персонала SOC работе с инструментами и процедурами;
• регулярная проверка непрерывности эксплуатации;
• наличие постоянно действующих договоров о сопровождении с производителями/поставщиками;
• экспертная оценка и количественное измерение степени улучшения процесса.
Этап 2
ИДЕНТИФИКАЦИЯ
Чтобы выявлять инциденты в сфере ИБ до того, как они затронут сети ваших клиентов, используйте аналитические инструменты и данные мониторинга, получаемые с помощью NetFlow, опросов по протоколу SNMP, сообщений SNMP-trap и syslog-сообщений.
Этап 3
КЛАССИФИКАЦИЯ
После того, как атака идентифицирована, необходимо оценить степень её серьезности и масштаб — затрагивает ли она одного либо нескольких клиентов или всю инфраструктуру.
Этап 4
ОТСЛЕЖИВАНИЕ ИСТОЧНИКА
У атаки есть жертва и источник. После того, как угроза классифицирована, ваши специалисты должны найти точку её проникновения: это может быть сеть организации-партнёра, сервер в сети более высокого или низкого уровня, взломанное сетевое устройство в центре обработки данных.
Этап 5
ОТВЕТНЫЕ МЕРЫ
Классифицировав атаку и выявив её источник, специалисты SOC применяют инструменты и процедуры подавления. Длятого, чтобы эта работа была успешной, необходима наглядная картина состояния сети и
хорошо прописанные стандартные операционные процедуры. Придерживаясь этих процедур, вы не рискуете усугубить проблему.
Этап 6
АНАЛИЗ
Ваши специалисты по ИБ должны анализировать исходные причины каждого события ИБ и вносить найденные решения в рабочие инструкции по разрешению инцидентов, чтобы использовать их для справки при возникновении очередного нарушения. Даже безупречные процедуры реагирования на инциденты принесут мало пользы, если у ваших специалистов нет опыта их правильного применения или достаточных профессиональных навыков.
В SOC должны существовать процедуры связи с работниками, клиентами и взаимодействующими провайдерами на случай кибератаки. Точная контактная информация поможет пройти шесть этапов реагирования на инцидент, описанных ранее, быстрее и эффективнее. Поэтому необходимо собрать и своевременно обновлять следующие данные:
• важнейшие адреса электронной почты, номера телефонов и пейджеров, URL-адреса web-страниц;
• контактные лица всех взаимосвязанных провайдеров — одного уровня с вашей организацией и более высокого уровня, а также производителей, поставщиков и клиентов;
• контактные лица ваших поставщиков из оперативных групп обеспечения безопасности продуктов и лица, ответственные за принятие ответных мер;
• политики, которые устанавливают уровень поддержки клиентов, порядок классификации и отслеживания источников атак, методы принятия ответных мер (например, будет ли применяться в вашей инфраструктуре сброс пакетов, формирующих атаку).
Итак, стратегию построения SOC в рамках конкретной организации следует выбирать, исходя из таких критериев, как наличие квалифицированных сотрудников, современных технологий и способности правильно выстроить процессы. Самый очевидный вариант — это создание SOC на базе специализированного структурного подразделения, которое будет полностью отвечать за выявление, обработку и оперативное реагирование на возникающие инциденты ИБ. Это позволит обеспечить высокий уровень контроля и управления. Можно также передать часть функционала провайдерам. Согласно Gartner, существует достаточное количество таких специалистов, а к 2020 г. 65% провайдеров управляемых услуг безопасности (managed security service providers, MSSPs) во всём мире будут предоставлять услуги по обнаружению и реагированию (managed detection and response, MDR-услуги) (рис. 4). В России уже имеются коммерческие SOC. Что касается Казахстана, то это вопрос двух–трёх лет. Казахстанские компании опасаются работать с иностранными провайдерами, т.к. не отрегулирован ряд спорных вопросов — например, кто несёт ответственность, если в результате инцидента произойдёт утечка данных. Вспомним, что
несколько лет назад такое уже случилось: процессинговый центр располагался в Америке, а аналитики — в Индии, и даже быстрая реакция аналитиков не помогла избежать компрометации данных, т.е. доступа к защищаемой информации посторонних лиц. После таких примеров заказчики в Казахстане не хотят передавать конфиденциальную информацию о событиях ИБ третьей стороне, находящейся в другой стране. Эту проблему можно преодолеть путем создания казахстанских или ведомственных объединенных SOCов, которым заказчики будут доверять. Вообще внедрение SOC частично решает задачу по выполнению единых требований в области информационно-коммуникационных технологий и обеспечения информационной безопасности (Постановление Правительства Республики Казахстан от 20 декабря 2016 года № 832).
Наша компания работает на рынке информационной безопасности уже девятый год, наблюдая динамику развития систем обеспечения ИБ в организациях различного уровня. Большинство их объе диняет
дефицит квалифицированных кадров. Ещё одна проблема связана с тем, что организация может предлагать зарплату ниже запросов аналитика. В этом случае мы рекомендуем рассмотреть вариант коммерческого SOC, где имеется полный штат необходимых специалистов, а у заказчика есть выбор по глубине аутсорсинга. В дальнейшем организация может обучать и выращивать собственных специалистов, постепенно сокращая присутствие третьей стороны вплоть до построения своего SOC. Компании, которая планирует сразу создавать SOC, понадобятся следующие сотрудники:
1) инженеры мониторинга (три–четыре чел.) — круглосуточная смена специалистов по ИБ, отвечающая за своевременное реагирование на возникший инцидент, его анализ и фильтрацию ложных срабатываний, а также за подготовку аналитической справки по всем типизированным инцидентам;
2) инженеры реагирования (два–три чел.) — технические эксперты по конкретным продуктам и направлениям ИБ, привлекаемые для решения нетиповых инцидентов в рамках области их экспертизы;
3) выделенный аналитик (один чел.) — эксперт в ИБ и работе с SIEM-платформой, владеющий наиболее полной информацией по инфраструктуре и внутренним процессам организации, отвечающий за
актуальность сценариев выявления инцидентов и качество реализуемых ими контролей для обеспечения ИБ клиента;
4) технический сервис-менеджер/бизнес-аналитик (один чел.) — лицо, ответственное за выявление основных рисков ИБ организации и возможных точек их контроля.
Центр реагирования на критические инциденты ИБ может быть собственным или коммерческим. В любом случае, внедряя SOC, организация одновременно реализует часть процессов системы управления ИБ (СУИБ) в соответствии со стандартом ISO 27001 (процесс управления инцидентами ИБ, управление уязвимостями и изменениями, контроль соответствия законодательным и отраслевым требованиям), а также выполняет часть требований стандарта PCI DSS. При условии грамотного использования SOC позволяет существенно повысить эффективность защиты информации. Одновременно в зону ответственности системы возможно добавить мероприятия по обеспечению непрерывности бизнеса, создавая тем самым единую точку контроля и применения с целью всесторонней защиты организации от перебоев деятельности, снижения их вероятности и обеспечения условий для восстановления. Можно пойти ещё дальше и расширить область ответственности SOC, включив смежные сферы, например техническую защиту, обеспечение физической безопасности, консолидирование данных систем видеонаблюдения, контроля систем управления оборудованием (электропитание, вентиляция, средства пожаротушения и мн. др.).
Павел ГЕНИЕВСКИЙ,
исполнительный директор
ТОО «ПАЦИФИКА»
(г. Астана, Казахстан)