Алаверды Дмитрию Кузнецову про сертификацию "комбайнов" и UTM-решений

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

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

Я начну с того факта, что сертифицируется обычно законченное решение, а встраивается отдельный модуль (например, антивирусный движок). Например, есть у меня Kaspersky Endpoint Security for Windows, который сертифицирован как антивирус (и не только). Он обладает набором функций, начиная от обнаружения вредоносного кода и обновления и заканчивая системой управления, контролем состояния и т.п. Так вот когда я хочу встроить антивирус в свой продукт, я беру не весь антивирус "из коробки" с определенными контрольными суммами, а только его часть, которая позволит моему продукту обнаруживать вирусы. И, например, систему управления я выброшу, так как антивирусный движок будет интегрирован с моей системой управления. И вот уже получается, что антивирусный движок не выполняет часть требований по безопасности и у него также не совпадают контрольные суммы с тем решением, на которое и выдан сертификат ФСТЭК. Поэтому считать встраиваемый антивирусный движок сертифицированным я никак не могу.

Кстати, если вспомнить, ровно с той же проблемой столкнулась в свое время ФСБ, которая регулярно сталкивалась с некорректным использованием криптобиблиотек и в конце концов запретила сертификацию библиотек, настаивая на сертификации законченного изделия целиком. Кроме того, встраивание криптобиблиотеки в чужие решение требовало и требует отдельного ТЗ, согласованного с ФСБ, которая проверит правильность (или как часто любят говорить корректность) встраивания и только после этого выдаст сертификат. Я не очень положительно оцениваю эту схему, хотя и понимаю ее правильность с точки зрения здравого смысла. Но то, как это реализовано (долго и непрозрачно) и вызывает мою критику. Если мы встраиваем антивирусный или ids'ный движок, то встраивание тоже должно проверяться. А то вдруг встроят, а трафик на модули заворачивать не будут?..

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

Представим, что вы разработали системы класса Endpoint Protection (EPP), которая включает в свой состав антивирусный модуль. Вы не имеет экспертизы в разработке антивируса, поэтому заключаете соглашение с Лабораторией Касперского, которая вам предоставляет свою прекрасную продукцию. Так как вы разработали средство защиты сразу для двух платформ - Windows и Linux (тему с форками Linux я оставлю в стороне), то вы взяли от ЛК их два продукта - KES for Windows и KES for Linux. Обратите внимание, эти два продукта получали свои сертификаты ФСТЭК в разное время и продлевали их в разное время. Поэтому и сроки окончания их действия тоже разнятся. Если вы разработали свое средство защиты в 2015-м году и 29 февраля 2016 года (срок взят с потолка) получили сертификат, то срок его действия должен закончиться через 3 года (обычно). В такой ситуации никакой проблемы нет - оба сертификата на KES перекрывают срок действия сертификата на ваше средство защиты. А теперь представим, что вы решили (а почему бы и нет) продлить срок действия сертификата своего решения еще на 3 года. ФСТЭК пошла вам на встречу и... вы надеетесь, что получите сертификат, продленный до 29 февраля 2022 года. Но... Согласно правилам ФСТЭК сертификат вам будет выдан исходя из срока сертификата, который заканчивается раньше всех. В данном случае это будет 25.11.2019 (по сроку KES10 for Windows).

Если же вы подождали бы до конца января, то вы могли бы встроить в свой EPP новую версию KES11 for Windows, которая была сертифицирована 22 января 2019 года. Правда, тут речь идет уже о новом продукте... Я не знаю, как будет трактовать ФСТЭК эту ситуацию. Если они отнесутся к встраиванию нового продукта лояльно (а почему бы и нет - производители-то свои, патриотически настроенные), то... срок действия продленного сертификата на ваше средство защиты будет заканчиваться... нет, 22 января 2024 года, и не 29 февраля 2022 года, а 18 ноября 2020 года. Именно тогда заканчивается срок действия сертификата на KES10 for Linux.

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