Россия перешла на "Общие критерии" (ГОСТ Р 15408-2002)

Истоки и стимулы принятия

Годом рождения стандарта можно считать 1990-й - именно тогда были начаты работы по созданию стандарта в области оценки безопасности информационных технологий (ИТ) под эгидой Международной организации по стандартизации (ИСО). Этот документ и был переведен и взят за основу при разработке ГОСТ/ИСО МЭК 15408-2002. Название стандарта сложилось исторически. Работы над ним велись при содействии государственных организаций по стандартизации США, Канады, Великобритании, Франции, Германии и Голландии и преследовали следующие концептуальные цели:

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

Заметим также, что спецификации стандарта обобщили основные положения и опыт использования "Оранжевой книги" и ее интерпретаций, развили оценочные уровни доверия Европейских критериев, воплотили концепцию типовых профилей защиты Федеральных критериев США. Именно потому стандарт и получил название "Общие критерии" (ОК). Первая его версия датирована январем 1996 г., в мае 1998 г. появляется вторая версия ОК, и, наконец, в июне 1999 г. был принят международный стандарт ИСО/МЭК 15408.

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

Как упоминалось выше, российский стандарт носит название ГОСТ Р ИСО/МЭК 15408 "Общие критерии оценки безопасности информационных технологий" и представляет собой точный перевод международного стандарта. Он принят постановлением Госстандарта России от 4.04.2002 г. № 133-ст с датой введения в действие 1 января 2004 г. Заметим, что появление этого ГОСТ отражает не только процесс совершенствования российских стандартов с использованием международного опыта, но и часть правительственной программы по вступлению России в ВТО (как известно, при вступлении в эту организацию в стране-претенденте должны быть унифицированы пошлины, налоги, стандарты на производство, стандарты качества и некоторые стандарты в области информационной безопасности).

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

Основные понятия

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

Профили

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

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

Каталог ФБО

Все механизмы защиты, описанные в профиле, называются функциями безопасности объекта (ФБО). Автор профиля не выдумывает ФБО, а берет их из специального "каталога" функций безопасности, который входит составной частью в "Общие критерии" (2-я часть ГОСТ). В данном "каталоге" функции безопасности описаны достаточно жестко и формально. В то же время в этих спецификациях приведены формальные и жесткие правила, которые позволяют "модернизировать" функции безопасности, по сути - уточнить и конкретизировать, сделав их адекватными требованиям к конкретному механизму защиты.

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

Угрозы, политики и предположения безопасности

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

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

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

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

Уровень доверия

Кроме функций безопасности, в структуру документа, описывающего профиль защиты, входит раздел "Требования доверия к безопасности". Эти требования, как и функции безопасности, выбираются разработчиком профиля из "каталога" требований доверия, фактически составляющего всю третью часть "Общих критериев". Однако, в отличие от "формального" набора функций, для требований доверия в стандарте сформированы определенные наборы, которые называются "Оценочными уровнями доверия" (ОУД). Самый низкий уровень доверия - 1-й, самый высокий - 7-й.

Если провести аналогию с определениями, уже знакомыми нам по руководящим документам (РД) Гостехкомиссии РФ, то ОУД имеют много общего с уровнями проверки недекларированных возможностей (см. РД Гостехкомиссии России "Защита от несанкционированного доступа к информации. Часть 1. Программное обеспечение средств защиты информации. Классификация по уровню контроля отсутствия недекларируемых возможностей").

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

Задание по безопасности

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

Качество жизни

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

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

Порядок аттестации объектов

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

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

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

Сертификация Windows XP по "Общим критериям"

Как сообщалось, 22 января 2004 г. ОС Microsoft Windows XP прошла сертификацию. Сертификат № 844 подтверждает, что Windows XP Professional (Service Pack 1a) соответствует заданию по безопасности MS.Win_XP_SP1a.ЗБ. Но: внимание! В сертификате указано, что сертифицирована партия Windows XP из 300 штук. Заявитель - ФГУП "Предприятие по поставкам продукции Управления делами Президента Российской Федерации". Вывод: на рынке сейчас отсутствует сертифицированная ОС Windows XP.

Последствия для рынка

Для производителей СЗИ

Чтобы уяснить себе последствия перехода на сертификацию СЗИ по ГОСТ 15408-2000 для производителей СЗИ, необходимо вкратце описать некоторые стороны порядка сертификации по "старым" нормативам. Ранее существовали (и пока продолжают действовать) несколько РД Гостехкомиссии, которые определяли требования, например, для межсетевых экранов, для систем защиты информации от несанкционированного доступа, для антивирусов и т. д. Данные требования, однажды созданные, содержали небольшой и при этом статичный набор, который не изменялся со временем, несмотря на появление новых угроз, видов атак и даже функций безопасности самого продукта.

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

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

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

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

Для потребителей СЗИ

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

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

ОК или РД - что применять?

Новый ГОСТ вступил в силу с начала 2004 г. Однако пока руководствоваться им могут лишь организации, которые не обрабатывают в своих автоматизированных системах данные, содержащие сведения, представляющие собой государственную тайну. Для госструктур, которые имеют дело с подобной информацией, остаются в силе прежние РД Гостехкомиссии и требования ФСБ (и бывшего ФАПСИ).

До 2007 г. организации, в ИС которых циркулирует конфиденциальная информация, могут выбирать самостоятельно - на какие руководящие документы им ориентироваться и по каким стандартам (старым или новым) аттестовывать свои автоматизированные системы.

Но рано или поздно все организации, работающие с конфиденциальной информацией (см. определение видов информации в Законе "Об информации, информатизации и защите информации"), будут аттестовывать свои ИС по "Общим критериям". А поскольку переход на новую нормативную базу всегда бывает в той или степени болезненным, то компании небольшого и среднего размера еще некоторое время, вероятно, постараются избегать нововведений.

Первыми кандидатами на аттестацию по "Общим критериям" станут организации, внимание к которым со стороны различных проверяющих органов традиционно велико. Это министерства, "полугосударственные" банки и другие очень крупные организации с большой государственной долей в уставном капитале - ведь они обязаны быть образцово законопослушными. Как следствие, они не смогут остаться "в тени" старых РД и фактически будут вынуждены одними из первых аттестовывать свои ИС по новому ГОСТ.

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

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

Вместо эпилога

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

Кроме того, стандарт ориентирован прежде всего на достаточно крупные, комплексные системы. Применение его к конкретным подсистемам ИБ, по примеру того, как это делалось в РД, не совсем корректно. Отдельные вопросы вызывает также декларированная в "Общих критериях" система доверия, начальный уровень которой практически подразумевает лишь то, что некоторые механизмы обеспечения безопасности определены в "Руководстве администратора":

Что ж, видимо, и в вопросе о том, в какую сторону потянет нас принятие новых стандартов, реальным арбитром станет время...