Создание и аттестация ГИС - Форум по вопросам информационной безопасности

Доброго всем времени суток.
Наверняка повторяюсь, но не нашел соответствующего обсуждения.
Пишу ТЗ на создание региональной информационной системы, являющейся частью ГИС. Возник ряд вопросов, связанных с информационной безопасностью и, соответственно, 17-м приказом ФСТЭК.
1. Кто принимает решение о необходимости создания системы защиты? Владелец этой системы может решить, что защита не требуется? На основании чего?
2. Для ввода системы в эксплуатацию, ее необходимо предварительно аттестовать. Т.е. разработчик не сможет сдать систему без аттестации. Соответственно:
- в ТЗ на создание системы нужно прописать все этапы: моделирование угроз, ТЗ на систему защиты, проектирование, поставка, внедрение, аттестация?
- разработчик вынужден привлекать стороннюю организацию (лицензиата ФСТЭК), чтобы выполнить эти мероприятия?
- в ТЗ должна закладываться поставка СЗИ. Как оценить бюджет на поставку и внедрение СЗИ (т.е. стоимость ТЗ), если ничего нет и не известно, какие СЗИ и в каком количестве придется приобретать???
- если владелец ИС по своей вине не пройдет аттестацию ИС, или она сильно затянется, разработчик не сможет сдать ИС и закрыть договор??
3. Если все таки аттестовывать. Система состоит из ядра (сервера), с котором учреждения работают через браузер. Достаточно будет аттестовать ядро и разрешить доступ к нему только через защищенную ведомственную сеть? Обязывать на клиентов устанавливать СЗИ не требуется?

Много букв, но зависимость разработки и внедрения ИС от ее защиты и аттестации запутала.

Вар.1 Разработали без защиты -> Внедрили -> Защитили -> пригласили лицензиата и аттестовали
Вар.2 Разработали с защитой (с или без привлечения лицензиата) -> Внедрили -> пригласили и аттестовали
Оценить бюджет - по эскизному проекту и конечному тех.проекту (дважды, ага, ибо что-то может поменяться на любом этапе от разработки до внедрения). Разработчик не может оценить самостоятельно? Пусть приглашает специалистов (с или без лицензиата), разрабатывает ИС и систему защиты совместно и оценивает что получилось...
ЦОД + Абоненты (ядро + клиенты). В зависимости от результатов моделирования, класса защищенности ИС и кучи других факторов, можно:
- или аттестация ЦОД отдельно + аттестация "типового сегмента" с распространением результатов на все Абонентские пункты;
- или аттестация ЦОД и каждого Абонента раздельно;
- или аттестация всей ИС в комплексе без деления на ЦОД и Абонентов (извращение, ага...).
То же самое относительно внедрения СЗИ у Абонентов. Все зависит от класса ГИС + целей, задач и реализованного функционала ее работы + выводов моделирования угроз.
Необходимость о создании системы защиты расписана в 17 Приказе. Минимальный класс - К4. Минимальный набор требований там же. Но Модель угроз и нарушителей обязательна в любом случае.

Внимательно курим нормативку.

1. а) Обладатель информации (ч. 4 статьи 16 ФP-149, кто это такой - см. там же, в статье 6).

б) Обладатель информации и оператор информационной системы (если это разные лица) обязаны защищать информацию., если такое требование установлено законом. Для ГИС такое требование установлено.

2. а) Состав и содержание ТЗ определены в ГОСТ 34.602.

б) Проектирование и аттестация ИС в защищенном исполнении - лицензируемые виды деятельности. Если нет своей лицензии, организация может быть вынуждена привлечь для этих действий лицензиата. Остальное можно делать самостоятельно

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

Разумеется, опытный проектировщик накидает вам примерную спецификацию СЗИ еще на стадии написания ТЗ, но стоимость этих СЗИ, особенно если в них есть импортные компоненты, может колебаться вместе с колебанием курса рубля. Поэтому нормальные люди выделяют закупку СЗИ в отдельный контракт в рамках общего договора на создание системы, и стоимость этого контракта определяют после утверждения технического проекта.

г) Это как? Единственный вариант, который приходит в голову - это если заказчик не заключит вовремя договор с органом по аттестации или не заплатит по нему, остальное - косяки создателя системы. Но в целом, на случай затягивания проекта по вине заказчика, есть стандартные решения - оформления протокола разногласий, доп.соглашение об изменении сроков, досудебное урегулирование, суд. Разработчика ТЗ это волновать не должно..

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

Спасибо за комментарии, коллеги.
Общее мнение совпадает с моими размышлениями.

Вопросы вызвала следующая логическая цепочка, вызванная сомнениями, а можно ли сдать систему без аттестации. В большинстве случаев, разработчики ИС не являются лицензиатами ФСТЭК и не имеют опыта работ по защите. Если неаттестованную систему нельзя ввести в эксплуатацию, то нельзя и принять такую систему, пока не будут выполнены все мероприятия по защите. Это разные области деятельности, которое в этом случае приходиться объединять еще на стадии замысла и проведения конкурса на разработку ИС.

Думаю, все же стоит отделять мух от котлет, и делать отдельное ТЗ на разработку и внедрение ИС. Принимать ее в незащищенном виде. Затем уже, отдельными работами защищать ее.

Как бы да. Классическая (не сказать, что правильная, но классическая) практика: ТЗ на разработку -> ТЗ на внедрение и "обкатку" (с доработкой в случае нештатности) -> СТЗ на обеспечение безопасности (как правило, включая аттестационные испытания).
Хотя да, более верным (с позиции защищенности) является разработка функционала + безопасности единовременно, через одно ТЗ. Впрочем, аттестация все равно отдельным ТЗ обычно оформляется. Потому как аттестация - проверка соответствия выполнения требований безопасности. Если они уже реализованы, а аттестация нужна только для подтверждения, то и Заказчик вполне может принять и эксплуатировать систему уже после разработки и внедрения, но до аттестационных испытаний...