宜信SDL实践：产品经理如何驱动产品安全建设

1、序言

本文从产品经理的角度出发，对产品经理的安全职责、产品驱动安全的内涵、工做内容、工做方法、所需安全资源、以及产品经理的安全工做量进行了分析。但愿全部产品经理在没有心理负担的状况下，有目标、有方法、有资源推动产品安全建设。

2、背景

安全是软件产品自然属性的一部分，“无安全不金融”，对于金融软件产品而言，安全尤其重要，由于客户老是可以从各类安全漏洞联想到他的金融资产安全和我的信息安全。之前偶尔会在一些安全沙龙或峰会听见同行吐槽，“信息安全提及来重要、作起来次要、忙起来不要”。吐槽背后的缘由很复杂，其中很重要的一点是跟产品经理安全意识淡薄、不清楚如何推动产品安全建设有关，好比不重视产品安全属性、产品安全需求不明确、产品安全资源不充分、产品安全建设无从下手等。本文主要站在产品经理的角度，从产品经理能力维度出发，探讨产品经理如何推进产品的安全性建设。

众所周知，安全性做为软件产品的自然属性，从产品定义与规划角度来看，产品经理对产品安全负有不可推卸的责任，但产品经理如何履行本身的安全职责，业界尚未给出一个清晰可行的行动方案。

目前，软件产品安全需求一般是基于开发人员和安全人员的职业常识提出相应的解决方案，好比目前业内比较通用的敏感信息五要素分析方法：

1	2	3	4	5
姓名	身份证号	电话号码	银行卡信息	联系地址

这种方法简单易行，但每每不能涵盖全部的敏感信息，好比

• 用户的多系统用户数据关联ID（超级ID）。
• 交易过程当中的音视频等多媒体数据。
• 各类非结构化的文档数据，如合同扫描件。
• 用户的行为画像数据等内容。

这些信息均为有价值的敏感数据，显然不属于前述的敏感数据范围，但每每没有明确的防御要求。从特定业务场景出发，产品经理对敏感数据范围及其业务价值最有发言权。

3、安所有门的尴尬

前述的敏感信息五要素分析方法是典型的安全驱动产品的方法，即安所有门推进产品相关各团队的安全工做开展。这种模式存在不少弊端，好比：

• 安全需求可能不完整，职业常识代替不了特定业务场景的深度分析；
• 产品各团队的安全工做资源没法保证，研发团队有理由认为安全团队干扰研发计划，研发进度与资源不变的状况下，额外增长了工做量；
• 安所有门一般没机会参与制订研发计划，产品研发计划与安全脱节；
• 安全团队高度依赖话语权，强制性驱动每每陷入窘境。

（图1 安全驱动产品）

众多的安全实践代表，安全驱动产品的思路与方法存在众多弊端，若是反过来，产品驱动安全，让产品经理明晰本身的安全职责、主动推进产品的安全建设，就会产生对比鲜明的效果。

4、产品驱动安全的合理性

产品驱动安全并不是意味着产品经理单一角色推进产品的安全建设，而是说产品经理主动承担相应的产品安全责任，主动与安所有门一块儿推进产品的安全建设，由安全驱动产品的单轮驱动转变为产品驱动安全的双轮驱动。以下图所示：

（图2 产品驱动安全）

安全是软件产品的自然属性，是产品经理职责的一部分。同时产品经理做为产品规划演进与研发资源投入的指挥棒，能够保证研发团队在安全上的适度投入。经过简单分析，产品经理承担产品安全责任，主动推进产品安全建设应该是十分合理的逻辑。

5、产品如何驱动安全

产品经理有意愿作好产品安全，可能会问以下几个问题：

• 内容方面，产品经理须要作哪些安全工做；
• 能力方面，为了完成这些工做，产品经理须要具有什么样的安全能力；
• 方法方面，这些安全工做如何作，才能既兼顾产品业务功能研发与安全，又能保持研发敏捷性和项目管理流程不变形；
• 安全资源，从安所有门和其余部门能够获取哪些安全支持，来提高本身和研发团队安全工做的效率和效果，下降安全工做的能力门槛；
• 工做负担，安全工做会不会让产品经理很辛苦，影响其工做品质和生活品质。

为产品经理解决了以上问题，消除其后顾之忧，产品经理才有可能大几率地拥抱安全，从根本上解决研发与安全间的矛盾。

6、产品经理的安全工做内容

产品经理的安全工做内容大体以下：

• 明确产品安全需求；
• 保障安全研发资源，将安全工做设定到研发计划中，并分拨足够的安全研发资源；
• 推进研发团队安全能力建设，确保研发计划中的安全工做执行到位;
• 整合周边安全资源，确保研发计划中的安全工做执行到位。

（图3 产品经理的安全工做内容）

6.1 明确产品安全需求

产品安全需求是指站在业务角度，软件产品须要知足的数据安全需求、业务合规需求和业务连续性要求，它是业务安全需求的一部分。本文描述的产品安全需求一般包括：

• 产品承载的业务数据安全防御需求，主要关注点是业务数据的机密性和完整性。
• 产品相关信息的安全监管要求，如等级保护、行业信息安全监管等要求。
• 产品承载的业务连续性要求。因为一般由数据中心或运维部门统一牵头实施该项任务，本文将不会展开描述该项内容。

（图4 产品安全需求）

6.2 产品数据安全需求

产品数据安全需求是指系统安全体系应确保恰当的用户在恰当的时间与地点以恰当的途径用恰当的动做访问恰当的数据，确保其承载数据的机密性、完整性和可用性。即系统安全体系应确保相似于白名单的合法访问行为清单，只要属于清单范围内的行为均为合法行为，白名单行为以外的行为都是默认不恰当的数据访问行为，须要安全措施进行预防，本文称之为黑名单行为。

因为黑名单行为一般为黑客攻击行为，其典型行为的分析与罗列须要较强的攻防技术背景，不在业务人员和产品经理能力范围以内，须要安全专家根据产品运行环境进行分析，因此本文要求产品经理明确的产品安全需求一般为其白名单部分，黑名单部分须要产品经理组织安全专家和研发专家配合明确。产品设计所包含的各类安全措施主要目标就是确保白名单行为必定成功，黑名单行为必定被预防、监控和审计。

从业务安全角度出发，定义合法数据访问行为以后，还须要有数据访问行为审计手段，帮助业务确保访问行为的正确性，以及对违规的数据访问行为进行审计。

（图5 产品数据安全需求）

基于上文分析，白名单行为清单的明确只须要了解业务模型相关信息就能够作到，对于产品经理而言，不存在能力上的门槛。过程当中产品经理须要明确的数据包括：

ID	内容	说明
1	合法用户清单	系统用户类别、办公地点与访问方式，用户类别应包括有接口调用关系的对端系统
2	敏感数据清单	敏感数据范围与清单，及其分类、分级说明
3	业务访问行为清单	系统用户与敏感数据之间的访问映射关系与操做方式清单
4	敏感行为清单	须要记录业务操做日志的最小集合，为业务审计提供依据，该清单与上面的业务访问行为清单基本重合

在明确上述信息的过程当中，产品经理应遵循以下两个原则：

ID	原则	解释
1	最小权限	将用户对数据的访问操做的方式和动做最小化，如对于某个用户类别，OA网访问可知足业务需求的就不该开放到外网访问，数据脱敏可读可知足业务需求的状况应不开放明文可读或可写权限
2	知所必需	将用户的数据访问范围最小化，如对于某个用户类别，单个文件访问能够知足业务需求，决不开放2个或多个文件访问

设计人员能够根据该白名单进行权限管理与访问控制模型设计，测试人员能够将白名单做为数据安全测试基线，任何违背白名单的测试发现均为系统的安全bug，好比：

• 敏感数据未脱敏。
• 多余的数据操做权限。
• 横向或纵向数据访问越权。
• 关键行为的日志痕迹缺失。

6.3 合规性需求

合规性需求是指因为系统运行地点、服务网络以及客户所在地区或国家相关部门，对服务提供模式、数据安全以及业务连续性提出了限制性要求。目前公司系统所面对的主要监管要求包括：

ID	监管要求	监管层级
1	网络安全法及其两高释法（国家）	国家
2	信息系统等级保护（公安部）	公安部
3	我的信息保护规范（工信部）	工信部
4	GDPR（涉及到服务欧盟公民的相关IT服务）	欧盟

2019年国家相关部门提出了一系列App收集我的信息相关监管要求：

ID	名称	时间	发文部门
1	关于开展App违法违规收集使用我的信息专项治理的公告	2019/1/25	中央网信办、工业和信息化部、公安部、市场监管总局
2	移动互联网应用基本业务功能必要信息规范	2019/6/1	全国信息安全标准化技术委员会
3	App违法违规收集使用我的信息自评估指南	2019/3/1	APP专项治理工做组
4	App违法违规收集使用我的信息行为认定方法（征求意见稿）	2019/5/5	APP专项治理工做组
5	信息安全技术 移动互联网应用程序（App）收集我的信息基本规范（草案）	2019/10/25	全国信息安全标准化技术委员会
6	关于开展APP侵害用户权益专项整治工做的通知	2019/11/6	工业和信息化部

在产品经理罗列出合规要求、安所有获得相关部门的权威解释后，与产品线沟通建议各类安全措施设计，将会在很大程度上知足IT安全合规要求。等级保护相关要求为全部系统须要面对的共通要求，无需产品经理罗列，安所有能够直接解释。

关于具体安全需求的定义与维护方法，笔者将经过其余文章进行说明。

7、产品经理安全能力分析与建设

分析产品经理的安全工做内容，最主要的考验来自于明确业务安全需求的四个清单。相关安全能力分析以下表：

ID	产品经理安全需求工做内容	能力分析
1	明确合法用户清单	无需额外能力，须要描述模板支持
2	明确敏感数据清单	须要理解安全基础概念，在指定敏感数据安全等级时，须要敏感数据分类分级标准支持，须要模板支持
3	明确业务访问行为清单	无需额外能力，须要描述模板支持
4	明确敏感行为清单	无需额外能力，须要描述模板支持

产品经理其余安全开发工做所需能力分析以下：

ID	工做内容	能力分析
1	保障安全研发资源	在产品迭代研发计划中增长安全相关活动与环节，并指定责任人。计划制订自己无需额外能力，但在安排相关安全活动时，为保持开发的敏捷性和现有的项目管理机制不变形，须要安全、质量管理和项目管理等部门提供方法论支持。须要产品经理有必定的安全意识。
2	推进研发团队安全能力建设	为了保证迭代研发计划中的活动执行成功，研发团队（设计、开发和测试）须要较高的安全意识和一些基础的安全能力，如安全设计、安全编码和安全测试。安所有应统筹各团队的安全能力建设需求，提供相关安全能力建设支持。须要产品经理有必定的安全意识。
3	整合周边安全资源	为了保证迭代研发计划中的活动执行成功，须要整合周边部门的专业性安全服务，好比安所有的各种安全评审服务、威胁建模、代码审计、渗透测试、流量实时监控等服务，基础研发部的SSO平台，运维的统一身份管理服务等等。甚至须要法务与合规等部门的安全支持。安所有门有责任提供和维护一份持续可用的安全服务清单，让产品经理和研发团队知晓服务清单，并知晓何处获取相关安全服务。须要产品经理有必定的安全意识。

综上所述，产品经理要履行相关安全职责，必要的能力和素质是具备较高安全意识，可以理解相关安全基础概念，没有太高的能力门槛，经过必定的安全培训，产品经理彻底能够达到相应的能力要求。

8、产品安全研发方法

针对目前敏捷开发与DevOps开发广泛落地的状况，安全开发不该固守与瀑布开发相结合的陈旧经验。由于瀑布开发周期长、资源充分，在繁杂的计划活动中安排一些零星的安全活动不会产生明显的延期压力和资源压力。而敏捷开发和DevOps开发要求快速响应用户需求的同时，兼顾开发质量与效率，若是在迭代计划中设置太重的安全开发活动，迭代开发容易失去敏捷特性。

为了将安全开发理念在敏捷与DevOps开发中获得贯彻，建议采用以下原则：

• 安全开发活动轻量化。轻量化能够经过工具化、自动化来实现，尽可能减小人工耗费大和耗时长的安全开发活动；
• 安全开发活动分散化。将那些短时间没法轻量化处理的安全开发活动分解并分散到多个迭代周期中执行；
• 安全开发活动并行化。将安全开发相关活动与其余活动并行，如渗透测试一般安排在测试的最后一个环节，避免单轮次渗透测试没法覆盖那些并行的修复点，固然渗透测试也能够由多个轮次来弥补这种状况，但一般资源不容许。实际上这种同步修复致使渗透测试覆盖率降低的问题，彻底能够经过良好的沟通和团队文化建设进行弥补。
• 优化现有敏捷开发与DevOps相关的流程与工具平台，使得安全专家可以充分参与项目，提高安全开发沟通效率，快速获取安全反馈；
• 将安全专家归入到敏捷开发和DevOps文化建设中来，信息安全人人有责，安全专家能够充分发挥教练员角色和守门员角色，使得团队人人有能力履行本身的安全职责，安全专家在恰当的时机对安全交付物进行质量把控；
• 提早进行安全基础设施规划与布局，如身份与权限管理系统、SSO系统、加解密平台与SDK、日志分析与监控平台、全流量检测平台等等，使得安全措施标准化、服务化和平台化，下降安全设计与编码的能力门槛，对安全基础设施的测试与验证取代设施所承载应用的大部分安全测试，能够有效消减安全测试工做量。

对于一些安全开发活动的计划安排示例以下：

ID	安全活动名称	迭代执行要求	触发场景与基线示例
1	建立产品安全需求名单	一次性执行	产品原型发布以前
2	维护产品安全需求白名单	每迭代执行
3	评审产品安全需求白名单	多迭代执行	重大需求变动或累积变动开发量达到n人天
4	建立产品数据流图	一次性执行	产品原型发布以前
5	创建威胁初始模型	一次性执行	产品原型发布以前
6	维护威胁模型	每迭代执行	重大需求变动或累积变动开发量达到n人天
7	评审威胁模型	多迭代执行	重大需求变动或累积变动开发量达到n人天
8	安全设计评审	多迭代执行	重大需求变动或累积变动开发量达到n人天
9	代码扫描及其报告分析（开发）	天天/迭代执行
10	代码扫描及其报告分析（安所有）	多迭代执行	重大需求变动或累积变动开发量达到n人天
11	深度黑盒安全扫描	天天/迭代执行
...	...	...

上表中“多迭代执行”指的是按照必定要求，间隔多个迭代后执行一次。关于多迭代执行的安全活动须要制订一个执行基线，该基线无标准可参考，须要根据各产品线实际状况逐渐摸索调整。

安全活动的触发场景与基线不是固定的，随着团队安全能力与自动化、工具化程度的提升，多迭代执行的安全活动可能转变为每迭代执行；不是全部识别出来的安全活动都必须执行，一切以控制主要安全风险、不拖迭代项目后腿为基准。一般安全团队会与全部产品经理和项目管理进行屡次沟通，提出一个多方基本承认的安全活动触发场景与基线表，供产品经理参考。

9、产品经理获取安全资源支持

产品经理在履行各项安全职责时，须要周边部门提供的安全服务与支持包括但不限于：

ID	产品经理工做内容	所需资源或服务	提供者
1	明确产品安全需求白名单	敏感数据分类分级标准及其相关模板和Demo；产品安全需求变动发生判断标准	安所有
2	保障安全研发资源	安全活动清单及其迭代基线	安所有&QA
3	推进研发团队安全能力建设	安全培训与实操	安所有
4	整合周边安全资源	安全资源清单，包括安全咨询、评审、培训、开发包、平台或服务	安所有&法务&合规

10、产品经理安全工做压力分析

产品经理安全工做压力分析以下表：

ID	产品经理工做内容	产品经理工做压力分析
1	明确产品安全需求白名单	初次建立产品安全需求白名单的4张表格有必定的工做量，但属于一次性工做。产品经理也能够分批次完成，先完善主要信息，其它信息后续择机补充。后续产品安全需求白名单维护工做压力比较小，新增需求或变动只要不触动白名单4张表格的内容，就无需维护。实践代表，产品的用户、数据、访问白名单在通过少数几轮迭代后趋于稳定，不多有机会对表格进行变动。
2	保障安全研发资源	是迭代研发计划制订与推动工做的一部分，无需额外花费时间；每一年可能须要花费一天左右的时间参加安全培训，了解安全活动迭代安排基线，了解安全基础概念，了解产品安全需求制订与维护方法。
3	推进研发团队安全能力建设	在研发团队能力建设计划与方案中添加安全相关内容，可能会涉及到一部分预算和人天。能力建设推动过程当中可能涉及到一部分参加培训和演练的人天投入，但这部分资源占比应该会较小，构不成明显资源压力。可能存在一些安所有能力暂时没法覆盖的培训，须要外购，好比云安全、移动安全等，产品经理能够独立申请预算，或安所有跟产品线统筹统一申请预算。
4	整合周边安全资源	为解决已知安全问题，不少产品经理平常也在推动该项工做，成为平常沟通协调工做的一部分。主要是将这种被动的、个案化的行动转换为主动的、常态化的工做行为。目前公司有较为清晰的安全责任划分和流程，构不成明显工做压力。

上表描述了产品经理可能会遇到的主要工做内容，但并非所有内容。总体而言，会增长产品经理必定的工做量，但不会构成明显的工做压力。

11、小结

产品经理对产品安全负有责任，经过明确产品安全需求中的白名单指明产品安全目标，经过制订安全研发计划、推进团队安全能力建设和协调周边安全资源，实现产品安全落地。

通过简短安全培训后，相关工做均在产品经理能力范畴，工做量不会对产品经理造成心理压力，灵活的安全活动触发标准也不会影响研发的敏捷性。笔者在这里衷心指望各位产品经理放心大胆、一往无前地拥抱安全，和安所有一块儿不断地将产品安全推向新高潮。

12、感悟

在笔者的工做经历中，安所有门为了推进安全工做，老是想着法地“抱大腿”，指望借助外力以推进安全工做，却没有注意到产品经理这个“大腿”，只需觉醒其安全意识，这一“大腿”不只粗壮有力，并且有着主动拥抱安全的强烈动因。

安所有与产品经理合做，很容易创建基于迭代开发的常态化安全落地机制，而与其余部门合做，例如合规或法务，经常只在特定阶段推进特定安全工做的落地。建议各位应用安全同行和产品经理多多交流，由于：产品经理才是咱们安所有最须要拥抱的“大腿”！

做者：危国洪 郭建伟

来源：宜信技术学院