Пишем модель угроз

В указанном постановлении указано немного угроз и сформулированы они достаточно общими словами.
Есть подозрение, что это постановление — выполнение для галочки нормы статьи 19 федерального закона «О персональных данных»:

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

По факту, скорее всего все эти угрозы у вас и так будут актуальными по БДУ. Либо неактуальными из-за неприменимости. То есть «угроза несанкционированного доступа к отчуждаемым носителям персональных данных» будет неактуальна, если отчуждаемые носители не используется.

Пишем модель угроз

Нет, конечно мы не ссылаемся на нечто «написанное в интернете». По-хорошему, это должно работать так — есть угрозы, некоторые из них можно отнести к связанным с НДВ, некоторые нет. Смотрим что у нас актуально -> определяем тип угроз.

И да, конечно же, когда нет отдельного раздела по НДВ мы не раз получали просьбы от регулятора добавить его.
При этом мы не используем подход, связанный с 378 приказом. Можно было бы конечно оставить эти разделы для ИСПДн, в которых не применяются СКЗИ, но мы этого не делаем, потому что норматива ФСБ местами мягко говоря не удачна. Не пользуемся ей везде, где можно ей не пользоваться.
В качестве определения НДВ используем термин из самого БДУ ФСТЭК: bdu.fstec.ru/ubi/terms/terms/view/id/34

Недекларированные возможности [программного обеспечения] (Undeclared software capabilities) — функциональные возможности программного обеспечения, не описанные или не соответствующие описанным в документации, при использовании которых возможно нарушение конфиденциальности, доступности и (или) целостности обрабатываемой информации (РД Гостехкомиссии России «Защита от НСД. Часть 1. ПО средств ЗИ. Классификация по уровню контроля отсутствия НДВ»).

Далее проще будет привести выдержку из нашего учебного пособия:

Из приведенного выше определения видно, что НДВ в классическом их понимании встречаются повсюду. Не только системные администраторы, но и простые пользователи повсеместно сталкиваются с НДВ в операционных системах семейства Windows. Отсюда можно сделать вывод, что НДВ есть всегда и везде, в том числе и в операционных системах. Что же получается, в любой ИСПДн актуальны угрозы первого типа?
К счастью не все так мрачно. Давайте посмотрим на вторую часть определения: «…при использовании которых возможно нарушение конфиденциальности, доступности и (или) целостности обрабатываемой информации». Итак, мы понимаем, что различные ошибки, особенно в таком сложном ПО, как операционные системы это обычное явление. Как определить, какие из них опасны для нарушения характеристик безопасности, а какие нет? Уязвимости программного обеспечения можно условно разделить на уязвимости, для которых существует исправление (патч, заплатка) и, так называемые, уязвимости нулевого дня. Уязвимости нулевого дня — это уязвимости, для которых еще не вышло исправление от разработчика и которая может быть легко проэксплуатирована. Сам термин означает то, что у разработчика есть 0 дней на выпуск исправления своего программного обеспечения, а сама уязвимость может быть проэксплуатирована без возможности защиты от нее. Иногда такие уязвимости становятся достижением общественности, но чаще информацией о них обладает узкая группа людей (хакеры, исследователи безопасности ПО, разработчики ПО). Нужно понимать, что поиск уязвимостей нулевого дня — это трудоемкий и дорогостоящий процесс, требующий высокой квалификации, а в последнее время даже слаженной работы команды высококвалифицированных специалистов.
Что происходит с уязвимостями нулевого дня, когда они обнаруживаются? Они могут быть проданы на черном рынке заинтересованным лицам. Цена на уязвимости нулевого дня, как правило, стартует с отметки в 50 тысяч долларов США. Еще один вариант — информация о такой уязвимости сообщается производителю ПО. Это чаще происходит в случае, если уязвимость нулевого дня обнаружена в ПО, у производителя которого есть программа по выплате вознаграждений за обнаружение таких уязвимостей. Такие гиганты как Google, Microsoft или Oracle выплачивают сотни тысяч долларов в год за сообщения о найденных уязвимостях в их продуктах. Ну и, конечно же, обнаруживший уязвимость специалист сам может использовать ее в своих целях.
Когда разрабатывается модель угроз и модель нарушителя, для большинства ИСПДн не рассматриваются такие специалисты (и тем более группы специалистов) в качестве потенциальных нарушителей. К тому же, даже если злоумышленник нашел дыру в безопасности распространенного ПО, используемого в ИСПДн, ему будет выгоднее продать эту уязвимость на черном рынке или разработчику программного продукта. И даже если информация, обрабатываемая в информационной системе, привлечет группу людей, обладающих финансовыми возможностями, позволяющими нанять такую серьезную команду специалистов, не проще ли пустить финансовые потоки на подкуп сотрудников организации и на реализацию других методов социальной инженерии? Проще, дешевле и быстрее. Но это уже совсем другой вектор атак.
Итак, возможность эксплуатации уязвимостей нулевого дня злоумышленником в большинстве случаев считается неактуальной из-за их дороговизны и сложности в реализации. А как быть с известными уязвимостями используемого в ИСПДн программного обеспечения? Для таких уязвимостей, как правило, существует исправление (патч) от производителя ПО, поэтому для того, чтобы признать неактуальными и эти угрозы необходимо всего-навсего регулярно обновлять программное обеспечение. Из всего вышесказанного можно сделать вывод, что угрозы первого и второго типа актуальны только тогда, когда в информационной системе используется устаревшее ПО, не поддерживаемое производителем (в том числе и свободно распространяемое) или не производится так называемый патч-менеджмент. Например, угрозы первого типа будут актуальны, если на рабочих местах используется ОС Windows XP. Некогда сверхпопулярная операционная система уже несколько лет не получает никаких обновлений безопасности и на данный момент уже существуют уязвимости (в том числе и критичные), которые уже никогда не будут исправлены.

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

Пишем модель угроз

Можно использовать удачные моменты, которые не пересекаются с методикой 2008 года. Например, можно взять описание мотиваций нарушителя, в проекте они неплохо описаны. Но что сделать нельзя, так это заменить вычисление Y1 и Y2 на определение актуальности угроз по проекту 2015 года.
По устройствам с ЧПУ да, конечно, если таких устройств нет, угрозы также исключаются.