Все заказчики разные. Одни хорошо разбираются в технологиях и точно знают, что им нужно. Другие – просто хотят работать без сбоев и инцидентов, хоть и не понимают, как это реализовать. А кто-то не разбирается в ИБ, но уверен, что точно знает, как выстроить процесс. Если дело доходит до таких сложных задач, как создание или перестройка Security Operations Center (SOC), разница в подходах к ИБ становится очевидной. В этой серии постов мы решили поделиться подборкой самых популярных запросов, с которыми к нам, как к сервис-провайдеру, приходят компании. Мы уже писали о заказчиках, которые действительно хорошо разбираются в IT и точно понимают, чего они хотят от SOC. И о тех, кто не понаслышке знает, что такое SOC, но не так погружен в вопрос, что в итоге приводит к своеобразной постановке задач. В этом посте мы расскажем о компаниях, которые видят основные риски не в киберугрозах, а в проверках и штрафах со стороны регулятора, сорванных сроках, поэтому хотят просто прикрыться фиговым листочком бумажкой.
Очень много запросов со стороны таких заказчиков связано с темой compliance:
«Хочу получать уведомления от вас раньше, чем от НКЦКИ».
«Просто организуйте взаимодействие с ГосСОПКА, у вас же есть лицензия».
«Поставьте железку, чтобы все работало, как сенсор от ФСБ, но для нас».
«Возьмите ответственность за все функции центра ГосСОПКА».
«Обеспечьте compliance по требованиям ЦБ/ФСТЭК/ФСБ (нужное подчеркнуть)».
В целом все они сводятся к трем основным задачам:
Выявление угроз, инцидентов, уязвимостей раньше регулятора.
Формальное закрытие требований при проверке.
Перенос зон ответственности на сервис-провайдера.
Давайте разбираться с каждой по-отдельности.
Выявление угроз, инцидентов, уязвимостей раньше регулятора
Что плохого в этом запросе? Вроде, все логично: желание максимально оперативно получать важную информацию. Но обычно в этом случае клиенту не нужны полноценный мониторинг, реагирование на инциденты, процесс выявления, приоритизации и ликвидации уязвимостей в инфраструктуре. Он хочет точечные оповещения по индикаторам полностью аналогичным сенсорам СОПКА, а также ряд мер, направленных на очистку периметра от критических уязвимостей накануне проверки регулятором. Реальная безопасность в этом варианте мало волнует.
Но обычно за таким запросом стоит неготовность наладить на своей стороне регулярную операционную работу с инцидентами и уязвимостями и выстроить функциональные процессы ИБ. Тут важно отметить, что сенсор СОПКА работает по закрытой базе НКЦКИ, агрегируемой и приоритизируемой по различным источникам, но это не единственный способ зафиксировать компрометацию ИТ-инфраструктуры компании со стороны НКЦКИ. Сервис-провайдер работает значительно шире, видит больше, копает глубже, но без обратной связи от заказчика не понимает контекст и не может самостоятельно принять решение (в 99% случаев) – является ли инцидентом та активность, которую он фиксирует или нет. В итоге количество оповещений от сервис-провайдера составляет десятки в день (а не раз в месяц, как ожидает заказчик), и меньше их не становится. В этот момент специалистам заказчика надо выбрать: либо начинать работать в тандеме с сервис-провайдером, либо копить оповещения. Во втором случае «письмо счастья» от регулятора обязательно придет и нужно будет писать объяснительные. К счастью, последнее время на фоне роста киберинцидентов многие компании по-другому стали оценивать роль сервис-провайдера, поэтому формальное выявление угроз встречается все реже.
Формальное закрытие требований при проверке
Регуляторная нагрузка воспринимается частью компаний как формальная мера и, по их мнению, никак не связана с реальной кибербезопасностью. Но на самом деле это не так. Регистрация событий ИБ – полезное требование, особенно, если после регистрации происходит подтверждение факта инцидента, локализация, ликвидация последствий и восстановление – то есть полный цикл реагирования. В случае формального подхода, перечень оповещений от сервис-провайдера или собственного SIEM/IRP выглядит как архив Ленинской библиотеки, который просто предъявляется регулятору при проверке.
Но пропущенный инцидент все равно остается в зоне ответственности компании, которой принадлежит инфраструктура: КИИ, ПДн, ГИС и прочее. И это плавно переводит нас к третьему типу запросов.
Перенос зон ответственности на сервис-провайдера
Сервис-провайдер по ИБ-мониторингу не несет ответственность перед регулятором за инцидент, произошедший у заказчика (за то, что происходит на инфраструктуре отвечает ее владелец). Конечно, если провайдер сам стал причиной инцидента – это другой вопрос (но, надеюсь, такие случаи происходят крайне редко). Поэтому подход по переносу определенных зон ответственности должен быть максимально разумен и осознан.
Разберем несколько примеров:
1. Взаимодействие с ГосСОПКА без мониторинга инцидентов ИБ. Многие клиенты под фразой «подключиться к ГосСОПКА» понимают установку криптошлюза на их стороне и перенос ответственности за взаимодействие с вышестоящим или главным центром ГосСОПКА на сервис-провайдера. Но большинство сервис-провайдеров готовы брать на себя эту функцию только по тем инцидентам, которые они выявили самостоятельно или в разборе которых хотя бы принимали участие.
Но на указанный выше аргумент часть компаний говорит примерно следующее: «поставьте мне сенсор на сеть и по нему выявляйте инциденты, о которых и будете оповещать центры ГосСОПКА». Такой подход практикуется некоторыми сервис-провайдерами, но, положа руку на сердце, является неполным. Сенсоры – это важный элемент системы мониторинга, но они не смогут заменить (пока, по крайней мере) SIEM, EDR. Причина в отсутствии хостовой части мониторинга, ограниченности сигнатур сенсоров и их направленности (разные вендоры позиционируют свои сенсоры по-разному – кто-то делает упор на выявление зараженных хостов внутри, кто-то – на выявление горизонтального распространения злоумышленника по сети).
2. Мониторинг инцидентов ИБ и взаимодействие с ГосСОПКА. Классический подход большинства сервис-провайдеров, который продиктован относительной легкостью отчуждения функции выявления угроз экспертам в этой области. Такой вариант универсален и подходит для большинства компаний.
Но у него тоже есть нюансы. Первый – это бесполезность мониторинга без дальнейшего реагирования на инциденты со стороны клиента (об этом много говорилось выше). Если компания не готова принимать активное участие в реагировании, то сервис-провайдер просто не понимает, что из подозрительных событий ИБ является ложноположительным срабатыванием, а что – настоящим инцидентом. Итог: лавина подозрений на инцидент в сторону заказчика, «замыливание» взгляда и потеря какой-либо целесообразности сервиса.
Другой вариант, когда штатная ИБ-служба реагирует на сообщение провайдера, но делает это в режиме 5Х8. Это снижает эффективность мониторинга. У нас на практике был такой пример. Проводили пилот у крупного заказчика из транспортной отрасли. В пятницу в районе обеда выявили потенциальную компрометацию инфраструктуры по косвенным признакам (правила категории Threat Hunting). Оповестили клиента, но услышали в ответ: «Коллеги, успеем собрать дополнительную информацию и провести работы по реагированию на инцидент за 40 минут? Если нет – давайте уже в понедельник».
Правда, текущее законодательство обязует владельцев значимых объектов КИИ оповещать вышестоящий центр ГосСОПКА в течение 3 часов с момента выявления инцидента. Для коммерческих компаний игнорирование инцидентов может привести к финансовым и репутационным потерям. Все больше менеджеров это понимают, и многие службы ИБ начинают действовать проактивно.
3. Мониторинг, взаимодействие и реагирование на киберинциденты. Комплексная передача ответственности за весь жизненный цикл выявления и реагирования на инциденты ИБ – пока не самая распространенная практика, но постепенно она начинает набирать популярность. Краеугольным камнем здесь является вопрос контроля и принятия решения.
Не бывает ситуации, при которой заказчик может «самоустраниться» - он должен курировать процесс реагирования и быть точкой принятия решения. Без контроля со стороны заказчика сервис может стать неуправляемым, так как провайдер не погружен на 100% в бизнес-процессы и структуру защищаемой компании (если, конечно, это не аутстафф). Что если из-за подозрительной активности заблокируется компьютер топ-менеджера или какой-то процесс на сервере, который нельзя прырывать.
Слепое доверие сервис-провайдеру опасно. Необходим прозрачный контроль SLA, состава работ, скоупа мониторинга и обслуживания. Не менее важным вопросом является собственная защита сервис-провайдера, ведь у него есть доступ к основным инфраструктурным элементам компании. А последнее время атаки типа supply-chain происходят все чаще. Поэтому предъявление требований по безопасности к подрядчику является важным пунктом договора услуг.
Мы несколько раз сталкивались с гибридным запросом, когда эксплуатация средств защиты и элементов инфраструктуры остается на стороне клиента, а для функций оперативного круглосуточного реагирования создаются плэйбуки и учетные записи на СЗИ, сетевом оборудовании и контроллерах доменов заказчика. В этом случае, после согласования активных действий (точнее противодействий) по локализации потенциального инцидента, сервис-провайдер осуществляет набор операций (например, производит выведение потенциально скомпрометированного хоста в отдельный VLAN). Конечно, оперативное реагирование удобнее делать с помощью агентов EDR на хостах или коннекторов SOAR-системы, но, в силу нехватки бюджетов, описанный выше способ является оптимальным промежуточным вариантом до момента внедрения специализированных средств.
Конечно, выполнять требования регуляторов непросто. К тому же не все их инструкции очевидны и понятны, аместами даже противоречивы. Вспомнить хотя бы требования к учету СКЗИ. Но часто этот страх перед compliance заменяет реальную киберзащиту организации. Однако все больше компаний понимают, бумажная безопасность не заменит практическую. Согласитесь, у регулятора нет задачи написать пошаговые инструкции и детализировать до каждого винтика универсальные требования, которые подходили бы для каждой компании. Всегда есть свои нюансы и особенности инфраструктуры, бизнес-процессов и т.п. Регуляторы задают вектор безопасности, а ИБ-специалисты должны использовать логику, разум, знания и опыт при реализации этимх мер.
Автор: Алексей Павлов, директор по развитию бизнеса центра противодействия кибератакам Solar JSOC