背景
在企业SDL(安全开发生命周期)实践中,安全需求至关重要的。软件开发的生命周期中,需求收集和需求分析占据了核心地位。产品经理需要确保通过多种渠道收集和汇总后的产品需求的完善程度。在需求分析阶段,他们还需要结合产品功能特性、自身从业经验等多方面筛选有价值的需求,辨别需求的真伪。
特别是在企业的SDL安全建设过程中,需求收集和需求分析阶段还需要加入的一个关键点就是Security。如果产品在一开始的需求收集和需求分析阶段只考虑了产品的功能性实现而忽略了安全需求或者需求本身的安全问题,那么在产品上线后将随着时间的推移不断涌现各种安全问题。这可能导致产品遭受重大损失,甚至可能需要产品下线重构。
安全开发生命周期的管理是保障互联网企业业务正常运营的重要举措,直接关系到企业线上业务运行的安全性。企业办公安全涉及的安全隐患则更加复杂多样,包括数据泄露、人员违规、外部入侵、物理安全等问题。
安全需求在SDL实践中是为了确保软件产品从设计到上线的整个过程中都能满足安全性要求,从而降低潜在的安全风险,保障企业和用户的利益。
目标
SDL安全需求的主要目标是帮助开发人员构建更安全的软件,解决安全合规要求,同时降低开发成本。
安全考量
1. 法律法规:在软件需求分析阶段,需要关注可能涉及的法律法规需求问题。这包括确保软件遵循相关行业法规、保护用户隐私和数据安全等方面的要求。例如,对于金融行业的软件,可能需要满足金融监管机构的规定;对于涉及用户个人信息的软件,需要遵循相关的数据保护法规。
2. 隐私安全:在软件需求分析阶段,需要充分考虑用户在使用软件产品时的隐私安全问题。这包括对用户数据的加密存储、传输过程中的安全保障以及对敏感信息的保护等。例如,可以采用SSL/TLS协议对数据传输进行加密,使用哈希算法对用户密码进行加密存储等。
3. 业务安全:在软件需求分析阶段,需要关注软件自身业务功能设计的安全问题。这包括对软件的业务逻辑进行安全性评估,确保不存在安全漏洞和潜在的攻击风险。例如,可以对软件的输入输出进行合法性检查,防止SQL注入、跨站脚本攻击等常见的安全漏洞。
备注:这里仅讨论软件开发过程中涉及到的安全问题,不涉及主机安全、中间件安全、部署安全等问题。在实际开发过程中,还需要关注其他方面的安全需求,以确保软件的整体安全性。
安全活动
1.安全评估流程宣贯:在项目立项时,安全团队需要对产品安全评估流程进行宣贯。虽然关注点主要集中在产品的功能上,但安全评估流程的宣贯仍然非常重要。特别是对于项目(产品)经理来说,这一步骤是为了确保所有相关人员都了解并理解在整个软件开发过程中应如何考虑和实施安全问题。
为了确保自研项目的安全性,在各个阶段都加入安全检查。这包括:
安全需求分析:在需求分析阶段,安全团队需要提出具体的安全需求,并确保这些需求得到充分考虑。
安全设计:在设计阶段,安全团队需要与开发团队合作,确保软件的设计满足所有的安全要求。
安全开发:在开发阶段,开发团队需要遵循安全编码规范,确保软件的实现满足所有的安全需求。
安全测试:在测试阶段,安全团队需要进行详细的安全测试,以确保软件没有安全漏洞。
发布审核:在发布前,安全团队需要对软件进行最后的审核,确保它满足所有的安全要求。
此外,系统发布上线前应设置卡点,确保软件满足各项安全要求才能顺利上线。如果软件不满足安全要求,需要经过一系列流程找到多位负责人和CTO同意,走绿色通道。在这个过程中,需要明确相关责任人以及后续的整改计划。
2.提出安全需求:基于对可能的威胁和风险的理解,安全团队需要提出具体的安全需求。这些需求应该明确指出软件必须具备哪些安全功能或特性,以防止潜在的攻击或滥用。
- 安全需求基线
安全需求基线是一个信息系统的最小安全保证,即该信息系统最基本需要满足的安全要求。它是为了在安全付出成本与所能够承受的安全风险之间找到一个合理的平衡点。
全基线=安全能力+安全能力上配置的安全策略,是为了满足业务可用性、保密性和完整性需求而使用的安全能力,以及为业务系统配置的安全策略。例如
对于内部系统,安全需求基线可能包括主机漏扫和Web漏扫,确保没有高中危漏洞。
对于对外发布系统,除了满足内部系统的安全需求外,还需要满足安全设计checklist、代码审计、人工安全测试等要求。
对于外部采购的产品,供应商需要提供产品安全证明材料,并在签订合同时包含安全责任协议和应急止损售后服务条款。
此外,不同的组织或公司可能会有自己的安全需求基线。例如,华为基于过去十年管理产品安全的实践经验,并参照广泛的外部法规、技术标准、监管需求而提炼形成了自己的安全基线。这些基线与其其它治理机制共同有效地保障了产品的安全可信和高质量。
- 业务安全需求
业务场景的安全需求分析需要根据具体的业务环境和操作来确定。例如,对于涉及文件上传、个人信息编辑等功能的业务,通常需要重点关注并进行分析,因为这些功能通常会发生安全漏洞。
在进行安全需求分析时,首先需要明确主要的输入因素。这些因素可能来自外部,如国家或企业所属行业出台的网络安全法规;也可能来自内部,如企业的业务流程和信息系统的安全目标。
在分析方法上,常用的包括误用和滥用案例、滥用框架、反模型、横切威胁和安全质量需求工程(SQUARE)等。其中,误用用例方法主要从功能性用例的文本描述中分析可能存在的安全漏洞并识别出对应的威胁,建立威胁用例,针对威胁用例建立安全需求用例。滥用用例方法主要用于捕获攻击者与系统之间的交互所产生的威胁,重视对攻击者的描述,主要对攻击者的企图、攻击能力进行评估。
3.声明安全质量要求:安全团队还需要声明软件最终上线前的安全质量要求。这些要求可以帮助开发团队明确他们的工作目标,并确保他们开发出的软件满足所有的安全标准。
- 内部系统:
- 主机漏扫:确保主机没有高中危漏洞。
- Web漏扫:确保Web应用没有高中危漏洞。
- 对外发布系统:
- 安全设计checklist:遵循安全设计checklist,确保系统的安全性。
- 代码审计:进行代码审计,发现并修复潜在的安全问题。
- 主机漏扫:对主机进行漏洞扫描,确保没有高中危漏洞。
- Web漏扫:对Web应用进行漏洞扫描,确保没有高中危漏洞。
- 人工安全测试:进行人工安全测试,发现并修复潜在的安全问题。
- 外部采购产品:
- 提供产品安全证明材料:要求供应商提供产品安全证明材料,包括第三方安全公司出具的报告、代码审计报告、主流扫描器漏扫、渗透测试报告以及开源组件清单(系统依赖的开源组件类型和版本信息)。
- 安全责任协议和应急止损售后服务:在签订合同时,包含安全责任协议和应急止损售后服务条款,明确双方的安全责任和应对措施。
常见的问题与难点
在SDL(安全开发生命周期)中,安全需求阶段的确是一个复杂且具有挑战性的部分。
- **安全需求的挖掘深度**:有时,对于某些项目,可能很难准确定义和识别所有的安全需求。这是因为安全需求可能与业务需求、功能需求或其他非功能性需求相互交织,导致难以明确地分离和界定。
- **对安全需求的理解和共识**:在团队内部,可能存在关于安全需求的误解或不一致的认识。确保所有相关方,包括开发人员、测试人员、项目经理和其他利益相关者都对安全需求有统一和清晰的理解是至关重要的。
- **需求收集和分析**:在需求收集和分析阶段,可能会遇到困难,因为需要深入挖掘产品需求以了解其中的安全风险和威胁。此外,如何将安全需求与其他类型的需求(如性能、可用性等)整合也是一大挑战。
- **变更管理**:在项目的后续阶段,可能会出现需求变更的情况,这可能会影响到原有的安全需求。如何妥善处理这些变更并确保不会对安全性造成负面影响是一个问题。
为了有效地应对这些问题和难点,建议采取以下措施:
- **持续的安全宣贯和培训**:确保团队成员对安全的重要性有充分的认识,并定期更新他们的知识和技能。
- **明确的角色和责任**:为团队设定明确的角色和责任,确保每个人都知道自己在安全需求阶段的职责所在。
- **与利益相关者紧密合作**:与项目经理、业务分析师、设计师等其他利益相关者紧密合作,确保从多个角度考虑和定义安全需求。
小结
SDL安全需求阶段是一个复杂而关键的过程,它需要对系统进行全面的分析和梳理,与利益相关者进行充分的沟通和合作,同时考虑法规和标准的要求以及行业的最佳实践。
4A评测 - 免责申明
本站提供的一切软件、教程和内容信息仅限用于学习和研究目的。
不得将上述内容用于商业或者非法用途,否则一切后果请用户自负。
本站信息来自网络,版权争议与本站无关。您必须在下载后的24个小时之内,从您的电脑或手机中彻底删除上述内容。
如果您喜欢该程序,请支持正版,购买注册,得到更好的正版服务。如有侵权请邮件与我们联系处理。敬请谅解!
程序来源网络,不确保不包含木马病毒等危险内容,请在确保安全的情况下或使用虚拟机使用。
侵权违规投诉邮箱:4ablog168#gmail.com(#换成@)