Дарья Орешкина, 04/09/20
Однажды в кафе произошел занимательный диалог официанта и посетителя:
– Я просил не курицу, а говядину, и не полусырую, а прожаренную.
– Да, вышла небольшая ошибка, извиняемся, но у нас все свежее, так что приятного аппетита!
– Я хирург. Верно ли я понял, что когда вы ко мне попадете и я вместо аппендицита удалю что-нибудь другое, потом просто извинюсь, то это будет правильно и всех устроит результат?
Стоит ли уточнять, какое было тщательное обслуживание после этого…
Невольно задумываешься: только ли медицина или питание должны быть безопасными и давать требуемый результат? Какова ответственность DevOps за свой продукт? Является ли экономия бюджетов основанием для выпуска уязвимых программных продуктов?
Автор: Дарья Орешкина, директор по развитию бизнеса компании Web Control
Коммерческая компания или сотрудник любой организации гипотетически хотели бы добиваться восхитительных результатов, быть востребованными обществом, прикладывая к этому разумные усилия. Рассмотрим прикладную задачу, составляющую часть пути к успеху, – переход от DevOps к гармоничному DevSecOps.
DevOps предполагает совместную работу разработчиков и служб эксплуатации для ускорения релиза. В случае DevSecOps при разработке ПО учитываются также цели создания безопасного продукта. Какие шаги предпринять, чтобы наиболее рационально встроить средства обеспечения комплайнс и безопасности в существующий DevOps-процесс?
4 ключевых ингредиента
Можно сказать, смягчая аналогию из диалога выше, что разработка ПО отчасти похожа на выпечку хлеба, где четыре основных ингредиента (мука, дрожжи, вода и соль), соединенные вместе, образуют крепкую, но пластичную структуру. Для разработки ПО нужна хорошая основа, которая обеспечит нужный вкус и требуемый результат продукции на выходе из печи. А качественная основа – это не только "красота" релиза, это еще и безопасность.
Торговля, финансы, здравоохранение, государственный сектор – требования к безопасности ПО в этих отраслях очень высоки. Однако количество разработчиков обычно в сотни раз превышает число специалистов по информационной безопасности и аудиторов, поэтому проверка безопасности и комплайнса становится "узким горлышком" процесса разработки. Чтобы избавиться от этого, необходимо автоматизировать процессы обеспечения безопасности и встроить их в конвейер разработки и поставки ПО, для чего требуются четыре ингредиента:
- 1. Сдвиг задач комплайнса и безопасности на наиболее ранние этапы в конвейере разработки.
- 2. Интеграция автотестирования безопасности и комплайнса в процесс непрерывной поставки.
- 3. Отслеживание состояний каждого шага создания продукта.
- 4. Наглядное представление и оценка уязвимостей безопасности.
Эти четыре ключевых ингредиента помогут любой компании из любой отрасли гармонично перейти от DevOps к DevSecOps.
Сдвиг задач комплайнса и безопасности на наиболее ранние этапы в конвейере разработки
Как правило, разработчики создают код и отдают его на тестирование. Результатом тестирования на уязвимости становится многостраничный отчет, выполнение бесчисленных рекомендаций из которого часто означает срыв сроков релиза.
Концепция DevSecOps предполагает включение процессов идентификации, исправления и предотвращения проблем безопасности и нарушений комплайнса на наиболее ранних этапах жизненного цикла разработки. Разработчик уже при написании кода может получать рекомендации по обеспечению его безопасности. В этом случае у команды есть возможность в штатном режиме исправлять недочеты. В идеале данные задачи должны быть автоматизированы и встроены в конвейер разработки, а перед встраиванием целесообразно провести ревизию средств тестирования безопасности продукта. Вполне возможно, что некоторые решения 10-или 15-летней давности можно заменить другими инструментами мониторинга безопасности приложений и статического анализа кода и сделать процесс проверки на безопасность более простым и точным.
Интеграция автоматических проверок безопасности, которые начинаются на этапе разработки и продолжаются вплоть до эксплуатации, позволяет гарантировать безопасный код с первого коммита до окончания поддержки релиза.
Shift Left ("сдвиг влево") для обеспечения безопасности и комплайнса с ранних этапов не означает, что решение этих вопросов перекладывается целиком на разработчиков. Наибольшая эффективность достигается, когда разработчики, службы эксплуатации и информационной безопасности работают над этим вместе.
Интеграция автотестирования безопасности и комплайнса в процесс непрерывной поставки
Автотестирование является наилучшей практикой для команд, принявших концепцию непрерывной доставки. Автоматизация тестирования комплайнса и безопасности с помощью инструментов статического анализа и композиции кода, таких как Fortify, SonarQube, WhiteSource, – весьма распространенный выбор для разработчиков и служб ИБ. Инструменты статического анализа дают возможность проверить, соответствует ли конкретный кусок кода требованиям безопасности и регуляторов. В подавляющем количестве проектов активно используется Open Source, поэтому инструменты автоматизации проверки компонентов с открытым исходным кодом и их зависимостей становятся незаменимы, в частности WhiteSource помогает выбрать качественные компоненты на этапе их выбора и включения в проект. Лучшей практикой становится объединение результатов всех тестов с другой информацией, относящейся к релизу ПО, – это позволяет видеть всю картину выпуска ПО целиком и всеми заинтересованными лицами.
В большинстве крупных компаний оценка безопасности и комплайнса не всегда может быть представлена в виде "соответствует/ не соответствует". Часто владелец продукта, менеджеры релиза, специалисты по безопасности и комплайнсу принимают решение о выпуске продукта на основе бизнес-целей, несмотря на выявленные проблемы. Немаловажный нюанс в том, что большинство из названных специалистов не настолько близки к процессу разработки, как разработчики, и, возможно, они никогда не видели результаты автотестов. Но для принятия решения им нужно иметь доступ к этим результатам и понимать, что они означают применительно как к отдельным функциям продукта, так и к релизу в целом.
Отслеживание состояний каждого шага создания продукта
"Сдвиг влево" и интеграция проверок безопасности и комплайнса в конвейер разработки ПО создает большой объем данных. Одним из вариантов их использования является создание цепочки учета событий каждого релиза. Она представляет собой набор подробно зафиксированных результатов всех действий в процессе разработки, в которых содержится информация о том, что произошло, когда и кто это сделал. Автоматический захват данных и учет позволяют бизнесу отслеживать процесс разработки и фиксировать результаты каждого этапа, предоставлять аудиторам нужную информацию и подтверждать выполнение всех проверок. Наличие такой цепочки учета событий дает возможность провести разбор ошибок в случае сбоя, накапливая суммарные знания компании и облегчая расследование инцидентов. Кроме того, команды получают инструмент для непрерывного управления качеством продукта, обнаруживая все недочеты на самых ранних стадиях: невыполненные действия или действия, которые регулярно не выполняются либо выполняются с ошибкой, ручные процедуры, которые можно автоматизировать.
Наглядное представление и оценка уязвимостей безопасности
Только лишь сбора данных о соблюдении требований безопасности и комплайнса и учета действий в процессе релиза недостаточно. Нужна гарантия, что каждое лицо, вовлеченное в процесс поставки ПО, может получить наглядные сведения и оценку соблюдения требований для своих целей.
Корпоративная цепочка инструментов поставки ПО обычно состоит из множества специализированных инструментов, каждый из которых предоставляет свои данные и свою отчетность. Но отдельные отчеты не позволяют увидеть общую картину разработки в целом. А без общей картины трудно понять, какие действия для обеспечения безопасности и комплайнса нужно предпринять.
Важно автоматически извлекать необходимые данные из инструментов DevOps, подставлять их по требованию и добавлять в контекст, с помощью которого эти данные можно осознать.
Например, результаты тестирования безопасности отдельного функционала не помогут специалисту по комплайнсу идентифицировать нарушение. Однако если он увидит, как этот функционал используется, взаимодействует с другими функциями и разворачивается, то нарушение может стать очевидным.
Фундаментальные принципы DevSecOps
Джин Кин, консультант по стратегическим вопросам компании XebiaLabs и автор ряда книг по DevOps, сформулировал ключевые принципы DevSecOps:
- При проектировании необходимо учитывать самые худшие сценарии. Пользователи не всегда следуют оптимальному или ожидаемому сценарию. Нужно учитывать злонамеренные пользовательские истории и проверять возможность их реализации, моделировать ландшафт угроз и проводить симуляцию разных уровней сбоев.
- Тестирование безопасности на каждом этапе конвейера. Можно использовать инструменты реальной атаки типа Metasploit. Безопасность должна быть не в виде бумажного документа, а в виде кода, хранящегося в репозитории, откуда его может взять любой разработчик. В конвейер должны быть встроены SAST-, DAST-, IAST-инструменты и инструменты проверки компонентов Open Source.
- Тренировок AppSec недостаточно. Нет также необходимости тренировать всех разработчиков писать безопасный код. Код пишут люди, и на 10 тыс. строк кода будет определенное число ошибок, часть из них приведет к уязвимостям. Тренировками эту проблему не решить. Нужны подходящие инструменты и автоматизация.
