Из неопубликованного. Классификация КВО

Аватар пользователя Sedov
Автор: Седов Олег, главный редактор BISA

Из неопубликованного. Классификация КВО

(Это те откровения, которые в силу деликатности темы не нашли спикеров готовых под ними подписаться, но охотно поделившихся со мной своими мнениями в частных беседах.)

Кот священника вываливает миску на пол, раскладывает корм крестом, молится, съедает корм и ложится спать.

Кот архитектора высыпает корм, раскладывает из него архитектурный план, меняет детали местами, наконец, съедает все и ложится спать.

Кот журналиста вываливает корм из миски и немедленно съедает его, а миску загоняет за холодильник и сообщает, что достоверные источники пожелали остаться неизвестными…

 

Вы когда-нибудь задумывались, каким образом и кем выполняется процедура классификации КВО? Масса примеров, когда сама по себе процедура классификации АСУ, владельцами этих АСУ, как и ключевых систем ИТ-инфраструктуры, как правило, либо выполнена формально, либо не выполнена вовсе. С одной стороны можно сказать, что так исторически сложилось, а с другой, возможность умышленного занижения степени критичности информации, дает возможность владельцу этой АСУ аттестовать систему по низкому классу значимости. Тем самым, минимизировать требования, которые к ней предъявляются и тем самым минимизировать затраты, которые реально необходимы для построения системы защиты. Там, где эти параметры либо не проверяются, либо проверяются формально комиссиями, назначенными из состава самого владельца, все это закрыто документами.

Пожалуй, это самая важная проблема на сегодняшний день и владельцев АСУ можно понять. Во-первых, свободных денежных средств на ИБ нет. Во-вторых, все статьи расходов на защиту информации в АСУ прописывались в общих рамках информационной безопасности объекта. Т.е требования к ИБ промышленного объекта присутствовали и раньше, но они относились к информационным вычислительным сетям, к телекоммуникационным сетям и пр. для каких-то объектов в рамках самого объекта. Поэтому предполагалось, что требования к информационной безопасности могут быть выполнены теми штатными средствами, которые закладывают заказчики в свое задание. Например, он прописывает, что операционная система должна быть Windows. Таким образом, в требованиях по информационной безопасности перечисляют требования, которые изначально заложены в Windows. Если это не может быть реализовано в рамках данной программной платформы, то предъявлять дополнительные требований не имеет смысла. Во-вторых, если это отдельно никем не требуется, то обосновать затраты будет сложно.

В этих условиях создается почва для множества сомнительных предложений с одной стороны, и появляются признаки заколдованного круга с другой. Мы возвращаемся к тому, как сам для себя заказчик оценивает критичность своей системы? И если у него нет свободных средств, то он способен обосновать как одни риски, так и другие. Риски в данном случае это эквивалент ущерба. Соответственно, если владелец АСУ оценивает размер ущерба по-своему, то доказывать, что его расчеты ошибочны это задача независимой стороны. Но независимые стороны работают не бесплатно. Иначе нет смысла им платить. Вот и получается заколдованный круг. Поэтому вопрос вхождения на открытый рынок тех или иных компаний, находится в зависимости от той степени свободы, в рамках которой сами владельцы АСУ приоткрывают дверь для открытого рынка.

Оцените материал:
Total votes: 162
 
Комментарии в Facebook
 

Вы сообщаете об ошибке в следующем тексте:
Нажмите кнопку «Сообщить об ошибке», чтобы отправить сообщение. Вы также можете добавить комментарий.