【THM】Security Principles(安全原则)-学习

本文相关的TryHackMe实验房间链接：https://tryhackme.com/room/securityprinciples

本文相关内容：了解安全三元组以及常见的安全模型和原则。

介绍

网络安全已成为一个流行词；每家公司都声称其网络产品或网络服务是安全的，但事实上真的是这样吗？

在我们开始讨论不同的安全原则之前，了解我们要保护我们的资产免受其攻击的对手(即恶意攻击者)至关重要。你是否试图阻止幼儿使用你的笔记本电脑？或者你是否想保护一台包含价值数百万美元的技术设计的笔记本电脑？对幼儿和工业间谍行为者使用同样的精确保护机制是荒谬的。因此，了解我们的对手是必须的，这样我们才能了解他们的攻击并开始实施适当的安全控制。

不可能做到完美的安全；没有任何解决方案是 100% 安全的。因此，我们只能试图改善我们的安全状况，使我们的对手更难获得访问权限。

本文的学习目标是：

• 解释安全功能：机密性、完整性和可用性 (CIA三元组-Confidentiality, Integrity and Availability)。
• 呈现安全三元组的对立面，与CIA对立的是：泄露, 篡改和破坏/拒绝(DAD-Disclosure, Alteration, and Destruction/Denial)。
• 介绍安全模型的基本概念，例如 Bell-LaPadula 模型。
• 解释安全原则，例如纵深防御、零信任以及信任但验证。
• 介绍 ISO/IEC 19249。
• 解释漏洞、威胁和风险之间的区别。

CIA三元组

在我们将某事物描述为 安全 之前，我们需要更好地考虑安全的构成因素。当你想要判断系统的安全性时，你需要从安全三元组的角度进行思考：机密性、完整性和可用性（CIA）。

• 保密性/机密性(Confidentiality)：确保只有指定人员或接收者才能访问数据。
• 完整性(Integrity)：旨在确保数据不能被更改；此外，如果发生任何改变，我们都可以检测得到。
• 可用性(Availability)：旨在确保系统或服务在需要时是可用的。

让我们考虑一下网上购物下订单时的CIA安全三元组情景：

• 保密性/机密性：在网上购物期间，你希望仅向处理付款的实体透露你的信用卡号。如果你怀疑你的信用卡信息会泄露给不受信任的一方，你很可能会避免继续交易。此外，如果数据泄露导致包括信用卡在内的个人身份信息泄露，相关公司也将在多个层面上遭受巨大损失。
• 完整性：填写网上购物订单后，如果攻击者可以更改你提交的送货地址，那么包裹将可能被发送给其他人；所以如果数据完整性得不到保护，你可能会不愿意向该卖家下订单。
• 可用性：要在网络上下购物订单，你至少可以成功浏览某商店的在线网站或者使用其官方的应用程序。如果相关的网络服务不可用，你将无法在线浏览产品或者下购物订单。如果你持续面临此类技术问题(在线商店本应提供的网络服务变得不可用)，你可能最终会放弃并开始寻找其他的在线商店进行网络购物。

让我们考虑一下CIA与患者记录和相关系统的关系：

• 保密性：根据现代国家的各种法律，医疗保健提供者必须确保和维护医疗记录的保密性；因此，如果医疗服务提供者非法泄露患者的医疗记录，他们将被追究法律责任。
• 完整性：如果患者记录被意外或恶意更改，可能会导致错误的治疗方案，进而导致危及生命的情况；因此，如果不确保医疗记录的完整性，相关系统将毫无用处，并且可能有害。
• 可用性：当患者前往诊所跟进其医疗状况时，系统必须可用；系统不可用意味着医生无法访问患者的记录，因此就无法知道当前的任何症状是否与患者的病史有关，这种情况会使得医疗诊断更具挑战性且容易出错。

企业组织在考虑上述三个安全功能时的侧重点不必相同，例如大学的公告：尽管它们通常可以不具备很好的保密性，但是在保证文件的完整性这方面还是至关重要的。

超越CIA三元组

超越CIA三元组更进一步，我们可以想到：

• 真实性(Authenticity)：真实意味着没有欺诈或伪造，真实性是指确保文档/文件/数据确实来自其所声称的来源。
• 不可否认性(Nonrepudiation)：否认意味着拒绝承认某事的有效性，不可否认性将确保原始来源不能否认它们是特定文档/文件/数据的来源，这一特性对于网络上的购物、患者诊断和银行业务等各个领域都是不可或缺的。

以上这两个安全要求密切相关，区分真实文件/订单与虚假文件/订单的需求是必不可少的，此外，确保对方不能否认自己是消息来源对于许多系统的可用性也是至关重要的。

在网上购物时，根据你的业务，你可能会容忍尝试以货到付款的方式交付T恤，但后来你又发现收件人从未下过这样的订单；然而没有一家公司能够容忍运送1000辆汽车后发现订单是假的。以购物订单为例，你想要确认该客户确实下了这个订单，这就是在要求信息的真实性；此外，你要确保他们不能否认下了这个订单，这就是不可否认性。

作为一家公司，如果你收到1000辆汽车的发货订单，你需要保证这个订单的真实性；此外，相关的消息来源也不应否认下过这样的命令。如果没有真实性和不可否认性，很多业务就无法进行。

Parkerian Hexad 帕克六元组

1998 年，Donn Parker提出了Parkerian Hexad帕克六元组，即一组六个安全元素：

1. Availability 可用性
2. Utility 实用性
3. Integrity 完整性
4. Authenticity 真实性
5. Confidentiality 保密性/机密性
6. Possession 支配权，控制权

我们在上文内容中已经涵盖了上述六个要素中的四个，所以让我们继续讨论剩下的两个要素：

• 实用性(Utility)：实用性侧重于信息的有用性。例如，用户可能丢失了用于访问具有加密存储内容的笔记本电脑的解密密钥。尽管用户仍然拥有其磁盘完好无损的笔记本电脑，但是他们无法访问它们。换句话说，虽然信息仍然可用，但其形式是无用的，即没有了实用性。
• 支配权，控制权(Possession)：此安全要素要求我们保护信息免遭未经授权方的获取、复制或控制。例如，恶意攻击者可能会拿走备份驱动器，这意味着只要他们拥有该驱动器，我们就失去了对信息的支配权；或者，恶意攻击者可能会使用勒索软件成功加密我们的数据，这也会导致我们失去数据的支配权。

答题

单击“查看站点”并回答五个问题。最后获得的flag是什么？

THM{CIA_TRIAD} 。

DAD三元组

恶意攻击者可以通过多种方式使得系统的安全性遭受攻击，这些攻击可以通过泄露秘密数据、更改数据或销毁数据来实现。

• 泄露(Disclosure)：与保密性相违背；换句话说，泄露机密数据将构成对信息机密性的攻击。
• 篡改/变更(Alteration)：与完整性相违背；例如，支票的完整性是必不可少的。
• 破坏/拒绝(Destruction/Denial)：与可用性相违背。

CIA三元组的对立面是DAD三元组：泄露、变更和销毁(破坏)。

考虑前面的患者记录和相关系统的示例场景：

• 泄露：与大多数现代国家一样，医疗保健提供者必须对医疗记录进行保密处理。因此，如果恶意攻击者成功窃取到其中一些医疗记录并将其转储到网上以供公开查看，那么相关的医疗保健提供者将因这种数据泄露攻击而蒙受巨大损失。
• 篡改/变更：如果攻击者设法修改患者的医疗记录，请考虑这种情况的严重性；这种数据篡改攻击可能会导致错误的治疗方案，因此，这种篡改攻击可能会危及患者的生命。
• 破坏/拒绝：请考虑医疗机构完全无纸化办公的情况，如果攻击者设法使得医疗机构的数据库系统不可用，那么相关的网络设施将无法正常运行；虽然医疗机构可以暂时回到纸上办公的模式，但是，很多保存在数据库中的患者记录将变得不可用，这种拒绝服务攻击将使得医疗机构的整个网络基础设施瘫痪。

防止泄露、篡改和破坏/拒绝是非常重要的，这种类型的保护相当于在努力维护信息的机密性、完整性和可用性。

最大限度地保护机密性和完整性可能会限制可用性，而最大限度地提高可用性又可能会导致机密性和完整性的丧失；所以，良好的安全原则能否得到实施需要CIA三元组三者之间的平衡情况。

答题

攻击者设法访问客户记录并将其转储到网上，这种攻击是什么？

Disclosure-信息泄露

攻击者能够找到主电源系统和备用电源系统并将其关闭，结果导致整个公司的网络被关闭，这种攻击是什么？

Destruction/Denial-破坏/拒绝

安全模型的基本概念

我们已经了解到，安全三元组的代表是机密性、完整性和可用性(CIA)。有人可能会问，我们应该如何创建一个可以确保具备一项或多项安全功能的系统？答案是使用安全模型。在本小节中，我们将介绍三个基本的安全模型：

• Bell-LaPadula Model ：贝尔-拉帕杜拉模型；
• The Biba Integrity Model ：毕巴完整性模型；
• The Clark-Wilson Model ：克拉克-威尔逊模型。

Bell-LaPadula Model 贝尔-拉帕杜拉模型

Bell-LaPadula模型旨在通过指定三个规则来实现保密性/机密性：

• 简单安全属性(Simple Security Property)：该属性被称为“不可向上读取-no read up”，它指出较低安全级别的主体无法读取较高安全级别的对象，此规则可防止用户访问超出授权级别的敏感信息。
• 星级安全属性(Star Security Property)：该属性被称为“不可向下写入-no write down”，它指出较高安全级别的主体无法写入较低安全级别的对象，该规则可以防止敏感信息被泄露给安全级别较低的主体。
• 任意安全属性(Discretionary-Security Property)：此属性使用访问矩阵来允许读取和写入操作，下表显示了一个访问矩阵示例，它可与前面两个属性结合使用。

Subjects	Object A	Object B
Subject 1	Write	No access
Subject 2	Read/Write	Read

前两个属性可以被概括为“向上写，向下读”。你可以与安全级别较高的人员共享机密信息(向上写)，并且可以从安全级别较低的人员处接收机密信息(向下读)。

Bell-LaPadula 模型存在一定的局限性，例如，它并不是为处理文件共享而设计的。

Biba Model 毕巴模型

Biba 模型旨在通过指定以下两个主要规则来实现完整性：

• 简单完整性属性(Simple Integrity Property)：该属性被称为“不可向下读取-no read down”，较高完整性主体不应从较低完整性对象处读取内容。
• 星级完整性属性(Star Integrity Property)：该属性被称为“不可向上写入-no write up”，完整性较低的主体不应写入完整性较高的对象。

这两个属性可以概括为“向上读，向下写”，这与贝尔-拉帕杜拉模型相反，这并不奇怪，因为一个关心机密性，另一个关心完整性。

Biba 模型存在一定的局限性，例如它不能处理内部威胁(insider threat)。

Clark-Wilson Model 克拉克-威尔逊模型

克拉克-威尔逊模型旨在通过使用以下概念来实现完整性：

• 约束数据项(CDI-Constrained Data Item)：这是指我们要保护其完整性的数据类型。
• 无约束数据项(UDI-Unconstrained Data Item)：这是指 CDI 之外的所有数据类型，例如用户和系统输入。
• 转换程序(TPs-Transformation Procedures)：这些程序是编程操作，例如读和写，并且应该保持CDI的完整性。
• 完整性验证程序(IVP-Integrity Verification Procedures) ：这些程序可以检查并确保 CDI 的有效性。

在这里，我们只讨论了三种常见的安全模型；如果有需要的话，你还可以继续探索许多其他的安全模型，例如：

• Brewer and Nash model：布鲁尔和纳什模型
• Goguen-Meseguer model：戈根-梅塞格尔模型
• Sutherland model：萨瑟兰模型
• Graham-Denning model：格雷厄姆-丹宁模型
• Harrison-Ruzzo-Ullman model：哈里森-鲁佐-乌尔曼模型

答题

单击“查看站点”并回答四个问题。最后获得的flag是什么？

THM{SECURITY_MODELS} 。

Defence-in-Depth(纵深防御)

纵深防御(Defence-in-Depth)是指建立多层次的安全体系；因此它也被称为多级安全。

我们考虑以下类比场景：你有一个上锁的抽屉，用于存放重要文件和贵重物品，尽管抽屉已锁，但是，你是否希望此抽屉锁成为小偷和贵重物品之间唯一的屏障？如果我们考虑多级安全，我们更希望抽屉被锁，相关的房间被锁，公寓的大门被锁，大楼大门也被锁，甚至你可能想让沿途都有一些用于安全保护的摄像机。尽管这些多重级别的安全措施仍然无法保证能够100%阻止所有窃贼，但是它们可以阻止大多数窃贼并且可以减慢窃贼的侵入速度。

ISO/IEC 19249标准

国际标准化组织(ISO-International Organization for Standardization)和国际电工委员会(IEC)创建了 ISO/IEC 19249标准。

在本小节中，我们将简要介绍 ISO/IEC 19249:2017 信息技术 - 安全技术 - 安全产品、系统和应用的架构和设计原则目录；本小节的目的是更好地了解国际组织将教授哪些关于安全原则的内容。

ISO/IEC 19249列出了五项架构原则：

1. 域分离(Domain Separation)：每组相关组件都被分组为一个实体，组件可以是应用程序、数据或其他资源；每个实体都有自己的域，并被分配一组通用的安全属性，例如x86处理器的权限级别：操作系统内核可以在ring 0(最高特权级别)中运行；相反，用户模式应用程序可以在ring 3(最低特权级别)中运行。在Goguen-Meseguer(戈根-梅塞格尔)模型中就包含了域分离原则。
2. 分层(Layering)：当系统被构造为许多抽象级别或层时，就可以在不同级别上实施安全策略；此外，验证操作也是可行的。例如具有七层网络的OSI模型，OSI模型中的每一层都为其上方的层提供特定的服务，这种分层使得我们可以实施相应的安全策略并轻松验证系统是否按预期工作。另一个例子是编程领域的磁盘操作，程序员通常会使用所选的高级编程语言提供的磁盘读写函数，编程语言隐藏了低级系统调用，并将它们呈现为更加用户友好的方法。分层原则与纵深防御密切相关。
3. 封装(Encapsulation)：在面向对象编程(OOP)中，我们隐藏低级实现并通过为此目的提供特定方法来防止直接操作对象中的数据。例如，如果你有一个时钟(clock)对象，你将提供一个方法increment()而不是让用户直接访问seconds变量，目的是防止变量的无效值。同样，在较大的系统中，你将使用(甚至设计)一个适当的应用程序编程接口(API)，你的应用程序将使用它来访问数据库。
4. 冗余(Redundancy)：这一原则用于确保信息的可用性和完整性。有很多与冗余相关的例子。考虑具有两个内置电源的硬件服务器的情况：如果一个电源出现故障，系统仍可继续运行。考虑具有三个驱动器的 RAID 5 配置：如果一个驱动器发生故障，则使用其余两个驱动器让数据仍然可用。此外，如果其中一个磁盘上的数据被不当更改，也会通过奇偶校验被检测到，从而更好地确保数据的完整性。
5. 虚拟化(Virtualization)：随着云服务的出现，虚拟化变得更加普遍和流行。虚拟化的概念是在多个操作系统之间共享一组硬件。虚拟化提供沙箱功能，可改善安全边界、安全引爆和观察恶意程序。

ISO/IEC 19249教导了五项设计原则：

1. 最小权限(Least Privilege)：当你回答“谁可以访问什么？”这个问题时，你也可以将其非正式地表述为“need-to basis(必需的基础)”或“need-to-know basis(需要知道的基础)”。最小权限原则告诉我们，你应该为 某人执行其任务 提供最少的权限，仅此而已。例如，如果用户需要能够查看文档，你应该授予他们读取权限，但不应该授予写入权限。

2. 攻击面最小化(Attack Surface Minimisation)：每个系统都可能存在攻击者可能用来破坏系统的漏洞。其中一些漏洞是已知的，而另一些漏洞是尚未被发现的。这些漏洞代表了我们应该尽量减少的风险。例如，在加固Linux系统的其中一个步骤中，我们将禁用任何我们所不需要的服务。

3. 集中化参数验证(Centralized Parameter Validation)：许多威胁是由于系统接收输入导致的，特别是来自用户的输入。某些无效输入可被攻击者用于利用目标系统中的漏洞，例如拒绝服务和远程代码执行。因此，参数验证是保证系统状态正确的必要步骤。考虑到系统处理的参数数量，参数的验证应该集中在一个库或系统中。

4. 集中化常规安全服务(Centralized General Security Services)：作为一项安全原则，我们的目标应该是集中所有安全服务。例如，我们将创建一个用于身份验证的集中式服务器。当然，你也可以采取适当的措施来确保可用性并防止产生单点故障。

5. 为错误和异常处理做准备(Preparing for Error and Exception Handling)：每当我们构建系统时，我们都应该考虑到错误和异常确实可能会发生并且可能即将发生。例如，在网上购物应用程序中，客户可能会尝试订购缺货的商品，此时数据库就可能会过载并停止响应Web应用程序。该原则告诉我们，系统的设计应具有故障安全功能；例如，如果防火墙发生崩溃，它应该阻止所有流量而不是允许所有流量。此外，我们应该注意错误消息是否会泄露我们认为是机密的信息，例如转储包含与其他客户相关的信息的内存内容。

tips：need-to-know basis，知情权原则——只有在必要的情况下才有权知道某些信息 的原则。

答题

参考本小节内容中的ISO/IEC 19249五项设计原则回答以下问题，根据设计原则的数字，回答 1 到 5 之间的数字。

当你关闭对业务不重要的不安全服务器时，你应用的是哪条设计原则？

2(攻击面最小化)

贵公司雇用了一名新的销售代表。当公司告诉你只允许销售代表访问公司的产品和价格信息时，应用的是哪一条设计原则？

1(最小权限)

在阅读 ATM 的相关代码时，你注意到有大量代码用于处理网络断开和电源故障等意外情况，这应用的是哪条设计原则？

5(为错误和异常处理做准备)

零信任vs信任但要验证

信任是一个非常复杂的话题；事实上，没有信任我们就无法运转网络应用。如果有人认为笔记本电脑供应商在笔记本电脑上安装了间谍软件，他们很可能最终会选择重建系统。如果人们不信任硬件供应商，他们就会完全停止使用它。如果我们从业务层面考虑信任，事情会变得更加复杂；所以我们需要一些指导性的安全原则。

我们将介绍以下两个与信任相关的安全原则：

• Trust but Verify 信任但验证
• Zero Trust 零信任

信任但验证：这一原则告诉我们，即使我们信任一个实体及其行为，我们也应该始终进行验证，这里的实体可以是用户或系统。在进行验证时通常需要设置适当的日志机制，"执行验证"表示将检查日志以确保一切正常。事实上，我们不可能验证所有的事情；想想审查单个实体所采取的所有操作（例如单个用户浏览的互联网页面）所需的工作。这就需要自动化的安全机制，例如代理、入侵检测和入侵防御系统。

零信任：这一原则将信任视为一种漏洞，因此，它能应对与内部人员相关的威胁。在将信任视为一种漏洞之后，零信任原则将试图消除这种漏洞，它间接地教导我们“永远不要相信，永远要验证”。换句话说，每个实体都被认为是敌对的，除非另有证明。零信任原则不会根据设备的位置或所有权而直接授予设备信任，这种方法与信任内部网络或企业所拥有的设备的旧模型形成鲜明对比。零信任原则要求我们在访问任何资源之前都需要进行身份验证和授权。因此，如果发生任何违规行为，若实施了零信任架构，相关损害将得到更大程度的遏制。

微分段(Microsegmentation)是可用于构建零信任架构的一种实施方法，它是指一个网段可以小到一台主机的设计，此外，不同网段之间的通信需要满足身份验证、访问控制列表检查和其他的安全要求。

在不对业务产生负面影响的情况下，我们可以应用的零信任程度是有限的；然而，这并不意味着我们不应该应用它(只要它是可行的)。

威胁与风险

我们需要注意以下三个术语以避免发生理解上的混淆。

• 脆弱性(Vulnerability，即漏洞)：脆弱性是指容易受到攻击或损坏，在信息安全中，脆弱性(漏洞)就是弱点。
• 威胁(Threat)：威胁是与此弱点或漏洞相关的潜在危险。
• 风险(Risk)：风险涉及威胁行为者利用漏洞的可能性以及由此对业务造成的影响。

概念类比：由于玻璃的材质特性，门窗由标准玻璃制成的展厅存在弱点或漏洞；因此，这个展厅就存在玻璃门窗被打破的"威胁"；展厅所有者应该考虑"风险"，即玻璃门窗被打破的可能性以及由此对业务造成的影响。

考虑另一个与信息系统直接相关的例子：你在一家医院工作，该医院使用特定的数据库系统来存储所有医疗记录。有一天，你在关注最新的安全新闻时，发现你所在的医院所使用的数据库系统不仅容易受到攻击(有漏洞)，而且网络上还发布了相关漏洞的概念验证(POC)以及有效的恶意利用代码(EXP)；已经发布的漏洞利用代码表明相关的威胁是真实的。有了这些知识，你就必须考虑由此产生的风险并决定采取什么后续步骤来进行应对。

我们在此不详细介绍威胁和风险。

本文小结

本文涵盖了与安全相关的各种原则和概念。到目前为止，你应该非常熟悉 CIA 和DAD以及其他术语，例如真实性、否认性、脆弱性(漏洞)、威胁和风险。我们浏览了三种安全模型和ISO/IEC 19249标准。我们涵盖了不同的安全原则，例如纵深防御(多级安全)、信任但验证和零信任。

最后，值得一提的是共享责任模型，尤其是在企业、组织对云服务的依赖日益增加的情况下，往往需要从各个方面来确保适当的安全性，它们包括硬件、网络基础设施、操作系统、应用程序等。然而，使用云服务的客户根据他们所使用的云服务的不同，具有不同的访问级别。例如，基础设施即服务 (IaaS) 用户对操作系统具有完全控制（和责任）能力。另一方面，软件即服务 ( SaaS ) 用户无法直接访问底层操作系统。因此，要在云环境中实现安全性，云服务提供商和用户都必须各司其职。共享责任模型是一个云安全框架，可确保各方都了解自己的责任。