当务之急1:用上下文感知、自适应和可编程的安全平台取代一次性的安全门
完全的安全是不可能的。然而，我们现有的许多安全基础设施都是基于一次性的安全门决定，使用预定义的“坏”和“好”列表。当零日或有针对性的攻击没有预先存在的签名时，或者当坏人(和内部威胁)获得了可信的访问权限时，这种方法从根本上来说是有缺陷的。作为补偿，我们让我们的用户接受更长的反恶意软件扫描，更长的密码，以及更频繁的密码更改，徒劳地追求完美的允许/拒绝门决定。
一旦授予访问权限，安全和风险管理负责人对用户、系统和可执行代码正在做什么只有有限的可见性。缺乏对风险和信任的持续可见性，我们别无选择，只能保守，在一开始就说“不”。CARTA战略方法从一次性密集的安全门决策转向实时的、连续的、自适应的、基于风险和信任的运行时“微”安全决策。
这意味着我们可以在最初的决定上花更少的努力——这永远不可能是完美的开始——因为我们不断地评估最初决定的影响。
传统的安全基础设施是为位于企业数据中心的更静态的IT环境设计的，其重点是在最初做出允许或拒绝决定时进行密集的评估(防火墙、入侵防御系统[IPS]、反病毒、认证等)。所有这些基础设施必须能够感知上下文，并适应不同级别的风险和信任的变化。从2014年开始，Gartner率先研究使用生命周期方法构建自适应攻击保护和访问保护架构。图2关注于自适应攻击保护，或“阻止坏事发生”，而图3关注于自适应访问保护，或“让好事发生”。
图2自适应攻击保护
图3自适应访问保护
在上图中，每个图右上方的初始控制决策仍然很重要，并将继续使用额外的上下文和增强的分析方法(如基于机器学习的可执行代码分析，用于改进预防决策和自适应认证，用于改进访问决策)进行改进。然而，即使有了改进，最初的门控评估也必须假定是错误的。一旦进入，下一个阶段(上面图2和图3的右下角)必须成为我们检测过度风险的重点。具体地说，我们必须看到实体——用户、可执行文件、设备、网络连接等等——在获得访问权限后正在做什么。它的表现如何?
该实体或其行为是否代表过度风险?如果是这样，那么我们应该有能力检测它，确认它是真实的，优先考虑它并采取行动。用于允许/拒绝初始访问(右上)的安全基础设施不应该与监视持续使用模式(右下)的需要隔离开来。攻击和访问保护必须作为生命周期问题来处理——从最初的访问到正在进行的行为-直到会话结束。安全基础设施必须发展以支持这一点。简单的yes/no安全门必须演变成集成的、实时的和运行的风险和信任评估平台。例如，端点EPP产品正在添加EDR功能，网络防火墙平台正在添加网络流量分析功能，身份验证产品正在演变为自适应访问控制平台。安全闸门成为连续和可编程的安全传感器，提供运行时可见性和行为评估，并据此进行调整。可编程安全基础设施的重要性将在后面的命令中更详细地探讨。
当务之急2:不断地发现，监控，评估和优先级风险-主动和反应
传统的安全基础设施将风险和信任视为二进制和固定的，并经常从系统所有权推断信任。这无法支持数字化业务，因为在数字化业务中，IT需要随时随地提供对系统和数据的访问对于任何设备上的合作伙伴和客户，通常是我们不拥有或控制的基础设施。在数字商业的世界里，风险和信任是流动的。风险在不断产生，环境也在不断变化。我们对用户、访问我们服务和数据的应用程序或设备的信任程度也会随着行为而不断变化。
有了CARTA战略方法，我们必须为数字业务环境构建架构，在这种环境中，风险和信任是动态的，需要在执行初始评估后不断进行评估。一旦允许进入我们的系统和数据，这些实体——用户、应用程序、机器等等——将与我们的系统和数据交互，所有这些交互必须在发生时进行监控和评估，以确保风险和信任。
相对风险和信任在会话期间根据上下文和观察到的实体行为(以及根据跨会话建立的基线)动态地增加和减少。
根据观察到的模式，可以建立风险和信任的模型。如果一个实体或其行为的观察风险过高，超过信任，我们可以采取措施，要么减少风险，要么增加对该实体及其请求的行动的信任。例如，如果用户试图将异常大量的敏感数据下载到非托管设备，而这超出了我们的风险阈值，我们可以:
- 采取措施增加信任:例如，向用户发送一个更强的认证请求，以增加我们的保证用户就是他们所声称的那个人。或者，用户可以被限制只下载到一个被管理的设备。
- 采取措施降低风险:例如，在下载内容时，对内容进行数字版权管理，或者，可以完全阻止下载。
低水平的风险总是存在的——事实上，也应该存在。有了《CARTA》，我们的重点从追求完美和消除一切风险和转移到发现和消除不必要的和过度的风险。安全和风险管理的领导者必须承认并拥抱这种完美预防、完美的身份验证和坚不可摧的应用程序永远不可能。为了追求完美的安全决策，我们创建了安全和风险管理基础设施和流程，这些都是速度和敏捷性的阻碍。的确，完美是“足够好”的敌人。
通过图2和图3，我们可以清楚地看到一个共同的要求:CARTA战略方法意味着不断地评估风险和信任，甚至在新的数字业务能力可操作之前就启用自适应的安全决策。这就要求我们把情境意识原则应用到风险管理中，有效地提供“情境风险情报”。
风险管理不能仅仅是一个被动的过程(在风险已经产生之后才发现过度的风险)。通过采取风险优先级的先发制人行动，可以发现、预见、预测和评估数字业务风险，以改变组织的安全和风险态势【Digitalbusiness risks can be discovered, anticipated,predicted
表1：主动和被动的风险发现和评估
翻译上表：
安全原则 | 主动风险发现 | 被动风险发现 |
攻击保护 | •攻击者的目标是什么?威胁有多真实? •我应该如何调整我的安全姿态，以减少我暴露在威胁之下? •我能主动做些什么来改善我的攻击表面积? •我如何对脆弱性补救工作进行风险排序? •主动测试控件的意义何在?(例如，连续渗透测试、突破和攻击模拟) | •我在哪里被攻破了? ·这些攻击是真实的吗?哪些事件代表着最大的风险? |
身份和访问管理 (IAM) | •用户需要在哪里以及如何访问?(例如，对新的SaaS应用程序、BU应用程序等。) •这种访问有多普遍? •这意味着多大的风险? •如何使用控制(特权访问管理、多因素身份验证)来降低风险? •这些资源有多重要和敏感? •如何提供对给定资源的及时、刚好足够的访问? •在提供访问权限之前，我需要在多大程度上保证用户是他们所声称的那个人? | •用户访问/使用模式在哪里代表了足够的风险，需要我做出回应? 我有多确信这不是假阳性? •这个用户有多大价值?他们正在访问的系统/数据? •当前的威胁级别是什么? •是否存在跨多个用户/域的可疑活动模式? •用户访问在哪里过度许可? |
数据 | •我的企业在哪里创建敏感数据? •企业外部的敏感数据是在哪里创建和存储的? •什么被认为是“有价值的”，为什么? •如何保护敏感/有价值的数据? 风险管理好了吗? •如果服务失去，业务的哪些领域/流程对收入的影响最大? •哪些系统支持这些? | •敏感数据在哪里被错误处理? •这些数据有多敏感/有价值? 这是否代表了我需要做出回应的风险? |
业务连续性管理(BCM)/弹性 | •如果服务失去，业务的哪些领域/流程对收入的影响最大? •哪些系统支持这些? | 在可疑故障情况下: •故障确认了吗? •哪些业务流程和收入面临直接风险? 哪些系统/进程必须首先恢复? |
Source: Gartner (April 2018) | ||
新的技术类别正在出现，以解决其中一些风险可见性差距，如入侵和攻击模拟工具、敏感数据流映射、云安全态势管理和基于风险的漏洞优先级。风险是永远存在的。缺乏对风险的可见性和智能管理可能是灾难性的。规范和结构化的方法主动和被动地发现、评估和应对数字商业风险成为CARTA的当务之急。
当务之急3:在数字业务计划中尽早执行风险和信任评估
前面的要求侧重于运行时的操作安全和风险保护。然而，不断的发现和评估无论何时何地，只要创建或修改新的数字业务能力，风险就必须扩展到创建(见注释1)新的数字业务能力，例如:
- 应用、服务和产品开发
- IT支持的系统采购
- IT和BU主导的新型SaaS、平台即服务(PaaS)和基础设施即服务(IaaS)服务的消费
- 下载新的应用程序和服务，以便在本地安装
- 新运营技术(OT)和物联网设备的选择和部署
- 通过应用程序编程接口开放内部系统和数据
- 建立数字业务伙伴关系
- 数字业务交付渠道联合外包
在所有这些领域中，信息安全面临着我们在前几节中所描述的同样的问题——过度依赖一次性密集的门槛评估是非常麻烦的，在执行的时候就过时了，最终会使业务变慢。
这种评估可能包括应用程序开发中的重量级动态应用程序安全测试(DAST)和静态应用程序安全测试(SAST)，或者在采购新的IT系统时提供繁琐的“验证”清单，或者在考虑新的云服务时提供100页的调查问卷。
我们必须停止将在生产中运行时创建新的业务能力和对这些能力的保护视为单独的安全和风险问题。当新的服务/功能被请求、创建、投入运行、修改和最终退役时，这些功能的风险和信任评估应该是连续的和交织在一起的(见图4)。
图4将CARTA“左”移至DevSecOps(开发/建设)和采购(购买)
在所有这些例子中，我们需要为CARTA添加“向左移动”的能力(见注释1)，并使风险和信任评估尽可能接近新的数字业务能力的起源。这些风险和信任评估需要适应用户的世界——他们的工具和过程——而不是反过来。例如，DevSecOps自动且透明地将安全测试集成到开发人员的持续集成/持续中部署(CI / CD)管道。安全性应该努力提供指南——而不是门——让用户在其中进行创建新功能的工作。指南，或高级策略，可能包括职责分离、活动审计和日志记录、后台扫描审计和加密。只要新功能保持在指南轨道内，安全性就不会成为障碍。即使出现了过度风险的警告，也应该出现在他们的工作流程中,在DevSecOps中，在开发人员的CI/CD管道中。并且，如前所述，CARTA风险/信任评估应该是主动的(在生产前，左侧和反应性(在生产中，图4的右侧)，回答的问题类似于表2所示。
表2。主动和被动的风险/信任评估
翻译上表：
安全原则 | 主动风险发现 | 被动风险发现 |
应用安全 | •新代码/服务的漏洞在哪里? •如果使用开源软件，授权风险在哪里? •通过对新服务、数据和应用程序进行简单的威胁建模，这种业务能力可能受到哪些攻击? •我对风险真实存在的信心如何? •这种业务能力有多重要? •风险是否大到需要解决? | •运行中的应用程序的漏洞在哪里? •这些应用程序真的受到攻击吗? •风险是否大到需要我采取行动? •如果系统不能打补丁，可能会使用什么缓解控制(例如，web应用防火墙[WAFs]和入侵防御系统[IPS]，或虚拟补丁)? |
采购 | •潜在供应商的产品/服务代表什么风险? •供应商是否使用了主动的bug奖励程序? •供应商在漏洞及时披露和补丁交付方面的记录如何? | •是否发现并披露了新的漏洞? •是否存在对供应商产品的真实攻击? •流程/资产的价值如何? •谁负责跟踪OT/物联网系统中的漏洞和风险? |
数字生态 | •一个潜在的数字生态系统合作伙伴的风险有多大? •他们可以访问哪些系统和信息? | •一旦连接起来并开始运行，我的搭档的安全姿势是否改变了? •结果是什么流程/资产受到威胁?这些有多大价值? •他们联系了哪些新伙伴，这对我的风险状况有何影响? |
Source: Gartner (April 2018) | ||
这包括开发中的软件组合分析，以识别开源软件中的风险，安全评级服务，以评估数字业务伙伴的风险和信任状况，云安全态势管理产品和对第三方软件和硬件安全测试的独立认证程序的兴趣新的技术类别正在出现，以解决其中一些风险可见性差距。
我们可以使用从图4左边收集的信息来更好地在运行时提供保护
-图4右侧。改进保护的示例包括为开发中的应用程序构建白名单配置文件，以便在运行时实施，建立行为和网络连接模式，使用数字签名确保没有发生篡改，并将漏洞的知识传递给运行时安全控制(如IPS、WAFs和运行时应用程序自我保护)。
最后，安全和风险管理领导人不能假设我们会提前参与所有这些新的数字业务能力的创建。因此，我们还必须不断地监视我们没有意识到的新业务功能的创建和使用。由于这个原因，发现和基线成为关键的持续评估功能(在图2和图3的左上角)。
对于基于云的服务的消费(采用的障碍是浏览器和信用卡)来说尤其如此，这也是为什么大多数云访问安全代理(CASB)项目都是从云应用发现和风险评估开始的。
