Тестирование на проникновение в облачную инфраструктуру
Многим интересно, как проходит пентест и насколько он страшен. Это напрямую зависит от степени готовности организации к такого рода мероприятию. Если вы разобрались с деталями, выполнили необходимые требования и инфраструктура вашей компании защищена в соответствии с установленными стандартами безопасности, пентест пройдет успешно.
Тесты на проникновение проводятся в назначенный срок. Используя наработанные методики и специализированные инструменты, уполномоченная пентест-команда со стороны аудитора организует различные сценарии атак, в том числе с учетом человеческого фактора. В каждом отдельном случае используется уникальный набор решений. До начала пентеста в «ИТ-ГРАД» подготовили два скопа:
- в первом разместили служебные сервисы, тестовые приложения, организовали доступ извне;
- во втором развернули ВМ с предустановленной ОС, назначили необходимые права соответствующим учетным записям.
Пример скопа с размещенными сервисами и приложениями
На что обратить внимание до начала пентеста
Убедитесь, что созданные аккаунты не обладают чрезмерными полномочиями. Предоставляйте учетным записям ровно столько прав и разрешений, сколько требуется для выполнения определенного ряда задач. До проведения пентеста аудитор высылает тестовое приложение, которое необходимо развернуть в инфраструктуре организации и обеспечить защиту средствами WAF.
старший системный администратор «ИТ-ГРАД»
Как проходил пентест в «ИТ-ГРАД»
Прежде всего «ИТ-ГРАД» согласовал с проверяющей стороной сроки начала пентеста и предоставил необходимый набор документов с подробным описанием инфраструктуры:
- Общее описание сертифицируемого бизнес-процесса и информационной инфраструктуры.
- Схема сети.
- Перечень компонентов информационной инфраструктуры.
- Перечень белых IP-адресов с описанием назначения каждого.
- Перечень средств сегментации и сокращения области аудита PCI DSS.
- Имеющиеся инструкции ко всем приложениям и API.
- Перечень и описание ролей пользователей, существующих в каждом приложении, и многое другое.
После чего в установленное время команда аудиторов в области информационной безопасности начала тестирование на проникновение в информационную систему «ИТ-ГРАД». Помимо технических проверок проводилось тестирование возможности проникновения в информационную систему с использованием метода социальной инженерии. В ходе пентеста аудиторы выполнили проверку средств сегментации и сокращения области аудита PCI DSS. Полученные результаты свидетельствовали о том, что принятые в «ИТ-ГРАД» меры по сегментации и сокращению области аудита PCI DSS являются достаточными. В момент тестирования на проникновение проверяющая сторона использовала специализированный набор инструментов, позволяющий провести полный анализ всех деталей исследуемого объекта. Вот некоторые из них:
- Утилита nmap
С помощью утилиты nmap просканировали белые IP-адреса «ИТ-ГРАД». Сканирование показало, что на всех серверах с публичными IP не обнаружено открытых портов, за исключением портов, необходимых для работы компонентов информационной инфраструктуры «ИТ-ГРАД».
- Доступ по VPN и сканирование внутренней сети
Средствами VPN с использованием механизмов двухфакторной аутентификации осуществлялся доступ к инфраструктуре «ИТ-ГРАД» из внешней недоверенной сети. В ходе тестирования на проникновение было установлено, что без использования двухфакторной аутентификации доступ по VPN невозможен. При подключении по VPN была просканирована внутренняя сеть «ИТ-ГРАД». Сканирование показало, что открытых портов, кроме тех, которые необходимы для работы компонентов информационной инфраструктуры, не обнаружено.
- Попытка доступа в инфраструктуру с помощью учетной записи пользователя
На стороннем ресурсе, расположенном по адресу iaas-blog.it-grad.ru, были получены учетные данные одного из сотрудников «ИТ-ГРАД». Этот пользователь также имел учетную запись в инфраструктуре «ИТ-ГРАД», входящей в область тестирования на проникновение. Полученные учетные данные использовались для попытки авторизации в инфраструктуре компании. Однако успешную авторизацию произвести не удалось, что свидетельствует о достаточности мер сегментации сети, принятых в компании. Помимо озвученных проверок, аудиторы выполняли задачи, прописанные ниже. Но это далеко не полный перечень мероприятий, проводимый в ходе технологического анализа защищенности инфраструктуры.
Задачи тестирования на проникновение:
- Идентификация операционных систем для всех обнаруженных хостов.
- Сканирование уязвимостей по всем диапазонам подсетей в рамках области аудита с использованием VPN.
- Поиск и анализ сервисов и функций, предоставляемых без аутентификации и авторизации.
- Подбор имен пользователей и паролей к обнаруженным сервисам, поддерживающим аутентификацию по паролю.
- Исследование безопасности проприетарных сервисов.
- Идентификация небезопасных сервисов и протоколов.
- Эксплуатация обнаруженных уязвимостей.
- Проверка кодов ошибок.
- Проверка использования слабых алгоритмов.
Распределение уязвимостей по уровням критичности
По окончании пентеста формируется документ, который содержит детализированный отчет и список обнаруженных уязвимостей. От того, насколько критичны уязвимости, зависит итоговый результат теста на проникновение. В случае низкого уровня критичности и наличия незначительных замечаний компании дается время на устранение недочетов. Главное требование – успеть устранить замечания до начала аудита. По результатам теста на проникновение в инфраструктуру «ИТ-ГРАД» были обнаружены семь уязвимостей различного уровня критичности:
Распределение уязвимостей по уровням критичности
Поскольку эксплуатация злоумышленником уязвимостей может привести к компрометации ДДК и ДПК, обрабатываемых в инфраструктуре провайдера, требуется их незамедлительное устранение.
# Уязвимость высокого уровня
Уязвимость 1. Неспособность WAF предотвращать более сложные векторы атак
Важно! Как отмечается в официальном блоге PaloAlto, вопрос, касающийся использования межсетевого экрана PaloAlto в качестве WAF для соответствия требованиям стандарта PCI DSS, является наиболее востребованным. Автор материала, Мэт Кейл, сделал заявление, что PaloAlto Networks не удовлетворяет отдельным требованиям стандарта PCI DCC и, следовательно, не может использоваться для реализации FAW. Более подробно о том, почему PaloAlto не стоит использовать как FAW, читайте в следующей статье.
# Уязвимость среднего уровня
Уязвимость 1. Доступный метод TRACE на администрируемом сервере веб-приложений
Уязвимость 2. На администрируемом сервере веб-приложений не используются HTTP-заголовки безопасности
Уязвимость 3. Наличие уязвимого ПО на хостах
# Уязвимость низкого уровня
Уязвимость 1. Использование небезопасных паролей
Уязвимость 2. Тестовые данные в производственной среде
Уязвимость 3. Наличие ПО, не используемого в компании
Из-за наличия высокого и среднего уровня уязвимостей первый пентест нам пройти не удалось. Исправив все выявленные уязвимости, мы успешно прошли повторное тестирование на проникновение в инфраструктуру.
Предаудит или возможность сдать пробный экзамен
До проведения финального аудита, где нет особых прав на ошибку, компания получает шанс в виде возможности сдать пробный экзамен. Это мероприятие носит название предаудит. В назначенный день – как правило, за 2–3 дня до аудита – в компанию приезжает QSA-специалист и имитирует сценарий настоящей проверки. В большинстве случаев предаудит занимает столько же времени, сколько и сам аудит. Но если в ходе проверки находятся несоответствия, ошибки или неточности, компания имеет право внести изменения. При финальной проверке такой возможности не будет.
Один шаг до финиша, или Как не провалить аудит
Итак, наступило время финального аудита, а это значит, что до финишной прямой осталось совсем немного. Но расслабляться не стоит, впереди вас ждет самое сложное: защитить честь и достоинство компании, продемонстрировать высокую компетенцию, а также соответствие организационных, бизнес- и ИТ-процессов компании установленным требованиям. Вдобавок следует быть готовым ответить на любой вопрос аудитора, потому что аудит без дополнительных вопросов – не аудит.
# Что проверяет аудитор Аудитор обращает внимание на компоненты информационной системы, может задать вопрос по нормативно-распорядительной документации или попросить показать интересующий его документ. Анализирует топологию сети, состав и характеристики аппаратных и программных средств, внутренние и внешние связи информационной системы, выясняет организацию процессов в компании, проверяет записи регламентов и может потребовать пояснений. Например, попросить открыть регламент, касающийся обучения. Согласно установленным требованиям, перед аудитом сотрудники компании проходят внутренние тренинги. Аудитор может проверить программу обучения, открыть презентацию, просмотреть запись обучения, проверить результаты тестов или акты выполненных работ. Не исключены и технические моменты, когда аудитор задает вопросы администраторам или ответственным за компоненты лицам. Выполняются проверки настроек и конфигурации той или иной системы на соответствие требованиям безопасности. В случае с «ИТ-ГРАД» анализировали схему сети, проверяли, как организована изоляция сегментов друг от друга, задавались вопросы по CM-системам, анализировали конфигурацию ОС Linux и Windows. Аудитор делает выборочную проверку компонентов согласно регламенту проведения аудитов. По завершении процесса QSA-аудитор составляет отчеты и передает в соответствующий сертифицирующий орган, который принимает решение о выдаче сертификата.
Устранение несоответствий и решение проблем
Аудитор выявил мелкие несоответствия?
Не беда, регламенты аудита допускают возможность их оперативного исправления. Ниже приведем пример несоответствия, выявленного в «ИТ-ГРАД»:
Пример выявленного несоответствия
В базе активного каталога (Active Directory) аудитор обнаружил учетную запись компьютера (computer account), который когда-то физически удалили из скопа. Объект не числился активным, отсутствовал на схеме, но присутствовал в каталоге. Чтобы соответствовать регламенту, computer account удалили из базы активного каталога.
Потребовалось внести изменения? Да, такое тоже случается. Вот вам пример: в процессе подготовки к аудиту возникла необходимость отслеживать загрузку/выгрузку файлов на sftp-сервере. Как известно, демон proftpd пишет соответствующие сообщения в файл /var/log/xferlog, который агент ossec отправляет на сервер avusm. Однако avusm не сохранял эти сообщения, поскольку отсутствовал декодер, который разбирал бы получаемый лог и генерировал алерты. Потребовалось самостоятельно написать декодер. Поскольку самостоятельное написание декодера – это операционные изменения, каждый шаг выполняемых действий проводился в соответствии с процессами управления изменениями и согласно требованиям стандарта PCI DSS. Вносимые корректировки выполнялись согласно плану, что представляло собой проактивное реагирование организации на проблему. При этом ключевыми этапами процесса управления изменениями стали:
- инициация изменения,
- анализ изменения,
- принятие решения о внедрении изменения,
- планирование внедрения изменения по срокам,
- координация и мониторинг внедрения изменения,
- контроль результатов внедрения изменения.
Запрос на изменение поступил от команды ИТ-отдела, после чего было выполнено уточнение параметров изменений и регистрация запроса в системе ITSM. Поскольку внесение изменений проводилось в рамках аудита PCI DSS и было лимитировано по времени, изменение рассматривалось как срочное. После чего лица, ответственные за принятие решений, провели детальный анализ и окончательно устранили проблему. В результате запрос был отработан и закрыт. Для этого в специальном файле /var/ossec/etc/local_decoder.xml, предназначенном для пользовательских декодеров, добавили блок, в основе которого лежит регулярное выражение:
<decoder name="proftpd_xferlog">
<prematch>^ d+ d+.d+.d+.d+ d+ </prematch>
<regex offset="after_prematch">(w)$</regex>
<order>status</order>
</decoder>
Если сообщение подпадает под регулярное выражение декодера, к нему применяются созданные в аналогичном файле /var/ossec/rules/local_rules.xml правила, генерирующие алерты в зависимости от совершенного действия на sftp-сервере. Таким образом, озвученная проблема была решена. Список правил представлен ниже:
<group name="proftpd_xferlog,">
<rule id="700020" level="0">
<decoded_as>proftpd_xferlog</decoded_as>
<description>xferlog messages grouped.</description>
</rule>
<rule id="700021" level="0">
<if_sid>700020</if_sid>
<status>^c</status>
<description>Transfer complete</description>
</rule>
<rule id="700022" level="1">
<if_sid>700021</if_sid>
<match> i </match>
<description>file was uploaded</description>
</rule>
<rule id="700023" level="1">
<if_sid>700021</if_sid>
<match> o </match>
<description>file was downloaded</description>
</rule>
<rule id="700024" level="1">
<if_sid>700021</if_sid>
<match> d </match>
<description>file was deleted</description>
</rule>
</group>
Заключение
Успешно завершив проведение аудита на соответствие требованиям стандарта, мы запустили сертифицированное по PCI DSS IaaS-облако «ИТ-ГРАД», которое позволяет передать в зону ответственности IaaS-провайдера выполнение максимально полного перечня требований стандарта PCI DSS по обеспечению безопасности обработки карточных данных.
