Инновационная безопасность

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

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

• Бизнес-разработка (Dev): приложение должно отвечать потребностям бизнеса и пользователей, которые зачастую быстро меняются.
• Безопасность (Sec): приложение должно быть устойчиво к атакам со стороны быстро меняющихся злоумышленников; кроме того, оно должно использовать нововведения в сфере кибербезопасности.
• ИТ-операции (Ops): приложение должно быть надежным и эффективным.

Объединить эти три требования и создать общую культуру критически важно, но зачастую несложно. Руководители команд по разработке, ИТ и безопасности должны стать движущей силой этих изменений. Дополнительные сведения см. в статье Требование к руководству: смешение культур.

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

Что такое DevSecOps?

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

Безопасность по умолчанию и сдвиг влево

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

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

В каскадной модели безопасность, как правило, представляла собой этап контроля качества после завершения разработки.

Методология DevOps расширила традиционную модель разработки (пользователи, процесс и технологии), включив в нее операционные команды. Это изменение снизило трения, которые проистекали из разделения команд разработки и операций. Аналогичным образом DevSecOps расширяет DevOps, снижая трения, проистекающие из разделения или разнородности команд безопасности.

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

Методология организации Cloud Adoption Framework предоставляет дополнительные сведения о структурах DevSecOps в организации. Дополнительные сведения см. в статье Общие сведения о функциях безопасности приложений и DevSecOps.

Почему следует применять именно DevSecOps?

DevOps обеспечивает гибкость, а DevSecOps — безопасную гибкость.

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

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

Злоумышленники могут воспользоваться следующими слабыми местами.

• Процесс разработки. Злоумышленники могут обнаруживать слабые места в процессе разработки приложения, например, при обмене данными с использованием слабого или ненадежного шифрования. Злоумышленники могут также обнаруживать слабые места в реализации проекта, например, код не проверяет входные данные и допускает такие распространенные атаки, как внедрение кода SQL. Кроме того, злоумышленники могут внедрить в код черный вход, который в дальнейшем позволяет им возвращаться для извлечения выгоды из вашей среды или среды клиента.
• ИТ – инфраструктура. Злоумышленники могут нарушать безопасность конечной точки и элементов инфраструктуры, на которых размещается процесс разработки, посредством стандартных атак. Злоумышленники также могут проводить многоступенчатые атаки с использованием украденных учетных данных или вредоносных программ для доступа к инфраструктуре разработки из других частей среды. Кроме того, риск атак цепочки поставки программного обеспечения делает крайне важной интеграцию безопасности в процесс для достижения следующих целей.
• Защита организации: от вредоносного кода и уязвимостей в цепочке поставки исходного кода.
• Защита клиентов: от любых проблем безопасности в приложениях и системах, которые могут нанести ущерб репутации, а также привести к неисполнению обязательств или другим негативным последствиям для деятельности организации.

Путь к DevSecOps

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

На этой схеме представлен жизненный цикл такого рода подхода к производству инноваций:

Безопасность инноваций — это интегрированный подход для обоих этапов.

• Развитие идей, где исходная идея создается, проверяется и подготавливается к первоначальному использованию в рабочей среде. Этот этап начинается с новой идеи и заканчивается, когда первый рабочий выпуск соответствует критериям продукта с минимальной функциональностью (MVP) для:
  • Разработки: функциональные возможности соответствуют минимальным бизнес-требованиям.
  • Безопасности: возможности соответствуют нормативным требованиям и требованиям к безопасности для использования в рабочей среде.
  • Операций: функциональные возможности соответствуют минимальным требованиям к качеству, производительности и поддерживаемости в качестве рабочей системы.
• DevOps: этот этап представляет собой непрерывный процесс последовательной разработки приложения или рабочей нагрузки, обеспечивающий непрерывное внедрение инноваций и совершенствование.

Требование к руководству: смешение культур

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

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

• Медленное создание ценности и низкая гибкость.
• Проблемы с качеством и производительностью.
• Проблемы с безопасностью

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

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

Методы руководства

Эти ключевые методы помогут руководству сформировать общую культуру.

1. Никто не выигрывает все споры. Руководители должны убедиться, что при принятии решений не преобладает одна-единственная позиция — это может привести к дисбалансу и негативно повлиять на бизнес.

2. Ожидайте постоянного улучшения, а не совершенства. Руководители должны сформировать ожидания постоянного улучшения и постоянного обучения. Создание успешной программы DevSecOpsтребует времени. Это непрерывный путь с постепенным прогрессом.

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

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

   • Срочность для бизнеса. Команда должна иметь четкое представление о доходе, о котором идет речь. Это представление должно включать текущий доход (если служба находится в автономном режиме) и потенциальный доход в будущем, который будет зависеть от задержки при доставке приложений и функций. Это должно быть основано непосредственно на сигналах от заинтересованных лиц в составе руководства.
   • Вероятные риски и угрозы. На основе входных данных команды по аналитике угроз, если таковая имеется, команда должна составить представление о возможных угрозах, с которыми столкнется портфель приложений.
   • Требования к доступности. Команда должна иметь общее представление об операционных требованиях, таких как требуемое время доступности, ожидаемое время существования приложения, а также требования к устранению неполадок и обслуживанию, например, исправление при подключении службы к сети.

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

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

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

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

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

Примечание

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

Выявление MVP DevSecOps

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

• Разработчики (dev) занимаются представлением бизнес-потребности для быстрой доставки возможностей, которые соответствуют ожиданиям пользователей, клиентов и руководителей компании. Определите минимальные требования, чтобы возможность помогала организации достичь успеха.
• Команда по безопасности (sec) занимается исполнением обязательств в отношении соответствия требованиям и защитой от злоумышленников, которые непрестанно стремятся нажиться на ресурсах организации. Определите минимальные требования для соблюдения нормативных требований, поддерживайте уровень безопасности и убедитесь в том, что операции по обеспечению безопасности позволяют быстро обнаруживать активную атаку и реагировать на нее.
• Команда по операциям (ops) занимается производительностью, качеством и эффективностью, гарантируя, что рабочая нагрузка продолжит приносить выгоду в долгосрочной перспективе. Определите минимальные требования, чтобы гарантировать выполнение и поддержание рабочей нагрузки без необходимости внесения значительных изменений в архитектуру или проект в обозримом будущем.

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

Интеграция безопасности в процесс

Требования к безопасности должны обращать внимание на интеграцию с существующими процессами и инструментами. Пример:

• Действия по проектированию, например моделирование угроз, необходимо интегрировать в этап проектирования.
• Средства проверки безопасности необходимо интегрировать в системы непрерывной поставки и непрерывной интеграции (CI/CD), такие как Azure DevOps, GitHub и Jenkins.
• Сообщать о проблемах безопасности следует с помощью тех же систем и процессов отслеживания ошибок, что используются для информирования о других ошибках, например, с помощью схемы приоритетов.

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

Дополнительные сведения о DevSecOps см. в статье Технические элементы управления DevSecOps.

Советы по прохождению пути

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

• Образование и культура — критически важные первые этапы.Воевать вам придется с той армией, что у вас есть. Вашей команде придется часто овладевать новыми навыками и внедрять новые перспективы для понимания других составляющих модели DevSecOps. Эти изменения, связанные с образованием и культурой, требуют времени, внимания, финансовой поддержки со стороны руководства и стандартных проверок, чтобы сотрудники могли в полной мере понять и увидеть пользу изменений. Коренные изменения, связанные с культурой и навыками, иногда могут затрагивать профессиональное самоопределение отдельных сотрудников и потенциально вызывать сильное сопротивление. Важно понимать и объяснять, зачем нужно изменение, что оно даст каждому сотруднику и ситуации и каким образом оно будет осуществляться.
• Изменения требуют времени. Вы можете двигаться не быстрее, чем команда адаптируется к новым способам работы. В ходе трансформации командам всегда приходится выполнять уже имеющуюся работу. Крайне важно тщательно расставлять приоритеты и управлять ожиданиями в отношении скорости осуществления изменений. Ваша организация выиграет от применения стратегии "ползком, шагом и только потом бегом", которая в первую очередь учитывает самые важные и базовые элементы.
• Ограниченные ресурсы. Как правило, организации на ранних этапах сталкиваются с проблемой поиска специалистов по безопасности и разработке приложений. По мере повышения эффективности совместной работы в масштабах организации можно отыскать скрытые таланты, например, разработчиков с типом мышления, подходящим для работы в области обеспечения безопасности, или специалистов по безопасности с опытом разработки.
• Меняющаяся природа приложений, кода и инфраструктуры. Техническое определение и композиция приложения радикально изменяются с внедрением таких технологий, как бессерверные технологии, облачные службы, облачные API и приложения без кода, например Power Apps. Этот переход меняет методики разработки, безопасность приложений и даже позволяет создавать приложения сотрудникам без опыта разработки.

Примечание

Некоторые реализации объединяют обязанности команд по операциям и безопасности в роль инженера по обеспечению надежности сайта (SRE).

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

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

Дальнейшие действия

Ознакомьтесь со статьей Технические элементы управления DevSecOps, чтобы получить более подробные рекомендации по DevSecOps.

Сведения о том, как расширенные функции безопасности GitHub интегрирует функции безопасности в конвейеры непрерывной поставки и непрерывной интеграции (CI/CD), см. в статье Расширенные функции безопасности GitHub.

Дополнительные сведения о внедрении DevSecOps ИТ-организацией Майкрософт и использованных для этого инструментах см. в статье Набор средств для безопасного выполнения DevOps.