Модель угроз безопасности персональных данных структура и порядок разработки

Модель угроз безопасности персональных данных: структура и порядок разработки

УТВЕРЖДЁН
приказом директора [полное наименование образовательной организации]
от «[дата]» № [номер]

СВЕДЕНИЯ О ПРОЦЕДУРЕ ПРИНЯТИЯ

Самостоятельное основание для учёта мнения представительного органа работников: [реквизиты коллективного договора, соглашения или иного основания либо «не установлено»].

Мотивированное мнение выборного органа первичной профсоюзной организации: [учтено, протокол от «[дата]» № [номер] / не запрашивалось ввиду отсутствия самостоятельного основания].

ПОРЯДОК разработки и актуализации модели угроз безопасности персональных данных [полное наименование образовательной организации]

1. Общие положения

1.1. Настоящий Порядок определяет, кто инициирует разработку модели угроз безопасности персональных данных, какие исходные данные для неё готовит [полное наименование образовательной организации] (далее — Оператор), из каких разделов состоит модель угроз и в каком порядке она утверждается и пересматривается. 1.2. Модель угроз разрабатывается для каждой информационной системы персональных данных Оператора отдельно. Одна модель угроз для нескольких систем совместно допускается по решению Оператора только в случаях, предусмотренных пунктом 2.13 Методики оценки угроз безопасности информации, утверждённой ФСТЭК России 05.02.2021: для совокупности взаимодействующих систем и сетей Оператора — с описанием угроз, актуальных для инфраструктуры каждой системы, и угроз, связанных с интерфейсами их взаимодействия; либо для нескольких однотипных создаваемых систем и сетей. Решение об объединении и признак взаимодействия или однотипности фиксируются письменно с обоснованием специалиста; произвольное объединение систем, не отвечающих этим признакам, не допускается. 1.3. Разработка модели угроз по существу (выявление угроз, оценка их актуальности, формирование перечня) выполняется [сведения]. Если собственной квалификации для разработки модели угроз у Оператора нет, к разработке привлекается специалист (организация) по защите информации. 1.4. Директор утверждает модель угроз и решение о привлечении внешнего разработчика. Ответственный за организацию обработки персональных данных координирует сбор исходных данных, регистрирует этапы работы и обеспечивает связь модели с документами Оператора. 1.5. Владелец информационной системы [должность] подтверждает назначение системы, состав пользователей и фактические процессы обработки. Администратор системы [должность] предоставляет сведения об оборудовании, программном обеспечении, сетевых связях, учётных записях и применяемых средствах защиты в пределах выданного задания. 1.6. Разработчик модели угроз отвечает за методику выявления и оценки угроз, обоснование перечня актуальных угроз и выводы, включённые в модель. Работники Оператора не подменяют профессиональную оценку разработчика предположениями, но сообщают ему о несоответствии описания фактической системе. 1.7. Результат процедуры включает утверждённую модель угроз, комплект исходных данных с датой актуальности, документ о проверке проекта, акт определения уровня защищённости и перечень решений, которые требуется отразить в системе защиты персональных данных. 1.8. Для новой информационной системы оценка угроз начинается на стадии создания системы, до ввода её в эксплуатацию; модель угроз, акт определения уровня защищённости и необходимые меры защиты по приказу ФСТЭК России № 21, вытекающие из них, оцениваются на эффективность и по возможности завершаются до фактического ввода системы в эксплуатацию.

2. Инициирование разработки

2.1. Разработка либо пересмотр модели угроз инициируется ответственным за организацию обработки персональных данных в следующих случаях:

• вводится в эксплуатацию новая информационная система персональных данных;
• определяется уровень защищённости персональных данных, а действующая модель отсутствует либо не отражает текущий состав системы;
• существенно меняются состав обрабатываемых персональных данных, состав пользователей системы или каналы взаимодействия с иными информационными системами;
• выявлен инцидент, свидетельствующий о неучтённой угрозе;
• появились новые угрозы или сценарии их реализации, значимые для системы (в том числе по результатам контроля защищённости или сведениям банка данных угроз ФСТЭК России);
• изменилась применяемая методика оценки угроз, правовой режим обрабатываемой информации либо значимо изменилась архитектура системы;
• наступил плановый срок пересмотра, установленный пунктом 6.1 настоящего Порядка. 2.2. Работник, которому стало известно об изменении системы, направляет ответственному служебное сообщение с описанием изменения, датой его ввода и перечнем затронутых компонентов. Ответственный в срок [число] рабочих дней регистрирует сообщение и принимает решение о внеплановой оценке актуальности модели. 2.3. Решение о начале работы оформляется заданием, приказом или служебной запиской директора. В документе указываются информационная система, основание, применимый правовой режим (постановление № 1119 и приказ ФСТЭК России № 21 — во всех случаях; дополнительно приказ ФСТЭК России № 117, если система относится к государственным информационным системам либо иным информационным системам государственных органов, государственных унитарных предприятий или государственных учреждений), ответственный за сбор данных, разработчик, срок подготовки проекта и форма результата. 2.4. Если из сообщения невозможно определить влияние изменения, ответственный запрашивает уточнение у владельца и администратора системы. До получения сведений он не отмечает действующую модель как проверенную; неопределённость и временное решение фиксируются в журнале актуализации.

[…] Полный текст документа доступен после оплаты.