Основные технологии защиты приложений в 2018 году

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

3 APPLICATION SECURITY TECHNOLOGIES TO ADOPT IN 2018

Download Free Whitepaper

Защита приложений является одной из наиболее затратных статей расходов согласно отчету SANS 2016 года, так как компании начали серьезнее относиться к вопросу защиты приложений. Однако, технологии, направленные на защиту разработки и жизненного цикла приложения, пока не столь популярны, они оказались на 14 месте из 21 в списке статей расходов на ИБ.

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

Тем не менее, статистика причин большинства инцидентов приводит нас к другому выводу. В 2015 году Тим Кларк из SAP написал в Forbes, что 84% кибератак происходит на уровне приложений, что вызывает вопрос о разумности акцента на другие области ИБ, на которые происходят основные расходы.

Возможно, пришло время пересмотреть, как и на что необходимо расходовать бюджет, чтобы соответствовать современным требованиям безопасности? Если мы собираемся еще раз рассмотреть технологии защиты приложений, то нужно понять, какие из них являются подходящими и действительно делают то, что нам от них нужно, тестируя проприетарный, а также open source код, которого так много в наших продуктах.

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

Узнайте, что за код в ваших продуктах

Во время разговора о том, что делает продукт особенным, ни один СТО никогда не укажет на open source компоненты, которые разработчики скопировали с GitHub.

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

Однако, проприетарный код – это только маленькая часть истории продукта.

Согласно отчету Forrester’s Wave о решениях класса Software Composition Analysis 2017 года проприетарный код составляет только 10-20 процентов программного продукта. Это значит, что даже если вы используете самые современные решения SAST, DAST или IAST, то защищаете только маленькую часть вашего кода.

Компоненты с открытым исходным кодом составляют примерно от 60 до 80 процентов кода в вашем продукте, помогая разработчикам направить усилия на написание более инновационного проприетарного кода. Они, вероятно, не будут говорить об этом (а что еще хуже – не будут следить за тем, что добавили в код), но разработчики используют open source компоненты. С их точки зрения, open source – это бесплатное ПО, которое облегчает им жизнь, помогая быстрее выпускать продукты.

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

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

Говоря об open source важно понимать, что компоненты с открытым исходным кодом очень широко применяется в индустрии разработки программного обеспечения. Это хорошо, так как сообщество разработчиков помогает поддерживать эти проекты и улучшает их. Когда такие «белые шляпы» находят новые уязвимости в коде, они обновляют информацию об open source проектах (update the managers of the open source projects) и отправляют уведомления в базы данных уязвимостей, такие как National Vulnerability Database (NVD) или Mitre, давая обозначение уязвимости. В большинстве случаев, они также находят способ устранить уязвимость и дают указания, как сделать исправление. И это хорошие новости.

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

Вторая причина заключается в том, что инструменты подобные SAST, DAST и пр., предназначенные для проприетарного кода, не защищают open source код. Использование их для компонентов с открытым кодом похоже на то, словно вы пытаетесь есть суп вилкой. Безусловно, вилка – это предмет посуды, но она не подходит для этих целей. Если вы пытаетесь использовать эти технологии, полагаясь на них при отлавливании уязвимостей в open source компонентах, приготовьтесь увидеть, как огромное количество плохого кода «выльется в тарелку с вашим продуктом».

Подбираем подходящий инструмент для этой задачи

При поиске инструмента для решения задачи защиты open source компонентов, с которым не справляются инструменты, предназначенные для проприетарного кода, на первый план выходят технологии класса Software Composition Analysis (SCA).

В отличие от SAST-инструментов и им подобным, которые отфильтровывать каждый маленький фрагмент вашего кода, проверяя его на наличие ошибок, инструменты SCA работают с уведомлениями NVD и других источников, откуда получают последние аналитические данные об уязвимостях.

Работа инструментов SCA основана на том, что просмотр всех библиотек, их зависимостей и зависимостей зависимостей не целесообразно для обеспечения безопасности. Вместо этого они находят уникальную цифровую сигнатуру (известную как SHA-1), которая изменяется при внесении изменений в код. Такой хэш-код дает пользователям информацию, какой open source код вы используете в своих продуктах без необходимости открывать ваш код (что может быть больным вопросом для людей, беспокоящихся о конфиденциальности), чтобы закончить вашу работу.

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

Есть однозначные преимущества использования SCA-инструментов с точки зрения бюджета, не говоря уже о том, что это удобный инструмент для работы. Как уже было отмечено выше, разработчики постоянно включают open source компоненты в свои проекты, не зная при этом, уязвимы они или нет. Хотя это может казаться практичным при выполнении проекта, в будущем такой подход может оказаться очень затратным, если разработчикам требуется заменить уязвимый компонент перед релизом. А если версия уже вышла и нужно «вырвать» компонент и заменить его в уже работающем проекте, то это может оказаться еще более досадным.

И хотя open source компоненты могут быть бесплатными, использование уязвимого кода может очень дорого обойтись. Вспомним историю с Equifax, когда компания столкнулась с необходимостью критического анализа после инцидента безопасности, происшедшего по причине уязвимой версии Apache Struts2, которая привела к краже идентифицирующей информации (кредитных карт и номеров карт социального страхования) 145 миллионов людей. Эта ситуация может свидетельствовать в пользу того, что неправильное управление open source компонентами вызывает непоправимый ущерб бренду компании и потерю доверия клиентов.

Возьмите безопасность приложений под контроль

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

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

Аналитики отрасли начинают понимать, что SCA-инструмент важен, как часть эффективной стратегии безопасности приложений. В отчете Forrester Wave Report подчеркивался рост этого сектора в прошлом году, а лидеры, как, например, Microsoft и IBM, начинают включать SCA-решения от компании WhiteSource в свои продукты, полностью понимая, какую ценность они добавляют жизненному циклу разработки ПО.

Скачайте информационный буклет WhiteSource «The Main Application Security Technologies to Adopt by 2018», чтобы узнать больше о технологии SCA и других технологиях, которые необходимы для обеспечения защиты и безопасности продуктов, а также чтобы разработать правильную стратегию. Мы обрисовываем, как эти различные технологии соотносятся с вашей стратегией, объясняем, что и где работает, чтобы ваши приложения были полностью защищены.

Источник >

Сюжеты Безопасность приложений Новости партнеров