网络安全复盘中最不应该出现的失误,往往不是技术上的高深漏洞，而是那些本可以通过基本流程和制度避免的“低级错误”。
如果一定要选出最“不应该”出现的一类，我倾向于认为是：“已知风险被忽视，或已知流程被绕过”。
以下几类失误在复盘中最常见也最令团队懊悔：
未修补已公开的已知漏洞 这是“最不应该”的典型代表，系统已经发布了针对某高危漏洞（如Log4j、永恒之蓝）的补丁，但在内部资产台账不清楚或运维疏忽下，某台边缘服务器未打补丁，最终被攻击者利用作为跳板。失误点不在于漏洞本身，而在于“知道该做而没做”，且缺乏有效的漏洞管理闭环。
默认口令和弱口令 “账号密码是admin/admin123”“数据库口令和测试环境一致”“离职员工的账号未注销”，这类问题在任何红队测试中都是“见面礼”，但往往在最严肃的生产环境中依然存在。失误点在于：把安全信任建立在对人性的过度乐观上，而非技术控制上。
备份失效（或从未测试过恢复） 复盘时最惊恐的发现不是“数据丢了”，而是“备份一直都在，但恢复不了”，当业务被勒索病毒加密后，IT部门拿出备份，才发现备份文件损坏、备份介质离线不可读、或者恢复演练从未做过。失误点在于：把“做了备份”等同于“能恢复”，却从未验证过备份的可用性。
日志缺失或日志权限失控 攻击者进入系统后，最怕的是留下痕迹，如果安全团队复盘时发现：关键服务器的日志只保留3天、日志被攻击者清空、或者日志存储与服务器在同一台机器上（被一起“端掉”）。失误点在于：没有把日志当成“最后一道防线”来保护，导致事后连攻击路径都无法还原。
权限管控“一锅端” 给所有员工开放了VPN、给所有外包人员发放了核心库权限、或者“开发人员拥有生产环境的sudo权限”，攻击者只要打下一个普通账号，就能横向移动到核心资产。失误点在于：没有遵循最小权限原则，把“内网信任”当成了“安全边界”。
应急响应中的“火上浇油” 在发现勒索病毒时，运维人员为了“保住服务器”，直接拔网线或关机，导致内存数据（攻击者留下的证据）丢失；或者管理员在处置前，先把中毒主机接入内网进行“分析”，导致病毒横向扩散。失误点在于：平时缺乏应急演练，关键时刻凭直觉操作，而非按预案执行。
如果非要选出一个“最”不应该的，我认为是：
“在事件发生前，安全团队已经通过日志或情报看到了预警，但因为汇报流程繁琐、或者担心“狼来了”而选择观望，最终错过了黄金处置窗口。”
因为这种失误,不仅仅是技术问题，更是组织信任和沟通机制的失效，它意味着安全体系在最关键的时刻失去了“刹车”的功能，而这种事后复盘，往往会让人扼腕叹息。
网络安全最怕的不是“未知威胁”，而是 “已知风险未管理、基础规范未执行、以及应急预案未验证”，这些失误共同的特征是：没有把“安全承诺”落实成“日常操作习惯”和“强制技术管控”。
在复盘会上,如果能坦然地承认“我们没做到‘最基本的’”，那这次复盘才算真正触及了核心。
