СЗПДн. Проектирование. Методы и способы защиты ПДн


В соответствии с «Положением о методах и способах защиты информации в информационных системах персональных данных» выбор и реализация методов и способов защиты информации в информационной системе осуществляются на основе определяемых оператором (уполномоченным лицом) угроз безопасности персональных данных (модели угроз) и в зависимости от класса информационной системы.
При этом в разделах 2 и 3 «Положения …» определены общие методы и способы, а в приложении к «Положению …» приведена детализация этих методов и способов.
Периодически возникает вопрос: каким образом на основе перечня актуальных угроз и класса ИСПДн должны определятся методы и способы защиты информации и в каком документе этот выбор должен быть зафиксирован?
В каком документе надо описывать определение выбора методов и способов защиты? Рассмотрим стандартные документы: отчет об обследовании, модель угроз и нарушителя, техническое задание на СЗПДн, эскизный или технический проект на СЗПДн.
При формировании отчета об обследовании ИСПДн угрозы ещё не определены, так что он отпадает.
Разработка проекта на СЗПДн осуществляется на основании конкретных требований к функциям СЗПДн из ТЗ. То есть на этапе разработки проекта СЗПДн определяется комплекс средств защиты и уже поздно выбирать методы и способы защиты.
Остаются следующие варианты:
1. Определить методы и способы защиты ПДн в модели угроз.
2. Определить методы и способы защиты ПДн в ТЗ на СЗПДн.
3. Определить общие методы и способы защиты ПДн в модели угроз, а детализацию методов и способов защиты ПДн в ТЗ на СЗПДн.

Комментарии

Alexey Volkov написал(а)…
> стандартные документы: отчет об обследовании, модель угроз и нарушителя, техническое задание на СЗПДн, эскизный или технический проект на СЗПДн

С моделью угроз все понятно, а вот чем регламентированы остальные документы? С чего вдруг они стали "стандартными"?
Сергей Борисов написал(а)…
По первых, есть обязательные мероприятия из НД РФ.
1. В соответствии с «Порядком проведения классификации…»:
“4. Проведение классификации информационных систем включает в себя следующие этапы:
сбор и анализ исходных данных по информационной системе”
2. В соответствии с ПП 781:
"Мероприятия по обеспечению безопасности персональных данных при их обработке в информационных системах включают в себя:
б) разработку на основе модели угроз системы защиты персональных данных, обеспечивающей нейтрализацию предполагаемых угроз с использованием методов и способов защиты персональных данных, предусмотренных для соответствующего класса информационных систем"
к) описание системы защиты персональных данных.
3. В соответствии с «Положением о методах и способах защиты информации в информационных системах персональных данных»:
“выбор и реализация методов и способов защиты информации в информационной системе осуществляются на основе определяемых оператором (уполномоченным лицом) угроз безопасности персональных данных (модели угроз) и в зависимости от класса информационной системы”

Данные мероприятия должны быть подтверждены какими-то документами.
С другой стороны у нас есть стандарты и методические документы которые определяют этапы создания АС или системы защиты: ГОСТ 34.601-90, ГОСТ Р 51583-2000, СТР-К.
В соответствии с этими стандартами и получаются “стандартные наборы документов”.
Alexey Volkov написал(а)…
> Данные мероприятия должны быть подтверждены какими-то документами.

Не должны, а желательны. У меня, например, все это "всунуто" в один документ - модель угроз. Все в соответствующих разделах. Не хотел бы - не указывал бы. И кто скажет что я не прав?

> С другой стороны у нас есть стандарты и методические документы которые определяют этапы создания АС или системы защиты: ГОСТ 34.601-90, ГОСТ Р 51583-2000, СТР-К.

СТР-К сюда не мешаем, потому как аттестовывать ИСПДн нет необходимости. А ГОСТы так же необязательны.

Получаем один документ - модель угроз. То, что консультанты пытаются впарить весьма увесиситую пачку - так она увеличивает смету ;) С другой стороны, если заказываешь консультанта, то такой набор действительно желателен. А если делаешь все сам - то по большому счету пофиг.
Сергей Борисов написал(а)…
Действительно - обязательного требования к количеству и названиям документов нет. Тут все зависит от степени зрелости организации.

Консультантам, подрядчикам, разработчикам, интеграторам приходится гарантировать некий уровень качества проектов. Для этого и используются стандарты, лучшие практики и т.п.

СТР-К как рекомендательный или методический вполне можно рассматривать.
Сергей Борисов написал(а)…
Кстати именно в СТР-К предусмотрено аналитическое обоснование, в котором есть раздел связанный с описанием мероприятий по защите.

А вот в приведенных стандартах фактически не предусмотрено описание неких общих мероприятий.

Если уж совсем дотошно расписывать порядок создания СЗПДн в соответствии со стандартами, то придется делать так:
1. Обследование и описание ИСПДн
2. Разработка модели угроз
3. Разработка ТЗ на эскизное проектирование
4. Разработка эскизного проекта защиты ПДн, в котором будут определятся общие методы и способы защиты ПДн
5. Разработка ТЗ на создание СЗПДн, в котором будут содержатся детализация методов и способов защиты ПДн
6. Разработка Технического проекта в котором будут определены конкретные средствами и меры защиты.

Так как для большинства Операторов такой перечень работ будет перебором,
и возникает вопрос куда бы ещё вставить выбор методов и способов защиты.
Alexey Volkov написал(а)…
В модель угроз - и дело в шляпе. Пусть она буде толстая и нечитаемая - пусть регулятор плачет :)

Популярные сообщения из этого блога

СКЗИ. НПА. Некоторые вопросы применения криптографии

КИИ. ОКВЭД vs 187-ФЗ

Модель угроз безопасности клиента финансовой организации