Глава 6

Интеграция информационной безопасности в жизненный цикл доставки

Возможно, название движения DevOps выбрано неудачно — оно игнорирует такие функции, как тестирование, управление продуктами и информационная безопасность. Первоначальной целью движения DevOps было — отчасти — объединить разработчиков и команды техподдержки для создания взаимовыгодных решений в погоне за целями системного уровня, вместо того чтобы перебрасывать работу через стену и указывать пальцами друг на друга, когда что-то пошло не так. Однако этот тип поведения не ограничивается только разработкой и техподдержкой. Он возникает там, где различные функции в потоке создания ценности доставки программного обеспечения не работают эффективно вместе. Это особенно верно при обсуждении роли команд информационной безопасности. Информационная безопасность (infosec) является жизненно важной функцией в эпоху, когда угрозы повсеместны и постоянны. Тем не менее команды информационной безопасности часто плохо укомплектованы. Джеймс Уикетт, руководитель исследований в Signal Sciences, приводит соотношение: 1 специалист по информационной безопасности на 10 сотрудников инфраструктуры и 100 разработчиков в крупных компаниях (Уикетт, 2014). При этом они обычно участвуют только в конце жизненного цикла доставки программного обеспечения, когда уже часто мучительно больно и дорого вносить изменения, необходимые для повышения безопасности. Кроме того, многие разработчики не знают об общих рисках безопасности, таких как OWASP Top 10, и как их предотвратить.

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

«Сдвиг влево» по безопасности

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

Что означает «сдвиг влево»? Во-первых, проверки безопасности проводятся для всех основных функций, и этот процесс выполняется таким образом, что он не замедляет процесс разработки. Как мы можем гарантировать, что такое внимание вопросам безопасности не снизит производительность разработки? Это то, на что направлен второй аспект этой возможности: информационная безопасность должна быть неотъемлемой частью всего жизненного цикла доставки программного обеспечения от разработки до эксплуатации. Это означает, что эксперты infosec должны вносить свой вклад в процесс разработки приложений, присутствовать и предоставлять обратную связь по демонстрациям программного обеспечения, а также обеспечивать тестирование функций безопасности в рамках автоматизированного набора тестов. Наконец, мы хотим, чтобы разработчикам было легко делать все правильно, когда дело доходит до infosec. Это может быть достигнуто путем обеспечения простых в использовании, предварительно утвержденных библиотек, пакетов, наборов инструментов и процессов, доступных для разработчиков и служб техподдержки.

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

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

Во-вторых, команды информационной безопасности просто не имеют возможности проводить проверки безопасности при частых развертываниях. Во многих организациях безопасность и соответствие требованиям являются серьезным узким местом для перевода систем из статуса «разработка завершена» (dev complete) в жизнь. Привлечение специалистов infosec на протяжении всего процесса разработки также положительно влияет на коммуникационные и информационные потоки, а это и есть взаимовыгодная и основная цель DevOps.

Соблюдение требований в федеральном правительстве

Федеральные информационные системы подпадают под действие Федерального закона об управлении информационной безопасностью 2002 года (FISMA). FISMA требует, чтобы федеральные агентства следовали системе управления рисками, утвержденной NIST. Система управления рисками включает в себя несколько этапов, таких как подготовка плана безопасности системы, который документирует, как был реализован соответствующий контроль информационной безопасности (325 элементов контроля для систем умеренного воздействия), а затем оценка и отчет по ее результатам, который документирует одобрение этой реализации. Этот процесс может занять от нескольких месяцев до более чем года и часто только начинается после стадии «разработка завершена» (dev complete).

В целях сокращения времени и затрат на доставку федеральных информационных систем небольшая группа государственных гражданских служащих в отделе 18F создала платформу в виде службы под названием cloud.gov на основе открытой версии Cloud Foundry компании Pivotal, размещенной на Amazon Web Services. Большинство элементов контроля в системах, размещенных на cloud.gov, а именно — 269 из 325 необходимых для информационной системы умеренного воздействия, приняты на уровне платформы. Системы, размещенные на cloud.gov, могут пройти путь от dev complete до запуска в жизнь в течение нескольких недель, а не месяцев. Это значительно сокращает объем работ и, следовательно, затрат, необходимых для реализации требований системы управления рисками.

Подробнее можно прочитать здесь:

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

Движение за надежность

Для расширения движения DevOps с целью охватить проблемы информационной безопасности были предложены и другие названия. Одно из них — DevSecOps (придуманное такими известными людьми в отрасли, как Топо Пал из Capital One и Шеннон Литц из Intuit). Еще один вариант названия — «Надежный DevOps», придуманный Джошем Корманом и Джеймсом Уикеттом. «Надежный DevOps» — это комбинация из DevOps и «Манифеста Надежности» (Rugged Manifesto):

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

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