安全运营平台是支撑安全运营工作的全生命周期核心枢纽，是在【策略】的目标下，对【工具】、【人员】进行1对1、1对n、n对1的合理分配，在【流程】的准则下，对安全运营服务进行全方位的支撑与管理。
这句话读起来比较拗口，那究竟是什么意思呢？
安全运营的所有工作应该都能在平台上进行追溯，一方面是为客户提供可信、可追溯的安全服务；另一方面也是SOC自身安全性、人员考核的刚性要求。
基于此，安全运营平台在顶层规划上，应该考虑以下几个要素：
▸ 安全运营平台理解【安全运营】，且与安全运营团队互相成就
我们以往采购平台时，几乎所有的平台部署以后，需要人员去适应平台，包括它的功能、平台的流转方式等，往往是削足适履，导致使用效果不佳。而在安全运营平台的规划建设上，我们强调安全运营平台是理解“安全运营”的，并在流程的准则下，去匹配甚至适应安全运营人员的工作，让工作更加高效，更加得心应手。安全运营的工作是一个长期的工程，要取得好的建设效果，必须使安全运营人员愿意且自发地使用它，并且在使用过程中越来越依赖，这就是我们所讲的安全运营平台与安全运营团队互相成就。
▸ 安全运营平台实现对安全服务的精细化管理
安全产品或者安全服务的价值是在于服务成果，但是安全运营服务只注重成果是不可取的。例如，某客户买了我们的安全产品后没有出现类似问题，其原因可能是用户之前的问题压根没有再出现了，它的成果（没有出现问题）达到了，但是它怎么达到的却没有深究。而我们安全运营中心提供的服务可以对服务结果进行复盘，也就是我们常说的“精细化、可追踪、可衡量”的安全运营服务。而这个服务怎么可视呢？这就由我们的安全运营平台来实现了。安全运营平台实现对安全服务的精细化管理，可以参考ITIL相关服务管理体系标准，对【策略】下设计的服务进行全生命周期管理。
▸ 安全运营平台的核心是围绕安全运营的目标达成而设计，而并非某个技术功能
我们一直在强调【策略】是5P的核心，其实这个【P（核心）】它是一个多边体，在不同的客户中是不一样的，例如，政府单位以“合规”为核心，行业运营单位以“风控”为核心等，目标不一样，平台也是不一样的。简单来说，安全运营平台是达成目标的路径，我们希望在这个平台上把目标落地成一个一个模块（100%分解）。由于目标不同及客户现状不同，分解后模块也是不同，也就能理解安全运营平台为什么需要定制了，因为它本来就是客户量身设计的，是在运营框架一致性下的百花齐放。
进行安全运营平台建设理念取得一致后，也需要对一些功能进行要求，可能大家会觉得有点矛盾，上文不是说不需要纠结某个技术功能吗？
不要着急，听小编娓娓道来。
为什么这里才开始说功能呢？因为安全运营的建设必须是“自上而下”与“自下而上”同时考虑，既要在顶层上进行整体设计来完成运营的目标，也要考虑核心的管控点。而达成目标的关键点是什么？其实，不管是以“合规”为驱动的政府单位还是以“风控”为驱动的行业运营单位，其运营的框架，都须关注几个核心的细节，这关系到运营质量的问题。它依然不强调技术功能，而是运营机制的核心关注。这个核心关注下，像未知威胁检测、数据安全等平台，是达成目标的平台及工具。
在安全运营平台下，它的核心关注至少应该有以下几点：
▸ 资产管理，强调业务相关性
安全运营必须围绕业务安全，基础资产是这些核心数据的载体。在构建安全运营平台时，应该做好基础资产的发现和管理。通过对资产探测或自身资产梳理，这里不关注具体技术，而是尽量去做到更加精细化的资产识别，如每个域名IP上所部署的应用及服务相关信息，它与业务系统的关系及重要性，一旦这些应用及服务在暴露出来安全风险，安全运营平台能够及时对业务进行定位，确定风险级别及受影响的范围。
▸ 风险检测，强调多元化与持续性
风险检测最重要的就是检测策略。服务风险检测主要包括系统基础服务相关的通用漏洞和服务配置不当的风险检测；应用风险检测主要包括一些应用的通用漏洞和相关漏洞带来的应用风险。由于网络安全在不断变化的过程，也带来了不同的漏洞风险。因此，在风险检测的实现上，尽量做到海纳百川，如引入第三方更加专业的团队，使用更加广泛的工具等。而安全运营平台除了能提供足够好的引擎框架和兼容工具外，也为第三方专家建立提供了策略路径。
持续检测能够避免由迭代更新带来新的安全风险和曾经修复过的安全问题再次出现。此外，通过对持续风险监测的结果进行趋势分析，能够帮助我们发现当前阶段主要面临的安全问题，并为下一阶段的安全建设提供有效的指导建议。至于如何高效地进行持续风险管理？一方面需要能够自主配置周期性的检测，这样可以适应业务的迭代更新频率；另一方面需要支持不定时的手动启动检测风险来满足突发的应用上线。
▸ 及时高效处置，打通安全与业务“最后一公里”
在安全运营中，我们发现的风险或漏洞大都是与业务系统息息相关的，督促业务部门进行整改。这个过程中往往容易忽略两个问题：一是业务部门的研发人员其实是不了解安全的，所以在安全问题及修复过程中可能会存在修复不当的情况；二是对最后修复处理完毕后还要进行及时回归测试，以免造成对业务的其他影响。这两个问题如果解决不好，安全对于业务就不是一个良性的上升机制。那怎么解决这两个问题呢？
我们提出了“打通最后一公里”，也就是在安全运营平台的设计上，安全运营平台应该与业务部门的产品生命周期管理平台进行连通，最好有API直接对接到产品开发上线的流程中去，可以让安全问题作为产品的严重BUG一样得到及时排期修复。同时，在这个过程中，指派专业的安全人员进行跟踪服务，确保问题完全修复，不再反复出现。
不知不觉，关于安全运营平台的讲解已说得口干舌燥了。不过呢，小编还想强调三个重点：
第一、安全运营平台建设并非一蹴而就，它是与安全目标同步发展，需要长期投入及调整的；
第二、安全运营平台不能解决所有安全问题，我们也不能解决所有问题，只能在当下阶段，团结一切可以团结的力量，把安全这件事情做得更好，平台是工具，可以依赖但是不能完全依赖；
第三、安全运营平台是抓手，它可以连接业务，连接其他工具及平台，它需要专业的人在上面对病人进行诊断，每一次诊断问题的时候，没有扎实的技术基本功和行业专业视野，就算给你好的工具也用不好。因此，人员专业性依然是运营结果的第一要素。
Copyright © 启明星辰 版权所有 京ICP备05032414号 
京公网安备11010802024551号
