В плену иллюзий относительно сертификации по требованиям ФСТЭК

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

Многие заказчики, партнеры, да и производители тоже, живут в плену иллюзий касательно темы сертификации по требованиям безопасности (не исключаю, что и я тоже). Они по-прежнему ориентируются на позицию регулятора 3-4-хлетней давности и ничтоже сумняшеся разносят эту позицию по рынку, как сеятель в известном романе «12 стульев» Ильфа и Петрова. Хотелось бы прокомментировать некоторые из этих высказываний, опираясь на то, что часто звучит на мероприятиях ФСТЭК из уст ее руководителей, а также развивая темы, поднятые мной ранее на страницах блога (тут, тут и тут).

В условиях непростой геополитики многие органы власти считают, что иностранные ИТ/ИБ-компании представляют собой угрозу национальной безопасности России. Опираясь на этот тезис регуляторы (что ФСТЭК в документах по КИИ, что в ФСБ в проектах документов по ГосСОПКЕ) устанавливают особые требования к системе обновления как программного обеспечения, так и к базе решающих правил. Так вот ФСТЭК в последнее время не сертифицирует решения, если они обновляются в реальном времени из-за рубежа. Если иностранная IDS, NGFW, антивирус или сканер безопасности имеют возможность скачивать обновления, а потом, по команде распространять их на сенсоры/агенты/шлюзы, то это вполне нормальная схема. Но если решение обновляет базу хешей вредоносного кода, получает фиды Threat Intelligence, сигнатуры атак или приложений, и делает это в реальном времени с зарубежных сайтов, то это рассматривается как угроза и такая возможность должна быть отключена. Для отечественных игроков никакой сложности в этом нет — они вообще не обновляются через облака (разве, что KSN от Касперского). А вот «иностранцы» для оперативного обновления своих решений знаниями об угрозах это делают. Эту функцию можно отключить, заменив обновление на ручное (по старинце, на флешке), но тогда эффективность защиты будет существенно снижаться.

Вывод 1. Либо снижение защищенности за счет отключения обновления в реальном времени, либо отказ от сертификации, либо использование отечественного решения, которое лишено всех этих проблем.

Не секрет, что многие отечественные производители встраивают в свои решения чужие модули. Обычно речь идет об антивирусе, а точнее об антивирусном движке, который в сетевом решении представляет собой возможность поиска вредоносных файлов в сетевом трафике, а в хостовом решении — ищет следы малвари на диске или в памяти. Например, «Код безопасности» объявил год назад о сотрудничестве с Лабораторией Касперского, а MultiScanner от Positive Technologies включает в свой состав сразу несколько антивирусных движков. Вообще это одна из стратегий развития продуктов по ИБ (купить кого-то, разработать свое или интегрироваться с кем-то), которая позволяет быстро удовлетворить задачи своих заказчиков. Так вот согласно требованиям ФСТЭК, чтобы сертифицировать такое решение на класс 5 и выше, заявитель обязан представить исходные тексты каждого из модулей. Без этого сертификация конечного решения невозможна.

Вывод 2. Либо отказаться от интеграционных решений, состоящих из модулей разных производителей, либо пытаться получить исходные тексты от всех них.

Схожая ситуация с UTM-решениями и NGFW. Чтобы сертифицировать целиком продукт данного класса, вы должны отдать на проверку все модули (МСЭ, СОВ, АВЗ, URL-фильтрацию, VPN и т.п.). И проверяться такой продукт будет на соответствие отдельным РД (на МСЭ, на СОВ, на антивирусы и др.). Если на какой-то функционал нет РД, вы должны в задание по безопасности включить соответствующий функционал. Иными словами вы не можете иметь в рамках сертифицируемого продукта несертифицированные компоненты. Или все, или… А что или? Регулятор считает, что компонент, который не будет сертифицироваться должен быть исключен из продукта. На логичный вопрос, а может просто не активировать его лицензией (например, в NGFW купить только функционал контроля приложений, без обнаружения вторжений и антивируса) регулятор дает закономерный ответ — низззяяя, а вдруг в непроверенном коде есть вредоносная составляющая?

Вывод 3. Либо отказаться от NGFW/UTM и использовать набор отдельных продуктов, легко сертифицируемых по отдельным РД, либо расширять область сертификации, увеличивая время на сертификацию (и инспекцию) и стоимость решения.

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

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

Дальше будет две неопределенности, связанные с новыми требованиями ФСТЭК из приказов по КИИ, которые требуют использовать только те средства защиты, которые имеют действующую техническую и гарантийную поддержку. И вот тут возникает два вопроса. Что делать с open source решениями, которые не имеют никакой официальной поддержки со стороны… кого? Ни производителя, ни службы поддержки, ни договоров (кроме оферты без ответственности). Если верить обзору с anti-malware.ru, то у 63% компаний бюджет на ИБ составляет менее 500 тысяч рублей в год, что ставит перед организацией вопрос о необходимости применения решений с нулевой стоимостью. Open Source подходит для этого лучше всего. Но нельзя 🙁 Наверное.

Аналогичная неопределенность с ПО, которое снято с поддержки. Например, на многих объектах КИИ в промышленности, энергетике и др. до сих пор используется Windows 2000, снятая с поддержки в 2010-м году. Так можно ее теперь использовать или нет? И если нет, то что делать?

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

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