在软件开发初期处理安全需求是防止安全问题最经济的方式。大多数安全需求都属于非功能性需求(Non-Functional Requirements ,NFRs)。很多从业者发现,在敏捷项目中处理安全和其他NFR非常具有挑战性。原因有二:
在本文中,我们会探讨以上两个问题。
敏捷专家们提出过一些方法,用以定义用户故事驱动的开发过程中的NFR。Mike Cohn在他的文章中讨论了评论者们提出的一些有趣的建议。Scott Ambler就该主题写了一系列文章,旨在证明并非所有的NFR都可以独立存在于用户故事中。而Dean Leffingwell可以说在这方面做了最深入的研究,他在自己的著作《敏捷软件需求》中花了整整一章探讨该主题。这些专家中大部分人都认为,NFR大致可以分成两类:
非功能性用户故事:以用户故事的形式展现的可测试功能块。这些用户故事中的参与者(Actor)可能是内部IT人员。例如:“作为安全分析师,我希望系统能抑制不成功的身份认证尝试,这样应用程序在面对暴力破解时不至于太过脆弱”。
约束:这是个跨领域的问题,常常涉及多个用户故事。我们可以将它看作是对所有相关开发工作收取“课税”。例如:开发Web应用时,要求所有开发者对Http表单中的字段进行数据校验即为一种约束。
处理第一类NFR很简单:创建一系列的NFR用户故事,将它们加入某种工作序列,例如Product Backlog。
然而处理第二类NFR则困难很多。敏捷专家们对此提出过一些解决办法,包括:
但无论哪个方法都无法解决的问题是,如何针对特定的用户故事选择适用的约束。而且,使用SD Elements进行安全需求匹配的经验表明,要将这些技术限定在一定范围之内很困难。下面这个列表是标准Web应用需要面对的安全约束中的一部分,我们以此为例:
该列表列举的可能只是程序员在实现用户故事时需要考虑的安全约束中的一小部分。若将需要遵循的法规标准——诸如支付卡行业数据安全标准(PCI DSS)之类——考虑在内,约束还要增加不少。如果你开始添加其他NFR约束,例如可访问性,约束列表会快速增长,转眼间就会超过程序员的承受范围。一旦列表变得臃肿,我们的经验是,程序员往往会将它全部忽略,仅根据自己的记忆来应用NFR约束。而在很多不断专业化的领域——例如应用安全——NFR的数量不断增长,这给程序员的记忆力造成了沉重的认知负担。因此,如何使用静态分析技术侦测代码中违背NFR约束之处就成了关注重点。研究表明,静态分析可以侦测出的可预防缺陷最多不超过总数的40%,也就是说仍有大量的约束漏网,包括特定领域的安全控制,更别说在缺乏定制的情况下辨别静态分析产生的“假阳性”结果也不是那么简单。
为了解决NFR约束过多的问题,我们需要做到以下四点:
虽然主动处理NFR很重要,但仍有必要进行验证。如果你有手动代码审查(Code Review)的经验,就可以检查用户故事中作为验收标准出现的NFR。然而,如果仅使用手动代码审查,很多约束的验证将是非常棘手或者繁重的。静态分析工具则可以自动检查编码标准的遵守情况,其中一些产品特别关注安全方面。将你的静态分析工具与持续集成过程整合在一起,可以帮助你始终遵守编码标准。但也务必注意,不要一味依赖于代码审查。防范特定领域缺陷——如HTTP参数篡改——的NFR要求对背后的业务领域有深刻的理解。将手动验证与针对特定攻击的自动测试结合起来,可以帮助我们建立一套对于特定领域缺陷拥有更强抵抗力的系统。
难以将安全需求集成进敏捷项目的另一方面原因是安全需求通常缺乏可见度。面向客户的会议,如Scrum的Sprint评审会议),容易使开发人员产生一种固有的倾向,即实现用户故事或修复缺陷时倾向于那些能直接改善用户体验的故事或缺陷。一部分非功能属性,例如易用性和性能,对于系统的使用体验有具体的影响,因此也比较容易向客户展示。而另外一些——如安全性——却很难在Sprint评审会议上给客户留下很好的印象。实际上,某些安全特性,如账号封锁(Account Lockout),可能给客户体验带来相当负面的影响。大多数安全特性对系统的影响,普通用户很难察觉。因此,安全性NFR是不可见的,它们必须和可见度更好的特性竞争,以夺得宝贵的开发周期。在软件开发初期,准确的说在程序员应该构建安全特性的时候,处理这些“隐形”需求的机会成本会特别高。
让安全特性可见
对于敏捷团队来说,没有“银弹”能让安全需求在开发伊始就拥有最高优先级。但有一些方法可以让安全NFR对客户和/或PO可见。
图形化安全用户故事:如果你在应用程序安全方面足够专业,就可以针对已知的安全弱点创建一套全面的安全控制。然后将它们与NFR用户故事匹配起来,并绘制简单的图形,用以说明系统中已实现的和未实现的安全用户故事数量。这个图可以放在大型可视图表中。
图1:安全用户故事图
当然,这个图没必要局限于安全用户故事,你可以将其他重要的NFR囊括进来。实际上,你可以使用故事点(Story Point)取代用户故事数量,从而更准确的反映工作量。另外,你有可能希望图中只记录那些针对高风险安全问题的、拥有最高优先级的用户故事或控制。每完成一个故事,“已完成”数量都会增加,客户也会籍由此图直观地了解项目的进度。
展示可利用性(exploitability):没有什么比可利用性展示更能让人们理解一个安全漏洞的各个方面了。这是安全性渗透测试和漏洞评估的主要区别。你可以展示在上一版本的应用中如何成功地利用了漏洞,而在新的版本中却没办法这么做了。然后你可以从对业务和/或客户影响的角度解释漏洞的方方面面。这非常有利于解释为什么在安全控制上花的时间是合理的。
主动处理NFR,特别是安全特性,在敏捷环境中非常重要。不少专家对于如何处理此类需求——特别是当它们与创建用户故事相关时——给出了建议。全面地处理约束是个相当大的挑战。记住本文讨论的提议,你可以极大地增加维护一系列约束的价值。即使不能完全做到以上所提的四点内容以改善对约束的管理,但从长远来看,任何一点改进都能带来很高的回报。进行验证能保证团队始终遵守NFR。最后,提高安全特性的可见度,可以让你证明用在NFR上的时间是合理的,就算它们对系统的改善不能反映到用户体验上。
Rohit Sethi( @rksethi on Twitter)是一位安全领域的专家,他致力于将安全控制构建到整个软件开发生命周期中(SDLC)。他曾帮助一些对安全相当敏感的企业改善软件安全性,涉及的行业包括金融服务、软件、电子商务、保健以及电信等。Rohit创建并讲授针对Secure J2EE开发的SANS课程。他曾在以下机构讲学:FS-ISAC、RSA、OWASP、安全开发会议(Secure Development Conference)、Shmoocon、CSI National、SecTor、Infosecurity、CFI-CIRT等等。他曾在InfoQ、Dr. Dobb’s Journal、TechTarget、Security Focus以及 Web Application Security Consortium (WASC)上发表过文章,上过 Fox News Live,还曾被 ITWorldCanada和 Computer World以应用安全专家的身份引用过。另外,他还创建了 OWASP Design Patterns Security Analysis项目。
查看英文原文:Managing Security Requirements in Agile Projects