09.09.09 я написал заметку о том, как 10 лет назад должна была развиваться система нормативно-методических документов ФСТЭК России. На тот момент не получилось :-( Хотя часть документов была разработана, но не принята. И вот вчера, в очередной раз разбирая свою библиотеку я наткнулся на ряд документов, которые так и остались в статусе проектов.
Первый из них - РД по обеспечению безопасности в жизненном цикле изделий ИТ. Обратите внимание на дату! 2004-й год. О безопасности на разных этапах жизненного цикла ФСТЭК начала думать уже тогда. Сейчас ФСТЭК возвращается к этой идее, а Банк России и вовсе выпускает отдельные рекомендации на эту тему.
60-тистраничный основной документ содержал очень много правильных замечаний по тому, как надо выстраивать процесс обеспечения ИБ - не в виде навесных средств защиты, к чему ФСТЭК скатилась в итоге, а виде интегрированной ИБ, которая начинается с момента задумки какой-либо информационной системы или иного ИТ-изделия.
Опираясь на ГОСТ Р ИСО/МЭК 15408 данный проект выделял 5 этапов жизненного цикла, для каждого из которых предлагались свои мероприятия по защите информации:
Этап задания требований по ИБ к изделию ИТ включает множество этапов, но каждый из них понятен и большинством компаний реализуется в той или иной степени. РД же просто систематизирует этот процесс в свод лучших практик (передового опыта).
Кстати, интересна нижняя часть этой картинки. В ней требования к безопасности разделены на три составляющие - функциональные требования (мы к ним привыкли больше всего - они понятнее), требования к доверию (это то, что так и не прижилось особо в России) и требования к среде, в которой будет функционировать изделие ИТ. Эта триада, к сожалению, не так часто всплывает в российской нормативке по ИБ, что зря. Достаточно посмотреть на тему АСУ ТП, чтобы понять, что без этой триады не обойтись. Установление обычных (функциональных) требований вопросов не вызывает. Достаточно взять документы ФСТЭК по КСИИ. Но мы понимаем, что просто взять и требовать наличия сертифицированной криптографии или обычных МСЭ в АСУ ТП нельзя - нужно учитывать требования среды. Но и ею дело не ограничивается. Нужно устанавливать еще и требования к доверию. Все-таки сканер безопасности иностранного производства, устанавливаемый на АЭС и в банке, - это две большие разницы. В первом случае необходимо контролировать происхождение продукции.
Отдельным приложением к этому РД шла 35-тистраничная базовая модель обеспечения ИБ в жизненном циуде ИТ, визуализирующая и детализирующая отдельные характеристики процесса обеспечения ИБ.
В целом, документ, даже спустя 10 лет, остается очень неплохим. И если бы его можно было реанимировать, то он мог бы составить неплохую пару с разрабатываемым ГОСТом по SDLC, который сейчас создается при ТК362.
Первый из них - РД по обеспечению безопасности в жизненном цикле изделий ИТ. Обратите внимание на дату! 2004-й год. О безопасности на разных этапах жизненного цикла ФСТЭК начала думать уже тогда. Сейчас ФСТЭК возвращается к этой идее, а Банк России и вовсе выпускает отдельные рекомендации на эту тему.
60-тистраничный основной документ содержал очень много правильных замечаний по тому, как надо выстраивать процесс обеспечения ИБ - не в виде навесных средств защиты, к чему ФСТЭК скатилась в итоге, а виде интегрированной ИБ, которая начинается с момента задумки какой-либо информационной системы или иного ИТ-изделия.
- задание требований к изделию ИТ
- разработка изделия ИТ
- ввод в действие
- эксплуатация
- снятие с эксплуатации.
Этап задания требований по ИБ к изделию ИТ включает множество этапов, но каждый из них понятен и большинством компаний реализуется в той или иной степени. РД же просто систематизирует этот процесс в свод лучших практик (передового опыта).
Отдельным приложением к этому РД шла 35-тистраничная базовая модель обеспечения ИБ в жизненном циуде ИТ, визуализирующая и детализирующая отдельные характеристики процесса обеспечения ИБ.
