Все заказчики разные. Одни хорошо разбираются в технологиях и точно знают, что им нужно. Другие – просто хотят работать без сбоев и инцидентов, хоть и не понимают, как это реализовать. А кто-то не разбирается в ИБ, но уверен, что точно знает, как выстроить процесс. А если дело доходит до таких сложных задач, как создание или перестройка Security Operations Center (SOC), разница в подходах к ИБ становится очевидной. В этой серии постов мы решили поделиться подборкой самых популярных запросов, с которыми к нам, как к сервис-провайдеру, приходят компании и рассказать, почему не все пожелания заказчика нужно и можно реализовывать. С какой бы стороны баррикад вы ни стояли (строитель SOC или заказчик), надеемся, наш опыт будет вам полезен. В заключительном посте мы поговорим о тех, кто мало разбирается в ИБ и плохо понимает свои потребности в киберзащите.
Первые три части можно прочитать тут: раз, два, три.
«Хочу SOC, но не знаю, зачем и готов ли я вообще»
Зачастую, услышав про APT или кибервойска, такие компании обращаются к сервис-провайдеру, чтобы подключиться к ИБ-мониторингу, а некоторые даже просят построить собственный центр противодействия кибератакам. Но часто после аудита их инфраструктуры выясняется, что сеть не поделена на сегменты, а антивирусом покрыты в лучшем случае 30% компьютеров. Иногда отсутствует доменная структура и межсетевые экраны – их заменяет border router. Службы ИБ, которая бы реагировала на выявленные инциденты, тоже нет.
Если подключить такую инфраструктуру к мониторингу, то его эффективность будет крайне низкая. Нет ни нужных источников событий ИБ, на основе которых происходит корреляция, ни штата ИБ-специалистов, способных провести реагирование.
Намного более целесообразным решением в этом случае станет проработка базового уровня защищенности компании, процессов управления уязвимостями и инцидентами ИБ – построение КСОИБ (комплексной системы обеспечения информационной безопасности). Речь здесь идет, например, про такие меры, как сегментация сети, полное покрытие антивирусом, формирование централизованных политик ИБ, контроль удаленного доступа, периметра и выхода в интернет. Все это может дать больший эффект, чем подключение к SOC.
Подход по построению КСОИБ необходимо начинать с постановки целей и задач, построения концепции. Также стоит «на берегу» определиться: есть ли у компании ресурс (в том числе и человеческий), чтобы реализовывать задуманный план и заручится поддержкой руководства, потому что любые реактивные изменения воспринимаются персоналом компании с трудом.
«Защитите только критические объекты, без мониторинга инфраструктуры»
Вполне разумный запрос. Но в этом случае клиент часто говорит не о сегменте с критическими данными и бизнес-процессами (что более логично), а о защите одиночных серверов. У этого подхода есть как положительные, так и отрицательные моменты.
Плюсы:
Защитить только критический сегмент дешевле, чем всю инфраструктуру;
Контроль за реализацией мер, выявлением инцидентов, наличием уязвимостей существенно проще за счет меньшего скоупа и практически идеального порядка;
Данный подход закрывает требования регулятора практически в любой отрасли.
Минусы:
На самом деле он один, но весьма существенный. При наличии точек сопряжения с остальной инфраструктурой (особенно, если их много и они плохо контролируемы), возникает опасность поздно увидеть атаку или инцидент.
Наиболее ярким примером является инфраструктура АСУ ТП промышленных, нефтегазовых или энергетических компаний. Уже мало кто верит в существование мифического зазора между сегментами сети. Запросов на мониторинг технологических сегментов в последние годы становится все больше, но мы всегда настаиваем на комплексном подходе к ИБ. Если сервис-провайдер обнаружит шифровальщик или злоумышленника на машине инженера или оператора АСУ ТП, либо в верхнем (SCADA) и среднем сегменте АСУ (PLC), на реагирование либо не будет времени совсем (и остается достать попкорн и наблюдать), либо его будет катастрофически мало. В этом случае вроде и SOC молодец – выявил атаку, но и злоумышленник достиг своей цели.
Если вы все-таки решили остановиться на защите критического сегмента, стоит немного укрепить тылы. Так на старте лучше уже иметь подготовленную инфраструктуру и процессы: сегментация сети и контроль взаимодействий с критическими сегментами. Идеальным вариантом будет терминальный сервер и межсетевые экраны на границе. А лучше два с разными владельцами: один эксплуатирует ИТ АСУ ТП, второй – корпоративное ИТ, а дополнительные каналы и интерфейсы взаимодействия открывают только синхронные настройки. Помимо этого, должны быть приняты меры для максимального покрытия СЗИ хостов, установлены сетевые сенсоры, система контроля пользователей (PAM), правильно организован удаленный доступа для подрядчиков.
Как видите, данный подход допустим и возможен, но нужно всегда четко осознавать и оценивать риски. Возможно, стоит сначала реализовать мониторинг корпоративной инфраструктуры, окружающей значимые сегменты. Это позволит выявлять злоумышленников на ранней стадии развития атаки и в целом видеть больше нарушений и инцидентов. Также эти данные позволят продемонстрировать руководству компании реальный уровень защищенности инфраструктуры и текущие киберугрозы и в дальнейшем обосновать расширение покрытия мониторингом.
«Хочу решить все проблемы ИБ одним SOC»
Нередко клиент ждет что, помимо задач по выявлению инцидентов, SOC сможет работать с утечками, являясь оператором DLP, реализует на SIEM антифрод (клиентский), проконтролирует рабочее время сотрудников и сможет управлять правами доступа.
Конечно, нет ничего невозможного, но такой подход не всегда оправдан, ведь внешние сервис-провайдеры заточены под определенные задачи и решение дополнительных – это кастомный проект, который априори не может стоить дешево. Конечно, некоторые дополнительные фичи сервис-провайдер может реализовать легко и просто, и их решение в рамках сервиса по мониторингу логично. Например, подключение бизнес-приклада и выявление внутреннего фрода путем корреляции общесистемных логов с логами прикладных систем. Но есть и совсем непрофильные задачи, решение которых напоминает стрельбу из пушки по воробьям. Так что же является непрофильным для провайдера SOC?
Работа с утечками информации
Инциденты ИБ, фиксируемые SIEM, содержат в первую очередь учетные данные, ip-адреса и прочие атрибуты, свойственные логам. Мы видим запуск RAT и вредоносы, фиксируем внутренних нарушителей ИБ и внешних злоумышленников. Когда речь идет о DLP и утечках, на первое место выходят люди и совершаемые ими нарушения. Эти нарушения лежат скорее в ведении экономической и физической безопасности: сговоры, хищения информации, некорректное обращение с грифованными документами. Все эти данные, как на ладони, становятся доступны внешнему сервис-провайдеру в момент, когда он забирает на себя управление инцидентами DLP. Как только компании понимают это – желание передавать управление DLP внешнему подрядчику пропадает. Если же ему передавать только алерты из DLP без контекста и содержимого, то польза резко снижается. Только по названию инцидента («зафиксирована аномалия поведения» или «утечка информации на съемный носитель») сделать выводы о серьезности нарушения невозможно.
Антифрод
Если мы говорим про антифрод на уровне бизнес-систем, с которыми работают сотрудники компании, то это типовая для SOC задача. Но когда речь идет про банковский антифрод на уровне транзакций по счетам физических и юридических лиц – это уже совершенно иной коленкор. Объемы транзакций крупного банка и количество учитываемых параметров в антифрод-системе способно положить практически любой SIEM. А еще такой контент плохо поддерживаем, и его необходимо разрабатывать с нуля, так как нет соответствующих наработок. Простейшие вещи, конечно, можно реализовать, но это равноценно использованию мультитулов: в целом работает, но отдельный нож, штопор или открывалка сильно удобнее.
Контроль времени работы и прав доступа
По косвенным признакам в SIEM можно контролировать работу сотрудников (время логина и логаута, запускаемые процессы, веб-серфинг) и привилегии (группы в AD, сбор статистики по реальным доступам сотрудника и прочее). Но намного проще и удобнее это делать профильными системами – они предоставляют намного большие возможностей. Хотя несколько лет назад, когда не все прокси-серверы обладали гибкой визуализацией и отчетностью, было довольно популярно собирать статистику посещений пользователей различных веб-сайтов с помощью SIEM.
Заключение
Итак, запросы, с которым клиенты приходят к сервис-провайдеру, с одной стороны, разнообразны, с другой – у них много общего. Кто-то хорошо понимает свои потребности, кто-то, наоборот, просто хочет SOC, не разбираясь в том, для чего он нужен. Одни хотят закрыть все проблемы ИБ одним центром мониторинга, другие – решить задачу compliance, ограничившись бумажной безопасностью. В любом случае сервис-провайдер должен трезво оценивать каждую потребность, соотнося ее со своими возможностями и особенностями конкретной инфраструктуры заказчика.
Для клиента выбор сервис-провайдера тоже непростая задача. Нужно смотреть на опыт поставщика услуг ИБ, наличие методик и методологий, гибкость сервиса и дополнительных услуг. Также важно выбирать партнера с необходимой экспертизой по конкретным вендорам и решениям.
На старте проекта важно предусмотреть путь развития SOC на ближайшие 5-7 лет и придерживаться именно его. Например, если компания решила идти по пути сервисной модели и все расходы перевести в OPEX, но через 3 года вдруг задумала купить SIEM себе на баланс - точно будет переплата. Если же в планах построить собственный SOC и привлечь провайдера для консалтинга, лучше заранее оценить силы и проработать кадровый вопрос на фоне дефицита ИБ-специалистов. Стоит сразу предусмотреть быстрый транзит экспертизы, дублирование компетенций, стажировки, которые позволяют заместить сотрудников 1-й линии за 2-3 месяца.
В любом случае важен диалог провайдера и клиента, потому что только в партнерстве с профильными подразделениями заказчика может быть создава эффективная киберзащита.
Автор: Алексей Павлов, директор по развитию бизнеса центра противодействия кибератакам Solar JSOC