ArcSight UseCase常见类型简介-ArcSight实战系列之六

释放双眼,带上耳机,听听看~!

UseCase的威力在于两方面:

  1. 采集日志的广度和深度,

  2. UseCase检测思路。

怎么让UseCase发挥检测能力,需要尽可能多(广)和详尽(深)的日志,以及开阔性的检测思路,甚至要带一点“猥琐”。本文介绍了ArcSight Usecase的三种类型,并分别介绍了案例。

1.    什么是ArcSight UseCase?

ArcSightUseCase是指通过ArcSight多种内外部资源的组合、配置来满足某一个或一类基于日志的分析场景需求,所以要实现某个Use Case的前提是有相应的基本日志源,其次要有对日志的分析基本手段和知识(即使没有SIEM工具,人工本身也要有基本的分析方法和解析能力)。


SIEMUseCase是基于日志的,SIEM本身不会产生原始行为检测的判断性事件。所以各位要小心,有些SIEM销售吹嘘的所谓很牛的UseCase时大多会忽略说明有相应日志源的前提,容易误导用户把SIEM当成了一个类似IDS之类,可以产生检测日志的产品(当然有些早期从基于流量分析产品而演进来的SIEM产品的确有此功能)。


ArcSight UseCase很多报警功能的确是基于内部资源Rule实现的,但UseCase不是只有这一种表现形式,除了规则还可能通过仪表板、报表的方式予以展现,所有展现出的内容后面也会有很多其它的内部资源予以支撑,有些会在日志采集的时候就事先做好预处理,所有这些满足某个检测场景的相关资源集合统称为一个UseCase


类似于软件开发的某个功能点一样,UseCase的简单与复杂程度和需求完全相关,所以简单的说有多少个UseCase其实无法真实体现真正的工作量。


2.    ArcSight UseCase利器Rule简介


2.1.  Rule类型


ArcSight的强项是灵活的关联性规则定义资源RuleRule3种类型:


  • Standard:可以定义多种类型事件,在特定时间窗口符合某些关联情况下,触发多少次后在哪种情况下执行何种动作;

  • Lightweight:定义满足某种单一类型的单一事件时对列表(List)资源进行增加、删除操作,此类型规则执行的优先级高于Standard类型规则;

  • Pre-persistence:定义满足某种单一类型的单一事件时对原始事件内容本身进行丰富、修改,此类型规则执行的优先级高于Standard类型规则;

2.2.  Rule定义类型


2.2.1.  简单类型规则(Simple Rule


这类规则指短时间内基于单一类型事件触发动作的规则,其实这也是很多常见的规则。


例如,需求是对Windows Security Event Log进行清除的行为监视。UseCase的编制过程如下:


1.需要监视的Windows版本信息,因为Windows 2003之前和之后的Event Log ID完全不同;


2.确定所有需要监视的Windows设备Security Event Log已经采集;


3.确定Windows Security Event Log清除的审计事件ID,确定此ID的方法很多,我常用的方法就是查阅ArcSight SmartConnectorfor Windows EventLog的说明文档,或者访问:

https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/default.aspx


4.基于上述方法确定,Security Event Log清除后,Windows 2003之前版本会产生ID=517的审计事件,Windows2003之后版本会产生ID=1102的审计事件,分别找两个测试环境进行相应的操作进行验证,获取ArcSight中采集到的原始日志并确定各信息对应的字段;


5.定义相应的原始事件过滤资源(Filter),定义的内容如下(最佳实践是把事件的筛选条件使用Filter来定义,其它资源统一引用此Filter,这样便于统一维护、变更):


6.定义实时报警规则,选择Standard类型;



7.规则适用的事件直接调用之前定义的Filter



8.归并的条件是2分钟内发送1次;


9.定义在第1次满足条件时触发如下动作:


  • 为了易读,设置报警名称;

  • 为了未来做长期的报表(例如年报),将报警的概要信息记录有效期为1年的活动列表中;

  • 调用报警邮件的脚本发送报警邮件(ArcSight本身具备邮件通知的功能,不过邮件显示内容不太易读,所以我们是通过一个自定义的脚本来发送报警邮件);


10.上述规则定义完毕后,可以点击“Test”按钮对之前产生的清除Event Log测试日志进行校验,看规则是否如期望的执行,且各需要字段是否正常。


11.如果测试符合要求,将此规则加入实时运行规则组中,再次在测试Windows环境中清除Event Log,验证规则是否正常触发、列表信息是否更新、报警邮件是否正常发送。


12.如果一切如期望运行,再基于规则记录的列表定制Event Log清除事件报警的月报、年报(由于原始事件不会长期在线保存,如果每次的月报、年报都要从数百亿条原始事件中再次过滤汇总对IO的消耗过大,而且完全没有必要)。


13.规则相关的所有资源引用关系如下图所示;

2.2.2.  关联型规则(Join Rules


这类规则指短时间内基于多种类型事件,这些事件之间存在相同要素的情况下触发动作的规则。


例如,需求是对触发了蜜罐的源地址成功登录了操作系统的行为监视。UseCase的编制过程如下:


1.获取蜜罐系统的报警日志并分析;


2.获取WindowsLinux系统的登录日志(我的环境就这两类操作系统,如果有其它操作系统,例如AIX也一样需要采集相应日志);


3.定义实时报警规则,选择Standard类型;


4.规则适用的事件类型及关联关系定义类似如下;



5.后续其它的设置、测试、上线方法类似其它类型规则,这里就不再赘述了。


2.3.  链式规则(Chain Rules


这类规则主要对于长时间判断的规则,由于ArcSight Rule是在内存内运行的,因此为确保效率、性能,前两种规则的时间窗口不建议大于10分钟,对于超过10分钟以上时间窗口的规则使用此类型规则,真实的场景下,此类规则是使用最多的。


例如,需求是对邮箱慢速密码破解的行为监视。UseCase的编制过程如下:


1.获取邮件系统的登录日志并分析,经过调研发现IPS已经设置了相关的SMTP暴力破解阻挡规则,但是邮件系统的登录失败日志中依旧可以发现很多用多个同网段地址,分别用不同的账号以20-30秒左右的频率来尝试登录,这种慢速攻击的行为IPS的现有规则还无法发现;


2.为更精准的发现SMTP的攻击行为,此UseCase要分几步做:


  • 将所有IPS的相关Use Case报警中超过某个阈值(例如1000次)的源地址(除已知的合作伙伴地址外)放入可疑源地址列表中;

  • 将所有的SMTP登录失败的源地址及账号记录入失败统计列表中并累加次数;

  • 只要上一条规则累加的某个源地址及账号登录失败次数在1天内大于某个阈值(例如100次),将该源地址放入可疑地址列表中;

  • 如果出现SMTP登录成功的源地址及账号在失败统计列表中,且累计次数大于某个阈值(例如5次),或者源地址出现在可疑地址列表中马上报警;

  •  对于通过多个IP分布式的进行慢速攻击,通过报表按C段来统计,每天大于1000次以上的源地址及账号的登录失败汇总信息以报表方式发送进行人工判断。


3.对于IPS报警规则维护的可疑源地址列表,这里不详述,以下主要介绍一下SMTP慢速攻击相关的部分。


4.定义实时报警规则,选择Lightweight类型;



5.条件是SMTP登录失败的事件;


6.动作就是把相关的源地址及用户账号信息分别写入短时间(1天)有效列表和长时间(1年)有效列表,分别用来做累加次数和未来出汇总报表;

7.定义实时报警规则,选择Lightweight类型;

8.条件是上一规则累加发生次数超过100次的源地址及用户账号;

9.把源地址写入可疑源地址列表:

10.定义实时报警规则,选择Standard类型;



11.条件是STMP登录成功的事件,源地址及账号对在失败列表累计次数大于5,或源地址在已知可疑源地址列表中;


12.发送报警通知邮件;

13.继续定义相关的报表,具体步骤不再详述,大致的摘要内容如下。

14.整个Use CaseRule资源关联关系如下图所示。

15.整个Use CaseReport资源关联关系如下图所示。

3.    总结


完整UseCase使用的资源远超过上面介绍的内容,这里也只是做个简述,有兴趣的朋友可以一起交流探讨。最近ArcSight发布了被MicroFocus收购后的新版本7.0,关联引擎支持分布式的部署模式了。

往期文章推荐

ArcSight实战系列:

ArcSight简介            -ArcSight技术系列之一

实施规划和架构设计 -ArcSight实战系列之二

ESM安装配置指南    -ArcSight实战系列之三

Syslog类型Connector安装配置-ArcSight实战系列之四

日志源有效性监控UseCase-ArcSight实战系列之五


时间有限?看此篇

金融业企业安全建设之路

———————————————-

企业安全建设,离不开“守望相助”。金融业企业安全建设微信群,在历次安全事件、安全应急中有大量实况直播,处置措施及时性、有效性,让我自己也获益良多。有兴趣加入的企业安全负责人,请关注微信公众号“君哥的体历”,后台留言,微信号+公司名称,验证身份后入群。


附注:

  • 聂君,信息安全从业人员,十余年金融行业信息安全从业经历,默默无闻。好读书,不求甚解。性格开朗,爱好足球。

  • 本订阅号文章是个人对工作生活的一些体验和经历分享,站在不同角度和立场解读会有偏差,见仁见智,不求正确统一,但求真、善、美。


长按识别二维码,和我交流




赞赏是认同或肯定,更是鼓励更多原创分享


本文源自微信公众号:君哥的体历

人已赞赏
安全工具

企业如何构建有效的安全运营体系

2019-10-16 13:49:56

安全工具

推荐几个公众号

2019-10-16 13:50:05

0 条回复 A文章作者 M管理员
    暂无讨论,说说你的看法吧
个人中心
购物车
优惠劵
今日签到
有新私信 私信列表
搜索