Pages - Menu

Страницы

30.4.19

Безопасность на полшишечки

За последний месяц я посетил несколько крупных мероприятий по ИБ - московский "Код ИБ. Профи", CISO Forum, питерский Код ИБ, SOC Forum в Казахстане, Cisco Connect и везде меня преследовало ощущение, что все-таки многолетняя ориентация на регуляторов сильно испортила современных безопасников, у которых сформировано неполноценное представление о том, для чего нужна кибербезопасность.

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

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

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

Что у нас еще из актуального? Измерения ИБ. Все гоняются за метриками, которые должны показать вклад ИБ в бизнес; ну или не в бизнес. Но... и тут у нас безопасность не до конца, на полшишечки. Измерение же ИБ нужно не само по себе, а для принятия решений по результатам измерений. Вот хотим измеряем мы число инцидентов ИБ и ставим себе цель сделать это число менее 100 в месяц. Но чтобы это сделать, нам нужно внедрять мероприятия, которые позволят снизить это число, а они могут быть достаточно непростыми и длительными. Или метрика для оценки времени между обнаружением уязвимостью и ее закрытием. Этот временной параметр должен уменьшаться, но сделать это не так уж и просто и потребует налаживания контакта с той же ИТ-службой и внедрением ряда организационных и технических мероприятий.

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

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

ЗЫ. А впереди еще несколько крупных мероприятий по ИБ - PHDays, ITSF, Offzone, ICC и думаю там тоже будет немало безопасности на полшишечки. Кстати, фраза "на полшишечки" пришла из наркоторговли - так определяли дозу марихуаны, приготавливаемой из шишек конопли. А уж потом эта фраза пошла дальше, не сильно изменившись по сути.

29.4.19

5 советов, от которых зависит успешность вашего SOC (презентация)

Опираясь на опыт службы ИБ Cisco, имеющей SOC с 19-тилетней историей, опираясь на опыт проектирования и построения SOC у сотни заказчиков, и опираясь на опыт аутсорсинга SOC у другой сотни заказчиков, у нас накопился большой опыт в области центром мониторинга ИБ и реагирования на инциденты. И вот для выступления на SOC Forum KZ я выбрал 5 советов, недооценка которых может сделать проект по SOC неудачным. Это не единственные советы, но за 20 отведенных мне минут, больше просто не получилось. Презентацию выкладываю на Slideshare (не у всех покажется).



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


А 15-16 апреля я в эту тему смог погрузиться еще глубже - в Алматы и Нур-Султане у меня было от 4 до 7 часов, выделенных только под мой рассказ про SOC. По отзывам получилось неплохо. Но эта презентация была наполнена инсайдами внутренней кухни Cisco и я не планирую ее выкладывать. Однако частично рецептами этой кухни я делился на Cisco Connect в конце марта, где у меня было два доклада - про выстраивание security operations и про некоторые аспекты обеспечения ИБ внутри Cisco. Обе презентации с видеозаписями моих выступлений выложены на сайте конференции (там много выложены и остальные записи с потока по ИБ).

8.4.19

ФСТЭК катится по наклонной

На днях широко известная в широких кругах сенатор (или сенаторша) Мизулина написала обращение в Генпрокуратуру по поводу занятий йогой в московских СИЗО. По мнению Мизулиной позы йоги вызывают "неконтролируемое сексуальное возбуждение, а это в свою очередь может привести к гомосексуализму в изоляторах"! Хорошее начало, да?! Эта новость иллюстрирует оторванность от жизни тех, кого мы выбрали или считаем, что выбрали. Тоже самое относится и к чиновникам.

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

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

Или вот еще пример. Тех же разработчиков IDS (СОВ) спрашивают: "А давайте мы разрешим обновления знаний об угрозах брать не только от вас, но и вообще откуда угодно, чтобы повысить эффективность обнаружения?". Все в один голос отвечают: "Нет, не надо". И снова разработчиков можно понять. Это же надо разрабатывать интерфейсы для поддержки STIX/TAXII, OpenIOC, CyBOX и т.п. стандартов и протоколов. А потребитель сравнит частоту обновления от вендора и от бесплатных источников и начнет задавать вопросы. Зачем это нужно вендору?

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

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

Когда-то, начиная с 2013-го года, я считал, что ФСТЭК стала на путь исправления и теперь станет прогрессивным регулятором, считающимся с мнение отрасли и не только устанавливающим требования по защите, но и толкающим отрасль вперед. Но последние и неоднократные действия регулятора похоже возвращают ФСТЭК во времена СТР-К, "четверокнижия по ПДн" и др., которые "царствовали" в начале 2000-х. Жаль... Похоже скоро я напишу такую же заметку, как когда-то написал про персданные и Роскомнадзор. Вернусь к тому, для чего я изначально затевал блог, - к бизнес-ориентированным заметкам.

5.4.19

Почему ФСТЭК блокирует использование облачных платформ Threat Intelligence?

Продолжу-ка я тему, начатую позавчера, и разверну вопрос, упомянутый вскользь, - облачная аналитика Threat Intelligence. Я упомянул, что новые сертификационные требования ФСТЭК по требованиям безопасности фактически делают невозможным оперативное получение данных об угрозах из облаков. Причина такого решения ФСТЭК мне понятна - они опасаются нанесения ущерба защищаемым объектам из таких облаков. Рисков два - утечка информации из защищаемой сети в облако и получение из него вместо обновлений вредоносного кода.

Что можно сделать в такой ситуации? Как, например, можно обновлять антивирус или систему обнаружения атак, требующие регулярного получения сигнатур? Флешка - самый простой вариант, который нередко используется сертифицированного решениями. Или создается нечто вроде прокси-шлюза, который отвечает за обновление всех средств защиты внутри защищаемого объекта, а сам он обновляется с помощью той же флешки или через однонаправленный канал. Например, именно такой вариант используют те же решения "Лаборатории Касперского", которые применяют не обычную KSN, а ее приватную версию - KPSN (Kaspersky Private Security Network). Кстати, и при сертификации "Касперского" подавалась именно KPSN, а не KSN. Схожая схема используется в тех же решениях Cisco, которые могут обмениваться данными с облачной песочницей Threat Grid, а могут с локальной, работающей даже в режиме "air-gap". EDR-решение Cisco AMP имеет как управление из публичного облака, так и из частного. Но вариант с флешкой или локальным сервером обновления (или той же "песочницей") работает только в случае, когда источник обновления всего один - от самого вендора средства защиты.


Но сегодня нельзя доверять одному вендору. И дело не в том, что он может прекратить свое существование или неоперативно обновлять свои средства защиты. Он не может "видеть" и знать все и обо всем. Например, он может хорошо разбираться в угрозах для финансовых организаций, но не иметь представления о промышленных атаках. Или он может прекрасно разбираться в атаках, присущих для европейского региона, но не "видеть" азиатских или американских операций хакеров. В любом случае потребитель хочет иметь возможность резервировать источники получения информации об угрозах. Поэтому сегодня многие современные защитные решения поддерживают функцию работы с различными TI-сервисами по стандартизованным протоколам - STIX/TAXI, OpenIOC, CyBOX и т.п. В этом случае вы можете существенно повысить эффективность купленных решений.


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

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

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

4.4.19

Как устроена безопасность внутри Cisco: зарисовки

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

Учитывая, что про нашу внутреннюю кухню ИБ можно говорить долго (даже на базе публичной информации), а у меня был всего один час, я решил сделать некоторые зарисовки, описывающие как технические, так и организационные аспекты. Про Cisco Security Ninja я уже писал на Хабре. Про мониторинг нашей инфраструктуры тоже; как и про контроль сетевого доступа. В этот раз я погрузился в детали того, что такое Trusted Enterprise в нашей трактовке и из каких четырех столпов оно состоит, а также в то, что такое C-Bridge, решение, которое позволяет нам мониторить удаленные и недоверенные площадки, подключаемые к нашей корпоративной сети. Ну и специально, чтобы показать, что нельзя построить эффективную ИБ только из готовых, купленных на рынке компонентов, я рассказал о системе iCAM, которую мы написали самостоятельно и которая является объединением двух технологий DLP и UEBA. Про наши собственные open source разработки я также уже писал - про GOSINT, про OpenSOC, про OpenGraphiti и про кучу других.



ЗЫ. Возможно скоро на сайте мероприятия выложат видео этой презентации.

3.4.19

Авторский вечер Алексея Лукацкого "Look At Sky"

Разбавим утренний негатив и чем-нибудь позитивным :-) Спустя 15 лет работы в Cisco дожил до авторского вечера для директоров по ИБ - "Look At Sky Party". Благодаря помощи золотого партнера Cisco, компании Step Logic, вечеринка пройдет в стиле "Звездных войн". Ростовые куклы (в том числе обещана моя кукла :-), настоящий R2D2, рассекающий гостей надвое, голографический бар с реальными напитками и мной, возможно, в роли бармена, игровые автоматы, обучение фехтованию на световых мечах, бизнес-игра и всякое разное другое. Регистрация для директоров по ИБ по адресу - https://ru.surveymonkey.com/r/32S685B


ЗЫ. За регистрацию я не отвечаю. Промо-кодов и контрамарок нет :-)

Новые требования ФСТЭК по сертификации еще больше сужают рынок средств защиты

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


Меня в этом информационном сообщении заинтересовал только один пункт, а именно следующий: "Разработчикам и производителям сертифицированных средств защиты информации рекомендуется с привлечением испытательных лабораторий провести оценку соответствия средств защиты информации Требованиям к уровням доверия и представить результаты в ФСТЭК России для переоформления соответствующих сертификатов соответствия. Действие сертификатов соответствия средств защиты информации, в отношении которых указанная оценка соответствия не будет проведена до 1 января 2020 г. на основании пункта 83 Положения о сертификации средств защиты информации, утвержденного приказом ФСТЭК России от 3 апреля 2018 г. N 55, может быть приостановлено" (выделение мое).

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


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

ЗЫ. Но есть и хорошие новости. Но после обеда :-)

2.4.19

"Код ИБ. Профи": послевкусие

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


Я не буду рассказывать о докладах; тем более, что скоро на сайте https://academy.codeib.ru/  скоро будут выложены и презентации и видеозаписи. Но я хотел бы сказать спасибо коллегам, которые согласились поделиться своим опытом с участниками "Код ИБ. Профи":

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


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


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


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


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


В целом хочу еще раз сказать спасибо и коллегам-докладчикам, и организаторам в лице компании "Экспо-Линк" и ее руководителю - Ольге Поздняк, и участникам. Думаю, что сейчас, по окончании четвертого мероприятия удалось нащупать баланс в темах, докладчиках, форматах. Близится летний "Код ИБ. Профи", который пройдет в Сочи 25-28 июля и регистрация на который уже открыта. Получено предварительное согласие от ряда спикеров, который вновь поделятся своим опытом (и никаких повторов). Уже есть идеи по новым киберучениям. Ольга Поздняк готовит новую культурную программу, благо горы (а "Код ИБ. Профи" пройдет в "Горки-Город" на Красной Поляне) позволяют замутить много разных вариантов. И такой немаловажный момент - в отличие от московского мероприятия, где спикерам было сложно оторваться от семей и работы и участвовать во всех активностях все дни, в Сочи все будет иначе - деться будет некуда и все открыты будут для общения. Кто был в прошлом году в горах на "Код ИБ. Профи", тот помнит вечерние посиделки в барах и кафе и разговоры до ночи. Присоединяйтесь! 

1.4.19

ФСТЭК переводит реестр сертифицированных средств защиты на блокчейн

На прошедшей 13-го марта "Нашей игре", посвященной сетевой безопасности, среди прочих я задал следующий вопрос:


Ответом на него был "Google Dorks", то есть набор приемов, который позволяет с помощью специальных операторов Google находить всякие разные штуки, включая уязвимости, пароли, а также конфиденциальные документы, а также файлы, которые сложно найти через систему индексации сайта. Я иногда "прохаживаюсь" по сайтам наших регуляторов и иногда улов бывает очень интересным. Например, как сегодня. На сайте ФСТЭК я наткнулся на презентацию, подготовленную консультантом управления ФСТЭК, в которой говорится о планах перевода реестра сертифицированных средств защиты информации на технологию блокчейн.

Я уже писал о том, каким мог бы быть реестр сертификатов ФСТЭК и на прошедшей в феврале конференции регулятора Виталий Сергеевич Лютиков сказал, что они внимательно изучили мой "сон" и что-то возьмут на реализацию, а что-то сделают уже в самое ближайшее время. И что-то они действительно сделали.


Но я не думал, что будет сделан такой рывок вперед. ФСТЭК решила перевести свой реестр на блокчейн, который в презентации назван "цепной записью". Кстати, именно этот термин используется ФСБ и ТК26, которые даже первый документ на эту тему выпустили.


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


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


В блоке цепной записи ФСТЭК планирует хранить всю сопутствующую средству защиты информацию:


в том числе и контрольные суммы на средство защиты информации:


И судя по составу информации, она может меняться достаточно часто - ФСТЭК приводит несколько таких ситуаций.


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


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



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

Будем ждать новый идей и реализаций от основного регулятора в области информационной безопасности.