РБПО — модный тренд или необходимость? Дискуссии на эту тему поднимают уровень культуры ИБ

РБПО — модный тренд или необходимость? Дискуссии на эту тему поднимают уровень культуры ИБ

В течение последних двух лет практически ни одно мероприятие или конференция по информационной безопасности не обходится без обсуждения вопросов разработки безопасного программного обеспечения. В профессиональном сообществе уже даже устоялся термин РБПО. Термин, во избежание множества толкований, был уточнён и зафиксирован в новом ГОСТ 56939-2024 как «содержание и порядок выполнения работ, связанных с созданием безопасного программного обеспечения и устранением выявленных недостатков, в том числе уязвимостей ПО». 

Можно говорить, что РБПО — это процесс создания программного обеспечения, который включает в себя меры по обеспечению безопасности кода на всех этапах его жизненного цикла. Это актуально, несмотря на то что в вышеупомянутом ГОСТ 56939-2024 прямо отмечается, что «поскольку модель жизненного цикла ПО зависит от специфики, масштаба, сложности ПО и условий, в которых ПО создаётся и функционирует, приведённые в … стандарте процессы намеренно не связываются с конкретной моделью жизненного цикла ПО».

Но, к сожалению, терминологические нюансы являются самой меньшей из проблем при внедрении РБПО.

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

Попробуем разобраться, в чём же состоят сложности оперативного внедрения РБПО (далее «безопасная разработка») в жизнь обычного коллектива, команды или компании. Можно выделить несколько причин, почему компании не спешат внедрять безопасную разработку в свои процессы:

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

2. Отсутствие понимания преимуществ и неопределённость результатов. Некоторые компании не понимают, какие конкретно преимущества на практике им даст внедрение безопасной разработки. Рассматривают культуру безопасной разработки просто как ещё один модный тренд, который не принесёт реальной пользы на практике. Особенно это актуально для компаний, чья технологическая экспертность сосредоточена в основном в отраслевых знаниях. Речь идёт о разработчиках АСУ ТП систем, SCADA-систем, систем, применяемых в энергетике, продуктов в сфере консультационных услуг, программно-аппаратных решений «полевого уровня», IoT-решений. То есть таких решений, где надёжность функционирования и промышленная безопасность, точность получаемых данных ранее всегда превалировала над информационной безопасностью. Как и с процессами управления рисками, результаты внедрения безопасной разработки могут быть неопределёнными на старте, отложенными и часто неподтверждаемыми до тех пор, пока не наблюдаются конкретные инциденты безопасности в отношении разрабатываемого ПО. Часто компании опасаются, что они вообще не получат никаких результатов или что результаты будут достигнуты слишком медленно. Внедрение РБПО не воспринимается как что-то, что напрямую может увеличить прибыль, потому что в лучшем случае приводит к реализации нефункциональных требований продуктов, которые «продать рынку достаточно тяжело». 

3. Сопротивление изменениям и страх перед ошибками. Любые изменения в процессах разработки и эксплуатации программного обеспечения могут вызвать сопротивление со стороны сотрудников. Специалисты могут опасаться, что внедрение новых методов работы приведёт к увеличению нагрузки или снижению их производительности. Более того, на первых этапах внедрения безопасной разработки именно так и происходит, что только подтверждает аргументы противников изменений. Несовершенство применяемых конвейеров сборки и систем тестирования, интеграционные проблемы на пути внедрения лишь добавляют в эту копилку свои аргументы против. Команды, менеджеры и отдельные специалисты могут бояться совершить ошибки при внедрении безопасной разработки. Ожидают, что новые процессы приведут к снижению безопасности их систем, навредят репутации, снизят прибыль. Эта проблема также актуальна в том случае, когда в уже существующие, хорошо отлаженные производственные конвейеры привносятся новые инструменты, решения, процессы. 

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

5. Необходимость пересмотра архитектуры системы. Часто архитектура разрабатываемых систем унаследована, закладывалась одним или несколькими ключевыми специалистами с учётом актуальных на момент проектирования задач (то есть «в прошлом»). Аспекты Security by Design могли откладываться на второй план или закрываться типовыми решениями: применением компонентов с открытым исходным кодом, базовыми фреймворками. В результате, когда для внедрения безопасной разработки необходимо пересмотреть архитектуру системы и внести в неё изменения, направленные на повышение уровня безопасности, это, с одной стороны, встречает сопротивление некоторых ключевых специалистов, а с другой — приводит к дополнительным затратам времени и денег. В ряде случаев внедрение РБПО вырождается в полный демонтаж старой архитектуры разрабатываемых систем.

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

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

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

Реклама. АО «АМТ-ГРУП», ИНН: 7703025499, Erid: 2VfnxwsZRa8