Экспериментирование

Можно не знать, как достичь цели, поставленной впервые. Именно здесь на помощь приходит экспериментирование. Сюда может входить проведение проверки концепции для трех различных продуктов Runtime Application Security Protection (RASP), чтобы понять, какой из них лучше всего подходит для организации; проведение различных видов обучения для небольших групп разработчиков и последующее предоставление «лучшего» варианта обучения на основе оценки каждого вида; либо добавление собственного сценария в один конвейер, измерение результатов в течение нескольких недель, регулярное улучшение сценария, а затем распространение его на остальные конвейеры в организации. Нет ничего страшного в том, чтобы попробовать что-то и решить, что оно не подходит, – вы только что чему-то научились, и это имеет ценность. Кроме того, вы, скорее всего, сэкономили много времени и денег.

Сферы DevOps и стартапов славятся тягой к экспериментам, обучению и постоянному самосовершенствованию, чему способствуют структурированные методы и повторяющиеся процессы. Я настоятельно рекомендую следующие две книги по данной теме:

«Руководство по DevOps: Как добиться гибкости, надежности и безопасности мирового уровня в технологических компаниях» (Джин Ким, Джез Хамбл, Джон Уиллис и Патрик Дебуа, опубликовано IT Revolution Press, LLC), itrevolution.com/book/the-devops-handbook;

«Бережливый стартап: как современные предприниматели используют непрерывные инновации для создания чрезвычайно успешных предприятий» (Эрик Рис, (опубликовано издательством Crown Business), theleanstartup.com/book.

Обратная связь от всех и каждой из заинтересованных сторон

Любые отзывы важны. Разработчики, владельцы продуктов, менеджеры проектов, другие команды безопасности и остальные сотрудники IТ-отдела – все они ваши клиенты, так как используют программу и сервисы по обеспечению безопасности приложений. Их мнение имеет значение.

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

Перед выпуском какого-либо стандарта или политики нужно провести консультацию. Спросите разработчиков, какая поддержка им нужна для следования новому стандарту. Уточните, все ли им понятно в нем, согласны ли они с ним полностью либо частично. Пришедшие на обсуждение люди (даже если их будет совсем немного) – это, как правило, те, кому есть что сказать. Можно провести даже несколько собраний. Цель не в том, чтобы убедиться, что абсолютно все поддерживают нововведение, а в том, чтобы удостовериться, что наиболее активные разработчики согласны с ним и что вы не допустили грубых ошибок.

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

Особое замечание о DevOps и Agile

При определении цели программы безопасности не имеет значения, какой методологии разработки придерживаются программисты. У людей из среды DevOps в любом случае есть требования, а код, написанный Agile-командой, в любом случае нуждается в тестировании. Потребуется изменить именно тип действий и инструментарий, а не конечные цели.

Если разработчики основывают свою работу на спринтах, необходимо подстроиться под спринты. Если команды DevOps используют конвейеры CI/CD для выпуска своего кода, то лучше выяснить, какие инструменты лучше всего работают в их конвейерах.

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

Деятельность по обеспечению безопасности приложений

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

Рис. 7.1. Деятельность по обеспечению безопасности в жизненном цикле разработки системы

Вот список хорошо известных и широко распространенных практик.

Запуск сканирования уязвимостей (оценки уязвимости), вероятно, является наиболее распространенным видом деятельности инженеров безопасности. Запуск автоматизированного инструмента для выполнения DAST (динамического тестирования приложений) – быстрой и достаточно точной проверки, которая позволяет выявить порядочное количество уязвимостей, но тем не менее многое может упустить. DAST можно автоматизировать для запуска в конвейере, запускать по расписанию или вручную.

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

Моделирование угроз может варьироваться от «мозгового штурма зла» до более формальных действий – например, разработки деревьев атак или следования моделям STRIDE или PASTA. Определение всех возможных угроз для системы с последующим смягчением – ручной процесс.

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

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

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

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

Программы вознаграждения за найденные ошибки (Bug Bounty) – заранее спланированные, управляемые взаимодействия между исследователями безопасности и компаниями, позволяющие проводить тестирование безопасности продуктов либо любым исследователем, либо одобренным/приглашенным исследователем. Идея Bug Bounty заключается в создании конкуренции посредством вознаграждения только тех исследователей, которые находят уникальную и достоверную ошибку.

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

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

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

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

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

Предоставление инструментов IDE для обеспечения и усиления безопасности кодирования и управления пакетами.

Добавление средств обеспечения безопасности в конвейеры CI/CD разработчиков.