27.10.21

Куда падает качество нормативки наших регуляторов и что с этим делать?

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

Давайте к примерам? Возьмем методику оценки угроз ФСТЭК, утвержденную 5-го февраля этого года. ЭТОГО! Но уже известно, что регулятор готовит в нее поправки. Документу от силы было полгода, когда регулятор решил вносить в него изменения, которые, согласно публичным высказываниям регулятора, планируют утвердить в первом квартале уже следующего года. У Банка России такая же проблема. 716-П по рискам вступило в силу 1-го октября прошлого года, но уже готов проект с поправками в него на 30+ (!) страниц. Не это ли свидетельство того, что документ получился сложным для восприятия? Ну а как может быть иначе, когда у вас нормативный акт занимает 130 страниц и к нему еще готовится ГОСТ на 180 страниц. 300 страниц (!), которые можно было бы изложить на одной странице формата А4! И это только один пример - у ЦБ таких косяков просто масса (отдельный пост им посвящу). РКН со своим 1046-м Постановление Правительства по надзору в области персональных данных тоже накосячил - и в расширительном толковании отдельных терминов, и синтаксических ошибках. И это только три примера, которые достаточно свежие и от разных регуляторов, но их ведь гораздо больше.   

Как с этим бороться? На мой взгляд вариантов решения проблемы всего несколько. Первый - сформировать пул лояльных специалистов, которые не будут зависеть от регулятора, и через которых можно было бы пропускать проекты нормативки с обещанием принять всю критику и постараться ее исправить. Причем делать это адресно в обе стороны, а не так обезличенно, как это сейчас работает на regulations.gov.ru. Хотя где найти таких специалистов в достаточном количестве? Все же реально ссут сказать что-то супротив регулятора, от которого зависит сертификация выпускаемых твоей компанией продуктов или обновление/расширение лицензии или еще какие-то ништяки. Надо сказать, что это не совсем проблема регулятора, что у нас исторически все боятся сказать что-то против политики партии, но и его тоже - он же поощряет ее.

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

Можно попробовать пропустить документ через маленькие предприятия, в том числе поднадзорные, чтобы понять, насколько написанное реализуемо с малыми ресурсами. Такое замечание было очень частым после принятия ЦБшного ГОСТа 57580.1, который рассчитан на крупные финансовые организации, которые и принимали участие в его написании. Но и тут нас поджидают упомянутые ранее подводные камни.

Хорошей практикой является обучение. Есть высказывание, что когда начинаешь готовить материал для обучения и преподавать, то начинаешь лучше разбираться в вопросе (а почему я так активно преподаю, а?). А когда начинаешь рассказывать, что же ты имел ввиду в документе по 10 раз перед разными людьми, тогда лучше начинаешь понимать и область регулирования и свои корявые формулировки. Можно, конечно, сделать вариант-минимум - читать перед подчиненными, но они же правду в глаза не скажут все равно. Поэтому только публичная активность, но на это рассчитывать не приходится - не приучен у нас регулятор к публичной критике, а еще и отомстить может.  

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

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

26.10.21

Моделирование угроз в процессе разработки ПО

Решил я тут раскрыть чуть больше краткую заметку в своем Telegram, посвященную моделированию угроз в процессе разработки ПО. Я написал следующее: "Методика оценки угроз ФСТЭК не применяется при моделировании угроз в рамках безопасной разработки. Учитывая, что ФСТЭК уделяет последней очень много внимания, стоит ли ждать отдельного документа/стандарта по этому вопросу? Пока у меня нет ответа на этот вопрос, хотя появление ГОСТа по этой теме было бы логичным.

А пока можно использовать сторонние источники для моделирования угроз в рамках разработки:

- STRIDE от Microsoft (и Threat Modeling Tool от них же)

- OWASP - (и Threat Dragon Tool от них же)

- Матрица угроз ATT&CK для CI/CD

- Инструмент Materialize Threats Tools

- threatspec

- The Raindance Project

- PyTM

- Meta Attack Language

- Agile Threat Modeling Toolkit"

Коллеги обратили мое внимание, что у ФСТЭК есть разделы в ГОСТах по безопасной разработке, посвященные моделированию угроз. И вот этот момент я бы и хотел прокомментировать. Если мы возьмем ГОСТ Р 56939 "Разработка безопасного ПО. Общие требования", то в разделе 5.2.1 говорится, что разработчик должен провести моделирование угроз, а в разделе 5.2.3.1 этот вопрос раскрывается чуть подробнее, но и в нем не приводится никакой методологии моделирования, а всего лишь уточняется, что она должна быть и что документация разработчика должна содержать описание выбранной методологии, список выявленных угроз и список мер, эти угрозы нейтрализующих.

Эта процедура моделирования из методики Microsoft

Список угроз можно найти в другом стандарте - ГОСТе Р 58412 "Разработка безопасного ПО. Угрозы безопасности информации при разработке ПО", в котором перечислено 19 угроз. Но в нем также нет методологии выбора из перечисленного перечня угроз актуальных. Да и сами угрозы достаточно высокоуровневы и хотелось бы иметь их большую детализацию. Например, огромный пласт угроз для процесса CI/CD или угрозы, реализуемые через репозитории кода, объединяются в одну - угрозу внедрения уязвимостей программы из-за неверного использования инструментальных средств при разработке ПО. Лично мне не хватает в ГОСТ 58412 деталей, - тех же техник и тактик, которые есть в методике ФСТЭК, процедуры выбора угроз, примеров, то есть ровно того, что сделает документ практически полезным в работе.

А, например, угрозы при использовании API куда попадают в рамках упомянутого ГОСТа? А отсутствие шифрования или хотя бы хэширования паролей в разрабатываемых приложениях? А отсутствие контроля вводимых параметров? Или это не угроза, а уязвимость переполнения буфера (хотя SQL Injection это именно угроза)? А угрозы генерации неслучайных чисел в "датчиках случайных чисел"? А работа с памятью, позволяющая выполнять вредоносный код от имени привилегированных пользователей/процессов? А, в конце концов, нарушение правил контроля доступа, которое отвечает за 10 из 30 основных проблем безопасности ПО? Или такой уровень детализации не является предметом регулирования ГОСТ 58412? Вообще, хотелось бы видеть либо что-то аналогичное проекту CAPEC от MITRE (раз уж мы так активно используем концепции этой корпорации у нас), либо ссылку на возможность его использования в том же ГОСТе 58412 (рах уж мы ссылаемся на CAPEC в методике оценки угроз от 5-го февраля).

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

Ее, кстати, нет и в текущей методике оценки угроз, что ставить нас перед непростой задачей - какую из актуальных угроз нейтрализовывать первой, какую второй, какую третьей и т.д. Ровно то, о чем я писал в июне, рассказывая о методике TARA той же MITRE. А применительно к моделированию угроз в рамках безопасной разработке за основу такого метода ранжирования можно взять DREAD от Microsoft, а можно и что-то другое.

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