前言
阅读这本独特的书籍，能够让你在进行进攻性安全交战时利用多种高阶技术。你将了解实际的谍报技术、操作指南和进攻性安全最佳实践，来开展专业的网络安全交战，而不仅仅是漏洞利用、执行脚本或使用工具。
本书将向你介绍基本的进攻性安全概念。重点说明了评估和道德黑客的重要性，并讨论了自动化评估技术。现代进攻性安全的现状以及面临的挑战。
这本书的作者是奥克利博士（Dr. Jacob G. Oakley），他曾在美国海军陆战队工作七年多，是美国国家安全局(NSA)下属的海军陆战队网络空间司令部作战兵种创始成员之一，之后担任海军陆战队的高级操作员和一个师的技术主管。入伍后，奥克利博士撰写并教授了一门高级计算机操作课程，最终回到米德堡的任务支持中心。后来，在解除政府合约后，他在一家私人公司为商业客户提供威胁仿真和红蓝对抗服务，并担任渗透测试的主要负责人以及渗透测试和网络运作的主管。他目前是一名政府客户的网络安全专家。奥克利博士在陶森大学(Towson University)完成了信息技术博士学位，主要研究和开发进攻性网络安全方法。他是迈克·奥利里(Mike O 'Leary)所著《网络行动，第二版》(Cyber Operations, second edition)一书的技术评论员。
系列文章目录：
开展专业的红蓝演练 Part.7：进攻性安全面临的挑战（上）
开展专业的红蓝演练 Part.8：进攻性安全面临的挑战（下）
评估范围的确定
进攻性安全评估范围的形成取决于客户和评估人员之间要评估什么以及何时执行评估。这两个属性是紧密联系在一起的，一个属性的约束会影响另一个的可行性。评估范围是“什么”在很大程度上取决于客户的感知到的或实际需求。“何时”是指执行评估的时间表和时间窗口，并受现有资源可用性的影响。影响“何时”评估的资源限制通常来自于客户的财务方面，以及红队的具体运作方式。本章将为你提供正确确定进攻性安全评估的适当范围所涉及的各个方面的知识，以及影响此过程结果的因素。
需要参与确定评估范围的人员
划分出错误的评估范围可能会破坏所有能够评估成功的机会，并且在有机红队的情况下可能会破坏组织员工之间的工作关系，在第三方供应商提供红队服务的情况下可能会破坏业务关系。有合适的人员在场或参与确定评估范围的决策是非常重要的，这样的评估才会有最好的机会满足客户的需求，并且能保证在评估资源的操作能力范围内执行评估。在一个理想的场景中，客户和供应商都有来自技术和运营或管理层的人员代表出席参与确定评估范围。
客户公司的技术人员
来自客户公司的技术代表人员一般是一些从事网络保护和网络管理工作的人。如果客户公司在确定安全评估范围过程中没有技术代表参与，那么评估范围可能不包括特定的关键点，或者可能遗漏整个组织的攻击面。如果没有这类技术人员参与，评估的商定范围也有可能包括正在开发的或对某些行动至关重要的网络部分。如果在这个阶段中没有给出正在开发中的网络，那么评估人员可能会浪费宝贵的时间和精力来测试可能完全不同或在不久的将来不存在的系统。
就我个人而言，我在评估期间以及在报告评估结果期间，花费了大量时间处理看似极具影响力的漏洞，结果在向客户汇报时，客户不认可这些漏洞，因为这些漏洞所在的系统即将下线。作为评估员，这个结果令人沮丧，也浪费了客户的资源。管理员或安全人员如果在一开始就参与评估范围的界定，提出若干数据库集群正在退役这一情况，那么评估人员就不需要浪费时间枚举这些数据库集群存在的漏洞并执行漏洞利用。
客户公司的运营人员
客户公司的运营或管理人员对于确定评估的范围同样重要。如果没有这样的投入，评估的结果可能无法为整个组织提供最好的成本效益。正如前面提到的，有时安全评估被用作获得资金或推动内部议程的杠杆。网络安全是任何现代组织都不可或缺的一部分，但它不是唯一的一部分。客户公司的存在是为了提供一个或多个职能，如果没有人在运营或管理的意义上负责引导这些职能，那么确定范围就是不负责任的。
在为大型组织提供红蓝演练安全评估服务时，我也参与过评估，在评估的过程中，评估范围由技术团队的主管提供，看起来是一些相当可疑的目标子集。本质上来说，其目的是证明组织给定子集的安全和运营人员的能力不足。作为商业环境中的第三方评估人员，我们的红队无法确定现有的评估范围是否适合整个组织。技术职能领域以外的运营或管理人员的存在可能会导致使用该评估来改进整个组织安全性的范围。
供应商公司技术人员
在确定评估范围和评估过程中同时拥有技术和非技术人员参与并不仅仅对客户有好处。让至少具有一些进攻性安全经验的技术人员，或者在形成评估的讨论过程中有一个或多个有实际经验的评估人员在场，这似乎是显而易见的。但情况并非总是如此，特别是当“红队”作为第三方服务而不是有机地提供时。有时，业务拓展或销售人员是推销并签约服务合同的人，而这往往是在没有技术人员或评估人员在场的情况下完成的，这导致评估结果面临两个主要的问题。首先，对于供应商可用的评估人员资源来说，达成的协议可能是不可行的，并且可能会给客户不现实的期望。第二，商定的评估范围可能不符合客户的最佳利益。在确定范围时，了解客户的实际需求是很重要的。如果不让红队专家参与讨论可能会导致评估范围无法满足客户需求。
供应商公司的运营人员
在有机红队（企业自建红队）和进攻性安全服务中，供应商公司也必须包括一些运营人员来参与评估工作。在一个有机红队中，评估大型组织的子集的范围可能对双方的技术人员都有意义，但是进行评估的道德黑客可能不了解大型组织的运营需求。将运营或管理人员的输入作为范围的驱动力对于确保在适合整个组织的窗口和时间表中适当地分配评估资源非常重要，而不仅仅是针对部分特定的交战过程。在商业环境中，评估的提供者将评估作为服务进行，在范围界定过程中有运营的输入同样重要。此类服务通常在较小的窗口周期中执行，评估资源可能用于多个客户。在范围界定过程中中有运营的输入可以防止一个客户的评估范围影响到其他客户的业务，也可以防止评估人员的资源被过度使用或未充分使用。
何时执行红队评估
在确定演练范围的两个属性中，范围的“何时”是最容易理解和确定的。范围界定所涉及的时间段是评估窗口，必要时还包括这些窗口的时间表。总体而言，评估窗口只是评估人员对已确定为可批准评估的目标进行攻击的时间段。在确定评估窗口时需要非常细致，在以下段落中我将讨论为何如此。
预防安全事件
红队的评估活动是为了模拟真正的攻击者，很容易被误认为是真正的攻击。为了尽量减少客户在应急响应方面浪费时间，评估窗口不仅需要包括评估活动的开始日期和结束日期，还需要包括一周中道德黑客评估活动的时间，最好细粒度到小时级。“活动”可以指人工参与的攻击、枚举和红队工具的自动化功能。如果红队安装的工具的行为类似于恶意软件，并且每小时会发出信标到外部服务器以接收命令，则应将其设置为一个在整个评估窗口内超出商定的评估时间或天数后不进行信标发送的时间表。这是评估人员经常忽略的事情，他们有时认为，如果他们当天已经停止扫描或完成了目标，那么他们就已经满足了何时他们可能会去处理有范围的项目的计划要求。
在某个案例中，一个在执行安全评估的组织看到了这样的信标活动，并认为公司已被入侵。该组织召集了高管级管理人员、安全人员和事件响应人员，并开始计划对该漏洞的公开披露以及如何减轻业务影响。但几个小时后，在通过周末深夜加班加点疯狂打电话确认发现，是红队工具在发送信标。美国的红队在欧洲的一个数据中心安装了恶意软件，从而加剧了这种特殊情况，因此该评估活动在欧洲的工作日操作时被安全人员注意到，但美国的红队成员此时正在睡大觉，一时难以联系到他们。
平衡范围属性
除了防止遇到许多挫折和资源浪费外，清楚地了解何时评估已确定的范围内的目标对于尽可能全面地满足客户需求是很重要的。被评估的内容可能会决定评估的时间表。我的意思是，客户可能会说，他们需要评估一个特定的数据中心，而团队将用八周的时间来充分评估该目标并给出评估报告，所以八周是指定的交战窗口。不幸的是，这几乎从来都不是范围界定讨论的方式。通常情况下，组织需要为四个星期的红队服务提供资源，并且希望对同一数据中心进行评估。限制因素可能是存在资金只能支付四个月的服务费用，或者由于其他义务，有机红色团队只有四个星期的窗口可用于给定的数据中心评估。
这是在“评估什么”以及“何时评估”之间发生冲突的简单示例，但这个问题与影响交战的许多复杂且困难的问题类似。在这种情况下，当评估窗口优先时，评估人员必须尽最大努力对整个数据中心进行充分的评估。考虑到时间的限制，重要的是——在确定评估范围的过程中——所有涉及的人员就评估的优先次序达成一致，并承认评估窗口并不理想，可能会对结果产生负面影响。如果不这样做，那么客户组织可能会有不切实际的期望，而红队也将自己置于失败的境地。
评估范围是什么
毫无疑问，客户组织的需求在任何交战中都是最重要的一面，当然也是影响范围形成的最重要因素。客户组织的需求决定了需要评估什么，而什么不需要评估的问题在于，在感知的和实际的评估需求中，往往存在微小的差异。这也是我们前面讨论为什么要让所有人员参与确定范围的另一个重要原因。在技术和非技术的客户和供应商人员之间进行富有成效的对话，将会确定出最合适的范围，以解决尽可能多的组织需求。客户组织必须回答几个问题，以便形成对话，从而产生与组织的实际需求和可用资源相结合的定制结果。一个理想的评估范围通过协调需求和实现它的能力，将为后续的业务合作带来最大可能的成本效益。尽管在范围讨论期间出现了许多问题，但我始终会询问以下内容以帮助阐明客户需求：
1.为什么客户要求评估？
2.客户之前是否经过测试?
3.他们的安全装置有多成熟?
评估的动机
为什么组织会有动机要求道德黑客进行安全评估，这一问题的答案有助于确定在交战过程中必须满足的需求。通常，请求进攻性安全交战是对计划的事件、预定的事件或未计划的事件的反应。第一种类型——计划内的事件——在组织的控制范围内，通常可以根据其他组织的需求和评估人员的可用性进行安排。第二种类型——预定的事件（已安排日程）——通常不受请求组织的控制，但足够一致，仍然可以围绕它们进行计划。第三种类型——计划外的事件——完全不受请求组织的控制，不仅会给范围确定阶段增加压力，还会给整个由此产生的红队交战增加压力。
计划内的事件是组织有意导致发生的事件，并且需要红队的服务。这些类型的事件可能与一些简单的事情有关，比如希望改善组织的安全状况。通常情况下，计划好的事件围绕着组织正在进行的其他项目，例如添加攻击面。这可能是添加到整个攻击面的组织的新站点、建筑物或子网。当这些事件发生时，组织最好了解清楚添加的攻击面会如何影响组织所面临的风险。这在大型组织收购较小外部机构的情况下尤其如此。在不参与站点、建筑物或网络的创建的情况下，红队可以成为理解添加外部实体对组织的安全风险意味着什么的宝贵工具。
计划内的事件还可以围绕新产品或服务的创建进行，并且可以针对组织子集（包括构成新服务的几个系统，甚至单个应用程序服务器）进行测试。在这种情况下，红队允许组织在产品或应用程序上线后供内部或客户使用之前对其进行测试。
预定的事件是由外部监管机构或拥有实体提出请求的组织所期望的事件。这些类型的事件是组织可能面临的预防、监管或合规性问题的结果。这些事件要求红队评估作为政策、程序或法律的结果，请求组织的责任。此类事件的例子是确保组织符合处理机密数据的要求、访问 HIPAA 或财务信息的程序，或允许与联邦或州政府实体合作的公司的政策。尽管在请求组织是否选择红队服务方面不受控制，但通常存在一个详细说明评估频率和方法的监管政策。当这些类型的事件要求进行评估时，需求很容易理解：红队必须帮助客户组织尽可能有效地履行义务。从客户的角度来看，通常在预定事件的演练动机中，改善安全状况是合规性的第二要务。
计划外的事件是指发生在请求组织控制之外的事件，可能会给红队交战带来困难的环境。计划外的事件可能是意外审计的结果，也可能是由诸如自然灾害等事件引起的网络和组织的变化。受到实际攻击是最不稳定的意外事件类型，导致红队评估请求被置于两种情况之一。更常见的情况是，在确定了入侵活动、结束了取证活动、完成了补救和缓解工作之后，引入了红队。在这种情况下，红队将被引入来验证组织已经就位的解决方案的有效性。一般有这类评估需求的客户希望从红队那里得到尽可能少的结果。很少有客户会希望红队尽更大努力确定黑客入侵是如何发生的，在这种情况下，客户希望红队能够发现安全防御系统尚未识别出的漏洞，并将其作为恶意攻击者获得访问权并破坏组织资产的手段。
本文翻译自：https://www.springer.com/us/book/9781484243084如若转载，请注明原文地址
如有侵权请联系:admin#unsafe.sh