Дима в своей заметке упомянул, что есть два подхода при сертификации комбайна — использовать уже сертифицированные компоненты (и тогда их не надо сертифицировать в составе комбайна) или сертифицировать как интеграционную платформу. Второй метод я оставлю в сторону — на мой взгляд, так это чистой воды обход требований регулятора (пусть и законный). Но оставлю это в стороне, такой фокус скорее доступен для отечественных производителей, чем для иностранных. А вот первый вариант очень интересен и важен, хотя и упомянут вскользь.
Я начну с того факта, что сертифицируется обычно законченное решение, а встраивается отдельный модуль (например, антивирусный движок). Например, есть у меня 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 в Телеграмме за якобы нарушение правил.
Как человек, ответственный за сертификацию со стороны Лаборатории Касперского не могу не прокомментировать.
Во-первых, конечно, составные решения не используют части существующего сертифицированного антивируса. Это вообще как-то за гранью.
Желающие использовать наш движок приходят к нам и получают себе именно движковую часть с программным API которая может быть легко интегрирована в их решения (KAVSDK). Эта часть естественно отвечает только за обнаружение, и этой частью действительно закрывается только часть функциональных требований профиля. Остальные требования — ведение отчета, настройки, ролевой доступ реализуется остальным решением. Никаких противоречий тут нет.
За интеграцию KAVSDK и отображение интеграции в архитектурной документации отвечает разработчик решения.
При испытаниях функциональные испытания проводятся лабораторией над общим решением, когда лаборатория доходит до НДВ она приходит к нам для работ над нашей частью модулей.
Никакой экономии времени или использования ранее сертифицированных компонентов не происходит, никакие естественно контрольные суммы не совпадут. Но правильно интегрированный движок вполне становится частью интегрированного решения и в ЗБ заявляется соответствие нескольким профилям защите, если это нужно.
Скажите, а почему вы не сертифицируете свой KES например как хостовый ids по соответствующему профилю? Ведь он имеет такую функцию.
Этот комментарий был удален автором.
Было бы логично создать консорциум где все сертифицированные средства были совместимы между собой, проходили сертификацию условно в одно и тоже время. Что как мы все понимаем утопия, никто не привяжет свой цикл разработки к этому внешнему фактору в виде сертификации. Есть конечно безумные компании которые готовы привязываться ко всему чему только можно, быть единственным продуктом подходящим под требования регулятора — но качество этого продукта настолько низки, что мне как инженеру внедрения всегда было стыдно смотреть в глаза приобретающим эти решения..
Этой сертификации мы кастрируем нормальный уровень безопасности, который и так отстает от плохих парней даже с самыми современными системами защиты, а мы еще в подарок даем использование средств защиты 3-х летней давности..
Импортозамещения нужно добиваться конкурентными решениями на мировом рынке, независимыми экспертизами, проверками уровня безопасности компании производящей продукт. А не этими филькиными грамотами выписанными бездарными лабораториями..
Олег, ну так правильно. Я поэтому немного удивился, когда Дмитрий в своем посте написал про использование уже сертифицированных модулей в чужих продуктах. Я с ходу не вспомню ни одного такого продукта, который бы без изменения использовался где-то. А движок — это уже совсем другой продукт и его надо проверять, независимо от наличия сертификата на продукт, в котором он используется.
Алексей, есть такой продукт как шлюз безопасности "граница", представляющий из себя sterra+fortigate в едином корпусе. Вот вам и интеграционная платформа двух сертифицированных сзи. Правда пока что у них нет сертификата.
У самой sterra и fortigate по отдельности есть серты. Нет своего у границы.
Это вырожденное решение. Две разных продукта, помещенных в единый корпус, чтобы считаться "отечественным". И сертификат на него врядли будет выдан