【SDL最初实践】安全需求

在软件安全开发生命周期中,安全需求并不是那么好做,具备投入人力大、效果不显著等特点,但其作用影响了整个软件的安全质量和周期。在没有系统化流程之前,可以量体裁衣,根据实际情况加入必要的安全活动。

01

开篇概述

为减少安全问题带来的损失,以及线上安全问题整改带来的成本,需要将安全工作进行前置。在需求分析阶段,应该对软件产品的风险进行评估,建立安全需求。由于产品多且功能繁杂、项目管理未覆盖到每条业务线、安全团队人员少等诸多因素,ROI是最头疼的难题。不过可以因地制宜,借助纵深防御思想并落实到该阶段,建立基本或通用的安全需求。

02

安全目标

安全团队通过参加立项或需求评审会议,宣贯安全评估流程,提出安全质量要求,引导输出安全需求。从而,避免安全活动影响业务系统上线发布,减少并消除产品安全隐患,提升业务安全能力。

03

安全活动

在需求分析阶段,安全活动可以包括:安全评估流程宣贯、提出安全需求、声明安全质量要求。

1)宣贯安全评估流程

项目立项的关注点聚焦在产品的功能,这时候不需要进行详细的安全评估流程宣贯,应该重点告知项目组成员关注安全流程与节点,特别是项目(产品)经理。

  • 自研项目各个阶段都要加入安全检查

安全需求-->安全设计-->安全开发-->安全测试-->发布审核

  • 系统发布上线前有设置卡点

需满足各项安全要求,才能顺利上线。否则需要经过很长流程找多位负责人和CTO同意,走绿色通道,但需要明确相关责任人与后续整改计划。

2)提出安全需求

△安全需求基线

如果最开始不清楚如何制定合理且有效的安全需求基线,可以根据后续安全活动中发现的“普遍”安全问题,从整改难度大和需要投入的时间长等角度,反向总结出基础安全需求,比如:

  • 域名备案号
  • Web系统强制使用https
  • 外购产品需要交付安全相关材料

△特定业务场景安全需求分析

具体场景中的安全需求分析,就得另当别论,此处会涉及到覆盖面的问题。并不是所有的业务场景都需要安全需求分析,比如:登录、注册场景是通用的,在没有变更的情况下,仅一次全面的安全分析即可;不涉及敏感操作的功能,也不需要考虑安全需求分析,比如:不涉及增删改查仅静态展示的功能;通常会发生安全漏洞的功能,需要重点关注,比如文件上传、个人信息编辑等。

3)声明安全质量要求

明确业务系统允许发布上线的安全质量要求:

  • 内部系统:需要满足主机漏扫无高中危漏洞、web漏扫无高中危漏洞;
  • 对外发布系统:需要满足安全设计checklist、代码审计、主机漏扫、web漏扫、人工安全测试均无高中危漏洞;
  • 外部采购产品:需要提供产品安全证明材料,并在签订合同时须包含安全责任协议和应急止损售后服务。安全证明材料一般是指第三方安全公司出具的报告,包括:代码审计报告、主流扫描器漏扫、渗透测试报告以及开源组件清单(系统依赖的开源组件类型和版本信息)。

04

常见难点

安全需求在执行的初期,或多或少会遇到覆盖面不足、分析点不够深入等困难,以下梳理出较为常见的几点供大家思考与探讨。

  • 业务覆盖面不足

安全需求分析虽然将安全活动与项目管理相结合,但还是存在未覆盖的情况。故应该推动与协助项管去解决覆盖问题(规范公司的立项流程,增加人手等方式)或另寻其他方法补漏,确保所有项目都能通知到安全团队。

  • 新增功能点未覆盖

目前仅针对新立项的项目,对于老项目新增功能点或功能需求变更,并没没有做要求。随着后续团队人员增加、更加成熟的自动化方案,将在覆盖面的基础上细化到功能点。

  • 安全需求分析不够深入

主要是基于普遍存在且需要较长时间去解决的问题,统一提前到需求分析阶段来做安全需求基线。具体到每一个产品的安全需求并不够深入,后续可以针对核心产品进行试点运行。


原文发布于微信公众号 - 我的安全视界观(CANI_Security)

原文发表时间:2019-04-11

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

扫码关注云+社区

领取腾讯云代金券