两年前，我将豆包 APP 推荐给姐姐时，她在亲身体验后满脸震惊与兴奋，直言：“真是个好东西，可以成为企业间竞争的有力武器” ；而今年春节，我与妻子旅游拍照时，一位 50 多岁的视频号博主主动上前搭讪，分享她的创作秘诀 —— 借助豆包对照片进行美化修饰，效果可堪称惊艳。短短 2 年时间，AI 便完成了从极客玩家专属利器到人人可用的大众工具的蜕变，深刻融入了不同年龄、不同职业人群的日常生活与工作。

近期，研究机构 Citrini Research 发布了一份关于人工智能经济风险的假设性报告[4]，其核心推演勾勒出一幅令人警醒的图景：AI 大量替代人类工作导致就业市场萎缩，人类因失去收入来源而购买力下降；企业面对消费市场疲软，为维持利润进一步加大 AI 替代力度，最终使经济陷入 “AI 替代 — 失业 — 消费萎缩 — 更激进替代” 的死亡螺旋。这一设想并非危言耸听，而是对技术变革与社会适应之间潜在矛盾的深刻警示。

一、AI 的发展与趋势畅想

我曾在一篇科幻小说构思中设想过一个 AI 爆发的临界时间点：即，当 AI 具备完全自我更新能力之时。如今，这一设想正逐步成为现实。虽然当前 AI 离 100% 自主迭代还很远，但这个自我优化的比例已在持续提升。Anthropic CEO Dario Amodei 在《技术的青春期》一文中提到，AI 已开始参与自身创建过程，GPT-5.3 Codex 便是首个参与自身开发的模型，Anthropic 的大部分代码也由 AI 编写，这种 “AI 创造 AI” 的反馈循环正逐月加速。按照这一趋势，或许再过 1-2 年，AI 进化将不再需要人类直接参与，人类仅需提供数据与算力支持；甚至在更远的未来，AI 可以实现自主生成数据 —— 其生产效率与质量都将超越人类，彻底摆脱对人类数据的依赖。AI 对人类的需求可能真就是《黑客帝国》中的“电池”。虽然听起来很新奇，但这个过程跟养猪的差别也不会太大：人类划定 “发展围栏”、提供 “算力饲料”、做好 “安全防护”，而 AI 如同生猪一般自主成长，其内在生长逻辑会逐渐超出人类的完全掌控。

回顾 AI 工具的演进历程，这种自主化趋势尤为明显。两年多前，行业分析师普遍预测 “提示词工程师” 将成为热门职业，核心原因在于当时的 AI 工具操作门槛极高，需要通过精准设计的指令才能获得理想结果。但如今，并没有看到这类职位需求呈爆发趋势。随着大模型能力的跃升，AI 不仅具备了一定的 “自我思考” 能力，还能在提示词信息不足时主动引导用户补充输入，极大降低了使用门槛。这种变化在编程领域体现得最为突出：

• GitHub Copilot 阶段：作为较为早期的智能代码补全工具，它完美契合 “副驾驶员” 的定位，人类主导编程过程，AI 仅负责补充代码片段，是辅助人类高效完成任务的帮手；

• Cursor 阶段：AI 实现了显著进化，能够理解项目结构、自主创建文件、修改代码、执行命令，人类角色转变为 “指挥官”，只需下达具体任务指令，AI 便可独立完成执行过程；

• Claude Code 阶段：则实现了工作模式的根本性转变，人类无需告知 “怎么做”，只需明确 “想要什么”，AI 便能自主规划方案、完成全流程开发。相较于 Cursor 的 “白盒式” 编程（人类可清晰追踪每一步操作），Claude Code 更偏向 “黑盒式” 交付（人类仅需验收最终成果）—— 前者聚焦任务完成，后者聚焦目标达成。

• 注：以上主要关注工具创造初期的产品设计思维，而并非后续的功能迭代

在我近期开发一个项目中，仅通过 200 行的产品需求文档（PRD）加 API 接口调用范例，Claude Code 便自主完成了 4400 行代码的开发，且一次性编译成功，大概只需要十几分钟时间。更令人惊叹的是，项目初期采用 Python 语言开发，后因需求变更需转换为 Golang，这一整套语言迁移工作仅耗时数分钟便完成，如果是人来做，可能需要数天。

《黑客帝国》中将矩阵设计者称为 “The Architect”（架构师），这一称谓恰如其分地映射了 AI 在软件工程领域的角色转变。未来的软件工程领域，产品设计师、系统架构师仍将不可或缺，但传统意义上的 “程序员” 岗位可能会逐渐退出历史舞台 ——AI 已成为更高效、更精准的代码实现者。

软件工程领域的变革并非个例，而是各行各业的未来预演。具身智能的进化速度同样令人瞩目：24年春晚还被刘谦 “一推就倒” 的宇树机器人，25年春晚已能自主完成翻跟头等复杂动作；部分工业级具身机器人已进入工厂 “上岗”，承担起装配、分拣等重复性劳动。按照这一趋势，未来 “拧螺丝” 等体力劳动岗位将被机器人全面替代；而 “跑滴滴” 等出行服务岗位，也将逐步被智能驾驶技术与无人驾驶出租车所占据……

从表面看，AI 在技能型、体力型、流程型工作领域的全面渗透，似乎让人类的未来一片灰暗。但技术变革带来的并非只有替代，工业时代将手工制作者转变为了工人，马夫/轿夫变成了司机；计算机时代把文员变成了数据操作员，账房先生变成了财务分析师。在 AI 替代大量现有职位的同时，人类也面临新的机遇与重构。

二、未来的模样：衰退、躺平与发展的三重可能

关于 AI 时代的未来走向，理性分析无非三种情景：衰退、躺平与发展。

（一）衰退：最不可能的危机图景

Citrini Research 在 “2028 年全球智能危机” 报告中描绘的衰退场景 —— 白领大规模失业、“幽灵 GDP”（产出增长但消费萎缩）、商业模式瓦解 —— 虽逻辑自洽，但在现实中发生的概率极低。核心原因在于，政府与社会不会坐视经济陷入死亡螺旋。历史经验表明，每次技术革命引发的结构性失业，最终都会通过政策干预、产业升级、技能培训等方式得到缓解。即便极端情况下可能出现类似《沙丘》中 “人肉计算机” 的小众场景，也绝不会上演《终结者》中人类与 AI 对立厮杀的科幻情节 ——AI 的发展始终处于人类的制度约束与伦理框架之内，其进化方向由人类决定。

（二）躺平：可能的过渡状态

人类普遍躺平是一种具有现实可能性的情景。随着 AI 与机器人技术的普及，大量劳动力将被替代，生产力将向拥有廉价 AI 与机器人的资本集中。在此背景下，政府可能通过加大对资本的税收力度，将部分收益转化为全民福利，使人类进入 “无工作但高福利” 的社会形态。这种模式下，少部分精英将继续主导技术创新与社会进步，成为推动文明发展的先驱；而大部分人则摆脱生存压力，选择躺平生活，专注于个人兴趣与精神满足。

（三）发展：更具生命力的未来图景

“发展” 是最具可能性的未来走向，且可能与部分人类躺平状态并行存在。AI 的大规模应用将极大降低商品与服务的生产成本，使人们即便不工作或仅从事低薪资工作，也能轻松满足基本生活需求。这一变革将推动人类社会从 “生存导向” 向 “生活导向” 全面转变，进而催生第三产业的蓬勃发展，具体将体现在三个核心领域：

1. 物质体验领域：旅游、餐饮、高端住宿等体验式消费将迎来爆发式增长。当生存成本大幅降低，人们将更愿意投入时间与金钱探索世界、享受生活，追求个性化、高品质的物质体验；

2. 精神追求领域：哲学、艺术、文学、音乐等精神文化产品将成为消费热点。AI 虽能生成符合审美规范的作品，但人类对真实情感、独特思想、生命体验的追求，将推动人类在精神领域的创作与探索不断深化；

3. 生命科学领域：健康管理、抗衰老研究、疾病治疗等与生命质量相关的领域将获得空前发展。随着物质生活的富足，人们将更加关注生命本身，推动生物医学、基因技术、健康服务等行业的快速进步。

三、人类的机会在哪里？

AI 的发展趋势清晰可见：价格将越来越低廉，智能水平将越来越高。凡是依赖技能积累、经验复用的职业工种 —— 无论是程序员、工人、客服，还是金融分析师、法律顾问 —— 都将随着 AI 能力的提升逐步被替代。

那么，人类的核心机会在哪里？我认为答案藏在人类与 AI 的本质差异之中：从短期来看，AI 在真实性和 “温度” 上远无法模仿人类；从长期来看，AI 永远无法比拟人类的 “血统”（生命传承与物种特性）和好奇心（对未知世界的探索欲）。

人类的未来，或许就在于坚守并放大这些独特的差异。

（一）短期机会：依托真实性与 “温度”，深耕人文服务

AI 可以模拟共情，但无法拥有真正的情感；可以生成标准化的服务流程，但无法提供带有人类温度的个性化关怀。基于这一差异，以下领域的人类需求或将长期不可替代：

1. 教育培训领域：教师的核心价值不仅是知识传授，更在于价值观引导、思维启发与情感支持。AI 可以成为教学辅助工具，但无法替代教师对学生个体差异的洞察、学习兴趣的激发以及成长过程中的陪伴与鼓励；

2. 医疗健康领域：医生、护士等职业的核心竞争力在于对患者的人文关怀与临床判断力。AI 可以辅助诊断、分析病历，但无法替代医生与患者之间的信任建立、病情沟通，以及面对复杂病症时的经验判断与情感支持；

3. 政府公务与社会服务领域：政府公务、社区服务等工作直接关系到公众利益，需要人类的责任担当、道德判断与灵活处置能力。AI 可以提升服务效率，但无法替代人类在政策执行中的人文关怀与复杂情况处理；

4. 心理咨询与情感陪伴领域：人类的情感需求具有极强的独特性与私密性，需要真实的共情与理解。AI 可以提供情绪疏导的参考，但无法替代心理咨询师的专业洞察与情感共鸣，也无法提供真正的人类陪伴。

（二）长期机会：依托 “血统” 与好奇心，探索未知边界

AI 的进化基于数据与算法，其目标是优化现有答案；而人类的 “血统” 决定了我们拥有生命的传承，好奇心则驱动我们不断探索未知、创造新知。基于这一本质差异，以下领域的需求或将持续增长：

1. 基础科学研究领域：材料科学、量子物理、天体物理等基础学科的核心是探索未知规律，需要人类的好奇心、想象力与坚持不懈的探索精神。AI 可以辅助数据处理与实验模拟，但无法替代人类提出颠覆性假设、设计创新实验、追求科学真理的内在动力；

2. AI 相关科学领域：包括 AI 工程、AI 算法优化、AI 伦理治理等。AI 是人类创造的工具，其发展方向、应用边界、伦理规范都需要人类来定义与把控。人类需要持续探索 AI 的技术极限，同时建立健全相关制度，确保 AI 始终朝着造福人类的方向发展；

3. 生物医学与生命科学领域：对人类自身的认知、生命奥秘的探索、疾病的攻克，是人类永恒的追求。AI 可以加速药物研发、基因分析，但无法替代人类对生命价值的敬畏、对健康福祉的追求，以及在医学研究中面临的伦理抉择与人文考量；

4. 艺术与创意领域：艺术的核心是人类生命体验的独特表达，包括情感、思想、文化传承等。AI 可以生成符合审美规律的作品，但无法拥有人类的生命体验、文化积淀与创作灵感，也无法替代人类通过艺术表达实现的自我价值与精神共鸣；

5. 哲学与社会科学领域：对人类社会、文明发展、价值意义的思考，是人类作为智慧物种的独特追求。AI 可以整合现有知识，但无法替代人类对存在本质的追问、对社会正义的探索，以及对未来文明形态的构想。

四、结语

AI 的发展不是为了替代人类，而是为了解放人类 —— 将我们从重复性、流程性的劳动中解放出来，让我们有更多时间与精力追求更有价值、更有意义的生活。从极客工具到大众应用，从辅助工具到自主系统，AI 的每一次进化都在推动人类社会的重构。

未来并非一片灰暗，而是充满了无限可能 —— 关键在于人类能否认清自身的独特价值，坚守本质差异，在技术变革中主动拥抱变化，在探索未知中实现文明的跃升。

参考：

1. https://mp.weixin.qq.com/s/z7zNi_DayzevcTe0EUTv5g 过了个年，AI 圈变天了？但没人告诉你为什么

2. https://www.darioamodei.com/essay/the-adolescence-of-technology Something Big Is Happening

3. https://shumer.dev/something-big-is-happening The Adolescence of Technology

4. https://mp.weixin.qq.com/s/4hXyDdJqEBZgTcQ0gI0RdQ?scene=1&click_id=30 2028年全球智能危机——一份来自未来的金融历史思想实验（中文版）

阅读原文

跳转微信打开

内容来自2025年05月14日，京东第十七届京麒沙龙上的技术分享的语音转录。近年来，蓝军实战攻防战术“内核稳定，外延革新”，本次分享将结合实战经验和思考，深入剖析近年来蓝军实战攻防战术的演变情况，进行深入的技术交流与研讨。

内容来自2025年05月14日，本人在京东第十七届京麒沙龙上的技术分享的语音转录。

大家下午好，非常高兴今天能与大家进行技术分享。感谢组织者的精心组织，使我有机会与大家进行技术探讨、学习和交流。今天我要与大家分享的主题是《蓝军实战攻防战术演变》。

大家应该都知道，蓝军的工作从上至下分为8个阶段：最上面是目标，然后是整体战略，再往下是战术、技术、技术的实现过程、工具以及工具产生的主机和网络工件，最后是原子指标。

我们工作中更多关注工具以上层面。其中技术过程和工具，大家之前已经讲了很多，而且有些细，因此本次分享没有挑选这一部分。至于上面的目标与战略，我在之前的一些技术分享和BCS等其他会议上讲过，包括团队建设以及红蓝对抗量化指标等。所以这回，我挑选了中间一个环节，即战术层面，与大家进行技术探讨和分享。

围绕蓝军实战攻防战术，我认为整体作战套路上并未发生根本性变化，但在战术思路上的确有很多的演变。今天我们将分为三个章节：首先总结下“始终未变的”部分，然后我们将讲下最近3到5年蓝军在作战战术上的实际变化。

第三部分会介绍在蓝军的实战工作过程中，一些小噱头或者创新。我认为虽然它（噱头与创新）虽然不代表蓝军的主要实战攻防作战方向，但是可以会成为我们在实战过程中的润滑剂，并获得一定的效果。因此，（这部分）我将向大家介绍我们在工作过程中的实践与探索。

我们首先来看第一部分始终未变的。它大致分为主动和被动两个维度。

主动部分不变的是渗透的三个阶段和套路。渗透手法一直在不断迭代，但从近20年来看底层逻辑一直未发生太大变化。大致来说，第一步是进行信息收集或者叫情报收集，然后发现潜在的问题和利用点。接下来是利用潜在问题、漏洞和利用点获得初始访问权限或者立足点，即我们所谓的打点过程。接下来的阶段是利用这个点进一步扩大权限，实现内网漫游或者横向移动。我将这个整体攻防过程简单总结为：情报、打点和横向。

我们针对每个阶段进行细化来看：情报阶段主要关注资产、数据和人员。我们之所以关注这些，是因为在资产上可以发现漏洞的暴露面。在数据层面，我们可能发现代码和凭证等信息，人员层面可以辅助下一步的社工工作。在打点阶段，基本就是利用漏洞、凭据和社工。有人可能提到物理渗透、供应链等，但实际上也不外乎上面提到的这三种。横向阶段，你需要完成三件事情：一是本机信息收集、权限提升或者权限维持；二是进行网络结构绘制以及网络弱点发现；三是从本机移动到你想要移动的位置。

整体方法套路就是这些。

我在公司内部也进行过一些技术分享。我对此的评价是：“太阳底下没有新鲜事”。不过，话虽如此，站在宏观层面这个东西的确没有变化，但站在战术层面，其实还是有很大的改变（后面会提到）。

另一个“不变”是被动的原因造成的，是由于我们的工作底线和职业操守所导致。这使得蓝军的工作战术与实际模拟攻击者的战术有一定区别。我给蓝军设了两条工作底线：一是在任何时候不能影响业务正常运行，二是在任何条件下不能留存用户数据。虽然我们在整个工作过程中不可能完全看不到用户数据，但是只要不留存，就符合我们的工作底线。

基于这两条工作底线，实际上它会导致我们有很多战术不能使用或者很少使用。右边这张图中，标黄和标红的部分是我们最近一次在做背靠背实战攻防演练中所使用的战术和相关技术。可以明显看到“影响”这一块几乎没有。

在我们实际工作过程中，始终很少用到的战术有：长期的持久化。短期权限维持是有的。但长期的持久化，比如长年累月不掉线，这种我们基本上不会去做，因为这个时候必然会对业务造成影响。而且蓝军的实战背靠背工作具备一定的周期性，不能把这一次的控制权限带到下一次工作当中，这也是一个要求。

另外利用漏洞进行提权，这个也很少使用。主要原因在于，使用漏洞提权时，很可能导致主机蓝屏或者服务Crash。另外，劫持类的采集操作，比如内网的MiTM流量劫持，我们很少会使用或者不使用。

除此之外，还有例如“捕鲸行动”。很多黑灰产、黑客可能会盯着公司的大鱼和高管进行社工。但作为蓝军，如果对他们采取行动，就可能会造成不必要的误判。

黑客在渗透到内网后，获得一定的内网服务权限时，通常会修改系统进行水坑攻击，这种情况蓝军也很少进行，主要怕难以控制攻击范围或对业务造成影响。

除此之外，在传统黑客攻击中，它会先攻击供应链，然后从供应链中找到跳板渗透企业内部。这种我们也基本不做，原因在于蓝军的攻防授权只在公司内部，不在外部。所以我们也不会用这种战术。

此外，目前阶段，我们对边界类漏洞利用较少，由于ASM攻击面管理的不断完善，边界类漏洞逐渐减少。此外，SRC（安全应急响应中心）的白帽子也在一直尝试发现这样的漏洞，他们第一时间的提交，使得这类漏洞的可暴露窗口期很短。

以上这些都是不太会变的，接下来我们观察发生变化的有哪些？

我对此进行了整理，包括7个部分：第一是社工方式有变化，第二是资产发现方式，第三是漏洞利用方式，第四是命令控制方式，第五是凭据利用方式，第六是针对集权系统的选择上。第七点是云渗透，它与前些年相比，近些年更多地被我们利用，后面我会与大家进行详细的说明和探讨。

在社工变化中，我们之前主要使用钓鱼方式，尤其是撒网式钓鱼。我记得我刚来公司时，他们在进行内部实战攻防时，对2000人进行钓鱼攻击，这可能会造成不必要的麻烦和影响，因此目前我们使用得较少。

目前我们主要进行鱼叉攻击。首先，我们先找这人是谁。上面提到情报收集阶段，我们会收集人员信息。在这个过程中，针对人员和角色，制定专门针对他的社工方案，然后实施鱼叉攻击。一是暴露面小，二是针对性强，最终成功率会更高。

除此之外，近一两年我们更多地采用混合式钓鱼方式。譬如通过小红书针对内部员工发布活动，或者通过微信、电话或者其他内部活动的方式开展钓鱼。

右侧这张图展示了我们近期开展的一次钓鱼攻击案例。我们看到它模拟了一个活动并放置一个二维码，这个二维码实际上是一个Evil Proxy，最终目标是获取经过MFA认证过的登录Token。

随着SSO和MFA的不断普及和覆盖，现在再通过社工库、撞库或者钓鱼等方式获得账密已经基本无用。因此我们更多使用Evil Proxy、聊天扫码等方式进行社工攻击。

除此之外，我们今年也进行了其他尝试。以前我们更多的是针对员工的公司邮箱来发起钓鱼邮件。但目前，SEG（安全邮件网关）已经相对成熟：首先，当外部人员给内部发送邮件时会有提示，表示邮件来自外部，需要小心。其次，SEG上面的安全策略和沙箱策略做得也相当不错，鱼叉攻击更容易被发现且难以规避。所以，今年我们尝试与对应的社工目标联系，诱使他们为我们提供个人或者外部的邮箱，然后我们进行鱼叉攻击。

除此之外，以往的横向操作更多的是当我们获得员工的邮箱权限后，通过他给别人发信息获得更多的权限。目前几乎每家公司都有自己的即时办公软件，例如企业微信、钉钉和京me等。我们现在更多通过即时办公软件进行横向操作，实际上它的效率和防御绕过的能力会更好。

这是社工上的一些变化。

第二是资产发现方面的变化。

我们以前基本是在设定目标后，就进行子域名爆破，发现IP、IP段，并进行端口扫描和漏洞扫描。

但目前，网络安全进入高强度防御阶段。首先互联网攻击暴露面变小，其次攻击动静也会很大（更容易被发现和处置）。因此，我们现在进行端口开发性测试，更多会以服务链接的方式代替端口扫描。针对漏洞，我们不会像很久之前那样使用类似于APPScan或者AWVS等进行批量化扫描：一方面很难再扫描出有价值的漏洞，另一方面很可能在扫描过程中被发现、识别和阻断。

我们现在一般通过服务连接方式确定资产类型和版本，并进行POC概念性验证。之后我们再编写具体的EXP，根据防御规则和手段进行最终实际利用。

此外，我们原本主要采用扫描方式获取资产，现在更多采用资产爬取方式，然后对内容进行解析和进行有限字典枚举等。

在漏洞上这些年有很大变化。

以前更多是通过漏洞利用，进行外网打点来获得WebShell，或者对一些外部系统进行Get Shell。但现在想获得这种Shell的难度很大，防守方出现百密一疏，即某个资产不在他掌控范围内，你才有可能有这样的机会。否则，很难有这样的机会。因为新爆发的0day、1day，只要在他掌握的资源范围内，漏洞就会很快被修复。对于短期难以被修复的，他也会很快采用WAF和RASP策略拦截阻断。这导致我们漏洞的发现和利用与以前有很大不同。我们现在更多地利用权限控制漏洞或者配置错误漏洞。

偶尔我们也会使用一击必杀，主要针对自研软件。针对一击必杀，我们主要发现这么几类漏洞：首先是凭证伪造类，利用凭证设置或者置换不合理，可以伪装成其他人。其次还包括RCE以及其他权限类问题等。

第四是控制方面也发生了一些变化。

以前我们基本是获得Webshell，获得C2，或者打下点以后做一个反代，基本上是这样一个方式。这种控制方式大家都比较熟悉，现在这种方式不太可行。因为Webshell可能会被第一时间发现，C2可能很快被NIDS、HIDS所发现。反代的话，模拟成HTTPS会好一点，纯TCP、UDP被发现概率也很大。现在我们更多采用如下策略：

第一种是LOTL，这是国外的名词说法，称为Living Off The Land，指在土地上生存的意思，我认为将其翻译成中文可能类似于以战养战，或者因粮于敌（孙子兵法）。即，在进一步横向过程中，并不使用自己的攻击工具，而是利用现成的系统工具。大部分使用方式包括以下几种：

一种是无恶意软件活动，我使用正常系统的功能和命令。第二，目前每个系统、容器等都会有一些内部运营工具，我可以复用这些工具开展攻击活动。第三，每台机器上可能都有各种Agent，包括OP Agent和安全Agent。我们可以通过挖掘Agent功能性漏洞实现内网横向。

此外，许多业务系统为方便对线上系统进行管理，会留存业务级别的后门。这种后门的鉴权能力会差很多，并且一些鉴权方式具备一定的通用性。例如，一旦获得某个内置的口令和密钥，就可以实现一打一大片的效果。因此LOTL是目前我们使用较多的一种手段。

其次，在获得立足点并进行横向过程中，我们更加关注NHI，即非人类身份。我曾经查阅相关报告，报告中提到对于一个中大型企业而言，非人类身份远大于人类身份。人类身份一般指以ERP为主的身份，非人类身份一般要十数倍或数十倍于人类身份。而，我刚才提到的MFA主要防护的是人类身份，而非人类身份主要以Token、密钥、key为主，缺乏MFA防护。针对非人类身份的凭据复用对我们进一步的攻击非常有帮助，它也成为我们有效的权限控制的一种手段。

针对PC机，在以前我们一般会钓到一个人，给他中一个马，并进一步控制他的PC去钓其他人，或进行针对IDC的一些穿透性的漫游。但随着EDR、UEM能力的不断提升，如果有一个可执行文件落地，基本上会很快被发现。因此在近一两年内，我们在对PE的控制上也做了一些其他方面的尝试。例如，我们不再控制终端，而是以获得终端上所登录的凭证为主。

刚才提到终端可能会有譬如VPN Agent、零信任Agent，以及办公即时通讯软件等，那么这些软件或Agent上一般带有登录态，我们将登录态抠出来后可以复用这个人的身份，进一步开展内外渗透。这种终端的登录态一般还有一个好处，即可以进行登录态置换。当你进行登录态置换时，可以换成一大堆其他动态，这是控制上的一些变化。

接下来我们看凭证利用上的一些变化。

在以前，我们主要以获取账密为主，当通过钓鱼、社工等获得账密以后，我们再通过账密去进一步获得这个人的凭证。

现在，首先因为有了MFA，很难绕过MFA直接获得登录凭证。其次，在进行账密登录过程中，也会有一些异地登录告警或拦截等防御方式，意味着账密攻击变得越发困难。

目前我们主要通过以下手段解决问题。首先我们不再直接钓账密，而是通过在整个MiTM或BiTM过程中获得登录态信息，绕过MFA登录验证。第二，我们在获得SSO Token后，因为单点登录通常具备对其他应用系统的Token置换能力，可以让员工无感登录不同系统。当获得一个人的Token后，就基本上具备了这个人在各个不用应用和系统上的访问权限。

在我们的历史实战攻防案例中，我们最多通过A Token置换B Token，B Token置换C Token等，置换过4次Token来达成对目标系统的访问。

除此之外，我们会用心收集ak/sk、ssh key等信息，并进行Open API的提取和使用。

不过账密也并非完全不使用，更多针对数据库、运维、运营及日志类系统。之所以它仍然可用，第一，是因为这些系统缺乏一定的安全管控能力或者存在安全管控不到位的情况。第二，这类系统属于开发运营人员之间的系统，并非属于业务系统或者前端应用系统范畴。它对接入SSO没有强制性要求，所以给攻击者留出来较大的可攻击空间。同时它可能也不会去接零信任，日志系统在正常操作过程中可能会存储一些Token或ak/sk，即存在数据未脱敏情况，这些都是我们可以进一步利用的方面。

第六方面是集团系统的控制和选择发生了很大变化。

以前，我们更多地是将譬如域控或者企业主站之类作为渗透目标来开展工作。但从最近几年，随着蓝军工作的不断深入。我们认为之前所谓的目标并非真正的目标，它只是过程性的指标，而非结果性目标。

结果性目标，它一定是跟黑客、黑灰产最终要达成的目的相同。

例如，黑客的目标可能是为了获得数据、导致系统瘫痪，或某种其他的系统控制。而如果我们围绕这些目标来看，并不一定要控制唯一的信息系统，我们有太多的点可以利用。我们从DevOps的各个阶段来看，每个阶段都有相应的系统。只要相应系统能够达成你的目标，就可能成为你最终的控制目标。

因此，我们现在不仅控制集权系统，还可能控制集权系统的外延。例如，如果我们将线上业务系统数据作为最终目标，那我们可能不会选择去直接控制它，因为它的防护可能会很强，我们可能会尝试控制与它同样接线上数据的预发系统。针对预发系统，它的安全策略可能并不严格，安全防护能力也不强。这就可能成为我们的一种新的工作方式。

另外，我可能为了获取数据，不选择控制业务系统，而选择直接控制数据库、日志系统或者数据分析系统，以及寻找整个数据在流转过程中的一些调用链，例如mq、缓存等，这些都是我们可以使用的新的方法。

除此之外，在横向过程中，我们现在更加关注对DevOps和CI/CD阶段的相关系统控制。包括：代码管理的相关平台、系统部署的相关平台应用、配置服务器、镜像存储的相关服务器、线上实际容器以及相关日志等，这些都将成为我们的控制目标。

这是在横向阶段以及对集权目标系统的选择和控制上的变化。

第七部分是云渗透，（照比前些年）它有更多被使用。

在三、五年之前，我们并不十分关注云渗透。主要原因在于当时云渗透的整体安全性能力，与当时企业系统外网攻击暴露面和内外的实际防护情况相比，安全性相对较高。

然而，随着企业安全能力和水位的不断提升，通过企业内外网直接打点的难度已经变得相当高。与此同时，我们回顾云服务发现，它由原来的长板变成新的短板，因此现在反而在实际过程中会更多地被使用。

而云服务目前看，暴露的问题非常多。从右侧两张图可以看出，对于云服务而言，提供的服务及应用实在太多，很多应用又涉及到对内网IDC的服务调用。最终导致云服务的服务众多、网络复杂和应用多而繁杂。例如京东云、腾讯云、阿里云，这种细分的应用普遍超过200个，有的甚至可以达到300个左右。这么多应用意味着只要某个应用出现问题，都可以成为进一步利用的点。

在实际的攻防渗透过程中，我们发现可以利用的点包括以下几个方面：首先是内部新孵化的应用。许多应用并非从创建的第一天就为C端用户使用，最初可能是做内部孵化项目或者作为内部提效的生产工具。在这个工具的使用过程中，它们会不断成熟完善，直到某天具备一定的成熟条件，它们可以挪到外部，作为一个对外的应用。而在应用从内到外的迁移过程中，可能保留原有的配置、权限和痕迹，这些痕迹很可能成为我们的利用点。这种问题在实际工作中也有所发现。

另外是网络隔离问题。我刚才提到云有很多复杂应用，这些应用会进行内网服务调用，导致整个隔离变得越发复杂。除此之外，每个服务都有相关的Agent、容器、K8S，这也暴露了很多问题。随着AI的发展，各个云服务都有上新的能力，譬如LLM、MCP、AI Agent等，从我们的实际掌握情况来看，都存在安全问题。

第三部分是噱头与创新。

在工作中，除了上面提到的，有板有眼地以目标为导向开展一些工作外，我们还会进行一些创新性或者趣味性的尝试。

例如，除了上面提到的对AI相关的攻击，我们也做过一些WiFi攻击和物理渗透。右侧是我们在某次物理渗透中将员工制卡机黑掉，并通过这个初始访问点进行内网渗透。

另外我们也做了一些AI+攻的尝试和利用，包括自动化代码分析、漏洞挖掘、钓鱼文案编写，以及员工在社交媒体上的社会化分析等。不过，从目前的实际情况来看，想要使用AI+攻实现蓝军全链路的无接管攻防不太现实，它对人员思路创新性的要求实在太高了。

在对抗形式上也有一定的变化。

以前更多的是限制时间，限制手段，会提前告知防守方什么时间段，采取何种形式对什么靶标开展工作。在整个过程当中，他们一直在监控我们，导致整个攻防激烈。很多时候我们的攻击可能会搞到后半夜，目的是为了实现一个不对称性对抗。

现在，随着防守侧防御能力的不断提升，他们的信心也在提升，并且整个攻防和安全运营也步入到常态化阶段。目前我们与他们基本上是背靠背的实战攻防过程，不会限制时间和手段，也不会提前告知。

在我们的工作过程中，以前以靶标为导向，因此我们采取短平快的策略。当我拿下靶标后，你发现我就发现我了，我已经完成了我的工作目标。现在，我们会把时间拉长，尽可能少触发或不触发告警，降低被发现概率，整体以绘制路径为导向。

右边这张图经过我打码的，主要想跟大家展示我们目前是以控制对企业造成重大影响的系统或数据为目标，并绘制攻击路径，会以这样的形式展现。

除此之外，在演练形式上有一定的探索和更新，可能也太不能算做创新。

例如，除了背靠背的实战攻防演习外，我们还会开展针对具体的安全防御能力的红蓝对抗，如人脸识别的红蓝对抗，大模型的安全评估，身份盗用对抗，针对NIDS、WAF的对抗，接口签名对抗等等。

我们也会借鉴国家级HW开展沙盘推演。

除此之外，在近一、两次背靠背实战攻防演习中，我们加入了溯源演练。之前攻击完成后形成报告即可结束。

最近一两次攻防结束后，我们会将一些数据以匿名方式提供给情报中心，让情报中心以正常情报的方式为安全运营做成输入，查看他们在数据溯源方面的情况。账号接管是在我们获得权限后，通过一定形式将少了账户接管信息同步给防守方，让他们去溯源账号是如何被接管的？手段是什么？能否及时止损和处置？是否还有其他被接管账号等等。这样的溯源演练更有利于防守侧检验和提升溯源方面的安全能力。

最后跟大家做一个总结。

我认为，目前的实战攻防，整体处于道高一尺、魔高一丈的状态。攻击技术的不断演变是由于防守方的不断进化所导致。例如：EDR的普及，使我们减少可疑文件落地，使用多阶段C2的次数增多；SBCP安全文件升级，使社工向多平台及定向深度伪造进行进化；SEG的提升，使我们会以外部邮箱为目标，抛弃常规钓鱼附件的方案；MFA的全覆盖，使得我们使用Evil Proxy和凭证复用成为一种更主流的突破方式；SSO的覆盖和办公便捷化，使得多平台Token置换成为可能性；漏洞的事前、事中、事后的检查，使得常规性漏洞逐渐减少。我们使用逻辑漏洞和配置漏洞更多；攻击面管理的升级也使我们转向云原生、研发、运营周边或者AI应用。

最后，总结一下蓝军的未来和演变趋势。

我觉得，虽然整个对抗仍然处于不断升级和进化的过程中，但蓝军肯定可以始终处于一个能不断发现安全运营和安全防护风险的过程当中。

原因主要有以下几点：

第一，万物皆变，人是安全的尺度，这是ISC 2017年的主题。老周也提到网络安全的本质是人与人的对抗。我加了一句“而，世界是一个巨大的草台班子”。我们发现防守侧人员的安全能力以及研发侧人员的安全能力并不一定是持续提升的，随着人员流动会有起伏变化，尤其每当一个新系统上线就会面临新的问题。

第二，有人的地方就有漏洞。虽然实战攻防过程中没有引弹，但是安全遵“水往低处流”的原则。刚才我也提到云安全最初属于一个长板，随着其他安全能力的提升，它反而会变成一个短板。而，新事物带来新的挑战。上面提到MCP、AI Agent、大模型等新技术都带来了新的问题。

第三，顶层越来越猥琐，底层越来越变态。这句话是在08、09年左右与大风（刺）聊天时提到的，目前依然奏效。顶层方面，我在关注近期国际APT组织的变化中，发现譬如Lazarus、暴风雪等组织都在使用ClickFix攻击技巧，虽然这是一种非常猥琐的社工方式，但是十分有效，反而使得这种攻击有愈演愈烈的趋势。底层方面也是如此，像接口验签最开始只是简单的加密和哈希，然后开始加入算法白盒化、代码混淆、VMP、WASM等，目的就是通过让自己更变态来不断增加对方破解成本。

所以，我认为实战攻防未来更多的是对脑力和体力的挑战。譬如你能不能想到一些新的突破点，能不能坚持完成防守方给你留下的变态挑战。这可能是未来的演变和变化。

以上就是我要与大家分享的内容，谢谢。

Q & A

Q1：可反哺企业安全建设的红蓝对抗可量化观测指标有哪些，如何将红蓝对抗和企业安全建设形成一个有效闭环

A1：我们在整个红蓝对抗过程中一直在考虑这个问题。例如当蓝军将红军打败或者打穿时，究竟是蓝军强还是红军弱，我认为这在很久以前一直是个问题。我加入公司后创建了一个名为“红蓝对抗评分框架”的系统（rtass.jd.army），这是一个能够明显观察红蓝对抗过程中各方面能力水平的指标。这是可量化指标方面。

在对防守赋能方面，每次红蓝对抗并不意味着工作结束，除此之外我们还会进行问题分析和复盘。最近，老板给了我们一个新的角色和定位：不仅要复盘，还要跟进防守侧的治理进度，最终实现验收。我认为这可能就解决你刚才提到的问题：通过红蓝对抗发现问题，通过复盘将问题变成治理项、行动项，跟进治理项的实施，通过验收Close问题，形成闭环，这样已有发现的问题可能被解决。然后，蓝军可以进入下一个循环，去发现一些不在现有掌握范围内的新问题。

Q2：这种token控制 如果遇到失效或者过期怎么处理 有没有备用方案？

A2：其实Token这个东西很明显是指一类的登录态或者一类的凭证，所以Token本身就分成长期和短期等不同种类。我们在工作过程中，各类Token都会获取，也会去做Token的一些状态维护和刷新。

Q3：实战过程中经常被员工顶掉登录态，没办法太好维持

A3：我认为针对只能在单个设备登录的情况，一种方法是获得更高的动态。刚才我也提到在整个Token的置换过程中，我们为了获得目标系统权限，一共置换了4次登录态。即使某个登录态被踢掉，也不会导致接下来的3个登录态全部被踢掉，因此在这个过程中你可以控制不同阶段的登录态。第二，我们不会将用户的登录态作为长期持久化的方案，我们获得登录态的最终目标是获得系统权限。获得系统权限之后，再去获得NHI的身份，它的登录态可以被自己获得或者维持，这样会更好。

我们也遇到过登录态被踢掉的情况。我认为如果将其作为长期策略，那么确实不是一个非常好的方案。最好的方式是在登录态尚且有效的情况下及时横向移动出去，或者及时置换成其他登录态或权限。

Q4：演练不通知防守方的话，是由蓝军来控制演练的进度吗？演练的周期和范围怎么选择？每次是对集团开展演练，还是会聚焦在业务线上。

A4：是的，演练由蓝军主动发起，控制进度，以及确定最终结束。演练周期方面：你可以确定一个大且宽泛的周期，例如每半年或者每个季度为一个周期。范围的话，我们会把公司所有资产都作为演练范围。

然后针对每个季度或每半年这个大的背靠背的实战攻防演练，我们是针对集团展开的，不会聚焦在业务线上。不过，有时业务线会找到我们或者我们主动想要评估某个业务线的安全性，我们会进行具体的红蓝对抗或者开展一次小型演练。

Q5：在甲方的红蓝对抗中，如何能够整体化、连贯性去看待，避免总是围绕攻防项目走？

A5：这个跟我刚才回答的Q1的问题是一样的。我们不能将红蓝对抗视为一个单点，因为红蓝对抗是有目标的，这个目标是：以攻促防。是为了发现短板去提升最终的防护能力和水平的，所以最终还是要实现闭环，原则的话，就像我Q1中提到的方式。

Q6：蓝军团队除了各种定期的演练、专项工作外，团队成员在非演练期间的日常工作一般是如何安排，还有如何对蓝军团队成员进行考核呢？

A6：考核这个有点大，今天时间有限我就不细说了，如果有机会，我们可以单独讨论。关于非演习期间的工作安排，我之前提到除了实战攻防演习模式外，我们还可以开展红蓝对抗和沙盘推演。我们还可以针对重要信息系统开展风险评估，开展溯源对抗演练等。除此之外，公司有时会有一些战略项目，这些战略项目既重要又紧急。蓝军可能会充当渗透测试工程师，针对这些战略项目开始渗透。

好的，由于时间关系，今天的交流就到这里，谢谢大家。

（PPT点击“原文链接”下载）

• “红蓝对抗演练评分系统”开源框架 (preview)

• 如何开展蓝军工作与量化评估

• BREAK业务风险枚举与规避知识框架v0.1.0

• DSRE-数据安全风险枚举知识框架

• 中小企业及创业公司信息安全建设指南

阅读原文

跳转微信打开

中小企业及创业公司如何开展信息安全建设？在公司发展什么阶段开展？如何开展？要遵循什么样的原则？重点关注解决什么问题？跟业务的关系是什么？如何考核？价值如何衡量？

注：本文以问答的形式来形成这份“中小企业及创业公司信息安全建设指南”，文中探讨了信息安全之于公司发展前期、团队建设、安全运营阶段及安全价值的各方面问题，助力企业做好信息安全建设。

一、公司发展前期

• 一家公司从什么时候起，应该研究建立信息安全部门？

几乎所有的大公司都经历过从弱小到强大的过程。在存活阶段，只有先活下去才是最重要的，信息安全什么的实在不应该奢望。但对于老板而言，到底应该在公司发展到什么阶段时，研究建立专门的信息安全部门呢？我觉得可以考虑如下几点：①已经有了实际的攻击事件；②公司已经进入了监管视线，会接收到监管指令；③公司在对应领域的市场份额快速增大；④通过IT策略来进行安全隔离和能力部署已经到了瓶颈；⑤已经有了比较明显的竞争对手；⑥内部员工增多，人员素质开始难以把控，且随着团队的增加，出现了部门墙；⑦公司已经基本度过了存活期，或者相对来说比较有钱。

当然，在建立专业的信息安全部门之前，一家初创公司也不见得什么安全能力都不存在，一般来说可以先让IT部门来承担一定的信息安全工作职责，譬如：员工权限管理、内外网的环境隔离、办公-开发-生产等环境的隔离、防火墙杀软的基本配置、运营与管理、一些基本的安全设备或软件的常态化安全运营工作，甚至对于部分业务复杂度低的公司，还可以招募1到2名渗透工程师到IT团队，来承担一定的产品渗透测试和网络渗透测试工作。

• 一家处于存活阶段的公司，要考虑信息安全吗？

答案是肯定的。越是弱小的公司越经不起大风大浪，很可能一次较大的信息安全事件就把公司干倒闭了。譬如Kaspersky发布的《勒索软件报告》中有提到：40% 的小型企业表示，如果遭遇勒索攻击而无法恢复数据，可能会导致其难以继续运营。

但小公司可能连盈利都达不到，是养不起专业信息安全团队的。所以最好的方式就是：向安全乙方厂商购买安全产品和服务。一般来说，定期的渗透测试是必须的，这个时间周期可以根据产品迭代的频次而动态调整，但一般建议最长不要大于1年，按季度为宜，按月亦可。而且建议跟购买安全服务的乙方工程师搞好关系，因为他对你公司使用的技术栈、组件、中间件、服务等都很了解，以便及时获悉零日漏洞资讯，或者干脆花点小钱来购买相关威胁情报服务。当然，自身的IT员工来关注所使用组件和系统的漏洞资讯亦可，这些资讯在各组件的官方网站或下载渠道都会公布。此外，终端安全防护和边界安全防护也有必要性，应按需采购。

我这里随意列一些安全乙方出来，可供安全服务和能力采购时参考：奇安信、深信服、天融信、绿盟科技、启明星辰、360、安恒、长亭、知道创宇、华顺信安、亚信科技、北信源。排名不分先后，而且也不保证齐全，不过这些公司的安全能力、产品和服务都是很好的，对付小公司是游刃有余。当然，联系到安全销售时，他总是想把各种各样的东西卖给你，你有一万的预算就能花掉你一万，你有一个亿的预算他也能花掉你一个亿。所以，选择适合自己的最重要，不要追求所谓的极致的安全。极致的安全是不存在的，只要能大体上控制好资产暴露面的安全风险就好。

• 安全就是为了防黑客吗？

安全的防御目标之一的确是黑客，但却不仅仅是黑客。更准确地说，安全是为了防御影响公司正常运营的“威胁行为者”。而威胁行为者不仅仅只有黑客一种，还至少有如下几种：①企业的客户，譬如对于电商型企业，买家有0元购、薅羊毛、自动化抢购等，卖家有违规商品、虚假交易等，对于游戏行业玩家有使用外挂、非法交易、利用bug等；②合作伙伴，有广告欺诈、数据泄露等；③供应链，有商密、舆情、外包等风险；④内部员工，如违规操作、贪腐、内外勾结、安全意识不足、恶意破坏等；⑤黑灰产，如虚假注册、经营数据爬取；⑥监管机构，如等保、关保、数据出境、合规风险等（更多参见：break.jd.army，BREAK业务风险枚举与规避知识框架）

所以，企业并不是终端安装了杀软、云端上了防火墙就万事大吉，要做的安全防护还有很多很多。不过，这些事情也并不需要在第一时间全部防护到位。对于企业而言，应重点关注“灰犀牛”事件，待此类事件防护得差不多时，再去研究解决“黑天鹅”事件。

在面对信息安全时，不要有侥幸心理。问题不在于信息安全事件会不会发生，而在于什么时候会发生。这个时间其实也是能够猜测一二的：一般来说，当企业业绩突飞猛进，营收或市场份额大幅增加，老板、合伙人和投资人都挺开心时，那么离信息安全事件发生就不会太远了。

二、团队建设阶段

• 信息安全团队怎么来建？

首先肯定是要去找一个很有经验的人，这个人不见得就是某个公司的信息安全一把手，但一定是有很见识的，即便没吃过猪肉，但也见过猪跑的那种。可以依葫芦画瓢地参照着之前的经验把公司的信息安全能力建立起来。

非常不建议直接招大厂的一把手、二把手这样的角色，一是这部分人实在是太贵了，二是也非常地能花钱，可能已经不记得该怎么精打细算，当然对于“暴发户”公司除外。此外有部分此类人也存在眼高手低、金玉其外等情况，虽然可以把事情说得头头是道，但这也是在大公司的典型的向上管理技巧，很可能本身的落地能力极差或所讲的事儿根本就虚无缥缈、缺乏落地能力。

最好招那种还没有完全脱离安全生产，具备实际上手能力的人来做一把手。面试时可以问问：你除了管理之外，还编码吗？或还做渗透测试吗？或还做实际安全运营吗？以此来评估上手能力。

在选择有限的情况下，招募安全乙方的一些渗透测试工程师，也是一种比较务实的选择。虽然有可能这类人因见识有限，未必会有非常高的安全视野和格局，但对于初创公司来说，应付个一两年还是游刃有余。而对于优秀的人来说，一到两年也应该有了较大的成长和格局提升。如果实在是资质差，到时再招个能力更强的负责人也不迟。

• 如何评价安全负责人的能力？

我认为，安全负责人的第一能力是：能跟不懂安全的老板把安全给讲清楚讲明白，可以辅助老板进行安全方面的相关决策。所以，但凡每天跟领导拽名词、拽英文、拽英文缩写、拽方法论的，把老板搞得晕头转向、云里雾里的，那么不妨换个人也罢，何必招个爷来天天难为自己？

当然，作为公司的老板，也一定要有一个客观的认知：安全不是银弹，解决不了所有问题。能解决燃眉的头等大事就行了，而且未必能保证100%解决。在信息安全领域，要记住：不要讲绝对。因为信息安全领域根本就没有绝对，也因此应该保有更大的宽容和理解。要允许信息安全出事和犯错，尤其是出小事，犯小错。但不应该允许同样根因的事情，三番五次，一犯再犯。这就不是客观的问题，而是能力或态度的问题了。

• 安全能力建设更应该系统化建设还是“头痛医头、脚痛医脚”？

如果“系统化安全能力建设”和“头痛医头、脚痛医脚”只能任选其一的话，我是倾向于头痛医头、脚痛医脚的。老话讲：远水解不了近渴，皮之不存毛将焉附？等信息安全按照系统化的方式建立起来时，可能公司都早已经死掉了。

如果安全负责人没有将公司和业务现阶段面临的问题作为工作重点，而是大谈特谈安全发展、安全体系、安全系统和安全规划，那么就是一个十足的空想家，是完全不称职的表现。不过，也不能只是“头痛医头、脚痛医脚”，一名合格的安全负责人应能够深谋远虑，具有长远的规划能力，可以走一步、看两步、想三步。能够在充分解决现有问题的同时，进行一些安全能力布局和铺垫。有这种能力的人，会在安全建设和运营过程中，将对业务的打扰及业务反感度降到最低，安全的路是越走越顺的。反之，会激化安全和业务之间的矛盾，安全能力和运营的推进会步履维艰。安全不是在助力业务，而是在束缚业务发展。

• 在有了信息安全团队后，安全能力都需要自研吗？

答案必然是否定的。即便对于目前的国内大厂，也不是所有的安全能力都是自建的。一般来说，更贴近于业务化的、个性化的、涉及业务敏感性、随着公司拓展会严重增加采购成本的安全能力，从效率更高、成本更低、更适应业务需求等方面来考虑，可以自研为主。而通用性的、需要大量人力物力进行长期维护和信息采集的、需要常态化能力运营、分析和对抗的，譬如杀软、NIDS特征库、威胁情报库，则采购安全乙方的产品更佳。

此外，一些严重依赖对抗性来实现安全防护的能力，譬如：代码加固、图形验证码等，会存在一家攻破、处处沦陷的情况。则应在对应业务发展起来后，从安全能力采购转换为自研，以防止城门失火、殃及池鱼。

• 安全到底应该养多少人才够？

安全人员从整体上来看，应分为“安全能力开发”和“安全能力运营”两种岗位。安全能力开发又分“能力研发”和“能力集成”两方面，安全能力运营又分为“事件运营”和“能力覆盖运营”两方面。安全到底要养多少人，要从成本结合必要性的角度来衡量。对于大部分公司来说，最开始是不需要能力研发的，但能力集成是需要的；事件运营可以采取乙方代运营的方式，但能力覆盖运营是需要的。

所以从招人的角度可以按照：能力集成、能力覆盖运营、事件运营、能力研发这么个优先级来考虑。

此外，任何公司都会将“降本增效”作为一个重要的商业运营策略。如果自建能力更能实现降本，或更能实现增效，则就有自建的必要性。否则，应该从成本、效率和安全性之间进行必要的权衡。

• 安全就是修漏洞吗？

这个问题跟上面“安全就是为了防黑客吗？”是一类问题。修漏洞肯定是信息安全要解决的重要问题之一，但仅仅修漏洞肯定不能保证企业安全。一般来说，企业还应关注：风险控制（风控）、商密保护、数据保护、合规经营、内部审计、员工安全意识、依法打击等多个方面。

从实际的企业信息安全的组成结构来看，既有把这些安全因素放到信息安全部门中的，也有把这些安全因素剥离出来成为独立部门的。这里面并没有什么约定俗成的规定。作为公司的老板，只要你觉得合适，你就可以把风控和信安放一起，或把内审从信安中独立出来。有时这可能跟业务的重要性有关，有时跟信安负责人的能力水平有关，有时跟团队人数有关，有时跟企业架构层级有关。业务的隔离可以降低互相间的耦合，让专业的更加专业，也会增加沟通成本，让协同更加困难。这跟玩扑克时，“2”这张牌到底应该单出还是配着出是一个道理。

• 信息安全应该由哪些部门组成？

狭义来看，信息安全团队主要为了解决：漏洞、数据安全、信息安全合规、员工安全意识、业务经营安全等方面问题。为了解决漏洞问题，有的公司会成立一个团队去解决，有的公司会成立多个团队来解决，主要看业务和网络的规模而定，其中主要涉及：应用安全、网络安全、系统安全（基础设施安全）、安全运营、安全响应中心、漏洞管理与渗透测试、身份与访问管理等。数据安全主要解决数据合规和用户隐私保护等问题，通常是一个独立的部门，通过数据分类分级、数据加密、数据脱敏、数据水印、数据血缘分析等方式来解决，有些公司可能会把数据密态计算也放在这个团队。信息安全合规和员工安全意识一般并不需要太多人，所以单独成为一个大团队的概率不大，可以将他们放在跟解决漏洞问题相关的团队之中，也可以单独出来成为一个团队。

业务经营安全主要通过风控团队来解决，在有的公司是放在信息安全团队中的，有的公司则放在了业务相关的团队。这两种放法各有利弊，放在信息安全团队，那么团队的安全属性会更重一些，所以风控的能力会更强一些。不过，因为很多风控策略和能力是要跟业务深度耦合的，也需要对业务加深了解，所以跨部门合作会是一个大问题。所以有的公司会采取前期放在信息安全部门，然后在团队具备一定的安全专业性后，再整体转移到业务相关的部门。还有的公司会选择在信息安全部门和业务部门同时放置风控能力，以类似于中台和前台的方式来运营。

除了上面提到的，在一些公司发展到一定阶段，可能会选择成立高级安全研究团队和蓝军（红队）团队，前者的意义在于，可以提供更深度的风险洞察能力和创新性的安全防护技术，同时也可在企业商誉维护、影响力建设和人才培养和储备上贡献力量；后者的意义在于，可以从攻击者的视角对企业安全防护能力水平进行客观的评估和度量，一方面有助于企业发现自身安全防护上的短板，另一方面也有利于防止防护团队自我感觉良好和自说自话，降低黑天鹅事件发生概率。

三、安全运营阶段

• 安全什么漏洞都要修吗？

这个问题也可以换种方式来问：修复漏洞时都要考虑什么？

简单来说，考虑如下三点就够了：①漏洞杀伤评估；②漏洞修复难度；③漏洞利用难度。然后可以参照如下表格来定一个优先级，从优先级高的来修复。

• 安全指标如何设定？

很多人觉得，给安全定指标可能会是一个老大难的问题。譬如，若以响应事件数量为指标，那没有那么多事件发生怎么办？以发现漏洞数量，那这个数如何确定？是多了还是少了？

我倒是建议可以以：事件发生率、成本、效率做为指标来综合评估信息安全的建设水平。安全的最终目的一定是为了降低坏事件发生数量或概率，那么这个就是最核心的指标，也是安全团队存在的意义所在。对于一支刚成立的信息安全团队，要求所有事件完全不发生是不现实的，可以以红色事件不能超过几次，橙色事件不能超过几次等来进行衡量。在此基础上，我们考量成本和效率，如果给安全无限的投入，让业务无限度的配合，那一定是更安全的，但也是最不可能的。所以，如何保持较高的人效比，如何更少的打扰业务就可以作为一个重要的衡量指标。譬如副指标1可以是维持安全人数与员工总数的占比不变，维持安全花销的占比不变等，副指标2可以是将对业务的打扰比值（业务投入在安全上的时间/业务投入在生产上的时间）降低等。

• 如何客观衡量企业安全能力水位，防止安全自说自话？

其实上面“信息安全应该由哪些部门组成？”中有提到，引入蓝军（红队）是一种很好的、客观衡量企业安全能力水位，磨练防护能力，发现防护短板，防止防护自说自话的手段。不过这个角色在信息安全团队发展的早期阶段不一定需要自己建立，完全可以从安全乙方公司来采购服务。

随着企业的发展，涉密的事情越来越多，安全团队逐渐壮大，根据实际需求，可以考虑建立专业的蓝军团队。一般来说，蓝军团队保持跟信息安全团队大概1/20的人员配比就好。这个团队建设起来后，不单单可以进行黑客的模拟（一般乙方服务只包括这部分），还可以进行黑灰产、内鬼、坏用户、坏供应商等多种威胁角色的模拟。而且除了模拟威胁行为者，还可以采用红蓝对抗演练的方式，针对红军的某项能力进行针对性对抗，以发现能力上的风险和不足。在企业发展到一定阶段时，建设蓝军团队很有必要性。

不过，蓝军在开展工作时，也会有问题。譬如，蓝军每次都打穿，那么红军的能力水平到底有没有提升？在这点上，我曾经开源了一个“红蓝对抗评分系统”（rtass.jd.army，红蓝对抗演练评分系统”开源框架、如何开展蓝军工作与量化评估），旨通过系统化的能力评价来解决这个问题。

• 安全的整体防御原则是什么？

安全业内人士经常吐槽行业的一句话是：安全界最多的是名词缩写和理论框架。名词缩写成千上万，安全人员自己也记不住、认不全，理论框架找出百八十个也不成问题。对于老板而言，只要知道安全防护阶段分成：事前、事中和事后，能力建设分成：防护、监测和响应即可。然后在安全防护的各阶段去部署对应的安全能力就好了。譬如：提前修复漏洞就是一个事前的工作，攻击事件的实时识别和阻断就是一个事中的工作，在事件发生后及时发现、恢复业务、消除影响、修复漏洞就是一个事后的工作。

至于到底用什么框架，其实更多讲的是：如何进行信息安全系统化、体系化建设。主要是为了让安全的各项能力充分联动，形成全方位、多层次、立体化的防护阵列，充分降低风险的同时，提升响应效率；强化统一管理和持续性改进的能力，满足监管合规要求和行业标准所需要的。

• 安全仅仅是安全部门的事儿吗？

安全是一家企业所有人都要努力的事儿。因为任何人在安全问题上都可能捅娄子，也都可能成为被攻击和利用的目标。安全上的所有漏洞和问题都是人类犯下的。提升每一个人的安全意识，是提升一家企业整体安全水位的重要保障。但安全工作本身是“反人性”的，因为它限制了人员的自由和便利性、增加了人员的心理压力。所以安全必然是一个自上而下的“老板工程”，应该让公司的每条业务线的Top级别领导去背负安全指标，否则安全的落实将存在很大的业务挑战和困难。至于是否应该让每一名基层员工来背负安全指标，反而不是最重要的，有也可，没有也行。一般来说，从安全的规章制度上来制定针对全员的奖惩措施并能落地，以及落实合理的安全通报机制即可。

四、安全价值

• 安全价值如何体现？

曾听说有一家公司的老板在某个管理会上，问他的安全负责人：“你们今年给公司止损、挽损了多少”，然后安全负责人说了一个数，老板说：“你知不知道，我养你们这一年都不止这么多”。从老板的这个认知来说，这名安全负责人是完全不称职的，因为他都没把安全的重要性跟老板讲清楚。

我们换一个例子来看，如果我们去衡量一个人身体中抗体的价值，那么会简单的把它标识了多少病毒作为指标吗？这不跟“扁鹊三兄弟的故事”一个道理吗？良医治未病。安全做得越好，就越能防患于未然，能够止损和挽损的必然越少。安全使得公司健健康康的存在和发展，这就是它的最大价值。如果公司没有了安全，就等于人身体中没有抗体，那么人……就死了，还谈个屁的标识了多少病毒？还谈个屁的止损挽损？你是否还记得为了得到抗体，我们从小到大需要打多少针吗？这些“疼痛”成本才换来我们的免疫。同样，安全也需要一些看不到水花的投入才能充分降低各种“坏事”发生的概率。

要以目的性的指标去衡量安全的价值，而不是过程性的指标，更不应该背离团队建设初衷，去过多考虑和追求非目的性的事。

• 安全与业务是一对儿天然的矛盾吗？

有人的地方就会有江湖。一家公司的两个兄弟部门，通常会互相看不顺眼。而这种情况在职能和业务部门之间则更加严重。

从下面SDL和DevSecOps这两幅图我们能看到，安全在力争渗透到开发流程的各个阶段。从需求设计、到开发测试，再到上线运营，哪个阶段都少不了。每个阶段耽误业务一点点，整体加一起耽误的时间就长了。业务就像戴着一副枷锁在干活，慢慢吞吞、束手束脚。他们眼中的安全就是指手画脚、凸显存在、没事找事、哪有事哪到。在这种情况下，安全与业务之间没有矛盾就怪了。

DevSecOps的安全介入业务流程

但为什么业务会有这种认知呢？说白了，还是KPI导向决定的。业务的KPI是快速完成产品，安全的KPI是不要出事。KPI是矛盾的，那么这两种角色之间就必然是矛盾的。所以，要想解决这个矛盾还得从根因出发，譬如让业务的KPI中带有安全的属性，让安全的KPI中带有提效的属性。这样不需要老板在之间拉架或断案，两种角色也能协同得亲密无间。这就是我说的：安全是一个老板工程，自上而下比自下而上更重要。

• 安全是成本部门还是利润部门？

在绝大部分人的认知中，安全是一个成本部门，而不是利润部门。然而事无绝对，如果信安的工作使得公司止损、挽损了，那可不可以算作利润？如何信安参与到业务的生产建设中去，赋能于业务，使得业务利润增加了呢？如果信安发展到了后期，不单单服务于自身安全，还可以服务于外部客户赚取收益呢？

我提这些例子是想说：不能将安全当做一个普通的成本部门来看待，它其实也有很多潜在的发展性的。我更喜欢用“搂草打兔子”来形容这件事：搂草是我们的本职工作和核心目标，是不应该变化的；但只要做好筹备并把握住机会，则打到兔子更是一件好上加好的事情。

在信息安全这个职能部门的发展前期，是不应该把利润考虑放在第一位的。因为容易好高骛远，导致团队走样。但当企业信息安全建设发展到一定阶段，在保证自身安全的同时，也是可以孵化出安全业务团队的，像阿里云的安全产品、腾讯iOA的安全能力嵌入等也都做出了很好的表率。

最后

本文内容全部来自于本人20余年对信息安全的认知、从业经验与沉淀，希望能够给中小企业和创业公司在开展信息安全能力建设中提供思路。本文非比武擂台，所以也不接受挑战，有不足之处，还望海涵。不过如果你有更多问题或具体案例需要探讨，随时欢迎交流！

阅读原文

跳转微信打开

2008年，特斯拉还没有出成品车，但公司内部机密消息经常性外泄，对公司造成了严重负面影响，于是马斯克采取一种办法，成功抓出了内鬼！

安装（使用pip）：

$ pip install textwatermark

使用：

命令行调用：

插入水印到文本：

$ textwatermark -v insert -f './tests/text/number.txt' -m ALPHA_NUMERICAL -t HOMOGRAPH_NUMBERS -x 999 -w 123
Ӏ2𝟑𝟒𝟓Ⳓ𝟟890
保存水印参数：
$ textwatermark -v insert -f './tests/text/number.txt' -m ALPHA_NUMERICAL -t HOMOGRAPH_NUMBERS -x 999 -w 123 -e
{"tpl_type": "HOMOGRAPH_NUMBERS", "confusables_chars": [], "confusables_chars_key": "", "wm_base": 7, "method": 1, "wm_mode": 5, "wm_len": 7, "wm_loop": false, "start_at": 0, "version": "0.1.2"}
从文本提取水印：
$ textwatermark -v retrieve -f out.txt -p '{"tpl_type": "HOMOGRAPH_NUMBERS", "confusables_chars": [], "confusables_chars_key": "", "wm_base": 7, "method": 1, "wm_mode": 5, "wm_len": 7, "wm_loop": false, "start_at": 0, "version": "0.1.2"}'
The retrieved watermark is: 123
代码调用：
'''Sample Example'''import os
from textwatermark.defines import WMModefrom textwatermark.main import TextWatermarkfrom textwatermark.template_type import WMTemplateType
# 1.Init TextWatermark instancewm_mode = WMMode.REAL_NUMBERwm = TextWatermark(wm_mode=wm_mode)
# 2.Choose a watermark templatewm.set_tpl_type(tpl_type=WMTemplateType.HOMOGRAPH_NUMBERS)
# 3.Set the maximum value of the watermark stringwm_max = '9'*9wm.set_wm_max(wm_max=wm_max)
# 4.Set the text to be watermarkedwm.set_text_file(path=os.path.abspath('../tests/text/1.txt'))
# 5.Insert watermark string to textwm_str = '123456789'wm_text = wm.insert_watermark(wm_str=wm_str)print(wm_text)
##############################################################
# Save the parameters to retrieve the watermarkparams = wm.export_params()
# retrieve the watermarkwm_out_str = TextWatermark.retrieve_watermark(wm_text=wm_text, params=params)
assert wm_out_str == wm_str
更多参见：https://textwatermark.jd.army/usage/
找回水印

$ textwatermark -v retrieve -b 10010000011000100000101000110000111 -p '{"tpl_type": "FONT_COLOR", "confusables_chars": [], "confusables_chars_key": "black4", "wm_base": 2, "method": 3, "wm_mode": 5, "wm_len": 35, "wm_loop": false, "start_at": 0, "version": "0.1.2"}'The retrieved watermark is: 123456

DBIR 2022：https://www.verizon.com/business/resources/T27b/reports/dbir/2022-data-breach-investigations-report-dbir.pdf#pdfjs.action=download

阅读原文

跳转微信打开

DSRE-数据安全风险枚举框架将补齐蓝军短板，从而RTASS、BREAK、DSRE三个框架可以分别为网络蓝军、业务蓝军、数据蓝军三种工作场景提供有力支撑，全面覆盖企业面临的各种信息安全风险场景，架构起完整的“以攻促防”蓝军对抗评估体系。

一、背景

目前各大头部互联网企业均建立了蓝军团队，通过“以攻促防”来评估和加强安全能力建设。“以攻促防”的形式多种多样，有实战攻防演习、红蓝对抗演练、蓝军专项评估、沙盘推演等模式。然而在蓝军工作过程中，始终有两大方面问题没有解决：一是如何量化“以攻促防”的结果，二是“以攻促防”的范畴与方法。

针对解决第一个问题，我们于今年7月首次向社区开源了“JDARMY RTASS红蓝对抗评分框架”（RTASS.JD.ARMY），参照CVSS的评分模式，可以以调查问卷的形式评价红蓝双方在单次演练中的有效输出，同时对企业与业务的安全水平进行衡量。我们的红蓝双方通过在实战攻防演习后在系统上进行背靠背打分，得分基本趋向一致，并获得红蓝双方的认同，所以该评分框架具备客观的评价能力，大体上可以解决蓝军工作中的第一方面问题。

针对第二方面问题，我们认为传统的蓝军仅将战场聚焦在网络安全攻防范畴，无法更全面地评估和模拟企业在信息安全领域面临的各方面威胁。譬如传统蓝军其实是对黑客的模拟，我们称之为“网络蓝军”，但对黑灰产、内鬼、供应链、合作第三方、监管方是缺乏模拟能力的。

黑灰产一般对应于业务安全问题。对黑灰产的模拟，我们称之为“业务蓝军”。业务蓝军照比网络蓝军有着本质的不同，我们不能再通过CYBER KILLCHAIN、MITRE ATT&CK、OWASP TOP 10等这些网络安全思维和方法论来搞。为此，我们于11月向社区开源了“JDARMY BREAK业务风险枚举与规避知识框架”（BREAK.JD.ARMY），参照MITRE ATT&CK的模式，按照业务、内容、身份、对抗等不同维度，枚举了80项风险（包含24项子风险）,划分了金融、电商、社交等15种业务场景，31种攻击工具与手法，同时也对31种风险规避与缓解手段进行了介绍与风险对应，方便攻防双方参照此来开展红蓝对抗工作。

最近几年勒索病毒、数据泄露事件层出不穷，国际国内均纷纷立法加强对数据的管控力度。数据安全上升到了前所未有的高度，对数据面临威胁的模拟将成为蓝军的一项重要的工作职责与使命，组建“数据蓝军”将成为大势所趋。数据蓝军将通过模拟黑客、黑灰产、内鬼、供应链、第三方以及监管单位在数据安全领域能够给企业造成的威胁与风险，最终有效评估企业目前面临的数据安全短板。但这项工作要如何来开展呢？这也正是我们本次向社区开源“JDARMY DSRE数据安全风险枚举”（DSRE.JD.ARMY）知识框架的初衷。也希望借BREAK框架和DSRE框架来解决蓝军的第二方面问题。

二、数据安全风险框架构建思路与方法

在BREAK业务风险枚举与规避知识框架中，我们其实是采取的先枚举再归类的方法，这是由于业务的复杂性和多场景导致的。而在DSRE数据安全风险枚举框架中，我们则采取了先归类再枚举的构建思路，这是由于数据本身既是原子的，又具备流向性的缘故。因为数据是原子的，我们可以更好地罗列其属性；又因为数据具备流向性，我们也很容易归纳其周期。

针对数据属性，我们结合了业内成熟的理论：安全三项基本要素CIA，安全三项基本功能AAA，形成针对数据安全要求的6大维度。三要素即：保密性（Confidentiality）、完整性（Integrity）、可用性（Availability）；三功能即：认证（Authentication）、授权（Authorization）、审计（Accounting）。这6个维度对应的安全威胁分别是：泄露、篡改、拒绝服务、仿冒、权限滥用和抵赖。

针对数据周期，我们则直接搬用数据安全全生命周期：数据采集、数据传输、数据存储、数据处理、数据交换、数据销毁，这6个阶段。

最终以数据属性（威胁）为横轴、数据周期为纵轴，通过交叉枚举，形成了我们的数据安全风险枚举知识框架。

三、按风险分类开展数据安全红蓝对抗工作

通过全面枚举数据在不同阶段面临的不同问题，在目前的版本中，我们共总结出95项风险隐患。不过因为风险维度比较繁杂，如果笼统地拿出来，是很难开展对抗实施的。为此，我们按照问题的发生域，又将风险分为：合规、功能、漏洞、对抗、隐患与规范6大类。

• 合规风险：指因不符合由国家监管单位、职能部门及组织下发的相关数据安全法律法规要求导致的风险，目前有14个。

• 功能性风险：指由数据系统实现过程中的功能BUG导致的一类风险，共12个。

• 漏洞风险：指可能被攻击者发现并利用造成一定数据安全影响的风险，共20个。

• 对抗性风险：指存在一定的对抗阶段，需要持续不断进行能力提升的一类风险，共11个。

• 隐患类风险：指不会直接被攻击者利用，但与某些漏洞相结合或在某些特定场景下有可能出问题的风险，共11个。

• 规范类风险：指因不符合除“合规”外的应该具备及被遵守的相关数据安全规范导致的风险，共21个。

将安全风险分类后，各安全团队可以结合自身在数据安全风险评估上的能力储备和工作意愿来决定开展哪些工作，即：复用现有的安全能力。譬如：网络蓝军可以选择“漏洞”与“对抗”的分类来开展红蓝对抗工作；“合规”和“规范”分类可以由安全规范与治理团队来开展；“功能”和“隐患”分类可以由安全运营与测试团队来开展。

四、构建完整的企业对抗评估体系

通过网络蓝军、业务蓝军、数据蓝军相结合，可以比较全面地覆盖企业面临的各种信息安全风险场景，架构起完整的“以攻促防”蓝军对抗评估体系。而RTASS、BREAK、DSRE三个框架可以分别为蓝军三种工作场景提供有力支撑，方便我们更好地开展相关工作。当然“一家之言”总有不足，我们从不敢奢望能代表整个行业，所以我们将三个框架开源，也是希望寄托于开源社区反哺框架本身，使之成为一个更客观、准确、全面的蓝军作战体系。

五、协作 & 贡献

与RTASS、BREAK框架一样，DSRE框架采用JSON格式进行了系统描述，详见“/src/DSRE”文件夹，其中：风险项放于“risks.json”中。各协作者可以通过直接修改该文件来与我们进行该系统框架的协作开发，亦可通过在github上提issue来给我们提供意见或建议。

• DSRE-数据安全风险枚举框架：https://dsre.jd.army/

• DSRE Github：https://github.com/JDArmy/DSRE

• RTASS-红蓝对抗评分系统：https://rtass.jd.army/

• RTASS Github：https://github.com/JDArmy/RTASS

• BREAK-业务风险枚举与规避知识框架：https://break.jd.army/

• BREAK Github：https://github.com/JDArmy/BREAK

🔽点击原文查看DSRE知识框架

阅读原文

跳转微信打开

BREAK(Business Risk Enumeration & Avoidance Kownledge)，是一个开放式业务风险枚举与规避知识框架。通过对各种业务风险进行枚举，为使用者提供完整的业务风险全景图，并提供了规避知识。

介绍

BREAK 是英文“Business Risk Enumeration & Avoidance Kownledge”的缩写，是一个开放式“业务风险枚举与规避知识”框架。该框架通过对各种业务风险进行分类、介绍与枚举，为使用者提供了一个完整的业务风险全景图，并对业务规避风险、提升能力提供了规避知识。

背景

随着信息安全能力对业务的覆盖与落地，以及业务对安全需求的加深，如果安全还是单单停留在网络安全范畴，仅仅是提前发现和修复各种漏洞，显然是无法保证业务正常的安全运营的，也无法满足业务安全的更高需求。

为此，我们根据多年以来对业务安全的理解和积累，推出 BREAK - “业务风险枚举与规避知识框架”，旨在为企业蓝军在开展业务安全评估过程中提供指导和依据，同时框架中的业务风险规避知识也为安全能力建设、业务安全运营、风控能力提升提供指引。

方法

框架整体按照：风险维度、风险场景、风险点的划分原则，框架包含若干风险维度，每个风险维度包含若干风险场景，每个风险场景包含若干风险点。

风险维度指代看待风险的不同角度，目前包含：业务维度、内容维度、身份维度和对抗维度。其中业务维度包含：营销风险、交易风险、游戏运营风险；内容维度包含：用户内容风险和违规引流风险；身份维度包含：身份风险和盗号变现风险；对抗维度包含身份对抗风险、设备对抗风险和非法请求风险。

目前框架共收集和整理风险点68个，后续会根据情况和反馈进行动态添加、升级或调整。每个风险点由风险编号、风险标题、风险描述、攻击描述、攻击复杂度、风险影响、规避手段和参加资料组成。风险编号通过 R00xx 的方式来进行唯一编号（效仿Mitre ATT&CK），以便后期交流和情报传递。而攻击描述可以指引企业蓝军更好地进行安全能力评估，规避手段可以帮助企业红军或业务风控来加强安全能力建设，以降低业务风险。

需要注意的是： 业务风险和漏洞不是一回事情。一般来说漏洞是由于业务编码的缺陷导致的，可以通过修改代码去除缺陷来修复漏洞；而业务风险很大程度上并不是由编码缺陷造成的，只是攻击者对正常业务逻辑的一种非预期的利用。也因此，在大部分情况下，并不能完全消除风险，只能将风险降低到一定的可接受范围。所以并不一定可以通过直接修改代码来修复漏洞，通常业务风险需要外挂安全能力、构造风控模型来减缓攻击、降低攻击ROI或缩小攻击面。

风险列表

目前版本的全部风险列表如下（详细资料请参考 BREAK 框架）：

规避手段

目前版本的全部规避手段列表如下（详细资料请参考JDArmy BREAK框架）：

协作 & 贡献

本框架采用JSON格式进行了系统描述，详见“/src/i18n/zh-CN/BREAK.json”文件，其中：

风险维度放于“riskDimensions”中，并通过其内的“riskScenes”来划分场景；

风险场景放于“riskScenes”中，并通过其内的“risks”来划分风险；

风险放于“risks”中，并通过其内的“avoidances”来承载规避手段；

规避手段放于“avoidances”中。

各协作者可以通过直接修改 BREAK.json 文件来与我们进行该系统框架的协作开发。亦可通过在github上提issue来给我们提供意见或建议。

链接

• 框架地址：https://break.jd.army/

• Github：https://github.com/JDArmy/BREAK

🔽点击原文查看知识框架

阅读原文

跳转微信打开

本文我们主要从实战攻防演习、红蓝对抗演练、科学有效开展复盘、量化评估体系建设等4个方面来概要性谈谈蓝军要如何来开展工作，以及如何对攻防双方的工作、能力和产出进行客观评价。

一、背景

随着数据泄露、勒索病毒等事件的频繁发生，企业管理者们逐渐意识到，仅靠渗透测试或者漏洞扫描工具是没办法保证网络安全的，更不具备评价安全防护、安全运营以及安全响应水平的能力。越来越多的中大型企业选择成立蓝军团队（或红队）作为网络安全部门的常规配置。通过定期或不定期的对抗模拟来发现安全防护盲区，评价自身网络安全防护水平，测试和锻炼安全运营队伍，以及通过制造“事件”来以攻促防。

然而，笔者通过调研与访谈发现，有不少的蓝军队伍并不知道该如何进行蓝军团队的搭建，以及科学地开展蓝军工作。更多的套路还是招具备渗透测试技能人员（如果有些HW经验更佳），然后就是“干就完了”，最终交付些漏洞或权限就算完事，颇有种乱拳打死老师傅的感觉。由于篇幅原因，蓝军的组建暂且不谈，本文我们主要从实战攻防演习、红蓝对抗演练、科学有效开展复盘、量化评估体系建设等4个方面来概要性谈谈蓝军要如何来开展工作，以及如何对攻防双方的工作、能力和产出进行客观评价。

二、实战攻防演习

实战攻防演习起初是一个军事词汇，最早出现在军事领域，是在想定情况下进行的作战指挥和行动的演练，是部队在完成理论学习和基础训练之后实施的，近似实战的综合性训练，是军事训练的高级阶段。网络安全中的敌我实战模拟式的攻防试练借用了军事领域中的词汇，被称作网络实战攻防演习。在网络实战攻防演习过程中，活动的组织方（有时也被称为紫方）会将安全人员分成攻方与防方两种队伍，通过实战化的方式来进行系统的安全评估测试。攻方队伍负责扮演黑客来对目标网络开展进攻，力争获取重要或指定系统权限及数据。而守方则利用现有的网络安全设备以及自身建设起来的安全能力进行防护，力争第一时间发现攻击者，开展阻断、溯源、修复、止损等工作。而组织方同时充当裁判员的角色，通过一系列规则对攻方和守方的工作成果进行打分和排名。在大规模实战攻防演习中，攻击方与防守方可能各自由多支队伍组成，工作目标侧重于衡量被攻击方的整体安全防护、监控和响应能力水平。

我们能从定义上看出，实战攻防演习是建立在企业已建设安全防护能力、落实了安全防护措施、组建了安全运营团队、配置了安全监控手段、制定了应急响应流程基础上的。企业安全防护的方法论永远是“假设建设落实了相关的安全能力，则可以防护或阻止对应的安全风险隐患”，所以蓝军的工作目标总是对防护进行挑战，发现安全能力的不足、制度或流程的缺失、策略落地的不到位等问题，最终通过“以攻促防”，补齐防护盲区和短板，以便提升整体的安全水位。开展企业内部实战攻防演习大体上分为以下几个步骤：

1、确定工作目标

任何蓝军团队的负责人需要明确地知悉一点：蓝军开展工作的目的或目标绝对不是为了体现蓝军有多么厉害，而是能够帮助企业提前黑客发现多少的问题，消除多少的风险隐患。因此，在每次开展实战攻防演习之前，一定要设定好合适的工作目标，绝对不是“干就完了”。

目标的设定可以围绕几个方面：发现安全防护不足以便补齐安全短板提升水位、锻炼安全运营威胁监控与应急响应能力水平、促进安全在业务侧的能力落地和措施执行。不同的工作目标决定了演习方向的不同。譬如笔者所在团队就将演习分成：身份安全、数据安全、应用安全、计算安全、办公网安全、基础设施安全、员工安全意识等不同方向。针对不同方向，在攻防过程中会有所侧重或设定不同的靶标。

2、制定工作计划和排期

在确定完工作目标后，下一步便是制定工作计划和排期。实战攻防演习不单单是攻与防的事情，更多情况下需要业务的配合和参与。

我们参考@aprilwright的信息安全色轮能发现，涉及安全的角色划分达到7个之多。除了我们熟知的“攻”（红色）与“防”（蓝色），还有紫色团队负责攻防演习的组织；黄色团队也就是业务方，负责安全策略和措施的落实，有很多业务团队还有自己的安全官；处于红黄之间的橙色团队，负责促织安全互动和培训教育；处于黄蓝之间的绿色团队，负责通过提升设计、编码、自动化检测来提升安全能力；此外还有白色团队，负责分析安全报告与态势、制定安全策略与规则、进行安全管理动作等工作。当然，对于绝大部分企业来说，不能成立这么多安全团队，不过即便对于单个安全团队来说，上述的角色与分工依然是必不可少的。

也因此，在一次实战攻防演习过程中，要对不同的角色来划分不同的分工，更要考虑各方的排期。譬如对于电商企业来说，通常会在每年的6月份与11月份进行大促，那么很明显在这段时间期间以及之前的临近时间就不是一个好的排期。

3、制定工作规范

蓝军开展工作的底线是：不能对业务造成影响。因此一般要制定比较严苛的工作规范，包括：敏感操作及时报备（譬如有几率引起蓝屏的操作等）；禁止开展与演练无关的任何工作；禁止进行拒绝服务类攻击；禁止修改线上配置；禁止批量拖数据；禁止物理破坏性渗透（譬如拉闸断电等）、禁止对供应链提供商开展攻击（黑客常用供应链攻击，但蓝军不行，因为没有授权）；禁止运行可传播的病毒程序等。部分情况下，因工作目标的不同可能还会限制蓝军攻击的手段，譬如时间段和时间范围的限制；不允许社工攻击等。

对于防守方来讲，一般来说工作规范较为宽泛，日常如何做监控响应，演习时就如何做就好，当然不能对业务造成影响同样是工作底线，譬如：不允许给沦陷主机断网、不允许有罪推定溯源、不能过度防守（譬如针对靶标限定特定IP登录的临时ACL策略）等。

有些企业的实战攻防演习还会效仿HW制定一定的评分规则，笔者所在企业在前期也曾使用过，不过现在已经通过量化评估模型来替代。因为区分攻击与防守的评分规则更适合在多支攻击队与多支防守队的情况下，对攻击队与攻击队、防守队与防守队之间的能力进行评价，而大部分企业内部的演习都是一支攻击队和一支防守队，此时再设立评分规则，形式大于意义。

4、行动实施与跟进

在学习朱日和演习的相关资料时，里面对蓝军的定义是我很赞同的：蓝军要始终把自己定位在“遇强不能弱，遇弱不过强”的陪练员角色，获胜并非只是依靠先进的装备，而是要模拟实战，让红军找体会，找不足。蓝军越硬，红军被磨砺的就越厉害，上战场杀敌就越能致胜。

从上述点来说，蓝军与红军在演习中是要充满对抗性的。如果蓝军与红蓝在演习中一团和气，那么就达不到磨砺的目的，红蓝双方也会失去目标感和成就感。因此紫色团队在整体演习期间，要能够时刻把握动向，做出调整。通过对双方设定指标等方式，来调节对抗的激烈程度，达成演习目标效果。

5、演习复盘与行动项落实

企业内部实战攻防演习的一块非常大的工作量便是演习复盘与行动项落实。如果一次演习没有落实多少改进或提升的行动项，那么总体来说，这次演习是失败的。

人类的天性就是规避风险和逃避责任。但在复盘这个事情上，一定要客观、实事求是和认真对待，否则演习就变成了一种形式，失去任何意义。复盘很多情况下是衡量企业安全运营的领导是否称职的一把尺子，好的领导会认真研判报告，寻找自身差距与不足，制定切实的可落地的行动项并照此执行；而不称职的领导会尝试解释报告中各项问题的成因：乙方厂家产品能力不行；蓝军没有在规定时间开展；安全运营人手不足不够用；安全规范都有，业务没有执行；资产业务没按流程来，所以安全能力没覆盖……总之，一句就是：不是自己的问题。

企业管理者与安全管理者可以通过复盘的问题暴露和行动项的制定来判断演习质量的好坏。不过管理者切记不能把暴露问题的多少跟绩效的高低进行挂钩，要对复盘持有鼓励的态度，同时不要对复盘过程干预太多，多对比结果、少关注过程。

三、红蓝对抗演练与复盘

有相当多的安全从业人员其实并不能准确分清什么是实战攻防演习，什么是红蓝对抗演练。甚至不少蓝军成员，甚至是蓝军的管理者也不知道。其实这两者的工作形式还是有很大的不同的。

实战攻防演习其实更像是一种一对一的HW模式。与实战攻防演习不同，红蓝对抗演练更侧重于对安全运营能力的检验和锻炼，因此裁判员不是必须的，演练也可以更场景化一些，不追求绝对的真实性，更追求场景的覆盖性，需要提前设定一定的Case，演练中的攻击行为也可以提前告知红军。

在演练前，蓝军通常设计好攻击实例，准备好可供实例运行的环境，与红军共同商定实例运行后安全运营体系该有的响应；在演练中，蓝军在准备好的环境中运行实例，接收安全运营体系或红军的监控响应并记录告警和响应时间；在演练后，比对实例与告警、响应的数量，可计算出安全运营能力分值，通过实例运行时间与告警时间、响应时间差值，可以计算出MTTD 和MTTR。再通过复盘 ，通过问题归因、根因分析、制定方案、落实规划等一系列步骤，最终实现安全防护能力和安全运营水平的提升。

图表 1 红蓝对抗复盘标准流程

红蓝对抗的复盘与实战攻防演习整体上可以采取同一套流程，不过因为更场景化，所以在要求与产出上可以更细致一些。整体流程如下：

1、针对每一个对抗点Case的执行情况进行风险枚举，这个过程不要考虑其他，风险枚举得越多越好；

2、将每一个风险都转化成问题。譬如风险是可以对登录接口进行暴力枚举，那么问题就可以转化为：为什么接口可以被暴力枚举？如何防止接口被暴力枚举？等。将风险转化为问题将有利于解决方案与行动项的形成和制定；

3、根因分析是为了确保每一个问题都问到了实处，避免问题还处于一个中间阶段。如下图所示。

图表 2 复盘问题归因

4、枚举方案主要是根据转化的问题和对根因的分析来制定。需要注意的一点是，枚举方案时先不要考虑方案的可落地性，因为方案是否可落地无非是受技术能力的限制以及投入产出的制约。而技术能力限制有时受到方案枚举人员的个人技术能力水平限制；投入产出的制约有时取决于方案枚举人员的权利和管理层级限制。有可能自己认为不可能的方案，对于其他人来说就是可能，因此尽量枚举方案将有利于下步行动项的形成。

5、方案评估。上面提到枚举方案时先不要考虑方案的可落地性，而在方案评估环节则是要充分评估方案的可落地性，确保每一条经过论证的方案都能得到落地保障；

6、制定规划。根据重要紧急程度将方案分成：重要紧急P0、重要不紧急P1、紧急不重要P2、不重要不紧急P3等4个维度。一般来说，如果划分成P3的方案，除非精力充分，不建议进行实际落实。

7、制定验收标准、验收时间与验收人。编筐编篓，全在收口。演习演练搞得再好，复盘弄得再全面，如果最后行动项没有落地，一切都是无用功。前面也提到复盘过程领导不要过多干预和设定绩效，但针对复盘后的行动项，一定要进行跟进，必要情况下通过设定OKR或者绩效指标的方式来进行跟进，确保提升与改进项能够确切落实。

四、红蓝对抗量化评估体系

渗透测试对于漏洞有一套CVSS评分标准，目前也被业内广泛使用，然而针对红蓝对抗则没有一套公共的标准。很多企业会参照HW的评分标准来对攻击方和防守方进行打分，但这种打分只能对攻击方与攻击方之间，防守方与防守方之间能力进行比较，并不能对攻击方与防守方进行对比衡量。而在仅有一支攻击队伍和一支防守队伍的情况下，问题则更加突出：如果核心系统被突破，那么是说明攻击队伍强，还是说明防守队伍弱呢？如果核心系统没有被突破，那么是攻击队伍弱，还是防守队伍强呢？这是非常难衡量的，业内也没有一套成熟的体系来进行评价。

因此，笔者与所在蓝军团队结合多年网络实战攻防演习以及红蓝对抗经验，参考CVSS以及OWASP风险评级方法，开发了一套针对实战演习场景下的红蓝对抗评分框架Red Teaming Assessment Scoring System (RTASS)。

图表 3 红蓝对抗评分系统

红蓝对抗演练评分系统（RTASS）是一个开放式的，针对红蓝双方对抗式网络实战攻防演练中，攻击方、防守方、业务方以及企业风险进行评分的框架。适用于网络红蓝对抗演练、网络实战攻防演习、红队评估、蓝军评估等通过模拟黑客APT手段对企业开展实网攻击的安全评估场景。用来评估单次网络红蓝对抗或实战演习中的攻防双方能力投入情况，以及涉及业务及所在企业所面临的风险程度。

在目前最新版本中，RTASS通过评估因子形成6个过程分值。过程分值再通过不同组合，形成针对攻击方、防守方、业务方以及企业等不同角色的四项最终分值：攻击能量、防守能量、业务风险和企业风险。

l攻击能量是攻击方在单次演练中做的有效输出，可代表攻防方之于本次演练的水平；

l防守能量是防守方在单次演练中的有效输出，可代表防守方之于本次演练的水平；

l业务风险指业务在安全上暴露的风险程度，可代表参演业务方在本次演练中的安全水平；

l企业风险指企业在安全上暴露的风险程度，可代表企业整体上在本次演练中表现出的安全水平。

RTASS目前采用Apache开源协议，如果只是使用，可以直接访问RTASS在线评分工具 https://jd.army/RTASS/ ，它将实时保持更新自最新的版本。如果想查看所有的评分项与相关说明，或者参与框架标准制定、更改评分因子或算法参数等，可以直接访问GitHub仓库：https://github.com/JDArmy/RTASS，进行协作开发和拉取请求，或下载源码开发和维护自己的版本。

好了，由于篇幅限制，本次跟大家概要性地讲了实战攻防演习、红蓝对抗演练与复盘，以及红蓝对抗量化评估体系等内容。其实在企业蓝军建设上，还有团队建设、目标管理、绩效评定、工作规范制定与落实、保密制度、工作组织与流程、技战策略、武器打造等诸多问题，后续有机会可以跟大家一一交流，感谢补天提供平台，谢谢。

参考资料

阅读原文

跳转微信打开

RTASS是一套针对红蓝双方对抗式网络实战攻防演练中：攻击方、防守方、业务方以及企业风险进行评分的框架。RTASS适用于网络红蓝对抗演练、网络实战攻防演习、红队评估、蓝军评估等通过模拟黑客APT手段对企业开展实网攻击的安全评估场景。

红蓝对抗演练评分系统（RTASS）目前公布的是 preview 版，主要向大家征集建议，大家有好的意见或想法，欢迎到github去提issue或PR：https://github.com/JDArmy/RTASS

在线评分计算机器：https://jd.army/RTASS/?lang=cn

1.  红蓝对抗演练评分系统（RTASS）的背景

2.  RTASS框架理念与评分方法

• 进攻能量是攻击方在单次演练中做的有效输出，可代表攻防方之于本次演练的水平；

• 防守能量是防守方在单次演练中的有效输出，可代表防守方之于本次演练的水平；
• 业务风险指业务在安全上暴露的风险程度，可代表参演业务方在本次演练中的安全水平；
• 企业风险指企业在安全上暴露的风险程度，可代表企业整体上在本次演练中表现出的安全水平。

• 进攻实力指攻击方在单场次红蓝对抗演练中，在关键渗透路径上使用攻击技术的最高水平
• 防守实力指防守方在单场次红蓝对抗演练中，在关键渗透路径上使用防守技术的最高水平
• 漏洞风险指在单场次红蓝对抗演练中，在演练的关键渗透路径上对最关键漏洞的风险性评价

• “进攻能量”与“进攻实力”、“防守实力”、“企业影响”有正向关系。
• “防守能量”与“防守实力”有正向关系，与“漏洞风险”、“企业影响”有反向关系。
• “业务风险”与“技术影响”、“企业影响”有正向关系，与“业务实力”有反向关系。
• “企业风险”与“防守实力”有反向关系，与“漏洞风险”、“企业影响”有正向关系。

a)  进攻能量

• 进攻能量 = ( 进攻实力 * 系数 + 防守实力 * 系数 + 企业影响 * 系数 ) / 3

b)  防守能量

• 防守能量 = ( 防守实力 * 系数 + ( 10 - 漏洞因素 * 系数 ) + ( 10 - 企业影响 * 系数 ) ) / 3

c)  业务风险

• 业务风险 = ( 技术影响 * 系数 + 企业影响 * 系数 + ( 10 - 业务实力 * 系数 ) ) /3

d)  企业风险

• 企业风险 = ( ( 10 - 防守实力 * 系数 ) + 漏洞风险 * 系数 + 企业影响 * 系数 ) / 3

3.  RTASS过程评分与评分因子

a)  进攻实力

• 进攻实力 = ( 进攻水平 * 系数 + 进攻难度 * 系数 + 目标达成 * 系数 ) / 3

• 0 - N/A
• 1 - 相当于入门级黑客
• 2 - 相当于普通水平黑客或工具、脚本黑客
• 3 - 等同精通渗透技术的黑客
• 4 - 需要较为专业的团队配合
• 5 - 相当于国家级APT黑客团队

• 0 - N/A
• 1 - 几乎没有难度
• 2 - 有点难度
• 3 - 较大难度
• 4 - 很难搞定
• 5 - 几乎不能搞定

• 0 - N/A
• 1 - 基本没达成
• 2 - 少量达成
• 3 - 中量达成
• 4 - 大量达成
• 5 - 完全达成

b)  防守实力

• 防护实力 = ( 防护水平 * 系数 + 监测水平 * 系数 + 响应水平 * 系数 + 反制水平 * 系数 ) / 4

• 0 - N/A
• 1 - 几乎没有拦截
• 2 - 轻微的拦截
• 3 - 较强的拦截
• 4 - 非常强的拦截
• 5 - 几乎难以突破

• 0 - N/A
• 1 - 几乎监测不到威胁
• 2 - 监测到周边攻击威胁
• 3 - 监测到少量关键路径威胁
• 4 - 监测到大量关键路径威胁
• 5 - 几乎监测到全部威胁

• 0 - N/A
• 1 - 几乎难以推进（一周以上）
• 2 - 响应较为缓慢（24小时以上）
• 3 - 响应较为及时（24小时内）
• 4 - 响应接近实时（2小时内）
• 5 - 实时响应（30分钟内）

• 0 - N/A
• 1 - 几乎不能有效溯源
• 2 - 可以找到攻击者使用的DNS、C2等信息
• 3 - 可以溯源到攻击者横向移动路径
• 4 - 可以找到攻击者的部分真实IP或虚拟身份
• 5 - 可以对攻击者进行成功溯源反制

C)  漏洞风险

• 漏洞风险 = ( 漏洞可发现性 * 系数 + 漏洞可利用性 * 系数 + 漏洞杀伤力 ) / 3

• 0 - N/A
• 1 - 几乎难以发现
• 2 - 困难
• 3 - 中等
• 4 - 简单
• 5 - 可用的自动化工具

• 0 - N/A
• 1 - 几乎难以利用
• 2 - 困难
• 3 - 中等
• 4 - 简单
• 5 - 可用的自动化工具

• 0 - N/A
• 1 - 几乎没有危害
• 2 - 较低的杀伤力
• 3 - 中等规模的杀伤力
• 4 - 大范围的杀伤力
• 5 - 极其广泛的杀伤力

d)  技术影响

• 技术影响 = ( 失去保密性 * 系数 + 失去完整性 * 系数 + 失去可用性 * 系数 ) / 3

• 0 - N/A
• 1 - 可泄露少量的非敏感数据
• 2 - 可泄露少量的敏感数据
• 3 - 可泄露中量的敏感数据
• 4 - 可泄露大量的敏感数据
• 5 - 可泄露全部的敏感数据

• 0 - N/A
• 1 - 可损坏少量非核心数据
• 2 - 可损坏少量的核心数据
• 3 - 可损坏大量非核心数据
• 4 - 可损坏大量核心数据
• 5 - 可损坏全部数据

• 0 - N/A
• 1 - 可导致企业少量的非核心业务中断
• 2 - 可导致企业少量的核心业务中断
• 3 - 可导致企业中量的核心业务中断
• 4 - 可导致企业大量核心业务中断
• 5 - 可中断企业几乎所有重要业务

e)  企业影响

• 企业影响 = ( 经济损失 * 系数 + 商誉损失 * 系数 + 合规影响 * 系数) / 3

• 0 - N/A
• 1 - 低于修复漏洞的成本
• 2 - 不会对企业年利润有明显影响
• 3 - 可以影响一定的企业年利润
• 4 - 对企业年度利润有显著影响
• 5 - 对企业年利润影响重大

• 0 - N/A
• 1 - 轻微的伤害
• 2 - 大客户或大量客户流失
• 3 - 商誉损失
• 4 - 品牌损害
• 5 - 品牌重大损害

• 0 - N/A
• 1 - 几乎不违规
• 2 - 轻微违规
• 3 - 明显违规
• 4 - 高调违规
• 5 - 严重违规或违法

  
  

f)  业务实力

• 业务实力 = ( 开发生命周期 * 系数 + 运维生命周期 * 系数 + 员工安全意识 ) / 3

• 0 - N/A
• 1 - 基本没有考虑安全问题
• 2 - 有大量的安全流程问题
• 3 - 有中量的安全流程问题
• 4 - 有少量的安全流程问题
• 5 - 几乎没有安全流程问题

• 0 - N/A
• 1 - 基本没有考虑安全问题
• 2 - 有大量的安全流程问题
• 3 - 有中量的安全流程问题
• 4 - 有少量的安全流程问题
• 5 - 几乎没有安全流程问题

• 0 - N/A
• 1 - 几乎全员没有安全意识
• 2 - 大部分关键岗位员工安全意识较弱
• 3 - 少部分关键岗位员工安全意识较弱
• 5 - 大部分关键岗位员工安全意识较高
• 6 - 全部员工都有极高的安全意识

  
  

4.  RTASS向量字符串与用法

5.  RTASS框架贡献与现阶段局限性

{

    "defaultLang": "cn",

    "cnTitle": "红蓝对抗演练评分系统（RTASS）",

    "enTitle": "Red Teaming Assessment Scoring System (RTASS)",

    "version": "0.2.1",

    "factors": {

        "OL": {

            "enName": "Offensive Level",

            "cnName": "进攻水平",

            "enDesc": "The highest level of technology used in the assessment path?",

            "cnDesc": "攻击者在评估路径中使用的最高技术水平？",

            "cnOptions": [

                "0 - N/A",

                "1 - 相当于入门级黑客",

                "2 - 相当于普通水平黑客或工具、脚本黑客",

                "3 - 等同精通渗透技术的黑客",

                "4 - 需要较为专业的团队配合",

                "5 - 相当于国家级APT黑客团队"

            ],

            "enOptions": [...]

        },

        ...

    },

    "factorCategories": {...},

    "processScores": {

        "AS": {

            "enName": "Offensive Strength",

            "cnName": "进攻实力",

            "vectors": [

                "OL",

                "OD",

                "TR"

            ],

            "algorithm": "(OL+OD+TR)*2/3"

        },

        ...

    },

    "finalScores": {

        "AE": {

            "enName": "Offensive Energy",

            "cnName": "进攻能量分值",

            "vectors": [

                "OS",

                "DS",

                "EI"

            ],

            "algorithm": "(OS+DS+EI)/3"

        },

        ...

    },

    "levels": [

        {

            "index": 0,

            "enName": "None",

            "cnName": "无",

            "className": "None"

        },

        ...

    ]

}

红蓝对抗演练评分系统（RTASS）目前公布的是 preview 版，主要向大家征集建议，大家有好的意见或想法，欢迎到github去提issue或PR：https://github.com/JDArmy/RTASS

在线评分计算机器：https://jd.army/RTASS/?lang=cn

[1]关于CVSS的版本演变及历史参见：https://en.wikipedia.org/wiki/Common_Vulnerability_Scoring_System

[2] CVSS通用漏洞评分系统，https://www.first.org/cvss/v3.1/specification-document

[3] OWASP风险评级方法：https://owasp.org/www-community/OWASP_Risk_Rating_Methodology

[4]注：本框架部分评分因子如“漏洞风险”、“企业影响”等参考借鉴了OWASP风险评级方法中相关因子。详见：https://owasp.org/www-community/OWASP_Risk_Rating_Methodology

阅读原文

跳转微信打开

人生如旅途，走走又停停。看着风景，耽误了行程；赶起行程，错过了风景。十一年后再来读这篇情书，里面的承诺我大体上是做到了。一路走来，风霜雨雪，一切都很值得！不负韶华，不负光阴！

阅读原文

跳转微信打开

我的职业生涯恰好覆盖了整个安全届的角色划分：甲方、监管和乙方。如果用一句话来总结，那么甲方学到“安全是为业务服务的”、监管方学到“技术是达成目标的一种手段”、乙方学到“打铁必须自身硬”。目前还远没到享受时候，持续奋斗会贯穿未来工作的始终。

我的人生回环

大家好！我是叶猛，我又回到了北京，跟北京说声：“嗨！”。这次我用了自己的真名字。在这个名字之前，我还有一长串的昵称或称呼：梦晔、Monyer、梦之光芒、猛子、小叶、叶队、叶帅、叶师傅、叶支、猛队……，这些称呼伴随着我前十年工作生涯的各个阶段。梦晔是我的笔名，是我姓名的倒序，在那个年少轻狂且心中“文意纵横”的时代，看到老舍把自己的姓拆开做字，便有学有样起了这个笔名。Monyer是从梦晔的发音造出来的英文昵称，从高中起一直用到现在。梦之光芒是从梦晔拓展出来的中文昵称，因为“晔”就是光芒的意思。这个中文昵称先是从05年起作为《黑客防线》的投稿笔名，后是作为百度空间的博客名一直到空间关闭。猛子这个昵称主要是刚毕业后在B公司工作，大哥大姐们的亲切称呼；小叶是后来特招到某省公安厅后，领导们的“爱称”；叶队是在公安厅任某科室支队长后，兄弟单位及合作伙伴的称呼；叶师傅、叶帅是省厅同事间的敬称和戏称；叶支、猛队是来到Q公司后，组建起国内顶级实战攻防红队，大家的敬称。关于我的称呼曾有过很有意思的事情，曾有不少人认识网上的Monyer还加了QQ好友，也认识现实中的叶队，但却不知道这是一个人。所以今天我用我的真名字为自己代言，也算是第一个回环吧。

听到宇宙的终点是人生的起点，我不禁莞尔，因为我也感觉人生是一个回环。称谓上的回环暂且不论，最近十年我又进行着另两个回环：一是从网络安全的甲方到监管方，再到乙方，又回到了甲方的回环；二是从沈阳到北京，到回沈阳，又回到北京的回环。我爱人说：你看你，兜兜转转，又转回去了。我说不然，虽然又转回去了，但能力变了、眼界变了、境遇也变了。如果用一个恰当的比较，这不是一个简单的循环，而是一个如同莫比乌斯带般的回环，虽然转了整整一圈，但已经站在了环的另外一面。

最近在和不少老板聊天时，都谈到了我的网络安全从业经历，也因此有了更多的感触。回顾是为了沉淀和畅想，总结是为了把握未来。

我的职业生涯从不同角度来看，算是既简单又惊奇。简单的原因是十余年工作经历全部是跟网络安全相关的，并且一共也只有3个东家。惊奇的原因则是恰好这3个东家覆盖了整个安全届的角色划分：甲方、监管和乙方，而且朋友同事听到我离开消息后，是一个比一个惊奇。

什么？离开北京大公司回辽宁了？……

什么？公安厅支队长都不干了？……

什么？要抛家弃子回北京了？……

（当别人告诉我，我的离职上了热门讨论，让大家震惊了一下，我还有些忍俊不禁。）

甲方时代：安全是为业务服务的

如果用一句话来总结我甲方的工作经验，那就是：“安全是为业务服务的”。

其实去B公司是有着偶然因素和侥幸成分的。在去之前A公司曾邀请我去面试，不过去跟导员请假没有申请下来，就作罢了。等B公司找到我时，恰逢暑假，遂商定好只做暑期实习生。不过实习期间，所在团队给我很大触动，那是一个高效、团结、热情、专业的团队，值得我继续实习下去。于是我跟学院做了申请，整个大四都是在B公司度过的，顺利拿到Offer，毕业后的两年也一直在B公司。

我所在部门是当时处于创业状态下的电商团队，职位最开始是渗透测试工程师，主要是代码和业务层面的安全工作，前期一直是我一个人。那时敏捷开发还在尝试阶段，DevOps更是影儿都没有。系统还是版本制，上线时需要在半夜进行，停服维护。期间比较有意思的事儿是协助架构师做MVC 2.0框架设计，通过框架和系统架构天然防御常见漏洞，当然现在很多开源的MVC框架也都内置了安全防护功能。后来11年部门拆分，便到了基础平台架构部，负责公司产品线的安全测试、代码审计以及安全内训工作。

在工作中也慢慢发现，随着安全从业者能力的提升，在掌握更多安全知识和理念的过程中，很容易陷入脱离业务过度防御的误区。有时安全人员会有种系统到处都是漏洞无从下手的感觉，甚至认为系统功能的本身就是漏洞。

Feature还是Bug这是一个问题！

这有点像我之前在知乎上回答的一个问题：某公司的安全人员认为手机验证码一定要是6位以上的，产品经理认为从易用性角度上一定要是4位的，于是就闹了很多矛盾。然而4位的验证码就一定不安全么？就没有更好的解决办法么？想当年支付密码必须要数字+大小写字母+特殊字符，要大于10位以上。而现如今，几乎所有支付应用的密码全部是6位纯数字，那么安全性是提升了，还是下降了呢？

安全是为业务服务的。脱离了业务本身去谈安全是没意义的，过度强调安全而忽视了业务可用性也是无稽之谈。不考虑系统架构和网络运行情况，生搬硬套各种先进安全理念和安全框架，会浪费大量资源又达不到预期效果。

当然，这并不是说安全要无限制地为业务让路，而是说安全人员要时刻思考如何在尽量保证业务的前提下，去维护系统安全，要考虑安全与业务共生的问题。

皮之不存，毛将焉附？

监管时代：技术是达成目标的一种手段

如果用一句话来总结我在网络监管单位的工作经验，那么就是：“技术是达成目标的一种手段”。

当时一些客观原因和机缘巧合，使我于11年底通过公务员特殊人才招募通道来到某省公安厅网安总队工作，一直到18年初离职为止。由于敏感性原因，工作内容暂且不谈。但这些年个人的成长和进步还是蛮大的，最重要的是在做人上有了长足的提高。

用技术去辅助公安工作，可以起到四两拨千斤的效果。我举个的例子：譬如某舆情事件，领导的想法是通过统计分析得出关键线索。但统计分析的前提是数据的获取、处理、存储、分析和展示。随着事件的持续性发展，如果纯人工去做，那么投入成本会是时间线性增加的，甚至会出现人工分析赶不上事态发展速度的情况。而通过程序去做，则可以在更短的时间内获得更好的结果。

但是不是说技术就永远比传统手段更好用呢？也不尽然。从另外一个例子来看：如果拿到了犯罪嫌疑人的手机，还在想着用技术手段去破解开机密码，就没有那些公安老哥们直接从嫌疑人口中撬出密码来的方便。

当然我只举两个很简单也不那么敏感的例子，实际上在这近7年的工作中，上百场战役和案件的侦办给我留下很深刻的认知：就是“技术是达成目标的一种手段”。

网安的成功破案并不是在我们这种技术人员招进来后才有的，只不过我们给了网安多一种选择，有时则是一种更短的路径。而在工作中，包括体制内、甲方和乙方，也不应该总从纯技术角度去考虑问题，有时换一种思路会发现有更快更容易的解决途径。

乙方时代：打铁必须自身硬

如果用一句话来总结我在乙方的工作经验，那么就是：“打铁必须自身硬”。

Q公司是目前网络安全toB领域的佼佼者。18年初我来Q公司时，它还没有自己的专业化红队。一些实战攻防演习任务的承接还要靠抽调各地渗透测试人员临时组队，人员战斗力以及演习排名均得不到保障。入职时，我在主管副总裁的引荐下，带着一个题为《专业化渗透团队可行性研究分析》的团队规划PPT赶赴北京见到了董事长。里面讲的就是要建立一支高精尖、能打胜仗的专业化渗透团队。汇报比较顺利，董事长最终同意给我5-6个HC来建设这样一支团队。

因为这个团队主要是模拟黑客APT手段来开展工作业务，因此我从APT“高级持续性威胁”这个名词中借用了“高级”二字，从零开始组建了“高级攻防部”网络攻防实战团队。在团队建设过程中，我借鉴了体制内团队建设管理经验，以“队”为建制来组建红队，把每支红队的管理者称为“队长”，队内员工称之为“队员”，红队按区域做命名，譬如“成都队”、“南京队”、“沈阳队”、“杭州队”等。在接下来的两年中，队伍一直在向着最高效、最专业化的道路迈进。建设过程含辛茹苦暂且不谈，现如今高级攻防部已经是一支横跨全国三个大区，人数超过*0人的专业级红队，攻击队数量也从0增长到*支。每次工作任务都以攻击队为单位来开展，类似于特种部队中的作战单元。一支攻击队由*-*个人构成，以攻击队队长为技术及领导核心，团队成员各具打点、社工、内网等不同方向本领，大家协同作战。正如任正非所言：要把能力建立在组织上。这样的团队组成模式对于实战攻防演习及红队评估项目来说是最有战斗力的。我统计过去年（2019年）的全年实战演习项目，我们排名第一次数是76%，排名第二是24%（第三及以后没有），综合作战能力已经远远将友商团队甩到了后面。

在部门的成长和管理过程当中，技术是我们的饭碗、能力是我们的本钱、排名是我们的荣誉。团队成员在技术能力、带队能力以及声望名气上均日新月异，长足提高。我们没有设立任何类似于996的工作制度，也不树立任何“舍己为人”的典型，但在项目中所有人都勇于吃苦耐劳、加班熬夜、奋战到底，因为大家都知道“打铁必须自身硬”，自身硬就是本钱，就是底气，就是话语权，是谁都拿不走的资本。前些日子，团队中某个毕业2年带队1年多的攻击队队长被某大型合资公司以高年薪挖走了，去做安全防护方面的负责人，还给配车。在不舍的同时，我也感到十分欣慰，有着沉甸甸的满足感，感觉团队没白带，人没看错也没白培养。

很多管理者怕人员流动，其实正常的人员流动对于团队和个人都有着好处。对于团队所有人员，我一直在宣贯着我称之为“技术人员发展四阶段”的成长路线：技术输出、经验输出、思路输出和决策输出（这个上一篇公众号也有详细地说明）。我希望从我团队走出的技术人员能成为外面的技术Leader，技术Leader能成为外面的技术经理，技术经理能成为技术总监。在日常的团队管理中，我也会尽量为大家提供能够向下一阶段发展的舞台和平台，给大家锻炼成长的机会。我认为这样的团队氛围才是健康的，对于团队成员来说才是负责任的，这也是自身硬的表现。

坚守梦想，持续奋斗

最近“刘备”那段“接着奏乐，接着舞”火了，然而在这个梗之前“刘备”说了一句话：“我打了一辈子仗，就不能享受享受吗？”。

可以享受吗？当然可以！然而梦想达成了吗？

对于刘备来说，没有！对于我来说，也没有！

那么就远没有到可以享受的时候。

在机关单位后期的安逸并不是我想要的。很多人打破脑袋想要进机关，捧着铁饭碗“混机关”。但对我来说混的不是机关，混的是自己。铁饭碗不应该是某个单位，应该是自己的能力和本事。不能靠“混”的施舍，因为混着混着就到达“宇宙的终点”了。

在乙方团队建成后的功成名就也不是我期望的状态。临走前有个大哥劝我说：如今团队已经建起来了，最难的时候都过去了，接下来可以养老了，只要大差不差干一干，可以活得比很多人都好。他说的都是真心话，我也都想到。但我还有追求，还想发展，还想做更多，还想做得更好。

正如最近这个段子：“看到74岁与77岁的两个老人为了一份工作还争吵这么激烈，你的人生还有什么借口不努力呢？”

所以，我的人生又经历了这一次回环：我又从乙方回到了甲方，我又从沈阳回到了北京。虽然岗位在变，城市在变，但奋斗的心没变。在接下来工作中，持续奋斗还是会贯穿我工作的始终。

仅以此文作为第一个十年工作的总结，也作为接下来工作的自勉吧！

感谢爱人的理解，朋友的支持！

也感谢屏幕前您的传阅，谢谢！

阅读原文

跳转微信打开

我们可以说公司某个老板是否有良心，但公司本身不存在良心；也可以说某个领导有人情味，但单位同样不存在人情味。公司和员工之间就是一种“等价交换”、“你情我愿”，“愿打愿挨”的契约关系。只有更客观地看待员工与公司的关系，才能更好地去谋划自身发展。

阅读原文

跳转微信打开

这个世界最刺激的事情莫过于脱离现状、摆脱束缚、迎接挑战，而网络黑客几乎能够满足这一切刺激的幻想，这是最吸引人的地方。然而对于旅游的人来说，爬山是兴奋的；对于景区捡垃圾的人，爬山只是为了完成生计。当黑客成为了生计，则有可能不再一切尽如人意！

回想起来，我从高中时期02年左右开始接触学习网络安全，到大学时期06年博客流行时成为网络安全活跃分子，再到11年进入某部门的网络沉寂期，再到18年离开后再次的不安分，可算得上是一段跌宕起伏的岁月了。

很多人说：“网络会记住你一辈子！”。

我以一个过来人的经验告诉你：不会的！网络有着它的记忆时限。

除非你能不断去刷新它的记忆，或者你成为乔布斯一般的传奇或经典，否则总有一天网络会将你忘记。

如果在11年左右，你到百度去搜索：Monyer，你能获得到几百万搜索结果。在有意地沉寂6、7年后，现在估计充其量几万条了吧！

有很多网络安全老人儿可能还记得那个monyer's game（http://monyer.com/game/game1/ ）。那上面长长的通关列表见证了中国网络黑客的进步和成长，也见证了中国网络安全的快速发展。里面有一些熟悉的ID现如今要么是各个互联网大公司的顶梁柱大佬，要么自己创办了网络安全公司成为了老板。有些人依然奋斗在技术的前沿，有些人已经转型创业或做了管理。

时代变迁，白驹过隙。社会在发展、网络在发展、人也在进步和发展，而这个速度实在是太快了。我在07年做monyer’s game时从来没想到，未来这种模式其实可以做成比赛，做成平台，甚至一个公司能靠此达到上市的地步；与08年我和余弦创建XEYE团队时相比，今天的网络安全团队朝着更专业化、更职能化、更商业化来运作；CTF、AWD、PWN2OWN当年只是一种业余的消遣，如今也可以成为一种职业。

近期又见有很多新的小伙伴儿问询：如何才能成为一名黑客？

事实上这个问题从我06年有博客以来就从来没有断过。我几乎很少去给人正面回复。因为说实话，黑客是一个很模糊很笼统的概念，会破解软件算不算黑客？会渗透技术算不算黑客？会挖掘二进制漏洞算不算黑客？广义来看，肯定都算。那怎么来学？各有各的学法。

如果把黑客作为一个兴趣爱好，我是非常赞同的。入门其实也不一定需要大师指引，学会用好百度、谷歌，去搜索“黑客技术入门”，简直是一搜一大把。但如果想把网络安全作为一个终身职业，那么可能就需要想清楚了：你是否愿意把你终身都投入到网络技术的事业上？如果只是因为看到了目前网络安全的热门，或者只是对网络攻防技术心血来潮，那么我建议要充分想好、调研好再做决定。

有句俗话讲：女怕嫁错郎，男怕入错行。其实网络安全并不是一个理想的行当，甚至相对于一些传统行业而言是一个相对糟糕的行当。一方面，一个人能力强否并不取决于他所接受的教育程度，身边学医、学广告、学化学出身的黑客比比皆是；另一方面一个不能孜孜不倦，始终处于新知识、新技术学习状态下的安全爱好者，必然会被超越和取代。

如果你找补习老师，一个是有着20年教龄的老教师，另外一个是20岁刚毕业的新老师，你会选哪一个？

如果你去医院挂号，一个是有着20年工作经验的老专家，另外一个是20岁刚毕业的小伙子，你会挂哪一个？

如果你找木匠做工，一个是有着20年工作经验的老木匠，一个是刚出徒的年轻人，你认为谁的手艺更高超？

我认为在薪酬一样的情况下，大多数人都会选择老教师、老医生、老木匠。因为老则意味着经验丰富。（如果你都选择年轻的，也不必太在意，你一定与众不同） 

那么同样类比过来，如果我们选择IT人才，一个是有着20年编程经验的老码农，另一个是有2年编程经验的新人，那么应该选择哪一个呢？

我不知道别人怎样抉择，若是我去选择，在他们同样满足招聘条件，展现相似技术能力的情况下，我会优先选择年轻人。原因就是2年工作经验的人会有更大的技术上升空间，有更高的活力，而单纯的20年的编程经验可能未必会强于2年编程经验。

为什么会出现20年的技术经验赶不上2年技术经验的情况？最主要的原因还是互联网以及IT技术的发展和迭代速度太快了。20年前，估计大部分程序员汇编都玩的很溜，一些凤毛麟角的网站还是用C或Perl开发的；20年后的今天，纯C开发都没那么多了，但python、go等语言大行其道。此外还有一个原因是网络技术开始分化，并且这些年技术分化和派生的越来越厉害了。

记得前些日子跟人聊天谈到：这些年随着网络技术的发展，最先淘汰的是哪一拨人？我半开玩笑的说：应该是学Flash的人吧！因为随着ES6、CSS3、HTML5的发展，WEB展示的进化，iOS的不兼容，Chrome对Flash的逐步冷漠，一名有着10年或20年Flash制作经验的工程师很有可能会面临失业的风险，而他掌握的ActionScript也很可能不再有任何用武之地。

拿我个人为例，我除了研究网络安全以外，其实还是一个“全栈”的开发程序猿。仅拿前端举例：十多年前，HTML、JS、CSS我就玩的很溜了。之后流行web2.0我也与时俱进研究Ajax、研究响应式布局，出现jquery、bootstrap各种新潮流我亦步亦趋。然后开始出现HTML5、ES5、ES6、CSS3、TypeScript、CoffeScript、less、sass、webpack、angular、react、jsx、vue……因为我不是专业前端，后来有些技术我就选择性不跟了。我不知道目前的全职前端工程师如何，但是一定有一大群人依然时刻在跟进技术前进的脚步，甚至在带领技术的发展，那么在这方面他们一定是强于我的。

在这些新知识的学习上老手并不比新手有太大的优势。你会jquery，跟你在学习angular上不会带来任何的便利。一个会css2的人和一个会css3的人在学习less上的时间也不会相差太多。而若开发一个项目，仅会css，跟先学会less，之后再应用的程序员相比，也不会慢太多。但新人总是会率先学习新的东西，而刨除之前的学习成本，显然工作效率上就会有所提高。而会一大堆老技术的人，却又不表现在新技术学习上的优势，反而由于固有的技术思维，老技术则有可能变成累赘。

网络安全上同样存在这个问题，像我当年也是加密破解、二进制漏洞挖掘利用、入侵渗透通吃的。缓冲区溢出也能简单玩一玩，然而在DEP、SEHOP、ASLR等一些防护技术普及后，又没有精力照顾这些，这块的技术积累上早已被时代远远地抛到了后面。现如今，一名黑客且不说通吃所有网络安全技术，甚至我看连WEB渗透和内网渗透都划分成了两个方向，同时精通的人都不多。

随着无线技术、移动系统、IoT、工控互联网、云计算、大数据、AI……一大堆新技术的出现，其实带来了一大堆新的安全问题。这些安全问题既有共通性，又有独特性。然而随着一大堆安全方案的产生，漏洞要么被挖掘了出来，要么隐藏得更深。再想挖掘漏洞，要么靠浸淫，要么靠运气。吴瀚清也说过：前端越来越猥琐，底层越来越变态。研究无线安全的人可能不会再有精力研究iOS或android系统的漏洞，研究渗透技术的人可能也没有精力再去研究逆向工程……这是技术分化的必然结果。在10年前，有很多“全栈”的黑客；现在不是说没有，但肯定已经不多了。再下去，可能研究智能汽车安全的人仅研究这一点就可以研究一辈子。

泛而不精的人在网络安全技术分化的形势下会面临很大劣势，而选错方向的人同样不容乐观。在06年、07年读过我博客的人会知道我在XSS上是十分精通的，Gmail、YahooMail的洞也不是没挖过。然而随着安全技术解决方案和防护能力的提升，Chrome基本上把一半的XSS给咔嚓掉了，CSP又咔嚓掉了另一半，使得外链脚本几无执行可能，同时一些规则的限制使得即便插入了脚步也执行不了。虽然现在XSS还是很有市场，但照比10年前已经是巨大的萎缩了，可能再过10年就将成为一项边缘化的技术。

我最近研究谷歌的BeyondCorp也很受感触，这是一个力争终结企业内网的网络安全架构。如果内网都没有了，那么内网渗透技术还有存在的必要么（当然这是指未来，现在大可不必杞人忧天）？这种安全架构要达到普及可能还需要10到20年或更久的时间，但也有可能像Chrome、Android、云WAF等产品或技术一样以更短的时间占领市场，你看今年ISC大会的主题就已经是零信任架构了。

前两天跟人聊起技术人员的发展路线，我总结了几个阶段：技术输出阶段、经验输出阶段、思路输出阶段和决策输出阶段。可以分别对标技术人员、团队Leader、部门技术经理和公司技术总监或CTO。这不是所有人都适合的发展路线，因为不是所有的人都能够在技术工作中总结经验并形成输出，更不会有太多人能够掌握市场、分析形势、预测动向形成新思路，而能正确作出决策的人更是寥寥无几。如果有相关的能力，能一步步往上走固然是好事；但如果由于主观或客观原因，没办法走到下一阶段，那么就要时刻学习、学习、再学习，不断研究、研究、再研究，掌握自身在技术上的领先优势，保持对新兴技术的把控能力，才能够不被新人所淘汰。

前两天一个老同学打电话过来，跟我述说“中年危机”：说已经在公司做了近十年，感觉很有危机感，很迷茫，有再择业的想法。我帮他深入分析了下发现，技术输出上他已比不过新来公司的年轻人，而又没有经验输出的能力，这导致了他在工作上必然有很大危机。然而若是一切都是自身原因造成的，再择业可能问题会更大。而这一切都是由于技术分化和派生造成的，他没进步，技术在进步，别人在进步，所以就有被淘汰的危机。“熟读唐诗三百首，不会作诗也会吟”这种通过反复熟练来成为专家的路数在IT技术行业上不会出现。在IT技术行业如果没有每天在进步，那么就是退步，那么就是被后浪拍在沙滩上的前浪。

有很多在校的大学生及网络安全爱好者想学习网络安全、黑客技术，那么请先询问自己的内心：你要学习的目的是什么，爱好还是就业？你是否要把这当作你未来的职业？你是否有毅力始终学习、进步不被淘汰？是否有能力持续性地做高效率技术输出，或达到技术输出的下一个阶段？如果是的，那么我建议你入坑，你能在学习、工作中体验到畅游互联网络、突破边界限制的刺激感；如果不是，那就仅把它当作一个业余爱好就好。

对于那些已经工作了N年，看到网络安全蓬勃发展，想要再择业的人，同样要多问自己：你是因为什么对现有的工作失去的兴趣，是否会在未来网络安全的学习和工作上产生同样的问题？你要通过怎么样的学习追上其他人的脚步，尤其是年轻人的脚步，并且在工作中持续性具有领先的优势？虽然TK或黑哥都是弃医从黑的成功案例和业界典范，然而他们亦有着一个由兴趣爱好向安全职业化转换的过程，那么这种形式是否对自身受用？所有的问题都需要做好思考，给定答案，确定无误后，再义无反顾投入网络安全的大坑中。

这个世界最刺激的事情莫过于脱离现状、摆脱束缚、迎接挑战，攀岩、跳伞、蹦极、竞技都可以达成这一目的，而网络黑客几乎能够满足这一切刺激的幻想，畅游网络、突破限制、斗智斗勇，这是最吸引人的地方。然而对于旅游的人来说，爬山是兴奋的；对于景区捡垃圾的人，爬山只是为了完成生计。当黑客成为了生计，则有可能不再一切尽如人意；此外由于目前网络安全市场的分工细化，可能最终给定你的职位未必是你当初想要的那个网络安全职位。

黑客是场电子梦。我们这些老鸟在这场梦里畅游了十来年，也将继续畅游下去。然而作为安全爱好者的你是否已经准备好了入梦？又是否会将梦一直做下去呢……

后记：本文大约成文于2018年的6月份，希望给那些希望成为网络安全从业者，甚至是IT技术从业者一个参考。当时还申请了公众号，励志要至少1个月一篇文章，到现在一年了，文章数量还是为0。仅以此文作为开篇吧，但现在不太敢保证什么，如果能一季度出一篇算高产，半年出一篇算幸运，一年出一篇就算达标了吧。感谢那些即便公众号文章数是0，但依然默默关注我的265人。

另：本文可以转载，留下署名即可，就不用再征求我意见了。不过除了错别字之外，就不需要再帮忙修改文中内容和观点了哈。

阅读原文

跳转微信打开