Инструменты аналитика SOC для выявления инцидентов

При построении Security Operation Center (SOC) принято уделять внимания трём основным компонентам: техническим средствам, персоналу и процессам. Сегодня поговорим о первом по порядку, но не по значению, компоненте SOC.

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

Первый инструмент, который стоит выбрать при построении SOC — это SIEM-система. SIEM является ядром SOC. Аналитики чаще всего и больше всего работают именно с этим компонентом. SIEM позволяет хранить все логи в одном месте (что само по себе очень удобно), а также строить корреляцию между различными записями. Это позволяет обнаруживать сложные атаки. Что касается вопроса, какие логи грузить в SIEM, а какие нет, тут всё очень просто: чем больше данных загрузите, тем проще обнаруживать и расследовать инциденты безопасности. Записи журналов стоит выгружать в режиме реального времени. Для этого можно воспользоваться syslog-ом или настроить snmp trap-ы. Оба подхода требуют, чтобы принимающий сервер был доступен по сети в момент создания записи, что не всегда возможно. Поэтому для отправки записей журналов лучше воспользоваться специальными агентами сбора логов. Главным преимуществом агентов является то, что они имеют локальное хранилище записей, которое используется, пока SIEM-система недоступна. Ещё одним достоинством агентов является то, что большинство SIEM-систем показывает статус своих агентов (онлайн, оффлайн). Это позволяет понять, отсутствие событий с устройства связано с тем, что там ничего не происходит, или с тем, что узел давно лёг под действиями нарушителей или других сил.

SIEM-систем представлено на рынке довольно много. Можно выбрать как из зарубежных, так и из отечественных. Среди прочих обратите внимание на Splunk Enterprise Security — это очень гибкая и высокопроизводительная система, которая легко внедряется, содержит очень мощные аналитические инструменты, а также поставляется с уже готовыми агентами сбора данных для большинства современных операционных систем.

Для малых инфраструктур можно попытаться обойтись и без SIEM-системы либо бесплатной версией того же Splunk. При небольшом объеме логов и некоторой скриптовой автоматизации это может сработать. Но остается вопрос с инструментами анализа и корреляции данных: они все равно необходимы, поскольку без них не получится выявлять сложные атаки.

Если с журналами событий ещё есть шанс справиться вручную, то с потоком сетевого трафика это уже становится невозможным. В самом деле, если мы анализируем канал с пропускной способностью 50 Мбит/с, то за день получим до 540 Гбайт трафика. Несмотря на большой объём получившихся данных, всё же стоит хранить дамп сетевого трафика хотя бы несколько дней. Это необходимо, чтобы при выявлении инцидента изучить, как происходила атака. Что в свою очередь позволит предотвратить подобные атаки в будущем. Для записи сетевого трафика можно воспользоваться утилитой tcpdump. Стоит писать дамп не в один файл (так как открыть файл размером 540 ГБ будет очень сложно), а бить дамп на файлы по 1−2 Гб с понятными названиями (например дата создания файла). Далее эти файлы можно будет открыть в wireshark-е для анализа.

Отдельная проблема — это шифрование данных при передаче по сети. Большинство современных сетевых протоколов обеспечивают стойкое шифрование, что является благом для пользователя, но проблемой для аналитика. Зашифрованный трафик не особо поддается анализу, хотя все зависит от того, на каком уровне модели OSI осуществляется шифрование. К этой проблеме вернемся в одной из следующих публикаций.

Также трафик стоит перенаправлять на анализ в систему обнаружения вторжений (СОВ). Либо воспользоваться активными средствами защиты: системы предотвращения вторжений, системы предотвращения таргетированных атак и пр. Есть как платные, так и бесплатные варианты. Среди бесплатных самыми популярными являются Snort и Suricata. Некоторые коммерческие СОВ представлены у нас на сайте в разделе «Решения».

Все СОВ умеют детектировать скачку исполняемых файлов, например, по PE-заголовку, и обязательно создадут соответствующую запись в журнале. Но скачка исполняемого файла — это не обязательно событие безопасности. Имеет смысл автоматизировать процесс восстановления скачиваемых файлов из дампов трафика. Для этих целей хорошо подойдёт утилита NetworkMiner. Восстановленные файлы можно проверять антивирусными средствами или изучать в безопасном окружении («песочница»). Также для трафика имеет смысл строить потоки информации, по которым можно выявить несанкционированный доступ к ресурсам сети и подозрительную активность в нестандартное время. Для построения потоков информации лучше использовать данные с сетевых устройств. Если это невозможно, то с этой задачей может справиться утилита Bro, которая позволяет определить, по каким протоколам происходило обращение и к каким ресурсам.

Следующий поставщик информации для SOC — это различные инструменты инвентаризации активов и сканеры уязвимостей, которые проверяют инфраструктуру и сервисы на наличие известных уязвимостей. Сканеры бывают как универсальными (например, OpenVAS или Nessus), так и узкоспециализированными под определённые сервисы. Например, одним из лучших инструментов для сканирования web-приложений является AppSpider от Rapid7. Среди compliance-инструментов рекомендуем обратить внимание на RedCheck от АлтэксСофт (вот тут есть обзор этого продукта). Все эти инструменты позволяют обнаружить и устранить проблемы безопасности до того, как ими успеют воспользоваться злоумышленники. Но у этих методов есть общий недостаток: они проверяют на предмет наличия известных уязвимостей и не очень хорошо справляются с так называемыми 1-day уязвимостями. Тому, как бороться с этой проблемой и эффективно выявлять уязвимости в инфраструктуре, будет посвящён наш доклад на SOC-Forum 22 ноября 2017 года. Приходите, будет интересно!

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