Ориентирование в PCI DSS 1_1 (1027414), страница 7

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 7)

Без оперативноговнедрения наиболее актуальных обновлений безопасности злоумышленник можетиспользовать эти эксплойты для проведения атак на сеть и нарушения ее работы.Необходимо определить приоритеты применения обновлений таким образом, чтокритичные обновления безопасности устанавливаются на критичные илиподверженные риску системы в течение 30 дней, а обновлениям с меньшим уровнемриска назначается более низкий приоритет.6.2 Должен существовать процесс идентификации вновьобнаруженных уязвимостей безопасности (например, подписка нарассылки, связанные с информационной безопасностью иобнаружением уязвимостей, свободно доступные в сетиИнтернет).Должно выполнятьсяобновление стандартовконфигурирования с целью устранения новых обнаруженныхуязвимостей.Цель данного требования состоит в том, что организации должны своевременноузнавать о новых уязвимостях для того, чтобы они могли защищать свои сети ивнедрять процедуры устранения вновь обнаруженных и имеющих отношение к ихсистемам уязвимостей в свои стандарты конфигурирования.6.3 Разработка программного обеспечения должна производитьсяс учетом накопленного в данной отрасли опыта и учитыватьвопросы обеспечения информационной безопасности на всехстадиях процесса разработки.Если не уделять должного внимания безопасности информации на этапах разработкипрограммного обеспечения (определения требований, проектирования, анализа итестирования), в среду эксплуатации непреднамеренно или сознательно могут бытьвнесены уязвимости в системе безопасности.6.3.1 До внедрения в среду эксплуатации должно выполняться Необходимо удостовериться, что все инсталляции и изменения выполняются так, кактестирование всех обновлений безопасности, а также изменений в планировалось, и не обладают иными недокументированными, ненужными иликонфигурации систем и программного обеспечениявредоносными функциями.6.3.2 Должны быть разделены среды разработки, тестирования Как правило, среда разработки и среда тестирования менее защищены, чем средаи эксплуатацииэксплуатации.

Без надлежащего разделения эксплуатационная среда и данныеплатежных карт могут подвергаться риску вследствие уязвимостей или ненадежныхвнутренних процессов.Copyright 2008 PCI Security Standards Council LLCNavigating PCI DSS. Understanding the Intent of the RequirementsОриентирование в PCI DSS: Понимание требованийПеревод ЗАО НИП «Информзащита»www.infosec.ru+7 (495) 9802345Май 2008Страница 23ТребованиеПояснение6.3.3 Должно существовать разделение обязанностей в средах Это позволит минимизировать количество сотрудников с доступом к эксплуатационнойразработки, тестирования и эксплуатациисреде и данным платежных карт и поможет гарантировать, что доступ предоставляетсятолько тем сотрудникам, кому он в действительности нужен.6.3.4 Для тестирования или разработки не должно В среде разработки обычно осуществляется менее жесткий контроль за обеспечениемиспользоваться данных из среды эксплуатации (реальных безопасности.

Использование в такой среде реальных данных позволитномеров PAN)потенциальным злоумышленникам, равно как и разработчикам, получитьнеавторизованный доступ к информации, используемой в эксплуатационной среде.6.3.5 Должно выполняться удаление тестовых учетных записей Тестовые данные и учетные записи должны удаляться из кода перед активациейи данных до внедрения в среду эксплуатацииприложения, поскольку они могут предоставить информацию о функционированииприложения. Обладание такой информацией может облегчить компрометациюприложения и связанных с ним данных платежных карт.6.3.6 Учетные записи, имена пользователей и пароли вразработанном программном обеспечении должны быть удаленыдо внедрения этого программного обеспечения в средуэксплуатации или его передачи заказчикуУчетные записи заказных приложений, имена пользователей и пароли должныудаляться из кода перед активацией приложения или его передачей клиентам,поскольку они могут предоставить информацию о функционировании приложения.Обладание такой информацией может облегчить компрометацию приложения исвязанных с ним данных платежных карт.6.3.7 Для идентификации потенциальных уязвимостей вразработанном программном обеспечении должен выполнятьсяанализ кода перед запуском этого ПО в эксплуатацию или егопередачей заказчикуУязвимости безопасности кода заказных приложений обычно эксплуатируютсязлоумышленниками для получения доступа к сети и компрометации данных платежныхкарт.

Поэтому для идентификации уязвимостей анализ кода должны выполнять лица,владеющие приемами безопасного программирования.6.4 При внесении любых изменений в системы и программное Без надлежащего контроля изменений программного обеспечения возможности защитыобеспечение необходимо следовать процедурам управления могут быть непреднамеренно или сознательно упущены или отключены, возможноизменениями. Эти процедуры должны включать:появление ошибок обработки или внедрение вредоносного кода. Если используютсянедостаточно основательные политики проверки биографии принимаемых на работусотрудников и контроля доступа к системе, то существует риск того, чтонеблагонадежные и недостаточно подготовленные сотрудники смогут получитьнеограниченный доступ к программному коду, а уволившиеся сотрудники будут иметьвозможность компрометации систем, при этом определить неавторизованные действиябудет невозможно.6.4.1 Документирование влияния, оказываемого изменениемНеобходимо документировать влияние, которое может быть нанесено изменением,чтобы все вовлеченные стороны могли надлежащим образом запланировать всеизменения в обработке данных.6.4.2 Утверждение руководствомУтверждение руководством указывает на то, что изменение является легитимным,авторизованным и санкционированным организацией.6.4.3 Тестирование работоспособностиТщательное тестирование должно выполняться для проверки того, что любаяCopyright 2008 PCI Security Standards Council LLCNavigating PCI DSS.

Understanding the Intent of the RequirementsОриентирование в PCI DSS: Понимание требованийПеревод ЗАО НИП «Информзащита»www.infosec.ru+7 (495) 9802345Май 2008Страница 24ТребованиеПояснениеактивность ожидаема, данные в отчетах точны и выполняется корректная обработкавсех ошибочных состояний и т. п.6.4.4 Процедуры отката6.5 Все web-приложения должны разрабатываться с учетомрекомендацийпопрограммированиюзащищенныхwebприложений, например, рекомендаций OWASP.

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

Без надлежащей защиты данные платежных карт идругая конфиденциальная информация компании могут быть раскрыты, что приведет кнанесению ущерба компании, ее клиентам и ее репутации.Необходимо выполнять проверку данных, получаемых от web-запросов, перед ихпередачей web-приложению – например, выполнять проверки на то, что введенытолько буквы, буквы и цифры и т. д. Без выполнения подобных проверокзлоумышленник сможет передать приложению неверные данные и атаковатькомпоненты внутренней сети с использованием этого приложения.6.5.2 Уязвимости механизмов контроля доступа (например, Злоумышленники часто пытаются просканировать и перечислить существующие взлоумышленное использование идентификаторов пользователей) приложениях пользовательские учетные записи для того, чтобы найти точку входа дляпроведения атаки.

Как только существующая учетная запись будет обнаружена,злоумышленник может попытаться использовать пароли, заданные по умолчанию, иливыполнить подбор паролей методом перебора для получения доступа к приложению.6.5.3 Уязвимости подсистемы аутентификации и управления Учетные данные и "маркеры" сеанса должны быть надежно защищены. Атаки,сеансами (использование учетных данных и сеансовых cookie)направленные на пароли, ключи, сеансовые файлы “cookie” или другие маркеры, могутпомочь злоумышленнику обойти требования аутентификации и попробовать угадатьидентификаторы других пользователей.

Кроме того, файлы “cookie” могут содержатьинформацию платежных карт и по умолчанию сохраняться в открытом виде.6.5.4 Атаки типа Cross-Site Scripting (XSS)При атаке данного типа web-приложение используется для отправки атаки браузеруконечного пользователя, что может привести к раскрытию маркера сеанса конечногопользователя, атаке на его компьютер, а также отправке подмененного содержимогодля обмана пользователя.6.5.5 Переполнение буфераЗлоумышленник может повредить компоненты web-приложения, которые необрабатывают должным образом данные, введенные пользователем (см.

Характеристики

Список файлов учебной работы