понедельник, 12 апреля 2021 г.

SSS (Secure Software Standard)

В феврале появилась свежая версия Secure Software Standard (скачать можно по ссылке).

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


  1. Прописанные навыки для каждой роли.

  2. Критерии оценки компетенций персонала.

  3. Ежегодная проверка компетенций.

  4. Подтверждение соответствия требованиям отраслевых стандартов.

  5. Процессы и документация. 

  6. Стратегия безопасной разработки ПО.

  7. Анализ кода.

  8. Наличие показателей эффективности критериев анализа мер безопасности.

  9. Критичные активы выделены и описаны.

  10. Описание рисков и угроз.

  11. Анализ решений с открытым исходным кодом, если применимо.

  12. Регулярное тестирование, анализ и устранение уязвимостей.

  13. Анализ ПО, влияние изменений. 

  14. Поддерживать версионность и контролировать целостность.

  15. Безопасность данных.

  16. Безопасная конфигурация ПО.

  17. Наличие каналов и процессов отслеживания угроз.

  18. Пентетсы и Баг Баунти

  19. SO/IEC 27034 Application Security Guidelines • Building Security In Maturity Model (BSIMM) • OWASP Software Assurance Maturity Model (OpenSAMM) • NIST Special Publication 800-160 and its Appendixes

  20. Иное.


Как видно, есть достаточно пересечений как с PA DSS так и с PCI DSS, но в несколько более широком ключе процессов ориентированных на разработку. 


воскресенье, 7 марта 2021 г.

Soft opt-in и GDPR

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

Остановимся на вопросе soft opt-in. 

Контролирующие органы Великобритании (Guidance on the use of cookies and similar technologies, dated 3 July 2019) и Франции (Recommendation on the practical procedures for collecting the consent concerning operations of storing or gaining of access to information in the terminal equipment of a user, dated 14 January 2020) пытались урегулировать этот вопрос, предоставляя свои разъяснения и руководства, однако принципы, предусмотренные в этих документах не могут использоваться в качестве унифицированных инструментов для всех контроллеров и обработчиков персональных данных в ЕС и мире, потому как они применяются только на государственном уровне, в рамках юрисдикции соответствующего органа, который выдал конкретный документ.

Однако, оба органа, в своих разъяснениях, сошлись на том, что получение согласия на использование файлов cookie, когда это необходимо, не могут приобретаться через так называемый «soft opt-in», когда считается, что согласие получается автоматически, если пользователь продолжает пользоваться веб-ресурсом. Такая позиция контролирующих органов шокировала некоторых представителей бизнеса, так как алгоритм «soft opt-in» использовался в различных сферах бизнеса уже на протяжении долгих лет.

В результате таких непонятных процессов, побуждающих к возникновению противоречий в обществе, European Data Protection Board принял решение о предоставлении разъяснения (Guidelines 05/2020 on consent under Regulation 2016/679 dated 5 May 2020), которое бы прояснило вопрос получения согласия на сбор и обработку файлов cookie в рамках Европейского Союза до момента принятия и вступления в силу Е-Privacy Regulation.

Одними из основных аспектов, которые были подчеркнуты в разъяснении, настаивают на том, что:

  • доступ к целому или части веб-ресурса не должен быть запрещен, если физическое лицо - пользователь не согласилась с использованием его файлов cookie, поскольку отсутствие вариантов использования веб-ресурса, в таком случае, является основанием считать, что не обеспечивается принцип свободного предоставления согласия;
  • если требуется согласие на использование файлов cookie, «soft opt-in» уже не может считаться надлежащим предоставленной согласия, поскольку отсутствие формального процесса не позволяет ни определить однозначное действие физического лица - пользователя, ни предложить возможность отозвать или выделить свое согласие.

Эти трактовки подтверждают позиции как Французского контролирующего органа, так и контролирующего органа Великобритании, и снимают резонансные вопросы по использованию «soft opt-in» как закоренелого принципа получения согласия на обработку файлов cookie (детальнее). 

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

вторник, 26 января 2021 г.

Проектирование ПО с учетом требований стандартов безопасности

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

Основной материал подготовлен и составлен на основе требований стандарта 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. Пункт, который вероятно вы захотите дополнить самостоятельно 😊.

Дополнительные требования DGPR

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

17. Обезличенные данные.
Везде, где возможно использование анонимизированных или обезличенных данных должны использоваться именно такие данные. Количество персональных и критичных данных в системах должно быть минимизировано. 

18. Должна быть предусмотрена возможность согласия пользователя на сбор и обработку его персональных данных (таких как куки), но не soft opt-in (когда считается, что согласие получается автоматически).
Кроме того, хороший документ Cookie Policy описывает техническую составляющую данного процесса.

19. Должна быть предусмотрена возможность получения согласия клиента на использование его персональных данных при рекламе, рассылках и пр. материалах.
Данное требование должно быть реализовано как Granular Consent (для каждого конкретного типа отдельно).

20. Проведение Data Mapping.
Документирование и структурирование потоков данных значительно упрощает разработку, выполнение требований и поддержку продукта.

Это последний по списку пункт, но один из самых важных в целом.

Публикация материала носит ознакомительный характер. Все указанные рекомендации являются частным экспертным мнением и могут отличаться от позиции PCI Council или ICO. Для реализации требований рекомендовано опираться на оригинальные версии официальных документов.

Если у вас есть вопросы вы можете связаться со мной по почте.

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