Click to order
Корзина
Total: 
Контактные данные
Для улучшения работы сайта мы собираем данные cookie. Продолжая пользоваться сайтом, вы даете согласие на обработку данных в соответствии с договором.
Согласен.

Требования по безопасности информации

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

Что это такое

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

Требования ФСТЭК

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

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

Средства защиты (а также защищенные средства обработки информации) подразделяются по их стойкости на классы защиты: чем меньше номер класса, тем выше его стойкость. Соответственно, чем более высокий уровень защиты требуется для определенного сценария, тем выше должен быть класс защиты используемого сертифицированного ПО. По предыдущему положению о сертификации сертифицировались средства защиты данных (на один из шести классов защиты) и средства вычислительной техники (на один из семи классов защищенности). Для определения соответствия всех этих средств для каждого из сценариев служили таблицы соответствия. Зазубрить все эти таблицы, если честно, было непросто. Сейчас с новым положением и новыми приказами ФСТЭК стало проще: средства защиты и защищенные средства фактически сведены в общую категорию («средства обеспечения безопасности информационных технологий, включая защищенные средства обработки информации»), три их высших класса защиты предназначены для защиты государственной тайны, низшие три – для информации ограниченного доступа. Причем чаще всего уровни/классы информационной системы для обработки информации ограниченного доступа делятся на 3 класса/уровня, так что стало намного проще: 6-й класс защиты для 3-го класса информационной системы, 5-й – для 2-го и так далее. Запоминать стало проще.

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

Требования заявителя

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

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

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

Но бывает и так, что для продукта вообще нет подходящего профиля. Чаще всего это бывает с прикладным ПО, в котором есть функции защиты. Тогда требования обеспечения безопасности (защиты) информации добавляются в технические условия. Они фактически описывают продукт, его основные характеристики, в том числе функции (механизмы) защиты информации. Цель этого документа – зафиксировать заявленные характеристики продукта, на соответствие которым и будут проходить сертификационные испытания. Технические условия — это тоже конструкторский документ, его формат должен соответствовать ГОСТ 2.114-95.

Разумеется, требования заявителя к функциям защиты не могут быть какими угодно, а должны быть согласованы ФСТЭК, то есть мы имеем дело с «требованиями к требованиям». Что проверяет ФСТЭК при согласовании? Соответствие показателей функций защиты своим методическим указаниям для государственных информационных систем (от 11 февраля 2014 года), где эти указатели расписаны шире и подробнее всего. То есть если в продукте реализована какая-то функция защиты, то берется такая же функция из методических указаний, и проверяется, чтобы функция в продукте была реализована не хуже по защищенности.

Комбинированные продукты

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

Как происходит сертификация программного обеспечения ФСТЭК? Всего в процессе есть 4 роли: федеральный орган по сертификации, аккредитованные органы по сертификации, испытательные лаборатории и изготовители средств защиты. Интересно, что такая структура не вполне совпадает с той, что задана в законе о техническом регулировании, но соответствует прописанной в постановлении правительства о сертификации средств защиты.
Например, в операционную систему Red Hat Enterprise Linux (RHEL) 8 входят и межсетевой экран, и своя встроенная система управления уязвимостями. Так как продукт сертифицировался по профилю для операционных систем, эти компоненты были исключены из дистрибутива сертифицированной версии.

Выводы

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