Важнейшие тенденции в области безопасности при разработке программного обеспечения

В 2018 и 2019 годах было непросто убедить предприятия в необходимости перехода на облачные технологии. Многие компании просто не были готовы к столь масштабным переменам, им было некомфортно полагаться на облачные сервисы, а не на локализованное оборудование и программное обеспечение.
Но ситуация изменилась. В 2020 и 2021 годах миграция в облако стала основным направлением, главным образом из-за внезапного появления пандемии. Компании выбрали одного из гигантских облачных провайдеров, а именно Amazon Web Services (AWS), Microsoft Azure и/или Google Cloud, поскольку эти три компании контролируют большую часть рынка облачных услуг.

В настоящее время облачные вычисления пользуются невероятным успехом, настолько, что в 2024 году мировые расходы на облачные услуги составят более 84 млрд. долл. Однако эксперты в области информационных технологий предупреждают, что на горизонте маячит новое потрясение. Широкое использование API, нехватка ИТ-специалистов и программное обеспечение с архитектурой "доверяй, но проверяй" создают проблемы безопасности в ближайшем будущем.
Экспоненциальный рост использования облачных вычислений означает, что сообщество разработчиков программного обеспечения должно оперативно реагировать на повышение уровня безопасности. Каждый день появляются новые киберугрозы, но разработчики используют те же технологии защиты, что и 3-10 лет назад. В 2024 году компаниям следует принять меры, чтобы включить эти критические тенденции в области безопасности в жизненный цикл разработки программного обеспечения и во все свое программное обеспечение.

Основные критические тенденции в области безопасности

Оценка работы ИТ-департамента

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

Кроме того, стоит отметить, что высшие учебные заведения ориентируются на потребности взаимосвязанного мира, создавая все больше программ для специалистов в области кибербезопасности и ИТ. Несмотря на это, разрыв между спросом и предложением на квалифицированных специалистов в области кибербезопасности, скорее всего, сохранится. В настоящее время имеется много работников начального уровня, но ощущается острая нехватка ИТ-специалистов с 10-15-летним опытом работы.

API

Взаимосвязь API (Application Programming Interface) может быть неочевидной для тех, кто не связан с разработкой программного обеспечения и веб-приложений. Но в этой области API связывают все. Однако их особенно сложно защитить, поскольку они труднодоступны.
Разработчики постоянно используют API, что иногда означает, что ваши инженеры могут использовать API, разработанные кем-то другим. Используя внешние API, компании открывают для себя катастрофические риски безопасности.

Отличным примером этого является компания Cambridge Analytica. Хотя эта пиар-катастрофа технически не была нарушением безопасности данных, в центре скандала оказались API-интерфейсы Facebook.
Facebook не смогла установить важные разрешительные рамки, соблюсти условия предоставления услуг, а также уведомить пользователей о том, как собираются и используются их данные. Не вдаваясь в подробности, можно сказать, что компания Cambridge Analytica смогла использовать Graph AI Facebook для сбора и продажи данных о более чем 87 млн. пользователей.
К другим рискам безопасности API относятся неправильная конфигурация системы безопасности, ненужное раскрытие данных, плохой мониторинг, неадекватное протоколирование, проблемы с разрешениями и авторизацией. При передаче данных между различными программными средами высок риск их злонамеренного манипулирования или сбора. Как минимум, все API, передающие пользовательские данные, требуют шифрования данных и интеграции с OAuth.

Ведомость материалов для программного обеспечения

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

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

Важно отметить, что в скором времени правительство США может потребовать SBOM для всех программных продуктов, используемых государственными учреждениями. SBOM - это спецификация материалов для программного обеспечения, в которой компания должна указать полный перечень всех компонентов, входящих в состав программного обеспечения. Эти компоненты включают в себя перечисленные выше элементы, такие как API, программное обеспечение и микропрограммное обеспечение.
Государственные органы смогут проверять программное обеспечение на основе SBOM и определять, достаточно ли оно надежно и безопасно для использования в государственных целях. Такой подход представляется хорошей мерой, поэтому не исключено, что он будет применяться и в частном секторе.

Нулевое доверие и контроль доступа

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

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

Сосредоточьтесь на одной области совершенствования за один раз

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

Чтобы избежать проблем, компании должны поручать специалистам по безопасности проверять API на предмет наличия проблем и немедленно их устранять. Если программное обеспечение приносит пользу и интегрируется в жизнь пользователя, оно почти гарантированно использует API. При необходимости следует перестроить эти системы, чтобы не оказаться в ситуации, подобной Facebook.
Компаниям, работающим в отраслях, где широко распространены федеральные и государственные контракты, следует рассмотреть возможность включения SBOM во все готовящиеся продукты. Все компании должны перейти от архитектуры безопасности "доверяй, но проверяй" к архитектуре безопасности с нулевым доверием. Разработчики, пользователи конечных точек и все, кто находится между ними, должны иметь четко сформулированные положения о минимальных потребностях. Нулевое доверие уже является стандартом во многих отраслях, и его распространение будет быстро расти.