问基于软件代码分析的风险管理

EN

对于整个PCI DSS来说，您对软件补丁、网络图和寿命结束日期的引用是正确的，但是对于您的问题有非常具体和相关的要求：

• 6.3.2:在发布到production...to之前检查自定义代码，找出任何潜在的编码漏洞
• 6.4:遵循变更控制程序
• 6.5:根据安全编码准则开发应用程序。防止常见的编码漏洞..。

PCI的第6节非常关注编码过程的安全性，但是您是对的，它不需要具体的实现。分析工具包属于6.3.2范围，需要通过手动或自动方式对代码进行审查。此外，您应该有一个流程来防止需求6.5.1和6.5.9之间引用的所有类型的漏洞。

应该使用许多重叠的过程来减轻漏洞，并确保它们不会进入生产代码。如果您认真地处理PCI的第6节，并满足所有为您的组织工作并具有安全性意义的流程的要求，那么您将处于一个良好的位置。

它没有理由不应该，事实上，这是一个很好的方式来做初步检查。之所以没有具体列出它，是因为笔试和手工分析应该比自动化分析做得更好(并且很可能包括一个作为评审的一部分)。关键是，仅仅进行自动化测试是不够的。

忽略PCI DSS。它是无用的(参见: BlackPOS)。

重要的是业务流程管理和对高价值产出链的深入理解。信息/数据/应用程序安全的问题是低价值的输入链可以让对手进入高价值的输出链。通过跟踪组织中的数据流来覆盖您的链。

确定关键要素，并建立一个设备，以确保所有适当的输入链。购买等同于BPM系统的网络保险。请您的审计团队、监管顾问、地区律师和联邦贸易委员会(或您的管辖范围所在的任何地方)通过替代框架进行自我评估。如果你想要我对一个框架的建议，我会推荐VisibleOpsSec，比如说，ISO 27001/27002，PCI，ISO，FISAP，CIP，等等。

Appsec非常简单。您可以将Microsoft (或Atlassian /Confluence)与过程模板集成在一起，这些模板映射到组织的需求(粗略地)，并与现有的流程模板(如EssUP、敏捷、Scrum、瀑布等)一起工作，或者任何可以调整产品管理团队与企业/组织所有者协调的小流程模板。如果您有第三方在做您的软件产品的任何部分，您就会包含它们(显然)，并将它们保持在相同的标准上。

然后，您执行模拟和红队分析，以及一些典型的德尔菲方法分析，以收集意见和了解结果，然后再发挥出来，在现实生活中。通过bdd-秒和bug搜索将这些概念集成到应用程序生命周期管理(ALM)中。许多bdd和bug搜索工具依赖于，所以您确保每个人都有一个副本，但也使用IronWASP和OWASP武装它们。如果您运行一个JEE商店(可能是用于ALM的亚特兰蒂斯)，那么您将需要一个良好的WebDriver (或O2)自动化测试工具和对比安全性。如果您有Microsoft，请查看许多标准的VisualStudio (或O2)工具--可能会在需要中间或持续缓解的现场项目中添加Fortify或Checkmarx。其他的框架确实需要一些不寻常的调整，但是没有什么太花哨或“存在”的地方。如果您正在运行移动项目，那么Appium与Clang (用于iOS)或Coverity (用于Android)结合使用，再加上Appthitor抽查可能会很好。

重要的是，这是支持ENISA和美国-CERT质量事件处理和反应计划.配置或留住优秀的DFIR人员始终是您最大的信息问题。将进程和工具添加到该程序是您的第二大信息问题。在此之后，appsec、datasec、"netsec“(哈哈，就好像那是存在的！)，风险管理将是在公园里散步。