漏洞扫描的问题
漏洞扫描工具是目前国内各个服务、咨询厂商进行安全评估的核心工具,甚至可以说,国内绝大部分风险评估项目其实是漏洞扫描项目。因此,一些自己生产漏洞扫描器的厂商可以肆无忌惮地报低价,用以为朋友的说法是,动不动就躺到地板上。
但是,从风险评估的需求和相关技术的发展来看,漏洞扫描器其实已经是一种地位非常尴尬的产品了,原因如下:
准确度低,由于多数扫描器是黑箱或者灰箱操作的,因此难以避免地会出现的误报;
可能会给主机和设备造成损害,弱点扫描器通常会包含攻击代码,因此会给被扫描的对象带来难以预计的破坏,例如:系统宕机。
只能评估远程弱点,对于本地弱点基本是无效的。
而且,自从nessus的第三版发布之后,修改了license,现在市面上几乎已经没有很好的开源漏洞扫描工具可用了。而nessus的开源替代者OpenVAS一直不太活跃,目前是否能够替代nessus尚难以下结论。另外,nmap于2006年发布了nse(nmap script engine)之后,使其必然会成为一个完整的漏洞扫描器,但是这一过程的进度无法预料。
信息收集的问题
风险评估过程中存在多处信息收集点,包括资产、弱点、威胁等技术类信息,以及访谈信息等。只有在正确、全面的数据基础之上,才能得到准确、全面的风险评估结果,至于具体使用什么样的评估模型和关联方式并不重要。但是,国内大部分作安全评估的厂商和单位恰恰忽视了这一点。
下表是一个信息及其收集方式的列表,通过这个列表可以发现,目前国内各个服务、咨询厂商在风险评估实施能力方面,已经远远达不到客户的安全需求了。
| 编号 | 信息 | 介绍 | 用途 | 方法 | 存在的问题 |
| 1 | 业务和资产信息 | 包括被评估业务系统信息,物理资产、软件资产、数据资产等信息。 | 业务和资产信息主要有如下用途: | 访谈和调查 | 目前赋值对象的选择可以是资产或者业务系统,随着等级化的推行,以业务系统作为赋值对象已经成为主流,此处是风险评估与等级化的一个结合点。 |
| 2 | 弱点数据 | 在风险评估中,弱点又叫脆弱性、漏洞。 | 弱点风险各要素(资产价值、威胁、弱点)中唯一的客观要素。而且在某些方面(网络设备、主机等)的弱点发现技术相当成熟。因此,风险评估项目几乎可以说就是弱点评估或者漏洞扫描项目。 | 扫描 | 弱点方面的问题见漏洞扫描的问题 |
| 3 | 配置数据 | 风险评估中,人工评估获得的主要内容。 | 主要为了判断评估对象本身安全策略、补丁、配置方面存在的安全问题。 | 根据checklist实行手工检查。 | 目前人工评估基本已经成为风险评估项目中的鸡肋,如果要进行详细检查,就会消耗大量的时间;如果要提高效率,就只能削减检查项。一般情况下,需要根据项目的规模和金额来确定怎么做。而且,由于从业人员素质的下降,目前checklist已经成为各家厂商的大问题,内容陈旧、无人维护、互相抄袭。 |
| 4 | 文档类数据 | 是从客户手中获得的一些规章制度、工作流程,以及系统开发文档等。 | 这是管理评估的一个重要依据,也是进行应用评估的重要素材。 | 访谈、调查 | 这部分数据的分析受评估咨询人员的素质影响很大。 |
| 5 | 访谈数据 | 针对评估对象不同角色访谈得到的数据。 | 管理评估的重要依据。 | 访谈 | 问题主要存在于问卷的内容,并且受评估咨询人员的素质影响很大。 |
| 6 |
技术发展的方向
风险评估相关的技术在进四年来发展迅速。由于IT应用发展的需要,例如:J2EE 和.Net的流行,2004年-2005年M$提出了基于威胁建模的风险评估模式。随后,出现了多种类似的评估方法,例如:Trike、coras,尤其 是coras,被挪威一家机构提交成为OMG(Object Management Group)的一个规范。
其实,威胁建模归根结底是由于应用弱点评估技术不成熟造成的,在还没有成熟的弱点评估技术之前,从应用系统面临的威胁入手来解决评估的问题,也未尝不是一条良策。
今几年,老美在风险评估方面的进展获得长足的进步。真正做到了既有规范:OVAL、XCCDF、CWE、CVSS、CPE等,又有内容。相关的内容可以参考SCAP、MeasurableSecurity。
国内相关标准的问题
目前国内风险评估标准尚处于刚刚起步的状态,而且面临一个严峻的事实:
一群不懂TCP/IP,不懂主机,不懂网络,不懂应用,不懂安全技术的人在编写风险评估标准。
1033

被折叠的 条评论
为什么被折叠?



