Защити ПО сам

Безопасная разработка софта и как она помогает бизнесу сэкономить деньги

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

КЛАССИЧЕСКИЙ ПОДХОД

Вопрос обеспечения информационной безопасности внутренних ресурсов компании возник сразу после постоянного подключения корпоративных сетей к Глобальной сети. Это привело к созданию защищенного периметра вокруг информационных систем и разграничению прав доступа внутри защищаемого контура.

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

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

Такой подход позволяет достичь высокого качества продукта и обеспечить быструю доставку его обновлений на рынок

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

Например, на рубеже 2020–2021 годов злоумышленники нашли уязвимость в системе производителя ПО SolarWinds и внедрили вредоносное обновление. Эта атака затронула 18 тыс. компаний. В списки пострадавших попали Microsoft, ИБ-компания FireEye, госдепартамент США, а также министерство финансов США. Злоумышленники проникли в инфраструктуру организаций и получили доступ к корпоративным учетным записям и документам.

РАЗРАБОТКА + ИБ

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

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

На втором – формируются требования и ограничения по ИБ, опираясь на подход security by design). Они включаются в техническую спецификацию и определяют ограничения в зависимости от угроз. Например, ограничения для версий языков программирования: устаревших, неподдерживаемых и уязвимых.

Мы столкнулись с противоположной проблемой, когда используемые инструменты статического анализа кода не поддерживали актуальную версию языка программирования

Так нам пришлось использовать предыдущую версию (в частности, Go 1.21).

На этапе разработки с точки зрения ИБ применяются практики безопасного кодирования для исключения типовых ошибок: включения пароля в исходный код, недостаточной проверки входных данных и т. п. На этом же этапе осуществляются автоматизированные и полуавтоматизированные проверки: статический анализ кода (SAST), динамический анализ (DAST), композиционный анализ (SCA) и другие.

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

Во время эксплуатации проводится периодический поиск и анализ уязвимостей, реагирование на инциденты ИБ, патчинг (выпуск обновлений ПО) и подобные процедуры.

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

НЕИЗБЕЖНЫЕ СЛОЖНОСТИ

Внедрять подобные процессы – непростой и долгий путь. Он ожидаемо приводит к срыву сроков или увеличению времени выхода продукта на рынок или в продуктивную среду (time to market).

Критическая уязвимость, которую обнаружили на этапе тестирования, может потребовать серьезных доработок

Конечно, это приведет к увеличению сроков обновления или выхода продукта.

Стоимость разработки значительно увеличится из-за затрат на ресурсы и инструменты для проведения тестирования, анализа уязвимостей.

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

На внедрение может повлиять нехватка квалифицированных специалистов по ИБ (в частности, AppSec, DevSecOps), которые могут выстроить эффективный процесс безопасной разработки ПО. Это также приводит к повышению финансовых затрат.

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

ПРЕИМУЩЕСТВА БЕЗОПАСНОЙ РАЗРАБОТКИ

Если возникает столько сложностей и проблем с внедрением безопасной разработки ПО, то зачем это вообще нужно?

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

Внедрение процессов безопасной разработки ПО сократит затраты на поддержку и исправление проблем

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

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

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

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

Компания будет соответствовать нормативным требованиям. Законодательные требования к безопасной разработке активно развиваются.

Проект нового ГОСТ 56939 предполагает более 25 мероприятий (процессов) по безопасной разработке ПО

Безопасный и стабильный продукт увеличит уверенность и позволит «не краснея» продавать продукт. В любом случае это положительно сказывается на репутации компании и повышает продажи ПО.

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

Наиболее используемые инструменты при разработке – статический анализ кода (SAST) и композиционный анализ (SCA)

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

Мы в компании пошли аналогичным путем и в первую очередь внедрили статический композиционный анализ. О том, как мы это делали и почему остановились на конкретных инструментах, можно написать отдельную статью. Если коротко, то мы внедрили следующие средства:

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

Мы рассчитываем, что

применение машинного обучения и искусственный интеллект значительно ускорят автоматизированные испытания, в частности анализ уязвимостей, и повысят их качество

Наше видение совпадает с общемировой тенденцией развития процессов безопасной разработки.