Третий выпуск "Нашей игры" уже в эфире

BIS-TV выложило третий выпуск "Нашей игры", посвященной сетевой безопасности. Когда я готовил вопросы к этому игре, я немного поменял подход, добавив идеи из ЕГЭ и "Как стать миллионером" с набором готовых вариантов, из которых надо выбрать было правильный. Вроде как удалось нащупать баланс между различными типами вопросов и способами их подачи. Но к финалу планирую сделать несколько сюрпризов для участников, чтобы они смогли в полной мере прочувствовать всю феерию чувств от необычных вопросов, связанных с их профессиональной деятельностью :-)

Чтобы я хотел выделить особо. Когда вы будете смотреть выпуск, я настойчиво рекомендую вам лайкнуть его (если, конечно, он вам понравился). Дело в том, что от количества лайков может зависеть результат игры. Один из вопросов случайным образом становится вопросом-сюрпризом и сумма баллов, начисляемых за него, равна числу лайков, умноженных на определенное значение (вроде 50). При большом числе лайков эта сумма может быть значительной и при успешном ответе на вопрос позволит оторваться от конкурентов. Во время третьей игры у нас, как мне показалось, произошел перелом именно в момент озвучивания вопроса-сюрприза - команда, успешно ответившая на него, смогла сразу выбиться в лидеры, получив 1500 баллов. Другие команды как-то сникли после этого вопроса (как мне показалось). Так что у вас есть возможность добавить перчику в 4-ю игру, лайкнув третий выпуск очень много раз.

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

Подробнее…

Криптографический Кракен продолжает опутывать щупальцами бизнес и граждан

Чуть менее трех лет назад я написал заметку про криптографического Кракена, в которой выделил 10 "щупалец", которые захватили определенные направления российской экономики и требуют применения сертифицированной криптографии по требованиям ФСБ. За это время произошло еще ряд важных изменений, которые я решил подсветить в небольшой заметке. А навело меня на мысль написать ее вчерашняя дискуссия в Фейсбуке, где зашла речь о планируемой концепции 5G, которая сейчас разрабатывается и обсуждается в узких кругах.

В заметке написано, что сейчас предлагаются следующие планы по сертификации сетевого оборудования по требованиям ФСБ к средствам криптографической защиты информации (СКЗИ):

• Оборудование центра изготовления ключей - КА
• Отечественные USIM-карты - КСЗ
• Оборудование для изготовления отечественных USIM- карт - КА
• Оборудование для программирования и ввода ключевой информации в отечественные USIM-карты и их персонализации - КА
• Средство криптографической защиты аутентификации абонента - КА
• Средство защиты центра коммутации - КА
• Средство защиты для базовых станций - КСЗ
• Средство защиты для транзитного оборудования - КСЗ
• Средство защиты шлюзового оборудования - КА
• Абонентские устройства - КСЗ

Зачем превращать абонентские устройства в КС3 я не понимаю (это все-таки выбор абонента должен быть, а не регулятора). Еще меньше я понимаю, зачем для внутренней инфраструктуры оператора 5G требовать КА? Я не знаю, можно ли вообще выполнить в современных сетях требования к КА, но если да, то оператор, который сможет/захочет это делать, будет только один и тарифы он для покрытия своих расходов выставит просто конские.

Но это не единственное новое щупальце криптографического Кракена. Вспомним последнюю редакцию 382-П с требованием перейти всем платежным системам на российскую сертифицированную криптографию. И заодно Единую биометрическую систему (ЕБС). В прошлом ЦБ был оплотом криптографического либерализма и он не давал в обиду перед ФСБ банки. Но теперь ситуация иная :-( Это, кстати, не все. На Магнитогорском форуме зампред ЦБ, госпожа Скоробогатова, рассказывала о цифровом профиле гражданина (законопроект был недавно предоставлен для обсуждения ведомствам) и на своем слайде упомянула, что минимальный класс СКЗИ для работы с цифровым профилем будет КС3.

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

Подробнее…

О сертификации блокчейна по требованиям безопасности

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

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

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

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

Подробнее…

Применение блокчейна в кибербезопасности (презентация)

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

Применение блокчейна в кибербезопасности from Aleksey Lukatskiy

Подробнее…

Майндкарта по 239-му приказу

Решил я тут освежить свои знания по 239-му приказу. Все-таки с категорированием мучаться все скоро закончат и наступит реальная работа по защите своих значимых объектов (ну если они, конечно, будут найдены у субъектов КИИ, которые не захотят загонять себя в прокрустово ложе жестких требований регулятора). Ну а какой самый лучший способ вспомнить и разобраться в хитросплетениях отечественной нормативки? Правильно. Сделать майндкарту. И вот я взял и сделал ее.

PDF с ней выложил в облако - качайте. В карте уже учтены последние правки, выложенные ФСТЭК на прошлой неделе для общественного обсуждения. Если и не примут что-то, то я потом быстро внесу изменения.

Пара замечаний по всему приказу. Обратил внимание, что местами нарушена методологическая составляющая (спустя полтора года обнаружил и только после составления майндкарты). Например, информирование и обучение персонала одновременно включается и в этап обеспечения безопасности в ходе эксплуатации значимого объекта и в список организационных и технических мер. Тоже самое относится и к реагированию на инциденты, и к обеспечению действий в нештатных ситуаций. Например, согласно перечню мер из приложения анализ возникших нештатных ситуаций (ДНС.5) не включен в базовый набор мер ни для одного уровня значимости, а в разделе 13.6 он включен для всех значимых объектов без исключения. Тут либо из перечня мер надо это исключать, либо из раздела 13 приказа. И я не знаю, что лучше. Логичнее вроде бы из перечня приказа, так как эти мероприятия логичны и их закономерно распространять на все ЗОКИИ, но с другой стороны, это нарушить преемственность с другими приказами ФСТЭК, например, с 31-м.

Пункты 15-18 я бы вообще вынес в самое начало приказа, в основные положения. А то получается, что о целях и задачах защиты ЗОКИИ мы узнаем только ближе к концу документа. Мелочь, а при составлении майндкарты за это глаз цепляется (я в итоге это и перенес в общие положения в майндкарте).

ЗЫ. А вообще классно было бы, если бы регулятор сопровождал свою нормативку майндкартами :-)

ЗЗЫ. Та же карта, но через Slideshare.

Майндкарта по 239-му приказу ФСТЭК from Aleksey Lukatskiy

Подробнее…

Киберучения, VR-экскурсия, ИБ-баня и куча эксклюзивных мастер-классов!

Пора-пора... Все оттягивал момент, когда надо сесть за формулирование своих мыслей по поводу грядущего "Кода ИБ. Профи", который пройдет в Москве и который мне посчастливилось вновь курировать. Тут стоило бы вновь спеть песню про Security Dream Team и вот это вот всё, но я подумал, что повторяться смысла нет, а подыскивать новые эпитеты для классной команды спикеров, которые в этом году разведут тучи на серой ИБшной Москвой, я не буду. Просто перечислю тех, кто согласился выступить в этом году и поделиться собственным опытом в непростом деле управления ИБ:

• Архипова Мона
• Борисов Илья
• Горчаков Денис
• Карпов Антон
• Леонов Александр
• Мананников Дмитрий
• Палей Лев
• Плешков Алексей
• Хайретдинов Рустем
• и я :-)

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

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

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

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

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

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

ЗЫ. Каким безопасником вам хочется быть? Тем, который показан наверху справа, или тем, который показан справа, но внизу :-) Выбор за вами. 

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

Подробнее…

Какое главное слово в словосочетании "Threat Intelligence"?

Какое главное слово в словосочетании "Threat Intelligence"? Большинство считает, что threat, угроза. На одном из мероприятий я как-то, не претендуя на социологическую правильность, провел блиц-опрос на тему, что для вас значит Threat Intelligence. 68% участников опроса сказали, что это фиды. Еще 17% сказало, что это информация об угрозах. Оставшиеся 15% затруднились с ответом. Так какое же главное слово в Threat Intelligence? Увы. Не Threat, и даже не Intelligence. Главное - принятие решений.

Именно это - ключевая ошибка большинства проектов по TI, которые реализуются многими компаниями. Cisco достаточно давно занимается аудитом SOCов и одним из популярных слабых мест в них является именно процесс Threat Intelligence, который воспринимается как сбор фидов различных типов и интеграция их в имеющиеся платформы Threat Hunting, SIEM, Incident Response и др. Поэтому частый вопрос во время аудита, который ты слышишь: "А какие источники фидов вы можете посоветовать для нашего TI?" Задаешь встречный вопрос: "А какие решения вы принимаете на основе желаемого TI?", а в ответ тишина и непонимание. Иногда на тебя смотрят как на ребенка, которому надо объяснять вроде бы очевидные вещи. 

Кстати, по поводу фидов и их источников. На Уральском форуме в презентации Владимира Бенгина из Positive Technologies были интересные цифры (я переделал его слайд), в котором он сравнивал C&C-фиды двух российских поставщиков за один и тот же интервал времени. Интересный результат - пересечение на уровне долей процента и это для одного региона и одного типа фидов. Как тут можно что-то советовать, не зная, исходной задачи, а самое главное, предназначения TI?

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

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

А такой показатель, как количество получаемых извне IoC применявшихся в компании? Может оказаться вообще, что индикаторы компрометации вы получаете, но не используете, потому что руки не доходят или не знаете, как автоматизировать процесс интеграции внешних источников с вашими средствами защиты/анализа. Первое говорит о том, что команда TI не очень эффективна, а второе - что возможно имеющиеся средства просто не могут работать с внешними IoCами - такое тоже бывает. О качестве текущих средств защиты и, как следствие, необходимости их обновления или замещения говорит нам и динамика снижения числа ложных срабатываний средств защиты после обогащения сигналов тревоги данными от службы TI, а также соотношение количества обнаруженных угроз средствами защиты организации с данными от службы TI и без них (например, голый IDS в сравнении с IDS + TI или IDS + TI + SIEM). Вот такое применение TI мы в рамках аудита SOCов видим очень и очень редко.

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

Подробнее…