Минцифры и ФСТЭК предложили создать единую среду безопасной разработки

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

Директор по маркетингу и коммуникациям ООО "Ракета" Дарья Зубрицкая назвала построение конвейера безопасной разработки сложной и затратной задачей не только для мелких, но и средних компаний: "Создание конвейера безопасной разработки с нуля требует большого количества ресурсов дорогостоящих разработчиков и архитекторов. Кроме того, требуется внедрение новых практик и инструментов разработки. Обычно в средних по размеру компаниях полноценное внедрение такого процесса занимает от полугода и далее зависит от специфики бизнеса и регуляторной политики отрасли".

Директор по стратегии и развитию технологий Axiom JDK, руководитель комитета по ИБ АРПП "Отечественный софт" Роман Карпов напоминает, что для создания такого конвейера, как и процесса безопасной разработки, нужны доверенные инструменты как разработки, так и проверки кода и квалифицированный персонал для работы с этими инструментами.

Но это, как он предупреждает, далеко не все: "Кроме того, потребуется время разработчиков, занимающихся проектом, в который внедряется безопасная разработка. Это необходимо для корректного применения инструментов, например, чтобы процессы SDL (Secure Development Lifecycle) не мешали существующим процессам разработки. Участие разработчиков, которые хорошо ориентируются в продукте, для которого выстраивается безопасная разработка, позволит значительно ускорить и упростить внедрение SDL. Наша команда инвестировала десять человеко-лет в разработку программного продукта Axiom JDK Certified, выстраивание процессов безопасной разработки в соответствии с требованиями ФСТЭК, верификацию 3 Гб программного кода".

Директор по развитию бизнеса "Девелоника" (ГК Softline) Роман Смирнов уверен, что конвейер безопасной разработки "уравняет" некоторых игроков рынка, потому что они смогут воспользоваться новыми возможностями: "Кто-то "подтянется", кто-то адаптирует ведение бизнеса с точки зрения ИБ или безопасности внутренних систем. А вот сложные и ресурсоемкие задачи возьмет на себя заказная разработка уже после решения большей части типовых проблем заказчиков, использующих Гостех".

Кроме того, как отметил Дмитрий Шевцов, присоединение к такому конвейеру существенно ускорит сроки сертификации. Еще в ноябре 2022 г. заместитель директора ФСТЭК Виталий Лютиков на конференции "SOC Форум 2022" объявил об изменении регламентов сертификации, которое дает серьезные преференции тем разработчикам, которые применяют технологии безопасной разработки.

Как заявил заместитель министра цифрового развития, связи и массовых коммуникаций Александр Шойтов, без включения разработчиков в единый конвейер безопасной разработки будет просто невозможно соответствовать высоким требованиям по безопасности, которые предъявляются к разработчикам ПО для критической информационной инфраструктуры (КИИ) и государственных информационных систем (ГИС). Для этого Александр Шойтов предложил разработчикам кооперировать усилия для создания единого конвейера безопасной разработки. Вместе с тем заместитель главы Минцифры признал требования к ГИС и КИИ избыточными для бизнес-ПО.

Старший вице-президент, технический директор (CTO) блока "Технологии" ПАО "Сбербанк" Андрей Белевцев, выступая на сессии ПМЭФ "Развитие критической информационной инфраструктуры: угрозы и перспективы", предлагал крупным компаниям включать во внутрикорпоративный контур безопасной разработки подрядчиков. По его мнению, это станет дополнительной гарантией от атак на цепочки поставок, в ходе которых злоумышленники атакуют крупные компании через поставщиков, в том числе внешних разработчиков.

Директор проектов, лидер стрима Сфера.Управления холдинга Т1 Юрий Дручинин предостерегает от использования простых на первый взгляд подходов: "Эконом-вариант подразумевает использование достаточно примитивных инструментов для сканирования кода и дистрибутивов на предмет уязвимостей, собранных из OpenSource-решений. Их относительно просто предложить рынку, и многие игроки имеют возможность их внедрить. Однако такой подход не дает возможности понять, насколько качественно выявляются уязвимости и проконтролировать отработку командой выявленных замечаний".

"Иными словами, подобным путем невозможно сформировать в компании культуру безопасной разработки в отличие от зрелого конвейера. Он подразумевает внедрение, помимо автоматического сканирования дистрибутивов и кода, проактивную работу со стороны инженеров информационной безопасности, - пояснил Юрий Дручинин. - Все выявленные различными способами уязвимости отслеживаются и отрабатываются по регламентированному процессу. Для этого пишется методология, создается статусная модель разных типов уязвимостей – Application Security. В этой парадигме программные продукты не смогут выходить в промышленную эксплуатацию без фактического прохождения контрольных точек и строго регламентированного и автоматизированного релизного процесса. Создание полноценного безопасного конвейера разработки – путь дорогой и сложный: он требует перенастройки множества процессов и покупки дорогостоящего инструментария".

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

Заместитель генерального директора Postgres Professional, глава комитета по интеграции российского ПО АРПП "Отечественный софт" Иван Панченко считает, что главная задача такого конвейера – помочь разработчикам снизить затраты на то, чтобы соответствовать нормам безопасной разработки: "Говоря о российском конвейере, речь идет о средствах верификации программного кода, помогающих разработчикам находить в нем ошибки. Эти инструменты дороги и сложны в освоении, поэтому практика коллективного использования может заметно снизить порог входа, а значит, и затраты разработчиков. Безопасная разработка действительно работает — могу подтвердить это на опыте Postgres Professional. Благодаря тщательному анализу результатов работы автоматизированных средств мы можем обнаружить и устранить ошибки в программном коде задолго до его запуска в эксплуатацию. Применять подходы безопасной разработки следует прежде всего там, где имеются наибольшие риски использования возможных уязвимостей с целью атаки. Такие места нужно определять с помощью изучения и моделирования угроз. Пренебрежение этим правилом приведет к распылению дефицитных трудовых ресурсов разработчиков".

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

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

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

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

Яков Шпунт