вторник, 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

вторник, 12 августа 2014 г.

PCI DSS - Information Supplement: Third-Party Security Assurance

PCI Council опубликовал документ – «Third-Party Security Assurance».  Выбор и управление взаимодействием с контрагентами (ИТ).
Документ доступен на официальном сайте.