SDL实践之安全教育

一、SDL概述

SDL是2004年开始，微软在全公司内部推行的安全开发生命周期（Secure Development Lifecycle），以在软件开发各个阶段保障信息安全，加入隐私保护，降低软件中的安全漏洞数量、严重性以及隐私违规，避免发布后的产品遭受恶意攻击，以及隐私问题造成的违法事件。

SDL的核心理念包括：教育、持续过程改善、责任。

教育即安全教育，是面向所有涉及软件开发过程人员的，目的是通过安全教育，让所有人员具备基础的安全开发意识、安全开发技术，以降低开发过程中潜在的安全风险和安全漏洞，并应对技术和威胁的变化。

信息安全本质上是人和人的对抗，技术和威胁始终是动态发展和演变的，因此需要在SDL实践过程中，基于新的技术和新的威胁，不断修正和改善已有措施，应对新的威胁，达到降低安全漏洞数量和严重性的目的。

即便是发布后的软件，也无法确保完全没有100%的安全漏洞和风险，必要的安全应急响应计划以及内部沟通，可以确保安全和研发团队从容应对安全事件，将安全事件影响降至最低，并根据事件数据和记录，持续改善SDL实践过程。

SDL基于五个功能领域进行构建：

• 培训、政策和组织功能
• 要求和设计
• 实施
• 验证
• 发布和响应

根据微软对于SDL的成熟度划分，包括基本、标准化、高级和动态，其中基本成熟度不包含任何培训、过程和工具，动态成熟度包含高效的研发过程、专业的工具、训练有素的人员、有责任心的团队或组织。

安全（security）是附属于其他事物或过程的属性，并非单独的功能或特性。因此，为保障软件开发过程的安全，需要将安全动作融入到软件开发过程中，按照软件开发过程的阶段进行划分，并确保在各个阶段确保对原本的研发过程和阶段动作产生最小的影响和干扰，过度的干扰和影响会阻碍软件开发过程（如：威胁建模需要研发团队专门腾出两周时间和安全团队一起进行，而两周已是一到两个完整的研发迭代周期），影响研发团队成员对于安全的认知和印象（如：不愿意配合SDL中的各项工作，认为安全团队只是耍嘴皮子的技术人员），并最终影响业务目标的达成和SDL的落地（安全具有滞后性，因此一定是业务优先）。

基于研发过程的各阶段，SDL模型各阶段及阶段动作如下：

二、安全教育

本文重点描述SDL中的第一个阶段，安全教育，并结合笔者以往的安全建设经验和安全项目经验，介绍SDL的安全教育阶段的最佳实践。

由于部门结构和职责划分原因，安全教育首先需要得到企业最高层的认可或首肯，方能确保安全教育顺利进行，没有高层授意的安全教育无法得到彻底的贯彻和执行，比如安全培训无法覆盖全员。

安全教育从教育方式和切入角度，同时确保人员参与的全面覆盖，包括但不限于：

• 入职培训
• 专项培训
• 安全分享
• 安全演练
• 安全活动

从安全教育面向的对象划分，包括技术人员（如研发人员、运维人员、测试人员、架构师）和非技术人员（产品经理、产品运营、项目经理），安全教育内容包括：

• 安全意识教育：面向全体人员的教育，旨在增强人员的信息安全观念和防范意识。
• 安全技术教育：面向技术人员的教育，旨在让技术人员了解、掌握安全防范技术的操作和手段，不涉及安全攻击技术。

按照安全教育中的培训内容划分，基础的安全培训内容包括但不限于：

• 安全事件及影响
• 员工安全守则
• 安全概念：包括安全测试和功能测试的区别、风险评估方法、安全测试流程、攻击面、杀伤链等。
• 安全设计原则：包括减小攻击面、最小权限、默认安全、纵深防御。
• 威胁建模模型：包括攻击树、STRIDE。
• 安全漏洞示例：包括漏洞原理、利用细节、漏洞危害、漏洞影响。
• 安全漏洞类型：如OWASP TOP10漏洞原理及解决方案。
• 安全编码：安全编码方式，如注入漏洞、缓冲区溢出等。
• 安全加密：包括安全的哈希算法和加密算法，以及已不安全的哈希算法和加密算法。
• 隐私防护：包括隐私概念（如PII、数据保护等级划分）、隐私设计最佳实践、隐私开发最佳实践、隐私泄漏风险评估。
• 法律法规：包括网络安全法、数据安全法、GDPR等。
• 合规要求：包括等级保护、ISO27001、SOC2、PCI-DSS等。

安全教育的方式包含线上、线下，其中安全培训以线下的小规模人员培训为主，线上培训无法与参与者进行足够的互动，大规模人员的培训无法确保所有人能够集中注意力参与培训，线上培训，可专门录制安全培训内容，方便人员复看或遗漏人员参与，以及设计线上的安全意识和安全技术考题，方便安全培训后的安全能力测试。

另外，由于技术和威胁的发展，所有培训内容和教育内容，都需要定期更新，落后的培训内容无法让其他人员信服，并可能会质疑安全工作的专业性。

三、入职培训

为了确保全员进行安全培训，并确保人员尽快熟悉、掌握安全意识和安全防范技术，最佳的实践之一，是对所有入职人员进行安全培训。该项工作需要人事部门的配合和协作，与其他入职培训课程一起设置，对于办公地点分散的企业，为保证培训效果，可派培训讲师到当地进行培训。同时，入职培训由于其周期性和频繁性，可以确保参与人数不太多，以至于影响培训效果。

入职安全培训面向所有人员，因此培训内容需要覆盖上文中的所有安全培训内容。如果条件允许，可以将参与人员按照技术岗位和非技术岗位进行分开培训，其中非技术岗位培训内容中不包含安全漏洞示例、安全漏洞类型、安全编码、安全加密以及隐私防护的技术实践部分，安全设计和威胁建模，可以应用到诸如产品设计、产品运营等日常工作中，因此非技术岗位的人员需要进行相关培训。

入职培训内容由于覆盖面广，因此培训的最佳讲师是安全负责人，其次是具备有安全技术背景的安全工程师（在技术培训过程中，可能会收到来自其他技术人员的问题甚至挑战），最后是专门的安全培训讲师或安全运营人员，但前提都是培训讲师能够将培训的内容讲的足够明白和清晰，特别是安全设计、安全漏洞修复，大多数的渗透测试或安全测试工程师通常都缺乏对于安全架构和安全设计足够的认识，以及对于漏洞修复方案足够透彻的理解。

由于入职培训的时长和方式由人事部门统一安排和限定，因此入职安全培训没有固定的时长和方式，如培训时间长，则可侧重安全技术，如培训时间短，则需侧重安全意识，让人员对安全部门、安全工作、信息安全有初步的认知和了解。每次入职培训后，都需要对参与人员进行必要的考核，确保入职人员了解并掌握了培训内容。

四、专项培训

入职培训可能由于培训时长限制，或人员规模限制，无法针对不同岗位的人员进行足够深入的培训，因此，安全部门需要每年定期对不同岗位的部门和团队进行专项培训，至少每年一次，包括架构团队、研发部门、测试部门、运维部门、产品部门等。研发等技术部门侧重培训安全防护，包括：

• 安全事件及影响：培训对象角色相关的安全事件及影响，比如运维安全事件；
• 员工安全守则
• 安全概念
• 安全设计原则
• 威胁建模模型
• 安全漏洞示例
• 安全漏洞类型
• 安全编码
• 安全加密
• 隐私防护
• 法律法规
• 合规要求

产品等非技术部门侧重安全设计，包括：

• 安全事件及影响：培训对象角色相关的安全事件及影响，比如人员失误；
• 员工安全守则
• 安全概念
• 安全设计原则
• 威胁建模模型
• 隐私防护
• 法律法规
• 合规要求

安全工作极其依赖研发和运维部门的工作过程和结果，因此，在面向研发和运维的培训中，需要特别强调从公司和业务角度安全合规的重要性。对于测试部门的专项培训，可以增加安全测试相关工具使用及漏洞测试的技巧和经验，通过测试部门的功能测试工作，发现产品的安全漏洞，一方面可以一定程度上降低安全工作的工作量，另一方面可以避免由于安全部门不知情导致漏掉业务或产品的安全测试。

专项培训内容的一部分与入职培训是相同或类似的，目的是为了加深人员安全意识，正如重要的事情说三遍，但并非连续说三遍（连续三遍和一遍没差），而是在不同时期说三遍，就像飞机起飞时每次都会有的安全提示和指示。

专项培训不建议设置培训后的考核，对于培训人员而言，能够抽出时间参与安全培训很可能已然是尽力而为了，额外的考核会另专项培训成为不受人欢迎的形式化工作。

五、安全分享

由于对信息安全的愈加重视，新闻或媒体中的安全事件的报道也逐渐增多，利用蹭热点的方式，安全部门可以将就近发生的安全事件中的内容进行展开和深入分析，并结合入职培训和专项培训内容，在公司范围内进行安全分享。比如某某公司数据丢失事件，可以单独或与运维部门协作，对架构设计、安全开发、数据运营、人员安全守则进行分享。

安全分享不强制要求参加，除了分享热点事件的分析，还可以分享安全工作中发现的业务或产品线中存在的安全漏洞及修复方案，以及安全工作最近的成果，一方面用于科普安全防范技术，通过安全分享发掘对安全技术有兴致的非安全部门人员（这些人员是安全运营工作中潜在的安全对接人），一方面用于展示安全人员的专业性，增加其他部门及人员的信赖程度，一方面用于展示安全工作的价值，避免被其他部门认为安全部门或团队是太监部门。

六、安全演练

安全培训和分享，还会受限于讲师的互动能力，单纯的培训和分享是不够的，通过安全演练，可以直接检验人员对于安全意识和安全技术的掌握和应用情况。常见的安全演练是钓鱼攻击演练，安全部门在事先获得企业高层允许的前提下，对企业内部人员进行钓鱼攻击，检验各部门、各人员中招的情况，根据演练的结果，需要对未通过演练的人员进行单独的、集中的安全意识培训。

比如，某互联网公司曾经在自家办公楼下贴出某商家的打折优惠活动，并在其活动海报上贴出钓鱼二维码，用于检验员工的安全意识，对于最终成功被钓的员工，进行相应的处罚。

七、安全活动

安全活动是内部安全运营的一部分，方式不一而足，可以是通过办公用品上的信息安全提示，可以是公司配发电脑中的默认电脑桌面，可以是公司不处不在的安全教育海报，也可以是专门举办的网络安全周（日），又或者是自愿参与的安全测试，成绩优胜者给与奖励。

比如，在公司内部开展安全意识大测验，得分超过一定分数的人可以获得相应的奖品；定期通过漫画或小视频的方式，面向公司内部宣传网络安全。

活跃、有趣的安全活动，可以让安全部门和安全工作不至于显得严肃和紧张，起到缓和和其他部门人员关系的作用。

八、总结

安全教育是SDL中的第一个阶段，也是日常安全建设中最为重要，也最容易被忽视的工作，以上是笔者总结出的安全教育最佳实践内容，五种安全教育实践中，其优先级和重要性从上往下排列。其中，入职培训和专项培训是强制要求参加的培训，为避免事后培训人员参与与否的扯皮，该类培训需要有培训签到表做留证和存档。

另外，安全教育应以奖励为主，处罚为辅，且所有的惩罚机制需要事先在人员安全守则中声明（需要建立必要的安全红线），并在入职等培训中进行再次声明（总会有人以不知情为由不接受安全处罚，在无明确证据的情况下，场面会非常尴尬，且会伤害安全工作的权威）。安全教育和意识普及阶段，惩罚会让大多数人感到反感和不易接受，除非，是在安全教育之后出现的安全漏洞或安全事件，比如开发人员在参加入职培训后仍然将源代码泄漏在GitHub，此种情况则按安全制度进行开除处理或罚钱处理，惩罚需要即时且公开，以起到杀一儆百的效果。

员工安全守则中的常见的安全红线包括：

1. 员工故意或无意泄漏公司机密信息；
2. 员工将公司代码泄漏至公司外的其他系统或平台；
3. 故意或无意将公司信息泄漏，并造成公司损失的；
4. 在办公环境中进行恶意网络攻击或网络监听的；
5. 在办公环境中私自搭建无线热点的；
6. 未销毁公司机密信息，造成信息泄漏的；
7. 未妥善保管自己公司账户，导致被利用造成公司损失的；

好的安全教育，不仅仅需要通过正式工作展开，也需要通过私下交往（并非指谈恋爱）进行。正式工作的场景中，交流往往是严肃的，而私下的交往是放松的，交流安全技术、事件、漏洞、意识会成为潜移默化，同时也可以搞好安全和其他部门及人员的关系。