На волне ажиотажа с атакой Heartbleed стоит еще раз поднять тему безопасности Web-приложений.
Одним из самых популярных, интересных и доступных материалов на эту тему является ежегодных отчет проекта по безопасности Web-приложений OWASP - OWASP TOP-10 2013
О нем и пойдет речь в обзоре.
Документ является классикой для специалистов по Web-безопасности, но рассказать о нем лишним никогда не будет :)
В документе использован интересный подход к классификации бед, связанных с Web-технологиями: рассматриваются не уязвимости, не атаки, а именно риски ИБ, которые определяются как совокупность:
1. Атакующего
2. Вектора атаки
3. Уязвимости (у которой есть характеристики распространенности и простоты обнаружения)
4. Мер защиты
5. Влияния реализованной атаки на технику
6. Влияния реализованной атаки на бизнес
И каждый риск описан в таком ключе.
Каждому риску посвящена всего 1 страничка, на которой кратко доступным языком даются его характеристики, то, как определить, подвержены ли вы этому риску, пример атаки, то, как от этого риска защититься и ссылки на другие материалы (среди других материалов стоит отметить отдельно знаменитый стандарт по оценке Web-безопасности того же самого проекта OWASP ASVS)
Итак, рейтинг ключевых рисков Web-приложений согласно OWASP:
1. Инъекции (SQL, LDAP, Xpath, NoSQL и т.д) - Injection
2. Угон сессий из-за уязвимостей в аутентификации и управлении сессиями - Hijacking (Broken Authentication and Session Management)
3. Межсайтовый скриптинг - XSS
4. Небезопасные прямые ссылки на внутренние объекты - Insecure Direct Object References
5. Ошибки конфигураций безопасности - Security Misconfiguration
6. Слабая криптография (и защита важной информации в целом) - Sensitive Data Exposure
7. Отсутсвие контроля доступа к функционалу
8. Подделка межсайтовых запросов - CSRF
9. Использование компонентов с известными уязвимостями - Using Components with Known Vulnerabilities
10. Непроверяемые переадресации между сайтами и внутри одного сайта - Unvalidated Redirects and Forwards
Стоит также отметить, что проверить приложение на предмет рисков из OWASP Top 10 требуется согласно стандартам PCI DSS 3.0 и PA DSS 3.0
Подошел к концу седьмой межотраслевой форум директоров по информационной безопасности (VII CISO Forum)
Расскажу о впечатлениях.
Мероприятие прошло на достаточно высоком уровне. Выступлений в стиле "покупайте наших слонов" практически не было. Даже если вендор и пытался продать свой продукт, делал он это с умом и интересно :)
Среди выступающих хотел бы отметить:
Константина Коротнева (Эльдорадо) с докладом о стратегическом управлении ИБ
Андрея Конусова (Avantpost) с его зажигательным докладом про собственный IDM
Алексея Волкова (Северсталь-Инфоком) с докладом про внедрение электронных подписей на Северстали
Андрея Дроздова (ISACA) с его анализом стандартов по ISMS и связкой их с COBIT
Андрея Ерина (CARCADE-лизинг) с его трогательной историей про внедрение ИБ в
корпоративную культуру при помощи шоколадок :)
Евгения Царева (Swivel) с его ненавязчивой рекламой своего продукта под видом анализа развития средств аутентификации
Никиту Кислицина (Group-IB) с анализом мобильных ботнетов
и, конечно, Евгения Климова (KPMG) c докладом про форензику
Прошу не обижаться докладчиков, которых я не упомянул, мероприятие было слишком интенсивное, все в голове перемешалось.
Я сам выступил с докладом "Современные методы противодействия инсайду" и рассказал о том, как проанализировать поведение инсайдеров при помощи системной динамики и выбрать стратегию противодействия.
Стоит отметить хорошую атмосферу форума, располагающую к общению, что, безусловно, является главным в мероприятии подобного уровня.
В ноябре 2013 г. вышла версия 3.0 стандарта безопасности данных платежных приложений индустрии платежных карт (PA-DSS).
Данные требования применяются к поставщикам платежных приложений.
Семейство стандартов и требований PCI (индустрии платежных карт) состоит из трех документов:
1. PCI PIN Transaction Security (PTS) Point of Interaction (POI) v. 4.0
- требования к POI-устройству по безопасности транзакций с использованием PIN-кода (требования к аппаратным терминалам)
2. PA-DSS v. 3.0 - требования к приложениям, обрабатывающим платежную информацию.
3. PCI DSS v. 3.0 - требования к среде, обрабатывающей информацию платежных карт.
Обзор стандарта PCI DSS v. 3.0
Стандарт PA-DSS применяется для платежных приложений, которые распространяются на рынке. То есть в случае, если приложение разрабатывается для использования в личных целях или для использования одним заказчиком, то можно добиваться соответствия сразу PCI DSS.
Сертификат PA-DSS гарантирует то, что приложение, установленное правильным образом в среду, удовлетворяющую требованиям PCI DSS не нарушит безопасность этой среды. Это гарантия того, что среда сохранит соответствие PCI DSS.
Именно поэтому вместе с самим сертифицированным приложением в комплект поставки должен входить документ "Руководство по внедрению стандарта PA-DSS", который говорит о том, как правильным образом устанавливать и эксплуатировать приложение.
Причем не обязательно выполнять все требования стандарта PA-DSS. Если приложение планируется использовать на конкретном POI-устройстве, прошедшем сертификацию по PCI PTS, то требования можно закрыть с использованием функционала POI.
Тогда в перечне приложений, сертифицированных по PA-DSS, наше приложение будет идти с пометкой, что его необходимо использовать только в связке с конкретным POI-устройством.
Аудит приложения производится сертифицированным аудитором платежных приложений (PA-QSA) в лаборатории, требования к которой приведены в приложении В к стандарту.
Причем по возможности PA-QSA должен использовать свою лабораторию.
Если в лаборатории PA-QSA отсутствует необходимое железо, то необходимо запросить железо у разработчика ПО либо, если это сделать невозможно, проводить аудит в лаборатории разработчика.
По результатам аудита оформляется отчет о проверке PA-DSS (называемый ROV) и направляется в PCI SSC.
PA-DSS состоит из 14 требований:
1. Не хранить полные данные магнитной дорожки, код или значение проверки подлинности карты (CAV2, CID, CVC2, CVV2), или данные PIN-блока
2. Обеспечить безопасное хранение данных держателей карт
3. Предоставление функций безопасной аутентификации
4. Следует вести журнал активности платежного приложения
5. Необходимо разработать безопасные платежные приложений
6. Защита беспроводной передачи данных
7. Необходимо тестировать платежные приложения с целью устранения уязвимостей и регулярного обновления приложений
8. Необходимо обеспечить возможность внедрения в безопасные сетевые среды
9. Данные держателей карт ни в коем случае не должны храниться на сервере, подключенном к Интернету
10. Необходимо обеспечить безопасный удаленный доступ к платежному приложению
11. Необходимо шифровать конфиденциальный трафик в общедоступных сетях
12. Необходимо шифровать неконсольный административный доступ
13. Необходимо составить Руководство по внедрению стандарта PA-DSS для клиентов, реселлеров и интеграторов
14. Необходимо назначить сотрудникам обязанности по стандарту PA-DSS и обеспечить программы обучения сотрудников, реселлеров и интеграторов.
Требования стандарта PA-DSS во многом пересекаются с требованиями его большого брата PCI DSS.
Из нового можно отметить требования к управлению версиями (5.4) и требование к разработке сопроводительного документа "Руководство по внедрению стандарта PA-DSS". О необходимости составления такого документа говорится практически в каждом требовании, также ему посвящено требование 13, кроме того существует Приложение А, которое еще раз говорит о том, что должно быть в документе.
Любопытно то, что согласно PA-DSS ответственность за обучение и предоставление информации реселлерам и интеграторам, которые будут внедрять ПО, ложится на разработчика ПО (требование 14).
Стандарт, безусловно, будет полезен разработчикам платежных приложений, даже если они не собираются сертифицировать свои продукты. Он детален, охватывает все аспекты безопасности приложений и хорошо структурирует подход к разработке и внедрению безопасного ПО.
Представляю вашему вниманию краткий обзор стандарта безопасности данных индустрии платежных карт PCI DSS 3.0 (Payment Card Industry Data Security Standard).
В начале необходимо рассказать, какие именно данные призван защищать данный стандарт.
Данные платежный карт (Account Data), согласно PCI DSS, делятся на данные держателя карты и критичные аутентификационные данные.
К данным держателя карты относятся:
1. Основной номер держателя карты (Primary Account Number, PAN) - 16 цифр, эмбоссированных или выгравированных на лицевой стороны пластиковой карты.
PAN идентифицирует платежную систему банк-эмитент (банк, который выпустил данную пластиковую карту) и держателя (владельца) карты.
2. Имя держателя карты. Указывается, как правило, в нижней части лицевой стороны пластиковой карты.
3. Данные истечения срока действия карты. Указывается непосредственно под основным номером держателя карты.
4. Сервисный код. Информация о возможностях карты (является ли она международной, встроены ли дополнительные технологии, такие как чип, а также для каких операций предназначена карта и для каких операций запрашивать PIN-код).
Данная информация находится на магнитной полосе и в чипе (при его наличии).
К критичным аутентификационным данным относятся:
1. Полные данные дорожки магнитной полосы или ее эквивалент на чипе.
2. CAV2/CVC2/CVV2/CID.
CVC2 - трехзначный код подтверждения подлинности карты Visa, расположенный под магнитной полосой с оборотной стороны пластиковой карты и используемый для проведения операций "Card not present" (покупка через интернет/телефон).
CVV2 - аналогичный код для MasterCard.
CAV2 - аналогичный код для японской платежной системы JCB Cards.
CID - аналогичный код для платежных систем American Express и Discover.
3. PIN/PIN-блоки. PIN - код (как правило, 4 цифры), аутентифицирующий владельца карты. PIN-блок - то, во что он преобразуется после ввода на пин-паде (зашифрованное значение).
Эту информацию и призван защищать стандарт PCI DSS.
Теперь расскажу более подробно о самом стандарте.
PCI DSS разработан организацией PCI SSC (Security Standards Council), учрежденной платежными системами Visa, MasterCard, JCB Cards, American Express и Discover.
Стандарт является обязательным для организаций, обрабатывающих данные платежных карт этих платежных систем.
Все организации делятся на торгово-сервисные предприятия (ТСП, merchants) и поставщиков услуг (service providers). К торгово-сервисным предприятиям относятся те организации, которые принимают оплату своих товаров или услуг посредством платежных карт (магазины, кафе, автозаправки и т.д.). К поставщикам услуг относятся организации, которые обеспечивают процесс осуществления платежа (банки-эмитенты, банки-эквайреры, процессинговые центры, сами платежные системы, хостинг-провайдеры и т.д.).
Для сертификации на соответствие PCI DSS существует три вида проверок:
1. Самое простое - самооценка с заполнением листа самооценки (Self-Assesment Questionnaire - SAQ). Причем бывает 4 вида листов самооценки (в зависимости от числа проверок)
2. ASV-сканирование - сканирование проверенными вендорами (Approved Scanning Vendors). Список компаний ASV
3. QSA-аудит - полноценный аудит на соответствие PCI DSS, проведенный организацией со статусом Qualified Security Assessor. Список компаний QSA
В зависимости от того, является организация ТСП или поставщиком услуг, а также от числа обрабатываемых транзакций, необходимо проходить те или иные проверки.
В самом стандарте 12 требований, разбитых по 6 доменам безопасности:
домен "Построение и обслуживание защищенной сети и систем"
1. Установить и обеспечить функционирование межсетевых экранов для защиты данных держателей карт.
2. Не использовать пароли и другие системные параметры, заданные производителем по умолчанию.
домен "Защита данных держателей карт"
3. Обеспечить безопасное хранение данных держателей карт.
4. Обеспечить шифрование данных держателей карт при их передаче через сети общего пользования.
домен "Программа управления уязвимостями"
5. Использовать и регулярно обновлять антивирусное программное обеспечение.
6. Разрабатывать и поддерживать безопасные системы и приложения.
домен "Внедрение строгих мер контроля доступа"
7. Ограничить доступ к данным держателей карт в соответствии со служебной необходимостью.
8. Определять и подтверждать доступ к системным компонентам.
9. Ограничить физический доступ к данным держателей карт.
домен "Регулярный мониторинг и тестирование сети"
10. Контролировать и отслеживать любой доступ к сетевым ресурсам и данным держателей карт.
11. Регулярно выполнять тестирование систем и процессов обеспечения безопасности.
домен "Поддержание политики информационной безопасности"
12. Разработать и поддерживать политику информационной безопасности для всего персонала организации.
Требования разбиты на подпункты. К каждому подпункту дан комментарий и перечень действий, которые должен предпринимать аудитор.
Для хостинг-провайдеров выдвигаются дополнительные требования.
Если организация не может выполнить какое-либо требование по объективным ограничениям, то после проведения оценки рисков она может внедрить компенсационные меры, с помощью которых достигнут цели изначального требования другим способом.
Необходимо отметить, что стандарт очень полно покрывает все аспекты обеспечения информационной безопасности. Требования детальны, понятны. Возможно, даже чересчур детальны и понятны :)
Вместо того, чтобы давать более гибкий и системный подход к обеспечению информационной безопасности, как это делают его коллеги ISO 27001 или ISM3, PCI DSS выставляет жесткие четкие требования, и их надо выполнить. Возможно, в сфере платежей с использованием пластиковых карт это оправдано.
Также необходимо отметить, что существует родственный стандарт PA DSS (Payment Application Data Security Standard), посвященный безопасности платежных приложений.
