Уровни критичности уязвимостей
Узнать большеЛетом 2021 года ФБР совместно с Агентством по кибербезопасности и защите инфраструктуры США, британским Национальным центром кибербезопасности, а также Австралийским центром кибербезопасности проанализировали самые атакуемые уязвимости программного обеспечения по итогам 2020–2021 гг. Выяснилось, что многие обнаруженные эксплуатируемые злоумышленниками баги связаны с активным переходом компаний на удаленную работу, использованием облачных сервисов и VPN. В топ популярных проблем вошли обнаруженные уязвимости в продуктах таких вендоров, как VMware, Microsoft (в частности, Exchange Server), Fortinet, Pulse Secure, Accellion. А ведь это крупные игроки рынка, которые тратят немалые ресурсы на контроль уязвимостей программного обеспечения. Что говорить о менее масштабных разработчиках, которые не всегда уделяют этому вопросу должное внимание? Поэтому даже компаниям, являющимися конечными пользователям ПО или заказывающими услуги разработки на аутсорсе, есть смысл перестраховаться, подумать о самостоятельном поиске и нейтрализации уязвимостей. Идеальных программ без дефектов не бывает. Рано или поздно какая-нибудь проблема всплывает.
Контроль и устранение уязвимостей ПО в процессе разработки
Затраты на устранение проблемы на этапе разработки включают аналитику, внесение изменений в проблемный код, а также повторную проверку (тестирование). Если же уязвимость будет выявлена в процессе эксплуатации, добавляются расходы на:
- обработку обращений пользователей,
- анализ влияния на участки кода, в которых проблема проявляется,
- специалистов, выявивших и исследовавших уязвимость (если они привлекались),
- устранение выявленных проблем, ввод в эксплуатацию новой версии ПО.
Организовать эффективное обнаружение и устранение уязвимостей программного обеспечения поможет внедрение безопасной разработки ПО SSDLC (Secure Software Development Lifecycle). Она включает несколько фаз, которые проходит продукт. Среди них:
- формулирование требований к продукту в области безопасности и конфиденциальности,
- определение уровня безопасности с опорой на действующие стандарты криптографии, метрик и критериев, по которым оценивается соответствие стандартам,
- оценка рисков.
Кроме того, безопасная разработка подразумевает использование инструментов статического (SAST) и динамического (DAST) анализа кода.
SAST (статическое или тестирование методом белого ящика) позволяет организовать проверку кода на соответствие стандартам, а также на наличие ошибок без его фактического исполнения. С его помощью можно организовать поиск проблемных мест уже на ранних этапах разработки – когда программа еще не работает.
DAST (динамическое или тестирование методом черного ящика) обеспечивает поиск (контроль) уязвимостей программного обеспечения при выполнении кода. Для этого применяются методы внедрения ошибок в работающее приложение и анализ реакции на них.
SAST и DAST при внедрении SSDLC могут использоваться совместно или по-отдельности. На практике (если речь о раздельном использовании) статический анализ применяется чаще – его предпочитают около 69% компаний-разработчиков – так как реализовать этот подход проще. Не нужно разворачивать дополнительные мощности для запуска отдельной копии приложения для тестирования. Метод позволяет покрыть практически 100% кода анализируемого приложения. Кроме того, SAST характеризуется универсальностью. Один инструмент, реализующий такой подход, одновременно может использоваться для контроля уязвимостей и поиска проблемных мест в нескольких приложениях. Все это – за счет поддержки разных языков программирования (например, с мая 2021 г. наше решение Solar AppScreener поддерживает 36 ЯП).
Контроль и устранение уязвимостей ПО при эксплуатации
Обнаружить абсолютно все возможные проблемы на этапе разработки невозможно. Даже внедрение SSDLC не гарантирует 100-процентной защиты от уязвимостей (но минимизирует их возникновение). Поэтому контроль должен продолжаться и в процессе эксплуатации.
Для этого также применяют DAST- и SAST-инструменты. Именно статическое тестирование пользуется большим спросом. Причины те же, что и указаны выше. Кроме того, организовать тестирование безопасности приложений с помощью SAST может даже компания без разработчиков в штате, эксплуатирующая ПО. Современные SAST-инструменты формируют рекомендации по локализации и устранению выявленных проблем. Solar appScreener предоставляет отчеты по результатам тестирования в простом и удобном для восприятия виде. Разобраться с ними может штатный специалист по информационной безопасности или сотрудник другого профиля.
Что касается внедрения анализаторов, реализующих подход белого ящика, проблем с этим не возникает. Их можно интегрировать практически с любой корпоративной IT-инфраструктурой: менять бизнес-процессы для обеспечения контроля уязвимостей приложений с помощью таких инструментов не требуется.
Поиск проблемных мест в приложениях должен быть реализован на всех этапах жизненного цикла ПО. И организовать его может даже конечный пользователь (эксплуатирующая компания). Если вы хотите быть уверенными в том, что используемое вашей организацией программное обеспечение безопасно, есть смысл внедрить SAST в свою IT-инфраструктуру. Нужно организовать постоянное статическое тестирование приложений и своевременную реакцию на обнаруженные проблемы. В некоторых случаях целесообразно заняться этими вопросами самостоятельно (тем более это не так сложно), а не просто полагаться на разработчиков.
