Три статьи про SOCи - обзор 40 российских SOCов, измерение эффективности и SOC на удаленке

Как-то кучно зашло... Первая статья посвящена теме измерения эффективности SOC, метрикам и т.п. Она получилась достаточно объемной и поэтому редакция "Information Security" решила разделить ее на две части. Пока опубликована первая часть, в которой я рассмотрел различные временные метрики, используемые в SOC.

Вторая статья тоже про SOC, но уже с другой точки зрения. Это обзор 40 российских SOCов, которые согласились ответить на 30 вопросов о своем технологическом стеке, предлагаемых сервисах, архитектуре, используемым фидам, процессе обучения и численности персонала и т.п. Этот материал тоже не вместился в рамки одной статьи, поэтому редакция "BIS Journal - Информационная безопасность банков" также решила разделить ее на части. Первая часть уже опубликована.

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

ЗЫ. Ну и "чтобы два раза не вставать" :-) Для IT-World написал продолжение обзора хакерских методов, которые запомнились за два месяца самоизоляции и карантина. Первые две части были опубликована на Хабре (тут и тут), а третью, спустя пару месяцев, опубликовал уже на IT-World.

Подробнее…

Техническая защита ПДн в соответствие с GDPR и ФЗ-152 (презентация)

По приглашению выступал на GDPR Day, собравшем около тысячи человек онлайн (очень хороший результат), и на котором я рассказывал о том, как технически защищать персональные данные в соответствие с ФЗ-152 и GDPR. Выкладываю презентацию:

Техническая защита персональных данных в соответствие с GDPR и ФЗ-152 from Aleksey Lukatskiy

Заодно выложу и ссылки из нее:

• Кейсы по обработке ПДн и оценка рисков для них
• Высокоуровневый чеклист по защите ПДн от английского ICO
• Английский список базовых мер защиты Cyber Essentials
• Французский чеклист по защите ПДн
• Рекомендации английского ICO по защите ПДн в онлайн-сервисах
• Рекомендации английского ICO по защите ПДн в облаках
• Рекомендации английского ICO по защите ПДн в использовании BYOD
• Рекомендации ENISA по защите ПДн в мобильных приложениях
• Рекомендации ENISA по защите ПДн в облаках
• Рекомендации ENISA по обезличиванию ПДн
• Стандарт ISO по защите ПДн в блокчейне
• Стандарт ISO 27701 по системе защиты ПДн
• Рекомендации ENISA по защите ПДн при долговременном хранении 
• Рекомендации английского ICO о защите ПДн при их использовании в Big Data и ML
• Рекомендации ENISA по защите ПДн в Big Data
• Рекомендации норвежского DPA по защите ПДн при их использовании в ML

Подробнее…

О проектах Указа Президента и Постановления Правительства по убийству всех СуКИИ

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

Но вернемся к теме. Я перечислю все инициативы, которые предложены в двух проектах:

• Правительство должно до 1-го сентября ЭТОГО, то есть 2020-го года, утвердить требования к ПО и железу и порядок перехода на его использование.
• Все субъекты КИИ (без исключений) должны перейти на отечественное ПО до 1-го января 2021 года, а на отечественное железо до 1-го января 2022 года. То есть на переход на ПО дается всего 4 месяца. Это я так, просто подсчитал временной интервал, а то замминистры у нас одаренные и привыкли считать, что переход на ПО осуществляется по команде "раз-два", то есть мгновенно.
• По мнению замминистра Соколова, изложенного в пояснительной записке, принятие Указа не потребует дополнительных расходов бюджета РФ. Логично же. На такое бюджет совсем не нужен, когда можно на плечи потребителя все переложить. На прошлом Уральском форуме, вице-президент по ИТ одного из госбанков упомянул, что импортозамещение по их оценкам обойдется только им в 400 миллиардов рублей. И, конечно, эти деньги будут взяты не из бюджета. Ну разве, что Игорь Иванович попросит помочь Владимира Владимировича деньгами на импортозамещение. Но он у нас такой один - бюджет не оскудеет от этого; и курс рубля не упадет, и нефть не рухнет от этого.
• Отвечать за реализацию Указа Президента по информационной безопасности будут... нет, не ФСТЭК с ФСБ, а Минцифра с Минпромторгом. Ведь именно они как нельзя лучше знают, как обеспечивать информационную безопасности объектов КИИ.
• Указ и Постановления Правительства распространяются на ВСЕ объекты, включая незначимые. И никого не волнует, что требования по ИБ у нас установлены только для значимых объектов. И никого не волнует, что ФСТЭК с Минпромторгом уже согласовали дифференцированные требования по доверию к средствам защиты и иным решениям, используемым на объектах КИИ. Плевать. Всех под одну гребенку! И Газпром и небольшую котельную, и РЖД и курьерскую службу, и Сбербанк и микрофинансовую организацию или ломбарж.
• Все используемое на ОКИИ ПО и железо должно быть включено в реестр отечественного или евразийского ПО или реестр радиоэлектронной продукции. Есть и исключения. Если аналоги иностранного ПО или железа не включены в РПО/РЕП/РРП, то можно и зарубежные ИТ-решения применять, но при этом его обновлять или поддерживать могут только компании, которые не находятся под прямым или КОСВЕННЫМ контролем иностранных физических или юридических лиц. Минцифра наступает на все те же грабли, что уже наступала ФСТЭК некоторое время назад. Но ФСТЭК тогда устранила все эти проблемы, но Минцифра, видимо, решила повторить этот путь заново. Вот, правда, в здравый смысл нового и старого замминистра я что-то, в отличие от ФСТЭК, не очень верю.
• Если ПО или железо является средством защиты, то дополнительно к требованиям Минцифры и Минпромторга добавляются требования ФСТЭК. А если ПО или железо еще и атаки ловит и инциденты передает, то оно должно соответствовать все еще отсутствующим требованиям ФСБ.
• Переходить на отечественное надо не только для новых объектов, но и на уже существующих. То есть выкинуть и заменить на новое и родное.
• При переходе, правила которого должны быть утверждены до 1-го сентября, надо провести аудит объекта КИИ. Чиновники не знают, что аудит проводят на соответствие чему-то и поэтому в проекте ПП написано, что надо просто провести аудит. Мне кажется, что авторы проектов нормативных актов имели ввиду инвентаризацию используемого и планируемого к использованию ПО и железа. Но могу и ошибаться - пытаться подняться до высот замминистра и уровня его компетенций я не могу. Потом надо провести анализ требований Правительства по переходу на отечественное ПО и железо, поискать аналоги и оценить сроки амортизации используемого оборудования и сроки действия прав на ПО. Правда, зачем оценивать сроки амортизации и права на софт непонятно - это никак не влияет на требование перехода (хотя и должно).
• После проведения анализа из пункта выше список используемого и планируемого ПО и железо должен быть согласован с Минцифрой и Минпромторгом (а могут ведь и не соглассовать). Напомню, что все это надо будет сделать в промежуток с 1-го сентября до 31 декабря и не забыть еще закупить и внедрить все купленное.

Одна радость. В предпоследнем пункте проекта Постановления Правительства о порядке перехода  говорится о том, что по итогам всех описанных выше мероприятий надо составить план перехода и отправить его копию в Минцифру и Минпромторг. Это как бы намекает на то, что до 1-го января 2021-го года надо всего лишь направить вновь появившимся в области КИИ регуляторам только планы перехода на отечественное ПО и железо, а реализовывать их по мере возможности, уже с учетом срока амортизации и сроков окончания прав на ПО, а также наличия финансовых возможностей. Но, правда, формулировки всех остальных пунктов говорят о том, что к этому сроку надо перейти на российское. Я только дочитав до последнего пункта документа задумался, что возможно речь идет не о самом переходе, а о плане перехода.

Так что будем посмотреть на то, как это вся эпопея будет разворачиваться. Если возобладает здравый смысл, то все останется как есть. Если г-н Соколов и г-жа Бокова будут настаивать, то своими действиями они убьют недобитый коронавирусом и обязательной добровольной самоизоляцией бизнес, которому "посчастливилось" быть отнесенным к критической информационной инфраструктуре.

ЗЫ. Уже вчера вечером стало известно, что замминистра Соколов, чьим именем и электронной подписью подписаны все описанные в заметке проекты, покидает Минкомсвязи. И как теперь будет развиваться эта история становится еще менее понятно. Либо упавшее знамя подхватит другая замминистра, г-жа Бокова, либо тему спустя на тормозах. Будем поглядеть... 

Подробнее…

О дашбордах для 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 недели до и после недельного обучения. Так должно быть, если обучение было успешным.

Подробнее…

Новые примеры карточных и онлайн-игр по кибербезопасности

Недавно я открыл для себя, что Safari на macOS держит не больше 130 открытых вкладок, после чего запускает копию себя, где можно открыть еще 130 вкладок и т.д. Недавно Safari запустил третью свою копию, что заставило меня задуматься, что пора разобраться с открытыми вкладками. И вот часть из них была посвящена геймификации, а точнее различным примерам онлайн и не очень игр в области кибербезопасности. Я этой теме уделяю в блоге немало внимания, так как считаю, что за этим направлением будущее ИБ, которая не должна, не может быть сухой и скучной. Особенно, если мы говорим о повышении осведомленности персонала и просто рядовых пользователей, у которых все чаще и чаще эта тема становится востребованной. Помню, меня в свое время удивили книжки-раскраски, книжки с головоломками, которые продавались в сувенирном магазине при Агентстве национальной безопасности. То есть американцы уже с детства начинают приучать к ИБ, а что лучше всего воспринимают дети при усвоении материала? Игры!

Но вернемся к теме заметки. Несколько примеров онлайн-игр по ИБ. Каждый год ИТ-департамент Университета Техаса, в рамках национального месячника ИБ, подготавливает новые игры по ИБ для своих сотрудников и студентов. Но и все желающие тоже могут поиграть в них, а может и почерпнуть какие-нибудь идеи для своих игры. Уже доступно 7 игр - https://it.tamu.edu/security/cybersecurity-games/index.php

Еще два десятка игр (преимущественно в форме "Своей игры" и кроссворда) доступно на сайте центра развития превосходства в ИБ (а как еще перевести Security Excellence?), который официально поддерживается американским агентством военной контрразведки и безопасности. Большинство игр доступно в формате PowerPoint и их спокойно можно скачать и переделать под свои нужды (с оговоркой на то, что они все на английском).

В рамках OWASP запущен проект Cornucopia, в рамках которого разработана карточная игра, направленная на повышение осведомленности в вопросах ИБ разработчиков программного обеспечения. Схожую идею, обучение SecDevOps, реализованную в виде игр, можно найти на сайте университета Вашингтона и OWASP Snake and Ladders. На сайте OWASP есть и другие проекты по геймификации, например, платформа OWASP Security Shepherd для повышения осведомленности в области разработки Web- и мобильных приложений. Еще один интересный своей практичностью проект, bWAPP, - напичканное дырами web-приложение, которое может использовать для обучения студентов вопросам безопасного web-программирование, пентестов и т.п.

Продолжает серию карточных игр по ИБ "Control-Alt-Hack", схожая с тем, что я уже описывал в марте этого года, и Cyber Realm, разработанная в калифорнийском Университете для обучения студентов основам ИБ. Среди других примеров карточных ИБ -игр я бы упомянул:

• Power Surge: Cyber Security Academy
• Cyber Threat Defender (и тут)
• Elevation of Privelege.

Вообще, карточные игры по ИБ - это то, что делается достаточно легко и быстро. Существуют даже специальные наборы для придумывания собственных карточных игр. Например, я себе купил вот такой - The White Box, который содержит набор чистых карт, стикеров, костей, а также руководство по созданию игр. Для начинающих разработчиков игр это полезный и недорогой (всего 30 долларов на Amazon) инструмент (хотя все тоже самое можно сделать и своими руками).

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

Подробнее…

О дашбордах для 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 в ноябре и ее видеозапись.

Подробнее…