«Общие критерии» на российской почве

«Общие критерии» на российской почве

В.Г. Грибунин, эксперт, к.т.н.

По пути наименьшего сопротивления

В последние годы по инициативе Гостехкомиссии РФ (ФСТЭК России) идет работа по приведению отечественной нормативной базы в области оценки безопасности ИТ в соответствие с международной. В рамках этого процесса осуществлен перевод стандарта ISO 15408 и предложен отечественный стан-дарт ГОСТ Р ИСО/МЭК 15408-х-2002 (так называемые «Общие критерии» — ОК). С 1 января 2004 года ОК вступили в действие.

Данный стандарт распространяется только на защиту несекретной информации, и до 2007 года организации вольны будут выбирать, на соответствие каким требованиям (изложенным в этом стандарте или перечисленным в РД Гостехкомиссии) им сертифицировать свои изделия. Также обстоит дело и с аттестацией объектов информатизации. Нельзя сказать, чтобы стандарт полностью «прижился» на почве российских информационных технологий. Существуют отдельные примеры сертификаций на соответствие этому стандарту (их можно пересчитать по пальцам одной руки), но ясного понимания того, «для чего все это нужно», на наш взгляд, пока нет. Вместе с тем, критические публикации на тему использования в России ОК встречаются редко. Обычно в статьях констатируется факт: действующие РД устарели, затем цитируются положения ГОСТ 15408, а также высказывается предположение о том, что его принятие поспособствует присоединению страны к мировому рынку.

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

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

Поэтому было принято решение идти по пути «наименьшего сопротивления», выполняя дословные переводы зарубежных документов, без оглядки на уже имеющиеся российские стандарты, сложившиеся отношения между заказчиками, разработчиками, потребителями и оценщиками IT-продуктов. Вдруг все проектирование нормативной базы оказалось необходимым вести «с чистого листа», словно ничего доселе не было. (Кстати, непонятно, почему ФСТЭК называет этот процесс «разработкой», а не «переводом»). Но, что сделано — то сделано, и теперь требуются усилия для того, чтобы этот ГОСТ «заработал». Предстоит внесение изменений в целый ряд действующих правил, а также принятие дополнительных документов, разъясняющих отдельные положения стандарта. Об этом и пойдет речь во второй части статьи.

Итак, посмотрим, какие «выигрыши» мы получаем, реализуя идею интеграции в области ИБ. При этом в дальнейшем не будем делать различия между данным курсом и принятием стандарта 15408, так как из одного непосредственно вытекает другое.

Нужна ли абстрактная безопасность?

Взаимное признание стандартов способно привести к тому, что продукты в области ИБ западных фирм хлынут на российский рынок. Конечно, наше правительство вправе отказать некоторым из них в легитимности, пусть они уже сертифицированы за рубежом (такой «люфт» допускает соглашение о международном признании стандартов), но тогда теряется смысл «присоединения». При этом ни для кого не секрет, что большинство американских фирм, доминирующих на рынке, достаточно жестко контролируются определенными госструктурами США.

Допустим даже, что с самим продуктом все «хорошо», закладки в нем отсутствуют. Однако идеология ОК свидетельствует о том, что продукт реализует набор требований по безопасности в соответствии с совокупностью возможных угроз, определенных для некоей абстрактной — «западной», между прочим, — организации. Наверняка в конкретной российской компании это набор окажется иным, а значит, продукт не будет гарантировать безопасность.

Хочется отметить следующий момент. В результате оценки с применением стандарта ОК получается формула, описывающая степень защищенности по некоторым параметрам. Оценить ее реальный уровень не представляется возможным, так как конкретное наполнение каждого элемента формулы есть интеллектуальная собственность организации, проводившей сертификационные испытания. Надо отметить, что в США использование коммерческих продуктов, оцененных по стандарту ISO 15408 государственными учреждениями, возможно лишь после их сертификации в аккредитованных АНБ- и NIST-центрах и с разрешения этих органов. И это — для несекретной информации, и это — в стране, принимавшей самое активное участие в разработке стандарта! О валидности сертификатов на криптографические продукты и говорить нечего — программа, реализующая простую подстановку, вполне получит сертификат по ОК.

Негативные последствия принятия стандарта

Во всем мире принято проводить протекционистскую политику по отношению к своим производителям. В области И Б эта политика выражается, помимо прочего, в жестко регламентированной системе лицензирования и сертификации. Российский рынок ИТ составляет 0,7% мирового, поэтому нетрудно предположить, что станет с нашими компаниями после снятия барьеров. Скорее всего, успешные фирмы окажутся скупленными «на корню» (вспомните печальную историю «Эльбруса»), продукция остальных будет неконкурентоспособна. Одна из причин заключается в существенном разрыве качества технологических процессов отечественных и зарубежных фирм. А с обеспечением технологии связано такое понятие ОК, как «уровень доверия». Очень и очень немногие российские компании способны получить сертификаты в соответствии хотя бы с относительно высоким уровнем доверия.

И далеко не факт, что наши сертификаты будут действительны на Западе. Как уже отмечалось, присоединение страны к соглашению не обязывает ее признавать все подряд сертификаты: в США, например, обязательно проведение дополнительной сертификации. Не исключено, что российские продукты в области ИБ просто окажутся в «черном списке».

Вряд ли имеет смысл ожидать дождя инвестиций в связи с взаимным признанием, ведь привлечение денег во многом зависит от предсказуемости проводимой руководством страны политики. Да и по рейтингу экономической свободы Россия занимает 124 место из 155.

О стоимости сертификации. Если сейчас оценивается лишь сам продукт, то по ОК должны рассматриваться профиль защиты (ПЗ), задание по безопасности (ЗБ) и продукт. Таким образом, цена сертификации возрастает для нашего производителя, а вот для зарубежного, наоборот, снижается (он ведь уже получил признаваемый в России сертификат у себя в стране).

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

Еще один социальный аспект заключается в обеспечении поддержки потребителей.

Утверждается, что ясность и четкость написания ПЗ и ЗБ будет способствовать непринужденной ориентации потребителя на рынке информационных продуктов. На самом деле документы, конечно, хорошо формализованы, но вот насчет «понятности» — это далеко не так. Вам приходилось читать/писать формулу изобретения? Так вот, ПЗ и ЗБ воспринимаются гораздо сложнее.

Скажем, отрывок из ПЗ звучит примерно так: «ФБО должны выполнить [выбор: «предотвращение подвергаемых аудиту событий, исключая предпринимаемые уполномоченным пользователем со специальными правами», «запись поверх самых старых записей аудита»] и [назначение: другие действия, которые нужно предпринять в случае возможного сбоя сохранения аудита] при переполнении журнала аудита». И так далее, и тому подобное на протяжении 60-200 страниц. Не правда ли, «понятный» документ?

Существуют и другие негативные стороны принятия ГОСТ Р ИСО/МЭК 15408. К их числу относится:

• увеличение затрат на повышение уровня технологического процесса разработки и испытаний IT-продуктов, переподготовку специалистов органов сертификации и испытательных лабораторий;
• использование в основном качественных показателей безопасности;
• увеличение затрат на дополнительную разработку новых методических документов.

Кому и что нужно знать из «Общих критериев»

Может сложиться впечатление, что мы являемся противниками ОК как таковых. Конечно же, нет: разработка такого документа является существенным шагом вперед в области оценки безопасности IT-изделий (имеются в виду мероприятия, проведенные международным сообществом, а не перевод стандарта на русский язык).

Главным достижением «Общих критериев» стала попытка введения системного подхода к разработкам сервисов безопасности — так называемое «проектирование сверху». Большое значение имеет систематизация функциональных требований по безопасности, а также постановка вопроса о гарантиях безопасности на всех жизненных циклах изделия.

ГОСТ Р ИСО/МЭК 15408, несомненно, будет полезен не только оценщику, но и разработчику и потребителю (особенно если он выступает в роли заказчика).

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

Вот как определены интересы игроков рынка безопасности в тексте стандарта (см. таблицу).

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

«Общие критерии» и развитие нормативной базы в области ИТ

Однако сам по себе стандарт «заработать» не может. Необходимо принятие сопутствующих документов, нужных как упомянутым участникам рынка, так и для организации всей системы обеспечения безопасности изделий ИТ в целом.

Повторимся: безопасность IT-продуктов согласно «Общим критериям» рассматривается через призму угроз. Следовательно, разработчиком должны быть сформулированы предположения о безопасности, конкретный перечень угроз и столь же конкретный перечень функциональных требований по защите, парирующих угрозы. Понятно, что было бы удобно выбирать угрозы из некоторого каталога. Однако в тексте стандарта не только не приведен такой перечень, но даже не дано определение ключевого понятия «угроза». Впрочем, еще восемь месяцев назад представители ФСТЭК заявляли о том, что разработка базовой модели угроз IT-безопасности завершена (ну и где же она?), планируется создание банка данных угроз. Конечно, у нас есть ГОСТ Р 51275-99, но в нем приведены лишь «факторы, воздействующие на информацию», и только некоторые из них можно отнести к угрозам. Так что пока проблема исчерпывающего каталога считается открытой.

В первую очередь также важно принять «Общую методологию оценки» (CEM). Судя по публикациям разработчиков, ждать ее осталось недолго. Появление этого документа будет способствовать повторяемости и сравнимости результатов оценки.

Безусловно, надо переработать документы, связанные с самим процессом сертификации (требования к участникам этого процесса, различные руководства...), определить орган по регистрации ПЗ. По сопровождению целого ряда ПЗ вообще возникает масса вопросов. Хорошо, конечно, что каждая «кухарка» вправе разработать свой ПЗ, но не приведет ли это к анархии? Как ориентироваться в потенциально большом множестве ПЗ? Как группировать их, выстраивать иерархии и т.п.?

За пределами рассмотрения ОК остался вопрос объединения базовых механизмов безопасности. Проектирование обычно идет «сверху вниз», от формулирования общих требований к выбору конкретных функциональных пакетов требований. Хотелось бы иметь методику такого перехода, равно как и методику «комплексирова-ния», когда из отдельных, надежных частей строится система. В этой связи, имеет смысл обратить внимание на подход США, где разработаны имеющие пока статус черновика рекомендации SP-800-53 (январь 2005 г.), отвечающие на вопрос: какие конкретно механизмы безопасности должны быть использованы в той или иной информационной системе государственных органов власти. Показательно, что в этих рекомендациях даже не идет речи об ОК, приведен «свой» перечень механизмов безопасности. Кстати, американцы пришли к тому, от чего мы сейчас решили отказаться: к классификации информационных систем (см. FIPS 199, принятый в конце 2003 г.). На основе выполненной классификации и выбирается множество механизмов безопасности.

Aнализ некоторых ПЗ показывает, что авторы вынуждены использовать собственные нестандартные составляющие механизмов безопасности. Причина кроется не в их «вольнодумстве», а в отсутствии во второй части стандарта подходящих классов, семейств, компонентов и элементов.

Есть над чем поработать

Совершенно непонятной остается область применимости стандарта 15408. Каков наименьший и наибольший продукт, к которому он может быть применен? Если обратиться к опыту США, то мы увидим, что диапазон разработанных ПЗ простирается от ПЗ на электронные брелоки до ПЗ на межнациональную сеть обмена информацией. Они создаются не только на классы продуктов, но и на технологии, например, ПЗ «Контролируемый доступ». Из российских публикаций последних лет следует, что по ГОСТ 15408 планируется сертифицировать автоматизированные системы предприятий и даже ведомств. Было бы правильнее каким-то образом определить границы действия стандарта.

Еще один момент, особенно важный для госучреждений, но актуальный и для коммерческих организаций. Нигде нет ответа на простой вопрос: сертификат по какому уровню доверия «позволяет» изделию обрабатывать конфиденциальную информацию? На самом деле этот вопрос следовало поставить чуть ли не в первую очередь. Очевидна необходимость его нормативного урегулирования.

Большую работу предстоит выполнить и по изменению ГОСТов, посвященных разработке автоматизированных систем (34-й, 50-й серии, СРПП, ЕСПД, ЕСКД и т.д.). Необходимо указать, на каком этапе и в каких случаях предусмотрено ПЗ, на каком — ЗБ, как эти документы согласовываются с заказчиком. Ведь есть же техническое задание на систему. Будет ли в нем присутствовать ссылка на ПЗ? Если ПЗ уже имеется, то, наверное, да, а если только планируется разработать? Опять же, за чьи деньги?

Должно быть прописано, может ли в разработке ПЗ и ЗБ принимать участие испытательная лаборатория. То есть, если смотреть на вопрос шире, вправе ли вообще испытательная лаборатория подключаться к созданию продукта на ранних стадиях его разработки. Сейчас ответ однозначный — нет, что зачастую противоречит здравому смыслу. Например, заказчик потратил большие деньги на создание аппаратного средства, а при проведении испытаний выясняется, что «нет, ребята, все не так». С другой стороны, подключение испытательной лаборатории к разработке ПЗ и ЗБ понижает независимость оценки.

Необходимо каким-то образом соотнести требования по обеспечению уровня доверия с требованиями, предъявляемыми при сертификации системы качества (ГОСТы серии 9000).

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

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

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

Взять все самое лучшее

Вне рассмотрения «Общих критериев» остались такие серьезные вопросы, как методология количественной оценки рисков заказчика, их прагматический анализ и количественные нормативы требуемой защищенности систем. Подобные оценки представляются наиболее важными для обретения гарантированной уверенности в достигаемой информационной безопасности. Элементы методологии их получения представлены в других международных стандартах, которые также не стоит слепо переносить на почву российской действительности, но целесообразно взять из них все самое лучшее. Не рассмотрены в документе и вопросы определения границ объекта оценки, анализа среды функционирования, построения модели нарушителя, оценки рисков и т.д. ГОСТ Р ИСО / МЭК 15408 -это лишь один из множества важных и взаимосвязанных стандартов в области безопасности информационных технологий, а выполнение его требований — необходимое, но далеко не достаточное условие информационной безопасности ИТ.