02.06.2020

Игра Cybersecurity Alias

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

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

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

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

Самое главное, что такая игра легка в изготовлении. Достаточно составить словарь из нескольких сотен слов (в оригинальной версии 180 карточек по 8 слов в каждой) и поместить их на шаблон карточки, который легко отрисовать в PowerPoint, Word или ином офисном продукте. В итоге получится что-то вроде таких карт, на которых можно увидеть совершенно разные слова, имеющие отношение к ИБ - от названия технологий до знаковых имен в ИБ, от нормативки до инструментария злоумышленников. Если вдуматься, то словарь современного ИБшника насчитывает не менее пары тысяч специфических слов, которые можно вынести на карты Cybersecurity Alias и долгими и скучными "вечерами" на самоизоляции заняться полезным делом.


29.05.2020

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

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


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


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

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

25.05.2020

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

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



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

21.05.2020

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

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

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


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

20.05.2020

О дашбордах для 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 инцидентов, число открытых инцидентов критического уровня, точность эскалации инцидентов или число пострадавших активов/устройств). Допускаю. Но вот правильно их сочетать и визуализировать - это совершенно иное умение, которое и помогает быстро принимать правильные решения, направленные на улучшение деятельности центра мониторинга.

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

15.05.2020

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

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

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


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


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


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


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


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

: 

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


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


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

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


14.05.2020

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

Недавно я открыл для себя, что 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, разработанная в калифорнийском Университете для обучения студентов основам ИБ. Среди других примеров карточных ИБ -игр я бы упомянул:

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

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

13.05.2020

О дашбордах для 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? Низкое качество разбора инцидентов? Текучесть аналитиков? Высокая длительность реагирования на инциденты? Невидимость многих инцидентов? Что еще? Ответив на этот вопрос, мы легко поймем, какой дашборд нам нужен и какую информацию на нем отобразить. А уже потом можно будет анализировать источники информации для дашборда, наличие коннекторов к ним, и способ автоматизации создания и поддержания дашборда. А без этого, все эти красивые картинки будут никому не нужны :-(

12.05.2020

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


24.04.2020

Как я моделировал угрозы по проекту новой методики ФСТЭК. Часть 6 (финал)

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

Но п.7.2 сразу вводит меня в ступор, так как согласно нему уровень опасности угрозы определяется уровнем сложности ее реализации, что на мой взгляд совсем не так. Опасность - это то, что касается потребителя. Сложность - это то, что касается нарушителя. Лично мне пофигу, насколько тяжело реализовать ту или иную атаку. Опасной для меня атака будет считаться опасной, если ущерб от ее реализации будет значимым. Возможно, сложность атаки определяется вероятностью ее реализации, которая в свою очередь, если следовать алгоритму определения потенциала нападения из ГОСТ 18045, зависит от мотивации нарушителя, его компетентности и ресурсов. Но это мы уже определили раньше, когда говорили о возможностях нарушителя. Зачем нам еще городить огород со сложностью реализации угрозы, и так усложняя непростую методику? Кстати, в одной из прежних редакций проекта методики ГОСТ 18045 использовался, но от него потом отказались. Хотя на мой взгляд предложенный там алгоритм был проще того, что используется сейчас.

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

Уровень опасности зависит от от типа доступа (наконец-то становится понятно, зачем мы мучались с определением локального, физического и удаленного доступа), сложности реализации угрозы и уровня значимости атакуемых информационных ресурсов. А ущерб? В п.7.2 же говорится, что негативные последствия тоже должны учитываться...

Дальше, в пп.7.5-7.6 у нас повторяется то, что было в разделах 3-5, - три типа доступа и 4 уровня сложности. Как и предполагалось уровень сложности реализации угрозы - это тоже самое, что и уровень возможностей нарушителя; один в один. Зачем тогда вводить еще одну сущность? П.7.7 вводит еще одну сущность - уровень значимости информационных ресурсов или компонентов, который... никак не связан с определенным в 3-м разделе ущербе (виде негативных последствий). Но зато вводится сложная конструкция с подсчетом числа пострадавших пользователей или критических процессов со странной градацией - один, больше одного, все, а также с введением непонятно как считаемого понятия "недостаточная эффективность критического процесса".
Апофеозом моделирования угроз является п.7.8 и таблица 8, которые показывают, что... сценарии реализации угроз нам нафиг не сдались, так как они никак не учитываются при оценке опасности каждой угрозы. Если бы мы хоть как-то могли оценивать сложность их реализации, то, возможно, и да. Хотя это была бы нетривиальная задача и 99% компаний и такой же процент специалистов по ИБ ее бы не смогли сделать (я бы вот не смог, признаю честно). Но у нас сложность реализации угрозы напрямую увязана с возможностями нарушителя и все. Поэтому весь 6-й раздел можно спокойно пропустить - в выполнении задачи он не нужен. Хотя провести работу по составлению максимально возможного перечня сценариев атак все равно придется. Хотя бы для галочки.

П.7.10 и таблица 10 определяют формат описания каждой угрозы, который не соответствует тому, что считает угрозой ФСТЭК в 6-м разделе. В нем, в частности, говорится, что угроза - это совокупность не только сценария реализации угрозы, но и типа источника (хотя мы помним, что скорее всего речь о нарушителе), ущерба и условий реализации угрозы. В формате же в таблице 10 из перечисленного упоминаются только сценарии. Зато к ним добавлены идентификатор угрозы (неважно из какого источника - привет неразбериха и отсутствие стандартизации), наименование угрозы (только из БДУ и неважно, что у вас может быть отсутствующая в БДУ угроза), описание угрозы, скопированное из БДУ (зачем?), и уровень опасности (для каждого сценария реализации).

Вот такой проект документа... Разные он у меня вызывает чувства. Не могу сформулировать их до конца. И самое интересное, что пытаясь сформулировать набор предложений по внесению изменений в этот проект, я колеблюсь от мысли "все нахрен выбросить и переписать заново" (но это неконструктивно) до попытки править текст вплоть до конкретной буквы или "склонения падежов"... Мне кажется, что в текущей концепции, документом пользоваться будет ооооочень тяжело, что создаст немалое количество предложений от лицензиатов, которые захотят нагреть руки на очередной кормушке "по подготовке обязятельной модели угроз", как это было в свое время, когда в 2008-м году было выпущено первое "четверокнижие" ФСТЭК по персданным. Ценник на разработку моделей угроз тогда подскакивал до 25 тысяч долларов за документ.

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


ЗЫ. Все, что было написано в серии заметок отражает мое сугубо субъективное мнение, с которым можно соглашаться или не соглашаться :-) 

23.04.2020

Как я моделировал угрозы по проекту новой методики ФСТЭК. Часть 5

К настоящему моменту, пройдя 5 разделов проекта методики моделирования угроз, мы знаем кто нас будет атаковать и какими возможностями он обладает. Мы понимаем, зачем он это будет делать и к чему приведу его действия. Теперь неплохо бы разобраться, что эти нарушители будут делать, то есть определиться с угрозами, которые могут быть против нас реализованы. Но нет. 6-й раздел проекта методики моделирования угроз ФСТЭК посвящен определению сценариев реализации угроз, то есть пропустив ответ на вопрос "ЧТО может сделать нарушитель", мы сразу обратились к вопросу "КАК он может это сделать". Что ЭТО мы не знаем, зато сейчас мы погрузимся в КАК.

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

Явно это не говорится, но идея использования терминов "тактики" и "техники" взята из американской MITRE ATT&CK, которая содержит уже за 200 техник и больше десятка тактик. Почему нет упоминания американской матрицы понятно, но это еще сыграет злую шутку с нами. Местами в таблице 4 используются совершенно непонятные без разъяснения термины, которые являются достаточно грубой калькой с англоязычной матрицы. Например, техника 5.4 "Запасные и многоступенчатые каналы" в оригинале определены как две техники - T1104 "Multu-Stage Channel" и T1008 "Fallback Channels". И если, вдруг, какой-то госорган спросит регулятора, что означает техника 5.4 придется как-то выкручиваться. А самое неприятное, что и сопоставление TTP ФСТЭК и MITRE очень сложно реализовать, так как у нас постеснялись признать применение общепринятой методики и решили "пойти своим путем". Поэтому у нас свой набор техник, свой набор тактик, своя нумерация и невозможность сопоставить их один к одному. И хотя у методике написано, что помимо таблицы 4 можно использовать и иные базы, в реальности все будет известно как. Проверяющие, незнакомые с английским языком и ATT&CK, а также боящиеся самодеятельности, будут ориентироваться на то, что есть в таблице 4, тем самым доводя изначально хорошую идею до абсурда. Если уж регулятор не хочет признаваться в копировании чужого опыта (и понятно почему), может тогда поступить как Банк России, который в своих нормативных актах написал, что список инцидентов размещается на сайте ЦБ. Его и править тогда проще. Так и ФСТЭК могла бы поступить.

При этом ATT&CK - это не про моделирование угроз, это про понимание конкретных действий, совершаемых киберпреступниками. Если уж приземлять ATT&CK на моделирование угроз, то это низкоуровневое моделирование. Сначала мы должны определиться с высокоуровневой моделью угроз, описывающей классы нарушителей и реализуемых ими действий "по-крупному", влекущих негативные последствия. Только определившись с ними, можно переходить уже к тактикам и техникам, который помогут мне не только понять, КАК меня могут взломать, но и помогут проводить киберучения, выявлять слабые места в текущей системе защиты, осуществлять поиск (threat hunting) следов незамеченных на этапе проникновения атак и т.п. И процессы высокоуровневого и нижнеуровневого моделирования не являются независимыми друг от друга - второе вытекает из первого. Высокоуровневая модель, она про ЧТО плохого со мной может произойти, а вот низкоуровневая, с тактиками и техниками, про то, КАК это плохое со мной может произойти. Если мы посмотрим на вот эту картинку из моего курса по моделированию угроз, то мы увидим, что ФСТЭК в этот раз сразу ушла в левую часть, забыв про правую или хотя бы середину, с которой и стоило бы начать.


В проекте методики ФСТЭК, к сожалению, первая часть совершенно упущена из ввиду. Разобравшись с типами антропогенных источников, мы сразу стали разбираться в сотнях миллиардов возможных сценариев реализации угроз (хотя правильно было говорить о сценариях атак, но это вряд ли возможно, так как термин "атака" уже закреплен за другим регулятором в области ИБ). При этом даже в части с TTP у текущего, "фстэковского" варианта, есть свои нюансы. Например, если посмотреть на онтологию взаимосвязей техник, тактик и процедур, то мы увидим, что они очень тесно завязаны с инструментарием, используемым тем или иным нарушителем (причем та же MITRE ATT&CK оперирует конкретными группировками, а не абстрактными антропогенными факторами), используемыми им командами и характеризующими его индикаторами (IOC). У ФСТЭК эти три компонента отсутствуют и у меня есть стойкое подозрение, что их и не появится, так как конкретными хакерскими группировками и их атрибуцией у нас в России если и занимаются, то только частные компании типа Лаборатории Касперского, Groip IB или Positive Technologies, а индикаторы у нас рассылают ГосСОПКА (ФСБ) и ФинЦЕРТ (Банк России). А будут ли все эти участники следовать общей стратегии я не знаю.


Еще один момент, связанный с развитием всего этого подхода. Матрица MITRE ATT&CK поддерживается и активно развивается международным сообществом ИБ и любой желающий может поучаствовать в расширении списка техник и атак. Кто будет поддерживать модель угроз и БДУ ФСТЭК? Один Воронежский ГНИИ ПТЗИ? Или им еще Positive Technologies будет помогать, чьи картинки используются в проекте методики ФСТЭК? Ну одна она будет не в состоянии это тянуть. В п.6.3 написано, что при выявлении новых TTP информацию о них надо направлять во ФСТЭК, но кто это будет делать и зачем? В итоге одни вопросы...

Но вернемся к проекту методики ФСТЭК. Выше я написал, что формирование перечня сценариев никак не связана с формированием перечня типов доступа, типов нарушителей, видов ущерба, целей и т.п. По уму, чтобы это вся схема заработала и было связано между собой, нужно иметь три уровня документов, которые можно было бы объединить термином "модель угроз":
  • Стратегический, описывающий общие, высокоуровневые угрозы типа "утечка", "вывод из строя", "повышение привилегий", "блокирование обновлений" и т.п. Текущий проект методики частично это делает, но только для определения нарушителей и их целей.
  • Тактический, описывающий как раз тактики и техники, то есть то, чему посвящен основной блок методики ФСТЭК.
  • Оперативный, описывающий конкретные правила обнаружения угроз для конкретных средств защиты и мониторинга. Этого в проекте методики нет вообще и это, скорее всего, "поле" ГосСОПКИ.


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


П.6.6 вновь напоминает, что моделировать угрозы надо на 5-ти уровнях - аппаратном, системном, прикладном, сетевом и сервисном. Правда, в 3-м разделе последний уровень касался только пользователей, а сейчас в него добавили еще Web-интерфейсы, информацию и иные компоненты (синхронизировать бы).

П.6.8 возникает в методике как гаишник из кустов на безлюдной трассе. Внезапно. Согласно нему угрозой считается совокупность ранее определенных:
  • источников, а их всего два, хотя тут по смыслу должны были быть типы нарушителей,
  • абстрактных условий реализации,
  • всех возможных сценариев реализации угроз
  • негативных последствий.
То есть оформление этого множества превратит специалистов по моделированию угроз в апологетов супрематизма. На рисунке 11 показан пример того, как может быть определен сценарий реализации угрозы. И такие картинки надо рисовать на каждый сценарий или группу сценариев. "Позитиву" впору выпускать библиотеку готовых сценариев или библиотеку иконок и шаблонов для их оформления. Большинство компаний будет не в состоянии оформить даже одну угрозу, не говоря уже обо всех. При этом п.6.8 зачем-то посылает нас на три буквы, то есть к БДУ, который должен стать основой для формирования исходного перечня угроз. Но формат БДУ сейчас вообще не соответствует тому, что написано в методике. И еще не меньше года не будет соответствовать, так как описать даже текущих 77 техник и соотнести их с текущими 200 угрозами - задача нетривиальная. Еще же надо не забыть решить вопрос с теми, кто уже провел моделирование по БДУ. Надо ли им будет все переделывать или нет? И, кстати, вопрос. Будет ли введена эта методика сразу или только после обновления БДУ?

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

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

На этом заканчивается 6-й раздел и мы почти подошли к финалу рассмотрения методики моделирования. В следующей заметке мы перейдем к 7-му, последнему разделу проекта методики, который... да-да, это еще не конец, позволит ранжировать все триллионы и миллиарды угроз по трем уровням опасности.

22.04.2020

Как я моделировал угрозы по проекту новой методики ФСТЭК. Часть 4

Раздел 5 погружает нас в мир нарушителей, которые могут атаковать нас или реализовывать непреднамеренные угрозы (то есть теща). Источниками угроз у нас могут быть как антропогенные, так и техногенные. Как мы помним из введения в методику, она не предназначена для моделирования последних. Тем непонятнее требование из п.5.1 моделировать и их, а также п.5.2, который описывает причины возникновения техногенных угроз и их источники. Так надо их моделировать или нет? И если да, то как? Куда хотя бы смотреть? Может в ГОСТ Р 51901 по анализу рисков технологических систем?

Возьмем, к примеру, проведение дистанционной телеконференции с помощью Zoom. Вполне распространенная практика, от которой, правда, многие отказываются из-за проблем с безопасностью на этой платформе. Согласно первым разделам методики, Zoom - это облачный поставщик услуг, от которого мы должны потребовать его модель угроз. Но вот в п.5.2 говорится, что низкое качество ПО, в том числе и уязвимости в Zoom, отсутствие безопасников в Zoom, недоступность Zoom из-за DDoS-атаки или бана со стороны Роскомнадзора и т.п., - это все приводит к угрозам техногенных источников. И как их моделировать? Они же вполне реальные. Почти все, что касается внешних поставщиков, согласно п.5.2 будет отнесено к техногенным источникам, работать с которыми непонятно как, так как проект методики рассчитан только на антропогенные угрозы. Но ФСТЭК путает окончательно в п.5.3 и примере 4, рассматривая в качестве источника угрозы программную или аппаратную закладку и предлагая учитывать ее при моделировании, хотя сама же в 1-м разделе утвердила распространение методики только на антропогенные источники.

Но самое неприятное, что ФСТЭК вводит новую классификацию источников угроз при наличии уже существующих и утвержденных. Например, для операторов связи есть утвержденный ТК362 (то есть ФСТЭК) ГОСТ Р 52448-2005. Там источников угроз три - субъект (то, что ФСТЭК назвала антропогенным источником), материальный объект и физическое явление (последние два ФСТЭК объединила под техногенным источником). В ГОСТ Р 51901.1-2002 по управлению рисками технологических систем источников уже 4 - природные, технические, социальные и связанные с укладом жизни. А есть еще ГОСТ Р 51275-2006 или ГОСТ Р ИСО/МЭК ТО 13335-3-2007, который определяет три источника угроз - естественный, преднамеренный и случайный.
Но идем дальше. Источником антропогенных угроз является лицо (группа лиц), которое реализовало угрозу путем несанкционированного доступа или воздействия на информационные системы. Я попробовал представить себе ситуацию, когда я, находясь на удаленном доступе, выложил на разрешенный Box или Dropbox конфиденциальные файлы (это допустимо), но дальше по причине корявости рук нашего админа или админа Box/Dropbox файлы оказались доступны неограниченному кругу лиц. Кто тут является нарушителем? Я ничего несанкционированного не делал. Админы тоже никак несанкционированно не воздействовали на систему. Скорее их бездействие привело к тому, что угроза утечки информации реализовалась. Методика этот момент не учитывает. Дима Кузнецов, комментируя моя заметки в Фейсбуке, написал, что бездействие админа - это не угроза, а уязвимость! Возможно, ему, как участнику последнего состава рабочей группы по разработке проекта методики, это понятно. Но вот мне, участнику предпоследнего состава :-), это совсем неочевидно. Вообще текст методики с последних чисел декабря изменился кардинально - как новый документ читаешь.

Не успев остыть от деления типов доступа при реализации угрозы на локальный, внешний и физический (так и повеяло CVSS, который применяется при анализе защищенности и который так любят разработчики сканеров безопасности), п.5.4 вводит градацию внешний/внутренний нарушитель. Кстати, сам термин "нарушитель" скачет по тексту как ныряющая золоторудная россыпь из романа Олега Куваева "Территория"; то тут всплывет, то там, но так и непонятно, кто это. Антропогенный источник - это нарушитель? Или антропогенные источники бывают и другие? Допустим обезьяна, которая живет дома у админа КИИ, который имеет удаленный доступ к СуКИИ, случайно запустила цепную реакцию на АЭС. Это антропогенный фактор или...?

Понятие внешнего нарушителя почему-то тесно завязано на наличие Интернет (прямо или косвенно). А если его нет? Вот представим себе такую ситуацию. Я работаю в изолированной среде, например, на атомной станции. И мне подкидывают флешку с вредоносным кодом (кто сказал Stuxnet?). А вредоносный код был залит на флешку на полигоне АНБ в штате Айдахо (кто сказал, что там есть только полигон МинЭнерго США и лаборатории INL?). И в Интернет этот вредоносный код никогда не попадал, как и в смежные с атакующей системой тоже. Каким нарушителем мне считать АНБ в этом случае? Под определение внешнего оно не подходит. Ну а внутренним тем более. Или более приземленный пример с системой удаленного доступа. Живет у нас в доме, на одном со мной этаже, сотрудник Хуавей. И допустим, написал он на своем домашнем ПК вредоносную программу, которую он, поигравшись с моим домашним Wi-Fi, засадил на мой домашний ПК. Это какой нарушитель - внутренний или внешний? Кстати, можно ли к беспроводным сетям применять термин "линия связи, расположенная за пределами контролируемой зоны"? Хотя, вон, Роскомнадзор и депутаты вполне себе применяют к Интернет термин "государственная граница"...


С внутренними нарушителями все, более или менее, понятно. Вот сотрудник Zoom, сидящий в Китае, для меня является нарушителем внутренним. И сотрудник Apple, который обеспечивает поддержку моего Macbook, тоже. А вот фирма DHL, которая перевозит мой сломанный ноутбук из моего дома в Apple, - это уже нарушитель внешний. По крайней мере, так написано в проекте методики.

П.5.5 является очень важным, так как говорит, что мы должны определить для себя актуальных нарушителей, для чего надо предположить, зачем им нас атаковать. Допустим, я предположу (имею право), что меня может атаковать компания Хуавей и попробовать через меня попасть во внутреннюю сеть Сиско и украсть наши ноу-хау. Это будет п/п.20 из таблицы 2, а значит уровень возможностей нарушителя будет базовый повышенный. Может ли меня атаковать АНБ? Да фиг там. Исключаю. А ФСБ? Да вот тоже. Исключаю. Могу ли я предположить, что компания Apple, операционной системой которой я пользуюсь, решила внедрить в macOS скрытые функции на этапе разработки? Могу. А могу ли я предположить, что АНБ на этапе поставки ко мне моего ноутбука для удаленного доступа внедрила в него скрытые функции? Тоже могу. Но я считаю для себя это неактуальным. Вычеркиваю.

Местами все-таки таблица 2 вызывает вопросы. Например, для киберпреступных группировок, крадущих деньги, уровень возможностей определен как базовый повышенный. Хотя мы все видим, что их возможности иногда мало чем уступают спецслужбам иностранных государств, а иногда и превосходя их (и это если не брать в расчет наличие в свободном доступе инструментария АНБ и ЦРУ, утекшего в результате известных инцидентов Vault7 и Shadow Brokers). Но если та же группировка работает в интересах спецслужб (а мы знаем, что есть группировки, которые работают сразу по нескольким фронтам), то ее уровень возможностей автоматически взлетает до максимального - высокого. А куда относить хакеров, нанятых спецслужбами?

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

Разобравшись с актуальными для себя типами нарушителей и тем, какие цели они преследуют, я по таблице 2 определяю потенциал нарушителя, а по таблице 3 его возможности. В итоге мы получаем 4 модели нарушителя - Н1-Н4. Как их соотнести с моделями нарушителя Н1-Н6 ФСБ даже и не спрашивайте. Пожалуй, единственное, что точно можно сказать, что Н4 по ФСТЭК - это тоже самое, что и Н6 по ФСБ.

Мы подошли к концу пятого раздела, по итогам которого у меня должны сформироваться списки:
  • Источников угроз. Хотя я могу сразу сказать, что у меня будут оба источника - антропогенный и техногенный. Это можно было так и записать в методике и не мучаться с описанием на две страницы.
  • Возможных целей нарушителей. Тут чистое творчество - методика никак мне не подсказывает, как это сделать. Я бы попробовал совместить список целей из таблицы 2 с предложенным в прошлой заметке списком видов ущерба.
  • Категориями и видами нарушителей. Я могу заранее утверждать, что у меня возможны обе категории нарушителей (внешние и внутренние); даже в условиях корявости их определения. Вот с видами чуть сложнее - понадобится экспертная оценка. Но спецслужбы, террористов и экстремистов я бы исключал в 99% случаев; как и единожды встречающихся разработчиков и производителей ПО и железа (а вот почему-то объединенных с ними поставщиков ПО и железа вообще бы исключил или перенос бы к ремонтникам).
  • Возможностей нарушителей, который автоматически вытекают из таблицы 2 и 3, и знание источников угроз и категорий нарушителей никак тут не нужно.
ЗЫ. В Фейсбуке Дима Кузнецов активно комментирует блогеров, написавших про методику, и разъясняет, что мы в своих вопросах неправы и все не так понимаем и что трактовать "это" надо так-то и так-то. Допускаю, что это так. Но хотелось бы в тексте, который будут использовать в том числе и небольшие организации, не имеющие в своем штате специалистов по ИБ, не было двойственных и тройственных толкований и совсем непонятных моментов. Хотелось бы ясности. Поэтому я подсвечиваю такие моменты, "проходясь" по шагам предложенной методики. По итогам этого блиц-анализа, растянутого на несколько дней, я сформирую список конкретных предложений и направлю его в ФСТЭК.

21.04.2020

Как я моделировал угрозы по проекту новой методики ФСТЭК. Часть 3

А я продолжаю свое путешествие по проекту методики моделирования угроз и перехожу к 4-му разделу, который позволяет оценить мне потенциал нарушителя или, как написано в методике, условия реализации угроз безопасности информации. Почему я оцениваю потенциал нарушителя ДО определения самих нарушителей, для меня остается тайной. Возможно потому, что пройдя через 4-й раздел вы поймете, что вам уже все равно, кто вас атакует - мамкин хакер или хакер в погонах. А может потому, что потенциал нарушителя, то есть оценка его возможностей, описывается в 5-м разделе? Зачем надо было разделять условия реализации угроз и возможности нарушителя?

Что нарушитель что-то плохое сделал с вашей системой должно совпасть два условия - должны быть уязвимости и у злоумышленника должен быть доступ для реализации угроз. Про второе мы поговорим чуть позже, а пока попробуем разобраться с первой частью. Уязвимости необходимо оценить все! В ПО, в архитектуре, в конфигурации, в организации процесса. Причем первые три типа уязвимостей могут быть не только на уровне общесистемного и прикладного ПО, сетевого оборудования и средств защиты, но и на уровне микропрограммного ПО, то есть на уровне BIOS, процессоров, контроллеров и т.п. Определение "недекларированных возможностей" из раздела 4.4 мне показалось очень размытым и совершенно неформализованным (ну что такое "потенциально опасные функциональные возможности"), но важно, что НДВ могут быть внедрены как разработчиком используемого в ИС софта и железа, так и иными нарушителями на этапе поставки, производства и ремонта (привет, Сноуден).

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

Пункт 4.7 предлагает мне подумать над тем, откуда нарушитель может реализовать свои угрозы - удаленно, локально или... физически. Для меня деление на локальный и физический доступ выглядит несколько надуманно; даже при разъяснении в примере 4. Вот представьте, что вы согласно 3-му разделу отнесли к компонентам ИС PLC или IP-телефон. Если я втыкаюсь в PLC, находясь внутри компании, или подменяю IP-телефон, то это какой доступ, локальный или физический? А в случае с удаленным доступом, если теща со своей учетки решила разложить пасьянс на домашнем ПК, подключенном к корпоративной сети, и случайно занесла на этот компьютер вредоносный код, то это какой доступ - удаленный, локальный или физический? Или, вспоминая первую заметку, это вообще не угроза, так как никаких неправомерных действий теща не совершала? :-) Теще, кстати, посвящен п.4.8, но и он не отвечает на вопрос выше.


Трата времени на определение типов доступа при моделировании угроз по анализируемой методике является, на мой взгляд, избыточным. В 6-м разделе, в п.6.5, говорится, что тип доступа определяет начальные тактики Т1 и Т2. Фигушки. Ничего он не определяет, так как Т1 - это сбор информации о сетях и системах, а он, и это я бы принял за аксиому, проводится почти во всех серьезных сценариях угроз (а для непреднамеренных угроз "отказ" нарушителя от этой тактики не влияет на конечный результат методики - для остальных типов нарушителей сбор всего равно осуществляется и мы все равно должны на него закладываться). С Т2, получением первоначального доступа к компонентам систем и сетей, тоже все проще. Я вот с трудом себе представляю ситуацию, когда злоумышленник действует только извне или только изнутри. А если мы посмотрим на 5-й раздел (его мы анализируем завтра), то вы поймете, что из-за нечеткости определения внутреннего и внешнего нарушителя и достаточно динамичного перехода одного статуса в другой, совершенно не важно, какие типы доступа у вас есть - вы все равно, перебирая сценарии угроз, включите в список актуальных оба варианта. По-другому сегодня просто не бывает.

Раздел завершается пунктом 4.9, который говорит, что должно быть определено по итогам оценки потенциала нарушителя. Но я так и не понял, что, а самое главное, как это должно быть определено. Как, конкретно, выявить уязвимости на этапе создания системы? Как, конкретно, выявить уязвимости, на этапе эксплуатации системы (или только пентест, условия проведения которого выходит за рамки методики)? Как выявить недекларированные возможности? По ДСПшному документу ФСТЭК (ну так где ссылка на него или выписку из него)? Зачем мне подробное описание типов доступа нарушителей и как я его должен использовать (кроме п.6.5)? А самое главное, как все выявленное я должен описать? В разделе 3 хотя бы пример таблицы был дан, а тут пустота. Возможно, в следующих разделах станет понятно, зачем это все надо было. Но пока 4-й раздел выглядит для меня незаконченным.