每一起严重事故的背后，必然有29次轻微事故和300起未遂先兆以及1000起事故隐患。

上面这句话，是德国飞机涡轮机的发明者帕布斯·海恩提出的一个在航空界关于飞行安全的法则，也是生产管理学著名理论——“海恩法则”。

海恩法则强调两点：一是事故的发生是量的积累的结果；二是再好的技术，再完美的规章，在实际操作层面，也无法取代人自身的素质和责任心。这个理论同样适用于 *** 安全行业， *** 安全事件的发生往往伴随着多个异常行为，再好的安全产品也需要合适的安全运营人员运用恰当的管理方式来充分发挥安全监测防护能力。本文将为各位读者展开分享应如何通过SOC[1]建设实现 *** 安全控制，避免 *** 安全风险。

为了更好的阅读体验，观仔在此先对文章中会涉及到的名词给予解释：

[1]SOC（Security Operations Center）：安全运营中心

[2]SIEM（Security Information And Event Management）:安全信息和事件管理

[3] ATT&CK（Adversarial Tactics, Techniques, and Common Knowledge）：是一个攻击行为知识库和模型

[4]UEBA(User And Event Behavior Analysis): 用户及实体行为分析

[5]APT(Advanced Persistent Threat)：高级长期威胁

[6]ISG（Informstion Security Govern）:信息安全治理

[7]MDR（Managed Detection Response）：托管检测及响应

[8]SOAR（Security Orchestration Automation And Response）:安全编排和自动化响应

[9]MSSP（Managed Security Service Provider）：安全托管服务提供商

[10]CARTA（Continuous Adaptive Risk and Trust Asses *** ent）：持续自适应风险与信任评估

聊聊为啥需要建设SOC？

技术问题烦人心

烦心1：多种安全设备，各种安全告警，如何整合归并？

不同厂商、不同类型安全设备的UI界面和安全事件定义往往不尽相同，如果让一个安全运维人员熟练掌握各类安全设备的使用 *** ，就必然要付出大量的学习成本。那么如何才能将各种安全告警整合归并，让安全运维人员只需处理一个系统上的数据呢？

烦心2：海量安全事件，不同紧急程度，如何确定优先级？

多种安全设备往往每天会监测出数以万计的安全事件，大大超出了安全运维团队每天的处理能力上限，并且安全事件的紧急程度各有不同，如果逐个判断和处理显然力不从心。是否可以将海量事件筛选标记，并帮助判断处理优先级呢？

烦心3：大量安全设备如何集中管理？

大型企业可能有多个分支机构或者数据中心，同时都会部署大量的安全设备，分散的设备难以统一远程管理。怎样让分散在各处的安全设备被集中管理起来呢？

安全运营烦恼多

烦恼1：是否可以将 *** 安全事件与业务风险关联？

安全运维人员以技术语言来描述安全问题，安全管理人员则需要从业务角度理解安全问题造成的危害，这就需要将具体的技术问题转化成抽象的安全管理数据，中间信息的传递会消耗大量沟通成本。

烦恼2：是否可以建立一套行之有效的 *** 安全事件处理流程？

处置安全事件的过程中，一些响应处置动作可能会导致某些正常服务遭到波及，这种情况下安全运维人员需要花费时间找到相关部门决策人沟通后才能进行阻断等操作，容易错过处置更佳时间。

如何决策费脑壳

费脑1：保证 *** 安全的同时如何满足合规要求？

国家监管部门和行业主管单位对企业的 *** 安全防护做出了具体的合规要求，企业迫切需要满足合规要求。

费脑2：保证 *** 安全的同时如何合理控制安全投资回报率？

企业在 *** 安全方面的投资，通常很难在之一时间产生立竿见影的效果，投资回报率难以考量，也很难明晰未来安全投资的方向。

谈谈SOC建设三剑客

图：SOC能力要素

软硬件设施建设

当企业需要进行SOC建设时，往往已经采购了一定数量的安全设备，在SOC建设初期，除了已有安全设备的利旧之外，往往还需要采购一定量的安全设备来监控过去没有注意到的安全“死角”。一个成熟的SOC，必需的检测设备主要分为 *** 层设备- *** 取证设备（NFT）或 *** 流量分析设备（NTA）、端点检测和响应设备（EDR）以及漏洞资产扫描类设备。

SOC的核心往往是一个安全管理平台，通常意义上讲即是一套SIEM[2]平台，它所需要包含的能力主要有：

实时监控：应用于威胁管理跟踪和分析跨组件/系统的攻击行为，对接入的各类安全设备日志进行统一分析和可视化处理。

高级威胁防御：通过纳入攻击链或ATT&CK[3]等分析 *** 来有效识别攻击者的一系列攻击行为，辅助响应决策，“治标又治本”地解决安全事件和隐患。

安全情报：利用安全情报来辅助验证事件准确性和确定响应优先级。

UEBA[4]：监测组织内的用户活动, 以发现一系列企业内部安全和业务问题，数据来源广泛，需要多种类型的算法支撑。

数据安全防控：数据和应用程序监视侧重于对数据存储、管理和访问进行实时监控。此功能侧重于将监视数据库管理系统 (DBMS)与文件完整性监视 (FIM) 和数据泄密防护工具(DLP)所输出的系统日志和安全日志进行集中统一管理分析。

高级分析：高级分析针对安全日志和事件数据采用复杂的统计和定量 *** , 如图形建模、机器学习和深度学习。结合安全事件相关的大量上下文日志，来及时有效的发现未知APT[5]攻击行为或者已知APT攻击变种行为。

漏洞监测：使用SIEM工具实时监测已经存在的漏洞并提供漏洞缓解策略。结合威胁情报进行漏洞风险等级的动态评估。

安全运营建设

在整个SOC体系建设当中，安全管理平台仅仅是一个可为运营提供支撑的实施工具，更重要的是安全运营体系的建设。而作为企业，首先需要明确层级分明的ISG[6]（信息安全治理）的组织结构，ISG组织通常分为三级架构：

安全治理团队：理清不同复杂时空条件下的业务战略目标，并且将安全计划和业务目标进行对比，执行战略决策。该团队往往由企业高层人员组成。

安全管理团队：参考业务目标构建并且运行安全计划，整合企业内的各类安全设备提供的安全功能，制定安全运维流程和安全策略。将业务目标消化并且拆解分配到每个安全运维人员的日常工作内容当中并建立考核机制。该团队往往由企业信息化部门或安全部门的主管人员组成。

安全运维团队：每天按照安全运维流程执行各类旨在降低企业安全风险的日常活动。该团队往往由企业基层运维人员、外包服务商或安全供应商人员构成。

据Gartner的研究表明，在不违背各个地区劳动法规的前提下，一个9-10人的安全运维团队是确保企业能够维系一个7/24小时的运维监测体系的最小规模。当企业无法构建一个如此规模的安全运维团队的时候，可以通过向安全供应商采购MDR[7]服务或者在安全管理平台上拓展SOAR[8]功能来实现相同效果。

安全攻防演练

对于企业客户而言，在日常 *** 安全运维过程当中，出现较大的安全威胁甚至APT攻击的频率往往偏低。为了检验安全运维人员的技术水平和安全设备的架构是否能够抵御黑客组织进行的目的性较强的APT攻击行为，定期进行安全攻防演练活动就显得尤为重要。通过安全攻防演练，可以有效的发现安全运维人员的技能缺失和安全设备配置问题，为组织人员进行相应的培训和采购适当的安全设备并进行合理部署等安全投资决策提供目标和方向。

讲讲如何建设好SOC

要想建设好SOC平台首先需要对建设的流程和规划有完整的认知，下面是在建设SOC前需要了解的信息。

时间和流程规划

建立一个全面的、具有合理的运维成熟度的SOC平台往往需要18到24个月，流程大概可以分为采购设备—购买和部署工具—雇佣、分配和培训人员—创建和完善业务流程—员工扩充合同和购买MSSP[9]服务—内部团队建成。

建设并优化SOC

首先安全建设需要一个明确的动机：“我们需要一个SOC，是因为….”

这个动机可能是我们需要解决的安全技术方面的问题，也可能是建立安全运营体系并降低人工成本亦或是为安全决策提供支撑参考。

当我们决定好需要建设一个SOC之后，这个SOC平台一开始可能仅仅能做到大量多源异构数据的统一收集和集中可视化，并且能够进行一定程度的安全分析，再将安全告警之一时间推送到安全运维人员的邮箱或者手机当中。往往这个建设时期是大多数安全主管最迷茫的时候，此时安全管理平台已经部署在企业的IT系统当中，大量的DPI设备和扫描类设备日志都已经完成接入，但是总觉得已经上线的“SOC”有种“鸡肋感”——初阶的运维人员在平台上无法对安全事件进行深度溯源和事件研判，高阶的安全专家往往更愿意登录到探针设备上获取数据进行安全分析。此时我们的SOC平台就进入了发展的“迭代期”。

图：GQM应用场景

在迭代期，安全管理者可以参考GQM（Goal Question Metric）模型来进行围绕SOC的安全体系迭代，通过不断设立“小目标”的 *** 来进行下一步的建设规划。GQM模型的应用，我们可以把它拆解为五个方面，分别是：目的、目标、问题、指标和度量。

目的：安全管理者需要明确下一步需要在安全方面取得的商业目的；

目标：从目的当中衍生出多个需要达到的具体目标；

问题：发现并提出当下安全体系当中的问题，并且明辨出哪些问题解决之后能够达到安全目标；

指标：拆解出多个碎片化的能够切中要害的指标来解决问题；

度量：将指标进行细化，得出不同的度量值，满足解决问题的需要。

一些常规的度量方向大致可以是：MTTD（事件/漏洞平均发现时间）、MTTR（事件/漏洞平均响应时间）和FPR（误报率）等等。

只有发现并满足了一个又一个的“小目标”，在小目标中不断进行迭代，发现安全管理体系的小漏洞，不断查缺补漏，不断进行排查。才能让我们的SOC平台不断充实，来应对日益复杂的 *** 环境带来的更广泛的安全问题。

发展的眼光看待SOC建设

图：CARTA自适应架构

从CARTA[10]的自适应架构当中，我们不难发现，一套完整的安全体系建设是一个长期的、持续不断的过程，将一次性的安全防护替换为上下文感知、自适应和可编程安全平台，并通过主动和被动的方式持续不断地发现、监测、面对风险并确定风险等级。

一个安全管理平台的建设也是一个不断扩充其“三V”的过程，“3V”分别是：体积（Volume）、变化（Variety）和速度（Velocity）。

体积：更多的日志数据、更多的日志源和更多类型的定时活动数据进入安全管理平台产品，数据的数量和多样性都有望进一步增加。

变化：模块化、可扩展的体系结构和大数据领域的技术逐渐被应用。

速度：日志流的增加、上下文数据量的增加以及向安全管理平台产品报告的节点数的增加、增加工具供应商都对处理速度产生压力。

建设好SOC平台不是一朝一夕的事情，就像建房子，先要有自己理想的“家”，然后将自己的理想落地为实实在在的计划，初步完成架构后再不断地增加“软装”和“硬件”，让“家”更符合我们的习惯。此外，我们也不应局限在此，建个庭院？扩大面积？变身智能房屋？只要不设限，求发展，也就一定能够建设好完全适合我们自己的美好“家园”。