我对中华民国相当熟悉,但不是QSA。
强密码的PCI定义参考您自己的标准,例如,如果我遵循NIST,即TLS,如特殊出版物800-57第1部分第5.6.2节所述,我不选择RSA,只使用Diffie-Hellman密钥交换,那么小于2048位的密钥不符合PCI DSS的要求?
这是一种狭义地侧重于弱公钥位的解释,那么TLS连接的所有其他方面都可能被认为是有问题的呢?只需查看SSL实验室的报告,就可以获得这个列表的长度的示例。
另外,如果两个端点都在您的控制范围内,那么对于TLS连接,使用mTLS是否会被认为是有问题的呢?我想应该是的。
然后是与客户证书相关的细微差别;如何确定客户证书颁发者,应该使用哪个信任锚(设备信任存储用于确定服务器证书链的信任锚),客户端是否需要遵守服务器的指示/可接受客户证书主题列表(一些颁发者主题没有CN,例如Amazon,因此不应该基于issuers == Cert AKI?),客户端是否也应该怀疑服务器端点的真实性并验证服务器握手的安全态势/期望?
这些只是我头上的4个客户证书想法,还有很多我可以肯定的。
我要问的是,是否有任何权威的来源,特别是满足PCI需求的框架/标准,您的实现可以遵循的东西,所有的TLS安全考虑和客户端和服务器端点的安全配置?
我搜索了NIST并找到了一些有用的零散的参考资料,OWASP也限制了分散的提示,SAFECode和CIS在这个领域是稀疏的,ISF是完全无用的(而且它的价值花费太高了)。我不知道还能去哪儿找。
发布于 2021-11-01 09:43:56
我要问的是,是否有任何权威的来源,特别是满足PCI需求的框架/标准,您的实现可以遵循的东西,所有的TLS安全考虑和客户端和服务器端点的安全配置?
对你简洁问题的简洁回答是否定的。只有标准和术语表是规范的。
请记住,PCI是一个基线安全标准。这并不是一本好的实践手册,部分原因是2016年的良好实践将不会在标准的整个生命周期中一直保持下去。这就是为什么它很擅长说你不能使用的东西(SSL),但是很不愿意说出你可以或应该使用的东西。
强密码的术语表定义有两个基本要求。
该标准有4.1中列出的三个要求。
如果一个实现满足这些需求,它将通过PCI。应由实体记录它们如何做到这一点,并由评估人员验证这一方法。标准并没有说“选择你自己的标准并遵循它”。它说(翻译)来自标准机构的文件可以帮助你找出业界目前所认为的“强大的密码和安全协议”。
老实说,从你的问题中,你可能比一般的QSA更了解TLS --所以做出好的安全决定,记录你的选择以及它们如何满足要求,这应该能满足你的评估人员的要求。
您还会发现以下PCI SSC常见问题很有用:
1491: PCI定义了必须使用哪些版本的TLS吗?https://pcissc.secure.force.com/faq/articles/Frequently_问_Question/Does-PCI-DSS-define-which-versions-of-TLS-must-be-used
1461: TLS 1.3的安全考虑是什么?https://pcissc.secure.force.com/faq/articles/Frequently_问_Question/What-are-the-security-considerations-for-TLS-1-3
老实说,gowenfawr的回答是:
不,没有。
就像这个一样正确。
发布于 2021-10-30 20:24:58
我要问的是,是否有任何权威的来源,特别是满足PCI需求的框架/标准,您的实现可以遵循的东西,所有的TLS安全考虑和客户端和服务器端点的安全配置?
不,没有。
PCI提供的指导非常有限,例如围绕从SSL和早期TLS迁移所做的大量工作。但即便是在那时,他们也只触及了TLS版本,并有了这种模糊的语言来涵盖其他所有内容:
除了提供对TLS后期版本的支持外,还确保您的TLS实现是安全配置的。确保您支持安全的TLS密码套件和密钥大小,并禁用对互操作性不需要的其他密码套件的支持。例如,禁用对弱“导出级”加密技术的支持,
他们还澄清了许多密码已经退休的事实:
此外,不允许使用弱密码套件或未经批准的算法-例如RC4、MD5和其他算法。
除此之外,谁来决定什么是“安全配置”?ASV和QSA。例如,他们最初说RC4不好,所以不要再使用它了。至少对于QSA来说,有一半的时间是在运行SSL实验室的打印输出,并决定您需要从中解决什么问题。
https://security.stackexchange.com/questions/256594
复制相似问题