2.7. Инструменты и качество данных

Успех или провал в обеспечении защиты сетей зависит от способности аналитиков SOC собрать и понять нужные данные в нужное время в нужном контексте. Практически каждый зрелый SOC использует набор технологий для создания, сбора, анализа, хранения и представления огромного количества данных для своей команды. На рисунке 4 изображена высокоуровневая архитектура используемых в SOC инструментов и технологий.

Рис. 4 Типичная архитектура инструментария SOC

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

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

2.7.1. От подозрений к подтвержденным данным

При создании SOC необходимо тщательно продумать, какими датчиками и средствами сбора логов следует вооружить клиентские ИТ-активы и сети, чтобы собирать подозрения на инциденты и подкрепляющий их контекст. Эта концепция не является чем-то новым. Утром 7 декабря 1941 года радиолокационная станция в Оаху, Гавайи под управлением армии США обнаружила сильный импульс какого-то сигнала. Радиолокационные операторы немедленно отправили новость об обнаружении в другое подразделение на острове. Однако те не могли понять, что именно было на их радаре [54], потому что у них не было дополнительных данных для подтверждения факта обнаружения и отсутствовал контекст. Они предположили, что сигнал на радарах был вызван дружественными В-17, вылетевшими на задание тем же утром. Однако на самом деле их радары засекли японские боевые самолеты, направляющиеся атаковать Перл-Харбор. Если бы операторы смогли подтвердить, что сигнал на радарах принадлежал вражеским самолетам, они бы приняли соответствующие меры для подготовки к атаке. То же самое можно сказать о многих серьезных предупреждениях, которые наблюдают аналитики SOC – в отсутствие подтверждающих данных поток первичных сообщений от средств обнаружения не представляет собой ценности.

Вне зависимости от степени серьезности, неподтвержденное событие само по себе не является достаточным доказательством того, что инцидент на самом деле произошел.

Каждое событие должно оцениваться в контексте системы, в которой оно произошло, окружающей среды, выполняемой задачи, релевантных данных киберразведки и других источников данных, которые могут подтвердить или опровергнуть наличие реальной угрозы. Именно поэтому логическая и физическая близость между аналитиками и контролируемыми ими системами повышает их способность выявлять инциденты и вовремя реагировать на них. Аналитики начинают с первичных индикаторов (например, высокоуровневого предупреждения об инциденте или сработавшего правила корреляции) и далее собирают дополнительные контекстуальные данные для подтверждения обнаруженных событий. Достоверность этих данных может быть улучшена с помощью средств корреляции и автоматизированной фильтрации, а также дедупликации данных в SIEM-системах. Зачастую специалисты SOC не могут быть на 100 % уверены в том, что на самом деле произошло, из-за неполных, неубедительных или неоднозначных данных. И SOC должен это учитывать, особенно, при выборе сценария реагирования.

И хотя автоматизация помогает SOC не утонуть в море необработанных данных, нельзя забывать о том, что

Аналитикам не существует замены.

Пока аналитик SOC не оценил событие, SOC не может подтвердить или опровергнуть наличие инцидента. Более того, ни один аналитик не может знать всех технологий и всех вариантов поведения на наблюдаемых хостах и сетях. Поэтому SOC рекомендуется задействовать несколько человек для решения аналитических задач. Бывают случаи, когда набор индикаторов является достаточно точным, чтобы можно было автоматизировать определенные действия по реагированию, например, с помощью IPS или SIEM-систем. Однако всегда есть вероятность того, что положительный индикатор окажется неправильным – они называются ложными срабатываниями и более подробно обсуждаются ниже.

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

Рис. 5 Полный спектр данных от подозрений к контексту

2.7.2 Обнаружение

Некоторые из обсуждаемых здесь средств – IDS/IPS на хостах и в сети, SIEM-системы, инструменты сбора логов, антивирусное ПО – имеют схожий набор свойств:

  1. Знание среды и угроз используется для формулировки политики обнаружения, которая определяет по заданным правилам правильное, неправильное и нормальное поведение.
  2. Система обнаружения вторжений отслеживает различные явления (например, события или изменения состояния в киберпространстве) и сравнивает их с заданной политикой. Активность, соответствующая неправильному поведению, или отклонение от типичного «нормального» поведения приводит к созданию события или последовательности событий с описанием подозрительной активности.
  3. События могут отправляться аналитику в режиме реального времени и/или сохраняться для последующего анализа.
  4. Опираясь на замечания в отношении генерируемых событий, в настройки политики обнаружения вносятся корректировки и уточнения.
  5. Некоторые события могут быть отфильтрованы на нескольких этапах – как правило, ещё до того, как они будут показаны аналитику или перед их сохранением.

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

Существует два классических подхода к обнаружению вторжений:

  1. Сигнатурное обнаружение или обнаружение несанкционированной активности – когда система априори знает, каким образом отличить и, следовательно, обнаружить вредоносное поведение.
  2. Обнаружение аномалий – когда система распознает нормальное и санкционированное поведение и предупреждает, если что-то выходит за рамки этого поведения.

Оба подхода имеют свои плюсы и минусы. На практике трудно найти инструменты, которые полагаются исключительно на один подход. Большинство поставщиков IDS и антивирусных систем объединяют в своих продуктах оба метода. Коммерческие поставщики IDS делают это для повышения видимой ценности своих продуктов. Реальная же эффективность продукта зависит от надежности механизмов обнаружения. Тем не менее, большинство инструментов SOC больше доверяют сигнатурным подходам, чем инструментам обнаружения аномалий. Важно понимать, что сигнатурный метод обнаружения требует наличия знаний о методах противника и не позволяет оповещать о ранее не известных угрозах. С другой стороны, обнаружение аномалий часто требует определения некого базового уровня «допустимого поведения», что тоже нелегко реализовать.

Рис. 6 Абстрактные инструменты обеспечения безопасности сетей

2.7.3 Стоимость ложных срабатываний

Инструменты не всегда предупреждают о том, что происходит что-то плохое, а получение сигнала тревоги от них не обязательно означает, что пришло время изолировать хост или вызывать полицию. Получение от IDS предупреждения о том, что «веб-сервер взломан» не означает, что веб-сервер был взломан на самом деле. Каждое событие, которое генерируют инструменты обнаружения, попадает в одну из четырех категорий, в зависимости от того, сработало ли предупреждение и произошло ли что-то плохое в действительности:

  1. Истинно положительные события. Произошло что-то плохое, и система обнаружила это.
  2. Истинно отрицательные события. Активность не является вредоносной, и предупреждение не генерируется.
  3. Ложноположительные срабатывания. Система генерирует предупреждения, но активность на самом деле не была злонамеренной.
  4. Ложноотрицательные результаты. Произошло что-то плохое, но система не обнаружила этого.
Рис. 7 4 категории событий

Самая важная задача для любой системы мониторинга, особенно IDS, – добиться высокой доли истинно положительных событий. Разработчики и продавцы как научных, так и коммерческих систем мониторинга стремятся доказать, что их система никогда не пропускает успешную атаку (т.е. никогда не имеет ложноотрицательных результатов). Однако, зачастую этого добиваются за счет потока ложных срабатываний, о чем говорилось в [55]. Слишком много ложных срабатываний заставляют аналитиков тратить слишком много времени на изучение данных или, что еще хуже, игнорировать инструмент полностью, потому что полезный сигнал теряется в шуме.

20 апреля 2010 года взорвалась нефтяная вышка компании Transocean у побережья Луизианы, в результате чего погибло несколько рабочих и произошла утечка миллионов галлонов нефти в Мексиканский залив. Это происшествие и потеря буровой установки Deepwater Horizon вылились в миллионы долларов прямых убытков бизнесу и экономике, не говоря уже об экологическом бедствии и последующих работах по очистке, которые выполнялись в течение нескольких лет [56].

Это событие было спровоцировано рядом факторов; мы сосредоточимся на одном — системах охранной сигнализации буровой установки. Сигналы тревоги для одной из систем безопасности на буровой установке были отключены, потому что они слишком часто срабатывали. Чтобы не будить обслуживающий персонал посреди ночи, аварийные сигналы были фактически отключены на протяжение года до взрыва [57]. Одной из основных проблем инцидента в Transocean было то, что не устранённые проблемы технического обслуживания не позволили системам безопасности работать правильно. Инцидент Transocean демонстрирует, что аналитик, не реагирующий даже на самые важные сигналы, может стать причиной катастрофических последствий. И хотя катастрофа Transocean произошла по целому ряду причин, игнорирование предупредительных сигналов явно не улучшило ситуацию.

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

Маркировка невредоносного события как «ложное срабатывание» предполагает, что целью автора сигнатуры было обнаружение какой-то злонамеренной активности, но иногда маркировку используют и в других контекстах. SOC часто предпочитают активировать различные сигнатуры IDS и принимать фиды логов, чтобы использовать эти данные для контекстного или ретроспективного анализа, а не потому, что они служат предупреждениями. Набор IDS-датчиков может генерировать тысячи «хороших» предупреждений в день, а миллионы записей журнала аудита собираются для их подкрепления.

Эти низкоприоритетные события «аудита» не являются ложными срабатываниями, учитывая, что они собирались не для подтверждения «вредоносности». Например, IDS может быть настроена для регистрации всех веб-запросов, поскольку SOC не имеет в своем распоряжении журналов веб-прокси. Полученные события не являются ложными срабатываниями; они указывают ровно на то, что было задано – веб-запросы. Один IDS-датчик или источник логов может генерировать более 100 000 событий каждый день. Такие инструменты как SIEM облегчают и автоматизируют сортировку событий. В результате, SOC в реальности может быть более гибким в отношении своей политики сигнатур. Более частые события, как правило, подходят для корреляции, выявления трендов или настройки, тогда как редкие события более интересны в качестве подозрений.

Рис.8 Поиск баланса между объемом и ценностью данных

Некоторые IDS и SIEM-системы предоставляют полную информацию о сигнатурах или правилах, которые они используют для генерации предупреждений, а также необработанные данные, которые вызвали сигнал тревоги. Поэтому можно утверждать, что нет такого понятия как ложное срабатывание, поскольку только аналитик знает, как интерпретировать результаты. Термин «ложное срабатывание» правильнее всего использовать в отношении события, которое было создано сигнатурой с целью идентификации «злонамеренности», однако в силу неточности сигнал тревоги сработал при неправильных обстоятельствах. Точность сигнатуры — это всегда проблема и, хотя в большинстве IDS реализована концепция приоритета событий, в них не реализовано понятие надежности. То есть, какова точность и достоверность сигнатуры в отношении действий, вызывающих подозрения?

2.7.4. Количество данных

Не все данные равноценны, поэтому SOC необходимо расставить приоритеты, какие данные следует собирать, обрабатывать и хранить, в соответствии с ожиданиями от них. SOC должен понимать ограничения своих инструментов, оценить, какие сценарии обнаружения и анализа он хочет поддерживать, и правильно рассчитать объем собираемых данных. Слишком малое количество данных означает, что инструменты используются недостаточно эффективно. Слишком большой объем данных приведёт к одной из двух проблемам (или обеим сразу): (1) сигнал потеряется в шуме, и (2) системы не выдержат нагрузку с точки зрения производительности обработки данных или производительности запросов.

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

Использование SIEM-системы может повысить ценность нескольких небольших по объему потоков данных, однако большинство коробочных SIEM имеют высокую стоимость и дороги в обслуживании. В результате, нецелесообразно развертывать SIEM стоимостью в несколько миллионов долларов и получать до 10 000 событий в день (учитывая, что с помощью Perl-скриптов и grep можно делать это бесплатно). В разделе 8.4 мы рассмотрим, что устройства сбора логов и SIEM обычно оправданы, когда количество событий измеряется миллионами в день или нужно собирать несколько типов данных.

На рисунке 9 показан еще один способ взглянуть на проблемы с обработкой данных.

Рис.9 Объем данных и их практическая ценность

Свободное ПО и программы с открытым исходным кодом (FOSS), Perl-скрипты, grep и тому подобные предоставляют собой ряд интересных способов обработки данных журнала, особенно, если оператору нужно обрабатывать тысячи или, возможно, миллионы событий в день. Однако двигаясь по диаграмме вправо, можно увидеть, что в случае большего количества и разнообразия данных, можно получить большую ценность за счет сбора логов и использования принципов и аналитики SIEM. Многим SOC приходится работать с объемом событий, который измеряется десятками или сотнями миллионов сообщений в день, и в этом случае они обычно используют средство управления журналом, SIEM-систему, или их комбинацию. SOC необходимо сделать обдуманный выбор между пользовательскими инструментами, которые обеспечивают большую гибкость, и коммерческими инструментами с техподдержкой, учитывая влияние на общую стоимость владения (TCO).

Стратегия «собирать все» не очень хороша, если в нашем распоряжении ограниченное количество аналитиков, пространство на жестком диске и вычислительные мощности. Например, многие организации должны выполнять требование к политике аудита безопасности «записывать доступ к или изменение ключевой информации». Что следует понимать под «ключевой информацией» — открытый вопрос для многих специалистов, из-за чего в это понятие нередко включают практически любую систему или базу данных. Поэтому рассматриваемое требование часто ошибочно трактуют как «необходимо создавать и собирать записи аудита для каждой операции чтения/записи файла на каждой системе предприятия». При таком подходе записи аудита перекроют большинство других потоков данных, занимая системные ресурсы и перегружая системы сбора аудита. Мораль такова:

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

Старая поговорка «искать иголку в стоге сена» часто используется в отношении интенсивного мониторинга безопасности сетей, особенно когда аналитикам не хватает эффективных инструментов для сокращения объема, корреляции или поиска контекста данных, которые они изучают. Некоторые SOC собирают максимум возможной полезной информации о состоянии безопасности, чтобы использовать её в будущем. Эта стратегия применима только к тем SOC, у которых есть достаточно свободного места для хранения данных, вычислительных мощностей и аналитиков, что далеко не всегда так.

Использование набора средств мониторинга требует, чтобы команда SOC была постоянно начеку, поскольку ландшафт угроз и состав клиентских систем непрерывно меняются. Потоки данных могут прерываться, датчики — отключаться, появляются новые сигнатуры и т.д. Многие SOC упускают из виду эти факты, что может быть основной причиной, по которой развертывание IDS и SIEM-систем воспринимается как бессмысленная трата ресурсов. Одним из наиболее важных аспектов мониторинга клиентов является:

Системы мониторинга, такие как IDS и SIEM, не работают по принципу «отработал и забыл» — они требуют регулярного ухода и поддержки.

Об этом речь пойдет далее, в том числе в разделах, где рассматривается набор инструментов и методы обнаружения APT-атак.

Поделиться записью: