转载了别人，初步看来下，应该是机翻的，看起来有些难懂，但是可以初步了解下。
转载的地址：https://www.jianshu.com/p/f7d9b9f8fc4c
一、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报告。
- 构建日志体系结构、源数据收集交付、SIEM和日志部署计划。有关SIEM部署检查表的更多信息，请参见第194页。同时,简要:
a.根据与您的业务模型、独特的数据源、遵从性需求和InfoSec程序相关的用例构建的评分模型，执行软件和供应商选择。
b.审查审计立场，并为环境中提供数据的每个系统构建每秒事件(EPS)评级。然后计划50%的增长，这样你的解决方案就能经受住“事件风暴”。在配置了源系统的审计级别之后，确定EPS是非常重要的!
c.提供硬件和存储平台并实现。
d.监控数据提要、报告和系统响应时间。
e.为商品源构建数据集成计划，并仔细选择定制源。例如，ERP应用程序可能不受支持，因此您可能需要开发一个数据库查询来从审计表中提取数据、实现审计、测试、开发一种方法来将当前数据存档到历史表，并进行监视，以确保查询过程对系统的影响最小。
- 构建用例:
a.在这本书中有整整一章是关于构建用例的。回顾所有这些材料，并将其与您选择的平台中的用例进行比较。
b.计划如何实现供应商定义的用例，因为这些用例应该提供基线覆盖率。
c.预测实现您自己的自定义用例所需的工作量和数据源。
d.从那里，对实现进行优先级排序，这样您就有了支持定义挣值的项目度量。
- 构建您的响应流程，该流程由到达的各种数据和您的需求所支持。
a.响应过程将由您的安全程序和您正在遵循的适用标准驱动。
b.规划过程的这一部分应该回答这样的事件解决问题:“当我们从系统B获得条件A时，分析人员要做什么，系统管理员需要什么数据来解决事件?”
c.实际上，将数据拉入SIEM的过程将为SOC功能提供许多需要处理的场景。当您构建这些过程时，确保您关注的是结果——需要实现的目标是什么。
-
构建SOC指标，如第38页SOC指标中定义的那样。
- 建立并实施你的持续培训计划。
a.培训是一个持续的过程。SOC技能需要随着攻.击者技能和判定能力的提高而提高。确保至少有两级教育的预算。为高级员工提供优质的教育，然后为初级员工提供OTJ培训，包括知识转移、短期课程和以工作技能为重点的教育。调查当地社区大学的劳动力教育计划和能力。
b.有几种开源或非常低成本的选择。考虑一下ENISA, SecurityTube, SANS Cyber Aces, Cybrary, local BSides conferences, DerbyCon, and the annual Security Onion conference作为更便宜的教育选择。
五、思考并准备好回答棘手的问题
为了资助SecOps、SIEM和SOC，您无疑将面临许多问题。以下是我多年来被问到的一些问题，经过压缩后将发表。在建立资金请求时确定答案。
-
什么也没有发生。我们为什么要这么做?你怎么能肯定什么也没发生呢?作为一个可能的答案，试试这些。不是如果，而是什么时候。”
- 团队将如何检测和响应安全问题、事件和数据泄漏?我们以前是怎么做的?这不正是系统管理员所做的吗?
3.该组织去年发生的事件是否产生了任何费用?病毒爆发?我们的同行和竞争对手为此付出了什么代价?
-
有多少处于哪个“级别”的用户受到某个事件的负面影响(比如生产力下降)?
-
你将如何衡量自己，并获得IT平衡计分卡?作为一种可能的方法，询问您是否可以在SOC charter开发过程中使用业务记分卡。
-
团队将如何确定哪些警报条件优先于其他条件——谁赢了?(提示:与关键业务流程和收入流保护相关的资产价值)。
-
我以为我们去年在安全上花了X。你为什么想要更多?
-
我知道我们没有任何值得偷的东西。为什么我们需要做越来越多的安全“存根”?
-
这些东西不是花了几百万吗?
-
我们正在进行脆弱性评估。难道这还不够吗?如果你没有积极及时地进行补救，那么就没有。
-
那些安全人员一直在说不，所以这次我要对他们说不。所以在那里。
-
我们可以成功地以1/8的成本外包出去，对吧?毕竟，供应商就是这么说的。你为什么不同意他们?他们不是专家吗?
-
SOC将如何为我们解决业务问题?
-
SOC是什么样子的，第1年，第3年，第5年?
-
我不想买更贵的安全人员，只让他们辞职。你打算如何留住员工?倦怠?摩擦?内部转移?我最近在一个安全会议上听说，当人们接受SOC工作时，他们计划在18个月内辞职。
-
你怎么知道你已经成功了呢?SOC的成功和失败是什么样子的?(或者是大笔的证券购买?)
-
你又和审计员谈过了吗?他们去年说过一些关于这个的事情。我买了一个新的防火墙。
-
先给我看看剧本——你能做到吗?完成后再回来。
- 这是外包的，是“X公司”的责任，不是我们的。我们没有责任，因为这是外包供应商的责任，而且是在云/供应商合同中。
20.你能用三分之一的钱做什么?因为我们只有这些。
- 去年我们在SOX法案上花了350万美元。没有更多!
六、收集重要的数据源
有许多基线系统需要监控，因为它们代表了在事件中需要的关键数据源，并且支持遵从性。这是EDIS过程的一部分。这些需要收集的资料系统和数据来源至少是:
-
DNS活动，首先关注内部到外部活动(约占网络DNS请求/响应流量的8%到10%)。
- Windows域控制器安全日志。
3.大多数(如果不是全部)Windows成员服务器。
4.工作站上的帐户生命周期、流程执行和状态指示器。此项目最好使用Windows事件转发和事件订阅来完成，因为这是Windows中内置的本机功能，可以防止部署另一个代理。
-
边界防火墙。至少，任何出站“拒绝”、接受和拒绝DMZ的流量以及平台更改。如果您有容量，也可以收集出站接受事件，前提是不能为通信流获得更好的数据源。例如，如果您有一个代理，如果您可以获得代理日志，您可以考虑不记录防火墙数据到/从代理。代理日志优于防火墙日志，因为它们是应用程序感知的，并且是用户可归属的，而防火墙数据通常不是用户可归属的。
-
数据库帐户活动和帐户管理。
-
对于Linux，至少要收集sudo、auth和authpriv日志。
-
防病毒集中控制台数据。
-
转发(出站)代理数据。对于代理，验证系统是否记录了用户代理、引用者、URI查询字符串和允许/拒绝决策。如果代理理解站点类型，这也很有用。
-
“在云中”编辑文档，比如谷歌的GSuite或Office 365。这意味着谁触摸了哪个文件以及如何触摸。
-
共享存储文件系统活动，如谁触摸了哪个文件以及如何为用户和进程公开共享。
-
VP.N的活动。
-
DHCP的事务。
- 网络设备认证通常通过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、出于真实的愿望或恐惧反应的管理指令。
-
您选择的标准定义了它的结构，并因此被审计，可能需要SOC和一个日志平台。
-
给定系统中的日志是易变的。有些系统，比如Windows域控制器，只保存几个小时的日志数据，然后数据滚动并永远丢失。有些系统将数据保存在内存中、缓冲区中，当电源或电源丢失时，数据也会丢失。
-
没有日志,你没有能力回到历史,发现问题一安全,操作,或改变有关。
- 事实上,这是“正确的做法”。
九、安全操作中心需要成本
在构建安全操作中心时，需要考虑许多成本组件。下面是许多常见的成本组成部分。对于每种成本，在开发“构建vs.购买”分析时，请仔细分析您当前的环境。
直接成本——在这个列表下面有更多的信息。
-
内部人员编制。一年365天，每周7天，每天24小时，至少需要5个人，使用最简单的人员配置模式。目标9名员工和1名SOC经理。
- 厂商中立的训练。例如SANS、Security University、CompTiA CASP和ISC2 SSCP。
3.产品培训:SIEM解决方案有供应商提供的培训。
-
工具:桌面基础设施、操作系统、Office、SIEM许可证和调查工具。
-
订阅:soc将有几个订阅服务,特别是威胁情报服务。
-
硬件:服务器、存储和网络基础设施。注意典型的硬件更新周期——通常是4年。
-
取证硬件:取证硬件有独特的要求，因为这些系统通常被隔离在一个锁着的房间里的小局域网中。例如，一个名为FRED的自定义取证工作站可能要花费5000美元以上，在中央存储上存储图像可能要花费很多tb，而写阻止程序包很容易花费1000美元以上。
-
包括年度维护的软件许可费用:软件包括SOC支持、各种管理控制台的附加许可、SIEM平台、摄取成本、取证包、PDF生成应用程序、Bl7工具和eDiscovery功能。
-
设施:SOC室，家具，共享大格式显示器或投影仪，和接近卡或可能的生物特征门控制。此外，取证分析空间应该有自己独立的锁和接近卡控制。
-
升级:每年升级一经常在SoW的基础上由供应商处理。
- 供应商帮助:随着时间的推移，您将需要供应商帮助提供新的内容、改进的报告、更多的培训以及可能的升级。
间接成本:
-
招聘成本，如构建团队，招聘和员工加薪。
- 初始项目的SIEM选择成本，包括特定的、审查和选择主要SOC工具集的劳动成本。
3.开展对SOC人员的工作培训。注意，这将占用关键的中小企业和时间的承诺不能低估。
-
集成新的数据源，这可能需要在平台中创建定制的数据解析器、警报和报告。
- 定期的内部或外部审计支持。
人员成本考虑:安全操作中心需要由熟练的信息安全分析师组成。闪亮的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)）的意见:
-
启动时间会有影响。MSSPs实际上在您的网络上部署了部分到完整的SIEM解决方案。每个数据源都需要集成到平台中，需要部署硬件，您的组织:仍然需要定义自己的事件响应流程。
- 一个MSSP在调查警报时只能走这么远，如果你幸运的话，MSSP可以很好地覆盖50%到70%的警报情况，并将使你的组织参与到15%的观察警报中。
3.mssp永远不会像您那样了解您的网络，而且您无法轻松量化这对其服务提供质量的影响。mssp也不太可能知道网络上发生了什么变化，因为他们很少参与更改控制。
-
mssp通过定义的SLA和报告关系与您一起工作。他们不能代替你自己的员工可以直接接触到一个系统托管一这是一个宝贵的好处有内部人员运行在一个安全操作的角色。
-
他们对警报灵敏度和配置的看法与您不同，因为他们倾向于关注“真正的威胁”条件，而忽略或忽略许多其他条件。您对SOC的使用应该包括策略问题、威胁捕获、审计报告，以及从SIEM将消耗的大量数据中收集操作价值。
-
如果任务不经常发生，那么有些任务应该外包，比如系统分析。然而，今天的战场空间告诉我们，我们需要的是内存映像，而不是磁盘映像。这是几乎不可能的第三方外包MSSP收集，但可能在他们的能力分析。
-
您不能将您组织所关心的资产的安全性的责任委托给第三方，不管别人如何试图说服您您可以这么做。您可以授权进行操作，但不承担系统安全的责任。
-
7/24/365由第三方监控比建立自己的6-8人团队的劳动力成本更低。这是无法回避的事实，如果你是被迫外包的，意识到这个论点，并想出方法来回应这个论点。
-
MSSP也可以执行系统升级，并且很可能比你做了更多的升级。将执行年度升级的一两个星期的部署成本考虑在内。
- 最后，你从一个MSSP关系中得到了你投入到MSSP关系中的东西。如果你不投入时间，那么不要认为他们会给你一流的结果。
十一、开始狩猎
从历史上看，SOC将监视各种面向预防的系统，如果其中一个或多个平台向团队发出警报，则进行响应。然后，他们将花时间验证警报，与系统管理员、所有者或最终用户进行通信，如果情况是突发事件，他们将作出响应。
从2000年开始的“被动或被动的模式或姿势”在今天已经不再有效。今天的SOC团队需要改变他们的关注点，假设存在可能的破坏方案，变得面向检测，并主动挖掘进入他们系统的大量数据，并主动寻找入.侵和不当行为的模式。先发制人的威胁搜索是SOC分析员的理想职业和技能发展路径。一旦他们了解了组织的所有数据源，知道如何处理警报，并证明他们已经建立了研究技能，利用这一点，让他们参与到威胁捕获中。根据SOC团队的操作方式，您可以让SOC分析师每周执行一天、每月执行一周，或者采取特定的狩猎路径。威胁搜索在第167页有进一步的定义，许多用例从第60页开始。
十二、SOC直接支持CSIRT功能
今天，需要开发某种形式的计算机安全事件响应小组(CSIRT)功能是不能忽视的。在许多组织或行业中，CSIRT是由特定的法规规定的。现代恶意软件猖獗、自动勒索软件、工业间谍、犯罪分子、国家一级***团队以及基于数字的非对称战争的其他方面，对CSIRT的需求尤其迫切。听起来很耸人听闻，不是吗?今天的网络罪犯会利用他们发现的任何弱点，从任何潜在的受害者那里提取无法追踪的数字加密货币。不管耸人听闻的程度如何，都有几个理由在您的组织中提倡和构建CSIRT功能，而这又得到了SOC功能的支持。
-
SOC提供了一种主动检测能力，应该能够及早响应并限制事件的长期影响。然后，CSIRT可以协调响应事件，以确定、控制和减少事件影响为目标。此外，CSIRT功能可以将破坏或loCs的指标返回给SOC，以便SOC可以执行历史数据分析，例如搜索与找到的IP或域名通信的内部系统。因此，一个更成熟的CSIRT和SOC团队可以利用威胁搜索功能来寻找并发现最近出现在网络上的恶意代理。
- CSIRT影响、支持并充分利用安全支出。它有助于确保SOC工具的到位将支持事件响应和安全操作。或者换一种说法，拥有一个单一的CSIRT应该确保环境的最佳工具已经到位，可以被利用，而其他工具则可以退役，以实现美元投资的最大化。
3.与内部员工沟通时保持客观，对事件进行分类，并对响应过程进行优先排序。CSIRT需要处理的挑战之一是人员关系和保持客观性。与负责以统一和一致的方式执行公司政策和程序的人力资源职能一样，CSIRT需要客观、执行其工作以保护业务，并避免偏袒。
- 最后,监管。业务环境中有许多方面要求具备事件响应能力。这些包括但不限于:HIPAA/HITECH# PCI DSS 3.2，以及Sarbanes Oxley合规。
十三、SOC的指标
成熟的经营单位和企业运用各种方法来衡量经营单位的效益。SOC也不例外。问题是，你如何做到这一点，并避免让员工失去动力的有害指标?
在《实用的安全度量标准》一书中。W. Krag Brotby和Gary Hinson提出了关于度量的几个关键点。它们的一些关键定义列于第1.6章:
-
仪器:是“测量仪器”的简称，即测量仪器。
-
测量:(动词)确定某物的一个或多个参数。
- 度量:与一个或多个参考点有关的度量。
在第2.6节中，他们指出“拥有有效的度量标准使业务经理能够对信息安全做出理性的、明智的、甚至是站得住脚的决策。他们再也不能完全依赖信息安全专业.人士或通用的良好实践标准、法律、法规的建议。”
在第3.2节中，他们声明“度量标准主要是管理的决策支持工具。好的度量标准提供了有用的、相关的信息来帮助人们——主要是，但不完全是，经理们——根据历史事件(背景)、现在正在发生的事情(包括可用的资源和约束)以及将来可能发生的事情(变化的必要性)的组合来做出决策。
有许多指标和测量,可以开发和应用于SOC。在设计度量时，有几个标准。
在开发度量标准时考虑这些标准。
-
度量标准应该与作为业务单元的SOC的目标、目的和使命相关。这意味着你应该能够用数字描述你所做的事情，并解释你没有测量的东西。
- 当您评估您的数据、安全用例和度量时，请确保开发一个路线图，其中包括您将度量的内容、如何捕获这些度量、与IT常规控制和安全程序的联系，以及可能的业务价值链。然后，指标可以为决策提供指导。
3.确保你所衡量的将会是一个可衡量的结果。不要为了测量而测量。每一个指标都应该告知消费者，并设法改变他们的行为，或者证明当前的行为在既定的程序中运行良好。在这里，您应该清楚地了解您期望度量的使用者基于度量所采取的任何操作。
-
度量应该支持“控件”，因此应该与ITGC程序匹配。如果没有的话，可以参考ISO 27002之类的标准。
-
坏数据比没有数据要好一点点。如果您没有为需要测量的数据收集任何源数据，那么就从那里开始，但不要停止。充分利用好数据。
-
避免给分析人员带来负担，使他们需要记录过多的数据，使用一些人为的方法来跟踪他们的工作，比如使用复杂的电子表格。相反，开发方法来挖掘SIEM平台、工作流系统、开放调查编码和警报结束代码，因为它们通过警报工作。这些方法提供了一种机制经济(EoM)，因为分析人员正在使用它们自己的工具。此外，遵循EoM原则可以促使您始终利用SIEM平台的内部功能，从而降低出错的可能性。
-
从你的业务/组织的角度讲述你的故事。讲故事时，记住听众并使用他们能理解的术语和定义是非常重要的。
- 我想到了两个关键的缩写词:
A :聪明一点:具体、可衡量;切实可行、有时限
B: KISS，要么保持简单，山姆/苏珊。这并不意味着可爱。相反，要确保度量的名称和度量尺度是明显的。需要解释的度量标准不太可能是有效的度量标准。
- 确定如何构建一个记分卡来度量组织的信息和技术安全状况。只要有可能，就构建一个工具来演示技术工具的工作效率。您可能不会将此工具展示给管理层，但您应该准备好展示。
表2一般SOC指标示例