From : elknot@360corpsec
0x00 写在前面：
昨天和某巨佬私下交流的时候，巨佬遇到了一个问题，甲方有一个比较难搞的需求：让这位巨佬给他提供一个安全攻击态势的模型。当时这个需求听完之后我觉得有点难办。但是后来想了一下也不是没有可能去做，由于以下的说法仅作为一些思路，落地性还有待考察，所以大家针对落地问题先不要去喷了。
0x01 所谓安全攻击态势是什么
跟巨佬的进一步聊天中，我大概明白了甲方的意思：对下属子公司进行考核。其实巨佬自己也知道这个模型偏向于管理而非技术，只是需要技术数据的支撑。那么实际上其实根据我个人的理解就是：客户需要把业务系统所面临的潜在风险罗列出来，并且考核安全部门对于这些潜在风险的解决成果。
那么我们的思路就逐渐清晰了，我们需要了解的也就是业务系统会面临那些潜在的风险和安全部门应对这些风险的技战术手段。
0x02 业务系统潜在风险
但从业务系统的潜在风险来判断的话，很多人第一反应就是日志，换句话说，很多领导要是问安全部门的同事我们系统的潜在风险是什么，经验不足的安全管理人员可能会马上从SIEM中抽取相关的安全日志（如果连SIEM都没有的话，那就是只能亲自动手去所有的安全设备的日志中逐条检索，所以针对大型的系统而言，规模越大SIEM的需求也就越高），然后按照攻击事件的数量排序，最后给出来一个所谓的“业务安全潜在风险分析报告”。但是各位仔细想一下就会发现这份报告实际上是有问题的，首先领导要的是“业务系统潜在风险”，而非是“已经发生的安全事件的统计”，换句话说安全部门提供的报告是领导期望的。那么如何评定业务系统的潜在风险呢？
（1）业务系统活跃指数
首先，针对一个系统而言，业务系统的活跃指数也就是能够被人访问到的几率是一个指标，如果这个业务系统被网络隔离了，也就只有内部的人可以访问的到，那么攻击面就大大减小了。那么如何判断这个系统的活跃指数呢。个人认为PV、UV、搜索引擎排名和Alexa指数这四个数据可以一定程度上来描述业务系统的活跃指数，PV、UV越大、搜索引擎排名越高、Alexa指数越高则说明了该系统被互联网用户访问到的可能性就越大，意味着被攻击的概率也就越高。
上面这张图表示的就是Alexa的指数，指数越高也就是用户访问越频繁。当然这个只是其中的一方面，越活跃不一定代表受攻击的可能越大。
（2）业务安全风险评定
活跃指数只能判断出该业务系统被访问的次数，但是这仅仅是外因。被攻击的可能起决定因素的不是外因而是内因。所谓的内因也就是业务系统资深的原因，比如说用了不安全的框架、中间件存在已知漏洞、管理平台弱口令等等，然而这些问题其实解决起来不是特别的容易，一方面原因是业务系统稳定之后不太可能进行大范围的重构，二是因为开发部门对于安全方面可能不是特别懂，甚至有些大哥直接把测试环境部署到外网上去。
其实这些问题如果企业按部就班的走SDL的话，问题应该不大，因为SDL对于系统的安全开发存在一步威胁建模，就比如下面这张图：
STRIDE威胁建模其实是一个很好的评估手段，但是很不幸，很多业务并不会去遵守这一套，这里安全部门就要多跑腿了，要定期对业务系统进行主动的渗透测试和安全监测，保证业务系统不存在可以被恶意利用的漏洞，
（3）历史攻击攻击行为比对
这一部分其实就是从SIEM中抽取对应业务系统的安全日志，然后将其统计分类最后按照影响范围统计出来攻击的行为，但是这么做的话还远远不够，因为攻击日志里面有些是成功的有些是失败的，有些是人产生的有些是机器产生的。判断历史攻击行为的时候应当注意以下几点：
- 确保SIEM中日志的有效性和准确性
- 统计攻击事件中成功次数与总次数所占的比例
- 列出所有攻击行为有特点的IP进行简单溯源
- 对攻击成功的IP进行重点监测并进行针对性溯源
- 回顾以往众测或者企业SRC收上来的漏洞利用报告
这样的话你将会得到：
- 一份带有详细数据的事件统计报告
- 一份发起攻击行为IP的列表
- 一份成功发起攻击行为IP的列表
- N份漏洞利用及分析报告
统计完成之后接下来就可以进行下一环节。
（4）IP溯源及引入情报体系
上面我们得到了一些攻击IP的数据，有些是成功的有些是失败的，这时候我们可以利用外部的威胁情报数据对这些IP进行浅层次或者深层次的溯源，浅层次的溯源主要是针对发起攻击但是失败的，需要收集的信息包括：IP的信誉度、地理位置、绑定的域名、域名注册时间、接入类型、被恶意标记的内容。
这些信息可以帮助我们去判断这些IP是不是肉鸡还是真实的攻击者，举个例子，假设一个IP的是一个荷兰OVH的主机，对我们输出的日志大多数都为扫描、注入类型的攻击，我们只接通过网络策略把这个IP拉黑了就可以了，因为他不是一个真是的攻击者而是一台肉鸡。相反的，如果一个IP攻击的行为包括社工、撞库、恶意漏洞利用、shell管理，并且接入方式是家庭宽带动态IP，那么这个IP我们就应该重点关注，甚至对其进行更深层次的溯源分析。
所谓深层次溯源分析，针对的主要是一些攻击行为有特点且明显不是自动化行为的攻击，比如上面那个例子。深层的溯源不是要把这个人的户口本全查一遍，然后家里几亩地，地里几头牛这些全都搞出来。之前我在ISC2017的大数据威胁分析论坛上面分享过我个人的观点——真的没必要大费周章把攻击的人直接抓出来，劳民伤财又费力不讨好，甚至没准还会触犯法律。我们需要明白的是攻击者瞄准的目标、攻击的套路和攻击者到底是出于什么样的目的攻击就足够了。
针对高级的溯源，我们需要采集的数据是：
- 攻击者使用的基础设施
- 攻击者的意图
- 攻击者的成功率
- 攻击者的Kill-Chain模型
- 攻击者瞄准的行业和系统
那么实际上高级溯源的结果我们也是有所区分的，比如说某些攻击者满天撒网导出扫描，抓到一个搞一个，这种的攻击者其实是没有价值的，通过网络策略直接ban了就完了。但是如果瞄准特定行业，攻击手段比较黑科技，而且Kill-Chain完整，攻击能力稳准狠，对待这种攻击者我们就应该去重点观察一下了，比如说把他的所有流量通过流量牵引到蜜罐里，观察他的操作。
其实说到这里，我们研究了所有的攻击者，可以把攻击我们的人都是什么来路摸清楚了。
（5）SOC团队素质
敌人分析完了，我们自己人也得分析分析，分析自己人最好的方法其实就是三个场景：重保、演习和众测。
出去前一个是有个别地方有需求，其他的两个都是可以找第三方团队去做的，主要目的是为了测试SOC针对外部威胁如何快速准确定位然后消灭威胁。
根据PDR模型来判断，如果响应时间Rt和检测时间Dt事件越短，同时防御时间Pt可以做到足够的长。攻击者得手的可能性越低。
0x03 写报告
笔者个人认为态势感知不是跟x管家、x卫士那种随便打个分数就完了，态势感知的目的是为了给客户提供潜在的攻击行为和应对的策略，应该是完整的建议。态势感知如果要是打分的话这个产品一定是假的，大家不要相信。
如果输出报告的话，报告中应包含
- 内因分析：威胁建模、安全手段评估、SOC素质、渗透测试和众测等
- 外因分析：业务系统活跃度、对外ACL、外部情报数据和对攻击者的认知。
具体怎么写，相信愿意看这篇文章的人应该都比我懂。
p.s. 文章仅代表个人观点，不代表其它的观点。
Q：评价业务安全风险的时候，是不是也应该包括业务所处基础环境的安全风险（物理、所处网络环境、操作系统及一些框架之类的）？
A：首先，您说的这些东西都是包含在内的，这一部分都已经集成到SDL和威胁建模环节，具体的一个业务上线流程请看
