Сколько лицензий надо, чтобы подключиться к ГосСОПКА?

Сегодня, в четверг, 20 сентября, проходит несколько мероприятий по ИБ, с которых приходят интересные новости от рыцарей виртуального плаща и кинжала, то есть от ФСБ. Среди них и злободневный вопрос: "Сколько лицензий и каких надо, чтобы работать с ГосСОПКА?". Попробовал для себя сформулировать все, что знаю:

• Для собственных нужд (только в рамках своего юрлица)
• лицензия ФСТЭК на мониторинг ИБ - не нужна
• лицензия ФСБ (или на шифрование, или на разработку средств защиты для ГТ) - не нужна
• лицензия ФСБ на гостайну - нужна, если вам нужен доступ к 6-ти методичкам ФСБ по обнаружению, предотвращению и ликвидации последствий компьютерных атак
• В рамках работы в холдинговых структурах
• лицензия ФСТЭК на мониторинг ИБ - нужна
• лицензия ФСБ (или на шифрование, или на разработку средств защиты для ГТ) - нужна
• лицензия ФСБ на гостайну - нужна, если вам нужен доступ к 6-ти методичкам ФСБ по обнаружению, предотвращению и ликвидации последствий компьютерных атак
• Для предоставления коммерческих услуг
• лицензия ФСТЭК на мониторинг ИБ - нужна
• лицензия ФСБ (или на шифрование, или на разработку средств защиты для ГТ) - нужна
• лицензия ФСБ на гостайну - нужна, если вам нужен доступ к 6-ти методичкам ФСБ по обнаружению, предотвращению и ликвидации последствий компьютерных атак

Итого: ФСБ в своем репертуаре. Чтобы получить методическую помощь от регулятора ответственного за обнаружение, предотвращение и ликвидацию последствий компьютерных атак, будьте добры получить лицензию на работу со сведениями, составляющими гостайну. Даже если ты сельская больничка из одного главврача и медсестры или ломбард. Приплыли... А если я не могу получить лицензию на гостайну, то как мне защищиться от атак? А тогда кому ты нужен, нищеброд?...

Подробнее…

ИБ-перевертыш или влияние культуры на ИБ (презентация)

В пятницу на BIS Summit я рассказывал про влияние культуры на ИБ, презентацию откуда и выкладываю.

ИБ-перевертыш или влияние культуры на ИБ from Aleksey Lukatskiy

В рамках презентации показывал видео, которое нельзя залить на SlideShare, но можно увидеть на Youtube (только в презентации я чуть обрезал запись с 4-х минут до одной):

Подробнее…

Bomgar покупает BeyondTrust

13 сентября компания Bomgar, занимающаяся решениями по управлению привилегированным доступом, подписала обязывающее соглашение о приобретении компании BeyondTrust, занимавшейся тем же. Детали сделки не раскрываются. 

Подробнее…

Можно ли защитить ИТ-инфраструктуру российского госоргана отечественными решениями по ИБ?

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

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

• Работа на Macbook'ах
• Разграничение доступа в iSCSI и FC сетях
• Защита SAN
• Высокоскоростные магистрали и резервные каналы связи (40 Гбит/сек и выше)
• Виртуальные среды на базе KVM
• Доверенная загрузка на ноутбуках (тут возможно и есть что-то, но я с ходу не вспомнил)
• Регламентация и контроль беспроводного доступа
• Средства контроля целостности ПО (как минимум на Windows 10, где пока не работает ФИКС)
• Обманные системы (вроде как решение Кода безопасности больше не существует).

Это я привел неполный перечень тех иностранных решений, которые достаточно активно используются в российских организациях, и при этом не имеют отечественных средств защиты, имеющих сертификат ФСТЭК. А если в качестве основы взять организацию, которая прислушалась к мнению чиновников и действительно перешла на отечественные информационные технологии или open source:

• средства унифицированных коммуникаций iMind, Vinteo, TrueConf и др.
• open source платформы Hadoop, Spark, Elastic, Pentaho, MongoDB и др.
• параллельные СУБД InfiniDB, InfoBright и др.
• семейство Apache - Tomcat, Cassandra, Struts, Metron, HTTP Server и др.
• сервера приложений - WildFly, GlassFish и др.
• web-сервера - nginx и др.
• промышленные решения - Tibbo и др.
• электронный документооборот - Alfresco, Directum и др.

Вот я с ходу не вспомнил российских разработчиков, которые бы декларировали средства защиты для упомянутых решений, преимущественно защищая решения иностранные - Windows, Oracle, IBM и т.п. А уж сертифицированных решений для названных решений и вовсе нет.

Есть две стратегии - разработать решения по ИБ для того, что используется сейчас заказчиками, или заставить перейти на то, что смогли разработать российские вендоры (но в области ИБ, так как ИТ-вендоры не сильно заботятся о соответствии требованиям ФСТЭК). Первая стратегия правильнее, но более ресурсоемка как по деньгам, там и по времени. Вторая гораздо проще в реализации и именно ее сегодня реализуют, заставляя российские госорганы переходить на отечественные мобильные и настольные ОС (и это не iOS, Android или Windows), перелицованные open source ИБ-решения и т.п. И если госорганам деваться особо некуда - за пределы 17-го приказа, требующего сертификат ФСТЭК, особо не выйдешь, то у коммерческих структур выбора побольше и стоит 10 раз подумать, надо ли загонять себя в прокрустово ложе требования по сертификации, которое выполнить нельзя.

А как же быть, если нормативные акты требуют сертификации? Так не требуют. Нужна оценка соответствия, а это не только обязательная сертификация ФСТЭК. Вот о том, что это такое и почему в обозримом будущем в России будет все сложнее найти адекватное число сертифицированных средств защиты, мы и будем говорить в рамках вебинара, который пройдет 26 сентября в 11 по московскому времени. Все детали и ссылка на регистрацию тут.

UPDATE: В Твиттере меня коллеги поправили. ФИКС есть для Windows 10. Для ноутов есть модули m2 и UEFI для доверенной загрузке. Есть Аккорд для KVM. Гарда поддерживает PostgreSQL, Cassandra, Hadoop и HDP. Threat Deception есть у Лаборатории Касперского.

Подробнее…

Правила Керкгоффса (не путать с законами Кирхгофа)

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

1. Система должна быть практически, если не математически, невзламываемый.
2. Система не должна требовать сохранения ее в тайне и попадание ее в руки врагов не должно вызывать проблем.
3. Хранение и передача ключа должны быть осуществимы без помощи бумажных записей; участники должны располагать возможностью легко менять ключ по своему усмотрению.
4.  Система должна быть совместима с телеграфной связью (напомню, что речь идет о конце 19-го века, когда единственным способом связи был телеграф).
5. Система должна быть портативной и работа с ней не должна требовать более одного человека.
6. Наконец, от системы требуется, учитывая возможные обстоятельства ее использования, чтобы она была проста в использовании и не требовала значительного напряжения ума или соблюдения большого количества правил.

Данные шесть принципов были впервые опубликованы в журнале "Военная наука" в 1883-м году (издается до сих пор). Две статьи, в январском и февральском выпусках, описывали существующие в 19-м веке системы шифрования и способы их криптоанализа. Там же Огюст Керкгоффс сформулировал и основы создания надежных криптографических систем, упомянутые выше.

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

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

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

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

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

Подробнее…

Правило "1-10-60" или три метрики SOC, когда вы не знаете как правильно измерить свой центр мониторинга ИБ

Помню 2 года назад, на SOC Forum, я выступал в модерируемой мной с Дмитрием Мананниковым секции по оценке эффективности SOC. В рамках своей презентации я описывал возможные подходы к оценке SOC различных точек зрения - технической, процессной, бизнеса и т.п. За прошедшие два года я не раз сталкивался с различными центрами мониторинга, создатели которых, построив неплохую инфраструктуру, набрав специалистов и даже выстроив  отдельные процессы, так и не смогли правильно оценивать свою деятельность. Участвуя в различных проектах по консалтингу SOC, а также имея доступ к нашей базе знаний по этой теме, могу отметить, что происходит это по двум основным причинам (движение снизу вверх вместо движения сверху вниз и плохо управляемые ожидания при создании SOC). В обоих случаях мы не понимаем, ЗАЧЕМ нам нужен SOC? Именно нам, а не кому-то. Для нашего бизнеса. Для нашей ИТ-инфраструктуры. Для нашей оргштатной структуры. Для нашего руководства. Чтобы это сделать надо двигаться сверху вниз - от стоящих задач к способам их решения. От них же, кстати, будет зависеть и все остальное, - архитектура, технологии, люди, процессы и т.п.

Но на практике обычно все бывает иначе. Поддавшись моде или желая замутить что-то новое инвестируются десятки и сотни миллионов рублей в прорывные технологии "из гартнера", нанимаются за бешеные деньги аналитики ИБ, закупаются сервисы Threat Intelligence из десятков источников, а потом приходит руководство и спрашивает "И что? Где результат?" И показать нечего. Но есть ряд метрик, которые все-таки можно использовать для того, чтобы показать эффективность своего SOC. Пусть не на бизнес-уровне, но хотя бы на уровне, понятном любому безопаснику. Для чего мы создаем SOC на понятийном уровне? Чтобы оперативнее обнаруживать и реагировать на угрозы. Это очевидно и именно это можно на первых порах поставить во главу угла своей программы (до момента осознания реальной потребности в SOC и стоящих перед ним задач).

Обычно выделяют 3 основных метрики, которые показывают:

• время обнаружения угрозы (Time-to-Detect, TTD)
• время локализации угрозы, включая расследование (Time-to-Contain, TTC)
• время реагирования на угрозу (Time-to-Response, TTR).

Иногда еще добавляют и время восстановления после угрозы (Time-to-Remediate, TTR). Визуально связь между этими метриками выглядит следующим образом:

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

Обычно считается среднее арифметическое параметров TTD, TTC и TTR, но у нас в Cisco также вычисляется и медиана, - две величины лучше отражают данные временные показатели в больших выборках с широким разбросом значений.

Как итог, отчет по эффективности SOC может выглядеть так:

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

Но есть и еще одна интересная метрика, которая не столь важна для представления ее наружу, сколько для оценки внутренней эффективности выстроенных в SOC процессов, поддержанных людьми и технологиями. Эта метрика называется время прорыва (breakout time). Ее предложила в 2018 году компания CrowdStrike, которая проанализировала около 30 триллионов событий безопасности в 2017-м году, и вычислила время, которое требуется злоумышленнику, чтобы уйти с первоначального плацдарма и начать распространение внутри корпоративной или ведомственной. Это время равно 1 часу 58 минутам. Важность понимания сути этого временного окна очень высока. Оно показывает, какой запас времени у нас есть, чтобы инцидент не превратился в катастрофу; чтобы взлом, например, публичного web-сайта (как это было с Equifax), не перетек во взлом баз данных.

CrowdStrike, кстати, предложила еще одно интересное измерение для SOC - это правило "1-10-60", которое означает, что хорошо защищенная компания должна уметь обнаруживать (TTD) угрозы за 1 минуты, проводить их расследование за 10 минут, а блокировать нарушителя за 1 час. Для этого надо использовать современные технологии ИБ, которые фокусируются не на предотвращении, а на всем жизненном цикле угрозы - ДО, ВО ВРЕМЯ и ПОСЛЕ.

PS. Скоро грядет очередной SOC Forum. Пройдет он в Москве 27-28 ноября (да, два дня, а не один). Пора регистрироваться!

PPS. А 9-10 октября буду на тему SOCов выступать на CyberCrimeCon 2018.

Подробнее…

Утверждено 3 приказа ФСБ по ГосСОПКЕ из шести

6 сентября были опубликованы утвержденные и зарегистрированные в Минюсте 3 (из шести) приказа ФСБ, касающиеся ГосСОПКИ.

Приказ №366 "О Национальном координационном центре по компьютерным инцидентам" превозносится в российских СМИ как абсолютно новая структура, которая придет на смену ЦИБ, и которая начнет бороться с хакерами всех мастей. Журналистам и отдельным экспертам невдомек, что эта структура существовала уже давно и просто настал черед формализовать ее работу в рамках закона "О безопасности критической информационной инфраструктуры", что и произошло. Ничего выдающегося в утверждем приказе я не увидел. НКЦКИ координирует, организует, собирает, обеспечивает методическую помощь, участвует... и т.п.

Второй приказ, №367, "Об утверждении Перечня информации, предоставляемой в ГосСОПКУ и Порядка предоставления информации в ГосСОПКУ" также не претерпел изменений по сравнению с проектом. Я про него уже писал и делал презентацию. Вопросы по данному приказу также остаются пока без ответа. Оценить причинно-следственные связи между атакой и инцидентов, да еще и оценить последствия... и все это в течение 24 часов?! Круто, ничего не скажешь.

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

Грустно все это. Разрабатывать документы почти год и получить на выходе пшик :-( Я не знаю с чем это связано. Неким показателем лично для меня должны стать шесть методических документов, о которых написал Валерий Комаров и которые сейчас готовит НКЦКИ:

• Требования к подразделениям и должностным лицам субъекта ГосСОПКа.
• Регламент информационного взаимодействия.
• Методические рекомендации по обнаружению компьютерных атак на информационные ресурсы.
• Методические рекомендации по установлению причин и ликвидации последствий компьютерных атак.
• Методические рекомендации по проведению мероприятий по оценке защищенности от компьютерных атак.
• Варианты организации защищенного канала.

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

Подробнее…

Взлом Equifax: разбор полетов

В августе Счетная палата США опубликовала отчет о результатах расследования нашумевшего взлома американского бюро кредитных историй Equifax, в результате которого злоумышленники получили доступ к персональным данным 145 миллионов граждан США, Канады и Великобритании.

Сам по себе взлом не представлял собой ничего необычного. В марте 2017-го года неизвестные злоумышленники использовали известную уязвимость на публичном Web-сайте для доступа к внутренним системам Equifax. В мае того же года злоумышленники стали красть данные из внутренних баз данных, пока 29 июля Equifax не обнаружила взлом и не блокировала действия злоумышленников.

Есть несколько интересных моментов, на которые я бы хотел обратить внимание в этой истории:

• Злоумышленники использовали известную к моменту первичной атаки уязвимость в Apache Struts Server, которая была идентифицирована US CERT двумя днями ранее. Это в очередной раз поднимает вопрос о том, как должен быть выстроен процесс устранения уязвимостей? Надо ли их устранять сразу по факту публикации бюллетеня по ним? А может надо ждать публикации сведений об экслойтах для уязвимости? Или опираться на рейтинг CVSS? Вопросов много, но однозначных ответов пока нет. В любом случае, это лишний раз напоминает нам, что злоумышленники далеко не всегда используют 0Day для своих атак.
• В процессе расследования выяснилось, что Equifax знал об уязвимости, так как получил от US CERT соответствующий бюллетень, который был распространен среди системных администраторов. Но... оказалось, что список этих лиц был устаревшим и в него не входили те администраторы, которые отвечали за установку патчей на уязвимом Web-портале. Наблюдается либо определенный пофигизм к поддержанию такой информации в актуальном состоянии, либо конфликт между ИТ и ИБ, что бывает очень часто.
• Интересно, что Equifax также заявил, что через неделю после получения бюллетеня от US CERT, они сканировали свою сеть, включая и уязвимый web-портал, но используемый сканер ничего не показал, что в очередной раз поднимает вопрос о том, надо ли целиком доверять используемым техническим решениям одного вендора и не надо ли их дублировать (не обязательно тратя на это еще деньги и используя решения open source).
• Equifax заявляет, что злоумышленники так долго могли скрывать свою деятельность, потому что использовали шифрование своей активности. Я уже неоднократно писал о том, что шифрование - это палка о двух концах и оно активно используется злоумышленниками для скрытия своих действий, существенно усложняя жизнь специалистам по ИБ. И им не нужно получать никаких лицензий ФСБ для этого. Так как это происходит все чаще, то необходимо иметь определенную стратегию для борьбы с зашифрованным трафиком.
• Самое интересное, что в процессе проведения регламентных работ в инфраструктуре Equifax выяснилось, что одно из решений по мониторингу и инспекции сетевого трафика не видело вредоносной активности в зашифрованном трафике из-за ошибок конфигурации этого устройства. Если быть точнее, то на данном устройстве был просроченный более чем 10 месяцев (!) цифровой сертификат. На мой взгляд это чистой воды халатность администраторов, которые почти год вообще не мониторили внутренний сетевой трафик. Это же показывает, что помимо защиты периметра необходимо иметь решения и для мониторинга аномалий во внутренней инфраструктуре. Без этого сегодня никуда.
• В другом источнике было написано, что используемое для инспекции сетевого трафика оборудование не соответствовали заявленным вендором цифрам по производительности, что часто приводило к задержкам в обработке трафика. В итоге настройки оборудования были изменены так (в сторону ухудшения ИБ), чтобы производительность устройства не снижалась.
• Никакой сегментации в инфраструктуре Equifax не было, что привело к неконтролируемому доступу к множеству различных баз данных, а не только к тем, которые были связаны с уязвимым Web-сервером. А ведь сегментация - это то, что дает чуть ли не 50% успеха в сетевой безопасности и при этом не требует особых затрат, так как задействует встроенные возможности сетевого оборудования.
• Интересный факт - позже выяснилось, что Equifax использовал оборудование компании FireEye для мониторинга угроз во внутренней сети, но FireEye на следующий день после известия о взломе Equifax удалил со своего сайта историю успеха о внедрении в кредитном бюро своих решений. Предположу, что это результат эмоционального решения руководства ИБ-вендора, который не хотел связывать себя с взломом, но мы все прекрасно понимаем, что кеш поисковых систем сохраняет все, в том числе и удаленные материалы. А на репутации такой факт сказывается гораздо больше, чем если бы мир знал, что Equifax защищался с помощью FireEye. Если верить отчету Счетной палаты США, то вина лежала целиком на администраторах Equifax, которые почти год не обновляли цифровой сертификат на средстве инспекции сетевого трафика. 

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

1. выстроить процесс управления уязвимостями и четко понимать, как и когда устранять обнаруженные уязвимости.
2. тесно контактировать с ИТ-командой, отвечающей за процесс управления патчами и иметь актуальный список лиц, которые занимаются устранением дыр.
3. мониторить внутренний трафик с помощью решений класса NTA (NBAD), которые позволяют обнаруживать аномалии и угрозы, проникшие из-за периметра или инициированные изнутри.
4. поддерживать актуальную конфигурацию как сетевого оборудования, так и средств защиты.
5. сегментировать сеть для предотвращения несанкционированного доступа. 
6. понимать риски использования злоумышленниками шифрования для скрытия своей активности и использования решений, которые борются с этим (EDR на оконечных устройствах, устройства для SSL Offload, инспекция DNS-трафика для обнаружения взаимодействия с инфраструктурой злоумышленников, использование технологий машинного обучения для обнаружения вредоносной активности внутри зашифрованного трафика без его расшифрования).

PS. Примечательно, но во взломе Equifax русских хакеров не обвиняли :-)

Подробнее…

Российский ИБ-рынок: между Востоком и Западом

Многие помнят нашумевший спор между Натальей Касперской и Анатолием Чубайсом на Петербургском международном экономическом форуме о том, какого пути надо придерживаться России в своем развитии. Наталья Ивановна считает, что Россия вполне может быть счастлива, идя по пути Китая. Анатолий Борисович напротив считал, что Россия не может повторить путь Китая, так как несоизмерима меньше и по населению, и по экономике, и по ВВП; и надо, мол, "дружить" с Западом.



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

Итак, "западники", в публичном пространстве, в меньшинстве. "Славянофилы" напирают на патриотизм, но кроме него предложить ничего не могут. Что остается? Обращение лицом к Китаю? И вроде как за эту почти пятилетку мы достаточно много добились в наших взаимоотношениях с восточным партнером. Кстати, почему в единственном числе? Ну тут все просто. Япония жестко связана с США партнерскими отношениями, а с нами она активизировала отношения только ради Курил. Южная Корея неплохо зарекомендовала себя на рынке электроники, но вот на рынке ИБ я что-то не помню южнокорейских имен. Да и кажется мне, что мы нужны Южной Корее только для того, чтобы заручиться нашей поддержкой по ядерной проблеме КНДР. Кроме того Корея тоже является союзником США и не пойдет против их санкций. Кто у нас еще может рассматриваться в качестве восточного партнера в ИБ-сфере? Малайзия? Сингапур? Вьетнам? В первые две страны в последние годы зачастили организаторы российских конференций для того, чтобы перенимать восточный опыт, но вот программных и аппаратных решений из этих стран что-то не видно. Ну разве что производство комплектующих на Тайване. Действительно остается только Китай, который обладает огромным внутренним рынком ИБ, насчитывающим минимум сотню компаний, разрабатывающих свои антивирусы, NGFW, IPS, сканеры безопасности, WAF, DLP и т.п. Но все это для внутреннего потребления и эти компании не стремятся к географической экспансии, уступаю пальму первенства всего одной китайской компании, продукцию которой запрещают в США, Австралии, Индии, Европе (из-за обвинений в шпионаже), но которая успешно развивается именно у нас. Кстати, если посмотреть новостную ленты, то за последнее время китайцы были неоднократно (минимум раз двадцать обвинены в шпионаже и краже интеллектуальной собственности).

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

Я сам буду выступать в секции по культуре ИБ с рассказом про... честно говоря еще и не знаю про что. У меня будет всего 15 минут и поэтому надо ужать в этот тайм-слот что-то интересное и полезное, что непросто. Я вообще не люблю такие короткие презентации, но так получилось. Кстати... у вас может возникнуть вопрос, причем тут конвергенция, которая упоминается в названиях трех панельных сессий? Честно, я и сам не знаю и в программном комитете нам не удалось прийти к консенсусу. Конвергенция - это процесс сближения ранее различных позиций, течений, точек зрения и т.п. Поэтому лично для меня понятие "конвергенция культуры ИБ" звучит достаточно странно, так как тут нет процесса сближения. С чем сближается культура? А с чем сближается последняя линия защиты? А конвергенция compliance? В общем, мне не совсем понятно использование термина "конвергенция", исключая пленарную сессию "ИБ между Востоком и Западом", в которой как раз есть две позиции и они... но вот сближаются ли они? Может для того, что происходит между двумя частями света, надо использовать термин "дивергенция", то есть расхождение?.. В любом случае Рустем Хайретдинов обещал раскрыть, в чем же заключается конвергенция ИБ в своем докладе, который и начнет секцию по культуре, а на самом деле является заглавным для всей презентационной части конференции. А я, возможно, буду его троллить :-)

В любом случае мероприятие должно быть интересным (еще бы времени увеличить докладчикам раза в два-три). 

Подробнее…

Новые требования ЦБ устанавливают обязательность ГОСТа для кредитных и некредитных финансовых организаций

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

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

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

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

Требования для кредитных организаций

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

В целом ничего нового в этом проекте нет, за исключением всего одного момента. Выполнение требований нового ГОСТа с дифференциацией требований по уровням защиты выглядит вполне разумно, но... кредитные организации обязаны также выполнять и 382-П наряду с новым Положением. А 382-П никак не привязывает требования по защите к 3-м уровням. И вот этот момент мне пока непонятен. Допускаю, что ЦБ в перспективе планирует внести изменения и в 382-П, но позже; после недавнего крупного изменения, вносить еще одни правки было бы неразумным.

Требования для некредитных финансовых организаций

Второй проект стал следствием получения Банком России новых полномочий. Он почти ничем не отличается от первого, разве что он не требует от некредитных финансовых организаций выполнять 382-П. Но в любом случае он может стать для них неприятным сюрпризом (хотя ЦБ неоднократно на протяжении последних лет предупреждал о том, что он обяжет всех профессиональных участников финансового рынка выполнять требования по ИБ, схожие с теми, что были установлены для банков). Он также как и предыдущий проект привязывает требования по защите к уровням из ГОСТа 57580.1, но уже не к двум, а к трем. Последний, минимальный уровень устанавливается для микрофинансовых организаций, кредитных потребкооперативов, жилищных накопительных кооперативов, сельскохозяйственных кредитных потребкооперативов и ломбардов. Вроде бы им и радоваться надо, что требований для них мало (хотя "мало" понятие субъективное; особенно для тех, кто никогда не занимался своей кибербезопасностью профессионально), но есть три нюанса, на которые я бы обратил внимание:

1. Такие организации обязаны изучить регулирование криптографии, которая им может потребоваться как для защиты ПДн, так и для защиты иной информации. Также они должны изучить законодательство об электронной подписи.
2. Такие организации обязаны информировать ФинЦЕРТ о выявленных инцидентах.
3. Такие организации обязаны присоединиться к ГосСОПКЕ и взаимодействать с ФСБ для уточнения порядка информирования ФинЦЕРТа и ГосСОПКИ.

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

Дата вступления в силу новых проектов не установлена (будет зависеть от даты принятия), а вот  требование по сертификации банковского/финансового ПО (исключая небольшие финансовые некредитные организации, которым это не требуется) вступают в силу с 1-го января 2020 года, требования по использованию ГОСТа 57580.1 и внешнему аудиту соответствия ГОСТ 57580.2 - с 1-го января 2021 года.

Подробнее…

Новый закон США повлияет на сертификацию ФСТЭК

13 августа 2018 года Президент США Дональд Трамп подписал закон №115-232, также известный как H.R.5515 – John S. McCain National Defense Authorization Act for Fiscal Year 2019. В отечественной прессе он рассматривался с точки зрения увеличения американского военного бюджета, но мне бы хотелось на него взглянуть с более привычной читателям моего блога точки зрения – кибербезопасности. В этом документе, занявшем 788 страниц, среди прочего затесалась неприметная статья под номером 1655, вольный перевод с английского которой звучит примерно так: «Министерство обороны США может не использовать (читай – не приобретать) ИТ- или промышленные решения, АСУ ТП или технологии кибербезопасности, если в отношении них в течение пяти лет до принятия настоящего закона или в любой момент после принятия настоящего закона иностранные организации или государственные структуры проводили анализ исходного кода упомянутых решений, используемых или планируемых к использованию министерством обороны США».

Что означает данная статья для компаний, чей исходный код инспектировался во время сертификации по требованиям безопасности в любой стране, которая установила такие требования (например, Китай, Германия или Россия)? В самом лучшем варианте – существенное усложнение процедуры продажи таких решений министерству обороны США, поскольку в положения закона уже заложена возможность отказа. В худшем сценарии возможен полный отказ МО США от использования и приобретения таких решений, что может обернуться огромными потерями для ИТ/OT/ИБ-компаний, измеряемыми десятками и даже сотнями миллионов долларов.

Какие известные нам компании поставляют свою продукцию в американское министерство обороны (обратите внимание, что речь идет не об американских компаниях, а о тех, кто имея штаб-квартиру, например, в Германии или Израиле, поставляет свою продукцию в МО США)? Вот только небольшой перечень (в алфавитном порядке):

• Check Point
• Cisco
• Dell
• Forcepoint
• Fortinet
• HP
• IBM
• McAfee
• Microfocus (Arcsight)
• Microsoft
• Palo Alto
• Rockwell
• SAP
• Trend Micro
• VMware

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

Как вы думаете, что будет делать компания, которая стоит перед дилеммой – сохранить минобороны США в качестве своего клиента, отказавшись от передачи исходного кода своих продуктов другим государствам, или попробовать получить новых клиентов в новых странах, которые требуют инспекции исходников (в России – сертификации на отсутствие НДВ)? Я не берусь предсказывать и тем более предполагать за руководство именитых и упомянутых ранее компаний, но что-то мне подсказывает, что они в лучшем случае приостановят все процессы сертификации, требующие передачи исходных кодов иностранным государственным структурам или организациям, упомянутым в статье 1654 обсуждаемого в заметке закона. К ним относятся организации и структуры тех стран, которые:

• Представляют риск кибербезопасности (читай атакуют) для критической инфраструктуры граждан и финансовых систем США или коалиционных партнеров США (это те государства и военные организации, которые вместе с США участвуют в военных операциях или помогают в них США).
• Поддерживают лиц и государства, перечисленные в предыдущем пункте.
• Занимаются разведкой с целью подрыва национальной безопасности США.
• Участвуют в транснациональной организованной преступности или преступной деятельности.
• Пытаются воздействовать на цепочки поставок, созданные в интересах американского правительства.
• Крадут интеллектуальную собственность у правительства или граждан США.

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

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

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

Подробнее…

Впечатления от проведенных киберучений

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

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

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

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

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

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

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

Подробнее…

Imperva покупает Prevoty

Компания Imperva 26 июля подписала соглашение о приобретении за 140 миллионов долларов компании Prevoty, работающей в сегменте DevSecOps и выпускающей решения по защите приложений в процессе исполнения. 

Подробнее…

Cisco покупает Duo Security

2 августа компания Cisco анонсировала приобретение частной компании Duo Security, являющейся лидером рынка многофакторной аутентификации и унифицированного защищенного доступа. Cisco последовательно расширяет свое портфолио, выводя свои традиционные корпоративные решения в облака. Вслед за покупкой OpenDNS (облачный Secure Internet Gateway), Observable Networks (облачный мониторинг аномалий), CloudLock (облачный анализ приложений и утечек), добавился и облачный контроль доступа (в развитие решения Cisco ISE). Стоимость сделки составила 2,35 миллиарда долларов. 

Подробнее…

Тест "Кобаяси Мару" при приеме безопасника на работу

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

По сюжету «Кобаяси Мару» является космическим гражданским кораблем, который находясь в нейтральной космической зоне расы клингонов, оказался поврежден. У клингонов с людьми идет длительное конфликт и поэтому вмешательство тестируемого курсанта может негативно сказаться на развитии событий. Если попытаться спасти пассажиров «Кобаяси Мару», нарушив нейтралитет с клингонами, то это спровоцирует их на агрессию и возможно военный конфликт. Если выбрать невмешательство, то это значит дать гражданскому судну погибнуть. Это классическая дилемма с двумя безвыходными и негативными сценариями развития событий и надо выбрать из них только один. При этом в фильме компьютер, который и моделирует данную игру с курсантами, запрограммирован на проигрыш курсанта.

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

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

Чем не идея? Среди других тестов "Кобаяси Мару" в ИБ может быть проверка дилемм "отечественное или зарубежное средство защиты", "open source vs коммерческое ПО", "своя система защиты vs аутсорсинг"...

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

Подробнее…

Новая триада законодательства по финансовой безопасности (презентация)

Еще одной темой презентации, прочитанной мной на Payment Security, стало новое законодательство, применимое к финансовым организациям. Это и пресловутый ФЗ-187, и новая редакция 382-П и ГОСТ 57580.1. Вот об этой триаде (хотя к ней можно было бы добавить и удаленную идентификацию) я и говорил в Питере. Вроде ничего нового, но вдруг кому-то будет интересно :-)

Новая триада законодательства по финансовой безопасности from Aleksey Lukatskiy

Подробнее…

Сегодня для обнаружения атак недостаточно систем обнаружения атак (презентация)

На прошедшей на прошлой неделе в Питере Payment Security довелось мне вернуться к истокам - к теме обнаружения вторжений, которой я начинал заниматься в 98-м году и про которую написал в 2000-м свою первую книгу. Прошло 20 лет, а некоторые отечественные разработчики так и застыли в том времени, используя те же самые подходы к разработке средств обнаружения атак/вторжений. Отчасти это связано с нормативной базой, которая и задает тон для российских разработчиков. Но сегодня обнаружение атак - это не тоже самое, что и 20 лет назад. Этот очевидный тезис не столь очевиден для многих потребителей, которые по-прежнему живут в парадигме "для обнаружения атак надо использовать СОВ/СОА". Но за прошедшие пару десятилетий изменилось многое - атаки, технологии, подходы, архитектуры. И все это надо учитывать при выстраивании системы обнаружения атак на предприятии. Именно системы, а не средства. Одним продуктом это не решить (какой бы он ни был). Этому и была посвящена презентация, которую я выкладываю в блоге.

Обнаружение атак - из конца 90-х в 2018-й from Aleksey Lukatskiy

ЗЫ. Я знаю, что SlideShare недоступен для многих пользователей из-за блокировки LinkedIn. Но обойти это ограничение не составляет большого труда.

Подробнее…

Broadcom покупает CA

11 июля компания Broadcom, один из лидеров рынка поставщиков полупроводников, согласился купить компанию CA за почти 19 миллиардов долларов. Зачем это Broadcom не совсем понятно - не повторилась бы история с Intel и McAfee. Но будем посмотреть...

Подробнее…

Фиды - это еще не Threat Intelligence

“А у вас есть фиды?” - так часто начинается разговор наших заказчиков, которые обращаются к нам с вопросом о наличии у нас решений класса Threat Intelligence. “А у нас есть фиды!” - так часто звучит доказательство наличия системы TI в организации. Но фиды - это еще не Threat Intelligence, это скорее попытка заговорить о создании программы TI (или CTI, Cyber Threat Intelligence) в организации. Хотя и просто работа с фидами - это тоже непросто. Как, например, понять, когда полученный в рамках обмена фидами индикатор в виде IP-адреса вредоносного узла необходимо перестать учитывать, потому что он был "вылечен"? Или вот реальный свежий пример. Приходит в рамках информационного обмена индикатор в виде имени домена, который надо блокировать, а там "media.kaspersky.com"!!! С какого перепуга, спрашивается? Начинаешь переписку, а тебе в качестве доказательства вредоносности приводят статью из New York Times, где говорится, что продукты ЛК шпионят за пользователями. Просишь доказательств, а их нет. И как верить такому источнику? А ведь можно вспомнить и историю с Гризлигейтом, когда Россию обвиняли почем зря во вмешательстве в американские выборы и приводились "какие-то" индикаторы, которые с тем же успехом могли играть и против американцев. А ведь это только фиды. В категории уровней TI - это самый нижний, технический уровень.

Выше у нас еще есть тактический уровень, на котором надо оперировать тактиками, техниками и процедурами (TTP). Помните, в ноябре 2016-го я писал об этом? В пирамиде это самый верхний и самый непростой уровень для сбора информации. Да, мы можем использовать ATT&CK, но как формализовать описание методов злоумышленников? Тоже непростая задача; особенно в условиях повального импортозамещения, когда все западные продукты, использующие ATT&CK в своей работе, не могут быть использованы многими российскими предприятиями, а российские продукты вообще не используют ATT&CK в своем функционале.

Но допустим мы решили и эту проблему, какие сложности встают перед нами? Второй по поулярности вопрос после "а у вас есть фиды", звучит так: "А можете прислать ссылок на источники фидов и желательно бесплатных?" :-) Ох уж это неискоренимая жажда халявы :-) Ну да ладно, есть такие списки и предоставляемые ими фиды вполне себе неплохи на первых порах (с учетом ранее описанных нюансов).

А где их хранить все эти фиды и описание TTP? А как поднять с тактического уровня на операционный и оперировать уже целыми кампаниями? Как от разрозненных индикаторов перейти к пониманию того, что против нас действует целая группировка и уж точно попадание в логи МСЭ или IPS IP-адреса из присланного фида является неслучайным совпадением? Для этого нам нужны платформы Threat Intelligence (TIP), которые могут быть коммерческими и бесплатными, закрытыми и открытыми, зарубежными и отечественными. А не накроется ли выбранными нами TIP медным тазом, как это произошло с Soltra)? Есть ли у нас план Б на этот случай?

И конечно не стоит сбрасывать со счетом TI, предоставляемый нам государством, ГосСОПКОЙ или ФинЦЕРТом. В чем их сила, а в чем слабость? Это тоже вопросы, которые требуют ответа. Правда, с ГосСОПКОЙ пока все ясно - там нет ничего, что можно было реально использовать, - ни достаточного количества данных, ни ясной процедуры подключения, ни утвержденных стандартов обмена данными об инцидентах.

Кстати, о стандартах. Какой их них выбрать? STIX, используемый большинством компаний в мире и ставший по сути стандартом де-факто в этой области? CybOX? А может отечественный СТО 1.5, разработанный Банком России, и требуемый для взимодействия с ФинЦЕРТом? А что будет использовать ГосСОПКА (кроме TLP)? Не получится ли так, что мы сейчас выберем то, что не будет поддерживаться ни регуляторами (куда уж без них), ни отечественными разработчиками (хотя вот BI.ZONE в своей платформе обмена данными использует расширенный вариант STIX).

Но допустим мы выбрали платформу, выбрали источники фидов, научились описывать не только отдельные индикаторы и целые компании, но даже смогли подняться на стратегический уровень TI (он не всем нужен, кстати) и заняться атрибуцией нарушителей (со всеми оговорками, которые связаны с данной процедурой). Как измерить процесс Threat Intelligence? Как понять, что и сам процесс работает эффективно, и используемые нами источники дают ценную информацию, которую мы действительно используем, а не просто складируем в TIP?

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

Подробнее…

Thoma Bravo покупает Centrify

Частный инвестиционный фонд, хорошо известный в области поглощения на рынке ИБ, Thoma Bravo, объявил 10 июля о намерении приобрести одного из игроков рынка контроля привилегированного доступа, компанию Centrify. Размер сделки не разглашается.

Подробнее…

AT&T покупает AlienVault

10 июля американский провайдер AT&T объявил о планах по приобретению компании AlienVault, известного разработчика SIEM (коммерческого USM и бесплатного OSSIM) и поставщика Threat Intelligence. Размер сделки не разглашается.

Подробнее…

Будущее криптографии: гомоморфное, медовое, функциональное и ДНК-шифрование

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

• Медовое шифрование. Когда я только начинал изучать криптографию, то я задавался вопросом: "А как при автоматизации процесса дешифрования понять, что мы получаем правильный текст и как отличить один набор получаемых символов от другого?" И вот проблема, лежащая в основе этого вопроса, легла и в основу нового метода шифрования под названием "медовое". Когда криптоаналитик пытается дешифровать шифртекст с помощью неверного ключа он получает бессмысленный текст; в случае с медовым шифрованием криптоаналитик получает вполне осмысленную последовательность. И злоумышленник даже не понимает - он получит реальный открытый текст или фальшивый? Интересный проект.
• Гомоморфное шифрование. Когда мы используем обычное шифрование, то мы сталкиваемся с ситуацией, к которой мы привыкли и даже не считаем ее проблемой. Чтобы поработать с зашифрованными данным мы их должны расшифровать и тогда они могут стать достоянием злоумышленников. Гоморфное же шифрование подразумевает, что вы можете проводить операции над зашифрованным текстом и получать вполне адекватный результат без расшифрования текста. Например, такую схему можно использовать в электронных выборах (подсчет голосов при сохранении анонимности избирателей), в облачных вычислениях, при защищенном поиске (выдача результата без анализа его реального содержимого) или в системах с обратной связью и т.п. И хотя идея гомоморфного шифрования была сформирована 40 лет назад, первый полностью гомоморфный алгоритм появился только в 2008-м году, но до сих пор все такие системы являются крайне низкопроизводительными, что и ограничивает их активное применение в реальной жизни. 
• Функциональное шифрование. С одной стороны функциональное шифрование, предложенное в 2005-м году, базируется на идее шифрования с открытыми ключами, а с другой - в нем передается не зашифрованное сообщение, а зашифрованная функция, которая позволяет по аналогии с гомоморфным шифрованием обеспечить защиту данных не расшифровывая их целиком. Например, одним из сценариев применения такой схемы является защита программного обеспечения от анализа злоумышленниками. После его функционального шифрования мы получаем эквивалентный по функциональности, но недоступный для анализа, обфусцированный исходный код. Помимо защиты интеллектуальной собственности функциональное шифрование может быть применено и в облачных вычислениях.
• ДНК-шифрование. В 1994-м году Леонард Адлеман (ему "принадлежит" буква А в алгоритме RSA) предложил идею использования ДНК для осуществления вычислений путем манипулирования молекулами, что позволяет производить параллельно триллионы операций. В отличие от бинарной логики современных компьютеров и кубитов квантовых компьютеров у ДНК-вычислений код тернарный (на основе 4-х оснований), что и обеспечивает огромную скорость вычислений. Однако извлечение результата вычислений из ДНК осуществляется гораздо медленнее, что пока и сдерживает активное их использование, в том числе и для криптоанализа.

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

PS. Кстати, у Siri очень забавные поисковые ассоциации с описанными в заметке вариантами шифрования :-)

Подробнее…

ФСТЭК определилась со своим будущим

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

1. ФСТЭК прямо заявляет, что они фокусируются на защите государственных органов и КИИ. Это вроде уже не новость - ФСТЭК об этом говорит уже не первый раз, дистанцируясь и от темы ПДн (проверять-то они не могут операторов ПДн), и от темы НПС (проверять участников НПС они тоже не проверяют, "делегировав" это Банку России), и от ряда других тем, где они не названы уполномоченным органом, имеющим всю полноту власти. То ли дело КИИ и госы, где ФСТЭК чувствует себя как рыба в воде и может выпускать любые приказы и регламенты и проверять их исполнение. Этот пункт важен в контексте всех последующих шагов и означает, что коммерческим организациям не стоит ждать откровений и решения всех своих вопросов и проблем - в порядке живой очереди, но госы все равно имеют приоритет.
2. Из пункта номер один вытекает пункт №2 - обязательную сертификацию ФСТЭК требует только для госорганов. Точка. Все, что придумывают остальные регуляторы (ЦБ в своем ГОСТе или 382-П, Минздрав в 447-м Постановлении Правительства от 12 апреля 2018 года), это все головная боль не ФСТЭК, а придумавших это регуляторов. И как будет осуществляться сертификация АБС по ОУД4 или прикладных систем, подключающихся к единой системе в сфере здравоохранения, об этом пусть думают регуляторы, установившие это требование.
3. Из пункта 1 и 2 вытекает пункт 3. Так как ФСТЭК ориентирован на госы и обязательная сертификация требуется только для госов, то ФСТЭК сейчас начинает говорить о вполне закономерном шаге, который должен повысить безопасность подопечных регулятора. Речь идет об установке "грифа" ДСП на документы ФСТЭК, в том числе и на требования по сертификации (я не буду вдаваться в детали, какие документы уже имеют такой гриф, а какие планируют его получить). Логичный вопрос для банка "а как мне устанавливать требования к средствам защиты, которые по требованию ГОСТа ЦБ должны быть сертифицированы, если РД на эти средства может быть закрыт для посторонних?" на самом деле не является головной болью ФСТЭК. Не они от банков требовали сертификации (они кстати выступали против принятия ГОСТа на заседании ТК122). Не они регулируют финансовые организации. Не им и отвечать. Это ЦБ должен думать, как доводить до всех тысяч финансовых организаций дспшные требования. То ли требовать от всех лицензию на гостайну получать, то ли лицензию на ТЗКИ. Но оба пути в никуда :-(  
4. Из первых двух пунктов вытекает и последняя замеченная мной тенденция - ФСТЭК постепенно отказывается от "Общих критериев" в сторону старых добрых требований к классам защищенности. Возможно это геополитически и не совсем верно, но зато проще для всех участников процесса сертификации по требованиям безопасности. Лаборатории не будут задумываться, как писать профили защиты и задачния по безопасности (это долго, дорого, и не всегда очевидно как, не имея опыта в этом процессе). Заказчики (читай, госы) четко будут понимать, что им требовать от вендоров. Вендора смогут понятным языком объяснять, какой функционал есть в их продуктах и как он накладывается на классы защищенности. Отсюда возникает вопрос, связанный с недавно принятой новой редакцией 382-П, обязывающей сертифицировать банковские и финансовые приложения на ОУД4 по линии ФСТЭК. Если лаборатории постепенно будут "забывать" про "Общие критерии", то найти того, кто возьмется за сертификацию и постоянное обновление сертифицированного изделия (а ЦБ постоянно что-то меняет в своей нормативке, что приводит к изменениям в ПО) будет непросто и недешево.

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

1. Десять раз подумайте, нужна ли вам обязательная сертификация средств защиты, если государство от вас этого не требует на уровне ФЗ или ПП.
2. Живите свои умом, но не забывайте поглядывать и в сторону документов ФСТЭК. Они написано здраво и не требуют сверъестественного. Более того, алгоритм выбора защитных мер оттуда гибкий и позволяет учесть кучу нюансов современной организации бизнеса.
3. Не стоит забрасывать ФСТЭК запросами и письмами, на которые ответ либо будет расплывчатым, либо неустраивающим вас. Фактически ФСТЭК не регулирует вопросы защиты информации ни у кого, кроме госов и КИИ. Так зачем спрашивать то, на что у ФСТЭК нет ни полномочий, ни опыта, ни, следовательно, четкой позиции.
4. Не ждите каких-то разъяснений, которые сделают вашу жизнь легче. А дальше см.п.3. И даже для КИИ не стоит ждать от регулятора манны небесной и ответа на вопросы: "А как мне категорировать мои объекты КИИ?", "А где мне провести границы объекта КИИ?", "А я субъект КИИ?", "А я могу объединить несколько объектов КИИ в один?". Помните, что в отличие от коммерческой организации, живущей по принципу "все, что не запрещено явно, разрешено", ФСТЭК, как и любой госорган, следуют прямо противоположному принципу - "Все что не разрешено явно, запрещено". Ну откуда ФСТЭК знает, как категорировать подстанцию, ТЭЦ, АЗС, автовокзал или районную больницу? Не она же управляет ими и не она обладает исходными данными для категорирования. Она может оценить (и то за ограниченное время) правильность ваших действий, но не решить это за вас. Да и правильность ФСТЭК оценить может только спустя какое-то время, получив опыт работы с кучей актов категорирования. 

Ну вот как-то так...

Подробнее…