В курсе по измерению эффективности ИБ я рассматриваю множество различных методов оценки эффективности ИБ. Один из них - оценка на соответствие стандарту. В качестве примера рассматривается несколько принятых в России стандартов и один из них PCI DSS. Помимо достоинств у данного метода есть и несколько недостатков. Один их них - субъективность оценки. В разные моменты времени одно и тоже требование может восприниматься по разному. Например, раньше требование наличия антивируса всеми трактовалось как установка соответствующего ПО на рабочие станции и сервера. А вот с недавних пор в число устройств, на которые надо ставить антивирус вошли и банкоматы. Что будет дальше?..
Другой недостаток метода - различие в понимание одних и тех же требований стандарта разными экспертами. В области PCI ситуация еще хуже, т.к. здесь сталкиваются не просто мнения экспертов, а мнения аккредитованных экспертов, которые, логично рассуждая, должны иметь единый взгляд и трактовку одних и тех же требований стандарта. Ан нет... В блоге Сергея Гордейчика наткнулся на интересный пример. Опять же из российской практики. Две уважаемых компании - Информзащита и Digital Security, обе имеющие статус QSA, имеют диаметрально противоположные мнения о том, можно ли хранить PAN в открытом виде. Digital Security против, а Информзащита - за. Правда, сценарии такого хранения рассматриваются разные - в одном случае речь идет о черных списках (где они хранятся не говорится), во втором - о PAN во внутренней почте. Но суть от этого не меняется - Digital Security категорична и считает, что надо либо шифровать PAN, либо хранить их хэши и не важно, где они обрабатываются - внутри или снаружи защищаемой сети. У Информзащиты иное мнение... Было. 5 июня. 1-го июля мнение поменялось. Причем тоже интересная ситуация. Информзащита, ссылаясь на PCI Council, признает свою ошибку (PAN надо шифровать даже во внутренней почте), но считает такую трактовку стандарта со стороны его разработчика и координатора некорректной ;-)
К чему мы приходим в итоге? К тому, что если для необязательного стандарта, разница в мнении эксперта/экспертов не столь критична (если, конечно, ее результатом не будет отказ от выдачи сертификата), то для стандарта, невыполнение требований которого влечет за собой штраф, такой разброс во мнениях может вести к более печальным последствиям.
Подписаться на:
Комментарии к сообщению (Atom)
10 коммент.:
это всё от того, что стандарты у нас появляются не входе обсуждения большинства заинтересованных сторон, а даются свыше, как истинное сокровенное знание.
ЗЫ. это баланда тянется минимум с 92 года как я теперь понимаю
Согласен, требования читаются по разному не просто у экспертов у регуляторов, и в разных ситуациях... но не будем об этом...
Отражу яркий пример на мой взгляд...
требования РД АС к классу 1Г...
Подсистема управления доступом:
"должна осуществляться идентификация программ, томов, каталогов, файлов, записей, полей записей по именам;"
Во времена разработки РД под "полями" и "записями" подразумевали что?! Бытует мнения о двух вариантах:
1 - это единицы хранения данных на МНЛ(эдакий шкаф-магнитофон) по аналогии с файлами.
2 - это единицы хранения данных в БД.
Теперь вопрос:
Вы стратифицируете АС... какой вариант Вам ближе, если в 1 случае МНЛ нет, а во втором реализуйте идентификацию по именам все поля и записи...
Да, проблема известная. В частных случаях решается долгими и нудными обсуждениями.
В общем - или по каждому требованию нужно официальное мнение брендов и совета PCI, или какое-то коллегиальное решение QSA.
А так - мнения разнятся от каждого аудитора к аудитору.
И это ключевая проблема для данного метода оценки ;-(
Алексей, Вы нашли ложку дегтя в бочке меда и на основании этого пытаетесь строить рассуждения, что в бочке один деготь.
Конечно, compliance audit - не панацея и не серебряная пуля. Но это много, много больше чем ничего.
На текущий момент нет, наверное, в мире IT стандарта, более детерминировнаного чем PCI и нет другой организации, поддерживающей свой стандарт и столь рьяно борящейся за повторяемость результатов аудита, нежели PCI SSC. Безусловно, никакая титаническая работа не может гарантировать стопроцентной одинаковости в трактовке требований, и ситуации, когда аудиторы по-разному понимают какое-то требование, возможны. Только для PCI это будет примерно 5 из 240 требований-процедур аудита (речь идет, конечно, именно о трактовке одних и тех же фактов). А попробуйте прикинуть аналогичные цифры для SOX или, что сейчас особенно близко России - для закона о персональных данных. Вы видели, чтобы сотни сертифицированных аудиторов PCI месяцами спорили о том, является ли трек треком и одно ли и то же CVV2 и CVC2? Я -нет. А вот километровые обсуждения, считать ли записи видеокамеры на банкомате персональными данными, а если да, то относятся ли они к биометрическим - неоднократно :-) Кстати, повторяемость результатов аудита обеспечивается далеко не только одинаковым пониманием требований.. Еще бы проверять одинаково -было бы совсем здорово. Так что реальная ценность результатов аудита для компании не столько зависит от выбранного стандарта по безопасности, сколько от того, как это соответствие проверено. В России до сих пор для многих понятие аудит тождественно интервьюированию или рассылке анкет.
А вообще, предлагаю рассмотреть смежную тему -насколько критично в целом для рынка ИБ неправильная трактовка требований обязательных стандартов вендорами, позииционирующими свои решения на этом рынке. И раз уж из всех стандартов для аргументации своих рассуждений Вы выбрали PCI DSS, то для отправной точки рекомендую почитать трактовку требований PCI DSS от Cisco и описания того, как при помощи продуктов Cisco можно выполнить практически все требования PCI. Например, здесь:
http://www.cisco.com/en/US/solutions/collateral/ns340/ns394/ns171/ns625/white_paper_c11-519489.html
Я бы с удовольствием послушала на Вашем курсе о том, как именно можно как при помощи системы мониторинга событий ИБ, генерируемых другими устройствами и ресурсами (SIM в общепринятой терминологии), можно выполнить требование по шифрованию данных платежных карт при передаче (4.1) или разорвать неактивную сессию oracle к БД, в которой лежат данные платежных карт (8.5.15) и про все остальное - тоже :-) Может, одна из причин низкого уровня ИБ в отсутствии какой-либо оценки эффективности внедренных средств защиты?
Anna: Анна, вы не совсем правильно трактуете мой пост. Я не обвиняю и не ругаю PCI DSS ;-) И в самом начале поста я пишу, что в своем курсе я рассматриваю РАЗНЫЕ методы оценки эффективности ИБ, среди которых есть и оценка на соответствие стандартам. И что у каждого метода есть своя область применения, свои плюсы и минусы. Плюсы рассматривать неинтересно - для этого есть ваш pcisecurity.ru и pcidss.ru Ильи. Но и другую сторону медали тоже полезно знать.
Теперь что касается Cisco и PCI DSS. Если говорить в целом о Cisco, то мы на этой поляне работаем не первый год. Еще когда PCI DSS не было, мы были включены MasterCard'ом в их список а-ля QSA. Потом мы заключили соглашения с CyberTrust и наши рекомендации проверены им и вполне соответствуют пониманию разработчиков стандарта и его аккредитованных аудиторов. То что есть аудиторы, которые несогласны с этим всего лишь доказывает то, о чем написано в посте. Сколько аудиторов, столько и мнений.
Что касается 4.1 и MARS, то в дрокументе же написано, что шифровать данные мы можем с помощью наших VPN-технологий, а MARS мониторит эту деятельность. С 8.5.15 ситуация аналогичная. С помощью ACS или EPM мы можем выполнить это требование, а с помощью MARS его мониторить. Не надо же буквально воспринимать "выполнение требований". Мы не все требования выполняем, а те, которые можем выполнить.
Что касается оценки эффективности средств, то такие методы тоже есть. Как качественные, так и количественные. Просто не каждый вендор к своим продуктам прикладывает метрики оценки их эффективности ;-(
Алексей, в том-то и дело, что "помощь в контроле выполнения требования" и "выполнение требования" совсем не одно и то же. Думаю, что здесь нет разногласий ни у кого - зря Вы пытаетесь все противопоставить нас и уважаемый Dsec. И я достаточно читаю/понимаю по-русски и по-английски, чтобы отличить эти две формулировки. И компании, от которых требуют регуляторы выполнения этих требований, понимают слова тоже вполне буквально. И очень может быть, что если бы им честно вендоры сказали, что трата N рублей/долларов(которое много больше M) никак не приблизит их к выполнению требований, а, возможно, поможет своевременно выявить факт его нарушения, они бы подумали, тратить ли на него такие деньги? Кстати, я все же имела достаточно прямое отношение к внедрению систем типа MARS и, пожалуйста, ближе к реальности, все же по каким сообщениям каких устройств можно на консоли MARS-а увидеть, что трафик от конкретного банкомата по открытой сети сейчас не шифруется нарушение 4.1) - для простоты пускай VPN построен на базе cisco? Аналогично, принимая на веру Ваше объяснение, что по всем требованиям, которые приведены как адресуемые при помощи MARS, просто "не совсем точная формулировка, не выполняем, а помогаем проверить выполняется ли оно", по каким сообщениям на консоли MARS можно понять, что сессии в Oracle не разрываются по истечении 15 минут неактивности, или вообще не разрываются или разрываются не для всех профилей пользователей (нарушение 8.5.15)?
Anna: Боюсь, что сказать, выполнено требование или нет, может только аудитор ;-) И для этого совершенно необязательно вообще использовать средства защиты. Да и вообще что-то делать ;-( И все это прекрасно понимают. Но это лирика ;-)
Что касается MARS и VPN, то он может принять сигнал о инициации и завершении VPN-сессии, а все остальное делается написанием соответствующего правила.
Что касается Oracle, то фиг его знает ;-) Я с ним не работал, чтобы говорить, как это сделано. Если такое требование есть и его можно проверить технически, то сигнал о выполнении/невыполнении можно передать на MARS. В Штатах у нас такие проекты вместе с Cybertrust'ом были.
Странно другое. То, что обычные, по сути доморощенные, best practices все называют СТАНДАРТОМ. Стандартом чего? Как надо делать? Так если делать так, как написано, то первое - это нельзя применять этот самый стандарт в 98% случаев, потому что он узко специализирован и предназначен для использования в весьма строгих, почти доверительных условиях функционирования.
Мне кажется, что попытка QSA опираться на _любой_ (не только PCI DSS) стандарт и слепо следовать его "букве" - это еще одна попытка "to enumerate badness". Думается, что успеха не будет. Ранним свидетельством этого являются организации, которые уже осуществили внедрение, а затем получили undetected intrusion... и complain, complain, complain...
Роман, если бы QSA слепо следовал "букве" то никакой речи о субъективизме бы не было. Как раз важно следовать "духу", понимать цель применения каждого из требований и уметь находить другие пути снижения тех же рисков. Слава Б-гу, PCI DSS имеет вполне легитимный механизм применения компенсационных мер. Если говорить конкретно о PCI, то его "best practices" не из воздуха придуманы, там нет ни одного откровения -обычные всем давно известные меры, каждому из требований можно сопоставить ISO или COBIT. А на тему успеха -возвращаемся к исходной постановке вопроса. Мир не черно-белый. Никто никогда не говорил, что выполнение этого свода требований есть гарантия безопасности. О гарантиях вообще как-то смешно говорить, но риск снижен до приемлемого для МПС уровня(они сами определили, что для них есть "приемлемый"). И на текущий момент статистика упрямо подтверждает, что можно сколько угодно смеяться над требованиями "сменить пароли по умолчанию", только на практике они по-прежнему не изменены, как это ни прискорбно. Посмотрите последний отчет Verizone по итогам расследований реальных компрометаций (http://www.verizonbusiness.com/resources/security/reports/2009_databreach_rp.pdf)- основная часть атак реализована "дедовскими" способами. При этом все давно уже согласились с тем, что главным двигателем в мире ИБ являются регуляторы ибо кто же своими руками будет тратить бюджеты на снижение ПОТЕНЦИАЛЬНЫХ рисков ИБ (риски то потенциальные, а вот траты очень даже реальные). Так что все же некоторая очевидная польза в применении стандартов есть. Еще бы разумно к этому вопросу подходить всем регуляторам :-))
Отправить комментарий