Журнал "Information Security/ Информационная безопасность" #4, 2024

SIEM буквально должна только вычитывать и сопо- ставлять события из разных источников. От нее не тре- буется глубокое расследова- ние атак, аварий, компроме- таций, если они выходят за рамки периметра. Выяснение мотивов и логики киберпреступников – не задача корпоративной ИБ. Ловить и выслеживать хакеров – прерогатива спе- циальных органов. А компа- ниям первостепенно – защи- щаться. Вспомним основы Основная задача SIEM – мониторинг событий безопасности, выявле- ние и управление инци- дентами. Происходить это должно в три этапа. 1. SIEM подключается к источ- никам в ИТ-инфраструктуре. Источниками могут выступать ПО, оборудование, сетевые узлы, сторонние ИБ-системы. SIEM должна уметь вбирать в себя максимум, чтобы провести полную инвентаризацию конт- ролируемой инфраструктуры. А затем привести все получен- ные данные к однородному и читаемому виду, чтобы эффек- тивно с ними работать – это этапы агрегации и нормализа- ции данных. 2. SIEM отбирает в потоке данных из источников инфор- мацию о событиях, потенциаль- но влияющих на ИБ, – это так- сономия – этап, на котором система структурирует получен- ные данные по типам, чтобы затем соотнести их между собой, за что, в свою очередь, отвечают автоматические пра- вила. Хорошо, если пользова- тель может создать собствен- ные правила или импортировать классификацию событий из источника. 3. SIEM сопоставляет события безопасности, чтобы обнару- жить инцидент. Система делает это на основе правил корреля- ции – алгоритмов, которые находят взаимосвязь между событиями в одном или нескольких источниках. Напри- мер, если в течение пяти минут за ПК более десяти раз срабо- тало правило "ввод неправиль- ного пароля", то, возможно, это попытка взлома с помощью брутфорса. Или, если в течение часа на нескольких ПК выклю- чился антивирус, и началось массовое изменение файлов, то это признак работы шифро- вальщика. После выявления инцидента SIEM оперативно уведомляет о нем службу ИБ. SIEM буквально должна толь- ко вычитывать и сопоставлять события из разных источников. От нее не требуется глубокое расследование атак, аварий, компрометаций, если они выхо- дят за рамки периметра. Однако, при избытке данных об инциденте логично желание их проанализировать, чтобы докопаться до причин, устано- вить виновников и их мотивы. Отсюда – запрос заказчиков на расширение возможностей расследования. К тому же, раз SIEM обнаруживает проблемы, то можно ожидать их решения в той же консоли – напраши- вается функционал реагиро- вания. И наконец, имея полную картину происходящего в инфраструктуре, хочется знать, откуда ждать проблем, а имен- но прогнозировать инциденты и проактивно их предотвра- щать. Это логичный путь развития систем, и фактически по нему идут все вендоры. На первый взгляд это очевидный плюс – заказчику так удобнее. Но увле- чение такими улучшениями гро- зит увести SIEM от решения первоначальных задач, что в итоге снизит ее эффективность. Рассмотрим, каким образом. Обратная сторона роста Для начала приведу простой пример. Многие SIEM сегодня внедряют сценарии развития инцидентов по матрице MITRE ATT&CK. Эти сценарии дополняют правила обнаруже- ния инцидентов и основаны на пошаговом анализе хода атаки – действий, которые злоумыш- ленник совершит в инфраструк- туре. По идее, это дает продви- нутые возможности расследо- вания, но на практике ряд SIEM с внедренной матрицей MITRE ATT&CK предлагают игнорировать незначительные события ИБ, пока они не сло- жатся в сценарий. Например, ждут, пока брутфорс пароля учетной записи завершится успехом, чтобы точнее опреде- лить, в чем цель атаки, какой элемент инфраструктуры будет атакован следующим, и где нужна особая защита. Но что важнее: определить чего хочет преступник или остановить его сразу, не допустив ущерба? Выяснение мотивов и логики киберпреступников – не задача корпоративной ИБ. Ловить и выслеживать хакеров – преро- гатива специальных органов. А компаниям первостепенно – защищаться. Получается, что SIEM, которая работает по мат- рице, отнимает у ИБ-отдела время на оперативное противо- действие угрозе. 20 • СПЕЦПРОЕКТ Парадокс возможностей: как развитие SIEM угрожает задачам заказчиков огда компания закупает ИБ-систему и активно ей пользуется, аппетиты тоже начинают расти: хочется, чтобы система могла все больше, решая максимум задач в одном окне. При этом возникает риск, что дополнительные функции вытеснят основные. Рассмотрим на примере SIEM, как рынок размывает задачи систем и выводит их за рамки своего класса, и что в таком случае лучше выбрать заказчикам. К Павел Пугач, системный аналитик “СёрчИнформ” Фото: СёрчИнформ