Введение
Одна из самых важных проблем эффективного функционирования банка является проблема его безопасности. Защита банковской информации стала намного более актуальной, став на первое место относительно физической охраны и методов технической защиты помещения банков. Необходимо обеспечить:
- целостности;
- конфиденциальности информации;
- доступность информации для авторизованных пользователей.
Для создания эффективной системы информационной безопасности требуется соблюдать определенные стандарты информационной безопасности. Богатый международный опыт показывает, что разрозненные усилия банков по защите информации оказываются малоэффективными перед лицом преступных группировок и лиц, активно использующих объединенный опыт технического компьютерного прогресса и достижений электроники. В связи с этим были созданы различные стандарты регламентирующие создание систем информационной безопасности. В данном случае будет исследован один из основных международных банковских стандартов PCI DSS. Данный стандарт регламентирует создание информационной системы безопасности. Следуя данному стандарту можно создать комплексную систему информационной безопасности устойчивую к большинству распространенных информационных атак, угроз и уязвимостей. В данной статье будет проведен сравнительный анализ соответствия решений Oracle по обеспечению информационной безопасности требованиям банковского стандарта PCI DSS.
Решения Oracle будут рассматриваться в этой статье, так как эти они зарекомендовали себя с самой лучшей стороны тысячами компаний в течении десятилетий. Данные решения показали себя как крайне устойчивые и защищенные от разного рода внешних и внутренних угроз.
Использование банковского стандарта PCIDSS
Стандарт безопасности данных разработанный советом PCI SSC PCI DSS, объединяющий в себе различные требования международных платежных систем по обеспечению информационной безопасности. В совет PCI SSC входят такие брэнды, как Visa, MasterCard, American Express, JCB и Discovery.
Банковский стандарт PCI DSS состоит из двенадцати тематических разделов описывающих требования к защите информации о держателях карт. Главный акцент банковского стандарта PCI DSS делается на создание и обеспечении безопасности сетевой инфраструктуры, а также на защиту данных о платежных картах, как на самые уязвимые места с точки зрения угроз конфиденциальности данных. Далее нужно отметить, что стандарт PCI DSS обозначает и упорядочивает правила безопасной разработки, эксплуатации и поддержки банковских платежных систем, а также процедуры мониторинга этих систем. Одну из главных ролей PCI DSS отводит созданию и поддержанию в актуальном состоянии нормативных документов системы менеджмента информационной безопасности.
Требования банковского стандарта PCI DSS распространяются в основном на банки, а также и на другие организации, если деятельность данных предприятий связана с обработкой, хранением и передачей информации о держателях платежных карт. Международные платежные системы требуют от организаций, на которых действуют требования стандарта PCI DSS, регулярно проходить проверку соответствия данным требованиям. Правила по которым проверяется соответствие стандарту разнятся, что обуславливается видом организации и ежегодным количеством обработанных карточных транзакций. Аудит на соответствие стандарту может выполнить только компания, обладающая сертифицированным статусом QSA, в дальнейшем отчеты об аудите соответствия отправляются платежными системами.
Банковский стандарт PCI DSS появился в 2004 году, но проблемы связанные с его применения все еще остаются. Проведем анализ проблем стоящих перед компанией на различных этапах достижения соответствия. Для этого выделим основные этапы работ.
Основные этапы:
1. Анализ несоответствий.
2. Устранение несоответствий.
3. Сертификационный аудит.
4. Поддержание соответствия.
Каждый из этапов требуется описать подробней, а также рассказать о проблемах внедрения РСI DSS.
Анализ несоответствий
Главная цепь этого этапа является выявление в компании заказчика несоответствий стандарта PCI DSS и подготовка мероприятий для их устранения.
Чаще всего этот этап начинаются процессом определения границ области оценки. На данном этапе компания часто встречается с первой проблемой. Главная задача данного этапа — выявить максимальное количества проблем, уязвимостей и несоответствий, чтобы далее в ходе последующих работ все они были успешно разрешены и сертификационные проверки прошли успешно.
Кроме того, во время разработки плана по ликвидации несоответствий стандарту возникает некоторые затруднения.
Во-первых, стандарт — создан изначально для американского рынка, из-за этого далеко не всегда он применим к реалиям России.
Во-вторых, отсутствие официального русского перевода стандарта PCI DSS. Эта проблема крайне актуальна и связана она с разными толкованиями стандарта как среди аудиторов, так и среди проверяемых. Даже эксперты в области информационной безопасности зачастую не сходятся во мнениях и по разному понимают многие положения стандарта.
В-третьих, отсутствие жесткой политики штрафных санкций международных платежных систем для организаций, которые не выполняют требования банковского стандарта. Это объясняется тем что платежные системы не сильно заинтересованы в очень сильном давлении на своих клиентов. С другой стороны — отсутствие штрафов не приближает компании к соответствию стандарту.
Устранение несоответствий
На данном этапе устраняются проблемы, уязвимости и несоответствия выявленные в ходе первого этапа. Система приводится в соответствие с банковским стандартом PCI DSS.
Есть определенная специфика прохождения данного этапа в России. Довольно часто бывает такая ситуация, одна и та же компания выступает в нескольких ролях она как консультант, так и аудитор, который контролирует выполнение стандарта, и в то же время интегратор, который устраняет несоответствия стандарту. Этот подход практически всегда отражается на качестве и объективности работ.
Это и есть основная проблема — аудитор не может проверять самого себя.
Сертификационный аудит
Завершающий этап — сертификационный аудит. На данном этапе все обнаруженные несоответствия уже устранены либо в процессе исправления. Аудитору представляются отчеты об успешных сканированиях на наличие уязвимостей, которые проводятся компанией имеющей, статус Approved Scanning Vendor (компания имеющая сертификат на проведение сканирования уязвимостей). Компания, которая проводит аудит, подготавливает Report on Compliance (отчет о соответствии) и Atteslation of Compliance (аттестацию соответствия), которые направляются в платежную систему. Но есть один «нюанс» поддержание соответствия стандарту — не единовременный проект, а постоянный процесс. Организации должны проходить регулярный сертификационный аудит ежегодно и проводить мероприятия, направленные на поддержание соответствия стандарту.
Поддержание соответствия
После выполнения предыдущих трех этапов требуется поддерживать соответствие стандарту. Для поддержания соответствия есть ряд процедур, их нужно выполнять для поддержки статуса соответствия. Также аудитор должен убедиться в выполнении процедур в течении всего года.
Процедуры которые необходимо выполнять в течении года:
- Ежегодная оценка рисков, включающая технологические риски и риски, относящиеся к РСI.
- Ежегодное обследование механизмов обеспечения безопасности.
- Проведение ежегодных тестов на проникновение.
- Проведение ежеквартального внутреннего сканирования на уязвимости.
- Проведение ASV организацией ежеквартального внешнего сканирования на уязвимости
- Формальное периодическое обучение сотрудников, задействованных в обеспечении функционирования РСI-систем, информационной безопасности.
- Ежегодное проведение тренингов для нетехнического персонала организации основам информационной безопасности.
- Периодическое тестирование процедур реагирования на инциденты. [1]
Сравнительный анализ соответствия решений Oracle по обеспечению информационной безопасности требованиям банковского стандарта PCI DSS.
Данный сравнительный анализ рассматривает основные требования PCI DSS и предлагаются решения Oracle для решения данных требований.
|
Требование PCI DSS |
Решение Oracle |
|
2.1 Перед установкой системы в сетевую инфраструктуру необходимо изменить настройки, установленные производителем по умолчанию, включая, но не ограничиваясь: пароли, строки доступа SNMP, а также удалить ненужные для работы учетные записи. [1, с. 23] |
Oracle блокирует и завершает период действия учетных записей и паролей во время установки. Пароли администрирования учетных записей запрашиваются во время установки. |
|
2.2 Должны быть разработаны стандарты конфигурации для всех системных компонентов. Стандарты должны учитывать все известные проблемы безопасности, а также положения общепринятых отраслевых стандартов в области безопасности. [1, с. 24] |
Oracle Configuration Management позволяет сканирование баз данных предприятия на соответствие. |
|
2.2.3 Следует настроить параметры безопасности системы таким образом, чтобы исключить возможность некорректного использования системы. [1, с. 25] |
Используя руководящие принципы Oracle Database security configuration можно настроить параметры безопасности системы таким образом, чтобы исключить возможность некорректного использования системы. Oracle Audit Vault консолидирует данные аудита из Oracle, SQL Server, DB2 (по Linux, UNIX и Windows), и базы данных Sybase. Oracle Audit Vault создает отчеты об аудиторских данных. Oracle Database Vault разделет обязанности и предотвращает несанкционированные административные действия в базах данных Oracle. |
|
2.2.4 Из системы должен быть удален весь неиспользуемый функционал: сценарии, драйверы, дополнительные возможности, подсистемы, файловые системы, ненужные для работы веб-серверы. [1, с. 26] |
Выборочная установка Oracle Database позволяет сделать выбор какие конкретные компоненты будут установлены или удалены. |
|
2.3 При использовании неконсольного административного доступа к системе, следует всегда шифровать канал с использованием стойких криптографических алгоритмов. Следует использовать такие технологии, как SSH, VPN или SSL/TLS для веб-ориентированных систем администрирования и иных способов неконсольного административного доступа. [1, с. 26] |
Oracle Advanced Security обеспечивает шифрование (SSL/TLS и собственный шифр) для шифрования всего трафика по протоколу SQL*Net. Кроме того, некоторые средства администрирования, такие как Enterprise Manager обеспечивают ограниченное использование SSL для защиты административный трафик |
|
3.3 Следует маскировать PAN при его отображении (максимально возможное количество знаков PAN для отображения — первые 6 и последние 4). [1, с. 32] |
Virtual Private Database (VPD) могут маскировать весь номер. Контроль безопасности Oracle Label Security могут помочь определить, кто должен иметь доступ к номеру. |
|
3.4 PAN должен быть представлен в нечитаемом виде во всех местах хранения (включая данные на съемных носителях, резервных копиях и журналах протоколирования событий). [1, с. 32] |
Oracle Advanced Security — шифрование данных (TDE) могут быть использованы для «прозрачного» шифрования номера на носителе. Oracle Secure Backup предоставляет решение для резервного копирования и шифрования непосредственно на ленту хранения. Алгоритмы шифрования, включают AES с 256, 192 или 128 бит длиной ключа, а также 3DES168 |
|
3.5 Защитить ключи шифрования данных о держателях карт от их компрометации или неправильного использования. [1, с. 34] |
Ключи хранятся в базе данных и зашифрованы с использованием отдельных мастер- ключей, которые хранится в Oracle Wallet или в Hardware Security Module (HSM). Oracle Wallet шифруется при помощи пароля (на основе PKCS#5). |
|
3.5.1 Доступ к ключам шифрования должен быть разрешен наименьшему возможному количеству ответственным за их хранение и использование сотрудникам. [1, с. 34] |
В Oracle, никому не нужен доступ к мастер-ключу шифрования. DBA или Администратор Безопасности Баз Данных (DSA) нужно знать пароли Oracle Wallet или HSM. |
|
3.5.2 Ключи должны храниться только в строго определенных защищенных хранилищах и в строго определенном виде. [1, с. 34] |
Есть только один мастер-ключ шифрования базы данных. Ключ может храниться в Oracle Wallet или HSM. |
|
3.6.1 Генерация стойких ключей. [1, с. 35] |
Oracle Advanced Security TDE использует RSA библиотеки для генерации сильных криптографических ключей. Если есть HSM, то HSM занимается генерацией ключей и их хранением. |
|
3.6.3 Безопасное хранение ключей. [1, с. 35] |
Ключ храниться в Oracle Wallet или HSM. |
|
3.6.4 Смена ключей шифрования, криптопериод которых истек (например, когда истек установленный срок, и/или когда данным ключом было зашифровано некоторое количество криптотекста), основана на передовых практических методах индустрии безопасности и руководствах (например, специальное издание 800–57 NIST) и должна производиться согласно предписаниям соответствующего производителя или владельца ключа. [1, с. 36] |
Oracle Advanced Security TDE обеспечивает возможность самостоятельного создания мастер-ключей шифрования и/или таблиц ключей. |
|
3.6.5 Изъятие или смена ключей (например, архивация, уничтожение или/и аннуляция) при нарушении его целостности (например, увольнение сотрудника, обладающего информацией об открытом коде ключа), а также ключей, относительно которых существуют подозрения в их компрометации. [1, с. 36] |
Мастер-ключ шифрования не может быть удален, из Oracle Wallet или HSM из-за резервного копирования и требований к восстановлению. |
|
3.6.6 Если процедуры управления криптографическими ключами в открытом виде осуществляются вручную, данные процедуры должны управляться с использованием раздельного знания и двойного контроля (например, таким образом, чтобы для расшифрования данных требовался составной ключ, компоненты которого хранятся у 2–3 сотрудников). [1, с. 37] |
Oracle Wallet пароль может быть разделен между несколькими администраторы. |
|
4.1 Для защиты данных о держателях карт во время передачи их через общедоступные сети следует использовать стойкие криптографические алгоритмы и безопасные протоколы (например, такие как SSL/TLS, IPSEC, SSH и т. д.). [1, с. 39] |
Oracle Database и Oracle Fusion Middleware поддерживает шифрование сетевого трафика с использованием протокола SSL/TLS. Для Базы Данных Oracle, поддерживает SSL/TLS шифрование. |
|
6.1 На все системные компоненты и программное обеспечение должны быть установлены самые свежие обновления безопасности, выпущенные производителем. Критичные обновления безопасности должны быть установлены в течение месяца с момента их выпуска производителем. [1, с. 43] |
Автоматизировано с помощью Oracle Enterprise Manager Grid Control. |
|
6.2 Должен быть внедрен процесс выявления и определения вновь обнаруженных уязвимостей по уровню риска. [1, с. 44] |
Есть возможность подписаться на электронную подписку секции безопасности и OTN. |
|
6.4.3 Производственные данные (действующие PAN) не должны использоваться для тестирования и разработки. [1, с. 47] |
Oracle Data Masking видоизменяет номера кредитных карт и другую важную информацию для тестирования и создания сред разработки. |
|
6.4.5.1 Документирование влияния изменения на систему. [1, с. 47] |
Процедуры управления изменениями может быть автоматизирована с помощью Oracle Change Management. |
|
6.5.1 Инъекции, в особенности, SQL-инъекции. Также следует учесть OS Command, LDAP и Xpath инъекции. [1, с. 48] |
Oracle Database Firewall может проверять входящие SQL запросы. |
|
6.5.3 Небезопасное риптографическое хранилище (необходима защита от криптографических ошибок). [1, с. 48] |
Oracle Advanced Security TDE мастер-ключ шифрования хранится в зашифрованном файле, TDE мастер-ключа шифрования могут храниться в HSM. |
|
6.5.4 Небезопасная передача данных (необходимо шифрование всех критичных соединений и процесса аутентификации). [1, с. 48] |
Oracle Advanced Security обеспечивает зашифрованные сетевые соединения с базой данных Oracle при помощи SSL/TLS. |
|
7.1 Доступом к вычислительным ресурсам и информации о держателях карт должны обладать только те сотрудники, которым такой доступ необходим в соответствии с их должностными обязанностями. [1, с. 51] |
Oracle Database Vault ограничивает доступ к приложениям / данным о держателях карт пользователям. |
Вывод
Сравнительный анализ показал что с помощью программных продуктов Oracle можно выполнить рекомендации банковского стандарта PCI DSS. Также из статьи становится ясно зачем использовать стандарт PCI DSS. Используя данный стандарт нельзя забывать что основная задача РСI DSS не ежегодное проведение аудитов, а достижение требуемого стандартом уровня информационной безопасности, подтверждением которого является успешный аудит.
Литература:
1. Стандарт безопасности данных индустрии платежных карт (PCI DSS) 2010, Сообщество профессионалов PCIDSS.RU
1.
