2012年9月发布的《在成熟模型中构建安全》（BSIMM）的第四版本被媒体大肆宣传，BSIMM4包含对英特尔和富达案件的详细的案例分析。笔者认为BSIMM的重要性在于-它是唯一可用于衡量软件安全计划的数据驱动模型。BSIMM从事实出发，详细描述软件安全状态。

    但BSIMM没有提供直接的建议来指导你的公司如何处理软件安全问题。诚然，绝大多数企业才刚刚开始面对软件安全，他们将受益于多年（集体）直接经验的可操作性指导。

    根据在该行业多年的经验以及四年解译BSIMM数据的经验，笔者提出了软件安全十诫。

    软件安全十诫：规范性指导

    0.你应该通过软件安全组（SSG）来建立软件安全计划（SSI）。

    1.你应该依赖采用BSIMM的风险管理和客观测量来定义SSI的成功来确定SSI的成功，而不是“前十名列表”和漏洞数量。

    2.你应该与企业高管沟通，直接将SSI的成功与业务价值联系，并与公司的竞争对手作比较。

    3.你应该创建和采用SSDL方法，如微软SDL或者Cigital Touchpoints,这些方法整合了安全控制（包括架构风险分析、代码审查和渗透测试）以及比他们自己运行的工具还更了解软件安全的人员。

    4.你不应该将软件安全活动仅限于技术SDLC活动，尤其是渗透测试。

    5.你应该为你的SSG发展培养软件安全专家（因为周围没有足够的合格专家）。

    6.你应该关注来自业务、运营和事件响应人员的情报信息，并相应地调整SSI控制。

    7.你应该仔细追踪你的数据，并指导数据的位置，无论你的架构多么云计算化。

    8.你不能单纯地依靠安全特性与功能来构建安全的软件，因为安全是整个系统的新兴资产，它依赖于正确地建立和整合所有部分。

    9.你应该修复已识别的软件问题：漏洞和缺陷。

    关于软件安全十诫的一些解释和理由，按照先后顺序。[page]
    通过软件安全组（SSG）来建立软件安全计划（SSI）。BSIMM的51家企业都有一个活跃的软件安全组。如果没有软件安全组，是不太可能建立可行的软件安全计划（迄今为止，在该领域没有出现过例外），所以，在你开始软件安全活动前，创建一个软件安全组。软件安全组有各种规模和形态，所有好的软件安全组都应该包含具有深度编码经验的人和具有架构经验的人。代码审查是非常重要的最佳实践，而执行代码审查，你必须完全理解代码（更不用说大量的安全漏洞）。然而，最佳代码审查人员有时候是非常糟糕的软件架构师，要求他们执行架构风险分析只会让他们一片茫然。请确保你的软件安全组中有架构人员以及代码人员。渗透测试同样如此，渗透测试需要以聪明的方式入侵事物（但通常不具有深度编码技能）。最后，软件安全组将需要对数百名开发人员进行培训和指导，并直接与他们合作。沟通能力、教学能力以及良好的咨询都是必备技能，至少对于部分软件安全组工作人员而言。

    依赖采用BSIMM的风险管理和客观测量来定义SSI的成功，而不是“前十名名单”和漏洞数量。太多软件安全专业人士将软件安全视为“打地鼠”式的漏洞查找。企业应该意识到，发现漏洞并不没有创建安全的软件，也不能以此与管理层沟通。事实上，面对不断扩大的安全问题清单，只会让高层管理人员感到更加沮丧。如果你将所有时间花费在查找漏洞上，而不花时间来修复这些漏洞，这根本是徒劳无功。同样地，如果你花时间来修复安全漏洞，但又反复发现同样的漏洞，这仍然是徒劳。幸运的是，BSIMM为软件安全计划提供了一个极好的测量标杆。你可以将你的软件安全计划中的活动与同行进行对比，以确定你是遥遥领先、排在中间，还是最后（不要让自己沦为倒数）。BSIMM测量提供了对软件安全计划的详细快照，这让高层管理人员很容易理解。一些领先的企业使用BSIMM测量来追踪进展情况，并为设置软件安全计划战略提供真实的数据。对于你的企业而言，需要何种程度的软件安全性？这个问题问得好。所幸的是，一些你的同行可能知道。

    与企业高管沟通时，直接将SSI的成功与业务价值相联系，并与公司的竞争对手作比较。正如上诉所说，如果你正面对着不断扩大的安全问题清单，而你没有想办法来解决这些问题，你可能会被视为是问题的一部分。企业高管希望看到你的软件安全计划所有方面的一些“关键绩效指标”.培训进展如何？你的开发人员学会了如何在最开始避免漏洞吗？你的漏洞密度比是？也就是说，与六个月前相比，在相同单位内，漏洞数量有所下降吗？每当你的开发团队整合新技术堆栈时，是否会出现大量安全漏洞？当你发现和解决架构问题或者修改了的要求时，你展示了这将会为你省下多少苦恼和金钱吗？与去年相比，通过最近的生命周期渗透测试，你是否发现问题变少了？（应该是这样）。最后，因为软件安全计划具有多个活动部件，BSIMM测量是测量你自己的最可靠的方法。高层管理人员喜欢BSIMM,并能够即时掌握其效用。

    创建和采用SSDL方法，如微软SDL或者Cigital Touchpoints,这些方法整合了安全控制（包括架构风险分析、代码审查和渗透测试）以及比他们自己运行的工具更了解软件安全的人员。因为很多公司都在做软件安全，所以存在很多不同的SSDL.并不是所有公司都有正式化的SSDL,但他们应该有。你应该从我的书《软件安全》以及微软的SDL借鉴一些想法，再加上一些OWASP和SAFEcode的想法。阅读BSIMM,看看其他公司正在做什么。主要是要认识到，我们知道现在应该如何做软件安全，这个领域已经很成熟。首先，你需要用代码审查（最好使用工具）来查找漏洞，用架构风险分析来找出问题，用渗透测试来找出容易忽略的漏洞。请确保当你使用这些工具时，不要盲目地使用它们（或者将这些工具扔给不知所措的开发人员）。请记住这一点：如果所有的开发人员在没有帮助的情况下，能够直接利用安全工具的结果并且修复安全漏洞，他们将不会在最开始制造漏洞。你至少需要一名比这些工具更聪明的安全专业人士。真的是这样，如果你需要确定和建立SSDL,就去寻求帮助，有很多安全顾问靠这个吃饭。

    不应该将软件安全活动仅限于技术SDLC活动，尤其是渗透测试。你当然应该利用渗透测试的优势，但你需要了解它的局限性。主要的限制是经济方面：当你在内部系统（或者即将出货的系统）中发现一个安全问题，解决问题将变得非常昂贵。你要解决你所发现的问题，对吗？这里需要注意的是，软件安全不仅仅是充斥着各种漏洞以及攻击者威胁的技术问题。当然你需要做大量适当的技术操作，但永远不要忘记将这些操作直接联系到业务影响和风险管理。你正在修复开发器以确保开发人员在最开始制造更少的安全漏洞吗？你正在构建安全的中间件解决方案以供开发人员和架构师使用吗？你正在测量安全活动，并内部公开相关结果吗？你应该这样做。这也是BSIMM涵盖的范围广于架构师、开发人员和测试人员的工作范围的原因。我们询问了很多企业有关提出、创建和部署安全软件的一切数据，我们记录了这些数据，并产生了BSIMM.我们与跨多个垂直行业的各种规模的几十家公司（包括软件供应商）的持续接触都表明，一个涵盖政策、风险、合规、管理、衡量、运营、服务水平协议以及相关条目的软件安全计划除了设计、编码和测试中所有重要关键的因素，他们认为是这些业务流程以及他们产生的文化和环境对生产和维护安全软件至关重要。

    为你的SSG发展和培养软件安全专家（因为周围没有足够的合格的专家）。最佳软件安全组成员是软件安全人员，但软件安全人员往往找不到。如果你必须从头开始创建软件安全类型，从开发人员开始，教他们安全知识。不要试图从网络安全人员开始--教他们关于软件、编译器、SDLC、漏洞追踪和软件界的一切知识。再多的传统安全知识也无法克服软件的“木讷”.应该像种树一样，从播种开始，逐渐将其培育成参天大树。当你开始这样做时，你应该尝试培养“瑞士军刀”类型的专家，而不是重视每分钟的专家。我一直期待找到可以审查代码、做一些渗透测试，以及能够解决安全问题的人。[page]
    关注来自业务、运营和事件响应人员的情报信息，并相应地调整SSI控制。安全是一个过程，而不是一个产品。软件安全更是如此。你可以构建世界上最好的代码，具有超级“防弹”架构，但在操作过程中仍然可能发生问题。使用你经历过（以及你的同行经历过）的安全攻击来提高你的软件安全方法，并根据业务重要性来进行调整。尽可能地了解你的敌人。

    仔细追踪你的数据，知道数据的位置，无论你的架构多么云计算化。云时代已经来临，你的数据将被转移到云中。请了解清楚，你不能将软件安全责任外包给你的云供应商。你的客户还依赖你来保护他们的数据，在某些情况下，政府还会监管这种责任。云计算的弊端在于应用在云端运行。现在正确地构建，能让以后的日子更轻松。

    不要单纯地依靠安全特性与功能来构建安全软件，因为安全是整个系统的新兴资产，它依赖于正确地建立和整合所有部分。无论我们说多少次，开发人员、架构师和建造者仍然将安全作为一件事情。他们接受的多年的培训都是将系统认为是特性和功能集，这是我们需要克服的。不要陷入“神奇加密神话”的陷阱。加密当然是有用的，一些系统仍将需要加密功能，但安全是一个系统级属性。聪明的攻击者很少会试图攻破加密功能，他们往往会攻击系统其它晦涩部分的漏洞。当你在选择和部署安全功能时，请确保你花了尽可能多的实践来试图消除漏洞和问题。即使是具有良好加密、强大的身份验证、细粒度授权、费解的CAPTCHA以及很多其他完美编码的安全功能的软件，都可能遭受攻击。这些功能通常会阻止授权用户做已知的不好的事情。但他们很少阻止未经授权的用户做未知的不好的事情。你需要一个软件安全计划来为整个产品组合有效且高效地构建安全软件。

    你应该修复已识别的软件问题：漏洞和缺陷。这很讨厌，但在实践中，软件安全就是这样的。你聘请一些洗心革面的黑客来进行渗透测试，你知道他们已经洗心革面了，因为他们是这样告诉你的。在你让他们从外部探测你的系统的一周内，他们就找出六个安全漏洞，然而，他们可能只会告诉你其中的五个漏洞。你修复了两个看似可修复的漏洞，然后宣布胜利。但其他四个漏洞呢？简单地说，如果你将所有精力花费在通过架构风险分析、代码审查和渗透测试来找出软件中的问题，而不花时间修复你找出的漏洞，你的软件将变得更加不安全。修复软件吧！当然，修复漏洞是一个风险管理活动，没有哪个公司有无限的资金投入其中。因此，企业应该根据影响、成本和其他重要业务因素，来优先漏洞修复顺序。然而，极少数企业会追踪每个没有被修复的漏洞。10个低严重漏洞会变成中级严重漏洞吗？那100个？1000个漏洞呢？此外，极少数企业会关联来自多个测试方法的研究结果，而是在每个测试后，独立作出决定。分别来自架构评估、静态分析、模糊技术以及渗透测试的低严重性漏洞相结合，会成为紧急漏洞吗？我也不知道，但企业应该考虑这个问题。修复软件可能更容易。

    有关描述性模型的规范性建议

    最终，你需要确定和采用你自己的规范性SSDL方法，然后使用描述性的测量系统来跟踪进度。我们的建议是使用BSIMM来测量你的软件安全计划的当前状态，确定你应该开始着手的其他软件安全活动。如果你的企业确定需要投资的领域之一与SDL中的一个做法相匹配（举例来说），你可以利用微软对此的智慧来做。

    鉴于多年来我们一直在观察51家公司的真正的软件安全计划，我们可以自信地说，如果你的软件安全计划没有每年进行改善，你将落后于其他公司。我们知道，每个软件安全计划都是独一无二的，就像所有其他软件安全计划一样，你的同样也是独特的。幸运的是，无论你为软件安全采取哪种规范性方法，BSIMM都可以作为测量标杆、灵感源泉以及是否进步的客观测量标准。
 

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。