“为了减少产品设计带来的安全隐患，避免后续发现问题时，对功能实现流程甚至程序架构大刀阔斧改动带来高昂代价。在产品设计阶段，需要加入必要的安全活动，减少并消除产品安全隐患，纵深提升业务安全能力。” 01 — 安全目标 安全团队可以通过引导相关责任人进行自检，要求输出安全检查结果，并推动落实安全整改项来开展安全活动。在此过程中，需关注以下四个基本要素： 安全介入时间：产品设计阶段。 安全介入时间：产品设计阶段。 推荐执行角色：产品设计人员或技术架构师（一般而言技术架构师，即开发总负责人。产品中会涉及不同功能模块，若是不同的开发独立负责，则需要开发总负责人组织各开发进行安全自查、统一反馈）。 推荐执行角色：产品设计人员或技术架构师（一般而言技术架构师，即开发总负责人。产品中会涉及不同功能模块，若是不同的开发独立负责，则需要开发总负责人组织各开发进行安全自查、统一反馈）。 安全自检产物：安全设计checklist自检报告。 安全自检产物：安全设计checklist自检报告。 安全验收标准：自检报告中不存在不符合项；对于不符合项需制定相应解决方案并落地解决。 安全验收标准：自检报告中不存在不符合项；对于不符合项需制定相应解决方案并落地解决。 02 — 安全活动 在产品设计阶段，安全活动主要围绕设计要求、减小攻击面和威胁建模展开。 1）确定设计要求 从隐私和安全角度两方面进行考虑： 基本隐私设计：明确国家法律法规，对获取、记录用户隐私的相关产品做出设计要求。（在告知用户并征得同意的情况下，仅收集程序必须用到的隐私数据。） 基本隐私设计：明确国家法律法规，对获取、记录用户隐私的相关产品做出设计要求。（在告知用户并征得同意的情况下，仅收集程序必须用到的隐私数据。） 基本安全设计：分为默认安全（在程序的默认配置中，需进行安全配置，确保程序初始状态是安全的）和最低加密（在程序处理之前，对所有数据进行严格验证或通过加密方式进行可靠地传输）。 基本安全设计：分为默认安全（在程序的默认配置中，需进行安全配置，确保程序初始状态是安全的）和最低加密（在程序处理之前，对所有数据进行严格验证或通过加密方式进行可靠地传输）。 2）减少攻击面 尽量减少暴露给恶意用户可能访问到的程序相关资源，包括但不仅限于端口、接口、服务、协议。 系统服务最小原则：可以是安全域划分、测试域名内网化，也可以是同一个应用（war包）仅允许发布在一个域名等运维安全相关举措。 系统服务最小原则：可以是安全域划分、测试域名内网化，也可以是同一个应用（war包）仅允许发布在一个域名等运维安全相关举措。 应用最小权限原则：评估实现程序功能所需的网络访问最小权限、程序运行的最小访问级别、边界防火墙端口最小化，从而建立按最小需求分配相应的权限机制。 应用最小权限原则：评估实现程序功能所需的网络访问最小权限、程序运行的最小访问级别、边界防火墙端口最小化，从而建立按最小需求分配相应的权限机制。 分层防御原则：在程序的不同层面实施安全方案，不同方案间需要相互配合构成一个整体，在解决根本性问题时需要实施针对性的安全方案。 分层防御原则：在程序的不同层面实施安全方案，不同方案间需要相互配合构成一个整体，在解决根本性问题时需要实施针对性的安全方案。 3）威胁建模 威胁建模是一种分析应用程序威胁的方法，可识别潜在的安全问题并实施相应解决或缓解措施。通常使用微软提出的STRIDE威胁等级分类法，将威胁分为：Spoofing（仿冒）、Tampering（篡改）、Repudiation（否认）、Information Disclosure（信息泄漏）、Denial ofService（拒绝服务）和 Elevation ofPrivilege（权限提升）六部分。 上述六大威胁所表示的定义、安全属性、消减措施可参照下表： 此外微软官方还提供了免费的威胁建模工具，可作为平时研究使用。 03 — 安全实践 在实际的安全活动中，一般采用安全设计checklist + 威胁建模的模式。 针对一般业务系统功能的新增、迭代等变更，可降低安全要求暂不做威胁建模，重点围绕安全设计checklist展开； 针对一般业务系统功能的新增、迭代等变更，可降低安全要求暂不做威胁建模，重点围绕安全设计checklist展开；

• 针对存在重大安全风险的环境、核心业务系统、业务系统通用功能等业务场景，可按需进行威胁分析与建模（威胁建模存在厚重、耗时长、技术门槛高等难题，不太适合企业所有的业务场景）。 针对存在重大安全风险的环境、核心业务系统、业务系统通用功能等业务场景，可按需进行威胁分析与建模（威胁建模存在厚重、耗时长、技术门槛高等难题，不太适合企业所有的业务场景）。 由此，安全设计checklist便是安全设计阶段的重中之重。一套好的安全检查项，并不是大而全，而是小而精且有效、业务方好理解。关于安全设计checklist的设计与内容，除了紧贴设计要求、安全编码规范、安全测试等后续安全活动反哺外，还可以参照一些互联网上的优秀案例。比如，美的金融SDL安全设计checklist： 又如，VIPKID产品设计与开发安全红线： 此外，还可以针对角色的不同，制作内容一致表现形式不同的安全检查项。比如从业务方视角： 又如，从安全角度出发： 04 — 持续优化 安全设计需要一定的积累和尝试，才能总结出一套可落地、有效的安全流程与解决方案。在实践过程中，发现一些比较行之有效的做法： 1）宣贯会上搜集业务方切身需求与体会 通过定期召开“安全评估流程”宣贯，不断搜集来自前端开发、后端开发、产品设计人员等不同参与人员的建议，持续优化现有安全设计checklist。 前端代码和后端代码需要精细优化，分别制定安全设计checklist或在现有表格中做明显区分； 前端代码和后端代码需要精细优化，分别制定安全设计checklist或在现有表格中做明显区分； 针对企业系统的特点，对于统一功能单独制定安全设计要求，不需要在每个系统中都要求开发来填写相关设计项，比如：单点登录、会员修改/重置密码； 针对企业系统的特点，对于统一功能单独制定安全设计要求，不需要在每个系统中都要求开发来填写相关设计项，比如：单点登录、会员修改/重置密码； 针对性对产品设计人员进行专业培训，选取一些常见的、工作中发现的案例进行分享，可以是某一功能实现的流程分析强调发现的安全问题； 针对性对产品设计人员进行专业培训，选取一些常见的、工作中发现的案例进行分享，可以是某一功能实现的流程分析强调发现的安全问题； 推行产品设计安全规范，类似于开发安全规范，从安全设计阶段进行取材，制定公司（业务）特有的“安全红线”。 推行产品设计安全规范，类似于开发安全规范，从安全设计阶段进行取材，制定公司（业务）特有的“安全红线”。 2）从后续安全活动中吸取经验，反哺安全设计检查项 在其后的环节，特别是代码审计和安全测试发现的漏洞与安全缺陷，可以反推到安全设计阶段，不断优化、持续补强针对某一重要系统或某一通用功能的专属安全设计checklist。 3）扩大相关责任人范围，衔接安全开发 如果仅聚焦于产品设计师可能带来的安全问题，往往难以满足在该阶段的期望（产品设计师输出产品功能原型图、业务流程图，具体功能实现便交由开发）。从降低安全活动带来的成本与打通SDL流程的角度考虑，需要将安全编码的理念提前一部分加入到安全设计阶段，因此该阶段关注的人物对象便是产品设计人员、开发人员。 长按识别二维码，和我交流 More... SDL最初实践 开篇 开篇 安全培训 安全培训 安全需求 安全需求 基础安全建设 基于堡垒机的自动化功能实践1 基于堡垒机的自动化功能实践1 基于堡垒机的自动化功能实践2 基于堡垒机的自动化功能实践2 基于堡垒机的自动化功能实践3 基于堡垒机的自动化功能实践3 基于堡垒机的自动化功能实践4 基于堡垒机的自动化功能实践4 企业安全建设 企业安全建设需求 企业安全建设需求 企业安全威胁简述 企业安全威胁简述 企业安全架构建设 企业安全架构建设 企业安全项目-测试环境内网化 企业安全项目-测试环境内网化 企业安全项目-Github信息泄露 企业安全项目-Github信息泄露 企业安全项目-短信验证码安全 企业安全项目-短信验证码安全 企业安全项目-前端绕过专项整改 企业安全项目-前端绕过专项整改 业务安全之另类隐患 业务安全之另类隐患 应用发布之安全隐患 应用发布之安全隐患 甲方眼里的安全测试 甲方眼里的安全测试 安全漏洞赏析 安全运维那些洞 安全运维那些洞 安全业务那些洞 安全业务那些洞 应急响应：redis挖矿（防御篇）

应急响应：redis挖矿（防御篇） 应急响应：redis挖矿（攻击篇） 应急响应：redis挖矿（攻击篇） 应急响应：redis挖矿（完结篇） 应急响应：redis挖矿（完结篇） 渗透测试技巧 那个简单的威胁情报 那个简单的威胁情报 Android APP数据存储安全 Android APP数据存储安全 搜集SRC信息中的“技术活儿” 搜集SRC信息中的“技术活儿” 常规渗透瓶颈，发散思维突破  常规渗透瓶颈，发散思维突破  一起玩蛇系列 python武器库 python武器库 漏洞扫描器资产处理 漏洞扫描器资产处理 python代码审计武器I python代码审计武器I python代码审计武器II python代码审计武器II Nodejs代码审计武器 Nodejs代码审计武器 fortify漏洞的学习途径 fortify漏洞的学习途径 个人成长体会 C3安全峰会参后感 C3安全峰会参后感 提高认知效率秘籍 提高认知效率秘籍