Опыт полутора десятков онлайн-курсов за время самоизоялции

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

3,5 месяца самоизоляции (а мы глобально продолжаем на ней находиться до конца осени) позволили высвободившееся от очных мероприятий и командировок время уделить самообразованию, которое в 100% случаев проходило дистанционно. И это были совершенно разноплановые курсы - от продуктовых по Cisco до трехдневного курса по проектированию и планированию SOCов, от создания дашбордов до организации собственной онлайн-школы, от создания бизнеса с нуля (две недели со стартаперами) до сетевого threat hunting'а. На что-то я пошел для систематизации собственных знаний и навыков, что-то было обязательным на работе, а что-то было просто интересно изучить с точки зрения расширения кругозора. Заодно я прослушал записи ряда конференций по ИБ - от RSA Conference 2020 или Cisco Live US 2020 до "Кода ИБ. Профи" или конференции по ИБ O'Reily. И что я могу сказать по итогам такого образовательного дистанционного интенсива?..

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

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

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

В-четвертых, на западных очных курсах обычно даются задания, которые вы выполняете во время многодневного курса. Например, на курсах SANS по обнаружению атак, SOCам, безопасности промышленных систем, Threat Hunting или реагированию на инциденты, в которых я участвовал у вас в день обычно проводится по 5-6 лабораторных работ, что приводит к 20-25 лабам за 4 дня, после чего пятый день целиком выделяется на практику. У нас такое мало где делается, а в онлайн это сделать вообще проблематично; как с точки зрения организаторов, так и с точки зрения слушателей. Особенно последним сложно - они же могут забить болт на "домашку" и ничего не делать. И проверить их сложно (хотя можно). В итоге обучение получается неполным. На очном обучении вы не можете откровенно манкировать заданиями, которые вокруг вас все делают.

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

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

1. Чем отличается дистанционное обучение от очного?
2. Будут ли домашние задания, включая стоп-задания (без которых нельзя пройти дальше)? На одном из курсов только стоп-задания заставили меня дойти до финала - курс был достаточно неудачно организованным, но я хотел его завершить и только стоп-задания стимулировали меня это сделать.
3. Какая платформа используется для обучения (специализированная или обычная, вебинарная)? Например, некоторые учебные центры используют Webex Meetings, который, в отличие от Webex Trainings, не очень подходит именно для обучения, при котором происходит активное взаимодействие со слушателями. А вот Webinar.ru, Youtube или Facebook, который также нередко используют для прохождения курсов, для этого совсем не предназначены.
4. Могу ли я общаться с другими участниками и как? В одном из курсов это происходило только в чате и только во время присутствия лектора, а в другом - организаторы создали специальные группы в Фейсбуке и Телеграме для постоянного общения.
5. Могу ли я задавать вопросы инструктору, в том числе и в частном порядке? Как это делается - в чате или голосом (писать длинные вопросы любят далеко не все)?
6. Будут ли мне доступны учебник и сопутствующие материалы (например, SANS заранее присылает вам коробку с учебниками и флешку с виртуалками для лабораторных работ)?
7. Как контролируется прогресс в обучении? Где-то это могут быть стоп-задания, а где-то специальная метрика, отражающая кумулятивный параметр оценки прохождения курса и выполненных домашек. 
8. В течение какого времени я буду иметь доступ к материалам онлайн-курса? У SANS, например, это обычно 6 месяцев. У курса по созданию бизнеса с нуля авторы предоставили пожизненный доступ к материалам. У всех все по-разному.
9. Если вам это важно, то уточните, сколько CPE вы получите от прохождения того или иного курса. Знаю, что многие сертифицированные специалисты иногда только ради CPE и ходят на конференции и обучение :-)

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

Подробнее…

Алгоритм оценки необходимости выполнения НПА по ИБ

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

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

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

Четвертый вопрос еще интереснее. Вот есть у вас требование и оно легитимное и даже проверяющие есть, и они даже прийти могут проверить. А наказать они нас могут, если мы что-то не выполняем? Например, по теме КИИ сейчас всего одна статья и она уголовная (ст.274.1). Да, регуляторы внесли законопроект об изменении КоАП и появлении там новых составов правонарушений, но пока их нет. А раз наказать нельзя, то стоит ли так стремиться выполнять требования? С точки зрения бизнеса, который считает свои затраты и не видит рисков, положительный ответ будет не столь очевидным. Понятно, что можно расширить этот вопрос и уточнить масштаб наказания. Например, за невыполнение требований ФЗ-152 размер штрафов незначительный, в отличие от штрафа за нарушение GDPR. 

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

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

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

Подробнее…

Что больше нужно предприятию - служба ИБ или функция ИБ?

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

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

Попробую пояснить на простом визуальном примере. Если мы посмотрим на большинство стандартов, best practices, приказов регуляторов и т.п., то мы увидим, что все они исходят из простой парадигмы - кибербезопасностью должна заниматься отдельная служба кибербезопасности (или ИБ, или ЗИ). Это стало "аксиомой" и чем серьезнее защищаемая система, тем больше она, по мнению авторов лучших практик, нуждается в отдельном подразделении. И, как следствие, многие продолжают эту мысль и считают, что вся ИБ должна быть сосредоточена в службе ИБ. Поэтому и тема персональных данных у нас часто попадает в руки безопасников; хотя в Европе, согласно тому же GDPR, этой темой занимаются совсем другие люди, далекие от ИБ и вообще ИТ. Многие ИБшники свою деятельность видят вот так:  

Есть отдельные подразделения, которые занимаются бизнесом, и есть служба ИБ, которая, как шериф на диком Западе, защищает бизнес от плохих парней, покушающихся на него. Как только возникает такая картинка, сразу всплывают вопросы, на которых традиционный безопасник не может дать ответа. Кто должен заниматься борьбой с мошенничеством (часто антифрод находится в руках отдельных людей)? Кто должен мониторить даркнет (часто это вешают на PR-службу)? Кто должен заниматься мониторингом использования ваших доменов (часто это вешают на digital marketing)? Кто должен заниматься повышением осведомленности персонала (часто это вешают на HR)? Кто должен заниматься обеспечением бесперебойной работы сайта (часто это вешают на ИТ)? Кто должен заниматься повышением продуктивности пользователей, тратящих время на чтение спама (часто это вешают на operations)? Кто должен заниматься управлением уязвимостями (часто это вешают на ИТ)? И т.д. По сути, у безопасников в руках остаются только вещи, которые прописаны в нормативных документах, то есть они занимаются так публично нелюбимой ими же (но так желаемой по ночам) бумажной безопасностью. А все потому, что они мыслят в терминах подразделений, отделов, служб, у которых есть свои полномочия, свой бюджет, свои ресурсы...

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

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

Подробнее…

Игра Cybersecurity Alias

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

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

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

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

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

Подробнее…

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

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

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

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

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

Подробнее…

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

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

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

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

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

Подробнее…

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

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

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

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

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

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

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

Подробнее…

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Подробнее…

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

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

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

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

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

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

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

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

: 

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

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

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

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

Подробнее…

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

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

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

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

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

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

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

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

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

Подробнее…

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

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

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

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

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

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

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

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

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

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

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

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

Подробнее…

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

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

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

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

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

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

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

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

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

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

Подробнее…

Как я моделировал угрозы по проекту новой методики ФСТЭК. Часть 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 тысяч долларов за документ.

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

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

Подробнее…