PCI DSS и ГОСТ Р 57580.1-2017 вместе — дешевле?

[ky0]

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

[Kifir42]

И да, и нет. тут вообще различия в подходе к созданию нормативных документов. В российской традиции создания именно обязательных документов - очень важно отразить 2 стороны медали:
- ограничения: чего делать нельзя, и что сделать нужно;
- методология: что и как сделать, чтобы было "нормально".
и методологическая часть описана и послабее, и плотно связана с обязательной - как раз через описание процессов и контролей.
А в западной традиции часто действует принцип "написано то, что должно получиться. А как - придумай сам, или закажи профильных специалистов. А если нарушишь - ну не маленький, сам понимаешь".
Мне, честно говоря, подход ГОСТа больше нравится - и подробнее, и конкретнее. Но на любителя, да

[bloodevil]

>>> Во-вторых, PCI DSS не предъявляет никаких требований к тестовым системам.

Я бы не был бы столь категоричным. См., например, п. 6.4.3 пока еще действующего PCI DSS v3.2.1

[Kifir42]

ок, спасибо: соглашусь, плохо сформулировал.
PCI DSS не требует конкретных мер и средств защиты для тестовых сред. Но при работе с тестовой средой - да, просит не вносить продуктивные данные в тест, и тестовые "артефакты" в прод

[ifap]

А Вы какую версию PCI DSS вообще обсуждаете? 3.2.1 ЕМНИП полагает, что TLS_RSA_WITH_AES_128_CBC_SHA - надежно и безопасно в 2023 году, да и 4.0 допускает использование SSL. Для передачи платежной информации, Карл.

[Kifir42]

не очень понимаю, в чем вопрос. PCI DSS по большей части ссылается на внешние документы по криптографии. И да, Sha-1, упомянутый в приведенном вами cipher suite подходил для PCI DSS 3.2.1, и не подойдет (начиная с 25-го года) для PCI DSS 4.
Только теоретически ничто не мешает во время жизненного цикла pci dss v4 появиться какому-то документу, регламентирующему уязвимость, например, sha-2 - и таким образом выводящим, например, sha-2 за пределы понятия "стойких алгоритмов"

[ifap]

Ткните меня, пожалуйста, носом, где PCI DSS ссылается на конкретные (т.е. назвавние и желательно версия) внешние документы. Я вижу только прил.А2, в котором явно указывается, что SSL допустим, если "исправлены уязвимости", но единственный известный мне сегодня способ устранения уязвимостей в SSL, это полный отказ от его поддержки. Как и от поддержки того, что в тексте кокетливо называется "early TLS", т.е. 1.0 и 1.1, и которые PCI DSS тоже считает невозбранным для обмена финансовой информацией все в том же 2023 году.

Я понимаю почему и это даже не скрывается: парк старого оборудования никто по щелчку менять не станет (и даже обновлять софт внутри), а выбирая между игнорированием рынком стандарта и следованием стандарта за реалиями рынка, его разрабы, разумеется, предпочитают второй вариант. Только это уже становится не стандарт, а "чего изволите?"

[Kifir42]

Не ткну: в PCI DSS прям самую малость другая логика ссылок на регламентирование шифрования. А вопрос я все также не понимаю. Не могли бы его сформулировать?

[ifap]

У меня не столько вопрос, сколько реплика: PCI DSS - такой себе стандарт, вилами по воде: безопасность должна быть безопасной, надо принимать должные меры и прочие обещукрепляющие фразы на 300 страниц, при этом никакой конкретики.

[bloodevil]

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

[ifap]

Пожалуйста: NIST SP 800-52.

[bloodevil]

эка вы ловко guideline к стандарту приравняли, увы, но мимо

[ifap]

Т.е. то, что документ, названный руководством, более конкретен в своих требованиях, чем документ, названный стандартом, Вас не смущает? ОК, закончим на этом.

[bloodevil]

совершенно не смущает, так и должно быть, так собственно и есть в парадигме того же NIST

[avf48]

*Спасибо за возможность увидеть ссылку на стандарт... прослезился... спасибо!

По работе с несколькими системами стандартизации, можно воспользоваться стандартами по ИСМ (ИНТЕГРИРОВАННЫМ СИСТЕМАМ МЕНЕДЖМЕНТА). А в дальнейшем, разработать свой стандарт предприятия, который учитывал бы требования обоих...

ГОСТ Р 58542-2019 ИНТЕГРИРОВАННЫЕ СИСТЕМЫ МЕНЕДЖМЕНТА. РУКОВОДСТВО ПО ПРАКТИЧЕСКОМУ ПРИМЕНЕНИЮ

ГОСТ Р 55269-2012 СИСТЕМЫ МЕНЕДЖМЕНТА ОРГАНИЗАЦИЙ. Рекомендации по построению интегрированных систем менеджмента

ГОСТ Р 53893-2010 РУКОВОДЯЩИЕ ПРИНЦИПЫ И ТРЕБОВАНИЯ К ИНТЕГРИРОВАННЫМ СИСТЕМАМ МЕНЕДЖМЕНТА

PDCA