0
点赞
收藏
分享

微信扫一扫

以安全有效为目标的综合运营

一、安全行业的现状

所有做安全的方案大多会在开始介绍安全的案例,都会列举近期国内外发生的重大安全事件, 基本上都是惨不忍睹,危害巨大。这里就不一一列举了,稍微了解这个行业的人都能看到大量的案例。

但业界又有个很奇怪的现象就是新概念,新词汇层出不穷,暂时把它叫做安全创新吧,比如

HIDS,XDR,PBAC,TBAC,OBAC,BBAC,CBAC,EDR,NDR,TDR,MDR,CBDR,ADR,AIDR,SA,SOAR,CTI,ATT&CK,SIEM,IPS,IDS,WAF,EPP,CWPP,DataDR, BAS, ASM ,ASPM, SAST ,DAST,IAST, CNAPP, XSPM, DSPM等等。估计没有几个厂家能全部说的清楚,绝大多数甲方也是看的一头雾水。仔细分析下来,很多时候一个概念就是一个产品,这个概念到底本质是什么,原理是什么,目标是什么,为什么要用新产品,之前的产品优化下不可以吗?也没人能说的清楚。

安全的目标这二十年来没有发生太本质的变化,唯一的变化就是规模和业务复杂度一直在膨 胀,但计算机的理论又很多年没有发生根本变化。编译原理,网络通讯,操作系统原理,数据结构等很多年变化都不大,那安全的创新有多少是安全本身的创新呢,我个人理解安全创新很多都是跟随了基础架构的发展而顺道利用了这些架构带来的创新,比如hadoop,es, clickhouse等大数据架构的发展,比如html5,http2.0等web的发展,比如spark,flink, kafka等处理能力的发展。从这个角度看,安全就是一种特殊的业务,和oa,erp本质上没有太大的区别,无非就是需求来源不太一样而已。

从安全投入看,各种市场分析报告的结论都是投入一年比一年高。这就难免让人产生一个巨大问题,安全创新一浪又一浪,安全投入一天天涨,安全问题还是很多,到底哪里出了问题呢?


二、原因分析

罗翔老师说:“人最大的痛苦,就是无法跨越知道和做到的鸿沟。”。我认为这个放在安全行业也是非常适合的。安全理念和概念非常好,也很容易理解,但能否落地是个问题。前几天看了15年前的ppt,大概是2006年左右写的,里面的原理,目标,方法放在今天看依然不过时, 那为什么到今天还做不好呢,本质的问题在知易行难,比如SOC中的关键指标关联分析,数据过载,在SOC中没有实现的很好,换个产品态势感知就能实现的好了吗,然后态势感知实现的不好,在换个产品XDR就能解决了吗?如果XDR等能解决这个问题,为什么不优化下算法在SOC中解决呢,计算机的执行都是一行一行代码组成的,所有的产品都是这样的,无非就是性能和功能的平衡,做成一个产品或者多个产品。有些产品拆分是性能问题,有些产品拆分是设计理念冲突问题,但不管怎么冲突也不应该产生这么多分类的产品。


安全没有银弹

《人月神话》书中有个重要的观点,就是软件工程是一个超级复杂的系统,所以断言没有银弹。我认为这句话同样适合安全,安全没有银弹。这本书是最早1975 年编写的,是一本非常经典的软件工程类的书,多次改版,现在看还有很多观点依然适合。

银弹介绍:在欧洲民间传说及19世纪以来哥特小说风潮的影响下,银色子弹往往被描绘成具有驱魔功效的武器,是针对狼人等超自然怪物的特效武器。后来也被比喻为具有极端有效性的解决方法,作为杀手锏、最强杀招、王牌等的代称。


勿在浮沙筑高台

这句话是著名台湾知名电脑技术专栏作家侯捷一本《深入浅出MFC》的一句话,万丈高楼平地起,勿在浮沙筑高台,所谓的基础,就好比是盖房子要打地基一样,没有坚实牢固的地基, 房子就没有稳定性,根基不稳,早晚会造成重大的危害。很多新名词、新技术固然诱人,可是如果自己的基础不扎实,就像是在云里雾里行走一样,只能看到眼前,不能看到更远的地方。这些新鲜的技术掩盖了许多底层的原理,要想真正的做好还是要走下云端,扎扎实实的把基础做好。


三、以安全有效为目标的综合运营

解决安全问题的最根本手段是要打好基础,只有打好基础后才有可能解决更高级的问题,而且很多基础的东西其实并不是不好做,而是数量多,太繁琐,这些繁琐的事情需要耐心。光靠耐心是不够的,所以需要借助一个平台去落地。暂且把这个平台的名称叫运营平台。运营平台的核心是传感器加大脑,说再直白点就是采集加分析。

运营:运营就是对运营过程的计划、组织、实施和控制,是与产品生产和服务创造密切相关的各项管理工作的总称。从定义看运营就是管理和流程,然后用技术落地。综合运营主要包括可采、可知、可查、可视、可感、可控、可验几个核心能力。


有效

安全建设的目标是什么呢,我认为目标应该是在投入和风险接受中取得一个平衡。在进一步说是对安全的指标进行平衡管理。具备包括:杀毒软件安装率,HIDS安装率,病毒查杀率,补丁升级率,漏洞修复率,事故处理及时率,堡垒机使用率,基线检查率等。平衡就是这些指标的高低接受程度和对应的投入。当然总的投入也包括采购设备和人员投入。


可采

信息化主要的基础内容包括物理环境,基础网络系统,服务和终端,应用系统几部分组成。对每一部分都有很多基础指标可以去做。

物理环境部分包括温度、湿度、电流、电压、ups、空调、门禁等信息。 基础网络主要包括设备在线、带宽占用、乱序、超时、重传、漏洞等信息。

服务器和终端包括设备在线、账号、进程、端口服务、网络连接、计划任务、启动项、日志、告警、漏洞等信息。

应用系统包括架构、组件、连接、数据流、部署、日志、告警、漏洞等信息。

可采就是能采集到目标对象上的信息,主要采集指标就看采集协议,正常平台需要支持SYSLOG、SFTP、FTP、JDBC、SNMP、SNMP Trap、httppost、kafka、nxlog、代理服务器等采集协议。对采集协议支持的越多,可以采集的范围就越广。其次看采集效率,正常情况下现代计算机的处理能力是比较强,只要算法和频率没有太大的问题,一般是没有问题的。这里需要平衡采集频率,比如采集性能指标,理论上越频繁约好,但实际上太频繁对设备会产生影响,采集过来的数据也需要分析和存储,需要一个平衡。

以安全有效为目标的综合运营_运营

以安全有效为目标的综合运营_威胁情报_02

可知

可知主要是要把采集过来的数据进行分析转换成有业务含义的数据,比如防火墙日志中把源ip,目标ip,源端口,目标端口,协议等信息单独分析出来,在很多后续分析的过程中,需要更多的维度信息进行处理,比如人员信息,资产信息等;同时计算机对非结构化数据进行关联分析是比较困难的,所以需要把非结构化数据转换成结构化数据。只有结构化分析出来后才能做进一步的利用,比如后面的关联分析,报表等,不然采集过来的的数据仅仅起到备份的作 用,这样价值就小很多。

由于系统繁多而且经常变化,所以平台需要提供灵活的自定义解析规则,无需编程,如果都通过编程实现,成本太大,时间也比较长。平台需要支持从界面或者配置来进行解析,提高易用性,灵活满足不同厂商不同格式的日志解析需求。只有当平台提供足够丰富的解析能力的上时候,才可以快速的适应不断变化的数据。


可查

可查是指数据在需要的时候能查询出来,它的能力主要是采用的软件架构和部署结构有关系, 好在目前大数据存储平台比较成熟,能力也比较强,比如clickhouse,elasticsearch, hadoop等都具备非常强悍的存储和查询能力。但是查询的灵活度决定了产品的方便性。业界做的比较好的是splunk提供的SPL搜索语言,它是是Search Processing Language 的简称, SPL提供了丰富的语法,提供一百多种命令,可让搜索、关联、分析和可视化数据等变的非常简单。使用SPL语言,能够实现从数据获取、分析、可视化整个过程的分析。其中分析包括常见的统计分析、人工智能算法等。SPL以linux管道形式的表达数据分析的过程,更加简单容易理解,把数据分析拆分成步骤,每一步完成数据相应的处理,最终得到分析结果。如果有条件平台可以支持SPL搜索或者类似比较方便的搜索语言来进行查询。


可视

可视就是界面展示了,采集分析过来的数据都在计算机内部,对人是无感知的,平台需要通过人机交互界面来展示内部的数据。由于不同时间不同场景下需要呈现的数据要求不一样,所以系统需要提供灵活的界面展示能力。现在业界平台有个趋势是低代码开发平台,它是无需编码或通过少量代码就可以快速生成界面的开发平台。客户通过可视化的界面操作进行定制界面的开发,(类似可视编程语言),使具有不同经验水平的开发人员,运维人员或者客户可以通过图形化的用户界面,使用拖拽组件和模型驱动的逻辑来创建丰富的界面和简单的逻辑操作。所以运营平台的发展应该支持部分低代码平台来满足日益复杂的界面需求。


可感

可感就是对事件进行感知的能力,这个能力的核心是分析,当然可以是关联分析也可以是机器学习分析,不过机器学习在安全领域的效果目前还不是太明显,所以在现阶段核心的还是用好关联分析。常用的关联分析如下:

基于规则的关联分析

基于规则的关联分析是指按平台预先内置关联规则,或者用户自定义维护的关联规则对安全事件进行分析。平台接收到经过范式化的安全事件以后,通过事件维度与告警规则进行匹配,一旦匹配到符合条件的规则,规则就会被触发。在规则设定的时间窗口内,平台会将多条成功匹配规则的安全事件进行关联,并按规则设定进行告警。

基于统计的关联分析

基于统计的关联分析在用户行为异常分析中也大量使用,需要通过计算前面的一段时间得到阈值,然后根据阈值进行计算偏离的方法。比如日志量异常模型,很多的客户不一定知道平时的日志量到底是多少才是正常的,这个时候就需要进行动态计算,比如今天9点到10点的日志量比前一周9点到10点日志量的平均值大80%。这个情况就可以理解为日志量异常模型。

基于威胁情报的关联分析

系统支持基于威胁情报关联分析,产生告警后,对于源IP,URL等数据信息通过rest接口查询威胁情报的数据接口,比较是否属于恶意IP等,如果是恶意IP在告警页面的详情页面展示告警源IP相关的威胁情报信息。同时系统内置威胁情报告警规则,一旦原始日志IP命中威胁情报恶意IP则触发展示威胁情报告警。

还有一些别的关联分析模型就不一一介绍了,详见其他文档。

以安全有效为目标的综合运营_关联分析_03

可控

可控主要是对产生问题后如何进行处理和控制,这块一般都是通过接口实现,目前常用的接口是ssh接口和http rest接口,这个和具体设备有关系。业界也有个产品SOAR做类似的事情, 但感觉SOAR作为独立产品还是过重,受限于数据和场景的限制,如果能作为运营平台的一部分,就能比较好的发挥价值。当产生告警事故后,经过分析确实是正常的事故,系统可以通过实现定义好的控制接口去下发策略,比如在终端上发现了病毒,可以联动杀毒软件下发杀毒策略或者终端下线策略。比如当发现有高频的密码猜测,可以下发边界防火墙一键封堵攻击者的ip信息。

可控还有个说法叫做策略下发,比如环境中如果有十几台边界防火墙,当做策略管理的时候, 如果一台一台去管理,无疑效率比较低下,如果能通过平台进行批量管理,会极大的提高效率。


可验

可验就是检查验证,主要有漏洞验证和事故处理分析验证,漏洞验证主要是要自动化的去扫描已经修复的设备,检查漏洞是否真的修复完成,这个需要自动化扫描,对比来处理,确定已知漏洞是否修复完成,来提高效率。

事故验证分两种,一种是分析,比如发现了sql注入攻击告警,我能从平台直观的看到攻击者ip信息,payload信息,目标资产信息等,这样比较容易确认事件的准确性,还有种验证是验证处理结果,比如密码猜测攻击封ip,验证是否封ip策略真的下发成功。

以上是运营平台的关键能力,通过以上关键能力然后结合指标来进行运营,可以解决很多问 题,当然还有一些流程的内容,这个和每个客户的管理有关系。最基本还是如何把基本功做 好,就比如如果能了解计算机的每个进程和每个网络连接的含义,安全风险就可以极大的被降低,当然这也运营的目标之一,是比较理想的一种方案。理想是要有的,万一实现了呢!

举报

相关推荐

0 条评论