云安全架构 (二)：Azure云平台威胁检测详解

更新背景

• 为什么先更新本篇？

相信第一篇《云安全架构连载之一-Azure整体架构及安全亮点详解》大家肯定看的不过瘾，觉得深度上没有满足各位严苛的云安全研究人员的胃口。第一篇笔者的目的还是想让各位对Azure的整体分层上有一些简单了解，随后的一些文章会逐步展开。

废话不多说如果按照之前的一些架构逻辑，了解完Azure的整体架构分层之后，就会进入Azure分层中的各个安全展开，但是笔者思前想后，觉得在讲解整个Azure分层中细的架构和安全架构之前，先给大家从反向看Azure整个云平台威胁的体系建设详细展开情况，这样让大家了解Azure云平台到底在检测和防御什么样的威胁。这样反过来去讲整体安全架构就会适得其反，更有一些效果。其实整个威胁检测是在Azure SDL体系下的，后续文章会详细分析Azure SDL亮点和落地姿势。

另外Azure对于租户提供的威胁检测体系包括（Azure Security Center、Azure Sentinel、Azure Cloud Firewall、ATP）等会有机会再跟大家同步和分享。

• 业界首次深入分析云平台威胁检测

PS：打个广告，云平台威胁检测有深度而且全面的，笔者确实很少见到。笔者不才的认为本篇文章属于业界首次针对云平台威胁检测进行深度、体系化、全面的分析。

• 重要免责声明

特别声明：本公众号只代表《鸟哥谈云安全》个体观点。

强烈免责声明：由于本篇内容分析了Azure云平台威胁检测策略，可能会造成某些人的误解。《鸟哥谈云安全》笔者声明：不存在非法获取行为，所有的分析全部构建在Open Source Intelligence（开源情报基础上）。

Azure安全架构设计原则

• Azure安全架构设计原则

在正式开始云平台威胁检测体系之前，还是要捎带提一下整个Azure的云平台安全设计原则，这些原则指引Azure的平台架构和安全架构前行，在遇到一些设冲突的时候，可以很好的达成一致性设计语言的要求，云平台系统、网络、云原生等各个架构团队跟安全架构团队有一致性沟通语言，将会是一件非常幸福的事，会让安全推动落地变的简单。

下面展开Azure安全架构设计原则：

1、安全设计原则概述（因为主要讲Azure平台威胁检测体系，不会展开讲解，如有兴趣可以联系微信：ThreatSource 获取公开安全设计文档）：

• Apply generic security best practices（应用业界通用的安全最佳实践）

• Understand that isolation is key（隔离是关键）

• Consider security as a the foundation for the entire solution（安全将会是整个云底层的基础中的基础）

• Assume attackers are authenticated and authorized（假设黑客已经过授权和认证）

• Assume all data locations are accessible（假设所有数据存储位置都可以被访问到）

• Use established strong cryptographic technologies（利用强壮的加密技术）

• Automate security operations（自动化安全运营）

• Reduce attack surface（削减攻击面）

• Restrict intra-application communication（限制内部应用通信）

• Audit extensively（大范围的审计，从下面的文章来看，Azure确实做到了这一点）

• Implement effective governance, risk management and compliance（实现有效的治理、风险管理和合规）

• Create data classification zones（创建数据机密区域）

2、Apply generic security best practices（应用业界通用的安全最佳实践）

简单一点，做一下Azure Follow哪些最佳安全实践？例如将IT基础架构系统放在安全且受控的位置（物理安全原则）、深入实施最小特权和防御原则（身份安全原则）、使用防火墙并将单独的NIC用于管理功能（网络安全原则）、进行渗透测试并持续审查安全流程（红蓝对抗）、使用网络防火墙对网络进行分段并提供访问控制（网络安全）；

笔者总结：

其实从Azure安全最佳设计原来来看，大家会觉得朴实无华，本来我也借此机会向”浮躁“的安全界发声，每天不用去搞一些高大上的NIST SP 800-53、CIS、NIST CSF、SANS什么的最佳实践，我不是说这些东西不好，说实话最重要的是适合自己的才是最好的。我就说我观察到的一个点来，Azure的最佳实践是落地在实处的，不是空话的，就拿红蓝对抗这件事来说，Azure做到了持续的进行渗透测试，并且会同步渗透测试报告给互联网的所有人（包括客户），试问这一点有多少厂商做到了，AWS和Google我没看到。如果有请各位看官也一定通知下。

3、Understand that isolation is key（隔离是关键）

Azure总结的下面几个点：

• Azure云服务产品隔离（包含VM，Azure产品和自动化脚本隔离等）；

• Azure云服务产品依赖库隔离（第三方源代码、配置文件等）；

• 租户计算隔离（Hyper-V虚拟机隔离、Hyper-V容器隔离）；

• 租户存储隔离（存储在上面的数据等隔离）；

• 租户网络隔离（租户和租户之间网络隔离、租户和平台双向访问隔离）；

• 备份和恢复隔离（各种系统会自动化备份，这些备份是否也不允许进行全局访问）；

• PS：多租户隔离也是一个分层细致的隔离策略，要从租户开始层层分解。

4、Reduce attack surface（削减攻击面）

这里跟传统的削减攻击面稍微有点不同的理解就是，Azure是利用纵深防御，例如SDL、网络安全隔离架构、红蓝军对抗之后加上限制攻击者访问可控的路径，经过层层纵深防御，Azure认为攻破的可能性非常小。

其他设计原则不再赘述，请联系笔者进行交流。

Azure云平台面临的风险

• Azure云平台面临的风险

1、身份安全风险

Azure Active Directory账号、OAuth2 Client Credentials、Azure各类云服务产品的Connection String（连接串）都会在互联网被访问到，所有很明显，Azure自身的云平台也是存在一些风险的，所以云安全不管是底层平台还是租户侧的安全架构，都需要由非常懂云安全的架构师来落地和解决风险，拼凑和缝缝补补式的云安全只会让自身业务的发展遇到巨大挑战，云安全架构师贡献和长时间的投入要云安全企业从长远给足发展空间和机遇。

• 身份风险安全架构解决方案：账号层面梳理清晰、最小权限设计、最小业务网络安全控制、云服务产品开启默认安全配置、威胁检测方面需要投入模型、红蓝军对抗要重点发现自身风险（Red Team和Blue Team要充分合作配合好）、云服务产品安全开发大量安全功能（上面的一些削减攻击面、进行隔离、网络控制是不是就用上了^_^）；

2、网络安全风险

Azure网络威胁检测包含第一篇讲到的A10 Network设备，A10 Network通过Azure NetMon、Azure Geneva Monitoring and Diagnostics（本篇重点）结合来检测内对外、外对内的各种网络攻击，另外Azure NetMon会实施自动化检测和防御能力，通过进行采样比的方式来进行采集、分析、响应和自动化防御的；

3、主机安全风险：

第一篇已经讲到了Azure云服务产品的架构组成，假设云服务产品层Extensions模块被入侵，会导致提供Extensions的VM造成入侵，针对VM的入侵也会使本篇重点讲解的（Geneva）安全监控同步到C+AI SOC（Cloud + AI Security Operations Center）进行响应（Response）、调查（Investigation）等动作。主机上的主要风险是特权账号被异常登录、操作系统配置恶意更改、植入恶意木马和蠕虫、代码被恶意篡改、操作系统漏洞、操作系统安全异常登录等风险；

4、云服务产品风险：

Azure云服务产品历史上也被报告了很多的安全漏洞，例如CVE-2019-1372（Azure App Service on Azure Stack代码执行漏洞）、CVE-2019-1234的SSRF漏洞都会影响Azure公有云云平台的漏洞，针对这些云服务产品的威胁检测也将会是一个重要的内容，Azure Geneva Monitoring and Diagnostics上也提供了一些服务级的检测能力，后续会展开分析；

5、第三方合作伙伴风险：

Azure云有非常多的合作伙伴，这些合作伙伴管理着Azure的一些资源包括客户的甚至是云平台自身的，这些合作伙伴的安全性其实还是非常差的，安全等级跟微软这种，差距还是很大的；

Azure云平台威胁检测

• Azure云平台威胁检测体系概述

1、整体架构概述

• 日志收集：

• VM：通过Azure Security Park（AzSecPack）来收集虚拟机日志，采用Geneva Monitoring Agent（Linux和Windows）端来进行数据上传，通过SCUBA Poller（通过低延迟的日志分析威胁、调查等，这里根据各种开源情报猜测一下这里的SCUBA就是实时分析系统，可以第一时间进行准实时的威胁检测分析）或者ASM Poller把数据传递到Kusto SIEM平台；

• Bare Metal：裸金属服务器会通过Windows Event Collection (WEC)或者Windows Event Forwarding (WEF)来投递数据到Kusto SIEM平台；

• 网络设备：网络设备日志通过Syslog投递数据到Kusto SIEM平台；

• 分析框架和逻辑：

• 产出安全事件：通过Kusto SIEM和SCUBA进行安全事件的检测和监控；

• 进行响应：Kusto SIEM和SCUBA产出的告警（未转化成安全事件）同步给Incident Management（IcM）平台进行响应处理，执行Action动作的还是云产品服务的部门的员工，让云产品服务部门的人来确认IcM Ticket工单是否已经解决；

• 进行调查：确认后的安全事件同步给Security Incident Response（SIR）团队进行事件的深度调查；

• 采用的最佳实践标准：

Azure如果发现了高敏感政府的入侵检测行为，C+AI Security Operations Center (SOC)和Azure Security team（Azure安全团队）会通过US CERT Federal Incident Reporting Guidelines（https://us-cert.cisa.gov/sites/default/files/publications/Federal_Incident_Notification_Guidelines.pdf）来进行应急响应最佳实践和定义对应的响应事件的SOW工作范围说明；

另外针对Azure自身的安全事件应急响应也会根据《Azure Incident Management Standard Operating Procedure》来定义标准化应急响应流程；

• 事件处理流程：

云产品服务部门的人通过IcM Ticket工单处理完成之后，发现存在相应的安全事件，会同步给SIR应急响应团队进行调查和事件的止血等操作；

• 小结：

其实Azure威胁检测提出来了一个Multiple levels（多层）威胁检测框架，第一层分析Azure Geneva Platform可以让Azure安全快速的进行诊断、监控、分析动作；第二层Azure Geneva来针对保护的Azure环境而采集的Metrics（指标）、Logs（日志）和Analytics（分析）；第三层Geneva Monitoring Agent来采集不管是Host OS、虚拟机上的GuestOS、Fabric Controller等等主机层面的信息；所以很明显就可以看出来，威胁检测的层次跟云平台架构息息相关，如果威胁检测的分层不足，覆盖的安全Agent范围不够、覆盖的安全Agent数据采集不足、威胁检测分析平台的模型不足，都将会导致某一层的入侵被遗漏，导致无法发现；

2、Azure Geneva（本文重点）详解：

• 郑重声明：

笔者在正式开始前，还是要重点声明一下的，笔者是通过Azure US Portal提供的正常AKS Extensions列表，发现了Azure Geneva Agent的部署Extensions模块，安装到了VM机器上，进行了详细分析的；由于会牵扯到非常细致的检测策略的细节，笔者会针对性的选择分析，力求覆盖面的和技术的深度有保障；

• Azure Geneva整体介绍：

笔者在第一篇中其实讲到了一些内容，本篇文章在深入进去讲一些细节；

• Security Logging And Monitoring：包括安全日志以及监控、用来监控和告警通用的安全场景的风险；

• Baseline CCV：Azure OS极限配置并且进行自动化的持续验证；

• Azure AV：Azure反病毒配置进行System Center Endpoint Protection来进行中心化的处置，通过Microsoft Endpoint Protect、Microsoft Defender和ClamAV来防御Malware；

• AppLocker And Code Integrity：验证代码签名；

• Vulnerability Scanner：持续发现OS、OS Feature和第三方软件的漏洞；

• Active Directory：针对本地域控里的账号创建、删除、修改、禁用等操作进行监控，特权账号通过和OneIdentity打通来收集自动化的账号创建、删除、修改、禁用等操作日志；

• Service Audit Logs：针对Azure云服务产品进行嵌入式的收集，这个嵌入式收集方法是通过SDL的方式进行推广的，技术的方式采用iFX Audit Instrumentation注入方式来采集；

• Azure Geneva-资产收集

• 风险：资产是所有安全工作的基础，笔者深有体会，做好资产库简直是一件非常要命的事，资产库不全导致了风险面无法看见，而资产库又非常难做好，笔者不想展开针对资产库如何全面的覆盖，笔者仅分析一下Azure的底层资产库收集哪些信息，让大家有一个直观的体会，进而带来一些思考；

• 检测分类：

• 网络资产数据：Azure Networking Team会把相关的网络设备信息，包括硬件厂商、硬件型号、网络设备位置等等信息同步到Kusto SIEM中，后续进行对应的分析；

• 操作系统资产数据：操作系统收集9种不同的数据类型的数据，包括MS Assets（微软资产）、DCMT、Cockpit、VMAC、Intune、Active Directory (AD)、DNS、Network Graph Service (NGS)和Fabric2日志源（说实话笔者也搜索不到DCMT、Cockpit等材料，有机会再详细分析后续同步吧）；

• 服务：包括SQL Server、Teams等Azure使用的各种产品；

• 举例系统检测项：笔者进行分析后发现采集如下的信息（驱动、Windows服务、产品、功能、补丁、版本、证书、提取证书公钥、NTP、ASEP注册表、反病毒注册表、自动运行AutoRun、Applocker注册、硬件注册、SecureBoot注册表、TPM注册表、CI配置功能、Bitlocker状态、WU设置注册表、MSRC注册表、DSMS注册表、AZWaston注册表、容器版本、容器镜像、Docker容器、Docker容器详情、Docker容器进程详情、Docker卷）；

• Azure Geneva-内存Dump分析

• 风险：特权凭证在内存中明文获取风险；一旦黑客入侵到Azure的操作系统上，如是普通权限肯定会利用操作系统本身服务、内核、第三方服务能安全漏洞进行提权到管理员，提权之后会利用ProcDump（参考：https://www.microsoft.com/security/blog/2020/06/24/defending-exchange-servers-under-attack/）和Mimikatz针对入侵的高危应用例如Exchange等来获取敏感的特权账号（例如域控管理员的明文密码获取）；

• 检测方式：Azure Waston采用了获取用户各种Crash进程Dump Procdump的AwGetUseProcDump、收集Crash状态包含如下几种：（收集Windows .NET已挂起的Thread线程方法AwGetSuspendThreads、被强制终止进程的AwGetForceTermination、恢复强制终止进程失败的AwGetResumeIfTerminationFails）等、另外Crach进程的信息收集包括（AwSetCrashNotificationProcessPlatform、AwGetCrashNotificationProcessPath、AwGetCrashNotificationProcessName、AwGetCrashNotificationEventType、AwSetCrashNotificationReportId等等多达20+信息收集维度），通过这些信息收集到Azure Waston后进行收集、分析以及进行调试，并且自动化提供根源分析的自动化分类能力；

• Azure Geneva-系统账号登录异常检测（Azure内部名KnownEntity）

• 风险：如前面所述，一旦黑客入侵到Azure的云服务产品上，第一步要做的就是要进行驻留、操作系统提权以及最终的实现横向移动到敏感目标进行数据窃取，而利用Windows账号的横向移动更是在APT报告中屡见不鲜，所以系统账号的异常检测非常重要；

• 检测方式：采用账号和组的白名单方式进行分析和采集，内部的采集组件叫KnownEntity分析，主要分析目的是黑客入侵后采取了异常账号登录的话，会直接进行告警，具体的内容展开分析一下：

如上图所示，针对Azure Service Fabric、Microsoft Dynamics以及Microsoft Network Monitor的账号进行收集；

如上图所示，是具体的登录组的白名单；

如上图所示，以及最终的安全组的登录；

• Azure Geneva-各种日常监控扫描

• 风险：前面讲到Azure被入侵之后会利用账号进行横向移动，同时黑客会利用SQL Server的漏洞、共享的漏洞、扫描、恶意的进程、安全基线配置错误、特权账号等手段来进行入侵，达到窃取重要且核心数据的目的；

• 检测方式：如下表配置策略所示，会针对用户组（UserGroup）、系统安全基线（ASMBaseline）、前面讲的资产收集（SWInventory）、事件驱动（EventDriver）、进程和网络通信（NetIso）、SQL Server漏洞扫描、进程调查（ProcessInvestigator）、共享漏洞扫描（ShavaVulnScan）、内核模块扫描（KernelInventoryScanner默认关闭）；

<?xml version="1.0" encoding="utf-8"?><AsmScannerConfiguration><ScanManagerheartbeatFrequency="PT1H"><Resources><!-- TBD. A placeholder for providing job constraints, working directory, and session parameters --></Resources></ScanManager><Scanners><ScannerInfoname="UserGroupScanner"path="UserGroupScanner.exe"persistent="true"frequency="PT0S"firstRunDelay="PT0S"priority="normal"featureName="AsmUserGroup"maxRuns="0"><Arguments></Arguments></ScannerInfo><ScannerInfoname="AsmBaselineScanner"path="DSCLauncher.exe"persistent="false"frequency="P1D"firstRunDelay="PT16M"featureName="AsmBaseline"maxRuns="0"><Arguments>-scenario:OSBaseline</Arguments></ScannerInfo><ScannerInfoname="SWInventoryScanner"path="SWInventoryScanner.exe"scannerconfig ="InventoryScannerConfig.xml"persistent="false"featureName="AsmSWInventory"maxRuns="0"><Arguments></Arguments></ScannerInfo><!-- <ScannerInfo name="KernelInventoryScanner" path="KernelInventoryScanner.exe" persistent="true" frequency="PT0S" firstRunDelay="PT0S" priority="normal" featureName="AsmKernelInventory" isPilot="true" maxRuns="0"> <Arguments></Arguments> </ScannerInfo> --><ScannerInfoname="EventDrivenScanner"path="EventDrivenScanner.exe"persistent="true"frequency="PT0S"firstRunDelay="PT0S"priority="normal"featureName="AsmEventDriven"maxRuns="0"><Arguments>-config:EventDrivenScannerConfig.xml</Arguments></ScannerInfo><!-- <ScannerInfo name="EventFilterScanner" path="EventFilterScanner.exe" persistent="true" frequency="PT0S" firstRunDelay="PT0S" priority="normal" featureName="AsmEventFilter" maxRuns="0"> <Arguments></Arguments> </ScannerInfo> --><ScannerInfoname="NetIsoScanner"path="NetIsoScanner.exe"persistent="false"frequency="PT12H"firstRunDelay="PT18M"priority="normal"maxRuns="0"featureName="NetIsoScanner"><Arguments></Arguments></ScannerInfo><ScannerInfoname="MsSenseS"path="WDATPLauncher.exe"persistent="true"frequency="PT0S"firstRunDelay="PT15M"priority="normal"maxRuns="0"featureName="WDATP"isPilot="true"><Arguments></Arguments></ScannerInfo><ScannerInfoname="ProcessInvestigator"path="PILauncher.exe"persistent="false"frequency="PT1H"firstRunDelay="PT3M"priority="normal"maxRuns="0"featureName="ProcessInvestigator"><Arguments></Arguments></ScannerInfo><ScannerInfoname="ShavaVulnScan"path="ShavaVulnScan.exe"persistent="false"frequency="PT8H"firstRunDelay="PT10M"priority="normal"maxRuns="0"featureName="OffNodeVulnScan"><Arguments></Arguments></ScannerInfo><ScannerInfoname="SqlVaScanner"path="SqlVaWrapper.exe"persistent="false"frequency="P1D"firstRunDelay="PT30M"priority="normal"featureName="SqlVaScanner"maxRuns="0"><Arguments></Arguments></ScannerInfo></Scanners></AsmScannerConfiguration>

• 示例：篇幅有限，可能无法做到全部的分析，这里就拿系统基线扫描来做一个样例，进行深入详细的分析，系统基线才利用基线扫描工具DSCLauncher.exe根据AzureBaseline.json来进行扫描，下面是AzureBaseline.json的一个例子；

"Id":"{9c2bc3d1-8668-48e5-ac5f-281718d52174}","OriginalId":"{7e27cc78-4b24-4c02-bd6c-0c615778bbf8}","SchemaVersion":"2","Name":"AzureWinBaselineInternal","Version":"4.9.0","Rules": [ {"RuleId":"{f520c2de-12a8-4e86-867d-b76c596a1cb8}","AZID":"AZ-WIN-00099","Name":"Audit Application Generated","Description":"This subcategory reports when applications attempt to generate audit events by using the Windows auditing application programming interfaces (APIs). Events for this subcategory include:\n– 4665: An attempt was made to create an application client context. \n– 4666: An application attempted an operation: \n– 4667: An application client context was deleted. \n– 4668: An application was initialized. \nRefer to the Microsoft Knowledgebase article “Description of security events in Windows Vista and in Windows Server 2008” for the most recent information about this setting: http:--support.microsoft.com-default.aspx-kb-947226.","Severity":"Critical","Vulnerability":"","Impact":"","DataSourceType":"Audit","DataSourceKey":"{0CCE9222-69AE-11D9-BED3-505054503030}","ExpectedValue":"Success and Failure","RemediateValue":"Success and Failure","Remediate":"false","ValueType":"AUDITPOLICY","AnalyzeOperation":"GREATEROREQUAL","Categories": ["Logging & Auditing","Advanced Audit Policy Configuration-Object Access" ],"Filter": ["OSVersion = [WS2008, WS2008R2, WS2012, WS2012R2, WS2016]","ServerType = [Domain Controller, Domain Member, Workgroup Member]" ],"Enabled":"true","Alertable":"false" },

重点看一下Rules规则这里（顺便看一下Azure基线管理的整个逻辑）：

RuleId：规则的ID；

AZID：Azure内部定义的ID，笔者看到这里大胆的进行了猜测，整个Microsoft公司的其他部门也会维持对应的操作系统版本的检测ID；

Description：针对哪些进行检测，主要是范围；

Severity：优先级或者说重要程度；

ExpectedValue：期望配置的日志过滤，例如这里是Success And Failure；

Catagories：规则的分类；

Filter：过滤的条件，就是采集的范围在哪里，例如Windows Server 2012上的Domain Controller、Domain Member、Workgroup Member等机器；

Enabled：是否开启这条规则；

Alertable：是否产生告警；

下面还是整理梳理一个表格来看到底基线配置这一项采集了哪些内容：（备注：Windows日志编号采集详情这块可以在https://www.manageengine.com/products/active-directory-audit/kb/object-access-events/event-id-4668.html来进行详细的排查）；

• Azure Geneva覆盖范围：Azure平台所有服务器包括Linux和Windows服务器，本次重点分析了Windows服务器（证据：All servers are configured to log all exceptions and security-relevant events.）

• Azure云平台威胁检测-分析平台Kusto

• Kusto SIEM分析平台：笔者经过长时间的跟踪和分析，发现Azure提供的Azure Data Explorer服务最为相似。

如上图所示，首先需要增加Cluster，按照之前分享的内容，就是把各种数据统一存储到Azure Storage上，每个产品线都会有对应的采集，例如Skype、Azure产品等，提供给对应的云服务产品的部门来进行业务上的统计和查询，安全来做整体的Threat Hunting和对应的威胁检测；

• Kusto SIEM分析规则：

• 确定威胁检测模型：

• 管理员操作：包含操作系统管理员、服务管理员、网络管理员的异常行为以及非白名单登录的行为等告警；OnIdentity系统也会跟威胁检测联动，利用SACLs对高敏感高价值文件的访问进行的异常行为；

• 基线配置：Azure SDL人员要审核的基线配置异常告警；

• Crash进程：之前提到过会使用Waston来针对Crash的进程进行分析；

• 恶意软件：针对操作系统上的恶意软件行为进行分析；

• 异常进程：针对异常的进程进行分析和反入侵行为的检测；

• 网络连接：针对异常进程产生的恶意网络连接进行模型分析；另外只要是Azure云平台上跑的所有服务的进程的网络访问都会被记录下来，便于后续进行分析；同时Azure云平台网络存在Network Baseline（基线）网络访问，如果不在Network Baseline中的访问进行告警，后续应急响应团队进行分析；这里就跟后续的架构设计有关系了，默认情况下SDN的网络防火墙防护策略是默认禁止的，按需进行开放访问；

• 云产品服务威胁检测：Azure通过iFX注入框架来收集服务对应的日志，针对云产品服务进行威胁检测，大家可能砌块Azure如果推动全部的服务接入iFX的，其实还是很简单的，都是通过SDL团队的强力推动和标准化的制定和落地推进覆盖量的；

• 合规检查：应对合规SOX、SOC 2等等外审和内部审计的合规性检查，对于提取证据来说就非常简单和方便了；

• 推测的威胁检测模型：

• UEBA：推断Azure内部采用了UEBA的相关模型来发现Insider Threat（内部威胁），例如下图所示的针对高敏应用进行对应的UEBA模型的分析；

• Mitre ATT&CK：其实读者肯定很纳闷，为啥不针对Mitre ATT&CK框架进行大写特写，笔者角度的观点是觉得适合自己的威胁检测体系和框架就好了，解决问题的方案和框架并且适合自己才是站得住脚的，不过中立角度来说，Azure内部推断也进行了对应的Mitre ATT&CK对应模型的涵盖；

• AI&ML：Azure内部笔者推断还是有很强大的AI&ML机器学习框架的，明显可以看到的就是Azure Sentinel和Jupyter完美结合的NoteBooks，笔者在多个场合提到过这个才是要重兵投入的Cloud SIEM AI&ML的技术方向，主要的点是用微软的这句话还是打动了笔者的：Jupyter 扩展了数据集执行的操作范围。 它将完整的可编程性与用于机器学习、可视化效果和数据分析的大量库集合组合在一起，这些属性使 Jupyter 成为安全调查和搜寻的引人注目的工具，很明显AI&ML、可视化以及Jupyter成熟的大量的库都是优势；

• 实时流式查询（LiveStream）：相信国内外很多云安全厂商都用了实时的流式查询进行实时的分析和威胁检测模型，笔者曾听到微软整个集团使用了几十万+的实时计算服务器集群，让告警可以做到近乎秒级，如果真是这样的程度，那还是非常令人流口水的资源投入和能达到的可怕的效果；

• 威胁情报整合（CTI）：上一篇已经提到过了再次啰嗦一下：威胁情报交换（Threat Intelligence Exchange）服务。它从各个Microsoft团队和各个第三方收集威胁数据（僵尸网络IP，恶意文件的Hash等），然后将这些数据共享给Microsoft团队，以便Microsoft团队可以在自己的产品和服务中采取对应的威胁消除和阻止行动。例如，Office 365经过分析和收集的情报确定某个特定IP属于某个僵尸网络。然后，他们与Interflow共享该信息，然后共享给对应的Office 365团队，以便该团队可以对IP进行阻断和禁止访问的动作；当然这些情报笔者推测会应用到了整个Azure云产品服务上；微软也会跟全球顶尖的威胁情报厂商合作，共享情报，用于内部情报的持续威胁检测效果保障；

• 内部数据格式标准化：Azure与 开源安全事件元数据 (OSSEM：https://ossemproject.com/intro.html) 一起合作，把内部的数据标准和元数据进行了很好的数据格式化标准，这一点也非常重要的，另外CyBOX笔者也发现是一个非常不错的威胁检测数据模型框架；

• Azure云平台威胁检测-应急响应平台（SOAR）

利用上面的威胁检测模型进行告警之后，会利用Kusto SIEM工具把攻击自动化同步到ServiceNow平台，另外Azure应急响应平台做的比较好的是进行了有效的事件响应分级策略，第一层：C+AI SOC人员会按照标准手册《Security Troubleshooting Guides》来进行标准化动作处置和响应，第二层：高优先级告警IPS或者AAA高危事件会直接同步给二线（Tier 2）处理，二线（Tier 2）如需要协作会同步给三线；第三层极其高危的安全事件例如Malware等直接交由三线（Tier 3）处理；

• Azure云平台威胁检测-分析层次和方法

第一层是Ingestion层，对应的Raw Event告警信息；

第二层是Filter层，根据安全研究来进行对应的过滤和威胁检测的模型；

第三层是Enrich层，针对上下文和行为进行检测；

第四层是Profile层，用户和对应的实体检测；

第五层是Correlate层，针对MITRE ATT&CK来进行关联分析；

第六层是Trigger层，产出异常告警；

• Azure云平台威胁检测-组织协调团队

• 组织主要是虚拟团队（Virtual Security Detections Service Teams）协作；

• 云产品服务团队（Services Team）负责一线的事件确认工作

• SOC团队（C+AI SOC Team）对安全威胁检测结果兜底和负责，内部协作分成Tier 1、Tier 2、Tier 3三层组织架构；

• 微软威胁检测中心团队（Microsoft Threat Intelligence Center Team）负责整个外部威胁的分析和同步内部；

• Microsoft Security Response Center（MSRC）：负责沟通、协调、处理外部白帽子上报的高危安全漏洞；

• Cyber Defense Operations Center：主要负责告警后的事件运营和防御；

• Azure Security Monitoring Team：负责监控整个云平台基础设施的安全，同步安全事件到SOC中心；

• Azure Security Incident Response (SIR) Team：负责针对云平台基础设施安全事件之后的应急响应、调查等工作；

• Microsoft Azure LiveSite (WALS) Team：负责网络安全事件和异常的事件响应和调查；

• Patch Triage Team：补丁修复推进团队；

• Vulnerability Management team：针对Azure云平台的漏洞进行全生命周期的管理；

• Azure Networking Team：网络团队负责响应和处理网络相关的安全事件；

• Core Services Engineering and Operations (CSEO) Software Licensing Service (SLS) team And Governance team：用来保证Microsoft使用的源代码的合规和安全管理；

• Azure云平台威胁检测-MOC（微软运营中心）

最后上三张图感受一下微软安全运营中心7X24，多地运营的实景图；

总结

说实话笔者写的过程中，查询资料的过程，看人家建设的过程和思考的维度，让笔者的实际水平又提升了很多，当然读者应该也应该能看到其实整个Azure云平台威胁检测的体系并没有完全的梳理到100%的清晰程度，笔者觉得把60%的一篇文章推送业界，业界如果有好的反响和反馈，一起来完善和发声整个云平台的安全性，那是笔者最最最愿意看到的一个场景。

笔者希望通过Azure云平台威胁检测的思路和体系化的思考以及人员的布局，数据的标准采集的项能跟业界各位专家多多交流，努力达到互相提升。因行文水平有限，时间仓促，如有不足请业界专家多多指点、指教、反馈，形成良好的行业交流渠道和深度。如有问题、错误和互相深入交流的请联系微信：ThreatSource。

再次感谢大家的阅读。

声明：本文来自鸟哥谈云安全，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。