Сколько ИБшников надо в штат службы ИБ: формула расчета

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

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

Очевидно, что чем крупнее организация, тем больше функций ИБ в ней реализуется и тем больше времени на них нужно. Но в данном примере нам нужно 140 часов в неделю, что при 40 рабочих часах по Трудовому Кодексу составит 3,5 FTE (Full-Time Equivalent). Иными словами, вам нужно (если отбросить в сторону круглосуточный режим работы некоторых функций) 3,5 сотрудника, чтобы обеспечивать минимальный набор функций ИБ на среднестатистическом предприятии. Если у вас в штате всего 2 человека, то вам не хватает "полутора землекопов", а на самом деле двух, так как у нас еще не научились делать половинки людей.

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

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

Возможно, вам стоит заранее подготовить этот список альтернатив с описанием каждой из них, чтобы руководство принимало решение, опираясь на конкретику, а не на эмоции. Теперь, когда вам надо будет добавить новых функций, например, после появления новой нормативки, вам будет проще добавлять к имеющемуся расчету новые FTE. Допустим, вы банк и вам "навесили" обеспечение непрерывной надежности и уведомление ФинЦЕРТ об инцидентах ИБ, а ИТ сбагрила вам проект по идентификации и аутентификации. В итоге у вас получится уже 260 часов или 6,5 FTE (7 человек).

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

Если вы хотите увидеть какие-то иные оценки временных затрат на обеспечение отдельных функций ИБ, то я могу порекомендовать интереснейший документ от Банка России, а именно РС 2.7 2015-го года по ресурсному обеспечению ИБ в финансовой организации. Он, правда, ориентирован еще на СТО БР ИББС, но ежегодные усилия для каждого процесса ИБ там расписаны достаточно детально. Согласно Банку России минимальный состав службы ИБ банка составляет 12 человек (при росте числа филиалов и отделений и число растет пропорционально). Там приводится более сложная формула расчета ресурсов, но суть у нее та же.

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

Подробнее…

Калькулятор оценки технологической зрелости соответствия 239-му приказу

 Несколько лет назад, а именно пять, я писал о том, как можно было бы облегчить жизнь с реализацией приказов ФСТЭК, внедрив неку/ю модель зрелости, которая бы позволила оценивать текущий уровень реализации требований регулятора и выстраивать некую дорожную карту достижения желаемого уровня соответствия. К сожалению, описанная мной тогда идея так и осталась идеей и, в отличие от NIST, который к своему фреймворку CSF предложил как раз схожую тему, наш регулятор, видимо по причине загруженности в условиях нехватки кадров, оставил этот вопрос в стороне. И вот на днях подумал я, что неплохо бы реализовать такую идею самостоятельно, что я и сделал. Итак, представляю калькулятор оценки технологической зрелости реализации приказа №239 ФСТЭК (для значимых объектов КИИ).

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

В итоге получилась вот такая табличка, где для каждого блока защитных мер были выделены 5 уровней зрелости, характеризующихся применением тех или иных технологий или тем или иным уровнем автоматизации. Например, на первом уровне блока ИАФ (идентификация и аутентификация) компания применяет обычные пароли для своих пользователей. Затем она переходит к многофакторной аутентификации, потом задумывается о Zero Trust или 802.1x начинает аутентифицировать не только пользователей, но и устройства. Потом компания созревает до доступа к своим активам внешних пользователей и начинает аутентифицировать их, а в финале, на пятом уровне зрелости, применяет федеративную систему аутентификации, применяемую в том числе и на внешних ресурсах - облаках и т.п.

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

Но и с обнаружением вторжений ситуация не столь сложна, как с аудитом безопасности, под которым приказ 239 понимает не только классический аудит, но и мониторинг ИБ, а также применение решений по анализу трафика, которому, на мой взгляд, место больше в обнаружении вторжении. Но такова уж карма термина "активный аудит", который в России известен уже давно и в него засовывают и обнаружение вторжений, и анализ защищенности. Но и с этим я тоже справился. В итоге получилась небольшая таблица, в которой достаточно всего лишь 20 раз выбрать нужный уровень вашей технологической зрелости, после чего будет отрисована радарная диаграмма, показывающая уровень зрелости по каждому из блоков защитных мер и насколько нам далеко до желаемого/рекомендуемого уровня. Кстати, о последнем. Я его выбирал опираясь на собственный опыт. При желании там можно поиграться с уровнем, к которому надо стремиться.

Вот такой вот легонький инструмент, который я выложил у себя в Телеграме.

Подробнее…

Что общего между числом калорий и числом инцидентов? И снова о метриках ИБ (анонс нового Telegram-канала)

Каждый год многие, я так думаю, ставят перед собой какие-нибудь амбициозные цели, например, похудеть. Ой, что это я, мы же про безопасность говорим. Значит ставятся цели по ИБ. Допустим снизить число инцидентов в день с 23 до 18 или на 17%. Вроде бы красивая и нужная цель, но чтобы достичь ее, необходимо произвести ряд шагов. И раз уж я упомянул похудение, то попробуем сравнить эти два процесса между собой.

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

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

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

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

С инцидентами все тоже самое. Само по себе снижение числа инцидентов не говорит ни о чем. Причиной этого может быть:

• снижение зоны покрытия мониторингом
• пересмотр понятия инцидента
• скрытие инцидентов.

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

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

1. Измерять все. Потом
2. Измерять правильные вещи. Потом
3. Измерять правильные вещи правильным образом

Но начинать с измерения всего (ну или многого).

И вот тут я подступаю к тому, для чего писалась эта длинная заметка. Решил я тут поддаться модному поверью, называемому гитхабизации ИБ (на русском), и запустить новый Telegram-канал по метрикам ИБ (Cyber Security Metrics). Буду ежедневно делиться одной метрикой ИБ с ее кратким описанием, формулей, источниками данных, ограничениями и т.п. На самом деле это, конечно, не гитхабизация, но как это назвать, я не знаю. Сначала я думал заделать сразу каталог метрик и выложить его на Github, но времени на то, чтобы сделать это сразу и все, нет. А вот по частям мне показалось вполне подъемной задачей. В день по метрике - к концу года получится 250 разных метрик из разных доменов ИБ - реагирование на инциденты, управление уязвимостями, Red Team, Privacy, управление финансами, мониторинг ИБ, compliance и т.п. В отличие от своего текущего канала "Пост Лукацкого", у нового я включил возможность комментариев и обсуждения, чтобы можно обсуждать каждую метрику, делиться опытом и т.п.

Так что добро пожаловать в новый Telegram-канал, который будет этаким регулярно наполняемым каталогом метрик по ИБ.

Подробнее…

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

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

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

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

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

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

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

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

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

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

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

Подробнее…

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

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

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

Подробнее…

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

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

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

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

Подробнее…

О необходимости регулярного пересмотра метрик в SOC

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

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

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

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

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

Подробнее…

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

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

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

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

Подробнее…

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

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

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

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

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

Подробнее…

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Подробнее…

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

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

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

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

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

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

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

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

: 

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

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

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

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

Подробнее…

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

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

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

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

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

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

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

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

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

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

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

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

Подробнее…

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

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

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

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

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

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

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

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

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

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

Подробнее…

Как ДИБ и ФинЦЕРТ могли бы улучшить кибербезопасность финансовых организаций?

Одним из часто звучащих вопросов от руководства, которое мало что смыслит в ИБ, но хочет держать руку на пульсе, среди прочих, является: "Как мы соотносимся с конкурентами?" За этим, казалось бы простым и сложным одновременно, вопросом скрывается вполне понятные управленческие решения. Мы хуже других - значит надо "наказать" виновных и инвестировать в улучшения. Мы лучше других - надо наградить "непричастных" и хвалиться этим.

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

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

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

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

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

И ЦБ - единственный из всех регулятор, кто способен это сделать. У ФСТЭК нет этих данных, хотя если аккумулировать результаты аттестаций, то может получиться тоже неплохая аналитика. ФСБ/НКЦКИ все по привычки засекречивает и делится только данными о десятках миллионов атак, отраженных на сайт Президента России. И только ЦБ в лице ДИБ не только имеет все необходимые данные, но и может их публиковать, так как уже делал это раньше и делает сейчас по смежным направлениям своей деятельности. Думаю, вот за это ДИБу бы реально сказали "спасибо". А то попытка вынести тему ИБ на уровень Правления, предпринятая в проекте положения по системе управления операционными рисками в принципе неплоха, но очень уж сложна для восприятия и реализации. Я уже дважды прочитал именно эту редакцию проекта, но пока в голове не уложил всю схему того, что хочет сделать ЦБ и как это соотнести с уже имеющимися мероприятиями по ИБ, требуемыми по другим нормативным актам регулятора.

Подробнее…

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

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

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

Бизнес-метрики ИБ для руководства финансовой организации from Aleksey Lukatskiy

Подробнее…

Измерение эффективности ИБ промышленных систем

На прошлой неделе мне довелось выступать на конференции Kaspersky ICS Cybersecurity Conference с докладом, посвященным оценке эффективности ИБ промышленных систем. Оказалось, что я удачно дополнил доклад выступившего передо мной Патрика Миллера из Archer про коммуникации с бизнесом. У меня же доклад был более приземленный с примерами метрик, которые могут быть использованы при оценке своей эффективности и последующей коммуникации с бизнесом.

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

Выкладываю свою презентацию:

Измерение эффективности ИБ промышленных систем from Aleksey Lukatskiy

Подробнее…

Пять уровней зрелости оценки ущерба от DDoS-атак на сайт организации

Понравилась мне прошлая заметка про ИБ для бизнеса на примере HR-подразделения. Она и дискуссии на прошедшем "Код ИБ. Профи" подтолкнули меня к идее данной заметки. На мастер-классе Рустема Хайретдинова зашел разговор о том, как можно показать влияние ИБ на бизнес, и прозвучал тезис о том, что бороться с угрозами не всегда необходимо, так как они не всегда интересны бизнесу. Этот тезис не нов, но дальше был приведен пример сайта, который подвергается DDoS-атаке, и который нуждается в защите... Или все-таки не нуждается?

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

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

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

Многие виды бизнеса являются сезонными. Турагентства продают большинство путевок перед майскими, летними и зимними каникулами. Интернет-магазины также имеют сезонные всплески - перед Рождеством, перед Новым годом, перед 14-м и 23-м февраля, а также 8-м марта. Кроме этого, глупо думать, что посетитель, столкнувшись с простоем сайта, навсегда про него забудет и откажется от покупки. Он может прийти через 15 минут и совершить покупку. Он может позвонить по телефону в отдел продаж или написать по электронной почте, а потом продолжить цикл покупки снова через сайт. Поведение пользователя и цикл продаж - это два важных параметра, которые вам потребуется узнать у вашего коммерческого подразделения прежде чем вы снова возьметесь за калькулятор.

Но можно (а временами и нужно) пойти дальше. Помимо учета множества показателей, связанных с циклом продаж, профилем пользователя, временными спадами и пиками, размер средней сделки, количеством транзакций и т.п., мы должны также оценить финансовые показатели приобретаемого средства защиты от DDoS. Понятно, что эта сумма не должна превышать размер ущерба, но это совсем уж поверхностное суждение. Борьба с DDoS может быть представлена в виде облачного или on-prem решения (то есть продаваться по модели OpEx или CapEx соответственно). Купить такое решение можно поставив его на баланс, а можно воспользоваться лизингом. Оплата может быть произведена как за год использования (типичная схема для большинства средств защиты), так и помесячно или в пиковые интервалы продаж/спроса со стороны клиентов, а также по схеме "on-demand", то есть во время самой атаки. При этом последний вариант тоже может быть реализован по-разному - оплата "за атаку" или оплата "за полосу". И вот собрав воедино все финансовые, маркетинговые и айтишные показатели, можно уже заниматься расчетом ущерба от DDoS-атак и его оценкой применительно к конкретной организации. И только в этом случае можно говорить о том, нужна ли конкретному бизнесу защита от DDoS-атак или можно принять данный риск.

Подробнее…