С техническим заданием на создание СЗИ обычно случается перекос в одну из двух сторон. Либо его превращают в формальный документ ради комплекта, который никто потом не открывает, либо пытаются впихнуть в него вообще всё: от общих фраз о важности безопасности до детальных настроек, которые ещё даже не определены. В обоих случаях ТЗ перестаёт быть рабочим…
Политику информационной безопасности любят либо переоценивать, либо недооценивать. В одном случае из неё пытаются сделать главный документ обо всём сразу: от принципов защиты до описания ролей, журналов, резервного копирования, схем, технических мер и реакций на инциденты. В другом — превращают её в короткий декларативный лист с общими фразами, который формально существует, но реально ни на…
С актом отнесения информационной системы к классу обычно происходит одна и та же неприятная история. Его воспринимают как стартовую формальность, которую нужно быстро подписать, чтобы перейти к «настоящей работе» — схемам, мерам защиты, настройкам и аттестации. На практике всё наоборот. Если акт сделан поверхностно или подгонялся под заранее выбранное решение, дальше начинает расходиться вся логика…
Если со структурной схемой чаще всего ошибаются из-за упрощения физической картины, то с логической всё происходит наоборот: её перегружают. В неё пытаются встроить всё сразу — от ролей пользователей до описания прикладной логики и сетевых маршрутов уровня, который уже неудобно читать даже самому владельцу ИС. В результате документ вроде бы подробный, но по нему невозможно…
Со структурной схемой информационной системы обычно происходит одна и та же неприятная вещь: её начинают рисовать слишком поздно и слишком формально. Когда система уже описана кусками в разных документах, когда часть решений принята устно, часть — “и так всем понятна”, а часть вообще живёт только в голове администратора, схема превращается не в инструмент понимания, а…
Ошибка с границами информационной системы почти никогда не выглядит как ошибка в моменте. На старте всё кажется понятным: вот серверы, вот пользователи, вот приложение, вот межсетевой экран. Но потом именно из-за этой мнимой понятности начинают расходиться схемы, документы и фактическая среда. В проекте одно, в эксплуатации другое, на аттестации всплывает третье. И почти всегда корень…
Ниже приведена рабочая последовательность действий (точнее один из вариантов) для владельца информационной системы, который самостоятельно организует проектирование, создание и аттестацию системы защиты информации по приказу ОАЦ № 66. Здесь сознательно нет широкой таблицы: для такого объёма текста она неудобна и плохо читается в обычной колонке сайта. Последовательность этапов Организационный старт. Сначала нужно определить, кто внутри…
Когда владелец информационной системы решает идти по приказу ОАЦ № 66 самостоятельно, основная проблема обычно возникает не в конце, на аттестации, а в самом начале. Работа стартует без нормального маршрута: кто-то сразу берётся за документы, кто-то — за подбор средств защиты, кто-то — за схемы или журналы. Внешне это похоже на движение, но по сути…
Если владелец информационной системы собирается самостоятельно пройти путь от идеи защиты до аттестации, самая опасная ошибка — начинать не с маршрута, а с отдельных задач. Сначала пишут приказы, потом обсуждают средства защиты, затем вспоминают про схемы, потом про аттестацию, а в итоге оказывается, что работа шла не по порядку. Приказ ОАЦ № 66 полезен именно…
В экспертной среде работа с Приказом ОАЦ № 66 часто сводится к попытке прочитать его как статичный перечень технических мер, которые нужно просто «закрыть» покупкой оборудования. Однако Приказ № 66 — это не список покупок, а алгоритм действий. Ошибка здесь в том, что внимание фокусируется на формальном соответствии пунктам, а не на последовательности этапов создания…
