В документах, связанных с сертификацией, установлено, что в случае, если разработчик средств защиты программного, программно-аппаратного обеспечения имеет сертифицированные процессы безопасной разработки, то внесение изменений в свои продукты он осуществляет самостоятельно, без привлечения лаборатории. Таким образом, мы встречаемся с таким разработчиком только раз в пять лет при переоформлении сертификата соответствия. Между этими двумя событиями он самостоятельно поддерживает свой продукт, устраняет все проблемы. Мы знаем, что у него внедрены все процессы, связанные с анализом кода, с работой с уязвимостями, с угрозами и так далее.
Это с точки зрения преимуществ. Мы продумываем вопрос, как их еще можно расширить, но пока вот это основное. Поэтому сертификация у нас идет активно.
К сожалению, у нас сейчас два органа по сертификации — это Институт системного программирования и Институт ФСТЭК России (ГНИИИ ПТЗИ). У них открыта область по сертификации. У нас нет там лабораторий, потому что испытывать нечего, процессы оцениваются экспертами органа, поэтому мы участие лабораторий здесь не предусматриваем.
У нас на сегодняшний момент выдано всего 3 сертификата, какие-то материалы уже поступили, будет 4–5, но это единицы. Много заявок, много в процессе рассмотрения. Скажу сразу, что этот очень трудоемкий и сложный процесс. То есть сертифицировать безопасную разработку, пройти оценку всех внедренных процессов и анализа композиционного, статического, динамического, а, самое главное, доказать и показать безопасность среды разработки и сборки и то, что к ней можно установить определенный уровень доверия, это непростой процесс. Особенно у больших разработчиков, которые, как оказалось, не всегда задумывались о том, как осуществляется сборка продуктов, из каких компонентов, откуда. Много очень open-source, с которым приходится разбираться. Много унаследованных продуктов, то есть разработчик ведет историю разработки продуктов с 90-х годов, и до сих пор некоторые библиотеки в продуктах используются с того времени. Понятно, что он тогда, в 90-х годах, думал, что ли, что это за библиотеки, из чего они собираются и так далее. Но тем не менее.
Все, кто заявляется, стремятся доказать, что их продукты безопасны. Это не означает, что в этих продуктах нет уязвимостей. Это означает то, что процессы работы с этой проблемой или с этой угрозой налажены, они существуют. И если появляются уязвимости в продукте, то это очень сложные уязвимости, которые просто так не проэксплуатируешь. Это не банальные ошибки, это уже сложные вектора, как показывает практика, у нас такие прецеденты есть. Поэтому процесс этот идет, и процесс этот будет набирать, я думаю, популярность и обороты.
Скажу сразу, что обязательность сертификации безопасной разработки она не установлена, то есть это заявительный характер. Разработчик самостоятельно заявляется на это. Я единственное знаю, что сейчас очень много заказчиков и в области КИИ, и в других направлениях, в ТЗ начинают прописывать те или иные требования. Заказчик пытается подстраховаться с точки зрения рисков, связанных с приобретаемыми продуктами. Имеет право, если это не противоречит законодательству.
Также стоит добавить следующее. В рамках проекта «Экономика данных» нам дали финансирование на создание унифицированной среды безопасной разработки. Мы хотим создать механизмы, типа фреймворки и методики, методологии в помощь для внедрения механизмов безопасной разработки, чтобы это стало достоянием не только для совсем крупных и совсем зрелых разработчиков, но и для разработчиков, как минимум, среднего уровня, учитывая, что количество требований в этой части у заказчиков начинает расти. Сейчас пока это видится в виде фреймворка, который от начала до конца объясняет, как это сделать, и какие при этом документы готовятся, их образцы, какие-то инструменты или отсылки на какие-то инструменты. Конечно, результат будет не завтра, не послезавтра, но тем не менее мы такую работу тоже ведем.