Microsoft 的安全相关资源整理


=Start=

缘由:

前两天在朋友圈里看到一个介绍Microsoft的网络安全架构体系的解读文章,才知道Microsoft很早并且经常性的在分享它在企业安全、云安全方面的一些实践和经验(我的眼界和见识还是短了)。虽然它这么做的一个初衷在于推广自家的云Azure和其它安全产品,但对于普通安全从业人员以及想系统性学习和了解网络安全体系、策略和实施路线等知识的人来说,Microsoft提供的这些资源非常有用且宝贵一般人是没有机会接触和了解大企业是如何做安全的,以及安全的最佳实践该是什么样——这些内容由Microsoft/Google/Amazon等顶级公司来定义和描述才足够可信和可靠,因为它们在公司发展壮大的过程中会面临各种各样的安全风险,它们有足够的动力和资源来应对/缓解这些风险,它们对安全的理解程度远比一般公司要深入。求其上,得其中;求其中,得其下;求其下,必败。想要学习提高就要挑好学习的目标,否则学习效果可能不达预期)。

正文:

参考解答:

这篇文章仅列出我近期在看且觉得很有参考价值的文档链接和概要,一方面原文(英文好的建议直接看英文文档,中文文档的部分内容是由机器翻译,可能会影响你对内容的理解)内容更多更全,不同经验的人能获取到的信息很可能不一样;另一方面原文是在不断更新的,且更新频率还挺高,看原文能获取到最新的信息。

1-零信任

为何采用零信任

当今组织需要一种新的安全模型,以更有效地适应复杂的现代环境、支持混合工作场所,以保护任何位置的用户、设备、应用和数据。尤其是在疫情的阴云还未消散,远程办公既是一种趋势、更是一种现实的情况下。

  • 随时随地高效工作
    使用户能够随时随地在任何设备上更安全地工作。
  • 云迁移
    通过智能安全性实现数字转型,以适应越来越复杂的环境。
  • 风险缓解
    消除安全漏洞,使横向移动的风险降至最低。
零信任原则
  • 进行显式验证 – Verify explicitly
    始终基于所有可用数据进行身份验证和授权,包括用户身份、位置、设备运行状况、服务或工作负载、数据分类以及异常情况。
  • 使用最少特权访问 – Use least privileged access
    通过即时(JIT,just-in-time)和最小可用访问权限(JEA,just-enough-access)、基于风险的自适应策略以及数据保护来限制用户的访问,以帮助保护数据并保障生产力。
  • 假定已经泄露 – Assume breach
    最小化泄漏影响半径并对访问权限进行分段。验证端到端加密,并通过数据分析获取可见性,促进威胁检测并增强防御。
微软对于零信任的定义

零信任模型假定已经泄露(而不是假定公司防火墙背后的所有内容均安全)并将每个请求都视为源自开放网络。零信任教导我们,无论请求源自何处或不管访问何种资源,都应坚守“永不信任,始终验证”的原则。每个访问请求在授予访问之前都应进行完整的身份验证、授权和加密。应用微分段和最少特权访问原则以最大限度地减少横向移动。利用丰富的智能和分析进行检测并及时响应异常情况。

零信任的覆盖范围
  • 身份-Identities
    对你的所有数字资产应用强身份验证方式来验证和保护每个身份。
  • 终端设备-Endpoints
    要获得可入网设备的相关信息。在授予访问权限之前,确保是合规和安全运行的状态。
  • 应用-Apps
    发现影子IT,确保合适的应用程序权限,访问要基于实时分析,并监控和控制用户的行为。
  • 数据-Data
    从基于边界的数据保护转变为数据驱动的保护。使用程序/人工智能对数据进行分类和标记。根据组织策略加密和限制数据访问。
  • 基础设施-Infrastructure
    使用遥测技术来检测攻击和异常,自动阻止和标记危险行为,并采用最小特权访问原则。
  • 网络-Network
    确保设备和用户不会仅仅因为在内部网络上而受到信任。加密所有内部通信,通过策略限制访问,并使用微分段和实时威胁检测。

2-Microsoft 安全最佳实践

治理、风险和合规 – Governance, risk, and compliance

安全操作 – Security operations

身份和访问管理 – Identity and access management

网络安全 – Network security and containment

特权访问 – Privileged administration

人为操作的勒索软件 – Ransomware and extortion

信息保护和存储 – Information protection and storage

应用程序和服务 – Applications and services

3-Azure 安全基准 (v3)

ASB 控制领域说明
网络安全性 (NS)网络安全包含用于保护 Azure 网络的控制措施,包括保护虚拟网络、建立专用连接、阻止和减少外部攻击以及保护 DNS。
身份管理 (IM)标识管理包括用于使用 Azure Active Directory 建立安全标识和访问控制的控制措施,其中包括使用单一登录、强身份验证、用于应用程序的托管标识(和服务主体)、条件访问和帐户异常监视。
特权访问 (PA)特权访问包括用于保护对你的 Azure 租户和资源的特权访问的控制措施,包括一系列用于避免管理模型、管理帐户和特权访问工作站面临有意和无意的风险的控制措施。
数据保护 (DP)数据保护涵盖控制静态数据保护、传输中的数据保护以及通过授权访问机制实现的数据保护,包括使用 Azure 中的访问控制、加密以及密钥和证书管理来实现对敏感数据资产的发现、分类、保护和监视。
资产管理 (AM)资产管理包括用于确保 Azure 资源安全可见性和治理的控制措施,包括以下几方面的建议:安全人员的权限、对资产清单的安全访问,以及管理对服务和资源的审批(盘点、跟踪和更正)。
日志记录和威胁检测 (LT)日志记录和威胁检测涵盖了用于检测 Azure 上的威胁以及启用、收集和存储 Azure 服务的审核日志的控件,包括使用控件启用检测、调查和修正过程,以利用 Azure 服务中的本机威胁检测生成高质量的警报;它还包括使用 Azure Monitor 收集日志,使用 Azure Sentinel 集中进行安全分析、时间同步和日志保留。
事件响应 (IR)事件响应包括对事件响应生命周期(准备、检测、分析、包含和事后活动)的控制措施,包括使用 Microsoft Defender for Cloud 和 Sentinel 等 Azure 服务自动执行事件响应过程。
态势和漏洞管理 (PV)状况和漏洞管理侧重于评估和改进 Azure 安全状况的控制措施,包括漏洞扫描、渗透测试和修正,以及 Azure 资源中的安全配置跟踪、报告和更正。
终端安全 (ES)终结点安全保护对终结点检测和响应的控制措施,包括在 Azure 环境中对终结点使用终结点检测和响应 (EDR) 和反恶意软件服务。
备份和恢复 (BR)备份和恢复包括用于确保在不同服务层执行、验证和保护数据和配置备份的控制措施。
DevOps 安全性 (DS)DevOps 安全性涵盖 DevOps 过程中与安全工程和操作相关的控制措施,包括在部署阶段之前部署关键安全性检查(如静态应用程序安全性测试、漏洞管理),以确保整个 DevOps 过程的安全;它还包括常见主题,例如威胁建模和软件供应安全。
治理和策略 (GS)治理和策略提供的指导可确保使用一致的安全策略和记录在案的治理方法来指导和维持安全保障,包括为不同的云安全功能、统一的技术策略以及支持策略和标准建立角色和责任。
Azure安全控制

4-如何基于 Azure 做安全

构想安全的最终状态

业务对齐(Business alignment)

  • 风险洞察: 将安全见解和风险信号/源与业务计划协调一致。确保通过可重复的过程向所有团队讲述这些见解,并使各团队负责改进。
  • 安全集成: 通过可重复的过程和组织所有级别的深层合作关系,将安全知识、技能和见解更深入地集成到业务和 IT 环境的日常运营中。
  • 业务弹性: 专注于确保组织能够在攻击期间继续运营(即使是在降级的状态),并且组织能够迅速退回到正常运营状态。

安全原则(Security disciplines)

  • 访问控制: 应用网络和标识会创建访问边界和分段,以降低任何安全违规操作的频率和范围
  • 安全操作: 监视 IT 操作以检测、响应违规操作并实现恢复。 使用数据持续降低违规风险
  • 资产保护: 最大程度地保护所有资产(基础结构、设备、数据、应用程序、网络和标识),以最大程度地降低整个环境的风险
  • 安全治理: 委托决策会加速创新并带来新的风险。监视决策、配置和数据以治理对整个环境、整个项目组合中的所有工作负载的决策。
  • 安全创新: 随着组织采用 DevOps 模型来加速创新,安全性必须成为 DevSecOps 过程不可或缺的一部分,并将安全专业知识和资源直接集成到此高速周期中。这涉及到将一些决策从集中的团队转移到以工作负载为中心的团队。
方法

风险洞察 – Risk insights
安全集成 – Security integration
业务弹性 – Business resilience
访问控制 – Access control
安全操作 – Security operations
资产保护 – Asset protection
安全治理 – Security governance
安全创新 – Innovation security
DevSecOps控制 – DevSecOps controls

5-Microsoft 网络安全参考体系结构

参考链接:

零信任
https://www.microsoft.com/zh-cn/security/business/zero-trust

安全文档
https://docs.microsoft.com/en-us/security/

Security in the Microsoft Cloud Adoption Framework for Azure
https://docs.microsoft.com/zh-cn/azure/cloud-adoption-framework/secure/

Azure 安全基准 (v3) 概述
https://docs.microsoft.com/zh-cn/security/benchmark/azure/overview

Security rapid modernization plan
https://docs.microsoft.com/en-us/security/compass/security-rapid-modernization-plan

Microsoft 安全最佳实践
https://docs.microsoft.com/zh-cn/security/compass/compass

Microsoft 网络安全参考体系结构
https://docs.microsoft.com/zh-cn/security/cybersecurity-reference-architecture/mcra
https://aka.ms/mcra

=END=


《“Microsoft 的安全相关资源整理”》 有 10 条评论

  1. A Roadmap to Zero Trust Architecture. Transform your network and modernize your security
    https://zerotrustroadmap.org/
    `
    零信任架构的7个关键组件(7 Components of a Zero Trust Architecture)

    # 用户-Users
    1. Establish a corporate identity
    2. Enforce MFA for all applications

    # 端点和设备 Endpoints and Devices
    1. Implement MDM/UEM to control corporate devices
    2. Implement endpoint protection
    3. Inventory all corporate devices, APIs and services

    # 内网流量 Internet Traffic
    1. Block DNS requests to known threats
    2. Block threats behind SSL/TLS

    # 网络 Networks
    1. Segment user network access
    2. Use Internet backbones for branch to branch connectivity
    3. Close all inbound ports open to the Internet for application delivery

    # 应用 Applications
    1. Monitor inbound emails and filter out phishing attempts
    2. Inventory all corporate applications
    3. Zero Trust policy enforcement for Applications
    ____* Publicly addressable
    ____* Privately addressable
    ____* SaaS applications
    ____* Non-browser apps (SSH, RDP, SMB, thick clients)
    4. Protect applications from Layer 7 attacks (DDoS, injection, bots, etc)
    5. Enforce HTTPS and DNSsec

    # 数据防泄漏产品和日志 Data Loss Prevention and Logging
    1. Establish a process to log and review traffic on sensitive applications
    2. Define what data is sensitive and where it exists
    3. Stop sensitive data from leaving your applications (e.g. PII, CCNs, SSNs, etc)
    4. Identify misconfigurations and publicly shared data in SaaS tools
    5. Establish a SOC for log review, policy updates and mitigation
    6. Stay up to date on known threat actors

    # 稳定状态 Steady State
    1. Employ a DevOps approach to ensure policy enforcement for all new resources
    2. Implement auto-scaling for on-ramp resources

    ==

    # 一个实现时间线举例 Example implementation timeline
    每一个零信任体系架构部署都是独一无二的,但大多数项目都遵循一组共同的步骤。对于开始零信任体系结构实现的企业来说,这是一个推荐的时间表。

    Timeline & Goal

    ## 阶段一(Phase 1) 基础

    ❑ Deploy global DNS filtering #部署全局dns监控/过滤能力

    ❑ Monitor inbound emails and filter out phishing attempts #监控入站电子邮件并找出其中的钓鱼企图

    ❑ Identify misconfigurations and publicly shared data in SaaS tools #用SaaS工具中识别错误配置和公开共享数据

    ## 阶段二(Phase 2) 基础+

    ❑ Establish corporate identity

    ❑ Enforce MFA for all application

    ❑ Enforce HTTPS and DNSsec

    ❑ Block or isolate threats behind SSL

    ❑ Zero Trust policy enforcement for publicly addressable applications

    ❑ Protect applications from layer 7 attacks (DDoS, Injection, Bots, etc)

    ❑ Close all inbound ports open to the Internet for application delivery

    ## 阶段三(Phase 3)

    ❑ Inventory all corporate applications

    ❑ Zero Trust policy enforcement for SaaS applications

    ❑ Segment user network access

    ❑ Zero Trust Network Access for privately addressable applications

    ❑ Implement MDM/UEM to control corporate devices Mac:Jamf,Kandji; Windows:Microsoft Intune

    ❑ Define what data is sensitive and where it exists

    ❑ Send out hardware based authentication tokens

    ❑ Stay up to date on known threat actors

    ## 阶段四(Phase 4)

    ❑ Enforce hardware token based MFA

    ❑ Establish a SOC for log review, policy updates and mitigation

    ❑ Implement endpoint protection

    ❑ Inventory all corporate devices, APIs and services

    ❑ Use broadband Internet for branch to branch connectivity

    ❑ Establish a process to log and review employee activity on sensitive applications

    ❑ Stop sensitive data from leaving your applications (e.g. PII, credit cards, SSNs, etc)

    ❑ Employ a DevOps approach to ensure policy enforcement for all new resources

    ❑ Implement auto-scaling for on-ramp resources
    `

  2. #39 美国防部发布网络安全零信任战略及至27年共5年roadmap
    https://mp.weixin.qq.com/s/BRJstATOOpkTTeCyEqvTTw
    `
    0、前前言
    1、 前言
    2、DoD的建设驱动力
    3、 DoD的零信任是战略/策略
    4、DoD零信任战略概览
    4.1、实现目标的4个How
    4.2、实现目标的7个What
    5、 DoD 零信任能力模型
    5.1、能力模型概览
    5.2、能力模型详细定义
    6、DoD零信任的三大阶段
    6.1、能力阶段
    6.2、财年阶段
    ==

    第一段第一句话,就说”我们的对手在我们的网络中,窃取我们的数据,并利用组织的用户。这些威胁的快速增长强调了DoD的调整和显著改进威慑战略和网络安全设施的必要性。

    第二段则说明需要以零信任”从不信任,永远验证”的心态,对设备(devices)、应用程序(applications)、资产(assets)和服务(services)负责,用户只能在需要的时候访问必要的数据。

    同时,零信任是所有人都要发挥作用的事情。

    4.1、实现目标的4个How
    DoD将How To DO的实现方法,总结了几个标准。

    3.1 Capabilities (能力)。指根据roadmap在2027年达到相关建设标准。
    3.2 Architecture(架构)。安全架构需要符合ZTA指导原则
    3.3 Interoperability(互操作性):这里更多是指协作类的。包括DoD还对Pre-ZT时代和Post-ZT时代进行了区分说明。
    3.4 Ideation/Innovation创新创意:快速试错、总结 最佳实践也非常重要。

    4.2、实现目标的7个What
    2.1、User(用户):对实体访问进行强身份认证。
    2.2、Device(设备):持续且实时识别、清点、授权、验证和修补所有设备。
    2.3、Application & workload(应用和工作负载):保护所有应用程序,包括容器和虚拟机。
    2.4 Data(数据):通过基础架构、应用程序、标准、端到端加密和数据标记保护数据透明度和可视性。
    **2.5 Network & Enviroment(网络和环境)**:通过精细的访问和策略限制 ,分段、隔离和控制网络和环境。
    **2.6 Automation & Orchestration(自动化和编排)**:通过自动化和编排的方式,使组织能够快速应用策略和发起行动。
    **2.7 Visibility & Analytics(可见性和分析)**:分析安全事件及其上下文,并通过AI/ML进行模型构建,从而能改进检测和响应

    5.1、能力模型概览
    DoD Zero Trust能力模型展开后共计7个能力领域45个能力项。

    大家从下图就可以看到,里面基本是将主流的安全能力要素(如MFA、条件访问、端点管理、XDR、微分段、远程访问、UEBA、安全编排等),全部纳入到能力模型中,可以认为这是一套适应于国家级的复杂的完整安全能力框架。
    `
    DoD Zero Trust Strategy
    https://dodcio.defense.gov/Portals/0/Documents/Library/DoD-ZTStrategy.pdf

    DoD Zero Trust Capability Execution Roadmap (COA 1) @15 November 2022
    https://dodcio.defense.gov/Portals/0/Documents/Library/DoD-ZTExecutionRoadmap.pdf

  3. 2022年安全架构总结以及2023安全方向展望
    https://mp.weixin.qq.com/s/D0mETMfF4wu_a3dSXoxIiQ
    `
    废话不多说,开始2022年总结之前,针对之前写的2021年安全架构总结和2022安全方向展望做一个简单的回顾(挑选2个总结):
    1、云上攻击会越来越深入,影响越来越大:2022年相信各位特别关心云安全漏洞的同学一定很清楚,今年Azure、AWS、Google被纰漏出大量导致数据泄露的多租户隔离和逃逸漏洞,影响范围极大,对云厂商信誉和客户的信心都造成了较大影响,其实这个趋势也是必然的,因为国家级的对抗都是随着基础设施变化而进行攻击的”进化”的,近两年上云的趋势已经非常的火爆,基本上上世界500强90%以上都已上云(多云、混合云),由于这些客户的高价值,作为国家级威胁体,会随着这些客户的上云进而研究最高安全等级云的安全,寻找安全漏洞,窃取客户的高价值数据。
    2、终端安全新赛道(”混合”办公安全):如果读者目前在做SASE、终端安全、数据安全等,就会在客户的需求中,得到对应的答案,目前各个行业的客户都在想如何利用”一站式”安全产品体系,来解决客户的数据安全问题。所以去年提出的跨平台、终端安全EDR、DLP、EPP进入融合时代是必然的,随着客户的设备的复杂性的增加,MacOS、手机端、*NIX操作系统的数据安全、反入侵等需求也呈增长态势。

    # 2022年总结-端到端身份防御架构落地

    首先讲一个场景,看看各位安全友人是不是都碰到过这种情况。自己的公司安全现状是在漏洞上投入了非常多的人力、产品,包括做渗透测试、红蓝演练,挖掘到了大量的API越权漏洞、RCE、SSRF等漏洞,但是做了特别多的事情,最终通过一个账号(身份)就把数据全部都窃取走了,包括去年提到的微软、英伟达、Uber、Okta遭受了Lapsus$的身份攻击,去年这个趋势已经非常明显了。而今年的对抗场景又进行了全新的升级,身份不管是被冒用、窃取、盗用等,是必不可少的Assume Breach的案例,由于身份的被攻破,就出现了另外一个比较严重的问题,目前很多应用层面的权限管理是非常混乱的。也就是说今年的身份对抗升级到了两种,一种是黑客入侵之后通过冒用、盗取Cookie、模拟账号准入、绕过MFA的方式持久化的维持企业的账号身份,另外一种就是利用这个身份的默认权限过大的设置,进而窃取更多的数据。
    总结一下身份的三层风险:
    1、高安全等级MFA绕过:现在暗网已经出现了一种新型的钓鱼方式和一种新型的账号买卖服务,Pishing As A Service(EvilProxy)可以模拟Microsoft、Apple、Google、Amazon等登录界面的伪造,让受害者直接登录EvilProxy的钓鱼服务,进而绕过MFA获取到登录的Cookie,并且通过持久化保持的方式,一直维持登录状态;
    2、身份伪造和冒用:黑客掌握了你账号之后,就会通过各种手段来维持这个权限,目前整个身份最薄弱的攻击点,就是用户你登录的身份之后,利用Cookie和JWT Token来维持权限,对经过验证的身份进行伪造和冒用;另外还有终极的伪造大招,就是窃取对应的JWT、Cookie的私钥,来伪造任意用户的登录,历史上俄罗斯的国家级攻击团队,就针对微软ADFS发起过Gloden SAML2的攻击,影响是毁灭性的,对整个企业造成了非常严重的影响,因为一旦拥有私钥就拥有了上帝攻击视角,可以伪造企业管理员来管理整个企业,包括ICS生产控制系统、数据窃取、企业知识泄露,这些就不在话下了;
    3、应用权限过大导致的大范围数据泄露:另外一个很普遍的事实,包括国内非常TOP的在外人看来安全性很高的企业,其实应用权限的问题也是一个泛滥的问题,默认权限就可以访问企业的敏感数据、默认的账号权限就可以访问大量内部文档、默认账号权限就可以控制生产系统,这些案例真是触目惊心,让人不寒而栗。

    在这种场景下,端到端的身份防御架构应运而生:
    1、无终端安全无入网:首先在企业内网中部署了对应的终端安全产品(EDR+DLP+EPP+AV)的统一安全架构,而且跟企业办公网络等进行打通,也就是说没有部署终端安全产品的话,是不允许准入整个企业办公网络的,这个也就形成了第一层的身份防御点,无终端准入不能入网的原则;
    2、未接入权限DNS域名配置:在讲统一接入智能网关之前还是先讲一下,接入内部应用域名的流程,首先在企业内部申请对应的域名,这个域名未来会同步到终端安全产品上,做对应的DNS导流操作;
    3、智能导流:通过终端安全的网络过滤模块,将上述的DNS的请求导到SmartGateWay智能网关上,通过智能网关接入统一的SSO身份认证能力;
    4、统一智能网关:智能网关接受终端转发过来的请求,这个时候请求第一次是不携带对应的身份的,这个时候智能网关因为没有判断到终端携带的身份属性,所以跳转到了对应的SSO登录后台,进行身份验证;身份验证过之后,可以通过终端+统一智能网关+SSO身份进行身份认证的操作了;
    5、统一智能权限网关:这个时候已经完成了对应的应用少量侵入就完成SSO统一接入的过程了(为了保证安全,后端服务要仅仅允许智能网关携带的身份访问,避免造成直接访问后台绕过智能网关的风险),接入SSO之后就可以通过统一的智能权限网关进行统一的权限收敛了,例如可以做到URL级、响应级、参数级、字段级的数据安全访问控制了,而且也能很好的在同一的地方收敛到敏感的个人信息,达到去标识化的目标。然后在业务场景上也可以做更多的限制,例如外包不能访问某些大数据平台、美国员工不能访问中国的PII数据、数据跨境的时候做对应的审计的各种业务场景了。

    # 2022总结-数据安全终极防御大招(全程票据)
    其实很多安全架构都是一点点的“进化”、升级迭代。从应用微隔离到全链路数据追踪到全程票据,都是安全架构的演进。应用微隔离主要解决的是大内网的网络横向移动的入侵爆炸半径R的范围,数据安全全链路追踪是为了看见和掌握数据流动的安全,最终的全称票据,让企业的核心数据访问全程带上访问凭证,让数据泄露的范围降低到最低,真正从安全架构层面、应用层面来解决对应的数据外泄风险。
    针对全程票据的设计细节,本篇文章也进行最核心部分的设计思路透出,让更多企业可以在核心、关键的核心基础设施应用和系统上展开落地。核心票据的架构图如下:首先从用户终端开始登录,这个时候有各种对应的身份验证手段,包括QR扫码、OAuth2认证、账号密码认证等;认证通过之后到凭证验证服务器验证凭证有效性,验证有效性之后,反馈对应的Ticket票据给到用户终端;用户终端使用Ticket票据来访问对应的中间链路的服务器,包括中间件、应用服务后台等,最终携带着Ticket票据访问核心数据服务器,核心数据服务器根据Ticket的权限和来源颁发最终登录用户自己可以访问的范围内的数据反馈到客户端,最终完成整个全程票据访问的全链路隐私和数据安全保护访问过程。

    # 2022年总结-云上Privacy By Design
    云安全的最终宿命还是最终解决客户的数据安全问题而生的。云安全发展了这么多年,从最开始的关注云产品安全(虚拟化逃逸、多租户隔离、越权等)和云上租户的安全(提供云上安全的纯净度,让整个云上客户享受云安全的福利,普惠云安全)到后来发展到关注云上数据安全(包括发展如日中天的云数据安全中心、云上分类分级、云DLP等等能力),再到现在和未来2-3年要发展的Privacy By Design默认隐私安全。这些路径的发展,其实也是有一根核心主线的。这个主线就是云上的看见能力不断提升。

    1、扩展数据源:目前云上数据安全产品的大概思路主要覆盖云上全域(包括终端例如手机,PC,服务器等、大数据包括Hadoop,云厂商自研的大数据AWS Redshift,Aliyun MaxCompute,Google Bigquery、数据类产品包括RDS,MySQL,PostgreSQL,SQL Server等、自建的各种数据存储平台、多云的、混合云)的数据采集维度作为数据源;
    2、覆盖数据安全能力:有了数据源之后开始建设各种数据安全能力,包括支持全域的数据分类分级、敏感数据识别、数据安全防护、数据脱敏、数据审计、数据访问异常等能力;
    3、满足合规和解决数据安全风险:构建这些能力,最重要的目标和目的还是解决数据安全泄露的相关风险,最终满足GDPR、个人信息保护等各种法律法规的要求;通过数据安全运营最终闭环数据安全风险;

    终局也就是说未来云上、线下、混合云、多云的各个领域的数据理论上是都会看见、保护、运营的闭环的。在未来2-3年,越来越多的云产品会支持发现个人隐私保护方面的发现能力、数据流动、数据权限开放过大而导致数据泄露的场景的覆盖。也就是说未来,企业上云之后个人隐私数据会第一时间知道在哪里保存的?保存的是否是合规的?是否有数据滥用外泄的风险?想想这样的隐私安全保护,客户的信任和数据安全风险的治理是不是上了一个更高的台阶?让Privacy By Design成为云的默认安全属性。

    # 2022年总结-数据安全顶层治理架构
    对于数据安全领域来看,很难有一套非常顶层、通用的一套数据安全治理的大图。下面的大图,我也仅仅是抛砖引玉,从我自己的角度来看一下我心目中的数据安全的大概的样子,也许不是很成熟,请大家多多指正。

    1、数据治理框架:这个不用过多的描述,相信大家比我更清楚的理解行业监管需求、国家法律法规、企业业务要求等;这里有两点要说一下,很多时候数据安全事件的处理和处置很难以奏效,或者有些时候很难在企业内部形成一致,其实这个时候红线、规范就非常重要了,红线设计的好坏直接影响到安全的信誉,以及安全在企业内部的阻力等问题,好的红线设计可以让安全水位得到质的提升,在设计安全红线的要充分考虑业务部门的感受,尤其是红线导致的奖罚措施也比较重要,要得到业务部门的充分理解和认可也是一件挺不容易的事情;第二个就是红蓝对抗,在对抗过程中会发现各种各样的安全问题,这些安全漏洞,就成为了企业数据安全治理方向的指引明灯,尤其一些企业目前建设了紫军、数据窃取蓝军、数据高仿真等岗位和角色,针对数据安全风险角度有了更多的输入,这样更有利于数据安全顶层设计的一些建设和输入;
    2、数据安全治理体系:企业安全制度制定的主要目的是有法可依,有章可循,先定好企业内部规范,在处理很多事件上会省不少解释成本。企业制度包括数据安全总章、数据分类分级标准、个人信息保护规范、数据跨境治理规范、外包管理等等内容;这里的企业安全规范治理制定的好坏的唯一评价标准,就是后续的巡检能否落地,企业的规范如果仅仅是一堆废纸,那也就失去了本来定义的价值。所以好的企业安全规范,是可以通过安全巡检能力来持续的、自动化的、不间断的验证能力和规范的水位的,例如定义了企业制度是没有终端安全不入网、DLP策略的有效性验证、数据分类分级的自动化验证、自动化的验证数据外发渠道策略是否有效、验证云盘上传可以发现,另外可以通过数据蓝军、紫军来构建“日日练”的效果。有了规范制度,也能巡检对应的安全水位了,下面要做的就是针对出现的各种问题的交付SOP了,例如数据外发策略失效了,那对应的处置手段、升级手段到底是什么?我见过好的SOP是非常详细的,可操作性极高的,而且明显可以让一线的人按照手册就可以快速解决的;最后通过不断的优化来完善整个数据安全治理体系的运转;
    3、构建数据安全能力层:通过威胁情报、数据泄露CASE输入、数据安全风险评估角度,分析出对应的数据安全风险,其实数据安全风险也会随着时间的推移而变化;有了这些输入之后,就开始构建对应的能力和解决方案,包括数据发现(分类分级、全覆盖等可参考下面的【2022总结-Privacy By Design】的思路来进行覆盖)->数据异常检测和保护->数据防泄漏;另外还有一层非常重要的身份层,可以参考【2022年总结-端到端身份防御架构落地】章节。
    4、数据安全运营:针对构建的安全能力,需要对应的数据安全运营手段来不断地分层运营,包括数据安全事件的处置、溯源,数据安全能力的推进等;
    5、度量指标:有了运营的持续运转,需要良好的度量指标体系来衡量整个数据安全的水位,这些指标是非常关键的,包括运营指标、能力指标、响应指标等各个维度的数据;数据安全度量体系是驱动整个数据安全良性运转的重要“北极星”指标,有了这些指标才能更加良好地推进数据安全往前发展。

    # 2023安全趋势展望
    1、MXDR将会扩展到Data DR+DataSecOps
    2、Data Breach Simulation需求明年会爆发:数据安全经过几年的发展,目前已经形成了相对完善的产品和解决方案体系,由于目前这两年完成了对应的初步建设,对于Data Breach Simulation(数据安全窃取模拟)的需求会增加;对于BAS厂商来说,融入DBS来检验数据安全建设水位,成为了新的方向;(演练内容包括数据安全泄露评估、数据泄露能力演练、数据加密防勒索演练、数据外泄演练、DLP渠道外泄演练、模拟窃取数据演练、大数据模拟窃取演练、内鬼分级(IT内部、财务内鬼)数据窃取演练、端到端数据泄露模拟演练、数据蓝军日日练);
    3、威胁情报(TI)+CAASM+EASM+DRPS+CTEM+BAS+反入侵分析组成新的平台
    4、应用安全平台(ASOC、ASPM)开始出现众多营收机会
    5、XSPM会成为继XDR之后的又一个爆发领域
    6、云平台安全需加大投入,预测国外TOP3的云会出现大规模数据泄露事件
    7、身份攻击会成为全球TOP One入侵原因,身份产品迎来重大机遇(黑客进入”无漏洞”【无漏洞就是利用身份+身份拥有的权限+API来进行攻击】的利用时代):去年的总结其实已经预测了对应的身份攻击会爆发,今年的众多安全事件【微软BING代码、Uber数据泄露、英伟达代码泄露、Okta入侵事件】已经暴露了众多的身份安全问题,未来这个趋势会越演越烈,预测今年身份安全产品会开始出现,围绕身份安全检测、身份异常、身份权限、身份攻击、行为检测、异常身份对抗会出现众多机会,安全厂商投入对应的技术研究和产品研发,另外客户也会在某些演习活动中感受到身份被窃取导致一些检测上的盲区进而身份领域需要增强的痛点。
    `

  4. 网络安全行业的机会:固化最佳实践
    https://mp.weixin.qq.com/s/aDTkralU-LnxjyLLpwKLWQ
    `
    当你自己是一个创业者的时候,你就能很清楚地看明白,那些所谓的合同收入甚至是利润增长都是自欺欺人的,只是一种财务统计方法,企业活不活得下来只有一条,那就是现金流。企业就跟革命先辈们抗战时的军队是一样的,要生存下来就要确保进来的比损耗的要多,才能确保可持续发展。如果把目光盯着那些数字增长,而没有解决损耗的问题,那么信号就比较危险。我们的业务也在持续增长,但是损耗的速度增长超过了收益的增长,比如人多了人均成本增加了,回款慢了,这就需要我们去思考,这种增长是否是对的,是否可持续。

    当年教员提出“独立自主的山地游击战”,就是发展群众,减少损耗,确保可持续发展,等待合适的时机,确保胜利那一天的到来。运动战还是要打,但不能老打,实际上是伤敌一百自损三百,脱离群众没有新鲜血液的注入,这么下去撑不了太长时间。不要急于一时,要耐得住性子,还没到决战的时候。我们马后炮来看,确实可以学习的有很多很多。

    **就网络安全行业而言,我觉得大量的资源人力物力都存在极大地浪费。大家做得事情千篇一律,同质化明显,效率低效果差,所以客户觉得不值钱,大部分技术产品做到最后都做成了商务活动和人工服务,赚不到钱得不到尊重。这种体力活动再干十年,这个行业也不会有任何本质的改变,一个新人不管能力多强,很快就可能会被同化。**大家得出一个结论是:这个行业就应该这么去发展,赚不到大钱是对的,公司不赚钱个人赚钱是对的,交付不好是对的因为换个团队也交付不好,新概念一天一个样是对的……

    就目前这样的市场,我估计用不了这么多人,**绝大部分的人是在做重复劳动,而且这种重复劳动并不是最佳实践,他们仅仅是因为需要有人做,具体是哪个人做以及是否是有提升空间的,这些问题在大量的人头堆积下,已经被掩盖的无影无踪**。这种模式想科技兴国怕是很难有所突破。**把大量重复工作的人用自动化的技术释放出来,让一批能力过硬的人寻找不同行业的安全场景,再寻找出来行业内的最佳实践,在此基础上进行固化和优化,才能保障行业的快速进步。**

    其实大家对最佳实践有很多误解,好像一定要多么高大上才是最佳实践,实际上任何一个细分的场景,就在我们例行的动作中,都是大量可以固化的实践。只不过考虑是不是最佳,必须有对比。对比可以是内部的对比,也可以是行业内的对比,总有好坏优劣之分,这种优劣好坏在不同的环境下可能是截然不同的相反面。

    最近我老是拿我们公司的安全部门和产品部门举例,比如安全从业人员都会做资产梳理工作,输入的是企业名称,输出的是互联网暴露面清单;还比如说做IP情报画像(溯源反制),输入的是IP列表,输出的是IP对应的价值情报信息。这是基础的不能再基础的工作内容,我相信这不仅仅是我们公司的工作,而几乎是所以安全行业甲乙方都必须具备的基础技能。一方面它们实在太简单了,没有人没做过也没有人不会,另一方面它们实在太难了,同一个工作不同的人来做,效果天地之别。为什么呢?是因为似乎做了就算有交付,除非你有行之有效的对比方法,否则很有可能一个实习生在几次忐忑交付没人提出反对意见之后,都敢于提出老子天下无敌的口号。

    **没有总结没有对比没有固化,那就是同样的基础工作,明明可以自动化的非得人工,明明可以做到更好的非要交付的稀巴烂,明明可以更加高效的非得拖延很长时间,明明可以成本很低的非得签出一堆人头**……你还别说,谁你都还动不了,这么多项目开发,你抽走一个人,项目就死给你看。于是乎人头越来越多,效果却完全没有提升,而是往失控的深渊奔去。

    **当你花了大量时间在做一件重复工作时,并且这个工作需要较长时间锻炼才能保证效果时,那就是我们需要提取最佳实践的最佳时刻。**这些最佳实践在不同的公司被视为核心竞争力,密不外传,因为想保证自己的持续领先地位。其实这些担心但是不必要的,特斯拉把所有技术开放,谷歌把核心技术思维发论文才有了后来的Hadoop等等。核心竞争力是我告诉你方法,但你短时间又学不会,比如芯片。实际上,一个更加开放的技术环境能够让国家让人类科技加速发展。你以为的最佳实践也还是最佳实践,但凡你敢拿出来秀,总有人做得比你更好,只是值不值得的问题。

    我要拿fofahub固化安全组的流程,要让研发工程师输出流程,然后跟安全组做对比。我们的CSO同学说不公平,他说安全部门总结的经验告诉研发,研发又能写工具,那么总会比现在的交付更好,双方合作就好不要对比。我听了先是一愣,然后觉得很有意思,这里面透露几个深层次的问题:一个是大家承认有很大的改进空间,无论是效果还是效率;二是对于交付到什么效果有没有尽力之前是没有做要求的;三是根本没有固化最佳实践,不同的人进来进行不同的思考,写不同的脚本工具,成长参差不齐监督效果也就参差不齐。

    **大家都觉得有更好的方式,但是大家都不觉得应该要做到最好的方式,因为投入成本太高。**嘿,这个就有意思了,假如不让你投入这种思考和开发的成本呢?也不让你投入培养的成本呢?我们把别人的最佳实践固化下来给你用呢?让每一个新入职的都能点几个按钮输出80分,你要不要?

    人类的每一次升级,就是有一些人发现了一种大家都大量遇到的场景,再结合一种成本可控的方式固化了下来,然后另一波人又找到了提升效果很多倍的方法,周而复始。每一个产品的使命如果不是某个场景下的对比最优解,那么它就是没有生存空间的。
    `

  5. Introducing Microsoft Security Copilot
    Empower your defenders to detect hidden patterns, harden defenses, and respond to incidents faster with generative AI—now in preview.
    https://www.microsoft.com/en-us/security/business/ai-machine-learning/microsoft-security-copilot

    微软:Security Copilot 的设计目的是辅助而不是取代安全分析师的工作
    https://mp.weixin.qq.com/s/QPsQpXBAhGFCBS5vql-oiQ
    `
    在宣布为 Office 应用提供人工智能驱动的 Copilot 助手后,微软现在将注意力转向了网络安全。

    (2023年)3月29日凌晨微软推出了一款新的人工智能助手,名为 Security Copilot,专门为网络安全专业人士提供帮助。这款助手可以帮助防御者识别网络入侵,更好地理解每天收集到的海量信号和数据。

    Security Copilot 的核心技术是 OpenAI 的 GPT-4 生成式人工智能和微软自己的安全专用模型。Security Copilot 看起来像一个简单的对话框,就像其他的聊天机器人一样。你可以问“我企业里有哪些安全事件?”,它就会给你一个概要。但在幕后,它利用了微软每天收集到的 65 万亿个信号,以及安全领域的专业技能,让安全专业人士能够追踪威胁。

    据悉,Security Copilot的特征包括但不限于:

    (1)更好地交互体验。Security Copilot就如同安全领域的AI小助手,可以直接询问它企业的安全隐患有哪些。

    (2)总结安全问题,并迅速响应。Security Copilot将通过总结、理解威胁情报,帮助安全团队识别恶意活动,并且能够帮助安全团队关联和梳理攻击信息,优先处理重要安全事件并推荐最佳行动方案,迅速处理各种威胁。

    (3)修复常见的安全攻击问题,Security Copilot也将与Sentinel和Defender等微软安全产品集成,能够自动阻断一些常见的安全攻击,修复错误安全配置

    Security Copilot 的设计目的是辅助而不是取代安全分析师的工作,并且还包括一个便签板功能,让同事们可以协作和分享信息。安全专业人士可以使用 Security Copilot 来进行事件调查或快速总结事件并帮助进行报告。

    Security Copilot 接受自然语言输入,所以安全专业人士可以询问某个特定漏洞的概要,输入文件、网址或代码片段进行分析,或者从其他安全工具中获取事件和警报信息。所有的提问和回答都会被保存,所以调查者可以有完整的审计记录。

    结果可以被固定和总结到一个共享的工作空间,这样同事们就可以一起进行威胁分析和调查。

    Security Copilot 最有趣的一个方面是提示书(prompt book)功能。它本质上是一组步骤或自动化功能,可以打包成一个单一的易用按钮或 prompt。比如说,可以有一个共享的 prompt 来对一个脚本进行逆向工程,这样安全研究人员就不用等待他们团队中的某个人来执行这种类型的分析。甚至可以使用 Security Copilot 来创建一个 PowerPoint 幻灯片,概述事件和攻击向量。

    就像 Bing 一样,当安全研究人员询问最新漏洞信息时,微软也会清楚地标明结果来源。微软使用了来自网络安全与基础设施安全局、国家标准与技术研究院的漏洞数据库以及微软自己的威胁情报数据库中的信息。

    但这并不意味着微软的 Security Copilot 总是正确的。“我们知道有时候这些模型会出错,所以我们提供了确保我们有反馈的能力,”微软人工智能安全架构师 Chang Kawaguchi 说,反馈循环比 Bing 上的赞或踩要复杂得多。“因为它可能有很多种错误方式,”Kawaguchi 解释说。微软将让用户回答到底哪里出错了,以便更好地理解任何错误。
    ==
    像工业革命一样,会有一部分工作被机器取代,但是也会产生一部分新职业,最终的结果是人和机器协同生产,重要的是保持学习。
    =
    保持清醒,保持学习,不要盲目焦虑,更不要消费焦虑。
    `
    微软将GPT-4引入安全领域,行业下岗潮还有多远?
    https://mp.weixin.qq.com/s/gCVHOKS3ozwHbxdUIbTlwg
    `
    微软安全执行副总裁 Charlie Bell 表示:“提升安全状态需要人员和技术——人类的聪明才智与最先进的工具相结合,有助于快速和大规模地应用人类的专业知识。” “通过 Security Copilot,我们正在建设一个未来,在这个未来中,每位防御者都将获得必要的工具和技术,让世界变得更安全。”
    `

  6. 微软数据安全防护中的几个小细节
    https://mp.weixin.qq.com/s?__biz=MzI1MjQwMTAyOQ==&mid=2247483769&idx=1&sn=334b461638c1c9bb87ca78e6870f7a60&scene=21#wechat_redirect
    `
    微软这几年在安全领域的发力是有目共睹的。包括在SolarWinds事件中的秀肌肉,和Windows Defender现在越来越牛的防护能力,传统的PC杀软市场到后面已经越来越小了。笔者最近对微软的数据安全防护体系做了一些调研,看到一些有趣的细节,决定跟大家分享下。

    微软在他的文档中针对内鬼泄露讲了以下几个场景:
    * 离职员工窃取数据策略
    * 常规数据泄露
    * 高敏人群数据泄露策略
    * 心生不满的员工进行的数据窃取
    * 安全策略违反
    * 病人数据误用
    * 离职员工安全策略违反
    * 高敏人群安全策略违反
    * 心生不满的员工进行的安全策略违反

    这里面针对内鬼泄露,微软其实着重强调了两类场景,一类是常规数据泄露,一类是安全策略违反。

    常规数据泄露应用主要是微软的DLP来发现。安全策略违反则是依赖Windows Defender的能力。如果映射到甲方安全建设中,就是一部分检测逻辑是在DLP上的,另一部分检测能力是建在EDR上的。从甲方安全映射来讲,一部分是数据安全团队在建设和运营,一部分是网络安全团队在建设和运营。所以,对于数据泄露的发现,要两边配合。又或者将网络安全建设运营的能力生成的安全策略违反告警交由数据安全团队运营,例如安全软件被禁用。

    在这两类的检测场景中,微软又将场景分别映射到了三类人群:离职员工,高敏人群和心生不满的员工。

    这里就涉及到如何界定三类员工的问题。微软提供了一个叫Connector的东西,其实就是搞个定时任务从HR系统中自动进行信息抽取,来识别这三类人群。

    其中,离职员工信息来自于HR系统中的离职信息,毕竟都有一个月的离职期。心生不满的员工则是来自于HR系统中的pip(performance improvement plan)信息,考评信息,例如被打C了,以及职位变动和薪资变动信息等,例如降薪降级。而高敏人群这里包括几种,一种是接触的数据本身敏感度非常高,例如DBA,例如财务,例如某些能直接接触敏感信息的客服,还有一些是接触数据敏感程度中等,但容易导致数据泄露的环节,例如外包。

    针对这几类人群的划分,也体现了数据安全中的一个重要原则,根据人群进行权限管控和检测。其实,前几年谈的比较火的UEBA就是这个视角。但因为融合了各种复杂的概念,还是没看到啥落地有效的东西。
    具体在进行数据安全防护系统研发时,如何与HR系统进行打通,获得标准化的数据进行实施,这里其实可以进行借鉴。

    对国内公司而言,对于自身的高敏系统,要进行梳理,针对高敏系统,单独进行数据安全策略的运维和运营。例如,对金融公司而言,需要对客户系统进行单独的策略建设。一方面,数据在系统上的增删改导出api跟用户行为需要做好映射,日志也需要记录更全。例如常规的系统日志可能只留存了accesslog,但高敏系统需要留存完整的http报文,包括cookie信息浏览器信息。甚至可能需要建设单独的埋点,来识别异常。
    `

  7. CISA零信任成熟模型2.0完整解读
    https://www.freebuf.com/articles/paper/370732.html
    `
    2021年5月,拜登签署E.O. 14028“提高国家网络安全防御能力”,要求政府所有部门必须在60天内给出实现零信任架构的计划。为此,网络安全和基础设施安全局(CISA)在2021年9月发布了零信任成熟度模型(ZTMM)1.0预览草案;近期,CISA再次发布了新版ZTMM 2.0草案,尽管该ZTMM是根据行政命令EO 14028的要求专门为联邦机构量身定制的,但所有组织都应审查并考虑采用下文中概述的方法。

    # 零信任成熟度模型解读
    ZTMM代表了跨越5个不同支柱的逐步实现零信任优化的过程,包括
    身份(Identity)、
    设备(Devices)、
    网络(Networks)、
    应用程序和工作负载(Applications and Workloads),
    数据(Data)。

    每个支柱都包含了一些横跨所有支柱的通用功能:可见性与分析、自动化与编排,以及治理。

    该模型反映了NIST SP 800-207中概述的7个零信任原则:
    1. 所有数据源和计算服务都被视为资源;
    2. 无论网络位置如何,所有通信都需要安全防护;
    3. 以会话(per-session)为单位,对企业资源访问进行授权;
    4. 按照动态策略确定资源访问权限;
    5. 企业监视和衡量所有自有和关联资产的完整性和安全姿态;
    6. 在允许访问之前,所有资源都必须经过动态、严格地认证和授权;
    7. 企业尽可能多地收集有关资产、网络基础设施和通信的状态信息,并利用这些信息来改善安全态势

    随着各机构向最佳零信任实现过渡,相关解决方案越来越依赖于自动化流程和系统,这些流程和系统更全面地跨支柱集成,并更动态地执行策略决策。每个支柱可以独立演进发展,也可能比其他支柱发展地更快,直到需要进行跨支柱的协调。然而,这种协调需要相关支柱能够在整个企业范围和环境中相互兼容才能实现,这就要求能够定义一个分步实现的零信任演进路线,以分摊成本,而非一次性全部投入。

    根据NIST提出的零信任实施步骤,各机构在投资零信任能力(包括本模型中概述的支柱和功能)之前,应评估其当前的企业系统、资源、基础设施、人员和流程,以帮助各机构识别现有能力,来支持进一步的零信任成熟度并确定优先级缺口。各机构还可以规划跨支柱协调能力的机会,以实现细粒度、最小特权访问控制并缓解额外风险。

    从传统阶段(Traditional)到初始(Initial)、高级(Advanced)和最佳(Optimal)三个阶段的ZTM之旅,将促进联邦ZTA的实施。每个后续阶段对保护能力、实现细节和技术复杂性都提出了更高的要求。
    `

  8. 微软云如何做自身安全体系建设?
    https://mp.weixin.qq.com/s/w5AT-LcgBzy0nTIVEJoYYg
    `
    第一篇:纵深防御体系去解决云上漏洞(Microsoft-Azures-defense-in-depth-approach-to-cloud-vulnerabilities)

    我们的数字世界正在发生变化,网络犯罪分子更加顽固、复杂和猖獗。随着风险的增加和威胁的加剧,信任比以往任何时候都更加重要。客户需要能够信任他们为建立和运行组织而投资的技术平台。作为最大的云服务提供商之一,我们通过帮助客户从一开始就确保安全来建立信任,并利用我们内置、嵌入式和开箱即用的云平台安全功能做更多事情。

    在 Microsoft Azure,我们的安全方法注重纵深防御,在平台和技术的设计、开发和部署的各个阶段都建立了层层保护。我们还注重透明度,确保客户了解我们如何不断学习和改进我们的产品,以帮助减轻当前的网络威胁,并为应对未来的网络威胁做好准备。

    在这篇博客中,我们将重点介绍过去、现在和未来的广泛安全承诺,以及我们认为有机会继续学习和发展的地方。这篇文章揭开了 Azure 内置安全系列的序幕,该系列由 4 个部分组成,旨在分享我们从最近的云漏洞中吸取的经验教训,以及我们如何应用这些经验教训来确保我们的技术和流程对客户的安全性。透明地分享我们的经验教训和变化是我们与客户建立信任的承诺的一部分,我们希望这能鼓励其他云提供商也这样做。

    第⼆篇:微软 Azure 安全系统以云的节奏扩大猎杀能力(Microsoft AzureSecurity 以云的节奏扩大变种猎杀能力)

    在本系列的第一篇博客中,我们讨论了我们在确保 Microsoft Azure 安全方面的广泛投资,包括 8500 多名专注于确保我们的产品和服务安全的安全专家、我们业界领先的漏洞悬赏计划、我们对安全开发生命周期 (SDL) 的 20 年承诺,以及我们对关键开源软件安全计划的赞助。我们还介绍了我们为应对不断变化的威胁环境而进行的一些更新,包括改进我们的响应流程、投资于安全多租户(Secure Multitenancy),以及将我们的变种猎杀工作扩展到包括一个专注于 Azure 的全球专门团队。在本篇博客中,我们将重点介绍变种猎杀,这是我们更广泛的整体安全计划的一部分。

    变种猎杀是一种归纳学习技术,从具体到一般。熟练的安全研究人员以新发现的漏洞为起点,寻找更多类似的漏洞,将学到的知识归纳为模式,然后与工程、治理和政策团队合作,开发整体的、可持续的防御措施。变体猎杀也关注积极的模式,试图从成功和失败中学习,但要通过真实漏洞和攻击的视角,提出这样的问题:为什么这种攻击在这里失败了,而在那里却成功了?

    除了详细的技术经验外,变种猎杀还试图了解某些漏洞出现的频率、导致漏洞逃脱SDL控制的原因、减轻或加剧漏洞的架构和设计范式,甚至是促进或抑制漏洞的组织动态和激励机制。目前流行的做法是进行根本原因分析,寻找导致漏洞出现的唯一原因,而变种猎杀则试图找到所有的诱因。

    微软SDL等严格的合规性计划定义了总体范围和可重复流程,而猎取变体则提供了更快响应环境变化的灵活性。在短期内,猎取变体通过更快地提供云服务的主动和被动变更来增强SDL计划,而从长远来看,它为持续改进提供了必要的关键反馈回路。

    第三篇:微软 Azure 安全演进:拥抱安全多租户、保密计算和 Rust

    在关于 Azure 安全性系列的第一篇博客中,我们深⼊探讨了我们应对云漏洞的深度防御方法。在第二篇博客中,我们重点介绍了使用变体猎杀来检测整个服务中的漏洞模式。在本篇中,我们将介绍我们改变游戏规则的赌注,这些赌注将使我们能够在未来数年内提供具有内置安全性的行业领先安全架构,确保客户获得安全的云体验。我们将讨论我们对安全多租户的关注,并分享我们利用机密计算和 Rust 编程语言的力量保护客户数据免受网络威胁的愿景。通过对安全多租户、保密计算和 Rust 编程语言等突破性安全策略的投资,Azure 为客户提供了强大的内置安全措施,不仅保护了他们的数据,还增强了整体云体验,使客户有信⼼安全地创新和发展业务。

    第四篇:不断学习,不断适应:解读 Azure 的持续⽹络安全演进。

    在关于 Azure 安全性系列的第一篇博客中,我们讨论了我们处理云漏洞的方法。在第二篇博客中,我们重点介绍了使用变体猎取来检测模式并增强整个服务的安全性。在该系列的第三篇博客中,我们介绍了改进内置安全性的颠覆性架构。在本篇中,我们将分享我们的集成响应策略,该策略提供了一个持续学习模型,利用大数据改进响应、检测、预防性控制和治理,以衡量和提高有效性。
    `

  9. Tag: Azure Built-In Security
    https://azure.microsoft.com/en-us/blog/tag/azure-built-in-security/

    Microsoft Azure’s defense in depth approach to cloud vulnerabilities
    https://azure.microsoft.com/en-us/blog/microsoft-azures-defense-in-depth-approach-to-cloud-vulnerabilities/

    Microsoft Azure Security expands variant hunting capacity at a cloud tempo
    https://azure.microsoft.com/en-us/blog/microsoft-azure-security-expands-variant-hunting-capacity-at-a-cloud-tempo/

    Microsoft Azure security evolution: Embrace secure multitenancy, Confidential Compute, and Rust
    https://azure.microsoft.com/en-us/blog/microsoft-azure-security-evolution-embrace-secure-multitenancy-confidential-compute-and-rust/

    Always learning, always adapting: Unpacking Azure’s continuous cybersecurity evolution
    https://azure.microsoft.com/en-us/blog/always-learning-always-adapting-unpacking-azures-continuous-cybersecurity-evolution/

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注