安全运营之内部事件管理
一、前言
在整个企业安全运营的体系中，告警管理可以说是处在安全运营的核心地位。他承载着各类规则的结果数据，通过运营人员使用人工或者机器辅助的方式，从结果数据中分析、提炼、甄别出有效的数据信息，并根据数据信息进行分析调查响应、对于违反规则行为进行制止、对于恶意的攻击行为进行抑制、对于异常规则进行优化调整。
然而，在实践过程中我们发现，告警管理的重心往往在于技术上的闭环管理。如某用户下载安装破解软件产生恶意外联行为，在告警的处置过程中，运营人员会先对用户机器进行断网处置，对终端进行上机分析，最后清除终端程序残留的恶意程序，确认无问题后告警工单便处置完成。但对其下载站点是否需封禁、下载软件有无违反公司软件正版化要求、用户是否存在软件仓库的需求、所下载程序是否为特定组织定向攻击行为等等深层次问题，一线的运营人员往往由于缺乏更高维度视角，亦或是疲于应对海量告警，忽略这些”深入灵魂”的根源性问题，久而久之会发现，告警规则已经优化得十分精准，但是告警量依旧不减，反而因为不断增加新规则而有所上升。一线运营人员因为相同告警反复处理，造成“路长人困蹇驴嘶”的窘境。
再比如，在处理数据安全告警中，发现有用户向外部发送了含有个人信息的敏感文件。运营人员介入后发现，原来是某系统的功能异常，管理员提取日志文件发送给厂商进行分析，日志文件中打印了相关敏感信息。运营人员会要求管理员撤回文件，并对日志文件进行脱敏处理。但是管理员是否知悉公司个人信息管理的规定、除当前系统外是否有其他系统也存在同类情况、应用系统日志存储敏感信息是否有相应规范要求等等，并不在其关注范围内。
类似问题被长期忽视，使得安全治理始终停留在表层。
因此，在告警管理之上，我们建立一套安全事件管理流程，用于将日常安全运营过程中发现的告警、问题，以安全事件形式向组织、向IT团队进行暴露，作为深入问题、推动根因整改的机制。其中，内部事件来源于告警和自发现问题，区别于行业通报等外部事件。本文即围绕“内部事件”，分享我们的流程建设与落地实践。
二、事件管理流程
我们在建立事件管理流程的两项核心原则是：
- 内部衔接：对内可以衔接安全运营的告警管理，作为一种告警升级手段，
- 外部融合：对外能与现有的IT体系相融合，遇到涉及运维团队、网络团队及数据库管理员需要跨团队协作时，也能很好适应流程，不会增加额外学习成本。
最终，我们将事件流程挂载至ITIL系统作为“安全风险隐患”上报，并形成如下三阶段闭环流程：
阶段一：事件上报
由一线运营人员在告警处置过程中发现典型问题，提交至三线专家团队（含攻防、数据、终端、安全流程等专家）进行初步评估。通过评估后，由安全负责人审批并录入ITIL系统，正式作为安全事件进行上报。
阶段二：事件调查
在安全运营团队内部，指定安全事件跟进人员开展深入调查，安全事件跟进人员从一、二线告警运营人员手中接手上报事件的第一手消息，并由此展开事件调查。
在事件调查过程中，需要调查并记录下面五项信息，这样事件调查报告才能算完整：
- 处理过程，事件调查处理过程的事实记录。应包含具体时间点和时间点下的具体操作行为。
- 影响面分析，发生什么事情，该事情产生了哪些影响。
- 原因分析，发生事件的原因是什么，需要有直接原因和根本原因分析。
- 幸运和做得好的，在事件处理过程中，有哪些幸运的地方，有哪些做得好需要坚持的地方。比如“发现日志中包含敏感信息是因为员工主动上报”或者“及时断网避免扩散”等
- 后续改进事项，通过事件分析，得出后续改进和优化事项。
完成事件调查报告后，经由安全相关负责人审阅通过后，就可以进入下一个阶段。
阶段三：事件上会和待办跟进
完成事件调查报告后，在公司每周IT事件例会上，安全团队对事件进行汇报，由IT的运维、网络、开发等领导对事件进行评议。最后完成评议的事件，按事件改进事项及IT事件例会中讨论措施录入ITIL待办。经由团队长对待办进行分发，由相关同事改进完成后，提交团队长进行验收形成闭环。
三、事件上报标准
在安全运营事件管理实践过程中，我们通过对历史安全事件进行分析归纳，确立上报安全事件应符合以下标准：
- 具有典型性，与往常处理告警不同，如往常处理终端病毒告警为用户手动下载，当前遇到病毒由攻击者通过微信聊天工具进行投递，该情况此前未遇到过，具有典型性。
- 涉及数量较大，远大于往常处理数量，如往常处理员工通过微信外发敏感数据告警外发数量为上百条，当前遇到外发敏感信息涉及上万条，已经超过数量级，涉及数量较大。
- 反复出现。当一个告警反复出现后，通过上报事件对问题进行深入分析，最后尝试通过深度挖掘，在源头解决问题。
- 涉及违规、违反既定策略。告警本身是由于违反公司相关管理规范，违反既定策略要求导致，根据情节严重程度进行判定。
- 涉及其他团队，通过事件推进。告警涉及其他团队，通过上报事件指出问题方式，能更加利于问题推动解决。
四、事件调查要求
调查过程要求：
- 依据事实，说了什么、做了什么、造成的影响和风险，都有记录可支撑，都有记录可佐证（证实、证伪）这些记录就是证据，是确凿的。
- 没有记录的（比如打了电话、没有录音）、调查人员推测的（比如没有证据），就不叫证据；但也应该在报告中呈现出来，并告知读者“这是推测”“没有证据”，便于读者区分。
- 对听到的、看到的内容，要有疑点分析。
- 对疑点，要去获取证据进行证实或证伪或无法证明，但对于这个疑点的结论是什么，要在报告中说明。
报告编写要求：
- 让事件报告阅读者充分了解事件前后及事件相关的事实，并作出正确的判断（对是否违规、违规情节严重性的定性、定量判断）。
- 让事件报告阅读者尽可能一次性掌握所有事实，减少沟通成本。
- 事实应该是中性的、无歧义，在描述中要严格区分“事实”和“观点”
- 不断地补充事实、证据，不断地证明和证伪；事实要完整、准确、真实。
- 所有事实阐述清楚，疑点证明完毕，对事件调查结论（是否违规、违规情节严重性的定性、定量判断）要给出建议。
五、总结
安全运营不仅仅是技术规则和告警响应，更是推动组织安全能力提升的驱动力。通过建立系统化的内部事件管理流程，我们实现了：
- 告警向事件升级的机制闭环；
- 问题向根因整改的协作推动；
- 安全流程与IT管理的有机融合。
并且，我们已将“事件管理”纳入安全运营度量体系，每月对安全事件数量、类型、闭环完成率进行统计，站在年度维度分析事件分布和风险趋势。这为我们识别高发领域、优化安全投入提供了数据支撑，使安全运营更加具备“量化、复盘、提升”的能力闭环。
六、常见事件调查关注点（供参考）
数据安全类
数据情况：
- 是什么数据?
- 涉及哪些敏感信息类型？
- 量级多少？
- 数据来源？
- 数据的拥有是否合理？
当事人情况：
- 为什么执行此操作？
- 操作是否工作需要？
- 操作是否经过授权？
- 使用过程是否遵守最小化原则？
- 是否签署保密协议？
- 是否知悉公司数据安全规定？
- 近期是否有离职倾向、岗位调动？
造成影响情况
- 是否造成敏感数据泄露？
- 是否在网上扩散？
- 是否造成恶劣影响？
应急措施：
- 是否删除敏感数据？
- 是否提供承诺函？
- 当事人领导告知和确认
- 部门合规人员告知和确认
内部脆弱性类
- 问题情况：
- 是什么问题？
- 为什么出现问题？
- 造成什么影响，影响范围多大？
- 是否被攻击者利用？
- 日常检测为何没发现？
异常软件类
- 为何使用，在什么场景下使用？
- 异常软件来源？
- 异常软件分析情况
- 如果是外编同事，项目经理是谁？
- 是否签署保密协议，是否有参与安全意识培训，成绩如何？
- 用户是否知道不应使用异常软件？
- 应急措施：
- 是否有拦截、查杀
- 是否在网络侧封禁
- 排查其他设备存在同样情况
- 是否了重装系统
钓鱼攻击类
- 攻击是如何找到此用户的邮箱的，是因为在公网上公开的吗？
- 为何用户会下载并点开该文件？
- 员工是什么职位，之前没有参加过钓鱼测试？成绩如何？
- 中招后恶意软件有哪些恶意行为，计算机上是否保存了账号密码、敏感文件、敏感数据，文件是否被窃取？
- 是否有后门？是否重新安装操作系统？？
- 是否溯源到攻击者信息？，攻击者画像是什么？有哪些其它的特征？
- 为什么有的邮件拦截了，有的没有拦截？？
仿冒诈骗类
- 受影响的客户有多少？
- 受影响客户发展趋势如何？
- 诈骗团伙诈骗的过程是怎样的？
- 是否可以溯源到诈骗团队信息？
- 被骗客户后续如何处置？
- 除仿冒我司APP外，是否有仿冒其他公司？