Что такое модель угроз?

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

Изначально пойдем простым путем и поищем определение на просторах интернета.

Как итог – определение Роскомнадзора используется практически везде.

Звучит оно так:

Модель угроз и нарушителя – это «совокупность предположений о возможных угрозах и возможностях нарушителя, которые он может использовать для разработки и проведения атак в рамках разрабатываемой системы».

Теперь разберёмся с основной целью написания документа (оставлю небольшую ремарку: в целом, модель нарушителя – это больше описание «бумажной безопасности»).

Для более точного понимания обратимся к нормативной документации, а именно – методике Федеральной службы по техническому и экспортному контролю (ФСТЭК). Получим следующее определение:

«Целью моделирования угроз безопасности информации является выявление совокупности условий и факторов, которые приводят или могут привести к нарушению безопасности обрабатываемой в системах и сетях информации (нарушению конфиденциальности, целостности, доступности, неотказуемости, подотчетности, аутентичности и достоверности информации и т.д., а также к нарушению или прекращению функционирования систем и сетей)»

Если вы впервые сталкиваетесь с требованиями информационной безопасности, то скорее всего вам будет «очень интересно, но ничего непонятно».

Будем проще – данная модель содержит перечень возможных нарушителей, которые могут скомпрометировать/навязать/испортить информацию в разрабатываемой системе; список угроз в соответствии с классом вашей системы и описание некоторых последствий, которые могут появиться, если нарушитель все-таки украдет вашу информацию.

Нормативно-методическая база

С моей точки зрения, необходимо сделать небольшое формальное отступление и перечислить ФЗ, которые, как раз-таки, регламентируют написание данного документа:

• Федеральный закон от 27.07.2006 года № 149-ФЗ «Об информации, информационных технологиях и о защите информации» (ред. от 09.03.2021);

• Федеральный закон от 27.07.2006 года № 152-ФЗ «О персональных данных»;

• Требования к защите персональных данных при их обработке в информационных системах персональных данных, утвержденные постановлением Правительства Российской Федерации от 01.11.2012 г. № 1119;

• Требования к защите автоматизированных систем управления субъектов критической информационной инфраструктуры – в соответствии с положениями Федерального закона от 26.07.2017 г. № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации»;

Итак, я думаю, что со списком ФЗ тоже все должно быть более менее понятно.

 Вывод: если вы взялись за разработку государственной информационной системы, которая содержит коммерчески значимую информацию или персональные данные, которые, как ни крути, подлежат защите в соответствии с законодательством, от разработки модели угроз вам никуда не деться.

Содержание модели угроз

Рассмотрение вопроса о необходимости написания документа позади, теперь давайте посмотрим, что предписывает нам законодательство по его содержанию. Здесь, как ни странно, все довольно скромно.

Для того, чтобы понять, что конкретно должно содержаться в модели, обратимся снова к нормативным документам ФСТЭКа, а именно к 17 приказу.

«Модель угроз безопасности информации должна содержать описание информационной системы и ее структурно-функциональных характеристик, а также описание угроз безопасности информации, включающее описание возможностей нарушителей (модель нарушителя), возможных уязвимостей информационной системы, способов реализации угроз безопасности информации и последствий от нарушения свойств безопасности информации».

Вы не поверите, но это все. С другой стороны, хоть требование и небольшое, оно довольно содержательное.

Давайте еще раз перечитаем и выделим основные моменты, которые должны быть:

• описание информационной системы;

• структурно-функциональные характеристики;

• описание угроз безопасности;

• модель нарушителя;

• возможные уязвимости;

• способы реализации угроз;

• последствия от нарушения свойств безопасности информации.

Это по законодательству, что требует ФСТЭК. Также, дополнительно есть требования Федеральной службы безопасности (ФСБ). Их в рамках нашей статьи мы не будем рассматривать, так как в нашей системе не предусмотрено применение средств криптографической защиты (СКЗИ), по крайней мере, пока что.

Давайте чуть подробнее пробежимся по содержанию требования для создания «общей картины» документа:

• описание информационной системы – тут все достаточно тривиально – необходимо привести назначение, цели создания системы, предполагаемую структуру/архитектуру. Также здесь есть раздел «Охрана помещений». Тут описываем, как охраняются помещения в рабочее и внерабочее время и т.д.;

• описание угроз безопасности – если коротко, то здесь нужно именно копипастить текст из БДУ (база угроз ФСТЭК), потому что в модели угроз должно быть «описание угроз», отделаться идентификаторами не получится;

• модель нарушителя – здесь можно разделить эту часть на классическую и новую. Классическая – это та самая, где описаны потенциальные нарушители 1, 2 и далее категорий. Практическую же ценность представляет раздел «Нарушители согласно банку данных угроз ФСТЭК России». Раздел представляет ценность так как сами угрозы из банка данных угроз ФСТЭК привязаны к нарушителям с низким, средним и высоким потенциалом;

• возможные уязвимости – в данном разделе необходимо перечислить возможные классы уязвимостей для конкретной информационной системы. А чтобы придать этому списку солидности, возьмем этот список не из головы, а из ГОСТ Р 56546-2015 «Защита информации. Уязвимости информационных систем. Классификация уязвимостей информационных систем»;

• способы реализации угроз – в этом разделе необходимо описать возможные способы, как программные, так и аппаратные;

• последствия от нарушения свойств безопасности информации – назвали этот раздел именно так, потому что, по сути, по определению опасности угроз, это является определением последствий. Итак, опасность угроз может быть низкой, средней или высокой, в зависимости от этого, незначительные негативные, просто негативные или же значительные негативные последствия наступают при реализации угрозы соответственно. Специалисты здесь часто спорят – должна ли опасность угроз определяться один раз и быть константой для всех угроз или же нет. Методикой это не оговорено, поэтому можно и так, и так. Наш подход промежуточный – мы определяем опасность угроз в зависимости от нарушения конфиденциальности, целостности или доступности при реализации конкретной угрозы.

В списке выше данный пункт не указан, но упомянуть его все же необходимо. Определение вероятности угрозы – здесь важно сказать, что заполнение данной информации – чисто наша инициатива и законодательством не предусмотрена. Поэтому можете его спокойно убирать. Но я считаю важным, что если специалист дополнительно исключает угрозы, потому что для их реализации нет предпосылок, важно чтобы он описал, почему он так решил.

Выводы

• определяем классы защищаемой информации в разрабатываемой системе;

• корректируем требования для дальнейшей разработки с учетом «хотелок» ФСТЭК;

• составляем перечень нарушителей, которые могут нанести ущерб вашей системе (как внутренние, так и внешние);

• не забываем про перечень возможных угроз в рамках вашей системы;

• проводим оценку найденных уязвимостей (придется задуматься, как защититься);

• получаем (бесценный!) опыт работы с 17-м приказом ФСТЭК.