29.3.21

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

Если мне не изменяет память, то в одном из романов Айзека Азимова из серии про Академию (она же "Фонд", она же "Основание") был фрагмент о том, что речь галактического чиновника прогнали через специальный алгоритм оценки осмысленности речи, чтобы понять, что важного было сказано за всей той канцелярщиной, которой так изобилует речь государевых мужей. И, о, ужас, оказалось, что несмотря на многочасовую речь, уровень ее осмысленности был равен нулю. Я раньше думал, что это такой красивый литературный ход, пока не столкнулся с различными технологиями 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. На сайте проекта упомянуты все используемые формулы, адаптированные к русскому языку.

16.3.21

Список идей для штабных киберучений

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

Фрагмент сценария с киберучений "Зомби атакуют"

Итак список идей для сценариев выглядит таким образом:

  • Утечка важной для бизнеса информации (например, планов поглощения и слияния или планов выпуска новой продукции)
  • Нарушение контрактных обязательств из-за действия шифровальщика
  • Инициация конкурентами проверки со стороны регулятора
  • Шантаж со стороны мошенников/хакеров
  • Санкционная тематика (отключение средства защиты или его обновления)
  • Внезапная публикация в СМИ информации об инциденте (да, если вы за 4 часа не среагировали, то вы проиграли эту информационную битву)
  • Массовое заражение шифровальщиком, включая цифровую АТС и почтовый сервер
  • Злой айтишник
  • Фишинг от имени руководства компании
  • Сервер компании заражен ПО для майнинга
  • Инцидент на новогодние праздники

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

Возьмем, к примеру, сценарий "Злой айтишник". Он может выглядеть по-крупному из следующих шагов:

  1. Знающий о своем увольнении системный администратор устанавливает закладки на все критичные сервера (или разработчик это делает в отношении ключевых компонентов разрабатываемого ПО).
  2. После увольнения бывший админ (разработчик) входит в ИТ-системы бывшего работодателя и крадет информацию, нарушая целостность всех баз данных и их резервных копий.
  3. Сисадмин находит на черном рынке покупателя на украденную информацию и продает ее.
  4. Покупатель требует выкуп; иначе угрожает опубликовать данные в СМИ. СМИ все равно узнают о данном шантаже и публикуют новость об этом.
Обратите внимание, задание правильных вопросов на каждом из 4-х этапов позволит прокачать как технические моменты (сбор артефактов и доказательств противоправной деятельности нарушителя или необходимость отключения учетных записей увольняемых сотрудников и контроль их наследия), так и организационные (взаимодействие со СМИ или анализ Darknet) и юридические (возбуждение уголовного дела и предоставление юридически значимых доказательств).

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

Фрагмент сценария с киберучения на "Магнитке" в феврале 2021

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

Но как вы понимаете, это только часть задач при организации киберучений. О других я еще напишу в блоге, а кроме того, о них мы поговорим в рамках выделенной сессии на Antifraud Spring Russia'2021 28 апреля, которая будет посвящена киберучениям. Ну а чтобы прокачаться перед ней, можно посмотреть уже упомянутый ранее эфир AM Live.

15.3.21

Список значимых отечественных мероприятий по ИБ в 2021-м году

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

Итак, на текущий момент известно о следующих очных мероприятиях:

Вот такой список. Очевидно, что он будет пополняться, так как в нем отсутствуют финальные мероприятия года - SOC Forum и Antifraud Russia, но их даты, скорее всего, станут известны позднее, по мере определения эпидемиологической ситуации. Кроме того, мне известны планы по запуску еще нескольких конференционных проектов, которые могут стать знаковыми и повторяющимися для России, но говорить о них пока рано. Однако, как только сведения о них станут доступны, я сразу внесу их в список.

12.3.21

Краткий обзор новой методики оценки угроз ФСТЭК

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

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

  1. Методика чего? Оценки? Определения? Моделирования? Постоянно перескакивают с термина на термин, что вводит в заблуждение. На суть не влияет, но уже напрягает.
  2. Методика обязательна для всех поднадзорных ФСТЭК организаций, так как распространяется на все объекты защиты - ИСПДн, ГИС, ЗОКИИ, АСУ ТП, ИС оборонки. Разве что станки с ЧПУ (не из оборонки) не затрагивают, хотя у ФСТЭК есть требования по их защите.
  3. В документе отсутствует переходный период и вопрос, как быть если модель угроз сейчас на согласовании в ФСТЭК, никто ответить не может. Даже сам регулятор. Надо переписывать модель (и тратить бюджетные средства на это) или нет?
  4. Упоминаемый по тексту методики STIX - это язык описания угроз, а не их база/источник, как CAPEC и т.п.
  5. Без автоматизации вся это методика мертворождена - не взлетает из-за количества задач, которые нужно реализовывать. ФСТЭК обещала средство автоматизации, но пока его нет. Ждем... 
  6. Методика оторвана от БДУ. ФСТЭК обещала его поменять, но пока это тоже не сделано. Поэтому и нужен был переходный период. 
  7. ФСТЭК обязывает реализовывать не дискретный процесс моделирования (раз в три года перед аттестацией или вообще никогда после сдачи толстого фолианта), а непрерывный. Поэтому без автоматизации вообще никак. И это средство автоматизации должно будет подгружать новые данные об угрозах и т.п. с сайта регулятора. Поддержание модели угроз в актуальном состоянии в свою очередь ставит вопрос о непрерывной переаттестации, что требует разъяснений от регулятора и бюджетов от аттестуемых (кто ж бесплатно это будет делать).
  8. В документе не говорится, но обновлять надо не реже одного раза в год (так часто либо НПА ФСТЭК меняются). А уж новые уязвимости, влияющие на возможности реализации угроз, а также новые тактики, появляются еще чаще. Так что процесс это не одноразовый. 
  9. Видимо не успели, но в идеале было отлично видеть привязку к разработанным проектам/методичкам оценки показателей значимости при категорировании ОКИИ. По сути подход же не меняется.
  10. Общая проблема документов ФСТЭК - их авторы никогда не пропускают себя через них. Вот что мешало ФСТЭК проект новой методики натянуть на какую-либо систему и сделать частную модель угроз? Был бы отличный пример работы документа и многие вопросы снялись бы автоматически. Причем ФСТЭК же по ее словам это уже делала. Когда на конференции ФСТЭК в рамках ТБ-Форума Д.Н.Шевцов рассказывал о новых требованиях к средствам защиты дистанционной работы, он говорил, что были проанализированы все угрозы для такого режима работы. Почему бы не опубликовать эту модель угроз, соответствующую новой методике? Все же работы уже проведены. Все бы спасибо сказали.
  11. Нарушитель актуален, если его действия МОГУТ привести к негативным последствиям и рискам (видам ущерба). Не получается ли так, что спецслужбы иностранных государств должны включаться всеми в список актуальных? Да и вообще, по этой логике любой тип нарушителя является актуальным. А самое главное, зачем мне их оценивать, если сценарии реализации угроз с ними никак не связаны?
  12. К делению нарушителей на внутренние и внешние те же вопросы. Если спецслужба может привлекать внутреннего нарушителя, то смысл делить всех на внешние и внутренние? Разработчик ПО по методике - это внутренний нарушитель. Звучит не очень логично, но по сути верно. Но почему сотрудник АНБ, который реализует фишинг против работника жертвы, внешний нарушитель? А если он внедрил закладку на этапе разработки или поставки (вспомним SolarWinds)? Почему оператор связи - это внутренний нарушитель, а поставщик обеспечивающих услуг (например, DNS) - внешний? В конце концов, почему разработчик ПО - это нарушитель со средними возможностями, а спецслужба - с высокими? Разработчик ПО имеет больше возможностей и знаний по внедрению вредоноса в свою продукцию, чем спецслужба. А почему APT, которая использует украденный арсенал кибероружия ЦРУ, - это базовые повышенные возможности? А почему спецслужба, привлекающая АРТ к своей деятельности, - это максимальные возможности? А главное, опять, зачем это все, если мы никак это не используем далее?  
  13. Классификация возможностей нарушителя Н1-Н4 приводит к путанице с моделями нарушителей Н1-Н6 ФСБ. Зачем это было сделано?
  14. Классификация источников угроз противоречит ранее выпущенным ГОСТам ФСТЭК и в методике вообще нет отсылок ранее принятых ТК362 ГОСТов. Зачем их тогда принимали? Они же классифицируют и систематизируют многие вопросы, рассматриваемые в методике, - нарушителей, источники угроз, мотивы и т.п.
  15. Из методики странным образом исчез вопорос ПОЧЕМУ. КТО может хакнуть (то есть нарушитель) у нас определяется. КАК хакнут (методы) - тоже. КУДА хакнут (интерфейс) - присутствует. ЧТО хакнут (компоненты) -тоже есть. А ПОЧЕМУ хакнут (мотивация) исключили. То есть нам все равно, могут нас вообще захотеть атаковать или нет? И мы исходим только из теоретической возможности такого взлома? Ведь была же раньше попытка сослаться на ГОСТ 18045 с его потенциалом нападения. И при оценке безопасности ИТ-продуктов эта концепция используется. А вот сейчас про нее забыли :-(
  16. Также из риск-ориентированной методики убрали понятие вероятности реализации негативного события. То есть ущерб (негативные последствия) мы оцениваем, а их вероятность - нет, принимая ее равной единице? С какого перепугу мы уравниваем вероятность подцепить шифровальщика, атаку китайских хакеров и падение метеорита?
  17. Очень мне не хватило примеров. Это ж методичка - ее не надо утверждать в Минюсте. Почему бы не добавить понятности и разбавить документ множеством примеров? Стало бы в разы все понятнее.
  18. Хорошо, что есть деление на угрозы возможные и актуальные. Но дальше все плохо - наличие хотя бы одного сценария делает угрозу актуальной. Тогда разницы между возможными и актуальными нет, так как мне сложно представить угрозу, для которой не было в современной организации хотя бы одного сценария реализации. А значит мы опять все возможные угрозы делаем актуальными, не имея возможности их сократить :-(
  19. Почему на этапе создания оцениваемой системы должен быть определен хотя бы один сценарий (TTP)? А на этапе эксплуатации множество? И сколько это - множество?
  20. Определили сценарии (правда, непонятно как - этот раздел прошлого проекта удалили) и что? Обрыв методики. Как выбрать меры по нейтрализации угроз?
  21. Как влияет определяемый уровень возможностей нарушителя, его категория, виды, риски и т.п. на определение актуальных угроз? НИКАК! Все равно все скатывается к определению возможных сценариев угроз, которые непонятно как связать с нарушителями и их возможностямяи. Мы проделали кучу работы, результаты которой мы не используем и которые ни на что не влияют.
  22. Опять тот же вопрос про утечки. Это пример воздействия на ресурсы и компоненты или пример негативного последствия? Оно используется и там и там. Отказ в обслуживании - это тоже вид воздействия; хотя логичнее было бы его считать негативным последствием.
  23. Проблема с тактиками осталась. Зачем этот неполный список оставлять в приложении к методике? Его же таким и будут использовать и расширить его будет нереально. Разместите на сайте ФСТЭК, как ЦБ сделал со списком инцидентов. И обновляйте, когда хотите. А почему нет ссылок на нумерацию MITRE ATT&CK? Ведь эту матрицу брали за основу. Ну и сделали бы ссылки, чтобы было удобнее. Ну или перевели бы целиком (отрасль бы спасибо сказала). За год уж точно можно было бы НИР для ГНИИ ПТЗИ заказать и все сделать (кстати, выполнение НИР делает ГНИИ ПТЗИ субъектом КИИ или нет?).
  24. На сайт регулятора можно было и все остальные приложения с перечнями (ущерба, нарушителей и т.п.) вынести. А по тексту просто сослаться, что это пример, но последние версии лежат там-то. Ведь они не требуют согласования с Минюстом и можно их пополнять в любое удобное время. А если эти перечни еще сделать в машинно-читаемом формате, то можно было и в средство автоматизации их подгружать. Было бы полезно и удобно.
Вот таких две дюжины вопросов к утвержденной методике. И ведь большая их часть мной задавалась и формулировалась еще год назад (части 1, 2, 3, 4, 5 и 6). Посчитали несущественными или неправильными? Ну может быть - не мне судить и не мне за регулятора решать, как ему делать свою работу. Но вопросов ФСТЭК огребет получит теперь немало - и по почте, и на своих мероприятиях. Не умеет регулятор просчитывать последствия своих действий и моделировать их. А вроде должен, если других учит в своих методических документах. Ну да ладно. Жизнь нас рассудит, а правоприменительная практика покажет, кто был прав и являются ли описанные выше нюансы значимыми или нет. В любом случае рынок услуг по моделированию угроз только вырастет - то есть задачу улучшению экономического положения лицензиатов регулятор точно своим документом решит. А это уже немало.

26.2.21

Дистанционное рабочее место - новое направление регулирования ФСТЭК

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


  1. ФСТЭК признает и я склонен с ней согласиться, что существующие нормы 17-го приказа (а также иных приказов) ФСТЭК вполне себе допускают удаленную работу и позволяют защитить ее в рамках действующей нормативной базы. Но зачем-то, вдруг, появляется требование о том, что удаленный доступ должен быть организован только со специальных технических решений, к которым надо установить требования.
  2. ФСТЭК, трезво оценивая нехватку бюджета у госорганов и понимая, что каждому чиновнику выдать по служебному компьютеру для работы из дома невозможно, предлагает использовать концепцию LiveUSB, то есть специальной защищенной флешки, с которой можно загружаться и подключаться к ГИС или работать со слежубными документами вне рамок аттестованного помещения и контролируемой зоны.
  3. При этом ФСТЭК считает, что это не может быть любая флешка, на которую установлены сертифицированные средства защиты, а только специальная флешка, сделанная под заказ в соответствие с треваниями по ИБ и стоящая как космический корабль.
  4. На этой LiveUSB, которая должна быть сертифицирована, должны быть реализованы/установлены соответствующие средства и механизмы защиты - доверенная загрузка, ОС, двухфакторная аутентификация, СКЗИ, удаленное управление. 
  5. ФСТЭК разрабатывает сейчас (на финишной прямой) руководящий документ к таким средствам, который будет ориентирован только на разработчиков и испытательные лаборатории. Вот тут у меня, конечно, в очередной раз всплывает вопрос. Понятно, что сделать документ, ориентированный на ограниченное количество участников, проще, чем документ для широкого круга лиц. Но если целью всего этого является именно усиление защиты информации и повышение ее уровня (а вроде именно это декларируется и является целью регулятора), то разрабатывать надо не только требования к средствам, но и требования к процессу безопасной удаленной работы. То есть речь может идти о методическе по безопасной удаленке, которой могли бы руководствоваться все госорганы, уровень квалификации которых не очень высок. И никакое, даже обвешанное сертификатами, средство не способно решить проблему безопасной удаленной работы, если не работать с конечными потребителями, чего ФСТЭК упорно не хочет делать, перекладывая эту головную боль на разработчиков средств защиты.
  6. ФСТЭК планирует внести изменения в 17-й приказ (ЗИС.31) и методичку "меры защиты" в связи с появлением этого РД, но когда это будет сделано, пока непонятно. В выступлении Шевцова Д.Н. прозвучало, что "мы по полгода все регистрируем в Минюсте", а значит ждать нам этих изменений не раньше конца года :-( так как цепочка тут простая. Сначала надо принять РД, потом поправки в 17-й приказ, а потом уже и в методичку внести изменения.
  7. Правда, в методичку внесут изменения явно не скоро. Днем ранее, на секции по безопасности АСУ ТП, Кубарев А.В. сказал, что ФСТЭК планирует (отмечу - давно планирует) разработать универсальную методичку по мерам защиты, которая бы объединяла разъяснение защитных мер не только к 17-му приказу ФСТЭК для ГИС, но и к 21-му (ИСПДн), 31-му (АСУ ТП), 31-му (оборонка), 239-му (ЗОКИИ). И будет это сделано, как было сказано, либо в этом, либо, что реальнее, в следующем году, Очевидно, что работа эта невозможна без синхронизации нумерации и наименования всех защитных мер в приказах ФСТЭК, чего пока не наблюдается. А это за собой тянет внесение изменений во все приказы регулятора, что, как мы помним из выступления Лютикова В.С., в 2021-м году делать не планируется.
  8. В отличии от всех ранее выпущенных РД ФСТЭК, никакого деления на классы защиты/защищенности у средств безопасной удаленной работы не будет. Все требования будут едины и применяться, что к ГИС 3-го класса, что к ГИС 1-го, что к ЗОКИИ 3-го уровня, что 1-го. С одной стороны унификация, а с другой - явное завышение защитных требований и отсутствие дифференциации, которое приведет к росту затрат и невозможности реализации требований ФСТЭК у многих субъектов регулирования. Ровно такая же ситуация была с требованиями по лицензированию мониторинга ИБ, когда ФСТЭК сразу установила требования по аттестации SOC по ГИС1 (и как ряд лицензиатов оказывает услуги мониторинга ИБ с облачного сервиса Microsoft Azure Sentinel мне до сих пор непонятно), мотивируя это тем, что к лицензиату может обратиться организация с ГИС1. Почему нельзя было прописать просто требование, что при мониторинге ГИС у лицензиата должен быть аттестат соответствия SOC уровня ни ниже того, который выдан на систему, отдаваемую на аутсорсинговый мониторинг? Так бы ФСТЭК дала развиваться рынку мониторинга ИБ, не снижая при этом уровня защиты госов. Сейчас ФСТЭК наступает на те же грабли, приравнивая какой-либо региональный банк (как СуКИИ) или районную больницу и корпорации типа Газпрома, РЖД или министерства типа Минцифры или Минфина. Всех под одну гребенку и всем выполнять максимально возможные требования - средства защиты не ниже 4 класса защиты (максимально возможный для "негостайны"). И если выполнение требований этого документа будет обязательным только для госов, то и ладно. Но если такие тревания будут обязательны, например, для субъектов КИИ, то реализовать их будет зачастую невозможно, так как не все приложения можно запустить с LiveUSB, особенно если речь идет об АСУ ТП.
  9. Вообще вопрос установки прикладного ПО на LiveUSB, как мне кажется, регулятором проработан не до конца. С web-приложениями вроде все понятно, но как работать с обычными standalone-приложениями? Ставить их на флешку? А места хватит? А сертифицированная ОС это позволит? А скорости работы с USB 2.0 (пока с этой версией) хватит? Одни вопросы.
  10. Кстати, и еще один вопрос. А как быть с требованиями ФСБ к СКЗИ? Насколько допустима такая схема не совсем понятно. Из проекта приказа ФСБ "Об утверждении требований о защите информации, содержащейся в ГИС, с использованием СКЗИ" у меня сложилось впечатление, что там вообще не учтена дистанционная работа. Еще LiveUSB будет хранилищем для ключей и сертификатов электронной подписи - поэтому надо смотреть, насколько эти флешки выполняют еще и требования ФСБ к средствам ЭП. Ну и скорость работы СКЗИ на слабой аппаратной начинке флешки тоже может стать очередным раздражителем.
  11. Требования будут ДСП. Если кто-то захочет получить к ним доступ после их регистрации, то необходимо сделать официальный запрос в ФСТЭК, но для этого надо иметь лицензию, о чем я уже писал, рассказывая про телемост с Лютиковым В.С. Правда, тут опять возникает вопрос. Если требования только для разработчиков, то как потребителю понять, какие он требования должен выставить к данным средствам? И как он может понять, что было сделано разработчиком в соответствие с закрытыми документами регулятора? 
  12. Интересно, что действующие нормативные документы ФСТЭК запрещают осуществлять удаленный доступ администраторов к ГИС, требуя, чтобы администрирование было только локальным. Останется ли данное требование или его поменяют? Пока непонятно. Вроде как Шевцов Д.Н. упомянул, что изменения внесут, но по срокам см.выше.
  13. Также не до конца понятна ситуация с уже аттестованными системами. Как быть с ними? Требуется ли переаттестация или достаточно проведения дополнительных мероприятий по проверке безопасности дистанционного доступа? Вроде как ФСТЭК говорит о последнем, но судя по вопросам на конференции, и пользователям и самим аттестационным лабораториям не хватает официальных и публичных разъяснений регулятора. 
  14. Интересно, что в рамках выступлений и вопросов неоднократно упоминалась информация "ДСП", то есть служебная тайна. Но на прямой вопрос, когда же хоть кто-то сможет назвать сроки принятия закона о ней, так никто и не ответил. На вопрос Шевцову Д.Н. из зала, как защищать "информацию ДСП" и в соответствие с чем, от представителя ФСТЭК последовал очевидный ответ - "в соответствие с 17-м приказом". Хотя с юридической точки зрения это нонсенс. 17-й приказ никакого отношения к информации ограниченного распространения не имеет - он регулирует защиту ГИС и только. Все всё понимают, но делают вид, что все хорошо :-(
  15. С практической точки зрения у данного подхода есть и еще один нюанс (помимо прикладного ПО) - чтобы загрузиться с LiveUSB необходимо в BIOS указать, что загрузка осуществляется с флешки, а не с жесткого диска домашнего компьютера. Как это объяснить низкоквалифицированным пользователям, не совсем понятно. Особенно при том многообразии домашних компьютеров, которые имеют BIOS/UEFI разных версий разных производителей. А ведь некоторые ПК вообще не имеют такой возможности. С техникой Apple вообще засада. И хотя у многих рядовых служащих нет макбуков, но у чиновников высокого ранга это не редкость. И как быть с ними непонятно. Как и с теми, кто вместо ПК использует планшеты, в которые нельзя воткнуть LiveUSB. Вопрос печати на локальных принтерах тоже остается открытым...
  16. Как мы помним, Минцифра с Минпромторгом, пытаются импортозаместить все госорганы, а к средствам защиты так и вовсе предъявляют требования об использовании отечественной микроэлектроники к определенному сроку. Сейчас, имеющиеся на рынке решения LiveUSB такие требования не выполняют, хотя и заявляют о движении в эту сторону. Это означает, что после переходя на отечественные микроконтроллеры и модули флеш-памяти придется заново проводить сертификацию готового изделия, а заказчикам тратиться на повторную закупку.     

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


Из доклада представителя Минцифры я с удивлением узнал о какой-то новой классификации информационных систем. Были упомянуты медицинские информационные системы и информационных банковские системы 1-го класса защищенности. Что это такое? Тоже самое было и в докладе генерального директора Аладдина Р.Д. Груздева С.Л. Кто у его копипастил (а там не только классификация совпадала, но и некоторые слайды)?

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

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

ЗЫ. Презентацию Шевцова Д.Н. можно посмотреть здесь, а Гурзова К.А. - здесь.

25.2.21

Ответы ФСТЭК на вопросы отрасли. Часть 2-я

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

  1. Статистика категорирования достаточно плачевна - от 1,5% до 50-60% по разным отраслям. И это при условии, что до 1-го сентября 2020 года категорирование должно было быть завершено, в том числе и для предприятий промышленности.
  2. Если изменилась информация о лице, эксплуатирующем ОКИИ, то об этом надо оповестить ФСТЭК в 30-тидневный срок.
  3. Если объект КИИ поменял собственника (продан, сменилась форма собственности, передан на баланс другому предприятию и т.п.), то об этом также надо уведомлять ФСТЭК. Причем уведомлять должны две организации - прежний собственник и новый.
  4. Аналогичная ситуация и в случае выведения из эксплуатации значимых и незначимых объектов - уведомлять ФСТЭК надо как и при любом изменении объекта КИИ.
  5. Если организация принимает решение о переводе незначимого ОКИИ в значимые, то необходимо направить информацию об этом в ФСТЭК, в которой должно быть соответствующее обоснование.
  6. Если у объекта КИИ изменился состав технических средств или применяемых защитных мер, то уведомить об этом ФСТЭК надо в разумные сроки, под которым регулятор понимает 30 дней.
  7. На вопрос о том, надо ли уведомлять ФСТЭК при изменении модели угроз, которая существенно не влияет на категорию значимости ОКИИ, регулятор прямо не ответил, но судя по характеру ответов на схожие вопросы про несущественные изменения в результатах категорирования, уведомлять ФСТЭК все-таки надо.
  8. О любых произошедших изменениях ФСТЭК сама уведомляет НКЦКИ - самостоятельно субъекту ничего писать в ФСБ не нужно.
  9. ФСТЭК обязательно хочет видеть от субъекта КИИ подробные расчеты показателей категорий значимости (для этого и опубликован проект методики по расчету экономического показателя и планируется методика по социальному показателю). Если тот или иной показатель не применим к объекту КИИ, то необходимо обосновать, почему? ФСТЭК прямо заявляет, что безопасники не в состоянии самостоятельно провести такую оценку и требуется участие других подразделений, обладающих знаниями по ценности объектов.
  10. После принятия ПП-452, внесшего изменения в ПП-127, стали возникать инсинууации по поводу сроков категорирования для создаваемых объектов. ФСТЭК считает, что для таких ОКИИ категорию значимости надо закладывать еще в ТЗ/ЧТЗ. То есть к моменту создания объекта его категория уже известна и срок в 12 месяцев из ПП-127 к таким объектам уже не применяется.
  11. ГНИИ ПТЗИ ФСТЭК, как и все подведомственные организации ФСТЭК, выполняют требования ФЗ-187 и подзаконных актов. На конференции "Актуальные вопросы защиты информации" Шевцов Д.Н., отвечая на вопросы из зала, отметил, что ФСТЭК постепенно переходит на отечественное ПО и оборудование, следуя курсу на импортозамещение. Хотя по оговорке было понятно, что денег особо не выделяют.  
  12. Субъекты промышленности задавали вопрос о том, какие показатели значимости к ним применимы, на что последовал ответ, что это зависит от сферы деятельности предприятия. Но, в частности, было отмечено, что социальный показатель применим. Также применим 7-й показатель, если организация участвует в исполнении какого-либо международного договора. 8-й и 9-й экономические показатели применимы также; 9-й так вообще применим к любому объекту КИИ. 11-й показатель применим для экологически опасных производств, а 13-й - для всех организаций ОПК.
  13. Время, в течение которого субъект КИИ должен ждать ответа от ФСТЭК по поводу результатов категорирования, составляет не 30 дней, а 30 дней на рассмотрение + 10 дней на подготовку ответа + неделя-другая на доставку почтой. Фактом внесения данных об ОКИИ в реестром является присвоению ему реестрового номера, о чем вас ФСТЭК должна уведомить. Но если вы считаете, что у вас ЗОКИИ, то не надо дожидаться получения реестрового номера, - можно сразу начинать обеспечение безопасности.
  14. При оценке показателя экономической значимости, при оценке снижения уровня дохода от выполнения деятельности предприятия в результате воздействия на объект КИИ при оценке сценария расчета потерь необходимо рассматривать не среднегодовые потери, а потери в случае успешной реализации конкретного негативного воздействия.
  15. При оценке потерь, наступающих в случае успешной реализации негативного воздействия на объект КИИ, потери часто зависят от возможностей предприятия по локализации и устранению последствий инцидента. ФСТЭК считает, что последствия от воздействия должны учитываться на временном промежутке до момента восстановления плановых показателей (до инцидента). 

Пока все. Часть ответов была раскрыта в самом выступлении Торбенко Е.Б., которое скоро выложат на сайте организаторов. Также ФСТЭК обещала на других своих мероприятия ответить на оставшиеся вопросы. Из интересного также хочу отметить интересную цифру, озвученную Кубаревым А.К. на конференции по защите АСУ ТП в рамках ТБ-Форума. Его спросили, хватит ли у ФСТЭК ресурсов на проверки всех объектов КИИ, число которых по разным выступлениям ФСТЭК разнится от 25 тысяч до полумиллиона? Ответ был нерадостен - ФСТЭК, имея в центральном аппарате всего 200, а в регионах 1000 человек, не сможет ежегодно проверять даже 1% от общего числа объектов КИИ :-( 


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

В заключение хочу отметить, что есть ряд вопросов, на которые регулятор врядли будет отвечать на своих мероприятиях, но ответы на которые хотелось бы все-таки увидеть в том или ином виде:
  1. Когда на сайте ФСТЭК появится вменяемый реестр сертиицированных средств защиты с возможностью фильтрации по классам и типам средств? Да и сам сайт пора бы уже обновить - он как из 90-х годов.
  2. Почему до сих пор не синхронизированы нумерация и названия мер защиты в приказах ФСТЭК?
  3. Почему до сих пор не отменен РД на АС 1992 года, если у ФСТЭК уже совершенно иная классификация ИС? Почему проверяющие ссылаются на ПП-79, в котором есть слова про «автоматизированные системы» и из-за этого вынуждают выполнять требования документа 92-го года.
  4. Как относится ФСТЭК к ситуации, когда средства защиты не покупаются предприятием, а берутся в лизинг или аренду у аутсорсинговой компании?
  5. Выпустит ли ФСТЭК матрицу соответствия "старых" специальностей и новых, утвержденных Минобразованием? Вообще вопрос образования вызвал бурную дискуссию на конференции по защите АСУ ТП в рамках ТБ-Форума. Ведь требования по квалификации специалистов и руководителей по ИБ есть, а как их трактовать до конца никто не знает. Вот у меня специальность по диплому "Прикладная математика" (квалификация "инженер-математик") и хотя у меня было немало предметов, связанных с защитой информации, формально я не могу считаться специалистом по защите информации и мне пришлось бы проходить соответствующие курсы переподготовки. С учетом того, что за последние полтора-два десятка лет у нас не раз менялись ФГОСы по ИБ, названия и номера специальностей, было бы неплохо иметь такую матрицу соответствия (сделать-то ее несложно). Говорят, у ФСБ такая есть.   
ЗЫ. Из интересного: по словам Шевцова Д.Н. именно он в ФСТЭК курирует вопросы импортозамещения. Странно, почему не ИТ-служба? Вообще всегда было интересно узнать, как сам регулятор реализует у себя вопросы информатизации и ИБ и кто за это отвечает у регулятора? Если за импортозамещение отвечает 2-е Управление, то это странновато.

24.2.21

21 тезис с телемоста с руководством ФСТЭК или ответы регулятора на вопросы отрасли. Часть 1-я

17 февраля, в рамках конференции "Кибербезопасность. Наши дни. Промышленные технологии" прошел телемост "Москва-Урал" с участием Виталия Сергеевича Лютикова, заместителя директора ФСТЭК, который отвечал на вопросы, полученные от отрасли. Я вел этот телемост на стороне Урала и позволил себе составить краткое резюме по прозвучавшим ответам. Сразу отмечу, что из почти 70 пришедших вопросов, было отобрано 26, который на мой взгляд были достаточно стратегическими, чтобы задавать их именно Виталию Сергеевичу. На часть тактических и практических вопросов по КИИ позже ответила Елена Борисовна Торбенко, заместитель начальника 8-го Управления ФСТЭК, о чем я еще напишу отдельно. Диалог получился конструктивным, хотя и не на все вопросы были получены четкие ответы, что объяснимо и ниже я попробую про это написать.


  1. ФСТЭК планирует продолжить практику участия в онлайн мероприятиях для донесения своей позиции (в последнее время активно участвовали от ФСТЭК не только Лютиков В.С., но и Кубарев А.В.). Проведение своих собственных мероприятий тоже возможно, но когда, непонятно, - ресурсов не хватает. Хотя мне кажется, что это позволило бы снять остроту многих проблем и наладить диалог регулятора не с узким кругом лицензиатов и экспертов, а с отраслью. Тем более, что это не так уж и сложно. Либо купить недорогой тариф у того же Webinar.ru, либо делать трансляции в Youtube, либо попросить помощи у той же группы Авангард-Медиа, которая и проводила телемост и имеет опыт онлайн-мероприятий (один SOC Live чего стоит).
  2. ФСТЭК думает о возможности выкладывания на своем сайте обучающих курсов по различным вопросам защиты информации для повышения квалификации кадров, которая у нас не очень высокая по словам той же ФСТЭК на многих мероприятиях. Первую попытку попробуют сделать в марте - в рамках курса по динамическому и фаззинг-тестированию ПО, который проводит ФСТЭК. Этот курс планируют записать и выложить либо на сайт самой ФСТЭК, либо на сайт Банка данных угроз (БДУ).
  3. Привлечение экспертов для экспертизы документов никто не отменял и ФСТЭК планирует и дальше привлекать специалистов для такой работы. Однако "массового" привлечения, как это было раньше, или "встреч с блогерами", видимо, не будет. Небольшие группы по несколько человек ФСТЭК считает более эффективным способом, чем собирать по 20-30 экспертов. Основным каналом коммуникаций ФСТЭК видит одностороннее взаимодействие через regulations или через обратную связь на выкладываемые на сайте документы, не требующие оценки регулятивного воздействия. Ну хоть так, хотя именно этот формат, похоже, многих и не устраивает.
  4. Проверки субъектов КИИ начинают со второго полугодия 2021-го года. В плане 5 объектов КИИ. Что за объекты неизвестно и в публичной плоскости эти данные не появятся.
  5. У ФСТЭК уже есть внутренние методики проведения проверок субъектов КИИ. Будут выкладывать их или нет - неизвестно. Но проверяют публичные требования 235/239-го приказов. Сами методики направлены на то, чтобы унифицировать подход и убрать отсебятину на местах, когда сотрудники терорганов ФСТЭК по своему трактуют то или иное требование нормативных актов.
  6. В случае выявления нарушений в рамках проверок передавать данные в правоохранительные и следственные органы ФСТЭК не планирует. Но если от них будут запросы, то никто скрывать результаты проверок не будет. В случае выявления в рамках проверок предпосылок к нанесению ущерба, то данные будут передаваться в НКЦКИ.
  7. Контролем использования отечественного ПО и отечественных средств защиты на объектах КИИ, как и вообще импортозамещением, ФСТЭК заниматься не будет. Они не уполномочены на это. Вообще, сложилось впечатление, что ФСТЭК сама не рада, что их используют для этой задачи. С этим же связано, как мне кажется, и то количество отказов от изменений в 239-й приказ, а также в проекты Указа Президента и Постановления Правительства по импортозамещению. ФСТЭК просто вынуждена делать то, что прилетело сверху.
  8. По истории с РЖД ответ был витиеватый :-) Мол проверка факта проведена - сделаны выводы. Но вообще тема реагирования на такого рода публичные истории она остается открытой. ФСТЭК говорит, что все отслеживается и реагируется, но непублично.
  9. Несмотря на ранее высказанные позиции о том, что объектом КИИ является не любая ИС, АСУ ТП или ИТКС, а только те, которые завязаны на критичные процессы (именно эту позицию ФСТЭК фиксировала в ПП-127), сейчас подход регулятора вернулся к тому, что написано в ФЗ-187, а именно - любая ИС, АСУ или ИТКС является объектом КИИ и подлежит категорированию. Даже если она по итогам категорирования и не будет признана значимым объектом, то все равно процедуры, предусмотренные ПП-127, должны быть проведены в отношении каждой ИС, АСУ или ИТКС. С моей точки зрения, именно этот, один из двух тезисов телемоста, пожалуй, имеет самые серьезные последствия для субъектов КИИ, которым придется пересмотреть результаты уже проведенного категорирования.
  10. Второй имеющий серьезные последствия для отрасли тезис прозвучал при ответе на вопрос о том, где проходит водораздел между средствами защиты информации по 239-му приказу ФСТЭК и средствами ГосСОПКИ по 196-му и 282-му приказам ФСБ. Это еще одна тема, в которой ФСТЭК, похоже, пытаются склонить к позиции, которая им не близка. По крайней мере, сейчас прозвучало, что SIEM, СОВ/СОА, МСЭ, антивирусы, IRP и т.п. вполне могут считаться средствами ГосСОПКИ, а не только средствами защиты, и к ним будут предъявляться не только требования ФСТЭК, но и ФСБ. А требования последние - это полный пушной зверек (это уже моя оценка, не ФСТЭК). Согласно требованиям ФСБ вам придется согласовывать с ФСБ места установки средств ГосСОПКИ, использовать сертифицированные в ФСБ средства защиты, а также вам фактически будет запрещено применять иностранные средства защиты информации.
  11. Изменений ФЗ-187 и ПП-127 в этом году не планируется. Надо дождаться правоприменительной практики и тогда уже оценивать все статьи закона вместе - что работает, а что нет. Как минимум, ФСТЭК видит необходимость поправить терминологию в части того, кого считать субъектом КИИ и что такое объект КИИ (хотят сузить).
  12. Также в этом году нет планов по внесению изменений в 235/239-й приказы, если сверху не прилетит новых указаний, как это было в части импортозамещения.
  13. Оценка соответствия прикладного ПО и средств защиты в форме испытаний или ввода в эксплуатацию может быть проведена самостоятельно субъектов КИИ или привлеченной им компанией, если кто-то из них имеет соответствующую экспертизу. А вот ФСТЭК, в соответствие с своими приказами, проверит протоколы испытаний и были ли установлены соответствующие требования при выборе прикладного ПО или средств защиты и их внедрении. Для меня это осталось достаточно спорным вопросом - как регулятор будет проверять выполнение этого требования и насколько его устроит это выполнение. Думаю и сам регулятор пока не знает этого с практической точки зрения.
  14. Разъяснений от ФСТЭК по тому как проводить оценку соответствия в формах испытаний и ввода в эксплуатацию не будет.
  15. Для проверки уровня доверия прикладного ПО у субъекта КИИ должны быть соответствующие документы, которые имеют отметку "для служебного пользования". ФСТЭК готова ими делиться при условии обоснованного запроса со стороны субъекта КИИ. Я безусловно верю словам замдиректора ФСТЭК, но если мы посмотрим на порядок доступа к документам ограниченного распространения, вывешенный на сайте ФСТЭК, то там четко написано, что для такого доступа нужна лицензия ФСБ на гостайну. Более того, для организаций, не имеющих ведомственной принадлежности (то есть обычные разработчики ПО попадают именно сюда), доступ к таким документам (помимо лицензии ФСБ на гостайну) осуществляется на платной основе и необходимо заключить договор с ГНИИ ПТЗИ ФСТЭК. Ровно такой же процесс (наличие лицензии) был упомянут начальником 2-го Управления ФСТЭК Д.Н.Шевцовым в рамках ТБ-Форума. Так что не все так просто, как говорится в телемосте. 
  16. Вообще ФСТЭК не откажется от подхода к "засекречиванию" своих документов, объясняя это тем, что "у всех так".
  17. Для прикладного ПО может быть выбрана оценка соответствия в форме обязательной сертификации по желанию самого субъекта КИИ и тогда он должен будет найти испытательную лабораторию, которая согласится провести такие работы. И вот тут еще один нюанс возник. Согласно всем последним приказам ФСТЭК (и уходящему 131-му и новому 76-му) проверка уровней доверия возможна только для средств технической защиты информации или средств по обеспечению безопасности информационных технологий. Поэтому формально обычное прикладное ПО оценивать по уровням доверия испытательные лаборатории не могут. Но если перефразировать слова ФСТЭК "если очень хочется, то можно". В общем, надо посмотреть, как все будут выкручиваться из этой ситуации.
  18. Пересматривать уже разработанные модели угроз при условии принятия новой методики моделирования не требуется. Если только речь не идет о модернизации или развитии объекта КИИ.
  19. Банк данных угроз будет переделан в течение ближайших месяцев для соответствия новой методики моделирования угроз. Может быть (сроки неясны) ФСТЭК выпустит и средство автоматизации этого процесса и сделает его бесплатным по аналогии с решением ScanOVAL, которое распространяется с сайта БДУ.
  20. В ближайшее время будет выпущена новая редакция ГОСТа 56939 по безопасной разработке. Кардинальных изменений не будет и проводить повторную оценку его выполнения разработчикам не потребуется. 
  21. И хотя Виталий Сергеевич на ТБ-Форуме "обещал не обещать" в рамках телемоста он осознанно нарушил свое обещание не обещать и озвучил планы по разработке нормативных и методических документов на ближайшее время:
    • проект методички по расчету показателей критерия социальной значимости (в дополнение к выложенной на прошлой неделе методичке по расчету показателей критерия экономической значимости)
    • порядок организации и проведения работ по аттестации объектов информатизации на соответстие требованиям о защите информации, не составляющей гостайну
    • требования по безопасности информации к средствам обеспечения безопасной дистанционной работы в информационных (автоматизированных) системах
    • изменения вв 31-й приказ ФСТЭК
    • методика анализа и поиска уязвимостей и НДВ в аппаратных средствах
    • новая методика анализа и поиска уязвимостей в ПО
    • типовая модель угроз для аппаратных средств
    • методичка по видам и методам испытаний при проведении аттестации
    • метожичка по управлению обновлениями (патч-менеджменту).

Вот такой краткий пересказ полуторачасового эфира, запись которого вы можете увидеть ниже:


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

4.2.21

Что общего между числом калорий и числом инцидентов? И снова о метриках ИБ (анонс нового Telegram-канала)

Каждый год многие, я так думаю, ставят перед собой какие-нибудь амбициозные цели, например, похудеть. Ой, что это я, мы же про безопасность говорим. Значит ставятся цели по ИБ. Допустим снизить число инцидентов в день с 23 до 18 или на 17%. Вроде бы красивая и нужная цель, но чтобы достичь ее, необходимо произвести ряд шагов. И раз уж я упомянул похудение, то попробуем сравнить эти два процесса между собой.

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

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

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

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

С инцидентами все тоже самое. Само по себе снижение числа инцидентов не говорит ни о чем. Причиной этого может быть:

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

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

  1. Измерять все. Потом
  2. Измерять правильные вещи. Потом
  3. Измерять правильные вещи правильным образом

Но начинать с измерения всего (ну или многого).

И вот тут я подступаю к тому, для чего писалась эта длинная заметка. Решил я тут поддаться модному поверью, называемому гитхабизации ИБ (на русском), и запустить новый Telegram-канал по метрикам ИБ (Cyber Security Metrics). Буду ежедневно делиться одной метрикой ИБ с ее кратким описанием, формулей, источниками данных, ограничениями и т.п. На самом деле это, конечно, не гитхабизация, но как это назвать, я не знаю. Сначала я думал заделать сразу каталог метрик и выложить его на Github, но времени на то, чтобы сделать это сразу и все, нет. А вот по частям мне показалось вполне подъемной задачей. В день по метрике - к концу года получится 250 разных метрик из разных доменов ИБ - реагирование на инциденты, управление уязвимостями, Red Team, Privacy, управление финансами, мониторинг ИБ, compliance и т.п. В отличие от своего текущего канала "Пост Лукацкого", у нового я включил возможность комментариев и обсуждения, чтобы можно обсуждать каждую метрику, делиться опытом и т.п.

Так что добро пожаловать в новый Telegram-канал, который будет этаким регулярно наполняемым каталогом метрик по ИБ.

3.2.21

Google Analytics в мобильных приложениях как угроза нацбезопасности или почему госорганы плюют на ФСТЭК и Роскомнадзор

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

Итак, что выяснила "Инфокультура"? 88% из проанализированных приложений, среди которых "Мои документы", "Московский транспорт", "Активный гражданин", "Парковки", "МВД", "Госуслуги" и т.п., имеют как минимум один встроенный трекер. Некоторые имеют 3, 4, 5 и даже 9 трекеров. Большинство приложений используют трекеры Google и Facebook, сервера которых размещаются за пределами РФ. Более того, далеко не всегда можно объяснить, зачем в мобильное приложение встроен тот или иной трекер. Например, зачем парковочному приложению отдавать что-то в Facebook? Ну да ладно, это не является предметом данной заметки. Если резюмировать, программное обеспечение государственной организации, часто являющееся частью государственной информационной системы, а то и объекта КИИ (например, "ковидные" приложения, Мосэнергосбыт или Дептранс, которые работают в сферах здравоохранения, энергетики или транспорта согласно ФЗ-187), осуществляет трансграничную передачу информации за пределы Российской Федерации. При этом сами приложения устанавливается также с серверов, находящихся за пределами Российской Федерации. А теперь посмотрим, что нам говорит на такие фокусы законодательство по защите информации.


Ст.13.2.1 трехглавного закона "Об информации, информационных технологиях и защите информации" говорит, что "технические средства информационных систем, используемых государственными органами, органами местного самоуправления, государственными и муниципальными унитарными предприятиями или государственными и муниципальными учреждениями, должны размещаться на территории Российской Федерации. Операторы государственных информационных систем, муниципальных информационных систем, информационных систем юридических лиц, осуществляющих закупки в соответствии с Федеральным законом от 18 июля 2011 года №223-ФЗ "О закупках товаров, работ, услуг отдельными видами юридических лиц", не должны допускать при эксплуатации информационных систем использования размещенных за пределами территории Российской Федерации баз данных и технических средств, не входящих в состав таких информационных систем".

Обратите внимание, в первой части этой статьи говорится о любых информационных системах, а не только о государственных ИС. Является ли трекер частью информационной системы? На мой взгляд да. Ведь он же для чего-то используется? Например, для отслеживания работы приложений и сбоев с помощью Google Firebase Analytics. По сути код такого трекера напоминает чужой контейнер или библиотеку, которую мы используем в своем ПО. Поэтому я вполне правомочен считать такой трекер частью ИС, а, следовательно, сервера, с которыми он общается, согласно ФЗ-149 должна располагаться на территории РФ.

Теперь обратимся к закону "О персональных данных", который уже много лет содержит норму, которую сотрудники Роскомнадзора трактуют как "запрет на хранение ПДн россиян заграницей". Мне можно возразить, что собираемая телеметрия не относится к ПДн, но я буду вынужден с вами не согласиться, так как согласно:
  • Определению Московского городского суда от 10.11.2016 по делу № 33-38783/2016
  • Постановлению 13 ААС от 01.07.2016 по делу № А56-6698/2016
  • Решению Таганского районного суда г. Москвы от 19.12.2018 по делу № 02-4261/2018
  • Решению Арбитражного суда города Москвы по делу А40-14900/2016

cookies, ID пользователя, IP- и MAC-адреса, User Agent, HTTP Referer, данные Google Analytics и Яндекс.Метрики и т.п. являются персональными данными. Тот же Google Crashlytics, который используется многими государственными мобильными приложениями собирает не только уникальный идентификатор устройства, геолокацию, данные об использовании приложения, но и в ряде случаев e-mail. То есть согласно позиции РКН и российских независимых судов, если дело дойдет до них, все данные, собираемые трекерами, будут рассматриваться как персональные, а следовательно снова возникает вопрос, на каком основании они передаются, обрабатываются и хранятся за пределами России.

Наконец, третий закон, с позиции которого я бы хотел посмотреть на работу государственных мобильных приложений, - это ФЗ "О безопасности критической информационной инфраструктуры". И если в самом законе ни слова не сказано о том, где можно или нельзя хранить данные субъектов КИИ и куда могут подключаться объекты КИИ, то в приказе ФСТЭК №239, в пункте 31-м прямо говорится, что "входящие в состав значимого объекта 1 и 2 категорий значимости программные и программно-аппаратные средства, осуществляющие хранение и обработку информации, должны размещаться на территории Российской Федерации (за исключением случаев, когда размещение указанных средств осуществляется в зарубежных обособленных подразделениях субъекта критической информационной инфраструктуры (филиалах, представительствах), а также случаев, установленных законодательством Российской Федерации и (или) международными договорами Российской Федерации)". То есть и эта ветка отечественного законодательства по ИБ запрещает использование (правда, не для всех объектов КИИ) зарубежных трекеров.

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

29.1.21

Задай свой вопрос ФСТЭК!

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

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

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


Поэтому еще раз подумайте и задавайте свои вопросы. Они могут быть любыми, как вы могли обратить внимание выше. Главное, чтобы они были конкретными и по делу. Тогда и ответы будут такими же.

Вопрос "Когда будет выпущена методика моделирования угроз?" можете не писать - его задали уже много раз :-)

Штабные киберучения по промышленной ИБ. Совсем скоро!

Вы знаете, что делать, если с ноутбука подрядчика, осуществляющего регламентные работы в вашей промышленной инфраструктуре, началось распространение вредоносного кода (именно так в 2003-м году пострадала атомная электростанция Дэвид-Бессе в США)? Какие первые шаги вы должны предпринять, чтобы локализовать проблему и снизить возможный ущерб от нее? А что делать, если подрядчик, подключающийся к вашему промышленному контроллеру удаленно, был скомпрометирован и через его сеть по VPN-каналу на ваше предприятие лезет китайский хакер, спонсируемый государством? Может быть вы знаете, что делать в ситуации, когда оператор ночной смены АСУ ТП, скучая от безделья, решил подключить к своему компьютеру 4G-модем и полазить по Интернет (такой кейс приключился в одной арабской стране)? А как поступить, когда инженер для облегчения задачи по снятию телеметрии с оборудования ставит в цеху точку беспроводного доступа с настройками по умолчанию (почти такой же кейс, но на одном гидротехническом сооружении, произошел в России)?

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

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

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

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

20.1.21

Импортозамещение КИИ: ситуация ухудшается

В мае я уже писал про проекты двух примечательных по своей значимости и некомпетентности проектов нормативных актов, которые обязывают всех субъектов КИИ перевести все свои объекты КИИ на отечественное ПО и железо. И вот на днях на портале regulations.gov.ru был выложен обновленный текст проекта Постановления Правительства "Об утверждении требований к программному обеспечению, телекоммуникационному оборудованию и радиоэлектронной продукции, используемым на объектах критической информационной инфраструктуры, и порядка перехода на преимущественное использование российского программного обеспечения, телекоммуникационного оборудования и радиоэлектронной продукции". Ранее, в ноябре был выложен обновленный проект Указа Президента. Давайте посмотрим, что там изменилось?

Если тезисно, то картина получается следующая:

  • Переход на преимущественно отечественное ПО должен произойти до 1-го января 2023 года, а на отечественное железо до 1-го января 2024 года. Первоначально сроки были установлены просто дикие - 1-е января 2020-го и 2021-го годов соответственно. По итогам доработки проектов НПА сроки были сдвинуты на 2024-й и 2025-й годы, но в финальном проекте сроки были установлены в виде 2023-го и 2024 годов соответственно. На мой взгляд все варианты нереальны, но судя по всему именно последний вариант и попадет в подписываемый Указ Президента, чего ждать осталось недолго, если не вмешается Провидение.
  • Под требования попадают все объекты КИИ независимо от их категории значимости и даже обычный ломбард или сельская поликлиника должны будут перейти на преимущественно отечественные ПО и железо. Попытки сообщества и достаточно серьезных лоббистов объяснить авторам нелепость этого требования не увенчались успехом - Минцирк (или те, кто стоят за ними) заявил, что иначе все субъекты КИИ будут занижать категории своей значимости, а то и вовсе обходить категорирование стороной. Так что готовимся к повсеместному внедрению отечественного софта и оборудования.
  • Название нового проекта ПП теперь касается не только ПО или оборудования, как раньше. Вместо термина "оборудование" стали применять "телекоммуникационное оборудование и  радиоэлектронная продукция". Хотя сами требования от этого не поменялись - они и раньше покрывали телеком-железо и РЭП.
  • Требования касаются не только нового ПО и железа, но и уже установленного на объектах КИИ.
  • До 1-го июля 2021 года необходимо утвердить план перехода на преимущественно отечественное ПО и железо. А перед утверждением плана надо провести аудит используемых ИТ-активов, провести их анализ и факт присутствия в реестрах отечественного всего и вся, после чего, в случае осутствия в реестрах, направить перечень такого ПО и железа на согласование в Минцифру (для ПО) и в Минпроторг (для железа). На все про все осталось 5 с небольшим (!) месяцев. Как за это время провести хотя бы аудит имеющегося, я не представляю.
  • Интересный момент, на который стоит обратить внимание и о котором я уже как-то писал (тут и тут). Неважно, в России разработано ПО или нет. Главное, чтобы оно было в реестре. А, например, средства защиты попадают в реестр только после получения сертификата ФСТЭК или ФСБ, что приводит к интересным коллизиям, о которых мало кто говорит. Например, выпустил какой-нибудь отечественный вендор МСЭ или антивирус или криптографический шлюз, а продать в КИИ не может, так как продукт или конкретная его версия не включена в реестр из-за отсутствия (понятно, что временного) сертификата регулятора. Парадокс, но именно так это и работает. Знаю кейс, когда именитому вендору отказали во включении в реестр Минцифры именно по причине отсутствия сертификата (хотя предыдущая версия ПО в этом реестре была).
  • А что с иностранным ПО и железом? Неужели все и использовать его нельзя? Нет, все не так печально. Есть разъяснения Минцифры, в которых говорится, что можно продолжать использовать невключенное в реестры ПО и оборудование, но при условии соответствующего обоснования, которое многие уже научились писать еще лет пять назад, когда только началась политика импортозапрещения в госорганах. Теперь эта практика перейдет и к коммерческим предприятиям.

Вот такая картина у нас сейчас с импортозамещением в КИИ. Есть подозрение, что упомянутые в заметке проекты Постановления Правительства и Указа Президента уже не будут изменяться и именно в таком виде будут приняты в ближайшем будущем. Проводить через депутатов их не надо - много времени это не займет. Так что готовимся к новой реальности. И если в прошлом году это была удаленная работа, то в этом - умение составить обоснование так, чтобы объяснить регулятору, почему все остается так, как и было раньше.