Быстрее, дешевле, надежнее: зачем приложениям нужна безопасность?

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

13 лет AGIMA работает с крупными заказчиками. Мы знаем изнутри требования и возможности служб безопасности больших корпораций. Еще четыре года назад к вопросам безопасности мы подходили несистемно, занимались этим только по запросу: например, к нам приходили с результатами сканирования проектов на безопасность, и мы устраняли уязвимости. В 2017 году мы поняли, что это пора систематизировать. Так в AGIMA появился свой отдел, который отвечает за информационную безопасность.

Для нас информационная безопасность — неотъемлемая часть производственного процесса. Мы должны быть уверены, что продукт, который мы выпускаем, прошел проверку не только на функциональные баги, но и на наличие уязвимостей. Алексей Клинов, руководитель направления информационной безопасности AGIMA, рассказал, зачем защищать мобильные и веб-приложения, почему о безопасности нужно думать заранее и каким может быть security-контроль в заказной разработке. Краткий гайд и профит внедрения безопасности — в нашей статье.

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

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

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

Заказчиком приложения выступает бизнес. Бизнесу нужно рабочее приложение с высокой производительностью и без функциональных багов. Чем быстрее такое приложение запустится и выйдет в продакшн, тем скорее клиенты начнут получать пользу, а бизнес — зарабатывать.

Каким бы идеальным с точки зрения функционала ни было приложение, в нем могут присутствовать артефакты, о которых бизнес не знает и которые ни на что не влияют до определенного момента. Пока не появляется тот, кто воспользуется ими в корыстных целях. Например, недобросовестный конкурент или человек, который ради развлечения захотел что-то «поломать». Действия злоумышленников нарушают безопасность данных и могут негативно повлиять на работу приложения и всего ресурса в целом, вплоть до полной остановки веб- или мобильного сервиса. Уязвимости также могут стать точкой входа злоумышленника в IT-инфраструктуру самой организации.

Несколько месяцев назад к нам пришел проект, который никогда не подвергался проверке на безопасность. Мы увидели более 700 артефактов из категории уязвимостей. Конечно, если отфильтровать все ложные срабатывания и незначительные артефакты, оставив только блокеры и критические, картина будет не такая ужасная. Но это тот багаж технического долга, который в любом случае требуется обработать!

Мы ранжируем уязвимости и составляем роадмап, где отмечаем, за сколько итераций критические уязвимости нужно устранить. Это зависит от участка кода, который они затрагивают, какие данные можно получить, используя эти уязвимости. Насколько велика вероятность того, что злоумышленник воспользуется конкретной уязвимостью.

На этот кейс было затрачено более 200 человеко-часов на «просев» и устранение найденных уязвимостей и только после этого приступили к полноценному развитию продукта.

Позаботьтесь о безопасности приложения заранее. Введите security code review и проверяйте код на уязвимости с самого начала разработки. Когда приложение будет в предпроде или выйдет в продакшн, примените инструментальное сканирование или проведите полноценный pen-тест, — так можно обнаружить уязвимости, которые не были найдены методом статического анализа в процессе разработки. Внедрите Web Application Firewall (WAF) и защиту от DDoS-атак. Это будет дополнительным рубежом защиты боевого приложения.

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

Для себя мы выделили три подхода, которые варьируем в зависимости от проектов и потребностей заказчика:

• полная интеграция в процесс разработки (CI/CD)
  

• ревизия безопасности на контрольных точках

• ситуационная или разовая ревизия безопасности

Идеальный вариант — когда сроки, бюджет и бизнес позволяют интегрировать процессы по безопасности в ежедневный цикл работы с кодом.

Система оповещает разработчиков о коммитах, не прошедших проверку, и просит убедиться, что уязвимости устранены или же просит указать причину, почему их устранять не нужно. Далее тимлид принимает окончательное решение.

Такая система подходит для длительной разработки или поддержки проектов с частыми релизами.

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

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

Такую проверку мы применяем к простым проектам, которые не требуют промежуточных точек для контроля. Лендинг достаточно проверить один раз перед выпуском. Внедрять сканирование кода в процесс на таких проектах бессмысленно, эффективнее сделать это разово.

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

Грамотная комбинация перечисленных подходов позволяет плавно встроить информационную безопасность в процесс разработки.

• снижение количества потенциальных уязвимостей на релизе

• минимизация технического долга продукта

• сокращение сроков вывода приложения в прод
  

• уменьшение репутационных рисков
• уменьшение стоимости устранения уязвимостей
  
• уменьшение количества независимых проверок приложения
  

Внедрение информационной безопасности в разработку приложений — это не раздувание сметы и сроков.

Если это игнорировать с самого начала, то после запуска продукта так или иначе придется столкнуться с вопросом безопасности, но это в большинстве случаев гораздо дороже.