2022年不容忽视的网络安全问题

本文的一个版本曾发表于《信息安全杂志》。本文经更新后在此同步发布。

‍

过去两年对所有人来说都堪称一场“烈火洗礼”。随着我们几乎在一夜之间转入远程办公模式，大多数组织的网络安全蓝图都经受了严峻考验。作为行业从业者，我们必须提高标准并积极适应，特别是在疫情爆发后，绝望的威胁行为者导致报告的网络犯罪激增了 300%。

我们都吸取了一些教训。令我感到欣慰的是，人们不仅更加重视通用的网络安全，对代码层面的软件安全和质量也愈发关注。拜登签署的关于保障软件供应链安全的行政命令揭示了关键问题，特别是在 SolarWinds 大规模入侵事件之后。我们都需要更加关注安全，并致力于通过可衡量的安全意识来减少漏洞，这无疑已成为讨论中更重要的一部分。

话虽如此，在与网络犯罪分子的博弈中，我们必须尽可能与他们保持同步，以预防性的思维抢先占领他们的“游乐场”。

以下是我认为他们在未来一年可能会兴风作浪的领域：

元宇宙：全新的攻击面

元宇宙可能是互联网的下一次进化，但大多数行业在保障软件和数字环境安全的方法上，尚未实现类似的转型。

虽然网络钓鱼等常见的网络安全陷阱不可避免（而且在每个人都在适应元宇宙的过程中，这些陷阱可能会大量出现），但构建这个沉浸式虚拟世界的基础设施和设备本身也需要得到保障。正如智能手机帮助我们实现了在线生活一样，VR 头显等外设正成为通往海量用户数据的新门户。要确保物联网设备的安全，就需要日益复杂的嵌入式系统安全技术，主流 VR/AR 的新世界也不例外。正如我们在 Log4Shell 漏洞中所见，代码层面的简单错误可能会演变成威胁行为者的“后台通行证”，而在模拟现实中，每一次移动都会产生可被窃取的数据。

尽管元宇宙尚处于起步阶段，但一个成功的元宇宙将需要加密货币（不仅仅是盲目囤积最新的模因币）和 NFT 等价值资产的实际应用，这意味着我们的现实财富、身份、数据和生计可能会暴露在一个新的“蛮荒西部”，从而使人们面临风险。在我们工程师开始疯狂追求史诗级功能和增强体验之前，从底层开始最小化这个广阔的新攻击面应成为重中之重。

Log4Shell 事件后的立法趋势

对于那些陷入混乱、争分夺秒地排查广泛使用的 Log4j 日志工具是否存在可利用版本或相关依赖项的开发者们来说，那个假期恐怕很难称得上愉快。

这次零日攻击是有史以来最严重的攻击之一，人们常将 Log4Shell 与毁灭性的 Heartbleed OpenSSL 漏洞相提并论，而后者在六年多后仍被利用。如果以此为鉴，我们将在很长一段时间内深受 Log4Shell 的后遗症困扰。显而易见，即使吸取了 Heartbleed 的教训——至少在需要尽快发布和实施补丁方面——许多组织在保护自身安全方面依然行动迟缓。根据公司规模的不同，打补丁可能极其困难且官僚化，需要跨部门的文档记录和实施。通常，IT 部门和开发人员并不了解所使用的所有库、组件和工具，且受限于严格的部署计划以尽量减少干扰和应用停机时间。这种工作方式有其合理原因（即：没人想节外生枝导致系统崩溃），但补丁更新太慢无异于坐以待毙。

正如SolarWinds 攻击改变了软件供应链的游戏规则一样，我预测 Log4Shell 之后也会发生类似的情况。虽然一些关键行业已经有了补丁管理的强制要求和建议，但广泛的立法则是另一回事。预防性软件安全永远是我们避免紧急安全补丁的最佳机会，但安全最佳实践规定，打补丁是不可妥协的优先事项。我认为这将成为一个热门话题，并促使人们提出明确的建议：尽快且频繁地更新补丁。

更加强调架构安全（但开发者尚未准备好）

新的《OWASP Top 10 2021》包含了一些重要的新增内容，同时也出现了一个令人惊讶的变化：注入漏洞从榜首跌至第三位。这些新增内容标志着开发者在安全编码和安全最佳实践方面的“第二阶段”旅程，遗憾的是，除非经过适当培训，否则大多数人并不具备减少此类风险的能力。

我们早就知道，如果我们要对抗代码中常见的安全漏洞，开发者必须具备安全技能，而各组织也正在更好地响应“开发者驱动的预防”这一前提。然而，随着“不安全的设计”进入 OWASP Top 10，且作为一种架构安全问题而非单一类型的安全漏洞，开发者在掌握基础知识后，需要被引导去探索更深层次的内容。学习涵盖威胁建模的环境——最好在安全团队的支持下——可以在开发者成功提升技能后减轻巨大的压力，但就目前而言，这对大多数软件工程师来说仍是一个巨大的知识缺口。

应对这一挑战需要“全员参与”，组织可以在为开发者创造积极的安全文化方面发挥作用，在不干扰其工作流程的前提下激发他们的好奇心。