修改后的PCI安全标准委员会指南。他们是否向左移动得足够远？

本文的一个版本最初发表在 数字交易杂志.

今年，PCI安全标准委员会发布了一套全新的软件安全指南，作为其PCI软件安全框架的一部分。这一更新旨在使软件安全最佳实践与现代软件开发相一致。这是一个非常好的倡议，它承认了这个过程是如何随着时间的推移而改变的，需要重新思考安全标准，这些标准是在我们大多数人的生活迅速数字化之前制定的。

这清楚地表明，我们的行业更密切地参与到可适应的指导方针的想法中--这些指导方针随着我们不断变化的需求而发展--以及网络安全环境的需求，如果我们继续在安全开发过程中松懈，可能会很快失去控制。当然，PCI安全标准委员会作为银行和金融业的管理机构（例如，为我们信任的软件制定安全标准，以保护我们所有的钱、信用卡、在线交易和销售点），他们承担着大量的风险，并且有巨大的动力来减少风险。

虽然这些标准肯定比以前的版本有所改进，并在一定程度上堵住了我们在快速、创新的功能开发方面的漏洞，同时也将安全作为其整体质量的一部分assessment ，但发现我们仍然有很长的路要走，这是一个有些令人失望的现实。

不，这不是我对这一举措说 "呸，讨厌！"。事实是，这些新的安全准则根本没有使我们向左走得足够远。

我们仍然专注于测试（而且测试得太晚）。

我发现PCI安全标准框架的一个突出问题是它对测试的明显依赖。当然，软件仍然必须进行测试（SAST/DAST/IAST过程仍然有它的位置），但我们仍然落入了同样的陷阱，并期望得到不同的结果。

是谁写了一行又一行的代码来创建我们所熟悉、喜爱和信任的软件？软件开发人员。

谁拥有测试这些代码的令人羡慕的地位，无论是用扫描工具还是手动代码审查？应用安全专家。

这些专家继续发现了什么？同样的错误，已经困扰了我们几十年了。简单的东西，我们已经知道如何修复多年了。SQL注入、跨站脚本、会话管理的弱点......对这些人来说，这就像土拨鼠日。他们把时间花在寻找和修复开发人员自己多年来有能力修复的代码违规行为上，只是在他们的过程中没有把安全作为优先事项 " 尤其是现在，在敏捷开发的时代，功能交付是王道，而安全是偷走创造性过程和项目完成的胜利的格林奇。

这并不是对任何一个团队的否定assessment ；开发人员和AppSec专业人员都有极其重要的工作要做，但他们仍然在互相妨碍。这种情况只会使有缺陷的SDLC长期存在，在这种情况下，安全意识淡薄的开发人员在消极的安全文化中操作，产生不安全的代码，然后在最初写完后，还得对其进行扫描、评估和修复。AppSec几乎没有时间来修复真正复杂的问题，因为他们被那些反复出现的小问题所困扰，而这些问题如果不加以检查，仍然可能给公司带来灾难。

我们正在浪费时间、金钱和资源，让测试成为代码中安全弱点的万能钥匙。由于每隔一天就有大规模的数据泄露，这种方法显然没有发挥出最佳效果，如果有的话。这些新的标准仍然在评估最终产品的状态（也许是假设所有的开发者都有安全意识，但事实并非如此）：比如，已经建成的产品。这是修复缺陷的最昂贵和最困难的阶段；这就像建造一座漂亮的新房子，但在你搬进去的同一天，却要请一个安全小组来检查是否有危险。如果地基出了问题，试想一下，要到那个地方去解决这些问题，需要多少时间、多少费用、多少头疼的事情。简单地重新开始往往更容易，也更便宜（而对于建造第一个版本的每个人来说，这是一个完全不满意的过程）。

我们绝对必须从基础做起：让开发团队参与安全最佳实践，赋予他们高效安全编码的知识，此外，还要在每个工作场所创建和维护积极的安全文化。

这是一个学习曲线吗？是的，它是。这是不可能的吗？绝对不是。而且它不一定是一个无聊的苦差事。如果Russ Wolfes在Capital One的经验能说明问题的话，直接吸引开发人员的创造性和解决问题的特征的培训方法已经在银行和金融部门取得了巨大的成功。

我们仍在寻找完美的 "最终状态"。

如果你把更新的PCI安全标准放在它们的背景下看，比如--你的成品、用户准备好的金融产品必须遵循这些最佳实践，以获得最佳的安全保障，那么它们绝对是好的。然而，在我看来，每一个公司--不管是金融公司还是其他公司--都会有最好的机会达到一个既能代表功能质量又能代表高标准安全的软件最终状态，只要他们退一步，意识到从周期的开始就这样做会更有效率。

那个完美的最终状态？你知道，当一个产品被扫描，人工审查，结果是完美的，没有错误的时候？我们仍在寻找它。在这个时间点上，它是一个独角兽。

为什么它如此难以捉摸？有一些因素。

• 人们依赖扫描工具，但它们并不总是有效的。误报是一个令人沮丧的、浪费时间的副产品，因为即使在一起，DAST/SAST/PCI扫描也不能识别和揭示代码库中每一个可能的漏洞。当然，它们可能会给你一个明确的答案，但它们真的在寻找一切吗？攻击者只需要利用一个漏洞就可以访问你认为受到保护的东西。
• 开发人员继续犯着同样的错误。开发人员之间没有围绕安全的知识分配，也没有众所周知和记录的 "安全代码配方"（好的安全代码模式）。
• 没有强调建立一个合作的、积极的安全文化。
• 开发人员需要被赋予正确的工具，以便在他们编写的产品中加入安全因素，同时不破坏他们的创意过程和敏捷开发方法。

这些准则是软件应该遵守的安全标准的有力验证清单，但让软件达到这种状态的最佳过程还有待商榷。

我们没有不安全的软件，因为我们缺乏扫描仪，我们有不安全的软件，因为没有为开发者提供易于使用、易于理解的安全工具来指导他们。

我们现在正处在一个进化的时代。多年来，软件安全总体上是可选的。今天，它基本上是强制性的--特别是对于敏感信息（金融、医疗、社会安全......你懂的）的保管者。

PCI安全标准委员会正在帮助设定基准，但我希望看到他们--以其所有的行业自尊和影响力--努力为开发人员提供实用指南，强调充分和积极的培训和工具。目前，企业没有压力来确保他们的开发团队具有安全意识和合规性，许多开发人员也不了解那些容易修复的小错误在被那些试图造成伤害的人利用时的严重程度。

正如生活中任何有价值的事情所预期的那样，真正的变革确实需要一个村庄。而空气中的变化（希望）将使我们所有人进一步向左倾斜。