При переводе руководство было мной немного актуализировано и приведено в соответствие с требованиями новой версии PCI DSS 2.0. Руководство состоит из трех основных частей:
- Описание требований PCI DSS в части журналирования событий,
- Описание процедур анализа журналов регистрации событий,
- Описание доказательств, которые потребуются для подтверждения соответствия требованиям PCI DSS в части журналирования событий.
В первой части рассмотрены следующие вопросы:
- Цели создания Руководства
- Начальные требования и предположения
- Вопросы, которые не вошли в Руководство
- Роли и обязанности
- Требования PCI DSS в части журналирования событий
- Требования раздела 10 PCI DSS
- Другие требования, связанные с журналами регистрации событий
Руководство разработано для специалистов по информационной безопасности, которые пока не являются экспертами в области сбора и анализа журналов регистрации событий. С помощью этого Руководства они могут выполнить свои задачи в рамках требований PCI DSS и повысить свою квалификацию. Хотя Руководство направлено в первую очередь на реализацию требований PCI DSS, оно также может быть полезно в качестве эффективной практики по анализу журналов регистрации событий при реализации любых других требований.
Несколько советов тем, кто решит воспользоваться этим Руководством в своей компании:
- Если вам нужно организовать процедуры анализа журналов регистрации событий в соответствии с требованиями п.10.6 PCI DSS («анализируйте журналы регистрации событий всех системных компонентов не реже одного раза в день») – пользуйтесь этим Руководством и адаптируйте его для своей среды.
- В Руководстве больше внимания уделяется журналированию событий операционной системы и приложений, но вам потребуется также анализировать события сетевых устройств и средств безопасности. К ним применимы те же методы и подходы.
- Руководство было проанализировано QSA и было им одобрено. Однако мнение вашего QSA может быть иным.
Целью является создание всеобъемлющего документа по процедурам анализа журналов регистрации событий для применения в рамках реализации требований PCI DSS. Этот документ должен охватывать процедуры, задачи и методы анализа журналов регистрации событий, описывать все этапы процесса анализа, при необходимости подключать к нему дополнительные системы. Если этот документ должен соответствовать и полностью удовлетворять требованиям 10 и 12 разделов PCI DSS, чтобы пройти аудит на соответствие PCI DSS.
Перечисленные ниже пункты имеют критическое значение для успешного и эффективного журналирования событий, управления журналами и анализа их содержимого в соответствии с PCI DSS. Они должны быть выполнены заранее, до введения в реальную работу процедур анализа журналов регистрации событий.
- Должна быть разработана Политика ведения журналов регистрации событий и другие нормативные документы, детализирующие и систематизирующие требования PCI DSS в отношении журналирования событий.
- Ведение журналов регистрации событий должно быть включено на всех системах, входящих в область, к которой применяются требования PCI DSS.
- Факты отключения или прерывания процесса журналирования событий должны регистрироваться и отслеживаться.
- В журналы регистрации событий должны записываться все события, требуемые PCI DSS и Политикой ведения журналов регистрации событий.
- Создаваемые журналы регистрации событий должны соответствовать требованиям PCI DSS (в частности, требованиям п.10.3).
- Время на всех системах, входящих в область действия PCI DSS, должно быть синхронизировано с использованием надежного сервера времени (с помощью NTP или другой технологии, соответствующей требованиям п.10.4 PCI DSS).
- Часовые пояса, в которых работают системы, выполняющие журналирование событий, должны быть известны, зафиксированы и пригодны для учета в процессе анализа журналов.
- Человек, чьи действия журналируются на определенной системе, не может быть единственным, кто выполняет анализ журналов регистрации событий этой же системы.
- Все попытки получения доступа к журналам регистрации событий должны регистрироваться и отслеживаться для выявления попыток отключения журналирования событий или иных попыток воздействия на ведение и содержимое журналов.
В Таблице 1 перечислены вопросы, которые не рассматриваются в настоящем Руководстве, несмотря на то, что они могут иметь важное значение для достижения соответствия требованиям PCI DSS.
| Вопрос | Почему он не вошел в Руководство? |
| Какие события должны журналироваться в каждом приложении? | Настоящее Руководство касается только процедур анализа журналов регистрации событий. Предполагается, что само журналирование уже реализовано надлежащим образом в соответствии с требованиями PCI DSS и Политики ведения журналов регистрации событий |
| Какую информацию нужно записывать в журнал для каждого журналируемого события в каждом приложении? | Настоящее Руководство касается только процедур анализа журналов регистрации событий. Предполагается, что само журналирование уже реализовано надлежащим образом в соответствии с требованиями PCI DSS и Политики ведения журналов регистрации событий |
| Высокоуровневая политика ведения и мониторинга журналов регистрации событий | Подразумевается, что эта политика уже должна быть введена в действие |
| Политики и процедуры сбора, обработки и сохранения событий | Эти процедуры не рассматриваются в настоящем Руководстве |
| Процедуры реагирования на инциденты информационной безопасности | Настоящее Руководство касается только процедур анализа журналов регистрации событий. Выполнение этих процедур иногда приводит к необходимости инициирования процедур реагирования на инциденты и проведения расследований |
| Приложения, которые не входят в область действия PCI DSS | Настоящее Руководство охватывает только приложения, находящиеся в области действия PCI DSS |
| Сетевые устройства, которые входят или не входят в область действия PCI DSS | Настоящее Руководство охватывает только приложения, находящиеся в области действия PCI DSS. Но в вашем проекте по организации анализа журналов регистрации событий сетевые устройства обязательно должны быть учтены! |
| Контроль доступа к хранящимся журналам регистрации событий, защита конфиденциальности и целостности данных в журналах регистрации событий | Эти процедуры не рассматриваются в настоящем Руководстве |
| Компенсирующие меры для случаев, когда ведение журналов регистрации событий невозможно | Настоящее Руководство касается только процедур анализа журналов регистрации событий. Анализ журналов всегда возможен, если возможно их ведение. Ситуации, когда ведение журналов невозможно, в настоящем Руководстве не рассматриваются |
| Мониторинг в режиме реального времени состояния централизованной системы журналирования событий, ее производительности и т.п. | Настоящее Руководство касается только процедур анализа журналов регистрации событий |
| Требования к журналированию событий, помимо разделов 10 и 12 PCI DSS | Настоящее Руководство ограничивается только требованиями разделов 10 и 12 PCI DSS. Краткий обзор других требований к журналированию также приводится, но для них не приводятся детальные процедуры |
| Гарантии успешного прохождения аудита на соответствие требованиям PCI DSS | Только QSA каждой компании может предоставить такие гарантии после проведения аудита |
| Правила корреляции для мониторинга событий | Настоящее Руководство касается только процедур анализа журналов регистрации событий, но не правил корреляции. Однако некоторые вопросы, имеющие отношение к правилам корреляции, в настоящем Руководстве рассматриваются |
| Сохранение записей журнала регистрации событий для целей криминалистического анализа | Вопрос сохранения записей журнала регистрации событий для целей криминалистического анализа, относится к процедурам реагирования на инциденты |
В Таблице 2 перечислены роли, использующиеся в процедурах анализа журналов регистрации событий, а также их обязанности в рамках этих процедур. Далее эти роли и обязанности будут рассмотрены более детально.
| Роль | Обязанности | Пример участия в анализе журналов |
| Администратор приложения | Администрирует приложение | Настройка системы регистрации событий в приложении, выполнение ежедневного анализа журналов регистрации событий для выявления технических проблем |
| Системный и сетевой администратор | Администрирует операционную систему, на которой работает приложение, и сеть | Настройка системы регистрации событий, выполнение ежедневного анализа журналов регистрации событий для выявления технических проблем |
| Бизнес-владелец приложения | Руководитель бизнес-подразделения, ответственный за приложение | Утверждает изменения в конфигурации приложения в части ведения и анализа журналов регистрации событий |
| Администратор безопасности | Администрирует средства безопасности на одной или нескольких системах / приложениях | Настройка механизмов безопасности и системы аудита в приложении, выполнение ежедневного анализа журналов регистрации событий для выявления технических проблем (только принимает участие!) |
| Аналитик безопасности | Работает с процессами обеспечения безопасности при эксплуатации приложения | Использование систем безопасности, просмотр журналов регистрации событий и других данных, выполнение ежедневного анализа журналов регистрации событий |
| Руководитель подразделения информационной безопасности | Контролирует соблюдение политики безопасности, выполнение процессов обеспечения безопасности, эксплуатации средств безопасности | Владелец процедур анализа журналов регистрации событий, обновляет эти процедуры по мере необходимости |
| Ответственный за реагирование на инциденты | Участвует в мероприятиях по реагированию на инциденты безопасности | Работа с инцидентами безопасности, анализ журналов регистрации событий в рамках мероприятий по реагированию на инциденты безопасности |
В этом разделе рассмотрены требования PCI DSS в части журналирования событий. Следует отметить, что вопросы ведения и мониторинга журналов регистрации событий рассматриваются не только в разделе 10, раздел 12 также затрагивает эти вопросы. Однако основной областью настоящего Руководства являются требования раздела 10.
Сначала мы рассмотрим требования каждого из пунктов, а затем углубимся в детали, примеры и рекомендации по реализации.
10.1
«Реализуйте процесс, обеспечивающий связь любых фактов доступа к системным компонентам (в особенности доступа, с использованием административных привилегий, например, root) с конкретными пользователями». PCI DSS не просто требует обеспечить наличие журналов регистрации событий или организовать процесс их сбора, он требует обеспечить связь событий, отраженных в журнале регистрации, с конкретными людьми (а не компьютерами или устройствами, которые были источником события). Это требование часто создает проблемы для внедряющих PCI DSS. Многие начинают думать о журналах, как о «записях о действиях людей», тогда как в действительности они являются «записями о действиях компьютеров». Кстати, требование п.8.1 PCI DSS, которое говорит, что «каждому пользователю должно быть присвоено уникальное имя (идентификатор) до предоставления ему доступа к системным компонентам или данным платежных карт», помогает и при реализации требования п.10.1, делая журналы регистрации событий более полезными.
10.2
п.10.2 определяет минимальный перечень системных событий, которые должны журналироваться. Это требование вызвано необходимостью проведения оценки и мониторинга действий пользователей, а также других событий, которые могут оказать влияние на данные платежных карт (например, системные сбои). Ниже представлен список событий, которые должны журналироваться в соответствии с этим пунктом:
- «10.2.1. Любой доступ к данным платежных карт
- 10.2.2. Все действия, выполненные с использование административных привилегий
- 10.2.3. Доступ к любым журналам регистрации событий
- 10.2.4. Неудачные попытки логического доступа
- 10.2.5. Использование механизмов идентификации и аутентификации
- 10.2.6. Инициализация журналов регистрации событий
- 10.2.7. Создание и удаление системных объектов»
10.3
Далее раздел 10 PCI DSS опускается до еще более детального уровня и указывает конкретные данные, которые должны записываться в журнал регистрации событий для каждого события. Это вполне разумные минимальные требования, которые обычно не превышают стандартных возможностей механизмов регистрации событий большинства ИТ-платформ. Записи подлежат следующие данные:
- «10.3.1. Идентификатор пользователя
- 10.3.2. Тип события
- 10.3.3. Дата и время события
- 10.3.4. Индикатор успеха или отказа
- 10.3.5. Источник события
- 10.3.6. Идентификатор или название задействованных данных, системного компонента или ресурса»
10.4
Следующий пункт требований учитывает очень важный аспект, про который часто забывают: необходимость использования при журналировании событий точного и согласованного времени. Очевидно, что время событий, которое будет записываться в журнал регистрации событий, будет браться на основе системного времени компьютера. Однако время на различных системах может различаться или вообще быть настроено некорректно. Это может сильно затруднить корреляцию и анализ событий с нескольких различных систем. Поэтому требуется настроить синхронизацию времени на всех критичных системах на основе надежного источника, например, службы NTP.
Во второй версии PCI DSS это требование немного детализировано, в него добавлены следующие подпункты:
- «10.4.1. На критичных системах должно быть установлено правильное и согласованное время
- 10.4.2. Данные времени должны быть защищены
- 10.4.3. Должно быть настроено получение текущего времени из надежных источников».
10.5
Далее, нужно учесть вопросы обеспечения конфиденциальности, целостности и доступности журналов регистрации событий. Пункт 10.5.1 PCI DSS касается конфиденциальности: «просмотр журналов регистрации событий должен быть разрешен только тем сотрудникам, которым это необходимо для выполнения своих должностных обязанностей». Причиной такого ограничения является высокая вероятность наличия в журналах регистрации событий конфиденциальной информации. Например, неудачные попытки аутентификации записываются в журнал с указанием использованного имени пользователя, при этом пользователь может ошибиться и ввести в поле имени свой пароль. Другим примером может быть плохо написанное приложение, которое может указывать пароль пользователя в адресах URL, которые сохраняются в журнале регистрации событий веб-сервера.
Следующим вопросом является целостность. Пункт 10.5.2 говорит, что «файлы журналов регистрации событий должны быть защищены от несанкционированных изменений». Это очевидно, поскольку, если журналы могут быть изменены неуполномоченным лицом, они не могут считаться объективной информацией о действиях пользователей и систем.
Однако это требует обеспечить защиту файлов журналов регистрации событий не только от неуполномоченных лиц, но и от системных сбоев, и от последствий ошибок при настройке систем. Это затрагивает не только целостность, но и доступность журналов регистрации событий. Эту тему продолжает требование п.10.5.3: «должно выполняться своевременное резервное копирование файлов журналов регистрации событий на централизованный лог-сервер или внешние носители информации, где эти файлы сложнее изменить». Организация централизованного хранения журналов регистрации событий на лог-сервере (одном или нескольких), на котором будет выполняться анализ собранных событий, очень важна, как для защиты журналов, так и для повышения эффективности их использования. Резервное копирование журналов регистрации событий на DVD-диски (или ленту) является еще одним следствием этого требования. Однако нужно понимать, что записанные на ленту или DVD-диски журналы не являются легко доступными, их неудобно использовать для поиска информации в случае инцидента, а PCI DSS требует сохранить возможность оперативного доступа к данным журналов регистрации событий в течение 3 месяцев.
Многие компоненты сетевой инфраструктуры, такие как маршрутизаторы, коммутаторы отправляют журналируемые события на внешний сервер, а на самом устройстве хранится только минимальный объем событий (или вообще не хранится). Для таких систем организация централизованного хранения журналов регистрации событий крайне важна. Кроме того, требование п.10.5.4 говорит, что необходимо «журналы регистрации событий доступных извне сетей и устройств (беспроводные сети, DNS, межсетевые экраны и т.п.) копировать на лог-сервер во внутренней сети».
Для дальнейшего снижения рисков несанкционированного изменения журналов регистрации событий, а также для обеспечения возможности доказать отсутствие каких-либо изменений, п.10.5.5 указывает, что «должно использоваться специальное программное обеспечение для контроля целостности файлов журналов регистрации событий и обнаружения изменений в них, обеспечивающее невозможность внесения изменений в данные журналов без генерации соответствующего предупреждения». При этом добавление в журнал новых событий не должно приводить к генерации такого предупреждения, т.к. в журналы регистрации событий постоянно добавляются новые события, их объем постоянно растет, а не уменьшается (за исключением периодической архивации старых событий на внешние носители информации и их удаления с сервера). Системы мониторинга целостности файлов используют криптографические алгоритмы хэширования для сравнения имеющихся файлов с заведомо правильной копией. Поскольку в файлы журналов регистрации событий постоянно записываются новые события, процесс постоянного расчета их хэш-функций может стать настоящей проблемой. Нужно понимать, что контроль целостности может проводиться только в отношении статичных файлов журналов регистрации событий, а не тех, в которые непрерывно добавляется новая информация. Существуют некоторые специальные алгоритмы, позволяющие выявлять любые изменения, кроме добавления.
10.6
Следующее требование является одним из самых важных, тем не менее, оно часто упускается из виду. Многие специалисты, внедряющие средства безопасности, необходимые для реализации требований PCI DSS, просто «забывают», что раздел 10 PCI DSS требует не только «иметь журналы регистрации событий», но и «контролировать их содержимое». В частности, в п.10.6 говорится, что «Просмотр журналов регистрации событий для всех системных компонентов должен выполняться не реже одного раза в день. Также должны просматриваться журналы регистрации событий серверов, выполняющих функции обеспечения безопасности (таких как системы обнаружения вторжений (IDS) и серверы аутентификации, авторизации и учета (AAA), например, RADIUS)». Далее в настоящем Руководстве процедуры и методы анализа журналов регистрации событий будут рассмотрены более подробно.
Данное требование определяет системы, журналы регистрации событий с которых должны «просматриваться ежедневно», поэтому недостаточно просто настроить на них журналирование событий и организовать копирование или централизованное хранение журналов. Учитывая, что большая ИТ-среда может производить гигабайты журналов ежедневно, анализ каждого сохраненного в них события выходит за рамки человеческих возможностей. Именно поэтому в данном пункте PCI DSS сделано примечание, которое говорит, что «для достижения соответствия требованию 10.6 могут использоваться инструменты сбора, анализа событий и передачи уведомлений». Далее будут рассмотрены ручные и автоматизированные методы анализа журналов регистрации событий.
10.7
Последний пункт требований раздела 10 связан с еще одним важным вопросом журналирования событий – сохранением журналов регистрации событий в оперативном доступе. В п.10.7 сказано, что «журналы регистрации событий должны храниться не менее одного года, при этом в течение трех месяцев журналы должны находиться в режиме постоянной готовности для немедленного проведения анализа». Таким образом, если вы не можете просмотреть журналы регистрации событий годовой давности, это будет являться нарушением.
Итак, подведем итог рассмотренных до настоящего момента требований PCI DSS в части журналирования событий:
- Раздел 10 PCI DSS устанавливает требования по ведению регистрации определенных событий и указывает уровень детализации сохраняемой в журналах информации. Эти требования распространяются на все системы, находящиеся в области действия PCI DSS.
- Необходимо обеспечить наличие связи между сохраненными в журналах действиями и конкретными пользователями.
- Системные часы на всех системах, входящих в область действия PCI DSS, должны быть синхронизированы.
- Необходимо обеспечить защиту конфиденциальности, целостности и доступности собранных журналов регистрации событий.
- Журналы регистрации событий должны регулярно просматриваться.
- Журналы регистрации событий всех систем, входящих в область действия PCI DSS, должны храниться не менее года.
Многие защитные меры, применяемые для реализации требований PCI DSS, такие как шифрование данных или обновление антивирусных средств, реально могут соответствовать этим требованиям только при выполнении журналирования событий и контроля журналов.
Например, в разделе 1 «Обеспечить настройку и управление конфигурацией межсетевых экранов для обеспечения защиты данных платежных карт» говорится, что компании должны иметь «формализованный процесс утверждения и тестирования всех подключений внешних сетей, а также изменений, вносимых в конфигурацию межсетевых экранов и маршрутизаторов». Однако после создания такого процесса, необходимо иметь возможность подтверждения, что настройки межсетевых экранов и маршрутизаторов изменяются только после официального утверждения этих изменений и в строгом соответствии с документированными процедурами по управлению изменениями. Как раз для этой цели очень удобно использовать журналы регистрации событий, поскольку они показывают, что происходило на самом деле, а не только то, что должно было выполняться.
Пункт 1.3 (со всеми его подпунктами) содержит указания по настройке межсетевого экрана вплоть до конкретных требований в отношении входящих и исходящих соединений. Для того чтобы подтвердить реализацию этого требования, необходимо использовать журналы регистрации событий. Проведения анализа конфигурации межсетевого экрана будет недостаточно, поскольку только журналы могут сказать о том, «как межсетевой экран работал на самом деле», а не просто «как он был настроен».
Раздел 2 говорит о лучших практиках по управлению паролями, а также об общем укреплении безопасности, в частности, об отключении ненужных сервисов. Журналы регистрации событий могут показать, что эти ранее заблокированные сервисы вновь были включены неправильно проинструктированным системным администратором или злоумышленником.
Раздел 3, который указывает на необходимость шифрования данных, имеет прямые и недвусмысленные ссылки на журналирование событий. В частности, весь п.3.6 основан на наличии журналов регистрации событий, которые позволят проверить, что требуемые в этом пункте действия действительно выполняются. Такие процедуры, как генерация ключей, их распределение и отзыв, журналируются большинством криптографических систем. Наличие этих журналов имеет решающее значение для обеспечения соответствия этому требованию.
Соблюдение требований раздела 4, который также связан с шифрованием, по тем же причинам может быть подтверждено только с помощью журналов регистрации событий.
Раздел 5 относится к антивирусной защите. Разумеется, чтобы подтвердить выполнение указаний п.5.2, который говорит, что «средства антивирусной защиты должны быть постоянно включены, они должны регулярно обновляться и вести журналирование событий», потребуется продемонстрировать эти журналы.
Таким образом, даже требование «использовать и регулярно обновлять антивирусное программное обеспечение» ведет к необходимости ведения журналов регистрации событий, поскольку при проведении оценки соответствия требованиям PCI DSS данные этих журналов понадобятся для подтверждения их фактической реализации. Кроме того, в журналах будут отражаться факты неудачных попыток обновления антивируса, что подвергает компанию дополнительному риску заражения вирусами, т.к. антивирус с неактуальными базами вирусных сигнатур создает ложное чувство безопасности и сводит «на нет» усилия по обеспечению соответствия данным требованиям.
Раздел 6 говорит о необходимости «обеспечить безопасность при разработке и поддержке систем и приложений», что немыслимо без организации полноценной системы журналирования событий и контроля безопасности приложений.
Раздел 7, в котором указано, что необходимо «ограничить доступ к данным платежных карт в соответствии со служебной необходимостью», фактически требует вести журналы регистрации событий для проверки, кто в действительности получал доступ к указанным данным. Если в журнале будут обнаружены события получения доступа к данным платежных карт пользователями, которым такой доступ не требуется для выполнения своих обязанностей, требуется, как минимум, внести соответствующие изменения в настройки прав доступа.
Назначение каждому пользователю, использующему систему, уникального идентификатора соответствует «лучшим практикам» в области безопасности. В PCI DSS это не просто «лучшая практика» – это требование (раздел 8 – «каждому лицу, имеющему доступ к компьютерным ресурсам, должен быть назначен уникальный идентификатор»). Очевидно, что при этом необходимо «контролировать добавление, удаление и изменение учетных записей пользователей, учетных данных и других идентификационных объектов» (п.8.5.1 PCI DSS). Большинство систем записывают такие действия в журнал регистрации событий.
Кроме того, выполнение п.8.5.9, требующего «обеспечить изменение паролей пользователей не реже одного раза в 90 дней», также может быть проверено путем анализа содержимого журналов регистрации событий сервера, чтобы убедиться, что пароли всех учетных записей реально изменяются не реже одного раза в 90 дней.
Раздел 9 относится к другой области безопасности – физическому контролю доступа. Даже п.9.4, в котором говорится, что «Для хранения записей о посетителях должен использоваться журнал регистрации посетителей, в котором должны указываться ФИО посетителя, название компании, которую он представляет, и ФИО сотрудника компании, который дал разрешение на пропуск этого посетителя. Данный журнал должен храниться не менее 3 месяцев, если это не противоречит законодательству», может быть связан с управлением журналами регистрации событий, если этот журнал регистрации посетителей ведется в электронной форме.
Раздел 11 говорит о необходимости «регулярного тестирования систем и процессов обеспечения безопасности». Однако п.11.4 также требует использования систем IDS или IPS: «Должны использоваться системы выявления и/или предотвращения вторжений для мониторинга всего трафика на периметре среды, в которой хранятся и обрабатываются данные платежных карт, а также на критичных узлах внутри этой среды. Эти системы должны оповещать персонал о подозрительных действиях. Должно проводиться регулярное обновление программного обеспечения и сигнатур систем выявления и предотвращения вторжений». Польза от работы системы выявления вторжений будет только в том случае, если анализируются ее журналы регистрации событий и отправляемые ей оповещения.
Раздел 12 касается более высокоуровневых вопросов безопасности – политики безопасности, а также стандартов безопасности и ежедневных процедур (например, среди них должна быть процедура ежедневного анализа журналов регистрации событий, предусмотренная в Требовании 10). Однако этот раздел затрагивает также и вопросы журналирования событий, поскольку ведение журналов регистрации событий должно быть частью любой политики безопасности. Кроме того, требования в отношении реагирования на инциденты, также связаны с журналами регистрации событий – п.12.5.3: «разработка, документирование и распределение процедур реагирования на инциденты безопасности и процедур эскалации для обеспечения своевременной и эффективной обработки инцидентов в любых ситуациях» невозможно реализовать это без эффективного сбора и своевременного анализа данных журналов регистрации событий.
Таким образом, организация журналирования событий и ведения мониторинга содержимого журналов при внедрении PCI DSS, выходит далеко за рамки требований раздела 10. Только с помощью тщательного сбора и анализа журналов регистрации событий компания сможет обеспечить свое соответствие большинству требований PCI DSS.
Я бы также добавил сюда и возможность интеграции информационной безопасности с системами смис и смик - очень будет мощная система!
ОтветитьУдалить