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

Цитата из заявления сообщества OWASP1 («Открытый проект информационной безопасности веб-приложений»):

«Незащищенное программное обеспечение уже подрывает изнутри нашу финансовую систему, энергетику, здравоохранение, оборону и другие важнейшие инфраструктуры. С усложнением и повышением взаимосвязи цифровых систем трудность обеспечения информационной безопасности растет экспоненциально. Мы больше не можем позволить себе закрывать глаза на такие сравнительно простые проблемы безопасности, как те, что перечислены в Топе-10 OWASP». (Курсив наш).

Разработчики веб-приложений и приложений ЭТ должны руководствоваться такими авторитетными источниками рекомендаций по управлению уязвимостями, как Топ-10 OWASP, SANS2 CWE Топ-25 и CERT3 Secure Coding. Приобретая приложения ЭТ, ТСП должны убедиться, что приложения прошли проверку на соответствие стандарту PA-DSS. Если ТСП разрабатывает собственные решения для ЭТ, то оно должно рассматривать стандарт PA-DSS как рекомендательный, а привлекаемые им разработчики должны понимать (и применять) принципы безопасного кодирования и программирования приложений.

1        www. owasp. org

2        www. sans. org

НЕ нашли? Не то? Что вы ищете?

3        www. cert. gov

4.1        Уязвимости, вызванные небезопасными приемами программирования

Некоторые из распространенных уязвимостей в веб-приложениях (таких, как «корзины покупок») можно разделить на следующие категории.

4.1.1        Инъекции кода

Помимо инъекций SQL-кода, сюда относятся инъекции команд ОС и LDAP. Уязвимости такого рода возникают, когда приложение  не проверяет должным образом данные, вводимые на веб-сайте (например, в формы или поля). В результате в исполняемые команды могут быть переданы потенциально опасные данные, приводящие к несанкционированному доступу.

Одним из важнейших элементов при выборе поставщиков услуг для ЭТ являются описание мер и методов обеспечения безопасности, предпринимаемых ими для защиты веб-сайтов от уязвимостей типа «SQL-инъекции».

4.1.2        Межсайтовый скриптинг (XSS)

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

4.1.3        Подделка межсайтовых запросов (CSRF)

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

4.1.4        Переполнение буфера

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

4.1.5        Слабозащищенные учетные данные для аутентификации и (или) сеансов связи

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

4.2        Неправильная конфигурация безопасности

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

Обеспечить безопасность настроек DMZ таким образом, чтобы доступ извне был возможен только к компонентам, выполняющим санкционированные, общедоступные сервисы; запретить несанкционированный исходящий трафик (требования 1.3.1 и 1.3.4). Обеспечить безопасность системных настроек, сменить пароли и настройки по умолчанию (требование 2) При передаче данных по сети Интернет использовать безопасные механизмы шифрования (требование 4) Защитить компоненты ЭТ от известного вредоносного ПО (требование 5) Своевременно устанавливать выпускаемые производителями обновления безопасности для программных и сетевых компонентов (требование 6.1) При разработке веб-сайтов придерживаться принципов безопасного программирования и разработки программ (требования 6.3—6.5) Реализовать процесс управления новыми уязвимостями ИБ (требования 6.1, 6.2, 6.6 и 11.2) Предоставлять доступ только пользователям со служебной необходимостью; для такого доступа использовать надежные аутентификационные данные (требования 7 и 8) Вести наблюдение и журналы событий (требования 10 и 11)

5        Рекомендации

В дополнение к требованиям PCI DSS, ТСП ЭТ рекомендуется полностью или частично придерживаться описанных ниже рекомендаций.

5.1        Знать местонахождение всех своих ДДК

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

Правильно составленная схема потоков данных позволит:

Определить, какие системы участвуют в хранении, обработке и передаче ДДК Определить, какие системы подключены к системам, хранящим, обрабатывающим и передающим ДДК Наглядно показать, как выполняется обработка ДДК (например, что происходит с ДДК в функциях веб-приложения и на веб-страницах) и как данные передаются по сети или между сетями. Показать участки, где реализованы те или иные меры безопасности Четко разделить зоны, где за обработку платежей отвечает ТСП (используя ПО собственной разработки или приобретенного у сторонней организации и встроенного в «корзину покупок»), и зоны, где платежи обрабатываются исключительно в средах сторонних организаций.

5.2        Не хранить без надобности

Избавляясь от всех ненужных ДДК (согласно требованию 3.1 PCI DSS), сосредоточив нужные в известных и хорошо контролируемых местах, а также изолируя все ДДК от сред с другими данными, можно свести к минимуму количество защищаемых мест хранения и объем защищаемых ДДК, равно как и количество точек подключения к среде ДДК, подлежащих защите.

5.3        Провести оценку рисков, связанных с выбранной технологией ЭТ

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

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

5.4        Реализовать управление рисками подрядных отношений со сторонними поставщиками услуг

Безопасность имеет первостепенное значение для интернет-магазина, «корзины покупок», любого другого сервиса ЭТ. Вниманию ТСП, передающих компоненты ЭТ на подрядную основу со сторонними организациями, предлагаются следующие рекомендации.

При выборе услуг потенциальных сторонних поставщиков ТСП рекомендуется поступать следующим образом:

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

С привлекаемым поставщиком услуг ТСП следует заключить договор или письменное соглашение, в которых:

определены границы ответственности обеих сторон за соблюдение требований PCI DSS (в соответствии с требованием 12.8 PCI DSS); отражен порядок выполнения требований PCI DSS; указано,  будет ли поставщик услуг проходить аудит PCI DSS самостоятельно или же он будет передавать предоставляемые им услуги на проверку в рамках ежегодного аудита PCI DSS ТСП.

Контролируя работу сторонних поставщиков услуг, ТСП следует учитывать следующее:

Пользуясь услугами веб-хостинга на подрядной основе, следует запросить у поставщика услуг:
— стандартные параметры конфигурации оборудования и программного обеспечения;
— график обновления оборудования, а также установки обновлений безопасности и новых версий программ;
— круглосуточную, всегда доступную службу наблюдения за состоянием системы;
— содействие в расследовании нарушений системы безопасности. При использовании услуг хранения данных на подрядной основе, следует проверить, может ли поставщик услуг самостоятельно управлять созданием шифрованных резервных копий и администрировать базы данных. Эти функции, а также соответствующие процедуры PCI DSS, следует, по необходимости, оговорить в соглашении или договоре. Если процессы и инфраструктура сети поставщика услуг еще не проходили проверку на соответствие стандарту PCI DSS,  решение обнаруженных проблем безопасности может оказаться для данного поставщика слишком трудным или затратным. При использовании физической или сетевой инфраструктуры на подрядной основе, до подписания договора или соглашения следует согласовать вопрос о том, какая из сторон возьмет на себя расходы по устранению данных проблем безопасности. Следует ознакомиться с подписанными Свидетельствами о соответствии (Attestation of Compliance) поставщиков услуг, чтобы удостовериться в актуальности их соответствия стандарту PCI DSS (подобно ТСП, поставщики услуг обязаны подтверждать соответствие PCI DSS ежегодно) и во включении в область оценки услуг, предоставляемых ТСП. Следует убедиться в том, что проверку на соответствие PCI DSS поставщик проходил именно в качестве поставщика услуг (а не ТСП). Если ТСП пользуется услугами хостинга с общей средой (т. е. если на одном общем сервере размещены веб-сайты нескольких ТСП), следует учитывать, что для таких поставщиков, помимо всех прочих применимых требований стандарта PCI DSS, существуют особые требования, описанные в «Приложении А: Дополнительные требования PCI DSS для поставщиков услуг хостинга с общей средой». Следует убедиться, что свидетельство о соответствии стандарту PCI DSS поставщика услуг хостинга с общей средой включает в себя все применимые требования.

5.5        ASV-сканирование веб-среды

Из за большого объема этот материал размещен на нескольких страницах:
1 2 3 4 5 6