中小型企业如何自动化安全运营；安全脚本维护与有效性检测策略| FB甲方群话题讨论

官方公众号企业安全新浪微博

FreeBuf.COM网络安全行业门户，每日发布专业的安全资讯、技术剖析。

FreeBuf+小程序把安全装进口袋

观点

中小型企业如何自动化安全运营；安全脚本维护与有效性检测策略| FB甲方群话题讨论

2024-08-30 17:20:04

所属地上海

各位 Buffer 晚上好，FreeBuf 甲方群话题讨论第 243期来了！FB甲方社群不定期围绕安全热点事件、前沿技术、运营体系建设等话题展开讨论，Kiki 群助手每周整理精华、干货讨论内容，为您提供一手价值信息（文末有帮会福利）。

话题抢先看

1. 除了网络攻击IP封锁、短信/登录接口爆破IP封锁，还有哪些场景可以用到自动化运营技术？
2. 实现自动化安全运营，除了Python/Shell，还有什么其他方式？
3. 有什么比较好的工具可以方便地对大量运营脚本进行维护/调试？目前脚本是部署在Linux服务器上，主要是通过Systemctl和Crontab进行管理。
4. 当需要维护的脚本达到上百个时，如何快速进行脚本有效性/可用性检测？例如自动封禁网络攻击IP的脚本，长时间不触发告警，可能是因为真的没发生过攻击，也可能是因为此时脚本代码有BUG碰到异常没法执行，也可能是因为云安全产品的接口超时/异常等等。

话题：针对自动化安全运营的技巧

背景：某中小型企业在进行安全建设，现在已有基本的安全产品并且已投入运营，但是比较依赖人工，希望通过自动化来提升效率。

Q：除了网络攻击IP封锁、短信/登录接口爆破IP封锁，还有哪些场景可以用到自动化运营技术？

A1：

病毒查杀、回收终端权限、账号封禁。

A2：

自动化暴露面采集和分析。

A3：

安全事件自动化分析、安全溯源自动化、安全运维工作自动化。

A4：

自动化筛简历，人永远是信息安全的第一道防线。

A5：

企业微信的告警机器人，可以配置好策略联动后，自动下发告警。

A6：

引入SOAR，针对业务场景定制化安全威胁的事前告警、事中阻断和事后溯源。

A7：

告警降噪，日志格式解析统一，标准化要先做好，这我感觉就不是中小企业能做到的。

A8：

ITSM事件管理、安全事件分析溯源、漏洞扫描与管理、基线安全检测与分析。

A9：

基于图数据库，自动化串联攻击链，后续出报告。

A10：

堡垒机加命令黑名单，防止IT尤其高权限IT内鬼在生产上执行恶意命令。

A11：

在数据采集方面，自动化可以帮助解决IP限制、反爬虫策略等问题，提高数据采集的效率和稳定性。通过API代理的API接口，自动化工具可以突破地域限制，访问被屏蔽的站点，进行数据采集‌。

A12：

自动化可以和OA联动，申请策略以后自动配置端口开放、访问策略这些配置。

A13：

分对内和对外吧，对内还可以有异常行为分析，告警降噪，对外可以加上漏洞情报分析，加上SIEM。

A14：

三个维度
桌管：自动化组策略、软件分发、账户管理等、邮件策略等
网管：自动化拦截策略脚本、日志收集、监控、分析、基线检查脚本
系统管理：自动化安全基线检查、监控 Ansible+Zabbix+ELK、Splunk等。

A15：

可以通过收集的攻击手法通过自动化脚本来进行本地安全能力验证。

A16：

IOC关联、资产关联、历史风险关联这些都能自动化吧，甚至你还能让AI给你打个相关系数分。

A17：

SOC平台的日志接入AI平台进行关联分析，然后针对高风险告警做定向邮箱或者短信推送。如果有态势感知平台的话，就直接使用SOAR平台编排剧本进行自动化封堵。

A18：

如果投入的资金比较大就自建，不行就采购产品，有专门的安全产品日志整合统筹，和自动soar自建的话主要是解决数据格式同步，判定规则来源，判断算法这些。

A19：

其实，中小企业表示 , 我们都没钱搞这些，不花钱是宗旨。

A20：

今天刚讨论完：
1、自动化资产扫描 +自动化漏洞检测
2、自动化任务管理（漏洞扫描+任务触发+补丁下载+修复）
3、自动化基线扫描/自动化基线加固-----我已经在做了
4、自动化流量分析+预警+与资产联动+与安全设备联动自动阻截
5、基于资产进行自动化的威胁分析+资产态势感知---包括新资产的发现+自动化扫描+自动化修复+自动化加固
6、操作系统模板镜像级自动化加固
7、数据库自动化安全评估+检查
8、技术层面的合规自动化扫描（基于27001、等保、Gdpr）
9、半自动化合规评估+自测评
10、自动化终端安全评估、服务器安全评估、数据库安全评估+部分自动化整改

A21：

自动化的本质，就是HC。某司几年以前推了一个自动化机器人的项目，帮助业务部门减少重复性的工作，很受业务部门欢迎，但在项目2期的时候，某个TOP管理层提了一个问题，1期花了这些钱做这个项目，最终业务部门能裁多少人？4个业务部门统计说总共2个HC，每个业务部门0.5个HC，可是没办法裁0.5个人，所以保持现状。最后项目2期和后续项目全部取消。每个业务部门的老板都不愿意自动裁HC。

Q：实现自动化安全运营，除了python/shell，还有什么其他方式？

A22：

Ansbile 、Terraform、Puppet 、Chef 、Splunk、Qradar。

A23：

SIEM+SOAR。

A24：

SOAR，或者其他低代码平台，但是本质还是shell脚本，通过拖来组件的方式只是降低了使用难度。

A25：

有钱——SOAR，没钱——没钱搞啥自动化，不过可以用一些其他的GO之类的，只要达成目的，把要封的指令给到FW等设备。

A26：

要是自写脚本的话，Perl、C#、Java、GO 这些用的比较多一些，其实最好用的是Excel+VB。

A27：

现在还是PY吧，Excel + VB ，WPS用不了啊。

A28：

不要在乎语言，只要是能实现自动化的工具，语言都可以上，重要的是切中可以自动化，提高效率的手段。

A29：

只要设备支持，啥语言都可以的。设备不支持，啥语言都没用。

A30：

设备不支持的话，上一个机器人UIpath，也可以解决问题。各种编程语言，各种自动化运维工具，各种无人值守机器人。

Q：有什么比较好的工具可以方便地对大量运营脚本进行维护/调试？目前脚本是部署在Linux服务器上，主要是通过Systemctl和Crontab进行管理。

A31：

QingLong

A32：

Ansible

A33：

AirFlow

A34：

Supervise挺好用的。

A35：

其实不单是维护和管理，还涉及到用户/组权限管理，脚本数据备份，版本控制。其实有devops的公司能自己拿开源的来设计一套，GitHub上有些开源项目可以参考——Devops-Project。

Q：当需要维护的脚本达到上百个时，如何快速进行脚本有效性/可用性检测？例如自动封禁网络攻击IP的脚本，长时间不触发告警，可能是因为真的没发生过攻击，也可能是因为此时脚本代码有BUG碰到异常没法执行，也可能是因为云安全产品的接口超时/异常等等。

A36：

总体思路应该也是模拟环境自动化验证反馈，写脚本的时候定好验证规范，然后批量跑，成品的工具没看到过。

A37：

这个最近就碰到过，准备在结果格式化上入手，所有的脚本都有输出日志，对日志格式化结果进行定期检测，目前是这个思路。

A38：

对脚本也需要分级分类管理，区分影响度和重要性。
对如测试或预生产环境，与生产环境一致性较好的，可以定期通过测试环境验证。
对影响度较小，可在非业务高峰期有计划的验证。
对影响度较大的且业务连续性要求高的，考虑人工定期走查验证。

A39：

之前也碰过类似情况，比如雷池waf升级，为了验证升级后不影响脚本，就得手动发起攻击去触发拦截和拉黑。完事后还得从黑名单里把自己IP放出来，再之前试过某厂商WAF的日志字段名改了，导致我的脚本异常，还是自己无意发现的。感觉针对这个问题，没太大好办法，只能是巡检的时候把脚本测试也加进去。只能说以前是很LOW地巡检防火墙什么CPU性能安全日志这类东西，现在变成巡检自己写的东西并确保的确能正常工作。

A40：

1、用BAS系统定期发送验证用例，对IP封禁等重要功能的有效性进行监控；2、对脚本报错和异常进行巡检。

A41：

把BAS当作安全能力的监控工具，其实还挺好用的，会发现WAF覆盖不全、NTA流量丢包、SOC延迟这些问题，评估安全设备能力这块，各家厂商现在都对主流的BAS厂商的检测规则做了针对性优化，验证结果都很高，有点假。

A42：

感觉BAS在目前这个环境下面似乎太超前了一点，想法是好的，但是生产系统谁也不敢这么大规模的搞，还是把传统的全流量和少量SOAR，以及基于Ansible的自动化运维扫描做好，还可以搞一个AI+聊天机器人，代替部分人工。

A43：

感觉BAS还不太成熟，都是采用攻击流量重放，对靶机模拟POC来模拟。就是POC的那些，可以用于自动化渗透和BAS，你可以选择不打靶机，打你生产环境。

A44：

想问问BAS的模拟攻击，这些库咋来的?

A45：

厂家提供更新。

A46：

更新是更新了，你咋知道他的模拟有效呢，还有自定义的咋弄，当你不知道他的规则确实有效，不是跟没买一样么。

A47：

先看覆盖率，再看暴露风险。覆盖率通过已有安全能力的告警规则量跟TTPs的覆盖率，暴露风险看安全能力没覆盖到的那部分。

A48：

我以前对上网行为设备要求做人肉验证，做了一段时间就发现，这个东西有点看缘分，我的意思是，网站的收录你都不完整，如何确保你的规则有效，所以上面说的覆盖能力，就好像规则一样，大项能力覆盖到了，小项无法覆盖。

A49：

你说的问题几乎绝大部分规则类的系统都存在或者说，检测类系统都存在这类问题，只能做到相对，做不到绝对。

A50：

所以上个BAS的意义是没啥上了，上一个机器人保安看下门，他如果看不住土匪，也不能全怪他么。。。

A51：

BAS的意义不是用来做漏洞验证的，是来验证你的安全设备是不是能有效拦截的，如果BAS的POC不对，最多也就是说明针对安全设备的验证是误报,他并不直接针对漏洞。

A52：

这个问题如果泛化下：就是在安全领域Verification是否有存在的必要？

A53：

BAS跟自动化攻击工具是两个方向。譬如流量重放、横向模拟，这些让自动化来做基本不太现实。

A54：

BAS要做好确实不容易，通过BAS验证安全设备有效，最多也只能说明能防护某类攻击，而不能说明能100%防住这类攻击，因为POC是变化的，一般情况下不可能把所有POC都写出来。

A55：

嗯，所以目前看，主要的方式还是靠：量大管饱。我看SafeBreach也是这样。

A56：

那我直接把设备可用性监控好，然后多搞几次渗透测试，不是比上BAS好？

A57：

要到红蓝程度，你如果每周能搞一次红蓝，那应该比BAS每周扫描一次效果好。

A58：

红蓝有几个问题：1是覆盖性不行，2是很难周期性，3还有就是红蓝很难规范化起来，连评个科学的分值都是个问题。

A59：

说白了，BAS就是和安全设备做对抗、做竞争，如果安全设备更强，BAS就没有意义。

A60：

对，还是覆盖度的问题，红蓝是靠攻击队的经验积累，BAS靠厂商积累。

A61：

所以自动化的前提是规模化，如果资产够多收益就大。如果本来就没有多少资产，还不如人工。

A62：

肯定了，而且不仅仅是资产多，主要是安全设备和能力多，网络环境复杂。因为变化是必然存在的，那变化的过程中就可能导致之前有效的东西失效了，开发在变更代码的时候还要做验证做测试，但是安全设备调整策略、更新规则、网络架构变更的时候不一定验证了安全有效性。

本周话题总结

中小企业在安全建设中通过自动化技术提高效率，应用场景包括IP封锁、安全事件分析、漏洞管理等。面对上百个脚本的维护和有效性检测，可利用Ansible、AirFlow等工具进行管理，并定期通过模拟环境验证。自动化技术选择不仅限于Python/Shell，还包括SOAR和低代码平台。尽管自动化带来效率提升，但覆盖率和规范化仍为挑战。安全验证是必要的，以确保策略和设备有效适应网络变化。未来，自动化安全运营将更智能和集成，但人工参与在策略制定和关键决策中仍然至关重要。中小企业在实施自动化时，需要平衡投资与回报，确保自动化解决方案真正提升安全运营效率。

近期群内答疑解惑

Q：业务重要还是被打穿通告重要？

A1：
没打穿之前业务重要。
A2：
关闭业务？那不是运营商的做法么。
A3：
临停。与是否挣钱无关，重点是1）业务影响度、影响面多大 2）抗不抗揍，比如测试系统、开发系统，大部分是不抗揍的。
A4：
通盘考虑吧，能关闭的都不是最重要的系统；简单做个业务BIA分析，定性一下重要性和关闭/非关闭的风险和必要性，在HVV期间，针对不那么重要的可以采取临停、关闭互联网权限等方式来规避风险；从另外一个方面，通过HVV来检验自己的短板和缺点，从而正视自己面临的风险和威胁，也是对自己有帮助的，一味的关闭系统来躲避、逃避风险，没有起到真正的安全保护能力。
A5：
其实我在想，有没有安全降级这个说法。就是针对可能存在的攻击，对于一些不重要的，或者平时整改不到位的业务进行关闭。或者限制。类似业务降级一样，在大流量或者资源紧张的情况下关闭一些不挣钱的功能。就是这个能不能成为一个规则，如果你平时整改不到位，我们认为对抗攻击有风险，那就这个状态下就关掉。我说的这个业务降级跟安全无关的那种，就是在尽量减少收入损失为目的。
A6：
一般不建议建立规则，一旦建立规则，就意味着会有坑有洞，容易被一堆人瞎BB ，最贱的一句：你说的关闭啊，回头过了HVV被打穿了也是你的责任，说难听点，你是咸吃萝卜淡操心。是否存在业务损失、是否流量、资源进展不是你的责任，你为啥要去建议关停、临停、关闭权限呢？
A7：
记住一点：你是安全口的，你的唯一目标是安全保护，而不是出主意甚至说业务可以自行降级，业务非要降级，那OK，而不是安全口建议你降级的，那你该要钱要钱，该扩容扩容啊。

Q：我想问一下，各位的机房里的系统是如何部署IPv6 的？例如机房里只有一个公网IPv4地址，通过反向代理服务器，映射相应的端口到内网的应用系统，如果使用IPv6后，是在网关上使用NAT64转到内网服务器，还是通过其他的形式？

A1：
把域名解析到一个IPv6地址，搞一个IPv6 LB，内网仍然4。
A2：
前边挂一个Saas版的WAF厂商会给你提供IPv6解析的。
A3：
机房的方法很多种，比如NAT64双栈部署、隧道等，针对你这个案例NAT64比较好，直接NAT64就行。
A4：
这个取决于机房的情况，理论上讲，最佳的方案是IPv4和IPv6双栈，也就是IPv4走NAT，IPv6是每台机器都有，通过防火墙直接访问公网，但是这个方案吧，不是每个机房都有条件搞，所以就可能比较别扭了。
可以考虑IPv6也走NAT，但是这么搞，一个是多了一层NAT损耗，失去了IPv6的优势，二个是你还是得给每个机器配置一下内网段的IPv6地址，麻烦也不少。
有条件还是双栈，但是防火墙的管理得跟上。如果有一些管理上的要求那就得多考虑。但是防火墙起码可以保证你的拥有IPv6地址的IPv4内网机器不会被反向连接到。
A5：
其实还是看你的需求，是要实现V6，还是管控V6，如果你机房内部的设备都是V4的，大可不必担心IPv6的安全性。如果做了NAT64的话，相当于得把NAT64的日志保存下来。目前我知道的NAT64的设备都不支持做XFF的，看不到源地址。你现在考虑的是入方向的防御安全还是出方向的溯源？
A6：
考虑入方向的防御安全，现在我就碰到这个问题，假设在内网的WAF看到的请求都是64转换后的IPv4地址，有时候想封都封不了，因为正常业务也是转成这个地址。
A7：
在机房这个层面没法解决，我们是买的云WAF，支持IPv6版本的。恶心就恶心在这些NAT64设备上。我接触的几家都实现不了，但是不代表市面所有厂商的都实现不了，可以具体了解了解。
A8：
云WAF支持XFF是吗？
A9：
不是啊，云WAF在你NAT64之前就把V6地址防御住了。想封IP的话可以在云WAF上封。
A10：
我们有一台WAF是架设在内网的，现在是请求先到反代，反代再转发到内网WAF，内网WAF再转发到业务系统。
A11：
云上WAF在最外层、有一个好处就是隐藏真实公网IP。
A12：
你这种WAF放在最前边就行，只要支持V6根NAT64的就行，可以用云的，也可以用开源的。具体的你综合成本考虑下。
A13：
我想了一下，可能还是不行，我们的反向代理服务器前面还有一台防火墙做地址转换，我们的服务器是放在云上，就是政务云的防火墙，先做地址转换，然后才到我们的方向代理服务器，现在IPv4是通过端口映射。
A14：
为什么要NAT64？你防火墙不是支持V6吗？
A15：
防火墙支持V6，但防火墙不在我们手里，在政务云的人手里，他们那边说V6就是做NAT64。
A16：
你一路边界双栈进来到你的墙，再到反向代理，反向代理把V6地址插XFF里就完了，你的反向代理分配个内网V6地址，除非内网那层没有V6，如果防火墙或者均衡给你64转化了，那你后面不可能拿的到V6地址，64转换是在TCP层的，不是应用层。
A17：
是的，所以政务云那边说，他们那边只能做NAT64，我的原意是内网的反向代理分配一个V6的地址，如果V6的请求直接到反向代理上，反向代理就可以把它插入到XFF，因为内网WAF是支持从XFF里识别V6地址，因为之前没搞过，也不知道大家是怎么部署的，所以就上来问一下。
A18：
NAT64是不符合最新工信部V6推进政策要求的。如果边界只能NAT64那么WAF舍弃源地址有关的策略，不同行业实现也不同，但V6应用前列的行业是很少在边界就NAT64的，至少双栈到DMZ。
A19：
想问一下现在符合工信部最新政策的应该是什么部署方式？
A20：
深入推进IPv6规模部署和应用2024年工作安排。

Q：大家对于轻代理的Agent这种服务器部署模式，是怎么平衡的？比如，做监控要装Agent，主机安全要装Agent，蜜罐伪装代理要装Agent，都是直接装到服务器上吗？会不会造成服务器出现异常？

A1：
有预算的话还是接入一个中转平台，适配各种Agent。
A2：
主机HIDS 不就有低交互蜜罐能力（端口+文件蜜罐），真实业务系统为啥还要装单独蜜罐Agent（另外就算主机HIDS没有这个能力，真实业务系统所部署的服务器，有几个会去装蜜罐Agent呢。
A3：
很多时候也就重保时期开一开。
A4：
蜜罐这东西，我觉得，要装就装没服务也没访问的服务器，装到你生产或者测试服务器上没意义，他本身就有访问，你装个这个还得排除误报，装到没访问的服务器，重保时候用就刚刚好，原则就是，有访问流量，就不对，就封源就对了，误报是可以慢慢消除的。蜜罐装业务服务器上，我们这边最显著的就是。邀请攻击队打的结果是有24％的概率在攻击队一突破，其它设备没反应的情况下，蜜罐先发现。
A5：
内网蜜罐我理解，如果HIDS有，基于HIDS 的能力就做了，如果没有，肯定也不是装在真实业务系统所在服务器上的，主要是增加感知，在每个VLAN中新搞几台服务器，开启一些蜜罐服务就行。某安应该有专门硬件蜜罐中继，不用单独搞一些服务器来提升蜜罐感知范围。
A6：
HIDS的蜜罐结合，我用起来有点问题。业务仿真度差，扩展性也差。确实可以在VLAN放新资源部署。只是我们这边的建设策略是内网100重要业务都影子化，也就是，一个业务会有好几个实体蜜罐存在在好几个网段中。还是下了一些资源血本的，但是国内搞蜜罐还是太抽象了，监管天天问，也没有关于这一块的政策。只能放内网，内网搞，想做点事，又会有各种角色部门出来挑战，问厂商放在业务主机AG会有多大的增加延时范围，一问三不知。都是只想着有这个功能，但是不考虑客户怎么用它。
A7：
国内蜜罐产业有个尴尬点，高级黑客一闻就知道这东西是蜜罐、低级黑客一般的传统安全能力就能发现、要蜜罐干嘛？溯源抓人？所以这细分行业很难发展。