
Эксперты TS Solution рассказали об особенностях и функционале продукта McAfee Enterprise Security Manager:
1. Архитектура и основной функционал составных элементов продукта
Продукт состоит из следующих компонентов, часть из которых обязательна, часть рекомендована к использованию, чтобы воспользоваться всем функционалом McAfee SIEM:
· McAfee Enterprise Security Manager — основной компонент системы (обязателен);
· McAfee Event Receiver — сбор и нормализация сырых событий (обязателен);
· McAfee Enterprise Log Manager — хранение сырых событий (рекомендован);
· McAfee Enterprise Log Search — поиск по сырым событиям (опционален);
· McAfee Advanced Correlation Engine (McAfee ACE) — дополнительные возможности по корреляции событий (рекомендован);
· McAfee Application Data Monitor — мониторинг данных 7-го уровня OSI для обнаружения угроз на уровне приложений (опционален).
2. Дашборды и Content Packs
После установки McAfee пользователю сразу доступны наборы дашбордов, среди которых для начала работы потребуются “Normalized Dashboard”, чтобы отобразить нормализованные события в системе, также “Incidents Dashboard”, чтобы отобразить скоррелированные события.
Из полезных особенностей -- возможность кастомизации виджетов и дашбордов и возможности для более детального анализа данных виджета -- “Drilldown”. Присутствует возможность открыть кейс во встроенной системе ведения тикетов напрямую из дашборда. Можно добавить данные по событию в “Watch list” напрямую из дашборда. Кроме того, вы можете запустить “Remote Command” напрямую из дашборда. Еще система может загружать “Content Pack” – наборы преднастроенных правил, дашбордов для каких-то целей или работы с конкретными источниками.
3. Подключение источников
Прежде чем получить события и производить их анализ нам необходимо добавить источники, это можно несколькими способами:
1) Система слушает на интерфейсе с каких источников приходят события и по какому протоколу, после получения каких-либо событий можно или в автоматизированном, или в ручном режиме добавить эти источники.
2) Добавить источник событий вручную из большого перечня готовых коннекторов, выбирая производителя и протокол передачи событий.
4. Threat Intelligence
Для выявления инцидентов нам могут потребоваться различные индикаторы компрометации и различные внешние фиды. Фиды можно подключить через функционал “Cyber Threat Feeds” – мы выбираем источник информации, способ подключения (к примеру, TAXII), частоту обращения и указываем какую конкретно информацию в каких “Watch list” мы добавляем. (“Watch list” – это статические или динамические наборы данных, которые мы можем использовать, к примеру, в правилах корреляции для выявления инцидентов.
5. Правила корреляции
Правила корреляции служат для выявления инцидентов, у McAfee ESM есть преднастроеннные правила, которые доступны сразу после установки продукта. Написание собственных правил корреляции происходит в графическом интерфейсе с использованием фильтров и логических элементов.
6. Оповещения
В продукте конечно же присутствует возможность гранулированного создания отчетов, но мы посмотрим немного более интересный функционал:
· Отсылка оповещений в telegram: создаем “Alarm” в котором указываем имя, критичность, триггер запуска (в нашем примере это срабатывание одного из созданных правил корреляции), выполнение удаленных команд – и указываем ссылку для отправки информации в наш telegram канал.
· Выполнение удаленных команд. Обычно нам мало детектировать угрозу и мы хотели бы иметь возможность автоматизировано остановить атаку, поэтому рассмотрим пример, когда у нас срабатывает правило корреляции и как результат мы отправляем на NGFW Check Point команду блокировки Destination IP адреса на определенное время: создаем “Alarm” в котором указываем имя, критичность, триггер запуска (в нашем примере это срабатывание одного из созданных правил корреляции), выполнение удаленных команд – и указываем выполнение команды на NGFW.
7. Работа с инцидентами
После того как мы получили события с источников, выявили инцидент, получили оповещение, нам нужно назначить сотруднику новый инцидент, по которому он будет вести работу и в завершение закроет данный инцидент. McAfee может как интегрироваться со сторонними системами обработки тикетов, но также существует встроенная система создания кейсов по работе с инцидентами и их отслеживание. Выше мы отметили возможность создать тикет вручную из события в дашборде, но также можно настроить автоматизированное создание кейсов согласно нужным критериям, это происходит через создание “Alarm”, но в действие указываем “Create Case” и указываем кому из сотрудников назначать данные кейсы и какую информацию добавить в описание кейса. Отслеживать в каком статусе и кому назначены инциденты можно из дашборда “Case Management Summary”.
8. API
У McAfee ESM есть API которым можно воспользоваться для интеграции продукта со сторонними системы или для автоматизации каких-либо задач. Первым шагом необходимо пройти этап аутентификации, после чего уже можно будет отправлять запросы на выполнение каких-либо операций.
9. Заключение
Посмотрев на работу McAfee SIEM можно отметить, что система интересна большим количеством контента, доступным «из коробки», дружелюбностью интерфейса и простотой настройки базового функционала:
· Большое количество различных интерактивных дашбордов;
· Большое количество коннекторов для стандартных систем с простой процедурой их включения;
· Графический интерфейс настройки правил корреляции;
· Возможности выполнения удаленных команд по различным критериям;
· Встроенная система ведения тикетов.
Система отлично впишется в любую инфраструктуру. Если вы уже задумались о необходимости выявлений инцидентов информационной безопасности, но не имеете большого опыта работы с системами класса SIEM, этот продукт станет отличным решением.
https://tssolution.ru/blog/mcafee-security-information-and-event-management
Никто пока не комментировал эту страницу.
В стандарте [6] предусмотрено присваивать различным документам вида «расчет» код[1] документа РР, а для локальной сметы код документа ЛС.
Никакой необходимости использовать код Б для обозначения документов, в названии которых нет слова «Обоснование», не существует, а отсутствие документов, в названии которых использовано это слово подтверждает, что из ГОСТ 34.201-2020 должен быть исключен фактически не существующий документ «Обоснование».
Литература:
6 ГОСТ Р 21.101-2020 Основные требования к проектной документации
7 Н. Зенин. Судьба требований ГОСТ 34-й серии в проектах по информационной безопасности // [Электронный ресурс], режим доступа: https://www.anti-malware.ru/practice/methods/GOST-requirements-34th-series-in-information-security-projects
[1] В данном стандарте вместо термина «код документа» используют словосочетание «шифр документа»
Разработчики стандартов иногда предлагают новые виды документов, объясняя это тем, что существующих видов документов недостаточно для новых изделий. Например, в таблице 1 стандарта [1] перечислены несколько видов документов, разрабатываемых для автоматизированных систем (далее АС). Обратим внимание на документ «Обоснование» (код документа Б). Его назначение определено так:
«Изложение сведений, подтверждающих целесообразность принимаемых решений»
Отметим, что в числе толкований значений слова «обоснование» есть и тексты, служащие основанием для принятия решения.
Какие же текстовые документы приведены в таблице 2 стандарта [1], где перечислены конкретные документы?
Как ни странно, но документа со словом «обоснование» в названии нет ни в стандарте [1] нет, как нет его и в отменном руководящем документе [2].
Слово «обоснование» в [2] использовано в названии раздела отчета, разрабатываемого на стадии формирования требований к АС – Обоснование необходимости совершенствования информационной системы объекта.
«Обоснование» содержится ещё в двух стандартах [3, 4], где применено в названии этапа работы – Обследование объекта и обоснование необходимости создания АС.
Отметим, что в cтандартах [3, 4] обоснование необходимо для вынесения технико-экономической, социальной и т.п. оценок на стадии формирования требований к АС.
При этом сам документ, содержащий результаты обоснования, оформляют в виде отчета по ГОСТ 7.32 [5], а не в виде документа вида «Обоснование».
Обратимся теперь к стандарту [1] и посмотрим какие же документы с кодом Б (присвоен документу «Обоснование») указаны в таблице 2:
- локальный сметный расчет (код Б2);
- проектная оценка надежности системы (код Б1);
- локальная смета (код Б3).
Из перечисления видно, что ни в одном из названий этих документов с кодом Б нет слова «Обоснование».
Продолжение следует