Gartner近日发布了美国联邦政府2024年预测，预测称为了管理人工智能、软件供应链安全和零信任，美国联邦政府发布了大胆的政策，给首席信息官的资源配置和实施带来了新的挑战。本研究的背景和建议可以帮助首席信息官实现政策目标。

主要发现

  • 为了制定联邦机构人工智能 (AI) 采用的使用和衡量标准，拜登-哈里斯政府于 2023 年 10 月 30 日以行政命令 (EO) 的形式发布了关于“安全、可靠和值得信赖的发展和人工智能的使用。”政府已就实施指南草案征求公众意见。

  • 联邦政府正试图对销售给联邦机构的商业软件产品实施严格的监管标准，从而改变整个行业。该标准在管理和预算办公室 (OMB) 备忘录“通过安全软件开发实践增强软件供应链的安全性”中予以体现。

  • OMB备忘录“推动美国政府走向零信任网络安全原则”，解决了身份、设备、网络/环境、应用程序/工作负载和数据的安全问题，但资源仍然不足。

建议

  • 开始准备使用美国国家标准与技术研究院 (NIST) 人工智能风险管理框架 (AI RMF) 来衡量人工智能管理。继续在联邦人工智能用例清单中捕获机构人工智能用例，以彻底解释供应商实现人工智能可信度的方法。

  • 与采购官员合作，通过完善库存并设定软件物料清单 (SBOM) 要求和可接受的不合格水平，将安全软件开发框架 (SSDF) 要求纳入合同中。

  • 通过解决长期问题的根本原因（例如无法实施多因素身份验证 (MFA)、要求所有新工作合规以及及时完成要求较低的要求）来追求零信任网络安全目标。

战略规划假设

到 2027 年，美国 OMB 将建立强制记分卡，以促进机构人工智能成熟度和风险管理。

到 2027 年，70% 的美国联邦商业软件合同将要求遵守 SSDF，从而改变行业惯例。

到 2026 年，75% 的美国联邦机构将因资金和专业知识短缺而无法实施零信任安全策略。

需要知道什么

人工智能：机构首席信息官现在必须为人工智能行政命令制定的合规措施做好准备。这些措施可能会纳入行政部门记分卡、监察长审计计划和国会活动，例如针对《联邦信息技术采购改革法案》进行的活动。首席信息官已经根据先前的指令参与了衡量工作，提交了人工智能用例。最新政策将增加人工智能使用机构管理的可报告方面，首席信息官应立即采取措施解决日益加强的监督问题。

软件供应链：OMB备忘录“通过安全软件开发实践增强软件供应链的安全”（日期为 2022 年 9 月 14 日）及其 2023 年更新，试图加强行业对软件安全的责任。SolarWinds、Microsoft Exchange、Kaseya 和 Apache Log4j漏洞等事件就是妥协的例子，这些妥协促使联邦政府对向联邦机构销售软件的供应商变得更加直接。政府政策指示各机构从供应商处获取有关其满足 NIST SSDF 要求的能力的一致性声明。该政策还指示联邦机构从供应商处收集 SBOM。指导软件供应商遵循政府指定的开发方法并公开他们可能认为专有的信息可能会严重扰乱该行业。首席信息官必须与采购官员合作，并在整体政策不明确的情况下为其机构制定指导。

零信任：作为广泛网络安全议程的一部分，联邦机构的八个优先事项之一“零信任”在 2021 年 5 月的《改善国家网络安全行政命令》(EO 14028) 中被提出。其他网络安全优先事项包括云采用、MFA 、数据加密、保护关键软件、推动供应商采用安全软件开发实践、保护终端并改进事件记录。EO 14028 为一系列标准和政策奠定了基础，零信任是一个包含其他七个优先事项中大部分内容的领域。联邦首席信息官和首席信息安全官多年来一直在推进网络安全，但过去几年政府机构面临的威胁激增。联邦机构的具体零信任要求无疑是适当且必要的回应。然而，这些要求和截止日期与资源配置不一致。迫切需求与可用资源之间的紧张关系在政府中很常见，首席信息官需要尽可能地取得最佳平衡。

战略规划假设：到 2027 年，OMB 将建立强制记分卡，以促进机构人工智能成熟度和风险管理。

主要发现：

  • AI EO提高了美国联邦机构在协调、监督和领导等领域改善 AI 管理的需求。

  • 美国联邦政府仍然致力于开发人工智能解决方案，以促进创新、降低风险并提高可信度。

  • 几个月来，各机构一直在跟踪正在进行的人工智能项目的数量，当前的清单列表显示了政府范围内发生的 700 多项举措，如图 1 所示，该图显示了各机构的人工智能项目数量。

图 1：按机构划分的人工智能项目数量

人工智能用例清单

市场影响：

  • 战略和规划的初步护栏：AI EO 的一个重要方面是初步建立与在以下领域部署人工智能项目的战略和规划相关的监督护栏：

o扩大有关机构使用方式以及机构如何管理这些风险的报告。

o发布该机构遵守 AI EO 的计划。

o指定首席人工智能官来领导和管理活动。

  • 正式基准的潜力：如果国会制定正式基准，这些措施将进一步包含要求机构永久遵守的具有约束力的权力。就目前的形式而言，该指南几乎肯定会得到机构负责人的自愿遵守，但未来的政府很容易被取消或不强制执行。

  • 衡量成熟度和风险的标准：用于评估各个机构的基准衡量标准（例如 IT 记分卡）将为监管机构提供一致的衡量标准，以确定机构绩效的以下两个关键方面的有效性：

o成熟度：验证项目是否进展顺利。

o风险管理：确定管理是否无意中恶化并需要干预。

  • 行业和商业合作伙伴责任：评估流程，如联邦风险和授权管理计划 (FedRAMP)，详细说明供应商建立风险管理程序的程度。这确保了人工智能解决方案的安全性和可信性，从而将部分责任转移给商业合作伙伴。

建议：

  • 开始：应用 NISTAI RMF 1.0框架作为标准化 AI 项目管理的完整工作流程。该指南提供了应从一开始就考虑三个主要主题的详细小节，包括：

o地图：识别背景并识别风险

o措施：评估、分析或跟踪风险

o管理：确定风险优先级并根据影响采取行动

  • 停止：将人工智能工作外包给没有适当的结构化方法来描述他们如何管理和降低风险的供应商。

  • 继续：修改和改进有关您的机构如何使用人工智能以及如何管理风险的报告，使其成为部署解决方案的利益相关者之间的文化现状。

战略规划假设：到 2027 年，70% 的联邦商业软件合同将要求符合 SSDF，从而改变这一过程中的行业惯例。

主要发现：

  • 政府正试图对出售给联邦机构的商业软件产品的开发实施严格的监管标准。

  • 实施这一要求的时间表非常紧迫，几乎不切实际。

  • 公众评论和行业担忧推迟了政策的实施。

  • 实现政策目标的大部分工作必须由机构采购组织完成。

市场影响：

  • 严格、结构化的实践：美国联邦政府在 2021 年 5 月的《改善国家网络安全行政命令》中发起了针对软件供应链安全的重点工作。OMB 备忘录 (M-22-18)“通过安全软件开发实践增强软件供应链的安全性”详细阐述了要求。该指令要求各机构获得软件供应商的证明，以确保其符合 NIST 特别出版物 (SP) 800-218、SSDF，如表 1 所示。关键软件的证明应在九个月内到期，非关键软件的证明应在一年内到期。M-22-18 对软件具有以下深远的定义：

“固件、操作系统、应用程序和应用程序服务（例如基于云的软件）以及包含软件的产品”—OMB备忘录 M-22-18

表1：SSDF 实践总结

准备组织

保护软件

开发安全性良好的软件

应对漏洞

定义软件开发的安全要求 (3)

保护所有形式的代码免遭未经授权的访问和篡改 (1)

设计软件以满足安全要求并降低安全风险 (3)

持续识别并确认漏洞 (3)

落实角色和职责 (3)

提供验证软件发布完整性的机制(1)

审查软件设计以验证是否符合安全要求和风险信息 (1)

评估漏洞、确定优先级并修复漏洞 (2)

实施支持工具链 (3)

存档并保护每个软件版本 (2)

在可行的情况下重用现有的、安全性良好的软件，而不是重复功能 (3)

分析漏洞以确定其根本原因 (4)

定义和使用软件安全检查标准 (2)

通过遵守安全编码实践来创建源代码 (1)

实施和维护软件开发的安全环境 (2)

配置编译、解释器和构建过程以提高可执行文件的安全性 (2)

审查和/或分析人类可读的代码以识别漏洞并验证是否符合安全要求(2)

测试可执行代码以识别漏洞并验证是否符合安全要求 (2)

将软件配置为默认具有安全设置 (2)

括号中的数字 (x) 指练习的任务数

资料来源：国家标准与技术研究所特别出版物 800-218

·积极的时间表：这是一个非常积极的时间表，取决于国土安全部的网络安全和基础设施安全局 (CISA) 在截止日期之前尽早建立供应商认证的通用表格。CISA 比原计划晚了三个月才提交了初稿。该草案此后多次接受公众意见征询。

正如对这种破坏性政策的预期，信息和通信技术 (ICT) 行业通过信息技术行业委员会对 M-22-18 提出了广泛的担忧。NIST 和 OMB 于 2023 年 6 月举办了一次公共研讨会，讨论政策实施。在此输入之后，OMB 发布了修订后的指南。修订后的指南修改了截止日期。现在，各机构必须在 OMB 批准通用表格最终版本后的三个月内获得关键软件的供应商认证。其他非关键软件的认证应在 OMB 批准通用表格后六个月内完成。

·供应商合规性：除了改变合规截止日期外，修订后的指南还加强了对不能完全合规的供应商的审查。无法完全证明 NIST SP 800-218 合规性的供应商必须提交行动计划和里程碑 (POA&M)，以降低风险并完全合规。在最初的要求中，允许各机构独立决定是否接受供应商 POA&M。根据修订后的指导意见，各机构必须就 POA&M 和合规性扩展寻求 OMB 的同意。

M-22-18中阐述了 SBOM 的要求，但措辞有些模糊，允许各机构自行决定寻求 SBOM。联邦机构对这一要求的措辞可能有不同的解释。一些机构可能将其解释为获取所有关键软件的 SBOM 的要求，而对于其他非关键软件，SBOM 是可选的。无论机构可能寻求何种软件产品的 SBOM，最低 SBOM 要求均已由国家电信和信息管理局定义。

SSDF政策提出了必须纳入现有软件合同关系的要求。虽然将 SSDF 一致性添加到新合同中可以说是简单的，但根据要求修改现有软件合同将需要谈判，而且很可能还需要财务考虑。在三到六个月的时间内，所有软件合同似乎不太可能发生这种情况。采购官员，而不是信息通信技术人员，必须推动合同修改工作。

建议：

  • 通过更新软件清单以包括关键和非关键产品的名称，协助采购办公室修改合同。

  • 通过就合同方面的问题向高级领导层提供建议并与高级采购官员合作，制定实现政策目标的共同责任。

  • 通过建立软件供应商何时需要 SBOM 以及如何使用该信息的标准，确定 SSDF 认证之外的数据要求。

  • 通过为可接受的 POA&M 设置标准来建立软件供应商不合格标准。

战略规划假设：到2026年，至少75%的美国联邦机构由于资金和专业知识短缺而不会全面实施零信任安全策略。

主要发现：

  • 2022年 1 月的 OMB M-22-09 规定了联邦机构的具体零信任要求和截止日期。

  • 要求很广泛，涵盖 CISA 零信任成熟度模型的所有方面（如图 2 所示），并具有大量投资和变更管理。

  • 尚未为此特定目的拨款，并且首次将零信任纳入预算制定过程的机会是 2024 财年（2023 年 10 月至 2024 年 9 月）。

  • 实现 M-22-09 目标的最后期限是2024 年 9 月 30 日。鉴于国会通过联邦预算通常会出现延迟，零信任计划的资金可能要到 2024 财年第二季度才能到位，只允许实现目标的部分年份。

图 2：美国联邦零信任要求

市场影响：

  • 支出激增：联邦机构在零信任方面的支出和努力预计将在 2024 财年下半年激增。

  • 例外流程：与其他合规期限一致，例如过渡到企业基础设施解决方案 (EIS)，各机构将难以实现目标。OMB 在面临明显的合规缺陷时，可能会为那些在 2024 年 9 月之前无法实现目标的人制定例外流程。

  • 实现目标的压力：尽管存在时间安排、资金可用性和其他竞争性网络安全需求方面的挑战，首席信息官仍将在许多方面面临实现目标的压力。监察长对各部门和机构进行年度《联邦信息安全管理法案》(FISMA) 审计的指标每年都会更新。这些指标已经包括 EO 14028 的某些方面，零信任计划就源于此。可以合理地假设 FISMA 指标的进一步更新将反映更具体的 M-22-09 目标，从而产生正式的审计结果。此外，FISMA 审计已纳入国会《联邦 IT 采购改革法案》(FITARA) 的记分卡中。

  • 有限的公开报告：尽管审计和衍生的 FITARA 评分可能会捕获零信任成就或缺乏零信任成就，但有关零信任进展具体细节的公开报告可能会受到限制或混淆。这是为了避免为了恶意行为者的利益而识别政府网络安全的薄弱环节。此前，从联邦 IT 仪表板删除 FISMA 分数时，也曾限制公众访问类似的敏感数据。

  • 长期要求：M-22-09 的许多方面重申了长期政策，例如使用 MFA 和持续诊断和缓解 (CDM) 工具。M-22-09 的其他方面无需大量费用或变更管理即可实现。

  • 未能满足最后期限：未能满足政策最后期限将继续使联邦机构面临本可以减轻的风险。这可能会导致重要的政府服务中断或敏感信息泄露，这两者都会对解决可以避免的问题产生重大的财政影响。即使是最好的网络安全实施也无法避免安全漏洞的发生。尽管如此，那些未能全面、及时采取零信任措施的机构及其首席信息官将受到最负面的审查。可悲的是，违规行为往往会促使人们关注和投资缓解措施，而这是可预见的需求。

理由：

由于美国国会内部动荡、众议院议长更替以及预算审议旷日持久，这一2023年的预测被重演。持续的预算不确定性强调了行政部门政策与实现网络安全目标所需资源之间的脱节。

建议：

  • 解决长期问题：通过关注根本原因并利用当前网络安全政策激增来获得高层领导对变革的支持，解决重申先前政策的 M-22-09 领域之前无法实现合规的问题，例如 MFA 和 CDM 工具。

  • 阻止问题增长：通过确保所有新的开发工作都纳入尽可能多的适当的零信任目标，防止合规问题的增长。

  • 选择容易实现的目标：通过及时解决 M-22-09 中不太困难的方面（例如简化密码要求和维护漏洞披露计划）来增强合规性。