Когда мы говорим о KPI и эффективности, возникает вопрос: что SOC должен отслеживать в своей повседневной деятельности? С одной стороны, здесь все понятно: во-первых, соблюдение SLA, во-вторых, возникающие события с подозрениями на инциденты.
Но статистику событий можно рассматривать с разных сторон.
А еще проблемы с источниками, а еще аномалии, а еще нагрузка на SIEM и т. д. – массовые параметры.
Какие из них достойны дашборда аналитика – об этом поговорим ниже.
Мониторинг выполнения SLA
Первое, что приходит на ум, — это степень соблюдения SLA. Этот параметр нужно отслеживать на всех этапах: запись и анализ событий ИБ, оповещение заказчика, решение инцидента, проведение расследования и т.д. И здесь нужно видеть не только среднее время (а еще лучше медиану) , но также максимальное и минимальное значения.Разумеется, должна быть возможность увидеть выполнение SLA по каждому инциденту, чтобы проанализировать и выяснить, в каких случаях оно нарушается.
Понятно, что одного только времени отслеживания недостаточно — нужно вести статистику изменения количества инцидентов, по которым был нарушен SLA. Другими словами, при подключении клиента мы прописываем SLA не только на услугу в целом, но и на каждое конкретное событие ИБ (в этом случае нас интересует информация о том, что это был за инцидент и при каком моменты, когда он менял свой статус).
Таким образом, мы сможем таргетировать людей, чтобы понять, кто «виноват» и в какой момент в процессе произошел сбой, чтобы сразу выявить причины.
Что ж, подстелите соломку, чтобы избежать такого «счастья» в будущем.
Мы ведем статистику событий информационной безопасности
Такая статистика даст понимание того, насколько компания подвержена внешним и/или внутренним атакам, на какие объекты они направлены (а это уже может стать стимулом для оптимизации внутренних процессов информационной безопасности заказчика).И здесь нам важно понять:
- что такое нормальное поведение систем/пользователей и на что следует обратить внимание;
- сколько вообще происходит событий ИБ;
- о скольких случаях мы сообщаем клиенту о предполагаемых инцидентах;
- какие события наиболее распространены;
- где они происходят;
- насколько затронуты важные для клиента активы (иногда коммерческий SOC знает инфраструктуру клиента лучше, чем сам клиент);
- какие подразделения участвуют в событиях в качестве жертв и источников;
- в какой момент происходят всплески количества событий, почему это происходит, есть ли в этом какая-то закономерность и можно ли с этим что-то сделать.
Отдельно смотрим статистику по событиям, признанным инцидентами.
Есть множество разделов, в которых мы можем посмотреть статистику: категории и статусы событий; внешнее нападение или внутренний инцидент; критичность; соглашение об уровне обслуживания; хосты или пользователи, затронутые событиями; затронутые системы или агрегаты; источники, от которых были получены события ИБ и т.д.
Смотрим на реакцию клиента
Здесь мы отслеживаем, сколько времени занимает реакция клиента на наше уведомление о возможном инциденте ИБ, и ведем статистику уведомлений, которые остались с его стороны без ответа.Это необходимо, прежде всего, для построения эффективного взаимодействия.
Например, если клиент не следит активно за нашими оповещениями, то в случае критического инцидента мы будем использовать все доступные каналы связи, чтобы уведомить его.
Кроме того, в некоторых компаниях есть внутренние KPI для реагирования на сообщения SOC, и наша статистика оказывается очень востребована в этой области.
В зависимости от того, как отреагирует заказчик (распознает событие как инцидент, легитимную активность или ложное срабатывание), мы корректируем правила.
То есть мы понимаем, какое событие ИБ является нормой и может быть включено в качестве исключения, а какое является критическим инцидентом, о котором заказчика необходимо уведомить не только по электронной почте, но и более своевременно, для например, по телефону.
Что еще?
Для себя мы выделили еще несколько параметров, которые считаем важным отслеживать на дашбордах.Давайте по порядку.
1. Запуск сценариев, на основе которых формируется итоговое событие ИБ.
Если сценарии по каким-то причинам больше не работают, нужно вовремя это увидеть.
Таким образом, мы можем заметить неисправности и исправить их.
Есть также сценарии, которые раньше никогда не срабатывали/работали крайне редко, а вдруг случилось впервые/участилось.
Причины таких аномалий также требуют выяснения.
Когда это наглядно показано на приборной панели, отслеживать такие моменты гораздо проще.
И в итоге мы можем выявить инцидент, который ничто не предсказывало.
2. Аномалии поступления событий ИБ от источников.
Здесь мы не только следим за полным отсутствием событий от источника, но и автоматически сравниваем этот период «молчания» со статистикой «нормального» поведения источника.
А если «пауза» слишком длинная, стоит выделить ее на приборной панели.
Так мы сможем быстро отреагировать и вовремя восстановить работу источника.
В противном случае может возникнуть ложное ощущение, что событий нет, а значит, все хорошо и никто на нас не нападает. Но на самом деле причин такого молчания может быть много – от некорректного вмешательства ИТ-службы заказчика в инфраструктуру до деятельности злоумышленника, который, например, написал вредоносное ПО таким образом, что оно обходит некоторые пункты в правило.
Давайте не расслабляться! Динамика получения событий также является важным показателем.
Есть такая любопытная вещь: события вроде бы есть, но в их течении наблюдаются загадочные «просадки» или «провалы».
Лучше вовремя заметить такую картину на графике, чтобы потом не пропустить происшествие.
3. Конкретные исходные данные.
Просматривая информационные панели для конкретных источников, мы можем сравнить собранные ими события с тем, что SIEM считает инцидентами.
Здесь мы анализируем, какие события были обработаны правильно, а какие необходимо добавить в корреляцию для выявления инцидентов.
Мы выносим сырую статистику из инструментов безопасности на дашборд и сравниваем, сколько атак было ими заблокировано и сколько поступило в SOC. Таким образом, дашборд должен показывать общий уровень (количество и сложность) атак на клиента и сколько атак требуют его реагирования.
То есть сколько было выполнено и сколько дошло до заказчика.
4. SIEM-нагрузка.
В SIEM-системе можно написать множество красивых скриптов и правил, которые будут отлично работать.
Но при этом они могут его очень сильно нагрузить, а в какой-то момент и вовсе остановиться, и линиям мониторинга будет сложно с ними справиться.
Поэтому статистику по загрузке правила необходимо показывать явно на приборной панели — в этом вопросе лучше переосторожиться, чем недоосторожно.
Ну а дальше смотрим и анализируем, как менялась нагрузка каждого правила.
Мы отслеживаем влияние на SIEM-нагрузку корректировок внутри правила и внешних изменений (например, если произошли изменения в инфраструктуре клиента или правило было запущено для нескольких клиентов).
На основании этого делаем выводы: нужно ли такое правило вообще (и в нынешнем виде в частности), не проще ли его полностью отключить или модифицировать.
5. Массированные атаки.
Когда у вас много клиентов по стране или даже миру, имеет смысл создать дашборд с картой, на которой можно отслеживать массу атак.
На карте будет отображаться информация о возникающих инцидентах, координатах начала атаки (IP-источника) и ее цели (IP-адреса назначения) практически в реальном времени.
Если векторов на карте слишком много, мы видим массированные атаки.
Бывает, что все они исходят из одной точки, но направлены в разные.
Бывает и наоборот. Для наглядности эти векторы лучше выделить разными цветами в зависимости от критичности инцидента.
Елена Трещева, ведущий аналитик Solar JSOC Теги: #информационная безопасность #sla #метрики #безопасность #siem #siem #SIEM #оценка производительности соц #центр операций безопасности
-
Советы По Зависимости От Компьютерных Игр
19 Oct, 24 -
Денежный Ящик – Объективный Обзор
19 Oct, 24 -
Расширения Firebug
19 Oct, 24
