29.3.21

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

29.3.21  , , , ,  6 comments

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

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

16.3.21  ,  No comments

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

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

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

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

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

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

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

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

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

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

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

Подробнее…

15.3.21

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

15.3.21    No comments

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

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

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

Подробнее…

12.3.21

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

12.3.21  , ,  16 comments

Когда я готовился к вчерашнему межблогерскому вебинару, где мы обсуждали новую методику оценки угроз ФСТЭК, я составил список замечаний, которые хотел озвучить и не постеснялся и озвучил их :-) Но в структурированном формате я их никуда не выкладывал и в презентацию не вставлял; поэтому сегодня можно посвятить отдельную заметку этому документу, который, как гром с ясного неба, без какого-либо повторного обсуждения, был утвержден регулятором 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). Посчитали несущественными или неправильными? Ну может быть - не мне судить и не мне за регулятора решать, как ему делать свою работу. Но вопросов ФСТЭК огребет получит теперь немало - и по почте, и на своих мероприятиях. Не умеет регулятор просчитывать последствия своих действий и моделировать их. А вроде должен, если других учит в своих методических документах. Ну да ладно. Жизнь нас рассудит, а правоприменительная практика покажет, кто был прав и являются ли описанные выше нюансы значимыми или нет. В любом случае рынок услуг по моделированию угроз только вырастет - то есть задачу улучшению экономического положения лицензиатов регулятор точно своим документом решит. А это уже немало.
Подробнее…
Подписаться на: Сообщения (Atom)