软件安全十诫(二)

安全
不应该将软件安全活动仅限于技术SDLC活动,尤其是渗透测试。你当然应该利用渗透测试的优势,但你需要了解它的局限性。

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

为你的SSG发展和培养软件安全专家(因为周围没有足够的合格的专家)。最佳软件安全组成员是软件安全人员,但软件安全人员往往找不到。如果你必须从头开始创建软件安全类型,从开发人员开始,教他们安全知识。不要试图从网络安全人员开始--教他们关于软件、编译器、SDLC、漏洞追踪和软件界的一切知识。再多的传统安全知识也无法克服软件的“木讷”。应该像种树一样,从播种开始,逐渐将其培育成参天大树。当你开始这样做时,你应该尝试培养“瑞士军刀”类型的专家,而不是重视每分钟的专家。我一直期待找到可以审查代码、做一些渗透测试,以及能够解决安全问题的人。

关注来自业务、运营和事件响应人员的情报信息,并相应地调整SSI控制。安全是一个过程,而不是一个产品。软件安全更是如此。你可以构建世界上最好的代码,具有超级“防弹”架构,但在操作过程中仍然可能发生问题。使用你经历过(以及你的同行经历过)的安全攻击来提高你的软件安全方法,并根据业务重要性来进行调整。尽可能地了解你的敌人。

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

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

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

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

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

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

责任编辑:蓝雨泪 来源: TechTarget中国
相关推荐

2012-10-30 09:21:50

2009-06-08 10:42:24

2010-07-19 10:48:06

2017-11-06 05:18:35

2013-03-06 09:56:21

2024-04-10 08:01:40

2011-04-11 09:49:42

2015-05-25 11:16:23

2020-11-04 10:21:37

机器学习技术人工智能

2012-11-07 09:53:50

2016-09-28 19:26:31

2023-06-13 10:42:35

2024-12-18 16:08:30

2022-12-09 11:46:20

2021-05-17 19:01:04

安全运营SOC攻击

2024-04-15 12:12:04

2011-03-03 13:35:46

2023-12-06 12:09:47

2009-03-25 10:15:29

2023-01-09 14:30:03

点赞
收藏

51CTO技术栈公众号