״Защитники мыслят списками, злоумышленники - графиками", - сказал Джон Ламберт из Microsoft, подчеркивая фундаментальную разницу в мышлении между теми, кто защищает ИТ-системы, и теми, кто пытается их скомпрометировать.
Традиционный подход защитников заключается в составлении списка пробелов в безопасности, непосредственно связанных с их активами в сети, и устранении как можно большего их числа, начиная с наиболее критичных. Злоумышленники, напротив, начинают с определения конечной цели и сосредотачиваются на прокладывании пути к нарушению. Как правило, они ищут самое слабое звено в цепочке безопасности, чтобы взломать его и продолжить атаку оттуда вплоть до "драгоценностей короны".
Команды безопасности должны учитывать точку зрения злоумышленника, чтобы обеспечить адекватную защиту кибербезопасности своей организации. Проводя аналогию с примером из повседневной жизни, можно сказать, что стандартный способ защитить наш дом от вторжения - убедиться, что все двери заперты. Но для подтверждения того, что ваш дом защищен, требуется протестировать вашу систему безопасности подобно взломщику: попытаться взломать замки, залезть в окна и поискать места, где ключи от дома могли бы "безопасно" храниться.
Тестирование на проникновение как раз отвечает этой потребности: оно дает злоумышленнику представление о том, что может быть скомпрометировано. Практика тестирования на проникновение существует уже несколько десятилетий, помогая выявить, насколько устойчивы наши сети к вредоносным атакам. Однако, поскольку современные предприятия все чаще используют облачные сервисы, столь же необходимо применять концепцию традиционного тестирования на проникновение к облаку.
В этом сообщении в блоге мы исследуем основные строительные блоки облачного пентестинга, уделяя особое внимание тому, как злоумышленники ищут и используют пробелы в безопасности в вашем облаке.
Для подготовки к различным сценариям взлома тесты на проникновение должны использовать разные отправные точки:
Вот пять ключевых строительных блоков для тестирования на проникновение в облако:
При традиционном сетевом пентестировании область тестирования обычно определяется IP-адресами конечных точек, которые будут включены в тест. Облачные ресурсы, напротив, идентифицируются с помощью уникальных идентификаторов, и доступ к ним осуществляется через API. Таким образом, типичный подход к рекогносцировке в облачных пентестах заключается в сборе информации об активах в начале тестирования путем подключения к облачному API организации.
Еще одним ресурсом, подверженным высокому риску, являются веб-приложения, которые обычно становятся мишенью хакеров, поскольку по своей конструкции они открыты для Интернета. Для подтверждения того, что средства контроля безопасности и программные реализации безопасности не допускают несанкционированного доступа к службам и конфиденциальным данным, тестирование на проникновение должно охватывать веб-приложения, размещенные в облаке. Тестирование должно включать 10 лучших рисков безопасности в OWASP, таких как проверка входных данных, внедрение SQL, межсайтовый скриптинг (XSS) и подделка запросов на стороне сервера (SSRF).
Однако сканирование уязвимостей - это только начало. Обнаруженные неправильные конфигурации и уязвимости необходимо протестировать на предмет возможности использования с целью распространения атаки точно так же, как это сделал бы злоумышленник. Например, при обнаружении общедоступного облачного хранилища его можно протестировать, просканировав содержимое на наличие ценных секретов или попытавшись извлечь данные.
Во-первых, сложность облачных архитектур IAM намного выше. Множество идентификационных данных человека и машины и сложные политики контроля доступа, внедренные для поддержки автоматического управления облачными ресурсами, вероятно, создают риски, которыми злоумышленники могут легко воспользоваться. Не только это, но и сочетание облачного и оперативного контроля доступа может привести к созданию очень сложной системы правил, а злоумышленники преуспевают в сложности.
Во-вторых, разработчики, использующие облачную инфраструктуру для создания своих приложений, часто помещают в свой код жестко запрограммированные секреты и могут забыть или пренебречь их удалением, предоставляя их доступ злоумышленникам.
В сценариях тестирования гибридной среды могут использоваться методы бокового перемещения для перехода от локальной среды к облачной или наоборот. Следовательно, изолированная защита облачной среды не сработает. На организации могут повлиять атаки, распространяющиеся по всей поверхности атаки - внутренней сети, внешним активам и облачным средам. Злоумышленники рассматривают организационные поверхности атаки не как разрозненные объекты, а скорее как единую поверхность, поэтому защитникам необходимо использовать аналогичный подход, работая в разных доменах для перехвата атак. Чтобы обезопасить облако, необходимо проверить все вмешательства, которые к этому ведут.
В облачном пентестировании следует оценить способность собирать и затем передавать данные во внешнее местоположение и утвердить средства управления сетевой безопасностью, чтобы проверить, предотвращают ли они распространение в известные IOC.
В заключение отметим, что эффективность программы облачного пентестирования определяется не только глубиной и широтой тестирования, но и частотой тестирования. Темпы изменений в локальных сетях наносят удар по эффективности длительных циклов ручного тестирования на проникновение. В облаке это сногсшибательно. Точно так же, как облачные службы и группы исследований и разработок автоматизируют свои облачные операции и развертывания, группы безопасности должны переключиться на автоматизацию своих действий по тестированию на проникновение в облако и, в конечном счете, дополнить цикл непрерывной интеграции / непрерывного развертывания непрерывной проверкой.
Чтобы с уверенностью подтвердить устойчивость вашей компании к облачным атакам, узнайте больше о Pentera Cloud и послушайте запись о том, как подвергнуть облачную безопасность стресс-тестированию, которая предоставляется по запросу.
Традиционный подход защитников заключается в составлении списка пробелов в безопасности, непосредственно связанных с их активами в сети, и устранении как можно большего их числа, начиная с наиболее критичных. Злоумышленники, напротив, начинают с определения конечной цели и сосредотачиваются на прокладывании пути к нарушению. Как правило, они ищут самое слабое звено в цепочке безопасности, чтобы взломать его и продолжить атаку оттуда вплоть до "драгоценностей короны".
Команды безопасности должны учитывать точку зрения злоумышленника, чтобы обеспечить адекватную защиту кибербезопасности своей организации. Проводя аналогию с примером из повседневной жизни, можно сказать, что стандартный способ защитить наш дом от вторжения - убедиться, что все двери заперты. Но для подтверждения того, что ваш дом защищен, требуется протестировать вашу систему безопасности подобно взломщику: попытаться взломать замки, залезть в окна и поискать места, где ключи от дома могли бы "безопасно" храниться.
Тестирование на проникновение как раз отвечает этой потребности: оно дает злоумышленнику представление о том, что может быть скомпрометировано. Практика тестирования на проникновение существует уже несколько десятилетий, помогая выявить, насколько устойчивы наши сети к вредоносным атакам. Однако, поскольку современные предприятия все чаще используют облачные сервисы, столь же необходимо применять концепцию традиционного тестирования на проникновение к облаку.
Облако не является безопасным убежищем - знайте, что вам нужно защитить
Облачные архитектуры включают ресурсы, идентификаторы и конфигурации, которые определяются программно и меняются быстрыми темпами. В результате облако может стать ящиком пандоры с дополнительной сложностью в области кибербезопасности. Хотя ведущие поставщики облачных услуг внедряют строгие методы обеспечения безопасности, это может создать ложное чувство безопасности у организаций, которые могут не осознавать свою ответственность за безопасность своих облачных активов, как определено моделью совместной ответственности за облако. По этим причинам пентестирование в облаке так же важно, как и традиционное тестирование на проникновение в сеть, а в некоторых случаях даже важнее.В этом сообщении в блоге мы исследуем основные строительные блоки облачного пентестинга, уделяя особое внимание тому, как злоумышленники ищут и используют пробелы в безопасности в вашем облаке.
Что должен охватывать ваш облачный Пентест
В зависимости от выбранной вами модели предоставления облачных сервисов границы вашей ответственности за безопасность могут различаться. В общих чертах, ответственность поставщиков облачных услуг заканчивается там, где начинается ваша ответственность. Поставщик облачных услуг несет ответственность за безопасность оборудования и базового программного обеспечения, обеспечивающего работу его сервисов. Вы несете ответственность за защиту всего, что вы создаете в облаке - ваших данных, ключей, активов, сервисов, приложений и конфигураций. Рассмотрим пример использования лямбда-функций для разработки облачных приложений в Amazon Web Services (AWS). Хотя AWS обеспечивает безопасность вычислительной инфраструктуры и инфраструктуры хранения данных, а также самого сервиса Lambda, вы несете ответственность за обеспечение безопасного доступа к коду и ресурсам вашей организации. Таким образом, вы сами должны убедиться, что ваши разработчики не хранят учетные данные в коде функций или переменных среды, которые могут быть использованы для компрометации конфиденциальных данных или их перемещения по сети в случае перехвата злоумышленниками.Для подготовки к различным сценариям взлома тесты на проникновение должны использовать разные отправные точки:
- Черный ящик - тестировщик не имеет начального доступа в облачной среде.
- Серое поле - тестировщик вводит учетные данные выбранного пользователя или роли в качестве исходных данных, чтобы показать потенциальное воздействие (оно же "радиус поражения") в случае взлома личности.
Вот пять ключевых строительных блоков для тестирования на проникновение в облако:
1. Разведка и обнаружение
Этот первый шаг включает в себя сопоставление всех активов облачной среды вашей организации; рабочих нагрузок, хранилища, баз данных и удостоверений. Информация, собранная на этом этапе, определяет объем ресурсов, которые могут быть использованы или нацелены в рамках тестирования, и базовую линию для инициирования атакующих действий.При традиционном сетевом пентестировании область тестирования обычно определяется IP-адресами конечных точек, которые будут включены в тест. Облачные ресурсы, напротив, идентифицируются с помощью уникальных идентификаторов, и доступ к ним осуществляется через API. Таким образом, типичный подход к рекогносцировке в облачных пентестах заключается в сборе информации об активах в начале тестирования путем подключения к облачному API организации.
2. Оценка уязвимостей
Необходимо выполнить анализ конфигурации облака и сканирование уязвимостей, чтобы выявить неправильные настройки и известные уязвимости программного обеспечения в ваших облачных ресурсах. Например, безопасность облачной сети следует оценивать путем оценки конфигурации элементов управления, таких как брандмауэры, виртуальные частные сети (VPN), параметры доступа и сегментации сети. Этот процесс необходим для выявления слабых мест, таких как общедоступные ресурсы или небезопасные пиринговые подключения к виртуальному частному облаку (VPC), которые могут допускать несанкционированный доступ, боковое перемещение, повышение привилегий и утечку данных.Еще одним ресурсом, подверженным высокому риску, являются веб-приложения, которые обычно становятся мишенью хакеров, поскольку по своей конструкции они открыты для Интернета. Для подтверждения того, что средства контроля безопасности и программные реализации безопасности не допускают несанкционированного доступа к службам и конфиденциальным данным, тестирование на проникновение должно охватывать веб-приложения, размещенные в облаке. Тестирование должно включать 10 лучших рисков безопасности в OWASP, таких как проверка входных данных, внедрение SQL, межсайтовый скриптинг (XSS) и подделка запросов на стороне сервера (SSRF).
Однако сканирование уязвимостей - это только начало. Обнаруженные неправильные конфигурации и уязвимости необходимо протестировать на предмет возможности использования с целью распространения атаки точно так же, как это сделал бы злоумышленник. Например, при обнаружении общедоступного облачного хранилища его можно протестировать, просканировав содержимое на наличие ценных секретов или попытавшись извлечь данные.
3. Повышение привилегий
Методы повышения привилегий могут предоставить злоумышленникам доступ к более конфиденциальным данным, приложениям и сервисам. Злоумышленники пытаются получить более высокие привилегии, используя:- Использование уязвимостей и неправильных настроек, предназначенных для получения более высоких привилегий в сети
- Пробелы в управлении идентификацией и доступом (IAM), такие как пользователи, входящие в группы, в которых они не должны находиться, и роли, которые являются чрезмерно разрешительными
- Компрометация удостоверений с более высокими привилегиями с помощью сбора учетных данных - набора методов, который включает в себя поиск и предоставление учетных данных, ключей и токенов сеанса, ненадлежащим образом хранящихся в различных источниках, включая, но не ограничиваясь ими, файлы, историю командной строки, реестр, переменные среды, средства развертывания и браузеры.
Во-первых, сложность облачных архитектур IAM намного выше. Множество идентификационных данных человека и машины и сложные политики контроля доступа, внедренные для поддержки автоматического управления облачными ресурсами, вероятно, создают риски, которыми злоумышленники могут легко воспользоваться. Не только это, но и сочетание облачного и оперативного контроля доступа может привести к созданию очень сложной системы правил, а злоумышленники преуспевают в сложности.
Во-вторых, разработчики, использующие облачную инфраструктуру для создания своих приложений, часто помещают в свой код жестко запрограммированные секреты и могут забыть или пренебречь их удалением, предоставляя их доступ злоумышленникам.
4. Боковое перемещение
Тестирование должно выявлять возможные пути между облачными ресурсами, которые злоумышленники могут использовать для сбора дополнительных конфиденциальных данных или секретов и продвижения своих атак.В сценариях тестирования гибридной среды могут использоваться методы бокового перемещения для перехода от локальной среды к облачной или наоборот. Следовательно, изолированная защита облачной среды не сработает. На организации могут повлиять атаки, распространяющиеся по всей поверхности атаки - внутренней сети, внешним активам и облачным средам. Злоумышленники рассматривают организационные поверхности атаки не как разрозненные объекты, а скорее как единую поверхность, поэтому защитникам необходимо использовать аналогичный подход, работая в разных доменах для перехвата атак. Чтобы обезопасить облако, необходимо проверить все вмешательства, которые к этому ведут.
5. Сбор и эксфильтрация данных
Сбор данных в облачных вычислениях относится к сбору данных из множества ресурсов, в основном конфиденциальных по своей природе, таких как кредитные карты, личная информация, пароли и т.д. Это основная причина, по которой злоумышленники проникают в сеть, чтобы завладеть конфиденциальной информацией. Иногда злоумышленники хранят данные в централизованном хранилище в качестве предварительного шага для концентрации данных, которые они хотели бы отфильтровать.В облачном пентестировании следует оценить способность собирать и затем передавать данные во внешнее местоположение и утвердить средства управления сетевой безопасностью, чтобы проверить, предотвращают ли они распространение в известные IOC.
Облачное пентестирование: ключи к успеху
Приступая к тестированию на проникновение в облако, крайне важно потратить некоторое время на понимание сферы применения ваших облачных сервисов и активов, а также того, какие части поверхности атаки находятся в ваших руках для защиты в соответствии с моделью совместной ответственности. После этого можно принимать обоснованные решения об инвестициях в облачное тестирование в контексте подверженности вашей организации рискам.В заключение отметим, что эффективность программы облачного пентестирования определяется не только глубиной и широтой тестирования, но и частотой тестирования. Темпы изменений в локальных сетях наносят удар по эффективности длительных циклов ручного тестирования на проникновение. В облаке это сногсшибательно. Точно так же, как облачные службы и группы исследований и разработок автоматизируют свои облачные операции и развертывания, группы безопасности должны переключиться на автоматизацию своих действий по тестированию на проникновение в облако и, в конечном счете, дополнить цикл непрерывной интеграции / непрерывного развертывания непрерывной проверкой.
Чтобы с уверенностью подтвердить устойчивость вашей компании к облачным атакам, узнайте больше о Pentera Cloud и послушайте запись о том, как подвергнуть облачную безопасность стресс-тестированию, которая предоставляется по запросу.
