среда, 30 мая 2018 г.

GDPR продолжается

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

Особо "порадовало" маркетинговое письмо с предложением помочь в выполнении требований GDPR, которое было выслано сегодня 30 мая (после того как 25 мая GDPR вступил в силу) на мою личную почту, явно без моего согласия на получение таких материалов компанией ХХХ (долго думал стоит ли давать ссылку на сайт компании, и пока решил не писать. Если бы ошиблась любая другая компания, я бы не придал значения - но тут предлагают консалтинг по  GDPR! Если в течении недели представителями компании будут предоставлены сертификаты и объяснение ситуации - опубликую ниже. Если нет - опубликую ссылку и переписку с поддержкой, где я прошу выслать сертификаты и описать ситуацию детально, а мне пишут, что меня уже удалили, а какие именно сертификаты они не понимают). 
На мой вопрос как так получилось, что мне пришла маркетинговая рассылка мне сказали, что произошла ошибка и меня из базы рассылки удалили (после моего же запроса ни о чем не уведомив). Сертификаты “Системные и грамотные люди, прошедшие сертификацию по GDPR в Дании”, упоминаемые в рассылке, мне предоставить отказались. Сколько еще человек получили такую рассылку, к кому еще попали данные и какая экспертиза указанных специалистов по GDPR остается не выясненным. И хотя я не гражданин ЕС, очень сложно сказать насколько компания сама GDPR Compliance и есть ли у них процессы, документация и DPO (которому по идее бы задали все вопросы как только я написал бы запрос), перед тем как учить других. Не делайте так. Хуже только отправить нотификацию о соответствии GDPR всем клиентам единым письмом скопировав их почты в поле адресатов :-).  

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

Практически все компании навели порядок на фронте - баннер о куках, запрос по маркетинговым материалам, вывесили обновленную политику. Часть поработала и над договорами о передаче данных пользователей при обработке.

Теперь самое время заняться задачами внутри компании, если вы их еще не сделали:

Места хранения персональных данных, сроки и ответственные
Процессы обработки персональных данных
Процессы безопасности
Расчет рисков
Нотификация

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

Если у вас тоже есть вопросы по выполнению требований стандарта GDPR или по кейсам в части GDPR - пишите.

P.S. Как и обещал выкладываю пруф. Писал в Компанию еще раз - ни кто даже не удосужился ответить.

четверг, 26 апреля 2018 г.

Как не потерять свой бизнес из-за GDPR

Чем ближе 25 мая, тем чаще люди слышат эту пугающую аббревиатуру. Иногда ее запоминают люди, которые слов PCI DSS, BCP, DRP и прочие, знать не знали, а про DLP, SIEM и прочие термины узнавать и не планировали.  

Вчера ко мне обратился человек, у которого своя маленькая компания. Часть клиентов у них международные компании и как следствие GDPR дошел и до них.
Если договор достаточно стандартный – «В случае чего вы нам должны покрыть все расходы и предоставить любую информацию» и прочее в таком духе, то вот вопросник по процессам информационной безопасности несколько сложнее. Данное произведение на 10 листах для компании из нескольких человек, это поток абсолютно непонятных терминов и аббревиатур. Множества процессов естественно в такой компании нет и никогда небыло, документы по вопросу безопасности отсутствуют, а ни о каких системах безопасности нет и речи (помимо решетки, сигнализации и огнетушителя).

Что же делать, если вам тоже «повезло» стать счастливым обладателем данных граждан ЕС и тем более если от вас требуют не только заполнить опросник, но и соответствовать требованиям.

Первое – посмотрите стандарт: тут или тут
Даже если экспертом в данном вопросе вы становится не планируете, получите представление что это такое, зачем он нужен и каковы его требования.

Далее посмотрите в Интернет что есть по данному стандарту из рекомендаций. Некоторые из них можно найти в предыдущуй статье.
Также мне очень понравилась вот эта статья.
Теперь вы вкратце понимаете какие требования вам нужно выполнять.

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

Не стоит переживать – если у вас нет SIEM – можно смело написать, что таких систем нет. А вот то, что у вас нет банально списка мест хранения, сроков хранения, что именно хранится, кто имеет доступ к информации данных граждан ЕС – это нужно устранить. Так же желательно подготовить хотя бы базовые внутренние регуляторные документы, схожие с  политикеой информационной безопасности, регламенты работы с данными, документирование процессов обеспечения безопасности этих данных, организации непрерывности бизнеса. И внедрить как выполняемые процессы.

Также, раз вы уже занялись этим вопросом посмотрите закон Украины о персональных данных, который также должен выполняться. Вот еще небольшая статья по данной теме.

Если вам тоже сложно разобраться в особенностях соответствия GDPR, буду рад вам помочь с построением процессов и написанием документации в соответствии с требованиями GDPR. Электронная почта.

вторник, 6 февраля 2018 г.

General Data Protection Regulation (GDPR). На сколько песец белый и полярный ли он?

Последнее время я не часто пишу о чем-то, помимо вопросов связанных с PCI DSS. Но вот столкнулся с General Data Protection Regulation, который становится все ближе с приближением мая 2018 года (с 25 числа).

Я начал знакомиться с данным стандартом более года назад (он вступил в силу в мае 2016, но обязателен для выполнения с 25 мая 2018). Лично мне он показался не конкретным, слишком объемным, не очень реальным в части реализации требований и абсолютно не реальным в части их контроля.

Но время шло, вопросы поднимались, статей появлялось больше, перспектива выполнять требования документа General Data Protection Regulation (GDPR) казалась все более реальной.
Упустим исторические справки какие предыдущие документы он заменит и перейдем сразу к реализации.
Что же удалось выяснить по GDPR.
      1.       Ознакомиться можно тут
      2.       Достаточно емкий отчет о влиянии данного закона на операторов персональных данных (РФ) и переводом на русский можно посмотреть тут.
      3.       Также доступны небольшие статьи по данной тематике – 1, 2, 3, 4, 5. Рекомендую ознакомиться.

Самые проблемные места, по моему мнению.
      1.       Размытые формулировки и множественность интерпретаций. Отсутствие детализированных требований для выполнения, конкретики при реализации и открытых рекомендаций по проверке выполнения оных.
      2.       72 часа на уведомление об утечке. Слишком мало времени. Зачастую компании даже не успеют выявить факт наступления инцидента. Уведомление органов, без согласования с руководством с учетом объема штрафных санкций выглядит не реальным.
      3.       До 10 млн или 2% глобального годового оборота при нарушении одних или 20 млн и 4% для других требований. Слишком большие суммы. Нет открытых принципов расчета штрафов. Высокая вероятность банкротства бизнеса или перевода на другое юридическое лицо.
      4.       Под действие закона попадают все компании, которые обрабатывают персональные данные граждан ЕС не зависимо от регистрации, места нахождения.
      5.       Абсолютно не понятный процесс проверок соответствия. На основе жалоб, по запросу граждан ЕС, избирательно? Есть упоминания о добровольной сертификации сроком на 3 года, но судя по всему она не делит ответственность в случае инцидента и не влияет на штрафы.

Рекомендации
      1.       Подготовить документацию определяющую политику компании в сфере обработки персональных данных и более низкоуровневые документы описывающие процессы реализации.
      2.       Начинать внедрять процессы безопасности в соответствии с требованиями GDRP в комплексе с требованиями других стандартов или лучших практик ИБ (СУИБ, внедрить PDCA, взять за основу требования ISO 27… или даже PCI DSS в части процессов и документации). Наличие процессов по любому из стандартов упрощает внедрение и позволяет показать аудиторам деятельность в данном направлении.
      3.       Максимально документировать внедряемые и работающие процессы. Готовить отчетность по событиям и инцидентам.
      4.       Готовить примеры реализации требований пунктов GDPR в части документации и реализации. Готовить компенсационные меры в случае невозможности применения требований или их частичной реализации.
      5.       Посмотреть рекомендации в статьях приведенных выше.

Дополнение к пункту 1.
««Персональные данные» (personal data) – означают любую информацию, относящуюся к идентифицированному или идентифицируемому физическому лицу («субъект данных»); идентифицируемое физическое лицо является лицом, которое может быть идентифицировано прямо или косвенно, в частности, на основе идентификационной информации, такой как имя, идентификационный номер, данные о местоположении, идентификатор в интернете (онлайн- идентификатор) или посредством одного или нескольких показателей, характерных для физической, физиологической, генетической, умственной, экономической, культурной или социальной идентичности данного физического лица;
«Обработка» (processing) означает любую операцию или набор операций, которые совершаются с персональными данными или набором персональных данных, с использованием автоматизированных средств и без таковых, в числе которых сбор, запись, организация, структурирование, хранение, переработка или изменение, поиск и выборка, экспертиза, использование, раскрытие посредством передачи, рассылка или иной способ предоставления для доступа, группировка или комбинирование, отбор, стирание или уничтожение (Статья 4 Регламента GDPR).
Персональные данные должны:
– быть обработаны правомерно, справедливо и прозрачно в отношении субъекта данных («принцип законности, справедливости и прозрачности»);
– быть собраны для определенных, четких и законных целей и в дальнейшем не обрабатываться способом, несовместимым с этими целями; дальнейшая обработка данных для архивных целей, в интересах общества, научных и исторических исследований или статистических целей, не рассматривается как несовместимая с первоначальным целям («принцип целевого сбора данных»);
– быть обработаны адекватно и ограничиваться целями, для которых они обрабатываются (принцип «минимизации данных»);
– быть обработаны точно и там, где это необходимо, а также должны обновляться; должны приниматься все разумные меры для гарантии того, что персональные данные, которые являются неточными, с учетом целей, для которых они обрабатываются, будут удалены или исправлены без задержки (принцип «точности»);
 – храниться в форме, позволяющей идентифицировать субъекта данных, не дольше, чем это необходимо для целей, для которых персональные данные обрабатываются; персональные данные могут храниться в течение более длительных периодов, т.к. персональные данные могут обрабатываться только для архивных целей в интересах общества, научных или исторических исследовательских целей или для целей статистики, с учетом осуществления соответствующих технических и организационных мер («принцип ограничения хранения данных»);
– быть обработаны таким образом, чтобы обеспечить надлежащую сохранность персональных данных, включая защиту от несанкционированной или незаконной обработки и случайной потери, уничтожения или повреждения, с использованием соответствующих технических или организационных мер («принцип целостности и конфиденциальности»).
Правомерность обработки данных оценивается исходя из следующих требований и условий:
– субъект данных дал согласие на обработку его персональных данных для одного или более конкретных целей;
– обработка необходима для исполнения договора, стороной которого субъект данных является стороной или для принятия мер по просьбе субъекта данных до заключения контракта;
– обработка необходима для соблюдения соответствующих обязательств контроллера;
– обработка необходима для защиты жизненных интересов субъекта данных или другого физического лица;
– обработка необходима для выполнения определенных задач и осуществляется в общественных интересах или для исполнении функций контроллера;
– обработка необходима для законных целей и интересов регулятора третьих лиц.»

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

Если вы сталкивались с детализированными матрицами рекомендаций, требований, более низкоуровневыми документами по данному вопросу (кроме тех, на которые ссылается стандарт GDPR) или просто готовы поделиться опытом работы с данным стандартом напишите в комментариях или на почту

P.S.Начав делать врезки из стандарта решил их не плодить, чтобы данная статья все же была подготовлена скорее для дискуссии и ознакомления, чем как руководство. Если тема вызовет интерес и будут получена полезная информация по реализации и внедрению, возможно будет подготовлена более объемная статья (цикл статей) непосредственно по самому стандарту и его требованиям. Сейчас же заниматься перепечатыванием многостраничного документа вижу не целесообразным.   

понедельник, 15 января 2018 г.

Выполнение требований PCI DSS 3.2 обязательно

Хочется напомнить, что с 1 февраля 2018 года (а это уже совсем скоро) версия стандарта PCI DSS 3.2 становиться обязательной. Вероятно, большинство компаний уже прошло сертификацию по данной версии, но есть и те, кому стоит с этим вопросом поспешить.

Хотелось бы акцентировать внимание на основных изменениях, теперь уже обязательной версии стандарта PCI DSS 3.2:

- Мультифакторная аутентификация должна обеспечиваться при любом административном подключении к CDE.

- Пентесты для поставщиков услуг необходимо проводить каждые 6 месяцев или чаще.

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

- Раздел 10.8 обязывает сервис провайдеров внедрить процессы обнаружения отказов критических систем контроля ИБ с обязательным документированием таких ситуаций.

- Что касается SSL\TLS то сроки - 30.06.18. Детальная информация предоставлена на PCI Security Standards Council.

Так же рекомендую обратить внимание на требования IATA по безопасности карточных платежей с 1 марта 2018 года.

Если у вас возникли вопросы по требованиям стандарта PCI DSS 3.2 обращайтесь на почту.

понедельник, 8 января 2018 г.

Блоги умирают?

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

Желая уделить внимание последним новостям я был удивлен, что наполняются свежей информацией и функционируют всего 14 из 72. Что составляет чуть менее 20% от списка.  


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

Ну и бонусом нашел у Прозорова Андрея ссылки на новые блоги.

Персональные блоги экспертов:



Блоги и новости ИБ компаний:

Дайджесты ИБ:

Прочее:

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


Вот, например, нашел в комментариях. http://gatamanov.blogspot.ru/

четверг, 11 мая 2017 г.

Стандарт PCI DSS 3.2

С удивлением обнаружил, что не публиковал ссылку на стандарт PCI DSS 3.2. И, хотя, прошло уже больше года с момента его публикации, это не чуть не уменьшает его актуальность. Наоборот, теперь именно эта версия рекомендована к использованию. Актуальную версию стандарта PCI DSS 3.2 можно скачать на официальном ресурсе pcisecuritystandards.

Так же хочу обратить внимание, что в начале 2017 года были внесены изменения в анкеты самооценки (SAQ) PCI DSS. Эти изменения коснулись формулировок и более точной трактовки для соответствия требованиям стандарта PCI DSS 3.2.

четверг, 26 января 2017 г.

PCI Card Production and Provisioning

2017 год начался с публикации PCI Card Production and Provisioning. Документ состоит из двух частей: Physical Security Requirements и Logical Security Requirements. 
Стандарт регламентирует вопросы безопасности при изготовлении платежных карт и связанные с ним процессы.

Очень хороший обзор данного документа на русском языке написан тут

Сам документ можно найти на официальном сайте pcisecuritystandards

понедельник, 20 июня 2016 г.

PCI DSS 4.0 не будет

Судя по всему, стандарта версии PCI DSS 4.0 в ближайшем будущем не предвидится. Но предвидеться новая версия стандарта PCI DSS третей версии - PCI DSS 3.2.

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

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

Новый стандарт PCI DSS 3.2 вступит в силу с первого февраля 2018 года. Но не смотря на то, что срок действия PCI DSS 3.1 закончится 31 октября 2016 года, до первого февраля 2018 года будет длится переходный период когда могут быть использованы обе версии стандарта. 

воскресенье, 14 февраля 2016 г.

PCI DSS 4.0?

Несмотря на то, что обязательной версия PCI DSS 3.1 стала только с 2016 года, уже прошло несколько лет с даты публикации стандарта третьей версии. И самое время задуматься о подготовке следующей, 4 версии PCI DSS.

Перспективные нововведения и возможные изменения стандарта PCI DSS 4.0 рассмотрены в только что опубликованной статье.  

Будем следить за развитием новой версии стандарта PCI DSS 4.0 и ждать ноября. 

вторник, 29 декабря 2015 г.

Опыт подготовки и прохождения аудита PCI DSS 3.1

В этом месяце под моим руководством успешно завершился проект по подготовке и сертификации PCI DSS 3.1. И есть повод написать о практическом опыте несколько слов. Отличия от третей версии не столь значительные как при переходе от PCI DSS 2.0 к PCI DSS 3.0, но они есть. 

В чем же они заключаются?

1. Как и в каждой новой версии стандарта PCI DSS переопределены понятия и есть перестановки в нумерации пунктов.
2. Одним из пунктов является признание протокола SSL небезопасным и запрет его использования.
3. Так же появилось требование о наличии матрицы распределения ответственности.
4. Изменились формы отчетности RoC и AoC (актуально для аудиторов).
5. Значительно увеличилось количество собираемых подтверждений выполнения требований стандарта (копий документов, отчетности, копий экрана).

В целом, по личному опыту могу сказать, что изменения в стандарте PCI DSS 3.1 практически не повлияли на процесс подготовки компании к аудиту. Если, компания успешно прошла в прошлом году аудит по версии 3.0 (и даже по версии 2.0) каких-либо проблем у нее возникнуть не должно. Конечно в том случае, если сертифицированные процессы выполнялись на протяжении прошедшего года непрерывно, и не забывали о периодических задачах (ежедневных, еженедельных, ежеквартальных и прочих, которых требует стандарт и внутренние документы компании).

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

Со всеми изменениями в PCI DSS 3.1 вы можете ознакомиться на официальном портале PCI Council.

В случае вопросов, буду рад проконсультировать. 
Skypeviktor.davydych