Круглый стол "Формальная безопасность vs практическая безопасность: как достичь синергии"

Вторым круглым столом на конференции "Кибербезопасность нового времени", проведенной Innostage в рамках казанской DigitalWeek, был "Формальная безопасность vs практическая безопасность: как достичь синергии", который получился не таким, как я его задумывал изначально, готовя вопросы. Поэтому в этой заметке я буду говорить не столько о самом круглом столе, сколько о том, во что вылилась дискуссия и что я про все это думаю.

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

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

Или вот еще история. В самом начале круглого стола, который проходил сразу после выступления Романа Чаплыгина из Positive Technologies об открытых стандартах по ИБ (лучших практиках, создаваемых сообществом), я задал вопрос в зал, сколько из них знает о профессиональном стандарте 12.004 "Специалист по обнаружению, предупреждению и ликвидации последствий компьютерных атак", который был утвержден в 2015 (!) году? Шесть лет назад! Было всего 3 поднятых руки! Всего три на зал из 150 человек. А все потому, что этот стандарт имеет пометку "для служебного пользования". Ну вот о каких открытых стандартах можно говорить, если регуляторы у нас так любят политику засекречения всего, даже списка навыков, которым должен обладать специалист по реагированию на инциденты ИБ? Но интересно не это, а то, что получить этот документ нереально. Если вы запросите его в Минтруде (захотите найти - спрашивайте в Минтруде приказ 1179н/дсп от 29.12.2015), вам откажут и пошлют в ФСБ. Запрос в ФСБ тоже закончится ничем - вас отправят в Минтруд. Вот такой замкнутый круг. А я напомню, что согласно ПП-584 от 27.06.2016 профстандарты являются обязательными к применению всем государственным и муниципальным учреждениям, фондам, а также предприятиям, компаниям и корпорациям, что принадлежат государственным либо муниципальным органам власти (на праве владения более чем 50% от уставного капитала).

Еще одна обсуждаемая на круглом столе тема - трактовки требований регуляторов. Это вообще боль; даже для самих регуляторов, в которых написание требований и их проверка - это часто разные подразделения. А тут еще приближенные к регуляторам компании, которые часто участвуют в разработке требований в составе рабочих групп. Представители этих компаний потом выступают на мероприятиях, в чатах, в соцсетях и выдают собственное мнение за позицию регулятора. Ну есть еще и просто эксперты, которые также по своему трактуют требования нормативных актов. И вот у нас уже 4 разных точки зрения на один документ. И как тут быть? Участники круглого стола, например, Виктор Вячеславов из Innostage, Шальнов Олег из Росэнергоатома или Александр Дубасов из ФГБУ ЦНИИОИЗ Минздрава, посоветовали общаться с регулятором, задавать ему вопросы. Но тут всплывает классическая история - лучше не светиться :-( Наши регуляторы любят при общении с народом задавать вопрос: "Представьтесь, пожалуста" или "Какую организацию вы представляете?" Ну и кто захочет отвечать на такой вопрос? Смельчаков мало. Вот и любят у нас все ждать, когда кто-то храбрый сам спросит регулятора, а потом выложит ответ в каком-нибудь чатике. А сам регулятор, не видя вопросов, считает, что все нормально. Или он видит вопросы с мест, но не хочет публично показывать, что он поторопился с каким-то требованием. Поэтому и информационные письма с разъяснениями он не часто выпускает, ограничиваясь короткими комментариями в узком кругу специалистов или на закрытых встречах. И те, кого на этих мероприятиях "за закрытыми дверями", нет, потом вынуждены слушать пересказы и играть в испорченный телефон.

А вот еще один классический вопрос: "Почему <регулятор> сам у себя не реализовал свои же требования?" Почему на сайте ФСТЭК в разделе "Государственные информационные системы" написано, что у регулятора нет ни одной ГИС? Вы верите в это? Я лично нет. Особенно слыша ответы регулятора на мероприятиях по поводу того, что считать ГИС. Но тогда почему у самой ФСТЭК нет ни одной ГИС? А ОКИИ? ФСТЭК говорила на мероприятиях, что у них есть ОКИИ (научной деятельностью они же занимаются в том же Воронеже). Тогда почему они часто "плывут" на практических вопросах по 235/239-м приказам? А Банк России? ДИБ пишет кучу Пэшек, Ушек, ГОСТов, а потом их должны выполнять в том числе и другие подразделения ЦБ. И у них тоже немало вопросов к регуляторике, которую непонятно как выполнять на практике, так как она местами предельно неконкретна, расплывчата, а то и имеет двойственное/тройственное толкование. С ФСБ все проще - они по-моему до сих пор не имеют локальной сети и живут в мире автономных компьютеров, а обмениваются документами бумажными. В их мире их требования чуть ли не идеальны.

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

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

ЗЫ. Мне кажется, что регуляторам надо выпускать свои документы тройками - сами требования,  разъяснения к ним для тех, на кого требования распространяются, и методика их проверки (в идеале тоже публичная). Все три документа должны быть взаимоувязаны между собой. Тогда и проблем ни с их толкованием, ни выполнением, ни проверкой не будет (ну кроме редких ошибок и клинических идиотов). Прислушался бы кто-нибудь, а?!

Подробнее…

Что не покрывает методика оценки угроз ФСТЭК?

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

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

• «Методические рекомендации по разработке нормативных правовых актов, определяющих угрозы безопасности ПДн, актуальные при обработке ПДн в ИСПДн, эксплуатируемых при осуществлении соответствующих видов деятельности» (утверждены руководством 8 Центра ФСБ России 31 марта 2015 года, № 149/7/2/6-432)
• «Состав и содержание организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных с использованием средств криптографической защиты информации, необходимых для выполнения установленных Правительством Российской Федерации требований к защите персональных данных для каждого из уровней защищенности» (утверждены приказом ФСБ России от 10 июля 2014 года № 378).

Во-вторых, финансовые организации, которые являются либо операторами ПДн, либо владельцами ЗОКИИ, обязаны соблюдать помимо документов ФСТЭК еще и документы Банка России, а именно два действующих Указания:

• Указание Банка России от 10 декабря 2015 г. № 3889-У «Об определении угроз безопасности ПДн, актуальных при обработке ПДн в ИСПДн»
• Указание Банка России и ПАО «Ростелеком» от 9 июля 2018 г. № 4859-У/01/01/782-18 «О перечне угроз безопасности, актуальных при обработке, включая сбор и хранение, биометрических ПДн, их проверке и передаче информации о степени их соответствия предоставленным биометрическим ПДн гражданина РФ в государственных органах, банках и иных организациях, указанных в абзаце первом части 1 статьи 14.1 Федерального закона от 27 июля 2006 года N 149-ФЗ «Об информации, информационных технологиях и о защите информации», в единой биометрической системе»

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

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

Разные методики моделирования угроз

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

Но если внимательно посмотреть на описанные зоны действия методики, то мы увидим, что она, например, плохо подходит для оценки угроз при разработке программного обеспечения, что, например, требуется по отечественным ГОСТам по безопасной разработке. В этом случае вам потребуется что-то другое. Например, хорошим стартом может послужить методика от Microsoft, которую для краткости называют STRIDE, хотя она этой аббревиатурой и не ограничивается. Она, безусловно покарывает не все угрозы для ПО, но самые популярные точно. Кроме того, по ней существует немало материалов и курсов, а также бесплатные средства автоматизации данной задачи. Можно еще посмотреть в сторону методики OWASP, но она не сильно отличается от Microsoft'овской.

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

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

Подробнее…

Математическая оценка читабельности нормативных актов регуляторов

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

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

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

Уровень читабельности 382-П 

У меня нет ни второго высшего, а аспирантуру я так и не закончил. Думаю поэтому мне приходилось читать нормативные акты Банка России по несколько раз. Такой же и один из последних образчиков ЦБшного творчества, 716-П. Он также далек от простоты восприятия (и он даже хуже 382-П по уровню читабельности).

Уровень читабельности 716-П

У ФСТЭК ситуация тоже далека от идеала. Вот так выглядит уровень читабельности приказа №17 с требованиями по защите государственных информационных систем.

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

Другие приказы ФСБ недалеко ушли от "лидера". Например, уровень читабельности приказа 196-го по требованиям к средствам ГосСОПКИ выглядит так:

А есть примеры абсолютно читабельного текста? Да, конечно. Например, если прогнать через проект "Простым языком" русскую сказку "Колобок", то уровень ее читабельности будет рассчитан даже на детей 6-8 лет. Понятно, что нормативка врядли будет изучаться учениками 1-3 классов, но как ориентир этот пример неплох. 

Кстати, сказки Владимира Безмалого по ИБ вполне себе в читабельной форме (правда, нормативку в таком виде не опубликуешь): 

Я решил прогнать через сервис ряд своих заметок в блоге :-) К уровню "Колобка" я не приблизился (и это хорошо), но для учеников последних классов школы я вполне читабелен (это анализ заметки про последнюю методику оценки угроз ФСТЭК).

Чуть более "формальный" обзор телемоста с Лютиковым В.С. оказался рассчитанным на студентов начальных курсов ВУЗов и мне кажется, что это именно тот уровень, к которому нужно стремиться в нормативных документах по ИБ (может быть достигая уровня 5-6 курсов ВУЗа). 

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

Читабельность моего раздела по кибербезопасности для учебника CDTO проект "Простым языком" оценил уже на грани. Думаю, что больше усложнять уже не надо, так как рядовым читателем многое будет восприниматься непросто, что приведет к неясности. 

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

или ПП-127 о категорировании объектов КИИ (это безусловный лидер сегодняшнего обзора, который не разобрать без ста грамм второго образования):

Но не надо думать, что регуляторы не способны писать читабельные документы. Например, проект ГОСТа по безопасной разработке ПО вполне себе читаем его целевой аудиторией:

Как и утвержденная методика ФСТЭК по оценке угроз (вопрос ее реализуемости оставим в стороне):

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

А что касается математики, лежащей в основе методики оценки читабельности текста, то она вполне себе развита и широко применяется. Например, формула Флеша-Кинкейда используется при разработке нормативки американского МинОбороны, а также встроена в популярные текстовые редакторы типа MS Word или сервисы типа Grammarly. На сайте проекта упомянуты все используемые формулы, адаптированные к русскому языку.

Подробнее…

Актуальные требования регуляторов к средствам защиты (видео)

В январе выступал на конференции Oracle Security Day с рассказом об актуальных на тот момент требованиях регуляторов к средствам защиты информации. Оказывается видео этого выступления было официально выложено на Youtube:

ЗЫ. Понятно, что с января много воды утекло, но многие аспекты остаются пока еще актуальными.

Подробнее…

Терминологический кризис или полный п...ец

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

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

Возьмем к примеру проект ГОСТа с терминами и определениями по ГосСОПКЕ, который внесли в ТК362 в августе этого года. Я на него писал отзыв и сейчас, спустя два месяца, думаю могу и в блоге повторить свои мысли здесь.

1. Большая часть терминов не соответствует терминам, уже данным в законодательстве, в том же ФЗ-187. Они зачем-то "адаптированы" в предлагаемом ГОСТе. Возможно, это и обосновано (хотя обоснования не приведено), но это будет вводить еще большую путаницу вместо того, чтобы терминологическую путаницу устранять. А часть терминов не "адаптирована", а просто другая. Например, термин "компьютерная атака" из ФЗ-187 вообще не соответствует проекту ГОСТа (при этом пометки "адаптировано" нет). Часть терминов не соответствует не только НПА ФСТЭК, но и НПА ФСБ.
2. Часть терминов, повторяющихся в утвержденном, но еще не принятом проекте ГОСТ по мониторингу, также не совпадают по тексту и "адаптированы". Это выглядит еще более странно, так как автор у двух проектов ГОСТов один и тот же. Но ГОСТ по мониторингу, видимо, "велся" "под эгидой" ФСТЭК, а ГОСТ по ГосСОПКЕ - "под эгидой" ФСБ. Необходимо хотя бы на уровне обоих ГОСТов принять единую терминологию.
3. Часть терминов из п.4.2.2 про источники данных не соответствует терминам из уже принятых профилей защиты ФСТЭК. Например, средство доверенной загрузки. Также по тексту используются термины, которые не используются ФСТЭК, например, "фсбшный" термин "система обнаружения атак" вместо "система обнаружения вторжений".
4. Часть терминов из п.4.2.3 не соответствуют их смыслу. Например, нормализация - это устранение избыточности, приводящей к ошибкам, а не приведение к единому формату. Корреляция - это поиск зависимостей между случайными событиями, а не просто вид анализа данных. Правило регистрации признаков атак и инцидентов не может быть алгоритмом анализа событий и т.п. При этом в п.4.4.9 для правила регистрации компьютерного инцидента уже другое определение.
5. Очень много терминов некорректны. Например, бэкдор - это не столько дефект алгоритма, сколько намеренно оставленная уязвимость ПО (про ПО в определении ни слова). А уязвимость "нулевого дня" не всегда трактуется как уязвимость до выпуска патча (есть известные годами уязвимости без патча и их никто не называть "нулевого дня"). Источником атаки (как написано в проекте методики МУ ФСТЭК) может быть не только лицо (то есть антропогенный источник) или инициируемый им процесс, но и техногенный источник. Факт получения ВПО ресурсом не может рассматриваться как распространение ВПО. Нарушение или замедление работы ресурса трактуется как неспособность ресурса выполнять возложенную функцию, но это не так. При замедлении работы ресурса он свою функцию продолжает выполнять.
6. В терминах используется то "Интернет", то "глобальные компьютерные сети". Также бывает, что подменяются понятия "признак", "критерий" и "индикатор" применительно к атаке и инциденту.
7. Очень много англицизмов и жаргонизмов, которые слишком буквально переведены на русский язык - "дампер", "плагин", "бэкдор", "руткит", "инсайдер" и т.п.

Причем, это не проблема только ФСТЭК или ФСБ. У других регуляторов схожая проблема. Например, последний, утвержденный 23 октября, стандарт Банка России СТО БР ФАПИ.СЕК-1.6-2020. Там есть такие термины, как "нативное приложение" (ну зачем эти англицизмы?", "агент пользователя" (это, на секундочку, user agent, - зачем тут буквально переводить - смысл же другой), "конечная точка" (это, как вы понимаете, "endpoint")... От этой "конечной точкой" и начинаются "конечная точка клиента" (наверное, точка G) и "конечная точка токена". А чего тогда не перевести "UserInfo endpoint" как "конечную точку информации пользователя"? Почему оставили "конечная точка UserInfo"?

В чем смысл буквального перевода английских слов на русский? Ну ладно "токен" или "инсайдер". Они уже прижились и вполне себе самодостаточно. Но "нативное приложение", "дампер", "бэкдор"?.. Это в разговорной речи они приемлемы, но не в стандарте, которым потом будут пользоваться по всей стране.

И почему нельзя при использовании терминов, посмотреть на уже принятые стандарты с разделами по терминам? Почему термин "атака"из нового СТО БР ФАПИ.СЕК-1.6-2020 отличается от определений из документов ФСБ? И это если не вспоминать упомянутую выше проблему с тем, что в проекте ГОСТа по ГосСОПКЕ этот же термин отличается и от ФЗ-187, и от уже принятых НПА ФСБ. Ну ладно... Я могу понять, когда регуляторы конфликтуют между собой и им недосуг читать документы "конкурентов" и синхронизироваться с ними. Но свои-то документы надо знать? Почему в новом СТО термин "аутентификация" отличается от этого термина в ГОСТ 57580.1? Да, понятно, что его взяли из свежего ГОСТа Р 58833-2020 по идентификации и аутентификации (а могли бы и из ГОСТ Р 53632-2009). Но почему-то не привести и ГОСТ 57580.1 к единому терминологическому аппарату (а там и не только терминологию, но и некоторые формулировки бы утрясти)? Кстати, термин "аутентификация" в ГОСТ 57580.1 взят из РД Гостехкомиссии 1992-года, который, вроде как никто и не отменял официально.

И вот таких примеров с терминологией по ИБ у нас в нормативке вагон и маленькая тележка. И что с ней делать, фиг разберешься. Регуляторы, похоже, не особо хотят создать единый глоссарий терминов и использовать его в своих документах. Даже один регулятор внутри себя этого не особо хочет. А это уже кризис. Или не кризис? Или п...ец, как говорится в прекрасном фильма "О чем говорят мужчины"?

Подробнее…

Вопросы к ИБ-регуляторам по поводу коронавируса

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

• Для субъектов КИИ ФСТЭК выпустила рекомендации (письмо ФСТЭК от 20 марта №240/84/389) об обеспечении безопасности объектов КИИ при реализации дистанционного режима исполнения должностных обязанностей работниками субъектов КИИ. Кстати, какова юридическая сила этого письма по сравнению с тем же 235/239-м приказами?
• Схожие, но почему-то дспшные, рекомендации (письмо ФСТЭК от 20 марта 2020 г. №240/22/1204дсп) о мерах защиты информации, принимаемых в информационных системах, в целях минимизации рисков возникновения дополнительных угроз безопасности информации при осуществлении удаленного доступа их работников, ФСТЭК направила в ФОИВ и подведомственные организации.
• НКЦКИ также 20 марта опубликовал уведомление об угрозах безопасности информации, связанные с пандемией коронавируса.
• 23 марта и Банк России опубликовал свои собственные рекомендации по организации работы соответствующих сотрудников вне зависимости от того, работают они из офиса или удаленно в условиях распространения коронавируса.

Даже Верховный Главнокомандующий у нас на удаленке

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

Я, опираясь на некоторое знание нормативных документов регуляторов, попробовал мысленно применить их в условиях удаленной работы и у меня сразу возник ряд вопросов, которые пока остаются без ответа:

1. ФСТЭК при оказании услуг мониторинга ИБ требует, чтобы у SOC было свое помещение и своя соответствующая требованиям ИБ информационная система. В условиях перевода на удаленку работников SOC, как выполнить это требование? Не пора ли все-таки перестать привязывать деятельность по ИБ к ее физическому местоположению и допустить существование виртуальных и мобильных SOCов?
2. Аналогичный вопрос и к центрам ГосСОПКИ. Насколько возможно обеспечение их функционирования из дома?
3. Многие работники, находящиеся на удаленке и работающие не только с корпоративных, но и личных устройств, имеют доступ к персональным данным, тем самым расширяя границы своих ИСПДн. Как ФСТЭК и Роскомнадзор рекомендуют вести себя операторам ПДн в таких ситуациях? Надо ли пересматривать требования по ИБ, установленные 21-м приказом ФСТЭК, или заново отправлять обновленное уведомление в РКН?
4. РКН вообще единственный не выдал никаких рекомендаций, кроме работы с тепловизорами при измерении температуры и новостей о том, что возможен фишинг (и тут) и спам, паразитирующий на теме коронавируса (без примеров и тем более индикаторов компрометации). А мне, например, интересно было бы посмотреть на рекомендации, связанные с получением согласий на обработку ПДн при дистанционной работе.
5. ЦБ и ФСБ (а в ряде случаев и ФСТЭК) настойчиво рекомендуют использование сертифицированных СКЗИ. Как выполнить это требование в условиях дистанционной работы? Не с технической точки зрения, а с точки зрения всех регламентов, формуляров, инструкций (той же 152-й) и т.п.? Это не говоря уже о том, что число мест, в которых ведется работа с применением СКЗИ существенно возросло и не потребует ли это внесения изменения в лицензию ФСБ на деятельность, связанную с шифровальными средствами?
6. Произойдут ли какие-то изменения в части ЕБС? Как с точки зрения съема биометрических данных (например, рекомендация приостановить эту деятельность), так и с точки зрения выполнения всего спектра нормативных и нормативно-правовых актов, связанных с работой ЕБС. В условиях пандемии выполнить их все достаточно затруднительно.
7. Есть подозрение, что в условиях пандемии и разработчикам средств защиты, и разработчикам финансового ПО, которое должно пройти оценку соответствия по требованиям ФСТЭК и Банка России, будет сделать это затруднительно. И начало лета, установленное обоими регуляторами (ФСТЭК - в части крайнего срока обновления сертификатов; ЦБ - в части отсрочки проверки), как мне кажется, становится уже нереальной датой для выполнения соответствующих требований. Будут ли смещать этот срок?
8. Как выполнять аудит внешними силами по требованиям ЦБ. Многие сидят дома и боятся высунуть нос на улицу. Можно ли проводить аудит дистанционно? Как удостовериться в его честности? Можно ли отсрочить проведение аудита (именно аудита со стороны финансовых организаций, а не проверок со стороны регулятора)? Если чуть расширить этот вопрос, то как вообще можно дистанционно убедиться в выполнении требований по оценке соответствия в условиях текущей нормативки? Если никак, то надо ли ее менять или  временно отложить ее применение?
9. Можно ли проводить оценку уровня доверия и вообще сертификационные испытания по требованиям ФСТЭК из дома? Как, например, читать дспшные требования к уровням доверия, если ты находишься на удаленной работе? Это вообще возможно (думаю, что нет)?
10. Как утверждать/заверять решения совещаний, проводимых дистанционно с помощью различных сервисов телеконференций? Как организовывать работы всяких комиссий, упоминаемых в нормативных документов регуляторов, например, комиссии по категорированию объектов КИИ? А если смотреть шире, то как вообще дистанционно выстраивать процессы, завязанные на бумажный документооборот (всякие согласования, утверждения, журналы и т.п.)? Причем это вопрос не только к тем, кто выполняет требования регуляторов, но и к тем, кто их проверяет.
11. Рекомендации по применению УКЭП при дистанционной работе.
12. Надо ли обновлять контакты лиц, отвечающих за ИБ или за обработку ПДн, которые собирали регуляторы в рамках выполнения своих обязанностей?

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

ЗЫ. Хорошо хоть категорирование объектов КИИ все уже закончили... ну или должны были закончить еще в прошлом году :-)

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

Подробнее…

Что я жду от конференции ФСТЭК и от РусКрипто?

Уже по традиции февраль стал месяцем, в котором проходит два мероприятия главных регуляторов по ИБ - ФСТЭК России и Банка России. Первый проводит свою юбилейную, уже десятую конференцию "Актуальные вопросы защиты информации". Думаю, что юбилей вряд ли будет как-то с помпой отмечаться, но контент, который должен будет представить регулятор, представляет, как и обычно, интерес. Учитывая, что на вчерашнем Инфофоруме уже было выступление Лютикова В.С., который высказался по 3-м ключевым направлениям - КИИ, сертификация и проблема кадров. Именно последняя тема, озвученная (на 45:40 мин) заместителем директора ФСТЭК, на последнем SOC Forum, вызвала бурную дискуссию в соцсетях. В программе конференции 12-го февраля этой темы нет, но зато чуть ли не половина докладов будет посвящена вопросам сертификации средств защиты информации по введенным недавно требованиям (тут и 55-й приказ, и требования по доверию, и планы по развитию БДУ).

Возможно будут озвучены в очередной раз планы по выпуску и разработке новых РД к средствам защиты, тем более, что те же требования к СУБД, упомянутые несколько лет назад, так и не появились, а с тех пор разрабатывались также требования, как минимум, к средствам отражения DDoS-атак. Я "пробежался" по прежним выступлениям регулятора и посмотрел на его обещания/планы в части выпуска новых требований к средствам защиты. Видно, что от года к году аппетит регулятора снижался и если в 2016-м году и ранее ФСТЭК хотела охватить своими требованиями все средства защиты, которые могут реализовывать меры из 17/21/31-го приказов, то в 2017-м году в планы попали только три документа, а в прошлом году новых документов вообще не обещали - только обновление. Правда, даже этого, не говоря уже о новых документах, отрасль не дождалась.

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

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

ФСБ в феврале нас не радует. Ее месяц - ноябрь, когда представители НКЦКИ рассказывают про тематику ГосСОПКИ на московском SOC Forum. Другие мероприятия они не жалуют, исключая, пожалуй, РусКрипто (и СТСrypt). Раньше, покойный Кузьмин А.С. выступал на РусКрипто и делал программный доклад о перспективах регулирования криптографии в России, а затем его тему подхватывали другие сотрудники ФСБ. Последние годы я не помню схожих докладов от руководства 8ки (а сейчас оно еще и поменялось снова). Но в любом случае, судя по программе РусКрипто, которая пройдет в марте, там можно будет узнать позицию регулятора и по теме, связанной с новым законом об электронной подписи, и про квантовую (и, возможно, постквантовую) криптографию, и про криптографию в IoT и транспорте, и про криптографию в энергетике и финансовой отрасли, и т.п. Я планирую выступать на РусКрипто с докладом "Эволюция систем управления идентификационной информацией" (про MFA, биометрию, мультиоблачную стратегию, идентификацию устройств и т.п.).

Подробнее…

Обзор 281-го приказа ФСБ по порядку установки средств ГосСОПКИ

Еще один появившийся на прошлой неделе приказ ФСБ касается правил установки и эксплуатации средств ГосСОПКИ. Эти правила достаточно просты:

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

Однако гораздо более интересен вопрос о том, что же такое средства ГосСОПКИ? Например, согласно 196-му приказу об утверждении требований к средствам ГосСОПКИ под это понятие попадают и SIEMы, и сканеры безопасности, и системы обнаружения вторжений, и SOAR/IRP и т.п. Значит ли это, что на установку всех этих решений надо получать согласие ФСБ, без которого их установка будет признана незаконной и за это можно будет "присесть" на срок до десяти лет лишения свободы? В пятницу в одном из чатиков была длинная дискуссия на эту тему, по результатам которой, мы так и не пришли к единому пониманию ибо практика общения с регулятором не бьется с его же требованиями. И вот почему.

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

Отсюда вытекает простой вывод "силы и средства ГосСОПКИ" и "средства защиты и подразделения по ИБ субъекта КИИ", хоть и схожи по смыслу, но являются разными сущностями. При наличии у вас значимых объектов вы обязаны выполнять требования ФСТЭК, описанные в 235-м и 239-м приказах регулятора. Вы должны регистрировать события (SIEM), искать и устранять уязвимости (сканеры), обнаруживать вторжения (СОВ/СОА), управлять инцидентами (IRP/SOAR) и т.п. И это все вы делаете по требованиям ФСТЭК, которая хоть и установила требования к средствам защиты, но достаточно свободные и исполнимые.

А когда же тогда надо устанавливать средства ГосСОПКИ? Согласно закону субъект КИИ это делает по своему желанию (в отличие от ряда госорганов, которые это делают по требованию), если таковое у него возникнет. Я не знаю, в каких случаях такое желание может возникнуть, так как требования ФСБ по этим средствам (196-й и 281-й приказы) загоняют в достаточно жесткие рамки ограничений, которые не так просто и выполнить.

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

Вроде бы на этом, можно было бы и завершить этот обзор 281-го приказа и экскурс в ГосСОПКУ, но в уже упомянутом выше чатике, в процессе дискуссии была озвучена очень интересная мысль о том, что НКЦКИ сегодня согласовывает центрам подключения к ГосСОПКЕ даже если их инструментарий не соответствует требованиям 196-го приказа и, например, может быть модернизирован только только иностранными организациями и имеет гарантийную поддержку от иностранных организаций (а это запрещено 196-м приказом). Я не то, чтобы против такого подхода, даже за. Просто такое вольное прочтение своих же приказов опять приводит к неоднозначностям, что не есть хорошо.

Подробнее…

Обзор 282-го приказа ФСБ по порядку информирования ФСБ об инцидентах

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

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

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

Информирование НКЦИ осуществляется в соответствии с утвержденными НКЦКИ форматами представления информации. Утверждены ли эти форматы? Где они опубликованы? Ответов на эти вопросы у меня нет.

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

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

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

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

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

Подробнее…

Как "дочкам" иностранных компаний обмениваться инцидентами с штаб-квартирами?

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

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

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

Учитывая, что в НКЦКИ никто так ни разу и не обратился по поводу разрешения на передачу данных зарубеж, регулятор вполне очевидно негодует и грозит карами (до двухсот тысяч рублей за нарушение). И вот тут возникает несколько моментов, на которые я хотел бы обратить внимание:

1. Из пунктов 11-12 не вытекает, что получать разрешение НКЦКИ надо на каждый инцидент и вроде бы можно получить его один раз. Но п.15 говорит о том, что НКЦКИ принимает решение по каждому инциденту отдельно.
2. Про оперативность реагирования можно забыть. НКЦКИ берет 24 часа на принятие решения об отправке данных об инциденте зарубеж и еще 12 часов на то, чтобы переправить вам ответ из-за рубежа. Итого 36 часов. Оперативно, ничего не скажешь :-(
3. Дальше больше. Взаимодействие с иностранными организациями ведется на... иностранном языке. При это взаимодействие с НКЦКИ ведется на русском языке. И возникает вопрос, кто будет осуществлять перевод информации об инциденте? Например, у нас в Cisco (хотя мы и не являемся субъектами КИИ) информирование об инцидентах ведется только на английском языке и во всех системах тикеты заводятся на английском (интересно, в азиатских компаниях на каком языке?).
4. Банк России, активно стоящий на страже интересов вкладчиков, подписал соглашение с рядом Нацбанков СНГ о взаимном обмене информацией об инцидентах, например, с Арменией. Так вот получается, что ФинЦЕРТ является тоже нарушителем требований ФСБ, так как он передает данные своим коллегам в Армении (а также в ряде иных государств) напрямую, минуя НКЦКИ.
5. У международных платежных систем (например, у Visa) существует требование об уведомлении об инцидентах в отношении компрометации данных платежных карт. Насколько я помню, схожее требование есть у SWIFT.
6. Дальше больше. Информация об инциденте от субъекта КИИ его зарубежному "визави" передается не субъектом, а НКЦКИ в формате, установленным НКЦКИ. Пока эти форматы публично нигде не описаны и соответственно на повестке дня возникает простой вопрос. А как зарубежная организация сможет принять данные на русском языке да еще в формате, который нигде не описан и, вероятно, не совпадает с тем, что используется на предприятии за пределами России? Вы пробовали, будучи дочкой иностранной организации, получить документы ФСБ официальным путем? Ооооо, это я вам доложу та еще эпопея.
7. Наконец, представьте себе, что вам от АНБ приходит информация об инциденте у вас внутри? Представили? Отложим в сторону эмоции. Вы вообще готовы к принятию такой информации извне (даже если отбросить в сторону репутацию нашей спецслужбы в мире)? К принятию IOCов да, но к карточкам с описанием инцидентов? Тут тоже есть сомнения, что процессы многих организаций вообще учитывают возможность приема данных об инцидентах извне, по внешним каналам. Да и чисто технически не совсем понятно, как это будет происходит.

Какой же ответ можно дать представительствам иностранных компаний, которым не повезло стать субъектами КИИ? Чего я не буду советовать:

• Скрывать факт передачи инцидентов зарубеж.
• Пытаться уйти от попадания под КИИ.
• Путем "правильного" категорирования прийти к ситуации с отсутствием значимых объектов (на взаимодействие с ГосСОПКОЙ это все равно не влияет - уведомлять надо об инцидентах на любых объектах).

Что же тогда делать? Я бы посоветовал несколько вариантов:

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

ЗЫ. У Валерия в заметке приводится интересный кейс с наказанием организации, которая опубликовала на сайте определенный материал, который не должен был распространяться за пределы РФ. Ну дальше можно фантазировать в меру своей испорченности :-(

Подробнее…

Техническая защита персональных данных. Как соблюсти GDPR и ФЗ-152 (презентация)

Вчера я по приглашению выступал в рамках московского GDPR Day, на котором меня коллеги из Б-152 попросили разбавить рассказы юристов о мерах по защите прав субъектов ПДн экскурсом в технические меры по защите ПДн и насколько можно совместить требования 32-й статьи GDPR и 21-го приказа ФСТЭК, разработанного во исполнение ФЗ-152. Получилась вот такая презентация:

Техническая защита персональных данных. Как соблюсти GDPR и ФЗ-152 from Aleksey Lukatskiy

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

Подробнее…

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

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

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

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

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

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

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

Подробнее…

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

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

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

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

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

Подробнее…

Перечень регуляторов по КИИ и процессов, за которые они отвечают

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

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

С требованиями по ИБ вроде все ясно - основным застрельщиком является ФСТЭК, а в зависимости от сферы деятельности, могут быть добавлены и иные защитные меры. Банки должны выполнять требования ЦБ, госы - требования 17-го приказа, операторы связи - отсутствующие требования Минцифры.

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

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

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

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

ЗЫ. Возможно в каких-то аспектах и ошибся, но вроде как перепроверил несколько раз по существующим и планируемым НПА.

Подробнее…

Можете работать руками или на счетах? Значит у вас нет значимых объектов КИИ

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

Секция по цифровой экономике меня и порадовала и огорчила одновременно. Порадовала она тем, что на ней выступали представители регионов, которые задавали закономерные вопросы о том, почему им приходится тратить на непонятные требования по безопасности сотни миллионов рублей и стоимость защиты информационных систем выходит выше, чем стоимость самих информационных систем. И почему, например, муниципалы только-только установили у себя VipNet'ы 3-й версии, а тут приходит указание заменить все на 4-ую. Министры региональной информатизации задаются закономерным вопросом - что такого изменилось в мире, что надо срочно и в обязательном порядке переходить на новую версию? Угрозы стали серьезнее? Алгоритмы стали быстрее и эффективнее? Не было ответа, так как, и это меня удручало, чиновники не пришли на секцию. Что касается секции по импортозамещению, то она была похожа как две капли воды на все остальные секции - импортозаместители говорили каждый за себя и ничего конкретного :-(

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

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

Из субъектов КИИ на секции присутствовали ИВЦ питерского РЖД, питерский метрополитен и ДИТ Москвы. У ИВЦ прозвучало сначала очень революционная идея, что у них после оценки оказалось, что объектов КИИ нет вообще. В процессе дискуссии выяснилось, что позиция ИВЦ базируется на простом факте - если нарушение работы информационной системы не сказывается на выполняемых ИВЦ задачах и они могут быть выполнены "вручную", то данная информационная система не является объектом КИИ (думаю, что все-таки речь идет о значимом объекте, а не просто об объекте). Очень интересная, но и понятная позиция. У метро подход оказался схожий. А вот у ДИТ Москвы (выступал Валерий Комаров) иная проблема - они не являются обладателями/владельцами/заказчиками информационных систем, используемых в Москве, - они всего лишь их оператор и на них требование по категорированию не распространяется.

Из зала была поднята тема лицензирования деятельности по защите для субъекта КИИ. Я заранее, на основе своей заметки, подготовил табличку и хотел ее обсудить с двумя регуляторами, но увы, НКЦКИ не пришел и поэтому их позиция (особенно по последнему пункту) осталась неозвученной. А ФСТЭК подтвердил правильность таблицы по их направлению. Кстати, представитель ФСТЭК также упомянул, что сейчас оперативно готовится (все-таки) единая методика моделирования угроз, которая будет применяться для ГИС, АСУ ТП, КИИ и других типов защищаемых по требованиям ФСТЭК объектов. Ждемс...

Вопросы к НКЦКИ остались без ответа, но тут может помочь презентация их представителя, прозвучавшая днем ранее в Москве.

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

Что еще прозвучало интересного на мероприятии? Тезисно я бы отметил следующее:

• питерское метро ориентируется в первую очередь на встроенные механизмы защиты и планирует выполнять 239-й приказ именно ими - в наложенных средствах защиты они не нуждаются
• ДИТ и Конфидент считают, что рынок отечественных решений ИБ вполне себе развит и можно выполнить требования 239-го приказа целиком на отечественных решениях (ну не знаю, я скептично отношусь к такой позиции).
• РТК-Solar рассказал, что НКЦКИ не требует, чтобы SIEM на стороне центров ГосСОПКИ были только отечественного производства. Интересно, в проекте приказа НКЦКИ было написано немного другое. Может и правда поменяют? Хотя РТК-Solar, использующий в своем SOCе три разных SIEM (Arcsight, QRadar и MaxPatrol), для субъектов КИИ применяет отечественное решение (может все-таки готовятся к негативному развитию событий?).
• Также РТК-Solar рассказал, что НКЦКИ рекомендует не арендовать SIEMы (например, в рамках аутсорсингового SOC), а покупать свой и ставить его себе на баланс, и хранить логи у себя локально.

Вот такие новости. Может кому-то будет что-то внове.

Подробнее…