СОИБ. Анализ. Что может выбирать оператор / эксперт

Последнее время от многих экспертов слышу: чем меньше обязательных правил / требований -> тем больше свобода выбора  -> тем лучше систему обеспечения ИБ можно построить.

А зачем организации вообще обращаются к каким-то стандартам, методикам, design guide-ам или другим лучшим практикам?  Если эти ограничения делают систему хуже, зачем тогда появились все эти серии документов от ISO, NIST, SANS, OWASP, СТО БР ИББС, ГОСТ ИСО/МЭК?

Пожалуй, потому, что с ним СОИБ приобретает ряд полезных свойств:

·        Накопление и передача знаний. Даже если человек занимается безопасностью всю жизнь, он не может быть экспертом во всех областях (не касается Алексея Лукацкого)

·        Системность подхода. В информационной безопасности самые опасные инциденты начинаются с самого слабого звена, поэтому надо не забыть рассмотреть все звенья

·        Независимость системы от одного ответственного за ИБ. Если система построена полностью на базе знаний и суждений одного человека, то с его уходом  систему придется создавать заново.

·        Защита от ошибок эксперта. К сожалению, всем людям свойственно ошибаться. Обнаружив противоречие своих суждений и стандарта можно хотя-бы ещё раз внимательно подумать/перепроверить.

·        Удобство коллективной работы. Как я уже писал ранее, во время жизненного цикла СОИБ на неё оказывают влияние следующие типы лиц: Оператор, Обработчики, Подрядчики – проектировщики, Подрядчики – поставщики, Подрядчики – аутсорсеры, Производители средств защиты информации, Аудиторы, Регуляторы. Они должны взаимодействовать на одном языке (термины), одинаково понимать требования, понимать решения и аргументы другой стороны. Сколько раз сталкивался с ситуацией, что после нескольких первых этапов меняется подрядчик, говорит что всё раньше было сделано неправильно и надо переделывать с нуля. Или приходит регулятор со своим списком проверяемых документов и его не волнует что у вас документ называется “Акт установления уровня защищенности”. Если у вас нет “акта классификации” значит требования законодательства не выполняются.

Теперь посмотрим только на методики. Среди основных показателей эффективности методики можно выделить:

·        Точность в достижении цели. Следуя указаниям методики пользователь должен получать результат соответствующий целям методики.

·        Повторяемость результатов. Два пользователя для одинаковых систем должны получать одинаковые результаты

Посмотрим теперь методический документ ФСТЭК России версии 1.3 “Меры защиты информации в государственных информационных системах”.

Цели его применения:

“Методический документ применяется для выбора и реализации в соответствии с пунктом 21 Требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах, утвержденных приказом ФСТЭК России от 11 февраля 2013 г. № 17, организационных и (или) технических мер защиты информации в информационных системах, направленных на исключение:

неправомерных доступа, копирования, предоставления или распространения информации (обеспечение конфиденциальности информации);

неправомерных уничтожения или модифицирования информации (обеспечение целостности информации);

неправомерного блокирования информации (обеспечение доступности информации).”

Как я писал в предыдущих заметках, документ не помогает в выборе мер. Разделы связанные с выбором – просто скопированы из Приказа ФСТЭК России. Следующие связи отсутствуют: характеристики ИС-меры, цели обработки – меры, угрозы – меры, объекты защиты – меры.

То есть, не факт что пользователь данной методики сможет выбрать меры. А значит цели не достигаются.

Повторяемость результатов.  По сути в документе приводится только последовательность блоков действий: определение базового набора, адаптация, уточнение, дополнение. Что и как делать на каждом этапе по сути не написано.

Поэтому 10 пользователей методики взяв одну и ту же систему получат 10 разных результатов.  У одного эксперта перечень мер будет составлять пустое множество. У другого - это будет базовый набор мер. Третий подумает, что может выбирать меры по своему усмотрению. Четвертый будет пытаться обосновать каждую используемую меру актуальной угрозой. Пятый подумает, что надо обосновать каждую неиспользуемую меру. Шестой решит, что может самостоятельно определить класс системы. Седьмой подумает что это должно следовать из модели угроз. Восьмой решит что все меры должны быть регламентированы. Девятый посчитает достаточным, чтобы средства защиты имелись и лампочки горели. Регулятор в любом случае будет искать нарушения.

Да, не все действия и не весь процесс обеспечения ИБ можно формализовать.  Какие-то кусочки работ придется оставить на экспертную оценку (слишком сложны в формализации), другие на усмотрение бизнеса (экономическая оценка).

Итак, мое мнение по поводу необходимости хороших методик:

·        Обследование

o   Определение характеристик ИС – можно формализовать в методике

o   Определение состава информации обрабатываемой в ИС – можно формализовать в методике

o   Определение имеющихся мер защиты - можно формализовать в методике

o   Определение класса системы – можно формализовать в методике

o   Определение объектов защиты – можно формализовать в методике

o   Определение целей защиты - можно формализовать в методике

·        Моделирование угроз

o   Определение степени ущерба - можно формализовать в методике

o   Определение возможностей нарушителя - можно формализовать в методике

o   Определение уязвимостей информационной системы и способа реализации угрозы – (формализовать ручной анализ сложно, поэтому либо формализовать в виде автоматического сканирования защищенности либо) оставить на экспертную оценку, но формализовать возможные результаты

o   Определение возможного способа реализации угрозы – можно формализовать исходя из характеристик ИС и имеющихся мер защиты

o   Определение последствия от реализации угрозы - можно формализовать в методике, должны быть как-то связаны с определением степени ущерба

o   Определение вероятности угрозы – оставить на экспертную оценку (пока)

o   Определение актуальности угрозы - можно формализовать

o   Определение базового набора мер, необходимых для нейтрализации угрозы – можно формализовать

·        Проектирование

o   Определение базового набора мер исходя из класса  – формализовать (сделано)

o   Определение необходимости усиленных мер - можно формализовать

o   Адаптацию мер в зависимости от характеристик -  можно формализовать

o   Выбор способа и порядка реализации конкретной меры – оставить на усмотрение бизнеса или эксперта

o   Документирование меры защиты – можно формализовать

·        Анализ

o   Оценка работоспособности конкретной меры – можно формализовать

o   Оценка выполнения требований в общем - можно формализовать