Compliance как угроза

Compliance как угроза

Соответствие требованиям регуляторов – одна из основных прикладных задач обеспечения безопасности компаний и организаций различных отраслей и масштабов. Несмотря на тенденцию усиления регуляторных рисков, процесс 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.

Цифровые следы - ваша слабость, и хакеры это знают.

Подпишитесь и узнайте, как их замести!