网络钓鱼事件响应流程图(举报邮件)

网络钓鱼事件响应流程图模板:用户举报、SOC 分流定性、全租户搜索副本、清除并封锁指标、重置密码并撤销会话、账户攻陷升级与安全意识跟进。

使用此模板

什么是网络钓鱼事件响应流程图(举报邮件)流程

网络钓鱼事件响应,是在一个人转发了一封邮件之后发生的事。触发点是一次举报,而不是一条告警:有人按下了邮件客户端里的举报按钮,或者就一封看起来不对劲的邮件打电话给服务台。从那一刻起,工作就是一个简短、可重复的循环。把样本分流出定性结论,找出所有到达组织内部的其他副本,移除这些副本并封锁它们所指向的目标,撤销收件人已经做过的操作,并告知相关人员发生了什么。下面这张图跟随一次举报从头到尾走完六个阶段:从受理,经过分流、确定范围、遏制和恢复,一直到决定下个月你们会收到多少举报的指标与安全意识工作。

这里说的只是通过邮件传播的这一种情形,而且仅限于此。它不是安全运营中心从一条检测告警出发所运行的那种通用网络安全事件响应生命周期:那个流程从遥测数据而不是从一个人开始,而本图在'是否有账户被攻陷的迹象?'这一步把案子移交给它,前提是某个邮箱被发现已落入他人控制。它也不是安全事件升级流程里的那把严重等级梯子,也不是一次常规的密码重置,因为这里的重置是针对攻击者已经掌握的凭证所做的遏制,并且必然伴随会话撤销。它同样不是数据泄露通知:如果个人数据已经落入攻击者手中,评估、法定时限以及与监管机构的沟通,属于法务和数据保护官的工作范围,与本图并行进行,而不是包含在其中。请把这张图当作一个教学起点,再根据你们自己的事件响应流程、适用的法规,以及安全负责人的审核去调整它。

四个判断撑起整个流程。'被举报的邮件是否恶意?'是把一次骚扰和一起事件区分开来的定性结论,它由 SOC 分析师而不是服务台来做,因为一个仿冒域名和一次失败的发件人身份验证检查,都不是一线人员能下的判断。“是否有人点击或回复?”把一项邮件卫生工作变成一项身份工作,图上一切代价高昂的环节都挂在它下面。'受影响用户做了什么?'被画成一个三分支判断,而不是一串是非题,因为输入凭证、执行了一个附件,以及一次未遂事件,需要不同的团队按不同的时钟去处理。'是否需要全员预警?'被有意放在安全管理层泳道:给每一位员工发一条消息,是一项有成本的沟通决策,不应该只由发现这场攻击活动的那位分析师一个人来做。

本流程图涵盖的内容

本模板包含

  • 五条泳道——员工/举报人、服务台、SOC 分析师、IT/身份团队与安全管理层——横跨六个阶段:举报与受理、分流与定性、确定攻击范围、遏制与清除、恢复与沟通,以及结案与改进
  • 两条受理路径汇入同一个队列:按下举报按钮,样本会直接送到安全团队手上;而选择打电话的人则由服务台开一张工单,并附上原始邮件而不是靠描述记录
  • 一个定性判断'被举报的邮件是否恶意?',其无害分支会回复举报人、调整邮件过滤规则,并以非恶意结案,而不是悄悄把它丢在一边,因为正是这条回复让大家愿意继续举报
  • 先确定范围再删除:“在租户内搜索其他副本”与“是否有人点击或回复?”,随后是一轮遏制清扫,清除每一份副本、封锁发件人、URL 与文件哈希值,并在攻击活动仍在持续投递时于“是否仍有新的副本到达?”上循环
  • 一个三分支的'受影响用户做了什么?'判断:输入了凭证会走向身份泳道里的“重置密码并撤销会话”,打开了附件会走向隔离主机与全盘扫描,而'是否有账户被攻陷的迹象?'则是升级而不是结案
  • 沟通与收尾:'是否需要全员预警?'在安全管理层泳道获批,收件人被告知需要留意什么,而这份举报只有在记录了失陷指标、时间线、举报率与点击率,以及一次安全意识跟进之后才会结案

何时使用本模板

  • 你们在 Outlook 或 Gmail 里有举报按钮,但背后没有一份大家认可的处置手册,于是一封被举报的邮件会遭遇什么,取决于恰好接手的是哪位分析师
  • 用户们把可疑邮件转发到一个没人真正负责的共享收件箱,你们需要把受理、定性和给举报人的回复画成一条完整路径
  • 一场凭证钓鱼攻击活动刚刚投递,你们想在下一波到达之前,把清除、重置、会话撤销和邮箱规则检查排好顺序
  • 你们正在撰写事件响应计划里的钓鱼邮件章节,需要它能干净地移交给更大范围的安全事件流程,而不是与之重复
  • 审核员问起员工如何举报疑似安全事件、之后又会发生什么,而这正是 ISO/IEC 27001:2022 附录 A 控制项 6.8 所要求的举报机制

运作方式

  1. 把泳道改成你们的角色

    把员工/举报人、服务台、SOC 分析师、IT/身份团队和安全管理层,换成你们实际拥有的角色。相当多组织根本没有服务台这条泳道,因为举报按钮直接通向安全团队;也有相当多组织把身份相关工作放在 SOC 内部完成。与其让一条泳道空置,不如直接删掉它;如果某条泳道有一部分由托管服务提供商负责,就把它拆开。

  2. 把每一条受理渠道都写下来

    列出一封钓鱼举报可能抵达的每一种途径:举报按钮、共享邮箱、服务台电话、代人转发的主管、告诉你们发票被改了收款方的客户。然后标出哪些会自动进入分流队列,哪些则取决于有没有人记得转发——那个缺口,正是举报悄悄流失的地方。

  3. 定下分流定性的判断标准

    打开“被举报的邮件是否恶意?”,写下分析师实际会做的检查:发件人身份验证是否一致、仿冒或新注册的域名、URL 引爆、附件沙箱检测,以及邮件是否索要凭证、付款或制造紧迫感。也要说清楚一封令人厌烦但无害的邮件会如何处理,让垃圾邮件的判定成为一个决定,而不是一次耸肩。

  4. 在清除之前先做好范围搜索

    清除的效果取决于它前面那次搜索的质量。记录下你们搜索时依据什么——应该包括发件人地址、显示名称、主题、URL 和附件哈希值——以及你们的工具能追溯到多久之前,通常只是云端邮箱上一段较短的回溯窗口。再单独说明你们如何在本地部署邮箱、归档以及任何已转发到外部的内容中找到副本。

  5. 商定身份响应内容及下令的人

    决定“重置密码并撤销会话”这一步会让你们承诺做什么,以及凌晨三点谁有权下令执行。仅重置密码,会让被窃取的会话令牌继续可用,所以撤销操作要与检查 MFA 方式、邮箱规则和已授权应用放在同一步骤里完成。同时说明新凭证会通过攻击者无法控制的渠道送达用户。

  6. 决定谁来批准全员预警

    在“是否需要全员预警?”旁边写上一个具体的名字,再定下一条阈值:涉及多少收件人、被冒用的是哪些品牌或高管、是否已经有人付款或输入了凭证。提前起草好这份通知,因为在压力之下临时写出来的版本,往往只会提醒员工留意攻击者一小时前已经改掉的那个邮件主题。

  7. 拿一封真实的举报邮件对照走一遍

    取两份近期的举报,一份最终证实是垃圾邮件,另一份演变成了真实事件,和当时处理它们的人一起,把两者都沿着这张图走一遍。那些没人能说清由谁负责的步骤,以及那些明明发生过却没有画出来的步骤,就是值得在发布并演练这份处置手册之前修正的发现。

常见问题

网络钓鱼事件响应流程包含哪些步骤?

员工发现一封可疑邮件并举报,方式是使用邮件客户端里的按钮,或者向服务台开一张附带原始邮件的工单。分析师检查邮件头、链接和附件,得出一个定性结论。一封令人厌烦但无害的邮件会得到给举报人的回复、一次过滤规则调整和一份已结案的记录。一封恶意邮件则会被确定范围:在租户内搜索其他副本,并确认是否有人点击或回复过。随后遏制阶段会清除每一份副本,封锁发件人、URL 与文件哈希值,并在副本持续到达期间反复进行。受影响用户做了什么,决定了后续走向。输入了凭证意味着重置密码并撤销会话,同时检查 MFA 方式、邮箱规则与已授权应用;打开了附件意味着隔离主机并进行扫描;账户被攻陷的迹象则会升级至事件响应。否则,团队会权衡是否需要全员预警,告知收件人需要留意什么,记录失陷指标与各项指标,并与举报人一起结案。

钓鱼邮件响应与网络安全事件响应有什么不同?

范围和触发方式不同。钓鱼邮件响应是一个高频率、在很大程度上可重复的流程,起点是一个人举报了一封邮件,而且大多数案例最终都不会被正式宣告为一起事件:邮件被清除、指标被封锁、举报人得到回复,就此了结。网络安全事件响应流程则从一次检测或一次已确认的入侵开始,依次走过宣告、定级、指派事件指挥官、取证、清除与恢复。两者只在这张图上的一个点相遇:当身份检查显示某个邮箱已经不再由其所有者掌控时,钓鱼邮件响应就完成了自己的任务,把案子移交出去。把两者分开在两个方向上都很重要:把每一封被举报的邮件都推入完整的事件生命周期会拖垮团队,而把一起正在发生的账户接管当成一次邮箱清理,则会放跑攻击者。

有人在钓鱼页面上输入了凭证之后,重置密码就够了吗?

通常不够。现代的凭证钓鱼工具包会以中间人的方式运作:伪造页面代理了真实的登录过程,密码和多因素验证提示都会被转发给真正的服务,而攻击者会截获随之返回的会话令牌与刷新令牌。这些令牌在密码更改之后仍然有效,这正是本图把重置与会话撤销放在同一步骤里的原因,并紧接着检查已登记的 MFA 方式、邮箱转发规则和已授权的 OAuth 应用——攻击者通常留后路的三个地方。从长远看,能够消除这类攻击而不是事后清理的控制措施,是抗钓鱼身份验证。CISA 的指南将 FIDO/WebAuthn 验证器以及智能卡等基于 PKI 的方式列为抗钓鱼形式,因为它们把登录过程绑定到真实域名上,在代理面前会失败。

邮件送达之后,能把一封钓鱼邮件从所有邮箱里清除吗?

只能部分做到,而且值得在你们做出承诺之前先了解清楚这个限度。云端邮件平台为那些送达之后才被证实是恶意的邮件提供追溯清除功能。以微软的 zero-hour auto purge 为例,它作用于云端邮箱中已经送达的邮件,其搜索范围覆盖最近 48 小时内送达的邮件,而且在受 Microsoft 365 保护的本地部署邮箱中并不生效。由分析师在安全门户中发起的搜索与清除,能撒出更大的网,但依然只覆盖那个平台所掌管的邮箱。任何清除都无法触及的,是收件人已经转发到外部的副本、被下载到本地归档的邮件,或者聊天记录里的一张截图。这正是本图在“是否仍有新的副本到达?”上循环、而不是把清除当作一次性事件的原因,也是告知收件人需要留意什么始终留在关键路径上的原因。

一起钓鱼事件必须上报给监管机构吗?

这取决于攻击者拿到了什么,而且不该由分析师一个人来决定。根据英国和欧盟的 GDPR,数据控制者必须在意识到个人数据泄露后毫不迟延地通知其监管机构,条件允许时最迟不超过 72 小时,除非该泄露不太可能对个人的权利和自由造成风险;迟交的通报还必须说明延迟的原因。行业规定、合同和网络保险保单还会在此之上设定各自的时限。实际的做法是,一旦这张图走到账户被攻陷的迹象这一步,法务和数据保护官就会同步介入,技术工作则继续进行。另外,也有多个国家的机构会直接接收样本本身:在英国,NCSC 的可疑邮件举报服务(Suspicious Email Reporting Service)会接收转发至 report@phishing.gov.uk 的邮件。

使用此模板

流程图模板中的更多内容

Browse all 网络安全流程模板