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

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