大型互联网公司如何防止黑客入侵?(下)
本文最后更新于927天前,其中的信息可能已经有所发展或是发生改变。

入侵威胁预警是否真的有效?

而时下最火爆的AI是否也可以对黑客入侵做出有效的检测~

想知道吗?那就快来阅读今天的推送内容吧!

入侵检测基本原则

大型互联网公司如何防止黑客入侵?(下)

不能把每一条告警都彻底跟进的模型,等同于无效模型。入侵发生后,再辩解之前其实有告警,只是太多了没跟过来/没查彻底,这是“马后炮”,等同于不具备发现能力。

所以对于日均告警成千上万的产品,安全运营人员往往表示很无奈。我们必须屏蔽一些重复发生的相似告警,以集中精力把每一个告警都闭环掉。这会产生白名单,也就是漏报,因此模型的漏报是不可避免的。

由于任何模型都会存在漏报,所以我们必须在多个纬度上做多个模型,形成关联和纵深。

假设 WebShell 静态文本分析被黑客变形绕过了,在 RASP(运行时环境)的恶意调用还可以进行监控,这样可以选择接受单个模型的漏报,但在整体上仍然具备发现能力。

既然每一个单一场景的模型都有误报漏报,我们做什么场景,不做什么场景,就需要考虑“性价比”。

比如某些变形的 WebShell 可以写成跟业务代码非常相似,人的肉眼几乎无法识别,再追求一定要在文本分析上进行对抗,就是性价比很差的决策。如果通过 RASP 的检测方案,其性价比更高一些,也更具可行性一些。

我们不太容易知道黑客所有的攻击手法,也不太可能针对每一种手法都建设策略(考虑到资源总是稀缺的)。

所以针对重点业务,需要可以通过加固的方式(还需要常态化监控加固的有效性),让黑客能攻击的路径极度收敛,仅在关键环节进行对抗。起码能针对核心业务具备兜底的保护能力。

基于上述几个原则,我们可以知道一个事实,或许我们永远不可能在单点上做到 100% 发现入侵,但是我们可以通过一些组合方式,让攻击者很难绕过所有的点。

当老板或者蓝军挑战,某个单点的检测能力有缺失时,如果为了“政治正确”,在这个单点上进行无止境的投入,试图把单点做到 100% 能发现的能力,很多时候可能只是在试图制造一个“永动机”,纯粹浪费人力、资源,而不产生实际的收益。

将节省下来的资源,高性价比的布置更多的纵深防御链条,效果显然会更好。

入侵检测产品的主流形态

入侵检测终究是要基于数据去建模,比如针对 WebShell 的检测,首先要识别 Web 目录,再对 Web 目录下的文件进行文本分析,这需要做一个采集器。

基于 Shell 命令的入侵检测模型,需要获取所有 Shell 命令,这可能要 Hook 系统调用或者劫持 Shell。

基于网络 IP 信誉、流量 payload 进行检测,或者基于邮件网关对内容的检查,可能要植入网络边界中,对流量进行旁路采集。

也有一些集大成者,基于多个 Sensor,将各方日志进行采集后,汇总在一个 SOC 或者 SIEM,再交由大数据平台进行综合分析。

因此,业界的入侵检测相关的产品大致上就分成了以下的形态:

①主机 Agent 类:黑客攻击了主机后,在主机上进行的动作,可能会产生日志、进程、命令、网络等痕迹,那么在主机上部署一个采集器(也内含一部分检测规则),就叫做基于主机的入侵检测系统,简称 HIDS。

典型的产品:国内有很多做入侵检测类的产品,具体效果各有分说,江民病毒威胁预警在同类型产品中做的较好,感兴趣可以关注一下。当然,一些 APT 厂商,往往也有在主机上的 Sensor/Agent,比如 FireEye 等一些产品都做得不错。

②网络检测类:由于多数攻击向量是会通过网络对目标投放一些 payload,或者控制目标的协议本身具备强特征,因此在网络层面具备识别的优势。

典型的产品:Snort 到商业的各种 NIDS/NIPS,对应到 APT 级别,则还有类似于 FireEye 的 NX 之类的产品。

③日志集中存储分析类:这一类产品允许主机、网络设备、应用都输出各自的日志,集中到一个统一的后台。

在这个后台,对各类日志进行综合的分析,判断是否可以关联的把一个入侵行为的多个路径刻画出来。

例如 A 主机的 Web 访问日志里显示遭到了扫描和攻击尝试,继而主机层面多了一个陌生的进程和网络连接,最后 A 主机对内网其他主机进行了横向渗透尝试。

典型的产品:LogRhythm、Splunk 等 SIEM 类产品。

④APT 沙箱:沙箱类产品更接近于一个云端版的高级杀毒软件,通过模拟执行观测行为,以对抗未知样本弱特征的特点。

只不过它需要一个模拟运行的过程,性能开销较大,早期被认为是“性价比不高”的解决方案,但由于恶意文件在行为上的隐藏要难于特征上的对抗,因此现在也成为了 APT 产品的核心组件。

通过网络流量、终端采集、服务器可疑样本提取、邮件附件提炼等拿到的未知样本,都可以提交到沙箱里跑一下行为,判断是否恶意。

 

典型产品:FireEye、Palo Alto、Symantec、微步。

⑤终端入侵检测产品:移动端目前还没有实际的产品,也不太有必要。PC 端首先必备的是杀毒软件,如果能够检测到恶意程序,一定程度上能够避免入侵。

但是如果碰到免杀的高级 0day 和木马,杀毒软件可能会被绕过。借鉴服务器上 HIDS 的思路,也诞生了 EDR 的概念,主机除了有本地逻辑之外,更重要的是会采集更多的数据到后端,在后端进行综合分析和联动。

也有人说下一代杀毒软件里都会带上 EDR 的能力,只不过目前销售还是分开在卖。

典型产品:杀毒软件有江民、SEP、赛门铁克、卡巴斯基、McAfee ;EDR产品不枚举了,腾讯的 iOA、阿里的阿里郎,一定程度上都是可以充当类似的角色,相对来说江民EDR专业性更强一些。

入侵检测效果评价指标

首先,主动发现的入侵案例/所有入侵 = 主动发现率。这个指标一定是最直观的。

比较麻烦的是分母,很多真实发生的入侵,如果外部不反馈,我们又没检测到,它就不会出现在分母里,所以有效发现率总是虚高的,谁能保证当前所有的入侵都发现了呢?

但是实际上,只要入侵次数足够多,不管是 SRC 收到的情报,还是“暗网”上报出来的一个大新闻,把客观上已经知悉的入侵列入分母,总还是能计算出一个主动发现率的。

另外,真实的入侵其实是一个低频行为,大型的互联网企业如果一年到头成百上千的被入侵,肯定也不正常。

因此,如果很久没出现真实入侵案例,这个指标长期不变化,也无法刻画入侵检测能力是否在提升。

所以,我们一般还会引入两个指标来观测:

  • 蓝军对抗主动发现率

  • 已知场景覆盖率

蓝军主动高频对抗和演习,可以弥补真实入侵事件低频的不足,但是由于蓝军掌握的攻击手法往往也是有限的,他们多次演习后,手法和场景可能会被罗列完毕。

假设某一个场景建设方尚未补齐能力,蓝军同样的姿势演习 100 遍,增加 100 个未发现的演习案例,对建设方而言并没有更多的帮助。所以,把已知攻击手法的建成覆盖率拿出来,也是一个比较好的评价指标。

入侵检测团队把精力聚焦在已知攻击手法的优先级评估和快速覆盖上,对建设到什么程度是满足需要的,要有自己的专业判断(参考入侵检测原则里的“性价比”原则)。

而宣布建成了一个场景的入侵发现能力,是要有基本的验收原则的:

  • 该场景日均工单 < X单,峰值 < Y单;当前所有场景日平均<XX,峰值 <YY,超出该指标的策略不予接收,因为过多的告警会导致有效信息被淹没,反而导致此前具备的能力被干扰,不如视为该场景尚未具备对抗能力。

  • 同一个事件只告警首次,多次出现自动聚合。

  • 具备误报自学习能力。

  • 告警具备可读性(有清晰的风险阐述、关键信息、处理指引、辅助信息或者索引,便于定性),不鼓励 Key-Value 模式的告警,建议使用自然语言描述核心逻辑和响应流程。

  • 有清晰的说明文档,自测报告(就像交付了一个研发产品,产品文档和自测过程是质量的保障)。

  • 有蓝军针对该场景实战验收报告。

  • 不建议调用微信、短信等接口发告警(告警和事件的区别是,事件可以闭环,告警只是提醒),统一的告警事件框架可以有效的管理事件确保闭环,还能提供长期的基础运营数据,比如止损效率、误报量/率。

策略人员的文档应当说明当前模型对哪些情况具备感知能力,哪些前提下会无法告警(考验一个人对该场景和自己模型的理解能力)。

通过前述判断,可以对策略的成熟度形成自评分,0-100 自由大致估算。单个场景往往很难达到 100 分,但那并没有关系,因为从 80 分提升到 100 分的边际成本可能变的很高。

不建议追求极致,而是全盘审视,是否快速投入到下一个场景中去。

如果某个不到满分的场景经常出现真实对抗,又没有交叉的其他策略进行弥补,那自评结论可能需要重审并提高验收的标准。至少解决工作中实际遇到的 Case 要优先考虑。

影响入侵检测的关键要素

讨论影响入侵检测的要素时,我们可以简单看看,曾经发生过哪些错误导致防守方不能主动发现入侵:

  • 依赖的数据丢失,比如 HIDS 在当事机器上,没部署安装/Agent 挂了/数据上报过程丢失了/Bug 了,或者后台传输链条中丢失数据。

  • 策略脚本 Bug,没启动(事实上我们已经失去了这个策略感知能力了)。

  • 还没建设对应的策略(很多时候入侵发生了才发现这个场景我们还没来得及建设对应的策略)。

  • 策略的灵敏度/成熟度不够(比如扫描的阈值没达到,WebShell 用了变形的对抗手法)。

  • 模型依赖的部分基础数据错误,做出了错误的判断。

  • 成功告警了,但是负责应急同学错误的判断/没有跟进/辅助信息不足以定性,没有行动起来。

所以实际上,要让一个入侵事件被捕获,我们需要入侵检测系统长时间、高质量、高可用的运行。这是一件非常专业的工作,超出了绝大多数安全工程师能力和意愿的范畴。

所以建议指派专门的运营人员对以下目标负责:

  • 数据采集的完整性(全链路的对账)。

  • 每一个策略时刻工作正常(自动化拨测监控)。

  • 基础数据的准确性。

  • 工单运营支撑平台及追溯辅助工具的便捷性。

可能有些同学会想,影响入侵检测的关键要素,难道不是模型的有效性么?怎么全是这些乱七八糟的东西?

实际上,大型互联网企业的入侵检测系统日均数据量可能到达数百 T,甚至更多。

涉及到数十个业务模块,成百上千台机器。从数字规模上来说,不亚于一些中小型企业的整个数据中心。

这样复杂的一个系统,要长期维持在高可用标准,本身就需要有 SRE、QA 等辅助角色的专业化支持。

如果仅依靠个别安全工程师,很难让其研究安全攻防的时候,又兼顾到基础数据质量、服务的可用性和稳定性、发布时候的变更规范性、各类运营指标和运维故障的及时响应。

最终的结果就是能力范围内可以发现的入侵,总是有各种意外“恰好”发现不了。

所以,笔者认为,以多数安全团队运营质量之差,其实根本轮不到拼策略(技术)。当然,一旦有资源投入去跟进这些辅助工作之后,入侵检测就真的需要拼策略了。

此时,攻击手法有那么多,凭什么先选择这个场景建设?凭什么认为建设到某程度就足够满足当下的需要了?凭什么选择发现某些样本,而放弃另一些样本的对抗?

这些看似主观性的东西,非常考验专业判断力。而且在领导面前很容易背上“责任心不足”的帽子。

比如为困难找借口而不是为目标找方法,这个手法黑客攻击了好多次,凭什么不解决,那个手法凭什么说在视野范围内,但是要明年再解决?

如何发现 APT?

所谓 APT,就是高级持续威胁。既然是高级的,就意味着木马很大可能是免杀的(不能靠杀毒软件或者普通的特征发现),利用的漏洞也是高级的(加固到牙齿可能也挡不住敌人进来的步伐),攻击手法同样很高级(攻击场景可能我们都没有见过)。

所以,实际上 APT 的意思,就约等于不能被发现的入侵。然而,业界总还有 APT 检测产品,解决方案的厂商在混饭吃,他们是怎么做的呢?

  • 木马免杀的,用沙箱+人工分析,哪怕效率低一些,还是试图做出定性,并快速的把 IOC(威胁情报)同步给其他客户,发现 1 例,全球客户都具备同样的感知能力。

  • 流量加密变形对抗的,用异常检测的模型,把一些不认识的可疑的 IP 关系、payload 给识别出来。当然,识别出来之后,也要运营人员跟进得仔细,才能定性。

  • 攻击手法高级的,还是会假定黑客就用鱼叉、水坑之类的已知手法去执行,然后在邮箱附件、PC 终端等环节采集日志,对用户行为进行分析,UEBA 试图寻找出用户异于平常的动作。

那么,我们呢?笔者也没有什么好的办法,可以发现传说中的“免杀”的木马,但是我们可以针对已知的黑客攻击框架(比如 Metasploit、Cobalt Strike)生成的样本、行为进行一些特征的提取。

我们可以假设已经有黑客控制了某一台机器,但是它试图进行横向扩散的时候,我们有一些模型可以识别这个主机的横向移动行为。

笔者认为,世界上不存在 100% 能发现 APT 的方法。但是我们可以等待实施 APT 的团队犯错,只要我们的纵深足够的多,信息足够不对称,想要完全不触碰我们所有的铃铛,绝对存在一定的困难。

甚至,攻击者如果需要小心翼翼的避开所有的检测逻辑,可能也会给对手一种心理上的震慑,这种震慑可能会延缓对手接近目标的速度,拉长时间。而在这个时间里,只要他犯错,就轮到我们出场了。

前面所有的高标准,包括高覆盖、低误报,强制每一个告警跟进到底,“掘地三尺”的态度,都是在等待这一刻。抓到一个值得敬佩的对手,那种成就感,还是很值得回味的。

所以,希望所有从事入侵检测的安全同行们都能坚持住,即使听过无数次“狼来了”,下一次看到告警,依然可以用最高的敬畏心去迎接对手(告警虐我千百遍,我待告警如初恋)。

AI 在入侵检测领域的正确姿势

最近这两年,如果不谈 AI 的话,貌似故事就不会完整。只不过,随着 AI 概念的火爆,很多人已经把传统的数据挖掘、统计分析等思想,比如分类、预测、聚类、关联之类的算法,都一律套在 AI 的帽子里。

大型互联网公司如何防止黑客入侵?(下)

其实 AI 是一种现代的方法,在很多地方有非常实际的产出了。以 WebShell 的文本分析为例,我们可能需要花很长很长的时间,才能把上千个样本里隐含的几十种样本技术类型拆分开,又花更长的时间去一一建设模型(是的,在这样的场景下,特征工程真的是一个需要更长时间的工作)。

而使用 AI,做好数据打标的工作,训练、调参,很快就能拿到一个实验室环境不那么过拟合的模型出来,迅速投产到生产环境上。熟练一点可能 1-2 个月就能做完了。

在这种场景下,AI 这种现代的方法,的确能极大的提高效率。但问题是,前文也提到过了,黑客的攻击黑样本、WebShell 的样本,往往极其稀缺,它不可能是完备的能够描述黑客入侵的完整特征的。

因此,AI 产出的结果,无论是误报率还是漏报率,都会受训练方法和输入样本的影响较大,我们可以借助 AI,但绝对不能完全交给 AI。

安全领域一个比较常见的现象是,将场景转变成标记问题,要难于通过数学模型把标记的解给求出来。

此时往往需要安全专家先行,算法专家再跟上,而不能直接让算法专家“孤军奋战”。

针对一个具体的攻击场景,怎么样采集对应的入侵数据,思考这个入侵动作和正常行为的区别,这个特征的提取过程,往往决定了模型最终的效果。特征决定了效果的上限,而算法模型只能决定了有多接近这个上限。

此前,笔者曾见过一个案例,AI 团队产出了一个实验室环境效果极佳,误报率达到1/1000000 的 WebShell 模型,但是投放到生产环境里初期日均告警 6000 单,完全无法运营,同时还存在不少漏报的情况。

这些情况随着安全团队和 AI 工程师共同的努力,后来逐渐地解决。但是并未能成功的取代原有的特征工程模型。

目前业界有许多产品、文章在实践 AI,但遗憾的是,这些文章和产品大多“浅尝辄止”,没有在真实的环境中实践运营效果。

一旦我们用前面的标准去要求它,就会发现,AI 虽然是个好东西,但是绝对只是个“半成品”。真正的运营,往往需要传统的特征工程和 AI 并行,也需要持续地进行迭代。

大型互联网公司如何防止黑客入侵?(下)

网络急速发展的时代

互联网公司

有着很好的发展市场和未来

但是在发展的路上

总要必不可免的要注意

网络安全问题

互联网公司不仅要注意的是

公司本身的网络安全

更要保护好用户的隐私安全

这样不仅可以保护好自身的安全问题

也会赢得更多的用户信赖~

来源:江民科技

点击数:95

暂无评论

发送评论 编辑评论


				
|´・ω・)ノ
ヾ(≧∇≦*)ゝ
(☆ω☆)
(╯‵□′)╯︵┴─┴
 ̄﹃ ̄
(/ω\)
∠( ᐛ 」∠)_
(๑•̀ㅁ•́ฅ)
→_→
୧(๑•̀⌄•́๑)૭
٩(ˊᗜˋ*)و
(ノ°ο°)ノ
(´இ皿இ`)
⌇●﹏●⌇
(ฅ´ω`ฅ)
(╯°A°)╯︵○○○
φ( ̄∇ ̄o)
ヾ(´・ ・`。)ノ"
( ง ᵒ̌皿ᵒ̌)ง⁼³₌₃
(ó﹏ò。)
Σ(っ °Д °;)っ
( ,,´・ω・)ノ"(´っω・`。)
╮(╯▽╰)╭
o(*////▽////*)q
>﹏<
( ๑´•ω•) "(ㆆᴗㆆ)
😂
😀
😅
😊
🙂
🙃
😌
😍
😘
😜
😝
😏
😒
🙄
😳
😡
😔
😫
😱
😭
💩
👻
🙌
🖕
👍
👫
👬
👭
🌚
🌝
🙈
💊
😶
🙏
🍦
🍉
😣
Source: github.com/k4yt3x/flowerhd
颜文字
Emoji
小恐龙
花!
上一篇
下一篇