СЗПДн. Проектирование. Качественный проект
В последнее время очень часто
сталкивался со следующей ситуацией: Операторы ПДн заказывает у Лицензиата
комплект бумажек (отчет об обследовании, модель угроз, ТЗ, проект, ОРД) и
сертифицированных средств защиты по минимальной стоимости, не беспокоясь как
это будет работать и будет ли работать. Главное чтобы жопу прикрыть
защитится от Регулятора.
В результате этого у других
Операторов создается впечатление – всё что связано с СЗПДн это что-то
бесполезное, заведомо не работающее.
На самом деле это не так. Мне приходилось
участвовать в большом количестве проектов, в рамках которых внедрялись
действительно необходимые заказчику меры и СЗИ. В дальнейшем СЗПДн расширялась
или интегрировалась в общую систему обеспечения ИБ Организации.
Что можно предпринять, если вам
нужна действительно работающая СЗПДн и исполнитель - Интегратор обещает внедрить
такую систему?
Большое значение для эффективной
реализации СЗПДн имеет проект СЗПДн. При
выставлении требований к Исполнителю необходимо убедится, что проект на СЗПДн
будет содержать:
1.
описание существующей ИТ-инфраструктуры
(ситуация до внедрения СЗПДн)
2.
описание существующих средств защиты информации,
в том числе наличия сертификатов или возможности сертификации
3.
описание актуальных угроз безопасности, которые
для нейтрализации которых предназначена система
4.
описание актуальных обязательных требований,
которые должны выполняться системой
5.
описание структуры СЗПДн в целом, составляющих
её подсистем, назначения подсистем
6.
перечень выбранных средств защиты информации и
их взаимосвязь с подсистемами СЗПДн
7.
описание наличия сертификатов у выбранных
средств защиты или возможности их сертификации
8.
описание компонентов, из которых состоят
средства защиты информации
9.
описание точного количества компонентов средства
защиты информации, которые будут вновь
устанавливаться на каждом из территориально выделенных объектов Заказчика
10.
описание точного количества существующих у
Заказчика компонентов средств защиты информации, которые будут использоваться в составе СЗПДн
11.
описание предварительных мероприятий по
изменению ИТ-инфраструктуры или подготовке к внедрению средств защиты
информации (например, перенос существующего оборудования, изменения в IP-адресации, добавление новых
VLAN, переключении существующего оборудования и т.п.)
12.
перечень технических средств (АРМ, серверов и т.п.)
на которые устанавливаются программные компоненты СЗИ с идентификаторами,
позволяющими однозначно определить такие технические средства
13.
описание мест, в которые устанавливаются новые
технические средства СЗПДн c указанием идентификаторов новых технических
средств (ТС), помещений, стоек.
14.
описание физических соединений между новыми и
существующими ТС, между новыми ТС и внешними системами
15.
описание взаимодействия между компонентами в
рамках подсистемы
16.
описание взаимодействия между подсистемами
17.
описание взаимодействия СЗПДн с внешними
системами
18.
описание тех функций (из всех возможных функций)
средств защиты информации, которые будут использоваться в СЗПДн
19.
описание этапов конфигурации каждого компонента
СЗПДн
20.
описание параметров конфигурации компонентов
СЗПДн
21.
описание изменения параметров конфигурации
существующих технических средств
22.
описание возможных режимов функционирования
СЗПДн и её компонентов
23.
описание правил диагностирования и перехода
СЗПДн и её компонентов из одного режима в другой
24.
описание существенных характеристик вновь
внедряемых технических средств (производительность, форм-фактор, размеры,
потребляемая мощность и т.п.)
25.
описание мер, используемых в СЗПДн для
нейтрализации угроз, подготовленных в соответствии с требованием 3.
26.
описание
соответствия предлагаемой СЗПДн обязательным требованиям, предъявляемым к системе
27.
описание функций и ролей выполняемых персоналом
при эксплуатации и обслуживании СЗПДн
28.
расчет численности персонала, необходимого для
эксплуатации и обслуживания СЗПДн
29.
описание квалификации персонала, необходимой для
эксплуатации и обслуживания СЗПДн
30.
описания необходимых изменений в организационной
структуре Заказчика
Пункты выше приведены, не потому
что они требуются каким-то стандартом, а потому что они были бы необходимы мне
при внедрении СЗПДн. И если Исполнитель не собирается при проектировании делать приведенные выше работы, то стоит задуматься - будет ли работать ваша СЗПДн?
Правильное содержание других работ, кроме проектирования, рассмотрю в отдельных заметках.
Правильное содержание других работ, кроме проектирования, рассмотрю в отдельных заметках.
Комментарии
еще очень важный кусок проекта - эксплуатационная документация. Заказчик должен знать как работает система, и как работать с системой.
Но считаю что описание и обоснование выбора, если краткое, делается отдельным неформальным документом.
Если это нужно сделать формально и качественно - то это уже другой документ, под названием технико-экономическое обоснование создания СЗПДн. Размер его как может быть больше проекта СЗПДн.
К разработке проекта я подхожу когда меры и средства защиты уже определены.
еще говорит что при разработке проекта обязательно проводят сравнение различных вариантов, в том числе, и по экономическим показателям.
оптимальный выбор, по ГОСТу, нужно обосновывать, да и заказчику это интересно в первую очередь (не обманывают ли его? не пытаются ли продать то, что по-дороже?).
Имхо качество проекта должно быть важнее его цены, поэтому даже если подобный анализ займет много времени - он должен обязательно быть.
Но делать это необходимо ДО разработки проекта (эскизного, технического, технорабочего и т.п.)
Потому что это отдельный этап, который необходимо согласовывать с Заказчиком, получать от него подтверждение или даже менять выбор.
Получится очень глупо если ты разработаешь проект, а потом не сможешь согласовать выбор СЗИ.
На счет ГОСТ.
ГОСТы серии 2 (ЕСКД) не распространяются на СЗПДн.
Смотрим ГОСТ 2.001-93:
“4 ОБЛАСТЬ РАСПРОСТРАНЕНИЯ СТАНДАРТОВ ЕСКД
4.1 Стандарты ЕСКД распространяются на изделия машиностроения и приборостроения.”
Более подходящим будет сослаться на ГОСТ 34.601-90, который говорит что до проектирования должен быть этап разработки концепции.
"5. На этапе 2.3. "Разработка вариантов концепции АС и выбор варианта концепции АС, удовлетворяющего требованиям пользователя" в общем случае, проводят разработку альтернативных вариантов концепции создаваемой АС и планов их реализации; оценку необходимых ресурсов на их реализацию и обеспечение функционирования; оценку преимуществ и недостатков каждого варианта; определение порядка оценки качества и условий приёмки системы; оценку эффектов, получаемых от системы."
Отчетным документом к данному этапу как раз может быть ТЭО.