BIS Journal №4(27)/2017

16 ноября, 2017

Живая вода для SOC

Набравшая силу волна популярности SOC обнаруживает целый ряд зомби-SOC, которые существуют только формально. Несмотря на кипы процессных документов, полные наборы дорогостоящих технологий (SIEM, IDS, Service Desk) и вроде бы компетентных специалистов компании с многомиллиардными оборотами годами безуспешно пытаются построить результативный, интересующийся всем новым, по-настоящему живой SOC.
 
Создавая для топ-5 российского MSSP свой SOC (естественно, итеративным путем, не минуя проб и ошибок), нам удалось найти практические рецепты – «живую воду», позволяющую возродить старый SIEM-ориентированный SOC и выстроить эффективную, гибкую, развивающуюся SOC-организацию.

ВИДЫ «ЖИВОЙ ВОДЫ» 

Security Baseline. Перед началом реального мониторинга необходимо навести базовый порядок – разработать и утвердить политику ИБ, в частности базовый набор требований к ИТ-инфраструктуре (контрольной среде, в которой работают безопасники, ИТ- и бизнес-пользователи).
 
По факту это небольшой набор основных требований, предъявляемых к защищаемым объектам. Например, для хоста это могут быть: наличие антивируса, наличие Host IDS, настройка отправки логов в SOC, установка последних патчей, отсутствие учетных записей пользователей без паролей или с паролями «по умолчанию».
 
Отсутствие таких базовых мер позволяет взламывать хосты в сети практически мгновенно. Так в одном из тестов на проникновение взлом непропатченного хоста занял 15 минут, а уже через 20 минут доменный контроллер был захвачен. Хотя до этого пентестеры молили – пустите в сеть, отключите Port Security и т.д.
 
А уж если хост доступен из Интернета, необходимо понимать, что, помимо вашего SOC, существуют еще десятки тысяч чужих систем (ботов), которые постоянно осуществляют мониторинг сети в надежде чем-нибудь поживиться. Боты реализуют простые, но эффективные сценарии поиска объектов атаки. Какой бы скромной и незаметной ни была ваша компания, за сутки к ее интернет-ресурсу обратятся два-три десятка ботов. Информация об обнаруженной уязвимости будет направлена хозяевам бота, после чего последует очень быстрая, хорошо автоматизированная атака по заранее приготовленному для найденной уязвимости сценарию.
 
Операторы SOC должны иметь под рукой Security Baseline предприятия, а также инструменты для его оперативной проверки. SOC должен отслеживать события изменения конфигурации наблюдаемой среды, в частности появление новых хостов, и немедленно выяснять, не нарушен ли Security Baseline. Это жизненно необходимо, так как ошибки в действиях ИТ-персонала могут привести к тому, что под огонь попадет незащищенная критичная для бизнеса система предприятия.
 
Базовые контроли. Основная (но не единственная) задача SOC – обнаружить факт того, что имеющиеся на предприятии средства защиты не сработали. SOC может это обнаружить, анализируя данные, получаемые от специальных технических и программных устройств, которые далее мы будем называть «контролями». Без минимального набора контролей шансов найти сколько-нибудь профессионального злоумышленника просто нет – если он будет понимать, что есть системы защиты, то, например, вместо хищения данных он оставит в сети шифровальщика и уйдет из нее в надежде получить свой выкуп.
 
Существуют 6 базовых контролей без которых никакой эффективности SOC не будет:
  • Host IDS умеет обнаруживать признаки атаки на хостах, такие как изменение системных файлов, создание новых учетных записей или изменение членства в группах безопасности, открытие новых портов и т.п. Желательно иметь Host IDS на всех без исключения компьютерах в сети, что не всегда возможно (например, в схеме с использованием BYOD). Основная рекомендация следующая: если вы можете установить Host IDS на компьютер – сделайте это.
  • Network IDS умеет «просматривать» сетевой трафик и находить в нем признаки атак, например, работу сетевого сканера или попытку использовать эксплойт (программу для эксплуатации известной уязвимости в системе). Желательно направить на Network IDS весь трафик вашей сети, а не только трафик сегментов, которые вы считаете критически важными. Маловероятно, что атака начнется внутри критически важного сегмента, обычно до него не просто добраться. Лучше иметь возможность обнаружить атаку на ранней стадии. Коммерческие IDS могут оказаться слишком дороги для «неважных сегментов», в этом случае можно использовать продукты Open Source.
  • Антивирус. Если антивирус что-то обнаружил на хосте, то как оно туда попало? Значит средства защиты «на периметре» не сработали. Кроме того, некоторые антивирусы содержат Host IDS в качестве одного из своих модулей.
  • Почтовый фильтр умеет обнаруживать исполняемый код во вложенных файлах и задерживать такие письма в карантине. Задерживать надо все, что может исполняться, не следует полагаться на такие вещи, как почтовый антивирус. Вот практическая статистика по одной из компаний: почти 100 % задержанных писем действительно содержали трояны или загрузчики троянов, менее 10 % из этих писем детектировались популярными антивирусами, как содержащие вредоносный код. Почему так? Прежде чем послать трояна по почте, любой злоумышленник сначала проанализирует его на одном из ресурсов, осуществляющих анализ подозрительных файлов и ссылок (например, Virustotal), чтобы убедиться в том, что файл проходит сигнатурный анализ всех известных антивирусов. Задержка в карантине нужна для того, чтобы ваш SOC смог сначала выполнить исполняемый код в так называемой «песочнице» и убедиться в том, что он безопасен.
  • Next Generation или UTM Firewall. Для простоты будем считать, что это разные названия одного и того же – межсетевого экрана. Что мы от него хотим? Он должен иметь встроенную IPS, обновляемую базу категорий известных сайтов, средства «разрыва» SSL-соединений. Мы хотим разрывать шифрованные соединения SSL и, с помощью IPS, анализировать, нет ли внутри вредоносных объектов. При этом мы не хотим разрывать все соединения, но только те, которые устанавливаются с неизвестными сайтами категории Unrated.
  • Сбор системных журналов: отовсюду, со всех компьютеров, сетевых коммутаторов, маршрутизаторов, веб-серверов, серверов баз данных. Наш SOC должен уметь принимать и хранить огромные объемы данных и, кроме того, выполнять в них очень быстрый поиск и агрегировать данные по различным параметрам. Больше всего «следов атаки» мы можем найти именно здесь, главное – знать, что искать.

МОНИТОРИНГ 

Мониторинг традиционно является основным процессом SOC. Операторы SOC непрерывно пытаются увидеть что-то, что может быть квалифицировано как нарушение безопасного состояния системы: признаки намеренных атак, ошибки персонала, сбои в работе оборудования. В этом им помогают «контроли» и Security Baseline. Интересно, что у широкой общественности сложилось мнение, что SOC – это, прежде всего, SIEM. Однако это – заблуждение. Заблуждение, возникшее благодаря многолетним усилиям продавцов SIEM.
 
SOC в первую очередь – это люди. А SIEM – это всего лишь средство автоматизации труда, позволяющее сократить трудозатраты персонала SOC (и то – в развитом SOC SIEM составляет до 10% в технологическом стэке). Главный ресурс – опыт, знания и компетенции. Главная ценность SOC – его команда. И эта команда должна постоянно учиться – учиться выделять признаки атак из всей массы анализируемых событий. Это является основой концепции RedTeam, о которой мы поговорим далее.
 
Непрерывное противоборство и совершенствование. Но есть и еще кое-что. Даже самая обученная команда не должна «спать на боевом дежурстве». В этом нам могут помочь те самые десятки тысяч ботов, которые непрерывно работают в Интернете. Их роботизированные атаки на нашу инфраструктуру бессмысленны и неопасны, если, конечно, у нас все в порядке с Security Baseline. Но SOC должен фиксировать факты атак, пусть и не открывая инцидент.
 
Пример из армейской жизни. Фраза «This is the CENPAC command center with the communication flash test call» знакома многим, кто служил в военной разведке – это всего лишь проверка связи типа «молния» у бывшего вероятного противника. Но боец на посту должен ее зафиксировать. Ваша проверка – это и наша проверка. А еще за проверкой связи может последовать что-то более важное, поэтому особо упорные роботизированные атаки тоже следует брать на заметку: возможно, это прелюдия, и следует ждать чего-то еще, например, фишинговых писем. Это сигнал о том, что нужно быть на чеку.
 
Не только «на периметре», но и внутри сети возникают такие «бодрящие» события. Например, создание учетных записей пользователей или изменение членства в группах безопасности. Это обычные действия администраторов, но их тоже следует фиксировать и, как минимум, отправлять администраторам, чтобы они могли посмотреть и подтвердить, что это была их работа.
 
Иногда «бодрящие события» относят к классу False Positive и стараются избавить от них SOC. Это ошибка. False Positive – это совсем другое, это когда некое автоматическое правило анализа событий выявляет индикатор «опасного» события, а на самом деле событие штатное. Кстати, такие события тоже не следует сразу отбрасывать, так как это вопрос точности индикаторов. Вместо того, чтобы «выбросить» False Positive, надо подумать над тем, как уточнить индикаторы.
 
RedTeam. Аналитики SOC всегда должны иметь некоторое количество инцидентов в работе независимо от того, происходят в настоящий момент реальные атаки на активы организации или нет – быть «на страже». Чтобы обеспечить поток атак реализуется концепция RedTeam (непрерывного внутреннего теста на проникновение) – практические навыки аналитиков совершенствуются непрерывно, а сама RedTeam совершенствует свои навыки скрытной эксплуатации уязвимостей и изучения корпоративной сети.
 
Чтобы не получилось как в известной истории про «Волки! Волки!», RedTeam должна быть не одна и постоянно перемещаться по сети – источники атак обязаны различаться. Время от времени RedTeam должна появляться в принципиально другом сегменте инфраструктуры, чтобы уже изученная первая команда не становилась преимуществом аналитиков SOC. Развитые компетенции RedTeam можно использовать уже в ходе независимых аудитов безопасности клиентов, поставщиков или дочерних предприятий.
 
Управление конфигурациями. Критично важен процесс управления конфигурациями. Ваша CMDB – большое подспорье для SOC. Очень трудно защищать что-то, о чем не имеешь ни малейшего представления. Но хороший процесс управления конфигурациями и актуальная CMDB – очень большая редкость. Однако есть минимум, без которого «каши не сваришь».
 
Прежде всего нужно выделить в вашей системе критические сегменты. Как правило, они связаны с важнейшими бизнес-процессами: платежи, каналы продаж, CRM и т.п. В них попадают критические элементы инфраструктуры: серверы, сетевые коммутаторы и маршрутизаторы, АРМы операторов и АРМы управления (администрирования). Для критических сегментов у вас, скорее всего, будет более строгий Security Baseline, но главное не в этом. Как правило, в этих сегментах реже происходят события изменения конфигурации и характер потоков данных относительно стабилен. Любое отклонение от стабильного состояния здесь является более подозрительным событием, чем в общем потоке событий. Можно определить несколько категорий активов, включая производственный, тестовый и девелоперский сегменты.
 
Также необходимо определить, какие свойства актива приоритетны: доступность или безопасность. Это важно для разработки разумных сценариев реагирования. Самая безопасная реакция при подозрении на успешную атаку, например, на какой-нибудь сервер, – отключить его, но вряд ли это разумно в отношении сервиса online-продаж. Или разумно? Это не очень простой вопрос.
 
Ваш SOC должен обладать указанной выше информацией о вашей системе, иначе он будет вынужден всего лишь дублировать «лай караульной собаки».
 
Маленьким нельзя. Почему трудно создать эффективный SOC в рамках небольшой компании?
 
Как мы уже говорили, главная ценность SOC – люди, обладающие необходимым опытом и знаниями. Главная проблема в том, что эти люди должны постоянно учиться, приобретая не только знания, что просто, но и навыки. Если вы отлично знаете устройство токарного станка, это не значит, что вы токарь 8-го разряда. Навыки приобретаются только на практике. А где взять практику? Грубо говоря, в компании с размером инфраструктуры до 500 узлов, практики не будет почти совсем, от 500 до 2000 узлов – опыта придется набираться долго, более 2000 – тут, пожалуй, можно научиться в течении года-двух.
 
Большим тоже. Почему трудно создать эффективный SOC в рамках большой компании?
 
В большой компании трудно навести и поддерживать порядок на том уровне, который необходим для эффективной работы SOC. Трудно описать конфигурации и Security Baseline, трудно расставить контроли. Трудно, но можно.

ЗДОРОВЫЙ И БОГАТЫЙ 

К сожалению, очень часто процесс построения SOC состоит из трех этапов, длительностью по полгода каждый:
  1. Мы решили сделать SOC и выбираем самый лучший SIEM.
  2. Консультант внедрил нам самый лучший SIEM, и он классно работает.
  3. Кто-нибудь помнит пароль от консоли SIEM? 
И не надо думать, что это преувеличение «для красного словца». Когда видишь такую картину первый раз в жизни – удивляешься, второй раз – не веришь своим глазам, третий – понимаешь, что это судьба. Причем, судьба очень многих.
 
С другой стороны, стоимость коммерческих сетевых IDS даже для средней компании для мониторинга всех сегментов сети составит десятки и сотни миллионов рублей, и, как правило, таких денег у бизнеса нет. Остается лишь по старинке брать SIEM. Но без мониторинга сети нельзя быть уверенным, что злоумышленник будет найден, поэтому нужно искать другие варианты. Например, использовать решения Open Source или аутсорсинг.
 
Не бывает безвыходных ситуаций, бывают лишь нелегкие решения, но без таковых в нашей профессии не состояться. 
Стать автором BIS Journal

Смотрите также

Подписаться на новости BIS Journal / Медиа группы Авангард

Подписаться
Введите ваш E-mail

Отправляя данную форму вы соглашаетесь с политикой конфиденциальности персональных данных

28.03.2024
Аитов: Ограничения Samsung Pay на использование карт «Мир» можно обойти
28.03.2024
Киберпреступления — 35% всех преступлений в России
28.03.2024
Почему путешествовать «налегке» не всегда хорошо
28.03.2024
«Тинькофф»: Несколько платёжных систем лучше, чем одна
28.03.2024
В РФ готовят базу для «усиленной блокировки» незаконного контента
28.03.2024
Термин «риск ИБ» некорректен по своей сути
27.03.2024
Samsung Pay перестанет дружить с «мировыми» картами
27.03.2024
Канадский университет восстанавливает работу после ИБ-инцидента
27.03.2024
Crypto Summit 2024. Трейдинг, майнинг и перспективы развития рынка ЦФА
27.03.2024
РКН начал работу по контролю за «симками» иностранцев

Стать автором BIS Journal

Поля, обозначенные звездочкой, обязательные для заполнения!

Отправляя данную форму вы соглашаетесь с политикой конфиденциальности персональных данных