诸子笔会｜孙琦：安全自动化架构设计和集中管理
Posted 安在
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了诸子笔会｜孙琦：安全自动化架构设计和集中管理相关的知识，希望对你有一定的参考价值。
自2021年6月起，安在征文全新“改版”——“诸子笔会，打卡征文”。简单来说，我们在诸子云社群招募“志愿者”，组成“笔友群”，自拟每月主题，互相督促彼此激励，完成每月一篇原创，在诸子云知识星球做主题相关每日打卡，同时邀请专业作者群内分享，互通交流。我们的目标，不仅是在持续8个月时间里，赢取累计8.8万的高额奖金，更是要探索一种脑力激荡、知识分享的新思路和新玩法。本期发文，即诸子笔会月度主题来稿之一。
安全自动化架构设计和集中管理
文 | 孙琦
孙琦
某上市公司信息安全负责人
自动化的安全能力是为了提升安全事件处理速度，降低安全人员工作负荷，目前已经有了很多工具在不同环节实现安全自动化。
作为企业安全掌舵人，我们要平衡好保护核心资产的安全和业务灵活多变的需求。相比绝对安全的概念，我更倾向于通过自动化能力为业务提供最适合的安全防护能力。
随着信息技术的高速发展，IT环境的复杂度和规模不断增加，传统的IT运营方式已遇到瓶颈，通过人工手动管理的方式已经变得越来越难。由于人工配置错误、响应不及时等问题造成的各类事故逐年增加，有些事故造成业务系统暂时不可用，另一些事故则造成了严重的信息安全事件，导致数据泄露等严重问题。
面对日益严峻的安全挑战，我们希望能够在减少人工参与的情况下，通过组合利用各类技术手段，实现安全防护的自动化，用相对较少的人力资源完成海量的安全防护工作，我们应该尽可能把所有信息安全相关的操作都进行自动化。
自动化的前提是大量基础工作完成标准化转化。举例来说，我们要先完成现有安全设备的集中管理，进而实现日志的集中监控，才有可能实现安全活动的协同处理。有了安全活动的协同处理，我们便能将更多的精力投入到安全体系建设上，毕竟对比自上而下、伤筋动骨的安全体系建设，从技术角度推动的安全自动化要相对容易很多。
企业信息化建设是一个系统性的工作，安全团队绝不是以闭门造车的方式去构建一个个坚固的安全堡垒，更多的是需要和IT、业务等团队不断交流互动，以安全团队主导、全员参与的形式共建一个动态的大安全防护架构。
首先，我们应该先盘点一下自己手上的安全资产。传统防火墙、应用层防火墙、IPS、VPN等等，这些是我们最常见的一些安全资产。
1.资产识别，明确资产的Owner和应用场景；
2.SSO统一登陆，尽量通过统一的认证源完成身份认证；
3.统一报警输出，构建统一的告警输出能力；
4.统一日志输出，使用统一的日志格式、字段等要素；
5.资产自动发现，周期性检查资产状态。
这里分享一些工具给到大家，方便大家在这个阶段更好的完成这些任务。SSO，我们最常见的就是微软的Active Directory,大部分设备也都支持与AD的集成认证，对于日后的日常维护非常友好。报警输出，我们用的最多的是SMTP通过邮件的方式进行输出，企业内部可以用自建的SMTP服务器进行发送，也可以采用外部的免费SMTP服务，这里需要注意的就是外部的SMTP服务可能会存在一些限制，具体你使用的SMTP服务商为准。日志格式，我们可以使用标准的syslog进行统一输出，如果你后期需要灵活调整，可以考虑在后期通过对原始syslog日志进行二次加工进行利用，比如用grok等进行字段切分后的统一输出利用。资产自动发现，这里其实可以用的工具非常多，比如像nmap、图形界面的诸如ARL。
资产发现工具：
日志处理（原始日志）：
统一标准化后的日志：
示例：
我们通过使用grok(\[%{TIMESTAMP_ISO8601:date}\] %{WORD:Field1}\(%{WORD:Field2}:%{WORD:Field2}\): %{GREEDYDATA:Field3})进行原始日志的标准化处理，本例中，我们通过grok的表达式将上述日志进行标准化转换得到我们想要的结果。这里推荐大家一个工具Grok Debugger （http://grokdebug.herokuapp.com/?#）。
有了底层基础，我们就可以开始把自动化安全体系逐步搭建起来了。目前很多企业已经在DevSecOps的实践中实现了CI\CD环节中的自动化实践，例如通过使用SonarQube去集成各类静态代码扫描工具（如Fortify、Checkmax等）实现代码安全管理；通过整合Jenkins和各类安全扫描工具（如ZAP、SQLmap等）实现持续安全扫描管理；通过整合自研VMS（漏洞管理系统）和SonarQube、Jenkins等工具实现了自动安全事件管理，系统根据规则创建case，后台人员根据case处理风险，实现安全管理闭环。
在大安全的框架下，可以根据事件处理的思路进行设计。
根据日志生成tag判断是否需要生成对应的case，即满足规则了就要立即处理，不满足的日志归档处理。这个一个整体的安全自动化处理思路，在这个思路上，我们再去逐步拆分其中的细节。
我们目前采用的是基于日志生成的自动化响应，其判定为威胁并需要生成case的情况比较简单，依赖于日志原中自带的威胁告警级别，如果是高风险，直接生成case，其余均标记为“信息”并打上对应的威胁级别进行归档处理。也许你会有疑问，难道除了高风险的问题，其他的问题都不处理？非也，只是因为人员和精力有限，只能处理最重要的问题。由于是以日志作为威胁的判定标准，就决定了我们在进行威胁处理的时候会存在大量的“误报”的case，虽然我们做了威胁对象的汇聚处理，但在真实环境中，依然难以摆脱“误报”偏高的情况，在现有条件下，我们选择辛苦“人”的方式来提升安全防护等级。
这里我想介绍一个开源项目TheHive，其本身的定位是一个开源的事件处理平台，结合ELK、Cortex、MISP实现威胁事件的处理，我本人目前是从0到1正在学习这个项目。我们目前是通过自研的方式做了类似的平台，威胁情报部分是集成了国内某知名品牌的产品，但这个丝毫不影响我们从技术角度对这个平台的研究。
对于预算有限的同学，可以从这个平台先入手玩起来，毕竟我们有很多工具都是从开源项目逐步转化而来的。
项目参考：https://github.com/TheHive-Project/、http://docs.thehive-project.org/thehive/
有了自动化平台，我们完成了威胁的从发现到等待处理的自动化处理，其中最大的问题是“误报”，这是我们必须直面的一个问题。
在这部分，我们开始尝试用自动化响应的方式来实现发现威胁、处理威胁、解决威胁。短时间内高频发生的case，快速block source IP；特定时间内汇聚到一定数量的case，人工介入review；普通case也一并由人工确认后再安排对应的处理策略。未能大量使用自动化技术处理的原因是复杂的，我们发现自动化会对业务产生中断的影响，这让我们在推行自动化的时候感到非常“通”。
这部分技术更多的是通过接口实现策略的调度。大部分安全产品都有成熟的文档，结合起来并不是很困难，最大的挑战在于联调以及触发策略后对于业务是否会造成异常的判断逻辑。
目前，我们已经在自动化技术上实现了半自动化的处理安全事件的能力，但并未真正的全面启用，仅在部分节点进行了尝试，主要原因还是在于复杂业务场景下的业务中断风险。实现安全事件从产生到处理完毕的自动化并不难，真正困难的是真实业务场景下的安全自动化行为。
此外，单一以日志位基础的安全事件处理能力也存在一定缺陷，我们试图结合全域网络流量进行威胁建模，发现潜在的安全问题，作为另一个安全事件的发现源头，目前这块还在摸索中，主要难题在于全加密环境下的数据流量分析以及威胁识别，我们期待这块在近两年能够有所成就。
自动化的安全能力是为了提升安全事件处理速度，降低安全人员工作负荷，目前已经有了很多工具在不同环节实现安全自动化，作为企业安全掌舵人，我们要平衡好保护核心资产的安全和业务灵活多变的需求。相比绝对安全的概念，我更倾向于通过自动化能力为业务提供最适合的安全防护能力。
诸子笔会 | 7月征文主题《安全自动化》
诸子笔会 | 6月征文合集《安全数字化》
齐心抗疫 与你同在 
以上是关于诸子笔会｜孙琦：安全自动化架构设计和集中管理的主要内容，如果未能解决你的问题，请参考以下文章