08.07.2020

Опыт обучения на курсах по SOCам

Упомянул вчера про прохождение курса по SOCам (для тех, кто думает, что SoC - это System-on-Chip, сообщаю, что это Security Operations Center) и хочу поделиться некоторыми впечатлениями. Начну с того, что когда речь заходит об обучении по SOCам, нет ни одного курса, который бы закрыл все потребности в этой части, как нет человека, который в SOC занимается всеми направлениями - от мониторинга до реагирования, от threat hunting до threat intelligence, от проектирования архитектуры до формирования плана обучения аналитиков. Это все разные задачи, которыми занимаются разные роли внутри SOC. Поэтому и обучение тут нужно разное. Одним нужны курсы по Threat Hunting, другим по реагированию на инциденты, третьим по организации Red Team (если это часть сервисной модели SOC), четвертым - по планированию и проектированию SOC. Я про это уже и писал и выступал, но посчитал нелишним упомянуть еще раз. Так вот сейчас я бы хотел поделиться впечатлением о курсе именно про планирование и проектирование SOC, который ориентирован больше не на аналитиков по мониторингу ИБ (типа CompTIA Cybersecurity Analyst, о прохождении которого я уже писал, или Cisco CyberOps Professional), а на руководителей центров мониторинга или их аудиторов и проектантов (проектировщиков). Ну а так как я в последнее время глубоко погружен в эту тему и участвую в разных проектах по аудиту или проектированию SOCов, то я и решил, что надо систематизировать свои знания по этой теме.

Хочу отметить, что курсы по проектированию SOCов я нашел только у SANS. Первоначально это был пятидневный курс SANS MGT517, который разработал и вел Chris Cowley. Позже, причина до сих пор непонятна, MGT517 был закрыт SANS'ом и долгое время никаких специализированных курсов по SOCам не было, пока в прошлом году Крис не анонсировал собственный трехдневный курс по SOCам (его я и проходил недавно), а SANS не запустил двухдневный курс MGT551 имени Джона Хаббарда. MGT551, по словам его автора, является дополнением к его же курсу SEC450 по Blue Team и позволяет дополнить картину уже с высоты птичьего полета, с точки зрения менеджера SOC. Курс Криса по-прежнему ориентирован только на руководителей/аудиторов/проектантов SOC и не является дополнением к чему бы-то ни было. У SANS есть еще шестидневный курс SEC511 по непрерывному мониторингу и SecOps, но он схож с упомянутыми выше курсами CompTIA и Cisco CyberOps, то есть ориентирован именно на специалистов по мониторингу ИБ, чем на лидеров.


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

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

Очень много времени уделяется вопросу выбора и обоснования. Например, как обосновать необходимость SOC руководству компании, какие доводы использовать, каким ролям CxO важны какие задачи SOC и т.п.


С выбором связана и тема смен в SOCах. Крис давал различные модели и описывал их плюсы и минусы. Полезная тема с точки зрения планирования работ персонала и определения численности сотрудников SOC.  


Фанатам технологий тоже было уделено внимание, но не с точки зрения лабораторных работ по конкретным платформам и инструментам, а с точки зрения их выбора. например, какие альтернативы есть для защиты коммуникаций в SOC, для TI, для SOAR, для SIEM и т.п. Причем они сравниваются по разным параметрам (цена, функциональность и т.п.), что дает возможность слушателям потом выбирать то, что лучше подходит под их задачи. Никаких "купите QRadar как SIEM" или "только Webex Teams может быть использован для коммуникаций внутри SOC".

Тема технологий развивается и с точки зрения геополитических рисков. Но не "Русские хакеры! Все пропало!", как это было на курсах SANS по промышленной ИБ, а с точки зрения оценки рисков использования различных технологий и сервисов от разных компаний и стран. Интересно, что Крис не просто показывает всякие прикольные таблички, а потом отдает их и с ними можно играться по своему усмотрению.


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

Хороший раздел про разработку use case. Причем не только с точки зрения теории, но и практики.


Например, выдали табличку с кучей готовых use cases с их разбиением по L1-L3, привязкой к матрице MITRE ATT&CK, метриками и оценкой их эффективности. Полезная штука - мы в рамках наших проектов по SOC тоже используем схожую табличку в Excel, куда заносятся все Use Case, которые мы разрабатываем и с которыми потом можно работать, а не просто теоретизировать. 


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


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


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

ЗЫ. Вроде как Крис упоминал, что ему тоже не очень понравилась идея онлайн-курса по SOC и, возможно, больше таких не будет, - останутся только очные мероприятия, что увеличит цену на них, минимум, вдвое (за счет билетов и проживания). И это не считая сложностей с командировкой за пределы страны (сам Крис из США, но иногда проводит курсы в Европе, куда попасть сейчас непросто).

07.07.2020

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

Так сложилось, что я не очень люблю отечественные учебные центры; не важно, в какой области они преподносят свои курсы - в ИБ ли или в чем-то ином. Пройдя немалое количество курсов западных (я тут посмотрел в нашей корпоративной 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ам.

15.06.2020

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

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

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

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

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

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


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


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

08.06.2020

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

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

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

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


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

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


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

02.06.2020

Игра Cybersecurity Alias

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

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

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

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

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


29.05.2020

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

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


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


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

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

25.05.2020

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

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



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

21.05.2020

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

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

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


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

20.05.2020

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

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

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


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


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


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

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


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


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


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

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


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


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


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


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

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

15.05.2020

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

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

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


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


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


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


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


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

: 

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


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


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

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


14.05.2020

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

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

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


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

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

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

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

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

13.05.2020

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

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


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


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


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


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


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


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


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


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

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


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