В последние дни что-то часто опять стала подниматься тема оценки соответствия по информационной безопасности. Поэтому решил разродиться парочкой заметок по этой теме. Давайте начнем с определения. Согласно ФЗ-184 "оценка соответствия - это прямое или косвенное определение соблюдения требований, предъявляемых к объекту". Очень простое и емкое определение, за которым скрывается очень много уровней и подводных камней. Именно эта емкость и подсказывает, что форм оценки соответствия может быть (и должно быть) больше одной.
Сегодня у нас регулятор (что ФСТЭК, что ФСБ) воспринимают только дискретную и детерминированную оценку соответствия. Есть средство защиты информации. Сняли с него контрольные суммы, зафиксировали и... "забыли" про его изменения. Во время появления 608-го Постановления Правительства "О сертификации средств защиты информации" (а это 95-й год) сертификации подлежали только средства защиты гостайны, которые не менялись годами; как, собственно, и сама защищаемая информация. Поэтому детерминизм и дискретность работали неплохо. Раз в 3 или 5 лет можно было обновлять сертификат; средство защиты обновлялись примерно с той же периодичностью. Все были довольны, всех все устраивало. Сегодня ситуация другая. Жизненный цикл разработки новых версий давно уже либо короче, либо сопоставим с длительностью сертификации. К моменту выхода сертифицированной версии, она уже успевает устареть, а то и вовсем оказаться снятой с производства. И в чем тогда сакральный смысл этой сертификации, если она не решает основной своей задачи?
Идем дальше. В 90-х понятие уязвимость хоть и существовало, но не было такого количества исследователей, инструментов, баз данных дыр. Сегодня все это есть. Дыры обнаруживаются ежедневно, а многие так скрытно и дремлют, дожидаясь своего часа. И вновь дискретность при сертификации играет злую шутку, т.к. после сертификации или в самом проверенном продукте, или в среде его функционирования может быть найдена дыра, которая сводит на нет весь процесс оценки соответствия. Сертификат есть, а смысла в нем нет, т.к. защищенность снижена.
Наконец, сегодня нередки ситуации, когда система защиты сама видоизменяется, следуя за изменчивой природой нейтрализуемых угроз. Не детерминированная и статическая, а динамическая и постоянно изменяющаяся. В такой ситуации тоже трудно зафиксировать конечное состояние, неизменность которого и будет гарантировать факт оценки соответствия. Возьмем, к примеру, некоторые средства защиты, которые при развертывании "привязываются" к своей аппаратной платформе. У них на каждом устройстве своя контрольная сумма. ПО одно и тоже. Версия одна и таже. А контрольные суммы разные. Или виртуализация. Сегодня у меня виртуальная машина со средствами защиты находится в Москве на сервере Cisco UCS C200, а завтра перекочевала в Хабаровск на сервер Cisco UCS B. Защита та же, уровень защищенности тот же. А среда функционирования поменялась. И как тут быть с текущими подходами к сертификации, принятыми в ФСТЭК и ФСБ?
Ну про проблемы с действующей системой сертификации известно не только мне - про нее и регулятор даже говорит. Вопрос в другом - делать-то что? Менять только подходы к сертификации бесперспективно. Они все равно устареют через какое-то время. Тут нужна целая стратегия и набор методов по оценке соответствия, принимаемых в зависимости от ситуации. В качестве исходных данных для выбора метода оценки соответствия я бы выбрал следующие (навскидку, не претендуя на полноту):
Ситуация с оценкой соответствия по требованиям информационной безопасности сегодня очень непростая. Угрозы усложняются и становятся скрытнее и динамичнее. Среда функционирования также эволюционирует и сложно предсказать, что будет завтра. В такой недетерминированной и недискретной среде старые методы оценки соответствия (в виде единственно признаваемой сертификации) уже не работают. Дальше ситуация будет только ухудшаться. Регуляторам, если, конечно, перед ними стоит задача повышения уровня защищенности российских организаций, а не выполнение "галочных" норм и недопущение на рынок "посторонних", нужно пересматривать свои взгляды на этот вопрос.
Сегодня у нас регулятор (что ФСТЭК, что ФСБ) воспринимают только дискретную и детерминированную оценку соответствия. Есть средство защиты информации. Сняли с него контрольные суммы, зафиксировали и... "забыли" про его изменения. Во время появления 608-го Постановления Правительства "О сертификации средств защиты информации" (а это 95-й год) сертификации подлежали только средства защиты гостайны, которые не менялись годами; как, собственно, и сама защищаемая информация. Поэтому детерминизм и дискретность работали неплохо. Раз в 3 или 5 лет можно было обновлять сертификат; средство защиты обновлялись примерно с той же периодичностью. Все были довольны, всех все устраивало. Сегодня ситуация другая. Жизненный цикл разработки новых версий давно уже либо короче, либо сопоставим с длительностью сертификации. К моменту выхода сертифицированной версии, она уже успевает устареть, а то и вовсем оказаться снятой с производства. И в чем тогда сакральный смысл этой сертификации, если она не решает основной своей задачи?
Идем дальше. В 90-х понятие уязвимость хоть и существовало, но не было такого количества исследователей, инструментов, баз данных дыр. Сегодня все это есть. Дыры обнаруживаются ежедневно, а многие так скрытно и дремлют, дожидаясь своего часа. И вновь дискретность при сертификации играет злую шутку, т.к. после сертификации или в самом проверенном продукте, или в среде его функционирования может быть найдена дыра, которая сводит на нет весь процесс оценки соответствия. Сертификат есть, а смысла в нем нет, т.к. защищенность снижена.
Наконец, сегодня нередки ситуации, когда система защиты сама видоизменяется, следуя за изменчивой природой нейтрализуемых угроз. Не детерминированная и статическая, а динамическая и постоянно изменяющаяся. В такой ситуации тоже трудно зафиксировать конечное состояние, неизменность которого и будет гарантировать факт оценки соответствия. Возьмем, к примеру, некоторые средства защиты, которые при развертывании "привязываются" к своей аппаратной платформе. У них на каждом устройстве своя контрольная сумма. ПО одно и тоже. Версия одна и таже. А контрольные суммы разные. Или виртуализация. Сегодня у меня виртуальная машина со средствами защиты находится в Москве на сервере Cisco UCS C200, а завтра перекочевала в Хабаровск на сервер Cisco UCS B. Защита та же, уровень защищенности тот же. А среда функционирования поменялась. И как тут быть с текущими подходами к сертификации, принятыми в ФСТЭК и ФСБ?
Ну про проблемы с действующей системой сертификации известно не только мне - про нее и регулятор даже говорит. Вопрос в другом - делать-то что? Менять только подходы к сертификации бесперспективно. Они все равно устареют через какое-то время. Тут нужна целая стратегия и набор методов по оценке соответствия, принимаемых в зависимости от ситуации. В качестве исходных данных для выбора метода оценки соответствия я бы выбрал следующие (навскидку, не претендуя на полноту):
- Тип потребителя. Требования для госов и бизнеса, для КВО и малых предприятий врядли будут и должны совпадать.
- Уровень значимости защищаемой информации. Общедоступные данные и гостайна требуют разных затрат и ресурсов на оценку соответствия.
- Объект защиты. ПО и облако, железо и виртуальная машина, микрочип и прикладной софт должны оцениваться по-разному.
- Этап жизненного цикла системы защиты. Вот тут требуется пояснение. У нас принято, что оценка соответствия должна проводиться либо до ввода системы защиты в промышленную эксплуатацию, либо с заданной периодичностью (например, раз в три года). А что делать в процессе эксплуатации? В условиях APT, когда между проникновением и кражей информации проходят минуты, а между проникновением и обнаружением - месяцы, столь длительные интервалы времени между оценками - непозволительная роскошь. Даже полгода и то много. Процесс оценки соответствия на этапе эксплуатации должен быть непрерывным.
- Доступность объекта оценки. Недавно один заказчик сертифицировал партию Cisco Pix по требованиям безопасности. На фоне сообщения ФСТЭК о завершении поддержки сертифицированной Windows XP факт сертификации Cisco Pix, который сняли с производства в 2008-м году, достаточно интересен, но тут важно другое. Как оценивать то, что используется, но уже не выпускается? Обычная сертификация тут не работает, но может помочь пентест в режиме черного ящика.
- Доступность стенда для развертывания объекта оценки. Вот возьмем антивирус. С его оценкой соответствия проблем особых нет - взял, поставил, погонял на стенде, получил результаты. Оставим за скобками, что в реальных условиях результаты могут быть немного иными (вот тут пример). А если у нас речь идет о системе ИБ электростанции или иного столь редкого объекта, что стенда просто нет?
- Глубина оценки. Если мне надо поискать недокументированные возможности в исходном коде, то уровень такой проверки может быть совершенно разный (опять же зависит от задач). Можно замутить многомесячные сертификационные испытания на отсутствие НДВ (и пропустить при этом кучу уязвимостей), а можно прогнать софт с помощью облачного Appercut и оперативно получить экспресс-оценку всего за несколько часов.
- Оценщик. Наконец, важно понимать, что оценку может проводить не только внешняя организация. Иногда достаточно и самооценки. При соблюдении определенных условий она может быть вполне адекватной и независимой. Но при этом может быть организована оперативнее, дешевле, а местами и эффективнее.
Ситуация с оценкой соответствия по требованиям информационной безопасности сегодня очень непростая. Угрозы усложняются и становятся скрытнее и динамичнее. Среда функционирования также эволюционирует и сложно предсказать, что будет завтра. В такой недетерминированной и недискретной среде старые методы оценки соответствия (в виде единственно признаваемой сертификации) уже не работают. Дальше ситуация будет только ухудшаться. Регуляторам, если, конечно, перед ними стоит задача повышения уровня защищенности российских организаций, а не выполнение "галочных" норм и недопущение на рынок "посторонних", нужно пересматривать свои взгляды на этот вопрос.
5 коммент.:
Прежде всего, необходимо осознать очень важный вопрос. И звучит он примерно так:
Оценка соответствия и защищенность это разные понятия.
Между понятиями Требования, Оценка и Защищенность растет пропасть.
Формула: Повышаем доверие за счет оценки соответствия требованиям так же распадается.
Защищенность - динамический показатель относительно целевой системы в конкретный момент времени в конкретном состоянии среды функционирования.
Не нужно оценке требованиям приклеивать понятие защищенности. Иными словами, оценка того, что автомобиль зеленый - 100% но это не говорит о том, что он вообще заведется и проедет 100 метров.
Женя, в идеале, я оцениваю соответствие, чтобы быть уверенным в защищенности
Ты же знаешь, чтобы быть уверенным в защищенности, нужно оценивать защищенность...
А чтобы быть уверенным в соответствии, надо оценивать соответствие
Мб следует пойти по пути упрощения сертификации? т.е. признать, что сертификат не говорит о том что средство не содержит дыр вообще, а что оно не содержит некоего ряда (широко)известных уязвимостей. И что изделие допускается к применению при условии использования в соответствии с эксплуатационной документации, в т.ч. обновления ПО. А в случае с гостайной подобные изделия разных изкотовителей можно например "каскадировать" с целью нивелирования уязвимостей, для каждого процесса (типа многовендорной защиты).
Отправить комментарий