Первый и самый логичный вопрос, который возникает, когда видишь этот документ в списке требований от Заказчика. Изначально пойдем простым путем и поищем определение на просторах интернета.  Как итог – определение Роскомнадзора используется практически везде.  Звучит оно так: Модель угроз и нарушителя – это «совокупность предположений о возможных угрозах и возможностях нарушителя, которые он может использовать для разработки и проведения атак в рамках разрабатываемой системы». Теперь разберёмся с основной целью написания документа (оставлю небольшую ремарку: в целом, модель нарушителя – это больше описание «бумажной безопасности»). Для более точного понимания обратимся к нормативной документации, а именно – методике Федеральной службы по техническому и экспортному контролю (ФСТЭК). Получим следующее определение: «Целью моделирования угроз безопасности информации является выявление совокупности условий и факторов, которые приводят или могут привести к нарушению безопасности обрабатываемой в системах и сетях информации (нарушению конфиденциальности, целостности, доступности, неотказуемости, подотчетности, аутентичности и достоверности информации и т.д., а также к нарушению или прекращению функционирования систем и сетей)» Если вы впервые сталкиваетесь с требованиями информационной безопасности, то скорее всего вам будет «очень интересно, но ничего непонятно». Будем проще – данная модель содержит перечень возможных нарушителей, которые могут скомпрометировать/навязать/испортить информацию в разрабатываемой системе; список угроз в соответствии с классом вашей системы и описание некоторых последствий, которые могут появиться, если нарушитель все-таки украдет вашу информацию. С моей точки зрения, необходимо сделать небольшое формальное отступление и перечислить ФЗ, которые, как раз-таки, регламентируют написание данного документа: Федеральный закон от 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-м приказом ФСТЭК.