道高一丈，且看 CWE4.2 的新特性

关注

发布于: 2020 年 12 月 28 日

摘要：CWE 在今年 2/24 发布 4.0，首次将硬件安全漏洞纳入了 CWE 中，6/25 发布 4.1， 8/20 就发布了 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 应用程序在基准测试应用程序中进行比较的重要步骤。

创始人与赞助商

https://www.omg.org/
https://www.castsoftware.com/
https://www.cgi.com/en
https://www.cognizant.com/
https://ishpi.net/
http://www.northropgrumman.com/Pages/default.aspx
https://www.synopsys.com/
https://www.techmahindra.com/CWCE.html
https://www.it-cisq.org/index.htm#

谁在使用

有超过 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 四个特性的概览

3.2.3. CISQ 2020 vs CISQ 2016

CWE 在 2019 年 3 月份的 3.2 版本引入了 CISQ 的 2016 年发布的草案 0.9 版本。这次发布的是 CISQ 今年 1 月份发布的 1.0 正式版。

4. 小结

从 2020 TOP 25 来看, 2019,2020 缓冲区溢出, 输入校验引起的问题(注入, CSRF) 仍然是软件安全和工具需要面对的主要问题; 同时权限设置引入的问题, 在呈上升的趋势;
CISQ 通过静态分析来实现软件质量的自动度量, 并采用对 CWE 的问题检测, 细化了衡量的标准。这为通过工具对应用软件质量的自动化度量提供了一个思路, 也为建立一个统一的标准下的软件质量的测评提供了重要依据。