«Доверие нельзя сертифицировать — его можно только построить». 11 вопросов после 11-го Certification Day

«Доверие нельзя сертифицировать — его можно только построить». 11 вопросов после 11-го Certification Day

После одиннадцатого Certification Day BIS Journal решил отказаться от привычного разговора о количестве участников, программе и итогах мероприятия. Вместо этого мы задали одиннадцать вопросов человеку, который уже одиннадцать лет наблюдает, как меняется система сертификации средств защиты информации изнутри.

— Карина, одиннадцать лет назад вы создали Certification Day. Чего тогда, на ваш взгляд, не хватало отрасли?

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

Я никогда не любила разговоры о том, почему что-то невозможно. Мне всегда было интереснее спросить: «Что мы можем сделать, чтобы это стало возможным?»

Именно с этой мысли и начался Certification Day. Мне хотелось создать не ещё одну конференцию, а профессиональную среду, где можно открыто обсуждать сложные вопросы, вместе искать решения и помогать новым подходам становиться частью реальной практики.

— Одиннадцать лет спустя — ​получилось? Certification Day стал именно такой площадкой, какой вы когда-то хотели его видеть?

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

Для меня это, наверное, и есть главный результат этих одиннадцати лет.

— Как вы понимаете, что идея действительно созрела для масштабирования?

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

Именно так и рождаются устойчивые изменения. Не потому, что появилась хорошая идея. А потому, что она прошла путь от профессиональной дискуссии до практики, которой начинает доверять вся отрасль.

— Можете привести пример идеи, которая на ваших глазах прошла весь этот путь — ​от профессиональной дискуссии до отраслевой практики?

— Таких примеров за одиннадцать лет накопилось немало. Но если выбирать один, я, наверное, назову электронную поставку сертифицированных продуктов.

Когда эта идея только появилась, она вызывала немало сомнений. Все привыкли, что сертифицированный продукт обязательно связан с физическим комплектом поставки. Но программное обеспечение обновлялось всё быстрее, поскольку количество новых уязвимостей, включая уязвимости в сторонних компонентах, ежегодно росло. Только за последнее десятилетие число ежегодно регистрируемых уязвимостей и дефектов безопасности (Common Vulnerabilities and Exposures, CVE) увеличилось почти в четыре раза.

Стало очевидно, что существующая модель уже не успевает за скоростью развития программного обеспечения. Электронная поставка была не просто новой идеей. Она стала неизбежным ответом на изменение реальности. Подход был апробирован на практике.

Сегодня он — ​естественная часть жизненного цикла сертифицированного продукта. Пользователь может оперативно обновиться до безопасной версии, не выводя информационную систему из аттестованного состояния.

— А есть ли пример, где изменилась не практика, а сама философия сертификации?

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

Именно здесь и произошло самое важное изменение. Сертификация всё меньше отвечает только на вопрос: «Безопасен ли этот продукт сегодня?» И всё больше — ​на вопрос: «Способна ли организация создавать безопасные продукты завтра?» Именно в этом и заключается главное изменение философии сертификации.

— Такие изменения невозможно реализовать в одиночку. Что, на ваш взгляд, делает их возможными?

— В системе сертификации средств защиты информации у каждого своя роль. Регулятор определяет направление развития и задаёт требования. Разработчики создают продукты, соответствующие этим требованиям. Испытательные лаборатории проводят независимую оценку их соответствия. Органы по сертификации подтверждают соответствие. Регулятор принимает решение о выдаче сертификата на основе результатов испытаний и экспертизы. Каждый выполняет свою часть работы. И именно так система должна работать.

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

— Можете привести пример, когда именно такой профессиональный диалог помог развитию системы сертификации?

— Таких примеров было несколько. Одним из первых примеров стала работа над Методикой выявления уязвимостей и недекларированных возможностей. Для любой новой методики важно не только качество самой идеи, но и понимание того, насколько она применима на практике. Именно поэтому была организована её апробация с участием ИСПРАН, «Лаборатории Касперского», компаний «Код Безопасности» и «Фобос». Мы не обсуждали методику как теоретический документ. Мы проверяли, насколько она действительно работает в реальных сертификационных испытаниях.

По такому же принципу строилась работа и по другим инициативам.

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

Аналогичным образом создавалась и новая редакция ГОСТ Р 56939–2024 «Защита информации. Разработка безопасного программного обеспечения». Документ разрабатывался совместно регулятором, рабочей группой вендоров и ИСПРАН. Такое взаимодействие позволило объединить регуляторное видение, научную экспертизу и практический опыт разработки безопасного программного обеспечения.

— Сегодня всё больше внимания уделяется сертификации процессов безопасной разработки. Почему именно сейчас?

— Я считаю это естественным этапом развития отрасли. Современное программное обеспечение постоянно развивается: выходят новые версии, исправляются уязвимости. В этих условиях становится недостаточно ответить на вопрос: безопасен ли продукт в момент проведения сертификационных испытаний? Важно понимать, способна ли организация сохранять этот уровень безопасности на протяжении всего жизненного цикла продукта. Именно поэтому всё большее значение приобретает оценка процессов безопасной разработки. Сегодня такие сертификаты становятся новой отраслевой практикой.

И здесь главный вопрос уже заключается не в количестве выданных сертификатов. Важно сохранить их содержательную ценность. Сертификат должен быть не маркетинговой наклейкой и не формальным подтверждением соответствия. Он должен быть доказательством зрелости процессов разработчика. Именно поэтому для меня сертификация процессов — ​это не про ещё один сертификат. Это про уверенность, что организация умеет системно создавать безопасные продукты.

— Какой вопрос, на ваш взгляд, станет для отрасли следующим большим профессиональным вызовом?

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

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

— Что за эти одиннадцать лет осталось для вас неизменным?

— Убеждение, что самые сложные вопросы нужно не обходить, а обсуждать. Проблемы надо решать, а не делать вид, будто их не существует.

— Если бы вам было нужно сформулировать главный итог этих одиннадцати лет одной мыслью, какой бы она была?

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

Доверие нельзя сертифицировать. Его можно только построить.

Вопросы задавал Александр Абрамов