Сертификация некриптографических средств защиты информации

“- На вашу программу есть сертификат ФСТЭК?

- Есть. Вас какой интересует?

- А что, они бывают разные?”

(Из бесед с заказчиками)

1. Что на что сертифицируется

Прежде всего нужно понимать, что требования о сертификации по требованиям безопасности информации распространяются не на все используемое программное обеспечение, а только на то, с помощью которого эти самые требования выполняются. Требования об использовании именно сертифицированных экземпляров средств защиты устанавливаются непосредственно в нормативных документах, устанавливающих и прочие требования безопасности. К примеру, для государственных информационных систем необходимость использования сертифицированных средств защиты установлена приказом ФСТЭК России №17 от 11.02.2013.

На сегодняшний день фактически выделены следующие виды средств защиты:

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

Для первых шести видов средств защиты существуют определенные требования информационной безопасности, установленные методическими документами ФСТЭК России. В последнем случае требования к функциям безопасности устанавливает их разработчик или поставщик, оформляя их в виде технических условий или задания по безопасности (эти документы подробнее рассмотрим дальше). Кроме требований к функциям безопасности, к средству защиты могут предъявляться дополнительные требования, например, требования по контролю отсутствия недекларированных возможностей (если проще – уязвимостей и программных закладок, далее - НДВ) определенного уровня, обеспечиваемого производителем при создании этого средства защиты. Эти требования также определены в соответствующем методическом документе ФСТЭК.

Для каждого вида средств защиты, кроме последнего, определяются несколько классов или уровней предъявляемых требований. К примеру, для межсетевых экранов установлены пять классов требований, при этом первый класс содержит максимальный объем требований безопасности, а пятый – минимальный. Таким образом, типичный сертификат соответствия содержит, как правило, два утверждения, например: “на соответствие 5 классу межсетевых экранов и 4 уровню контроля отсутствия НДВ”.

 2. Процедура сертификации

Процедура сертификации определена в Положении о сертификации средств защиты по требованиям безопасности информации, утвержденном приказом председателя Гостехкомиссии России от 27 октября 1995 г. В процедуре задействованы несколько участников.

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

Оценку соответствия средства защиты заявленным требованиям выполняет испытательная лаборатория – компания, аккредитованная ФСТЭК России в качестве испытательной лаборатории системы сертификации. Деятельность испытательной лаборатории контролирует орган по сертификации – вторая компания, также имеющая соответствующую аккредитацию. Во главе процесса стоит ФСТЭК России.

В общем случае процедура сертификации выглядит следующим образом. Разработчик, не имеющий лицензий на разработку средств защиты, заключает с одним из лицензиатов партнерский договор, в рамках которого обговариваются условия сертификации, а также поставки сертифицированных экземпляров конечному потребителю. Заявитель выбирает испытательную лабораторию (соответствующий реестр публикуется на веб-сайте ФСТЭК России), совместно с которой определяют, на соответствие каким требованиям будет проводиться сертификация и по какой схеме (о схемах – чуть позже). В результате заявитель направляет в ФСТЭК России заявку, содержащую название средства защиты, наименование методического или иного (технические условия, задание по безопасности) документа, на соответствие которому предлагается провести сертификацию, схему сертификации, а также ходатайство о назначении для проведения сертификации выбранной испытательной лаборатории.

Есть несколько причин, помимо формальных, на основании которых заявителю может быть отказано в сертификации. Вот несколько из них:

• некоторые из функций безопасности выходят за рамки компетенции ФСТЭК (например, если выполнение некоторых требований безопасности невозможно без криптографических функций, оценка которых в рамках системы сертификации ФСТЭК невозможна);
• средство защиты уже имеет действующий сертификат или уже проходит сертификацию по заявке другой компании;
• заявитель запрашивает проведение сертификации на соответствие требованиям технических условий или заданию по безопасности при наличии методических документов, определяющих требования к данному виду средств защиты, и т.п.

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

На практике применяются три схемы сертификации:

• сертификация единичного образца;
• сертификация партии изделий;
• сертификация серийного производства.

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

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

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

 3. Особенности сертификации на соответствие отдельным нормативным требованиям

 3.1. Руководящие документы Гостехкомиссии России

К настоящему моменту продолжают действовать два руководящих документа ФСТЭК России:

• руководящий документ «Средства вычислительной техники. Защита от несанкционированного доступа к информации. Показатели защищенности от несанкционированного доступа к информации»;
• руководящий документ «Средства вычислительной техники. Межсетевые экраны. Защита от несанкционированного доступа к информации. Показатели защищенности от несанкционированного доступа к информации».

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

Периодически встречаются попытки сертифицировать отдельные средства защиты на соответствие требованиям руководящего документа «Автоматизированные системы. Защита от несанкционированного доступа к информации. Классификация автоматизированных систем и требования по защите информации», а также на соответствие требованиям, предъявляемым нормативными документами ФСТЭК России к информационным системам персональных данных. Потребителям таких средств защиты следует четко понимать, что ни одно отдельно взятое средство не способно в полном объеме выполнить требования этих документов. Как правильно, сертификация в этом случае проводится на соответствие техническим условиям или заданию по безопасности (об этом – позже), в которые включаются отдельные требования нормативных документов. В этом случае в сертификате делается приписка “…и может использоваться в…” (например, в автоматизированных системах до класса 1Б включительно), однако понять, в каком именно объеме выполнены требования нормативных документов на основании только сертификата невозможно, что часто приводит к неприятным сюрпризам на стадии аттестации созданных информационных систем.

 3.2. Сертификация на соответствие техническим условиям

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

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

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

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

• спецификация (ГОСТ 19.202-78);
• описание программы (ГОСТ 19.402-78);
• описание применения (ГОСТ 19.502-78);
• пояснительная записка (ГОСТ 19.404-79);
• руководства оператора/программиста/системного программиста (ГОСТ 19.505/504/503-79 соответственно);
• формуляр (ГОСТ 2.601-95).

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

Особенность сертификации на соответствие техническим условиям заключается в том, что заявитель, как правило, не предоставляет текст технических условий потребителю средства защиты. Как уже упоминалось выше, в силу произвольности формулировок технических условий невозможно определить, в каком объеме сертифицированное средство защиты выполняет требования нормативных документов. Поэтому для успешного прохождения аттестации оператору информационной системы следует требовать от заявителя включить в комплект поставки текст технических условий, а в случае отказа – обратиться в соответствующее подразделение ФСТЭК.

 3.3. Сертификация на соответствие заданиям по безопасности и профилям защиты

В последние годы ФСТЭК России расширяет применение в системе сертификации требований ГОСТ 15408, являющийся локализацией международного стандарта ISO 15408 «Information technology -- Security techniques -- Evaluation criteria for IT security». Описание этого стандарта – тема отдельной большой статьи, поэтому остановимся только не основных моментах.

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

Есть два существенных отличия сертификации на соответствие заданию по безопасности от сертификации на соответствие техническим условиям. Первое и основное – понятие уровня доверия. Помимо требований к функциям безопасности, ГОСТ 15408 определяет требования к составу и содержанию свидетельств, которые заявитель должен предоставить испытательной лаборатории для подтверждения того, что сертифицируемое решение соответствует требованиям. Низший, первый оценочный уровень доверия примерно соответствует сертификации на соответствие техническим условиям: заявитель предоставляет испытательной лаборатории руководства администратора/пользователя и поверхностное описание того, как реализованы функции безопасности, а испытательная лаборатория подтверждает выполнение требований независимым тестированием. Для второго уровня доверия необходимо предоставить подробную проектную документацию и описание жизненного цикла разработки, прежде всего – процесса тестирования, системы управление версиями программного обеспечения и контроля версий исходных кодов. Для третьего уровня необходимо пройти аудит процесса разработки и, в частности, мер защиты, направленных на предотвращение несанкционированного изменения исходных кодов программистами. Для четвертого уровня необходимо предоставить на анализ исходные коды программного обеспечения и так далее.

При этом, в отличие от ГОСТ 19, ГОСТ 15408 предъявляет строгие требования к содержанию документов, в том числе – к тому, как именно должны быть описаны “внутренности” средства защиты. Прежде всего это касается декомпозиции программного обеспечения на подсистемы и модули, выделение интерфейсов, описание интерфейсов и взаимодействия модулей программного обеспечения между собой при выполнении функций безопасности. Такое пристальное внимание к техническим деталям приводит к сравнительно высоким трудозатратам испытательной лаборатории и, как следствие, к сравнительно высокой длительности и стоимости сертификации.

Вторым отличием данного вида сертификации является возможность демонстрации соответствия требованиям методических документов. Для этого ФСТЭК издает в качестве методических документов профили защиты – формализованные шаблоны, содержащие обязательные для выполнения определенным видом средств защиты требований к функциям безопасности, а также специализированным требованиям к свидетельствам доверия. Функциональные требования при этом также формулируются в виде шаблона, например: “должна обеспечиваться аутентификация пользователя на основе [назначение: метод аутентификации]”. При сертификации заявитель включает в задание по безопасности утверждение о соответствии своего продукта определенному профилю защиты и раскрывает в нем недооформленые требования профиля, например: “должна обеспечиваться аутентификация пользователя на основе [сопоставления папиллярных узоров с эталонными]”.

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

 3.4. Контроль отсутствия недекларированнных возможностей

Контроль отсутствия недекларированных возможностей является одной из наиболее непонятных и непрозрачных для заявителя видов сертификации – до первого самостоятельного опыта такой сертификации. Связано это с тем, что методический документ «Защита от несанкционированного доступа к информации. Часть 1. Программное обеспечение средств защиты информации. Классификация по уровню контроля отсутствия недекларированных возможностей» практически не содержит требований, которые предъявляются к сертифицируемому образцу. К примеру, согласно данному документу, третий уровень контроля включает в себя динамический анализ исходных кодов, который, в свою очередь, включает в себя “контроль выполнения функциональных объектов (процедур, функций)”. В чем должен заключаться указанный контроль и каким требованиям должен соответствовать исходный код, заявителю предлагается додумать самостоятельно.

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

В указанном выше методическом документе определены четыре уровня контроля, на соответствие которым проводится сертификация. Четвертый, низший уровень контроля, заключается в проверке двух фактов:

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

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

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

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

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

 4. Особенности внедрения и эксплуатации сертифицированных средств защиты

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

Определившись с требованиями по сертификации, следует внимательно отнестись к выбору сертифицированных решений. Есть три типовые ошибки, которые совершаются при выборе:

• использование несертифицированных экземпляров сертифицированных средств защиты;
• использование средств защиты с непригодными сертификатами;
• использование средств защиты с невыполнением сертификационных ограничений.

Первая ошибка связана с тем, что сертифицированным считается программный продукт, установленный с определенного носителя. К примеру, очень часто недобросовестные поставщики заявляют, что предлагаемая ими версия программы сертифицирована, подтверждая это записью из реестра сертификатов ФСТЭК России. Нужно четко понимать, что сертифицируется не определенная версия программы, а определенные ее экземпляры. Поставщик должен подтвердить наличие сертификата, предоставив следующие свидетельства:

• в комплект поставки сертифицированного программного средства защиты должна входить документация, включающая в себя копию сертификата и формуляр средства защиты (на листе утверждения последнего должны быть отчетливо различимы подпись должностного лица и печать соответствующего управления ФСТЭК России);
• на носитель дистрибутива программного средства защиты и корпус аппаратного средства защиты должен быть нанесен специальный защитный знак системы сертификации;
• дистрибутив программного средства защиты и аппаратное средство защиты должны соответствовать требованиям, указанным в разделе контроля основных характеристик формуляра (например, для программных средств фиксируются контрольные суммы файлов).

Только при выполнении трех перечисленных выше условий экземпляр средства защиты является сертифицированным.

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

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

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

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

Есть три варианта. Во-первых, в рамках сертифицированного производства для ряда средств защиты (например, для сертифицированных операционных систем Microsoft Windows) запущен процесс сертификации обновлений. Такие обновления устанавливать не только можно, но и требуется.

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

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

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