Показаны сообщения с ярлыком compliance management. Показать все сообщения
Показаны сообщения с ярлыком compliance management. Показать все сообщения

суббота, 2 апреля 2011 г.

Опрос экспертов по регулированию в сфере безопасности

Опубликован в CIO под громким названием "Безопасность и закон".

Ваш покорный слуга тоже что-то ляпнул авторитетно прокомментировал этот актуальный вопрос.


Полный текст:

http://www.ibusiness.ru/10853

среда, 2 февраля 2011 г.

Истинная цена Compliance

Цитата

Расходы организаций, не соблюдающих правила информационной безопасности, в среднем превышают расходы организаций, их соблюдающих, в 2,65 раза, подсчитали аналитики из Ponemon Institute.

http://hitech.newsru.com/article/02feb2011/moresafe

http://www.tripwire.com/ponemon-cost-of-compliance/pressKit/True_Cost_of_Compliance_Report.pdf

Смело заявление. Надо покурить методику.


четверг, 9 декабря 2010 г.

Shared Personal Data

Две новости с минимальным разрывом. Очень забавно вышло. 


Операторы персональных данных вновь получили отсрочку

Законопроект "О внесении изменений в статью 25 Федерального закона "О персональных данных" (в части продления срока приведения ранее созданных информационных систем персональных данных в соответствие с требованиями Федерального закона "О персональных данных") принят Госдумой в первом чтении.

http://www.securitylab.ru/news/400089.php 



Россия: Сотовый оператор выложил в Сеть персональные данные абонентов



Дальневосточный оператор БИТ допустил утечку документов, в результате которой около года в открытом доступе находились персональные данные его 11 тыс. клиентов, а также данные о его обмене трафиком с другими операторами региона.

http://safe.cnews.ru/news/top/index.shtml?2010/12/09/419487 


В последнем особенно позабавило

"Факт утечки был обнаружен экспертом по информационной безопасности Ильей Шабановым 8 декабря 2010 г. в результате регулярного мониторинга Сети. "

и

"Изучение документов, выложенных на ftp-сервере, позволило CNews ознакомиться с отчетностью, содержащей персональные данные более чем 11 тыс. абонентов БИТ."

Интересно, на каком основании Cnews осуществляет несанкционированный доступ к охраняемой законом информации и так спокойно об этом рассказывает. Или что-то изменилось у нас в законодательстве? Тот факт, что информация лежит на "открытом ftp" ничего не меняет. 

И в конце, пользуюсь служебным положением, процитирую Дмитрия Кузнецова.


Как Вы расцениваете эффективность обсуждаемой сейчас очередной отсрочки (на полгода) вступления в силу требований к информационным системам, созданным до 2006 года? Действительно ли это позволит кому-то решить проблемы или же просто на полгода оттянет неизбежное?


В отличие от предыдущей отсрочки, данная отсрочка имеет исключительно технический характер. Сейчас Госдума готовится к рассмотрению во втором чтении законопроекта № 282499-5, который внесет очень существенные поправки в действующую редакцию, в том числе – в порядок государственного регулирования защиты персональных данных. Поэтому перенос сроков – ожидаемая мера, которая позволит операторам дождаться принятия этих поправок.

Если говорить о переносе сроков (особенно – прошлогоднем) как об “оттягивании неизбежного”, то такая постановка вопроса несправедлива ни по отношению к законодателю, ни по отношению к операторам. Скорее этот перенос свидетельствует о способности органов государственной власти не только совершать ошибки, но и признавать их. В августе 2007 г. Правительство выпустило распоряжение № 1055-р, поручив ФСБ и ФСТЭК в течение шести месяцев разработать требования по защите персональных данных. Таким образом, предполагалось, что с момента принятия требований у операторов будет два года на их выполнение. Впрочем, невыполнимость подобного распоряжения уже тогда была понятна специалистам, и дальнейшие события это подтвердили. Первые версии документов, выпущенные ведомствами, вызвали резкую критику со стороны профессионального сообщества и фактически так и не были введены в действие. Так что первый перенос сроков отчасти был вызван фактическим отсутствием на тот момент требований, которые должны были бы быть выполнены операторами. Действующие требования ФСТЭК появились только в феврале 2010 г., а требования по криптографической защите персональных данных не введены в действие и по сей день.

В настоящий момент всем хорошо понятно, что разработать единые требования для всех отраслей невозможно, и события развиваются по пути инициативной разработки отраслевых требований самими операторами (отраслевой стандарт Банка России, отраслевой стандарт операторов связи, ведомственные документы Минздравсоцразвитьия и т.п.). Есть надежда, что эта практика будет закреплена законодательно, и это позволит сдвинуть дело с мертвой точки.



Какую часть рисков, связанных с выполнением требований законодательства о ПДн, позволяют решить продукты и услуги Вашей компании, а какую часть работ заказчику неизбежно нужно решать самостоятельно?


В приказе ФСТЭК №58 от 05.02.2010, регулирующем методы защиты персональных данных, появилось одно важное на наш взгляд нововведение: оператор должен построить систему защиты персональных данных, но и контролировать ее, своевременно выявляя и устраняя недостатки в обеспечении безопасности, уязвимости, ошибки в конфигурации, которые неизбежно возникают в ходе эксплуатации любой информационной системы. Система контроля защищенности и соответствия стандартам MaxPatrol, разработанная нашей компанией и уже внедренная многими организациями, позволяет оператору самостоятельно реализовать и автоматизировать такой контроль для информационных систем любой сложности и любой территориальной распределенности с минимальными затратами человеческих ресурсов.

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

Кроме того, ЗАО «Позитив Текнолоджиз» оказывает услуги по анализу защищенности информационных систем, помогая компаниям выявлять и устранять недостатки, которые могут использоваться злоумышленником для несанкционированного доступа к информационным системам. Эти услуги востребованы кредитными организациями, операторами связи, промышленными предприятиями и другими организациями, в деятельности которых информационные системы играют ключевую роль.


Испытываете ли Вы как поставщик услуг в сфере информационной безопасности какие-либо сложности и затруднения в связи с действующим законодательством в сфере ПДн (проблемы компаний - операторов ПДн понятны)? Если да, то в чем они проявляются?


Напротив, на сегодняшний день мы наблюдаем повышеный интерес компаний к вопросам информационной безопасности. Причем, если несолько лет назад одним из мотивов было соответствие формальным требованиям (будь то требования государственных регуляторов, ISO 27001 или PCI DSS), то сегодня на первое место ставятся имено практические аспекты защиты от фактически используемых методов атак. Складывается ощущение, что постоянно муссируемая тема защиты персональных данных заставляет руководство компаний задуматься над вопросами безопасности и более трезво оценивать готовность своих компаний к современным вызовам. И это не может не радовать.

понедельник, 22 ноября 2010 г.

Compliance как угроза

Статья "Compliance как угроза", опубликована в ИКС  ИКС № 9 2010.

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

http://www.securitylab.ru/analytics/399689.php

вторник, 2 ноября 2010 г.

PCI DSS 2.0

Опубликованы неплохие обзоры нововведений PCI DSS 2.0 и PA DSS 2.0.

http://pcidss.ru/articles/22.html

https://www.pcisecuritystandards.org/pdfs/summary_of_changes_highlights.pdf

Сам стандарт:

https://www.pcisecuritystandards.org/documents/pci_dss_v2.pdf

В целом ничего революционного, работа над ошибками.

понедельник, 6 сентября 2010 г.

четверг, 5 августа 2010 г.

Обзор инцидентов: Verizon Breach Report 2010

Опубликован обзор инцидентов Verizon Breach Report 2010. Рекомендую.


http://www.verizonbusiness.com/go/2010databreachreport/



PS. В отчете широко используется WASC WATCv2. Приятно. 



PPS. Без комментариев:

понедельник, 5 июля 2010 г.

Compliance & Risks

Недавно компелировл в презентацию поток мыслей по управлению рисками.
Возможно кому-то пригодиться.

среда, 16 декабря 2009 г.

ПД умерли?! Да здравствуют ПД!

Не мог обойти вниманием перенос "приведения в соответствие" 152-ФЗ на год.

http://www.securitylab.ru/news/388888.php

С точки зрения маркетинга - неплохой способ "освежить тему" :)
Кстати, кто-то в знает, как там Visa? Все еще "переносит"?

четверг, 19 ноября 2009 г.

Юридические аспекты консалтинга в области ИБ

Опубликовал презентацию доклада «Всех аудиторов «посодют»?! Юридические аспекты консалтинга в области ИБ»:

http://www.ptsecurity.ru/news_page.asp?id=75

Обратная связь приветствуется.

четверг, 15 октября 2009 г.

PCI DSS и беспроводные сети

В очередной раз воник вопрос о PCI DSS и беспроводных сетях

http://www.securityfocus.com/archive/137/507096

But how can we determine if this rogue AP and especially rogue wireless
clients (WLAN card into a back office server)
are inside CDE? By signal level? But Kismet shows this information only
for APs (not for clients) :(


Я уже отвечал на этот вопрос на сайте информзащиты, повторюсь.


>как узнать, что беспроводная точка с включенным шифрованием принадлежит к нашей локальной сети?


Принадлежность точки может вычисляться различными способами. Самый простой - по трафику, "летающему" в воздухе. Даже есть точка использует нормальное шифрование (не WEP), то в открытом виде передается достаточное количество информации для идентификации сегмента. Например - mac адреса отправителя. Поскольку точка доступа является устройством канального уровня, она будет ретранслировать все широковещательные запросы сегмента "в воздух". А поскольку в сети таких запросов достаточно много (ARP, NetBIOS, IPv6 и т.д.), то сравнив MAC-адреса отправителей пакетов через точку со списком известных MAC-адресов своей сети можно легко идентифицировать место, куда включена точка. Дополнительно можно спровоцировать отправку большого количества широковещательных пакетов в сегменте с помощью утилит, реализующих ARP-ping, таких как Cain или nmap. А бегать с антенной за каждым beacon - задача не для слабонервных.

>А где можно почитать про технологию поиска точек методом
>триангуляции и какую лучше антенну использовать?


Параболические или Yagi антенны для диапазона 2,4 достаточно громоздки, в связи с чем комфортней использовать панельные варианты, не смотря на меньшую направленность и чувствительность к отраженному сигналу.

http://www.wifilab.ru/catalogue/catalogue.php?cat_id=51

Крайне рекомендую мою книгу ;)

http://www.techbook.ru/gordejchik.html


>А если это действительно правильно сконфигурированая точка WPA2+hidden+MAC
> filter. Долго придется искать пока не будет активности.


Такая точка подключенная к сети все равно "фонит":
- рассылает beacon (пусть и с пустыми ESSID)
- транслирует broadcasts и multicast с Mac-адресами источника в открытом виде

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

>Определение клиентов, подключающимся к внешним точкам доступа

Клиентов, санкционировано подключающихся к "внешним" точкам доступа можно определять с помощью активных средств оценки защищенности. Например в MaxPatrol есть три механизма, позволяющие решать эту задачу: - инвентаризация, в рамках которой анализируются настройки беспроводных клиентов Windows - оценка защищенности, в рамка которой проводится анализ небезопасных конфигураций (например, multihomed, отсутствие шифрование, использование WEP) - контроль соответствия (compliance), позволяющий указывать черные и белые списки точек доступа, разрешенных в сети.

Путем мониторинга беспроводной сети, но для этого надо предварительно составить список "своих" MAC-адресов. Можно это сделать активными средствами (см выше) или пассивными (см. ниже).

>Как понять, твои ли это пользователи?


Немного об этом писал здесь.

Но в любом случае, рабочая станция (особенно под управлением Windows) рассылает очень много интересного трафика, по которому можно определить принадлежность к сети. Это и NetBIOS Broadcast и запросы WPAD и DHCP-запросы в которых передается имя узла и домена...

Остается открытым вопрос - как спровоцировать на отправку данного трафика? Тут нам на помощь приходит Gnivirdraw.

>Активные сканеры нам не помогут!!!

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

- инвентаризация (fingerprint) в режиме pentest сетевых устройств (в том числе и AP).
- инвентаризация настроек беспроводных клиентов (MAC-адресов, списков сетей)
- анализ конфигурации точек доступа
- анализ журналов беспроводных устройств с точки зрения "нехороших" событий

четверг, 25 июня 2009 г.

Сколько людей, столько мнений. Аудиторы PCI о хранении PAN

Практически одновременно запущенно два сайта по PCI DSS: один от Информзащиты и второй от Digital Security.

Интересным оказалось наличие у аудиторов двух диаметрально противоположных взглядов на хранение PAN.
Если Digital Security достаточно категорично выступает против хранения PAN в открытом виде и предлагает использовать их хэш-значения, то Информзащита не видит ничего противоречащего требованиям PCI в хранении PAN в открытом виде в почтовых ящиках пользователей.

Цитировать и вырывать из контекста не хочу, лучше посмотреть оригинальные обсуждения.

понедельник, 22 июня 2009 г.

Secret, Sex, Love, God? Нет, 1234567!

Опубликован подготовленный Дмитрием Евтеевым обзор наиболее распостраненных нарушений парольной политики в российских компаниях.
Как показано в публикации, статистика используемых паролей российских пользователей значительно отличается от данных западных исследований. Так, список наиболее распространенных паролей включает только фразы, составленные из расположенных рядом символов, таких как 1234567 и qwerty, тогда как западные пользователь больше склонны использовать слова английского языка (password, love и т.д.). Более 50% используемых паролей состоят только из цифр, что крайне негативно сказывается на их стойкости.
Требования PCI DSS нарушаются в 74 случаях из 100, а администраторы более склонны к использованию пустых паролей чем обычные пользователи.

Полный текст исследования:
http://www.ptsecurity.ru/download/PT-Metrics-Passwords-2009.pdf

Другие исследования Positive Technologies:
http://www.ptsecurity.ru/analytics.asp

воскресенье, 24 мая 2009 г.

Отчет о PCI Moscow

В четверг закончилась конференция PCI Moscow. Не смотря на узкую специфику мероприятие оказалось достаточно интересным и хорошо организованным.
Из запомнившихся докладов:

"Безопасность банкоматов. Опыт борьбы с кибер-преступниками."
Иван Стригин, Системный инженер, Московское представительство компании «Диболд, Инк»



"Стандарты PCI DSS и СТО БР ИББС 1.0. Сходства и отличия"
Павел Гениевский, Секретарь Совета Сообщества ABISS


Иван раскрыл timeline "борьбы" со злобным вирусом, занимавшимся кражей данных пластиковых карт из банкоматов. И выразил неодобрение отсутствием координации разглашения со стороны антивирусных вендоров. Теперь не только исследователи уязвимостей стоят на тонком льду Full-Disclosure :)). Что хуже - антивирусных вендоров подталкивает мощная маркетинговая машина.

Организаторы обещают опубликовать материалы и презентации на сайте в течении недели.

Мой доклад - "Измеряя защищенность. Метрики безопасности для PCI DSS" ниже.


четверг, 14 мая 2009 г.

Compliance как угроза. Анализируем риски #2

В ходе обсуждения пришла в голову мысль.


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

Кстати, еще нет данных по эффективности контр-мер. Иметь бы источник (открытый), кто из интеграторов делал проекты ЗПД для компаний и коррелировать это с последствиями проверок :)))

среда, 13 мая 2009 г.

Compliance как угроза. Анализируем риски

Если рассматривать вопрос соответствия требованиям с точки зрения анализа рисков, т.е. принимать:

угроза - прописанные регулятором последствия нарушения
уязвимость - несоблюдение требований
атака - проверка регулятора
контрмера - соблюдение требований

возникает практически беспрецедентная ситуация - у нас присутствую все необходимые исходные данные для проведения количественного анализа рисков на основе классической методики ARO x SLE = ALE.

http://www.windowsecurity.com/articles/Risk_Assessment_and_Threat_Identification.html

У нас есть:

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

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

И так, рассмотрим пару примеров, которые сейчас "на слуху" - ФЗ 152 (ЗПД) и PCI DSS.

PCI DSS

Здесь все довольно просто, потому как в связи с известными событиями в мировой экономике Visa и другие платежные системы решили "не кошмарить бизнес", и, в большинстве случаев позволяют сдвигать action plan. Это дает отсрочку в реализации атаки в несколько лет. Беспрецедентная ситуация, когда вы точно знаете, что данная конкретная атака не произойдет в течение года. Или двух. Представьте себе индульгенцию от вирусных атак или кражи оборудования сроком на год... Великолепная штука.


Итак:

угроза - штраф (N децикило $) или ущерб от запрета операций (пусть для простоты будет тоже N децикило $), SLE
уязвимость - несоблюдение требований (PCI DSS)
атака - реакция регулятора на отступление от action plan (вероятность наступления, ALE - 0 раз в год)

Итого, получаем:

Риск = (N децикило $) x (0) = 0

Т.е. можно ничего не делать!!!

Но! Ключевым условием является наличие action plan. Соответственно надо его сформировать. Самому, или с помощью QSA - по желанию. К сожалению, у меня нет информации о реакции регуляторов на отсутствие action plan по PCI DSS, но думаю, что SLE в этом случае будет на уровень стоимости контрмеры (аудита).

ФЗ 152

Тут все просто.

угроза - несколько вариантов

1. Административная ответственность - штрафы
2. Приостановление или прекращение обработки персональных данных в компании - время простоя/деградации связанных бизнес-процессов "до устранения". Думаю, можно смело взять минимум 1/6 года.
3. Привлечение компании и (или) ее руководителя к уголовной (гражданской, дисциплинарной и иным видам ответственности) - катастрофический риск.
4. Приостановление действия или аннулирование лицензий на основной вид деятельности компании - в текущей ситуации ближе к катастрофическому.


атака - проверка регулятора

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

http://community.livejournal.com/personal_data/721.html

Итого, получаем:

Риск = (стоимость бизнеса) x (1) = (стоимость бизнеса)

Т.е. проблема есть и ее надо решать.

PS. Не надо делать далеко идущие выводов. Просто анекдот.

вторник, 12 мая 2009 г.

PCI Moscow - Обеспечивая безопасность данных платежных карт в России


21 мая пригласили поучаствовать в "франшизе" международной конференции по безопасности платежных карт PCI Moscow

http://www.pci-portal.com/lang-ru/events/event-info/pcimoscow/agenda

Доклад будет посвящен метрикам безопасности в контексте PCI DSS. Планирую поделиться нашими наработками в этой области и международным передовым опытом. Тезисы ниже:

Измеряя защищенность. Метрики безопасности для PCI DSS


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


PS. Как ни печально, практически не слышал интересных выступлений на тему PCI. Все в основном сводится к "пугалам", или пересказу основных требований стандарта. Хотя есть и редкие исключения. Например, доклад Максима Эмма по наиболее распространенным нарушением.

среда, 22 апреля 2009 г.

ЗПД всех устал

http://cnews.ru/news/top/index.shtml?2009/04/22/345142

Российские банки просят Роскомнадзор перенести сроки аудита информационных систем персональных данных на соответствие закону 152-ФЗ. На проверки нет ни денег, ни времени, утверждают они; кроме того, в законе имеются некоторые противоречия. Игроки рынка инфобезопасности, в свою очередь, предупреждают, что на фоне законодательного хаоса отсрочка не решит проблему, а лишь отодвинет ее на неопределенный срок.

Понятно, что "регулируемым" (в основном банкам) вся эта беготня с ЗПД в текущей ситуации совершенно не вовремя, а интеграторам и производителям очень даже наоборот.
Думаю, что идея "отложить" имеет право на жизнь. Только откладывать надо не аудиты, а карательные меры. Аудиты пускай как-раз идут. Наработается методика, компенсационные контроли и т.д., может и требования нормальные сформируются.
Как делает PCI Security Standards Council с PCI DSS - требования вводят очень осторожно, давая достаточно времени на подготовку и аудиторам и производителям СЗ и интеграторам и "регулируемым". И это при том, технологическая и методическая обвязка PCI DSS на две головы выше чем ЗПД, взять хотя бы пресловутое "четырехкнижие".

вторник, 24 марта 2009 г.

CSO Summit II

Закончился Russian CSO Summit II (Второй Съезд директоров по информационной безопасности) http://www.cso-summit.ru/.
В этом году визуально было меньше участников. Видимо, сказалось пересечение по времени с другими меропрятиями.

В целом были все прошло достаточно динамично, с присущими этому меропрятию баталиями и спорами. В узком кругу коллег CSO и CIO явно чуствуют себя свободнее и не стесняются поднимать острые и щекотливые темы.

Презентации участников:
http://www.cso-summit.ru/?page=program


В рамках дискуссии «Реальная» и «бумажная» безопасность: как найти золотую середину? делал доклад по теме Compliance Management. Живой отклик вызвала "страшилочная" часть, в ходе которой комментировалась "почти реальная история pentest'а некой компании".



Из зала прозвучал достаточно типичный комментарий "Мы тоже делаем пентесты, и они успешны на 100% (99%, 83,463%)"

Зачастую такую фразу можно услышать на выступлениях или в кулуарах. Если понимать под "успехом” пентеста непосредственно "взлом", то тогда в качестве достоверной может быть выбрана любая из приведенных цифр. Но при такой постановке задачи гораздо проще воспользоваться ”сервисом" Брюса Шнаера, предлагающего любому желающему бесплатный пентест: "Вы уязвимы"... Если измерять пользу услуги, то она должна отталкиваться от того, что она принесла заказчику. Например, было продемострированно (не)соответсвие требованиям стандартов, внедрены Web Application Firewall, запущенна программа повышения осведомленности в вопросах ИБ, достигнуто понимание между ИТ и ИБ подразделением. Только в этом случае пентест может считаться действительно успешным.

Планирую подробнее обсудить эту тему в рамках Рускрипто:
http://www.securitylab.ru/news/370275.php

четверг, 18 декабря 2008 г.

Анализ рисков. Web-приложения

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

Статья Оценка рисков использования Web-приложений касается этой проблемы в контексте Web-приложений.
Полагаю, что собранные в ней данные и источники будут полезны для широкого круго специалистов.