Вопросы, которые вы должны задать себе о вашей облачной безопасности

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

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

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

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

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

1. Насколько наша облачная среда не соответствует требованиям?

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

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

2. Сколько уязвимостей мы выявили и устранили?

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

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

3. Сколько уязвимостей мы предотвратили от развертывания?

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

4. Встроена ли в вашей команде система безопасности в конвейеры непрерывной интеграции и непрерывной доставки (CI/CD)?

Проверяет ли ваша команда инфраструктуру как код (средство программного создания и развертывания облачной инфраструктуры) для поиска и исправления неверных конфигураций перед развертыванием, когда это происходит быстрее, проще и безопаснее? Если ответы здесь «нет», возможно, инфраструктура как код и конвейеры CI/CD не были приняты. Но если они используются, должен быть как минимум план по обеспечению безопасности этих процессов.

5. Защищаем ли мы плоскость управления облачным API?

Все взломы облака следуют одной и той же схеме: компрометация уровня управления. Интерфейсы прикладного программирования (API) являются основной движущей силой облачных вычислений; думайте о них как о «программных посредниках», которые позволяют различным приложениям взаимодействовать друг с другом. Плоскость управления API — это набор API, используемых для настройки и эксплуатации облака.

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

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

6. Насколько снижает производительность безопасность?

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

7. Как мы выражаем политику безопасности?

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

8. Насколько быстро мы можем реагировать на события нулевого дня?

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

9. Все ли команды имеют то, что им нужно для успеха?

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