一、SOC 定义

安全运营中心(SOC)对不同的人有不同的含义。有些人说他们“运行安全平台”,别人说“他们处理事件”,还有人说“他们监控网络的安全”。BTHb:SOCTH中SOC的定义为:

一个集中在单一组织中的团队，负责监控信息技术环境中的漏洞、未经授权的活动、可接受的使用/策略/程序违规、网络入侵和向网络外入侵，并为网络事件响应过程提供直接支持。

简而言之，SOC是第一道防线。这个定义包含了成功SOC的几个重要策略。首先，SOC必须处于单一的管理和报告结构下，这样它就有了清晰的权限、资金、报告和责任。其次，SOC必须了解业务和IT环境的所有方面，从最小的工作站到云中的最大超级集群。第三，SOC需要了解其运营领域(AO)、它们将如何支持业务、监视业务应用程序和基础设施。这些标准必须包括在SOC宪章中。第四，SOC预算需要足够大，以持续投资于人员和支持交叉培训，而不是超级复杂的软件。这一概念引出了第五个策略:训练并鼓励分析师保持冷静，正确解读警报及其支持数据。这要求SOC分析人员受过良好的培训。

有一点值得详细说明。SOC团队可以通过几种不同的方法来建立它的AO。SOC可以使用IT通用控制程序、公司政策/程序、来自ISO 2700X系列等标准的指导，或者遵循互联网安全中心的20个关键控制。在设计、构建、配置和操作SOC时，您需要开发一个章程和任务声明。

为了实现这些不同的策略，SOC需要知道网络、应用程序到服务器的关系、网络上正在发生的事情，并且能够确定该活动是否对组织构成了需要有效处理的足够大的风险。SOC团队不使用复杂的SIEM软件解决安全问题。他们用知识、技能和能力解决问题。复杂的SIEM工具有所帮助——但它们不是技术上的万能药。

二、SOC章程

每个安全运营中心都需要一个“章程”。SOC章程定义了SOC如何服务于业务、任务以及定义治理和操作规则，它的操作领域是什么，以及组织需要如何响应警报条件和监视SOC的执行。

请注意SOC章程与项目章程并不相同。SOC项目实施章程是授权项目开发SOC、可能实现SIEM并授权项目经理应用资源和创建SOC的正式文件。

SOC章程通常与SOC/SIEM项目实施章程同时制定。SOC章程的范围应该适当，而实现章程是项目管理协会(PMI)定义的文档。这个术语来自作为“项目构件”类型的项目知识管理主体(PMBOK)。不要混淆这两者。

三、业务价值链紧密相连

IT人员通常不接受的一个概念是业务“价值链”。价值链是一组活动，这些活动接受输入并将其转换为输出，从而为市场带来有价值的服务或产品。价值链包括:资源生成器、入站物流、制造或服务运营、营销、出站物流或服务交付，以及售后服务和支持运营。今天，价值链中很少有不依赖于某种形式的信息技术的方面，而这些信息技术必须按照IT一般控制程序进行监视和完全保护。

对于SOC，以及一般的IT，为了与业务相关并与业务沟通，他们必须了解业务如何表述，以及业务的上下文和运营概念。从形式上讲，价值链应该在市场上创造某种形式的竞争优势。

四、识别SOC的服务

安全运营中心可以为业务和IT提供许多服务。当您考虑这些服务中的每一个时，请确保将它们合并到您的SOC规划过程以及支持技能、数据源、响应模式和人员配置中，以在SOC的生命周期内实现该服务。

此外，当您的组织考虑它将为业务提供的服务时，请小心构建那些仅通过采用您能够成功交付的服务就能够成功的服务。SOC运营团队的核心服务如下所示。您的组织肯定会基于您自己的能力、资金和人员水平来实现这些服务。

监视安全状态:这是SOC的主要角色:监视安全条件、警报、安全平台的健康状况的环境，并通过组织提供各种技术解决方案进行响应。

命令功能:这可能是一个重复的活动，因为SOC协调警报响应、事件响应和取证过程。事件指挥可以是一个非常密集的过程。事件指挥意味着SOC将识别事件，与处理程序合作，协调遏制行动，协助根除工作，从事件中获取信息，并根据新发现的情报更好地实现内部系统，还可能支持推出更新或其他修复。

发起和管理事件响应(识别和补救支持):SOC的活动和检测的一个重要部分集中于基于警报和NSM工作发现和验证安全事件。SOC可能被授权从供应商、承包商、二级业务单位(SOC和IR职能之外的各种人员)发起特定的IR支持。在这些情况下，需要使用一组提供给SOC/IR团队外部的可发布数据来定义操作流程。不要做自由撰稿人，也不要在旅途中编造这些观点——要提前计划。要开始计划，请检查应用程序清单，并确定是否可以在内部处理IR支持，或者是否需要聘请第三方。如果你已经计划好了，那就用桌面练习的形式，每年至少锻炼两次。一旦稳定下来，将各种真实数据或活动组件集成到IR计划的测试中。逐步加入外部渗透测试团队，勾勒出参与结构，并对蓝队进行测试。

漏洞管理:SOC管理器可能被要求帮助甚至运行一个漏洞管理程序。SOC管理人员应该非常谨慎，不要承担SOC可能无法处理的任务:开发和部署一个双向的、全面的VA/VM程序。通过安全查找、通知、跟踪和尝试识别系统所有者和管理员，然后及时获得系统管理员和数据所有者对补救漏洞的支持，这可能是一个劳动密集型的过程。此外，一个有效的VA/VM程序需要在业务上下文和概念层中执行，这意味着程序的焦点应该遵循业务临界模型。这些都是复杂的运行一个程序,可以拉伸SOC。

取证/eDiscovery:根据SOC的规模，取证支持可以在内部进行，或者SOC可以与第三方协调和支持取证检查。组织内的eDiscovery通常使用相同或类似的工具，在收集特定于案例的信息时需要进行链托管，并且还将分析数据收集的结果。一个关键的不同之处在于，eDiscovery专注于从活动中收集特定的搜索信息，使用由人们生成和使用的数据和信息存储库。取证技术更深入，检查来自文件系统的系统构件，这些构件显示了用户与文件和数据、驻留在内存中的恶意软件或从磁盘删除的数据交互的意图。

报告:运行报告以支持遵从性需求和IT一般控制监视。运行报告以支持警报、事件和其他报告需求。响应其他数据请求。

恶意软件分析:如果SOC分析人员能够安全地恢复恶意软件样本，那么他们可能倾向于使用VirusTotal、JoeSandbox或ThreatExpert等服务执行一些轻量级的恶意软件分析。这个建议在十年前是有用的，现在已经不再被认为是最佳实践。2017年，更好的做法是通过一个建在Cuckoo沙箱上的本地恶意软件分析引擎运行样本，以防止通知攻击者，攻击者可能正在监视在线服务如何找到他们的恶意软件。这些工具允许用户上传可疑的二进制文件，然后通知是否已知错误，并提供不同级别的活动分析，如注册表更改、新服务、文件系统更改、正在使用的IP地址或查找的域名。如果分析揭示了一些可疑的东西，那么SOC分析人员将获得运营情报并能够更好地搜索安全数据。更复杂的逆向工程是一项非常专业的技能，需要为此目的设置环境。

入侵检测:在网络或主机上可以部署多个检测系统。这些检测系统(Snort、Suricata、Bro、PassiveDNS等)都需要护理和喂养，以确保正常运行。赢得预算但不维护规则集的NIDS平台并不是最佳解决方案。

通知完善和改进:对于被认为有效的警报条件，创建通知并为接收方提供足够的支持信息。

网络安全监控:NSM是基于网络级数据收集、检测、分析和升级表示入侵的指示和警告。

威胁搜索:威胁搜索是一个主动的过程，它从本质上假定存在某种形式的入侵或入侵。威胁狩猎首先产生一个破坏的假设，然后检验这个假设。它包括从纵向和总体上对流程、账户活动和事件的系统审查。威胁搜索用于检测数据挖掘带来的安全威胁、入侵、误用和破坏。

平台健康监控:监控SIEM仪表板和警报流，根据优先级对警报进行审查和处理。监控SIEM平台和其他支持数据源，以发现问题并与数据保管人合作，确保数据的可生存性。随着环境的变化，更新平台定义(资产、网络、特权用户、警报等)。包括通过检查确保事件被解析并创建新的或改进的警报来维护源数据的可用性和质量。

网络威胁情报:分析对手的能力、动机和目标。网络威胁情报(CTI)是分析对手如何利用网络领域来实现他们的目标。在考虑CTI时，应该使用多个源。并非所有的CTI来源都是相同的或提供相同程度的覆盖。此外，CTI(在我看来)还包括了解软件漏洞和现成的攻击者功能。例如，本周添加了哪些新的Metasploit漏洞?Metasploit大大简化了漏洞利用的过程，因为漏洞被封装在可重用的代码中，在您所依赖的技术中宣布#漏洞之后，新漏洞出现的速度有多快?通过了解来自IR社区(如SANS、TrustWave、IANS、FireEye、CrowdStrilce、AlienVault和EMC/RSA)的攻击工具、供应商公告和帖子，您可以构建一个非常低成本的CTI程序，然后做出购买决策。

威胁情报集成:这是一个仔细选择并将威胁情报feeds引入系统的过程，以改进警报和更好地识别可疑或恶意源、目标、域和其他模式。威胁情报来源及其提供的信息应该在检测路线图上。

策略和过程支持:许多监视控制和功能应该直接与已建立的策略和过程相关联。在实现用例时，确保SOC将如何支持PnP强制执行。更具体地说，随着这个服务领域的成熟，确保编写SoP来定义SOC将如何正确地与用户、主管、HR和法律打交道，以应对违反PnP的情况。

内部培训:铁器必须磨铁，所以SOC管理团队必须确保，当SOC发生变化时，必须对生产线人员进行培训并保持最新。例如，当一个新的数据源集成到SOC中时，所有成员都需要对数据源以及如何正确使用数据源进行简要说明。

四、SOC项目规划大纲和专业说明

“如果你计划失败，你就计划失败。”

-通常认为是本杰明·富兰克林

而不是重复BTHB:SOCTH中的任何内容，这是一个基于PMI PMBOK规划SOC的浓缩大纲。此外，不要回避使用PMI PMBOK，因为“项目经理很烦人”、“项目管理毫无用处”或“没有那么难”。一个了解如何在预算之内按时完成项目的可靠的PM是一个非常好的伙伴。这部分提供了一个没有多余的，只是事实，讨论SOC和SIEM计划。

1、开发关键业务重点是理解组织以及SOC如何支持其目标。

（1）理解组织对SOC的需求，这意味着您需要理解组织的目标和目的，通过能够阐明SOC如何保护组织生产、销售或向他人提供的服务，SOC将具有更高的可信度，与业务相关，并支持组织的使命声明。

（2）了解SOC需要解决的业务问题，以及SOC需要监控的价值链资源。您可能需要更多的以“遵从性”为重点的SOC、战术SOC、以事件为重点的SOC，或者这些的一些组合。除了一般的IT资源外，SOC还将监视价值链的几个组件。智能地针对价值链进行监控的SOC将更加成功，并且与业务相关。

（3）确定SOC的支持者。发起、构建和部署SOC可能会遇到困难。SOC经理必须确保支持者关系得到良好维护。“客户”应该想要SOC服务，而不是把它们扔到他们的膝盖上。其他业务角色将需要配备良好的人员。评估人员和监管者是“外部利益相关者”的例子，这些角色将由具有不同技能水平的审计人员担任，他们试图衡量和报告组织内的风险和合规程度。了解涉众可能会提出的问题，将为向SIEM平台报告应该实现的用例、报告和数据源提供信息。

（4）确保SOC及其支持的日志基础设施有实际的需求。准备好阐明需求，并解释员工和技术能力如何满足需求。在这里，您应该开发一个正式的业务案例。准备好证明构建SOC所需的人员、资源、访问和软件的合理性。

（5）开发关键的“安全状态”理解(“现状”与“未来”状态)。这种理解本质上是技术性的，并且与传统IT视角下的各种用例和监视需求相对应。在可能的情况下，将安全状态监视功能与价值链组件和IT General Controls程序连接起来。请参考您所在行业最适用的标准，如ISO 27002。更多信息见第241页。)

2、构建您最初的业务案例、章程、项目计划、预算请求和支持构建SOC的理由。这个过程可能需要三到八个月的努力。设计阶段，确定每个阶段的关键投入和产出，以及谁将支持每个项目阶段。

（1）定义组织的所有权、职责和SOC位置。试着找到一个能容纳两倍于第一年人数的空间，这样你就不用在第三年搬家了。

（2）确定SOC的关键角色:“架构师”、“工程师”、“分析师”、“经理”、“customer”、“sponsor”和“利益相关者”。其中一些角色几乎与PMTs PMBOK(脚注中的定义)定义的角色相同。

（3）确定相关的策略、过程和治理。审查现有的PPG并确定它们是否支持SOC。确保SOC功能集成到ITIL流程中，特别是变更管理流程中。SOC将需要使用变更的远期计划、维护窗口更新和变更成功的通知5。作为一个监控服务，SOC团队需要了解变更，这样他们就不会在变更失败时过度反应。

（4）编制必要的人员编制、培训和教育程序文件。具体的第一年计划。一旦这样做了，制定一个三年计划，并假设您将拥有高于平均水平的SOC分析师的高需求，而事件响应往往会耗尽人们的精力。注意，一个人的SOC不是SOC。通常是一个极有动力的人，他会做出英勇的行为，但最终却会精疲力竭，或者是一个人在管理一个SIEM。

（5）进行当前数据源调查。识别数据源、它们的日志配置、资产、应用程序、资产映射的应用程序、数据或日志是否适合SOC。您不应该假设每个候选数据源都得到了很好的工具化，并且具有审计SOC所需的级别。

在准备数据源调查时，请保存描述日志工作方式及其值含义的供应商和产品文档。稍后您将需要这个细节。在此过程中，您需要了解每个数据源如何向将来的SIEM提供信息:syslog (UDP或TCP)、文件写入、数据库表、SNMP陷阱等。

（6）进行环境数据库存调查(EDIS):您不仅需要源系统数据，还需要关于网络、组织、用户和应用程序的元数据。数据包括用户及其人员统计、网络地图、地址范围、正在使用的应用程序、应用程序到服务器的映射以及组织结构图。这些数据源中的许多将通过自动化向SOC和SIEM提供信息，因此确保至少为存储这些信息的系统获得“只读”凭证。

（7）在EDIS审查过程中，估计合并用例数据源的时间。

（8）在EDIS评审过程中，包括项目特定的行项目，为SOC团队开发一个简要说明，解释每个数据源字段集和字段值。

（9）支持SIEM的技术供应过程。计划两倍于你认为第一年需要的数据。

a、硬件:包括磁盘和磁盘控制器架构，受日志记录需求和SIEM平台的影响。

b、虚拟化层:现代虚拟化技术使您的SIEM虚拟化成为一个非常有吸引力的选项。在考虑此选项时，根据数据库和/或数据存储所需的IOPS来明确表示数据速度非常重要——不要假设这将由您的基础设施团队来处理。

c、日志存储体系结构、脚本和长期存储需求。对于长期存储，您确实需要空间超过速度，因为您很少会返回超过90天阈值的数据。可靠、安全、大容量的长期储存比惊人的速度更重要。高速度需要针对过去三天的日志。

d、SIEM和支持软件。请注意，大多数主要供应商都有自己的预定义项目计划来实现他们的软件，您应该充分利用这些计划。

（10）花时间在预算过程上。SIEM实际上是企业范围内的一个主要应用程序，它与任何企业项目一样需要严格的预算。这意味着先建立一个第一年的模型，然后是3年的预测，然后是5年的预测。预算开发过程的重要组成部分是开发所有权的总成本模型。您需要了解组织的技术更新模式，以便计划系统替换。您应该假设日志存储每年增长50%。

（11）应用程序和IT资源数据供应和可能的开发。在这个阶段，您将设计如何将每个应用程序和数据源集成到SOC和SIEM中。它通常涉及一些重要的定制开发工作。每个数据源都有自己的功能，需要某种形式的报警支持。

（12）为了使这个过程很好地工作，找出组织安全状态中的漏洞，并对风险进行量化。要做到这一点，请找到您的风险管理主题专家(SME)或联系人(POC)，并与他们合作。

3、审查收集第27页的主要数据来源。对于每个数据源，您都需要以下规划和实现元素:

a.识别PoC。

b.决定如何收集数据源。

c.检查当前的审计和日志配置是否合适。

d.尽可能估计数据量。

e.确定数据是否可以被修剪。

f.从数据源中整理数据字段，并制定内部SOC培训计划，使SOC所有人员都能理解数据源。

g.根据需要，实现必要的变更控制，以配置数据源向SIEM报告。

4. 构建日志体系结构、源数据收集交付、SIEM和日志部署计划。有关SIEM部署检查表的更多信息，请参见第194页。同时,简要:

a.根据与您的业务模型、独特的数据源、遵从性需求和InfoSec程序相关的用例构建的评分模型，执行软件和供应商选择。

b.审查审计立场，并为环境中提供数据的每个系统构建每秒事件(EPS)评级。然后计划50%的增长，这样你的解决方案就能经受住“事件风暴”。在配置了源系统的审计级别之后，确定EPS是非常重要的!

c.提供硬件和存储平台并实现。

d.监控数据提要、报告和系统响应时间。

e.为商品源构建数据集成计划，并仔细选择定制源。例如，ERP应用程序可能不受支持，因此您可能需要开发一个数据库查询来从审计表中提取数据、实现审计、测试、开发一种方法来将当前数据存档到历史表，并进行监视，以确保查询过程对系统的影响最小。

5. 构建用例:

a.在这本书中有整整一章是关于构建用例的。回顾所有这些材料，并将其与您选择的平台中的用例进行比较。

b.计划如何实现供应商定义的用例，因为这些用例应该提供基线覆盖率。

c.预测实现您自己的自定义用例所需的工作量和数据源。

d.从那里，对实现进行优先级排序，这样您就有了支持定义挣值的项目度量。

6. 构建您的响应流程，该流程由到达的各种数据和您的需求所支持。

a.响应过程将由您的安全程序和您正在遵循的适用标准驱动。

b.规划过程的这一部分应该回答这样的事件解决问题:“当我们从系统B获得条件A时，分析人员要做什么，系统管理员需要什么数据来解决事件?”

c.实际上，将数据拉入SIEM的过程将为SOC功能提供许多需要处理的场景。当您构建这些过程时，确保您关注的是结果——需要实现的目标是什么。

7. 构建SOC指标，如第38页SOC指标中定义的那样。

8. 建立并实施你的持续培训计划。

a.培训是一个持续的过程。SOC技能需要随着攻击者技能和判定能力的提高而提高。确保至少有两级教育的预算。为高级员工提供优质的教育，然后为初级员工提供OTJ培训，包括知识转移、短期课程和以工作技能为重点的教育。调查当地社区大学的劳动力教育计划和能力。

b.有几种开源或非常低成本的选择。考虑一下ENISA, SecurityTube, SANS Cyber Aces, Cybrary, local BSides conferences, DerbyCon, and the annual Security Onion conference作为更便宜的教育选择。

五、思考并准备好回答棘手的问题

为了资助SecOps、SIEM和SOC，您无疑将面临许多问题。以下是我多年来被问到的一些问题，经过压缩后将发表。在建立资金请求时确定答案。

1. 什么也没有发生。我们为什么要这么做?你怎么能肯定什么也没发生呢?作为一个可能的答案，试试这些。不是如果，而是什么时候。”

2. 团队将如何检测和响应安全问题、事件和数据泄漏?我们以前是怎么做的?这不正是系统管理员所做的吗?

3.该组织去年发生的事件是否产生了任何费用?病毒爆发?我们的同行和竞争对手为此付出了什么代价?

4. 有多少处于哪个“级别”的用户受到某个事件的负面影响(比如生产力下降)?

5. 你将如何衡量自己，并获得IT平衡计分卡?作为一种可能的方法，询问您是否可以在SOC charter开发过程中使用业务记分卡。

6. 团队将如何确定哪些警报条件优先于其他条件——谁赢了?(提示:与关键业务流程和收入流保护相关的资产价值)。

7. 我以为我们去年在安全上花了X。你为什么想要更多?

8. 我知道我们没有任何值得偷的东西。为什么我们需要做越来越多的安全“存根”?

9. 这些东西不是花了几百万吗?

10. 我们正在进行脆弱性评估。难道这还不够吗?如果你没有积极及时地进行补救，那么就没有。

11. 那些安全人员一直在说不，所以这次我要对他们说不。所以在那里。

12. 我们可以成功地以1/8的成本外包出去，对吧?毕竟，供应商就是这么说的。你为什么不同意他们?他们不是专家吗?

13. SOC将如何为我们解决业务问题?

14. SOC是什么样子的，第1年，第3年，第5年?

15. 我不想买更贵的安全人员，只让他们辞职。你打算如何留住员工?倦怠?摩擦?内部转移?我最近在一个安全会议上听说，当人们接受SOC工作时，他们计划在18个月内辞职。

16. 你怎么知道你已经成功了呢?SOC的成功和失败是什么样子的?(或者是大笔的证券购买?)

17. 你又和审计员谈过了吗?他们去年说过一些关于这个的事情。我买了一个新的防火墙。

18. 先给我看看剧本——你能做到吗?完成后再回来。

19. 这是外包的，是“X公司”的责任，不是我们的。我们没有责任，因为这是外包供应商的责任，而且是在云/供应商合同中。

20.你能用三分之一的钱做什么?因为我们只有这些。

21. 去年我们在SOX法案上花了350万美元。没有更多!

六、收集重要的数据源

有许多基线系统需要监控，因为它们代表了在事件中需要的关键数据源，并且支持遵从性。这是EDIS过程的一部分。这些需要收集的资料系统和数据来源至少是:

1. DNS活动，首先关注内部到外部活动(约占网络DNS请求/响应流量的8%到10%)。

2.  Windows域控制器安全日志。

3.大多数(如果不是全部)Windows成员服务器。

4.工作站上的帐户生命周期、流程执行和状态指示器。此项目最好使用Windows事件转发和事件订阅来完成，因为这是Windows中内置的本机功能，可以防止部署另一个代理。

5. 边界防火墙。至少，任何出站“拒绝”、接受和拒绝DMZ的流量以及平台更改。如果您有容量，也可以收集出站接受事件，前提是不能为通信流获得更好的数据源。例如，如果您有一个代理，如果您可以获得代理日志，您可以考虑不记录防火墙数据到/从代理。代理日志优于防火墙日志，因为它们是应用程序感知的，并且是用户可归属的，而防火墙数据通常不是用户可归属的。

6. 数据库帐户活动和帐户管理。

7. 对于Linux，至少要收集sudo、auth和authpriv日志。

8. 防病毒集中控制台数据。

9. 转发(出站)代理数据。对于代理，验证系统是否记录了用户代理、引用者、URI查询字符串和允许/拒绝决策。如果代理理解站点类型，这也很有用。

10. “在云中”编辑文档，比如谷歌的GSuite或Office 365。这意味着谁触摸了哪个文件以及如何触摸。

11. 共享存储文件系统活动，如谁触摸了哪个文件以及如何为用户和进程公开共享。

12. VPN的活动。

13. DHCP的事务。

14. 网络设备认证通常通过RADIUS或TACACS+进行。此外，网络更改检测通常来自Syslog事件。

一旦您将自己的“必须拥有”添加到此列表中，您的下一个任务就是获取每个源的每日数据量。成交量有三个因素:每天事件的平均事件宽度，以及典型的峰值或峰值时间。

七、有用的MBA概念:SWOT和PESTL

在设计、规划和构建SOC时，有两个业务管理概念可以提供帮助:SWOT和PESTL。

SWOT分析

SWOT是一种战略规划技术，用于帮助组织识别优势、劣势、机会和威胁，每个经理都应该了解这些，并准备在战略规划练习中使用。构建SOC是一项内部业务风险，受到内部和外部压力的双重影响。SWOT分析将改进您的SOC业务案例，也将帮助您进行计划，如果做得好，还可以帮助确定将对组织发起攻击的对手。下面是一个非常简短的例子，让您了解SOC项目的SWOT分析是什么样子的。

表1 SWOT分析实例

PESTL分析

PESTL(政治、经济、社会文化、技术和法律)分析是宏观经济和宏观环境因素推动组织的框架。战略管理、市场营销和业务开发团队都需要使用它，他们需要对组织在特定的业务风险中如何执行有坚实的理解。PESTL分析将帮助SOC从两个维度进行规划:组织消耗或生产的技术的变化和速度，以及组织运行和存在需要监视的立法或监管环境。

八、资助SOC

永远记住，一个组织有一个特定的使命或目标，它在使命声明中阐明了一组目标来实现它的目标。由于SOC团队很少是利润中心，它应该确保资金请求与组织和支持业务的应用程序保持一致。

理解应用程序堆栈。SOC领导团队需要了解组织是如何从其价值链中获得资金的，并相应地了解SOC可能从资本支出(CapEx)和运营支出(OpEx)中获得多少IT支出。实际上，这意味着您的团队需要一个业务应用程序的临界性清单，然后是服务器、数据库、存储和支持这些应用程序的网络连接的映射。有了这个模型，您就可以调整监控控制、功能和工具，以支持这些应用程序的可用性、完整性和安全性。您的灾难恢复计划/业务连续性计划(DRP/BCP)团队可能非常有价值，因为他们对应用程序堆栈有一个基于关键度的视图。如果你没有一个DRP/BCP团队，你可以自己构建应用程序清单，目的是将工作用于SecOps，因为它将在需要恢复事件时提供帮助。

例如，您的组织可能有一个电子商务的存在。电子商务链上有几个组件:数字店面、订单处理、向客户和供应商发送消息、WAN链接、后端数据存储、管理所有这些IT组件的员工，以及保护信用卡交易。仅在该列表中，就有数十个服务器、技术、人员和流程。因此，如果安全团队能够将监视和事件响应置于适当的位置，以便它能够在基线中检测违规行为，并确保组件正在工作，那么它就支持了公司的使命和业务销售商品和服务的能力。

确定资助SecOps的原因:资助安全操作和soc和SIEM平台所需的日志基础设施的原因有很多很多。

1、法规遵从性(HIPAA/HITECH、Sarbanes Oxley和其他)。

2、先前的事件可能会引发资金事件。

3、出于真实的愿望或恐惧反应的管理指令。

4. 您选择的标准定义了它的结构，并因此被审计，可能需要SOC和一个日志平台。

5. 给定系统中的日志是易变的。有些系统，比如Windows域控制器，只保存几个小时的日志数据，然后数据滚动并永远丢失。有些系统将数据保存在内存中、缓冲区中，当电源或电源丢失时，数据也会丢失。

6. 没有日志,你没有能力回到历史,发现问题一安全,操作,或改变有关。

7. 事实上,这是“正确的做法”。

九、安全操作中心需要成本

在构建安全操作中心时，需要考虑许多成本组件。下面是许多常见的成本组成部分。对于每种成本，在开发“构建vs.购买”分析时，请仔细分析您当前的环境。

直接成本——在这个列表下面有更多的信息。

1. 内部人员编制。一年365天，每周7天，每天24小时，至少需要5个人，使用最简单的人员配置模式。目标9名员工和1名SOC经理。

2. 厂商中立的训练。例如SANS、Security University、CompTiA CASP和ISC2 SSCP。

3.产品培训:SIEM解决方案有供应商提供的培训。

4. 工具:桌面基础设施、操作系统、Office、SIEM许可证和调查工具。

5. 订阅:soc将有几个订阅服务,特别是威胁情报服务。

6. 硬件:服务器、存储和网络基础设施。注意典型的硬件更新周期——通常是4年。

7. 取证硬件:取证硬件有独特的要求，因为这些系统通常被隔离在一个锁着的房间里的小局域网中。例如，一个名为FRED的自定义取证工作站可能要花费5000美元以上，在中央存储上存储图像可能要花费很多tb，而写阻止程序包很容易花费1000美元以上。

8. 包括年度维护的软件许可费用:软件包括SOC支持、各种管理控制台的附加许可、SIEM平台、摄取成本、取证包、PDF生成应用程序、Bl7工具和eDiscovery功能。

9. 设施:SOC室，家具，共享大格式显示器或投影仪，和接近卡或可能的生物特征门控制。此外，取证分析空间应该有自己独立的锁和接近卡控制。

10. 升级:每年升级一经常在SoW的基础上由供应商处理。

11. 供应商帮助:随着时间的推移，您将需要供应商帮助提供新的内容、改进的报告、更多的培训以及可能的升级。

间接成本:

1. 招聘成本，如构建团队，招聘和员工加薪。

2. 初始项目的SIEM选择成本，包括特定的、审查和选择主要SOC工具集的劳动成本。

3.开展对SOC人员的工作培训。注意，这将占用关键的中小企业和时间的承诺不能低估。

4. 集成新的数据源，这可能需要在平台中创建定制的数据解析器、警报和报告。

5. 定期的内部或外部审计支持。

人员成本考虑:安全操作中心需要由熟练的信息安全分析师组成。闪亮的SIEM解决方案不能解决问题，受过教育和经验丰富的人可以。自从2001年参加了InfoSec，我可以确定它就是这么简单。高技能的人可以用一个适中的产品集产生比新手用一个超级昂贵的闪亮的工具集更准确和及时的结果。

基本工资、福利和不可避免的员工流动打乱了成本模型。美国劳工统计局(US Bureau of Labor Statistics)的数据显示，信息安全分析师2016年的基本工资为92,500美元，2017年为95,510美元。如果你的内部管理费用是管理费用的30%，那么一个负担过重的职位每年的费用是124,163美元。按照这个速度，以2017年的美元计算，五个人每年需要620815美元。glassdoor.com网站2016年发布的一项研究可以帮助了解招聘环境:公司花费4000美元通过公开招聘填补一个职位空缺，有52天的空缺期，47%的候选人会拒绝最初的报价。进一步的分析发现，50%的员工离职是因为他们的经理。这些数字有助于定义如果您找不到FTE或需要替换FTE，临时承包商的成本是多少。为了将成本降至最低，应集中精力让SOC人员通过投资期，并通过尽快让他们开始处理特定SOC服务和IR任务，使他们进入回报期。

人员成本进一步受到覆盖模型的影响。如果团队使用24/7/365，那就需要4.52人，或者至少5个FTE来配备SOC的人员，并由一个人来配备设施。确实是一份孤独的工作。这一数值是基于每年8760小时、两周带薪休假和8天假期得出的，其中48.4周是工作时间，即1936年的人均工作时间。实际上，任何24小时运作的团队都应该至少安排9个人来适应假期、病假和员工流动。五个人将负责轮班，剩下的三个人将在高活动时间提供额外的保险，比如早上7点到晚上7点和周六的部分时间。这一估计中缺少的是“管理”时间的百分比。管理时间包括所有其他公司需要完成的任务，这些任务会减少实际的工作任务。

与其他技术行业相比，事故响应的燃尽率非常高。因此，通过不同的SOC服务来补偿你的SOC前线，使他们在工作职责上有差异。此外，寻找那些渴望升职，而不是每天都做同一件事的分析师。为了留住人才，SOC经理应该经常评估改变工作职责的机会。

设施/空间:大多数组织的办公空间都有每平方英尺的价格，这应该在成本结构中。例如，2016年佐治亚州亚特兰大市每平方英尺的平均成本为A类空间20.01美元，B类空间16.36美元。如果假设共享工作组区域有90平方英尺，并且有两个工作空间可供五人轮转团队使用，那么对于两个人SOC，每月的办公空间成本为2944.80美元。然而，还有其他的单个购买成本。例如，你可能想要两个大屏幕显示器和个人电脑来运行它们，所有的东西都挂在墙上。这可能是一个简单的$4,000事件成本项目。

厂商中立的正规教育:假设您能找到安全人员，您仍然可能需要在SOC操作方面对他们进行培训。截至2018年8月，SANS研究所的最佳课程之一是“SEC511:持续监控和安全操作”（Continuous Monitoring and Security Operations），并获得GIAC GMON认证。本课程涵盖了每个SOC工作人员所需的实践技能。我可以证明，完成本课程和相应验证的每个分析师的质量和速度都有可衡量的改进。2018年8月的成本为6939美元。另外，在考虑培训成本时，确保将差旅和酒店费用包括在内，并估计为18009美元。留在第六天，为SEC511硬币竞争!

产品培训:各大SIEM供应商都有一系列的产品培训课程。这些通常包括在最初的建议和实现中。新员工入职时将会有成本。为了支付费用，我申请了一个培训学分，包括升级，系统增强活动，或者添加新产品组件。

组织专项培训:在职培训是一个持续的过程。有许多研究对开发健壮的和可重用的培训的成本进行了量化。英国人才发展协会(Association for Talent development)的数据列出了43至185小时的教学演示(一门正式课程)所需的一小时授课时间，影响这一时间的因素很多。不要轻视它，也不要忽视它。为了对学习型组织及其对公司的价值有一个简明的认识，请回顾大卫·戈德史密斯在《付费思考》一书中的第七章。

桌面:分析师硬件、显示器(越多,越快乐!),监控武器,客户端软件,几十个应用程序的分析师许可证,家具,照明。想想Quad 24”或IT显示，和Ergotron类型的Quad手臂。好了!

供应商支持:为安全产品套件、用例实现和持续升级过程提供专门的供应商支持。这些支持关系通常以每小时为基础定价，每周的小时数最少。如果您的SIEM供应商收取每小时225美元的费用，并以最少4小时的时间销售这种支持安排，则每年的支持成本为46,800美元。

基础设施:后端服务器、传感器平台、网络仪表(如TAP)和多层存储。在服务器维护之前3-4个月计划一次服务器硬件更新，以确保您不会为服务器维护窗口之外的在线服务器支付额外费用。如果你需要六台服务器，每台8000美元，那么仅硬件就需要48000美元的初始资本支出。计划每年20%的维护，并在四年后更新技术。我完成的大多数SIEM实现都是使用VMware 5和6进行虚拟化的。这个模型可能非常成功——但是您需要增加管理程序的成本。当涉及到实际容量时，为您认为需要的CPU和内存分别增加2和4 GB，并仅在该服务器上虚拟化您的平台。你将获得巨大的长期利益。这些功能包括卷快照、在技术更新期间复制到新平台，以及更轻松地匹配驱动器配置的能力。

集成新的数据源:为了在新系统上线时将影响降到最低，请将SOC工程人员合并到IT供应流程中。目标是确保新的系统或主要的系统更新能够向SIEM/SOC团队提供相关的日志数据。这个人工费用应该分配给应用程序或系统，而不是SecOps，并且是SI EM生命周期中的一个循环成本项目。

内容开发:在SIEM解决方案中开发新的和细化当前用例。当前的用例也将根据来自威胁搜索团队的改进进行更新。您对输入数据、所需内容、分析、规则、通知、SOC操作和期望结果的定义越好，成本就越准确，成功的机会就越大。

SIEM软件:SIEM平台许可证通常是由规模因素驱动的。典型的因素是每秒事件(EPS)、每天GB或监控设备计数的“摄取率”。您将发现有一类与安全无关的事件，它们与真正需要的数据一起到达SIEM。根据许多因素(事件成本、处理能力、日志存储、事件宽度)，您可能希望开发分层日志记录方法。这里的成本差别很大，从每年2万美元到更高。您定义的环境越好，您从供应商那里得到的评估就越好。

SIEM软件升级:企业系统的某些升级可以通过更新过程执行，而有些则不能。根据我在5个不同平台上的经验，我建议将复杂的升级(如重大升级)外包给SIEM供应商可能更好。一个典型的SoW将是40到80个小时，按照供应商的价格加上旅行和费用。确保您与您的供应商充分研究这一点，并将至少一个年度升级事件集成到您的平台上。

审计证据支持:SOC经常被要求支持安全事件数据和事件的报告，以直接支持内部或外部审计。这一特定角色的人员配备与监管环境和审计人员提出要求的频率密切相关。要估计这一点，请确定您的组织每年响应多少次审计以及支持这些审计所需的报告。SOC团队应该始终记录他们的时间来支持审计，因为这是对业务的一种服务。如果你有重复审计与一个特定的单位，然后要求会计费用代码，以证明成本的SOC，以支持业务单位。

十、内部、外包、混合SOC

现在您已经对构建安全操作中心的成本和大多数长期因素有了一个结构化的轮廓，您可以更好地考虑外包部分或全部SOC功能的利弊。以下是一些基于经验的有关聘用外判管理保安服务供应商（Managed Security Service Provider (MSSP's)）的意见:

1. 启动时间会有影响。MSSPs实际上在您的网络上部署了部分到完整的SIEM解决方案。每个数据源都需要集成到平台中，需要部署硬件，您的组织:仍然需要定义自己的事件响应流程。

2. 一个MSSP在调查警报时只能走这么远，如果你幸运的话，MSSP可以很好地覆盖50%到70%的警报情况，并将使你的组织参与到15%的观察警报中。

3.mssp永远不会像您那样了解您的网络，而且您无法轻松量化这对其服务提供质量的影响。mssp也不太可能知道网络上发生了什么变化，因为他们很少参与更改控制。

4. mssp通过定义的SLA和报告关系与您一起工作。他们不能代替你自己的员工可以直接接触到一个系统托管一这是一个宝贵的好处有内部人员运行在一个安全操作的角色。

5. 他们对警报灵敏度和配置的看法与您不同，因为他们倾向于关注“真正的威胁”条件，而忽略或忽略许多其他条件。您对SOC的使用应该包括策略问题、威胁捕获、审计报告，以及从SIEM将消耗的大量数据中收集操作价值。

6. 如果任务不经常发生，那么有些任务应该外包，比如系统分析。然而，今天的战场空间告诉我们，我们需要的是内存映像，而不是磁盘映像。这是几乎不可能的第三方外包MSSP收集，但可能在他们的能力分析。

7. 您不能将您组织所关心的资产的安全性的责任委托给第三方，不管别人如何试图说服您您可以这么做。您可以授权进行操作，但不承担系统安全的责任。

8. 7/24/365由第三方监控比建立自己的6-8人团队的劳动力成本更低。这是无法回避的事实，如果你是被迫外包的，意识到这个论点，并想出方法来回应这个论点。

9. MSSP也可以执行系统升级，并且很可能比你做了更多的升级。将执行年度升级的一两个星期的部署成本考虑在内。

10. 最后，你从一个MSSP关系中得到了你投入到MSSP关系中的东西。如果你不投入时间，那么不要认为他们会给你一流的结果。

十一、开始狩猎

从历史上看，SOC将监视各种面向预防的系统，如果其中一个或多个平台向团队发出警报，则进行响应。然后，他们将花时间验证警报，与系统管理员、所有者或最终用户进行通信，如果情况是突发事件，他们将作出响应。

从2000年开始的“被动或被动的模式或姿势”在今天已经不再有效。今天的SOC团队需要改变他们的关注点，假设存在可能的破坏方案，变得面向检测，并主动挖掘进入他们系统的大量数据，并主动寻找入侵和不当行为的模式。先发制人的威胁搜索是SOC分析员的理想职业和技能发展路径。一旦他们了解了组织的所有数据源，知道如何处理警报，并证明他们已经建立了研究技能，利用这一点，让他们参与到威胁捕获中。根据SOC团队的操作方式，您可以让SOC分析师每周执行一天、每月执行一周，或者采取特定的狩猎路径。威胁搜索在第167页有进一步的定义，许多用例从第60页开始。

十二、SOC直接支持CSIRT功能

今天，需要开发某种形式的计算机安全事件响应小组(CSIRT)功能是不能忽视的。在许多组织或行业中，CSIRT是由特定的法规规定的。现代恶意软件猖獗、自动勒索软件、工业间谍、犯罪分子、国家一级黑客团队以及基于数字的非对称战争的其他方面，对CSIRT的需求尤其迫切。听起来很耸人听闻，不是吗?今天的网络罪犯会利用他们发现的任何弱点，从任何潜在的受害者那里提取无法追踪的数字加密货币。不管耸人听闻的程度如何，都有几个理由在您的组织中提倡和构建CSIRT功能，而这又得到了SOC功能的支持。

1. SOC提供了一种主动检测能力，应该能够及早响应并限制事件的长期影响。然后，CSIRT可以协调响应事件，以确定、控制和减少事件影响为目标。此外，CSIRT功能可以将破坏或loCs的指标返回给SOC，以便SOC可以执行历史数据分析，例如搜索与找到的IP或域名通信的内部系统。因此，一个更成熟的CSIRT和SOC团队可以利用威胁搜索功能来寻找并发现最近出现在网络上的恶意代理。

2. CSIRT影响、支持并充分利用安全支出。它有助于确保SOC工具的到位将支持事件响应和安全操作。或者换一种说法，拥有一个单一的CSIRT应该确保环境的最佳工具已经到位，可以被利用，而其他工具则可以退役，以实现美元投资的最大化。

3.与内部员工沟通时保持客观，对事件进行分类，并对响应过程进行优先排序。CSIRT需要处理的挑战之一是人员关系和保持客观性。与负责以统一和一致的方式执行公司政策和程序的人力资源职能一样，CSIRT需要客观、执行其工作以保护业务，并避免偏袒。

4. 最后,监管。业务环境中有许多方面要求具备事件响应能力。这些包括但不限于:HIPAA/HITECH# PCI DSS 3.2，以及Sarbanes Oxley合规。

十三、SOC的指标

成熟的经营单位和企业运用各种方法来衡量经营单位的效益。SOC也不例外。问题是，你如何做到这一点，并避免让员工失去动力的有害指标?

在《实用的安全度量标准》一书中。W. Krag Brotby和Gary Hinson提出了关于度量的几个关键点。它们的一些关键定义列于第1.6章:

1. 仪器:是“测量仪器”的简称，即测量仪器。

2. 测量:(动词)确定某物的一个或多个参数。

3. 度量:与一个或多个参考点有关的度量。

在第2.6节中，他们指出“拥有有效的度量标准使业务经理能够对信息安全做出理性的、明智的、甚至是站得住脚的决策。他们再也不能完全依赖信息安全专业人士或通用的良好实践标准、法律、法规的建议。”

在第3.2节中，他们声明“度量标准主要是管理的决策支持工具。好的度量标准提供了有用的、相关的信息来帮助人们——主要是，但不完全是，经理们——根据历史事件(背景)、现在正在发生的事情(包括可用的资源和约束)以及将来可能发生的事情(变化的必要性)的组合来做出决策。

有许多指标和测量,可以开发和应用于SOC。在设计度量时，有几个标准。

在开发度量标准时考虑这些标准。

1. 度量标准应该与作为业务单元的SOC的目标、目的和使命相关。这意味着你应该能够用数字描述你所做的事情，并解释你没有测量的东西。

2. 当您评估您的数据、安全用例和度量时，请确保开发一个路线图，其中包括您将度量的内容、如何捕获这些度量、与IT常规控制和安全程序的联系，以及可能的业务价值链。然后，指标可以为决策提供指导。

3.确保你所衡量的将会是一个可衡量的结果。不要为了测量而测量。每一个指标都应该告知消费者，并设法改变他们的行为，或者证明当前的行为在既定的程序中运行良好。在这里，您应该清楚地了解您期望度量的使用者基于度量所采取的任何操作。

4. 度量应该支持“控件”，因此应该与ITGC程序匹配。如果没有的话，可以参考ISO 27002之类的标准。

5. 坏数据比没有数据要好一点点。如果您没有为需要测量的数据收集任何源数据，那么就从那里开始，但不要停止。充分利用好数据。

6. 避免给分析人员带来负担，使他们需要记录过多的数据，使用一些人为的方法来跟踪他们的工作，比如使用复杂的电子表格。相反，开发方法来挖掘SIEM平台、工作流系统、开放调查编码和警报结束代码，因为它们通过警报工作。这些方法提供了一种机制经济(EoM)，因为分析人员正在使用它们自己的工具。此外，遵循EoM原则可以促使您始终利用SIEM平台的内部功能，从而降低出错的可能性。

7. 从你的业务/组织的角度讲述你的故事。讲故事时，记住听众并使用他们能理解的术语和定义是非常重要的。

8. 我想到了两个关键的缩写词:

A :聪明一点:具体、可衡量;切实可行、有时限

B: KISS，要么保持简单，山姆/苏珊。这并不意味着可爱。相反，要确保度量的名称和度量尺度是明显的。需要解释的度量标准不太可能是有效的度量标准。

9. 确定如何构建一个记分卡来度量组织的信息和技术安全状况。只要有可能，就构建一个工具来演示技术工具的工作效率。您可能不会将此工具展示给管理层，但您应该准备好展示。

表2一般SOC指标示例

事件响应指标与SOC指标不一样，因为它们在许多情况下决定警报处理的结束位置。换句话说，当SOC确定一个真正的事件时，他们将把它交给一个事件响应函数。

表3事件响应度量实例

十四、SOC培训、技能、人员配备和角色

有效的安全运营团队需要技术技能，需要具备一定的个性特征，需要按角色进行产品培训。为SOC团队配备人员是成功的关键。理解这一点很重要，即你不能“制造”忍者级别的事件处理程序和SOC分析师，他们可以实时合成十几个数据源，并在完成一周的课程并通过考试后找到“坏人”。这种技能只有在“游戏时间”中才会出现。你所能做的就是培养人才，给他们成长的机会，并制定策略让他们留在分析师的位置上。您可以培训人员响应特定的警报类型、处理特定的情况和特定的工作流程。总是会有“任务驱动”的工作需要某个级别的SOC分析师来完成。剧本使这种水平的员工更有效率，这反过来又给了他们成功，并导致员工想要做更多。这些人是你想要识别和培养的人。

14.1 入职培训和初步培训

SOC的培训将分为以下几种:

1. 产品技能:这些是实际的供应商解决方案培训。这是通过SIEM平台上提供的供应商或主要的技术供应商，如思科CCNA网络行动计划来实现的，因为该课程材料针对实际使用的产品。

2. 与供应商无关的技能开发:这些技能应该包括分析师在不考虑技术平台的情况下完成工作所需的工作角色、任务和概念。不缺乏教育，如:大学课程，认证课程，如EC-Council认证安全分析师，ISACA的认证信息安全经理，CompTIA网络。Security+和CompTIA高级安全从业者;SANS的SOC重点培训;CyberAces;以及安全大学提供的各种Q课程。对于欧洲的读者，可以参考欧洲信息技术认证学院(EITCA)和欧盟网络与信息安全机构(ENISA)。

3.在职:与职位和团队相关的内部培训，内部开发和交付。

4. 成功与失败:没有什么比“做对了”、阻止坏人或者错过坏人、然后发现真相更美好的了。

5. 网络靶场操作员培训:在一个专门的大型实验室提供的强化训练，重点是手的技能发展。

6. 和许多更多。

您的培训计划应该包括以上项目的混合，目标是确保您的分析师开发下一节中列出的所有技能。当新员工加入SOC团队时，您应该遵循一个定义良好的结构，以确保他们有最佳的成功机会。下面是我在几个组织中使用过的SOC分析人员的入职模型示例。你入职培训的主要目标应该是培养分析师，这样他们在4到5周的入职培训后就能在自己的水平上自给自足。

14.2 SOC分析师技能

从历史上看，成功的IR和SOC人员需要有一个多样化的IT背景，应该有几年的IT游戏经验，需要不断的培训，并拥有各种各样的技能，以处理SOC将面临的各种情况。特别是，分析师需要了解如何“连接各个点”。把点点滴滴串连起来是一项随着时间的推移而发展起来的技能。分析人员可以接受关于理解给定数据源的培训，但是必须获得在一段时间内理解另一事件上下文的技能。

分析师还需要学习如何有效地保存案件相关信息，因为他们通过报警调查工作。一种有效的技术是在他们写罚单或起草事件报告时捕获相关数据，而不是试图在事件结束后重建数据。

今天，为了解决技能差距，找到这样的人:天生好奇，能抽象思考，在性格形成时期经常把东西拆开再放回一起，对细节有很强的关注，能“连点成线”，最后能做研究的人。

下面是一份分析师技能开发配方，它来自于Ql/2017年期间对30多个SOC和安全经理的调查，然后在我实现这个建议时进行了改进。SOC分析师需要了解:

1. “攻击”的过程和阶段:侦察、扫描、最初的破坏、建立持久性、命令和控制、横向移动、达到目标、对目标采取行动、窃密、覆盖轨迹、不留痕迹。MITRE ATT&CK框架是这个领域非常宝贵的学习工具，同时也是第180页描述的网络杀戮链。

2. 伦理:伦理行为意味着他们在自己的范围内工作，寻求帮助，不夸大结论，不捏造事实，对他们使用的所有数据保密，以及其他专业责任。

3.熟悉组织特定的数据:熟悉您的组织源数据(事件类型和字段)，以便分析人员能够梳理出能够在可疑机器或用户的事件流的整个上下文中“连接点”到警报事件的事实数据。这是最难培养的技能之一。当一个新的数据源被添加到一个给定的系统中时，使用EDIS过程:高级分析人员必须为团队的其余部分准备一个数据的概述。

4. 系统:技术系统访问控制功能以及如何应用技术控制。

5. 防火墙:防火墙原理如日志类型和日志行记录什么;规则属性;动作，如block, allow, reset, drop;接口意味着它与流程相关;SNAT / DNAT字节发送/接收;了解安全区。

6. 安全区域:具体来说，安全区域是特定于每个组织的。人们可以推断区域的含义，但不应该这样做，因为不同的管理员或工程师可能不一致地应用区域术语。在构建防火墙规则集时，防火墙团队必须记录给定区域的含义及其关于流量的基本假设。Active Directory管理员需要对组织单元定义执行相同的操作。通过这种方式，一个名为“eComDMZ”的防火墙区域可以连接到一个名为“WebSalesDMZ”的ADOU，当定义声明“用于支持用于电子商务的web站点的服务器”时。

7. PCAP收集和分析:网络数据收集和使用tcpdump作为数据收集到，然后WireShark/TShark作为分析工具。

8. 取证:取证原则

a.按照波动的顺序收集系统数据

b.建立和维持托管链

c.记录所采取的行动、提取的数据、时间移位和时间轴重建

d. locard的交换原理

9. 硬件:硬件平台:PC、服务器、路由器、交换机、TAP、磁盘引导、MBR、识别卷。

10. 事件处理:事件处理过程:准备、识别、遏制、根除、恢复和吸取教训。一旦人们理解了这些要点，他们就需要能够撰写案例的执行摘要。

11. 调查:报警调查章节中描述的调查过程。

12. NAT问题:NAT转换和定位真正的源IP的复杂性。

13. 网络应用协议:DNS、SSH、HTTP/S、SMB、NTP、DHCP、FTP、SSL、SMTP、POP3、IMAP和SIP。

14. 网络协议理解:ICMP, QUIC, IP, TCP, UDP, GRE, BGP, SCTP，和ARP。

15. NIDS:网络入侵检测系统(NIDS)、规则集类别以及如何使用Talos Snort规则集(以前称为SourceFire VRT)和新兴威胁专业提要等规则集读取IDS生成的事件。

16. 应用程序组合:组织应用程序目录、应用程序行为和PoCs

17. 政策:组织政策/程序和礼貌地表达和执行PnP的能力。

18. 熟练操作系统:Windows和Linux:服务、启动、日志文件、网络连接、注册表和进程标识，以及如何在Windows和Linux上应用权限。

19. 脚本:编程，侧重于使用PowerShell、Python、shell、Perl或类似的实用脚本语言的管理和数据简化脚本技能

20.写报告，包括拼写，语法，单词的用法，写总结的能力，回答“谁，什么，什么时候，如何，在哪里”，并合理评估“为什么”。

21. HTTP、HTTPS和Web浏览器:了解最危险的应用程序(浏览器)如何工作对于分析人员的成功至关重要。应用程序本身比外围攻击更常见，因为它更成功。作为证据，考虑到钓鱼工具的兴起和对社会工程的关注，最终用户引诱他们点击。当代理服务器涉及到警报时，识别源用户的能力和一致的习惯是至关重要的。当警报发生或代理被识别为参与了入侵时，分析人员需要始终尝试查找生成流量的用户、用户代理或系统。

a.理解用户代理、HTTP状态码、url和浏览器重定向。

b.研究通过代理显示的URL数据。

c.研究用户浏览习惯时的判断力。

22. OWASP Top 10:除了需要了解浏览器之外，还需要了解如何攻击面向Internet的应用程序。

23. 所有在CompTIA安全+认证和许多网络+技能领域中测量的技能，所以SOC分析师是术语兼容的。

14.3SOC分析师特征

SOC分析师需要有特定的个性特征才能有效地工作，如下所列。

1. 天生的好奇心:SOC分析师将面临一系列不断变化的问题、情况和新的数据源。找一些人，他们年轻的时候会把东西拆开再装回去，特别是当他们把东西装好之后。

2. 组织能力:一种执行“快速研究”的能力，这种能力使他们能够区分优劣，特别是根据警报和警报周围的数据确定警报是否可能是真实的。例如，如果一个NIDS规则从三年前流行的攻击中触发，那么今天必须具备什么条件才能使攻击成功?

3.抽象思维:特别是，能够读取来自Snort/Suricata系统和Palo Alto防火墙的警报之类的入侵事件，并将它们与其他数据源进行实时关联，在它们的脑海中可视化活动模式

4. 将大型数据集放在上下文中:在上下文中将大量数据减少为信息的能力。更具体地说，在当前遇到警报时，确定该警报是否与更大的上下文相关。

5. 交流:进行数据总结和共性检测，使一组原始事实产生信息，然后阐明这些信息如何证明或推翻一个假设。

6. 自我意识小，但还不至于小到不以自己的工作为荣。

14.4SOC角色

在安全操作中心需要配备几个工作人员。根据大小、范围和预算，SOC可以定义更多的角色。角色还将定义与其他关键角色的交互，因为SIEM平台和NSM平台实际上拥有由SOC团队的工程、架构和流程支持方面支持的用户社区（SOC安全分析人员）。

表4 SOC的作用和功能

14.5SOC分层操作模型

少数人组成的小型安全团队很少遵循等级制度。这个团队只是互相协作来监视环境并对警报做出响应。随着安全运营中心的成熟、规模和广度的增长，它通常会发展成某种形式的分级分析师工作结构，反映了员工的技能基础、工作警报条件、工资水平、他们支持的SOC服务领域，以及与他们工作水平相称的培训。

本节描述一种两层和三层的方法，其中“层”一词用作占位符。职位头衔可以是一级分析师、二级分析师、三级高级分析师，或者是初级分析师、分析师、高级分析师、首席分析师、或SOC Shift Lead。不管实际的头衔是什么，基本的概念是有一些层次与分析师的技能基础、舒适程度以及他们对警报和事件条件的反应能力有关，而警报和事件条件又与薪酬和责任有关。分层模型还提供了一种衡量进展的方法，并根据头衔和与技能基础相称的薪酬来提供工作进展。

不管模型和标题是什么，安全操作团队几乎总是有一个正式的管理层。

什么是必不可少的分层模式!你的SOC使用的是每个分析师必须愿意寻求帮助，如果他们发现自己在处理警报或票据时超出了自己的能力范围。

1、两层模型

在两层模型中，一线人员通常由经验丰富的安全分析师组成，而第二层由工程师级别的人员组成，他们处理更复杂的案例或需要更复杂的分析。在这两个操作层之上是SOC管理。在某些情况下，每个级别都将具有最终用户和管理交互。

表5 SOC两层模型的角色和职责

2、三层模型

在三层模型中，责任更加分层，因为组织试图响应对更多覆盖的增加需求，并平衡人员成本和技能，或者需要提供更多覆盖，比如增加夜班和周末。因此，更高的分离似乎使初级分析师对SOC有效。

表6 SOC三层模型

14.6使用CMMI的SOC成熟度曲线

安全团队经历了各种各样的成长阶段和阶段，这通常是非常自然地发生的。SOC通常开始于管理层有意雇佣某人，或者是作为对事件的响应，因为他们需要“处理安全问题”，然后雇佣或引入一些IT人员来组成安全团队，作为自然的结果，形成了某种形式的SOC团队。在这些有机步骤中含混不清的，是对“购买和实施SIEM”的关注。然后在某人的共享办公室中有一个SOC，或者几个人在网络操作中心(NOC)中获得一些空间。所有这些都发生在相关人员做他们的“日常工作”的时候。

这些有机成长的团队经常在他们的形成中忽略一个关键的因素:SOC功能不是在需求评估或正式模型之后故意创建的。结果，第17页中描述的SOC服务的不同方面在不同的级别上运行。SOC工作人员针对相同的警报编写不同的报告，因此结果是不可预测的，每个人的技能水平不同，操作结构在内部不一致，工作人员可能会感到沮丧。

这个问题是如何解决的?一个备受推崇的方法是应用卡内基梅隆能力成熟度模型集成(CMMI)。在CMMI中有五个成熟度级别，每个级别代表了过程改进方面的进化平台。通常情况下，CMMI在一个组织中被全面地应用，跨越多达24个流程领域，因此使用它需要被调整，并集中于一个安全操作组织。将所有功能和过程都提升到5级可能是不必要的，甚至是不可取的，因为每个成熟度级别都是通过满足过程的一组目标来度量的。

表7 CMMI五级成熟度模型

还有一个形式化的模型可用来帮助评估soa成熟度级别。socc - cmm是由Rob van Os (MSc)创建的。这是他硕士论文的一部分。Rob的方法、工具和电子表格用于评估五个维度和25个方面的SOC。这五个领域是业务、人员和流程，它们被评估为成熟度。另外两个是技术和服务，分别针对成熟度和能力进行评估。

您可以使用此工具来评估您的当前状态，并开发一个如何使SOC成熟的路线图。Rob的网站是https://www.SOC-cmm.com/。罗布的工具越来越有吸引力了。

14.7度量数据源集成成熟度级别

为了应用CM CMMI, SOC可以考虑如何将一个数据源集成到SIEM及其操作过程中，作为一个必须得到良好管理和可重复的过程。作为一个主要的需求，为了将这个特别的过程移动到一个成熟的、定义良好的过程，SOC需要系统地接受数据，挖掘数据，并确保SIEM平台最大化。

作为初始过程的数据输入(L1)的特征是:

•将数据输入SIEM可能非常特别。善意的系统管理员设置了一个syslog feed，并让SOC知道新数据的到来。

•SOC中有人与系统管理员合作，以确保系统数据可以收集到SIEM中。

•SOC的其他人与SIEM供应商合作以确保数据被解析。

•建立数据生存能力基线，这样如果源系统停止提供数据，就可以“足够快地”检测到。

作为管理过程的数据输入(L2)的特征是:

•数据输入经过一致的过程。源系统工具定义良好，如果供应商需要自定义，则计划使用它，并设置一个合成事务(参见第189页)。

•源系统得到充分运行，因此所有安全和操作相关的事件都被记录下来。

•一旦数据到达，SOC将基于该数据源构建源特定的报警条件。

•SOC是针对事件类型的广度进行培训的，以便团队能够充分利用源系统能够提供的所有资源。

作为定义的过程特征的数据输入:

•组织策略和流程策略要求将数据源输入集成到组织中。例如，策略要求对SIEM和/或日志管理平台进行日志记录，并将检查设置是否正确的功能集成到配置管理流程中。

•SOC经理确保所有用户已完成新员工培训对于每个数据源和确认都有等价的理解如何使用数据。

14.8测量报警处理管理成熟度级别

为了应用CM CMMI, SOC可以分析它如何处理报警处理。警报处理是应该一致交付的服务的另一个好例子。这项服务是处理输入到SIEM的数据，然后由SOC分析人员执行的结果。为了实现该服务，SIEM和SOC的所有方面都是服务交付的一部分:数据输入、解析、健康监控、响应事件的警报、验证警报是否真实为正的警报分析、响应的严重性、基于对组织的影响、事件响应被激活到所需的程度，以及对结果事件的跟踪到解决。

真拗口!下面是一个警报管理如何通过一组成熟度步骤，从特定的成熟度级别过渡到定义良好的级别的示例。主要的要求是SOC尽可能快速、完整地读取、检查和响应警报。

报警处理作为初始(L1)过程具有以下特征:

•soc分析师在警报到达时对其进行审查，并提出一些优先级和影响的概念。高度优先的警报，可能是真正的积极的收到注意，如报告的决议，数据所有者和系统保管人通知，或路由到第2层的进一步调查。

•soc分析人员在警报解决的决策过程中可能一致，也可能不一致。在高压力时期，警报并没有得到持续的管理。紧急警报可能永远不会得到及时的评估。

•警报可能偶尔会在每天的汇总审查，这样关键的警报总是接受某种形式的治疗作为“临时措施”。

报警处理作为一个管理(L2)过程特征:

•对事件数据进行审核，以发现其他报警情况，从而提高检测能力。

•调整警报，使误报可以最小化。这部分流程应该在反馈循环中影响源系统。

•警报由SOC的所有成员一致处理，其中大多数映射到事件剧本或其他支持流程。

•警报解析、路由或调查,因为他们定义在一定时间内到达一30分钟为关键,说一个小时中,在4小时内低。

•每班都要对警报板进行检查，以确保所有的“紧急”和“紧急”警报都得到重视。

•警报分析和处理进入调优过程，从而获得的经验教训和系统管理员反馈改进了警报管理过程。

报警处理作为一个定义的(L3)过程具有以下特征:

•随着数据源被集成到SIEM和SOC流程中，它们被映射到分类法中，审查流程被定义，SOC人员被充分培训，以了解数据源及其带来的警报条件。

•SIEM平台增加了编配和自动化功能，以提高分析师的响应能力，并将更好的数据交付给分析师。

•警报和事件数据用于指导威胁捕获程序，而威胁捕获程序又通过相应的SOC过程指导和改进警报生成能力。

14.9例如SOC周转清单

从这个列表开始你的SOC周转清单。在每班开始的时候负责人员的周转。每个班次需要总结下一个班次的警报、事件和跟踪事项，因为这些对情景感知非常重要。回顾这个列表并定义分析师每班做什么，开发一个组织特定的模型，然后更新换班结束。一些SOC团队没有足够的人手来提供夜间功能，因此在早班开始时，应该立即检查夜间警报，确定如何将这一点纳入您的环境中。

1. 从以前的班次，这应该包括:

a.关键事件

b.持续事件的状态

c .员工中断

d.主要数据问题

e.任何系统稳定性问题

f.相关沟通议题

2. 在正常的维护日，检查计划的变更，这样SOC就不会对可以通过变更管理运行的变更来解释的警报情况做出过度反应。

3.快速回顾昨天的警报，以便很容易识别任何可能揭示重复事件的重现或重复情况。

4.回顾每日简报，内容应包括以下主题:

a.系统中安装了新的警报装置

b.离开系统的数据源

c.新数据源进入系统

d. otj培训缺口