Что общего между SOCом и онлайн-мероприятием по ИБ? Ложь в цифрах!

Выборы президента США навели меня тут на рассуждения о том, как умело манипулируют цифрами то демократы, то республиканцы и как это похоже на то, что происходит в центрах мониторинга ИБ, а именно при визуализации ключевых показателей эффективности SOC. Аналогичные манипуляции используют и организаторы онлайн-мероприятий по ИБ, которые пытаются их продавать, используя все те уловки, что и при подсчете голосов или числа инцидентов. Ведь иначе свой "продукт" не продашь. А покупают его все хуже и хуже, так как просто пустить говорящую голову в Zoom или Webinar.ru (даже если она моя ;-), - это еще не значит провести достойное мероприятие. Ни особых фишек, ни кулуаров, ни чего-то еще, что могло бы действительно привлечь аудиторию...

Собственно аналогия с мероприятиями у меня возникла не на пустом месте. Попросили тут меня провести для одной компании вебинар по повышению осведомленности сотрудников в области ИБ, пообещав загнать туда около 400 человек, почти весь свой персонал. Для этого они были готовы привлечь HR, который должен быть разослать сообщение по всем сотрудникам, большинство из которых находилось на удаленке. Сказано - сделано. В день мероприятия я подключаюсь к платформе (это был Zoom) и вижу там 36 человек. Мда, - думаю. "Прекрасный" результат, отражающий все отношение сотрудников компании к ИБ. До конца мероприятия осталось 32 человека (достаточно неплохой результат - 89%). Каков эффект от мероприятия мне неизвестно, но в письме, которое служба ИБ направила своему руководству, фигурировало число 400, красиво обернутое фразой "информация о мероприятии была доведена до 400 человек" :-) Но мы же прекрасно понимаем, что это совсем не то, что было в реальности. Аналогичная ситуация и с онлайн-мероприятиями, а я за последние почти 9 месяцев поучаствовал в многих из них.

Их организаторы обычно хвалятся числом регистраций. Это примерно как хвалиться числом событий ИБ, которые фиксируют ваши средства защиты. Например, в инфраструктуре Cisco фиксируется ежедневно 1,2 триллиона событий ИБ. Это, на минуточку, в 3 раза больше чем звезд в нашей галактике "Млечный путь". Круто, не правда ли? Но вот только мы прекрасно понимаем, что из этих событий ИБ многие ложные, а многие вообще малоинтересны. Мы должны все эти события просеять через различные фильтры, убрав ложные срабатывания, проведя анализ и корреляцию, а после из оставшихся реальных инцидентов выбрав только критичные. В итоге, в Cisco остается на отработку нашим SOCом всего 22 инцидента в день. Так вот с онлайн-мероприятиями необходимо использовать ту же саму "воронку продаж", только вместо "клиентов" использовать слушателей.

Не так важно, сколько человек зарегистрировалось, важнее, сколько из них вообще пришло на вебинар. Кто-то из организаторов говорит, что у них офигенная конверсия, если удается заполучить на вебинар больше 50% от числа регистраций. Это еще одно лукавство организаторов онлайн-мероприятий. Считать надо не число пришедших, а число дослушавших до конца. Причем именно дослушавших, а не досидевших. Вы же понимаете разницу, да? Первые держали окно плейера или вкладку браузера поверх всех остальных окон и, скорее всего, слушали вебинар (конечно, есть вероятность, что они просто свалили пожрать в это время, но это отдельная тема). А вот вторые могли просто включить вебинар, отключить звук и заниматься своими делами. Поэтому, говоря об эффективности онлайн-мероприятия хвалиться надо не числом регистраций (хотя эта цифра лучше продается), а числом активно дослушавших до конца.

В SOC ровно тоже самое - показывать надо не число событий безопасности, и даже не число инцидентов, а число тех инцидентов, которые не были закрыты в течение заданного для данного типа инцидента времени. Именно это будет показывать один из срезов реальной работы SOC. Хотя этот показатель может быть и не очень приятным. В идеале он должен быть равен нулю; как и число активных слушателей вебинара должно быть в идеале равно числу регистраций (а лучше числу разосланных приглашений). В реальности он обычно сильно отличается, может быть на порядки, от первоначального числа, которое все и показывают. Кстати, если говорить о платных онлайн-мероприятиях (для вендоров/интеграторов, покупающих их у организаторов), то там для их покупателей гораздо более важным показателем будет считаться число сделок после вебинара; или хотя бы число лидов после него. А иначе зачем платить деньги за вебинар, если он не приносит покупателей? 

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

Вот пример с повышением осведомленности и более глубокая статистика, чем просто число регистраций. Для анализа использовался сервис Cisco Webex Events (не путать с Webex Meetings - разница именно в фишках для организации мероприятий), который по каждому мероприятию позволяет собрать полноценную статистику, из всего объема которой нас в контексте данной заметки интересует всего три показателя. Первый - длительность участия в мероприятия с момента входа до момента выхода. Для одного из Security Awareness тренингов, длившихся чуть более двух часов (почему так долго - это отдельный разговор), статистика выглядит следующим образом. Метрика "среднее время нахождения на мероприятии":

Четверть слушателей только половину тренинга отсидела и свалила. Второй важный показатель - это время, в течение которого Webex находился поверх других окон, то есть иными словами это реальная активность слушателя. Истинная картинка такая:

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

В заключение хочу повторить мысль, с которой я начинал заметку. Понятно, что красивые и большие числа всегда интереснее небольших. Именно первые хочется вынести на дашборд SOC или отобразить в отчете службы ИБ; а организаторам онлайн-мероприятий показать покупателям. Но увы, как и в случае с выборами, надо смотреть за пределы этих очевидных KPI. Тогда оценка эффективности будет более эффективной. Уж простите за тавтологию...

Подробнее…

Презентация ИБ для руководства (видео с CISO Forum)

Продолжим вчерашнюю тему про дашборды для руководства, но выйдем за рамки темы АСУ ТП. Сегодня я выложил видеозапись своего выступления (оно вдвое длиннее, чем на Kaspersky ICS Security Conference) с CISO Forum, прошедшем в этом сентябре, в рамках которого я вновь коснулся темы дашбордов, но уже в более расширенном варианте. 

Презентацию этого выступления я уже выкладывал. 

Подробнее…

Создание дашбордов по ИБ АСУ ТП, понятных руководство (видео)

В начале сентября, первым моим очным мероприятием стала конференция Лаборатории Касперского Kaspersky ICS Security Conference, где я выступил на тему дашбордов по ИБ АСУ ТП. Свою презентацию я выкладывал раньше, а сейчас подошло время и для видеозаписи.

Это мое выступление по сути продолжает прошлогоднее, в котором я рассказывал про измерение эффективности ИБ АСУ ТП. Поэтому я дам ссылку еще и на него, чтобы можно было сложить А и Б, то, что мы измеряем, и то, как мы это визуализируем. Оказалось, что я видео этого выступления в блоге не выкладывал, так что исправляюсь.

ЗЫ. Остальные видеозаписи с Kaspersky ICS Security Conference 2020 можно посмотреть в плейлисте на Youtube (постепенно туда выкладывают обработанные записи докладов).

Подробнее…

Презентация по ИБ для руководства компании (презентация)

 В пятницу, на CISO Forum, я завершал это отличное мероприятие мастер-классом о том, как надо готовить презентации и отчеты по ИБ для руководства компании. Тема эта непростая и за один час изложить ее непросто, но я попытался показать отдельные важные моменты. Рассказал и про то, на чем делать акцент, и что в отчете обязательно нужны KPI/КПЭ, привлекающие внимание, и как увязать KPI по ИБ с KPI топ-менеджера, и как учитывать интересы целевой аудитории и многое другое. Но все-таки час - это час. Границы времени не расширишь и многие практические лайфхаки остались за кадром. Уже подумываю над созданием однодневного курса по этой теме с практическими занятиями.

А пока выкладываю презентацию - на Slideshare и в канал в Telegram.   

Презентация по ИБ для руководства компании from Aleksey Lukatskiy

Подробнее…

Дашборды по ИБ АСУ ТП (презентация)

После почти двухмесячного молчания в блоге, компенсированного активностью в Twitter  и Telegram, возвращаюсь и на эту площадку :-) И начну с выкладывания презентации, которую я читал на Kaspersky ICS Security Conference. Посвящена она дашбордам по ИБ АСУ ТП, хотя ее положения могут быть без особых отличий применяться и не только в АСУ ТП, так как принципы визуализации и донесения информации до лиц, принимающих решения, мало чем отличаются от отрасли  к отрасли. Времени было не так много - всего 30 минут, поэтому не удалось рассказать все, что хотел, но главное все-таки успел.

Небольшая зарисовка. После доклада ко мне подошел человек из команды организаторов, могу ошибаться, но возможно это был кто-то из звукорежиссеров, и сказал, что "даже он понял" мой доклад, так было все разжевано и по делу рассказано. Пустячок, а приятно :-)

Скоро коллеги из Лаборатории Касперского выложат видео этого доклада (кто не смог вчера его посмотреть вживую или в онлайн-трансляции), а я пока выкладываю на Slideshare саму презентацию. У кого нет доступа к Slideshare (хотя обойти блокировку РКН сегодня не представляет большого труда) и кто не готов ждать 24-го сентября, когда все презентации Slideshare будут интегрированы в сервис Scribd, могу порекомендовать зайти ко мне в канал Telegram, куда я выложил презентацию в виде pdf. 

Дашборды по ИБ АСУ ТП from Aleksey Lukatskiy

Подробнее…

О дашбордах для SOC - часть 4. Инциденты и тикеты

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

Но только попробую. Потому что тема визуализации этой темы достаточно объемна и, самое главное, зависит от целей этого самого мониторинга и реагирования. Можно ограничиться только визуализацией числа инцидентов ИБ, которые обрабатывает SOC (можно даже с динамикой изменения этого числа). Например, вот так:

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

Смотря на рекламные материалы некоторых аутсорсинговых SOCов, удивляешься, когда SOC пишет, что они за 15 минут реагируют на инцидент. Тут либо манипуляция терминами и под словом "реагирование" они понимают "принимают в обработку" (но тогда чем тут хвалиться)? Либо речь идет о непонимании реальной работы SOC, в котором время принятия инцидента в обработку может составлять минуты (пока прилетит сигнал тревоги в SIEM, пока он скоррелируется, пока он приоритезируется). Поэтому одной из важных метрик в SOC будет время принятия инцидента в обработку первой линией. Виджет, который это будет показывать, может выглядеть так:

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

Но этот виджет показывает нам текущее значение (за указанный интервал времени), не говоря ни слова о том, какое число инцидентов из общего их числа было взято вовремя. Для этого может подойти вот такой виджет: Опять же, зеленая/красная направленная стрелка показывает нам улучшение или ухудшение (а не рост или падение) этого показателя, а зеленый или красный цвет числа покажет, вышли ли мы за установленные целевые значения или нет. Если накапливать этот показатель в течение времени, то можно будет еще строить динамику его изменения.  

Данный виджет может быть интересен не только в его абсолютном значении. Мы можем захотеть понять, от чего зависит несвоевременность принятия инцидентов в обработку. Например, может оказаться так, что аналитики перегружены инцидентами и не успевают их отрабатывать, что приводит к переполнению очереди и нарушению установленного SLA. А может быть несвоевременность связана с усталостью аналитика? Тогда надо анализировать предыдущий показатель в привязке к времени суток. Выглядеть это может так:

Если инцидент не был разрулен на первой линии SOC, то он передается на вторую линию (не эскалируется, как ошибочно считают многие). Посколько аналитиков второй линии в SOC обычно меньше (бывают исключения) и они дороже обходятся компании, то их избыточная нагрузка может негативно сказаться на показателях работы SOC. Аналитики L1 могут по ошибке, незнанию или умышленно передавать даже простые инциденты на вторую линию, чтобы соблюсти свои показатели деятельности (своевременно закрыт инцидент). Поэтому нам надо отслеживать, какие инциденты передаются на L2 и по какой причине, например, так:

По идее у вас должна быть выстроена воронка инцидентов, когда по мере перехода от L1 к L2 и L3  число инцидентов существенно сокращается. 

Еще одним интересным виджетом может стать "занятость аналитика". Обычно мы считаем, что человек работает весь рабочий день, с 9-ти до 6-ти или с 9-ти до 9-ти или в каком-то ином режиме, в зависимости от длительности смен. На самом же деле, может оказаться так, что аналитик отлынивает от работы, много времени отдыхает, перекуривает и т.п. Поэтому занятость аналитика, которая оценивается как отношение суммарного времени, затраченного на работу с инцидентами (легко оценивается в IRP/SOAR-платформе), к общей длительности смены, является очень хорошим показателем. На виджете ниже вы видите, как его можно визуализировать. Мы видим не только текущее значение для всех аналитиков или какого-то конкретного из них, но и целевое значение. В рабочей версии виджета мы можем использовать фотографии аналитиков и цифровую дифференциацию в зависимости от попадания или нет в целевые значения.  

С занятостью напрямую связана производительность аналитика, когда мы оцениваем и число взятых в обработку инцидентов и среднее время взятия в обработку или длительность обработки инцидента. Сопоставление этих позиций нам помогает понять, кто из аналитиков работает хорошо, а кому нужен волшебный пендаль или отправка на повышение квалификации. Кстати, на виджете ниже, показана прикольная фишка, которую мы реализовывали в одном из SOCов - геймификация. Исходя из показателей оценки работы аналитика вычислялись баллы, которые ранжировались по диапазонам и каждому из них присваивались соответствующие статусы (SOC Master, COS Newbie, SOC Expert и т.п.). Учитывая возраст аналитиков в этом SOC и некий соревновательный дух среди его состава, такая геймификация позволила улучшить показатели реагирования на инциденты (без снижения его качества). 

Обрабатываемые инциденты можно визуализировать с помощью диаграммы, в которой показать соотношение между разными типами, приоритетами, источниками или аналитиками. Так как в данном случае у меня нет цели свести какой-то тип или приоритет инцидента к нулю (ну если начальство вдруг не поставило такую задачу ради PR), то диаграмма будет вполне к себе к месту. Ниже показан схожий пример, но вместо инцидента у нас отображаются тикеты в системе управления деятельностью SOC, которую иногда разворачивают на базе SOAR, а иногда применяют что-то самостоятельное, для чего даже придумали термин "Security GRC". Это вообще странная конструкция, но почему-то очень популярная у производителей ИБ, которые, видимо, хотят показать свою близость к бизнесу, в котором GRC применяются достаточно давно. Или они берут пример с производителей IT GRC?..

Ну а дальше мы можем визуализировать инциденты/тикеты по различным срезам и с привязкой к разным их атрибутам.

Вообще тема визуализации метрик ИБ в виде отчетов и дашбордов сегодня очень мало кем прорабатывается. Она гораздо сложнее, чем даже просто тема измерения эффективности SOC. Ну считаете вы классические TTD/TTC/TTR. Может быть вы добавляете к ним MTTI, MTTQ, MTTV или MTTM. А может быть вы все-таки оцениваете еще и другие параметры (число переданных на L2 инцидентов, число открытых инцидентов критического уровня, точность эскалации инцидентов или число пострадавших активов/устройств). Допускаю. Но вот правильно их сочетать и визуализировать - это совершенно иное умение, которое и помогает быстро принимать правильные решения, направленные на улучшение деятельности центра мониторинга.

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

Подробнее…

О дашбордах для SOC - часть 3. Контроль обучения

По прошлой заметке, посвященной дашборду оценки персонала в SOC, в одном из закрытых чатиков по SOCам возник вопрос относительно верхнего крайнего правого прямоугольника (KPI) с показателем по обучению. Мол, он не был раскрыт на дашборде кроме последнего блока по квалификации аналитиков разных подразделений SOC. Это действительно так, потому что в заметке описывался от руки нарисованный прототип, который затем не только дорабатывался до своего финального вида (с соответствующей цветовой раскраской и применением микро-графиков), но и был только частью набора дашбордов, описывающие различные аспекты работы с персоналом. Я просто показывал пример. Чтобы ответить на вопрос про дашборд с обучением аналитиков SOC, я и пишу данную заметку, показывая еще один прототип.

Итак, с точки зрения обучения меня интересует множество вопросов - от количества обученных/необученных сотрудников и потраченного/имеющегося бюджета на обучение, до форма и форматов обучения, а также рейтинга учебных центров или, что может быть более точным определением, провайдеров обучающих программ, которые могут быть представлены не только различными УЦ, но и другими организациями. Например, в примере ниже вы увидите Cisco, которая не являясь учебным центром (но имея сеть авторизованных УЦ, готовящих специалистов по программе обучения аналитиков SOC), при этом предлагая различные обучающие программы и треки (например, грядущий и бесплатный CiscoLive с треком по кибербезопасности, насчитывающим пару сотен докладов на столько же часов). Бесплатный (в этом году) виртуальный Defcon тоже может быть отнесен к провайдерам обучения.

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

Готовя программу обучения для вновь поступивших на работу, а также уже работающих сотрудников, мы должны понимать, какие курсы могут быть нам интересны и полезны, а на какие лучше не тратить деньги. Поэтому у нас появится в дашборде виджет по программам/курсам обучения, который может выглядеть примерно так (колонка с длительностью позволит мне судить, насколько длительным может быть отсутствие аналитика, если мы направим его на обучение):

Не желая тратить деньги провайдерам, которые не удовлетворяют нашим требованиям, мы разработаем виджет для рейтинга качества учебных центров. В тех случаях, когда провайдер предоставляет бесплатное обучение, например, упомянутые выше CiscoLive и Defcon, нам будет важна третья колонка - с оценкой провайдера, которую мы получаем либо от уже обучившися сотрудников, либо берем чужую оценку (например, из Интернет).

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

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

: 

Так как у меня многовато переменных (форма и формат обучения, отделы, провайдеры и т.п.), то мне могут понадобиться фильтры в дашборде, которые могут выглядеть так:

Если мы попробуем теперь свести все вместе, то прототип дашборда будет выглядеть примерно так:

Он показывает все ключевые аспекты обучения аналитиков SOC и помогает принимать нам соответствующие решения касательно направления сотрудников на обучение, выбирать лучшие программы/курсы и форматы обучения, а также понимать, стоит ли продолжать иметь дело с тем или иным провайдером обучения. А это именно то, что мне нужно от этого дашборда.

На самом деле, этот прототип может быть еще улучшен. Если вдуматься, нас интересует не просто число обученных сотрудников (если мы не для галочки измеряем этот показатель) и рейтинг провайдеров обучения, но и понимание, насколько в лучшую сторону меняется эффективность и результативность аналитиков после обучения. Иными словами, мы хотим понимать, обучение меняет что-то в деятельности сотрудников SOC или нет? Тогда можно добавить следующий виджет с гистограммой динамики KPI аналитика SOC (если он, конечно, есть и измеряется) до и после обучения. Так мы увидим не только оценку курса/программы обучения, поставленную самим сотрудником, но и увидим, насколько курс изменил поведение сотрудника и он стал работать лучше, то есть применять полученные на обучении навыки (а иначе зачем его туда посылали). Колонки означают 3 недели до и после недельного обучения. Так должно быть, если обучение было успешным.

Подробнее…

О дашбордах для SOC - часть 2. Кадровый вопрос

Продолжим про дашборды в SOC и посмотрим на достаточно редкий пример, а точнее на кадровой вопрос SOC. Вспомним вчерашнюю заметку. Дашборд - это представление информации, которое необходимо для быстрого взгляда на ситуацию с целью подсвечивая как слабых, так и сильных сторон рассматриваемого вопроса. В случае с кадрами, что может интересовать руководителя SOC или руководителя служб ИБ, в состав которой входит SOC? Я попробовал выделить набор таких вопросов, среди которых не только штатная численность и динамика ее изменения по ролям/подразделениям SOC, но и средняя зарплата в динамике и ФОТ, кадровые риски (мало кто вообще мониторит эту область), а также образование и квалификацию аналитиков.

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

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

Важный показатель - текучесть кадров. Он показывает, насколько сотрудники готовы задержаться у нас, насколько их все устраивает с точки зрения зарплаты, условий труда, интересных задач и т.п. Выглядеть это может примерно так. Показатель "нормы", указанный на квази-виджете, показывает установленное в компании значении текучести кадров - его можно узнать в HR. На иллюстрации мы видим достаточно большую текучесть в первый год для аналитиков первой линии и ее снижение в следующем году. Отрицательное значение текучести говорит о том, что ситуация улучшается. Но вообще значение в 1000% немного смущает и стоит подумать о другом представлении таких чисел (возможно, пересчитать формулу, если один из  показателей равен нулю.

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

Гораздо более интересен, но очень редко когда он оценивается, показатель eNPS или Employee Net Promoter Score. Первоначально этот показатель (без приставки "e") использовался для измерения лояльности клиентов, но потом возникла идея применить его и к оценке лояльности сотрудников. Он оценивает, насколько сотрудник захочет порекомендовать работодателя своим друзьям и коллегам. Вовлеченность он не оценивает, но общее положение дел помогает увидеть. За этим показателем, на самом деле, скрывается многое. Лояльные сотрудники работают лучше. Они реже увольняются, что приводит к экономии (удержать сотрудника обычно дешевле в 4 раза, чем найти нового). Они выходят с инициативами по улучшению компании. Я не буду подробно расписывать, как считать eNPS (это несложно), но на дашборде у нас будет примерно такая картина. Она говорит нам о том, что лояльность снижается. Это плохой знак и с ним надо будет что-то делать.

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

Три последних виджета можно собрать в один блок. Можно даже добавить к нему текучесть кадров в SOC. А в ключевые показатели, на самом верху дашборда, можно даже вывести какой-нибудь сводный показатель "уровень кадрового риска" или "уровень лояльности", чтобы сразу видеть наличие проблем в этой области.

В первоначальный список у меня также попали вопросы связанные с образованием, но в конце концов, SOC - не ВУЗ, который кичится числом своих профессоров, академиков, доцентов и других статусных позиций. Можно быть отличным реверсером малвари и не иметь высшего образования по ИБ, а можно его иметь, но при этом знать, что такое Mimikatz (помнится, на одном из Уральских форумов Руслан Стоянов выдал фразу "Какой ты безопасник, если не знаешь, что такое Mimikatz", вызвав тем самым острую дискуссию в кулуарах). Поэтому виджет про образование можно убрать, а вот тему квалификации сотрудников SOC в привязке к прохождению ими тренингов, нужных для выполнения ими служебных обязанностей, на дашборде стоит отразить.

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

Если попробовать теперь свести все вместе, то у меня получится вот такой проект дашборда по ситуации с кадрами в SOC. Теперь можно попробовать автоматизировать его с помощью Excel PowerBI, Grafana, встроенных возможностей SIEM и т.п. Но это уже выходит за рамки статьи, в которой я хотел показать, что прежде чем мы зададимся вопросом о том, какие дашборды мне нужны в SOC, стоит задать иной вопрос - что меня волнует в SOC? Низкое качество разбора инцидентов? Текучесть аналитиков? Высокая длительность реагирования на инциденты? Невидимость многих инцидентов? Что еще? Ответив на этот вопрос, мы легко поймем, какой дашборд нам нужен и какую информацию на нем отобразить. А уже потом можно будет анализировать источники информации для дашборда, наличие коннекторов к ним, и способ автоматизации создания и поддержания дашборда. А без этого, все эти красивые картинки будут никому не нужны :-(

Подробнее…

О дашбордах для SOC

Да, опять :-) Вообще эта заметка должна была быть опубликована на Хабре. Но я там уже недавно публиковал одну заметку про SOC на удаленке и не могу сказать, что она была воспринята положительно. Хотя и отрицательных отзывов тоже не было. Скорее, она оказалась не в формате Хабра, так как в ней не было "техники", а скорее организационные и психологические аспекты работы аналитиков SOC в дистанционном режиме. Поэтому заметку про дашборды в SOC я решил вынести уже в этот блог, хотя она и опирается на опыт Cisco в этом вопросе. Но так как никаких продуктов Cisco в ней не рекламируется, а высказанные мысли будут полезны широкой аудитории, то пусть лежит здесь.

Итак, исходные данные следующие. Один наш заказчик решил провести аудит своего SOC и среди прочих задач, одна звучала так "Провести анализ существующей системы метрик оценки эффективности SOC и их представлений в виде дашбордов и отчетов". Могу сказать, что это достаточно редкая задача, так как по нашему опыту (а он измеряется не менее сотни спроектированных и примерно столько же проаудированных центров мониторинга) до оценки того, как работает SOC и его аналитики, руки доходят не всегда. Проработать архитектуру, отрисовать процессы, разработать Use Case и playbook... Это да, очень востребованные услуги. А вот так, чтобы оценивать свою эффективность, да еще и демонстрировать ее... до этого созрели далеко не все владельцы SOC.    

Проекты по созданию дашбордов... Хотя нет. Дашборды - это всего лишь верхушка айсберга. На самом деле речь может и должна идти о проектах именно по оценке эффективности SOC. Так вот такие проекты часто проваливаются, так как для того, чтобы они выстрелили нужны соответствующие верифицированные данные и умение с ними работать, то есть правильно ставить вопросы, подбирать данные, визуализировать их, а также делать выводы и вносить изменения в процессы. Если на каком-то этапе у нас происходит сбой, то и вся системе оценки эффективности дает сбой и мы вновь возвращаемся к набившим оскомину - время обнаружения инцидента, время реагирования на инцидент, загрузка аналитика SOC и т.п. В целом, эти метрики неплохи, если мы знаем, зачем они нам и что мы хотим сделать на их основе. Просто отображать время взятия инцидента в работу недостаточно. И постоянно лишать премии аналитиков за то, что они вместо 3-х минут "по SLA" инцидент берут за 3 минуты 12 секунд, тоже неправильно. Надо понять, почему так происходить и что сделать, чтобы улучшить показатель (или изменить SLA).

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

Первый дашборд - всегда прототип. Его задача подсветить слабые места в том или ином процессе.  И вот тут самое главное - противодействовать сопротивлению руководителей групп аналитиков, которые будут утверждать, что никаких проблем у них в процессах нет и "все так и должно быть". Очень часто такие руководители утверждают, что они доверяют своим подчиненным, ставят ему верхнеуровневые задачи, а потом спрашивают результат. А контролировать и разбираться, почему процесс работает не так, как задумано, медленно или не полностью охватывает всю область действия SOC, это, мол, не задача руководителя. Хотя именно в этом и заключается его задача. И перебарывать сопротивление таких руководителей должен уже не консультант, который дает инструмент, а руководитель SOC (если он хочет это делать) или руководитель службы ИБ или руководитель компании, который инвестировал много денег в SOC и хочет получить результат на все 100.

Допустим, у вас есть playbook по анализу подозрительной активности пользователя и среднее время реагирования на нее (от момента получения сигнала в SIEM и до замораживания учетной записи в AD, помещения узла в карантинный VLAN и поиска других узлов и пользователей, которые могли быть связаны с пострадавшим) у вас занимает около 28 минут. Вы смотрите статистику по отработанным инцидентам и видите, что этот показатель немного скачет в диапазоне от 19 до 37 минут, но в среднем составляет те же 28 минут. Вроде все ОК. Отвлекусь на секунду и отмечу, что в данном случае надо смотреть не среднее арифметическое, а медиану, которая гораздо лучше покажет насколько часто аналитики выходят за средний показатель. В идеале же надо смотреть еще глубже и оценивать время реагирования применительно к разным типам инцидентов, да еще и для разных аналитиков (новичок и бывалый должны иметь разные временные показатели - второй должен работать быстрее).

Но если бы у вас была возможность мониторить все отдельные шаги/задачи playbook, то вы бы увидели, что вместо традиционных 1-3 минут на выявление индикаторов, 1-3 минут их проверки в TI-платформе, 1-2 минут на принятие решения, 3 минут на замораживание учетки и т.п., у вас аналитик сразу после получения сигнала тревоги помещает пользователя и его узел в карантин, а то и вовсе без проверки передает инцидент на следующий уровень, к аналитикам L2. И, примерно, 9-10 минут вообще непонятно, что аналитик делал. То ли он пошел на кухню налить себе кофе, то ли он решил посмотреть новости на смартфоне, а может он просто пошел проветриться или посмотреть на солнце. Но имеющаяся у вас метрика по конкретному инциденту соблюдена. Поэтому так важно оценивать не процесс целиком, а отдельные его этапы и учитывать это в соответствующем дашборде.

ЗЫ. А где же про дашборды? Мы думали примеры будут. Будут. В следующей заметке. Я выше написал, что дашборд - это вершина айсберга. Чтобы дашборд "попал" в нужную аудиторию - надо понимать, что мы хотим (и хотим ли) и что она хочет? И только потом отрисовывать дашборды, о чем я уже подробно писал два года назад.

ЗЗЫ. Еще бы хотел обратить ваше внимание на свою презентацию про измерение эффективности SOC, которую я читал на SOC Forum в ноябре и ее видеозапись.

Подробнее…

Разделенное внимание, мнимая многозадачность и количество мониторов в SOC

Наверное многие видели фотографии SOCов с огромными экранами, на которых что-то показано красивое и переливающееся всеми цветами радуги. А вы знаете, что по статистике, эти экраны не используются в 80% времени, исключая приходы руководства, СМИ (если компания важная) и важных клиентов.

Вместо правильного их использования (например, для вывода дашбордов) в SOC почему-то принято ставить у аналитиков по несколько мониторов. Вот примерно так:

Но на самом деле человек не способен работать в многозадачном режиме. Многие компьютеры тоже это не умеют несмотря на термин "многозадачность" (если не брать в расчет многопроцессорные или распределенные системы). Просто разные задачи распределяются между тактами процессора и переключение между задачами происходит незаметно для человеческого глаза. А вот человеческий мозг так не умеет (ну если вы не Юлий Цезарь, конечно). Более того. Мнимая человеческая многозадачность приводит к замедлению работы и забывчивости. При переключении мы откладываем дела в краткосрочную память и можем забыть до 40% в ней хранящегося, то есть того, что делали и планировали делать. Вот, посмотрите ролик, в нем как раз хорошо показан результат переключения с задачи на задачу:



Что делают ваши аналитики SOC? Только анализируют события безопасности? Или еще принимают звонки об инцидентах по телефону и электронной почте? А регистрируют заявки или занимаются эскалацией тоже они? А еще они ходят по нужде, покурить, поесть, попить воды и т.д. Все это отвлекает внимание и приводит к "слепоте".

В этой области (change blindness) проводится достаточно много различных исследований, особенно военными, у которых цена ошибки достаточно высока. В частности, ВМС США проводили такое исследование "Verification of the change blindness phenomenon while managing critical events on a combat information display" с целью определить, каков процент изменений на мониторах упускают из ввиду операторы ВВС, следящие сразу за несколькими мониторами. Согласно многочисленным исследованиям, на полное восстановление состояния глубокой концентрации после отвлечения на другие задачи, уходит примерно 15 минут. Иными словами, использование двух и более мониторов, отображающих разные типы информации, может негативно сказаться на способности концентрировать внимание. Это иная сторона психологической слепоты, о которой я уже писал в октябре.

А сколько мониторов нужно для того, чтобы работа аналитика SOC была максимально эффективной? Если честно, то я не нашел ни одного исследования, дающего ответ именно на этот вопрос. Но есть исследования, которые отвечают на вопрос относительно числа мониторов у операторов систем охранного видеонаблюдения. Согласно исследованиям, при использовании одного, четырех, шести и девяти мониторов, точность обнаружения составляет 85%, 74%, 58% и 53% соответственно. В различных материалах говорится, что чем критичнее область контроля (например, казино или алмазные компании), чем меньше мониторов используется - не больше 3-4-х. В SOCе же объекты контроля не только меньше, но и менее заметные, чем у видеонаблюдения, поэтому и мониторов должно быть меньше. Если бы мы наблюдали только за DDoS, то мы могли бы использовать больше мониторов, но увы... бывают и другие, менее заметные атаки, а значит число мониторов не должно быть большим. Тем более, что одна атака может скрываться за другой, отвлекающей внимание, и концентрация внимания у аналитика должна быть достаточно высокой - большое число мониторов только распыляет его концентрацию.

Бороться с описанной проблемой можно несколькими путями:

1. Не использовать больше двух мониторов на аналитика.
2. Согласно исследованиям многозадачность гораздо меньше сказывается на молодых женщинах, чем на пожилых мужчинах (возраст и пол имеют значение). Поэтому в качестве аналитиков SOC эффективнее брать прекрасную половину человечества, что, правда, немного отличается от современных реалий.
3. Проводить тест Мюнстерберга при приеме на работу аналитиков SOC, который позволяет проводить профотбор тех, кто обладает хорошей избирательностью и концентрацией внимания (правда, если есть из кого выбирать и можно проводить тесты).
4. Выбирать (разрабатывать) решения по мониторингу с учетом соответствующих рекомендаций по проектированию графического дизайна (например, вот). 

ЗЫ. А что тогда выводить на большие экраны, коль скоро они уже есть в SOCе? Ну уж точно не аномалии и атаки. Почему бы не вывести туда новостную сводку, которая имеет отношение к деятельности организации в ИБ-поле (например, фиды по ИБ)? А еще туда можно выводить твиты или заметки из соцсетей с тэгом вашей организации или бренда или сводные данные по Топ10 - внутренних или внешних узлов, пользователей, нарушителей, приложений, протоколов и т.п.

ЗЗЫ. Карты атак тоже бессмысленны для больших экранов. Да и вообще бесполезны.

Подробнее…

Дашборды по ИБ для руководства: объединяем все вместе (презентация)

Теперь попробуем собрать все заметки по дашбордам (1, 2, 3 и 4) вместе. Получится презентация, которую я выложил на Slideshare (да, он заблокирован на территории России, но кого это останавливает?), и которую я читал в рамках мастер-классов в Москве на CISO Forum и в Санкт-Петербурге на Код ИБ.

Дашборды по ИБ для топ-менеджмента from Aleksey Lukatskiy

Подробнее…

Дашборды по ИБ для руководства: как получить финальный вариант?

Давайте посмотрим на дашборды, которые есть у современных решений по ИБ. В качестве примера я возьму то, что мне ближе, - решения Cisco (Cisco ISE, Cisco Stealthwatch, Cisco Threat Grid и Cisco Cognitive Threat Analytics). Посмотрите на иллюстрацию ниже. Мы видим, что все дашборды построены по описанному вчера принципу - сначала ключевые показатели, потом аналитические диаграммы, раскрывающие эти показатели. Клик по выбранным диаграммам приводит к детальным отчетам. Все вроде бы на месте, но можем ли мы такие дашборды показывать руководству? Увы, нет. Ибо они не отвечают на вопросы, которые нужны топ-менеджменту.

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

Чтобы вынести все эти показатели на дашборд нам нужно их каким-то образом выцепить из разных систем, собрать вместе, произвести дополнительные вычисления (например, рейтинг успешности повышения осведомленности в области использования и защиты e-mail) и визуализировать все это в рамках дашборда. Для этого нам понадобится взять "сырые" данные от средств защиты и данные от бизнес-систем (HRM, SCM, ERP, CRM и т.п.), для чего воспользоваться API, которое сегодня является неотьемлемой частью любого современного решения по ИБ (и не только). Помните, я в прошлом году писал о пяти вещах, которые вы должны требовать от любого ИБ-вендора. Так вот наличие API там стояло там на первом месте. Для захвата данных через API необходимо умение программировать. Сразу надо заметить, что речь идет не о "кодинге" на C++ или Ассемблере, а о навыках извлекать данные из разных систем. Будет это ODBC, JDBC, Visual Basic или Python и R, - не так уж и важно.

Что использовать в качестве инструмента для создания и визуализации дашборда? Этот вопрос звучит чаще других, но именно он-то совсем неважен. В конце концов, какая разница, что позволит вам решить вашу задачу? С чем вы лучше знакомы и что используется у вас в организации - то и применяйте. Это может быть Excel (для простых задач вполне себе решение), MS PowerBI, Tableau, QlikView или grafana. В конце концов вы можете заточить под это ваш SIEM, если у него есть возможность конструирования дашбордов и развитый API для подключения к внешним системам. Я вновь повторю, что не так важно КАК визуализировать, как то, ЧТО вы хотите показать и ЧЕГО достичь своим дашбордом.

Подробнее…

Дашборды по ИБ для руководства: как создать макет?

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

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

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

Чтобы ответить на эти вопросы нам по каждому инциденту нужно собрать следующие данные:

• аналитик SOC, работающий с инцидентом
• тип инцидента
• источник инцидента
• статус инцидента (разрешен/просрочен)
• дата и время.

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

Разумеется это еще не макет дашборда - это скорее набросок той информации, которая должна быть на дашборде. А вот макет будет выглядеть так:

На его отрисовку у меня ушло всего 10-15 минут. Да, не Пикассо. С этим к руководству не пойдешь. Но и задача такая не стоит на этом этапе. Зато мы видим, как будет выглядеть дашборд, какие диаграммы и какие ключевые показатели будут отображаться на нем.

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

• Время между созданием и закрытием заявки (ticket) в SOC
• Процент инцидентов обнаруживаемых и нейтрализуемых автоматически, без участия специалистов SOC
• Соотношение открытых и «закрытых» заявок
• Соотношение инцидентов и заявок
• Число повторных инцидентов
• Соотношение методов коммуникаций с SOC (e-mail / звонков / портал)
• Число false positives (несуществующих инцидентов)
• Число изменений средств защиты по результатам расследований инцидентов
• Соотношение инцидентов по их критичности
• Цена/длительность разрешения инцидента
• Число новых заявок.

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

Финальную заметку я посвящу вопросу создания прототипа и финального варианта дашборда, для чего нам понадобятся различные средства автоматизации - от Excel или MS PowerBI до Canopy или Splunk.

Подробнее…

Дашборды по ИБ для руководства: КАК отобразить

Как и отчеты дашборды бывают трех типов - стратегические (для топ-менеджеров), аналитические (для руководителей среднего звена) и оперативные  (для исполнителей). Учитывая, что большинство отчетов (да и дашбордов) готовится именно исполнителями и ни они не задаются нужными вопросами (КТО моя целевая аудитория, ЧТО они должны решить и КАКАЯ информация им для этого нужна), ни им не дают ответы на эти вопросы, то большинство отчетов/дашбордов превращаются в простыни цифр, которые никто не читает (распечатки логов IDS, МСЭ, список непропатченных ПК, список критичных уязвимостей и т.п.). Чтобы сделать ваш продукт (а дашборд или отчет - это продукт, который вы продаете руководству) надо усвоить несколько важных моментов:

• виды анализа
• используемые виды диаграмм
• макет дашборда
• прототип дашборда.

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

• количество запросов и трудозатрат по сотрудникам SOC
• трудозатраты по типам инцидентам
• динамика инцидентов в течение года (кстати, на этом показателе становится понятной разница между средним арифметическим и медианой)
• количество инцидентов по источникам.

Попытка вынести эти 4 блока на один дашборд обычно с первого раза не получается. Точнее получается фигня - все блоки равнозначны и непонятно, куда смотреть и какой вывод может быть сделан на основе полученной информации. Пробуем перегруппировать, опираясь на три типа отчетов/дашбордов, упомянутые в самом начале. Стратегические показатели (число инцидентов, число просроченных инцидентов в %, трудозатраты в часах, число аналитиков SOC) выносим наверх, а аналитические (оперативные в дашборде будут лишними) разместим ниже. Именно там покажем динамику инцидентов, количество инцидентов по типам и источникам, трудозатраты по аналитикам SOC.

Определившись с тем, ЧТО показываем в дашборде, надо решить, КАК мы это показываем. Несмотря на то, что современные BI-решения и даже Excel содержат десятки разных типов диаграмм, в реальности вам понадобится всего 5 - линейчатая диаграмма, график, гистограмма, точечная/пузырьковая диаграмма и круговая/кольцевая диаграмма.

Иногда еще могут понадобиться всякие радарные диаграммы или светофоры, но это гораздо реже предыдущих пяти. Эти диаграммы помогут вам отобразить 4 базовых вида аналитики:

• Рейтинг. Это самый распространенный вариант анализа, который позоляет сравнивать данные по принципу больше/меньше. Число незакрытых или просроченных инцидентов, число непропатченных ПК, размер ущерба, число IoC, обработанные заявки на доступ и т.п. Демонстрировать данный анализ позволяют линейчатые диаграммы и гистограммы.
• Динамика. Это вид анализа, который обычно демонстрируется графиком или гистограммой, показывает тренд, сезонность, изменение во времени суток и т.п. 
• Структура. Этот вид анализа показывает часть, долю целого. Например, распределение затрат на ИБ, распределение инцидентов по типам или источникам, соотношение закрытых и просроченных инцидентов и т.п. Единственным способом отобразить данный вид анализа позволяет круговая диаграмма.
• Взаимосвязи. Это гораздо более редкий, но все-таки важный вид анализа, который помогает показать наличие или отсутствие (а иногда и характер) взаимосвязей между несколькими показателями. 

При выборе диаграмм главное не переборщить. По себе знаю - часто хочется не показать важную информацию, а показать ее красиво и продемонстрировать не только умение пользоваться разными тулами, но и потраченную на разные плагины и коллекции иконок кучу денег :-) В итоге вместо концентрации на том, ЧТО показывать силы уходят на то, КАК это показывать, что неправильно. Я на первых порах всегда начинал с вопроса "какой тип диаграммы использовать" или "где разместить эти данные - на оси абсцисс или ординат" вместо "число инцидентов типов А, Б и В за отчетный период составило ххх, yyy и zzz и для этого мне нужно использовать гистограмму".

Отсюда же, кстати, вытекает и рекомендация не увлекаться инфографикой. Я сталкивался с парочкой фирм, в которых цифры и аналитика уходят на второй план, а их подменяют красивые иконки, на рисование которых тратятся усилия целых отделов. Помочь принять решение это не помогает, а ресурсов требует немалых. Если, конечно, у вас денег куры не клюют, то можно и поиграться в эти игры, но в обычной жизни для 99% компаний все это баловство.

Завтра поговорим про макет и прототип дашборда. И попробую отобразить уже реальные картинки, которые все так хотят увидеть :-)

Подробнее…

Дашборды по ИБ для руководства: КТО, ЧТО и КАКОЕ

Достаточно часто сталкиваюсь с вопросом, который звучит "Как должен выглядеть отчет/дашбоард по ИБ для руководства?" Это немного другая сторона медали, связанной с выходом ИБ на уровень бизнеса, о которой я достаточно часто говорю в последние годы (хотя и не так часто как хотелось бы). Многие вопрошающие считают, что существует некий магический пример отчета или дашборда (разница между этими понятиями не столь большая), который можно скопировать и наступит счастье в общении с руководством, которое сразу должно понять, что безопасность не зря ест свой хлеб и не зря на нее тратят десятки и сотни миллионов рублей. Нередко заданный в начале вопрос сопровождается дополнением - "У нас уже есть SIEM/SOC и нам осталось только правильно расположить виджеты, чтобы получить нужный результат. У вас же в Cisco это сделано. Покажите как?"

Вот об этой проблеме мы сегодня поговорим, но как это часто бывает - никакой серебряной пули не существует и никакого магического отчета нет. Все ситуации уникальны, а потому уникальны будут и дашборды/отчеты, которые могут показать эффективность (или неэффективность) работы службы ИБ или отдельных ее подразделений. Но это не значит, что нет общих рецептов, которым надо следовать, чтобы добиться нужного результата. Для начала стоит понять, в чем корень проблем с визуализацией бизнес-представления ИБ? В разном восприятии. Человек, готовящий отчет (предположим, что он понимает, чем он занимается), слишком погружен в детали. Он считает все данные в отчете или на дашборде важными. Еще бы - он ведь их сам собирал по крупицам и поэтому не может отказаться от чего-то, на что он, возможно, потратил не одну неделю. Руководителю (и не важно какого уровня), в отличие от аналитика, нужны не детали, а общая картина, наглядность. Аналитика волнуют ответы на вопросы классической игры "Что? Где? Когда?", а руководителю нужны ответы на вопросы "Что будет? Что делать?" Отсюда и все проблемы, для устранения которых надо ответить на ряд простых на первый взгляд вопросов, а точнее просто произвести декомпозицию исходной задачи.

Первое с чего стоит начать, с ответа на вопрос "КТО?", который разбивается на две составные части - кто вы и кто ваша целевая аудитория? Первая часть не столь актуальна в небольших организациях, в которых вся ИБ - это 2-5 человек без жесткой иерархии подчинения. В такой ситуации совсем не важно, кто вы; главное, что вы занимаетесь ИБ и вам поручили подготовить отчет или сделать дашборд для руководства. В крупных организациях, в которых служба ИБ насчитывает сотни или даже тысячи человек эта часть вопросам становится уже гораздо важнее. Врядли руководитель отдела СКЗИ или антифрода сможет адекватно подготовить дашборд по деятельности всей службы ИБ - у него своей фронт работ, по которому он и может говорить предметно. Поэтому если вам поручили задачу сделать отчет/дашборд "обо всем" лучше сразу расставить все точки над i. В противном случае вы точно окажетесь виноватым.

Вот вторая часть вопроса "КТО" гораздо важнее. Кто ваш заказчик? Кто будет смотреть на ваш отчет или дашборд? CISO? CSO? CEO? COO? CFO? Иной CxO? С CISO ситуация не так просто как кажется на первый взгляд. Это в небольших организациях руководитель ИБ обычно в курсе всего, что творится у его подчиненных. В крупных, уровня Газпрома или РЖД или Сбербанка, сложно ожидать, что CISO знает все, что находится на 2-3-4 уровня иерархии ниже. Это физически невозможно. Поэтому, получая задачу подготовки дашборда или отчета от своего руководителя ИБ все-таки уточните задачу и получите как можно больше деталей. Мне доводилось слышать такую постановку задачу "Сделайте мне красиво, понятно и чтобы я мог перед предправления отчитаться". Или вот такую: "Вы сами должны знать, что мне надо, я же не зря вам плачу зарплату". Увы, в последних двух случаях вероятность сделать что-то устраивающее вашего "рукамиводителя" невысока. При столь нечеткой постановке задачи это равносильно "пойди туда, не знаю куда, принеси то, не знаю что".

Второй важнейший вопрос - ЧТО. Что нужно вашей целевой аудитории? Какие ключевые показатели ей необходимо показать? Ответ на этот вопрос зависит от ответов на предыдущий вопрос. Понятно, что финансовому директору не интересно число уязвимостей в Web-сайте компании (да и никому не интересно). И среднее время реагирования на инциденты (кстати, среднее арифметическое или медианное?) тоже неинтересно. И эффективность источников Threat Intelligence тоже. Все это внутренняя кухня ИБ, которая в лучшем случае интересна CISO.

Для ответа на вопрос ЧТО, вы должны ответить на третий вопрос - КАКОЕ решение должна принять ваша целевая аудитория? Запустить проект по повышению осведомленности сотрудников? Увеличить инвестиции в проект по приведению себя в соответствие с PCI DSS или 382-П? Инвестировать в защиту Web-сайта от прикладных атак? Обратиться к аутсорсингу ИБ вместо содержания собственной службы ИБ? Увы. Все эти решения не имеют никакого отношения к бизнесу. Это в лучшем случае уровень CISO. Бизнес волнуют совершенно иные вещи и вопросы. Какой канал лучше позволяет привлекать клиентов? Какие регионы/города России наиболее перспективны для географической экспансии? Как снизить издержки и повысить доходность? Как поднять лояльность сотрудников/клиентов/партнеров? Как снизить регулятивные риски? Могут ли ваши дашборды/отчеты помочь ответить на эти вопросы? Скорее всего нет. Но это не значит, что вам не надо общаться с бизнесом и пытаться понять его чаяния. Именно о том, что нужно бизнесу в контексте ИБ и как ИБ влиться в общие бизнес-процессы, будет посвящено два мастер-класса на Магнитогорском форуме по банковской ИБ, которые буду вести я и Дмитрий Мананников уже в следующий вторник. Это важнейшая часть работы ИБ (общение с бизнесом), но выходящая за рамки сегодняшней заметки. В любом случае, независимо от уровня вашей целевой аудитории (CEO или CISO) вы должны понимать, какое решение она должна принять. Отсюда вы поймете, что ей нужно для принятия решения и какие данные вам помогут облегчить принятие решения.

Например, перед вашим CISO стоит задача - искать ли новые источники Threat Intelligence или оставить используемые сейчас? Чтобы принять решение ему нужно ответить на ряд вопросов:

• Какое соотношение получаемых извне IoC с теми, которые применялись в компании за отчетный период? Ответ на этот вопрос помогает понять, насколько вообще внешние источники помогают вашей организации в обнаружении атак и инцидентов?
• Какие источники TI наиболее релевантны для организации? Это предыдущий показатель применительно к каждому внешнему источнику.
• Число индикаторов, полученных от внешнего источника TI с учетом их полезности для организации (полезно при принятии финансовых решений о продлении контракта на TI). 
• Соотношение количества угроз, пришедших по каналам TI, и не обнаруженных за счет внутренних возможностей (фишинговые сайты, украденные логины/пароли, сайты-клоны и т.п.).
• Какое количество получаемых извне IoC применялось в компании? Может оказаться вообще, что индикаторы компрометации вы получаете, но не используете, потому что руки не доходят или не знаете, как автоматизировать процесс интеграции внешних источников с вашими средствами защиты/анализа.

Кстати, при оценке деятельности подразделения Threat Intelligence с точки зрения руководителя ИБ, было бы неплохо задать следующие вопросы:

• Сколько IoC, сформированных службой TI, помогло отразить инциденты в организации (например, на МСЭ, IPS, рутерах и т.п.)?
• Сколько playbook было создано/обновлено и использовано группой по реагированию на инциденты на основе IoC, сформированных службой TI? 
• Распределение полученных IoC по типам и соотношение их с типами угроз внутри организации.
• Динамика снижения числа ложных срабатываний средств защиты после обогащения сигналов тревоги данными от службы TI.
• Снижение времени (ускорение) на расследование инцидента и реагирование на него за счет обогащения данных об инцидентах данными от службы TI.
• Соотношение количества обнаруженных угроз средствами защиты организации с данными от службы TI и без них (например, голый IDS в сравнении с IDS + TI или IDS + TI + SIEM).
• Количество самостоятельно обнаруженных и отреверсенных вредоносов по сравнению с традиционными антивирусными программами (если это функция TI).
• Количество подготовленных бюллетеней по акторам/угрозам/кампаниям, которые имели отношение к предприятию; особенно тех бюллетеней, которые описывают угрозы, направленные именно на само предприятие, а не веерные угрозы.
• Количество подготовленных бюллетеней, направленных в ФинЦЕРТ/ГосСОПКУ/иным внешним лицам (если стоит задача awareness и обучения отрасли/индустрии).
• Участие в стандартизации вопросов обмена информацией об угрозах (если такая тема актуальна для организации).

Ответив на эти три вопроса - КТО ваша целевая аудитория, ЧТО им нужно и КАКОЕ решение они должны принять - вы решите, нет, не 50%, а 80% задачи по созданию правильного дашборда/отчета по ИБ. Про остальные 20% мы поговорим уже завтра.

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

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

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

ЗЫ. Когда писал заметку, думал нашпиговать ее красивыми примерами дашбордов, но уже в процесс написания отказался от этой идеи. Правильные примеры явяются таковыми только в конкретной ситуации, в конкретной организации, после ответа на поставленные вопросы. Они могут не копироваться в других компаниях при других условиях ункционирования службы ИБ. Да и, положа руку на сердце, таких примеров-то и немного. А вот дурацких примеров в Интернете полно - достаточно ввести в Гугле поиск картинка по ключевым словам report|dashboard security|cybersecurity и вы получили красивые, но абсолютно бесполезные в реальной жизни диаграммы, графики, светофоры, индикаторы и т.п. 

Подробнее…