22.11.2010

Compliance как угроза

image

Соответствие требованиям регуляторов – одна из основных прикладных задач обеспечения безопасности компаний и организаций различных отраслей и масштабов. Несмотря на тенденцию усиления регуляторных рисков, процесс compliance management может быть разумно встроен в систему управления ИТ и ИБ, реализованную на основе общепризнанных методик и рекомендаций.

Автор: Сергей Гордейчик

Статья опубликована в журнале ИКС № 9 2010

Долгое время в России было принято считать отечественный рынок информационной безопасности очень жестко регулируемым и при каждом удобном случае кивать на Запад, где свободнее и проще. Глобализация привнесла в нашу жизнь элементы зарубежного регулирования, и выяснилось, что многие требования, казавшиеся сложными и затратными для исполнения, меркнут по сравнению с новыми.

В области управления соответствием требованиям регуляторов (compliance management) можно выделить три устойчивых тренда: увеличение количества требований и регуляторов, расширение круга компаний и организаций, подпадающих под действие требований, и переход требований из разряда рекомендательных в обязательные.

За последние несколько лет к привычным требованиям, закрепленным в российском законодательстве и контролируемым ФСТЭК и ФСБ, добавились несколько международных, государственных и отраслевых стандартов, исполнение которых во многом определяет развитие отрасли. Рассмотрим по одному наиболее яркому представителю из каждой группы.

Стандарт PCI DSS

Стандарт безопасности информации индустрии платежных карт PCI DSS (Payment Card Industry Data Security Standard) с 2004 г. обязателен для исполнения в мире и с 2006 г. активно внедряется в России. Несмотря на то что начало применения штрафных санкций и других мер наказания за неисполнение стандартов для резидентов Российской Федерации неоднократно откладывалось, есть основания полагать, что очередной установленный Советом по безопасности PCI Security Standards Council срок (сентябрь 2010 г.[1]) больше переноситься не будет. Многие думают, что требования стандарта касаются только банков – эмитентов пластиковых карт. Это заблуждение. В той или степени положения стандарта должны соблюдать все компании, связанные с электронными платежами, начиная с финансовых организаций и заканчивая магазинами и операторами связи (мерчантами). Один из наборов требований, выделенных в стандарт PA DSS (Payment Applications Data Security Standard), относится непосредственно к разработчикам информационных систем, обслуживающих и осуществляющих транзакции с использованием платежных карт. Таким образом, стандарт PCI DSS является международным отраслевым стандартом, обязательным для исполнения большим количеством компаний. Следует отметить, что на сегодняшний день PCI DSS – один из наиболее ориентированных на практику, корректно сформулированных и процедурно выстроенных международных стандартов в области ИБ.

Стандарт СТО БР ИБСС

Стандарт Банка России «Обеспечение информационной безопасности организаций банковской системы Российской Федерации» развивается достаточно давно, но до сих пор не является обязательным для исполнения и носит рекомендательный характер. Однако тенденции последних двух лет показывают, что с высокой степенью вероятности организации кредитно-финансовой сферы примут положения стандарта в качестве основы для выполнения требований Федерального закона «О персональных данных». Это сделает его де-факто обязательным и, естественно, серьезно повысит его популярность. Учитывая, что при разработке стандарта широко использовался передовой мировой опыт в области управления ИБ, с концепцией СТО БР ИББС гармонично сочетаются процессы управления соответствием как высокоуровневым таксономиям (например, CobiT или ITIL/ITSM), так и более практическим рекомендациям уровня PCI DSS.

Закон «О персональных данных»

Принятие Федерального закона «О персональных данных» (ФЗ-152) вызвало бурную реакцию на рынке. Особенность закона в том, что он затрагивает не какую-либо одну отрасль или индустрию, а всех субъектов, которые участвуют в обработке информации, относящейся к персональным данным. Таким образом, под действие стандартов подпало огромное количество компаний и организаций – от детских садов до транснациональных корпораций и госорганизаций. Учитывая глобальность охвата, а также наличие в законе и нормативной базе целого ряда недочетов, перенос на год срока приведения информационных систем в соответствие с требованиями законодательства представляется необходимым. Однако отметим, что, несмотря на перенос, проверки соответствия проводятся регуляторами достаточно давно и зачастую заканчиваются констатацией нарушений.

Конечно, тремя обозначенными стандартами требования по защите информации не ограничиваются. Существуют привычные регулирующие документы ФСБ и ФСТЭК, такие как требования к ключевым системам информационной инфраструктуры (КСИИ), менее популярные отраслевые («Базовый уровень безопасности» РСС), корпоративные (например, серия стандартов СТО Газпром 4.2) и международные (закон Сарбейнса–Оксли, SOX) требования. Но их количество и разнообразие лишь подтверждает наметившуюся тенденцию усиления регуляторных рисков.

Compliance как риск

Если рассматривать соответствие требованиям регуляторов с точки зрения анализа рисков, то можно провести следующее сопоставление с терминами информационной безопасности:

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

При таком подходе возникает практически беспрецедентная ситуация: появляются все необходимые исходные данные для количественного анализа рисков на основе классической методики [2], согласно которой итоговый потенциальный ущерб равняется ARO × SLE, где ARO (Annualized Rate of Occurrence) – усредненная вероятность реализации угрозы, SLE (Single Loss Expectancy) – потенциальный ущерб от единичной реализации угрозы.

В рамках нашей аналогии:

- ARO – вероятность проверки регулятором;

- SLE – прописанные регулятором последствия нарушения.

При таких допущениях можно рассмотреть «худший сценарий» рисков, связанных с ФЗ-152. В качестве угрозы могут выступать последствия, указанные в законе и подзаконных актах:

  • административная ответственность, штрафы;
  • приостановление «до устранения» или прекращение обработки персональных данных в организации и вызванный этим простой или деградация бизнес-процессов;
  • привлечение компании и (или) ее руководителя к уголовной (гражданско-правовой, административной или другой) ответственности – катастрофический риск;
  • приостановление действия или аннулирование лицензий на основной вид деятельности компании – риск, близкий к катастрофическому.

В качестве атаки выступает проверка регуляторов. Детальные расчеты обоих показателей по отраслям деятельности и регионам можно провести на основе открытых источников, таких как план и результаты проверок [3]. Учитывая, что редкая проверка заканчивается без вынесения предписания об устранении нарушений, можно констатировать увеличение риска наступления катастрофических последствий в дальнейшем. Законы против стандартов?

В большинстве своем требования стандартов не противоречат, а скорее дополняют друг друга. Однако встречаются и исключения из этого правила. Наиболее ярким пример – конфликт Федерального закона «О банках и банковской деятельности» и положений ряда стандартов о периодическом проведении аудита внешними органами. Противоречие обусловлено отсутствием легитимного способа передать третьей стороне сведения, составляющие банковскую тайну. Но в ходе аудита необходимость доступа к таким сведениям время от времени возникает. Также не стоит исключать возможности непреднамеренного ознакомления аудитора с банковской тайной.

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

Так, описанная выше коллизия разрешается с помощью распространенного аудиторского приема, в ходе которого операции доступа к данным осуществляет сотрудник банка, а анализ обезличенных результатов производится независимой стороной[4].

Выполнять невыполнимое?

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

Такие ситуации не редкость (далеко не исчерпывающий их список см. в таблице). Однако в большинстве случаев проблема рано или поздно решается путем отмены или изменения формулировки требования.

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

Обеспечение соответствия или обеспечение безопасности?

С момента появления требований регуляторов начал развиваться формальный подход к их выполнению. В настоящее время он приобретает все более и более изощренные формы. Один из интересных вариантов обхода требований безопасности получил название «отказ от соответствия» (Reverse Compliance)[5, 6]. Суть этого подхода заключается в сознательном игнорировании ряда требований, которые могут явно продемонстрировать несоответствие. Так, отказ от внедрения системы протоколирования и анализа инцидентов позволяет закрывать глаза на реальные инциденты и атаки, скрывать многие другие несоответствия и даже дает некоторые преимущества в случае реальных инцидентов.

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

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

Таким образом, система управления ИТ и ИБ может строиться на основе заслуживших доверие рекомендаций, таких как COBIT, ITIL, ISO 27001, а требования регуляторов являются исходными данными для анализа рисков, организации процессов и выбора средств защиты, описанных в методиках.

Такой подход широко распространен в мире, прежде всего из-за того, что позволяет снизить издержки на обеспечение соответствия и использовать этот процесс для повышения качества ИТ-услуг и реального уровня защищенности. Более того, библиотеки взаимного соответствия стандартов (Compliance Mapping) являются одной из стандартных возможностей автоматизированных средств класса «система контроля защищенности и соответствия стандартам». Их использование позволяет достаточно просто формулировать и поддерживать в актуальном состоянии внутренние стандарты, построенные с учетом применимых требований регуляторов, и автоматизировать контроль соответствия. 

Ссылки

  1. М. Эмм. «Защита персональных данных и требования PCI DSS», www.infosec.ru.
  2. П. Покровский. «Защита информации: анализ рисков», www.ot.ru.
  3. «Персональные данные. Правоприменение», http://community.livejournal.com/personal_data.
  4. Подробнее см. Гордейчик С.В., Гордейчик А.В., Кузнецов Д.Ю. «Юридические аспекты консалтинга в области безопасности», www.ifap.ru.
  5. D. Ingram. Logs – A double-edged sword?, http://beastorbuddha.com.
  6. A. Chuvakin. Reverse Compliance or Logs as Proof of Incompetence? http://chuvakin.blogspot.com.
или введите имя

CAPTCHA
Страницы: 1  2  
C3
22-11-2010 23:55:13
Сергей, скажите, пожалуйста, какие методы Вы предлагаете использовать для оценки вероятности проведения ( ARO ) проверок регулятором? Если исключить наличие инсайдерской (для контрольного органа) информации, а также открытость плана проверок (в силу специфики работы государственных органов, а также самой сути контрольного мероприятия в области применения стандартов - такое допущение представляется вполне реальным). Более того, на мой взгляд, весьма проблемной представляется оценка уровня вероятности даже на основе статистических данных, опять же в силу специфики проведения контрольных мероприятий уполномоченным органом.
0 |
C3
22-11-2010 23:55:48
Относительно SLE - представляется разумным допущение о том, что характер и масштаб штрафных санкций за неприменение того или иного требования будет в значительной степени зависеть от масштаба деятельности организации в конкретной отрасли, требующей применения определённых стандартов, а также потенциальных последствий неприменения стандарта, то есть зависеть от ряда факторов. То есть, подход "не применяется в операционной деятельности стандарт - штраф 100 МРОТ" - также маловероятен, так как он изначально говорит о неэффективности применения административных мер, как средства повышения эффективности применения стандарта в соответствующей сфере. На мой взгляд, штрафовать одной суммой посредника в системе электронных платежей (например, посредством банковских карт) и эмитента (в случае, если он подпадёт под требования правового акта, регламентирующего необходимость применения стандарта) - неразумно.
0 |
C3
22-11-2010 23:56:25
Также интересует Ваш ответ на следующий вопрос - как в предложенную Вами модель вписывается (или потенциально может быть вписано) понятие необходимости (эффективности) применения/неприменения стандарта с точки зрения убытков/прибыли организации в 2х случаях. Как организация, как хозяйствующий субъект, нацеленный в т. ч. и на максимизацию прибыли и минимизацию издержек сможет для себя решить - как долго времени она может не применять стандарт? Как соотнести эффект от неприменения стандарта (например, выразившийся в экономии на затратах на его внедрение в операционную деятельность) с результатом применения Вашей модели, который, если я правильно понял, можно будет привести к определённому денежному эквиваленту (вероятность*сумму штрафных санкций).
0 |
C3
22-11-2010 23:57:10
И последний вопрос - Вы пишете: При таких допущениях можно рассмотреть «худший сценарий» рисков, связанных с ФЗ-152. В качестве угрозы могут выступать последствия, указанные в законе и подзаконных актах: административная ответственность, штрафы; приостановление «до устранения» или прекращение обработки персональных данных в организации и вызванный этим простой или деградация бизнес-процессов; привлечение компании и (или) ее руководителя к уголовной (гражданско-правовой, административной или другой) ответственности – катастрофический риск; приостановление действия или аннулирование лицензий на основной вид деятельности компании – риск, близкий к катастрофическому. В данном контексте - почему административная и гражданско-правовая ответственность руководителя/самой организации оценивается Вами как катастрофический риск, если данная ответственность чаще всего не предполагает возникновения существенных ограничений для нормального функционирования организации?
0 |
Гость
23-11-2010 11:14:26
Сергей, цель статьи какая? по-моему, ты намешал всего понемногу и в итоге до конца ни одну тему не раскрыл до конца. Например, про оценку рисков: там много катастрофические последствия - это в деньгах как считать? и что теперь мы должны любые деньги выкладывать интеграторам за защиту ПДн? и название статьи соответствует именно это теме. зачем ещё что-то добавил? что хотел сказать. видимо это всё-таки всплеск мозга по более широкому исследованию.
0 |
Страницы: 1  2