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

Большинство SOC, к сожалению, очень хорошо умеет вычислять число инцидентов событий с тече- нием времени, но очень плохо занимается измерени- ем непосредственно времен- ных метрик. Число временных метрик, в зависимости от этапа про- ведения анализа и рассле- дования инцидента, может быть разным. Например, если свести все этапы рабо- ты с инцидентом в таблицу и визуализировать их, то мы поймем, что измерять мы можем любые временные интервалы между всеми указанными этапами, выявляя слабые места в наших процессах реагиро- вания на инциденты. более серьезным для бизнеса инцидентам. Завершается вре- менная шкала фактом закрытия инцидента и устранением при- чин, повлекших за собой появление инцидента, попав- шего в центр мониторинга. Большинство SOC, к сожале- нию, очень хорошо умеет вычислять число инцидентов событий с течением времени, но очень плохо занимается измерением непосредственно временных метрик, а точнее конкретных показателей на показанной временной шкале. Указанные три основные вре- менные метрики (Time-to-Detect, Time-to-Triage, Time-to-Contain) на самом деле представляют только верхушку айсберга. Число временных метрик, в зависимости от этапа прове- дения анализа и расследования инцидента, может быть разным. Например, если свести все этапы работы с инцидентом в таблицу и визуализировать их, то мы поймем, что измерять мы можем любые временные интервалы между всеми ука- занными этапами, выявляя сла- бые места в наших процессах реагирования на инциденты. Такая декомпозиция времен- ных параметров будет полезна и на нижележащих уровнях, например при оценке эффек- тивности работы по конкретно- му Рlaybook (руководству по конкретному типу инцидента). Допустим, у вас есть Рlaybook для анализа подозрительной активности пользователя и среднее время реагирования на нее (от момента получения сиг- нала в SIEM и до заморажива- ния учетной записи в AD, поме- щения узла в карантинный VLAN и поиска других узлов и пользователей, которые могли быть связаны с пострадавшим) у вас – около 28 мин. Вы смот- рите статистику по отработан- ным инцидентам и видите, что этот показатель немного скачет в диапазоне от 19 до 37 мин., но в среднем составляет те же 28 мин. Вроде все в порядке. Но если бы у вас была воз- можность мониторить все отдельные шаги/задачи Рlay- book, то вы бы увидели, что вместо традиционных 1–3 мин. на выявление индикаторов, 1–3 мин. их проверки в TI-плат- форме, 1–2 мин. на принятие решения, 3 мин. на заморажи- вание учетной записи в AD и т.п. ваш аналитик сразу после получения сигнала тревоги помещает пользователя и его узел в карантин, а то и вовсе без проверки передает инци- дент на следующий уровень, аналитикам второй линии (L2). И вообще непонятно что анали- тик делал оставшиеся 9–10 мин. То ли он пошел на кухню налить себе кофе, то ли он решил посмотреть новости на смарт- фоне, а может он просто отпра- вился проветриться или посмот- реть на солнце после несколь- ких часов "самоизоляции" в душном помещении. Но имею- щаяся у вас метрика по кон- кретному инциденту соблюдена. Поэтому так важно оценивать не процесс целиком, а его отдельные этапы, проводя декомпозицию. Средние значения Кстати, вы заметили, что аббревиатуры, описывающие метрики, начинаются с буквы M? Это сокращение от Median, то есть не среднее арифмети- ческое, а медиана, которая гораздо лучше покажет, насколько часто параметры выходят за средний показатель. Почему мы говорим о меди- анных значениях, а не о сред- нем арифметическом? Этот показатель лучше отражает временные показатели в боль- ших выборках с широким раз- бросом значений. Именно он, а не среднее арифметическое, которым так часто манипули- руют. Например, вы встречаете в каком-нибудь отчете тезис, что средняя сумма инцидента ИБ составляет 11 млн руб. (цифра взята с потолка). Авторы отчета умалчивают, что они имели в виду под средним, но чаще всего они, недолго думая, просто делят сумму по всем инцидентам на число инциден- тов. Является ли это действи- тельно средним? Увы. В данной ситуации средним должна быть медиана – именно она наиболее точно показывает среднестати- стическую компанию. Давайте проиллюстрирую. Представим, что у нас 10 ком- паний сообщили об инцидентах ИБ. У девяти компаний размер ущерба составил 1 млн руб., а у десятой – 100 млн руб. Среднее арифметическое будет равно 10,9 млн, а вот медиана – одному миллиону. И именно медиана отражает реальную картину размера ущерба (медиана может совпадать со средним арифметическим при симметричном распределении сумм ущерба у компаний). Другой пример. Мы измеряем среднее время обнаружения инцидента, то есть метрику Time-To-Detect (TTD). Среднее арифметическое для данного графика будет 8,81 часа. Но значит ли это, что оно действи- тельно среднее? Нет. Медиана, то есть типичное значение TTD, будет в данном примере равно двум часам. При этом худший показатель TTD будет равен 42, а лучший – 0,1 часа на обнаружение. Но стоит помнить, что для разных угроз/инцидентов эти значения будут разные (хотя их и можно свести к некому еди- ному показателю). Это по тре- бованиям ФСБ в ГосСОПКA данные передаются в течение 24 • УПРАВЛЕНИЕ Рис. 2. Рис. 3.