我正在设置一台新电脑。我完成了注册屏幕，安装了我的软件，更改了我的壁纸，一切都运行良好。然而，我仍然有一种挥之不去的不安感：我不知道这台机器是否安全。我是一个计算机人员，所以我知道如何设置强密码和防火墙，但我仍然不确定我是否做对了所有事情。我求助于我的供应商，他们有望发布一份 安全加固指南。如果我非常热衷，我甚至可能会遵循 NSA 的 安全和网络分析中心指南。如果我做了任何这些事情，我已经比 95% 的用户更勤奋了。这是一个问题。
个人责任及其不共戴天的敌人，“我有更重要的事情要做。”
- 当用户对其自身安全负责时，事情就会出错。（照片由 flickr 上的 billselak 提供，已获得 CC-BY-ND 许可）
软件供应商让用户对其安全配置负责。他们不得不这样做。如果 Red Hat 在发货时已经包含了每一项推荐的安全配置更改，用户会哗变。他们会怨恨使他们的系统有用所需的所有额外工作。选择足够安全但又不会让用户感到厌烦的默认配置是一项微妙的平衡，供应商永远无法完全正确地做到这一点。因此，责任落到了用户身上。
除非用户非常有安全意识，否则他们不会对这种责任做任何事情。这真的不是他们的错。很难为您的特定系统找到“正确”的指导。即使您找到了合适的指导，您也必须手动进行所有推荐的更改。整个过程非常繁琐，而且您几乎肯定会做错。
数百万配置错误的系统连接到互联网。它们是僵尸网络、黑客和病毒的目标。Conficker蠕虫证明了这个问题有多么可怕 —— 而且没有人比联邦政府更感受到这种痛苦。因此，管理和预算办公室 (OMB) 不得不为此做些什么。
以下是首字母缩略词
联邦桌面核心配置 (FDCC) 应运而生。FDCC 基于空军已经完成的出色工作，是 OMB 强制联邦政府中每台 Windows 桌面进行的配置更改集。OMB 知道他们无法通过措辞强烈的备忘录来解决问题。该指南要求检查数百个配置项。要求人们系统地检查数百万台机器上的每个项目是容易出错、不切实际且残酷的。因此，OMB 要求美国国家标准与技术研究院 (NIST) 使 FDCC 变得容易。
NIST 提供了“安全内容自动化协议”，或 SCAP。SCAP（发音为 S-cap）由 NIST 已经在使用的一系列规范的首字母缩写组成：CVE、CCS、OVAL、XCCDF 等等。借助 SCAP，您可以用计算机可以理解的方式描述安全配置策略。因此，计算机可以读取指令并告诉您系统的对错，而无需人工阅读数十页的技术文档。
如果您有点像我，您读到这里会对自己说：“为什么以前没有人想到这一点？” 这种反应是一个好主意的标志。我们现在可以明确地描述“安全”配置，然后将该描述提供给工具，该工具会告诉我们是否已正确完成所有操作。这几乎是一个完美的解决方案。
明智的是，FDCC 计划认为决定这些配置应该是什么不是 NIST 的最佳和最高用途。相反，Red Hat 等供应商与 NIST、NSA 和其他政府机构合作，供应商在其网站上发布 SCAP 内容。这些 SCAP 文档可以被我机器上的 SCAP 工具下载，然后验证机器是否符合标准。这就像魔法一样。NIST 在国家清单计划网站上提供了指向各种 SCAP 内容的指针。
每个系统都是美丽而独特的雪花
- 例如，这是我的 Web 服务器。（照片由 flickr 上的 CaptPiper 提供，已获得 CC-BY-NC 许可）
巧妙的是，SCAP 内容（技术上是一个 XCCDF 文档）允许您定义涵盖不同类型场景的不同“配置文件”。使用这些配置文件，组织可以使用自己的更改来改进基线 SCAP 文档。您可以定义工作站、Web 服务器、数据库等的标准。您可以更具体：一个“低安全性”的 Web 服务器，一个“高安全性”的数据库等等。
这种灵活性允许组织从供应商处下载基线 SCAP，将其调整为公司标准、公司标准调整为部门标准、部门标准调整为项目标准等等，而不会丢失原始建议的踪迹。如果基线更新，则将该更改向下推送到链中是一个相对简单的事情。
SCAP 可以自我迭代
当 SCAP 工具执行审核时，它可以输出 XCCDF 报告。这很棒，因为结构良好的审核报告可以由中央机构存储、聚合和分析。这比当前的方法好得多，当前的方法迫使人们阅读成堆令人麻木的糟糕散文
[gunnar@willa ~]$ rpm -Va missing /var/lib/nfs/statd/sm (Permission denied) missing /var/lib/nfs/statd/sm.bak (Permission denied) ..?...... /usr/bin/chfn ..?...... /usr/bin/chsh
..等等，永远持续下去。您甚至可以想象工具供应商提供复杂的审核和报告工具，以衡量您随着时间的推移的相对安全性。像 McAfee 和 Tripwire 这样的人已经在做这件事了。显然，这对家庭用户和企业用户都同样有用。
凭借所有这些希望，SCAP 现在的关键在于广泛采用。SCAP 有可能被归入晦涩难懂的政府安全标准的世界，即使它如此明显地有用。那将是一场灾难。如果 SCAP 内容难以使用，或难以改进或创建，主流用户和管理员将不会费心。那么，我们如何确保 SCAP 的广泛采用呢？
使其无处不在且不可见
目标用户是那些懒得阅读安全指南的用户。他们将通过异常来管理安全，假设一切都很好，直到屏幕上的弹出窗口告诉他们出了问题。这应该是这样。如果我们依赖普通用户的专心来使安全工具有用，我们会感到失望的。
操作系统应附带基本的 SCAP 审核工具。基于 SCAP 的审核和报告应在后台进行。工具应默认自动下载 SCAP 内容。最终用户 SCAP 工具应允许用户表达其安全偏好，然后消失。用户只有在工具需要他们做某事时才应意识到该工具正在运行。
使其易于创建
目前，SCAP 内容必须手动创建。它看起来像这样
<Rule id="UNIX-STIG-3-2-9-8" selected="false" weight="10.0"> <title xml:lang="en">Manual Page File Permissions</title> <description xml:lang="en">Manual page file is more permissive than 644.</description> <reference> <dc:type>DISA PDI Number</dc:type> <dc:source>GEN001280</dc:source> </reference> </Rule> <Rule id="UNIX-STIG-3-2-9-9" selected="false" weight="10.0"> <title xml:lang="en">Library File Permissions</title> <description xml:lang="en">Library file is more permissive than 755.</description> <reference> <dc:type>DISA PDI Number</dc:type> <dc:source>GEN001300</dc:source> </reference> </Rule>
我们越早拥有将此转化为复选框、下拉菜单和单选按钮的 GUI 工具市场越好。安全官员或新手家庭用户越容易描述他们的偏好，该标准就越有可能被采用。已经有许多专有工具知道如何处理 XCCDF 和 SCAP，但真正需要的是一套跨平台和开源工具来推动采用。这些工具甚至可以是基于 Web 的 —— 任何鼓励人们在其组织中试验该标准的东西。
良好的 SCAP 应该共享
在适当的创建工具到位后，帮助 SCAP 内容创建者相互找到对方应该是一件简单的事情。他们可以比较笔记，制定最佳实践，并在彼此的成功基础上再接再厉。NIST 在其 SCAP 社区 和 国家清单计划 网站上已经有了一个良好的开端。
关于流程重要性的元注释
通过与供应商合作定义标准，然后强制政府使用该标准，NIST、DOD 和 OMB 不仅解决了有害的问题，而且为围绕该标准的工具创建了市场。每个人都理所当然地对政府干预和过度扩张保持警惕，但我认为这是解决“公共”问题的正确方法。没有一家安全工具供应商或操作系统供应商可以单独解决这个问题。它需要像美国政府这样庞大的集体购买力来推动此类标准的采用。
这些政府人员没有专横跋扈，而是决定使用他们的“软实力”，并确保工具和协议非常有用，以至于供应商必须疯了才
显然，如果政府在未咨询相关软件供应商的情况下向其用户提供了一堆配置指南，那么这场 SCAP 运动永远不会起步。这种情况已经发生了，而且行不通。DOD STIG、IAVA、各种民用基线 —— 它们彼此冲突，它们已经过时，有时甚至与供应商提供的指南相矛盾。一旦每个人都使用像 SCAP 这样的通用语言，就更容易就报告和补救策略达成共识。
那么我们能做什么呢？
如果您读到这里，您可能已经被 SCAP 的价值所折服。有几种方法可以参与其中，并推动这个标准向前发展。
首先，查看 NIST 的 SCAP 网站。那里有很多很棒的内容，并且有很多您可以加入的 邮件列表。
接下来，OpenSCAP 项目将欢迎您的帮助。它是一个底层库，处理 SCAP 协议的一些粗糙机制。secstate 项目是一个很好的起点，对于那些想要创建 GUI、Web 界面或以其他方式基于已完成的优秀工作进行构建的人来说，这是一个充满机遇的仙境。
最后，您可以参加（或至少阅读会议记录）NIST 于 9 月 27 日至 28 日在巴尔的摩举行的 SCAP 会议。我在那里等你。
7 条评论