Как стать автором
Поиск
Написать публикацию
Обновить

Комментарии 8

Занятный материал для безопасников. Спасибо.
Методикой (проектом) 2015 года пользоваться можно при составлении модели угроз? Помнится, когда-то говорили, что его вот-вот примут и пользуйтесь ею.
В пункт «Исключение «лишних» угроз» можно еще добавить тип угроз Устройства с ЧПУ, хоть их там и пару штук.
Можно использовать удачные моменты, которые не пересекаются с методикой 2008 года. Например, можно взять описание мотиваций нарушителя, в проекте они неплохо описаны. Но что сделать нельзя, так это заменить вычисление Y1 и Y2 на определение актуальности угроз по проекту 2015 года.
По устройствам с ЧПУ да, конечно, если таких устройств нет, угрозы также исключаются.
Очень хорошая статья, но есть несколько замечаний. Самое главное, не рассмотрен процесс определения типа актуальных угроз НДВ:
«Про типы угроз подробно не будем останавливаться, информации много в интернете. Остановимся на том, что есть 3 типа угроз и нам всеми правдами и неправдами, если планируется применение криптографии нужно делать именно 3-й тип угроз (неактуальны угрозы, связанные с недекларированными возможностями в прикладном и общесистемном ПО).»

Вы правда предлагаете в модели угроз ссылаться на то, что где-то в интернете написано, что угрозы НДВ неактуальны?

Давайте вспомним, откуда взялось понятие «тип актуальных угроз НДВ»? Единственное место, где используется данный термин — это ПП-1119 от 2012 года. Причем это один из ключевых параметров, влияющих на определение итогового уровня защищенности, соответственно его нужно определять для всех ИСПДн.
В документах ФСТЭК России такого термина нет, и они вообще отказываются комментировать ПП-1119, т.к. это не входит в сферу их регулирования.

Соответственно, раз Постановление 1119 разработано ФСБ России, значит и расшифровку термина НДВ нужно искать в документах ФСБ (378 приказ и Методические рекомендации от 2015 г.).
Вот именно в разделе модели угроз «Обобщенные возможности источников атак» мы и видим, что имеются две категории нарушителей, связанные с НДВ:
5) Возможность привлекать специалистов, имеющих опыт разработки и анализа СКЗИ (включая специалистов в области использования для реализации атак недокументированных возможностей прикладного программного обеспечения);
6) Возможность привлекать специалистов, имеющих опыт разработки и анализа СКЗИ (включая специалистов в области использования для реализации атак недокументированных возможностей аппаратного и программного компонентов среды функционирования СКЗИ).

В 5-м пункте четко прописано — «реализация атак недокументированных возможностей прикладного ПО», что соответствует 2-му типу актуальных угроз НДВ из ПП-1119.

В 6-м пункте написано — «реализации атак недокументированных возможностей… программного компонента среды функционирования СКЗИ». Среда функционирования СКЗИ — это операционная система, следовательно данная категория нарушителя соответствует 1-му типу актуальных угроз НДВ из ПП-1119.

А в следующем разделе модели угроз — «Реализация угроз безопасности информации, определяемых по возможностям источников атак» как раз и приводится обоснование отсутствия у нас угроз 1-го или 2-го типа, т.е. пунты 3.1-4.3 из таблицы, которые вы признали неактуальными.

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

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

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


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

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


В целом мы сами понимаем, что и с этим можно поспорить, но регуляторов пока устраивает такой подход.
Благодарю за статью. Назначили недавно администратором безопасности. Материал помог разложить некоторые моменты по полочкам. Но белых пятен еще много.
Есть такой вопрос.
Пока разбираюсь, накопал, что для кредитных организаций и некредитных финансовых организаций, указанных в части 1 статьи 76.1 ФЗ от 10.07.2002 №86-ФЗ, коих сейчас вагон и огромная телега, имеется Указание ЦБ от 10.12.2015 г. №3889-У, где установлен минимальный набор актуальных угроз безопасности.
Получается, в модели угроз таких организаций эти угрозы надо указать безусловно актуальными сославшись именно на это Указание ЦБ?
На это Указание вообще стоит обращать внимание, ведь ЦБ не регулятор в области ПДн, а лицензирующий орган?
В указанном постановлении указано немного угроз и сформулированы они достаточно общими словами.
Есть подозрение, что это постановление — выполнение для галочки нормы статьи 19 федерального закона «О персональных данных»:

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


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