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

Зачем и от чего защищаться? Какие инструменты для этого существуют, в том числе Open Source? Что такое Secure Software Development Lifecycle? Александр Киверин — технический директор в Ак Барс Цифровые Технологии — рассказал об опыте своей компании на TechLead Conf 2020 Online. А мы подготовили расшифровку.

Зачем защищаться? На этот вопрос есть понятный ответ: уязвимость приложений может принести репутационные или финансовые риски компании (а, возможно, и те, и другие). Поэтому безопасность важна для всех. А от чего стоит защищаться?

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

• Инъекции – SQL, LDAP, XPath;

• Слабая криптография;

• Небезопасная передача информации;

• Некорректная обработка ошибок;

• Раскрытие информации;

• Cross-Site Scripting (XSS);

• Cross Site Request Forgery (CSRF);

• Ошибки в контроле доступов;

• Некорректная аутентификация и управление сеансами.

SSDLC 

«Думайте о безопасности на всех этапах жизненного цикла разработки ПО, с самого начала».

SDLC — Software Develop Life Cycle — это жизненный цикл разработки ПО, который включает следующие этапы:

• проработка требований или анализ;

• разработка архитектуры;

• непосредственно сама разработка;

• тестирование;

• выкладка.

Соответственно, Secure SDLC — это забота о безопасности на каждом этапе. 

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

После чего стоит сделать тестирование безопасности. А во время деплоя позаботиться о правильной конфигурации приложений.

SSDLC и итерации

Многие из нас работают в гибких парадигмах Agile. И чаще всего речь идет о каком-то итеративном фреймворке, например, о Scrum. Как SSDLC ложится на наши итерации?

По сути, мы имеем те же фазы жизненного цикла разработки ПО, только они перемешаны или наложены друг на друга.

При итерационном подходе разработка приложения проходит несколько этапов:

• проработка спринтового бэклога;

• аналитика (особенно если делаем что-то комплексное);

• планинг спринта;

• разработка;

• тестирование во время разработки;

• feature freeze;

• релиз.

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

Проработка бэклога (PBR)

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

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

Например, в Ак Барс Цифровые Технологии завели для уязвимостей отдельный тип запросов в JIRA. Он очень похож на шаблон дефекта: есть priority, severity, описание, шаги воспроизведения и т.д. 

Анализ 

«Анализируйте риски при проектировании решений и при проработке функциональных и нефункциональных требований».

На этапе анализа, помимо проработки требований пользовательских историй, нужно заботиться об анализе рисков.

Что такое анализ рисков? Наверное, все слышали про модель угроз, но представление о ней у всех разное. В Ак Барс это происходит следующим образом: для приложения или куска функциональности стараются создавать модели угроз, основанные на так называемом DFD (Data Flow Diagrams):

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

Планирование итерации

«Поднимайте приоритеты для критичных уязвимостей, “продавайте” технические задачи».

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

Как в Ак Барс Цифровые Технологии «продают» уязвимости?

Есть поле Priority —  стандартная градация приоритета, как у большинства типов issues. 

У уязвимостей, как и у дефектов, есть отдельное поле Severity (серьезность). Кроме того, у Severity должна быть своя градация (Critical, High, Medium, Low, Info). От этого Severity зависит то, как быстро нужно устранить все эти уязвимости. Например, можно заявить количество дней.

Также стоит ввести еще один параметр — Risk. По сути — это некоторый количественный параметр от Severity, его scoring:

Risk = Severity score = (Application score + Business Impact)/2

Risk зависит от Application score, который дают разные инструменты для безопасности:

Application score = InCode Severity score или Nessus Severity score или SonarQube Severity score

Кроме того, в компании учитывается Business Impact, то есть влияние на бизнес, когда уязвимости могут повлечь за собой какие-то финансовые угрозы, репутационные риски либо что-то, связанное с privacy клиентов. Все это усредняется и получается некая цифра:

Business Impact = (Financial Damage + Reputation Damage + Non-Compliance + Privacy Violation)/4

Эту цифру можно показать Product Owner.  Увидев высокий показатель Business Impact, он поймёт, что стоит взять эту задачу в работу и повысить ее приоритет.

Разработка 

«Следите за всеми временными решениями в приложении, смотрите на все типы угроз по тому же OWASP».

Есть такая аббревиатура — OWASP — Open Web Application Security Project.

Это открытый проект обеспечения безопасности веб-приложений. Он описывает разные уязвимости и способы борьбы с ними. А кроме того, предоставляет некоторые open source инструменты.

OWASP определяет Top Ten угроз:

• (A1) Injection;

• (A2) Broken Authentication;

• (A3) Sensitive Data Exposure;

• (A4) XML External Entities (XXE);

• (A5) Broken Access Control;

• (A6) Security Misconfiguration;

• (A7) Cross-Site Scripting (XSS);

• (A8) Insecure Deserialization;

• (A9) Using Components w/ Known Vulnerabilities;

• (A10) Insufficient Logging & Monitoring.

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

Что поможет предотвратить угрозы:

(A1) Инъекции.

• Объектно-реляционное преобразование (ORM). Чаще всего в них уже вшиты определенные вещи, связанные с обработкой данных.

• Валидация пользовательского ввода.

• Экранирование данных.

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

(А2) Некорректная аутентификация.

• Алгоритм хеширования не слабее SHA256.

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

• Сессионный токен.

• Защита от перебора пароля.

• Сложность вводимого пароля.

• 2FA. Желательно использовать двухфакторную авторизацию там, где это не ломает пользовательский путь.

(А5) Нарушенный контроль доступа.

• Механизмы контроля доступа, чтобы злоумышленник не попал туда, куда нельзя. 

• CORS. Это настройка веб-сервера таким образом, чтобы не было нежелательных redirect’ов на недоверенные домены. Когда вы пропишете доверенные домены, приложение будет работать только с ними. А значит, атаки типа CSRF уже навряд ли пройдут.

• Инвалидация сессии (для JWT-токенов). Раз мы говорим про токены (SSO-сценарий), то нужно иметь механизм отзыва сессий в случае ЧП.

• Логирование нарушенного контроля доступа. Опять же мы должны логировать, триггерить, анализировать, либо сразу алертить, если вдруг появилась нездоровая активность.

• Rate limit. Некоторые сервисы с высокой нагрузкой или часто используемые в других клиентах выставляют ограничения типа «Ко мне можно стучаться не больше N раз в минуту». В этом нет ничего страшного, зато они защищены от разных DDoS-атак.

(А6) Ошибки в конфигурировании:

• Удалять лишние файлы и тестовый функционал в релизе.

• Отключать неиспользуемые компоненты.

• Отключать неиспользуемую функциональность.

Важно, чтобы не оставалось никаких дыр. Если забыть что-то протестировать, злоумышленник может найти это при помощи сканеров.

(А7) XSS (когда злоумышленник пытается выполнить свой JavaScript в нашем приложении).

• Экранирование входных данных.

• Content Security Policy (CSP).

• X-XSS-Protection.

• Сookies: HTTP-only, Secure, SameSite.

• Библиотеки / фреймворки (например, Microsoft AntiXSS).

(A10) Недостаточное Избыточное логирование.

OWASP говорит о недостаточном логировании для того, чтобы мы могли иметь какие-то данные для анализа. Но логичнее все же затронуть момент избыточного логирования. Особенно если речь идет о финансовом секторе.  

• PAN, CVV / CVC;

• PIN карты;

• Пароли и OTP;

• Токены и cookie;

• ФИО, персональные данные;

• Серия и номер паспорта.

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

Code Review 

«Ревьюйте код не только на соблюдения правил написания кода и архитектуры, а также на наличие потенциальных дыр».

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

Например, такое не должно проходить:

Тестирование и Feature Freeze 

«Встройте в проверки QA анализаторы SAST и DAST, следите за алертами по уязвимостям, атакам, логам».

Если вы используете практику Feature Freeze для того, чтобы провести регрессионное тестирование в конце и все-таки удостовериться, что все ОК, можно встроить какие-то автоматические проверки. Для этого существуют разные анализаторы. Ниже поговорим о действующих инструментах.

Проверка при сборке

Часто используются SAST-анализаторы. Например, можно применять следующий инструментарий:

Solar APPscreener. Поддержка большого количества языков (самые востребованные: C#, JS, Java, Python). Это классный инструмент, хоть и не бесплатный.

SonarQube. Оценка качества кода. Имеет большое количество плагинов, среди которых dependency-check. Этот инструмент также очень распространен в разработке. Наверняка многие из вас его используют. Он отвечает за качество кода, но может работать и с уязвимостям. Есть community edition, можно использовать бесплатно.

Dependency Check. Нахождение уязвимых зависимостей — библиотек и модулей. Можно использовать бесплатно. 

Trivy. Проверка контейнеров на уязвимые компоненты. Интересный инструмент (и тоже бесплатный).

Проверка при деплое

Есть такой класс инструментов, как DAST-анализаторы — Dynamic Application Security Testing — это анализ на наличие уязвимостей выполняемого приложения. По сути DAST делает тест черного ящика.

При деплое в Ак Барс Цифровые Технологии пользуются следующими инструментами:

ZAP от OWASP. Бесплатный инструмент. Расширяемый, с большим количеством проверок. Автоматизируемый и вшиваемый в CI/CD.

Burp Suite. Инструмент для ручного тестирования веб-приложений.

Nessus. Сканер уязвимостей. Инструмент платный, но есть неплохая бесплатная альтернатива OpenVAS.

WFuzz. Бесплатный инструмент для тестирования уязвимостей подачи на вход некорректных данных. 

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

Артефакты

«Фиксируйте факт релиза, прикладывайте результаты проверки – у нас заявка с артефактами на безопасников».

Хорошая идея — оставлять артефакты при релизе. Делать это при проверке как на дефекты, так и на уязвимости — крутая практика, потому что если что-то случилось, это потом можно проанализировать.

В Ак Барс используют классный бесплатный инструмент DefectDojo, который агрегирует в себе все уязвимости из большого числа инструментов. Кроме того, он умеет генерировать отчет, посмотрев который можно понять, все ли ОК.

Релиз 

«Релизьте только при отсутствии критичных дефектов и уязвимостей – дефекты S1/S2 с P1 являются блокерами для деплоя».

Главное — релизить без критичных дефектов! Серьезность (Severity) на дефектах у quality assurance инженеров должна иметь такую градацию (у уязвимостей она чуточку другая):

• S1 Блокирующая (Blocker);

• S2 Критическая (Critical);

• S3 Значительная (Major); 

• S4 Незначительная (Minor);

• S5 Тривиальная (Trivial).

А приоритет содержит такую градацию:

• P1 Highest;

• P2 High;

• P3 Medium;

• P4 Low; 

• P5 Lowest.

Собственно, наличие багов S1/S2 и P1 является блокером для деплоя версии на прод.

Автоматизация проверок 

«Проверяйте уязвимости в сборках и контейнерах, лучше с возможностью автоматически заблокировать релиз».

Автоматизировать проверки можно, например, при помощи инструмента Trivy, который вшивается в CI/CD pipeline и сам чекает контейнеры. Но важно, чтобы сам CI/CD pipeline не нарушился. В идеале делать это фоном, триггерить, алертить и т.д.

Расположение (микро)сервисов 

«Соблюдайте требования стандартов безопасности, часть сервисов размещайте в более защищенной зоне».

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

Есть разные стандарты безопасности. Например, в банковской сфере существует стандарт PCI DSS, который регламентирует то, как именно нужно защищать сервисы, обрабатывающие карточные данные. 

В Ак Барс Цифровые технологии используют такой CI/CD pipeline в разные контуры:

Recovery policy

«Предусмотрите откат в случае проблем. Особенно с уязвимостями. Помните принципы DevOps – CALMR».

Еще один важный момент на жизненном цикле разработки ПО — откаты (Recovery). Особенно это актуально, если все же появилась уязвимость. 

И еще один момент. Когда вы работаете, не обязательно ждать дней Feature Freeze или таски на то, чтобы что-то поправить. С уязвимостью лучше работать так: увидели — пофиксили, потому что уязвимость — это критично.

Security Champions

«Не обязательно AppSec инженер должен все делать, команда может иметь амбассадора. Security Champions».

Для того, чтобы практики безопасной разработки действительно распространялись на все команды, вводятся Security Champions. Это амбассадоры безопасности, которые присутствуют в командах.

Security Champion — это не человек, а роль, которую на себя может примерить Quality Assurance инженер, аналитик, разработчик и пр.

Разработчики часто тяготеют к тому, чтобы заниматься исследованием уязвимостей и понимать, что такое безопасная разработка. У Quality Assurance инженеров есть целая ветка безопасного тестирования, и они должны изучать угрозы. Аналитики тоже часто тяготеют к моделированию угроз.

Важно найти в компании людей, которых заинтересует эта область, и обучать их. 

Основные компетенции и знания Security Champion:

• организация SSDLC

• законодательные и регуляторные требования безопасности;

• OWASP Top 10 Web and Mobile;

• основные виды угроз ИБ, понимание рисков ИБ.

Этих умений достаточно для того, чтобы человек мог отвечать за безопасность. 

В идеале SecChamp хорошо бы иметь дополнительные навыки: 

• безопасная разработка – уязвимый код, способы решения; 

• проведение тестов безопасности – ручное тестирование инъекций;

• проведение тестов безопасности – запуск сканеров безопасности;

• написание кейсов для фаззинга приложений;

• криптография – виды, лучшие практики, применение в приложениях;

• тестирование новых инструментов для тестирования безопасности и т.д.

Правила, инструкции и гайды

«Ведите knowledge base в confluence с правилами и требованиями, обязательное соблюдение командами. Пишите инструкции как для команды в целом, так и для Security Champions в частности»?.

Чтобы Security Champions развивались, нужно подготовить инструкции и гайды примерно такого характера:

• welcome guide;

• рекомендации к проведению контроля исходного кода;

• рекомендации к проведению оценки защищенности;

• требования безопасности к системам логирования;

• методика моделирования угроз;

• основные нормативно-правовые документы;

• внедренные системы безопасности и их настройка;

• обучающие материалы по информационной безопасности.

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

Помните: безопасность касается всех. Любые приложения подвержены рискам и могут привести к потерям компании. Следите за своей безопасностью, защищайтесь и будьте здоровы!

TechLead Conf 2021 — конференция, полностью посвященная инженерным процессам и практикам — откроет свои двери со дня на день: 30 июня и 1 июля она пройдет в Radisson Slavyanskaya (Москва). Расписание готово. Билеты пока ещё в продаже. А ещё у нас открыт доступ к докладам TechLead Conf 2020.

До встречи в офлайне и онлайн!