AVB LabКибербезопасность

Безопасность при передаче разработки на аутсорсинг

Поделиться

По данным GitLab – 68% специалистов по ИБ убеждены в том, что менее половины разработчиков уделяют должное внимание аспекту безопасности кода. С ростом осведомленности о высокотехнологичных угрозах в бизнес-среде возникают закономерные требования к разработчикам – обнаружение и исправление потенциальных брешей в защите еще на этапе проектирования ПО. Ведь чем позже обнаружена уязвимость – тем дороже стоит ее устранение.

Требования к разработчикам – безопасный код?

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

Требования к разработчика - безопасный код?

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

Если имеются важные данные, которые необходимо защитить, следует уделить внимание анализу кода при приеме работ от подрядчика. Для этого можно прибегнуть к услугам сторонней специализированной организации (аутсорсеру ИБ). Часто после анализа выясняется, что такое приложение не следует вообще выпускать в продакшн.

Рынок разработки, готовы ли подрядчики писать безопасно?

Как мы уже упоминали – большинство разработчиков не уделяет должного внимания проблемам безопасности при проектировании и разработке приложений. Различные аудиты проводят лишь 22% компаний-разработчиков, при этом риски не отражены в договоре подряда. Автоматизированные средства анализа зачастую оказываются малоэффективными.

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

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

Тенденции

Взлом приложений – угроза, которая не теряет актуальность.

По данным западных исследований, доля уязвимых приложений (угроза утечки исходных кодов, конфигурационной информации, личных данных клиентов) возросла до 72% по итогам 2019 года. На протяжении последних лет этот показатель не падает.

Версии ПО раскрываются все реже

После широкого освещения данной уязвимости большинство разработчиков и заказчиков стали реже раскрывать версии используемого программного обеспечения. Для сравнения: 32% в 2019 году против 70% в 2016 году.

Как составить ТЗ для создания безопасного приложения

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

ак составить ТЗ для создания безопасного приложения

Основные требования должны выглядеть следующим образом:

  • Анализ на предмет уязвимости нулевого дня. Такие уязвимости НЕ известны до момента их обнаружения, не реализованы в различных эксплойтах. При этом, такие эти уязвимости представляют наибольший интерес для злоумышленников. Анализ проводится в “ручном” режиме опытными специалистами, существует также ряд автоматизированных средств, но они не всегда эффективны.
  • Статический анализ или SAST-анализ, (Static Application Security Testing). Крайней важный этап в процессе разработки. Учитывая истину – чем раньше обнаружена уязвимость – тем дешевле ее устранить, такой анализ должен проводиться регулярно. При статическом анализе проверяется сам код, без запуска приложения.
  • Динамический анализ или DAST-анализ (Dynamic Application Security Testing). В отличие от статического анализа при динамическом анализе проверяется работа приложения. Существует несколько программных комплексов для DAST-анализа, логика работы которых сводится к отсылке приложению различных команд и анализу ответов.

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

Как проверить выполненную работу

Не всегда на стороне заказчика имеются квалифицированные спецы из сферы информационной безопасности – да и в целом наблюдается серьезный дефицит таковых на рынке труда. Это объясняется в первую очередь большими затратами на содержание таких специалистов (средняя заработная плата Специалиста ИБ превышает уровень ИТ специалиста).

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

Самый идеальный вариант – когда аутсорсер изначально уделяет должное внимание аспекту безопасности кода – именно такой подход у нашей команды! 🙂 Ознакомьтесь с разделом “Услуги“. Будем рады видеть вас среди наших клиентов!

Поделиться

Tags: ,
Подборка стартапов разработанных на аутсорсе

Другие материалы

Меню