И тоже об иллюзиях в сертификации средств защиты

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

• "чтобы сертифицировать на класс 5 и выше средство защиты с встроенными чужими антивирусными модулями, заявитель обязан представить исходные тексты каждого из модулей" и
• "сертифицировать UTM и NGFW практически невозможно"

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

Как проходит "сертификация по требованиям ФСТЭК"

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

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

...должны блокировать неразрешенный информационный поток по протоколу передачи гипертекста, путем [выбор:
а) блокирования запроса по протоколу передачи гипертекста;
б) разрыва сетевого соединения;
в) перезапуска сетевого соединения;
г) блокирования взаимодействия с конкретным сетевым адресом;
д) блокирование сессии на уровне конкретного приложения;
е) блокирование взаимодействия на уровне конкретного пользователя приложения;
ж) отправка управляющего сигнала на иной МЭ для блокирования неразрешенного информационного потока;
з) [назначение: другой способ]]

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

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

• ОУД1: "мамой клянусь!" (анализируются руководства администратора/пользователя, проводится выборочное тестирование)
• ОУД2: ОУД1 плюс анализируется проектная документация и проводится полное тестирование;
• ОУД3: ОУД2 плюс анализируется жизненный цикл разработки;
• ОУД4: ОУД3 плюс анализируются исходные коды.

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

Так вот, о нюансах...

"Мы делили апельсин, много наших полегло"

Предположим, что мы хотим сертифицировать комбайн, например - какой-нибудь UTM с антивирусным модулем и модулем IDS.

Такое комбинированное решение относится сразу к двум видам специальных средств защиты: оно одновременно является и антивирусом и средством обнаружения вторжений. Если оно заявляется как единый комплекс, то и сертифицируется как единый комплекс. Для этого в задание по безопасности включаются требования из обоих профилей защиты (на антивирусы и на СОВ), вписывается утверждение о соответствии одновременно двум профилям защиты и устанавливается максимальный из двух уровней доверия, которые установлены в этих двух профилях. Соответственно, ко всем трем модулям (платформе, IDS и AV) предъявляются одинаковые требования доверия. При этом никого не волнует, сами во разработали эти модули или позаимствовали по лицензии: если вы сертифицируетесь на ОУД4, то должны предоставлять исходные коды и на платформу, и на IDS, и на AV. Это не новшество, так оно и было изначально и в Common Criteria, и в ISO/ГОСТ 15408.

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

А что делать, если вы используете чужие модули и у вас нет доступа к документации и исходникам, необходимым для нужного вам уровня доверия? Для этого во всех схемах сертификации СС/ISO 15408/ГОСТ 15408 есть трюк, который называется "разделение на объект оценки и среду"

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

Отмечу: таким способом заявитель решает свои проблемы, но не проблемы своих заказчиков. Последним все равно понадобятся сертификаты и на модуль IDS, и на модуль AV. Такой трюк используется довольно часто, но упоминавшийся Алексеем PT MultiScanner сертифицируется по самому первому варианту.

"Все или ничего"

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

Давным давно, когда аббревиатуру NGFW еще не придумали, один известный вендор злоупотребил приемом "а ТУ я вам не покажу". Суть приема очень проста: вы заявляете на сертификацию комплексное решение (DPI, IDS, DLC, AV, IPSec и т.п. в одном флаконе), указав в ТУ единственную (утрирую) функцию: например, пакетную фильтрацию. Получив сертификат, бегаете по рынку с радостными криками, что ФСТЭК сертифицировал все предлагаемые вами радости жизни. А ТУ... "Фиг вам, а не ТУ почитать, коммерческая тайна". В принципе, так поступают многие, но втихую - но этот вендор уж слишком активно пытался продаваться в госы, и ФСТЭК вскоре это лазейку закрыла.

Это затруднило сертификацию решений, которые содержат наборы модулей, динамически активируемых и деактивируемых опциями лицензии. Действительно, самый честный путь - это сертификация всего набора модулей. Именно так работает MaxPatrol 8: с дистрибутива устанавливаются все модули, а какие именно будут работать - определяется опциями лицензии, привязанной к данному экземпляру. MP Local Update Server может превратиться в MP Scanner без установки дополнительных бинарников одним только переключением опций лицензии. Соответственно, сертфицированы все модули, и нас это устраивало с самого начала.

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

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

А что же действительно изменится?

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

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

Сейчас идет последнее обсуждение методики анализа уязвимостей, в первом квартале ожидается ее принятие. Методика определяет шесть уровней глубины анализа (от "мамой клянусь, нет уязвимостей" на шестом до глубокого динамического анализа кода на первом). Уже на пятом уровне должно будет проводиться фаззинг-тестирование (т.е. поиск уязвимостей нулевого дня методом черного ящика), а начиная с четвертого - анализ исходных кодов.

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

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

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