前言

软件开发安全生命周期SSDLC(Secure Software Development Lifecycle)是微软提出的从安全角度指导软件开发过程的管理模式，在传统软件开发生命周期SDLC(Software DevelopmentLifecycle)的各个阶段增加了一些必要的安全活动，目的是减少软件中的漏洞数量和降低其严重级别。主要分为以下阶段：安全需求->安全设计->安全开发->安全测试->安全运营。SSDLC的基本思路是将安全工作左移，侧重在事前事中做好安全控制，而不是在事后修补。

需求分析流程

需求分析是解决应用系统“做什么”的问题，需求分析的好坏直接影响着开发生命周期的后续阶段。对于同一项需求，不同的人有不同的描述，如用户需求、软件需求、功能需求、系统需求、技术需求、业务需求或产品需求。

下图展示了需求说明书的产生过程：

非功能需求主要是描述产品的特性：安全、性能。约束主要涉及技术选型（如公司应用架构限制）、运行环境（云环境/传统环境）、使用环境（H5/Web/Android/Ios等）

项目经理负责整个项目的规划，业务分析师挖掘用户需求，产品经理将用户需求转化为开发人员能看懂的功能需求，而安全和架构师负责将非功能需求和约束条件加入需求说明书里。

安全需求分析方法

广义来说：应用系统的安全需求就是要实现机密性、完整性、可用性的目标。另外安全需求分析跟风险分析是密切相关的。风险分析主要有3个要素：资产价值、威胁可能性、系统脆弱性。比如交易系统和内容发布系统的资产价值是不同的，网络游戏系统更容易遭受攻击，不同的技术选型也会本身具备先天的脆弱性。由于安全需求是非功能性需求，安全是为业务服务的，安全需求分析前必须要熟悉业务背景：

可以通过几个问题来确认安全人员对分析的目前是否有基本的了解：

1.应用系统的商业价值是什么？盈利模式？

盈利：对用户免费,通过广告或流量获取收益；对用户收费，出售实体商品、虚拟商品或作为中介平台收手续费。

非盈利：成本（OA办公类应用），公益类应用。

2.应用系统的开发迭代计划？如何推广营销？

产品开发迭代计划，一期二期三期的主要目标是什么？哪些不同阶段在线上开展的业务有哪些差异？如何推广营销，比如如何拉新用户，促进现有用户的活跃度，是否推出增值服务增加营收？

3.应用系统的主要用户群体，用户的收益，在哪些国家地区运营？可以识别对应风险

用户的主要阶层分布、年龄分布，用户对什么安全问题敏感，隐私泄露，资金损失，品牌形象还是服务质量？所在国家地区是否有特殊合规要求，如东南亚、欧洲、美国法律差异。如数据跨境传输政策，隐私政策。

通过以上的分析我们能够确定哪些资产是有价值的，是需要重点保护的。我们可以对信息进行分类分级：秘密、机密、绝密、公开。不同级别数据采用不同级别的安全控制，避免有限资源的过度耗费。

另一方面我们可以获取到合规的需求，不同的行业受到不同监管部门的要求，如物流行业实名制、金融行业反洗钱等各种合规需求。

接下来需要分析威胁和脆弱性，可以从人员、流程、技术三方面来确定安全需求：

人员

人往往是信息安全中最薄弱的环节，必须有规范制度来约束人员的行为。每个人员的角色及任务，所需承担的责任必须明确。

比如通过培训、不同角色与职责设置、进行严格人员管理（保密协议、背景调查）、确定制度规范。对内部人员恶意操作风险和外部的钓鱼社工风险进行基本防范。

如下是角色权限矩阵示例：

我们需要应用系统的外部行为和内部特性，确保角色权限的合理设计。

技术

业务是基于IT技术来实现的，我们需要根据业务特点，采用不同的技术。如网络、基础架构、操作系统、应用系统、监控系统等必须作出多层次的防御，单一层面控制失效时，其他层面仍可确保系统安全。

我们可以根据业务特点设置不同级别的基础设施，比如私有云方案包括医疗云、政务云、金融云，每个云环境提供不同级别的防火墙、NAT、IDS、防病毒、应用监控等深度防御策略增加攻击者成本。另外我们根据业务选用不同的技术框架，比如应用系统是给各门店营业员用的，我们通过专线技术可以避免服务对互联网开放，通过专门的定制设备(ipad、柜员机等)可以避免不安全的使用环境，目标是用最小代价实现必要的安全控制，确保技术成本和安全收益的平衡。

流程

流程设计是需求的重要部分，在人员或技术上控制无法解决安全问题，就需要通过设计流程来降低安全风险。人员不可避免会出现操作失误或主观恶意破坏，比如更改应用系统配置参数，这种风险无法通过技术或培训宣导进行事前事中的控制，可以通过流程上审批确保操作是合理可控的。再比如内容发布，技术上无法自动识别内容是否合规，是否涉及不良信息或敏感信息，需要通过流程审批确保内容安全，毕竟申请人审批人合谋或者同时疏忽的风险比较小。

流程上安全控制分为：威慑性、预防性、检测性、响应性、恢复性的流程

阻吓性：规范、守则、警告、培训。比如用户使用协议，如果用户行为失当，将追究用户责任。防止性：职责分离、访问控制、最低权限。确保重要操作不能单人完成。侦察性：监控告警、日志审查。响应性：需要制定应急响应预案，出现安全事件时能联系到处理人，在指定时间响应。恢复性：高可用、备份、系统恢复，危机公关。

安全需求分析工具探索

由于安全需求分析工作需要大量的人力投入，安全部门往往无法满足。因此需要把常规安全需求分析工作下放到产品经理或者架构师来完成。这就涉及到安全需求分析工具，这里使用了问卷和推荐系统两种方式

问卷系统

问卷设计的主要方法:

1．通过高频重点问题如整合内审、外审、外部漏洞上报、SOC安全事件的分析发现的问题来设计问卷

2．通过监管合规的最新要求来设计问卷

3．通过行业动态和威胁情报来设计问卷

如下是一个示例：

问卷的优点：

实现简单，只需要进行内容设计，配合一个现成的问卷系统就可以开展安全工作。

问卷的缺点：

问卷缺乏针对性，更新缓慢，问卷填写容易变成形式化工作。

推荐系统

由于问卷存在的一些问题，需要探索新的需求分析工具，基本思路还是要将复杂的安全需求分析过程可视化，规范化。经过调研，发现基于知识图谱的推荐系统比较适合。

知识图谱本质上是一种揭示实体之间关系的语义网络。建立知识图谱的过程就是从文本中抽取三元组信息，包括“实体-关系-实体”以及“实体-属性-实体”两类，然后把三元组信息存储在数据库里。

比如我们的一个远程办公安全需求：员工远程办公的访问控制应该采用双重认证的方式，远程办公的信息在传输过程中必须加密。需要转换成为一条能在数据库里存储的知识。

信息抽取：员工—进行à远程办公—必须à双因素认证员工—进行à远程办公—必须à加密

建立的知识图谱如下：

通过这种方式，我们可以把公司制度、外部文件、威胁情报、历史事件、审计发现、业务安全风险汇总产生安全需求库。实体就是人员、流程、技术在需求分析中最重要的三个因素，关系就是不同类型的安全要求，包括禁止，要求，建议等，比如禁止匿名用户访问，要求传输加密，建议前端敏感信息掩码。

以下是实体和属性的信息：

建立了需求库只是第一步，让数据库发挥作用还需要对提取每个需求文档的关键标签，再针对性查询数据库，就可以得到精准的安全需求推荐。

需求文档通常以word、excel、ppt形式保存，也有的是通过需求管理系统在线存储，通过把需求转换为结构化数据，然后对数据进行分词，通过文本摘要算法提取关键词标签，再针对标签进行数据库查找，最终效果如下：

知识图谱可以不断扩展，根据重要性进行安全需求优先级排序。

总结

安全需求分析是SSDLC的第一个环节，而安全需求分析缺少合适的工具，更多依赖安全专家的经验，通过将专家知识、制度要求、历史安全事件、审计发现、业务风控发现汇总形成知识图谱，可以降低安全需求分析的难度和工作量，实现定制化安全需求推荐系统。

*本文作者：随便看看，转载请注明来自FreeBuf.COM