一家总部设在中部某省会的科技企业，主营业务是软件开发和大数据服务，客户覆盖了几个政府机构和一些金融机构。公司的IT基础设施规模不算特别大，但运维团队配置得还算齐全，有专职的安全工程师负责服务器的日常监控和漏洞扫描。但即便是配置了安全管理岗位的科技公司，真正遇到黑客攻击的时候，应对能力往往也没有平时想象的那么从容。
事情发生在某个星期三的下午。安全工程师在例行检查服务器日志的时候发现了一些不正常的网络活动模式，有几个管理员账号在非工作时段产生了大量的登录尝试记录，而且部分尝试竟然成功了。安全工程师的心一下子就提了起来，他马上把情况报告给了IT部门的负责人。部门负责人的反应也挺快的，立刻召集了团队里几个核心成员，包括系统运维、数据库管理员和安全工程师，在IT部门的小会议室里开了一个紧急闭门会议。会议的主题很明确——确认入侵的范围、评估已经造成的损失、快速制定应对方案。
几个人的讨论从入侵路径排查开始。安全工程师调出了近几天的系统日志，分析了攻击者是通过什么漏洞进来的、已经访问了哪些服务器、有没有提取数据的行为。大家越讨论越紧张，因为发现有多个数据库的读写日志在特定时间段有明显的异常，攻击者可能已经获取了部分客户数据。团队开始讨论要不要立刻切断对外服务、哪些服务器需要隔离、数据备份有没有受到影响、需不需要通知客户。整个讨论的内容非常详细，把公司网络架构的薄弱环节、各系统的权限配置情况、以及哪些客户的数据可能已经暴露了的信息都摊在了桌面上。
但这个会议室里的所有人都忽略了一个很关键的问题——攻击者在入侵公司服务器的时候，可能已经在内部的某个点上留下了持久化的后门程序或者远程控制通道。安全工程师虽然发现了入侵的痕迹，但在那个时间点上还没有完全清除掉攻击者对内部系统的控制权。黑客在入侵成功的初期就已经在几台关键的服务器上安装了远程控制工具，可以通过这些工具实时监听系统上的网络流量变化和进程活动。
团队在会议室里讨论的时候，黑客正在通过远程控制通道观察着内网的动静。他发现自己的入侵行为已经被发现，IT团队正在紧急商量应对方案。于是他马上调整了自己的策略，在团队讨论的过程中加速了数据提取的进度，把自己能接触到的客户数据压缩打包，通过加密通道分批传输到了自己控制的境外服务器上。等到IT团队讨论完毕、开始执行隔离和切断操作的时候，黑客已经完成了数据窃取并清除了部分入侵痕迹。团队原本以为能在不被对方察觉的前提下打一场反击战，结果因为沟通信息被攻击者同步获取，整个应对行动的战略意图和时间窗口全部暴露了。
事后复盘的时候，IT部门负责人非常后悔。他说如果当时团队不在会议室里公开讨论入侵范围和数据损失情况，而是通过加密的即时通信工具或者加密电话沟通，黑客就不会知道自己的入侵行为已经被发现，也就不会有那个加速窃取数据的操作。团队在信息不对称的对抗中本来是有机会的，但因为沟通渠道没有隔离，把信息优势拱手让给了攻击者。
从泄密链路来看，第一个环节是IT团队在发现安全事件后选择在被攻破的网络环境内通过不安全的渠道进行讨论，讨论的内容可能已经被攻击者通过遗留的后门监听。第二个环节是团队没有在发现入侵后第一时间切断所有可疑连接，也没有建立一个独立的、与受感染网络隔离的应急指挥通信渠道。第三个环节是黑客利用自己对内网的控制能力，实时获取了IT团队的决策信息，从而调整了自己的行动策略。第四个环节是企业没有制定过针对安全事件响应的通信安全规程，应急时的沟通方式完全依赖平时的工作习惯。
这个案例给所有企业的信息安全团队带来了一个非常关键的教训。当发现系统被入侵之后，紧接着采取的沟通和决策过程本身就是信息安全的一部分。攻击者如果已经进入了你的网络，他也有可能在你不知道的情况下监听你的各种通信。应急响应团队在讨论入侵情况和制定方案的时候，应该使用一个与受感染网络完全隔离的独立通信渠道，比如使用加密的手机通信应用或者独立的语音线路，而不是默认使用公司内网可以访问到的一切沟通工具。你着急解决问题的那个会议室里的讨论内容，可能正在成为攻击者下一步行动的参考依据。发现入侵只是对抗的开始，怎么沟通、在哪里沟通、用什么工具沟通，同样决定了这场攻防战的走向。
