Доклады, выступления, видео и электронные публикации

Вопросы сертификации - что, как и зачем

Вопросы сертификации - что, как и зачем

Много лет тому назад (а именно - 13) мы получали свой первый сертификат на наше изделие. У выданного нам сертификата Гостехкомиссии был номер 15, что говорит само за себя. Кажется, это был первый сертификат, выданный на коммерческий продукт. Помнится и процедура подготовки документов, и многократные и длительные совещания рабочих групп, анализ исходных текстов и почти дословно - итоговое заседание комиссии под председательством Александра Ивановича Ефимова. Сертификат был напечатан даже не на бланке, а на обычном листе бумаги, даже, кажется, не на компьютере, а на пишущей машинке, и подписан Виктором Александровичем Вирковским. Вручал сертификат в торжественной обстановке Арнольд Петрович Каландин.

Много лет уже прошло. Первое изделие положило начало серии, которая выпускается и сейчас, и, хочется верить, будет выпускаться и впредь. Номера сертификатов давно перешагнули за тысячу, хотя вряд ли кто из специалистов сможет перечислить хотя бы десяток изделий, которые действительно широко применяются. Среди известных сертификатов есть разные - многие из них вызывают уважение, а некоторые - изумление. К последним, на мой взгляд, относятся сертификаты на так называемые <встроенные> средства защиты.

Этот вопрос поднимался на конференции в Сочи. Представитель одной из коммерческих организаций предложил отказаться от использования <наложенных> средств защиты, считая, что встроенные в операционную систему возможности достаточны для обеспечения высокого уровня защищенности. Так как эта позиция начинает озвучиваться все чаще, считаю абсолютно необходимым провести анализ источников, решений и последствий возможной реализации этой идеи. Позицию свою определю так: попытка защитить программные средства другими программными средствами эквивалентна, по своим результатам, попытке вытащить себя самого за волосы из болота, и в силу этой эквивалентности получила название - <синдром Мюнгхаузена>. Это тяжелая техническая болезнь, проявляющаяся в имитации мероприятий по защите, а не в их выполнении. Болезнь опасна, так как имитация обычно осуществляется за деньги бюджетов разных уровней, и заразна - в силу простоты имитации.

В дальнейшем это мнение постараюсь обосновать.

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

Возможно, это манипуляция с понятием <необходимый уровень защиты> - то есть, что для обеспечения некоторого уровня защиты можно использовать <встроенные> средства, так как они, например, дешевле. Рассмотрим эту постановку.

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

Таким образом, речь идет об уровне, необходимом для защиты персональных данных.

Чтобы ощутить всю опасность такого подхода, вспомним два часто упоминаемых феномена - компьютерную преступность и кибертерроризм.

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

Перед тем, оценить последствия применения только встроенных средств защиты, сузим предметную область, отказавшись рассматривать несертифицированные решения. При этом обнаружим, что в природе существует одна группа сертификатов, основной из которых - на встроенные средства - это сертификат № 844/2 от 3 декабря 2007 года (удостоверяющий, что ОС Windows XP Professional является программным средством общего назначения со встроенными средствами защиты от несанкционированного доступа к конфиденциальной информации, соответствует заданию по безопасности MS.Win_XP.3Б и имеет оценочный уровень доверия ОУД 1 (усиленный)). Таким образом, речь идет о возможности применения Windows XP для защиты персональных данных.

Фундаментальным понятием безопасности (защищенности) является доверие. Это связано с человеком как субъектом безопасности. Любая защита, сколь бы надежной она ни была, не создаст ощущения безопасности, если человек ей не доверяет.

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

А вот доверие к продукту зависит от доверия к технологии - например, от применения сертифицированной ЭЦП или специальных каналов доставки. В подлинности купюры, получаемой в Сбербанке, можно не сомневаться. Пачка банкнот в руках <барсеточника> - почти наверняка <кукла>. Если Вы <барсеточникам> доверяете - быть проблемам.

Доверие обеспечивается двумя составляющими - возможностью проверки и продолжительным положительным опытом.

Научные исследования показали, что работа программиста является одной из самых сложных в нашем мире (сложнее только работа крупных руководителей и политиков - так как сложность работы связана с необходимостью постоянного принятия решений, последствия которых проявятся, может быть, через годы). Сложность программного обеспечения экспоненциально зависит от количества команд, его составляющих. Естественно, аналогично оценивается сложность проверки программного обеспечения. Это означает, что достаточно несложно проверить правильность программы в тысячу строк, но невозможно сделать это для программы в миллион строк.

Конечно, можно прилагать усилия для автоматизации процесса проверки, однако и это путь абсолютно неперспективный. Вряд ли, даже из лучших побуждений, удастся отменить фундаментальную теорему Геделя о неполноте и следующий из нее вывод о неразрешимости задачи о самоприменимости. Нельзя написать программу, которая может установить правильность себя самой.

Таким образом, достоверно проверить такой сложный объект, как операционная система, невозможно. О каком же доверии тогда можно говорить? Нельзя доверять непроверенным продуктам.

Несмотря на очевидные выводы, странные сертификаты все же появляются.

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

Так что, неужели сертификат был выписан неправильно? Или исследования проводились не в полном объеме?

Для того, чтобы понять, о чем действительно сообщает нам сертификат № 844/2 от 3 декабря 2007 года, рассмотрим раздел <детализация оценочных уровней доверия> документа <Общие критерии>. Итак, что же определяет словосочетание <ОУД1 усиленный>? Как определяет оценочные уровни стандарт?

Согласно стандарта, оценочный уровень доверия 1 (ОУД1) - это уровень, предусматривающий функциональное тестирование. ОУД1 применим, когда требуется некоторая уверенность в правильном функционировании, а угрозы безопасности не рассматривают как серьезные (здесь и далее выделено мной. - В. К.). И далее: <ОУД1 обеспечивает оценку ОО (объекта оценки) в том виде, в каком он доступен потребителю, путем независимого тестирования на соответствие спецификации и экспертизы представленной документации. Предполагается, что оценка может успешно проводиться без помощи разработчика ОО и с минимальными затратами>.

Я воспринимаю этот текст следующим образом. Уровень доверия ОУД1 устанавливается в том случае, если организация, которая проводит независимое тестирование, может подтвердить, что программное обеспечение просто работает, причем в условиях отсутствия сколько-нибудь серьезных угроз. Ну и зачем нам такой сертификат? Однако, возможно, все решает приставка <усиленный>. Рассмотрим и это предположение.

Как известно, чем выше уровень, указанный в сертификате, тем выше защищенность объекта оценки[1]. Самый высокий уровень, таким образом, ОУД7, а самый низкий - ОУД1. ОУД1 усиленный (логично предположить) находится где-то между ОУД1 и ОУД2. Что же такое ОУД2?

Опять же согласно стандарта, это уровень, <предусматривающий структурное тестирование. ОУД2 содержит требование сотрудничества с разработчиком для получения информации о проекте и результатах тестирования, но при этом не следует требовать от разработчика усилий, превышающих обычную коммерческую практику>. И далее: <Поэтому ОУД2 применим в случаях, когда разработчикам или пользователям требуется независимо подтверждаемый уровень доверия от невысокого до умеренного при отсутствии доступа к полной документации по разработке>.

Кажется, комментарии и не требуются. Действительно, сертификат № 844/2 от 3 декабря 2007 года подтверждает, что уровень доверия к защитным функциям ОС Windows XP, выработанный в результате проверки функционирования упомянутой ОС, невысокий. Да и откуда взяться высокому, ведь с функционированием этой ОС многие сталкиваются каждый день, и явное тайным сделать нельзя. Понятна и позиция ФСТЭК, выдавшей этот сертификат - здесь нет ни капли натяжки или, тем более, неправды. Ну да, невысокий уровень доверия, а что сделаешь? Документации нет, доступа к исходным кодам нет, обновления (читай - исправления ошибок) идут нескончаемым потоком - выше уровень нельзя присвоить. Проблема только в одном - а как общество воспринимает данный сертификат, питая чувство глубокого доверия к сертификатам Гостехкомиссии (ФСТЭК)? Не ошибется ли потенциальный заказчик, которому вместо сертификата на соответствие требованиям к классу 3 предъявят сертификат по ОУД1? Ведь с точки зрения заказчика, ему важно, чтобы сертификат ФСТЭК был, а не был какой-то конкретно.

Условно описать объект защиты можно как совокупность защищенных сегментов сети, которые обмениваются сообщениями по открытой сети, например, с помощью Outlook.

Если бы разработчик исходил из требований РД, он предусмотрел бы, как минимум, следующие мероприятия по защите от НСД:

1. Защищенные сегменты должны быть отделены от открытой сети межсетевым экраном, сертифицированным по классу не ниже 4-го.

2. Компьютеры защищенного сегмента должны быть защищены по требованиям класса 1Г, что предполагает выполнение доверенных процедур идентификации/аутентификации, контроля целостности аппаратной и программной среды, контроля доступа к защищаемым ресурсам, регистрации (входа (выхода) в систему (из системы), выдачи печатных (графических) документов на <твердую> копию; запуска (завершения) программ и процессов; попыток доступа к защищаемым файлам; попыток доступа к дополнительным защищаемым объектам доступа), а также очистки (обнуления, обезличивания) освобождаемых областей оперативной памяти ЭВМ и внешних накопителей.

Конечно, выполнение этих требований можно заменить на соответствие <Общим критериям>, однако, по какому уровню доверия? ОУД1? Смотри выше. Думается, что проверка функционирования и перечисленные выше требования сильно различаются, и не в пользу ОУД1.

Как и ожидалось, в данном случае применение <Общих критериев> для сертификации средств защиты значительно снижает планку требований. На первом этапе для участников рынка это безболезненно - по низким критериям легко сертифицировать средства, выполненные на хорошем уровне. Но дальше будет хуже - снизятся требования, станут неразличимыми плохие и хорошие средства, более того, плохие средства на основе сертификатов станут идентифицироваться как хорошие, хорошие, как более дорогие, станут ухудшаться, чтобы конкурировать по деньгам, а не по качеству, и в результате защищенность наших систем упадет до уровня западных. Мы этого добиваемся?

Посмотрим теперь, что же нужно сделать, что бы обеспечить доверенную среду исполнения <сертифицированной> ОС.

Обратим внимание, что операционная среда далеко не статична. По заявлениям представителей Microsoft, обновления ОС выходят в настоящее время ежемесячно. Обновления предназначены не для занимательной игры в увеличение трафика и загрузки сервера компании, а для блокирования обнаруженных уязвимостей. Обновления нужно устанавливать. С точки зрения доверенности среды, изменение ее состава требует полной перенастройки окружения, то есть новых и новых затрат. Действительно, было бы неразумным пытаться контролировать динамическую среду статическими методами.

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

Таким образом, цена владения <сертифицированной> ОС со <встроенными> средствами защиты складывается из:

- стоимости ОС;

- стоимости установки и наладки;

- стоимостей периодических обновлений и наладок.

В этом случае цена владения уже через год после начала эксплуатации превысит затраты даже на самую сложную и дорогую <наложенную> СЗИ.

Обеспечить безопасность использования универсальной ОС можно и другим путем - установить некоторое дополнительное настроечное средство, которое перед эксплуатацией будет отключать <опасные> функции и сервисы операционной системы.

Очевидно, что сужение функциональных характеристик ОС - не лучший механизм ее сертификации. Очевидно, что пользователь при первом же удобном случае снимет ограничения, чтобы обеспечить приемлемый сервис в работе. В скором времени произойдет утечка, и вот тут-то виноватый легко найдется - им окажется потребитель, то есть тот же орган госвласти, который понадеялся на профессионализм исполнителей и даже заплатил за это. В некоторых молодежных кругах это называется <подстава>.

Девальвация доверия к государственным сертификатам - вот социальная цена такой политики.

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

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


[1] Отметим при этом, что так установлено лишь в данном случае. Например, согласно РД СВТ, классы защищенности повышаются от практически не защищенного класса 6 до самого защищенного класса 1. Этот механизм усиливается и буквенными обозначениями, т.е. для всех, знакомых с классификацией РД АС очевидно, что уровень защищенности 2А выше, чем 2Б и ниже, чем 1А. Похожий механизм принимается и в известной модели мандатного доступа Белла-Лападула, описывающей широко применяемый в реальной жизни регламентированный доступ к документам. Здесь тоже грифы документов и допуски сотрудников возрастают в порядке уменьшения цифрового индекса - то есть допуск с индексом <3> в соответствии с моделью Белла-Лападула меньше допуска с индексом <2>. Именно поэтому в сертификате по <Общим критериям> обозначение <ОУД1> воспринимается как вполне серьезный класс, а уж <усиленный> - и подавно!

Авторы: Конявский В. А.; Фролов Д. Б.

Дата публикации: 01.01.2007

Библиографическая ссылка: Конявский В. А., Фролов Д. Б. Вопросы сертификации – что, как и зачем // Безопасность сетей и средств связи. 2007. Вып. 2. С. 46–49.


Scientia potestas est
Кнопка связи