话说CWE 4.2的新视图
话说CWE 4.2的新视图
1. 按照惯例,先说故事
我们先说下CWE的幕后老板--MITRE[1]。 MITRE称自己是一家“非赢利组织”,通过联邦资助的研发中心(Federally Funded R&D Centers(FFRDC))运作。目标是为更安全的世界解决问题(we solve problems for a safer world)。
1.1. MITRE的起源
MITRE的历史可以追溯到美、苏二战后的冷战时期。50年代后期,面对苏联核打击的威胁,美国空军呼吁麻省理工学院帮助其建立一个防空系统,以帮助其侦查即将来临的轰炸机。该研究所提出了半自动地面环境(SAGE)系统结合了雷达,无线电和网络通信来检测敌机,对附近的空军基地发出警报并不断更新,这些基地的战机会及时升空拦截即将来临的威胁。SAGE也是美国的第一个现代化防空系统[6]。MITRE的前三个字母MIT就是麻省理工学院的缩写。记得以前的一个法国电影《蛇》(1973),讲的就是这个历史背景下的故事人员发现苏联制造战略轰炸机剩余的材料,做成了衣架被用到民用航空上,人员就想方设法偷了来,交给实验室分析,厉害的科学家们,通过材料的组成成分,推算出了由此材料制成的轰炸机满载时的航程。有兴趣的朋友可以翻出来看一看,那个年代非常经典的谍战片。
1.2. 著名的ATT&CK
对于MITRE这个名字,可能更多的人会先想到这些年比较火的MITRE的ATT&CK攻击框架,这个引领全球网络安全攻防潮流的安全技术战术知识库框架。10/27号MITER刚刚发布了ATT&CK的第8.1版本。说它是个战术的知识框架,是因为ATT&CK将入侵期间可能发生的情况,细分成14个策略阶段:侦察、资源开发、入侵初期、执行、持久化、权限提升、防御逃避、凭证访问、发现、横向移动、收集、指挥和控制、渗透、影响。然后针对攻击方在每个阶段所使用的技术、工具加以总结、归类成知识库,从而有助于我们理解攻击者具备的能力。 目前ATT&CK按领域分为:
- 企业(Enterprise):传统企业网络和云环境;
- 移动(Mobile):移动通信设备;
- ICS:Idustrial Control System 工控系统
下图为企业的ATT&CK:
1.3. 运营模式:臭鼬工厂(Skunk Work)
MITRE经营着一些最隐秘、低调的科学技术实验室,这些实验室就像电影《007》中的M16实验室。因为MITRE是非赢利组织,所以MITRE通过“联邦资助的研发中心”(FFDRC)的方式,运营着7家“臭鼬工厂”(Skunk Work)级别的研发中心。也许大家对“臭鼬工厂”这个模式有些陌生,这里稍微解释一下。1943年,为了与德国飞机制造公司Messerschmitt制造的飞机竞争,洛克希德公司成立了一个名为 Skunk Works(臭鼬工厂)的顶级秘密研究和生产基地,它明确的任务是在 180 天内开发一架高速战斗机。项目在决策上给予了很大的自主权,鼓励无视标准程序。结果项目创纪录的在143天里,开发并交付了洛克希德公司的 P-80 射击机,这是美国陆军航空兵的第一架喷气式战斗机。以及后面我们熟悉的U2,F22,F35都是由这类工作室研发出来的。后来臭鼬工厂就成为一种创新的模式被一直沿用至今,苹果、Google等大公司都有类似的工作室。下图是2014年洛克希德公司在臭鼬工厂70年的时候的一个宣传图。
1.4. 研发领域
MITRE的研发领域涵盖先进的航空系统、企业现代化技术、司法工程、医疗保健、国家网络安全等。产品也从机载预警通讯系统(AWACS)、军用卫星通信系统;到FBI的社交媒体图像指纹识别项目和与之关联的人体解剖学和犯罪史数据库;帮助美国国土安全部(DHS)开发的物联网(包括智能手机、健身追查器、智能家居产品等)入侵与检测系统;据说还正在研发一项通过体味变化测谎的技术......。 Mitre吸引了大批最顶尖的网络安全人才和跨界科技专家、科学家,也营造了很多传奇的故事。比如,前MITRE工程师Matt Edman(秃头,胡须, 清脆的男中音)曾与联邦调查局(FBI)合作,利用其黑客技巧帮助FBI摧毁了臭名昭著的地下网络du品市场--“丝绸之路(Silk Road)”。
今年新冠疫情流行,美国的卫生机构向Mitre Corp.提出打造一种名为“Sara Alert”的监控系统。通过Sara Alert系统,公共卫生官员可以登记和监控生病或有感染风险的个人和家庭,被登记的人被要求每天通过短信、电子邮件、电话或网站输入他们的症状。这将有助于卫生保健机构确定哪些人需要护理,哪些人需要隔离。美国疾病控制和预防中心现在正依靠Sara Alert来挽救该国的新冠肺炎疫情监测工作。感觉有些像我们的“健康码”。
2. CWE的简介
2.1. CWE的诞生
回到今天的主题上来,从1999年MITRE开始发布CVE(Common Vulnerabilities and Exposures)[2]缺陷列表。作为CVE的一部分,MITRE的CVE团队对漏洞、攻击、故障和其他概念进行了初步分类,以帮助定义常见的软件漏洞。但是这些分类过于粗糙,无法用于代码安全评估行业产品中提出的缺陷的识别和分类的需求。为此,MITRE参与美国国土安全部(DHS)赞助的美国国家标准技术研究院(NIST)的软件保障度量和工具评估(SAMATE)项目中,于2005年首次修改了内部CVE类别工作,以用于代码评估行业。于是便产生了CWE(Common Weakness Enumeration)[3]。CWE被用于以下目的:
- 用通用语言描述和讨论软件和硬件的弱点;
- 检查现有软件和硬件产品中的弱点;
- 评估针对这些弱点的工具的覆盖范围;
- 利用常见的基准标准来识别,缓解和预防漏洞;
- 在部署之前防止软件和硬件漏洞;
于是CWE做为软件缺陷分类的重要标准, 对安全研究、安全标准、缺陷管理起了重要的纽带作用。CWE使代码缺陷不同领域的研究人员在交流安全问题时,能够采用相同的定义,减少了歧义性。
2.2. CWE编号类型
目前CWE对软件和硬件的缺陷进行了分类和描述, 每一个分类拥有唯一的一个CWE编号, 并按照CWE编号的类型(类缺陷、基础缺陷和变种缺陷等)形成了多层次的缺陷类型划分体系。
3. CWE 4.2的新视图
近些年随着软件安全问题越来越成为软件应用系统风险防控的重要因素,CWE的更新速度也明显加快。
特别是今年2/24发布4.0,首次将硬件安全漏洞纳入了CWE中,6/25发布4.1, 8/20就发布了4.2。
- CWE-1350: Weaknesses in the 2020 CWE Top 25 Most Dangerous Software Weaknesses
- CWE-1305: CISQ Quality Measures (2020)
3.1. CWE-1350: CWE/SANS Top 25
这个视图是CWE按照NIST(National Institute of Standards and Technology)管理的缺陷库NVD(National Vulnerability Database)[3]中的缺陷CVE(Common Vulnerabilities and Exposures), 并依照CVSS[4]评分体系(Common Vulnerability Scoring System)给出的出危害性(severity)和缺陷的出现频率(prevalence), 按公式计算后的得分给出的排名。 从这里可以看到数据的可靠性, 能够反映2020年发现的主要的安全缺陷,对工具、测试和安全研究有着重要的指导作用。
CWE和SANS学院一起,从2009,2010,2011 一共发布了三次 TOP 25[5]。但后来不知道因何原因,直到2019才又再次发布了TOP 25, 这是继CWE 2019 TOP 25后的又一次更新。CWE 2020 TOP 25统计了从2018到2019大约27,000 CVE漏洞。我们来看以下2020和2019年Top 25发生的变化。
3.1.1. CWE 2020 TOP 25 vs CWE 2019 TOP 25
-
上升较快的有:
- CWE-787 (Out-of-bounds Write): from #12 to #2;
- CWE-522 (Insufficiently Protected Credentials): from #27 to #18
- CWE-306 (Missing Authentication for Critical Function): from #36 to #24
- CWE-862 (Missing Authorization): from #34 to #25
- CWE-863 (Incorrect Authorization): from #33 to #29
从这里可以看出,除了787是缓冲区问题之外,另外上升较快的都是权限控制相关的问题.
-
下降较快的有:
- CWE-426 (Untrusted Search Path): from #22 to #26
- CWE-295 (Improper Certificate Validation): from #25 to #28
- CWE-835 (Loop with Unreachable Exit Condition): from #26 to #36
- CWE-704 (Incorrect Type Conversion or Cast): from #28 to #37
3.1.2. CWE 2020 TOP 25 变动表
3.1.3. 排名算法
由于排名得分的算法,考虑到了出现频率(prevalence)和危害(severity)两个参数, 确保出现频率低, 危害小的缺陷, 不容易出现在排行榜中, 而是让频率高, 危害高的缺陷出现在排行榜中。这个算法只能从统计学的角度消减数据偏差,但对于对缺陷归属哪一个CWE的理解问题的偏差,仍然会对造成在CVE的缺陷分类映射到CWE时据造成一定的误差。这些在CWE分类层次上一直存在的问题,只能希望在后期的CWE版本逐步得到解决。
- 计算公式:
- Freq = {count(CWE_X’ ∈ NVD) for each CWE_X’ in NVD}
- Fr(CWE_X) = (count(CWE_X ∈ NVD) - min(Freq)) / (max(Freq) - min(Freq))
- Sv(CWE_X) = (average_CVSS_for_CWE_X - min(CVSS)) / (max(CVSS) - min(CVSS))
- Score(CWE_X) = Fr(CWE_X) * Sv(CWE_X) * 100
3.2. CWE-1305: CISQ Quality Measures (2020)
3.2.1. CISQ 背景
CISQ是信息和软件质量联盟(Consortium for Information & Software Quality(CISQ))基于自动化质量特征度量标准来衡量软件质量。这个质量标准源于自对象管理组织(Object Management Group (OMG))[7]。对象管理组(OMG)是一个国际性,开放成员,非营利性技术标准联盟。OMG标准由供应商,用户,学术机构推动。 OMG工作组针对各种技术和更广泛的行业制定企业集成标准。 我们熟悉的 Unified Modeling Language (UML) 和 Model Driven Architecture (MDA)就是这个组织制定的。
-
CISQ
CISQ由卡耐基梅隆大学的工程学院(Software Engineering Institute (SEI) at Carnegie Mellon University)和对象管理组织(OMG)于2010年共同创立。 这两个组织都受到系统集成商的邀请,并被要求制定衡量软件可靠性和安全性软件属性的标准。 建立全球标准是为了对供应商的IT应用程序在基准测试应用程序中进行比较的重要步骤。 -
创始人与赞助商
-
谁在使用
有超过1500个软件组织加入了CISQ的会员, CISQ也被许多顶级的系统集成或软件开发商使用, 例如: Cognizant, CGI, Tech Mahindra, GSA, BNY Mellon, U.S. Air Force, Generali, BMW。 -
ISO/IEC正在启动将CISQ并入ISO/IEC DIS 5055 Information technology — Software measurement — Software quality measurement — Automated source code quality measures 标准中。 估计这个标准在明年就会正式发布。
3.2.2. CISQ如何评估软件质量
- CISQ汇集了世界知名软件专家, 定义了一套最佳实践, 以确保软件的: 可靠性, 性能效率, 安全性 和可维护性;
- 对评估的四个维度, CISQ整理了CWE中800多个已知的软件弱点, CISQ确定了最关键和影响最大的CWE,并针对每个质量特征对它们进行了标准化以实现自动化;
- 在每个质量度量的角度, 都可以通过静态分析的方法, 通过代码层面和架构层面进行自动化评估;
- CISQ 四个特性的概览
SOFTWARE QUALITY CHARACTERISTIC 软件质量特性 |
CODING PRACTICES UNIT LEVEL 代码层面 |
ARCHITECTURAL PRACTICES SYSTEM LEVEL 架构层面 |
---|---|---|
RELIABILITY(可靠性) | * 多线程环境中的保护状态 * 安全使用继承和多态 * 资源范围管理,复杂代码 * 管理分配的资源,超时 |
* 多层设计合规 * 软件管理数据完整性和一致性 * 通过交易处理异常 * 类架构合规 |
PERFORMANCE EFFICIENCY (性能效率) |
* 遵守面向对象的最佳实践 * 符合SQL最佳做法 * 循环中的开销计算 * 静态连接与连接池 * 遵守垃圾收集最佳实践 |
* 与高开销或远程资源的适当交互 * 数据访问性能和数据管理的内存,网络和磁盘空间的管理 * 集中处理客户请求 * 使用中间层组件与过程/数据库功能 |
SECURITY(安全性) | * 硬编码凭证的使用 * 缓冲区溢出 * 未初始化 * 数组索引验证不正确 * 不当锁 * 不受控制的格式字符串 |
* 输入验证 * SQL注入 * 跨站脚本 * 无法使用经过审查的库或框架 * 安全架构设计合规 |
MAINTAINABILITY(可维护性) | * 非结构化和重复的代码 * 高圈复杂度 * 受控级别的动态编码 * 方法的过度参数化 * 文字的硬编码 * 组件尺寸过大 |
* 重复的业务逻辑 * 符合初始架构设计 * 架构层之间严格的调用层次 * 水平层过多 * 过多的多层扇入/扇出 |
3.2.3. CISQ 2020 vs CISQ 2016
CWE在2019年3月份的3.2版本引入了CISQ的2016年发布的草案0.9版本。这次发布的是CISQ今年1月份发布的1.0正式版。
SOFTWARE QUALITY CHARACTERISTIC | CISQ 2020 | CISQ 2016 |
---|---|---|
Reference(参考版本) | 2020.1 1.0(formal) | 2016 0.9(draft) |
RELIABILITY(可靠性) | 74个CWE | 28个CWE |
MAINTAINABILITY(可维护性) | 28个CWE | 20个CWE |
SECURITY(安全性) | 78个CWE | 22个CWE |
PERFORMANCE EFFICIENCY(性能效率) | 18个CWE | 14个CWE |
Total CWE | 142 | 81 |
4. 小结
- 从2020 TOP 25来看, 2019,2020 缓冲区溢出, 输入校验引起的问题(注入, CSRF) 仍然是软件安全和工具需要面对的主要问题; 同时权限设置引入的问题, 在呈上升的趋势;
- CISQ 通过静态分析来实现软件质量的自动度量, 并采用对CWE的问题检测, 细化了衡量的标准。这为通过工具对应用软件质量的自动化度量提供了一个思路, 也为建立一个统一的标准下的软件质量的测评提供了重要依据。
5. 参考
[1] MITRE: https://www.mitre.org/
[2] CVE: http://cve.mitre.org/cve/
[3] CWE: https://cwe.mitre.org/
[4] NVD: https://nvd.nist.gov/
[5] CVSS: https://nvd.nist.gov/vuln-metrics/cvss
[6] Inside americas secretive 2billion research hub collecting fingerprints from facebook hacking smartwatches and fighting covid-19
[7] OMG: https://www.omg.org/about/index.htm
[8] List of Weaknesses Included in the CISQ Automated Source Code Quality Measures June 2019
- 点赞
- 收藏
- 关注作者
评论(0)