1.2　制定基础制度

安全从来都不是一项可以自下而上单纯依靠员工自觉就能做好的工作。安全绝大部分时候是反人性的，它会给产品增加更多的限制、给技术增加更多的工作量、给各个方向各个层级的员工增加更多需要遵守的“条条框框”，这些都不太可能让人自愿积极配合。所以，那些好的安全管控，几乎全部都是自上而下的。

所谓自上而下，并不是要求 CEO、CTO 亲力亲为，也不是要求高管们在会议上喊口号或者反复强调。事实上，安全负责人不可能也不敢要求他们的老板这么做。

那么怎么实现自上而下的安全管理呢？答案很简单，就是通过发布制度，让高级管理层为自己授权，把那些你希望其他团队关注、执行和配合的工作，变成他们必须遵循的公司制度。

很多人都认为，制定制度是一件很简单的事情，无非就是从网上搜索一些相关模板甚至是现成的文档，把里面的内容拼拼凑凑稍微修改一下，发出来让大家执行就可以了。

这种观点大错特错！

一般情况下，可以从网络上直接获得的制度模板和原文，大多来自成熟的大型企业或咨询机构，这些制度在经过很长时间的磨合修订后，要么极其全面细致，要么高度耦合业务特征，生搬硬套，很难在一家内控合规、工作处于起步阶段的公司落地执行。具体的困难同时来自签批人和执行人。

• 对身为签批人的企业高层管理者来说，他们往往非常介意新发布的制度对现有业务流程造成负面影响，毕竟业务发展才是企业运营的根本，而安全管控越是全面细致，对业务的干涉程度也就越严重。除了业务影响本身，大部分高层管理者还需要考虑各个团队之间的职能约束与权力平衡，因此比较排斥对某个团队或个人一次性授予过多过大的权限。所以，作为安全负责人，需要多给高管们一些时间，让他们逐步感知安全的重要性，增加对安全人员的信任，并随之落地每个阶段必要的安全管理要求。
• 对身为执行人的各级部门和同事来说，一定对用于约束他们的制度带有一些抵触情绪。这是一种正常的心理状态，千万不要把这种情绪“上纲上线”到工作态度甚至个人品德问题，毕竟现在安全不是他们的KPI，把过多的时间花在安全上就会影响他们的业务产出。就像如果业务目标不是安全的 KPI，你在推动安全工作的时候就可能不会顾及业务是否能准时上线。正是因为这种抵触情绪的存在，如果发布的是一份通篇大论、咬文嚼字的冗长文档，他们可能连看都不会看，更别说后面的执行了。

小贴士

很多安全工程师认为：一个优秀的员工，应该排除万难，坚持做正确的事情，哪怕不被任何人理解。这句话其实只对了一半，正确的说法应该是：一个优秀的员工，应该排除万难，做成正确的事情。在任何一个需要多人协同完成的工作中，每个人都有自己的目标，努力的目的是为了结果而非过程。为了达成结果，就需要及时换位思考，充分考虑各方心理与诉求，尽可能找到各方都能接受的共赢方案，这样才能更快、更好地把事做成。

考虑到 M 公司正处在“救火”阶段，并且大部分员工对安全缺少初始认知，我认为当前阶段需要制定的制度应该具备以下特点。

• 适度约束：只覆盖当前阶段必须管控的内容，避免引发群体抵触。
• 简明清晰：制度内容一目了然，避免空话套话太多导致重点内容被忽略。
• 平衡业务影响：对业务和风险划分优先级，允许业务部门适当调整资源排期。
• 明确职责和惩戒：约定协作义务，制定可衡量的判断标准，减少将来出现问题后互相“踢皮球”的可能性。

在经过充分调研和考虑后，我紧急制定了3个制度：《安全评估管理规范》《安全事件定级标准》《安全应急响应流程》。

安全评估管理规范 v1.0

（一）目标

为提升公司安全防控能力，及时发现安全风险，规范安全评估管理，明确安全提测、风险定级、问题整改等要求，特发布此规范。

（二）适用范围

本流程适用于公司开发及采购的各项产品与服务。

（三）安全评估要求

1. 安全负责人具有公司内任何信息系统项目的知情权，即有权获取任何系统项目的相关信息，对于认定有风险的，可根据实际情况要求相关团队进行整改。由于特殊原因不适宜告知安全负责人的，应以邮件说明具体原因并由安全团队备案。
2. 涉及账号、个人信息、资金以及具有现金价值的其他资产或其他涉及公司敏感信息的系统，必须经过安全评审和安全测试，确认无高危风险后才可上线。不涉及前述内容的其他系统默认执行原定的开发、上线流程，但应将相关信息同步提交安全负责人，由安全负责人判断是否必须经过安全评审和安全测试。
3. 项目开发进度须为安全测试预留 2 天测试时间，预留时间低于 2 天的，需与安全负责人具体沟通排期；提交安全测试的版本应基本排除导致业务流程无法正常运行的功能类 BUG。
4. 各团队完成安全风险的整改后，须反馈安全工程师，以安全工程师最终验收通过结果为准。

（四）风险评级

现阶段由安全工程师和业务方根据安全风险可能造成的实际影响确认风险等级。当双方无法达成一致时，暂以安全工程师判断为准。

（五）整改要求

在满足正常业务的前提下，业务方须执行安全要求，尽可能保证把安全风险降到最低。具体安全风险整改应该满足表 1.2 中的时限要求，当无法满足相关要求或业务方单方面接受风险时，必须由对应层级负责人书面审批确认。

表1.2　安全风险整改要求

（六）归纳总结要求

1. 安全团队每月对新增和存量安全风险进行归纳总结，相关结果向相关人员披露，并根据相关数据，调整后续安全工作和培训。
2. 安全团队梳理各个团队安全风险产生、整改情况，相关数据向 CTO 汇报。

安全事件定级标准 v1.0

（一）目标

为了加强公司信息安全管理，明确安全事件定级依据及安全责任惩罚措施，特制定本标准。

（二）适用范围

本标准适用于公司所有部门。

（三）术语定义

资金损失：特指公司已持有的资金因安全事件减少或丢失的情况，不包括实际收入不及预期、运营活动福利派发分布不符合预期、不可提现的虚拟资产不受控扩散等情况。

网络入侵：特指公司系统权限被非法获取、数据被非法篡改等情况。

生态影响：指安全事件未对公司造成资金、机密性、可用性等方面的实质损失，但对业务生态造成负面影响的情况。例如，利用安全漏洞发布非法内容，破坏游戏平衡，触发虚拟货币通货膨胀或虚拟商品比例失衡，引发用户强烈不满情绪等。

（四）定级标准

当损失为多种类型时，以受影响最严重的类型判定等级，具体如表 1.3 所示。

表1.3　信息安全事件定级表

（五）责任判定

1. 安全团队对公司范围内的任何安全事件承担责任。
2. 对于符合《安全评估管理规范》，经安全团队评审、测试通过的系统发生安全事故，由安全团队承担主要责任，由安全负责人决定业务方是否需要承担次要责任。
3. 对于不符合《安全评估管理规范》，包括但不限于不遵从安全团队要求执行开发或上线或在强制评估范围内的业务，如未告知安全团队或未经过安全团队评审测试，发生安全事故由业务方承担主要责任，安全团队承担次要责任。
4. 由历史原因引发，已找不到责任方的，责任归属到目前负责此业务的团队。
5. 由安全负责人对安全事件定级。如对 P3 及以上级别事件的责任判定结果有争议，由安全负责人临时组织建立安全事件评审委员会进行仲裁，安全事件评审委员会可能由 CTO、业务部门总监及以上管理层、责任部门总监及以上管理层组成。

（六）惩戒

当发生安全事件时，惩戒标准如表 1.4 所示。

表1.4　信息安全事件定责表

安全应急响应流程 v1.0

（一）目标

为减小公司安全事故损失，及时发现、准确应对安全威胁，明确安全事故上报、处置、复盘和后续整改过程，特发布此流程。

（二）适用范围

本流程适用于公司所有部门。

（三）职责定义

安全团队：对安全应急响应整体负责，执行包括但不限于安全事件的监控、记录、通知、分析、制定处置措施、复盘和上报工作。

运维部门：根据安全要求，执行其职责范围内的网络、操作系统、数据库、中间件、应用程序、应用数据等相关系统和组件的恢复、调整、隔离、下线等操作。

研发部门：根据安全要求，执行其职责范围内应用程序代码和脚本的风险整改操作。

产品及运营部门：根据安全要求，执行其职责范围内的产品问题功能整改和安全属性调整相关的工作，负责因相关调整产生的客服问题，包括问题解答和用户安抚等。

公关及政府关系部门：接收安全事故通知并了解跟踪相关动态，判断是否需要启动公关工作。对符合条件的安全事故，由政府关系部门根据相关法律和监管要求向主管部门上报，并协助完成报警立案工作。

法务部门：接收安全事故通知并了解跟踪相关动态，对符合条件的安全事故，协助完成报警立案、法律诉讼和取证指导工作。

人力部门：接收安全事故定责结果，根据公司相关制度对责任员工实施惩罚。

（四）应急响应流程

1. 公司内任何员工通过任何途径知晓任何安全事件或疑似安全事件后，须第一时间通报安全团队。
2. 安全团队对安全事件进行初步分析，对于可能或已经造成实际影响的安全事件，应立即上报安全负责人，并立即启动应急响应流程。安全负责人对安全事件预判定级达到 P3 及以上时，应立即上报更高一级负责人。
3. 安全团队根据安全事件的实际情况，优先制定快速止损措施，根据团队职责指定运维或研发团队执行。当止损方案涉及业务暂停或下线时，安全负责人必须先征得业务部门副总裁以上管理层或 CTO 同意；当安全事故可能导致20%以上用户信息泄露，或 1000 万元以上经济损失，且因特殊原因无法联系高级管理层审批时，由安全负责人行使应急响应临场决策权，先行指定处置措施并指定相关团队执行，后续再向高级管理层和业务团队报备和详细解释。
4. 执行快速止损措施并验证有效后，由安全团队制定更为完善、彻底的整改措施，根据团队职责指定运维、研发或产品运营团队执行。同时针对相关风险开展大排查工作，避免同类事故再次发生。
5. 由安全负责人梳理事故情况，同步公关部门、政府关系部门、法务部门，并由各部门判断是否需要在其职责范围内开展下一步工作。

（五）安全事故报告和复盘

1. 由安全团队汇总事故影响、定级、原因和责任人，上报 CTO。安全负责人根据内容敏感程度确定是否公示安全事件。
2. 相关责任人通报人力部门，由人力部门根据公司相关制度进行惩罚。
3. 由安全团队组织应急响应过程及结果复盘，为后续工作提供优化指导。

虽然现在我的直接汇报对象是运维总监，但是这3个制度是全公司执行的，因此，制度签批必须由 CTO 完成。在征得运维总监同意后，我将制度文档发给了 CTO 进行邮件签批。

Q 王总：小陌，你为什么要发布这 3 个制度？

A 马小陌：王总，我之前了解了一下公司的情况。现在公司的安全事故比较多，最主要的原因就是没做安全评估，导致很多隐患暴露在线上。所以我们得赶紧把安全评估机制建立起来，尽量在恶意用户对我们造成破坏之前，自己先发现并解决掉这些隐患。但全面的安全评估需要一些时间，这个间隙我们可能还是会遭受攻击，所以我想通过做好应急响应，把可能的损失降到最低。但是我刚刚来到公司，和各个团队的协作也是刚开始，如果自由磨合的话，需要很长一段时间，因此希望先通过制度规范起来，然后再慢慢优化。

Q 王总：我看你的制度里提到了大量的惩罚，而且整体比较严格，你有考虑过这可能让其他团队产生抵触情绪，导致合作更复杂吗？

A 马小陌：我在制定惩罚措施的时候考虑了两点。第一，我虽然对安全负责，但是具体的风险整改和应急响应操作大部分是由其他团队来操作的，如果安全不和他们的奖惩挂钩，那么可能很难改变现在这种经常发生安全事故的现状；第二点就是您说的其他团队有抵触情绪的问题，我也很担心大家认为安全团队把责任甩给他们，所以我在《安全事件定级标准》中给出了明确的说明，如果业务团队遵守了安全规范和流程，那么发生安全事故后由安全团队来承担主要责任，业务团队是否需要承担次要责任由安全负责人来确定。

Q 王总：既然他们已经遵守了流程，为什么还是有可能要承担次要责任呢？

A 马小陌：这点主要是为了保持各个团队对安全问题的持续重视，避免产生把所有安全责任直接甩给安全团队自己不管不顾的情况。比如研发人员自己知道一些安全开发的方法，但是很麻烦，如果他只需要遵守《安全评估管理规范》，那么他有可能采用最简单的方式快速完成功能开发任务，这时如果安全团队恰好没检查出来，那么等于他的效率提高了，但实际上这对公司整体来说是利益受损的。所以如果研发人员承担相关责任，那么他就更可能继续采用安全的开发方法。因此，我在《安全事件定级标准》中明确了业务方在遵守安全制度的情况下，是否需要承担次要责任由安全负责人来确定。当然，这个规定也更有利于推动其他团队对安全工作的配合与支持。

Q 王总：没问题。