Gdpr

В данной статье я хотел бы затронуть тему применения требований стандартов безопасности при разработке ПО.

Основной материал подготовлен и составлен на основе требований стандарта PCI DSS. Данные требования также могут быть применены к обработке и хранению персональных данных в части выполнения требований GDPR.

Мой 12 летний опыт подготовки и успешного прохождения аудитов в разных странах мира показывает, что многие компании, которые занимаются разработкой ПО имеют системы и решения собственной разработки, которые обрабатывают карточные (и персональные) данные. А со стороны PCI Council есть даже отдельный стандарт PA DSS, который регламентирует требования к тиражируемому программному обеспечению. Вот только, большинство компаний в моей практике, будь то США, Британия или Китай, которые проходили аудит PCI DSS, не имели планов по тиражированию и продаже ПО. Более того, компании специально вносят ряд изменений в ПО используемое в рамках определенного проекта, чтобы не проходить аудит PA DSS, если это ПО внедряется на заказ. Потому не всегда выполнение требований стандарта и прохождение сертификации желанно и оправдано, а в данной статье приведены именно упомянутые стандарты, а не требования PA DSS.

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

Итак, давайте перейдем к детализации и описанию требований.

Общие разделы стандарта PCI DSS.

Требования PCI DSS (на основе требований PCI DSS 3.2.1)

1. Минимизировать места и сроки хранения критичных данных. В контексте данной публикации критичные данные это данные, безопасность которых регламентируется требованиями PCI DSS + GDPR (карточные и персональные данные).

Нужныли таковые данные впринципе или ихможно анонимизировать? Действительноли необходимо хранить критичные данные втаком объеме? Можноли избежать дублирования данных икак обеспечить ихминимизацию?

Кроме того, врамках проектирования архитектуры решения иеереализации требуется учесть вкаких базах данных (таблицах), местах файловой системы, архивах ипр. будут сохранены критичные данные. Каким образом эти данные могут быть удалены. Атакже перешифрованы при смене ключей шифрования. Учесть увеличение нагрузки наБД вслучае выполнение поиска позашифрованным данным. Как добиться максимальной производительности системы, при обработке минимально необходимого количества критичных данных.

2. Критичные данные в базах данных, рекомендовано хранить в зашифрованном виде.

Критичные данные должны хранится в зашифрованном виде. Достаточно шифрования средствами базы данных (или файловой системы). Но значительно более безопасно использовать дополнительное шифрование в рамках передачи данных и последующего помещения в БД данных в зашифрованном виде. В этом случае требуется определить стойкий алгоритм шифрования, предусмотреть возможность перешифрования данных при смене ключа, а также безопасный метод хранения или формирования ключа.

3. Клиентские сетевые потоки данных должны передаваться в зашифрованном виде.

Критичные данные должны передаваться по шифрованному каналу. Сетевые критичные данные должны передаваться по шифрованному каналу. Формально достаточно использование протокола безопасности TLS, но лучше обеспечить шифрование передаваемой информации на уровне ПО.

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

4. Если собираются фото платежных карт, они должны соответствовать требованиям безопасности.

Сбор пользовательских данных для процессов верификации, часто подразумевает сбор графических материалов с изображением платежных карт, на которых могут быть указаны карточные данные (PAN, CVV). Простое решение - это удалять такие данные из систем и просить клиента самостоятельно повторно предоставлять фото копии требуемогоформата. Следующий вариант - самостоятельно удалять критичные данные и сохранять фото без таковых. Еще более интересный вариант - это самописные или купленные сервисы распознавания и замыливания Cvv и номера карт на графических изображениях.

5. Базы данных должны размещаться в отдельной подсети от подсети приложений.

Для уменьшения рисков утечки критичных данных, БД должны размещаться отдельно от подсети, в которой размещены приложения.Учитывая повсеместную виртуализацию, рекомендуется также рассмотреть возможность дополнительного разделения БД и приложений.

6. Все тестовые параметры при переводе в эксплуатацию должны быть удалены.

Зачастую в рамках интеграции используются боевые аутентификационные данные. Что несет риски их компрометации. Рекомендуется использование тестовых данных, при переводе в среду эксплуатации, таковые данные должны быть изменены или удалены.

7. Требуется использовать защищенные технологии и стойкие алгоритмы шифрования.

Не все алгоритмы шифрования считаются стойкими.

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

8. Запрещено хранить пользовательские пароли, только хеш (результат выполнения однонаправленного преобразования над паролем).

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

9. Проверка на OWASP TOP 10.

Необходимо проверять решение на основные уязвимости безопасности перед передачей его в эксплуатацию. Сам данный пункт достоин не то что одной, а целой серии статей от процесса проверок внутри Компании до внедрения систем Bug Bounty. Для начала рекомендуется проверять хотя бы на OWASP TOP 10.

10. Использование персонифицированных учетных записей.

Будьте аккуратны и внимательны с использованием групповых учетных записей в ПО как на этапе тестирования так и при переводе системы в промышленную эксплуатацию. Это сильно затрудняет процессы расследования, мешает разделению полномочий и не ведет ни к чему хорошему.

11. Логирование действий с возможностью перенаправления во внешние системы.

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

12. Система разграничения полномочий с минимально необходимыми правами.

В системе должна функционировать система разграничения полномочий. Такая система может базироваться на ролевой или смешанной модели доступа (матричная тоже не запрещена, но слишком сложна при поддержке и значительном количестве пользователей). Разделение ролей должно быть построено на основе матрицы разделения полномочий.

13. Шифрование безопасными ключами.

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

14. Требования к стойкости пароля.

Должны выбираться пароли которые не поддаются атаке перебором. Хранение и передача паролей должна быть обеспечена таким образом, чтобы минимизировать вероятность его компрометации (парольные хранилища, раздельное хранение и пр).

15. Пункт, который вероятно вы захотите дополнить самостоятельно

В данной статье я хочу описать основные этапы подготовки к аудиту безопасности. Чаще всего это аудит соответствия стандартам безопасности серииISO(27***) илиPCIDSS, либо выполнение требований соответствияGDPR.

Мой опыт в области информационной безопасности 12 лет. За это время мной были выполнены проекты с десятками компаний из США, Британии, Китая, России, Украины и стран Европы. Клиентами были как крупные процессинговые центры и банки, так и ИТ компании разной специализации. Результаты внедрения оценивалиPWC(Hongkong),VISA(USA),Deloitte(UKR) и успешно подтвердили соответствие требованиям, о чем можно посмотреть в рекомендательных письмах насайтеи отзывах в профилеLinkedin.

Надеюсь, что мой опыт проведения аудитов, консалтинга и курирование проектов по приведению компаний в соответствие требованиям стандартаPCIDSS,VISA&MASTERCARDSecurityпоможет мне простыми словами донести полезную информацию до читателей.

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

Итак, с чего же начинается и как проходит аудит?
Все начинается даже не с подписания договора на аудит или пред аудит. Все начинается с решения компании (чаще директора или менеджера) о необходимости прохождения аудита.

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

По-иному обстоят дела, если инициатором выступает руководитель отдела ИБ. В таком случае с высокой долей вероятности процессы так или иначе уже соответствуют требованиям стандарта. Документация подготовлена, архитектура в корне не противоречит требованиям стандарта, начальник ИБ понимает, зачем это нужно. А раз он инициирует, значит, понимает пользу для себя и для отдела. И сможет донести до подчиненных (скорее всего, уже донес) необходимость, а также найти понимание (в идеале поддержку) у отдела ИТ.

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

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

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

Если есть необходимость пройти аудит, а не построить процессы (заранее говорю, что часть требованийPCIDSSособенно в части документирования процессов тормозит работу самих бизнес-процессов). То лучше обратится к маленькому локальному игроку рынка. Аудиторы такой компании, как правило, более лояльны к формам реализации требованийPCIDSS. Если же хочется получить не только толстый отчет, но и консалтинг в рамках его проведения то однозначной рекомендации нет. Выбирайте именно аудитора. Если же нужен красивый отчет с печатью известной компании выбор очевиден, международная известная компания. Окончательный выбор только за Вами.

В рамках данной статьи не будет рассматриваться вопрос, по какой версии проводить аудит, так как стандарт развивается и его версии меняются. Сейчас актуальной версией является версияPCIDSS3.2.1 но готовится к выходу версияPCI DSS4.0.

Если не планируется привлекать профильного специалиста или консультанта на этапе подготовки, то проводить внутренний аудит придется собственными силами. Результатом аудита должен стать не отчет, а согласованный план-график устранения несоответствий (пример таблицы аудита, разделов отчета и плана графика приведен в Приложениях 1-3).

Приложение 1

Приложение 2

Приложение 3

И вот для того, чтобы получить данный план, необходимо провести детальный анализ инфраструктуры, документации, процессов и интервьюирование персонала. Выполнение данной задачи позволит понять уровень зрелости процессов компания и выявить самые большие прорехи.
Основные моменты, на которые стоит обратить внимание в рамках устранения несоответствий можно разделить на следующие:
1.Подготовка либо внесение изменений в регуляторные документы.
2.Подготовка актов, реестров, планов тестирования и иной отчетности.
3.Модернизация и внесение изменений в конфигурацию систем и ПО.
4.Проведение внутренних и внешних сетевых сканирований и обработка их результатов.
5.Проведение тестов на проникновение.
6.Проведение обучений и тестирование планов реагирования.
7.Анализ прав доступа в логических и физических системах.

Стоит быть готовым к тому, что, как и любое изменение бизнес-процессов, изменения вносимые в рамках приведения компании к соответствиюPCIDSSмогут встречать ожесточенное сопротивление со стороны руководителей отделов и остального персонала. Для нивелирования данного эффекта, рекомендую комплексный подход. А именно:
- Поддержку вашей позиции руководством и доведение его мнения до персонала.
- Выделение части времени персонала на задачиPCIDSSпо указанию руководства.
- Проведение совместных совещаний с руководителями отделов для донесения сути стандарта и предполагаемых проверок.
- Ознакомительные рассылки для персонала.
- Непрямая мотивация: сувениры по теме ИБ, конкурсы, плакаты, заставки.

Думаю, не стоит говорить, что нет компании, в которой бы абсолютно все было без нарушений. На то есть разные причины: слишком большие затраты на выполнение требований, нарушение или разрушение реальных бизнес-процессов при исполнении требований, исторически сложившиеся процессы. И тут все зависит от того, что покажут аудитору или, что он увидит или найдет. Опять-таки не стоит забывать о возможности применения компенсационных мер.
В случае отсутствия возможности привлечения профильного консультанта, при подготовке к аудиту, безусловно, необходим человек компетентный в области аудита и стандартов, или тот, кто быстро может стать таковым (специалист смежной сферы). Так как аудиторам и представителям компании крайне желательно понимать друг друга, обладать высоким уровнем компетенций в сфере, подлежащей аудиту. Когда проектом по прохождению аудита соответствия руководит не мотивированный и некомпетентный в вопросах проектного менеджмента и стандартов ИБ человек, вероятность его успешного прохождения сильно уменьшается, а сроки и бюджет проекта, наоборот увеличиваются. Исключение могут составлять случаи, когда за все уплачено заранее. Но в таком случае, наверное, даже не стоит вести сам проект.

Поговорим более детально по перечисленным ранее пунктам.

1.При разработке и редактировании документов используется очень простой принцип. Необходимо, чтобы все процессы, подлежащие документированию в рамках требованийPCIDSS, были документированы.
Из нюансов рекомендую обратить внимание, что это чревато тем, что большинство процессов так и останутся только на бумаге. Прописывая, тот или иной процесс в документах думайте, как он будет выполняться персоналом. Как это ни банально, но это действительно важно.
2.Достаточно длинный перечень ежемесячных, ежеквартальных и прочих актов должен готовиться сотрудниками компании. Если прибавить к этому актуализацию реестров, планов, анализ и обработка результатов сканирования и обработку рисков, а также документацию по реагированию на инциденты, то стопка за год, может быть толще качественной кирпичной кладки (хотя возможно, что и в электронной форме). Нужно понимать, что лучше готовить ее на протяжении года. Хотя часто ее делают непосредственно перед аудитом. Тут уже вопрос корректности процессов. В конце концов, все направлено на повышение уровня безопасности и логичнее все делать вовремя. Ведь все равно делать придется.
3.Системы требуют постоянных обновлений, изменения настроек и параметров конфигураций. Для этого необходимо иметь в штате компетентных специалистов, отслеживать частоту и правильность установки обновлений. Соответствие паспортам конфигураций. Это периодическая и очень затратная по времени часть работ. Кстати, это можно автоматизировать. Я писал об этом, когда рассматривал вопрос Построение процессов управления уязвимостями и соответствиемтут.
4.Для проведения внутренних сканирований достаточно использовать любой более-менее качественный сетевой сканер с последними обновлениями. И разворачивать целый комплекс по управлению сетевыми уязвимостями в рамках соответствияPCIDSSсовсем не обязательно.А вот что обязательно это обработка результатов сканирования. Все уязвимости, которые немогут быть устранены должны быть проанализированы. И если уязвимость обнаружена не ошибочно, для нее должны быть разработаны и внедрены компенсационные меры.
Что же касается ежеквартального сканирования внешнего периметра (ASV) то достаточно просто купить лицензию на необходимое количествоIPC28Cи проводить 4 раза в год сканирование самостоятельно. Естественно это для тех случаев, когда у Вас нет уязвимостей в сканируемой инфраструктуре. А их не должно быть.
5.C29CВ рамках подготовки к тесту на проникновение по приоритетности я бы выделил следующие особенности:
- Донесение до сотрудников компании, что можно, а чего делать нельзя.
- Контроль мест хранения карточных данных.
- Обновление систем.
Именно в этой последовательности, как правило, возникают проблемы в рамках теста на проникновение.
6.C30CОбучение сотрудников является неотъемлемой частью улучшения безопасности. Но вот если у вас не все процессы, прописанные на бумаге, работают в действительности, то это как раз возможность рассказать сотрудникам кому и как они должны отвечать на вопросы. Чтобы в рамках интервьюирования сотрудников не выяснилось, что далеко не все процессы, отраженные на бумаге, используются в действительности.
Что касается планов реагирования, то если за текущий отчетный период они применялись нужно подготовить свидетельства. В противном случае провести тестирование планов реагирования по результатам - составить акты.
7.C31CТакже обязательно контролировать доступ пользователей к системам. При этом если это выполняется сугубо для галочки, то так тому и быть. Но если Вы хотите наладить процессы и обеспечить реальный процесс разграничения доступа, то сначала нужно строить процесс, а потом проводить аудит. А не наоборот. Так как при неработающем процессе у Вас очень быстро все вернется на круги своя и усилия будут напрасны.C32C

Особое внимание хотелось бы уделить планированию работ и контролю их выполнения. Думаю, что для каждого проекта актуален вопрос недостатка ресурсов. Аудит в этом плане, наверное, самый лучший пример. Так как ни для одного из привлеченных отделов(может быть за исключением отдела безопасности) проект не является приоритетным. А поскольку основные проекты для задействованных подразделений никто не планирует останавливать, то отношения ждите соответствующего. А если Вы не заручились поддержкой руководства в этом вопросе Но не будем о грустном.
Я являюсь сторонником ведения проектов по методологииPMBok, правда, позволяя себе сократить иногда количество отчетных бумажек. Данная методология позволяет корректно вести проекты и очень много вопросов, которые будут возникать у Вас в процессе ведения проекта уже предусмотрены заранее. Вот только если Вы с ней не знакомы, то потребуется время на ознакомление с ней и ее апробацию.
Какие бы ситуации не приходилось решать в рамках тех или иных проектов, это всегда немножко творчество. И еще опыт и крупицы знаний. Которые как раз можно почерпнуть в том числе, например из статей в профильной прессе. Я, например, почерпнул идеи из методологииSCRUM, которая к информационной безопасности и аудитам не имеет никакого отношения. Но пришлась как нельзя кстати.
Что касается несоответствий, то я бы рекомендовал относиться к найденным несоответствиям спокойно, если это не базовые несоответствия в архитектуре системы, недостатке оборудования, ПО или критичных, для компании процессах, которые ни коим образом не могут быть изменены.Во всех остальных случаях от аудитора можно получить разъяснение, а часто и совет как это исправить самым простым образом. Вот только времени и денег на это может потребоваться значительно больше, чем планировалось изначально. Потому, лучше воспользоваться услугами профильного специалиста заранее. Но тут не нужно забывать о человеческих качествах и отношениях между людьми.

Непосредственно перед проведением аудита обязательно необходимо собрать всех сотрудников, которые будут участвовать в интервьюировании и провести совещание, где уточнить основныемоменты предстоящего аудита и особенно обратить внимание на нюансы. Например, что администратору запрещается покидать рабочее место, не заблокировав компьютер при посторонних. На каждом аудите находится администратор, который выбегает, куда-то оставив при этом аудитора один на один с открытыми соединениями к подлежащим аудиту критичным серверам. Данное замечание не критично, и использовано как пример, но таких мелочей может накопиться достаточно много. Кроме того, обязательно согласуйте с коллегами, какую информацию не стоит разглашать аудитору ни в коем случае об этом выше. Так как, услышав хоть какое-то несоответствие, аудитор обязательно распутает клубок можете не сомневаться.
Перед аудитом будьте готовы к тому, что как бы вы все не планировали, вы не успеете устранить все несоответствия и выполнить все задачи, которые хотели к запланированным срокам. Так как в компании происходят непрерывные внесения изменений в системы, процессы, случаются авралы (обязательно в самый неподходящий момент), а сотрудникам кроме подготовки к аудиту нужно выполнять свои функциональные задачи. Рекомендую обязательно при планировании в зависимости от уровня зрелости процессов, загрузки сотрудников и своей сферы влияния закладывать от 10 до 35% дополнительного времени на риски.
Да вот еще, что касается решений, которые рекомендуют компании по результатам аудита. Нужно понимать, что как правило, компании, которые проводят аудит, имеют подразделения, которые занимаются внедрением определенных решений и систем. И можете не сомневаться, что независимо от их соответствия в полной мере вашим требованиям, рекомендовать к внедрению будут именно их. Просто имейте это виду. Ничего страшного в этом нет. Если подразделение компании обладает реально выполненными успешными проектами, а данное решение и цена за услуги вас устраивает смело соглашайтесь. Просто имейте виду, что не стоит слепо полагаться на рекомендации и внедрять дорогостоящие системы, чтобы пройти аудит и забыть о них до следующего года.
И еще. Не воспринимайте аудитора как врага. Воспринимайте его как союзника. Часто, результаты аудита могут показать руководству, что у вас действительно не хватает ресурсов, технологий или бюджета, и что это не вы сами придумали необходимость наличия бесполезных игрушек для ИТ или ИБ. Смело говорите об этом аудитору, пусть пишет в отчете. Но помните, такое можно говорить при предварительном аудите или экспертном аудите, но уж никак не как несоответствие, на сертификационном. Так как в противном случае сертификата соответствия, вы можете и не увидеть. А руководство вместо дополнительных ресурсов и бюджета может наградить вас выговором или и вовсе уволить, за плохую работу и провал сроков проекта.
В целом могу сказать, что подготовка компании к аудиту на предмет соответствия требованиям стандартаPCIDSS(впрочем, как и любого иного) требует четкого планирования, упорства и выдержки. А также умения балансировать между документированными требованиями стандарта и их внедрения таким образом, чтобы они минимально влияли на работающие процессы в компании, при этом повышая их реальную безопасность.

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

Актуальнуюиполезную информацию поPCIDSSможно найтина сайте.

TL;DR: Разрабы второго по популярности (по версии ratingruneta) интернет-магазина встроили в движок код, который делает копии всех счетов клиентов на сервер в Аризоне.

Кто пострадал

Интернет-магазины и их клиенты, работающие на CS-Cart всех версий.

Сама компания заявляет о 35'000 установок в 170 странах мира.

Какая информация содержится в утечке

• ФИО покупателя интернет-магазина

• Адрес покупателя

• Телефон покупателя

• email покупателя

• Сумма заказа, заказанные товары и услуги

• Почтовые треки

Подробности

С CMS можно познакомиться (и скачать демо) по двум адресам: https://www.cs-cart.ru/, https://www.cs-cart.com/.

Последняя версия на сегодня 4.12.2.SP2, написана на PHP, ставится как всё, заточенное под LAMP, но нам для наших целей это не обязательно делать.

Скачиваем, распоковываем и сразу идём смотреть ./app/Tygh/Pdf.php , где видим такой код для отрисовки счёта клиента в виде Pdf-файла:

<?php...protected static $url = 'http://converter.cart-services.com';...public static function render(...)  {  ...  $response = Http::post(self::action('/pdf/render'), json_encode($params), array(            'headers' => array(                'Content-type: application/json',                'Accept: application/pdf'            ),            'binary_transfer' => true,            'write_to_file' => $file        ));...protected static function action($action)  {    return self::$url . $action;  }

где json_encode($params) содержит всю личную информацию, в т.ч. персональные данные покупателя, а Http::post(self::action('/pdf/render') после эвалюации превращается в Http::post("https://converter.cart-services.com/pdf/render") и все наши данные отправляются по ссылке выше, а уже в ответ из Аризоны (см. далее) приходит Pdf, который потом отправляется покупателю и/или используется для других целей системы.

converter.cart-services.com

Если погуглить этот адрес (converter.cart-services.com), то окажется, что первые обращения в форум поддержки датируются не позже 2018 года (вероятно, даже раньше, но администрация форума поддержки удаляет сообщения об этой проблеме), скорее всего с 2006 года, когда этот адрес был зарегестрирован.

Сам сервер, где собираются счета находится в Аризоне, США:

- Resolving "converter.cart-services.com"... 1 IP address found: 184.95.47.28

PTR cs-cart.com
ASN 20454 (SSASN2, US)
ORG Servstra
NET 184.95.32.0/19 (SERVSTRA)
ABU -
ROA UNKNOWN (no ROAs found)
TYP Proxy host Hosting/DC
GEO Phoenix, Arizona (US)
REP GOOD

Выводы

Компания-разработчик установила закладку, которая все заказы всех своих 35к клиентов, включая информацию о ФИО, емейлах, телефонах, адресах покупателей сливает куда-то в Аризону на сервер, который зарегистрирован уже 15 лет.

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

Как это соотносится с законами о персональных данных (GDPR, 152-ФЗ), думаю, объяснять не надо.

Обращение на форум поддержки, кстати, заканчивается удалением топиков и открытым признанием, что такое поведение меняться не будет.

28 января 2021 года, в международный день защиты данных, пройдет тематическая конференция Privacy Day 2021. Российская конференция состоится уже в третий раз. Рассказываем, какие проблемы нашей приватности спикеры обсудят на Privacy Day уже в этот четверг.

В Европе и США День защиты данных отмечают с 2007 года. Под датой 28 января он закреплен в национальных календарях, регулярно проводятся многотысячные тематические мероприятия, в том числе международные. Московская конференция призвана поддержать общемировое движение и дать российским специалистам площадку для дискуссий и нетворкинга.

Главные темы Privacy Day 2021 - нарастающие объемы сбора данных о пользователях со стороны госструктур и медиакорпораций, а также проблемы приватности в пандемическом мире.

Темы, которые спикеры обсудят на конференции:

• тенденции регулирования персональных данных в России и в мире;

• новые угрозы приватности со стороны технологий, государства и корпораций;

• успешные бизнес-кейсы в области защиты, хранения и оборота персональных данных;

• выдающиеся случаи ответственного и добропорядочного обращения с данными пользователей;

• новые проекты в сфере приватности;

• экспертные оценки, жаркие баталии и неожиданные выводы.

В 2021 году конференция проходит онлайн, доступна и бесплатна для всех пользователей в прямой трансляции на YouTube.

Аудитория мероприятия: эксперты в области приватности и защиты информации, DPO, специалисты по безопасности, сотрудники и владельцы крупных IT-компаний, юристы, экономисты, социологи, общественные деятели, журналисты и пользователи Сети. Privacy Day 2021 интересна тем, кто работает с персональными данными, а также пользователям, которые их и производят.

ОРГАНИЗАТОР

Privacy Day 2021 проводится РосКомСвободой совместно с Digital Rights Center и Privacy Accelerator.

ГДЕ И КОГДА

Конференция в формате онлайн

28 января 2020 года

Начало в 11.00 (Мск GMT+3)

ПРОГРАММА

На сайте: http://privacyday.ru

Общий регламент защиты персональных данных (General Data Protection Regulation, GDPR) вступил в силу почти три года назад, но за столь незначительный период по меркам развития законодательных инициатив он стал настоящим флагманом, примером и во многом поводом для пересмотра локальных актов по работе с персональными данными в целом ряде государств.

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

Что случилось

Степень влияния GDPR сложно преувеличить. Он потянул за собой цепочку похожих мер в США, Бразилии и даже Кении. На третий год победоносного шествия закона по планете к делу подключились и канадские регуляторы. Они решили обзавестись своей локализацией закона пересмотреть двадцатилетний PIPEDA (Personal Information Protection and Electronic Documents Act) и разработать новый документ под названием Consumer Privacy Protection Act (CPPA).

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

Главное, что выделяет GDPR по-канадски, это новые санкции для нарушителей регламента. Им придется выложить 3% годового дохода компании (с учетом заработка филиалов по всему миру) или 10 миллионов, по всей видимости, канадских долларов.

Но в случае крупной утечки, умышленного слива или нарушения правил деиндентификации данных, предусмотрен штраф до 5% / 25 миллионов соответственно.

Примечательные нюансы

Верхняя планка в пять процентов выбрана отнюдь не случайно так канадские власти демонстрируют решительные намерения превзойти GDPR по всем параметрам. Размером санкций они не ограничиваются. Руководствуясь CPPA, организации будут обязаны по запросу предоставлять разъяснения относительно того, как работает их алгоритм или рекомендательная система, принимающая решения на основе персональных данных гражданина страны. Эксперты считают, что в этом плане (как и по штрафам) Канада может обойти европейских регуляторов.

Что касается деиндентификации подразумевается ее полный запрет. За установление личности по предоставленным персональным данным предусмотрены санкции. Единственное исключение тестирование в целях поддержания должного уровня безопасности (вероятно, некой системы, предупреждающей подобные попытки). Однако пока сложно сказать, как будут выполнять это требование условные соцсети, если человек решит указать действительные ФИО и возраст. Скорее всего, требование применят против злостных нарушителей например, организаций, занимающихся восстановлением данных из множества серых баз для последующего спама аудитории с предложениями воспользоваться какой-либо услугой.

Что интересно, в CPPA учли и ситуации, когда не нужно получать согласие для сбора персональных данных. Допустим, сюда относят поддержание сетевой безопасности, плюс все, что не подпадает под коммерческую деятельность и другие попытки оказать какое-либо влияние на принятие человеком тех или иных решений (например, о покупке).

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

Чего стоит ожидать

Канадский вариант GDPR будут применять ко всем структурам, которые хоть как-то соприкасаются с данными граждан. Если крупные компании могут выделить двух-трех штатных специалистов на подготовку, поддержание в актуальном состоянии и проверку корпоративных политик по работе и обеспечению безопасности ПД, то для малого бизнеса этот процесс, по всей видимости, окажется затруднительным, учитывая, что CPPA требует еще и обучения сотрудников.

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

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

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

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

Что еще почитать у нас в блоге:

• В Китае ввели блокировку ESNI-соединений

• Проект Доступный интернет: промежуточные итоги

• Как SD-WAN и VNF помогут снизить расходы на корпоративную сеть

• Одной канарейки мало: у VPN-сервисов все чаще запрашивают данные

• Как развивается ситуация с возможным ограничением на end-to-end шифрование