Как «ИТ-ГРАД» сертифицировал IaaS-облако по стандарту PCI DSS. Часть 2

Как «ИТ-ГРАД» сертифицировал IaaS-облако по стандарту PCI DSS

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

Тестирование на проникновение в облачную инфраструктуру

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

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

Целью тестирования на проникновение является проверка работоспособности и эффективности средств сегментации и сокращения области аудита PCI DSS, выявление вектора атак и уязвимостей, реально или потенциально влияющих на конфиденциальность данных держателей карт (ДДК).

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

До начала пентеста в «ИТ-ГРАД» подготовили два скопа:

  • в первом разместили служебные сервисы, тестовые приложения, организовали доступ извне;
  • во втором развернули ВМ с предустановленной ОС, назначили необходимые права соответствующим учетным записям.

Пример скопа с размещенными сервисами и приложениями

Пример скопа с размещенными сервисами и приложениями

На что обратить внимание до начала пентеста

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

Дмитрий Козлов«Что использовать для защиты веб-приложений решать вам. Главное – добиться высокого уровня безопасности. «ИТ-ГРАД» выбирал между Citrix и ModSecurity, остановившись на последнем. Мы не делали ставки на коммерческое или некоммерческое решение, платное или бесплатное. Искали средство, способное защитить от известных на момент выбора атак. Установив ModSecurity, мы получили продукт с хорошим сообществом и защитой от уязвимостей».

Дмитрий Козлов,
старший системный администратор «ИТ-ГРАД»

Как проходил пентест в «ИТ-ГРАД»

Прежде всего «ИТ-ГРАД» согласовал с проверяющей стороной сроки начала пентеста и предоставил необходимый набор документов с подробным описанием инфраструктуры:

  • Общее описание сертифицируемого бизнес-процесса и информационной инфраструктуры.
  • Схема сети.
  • Перечень компонентов информационной инфраструктуры.
  • Перечень белых IP-адресов с описанием назначения каждого.
  • Перечень средств сегментации и сокращения области аудита PCI DSS.
  • Имеющиеся инструкции ко всем приложениям и API.
  • Перечень и описание ролей пользователей, существующих в каждом приложении, и многое другое.

После чего в установленное время команда аудиторов в области информационной безопасности начала тестирование на проникновение в информационную систему «ИТ-ГРАД». Помимо технических проверок проводилось тестирование возможности проникновения в информационную систему с использованием метода социальной инженерии. В ходе пентеста аудиторы выполнили проверку средств сегментации и сокращения области аудита PCI DSS. Полученные результаты свидетельствовали о том, что принятые в «ИТ-ГРАД» меры по сегментации и сокращению области аудита PCI DSS являются достаточными.

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

  • Утилита nmap

С помощью утилиты nmap просканировали белые IP-адреса «ИТ-ГРАД». Сканирование показало, что на всех серверах с публичными IP не обнаружено открытых портов, за исключением портов, необходимых для работы компонентов информационной инфраструктуры «ИТ-ГРАД».

  • Доступ по VPN и сканирование внутренней сети

Средствами VPN с использованием механизмов двухфакторной аутентификации осуществлялся доступ к инфраструктуре «ИТ-ГРАД» из внешней недоверенной сети. В ходе тестирования на проникновение было установлено, что без использования двухфакторной аутентификации доступ по VPN невозможен. При подключении по VPN была просканирована внутренняя сеть «ИТ-ГРАД». Сканирование показало, что открытых портов, кроме тех, которые необходимы для работы компонентов информационной инфраструктуры, не обнаружено.

  • Попытка доступа в инфраструктуру с помощью учетной записи пользователя

На стороннем ресурсе, расположенном по адресу iaas-blog.it-grad.ru, были получены учетные данные одного из сотрудников «ИТ-ГРАД». Этот пользователь также имел учетную запись в инфраструктуре «ИТ-ГРАД», входящей в область тестирования на проникновение. Полученные учетные данные использовались для попытки авторизации в инфраструктуре компании. Однако успешную авторизацию произвести не удалось, что свидетельствует о достаточности мер сегментации сети, принятых в компании.

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

Задачи тестирования на проникновение:

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

Распределение уязвимостей по уровням критичности

По окончании пентеста формируется документ, который содержит детализированный отчет и список обнаруженных уязвимостей. От того, насколько критичны уязвимости, зависит итоговый результат теста на проникновение. В случае низкого уровня критичности и наличия незначительных замечаний компании дается время на устранение недочетов. Главное требование – успеть устранить замечания до начала аудита.

По результатам теста на проникновение в инфраструктуру «ИТ-ГРАД» были обнаружены семь уязвимостей различного уровня критичности:

Распределение уязвимостей по уровням критичности

Распределение уязвимостей по уровням критичности

  • высокий уровень – 1 уязвимость,
  • средний уровень – 3 уязвимости,
  • низкий уровень – 3 уязвимости.

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

# Уязвимость высокого уровня

Уязвимость 1. Неспособность WAF предотвращать более сложные векторы атак

Уязвимости в виде некорректной работы Web Application Firewall (WAF) был присвоен высокий уровень критичности. В процессе тестирования было выявлено, что выбранное «ИТ-ГРАД» средство WAF в виде межсетевого экрана Palo Alto предотвращает только стандартные векторы атак, тогда как более сложные остаются без внимания. Поскольку это обстоятельство может способствовать осуществлению успешной атаки на веб-приложения клиента и повлечь компрометацию ДДК или ДПК пользователей веб-приложения, «ИТ-ГРАД» выполнил меры по устранению озвученной уязвимости.

Как устранили: развернули альтернативное решение WAF в виде веб-сервера Apache с модулем Modsecurity, способным фильтровать все данные ввода и вывода на присутствие в них управляющих символов языков HTML и JavaScript, обновили и привели к актуальному состоянию базу данных сигнатур WAF.

Важно! Как отмечается в официальном блоге PaloAlto, вопрос, касающийся использования межсетевого экрана PaloAlto в качестве WAF для соответствия требованиям стандарта PCI DSS, является наиболее востребованным. Автор материала, Мэт Кейл, сделал заявление, что PaloAlto Networks не удовлетворяет отдельным требованиям стандарта PCI DCC и, следовательно, не может использоваться для реализации FAW. Более подробно о том, почему PaloAlto не стоит использовать как FAW, читайте в следующей статье.

# Уязвимость среднего уровня

Уязвимость 1. Доступный метод TRACE на администрируемом сервере веб-приложений

На предоставленном «ИТ-ГРАД» сервере с размещенным для тестирования на проникновение веб-приложением не был отключен метод TRACE. Как известно, этот метод используется для получения ответного сообщения на запрос на уровне приложения. При этом ответное сообщение содержит тело запроса (включая HTTP-заголовки) с кодом ответа 200 (ОК). Браузеры не поддерживают метод TRACE, но с помощью различных расширений можно осуществить отправку этого запроса на сервер веб-приложения и в результате произвести атаку на пользователя, например атаку типа XSS. Поскольку в настоящее время такая атака блокируется почти всеми веб-браузерами, был присвоен средний уровень критичности.

Как устранили: отключили метод TRACE при настройке веб-сервера.

Уязвимость 2. На администрируемом сервере веб-приложений не используются HTTP-заголовки безопасности

На администрируемом сервере не использовались или применялись с небезопасными значениями HTTP-заголовки безопасности, такие как: x-xss-protection – заголовок, обеспечивающий защиту от XSS-атак; x-content-type-options – заголовок безопасности, способствующий значительному снижению рисков безопасности типов MIME в Internet Explorer и Google Chrome; HTTP-strict-transport-security – заголовок, используемый механизмом, активирующим форсированное защищенное соединение через протокол HTTPS и блокирующим пользовательский доступ к сайту в случае изменения сертификата сервера; cache-control – заголовок, предназначенный для управления кэшем. Использование заголовков безопасности способствует предотвращению многих векторов атак, направленных на пользовательский интерфейс.

Как устранили: включили заголовки безопасности.

Уязвимость 3. Наличие уязвимого ПО на хостах

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

Как устранили: выполнили настройку регулярного обновления ПО на всех узлах компании.

# Уязвимость низкого уровня

Уязвимость 1. Использование небезопасных паролей

В ходе пентеста было выявлено использование небезопасных паролей. Например, использовался пароль 2wsxMKI* для доступа к БД. Такой пароль был признан небезопасным, потому что состоит из символов, расположенных рядом на клавиатуре. Для тестирования на проникновение был разработан генератор подобных паролей, но подобрать пароли какого-либо пользователя с помощью генератора не удалось.

Как устранили: выявленные небезопасные пароли изменили на пароли, соответствующие требованиям политики безопасности.

Уязвимость 2. Тестовые данные в производственной среде

В ходе тестирования на проникновение были найдены тестовые данные в производственной среде, такие как файлы логов ssh-клиента PuTTY, в которых были обнаружены хэши паролей пользователей нескольких сетевых устройств.

Как устранили: провели инвентаризацию файлов на хостах и удалили все неиспользуемые данные.

Уязвимость 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-облако «ИТ-ГРАД»

Успешно завершив проведение аудита на соответствие требованиям стандарта, мы запустили сертифицированное по PCI DSS IaaS-облако «ИТ-ГРАД», которое позволяет передать в зону ответственности IaaS-провайдера выполнение максимально полного перечня требований стандарта PCI DSS по обеспечению безопасности обработки карточных данных.

Поделиться в социальных сетях

1 Звезда2 Звезды3 Звезды4 Звезды5 Звезд (1 оценок, среднее: 5,00 из 5)
Загрузка...