PCI DSS / PA DSS: как это будет по-русски?

ДЕДЛАЙН ОТ VISA

Банки же (а в России под требования подтверждения комплайнса попадают в основном именно крупные банки) оставались один на один со своими несоответствиями и, несмотря на довольно детальные рекомендации, выданные аудиторами по результатам аудита, через год оставались примерно на том же уровне соответствия, что и при первичном аудите.

Однако после объявления первого глобального дедлайна VISA по комплайнсу ситуация в корне изменилась. С тех пор банки и процессоры не хотели простого перечня недостатков, а желали иметь комплайнс и только за это готовы были платить. Как известно, спрос рождает предложение.

Первыми комплайнс, то есть активное участие в реализации недостающих защитных мер, стали предлагать интеграторы по ИБ, имеющие статус QSA. Это и понятно, ведь у них было все необходимое для этого – и линейка средств защиты, и специалисты по консалтингу и внедрению. Следом, заключив партнерские соглашения с интеграторами не-QSA, аналогичные услуги стали предлагать и остальные компании-QSA.

В настоящее время решение задачи комплайнса строится по практически унифицированной для всех аудиторов схеме: предварительный аудит/gapanalyse–> внедрение защитных мер –> сертификационный аудит. Таким образом, в ходе сертификационного аудита аудиторы проверяют результаты, в том числе и своей работы, что, по мнению многих, в корне противоречит принципу независимости аудита.

Причем аналогично ситуация обстоит и на Западе, где тема соответствия стандарту PCI DSS актуальна на несколько лет больше, чем в России. Так, основные аудиторы, работающие на западных рынках, предлагают разнообразные услуги ИБ, предшествующие сертификационному аудиту.

В ЦЕНЕ НЕПРЕДВЗЯТОСТЬ

Давайте же попробуем разобраться, в чем заключается принцип независимости аудита и насколько велик риск его нарушения. Согласно многочисленным стандартам по аудиту, в том числе IT-аудиту(1), аудитор должен быть независим по отношению к аудируемому на протяжении всего аудита – как в части позиции, так и формального подчинения.

Причем под независимостью понимается совокупность многих факторов – независимость аудиторской и проверяемой компаний, персональная независимость аудитора, в том числе отсутствие финансовой выгоды от результатов аудита, отсутствие отношений с проверяемой компанией или конкретными ее сотрудниками, отвечающими за выполнение поверяемых функций и т.п. Ну и, пожалуй, одной из наиболее частых причин конфликта интересов в ходе аудита является проверка тех областей и функций IT-систем, в реализации которых участвовал ранее аудитор.

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

К ним можно отнести технические консультации, основанные на имеющихся у аудитора компетенциях, давая которые, аудитор не участвует в принятии решений применительно к конкретным IT-системам. Например, поддерживает ли определенный тип МЭ функции антиспуффинга и как реализован этот механизм, можно ли реализовать аудит действий администраторов СУБД, насколько велика будет нагрузка от включения такого аудита и т.п.

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

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

АФФИЛИРОВАННОСТЬ ПОД ЗАПРЕТОМ

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

На самом деле ни VISA, ни консул PCI SSC, поддерживающий стандарт и дающий аккредитацию аудиторам, не запрещают компаниям-QSA оказание услуг, отличных от аудита, в рамках программы комплайнса. Причем «не запрещают» означает в данном контексте «признают за аудиторами это право и даже в некотором смысле поощряют». Причина этого довольно простая – МПС поддерживают любые меры, которые позволят им добиться от своих членов желаемого уровня безопасности.

А кто правильнее интерпретирует требования стандарта и лучше знает, что действительно нужно для их выполнения, чем сертифицированный QSA-аудитор? Ведь если посмотреть на опубликованные вендорами средств защиты результаты их собственного анализа полезности своих решений для выполнения требований PCI DSS, то получается, что для получения заветного сертификата соответствия необходимо внедрить практически всю существующую на рынке средств защиты номенклатуру продуктов.

Однако МПС, входящие в состав консула, отнюдь не игнорируют best practices IT-аудита. Скорее, они посчитали риск нарушения аудиторами принципов независимости аудита не настолько высоким, насколько полезен эффект от участия сертифицированного аудитора в работах в рамках плана достижения соответствия. А для снижения этого риска, в дополнение к квалификационным требованиям для аудиторов о наличии сертификата CISA(2), включили положения в поддержку принципа независимости аудита в официальные требования к компании-QSA (PCI DSS Validation Requirements for QSA).

Согласно этому документу, проверяемая компания и компания-аудитор не могут быть аффилированы, а все факты участия компании-аудитора в разработке, установке, настройке или управлении средств и систем защиты проверяемой компании должны быть детально изложены в отчете для возможности их анализа. Более того, каждая компания-QSA обязана продумать комплекс мер, позволяющий гарантировать беспристрастность и объективность оценки выполнения своей же работы (например, реализация и аудит выполняются силами сотрудников разных подразделений).

ОБ ЭТИКЕ АУДИТОРА

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

Ведь представьте себе ситуацию, когда на аудите выясняется, что в зону контроля сложной системы сбора событий ИБ, которую внедряли полгода, проектировщики забыли включить один или два ресурса, причем подключить их оперативно невозможно, потому что или закончились лицензии, или на интеграцию этого типа ресурсов с системой необходимо время. Вполне закономерен праведный гнев проверяемой компании: «Мы вам заплатили за внедрение столько-то денег. Где комплайнс?».

Разрешить возникший конфликт интересов действительно бывает непросто, а вот предупредить – возможно. Приведенные ниже рекомендации позволят компании-QSA реализовать взятую на себя часть плана приведения в соответствие и соблюсти при этом принцип независимости аудита:

• Если предполагается внедрение средств защиты, то их проектированием/внедрением/настройкой должно заниматься подразделение, которое не будет участвовать в предстоящем аудите;
• Если предполагается разработка нормативных документов/проведение пен-теста или оказание других услуг с участием аудитора, то этот аудитор не должен участвовать;
• По итогам предварительной оценки (gapanalyze) аудитор зачастую определяет только недостающие средства защиты, а проектировщики самостоятельно проектируют системы, исходя из своего понимания требований PCI DSS и отданного им в руки аудиторского отчета.

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

Ну и последнее, наверное, на что хочется обратить внимание в связи с вопросом независимости аудита. Его контроль в настоящий момент как со стороны PCI SSC, так и отдельных МПС практически не реализован. Более того, введен институт внутренних аудиторов PCI, и мерчантам разрешено подтверждать соответствие своей компании требованиям PCI DSS именно силами своих внутренних аудиторов(3).

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

_____________________________________________________________________________________
[1]В частности, «IT Standards, Guidelines, and Tools and Techniques for Audit and Assurance and Control Professionals», разработанный ISACA.
[2]Certified Information System Auditor. Получение этого сертификата предполагает принятие принципов этики аудитора, включая следование принципу независимости аудита.

 

КОММЕНТАРИЙ БАНКА

Андрей ГРИЦИЕНКО,
начальник Службы информационной безопасности ОАО «Банк «Возрождение»:

Банк «Возрождение» (ОАО) и ЗАО «Информзащита» – давние деловые партнёры. Многолетняя совместная работа сотрудников Службы информационной безопасности Банка и специалистов ЗАО «Информзащита» увенчалась достижением Банком статуса соответствия Стандарту PCI DSS . При проведении аудита Банка мы убедились в глубоких знаниях аудиторов, их умении предложить оптимальные пути устранения имеющихся несоответствий, корректно оценить комплекс мероприятий, выполненных сотрудниками Банка в ходе реализации требований, предъявляемых Стандартом PCI DSS .

Получение Банком статуса «compliance» – это один из важнейших шагов по достижению соответствия предъявляемым требованиям по защите данных держателей банковских карт. Но получение соответствия – это не самоцель, гораздо важнее поддержать достигнутое соответствие до очередного аудита. А вот это совсем не просто, так как банк – это не застывшая статическая структура. Потребности бизнеса обуславливают непрерывное изменение структуры банка, состав информационных систем, технологий обработки данных держателей банковских карт и т.д. Эти изменения сопровождаются внедрением новых систем и мер безопасности, разработкой и/или внесением изменений в нормативные и технологические документы. Одновременно появляются новые руководящие документы и комментарии МПС и PCI Council по реализации отдельных требований. Своевременно отследить и правильно отреагировать на появление новых требований сотрудникам банков весьма непросто. Поэтому предлагаемая схема: предварительный аудит – разработка и внедрение дополнительных защитных мер (при необходимости) – сертификационный аудит, – с моей точки зрения является наиболее рациональной и жизнеспособной после получения банком статуса соответствия Стандарту PCI DSS . Да, конечно, данная схема повлечёт увеличение затрат на проведение аудита, но в то же время существенно снизит риски банка подвергнуться штрафным санкциям со стороны международных платежных систем.

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

В 2010 году Банком России принят комплекс документов по стандартизации СТО БР ИББС-1.0-2010, который содержит ряд требований, совпадающих с требованиями Стандарта PCI DSS, но это два абсолютно разных стандарта. Одновременное выполнение требований обоих стандартов для банка весьма непростая задача. Если в основе Стандарта Банка России лежит риск-ориентированный подход, допускаются границы выполнения содержащихся требований, то Стандарт PCI DSS требует однозначного и полного выполнения всех требований.

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

Как видно из требования Стандарта PCI DSS, «План реагирования на инциденты информационной безопасности» должен содержать процедуры восстановления и обеспечения непрерывности бизнеса, процессы резервного копирования. Но, в соответствии с Указанием Банка России от 5 марта 2009 года № 2194-У, данные процедуры (процессы) должны быть включены в «План действий, направленных на обеспечение непрерывности деятельности и (или) восстановление деятельности кредитной организации в случае возникновения непредвиденных обстоятельств».

В то же время третий Стандарт РФ ГОСТ Р ИСО / МЭК ТО 18044-2007 «Менеджмент инцидентов информационной безопасности» требует, чтобы в организации была разработана Политика менеджмента инцидентов информационной безопасности совершенно иного содержания.

Иными словами, реализация выполнения норм данных Стандартов потребует от подразделений информационной безопасности банков дополнительных затрат на разработку документов «под каждый стандарт».

В качестве вывода следует отметить, что внедрять Стандарты надо. Но все должны понимать, что внедрение каждого Стандарта потребует не только дополнительных финансовых затрат, но и каждодневной напряжённой работы сотрудников банка, согласованных действий всех его структурных подразделений.

 

Требования к содержанию Плана реагирования на инциденты информационной безопасности разных Стандартов

Стать автором BIS Journal