
Время — деньги
Журналов событий, получаемых от одних только активных средств защиты, — много, не говоря уже о критических серверах, базах данных, приложениях. При помощи этих журналов можно выявить несанкционированные попытки доступа, сетевые атаки, аномалии, ведущие к нарушению непрерывности бизнеса или политик безопасности. Чтобы открыть журнал событий, нужно выполнить последовательность действий, которые требуют времени: запустить приложение, подключиться к консоли, вывести список событий и изучить его. Даже если допустить, что один сотрудник отвечает только за контроль антивирусного ПО (предположим, что имеется централизованная консоль управления), установку обновлений и IPS (предположим, что их не более 2—4), — на просмотр событий от этих источников и разбор проблем за последние сутки у него уйдет около часа. Отметим человеческий фактор: офицер может быть загружен другими делами, может болеть или быть в отпуске, отвлечься от работы или выполнить ее для проформы. Теперь посчитайте, сколько человеко-часов нужно, чтобы анализировать журналы событий на критических активах хотя бы раз в сутки? Учтите в расчетах заработную плату квалифицированного сотрудника, способного выявить угрозы в этих журналах событий, учтите время, необходимое для подключения к СЗИ в вашем филиале по медленным каналам связи. Дорого? Да, выходит круглая сумма, назвав которую руководству, вы, скорее всего, будете выставлены из кабинета.
Защита бизнеса
Главная задача ИБ — обеспечить защиту бизнеса и непрерывность бизнес-процессов. Что для этого нужно? Описываются бизнес-процессы, определяются активы, проводится их аудит (включая сканирования и пентесты), составляется модель нарушителя, изучаются риски, составляется план их минимизации. Какие меры принимаются для минимизации риска? Создаются политики, проводится обучение пользователей, устанавливаются средства защиты информации, изменяются конфигурации, устанавливаются обновления… Мы все это сделали — и оставили как есть? до следующего цикла PDCA?
Держать руку на пульсе
Принцип «поставить и забыть» в ИБ неприменим. Абcолютной защиты не существует, и самые маловероятные риски могут аукнуться остановкой бизнеса и огромными финансовыми потерями. Любое программное и аппаратное обеспечение может перестать работать или быть неверно настроено — и пропустить угрозу. Видели панель управления в современных самолетах? Все важные индикаторы собраны воедино с соблюдением эргономики и приоритета. Пилот и его помощник не могут не увидеть нарушение критически важного показателя. Так и в SIEM: в случае любого отклонения от baseline или политик (курс самолета) или нарушения работоспособности актива в результате сбоев или угроз (неполадки в оборудовании) — операторы-пилоты будут незамедлительно уведомлены.
Превентивной защиты не существует
Если мы устанавливаем централизованное антивирусное ПО — необходимо убедиться, что оно установлено везде, правильно сконфигурировано, работает с актуальными базами. Как? С помощью журналов событий.
Контролируемая угроза, принятый риск
На практике встречаются случаи, когда безопасность идет вразрез с бизнесом. Случаются ситуации, когда нельзя поставить обновление, чтобы закрыть уязвимость (причин масса: сертификация, нестабильность работы, «не протестировано», конфликт с другим ПО), или, например, невозможно запретить RPC, поскольку бизнес-приложение перестанет работать. Затраты на устранение угрозы могут превышать возможные потери, поэтому риск «принимается». Однако мы можем контролировать подобные риски с помощью SIEM, реагировать на возникающие инциденты, возвращая по окончании года средства, выделенные на покрытие операционных рисков, обратно в бюджет. Естественно, что в данном случае не может быть и речи о просмотре оператором журналов межсетевого экрана без автоматического анализа и регистрации инцидентов как способа контроля рисков.
Нет причины — все виноваты
Вы наверняка сталкивались со случаями, когда для решения инцидента нет данных: отсутствует информация о точном времени и месте возникновения (не считаем звонки от пользователей), о том, что предшествовало инциденту; и мы не можем ответить на главные вопросы — почему произошел инцидент и кто в этом виноват. Нет, это нужно не для того, чтобы наказать виновных (хотя это тоже иногда необходимо). Главное, что необходимо выяснить по итогам инцидента, — что делать, чтобы инцидент не повторился. Причем одного только встроенного в OС журнала (Windows event log или syslog) может оказаться недостаточно.
Я не бог, я всего лишь системный администратор
В зрелой разветвленной инфраструктуре права администрирования делегируются достаточно широкому кругу сотрудников. Естественно, все эти сотрудники проходят проверку службы безопасности, и мы им доверяем. Но на практике зачастую сказывается людская психология: сотрудник, порушивший базу данных, RAID, принесший на личной флешке вирус, из-за которого «встал» бизнес-процесс, под страхом увольнения и штрафа, загнанный в угол — заметает следы, удаляя или подделывая журналы событий. Если не собрать вовремя эти журналы, то бизнесу будет нанесен вред в виде финансовых потерь и испорченной репутации. Собранные вовремя и консолидированные в хранилище журналы событий помогут вам принять правильное решение по итогам инцидента. Осуществить удаление данных (событий и инцидентов) из SIEM незаметно не получится: остаются записи в системном журнале, осуществляется контроль целостности. Доказательства в виде журналов событий в SIEM-системах помогут вашей организации в решении судебных вопросов.
Кто знает, что это за скрипт?..
Безусловно, можно построить управление журналами и какое-никакое управление событиями на «самописных» сценариях. Журналы собирать через syslog или открытое ПО. Можно все оформить на PowerShell, «батники», sh-сценарии, а об инцидентах сообщать на электронную почту. Как удобно и дешево!
Защищайте не только критические активы
Представим, что вы защитили критические (по вашему мнению) активы, к примеру бизнес-приложение или базу данных. Все прекрасно, денег потрачено в меру, сэкономили на отсутствии СЗИ для рабочих станций и двухфакторной авторизации для мобильных пользователей. Пользователей «зажали» групповыми политиками. Вот только не учли, что дверь с замком, стоящая посреди поля, — абсолютно неэффективна. Злоумышленники получат пользовательский и административный аккаунт с незащищенных рабочих станций или с мобильных устройств и с абсолютно легитимными запросами к вашей суперзащищенной базе данных «вытянут» все, что только можно. Деструктивные действия давно не в моде. Вы узнаете об утечке информации из новостей — и удивитесь: ведь все ваши серверы были надежно защищены! Это пример типовой атаки по модели APT. Запущенные процессы, новые библиотеки в OС, новые сервисы, открытые порты и соединения, повышение привилегий — все это можно увидеть в журналах событий на рабочих станциях, которые не являлись, по вашему мнению, критическими активами…
Представления
Средства защиты, как правило, являются сигнатурными, то есть создаются на основе анализа уже известных угроз (вирусы, сетевые атаки, даже словарики в DLP). Новые угрозы вы можете выявить только с применением сложных алгоритмов корреляции (об RBR-корреляции — см. статью в нашем блоге — здесь не может быть и речи) на основе миллионов событий и показателей, а также анализа baseline. Человеческий мозг не всегда способен комплексно проанализировать такой объем данных. Однако абстракция представлений в SIEM-системах способствует своевременному обнаружению угроз операторами. Система делает все предварительные расчеты и выводит показатели. Как минимум, к примеру, на основе анализа baseline система сообщает о новом DynDNS-трафике, о том, что зафиксировано по 10 безуспешных попыток входа с различных активов от имени доменного администратора. Как правило, система способна сообщить о трояне или брутфорсе (в зависимости от состава правил корреляции и возможностей конкретной системы). Применение более сложных алгоритмов корреляции позволит узнать причину инцидента (например, выявить подключение пользователем модема, в результате которого произошло заражение трояном и брутфорс). Человеку не под силу самостоятельно осуществлять такой анализ на основании миллионов текстовых событий. Возможность настройки панелей визуализации полезна как отдельным сотрудникам, так и для работы SOC (security operation center), а также подразделений ИТ и техподдержки.
Соответствие (compliance)
В ряде региональных, международных, национальных, отраслевых стандартов имеются требования к организации процесса управления журналами. Все SIEM-системы имеют шаблоны, соответствующие международным стандартам, и возможность добавления своих шаблонов для формирования отчета о соответствии по сбору и хранению событий. В случае с самодельной системой вам придется потратить значительные ресурсы, чтобы сделать подобные шаблоны в формате отчетов или интерфейса для аудитора.
Акценты
Неверное реагирование на инциденты сравнимо с некорректным поведением светофора. ИБ- и IТ-подразделения будут неспособны решать первоочередные задачи по обеспечению бизнес-процессов. SIEM обладает минимально необходимыми средствами организации процесса регистрации инцидентов (или имеет возможность интеграции со службой поддержки), способствующим контролю решения инцидентов и накопления базы знаний. В SIEM имеется возможность интеграции и приоритезации инцидентов в зависимости от их влияния на бизнес-процессы, от ценности актива и опасности угрозы. В некоторых системах возможна интеграция с системами управления рисками.
Поделитесь событиями
SIEM — это система не только для ИБ. Ошибки и сбои в операционных системах, сетевом оборудовании, ПО — информацию обо всем об этом сотрудники IТ-отдела могут почерпнуть в SIEM. IТ-отделу также хочется узнавать о возникающих инцидентах не по звонку пользователей, а заранее (тем более, что — как и инциденты ИБ — IТ-инциденты можно предотвратить).
- корреляцию и оценку влияния IТ- и ИБ-событий и процессов на бизнес;
- SOC с анализом ситуации в инфраструктуре в режиме реального времени;
- автоматизацию процессов обнаружения угроз и аномалий;
- автоматизацию процессов регистрации и контроля инцидентов;
- аудит политик и стандартов соответствия, контроль и отчетность;
- задокументированное корректное реагирование на возникающие угрозы ИБ и ИТ в режиме реального времени с приоритизацией в зависимости от влияния угроз на бизнес-процессы;
- возможность расследования инцидентов и аномалий, в том числе произошедших давно;
- доказательную базу для судебных разбирательств;
- отчетность и показатели (KPI, ROI, управление событиями, управление уязвимостями).
Я привела лишь немногие примеры того, как SIEM поможет вашему бизнесу в обеспечении непрерывности, повышении оперативности, в решении проблем и инцидентов. Можно еще много писать об автоматизации, реакции (сценариях), предотвращении инцидентов и их расследовании. Об этом я постараюсь рассказать в следующих публикациях. Отдельно рассмотрим крайне важный момент, волнующий многих: как с помощью SIEM проследить влияние IТ- и ИБ-событий на бизнес.