Что регистрировать в SIEM: лучшие практики ведения журналов

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

Как узнать, с чего начать, когда дело доходит до регистрации событий безопасности? Каким источникам журналов следует отдать предпочтение?

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

Ниже приведена информация о наиболее важных источниках журналов, которые необходимо регистрировать в системе управления информацией о безопасности и событиями (SIEM).

Что регистрировать в SIEM

Вопрос о том, что регистрировать в SIEM-решении, может быть спорным. Существует две школы мысли по этому вопросу:

• Все. Обычно это исходит из точки зрения "вы не знаете того, чего не знаете". При таком подходе вы храните все, а поиск и фильтрацию осуществляете позже. Это действительно обеспечивает доступ ко всем возможным данным, которые могут вам понадобиться, но при этом возникают проблемы, связанные с хранением, индексированием и, в некоторых случаях, передачей данных журнала. Если вы используете коммерческое решение, лицензирование также может зависеть от объема.
• Только то, что вам нужно. Неудивительно, что этот подход является полярной противоположностью первому. В этом сценарии технологические ресурсы используются гораздо меньше, но есть риск, что вы что-то упустите. Когда вы начинаете с новой системы сбора и корреляции журналов, лучше всего начать с того, что вам нужно, а затем развивать ее. Это определенно неплохой способ начать сбор журналов, если большая часть конфигурации находится внутри компании.

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

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

Если вы только начинаете знакомиться с идеей и внедрением SIEM, начните с систем, которые уже ведут журналы безопасности, например, IPS/IDS и системы защиты конечных точек. Это позволит вам ознакомиться с программным обеспечением и вариантами конфигурации, объединив несколько приложений в одну систему управления журналами. После определения и соблюдения процессов и процедур можно добавить другие источники данных, такие как Windows, DNS, honeypots, приложения и базы данных для более глубокого изучения инфраструктуры.

1. Стандартные веб-приложения

Большинство стандартных веб-приложений генерируют журналы того или иного типа. Сюда входят такие службы, как серверы электронной почты, веб-серверы и другие (вероятно) службы, выходящие в Интернет. Эти журналы могут дать полезную информацию о противниках, осуществляющих атаки на эти узлы или проводящих разведку. Например:

• Слишком большое количество ответов 4XX от веб-сервера может указывать на неудачные попытки эксплуатации. Коды 4XX - это неудачные ответы типа "не найдено", "доступ запрещен", которые являются обычным побочным продуктом попыток людей вызвать уязвимые скрипты. Высокая частота ошибок 4XX может свидетельствовать о готовящейся атаке или сканировании.
• Слишком большое количество обращений к одному определенному URL-адресу на веб-сервере может указывать на то, что происходит перебор или перечисление. Конечно, повторные обращения к одному и тому же URL могут быть нормальными в зависимости от настройки сайта, поэтому важно применять контекст среды, чтобы определить, применимо ли это.
• Подключения и отключения без транзакций на нескольких типах серверов могут быть признаком того, что кто-то зондирует сеть. Это может быть вызвано простым сканированием портов, сканированием баннеров протоколов, проверкой стеков TLS и другими видами разведки.
• Новые службы, процессы и порты не должны быть незапланированным изменением конфигурации, особенно на серверах. Определение базовой линии для каждого узла, а также нежелательных или несанкционированных служб, процессов и портов может быть полезно для обнаружения установки или активности вредоносных программ.

2. Системы аутентификации

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

• Пользователи, входящие в систему в неурочное время, могут быть возможным сигналом тревоги в организации. Если пользователи обычно подключаются только в рабочее время, предупреждения об активности, например, между 7 вечера и 7 утра, скорее всего, будут достаточно немногочисленными и достаточно релевантными для расследования.
• Повторяющиеся сбои входа в систему, превышающие установленный порог, могут быть признаком попытки подбора пароля, атаки грубой силы, неправильно настроенных клиентов или просто пользователя, который не помнит свой пароль.
• Вы можете отслеживать пользователей, входящих в систему из необычных или нескольких мест. В некоторых средах пользователи могут иметь предсказуемое количество IP-адресов, с которых они подключаются. Большинство пользователей также входят в систему из одного географического местоположения за раз. Если видно, что пользователь входит в систему с обычного офисного IP-адреса, а через пять минут входит в систему из места, находящегося в пяти часовых поясах от него, возможно, что-то не так.
• Некоторые типы аутентификации по своей сути небезопасны, например, вход по HTTP или telnet, который передается по сети в открытом виде.

3. Базы данных

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

• Доступ или попытка доступа к конфиденциальным данным со стороны пользователей, а также доступ приложений к серверам, не связанным с приложением (или попытка доступа), могут дать подробное представление о том, куда и откуда перемещаются данные.
• Помимо доступа, вы должны тщательно регистрировать и отслеживать другие действия, такие как копирование и удаление баз данных и таблиц, запросы и активность всех привилегированных пользователей. Вы можете создавать предупреждения о любой активности, выходящей за рамки обычного базового уровня, чтобы отслеживать утечку данных или злонамеренный доступ.
• Другие действия по аутентификации, такие как грубая сила, несколько неудачных входов или запросов, или повышение привилегий пользователя, могут указывать на злонамеренное поведение.

4. DNS

Протоколирование подробных запросов и ответов DNS может быть полезным по многим причинам. Первая и наиболее очевидная причина - помощь в реагировании на инциденты.

Журналы DNS могут быть очень полезны для отслеживания злонамеренного поведения, особенно на конечных точках в пуле DHCP. Если вы получаете предупреждение с определенным IP-адресом, этот IP-адрес может не быть на той же конечной точке к тому времени, когда кто-то закончит расследование. Это не только приводит к потере времени, но и дает вредоносной программе или злоумышленнику больше времени, чтобы скрыться или распространиться на другие машины.

DNS также полезен для отслеживания других скомпрометированных узлов, загрузок с вредоносных веб-сайтов, а также в случае использования вредоносным ПО алгоритмов генерации доменов (DGA) для маскировки вредоносного поведения и уклонения от обнаружения.

Если вы используете ОС Windows, Sysmon - ваш лучший выбор, когда речь идет о регистрации этого типа трафика.

5. Решения для конечных точек

Решения для конечных точек - иногда называемые EDR, XDR и т.д. - обеспечивают безопасность и защиту конечных точек от вредоносного ПО, атак и непреднамеренной утечки данных в результате человеческих ошибок, часто с использованием автоматизации. Ранние антивирусные программы полагались исключительно на обнаружение на основе сигнатур, но современные инструменты для конечных точек используют комбинацию сигнатур, хэшей, а также идентифицируемых действий и поведения, которые могут быть определены как вредоносные. Как и в случае со многими другими технологиями, необходимо сначала настроить решение для конечных точек самостоятельно, чтобы его эффективность была перенесена на решение для протоколирования.

6. Системы обнаружения и предотвращения вторжений (IDS/IPS)

Обычно IDS/IPS включают на начальных этапах оповещения о кибербезопасности, поскольку их довольно легко настроить, и они часто имеют сотни или тысячи сигнатур или наборов правил.

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

7. Операционные системы

Сбор журналов операционной системы (ОС) конечных точек является обязательным условием для любого типа расширенного обнаружения и мониторинга. Системы на базе Windows и Linux/Unix содержат большое количество локальных журналов, которые могут быть очень полезны во многих отношениях.

• Довольно сложно составить базовую линию любой операционной системы, но после завершения этой работы вы сможете отслеживать и предупреждать о новых невидимых процессах. Это особенно упрощается при использовании качественного решения для конечных точек и стандартных настроек.
• Для ОС Windows Sysmon - это очень ценный и бесплатный инструмент, который может улучшить протоколирование Windows и обеспечить связь по активности с такими компонентами, как MITRE ATT&CK framework. Для сред Linux такое программное обеспечение, как osquery или ossec, может предложить дополнительное протоколирование и обнаружение, например, мониторинг целостности файлов (FIM), который требуется для сред PCI-DSS. FIM - это технология, которая отслеживает файлы и обнаруживает изменения, которые могут указывать на кибератаку.
• Журналирование командной строки - это чрезвычайно мощный способ просмотра подробной информации о том, что выполняется на конечных устройствах. Для Windows его можно использовать для оповещения о запущенных сценариях PowerShell, таких как bloodhound или mimikatz. В Linux можно отслеживать изменения разрешений или запущенные сценарии.

8. Облачные сервисы

Многие облачные приложения для повышения производительности работают по модели предполагаемого доверия и не требуют от пользователей аутентификации таким же образом или с такой же частотой, как локальные приложения, поэтому между пользователем и аутентификацией часто существует менее надежная связь. Для организаций, использующих облачные пакеты для повышения производительности, такие как Google Workspace или Microsoft 365, регистрация облачных служб может помочь выявить модели доступа к этим службам, например:

• Как пользователи проходят аутентификацию в облачных службах, т.е. используют ли они старые клиенты?
• Как пользователи взаимодействуют с файлами в облачных службах, т.е. с кем они обмениваются файлами.
• Приложения для управления паролями, такие как LastPass, могут генерировать полезные журналы, которые определяют, что делают пользователи, где они входят в систему и как они получают доступ к паролям.

9. Учетные записи пользователей, группы и разрешения

• Используйте учетные записи по умолчанию только в случае необходимости, поскольку они считаются общими учетными записями. Оповещение об использовании этих учетных записей без разрешения может указывать на активность неизвестного происхождения. Если в среде необходимо использовать учетные записи по умолчанию, их следует поместить в группу учетных записей, подвергающихся тщательному контролю.
• Вносите изменения в группу администраторов домена в AD только в редких случаях. Хотя вредоносное добавление обычно происходит на поздних стадиях атаки, это все равно жизненно важная информация для оповещения.
• Для любого устройства, имеющего возможность выбора между локальным и централизованным, всегда рассматривайте возможность локальной аутентификации, создания локальных пользователей или добавления в локальные административные группы - особенно в среде с централизованным расположением.

10. Прокси-серверы и брандмауэры

Брандмауэры, прокси-серверы и другие системы, обеспечивающие регистрацию каждого соединения, могут быть очень полезны, особенно при обнаружении неожиданного исходящего трафика и других аномалий, которые могут указывать на угрозу безопасности со стороны инсайдера или уже начавшееся вторжение:

• Исходящие соединения с неожиданными службами могут быть индикатором утечки данных, латерального перемещения или сотрудника, который не прочитал должным образом руководство по допустимому использованию. Опять же, необходим контекст, но часто можно определить подключения к облачным файловым хранилищам, платформам обмена мгновенными сообщениями, службам электронной почты и другим системам по именам хостов и IP-адресам. Если эти соединения не ожидаются, то, вероятно, они заслуживают дальнейшего расследования.
• Сопоставление IP-адресов или имен хостов с черными списками является несколько спорным, поскольку черные списки, как правило, не полны и не актуальны. Однако, например, наличие соединений с известной командно-контрольной инфраструктурой для вредоносных программ часто является признаком заражения рабочей станции.
• Соединения неожиданной длины или пропускной способности могут быть индикатором того, что происходит что-то необычное. Например, запуск SSH на порту 443 может обмануть многие прокси-серверы и брандмауэры, однако средняя сессия HTTPS не длится шесть часов, и даже сайт, который остается открытым в течение длительного времени, обычно использует несколько небольших соединений. SSH-соединение с нестандартным портом вполне может показаться длительным и с низкой пропускной способностью.