Firemon покупает Lumeta

29 мая компания Firemon, занимающаяся управлением сетевыми политиками безопасности, объявила о намерении приобрести компанию Lumeta, игрока специфической ниши по ситуационной осведомленности. Детали сделки не раскрываются.

Искусственный интеллект в кибербезопасности (презентации)

Четвертым, финальным докладом на IT & Security Forum, стала тема искусственного интеллекта в кибербезопасности. Учитывая сокращенный формат, я с одной стороны подсократил презентацию, которую я читал на RIGF, а с другой добавил туда ряд новой информации из презентации, которую я читал в Школе управления Сколково. В итоге получилось вот такое творение:

Кибербезопасность и искусственный интеллект from Aleksey Lukatskiy

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

Проведение киберучений по ИБ для топ-менеджмента (презентация)

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

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

Киберучения по ИБ для топ-менеджмента from Aleksey Lukatskiy

Антисуслик Шредингера: документы ФСБ, которые есть и которых нет одновременно (презентация)

Продолжаю публиковать презентации с ITSF, которые я читал на этом прекрасном мероприятии. Эта связана с кратким обзором проектов приказов ФСБ по ГосСОПКЕ, которые должны были быть приняты до 1-го января, но до сих пор находятся в статусе проектов. В них есть энное количество неочевидных вопросов, которыми я и задался в рамках своего доклада.

Антисуслик Шредингера: документы ФСБ, которые есть и которых нет одновременно from Aleksey Lukatskiy

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

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

Подводные камни open source при создании отечественных средств защиты

Давайте не будем лукавить и честно признаемся - свежие российские решения по ИБ (исключая СЗИ от НСД, СКЗИ и других “старичков”) активно используют open source компоненты в своем составе. Этого нечего стыдиться - это нормальная практика, задействовать уже написанный кем-то и распространяемый под разными лицензиями (GPL, ) код. Согласно отчету Black Duck Open Source Security and Risk Analysis (OSSRA) за 2017-й год 96% проанализированных авторами отчета приложений используют open source. Прошли те времена, когда сложные приложениям (да и не очень сложные тоже) целиком создавались одной командной с нуля. В условиях нехватки времени и компетенций, многие используют уже кем-то написанный код. И наша отрасль не является исключением. По данным отчета OSSRA сфера кибербезопасности находится на 3-м месте по проценту использования открытого ПО (после здравоохранения и ритейла с электронной коммерцией). А вообще согласно OSSRA 96% приложений задействует open source компоненты, число которых может достигать 147 штук на одно приложение.

Учитывая стратегию на импортозамещение в России, тема контроля применения open source в российских средствах защиты информации становится как никогда актуальной. Особенно в контексте последних нормативных изменений. Например, недавний приказ ФСТЭК №55 по новым правилам сертификации. Есть там такой пассаж, который применяется в тех случаях, когда продукт, подаваемый на сертификацию, содержит компоненты не только одного разработчика, но и других компаний или команд. Да, к open source этот фрагмент тоже имеет отношение.

Соответственно, при использовании open source, заявитель должен прикладывать к продукту текст лицензии (GPL, BSD и других), которые и считаются договорами. Интересно, что согласно OSSRA 85% приложений содержат компоненты open source в нарушение существующих лицензий, а 53% и вовсе не упоминают об использовании open source, нарушая права авторов на создание, модификацию и распространение своего ПО. Например, у Континент СОВ явного упоминания использования open source нет - кроме единственной новости 2013-го года про использования Snort и завуалированной новости про устранение уязвимости в движках Snort и Suricata. А вот у Инфотекса есть отдельный документ про использование open source, который прилагается к VipNet IDS. И тут возникает

Вопрос №1. Должна ли ФСТЭК требовать соблюдения лицензий GPL и др. от заявителей? 

Второй вопрос достаточно очевиден и я про него уже не раз писал. Речь идет об уязвимостях в open source и иных компонентах третьих фирм. Согласно требованиям ФСТЭК именно заявитель отвечает за устранение уязвимостей в своем продукте, независимо от того, в каком компоненте (своем или чужом) эта уязвимость найдена. Согласно OSSRA среднее число уязвимостей в open source компоненте составляет 27, а известные open source уязвимости (OpenSSL, Apache, zlib, libxml2, libpng, ядро Linux и др.) найдены в 67% приложений. Вспоминая историю с некоторыми сертифицированными форками, авторы которых прямо признавались, что они не способны устранить уязвимость, пока ее не устранит сообщество, поддерживающее компонент open source, возникает логичный:

Вопрос 2. Что делать потребителю, если ФСТЭК отзывает/приостанавливает сертификат на средство защиты при отказе/невозможности заявителя устранять уязвимость в open source компоненте?

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

Меня в этой пятерке требований интересует 3-й и 4-й пункт, которые, если транслировать их на open source, вызывают вопросы. Возьмем к примеру Snort или Suricata, в числе активных контрибуторов или разработчиков которого, российских ИБ-вендоров не наблюдается. Кто занимается модернизацией этих движков, на которых построены некоторые "отечественные IDS"? Российский вендор или все-таки сообщество, которое находится преимущественно зарубежом и обычно работает в иностранных организациях? Что-то мне подсказывает, что второе. Но тогда получается, что это приводит к невозможности выполнения третьего пункта в перечне на слайде? А покупка сигнатур атак у той же Emerging Threats - это ведь гарантийная поддержка (4-й пункт слайда)? Кстати, наличие управляющей компании в Лондоне тоже ведь нарушает данные требования ФСБ (правда, это уже не про open source). Отсюда

Вопрос №3. ФСБ сознательно закрывает доступ open source в ГосСОПКА или с этой стороны о проблемах никто не думал?

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

ЗЫ. Тем, кто утверждает, что на open source не распространяются геополитические риски и санкции, впору вспомнить историю с запретом Asterisk в Иране и кейс с блокированием доступа к Sourceforge пользователям Судана, Сирии, Кубы, Ирана и Северной Кореи.

Malwarebytes покупает Binisoft

24 мая Malwarebytes анонсировала приобретение частной румынской компании Binisoft, занимающейся защитой ПК под управлением Windows. Размер сделки не раскрывается.

Анатомия атаки на АСУ ТП (презентация)

Выкладываю первую презентацию с IT & Security Forum, который прошел в Казани на прошлой неделе и на которой у меня было 4 выступления. Эта презентация была последней в списке и подготовленной в попыхах, буквально за полтора часа до выступления. Так что получилось не очень - лично мне не нравится. Но вдруг кому-то будет интересно.

Анатомия атаки на АСУ ТП from Aleksey Lukatskiy

Видео, которые использовались в презентации, также выложу. Первое описывает анатомию атаки на корпоративную сеть, которая также применяется и как первый этап атаки на промышленные системы.

Второй ролик описывает атаку на Интернет вещей:

ЗЫ. Надо признаться, что ITSF стал для меня примером идеального мероприятия, в котором найден баланс между деловой и культурной программой, рекламой и контентом, нетворкингом и стендами. 11 лет работы не прошло даром. С мероприятия, которое начиналось в офисе ICL (если я ничего не путаю), оно доросло до общероссийской конференции, которой могут позавидовать и московские ИБ/ИТ-тусовки.

Ростелеком покупает Solar Security

22 мая Ростелеком анонсировал приобретение за 1,5 миллиарда рублей 100% компании Solar Security, известной как своим продуктовым направлением, так и направлением аутсорсинга SOC. Несмотря на значимость события для российского рынка ввиду редкости у нас M&A-сделок, комментировать его пока рано. Мне показался примечательным факт из пресс-релиза, что Solar Security сохранит свою самостоятельность и в Solar Security будут переведены сервисы и специалисты Ростелекома по ИБ. Но, как говорит современная молодежь, "это не точно" :-) Будем следить за развитием событий.

ЗЫ. Видео-репортаж с пресс-конференции Ростелекома и Solar Security.

Антисуслик Шредингера. Документы ФСБ, которые есть и которых нет одновременно

Завтра и послезавтра я буду выступать в Казани на IT & Security Forum и участвовать в двух круглых столах. И если с круглыми столами и тремя темами для выступлений мы с организаторами определились достаточно быстро, то четвертая тема в потоке по КИИ вызывала вопросы. До тех пор пока я не погрузился в изучение проектов приказов ФСБ в рамках законодательства по безопасности критической информационной инфраструктуры.

Вообще в последнее время я мало пишу про законодательство (последний раз аж 2 месяца назад), занимаясь немного другими проектами. Но иногда, нет да приходится погрузиться в эту тему. На этот раз я попробовал вычленить что-то из тех приказов ФСБ, которые были анонсированы в декабре 2017-го - марте 2018-го годов, но которые до сих пор так и не приняты. Вот именно этим документам я и посвящу свое четвертое выступление на ITSF. И хотя это пока проекты и есть надежда, что финальные версии будут отличаться от текущих, я бы хотел задаться рядом вопросов, ответы на которые, возможно, прозвучат в Казани, а возможно авторы документов по ГосСОПКЕ учтут их в финальной версии.

Итак, вопросы следующие:

1. Согласно правилам платежных систем Visa и Master Card, а также по правилам SWIFT, их клиенты сообщают об инцидентах, произошедших в указанных системах/сервисах. Однако согласно п.8 порядка "Обмена информацией о компьютерных инцидентах..." передача информации об инцидентах за пределы РФ осуществляется только через НКЦКИ. Согласно описанной в пп.9-14 процедуре субъект КИИ направляет в НКЦКИ обращение по каждому инциденту, а НКЦКИ в случае положительного решения переправляет информацию зарубеж в течение 12 часов с момента обращения субъекта посредством почтовой, факсимильной и электронной связи, а также через инфраструктуру НКЦКИ. Если же НКЦКИ считает необходимым отказать, то он это делает в течение 24 часов, о чем сообщает субъекту, направляя ему выписку из принятого решения. У меня возникает три вопроса. Посредством чего НКЦКИ направляет субъектам свой отказ? Является ли этот отказ мотивированным? И действительно ли надо по сотням тысяч инцидентов с картами Visa и Master Card (а именно такое число фигурирует в отчете ФинЦЕРТ за 2017-й год) оформлять обращения на каждое из них?
2. Согласно методичке по созданию ведомственных и корпоративных центров ГосСОПКИ такие центры должны среди прочей информации о компьютерных атаках уведомлять о рассылках спама (п.8.6). Спам также фигурирует в п.8.7 уже в разряде инцидентов. У меня снова три вопроса по данному требованию. Зачем по спаму сообщать IP-адреса атакующих и пострадавших, а не их почтовые адреса и почтовые сервера? Сообщать надо именно о спаме или также о срабатывании репутационных фильтров? Также мне интересно, надо ли сообщать о каждом спамерском сообщении? Например, в Cisco ежемесячно спам-фильтрами блокируется около 5 миллионов сообщений, а репутационными - 81 миллион сообщений. Надо составлять 86 (в худшем случае) или 5 (в "лучшем") миллионов карточек инцидентов?
3. Согласно перечня информации, предоставляемой в ГосСОПКУ, об инцидентах надо уведомлять незамедлительно, но не позднее 24-х часов с момента их обнаружения. Все бы ничего, но по каждому инциденту надо среди прочего сообщать о последствиях инцидента. У меня вопрос - как можно оценить последствия (ущерб) от инцидента в течение суток (и это в худшем варианте - если придерживать информацию) в течение такого короткого интервала времени? У ЦБ в 2831-У для этого предусмотрены формы за прошлый отчетный период, когда мы уже имеем собранную информацию, в том числе и по последствиям.
4. Финальный вопрос, который я не перестаю задавать в последние месяцы, касается формата обмена информацией об атаках / инцидентах / признаках атак. Это STIX/TAXII, OpenIOC, иные стандарты обмена данными? Кроме применения TLP пока ни о какой стандартизации речи не идет, что печально. Будет ли назван такой стандарт или разработан с нуля? Вот ЦБ недавно анонсировал проект СТО 1.5 как раз по описанию формата данных при обмене с ФинЦЕРТ (и вроде даже как заявляется, что проект стандарта согласован с ФСБ). А что регулятор по ГосСОПКЕ?

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

ЗЫ. Три оставшиеся темы будут посвящены искусственному интеллекту и ИБ, киберучениям по ИБ для руководства, а также анатомии атаки на АСУ ТП. 

Новые форматы донесения важности ИБ до неспециалистов

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

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

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

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

В любом случае хочу сказать спасибо Русту за его критику :-)

Куда податься бедному хакеру?

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

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

• Фишинговые симуляции. Эти люди хорошо знают, как ломать разные компании. А так как одним из самых популярных способов до сих пор остается фишинг, то логично, что бывшие хакеры уходят именно в это направление security awareness и по заказу создают фишинговые кампании и оценивают их эффективность. 
• Обучение. При наличии предрасположенности и знаний, нередко "хакеры" начинают разрабатывать курсы и преподавать их. Часто это направление offensive, но бывают и смешанные программы, объединяющие в себе нападение и защиту.
• Киберучения. Имея немалый опыт участия в реальных пентестах и смоделированных CTF, бывшие кибербойцы начинают заниматься очень интересной темой киберучений, в рамках которых не просто эмулируются искусственные уязвимости, а прокачиваются навыки защиты и нападения, работы в Red и Blue Team. 
• Консалтинг. Ну тут вроде все понятно. 
• ПО для симуляции атак. Консалтинг, обучение, фишинговые симуляции - это все не очень масштабируемые вещи. И хотя на хлеб с маслом на них можно заработать, на черную икру уже может и не хватить. Поэтому нередко "хакерские" команды пытаются создавать ПО, которое затем предлагается рынку. Достаточно новым направлением на рынке сегодня можно назвать ПО для симуляции атак. Это не Metasploit, а решения именно корпоративного уровня, ориентированные на защитников, а не атакующих. Про этот класс решений мы поговорим завтра - там немало интересных новинок появилось за последний год.

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

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

Дашборды по ИБ для руководства: объединяем все вместе (презентация)

Теперь попробуем собрать все заметки по дашбордам (1, 2, 3 и 4) вместе. Получится презентация, которую я выложил на Slideshare (да, он заблокирован на территории России, но кого это останавливает?), и которую я читал в рамках мастер-классов в Москве на CISO Forum и в Санкт-Петербурге на Код ИБ.

Дашборды по ИБ для топ-менеджмента from Aleksey Lukatskiy

Дашборды по ИБ для руководства: как получить финальный вариант?

Давайте посмотрим на дашборды, которые есть у современных решений по ИБ. В качестве примера я возьму то, что мне ближе, - решения Cisco (Cisco ISE, Cisco Stealthwatch, Cisco Threat Grid и Cisco Cognitive Threat Analytics). Посмотрите на иллюстрацию ниже. Мы видим, что все дашборды построены по описанному вчера принципу - сначала ключевые показатели, потом аналитические диаграммы, раскрывающие эти показатели. Клик по выбранным диаграммам приводит к детальным отчетам. Все вроде бы на месте, но можем ли мы такие дашборды показывать руководству? Увы, нет. Ибо они не отвечают на вопросы, которые нужны топ-менеджменту.

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

Чтобы вынести все эти показатели на дашборд нам нужно их каким-то образом выцепить из разных систем, собрать вместе, произвести дополнительные вычисления (например, рейтинг успешности повышения осведомленности в области использования и защиты e-mail) и визуализировать все это в рамках дашборда. Для этого нам понадобится взять "сырые" данные от средств защиты и данные от бизнес-систем (HRM, SCM, ERP, CRM и т.п.), для чего воспользоваться API, которое сегодня является неотьемлемой частью любого современного решения по ИБ (и не только). Помните, я в прошлом году писал о пяти вещах, которые вы должны требовать от любого ИБ-вендора. Так вот наличие API там стояло там на первом месте. Для захвата данных через API необходимо умение программировать. Сразу надо заметить, что речь идет не о "кодинге" на C++ или Ассемблере, а о навыках извлекать данные из разных систем. Будет это ODBC, JDBC, Visual Basic или Python и R, - не так уж и важно.

Что использовать в качестве инструмента для создания и визуализации дашборда? Этот вопрос звучит чаще других, но именно он-то совсем неважен. В конце концов, какая разница, что позволит вам решить вашу задачу? С чем вы лучше знакомы и что используется у вас в организации - то и применяйте. Это может быть Excel (для простых задач вполне себе решение), MS PowerBI, Tableau, QlikView или grafana. В конце концов вы можете заточить под это ваш SIEM, если у него есть возможность конструирования дашбордов и развитый API для подключения к внешним системам. Я вновь повторю, что не так важно КАК визуализировать, как то, ЧТО вы хотите показать и ЧЕГО достичь своим дашбордом.

Дашборды по ИБ для руководства: как создать макет?

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

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

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

Чтобы ответить на эти вопросы нам по каждому инциденту нужно собрать следующие данные:

• аналитик SOC, работающий с инцидентом
• тип инцидента
• источник инцидента
• статус инцидента (разрешен/просрочен)
• дата и время.

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

Разумеется это еще не макет дашборда - это скорее набросок той информации, которая должна быть на дашборде. А вот макет будет выглядеть так:

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

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

• Время между созданием и закрытием заявки (ticket) в SOC
• Процент инцидентов обнаруживаемых и нейтрализуемых автоматически, без участия специалистов SOC
• Соотношение открытых и «закрытых» заявок
• Соотношение инцидентов и заявок
• Число повторных инцидентов
• Соотношение методов коммуникаций с SOC (e-mail / звонков / портал)
• Число false positives (несуществующих инцидентов)
• Число изменений средств защиты по результатам расследований инцидентов
• Соотношение инцидентов по их критичности
• Цена/длительность разрешения инцидента
• Число новых заявок.

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

Финальную заметку я посвящу вопросу создания прототипа и финального варианта дашборда, для чего нам понадобятся различные средства автоматизации - от Excel или MS PowerBI до Canopy или Splunk.