Как сохранить безопасность во время разработки 

Кирилл Иванов

Сооснователь и генеральный директор компании по разработке цифровых экосистем для банковских и страховых компаний Self, эксперт в области разработки и развития комплексных IT-продуктов

По информации МИД РФ, в 2021 году ущерб от действий хакеров может достичь шести триллионов долларов. В этом материале мы поделимся знаниями и опытом того, как интегрировать безопасность в процесс разработки.

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

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

Определяем модели угроз

Проработав требования заказчика, переходим к определению угроз.

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

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

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

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

Доступ к инфраструктуре

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

Ещё один способ обеспечения безопасности в команде — разделение ответственности. То есть ограничение доступа к компонентам и уровням программно-аппаратного комплекса.

Приведём пример того, как можно распределить задачи:

• системные администраторы — работают с аппаратной частью, отслеживают операционные системы;
• DevOps-инженеры — осуществляют управление кластерами, развёртывание системы, мониторинг на уровне кластеров и компонентов;
• администраторы БД — заняты исключительно управлением БД;
• администраторы программного комплекса — выполняют управление настройками ПО;
• инженеры по качеству — следят за уровнем ключевых показателей системы, выполняют разбор и локализацию инцидентов.
• разработчики — создают код программного обеспечения.

Проектирование и дизайн

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

Пять заповедей команды разработки на этапе проектирования:

1. Выделить подклассы ресурсов (с внешним доступом, с чувствительными данными, менее чувствительными, а также технологическими ресурсами, IoT).
2. Отсортировать ресурсы по базовым критериям информационной безопасности (происходит деление по необходимому типу доступа и требованиям конфиденциальности).
3. Выбрать дизайн сети с учётом полученных подклассов данных (базовый набор сегментов включает DMZ, ЛВС, сегменты конфиденциального характера, технологической информации, управления и прочие).
4. Выбрать средства защиты (к базовым инструментам относят +Sandbox, межсетевое экранирование, интеграцию антивируса, DDoS-защиту, WPA2, криптографию, центры мониторинга и иное).
5. Проработать вопрос взаимодействия информационных систем. Для безопасной работы нескольких ИС применяются специальные правила, которые указывают на необходимость пошагового исследования всех возможных багов.

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

Разработка и автоматизация тестирования

Чтобы упростить процесс безопасной разработки, следует максимально автоматизировать процесс тестирования. Эта рекомендация относится не только к безопасности, но и к проверке нормального функционирования и развития проекта в целом. Крупный проект с большим количеством постоянных изменений без автоматизированных проверок при развертывании и работе ПО начнёт давать сбои, что снизит лояльность клиентов и может привести к потерям в доходах.

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

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

Ещё одним способом проверки кода на уязвимости и ошибки является ревью кода.

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

Развёртывание

Чтобы процедура развёртывания проходила эффективно, разработчики безопасного ПО снова применяют методологию DevSecOps. При запуске ПО в эксплуатацию следует обратить внимание на последовательность внедрения компонентов, чтобы не возникало ситуаций, когда WAF (web application firawall) интегрируется после запуска самого приложения. Также после установки ПО на сервер нужно провести внешний аудит, нагрузочное тестирование, настройку мониторинга и сборку логов.

И самое важное, помнить о мантре всех security специалистов: безопасность — это процесс, который продолжается даже на этапе продакшена.

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