Компании должны сконцентрироваться на обнаружении и устранении уязвимостей в
библиотеках, от которых зависят их собственные продукты, говорят эксперты.
Спроси директора по информационным технологиям о безопасности приложений, и
получишь много ответов о попытках выявит уязвимости в защите собственных
продуктов. Но во многих случаях риск состоит не в коде, который написали
внутренние разработчики, а в компонентах, предоставленных внешними
программистами, будь это open-source библиотеки или средства для разработки
сторонних фирм. Возьмём открытый WebKit: многие компании знают, что такие
браузеры как Apple Safari и Google Chrome полагаются на WebKit, и,
соответственно, используют его в своих разработках, таких как, например,
Entourage 2008, Yahoo! Messenger и Macromedia Contribute 3.
"Компании, которые рассчитывают на третьих лиц в своем коде, отдают
безопасность в руки других разработчиков", - говорит Бармак Мефтах,
вице-президент по продуктам безопасности в Hewlett-Packard.
"Компании обычно не думают о рисках, которые открывает им стороннее
программное обеспечение, и свободно используют открытое ПО как часть своего
стека", - отмечает Мефтах. "Существует предположение, что open-source поставщики
и разработчики прошли через систему контроля безопасности в процессе создания
приложения, но это предположение ложно".
Чтобы защитить своё программное обеспечение, компании сначала должны
вычислить, какие компоненты стали частью их собственной базы исходных кодов.
"Первый шаг – составить список всех кодов, использованных для разработки", -
говорит HD Moore, глава системы безопасности Rapid7 и главный создатель
Metasploit.
"Даже группы разработчиков, которые очень хорошо разбираются в том, что они
делают и знают, что собой представляют их продукты, не могут отдавать себе отчёт
в том, какие внутренние библиотеки использовались - это то, что открывается
только во время аудита кода", - поясняет он.
"В качестве первого шага к любой ревизии компания должна удостовериться, что
она способна получить доступ к библиотекам, открытым или закрытым. Если
библиотеки поставляются сторонними разработчиками, то компания должна
сосредоточиться на контракте и первый шаг в нем - получение разрешения
проанализировать программное обеспечение", - говорит Мефтах из Hewlett-Packard.
"Мы наблюдаем тренд появления пунктов в договорах, которые позволяют конечным
пользователям самим анализировать программное обеспечение ", - добавляет он.
А раз компания получила это право, разработчики и группа IT-безопасности
должны сделать оценку приложений и найти слабые места в ПО, либо путём
статического анализа и мониторинга форума разработчиков, либо через отслеживание
изменений в программном обеспечении.
На основании полученной информации компания может принять решение пропатчить
программное обеспечение, или, если исправление нецелесообразно, использовать
сторонние продукты, чтобы защитить приложение от использования его критических
уязвимостей.
"Любая аномальная деятельность, которая осуществляется через этот компонент,
может быть отслежена", - говорит Мефтах. "Вы можете жить с уязвимой частью
программного оборудования до тех пор, пока не исправите её".
"Общая для многих компаний проблема, что источником библиотек может быть не
один поставщик", - отмечает Висопал из Veracode.
"Каждый разработчик, с которым вы имеете дело, может также иметь своих
поставщиков библиотек", - говорит он. "Каждый, кто хочет проявить должную
осмотрительность, должен пойти к своим поставщикам ПО и спросить, что они делают
для безопасности приложений".
"Эта проблема вложенных поставок может скрыть фактический источник
программного обеспечения и усложнить определение уязвимостей", - уточняет он.
"Даже после определения компонентов, от которых зависит определённая
библиотека, компании всё ещё с трудом могут определить, что патч не испортит их
приложения. Это очень сложный процесс, но он необходим для компаний,
использующих сторонние компоненты", - говорит HD Moore.
"Вы точно провалитесь в кроличью нору, когда начнете все это проверять", -
заключает он.
