网络安全反模式：摩擦软件

本文最初发表于 Open Government Products 的 Substack。提醒：我正在与 No Starch Press 合作出版新书！《From Day Zero to Zero Day》面向希望进入漏洞研究领域的新手。我将在 DEF CON 演讲（敬请关注）并举办签书会，Hacker Summer Camp 见！

没有人关心你构建的基础设施。你的工具用户永远不会像你那样深入理解它，也不会像你那样关心它……他们花在思考你的工具上的时间越少，他们就越快乐。他们被迫意外思考你的工具的那一天，对他们来说就是糟糕的一天。这种敏感性需要深深嵌入工具的 UX 中。易用的基础设施不在于编写良好的变更日志和开发者指南，而在于构建人们无需阅读任何文档即可使用的工具。 — Jay Gengelbach，Vercel 软件工程师

这是关于在 Open Government Products (OGP) 构建网络安全解决方案的第一原则系列博客文章的第二篇。从攻击性安全转向安全工程，我注意到安全与其它内部工具团队（如 devops、平台工程和站点可靠性工程）面临的许多挑战是共通的。只需将 Jay 上面引文中的“基础设施”替换为“安全工具”（事实上，请阅读整个 LinkedIn 帖子），你就会明白我的意思。这是一个关键的认识：安全并非每个人的首要任务。即使安全团队认为安全应该排在首位，现实是还有更多需要担心的事情——保持服务运行、开发下一个功能以及确保基础设施账单得到支付。然而，我们的安全工具往往没有反映这一现实。我评估过明显针对“133t h4x0r”原型的网络安全解决方案，从实时网络攻击地图到带有可怕名称的 APT 网络朋克插图。这些装饰实际上与大多数网络安全团队的核心工作不符。虽然我们愿意想象我们每天都在与 APT 作战，但许多组织更可能因为其攻击面上的简单弱点而被“高级持久青少年”击垮。此外，虽然可以论证专门为网络安全团队设计的工具，但并非每个组织都能建立全面的安全运营中心。相反，现代安全计划采用 DevSecOps 和针对开发者和维护者的“左移”平台。如果安全工具不是为他们设计的，我们怎么能期望软件工程师、系统管理员和非网络专家有效使用它们呢？ Ross Haleliuk 捕捉到了“这些值得提醒自己的明显事实”：

大多数安全从业者只是在做我们的工作
大多数公司不是科技公司
安全领域之外的大多数人不关心（也不会关心）安全

当安全团队忽视这些“明显事实”时会发生什么？

摩擦软件 🔗

让我们深入另一个虚构的例子：

Jane Doe 的管理层最近采购了一款顶级的 Gartner 魔力象限网络安全解决方案。它承诺检测并阻止对其 AI 应用程序的任何潜在攻击，而且实际上做得相当好。特别是，管理层对其华丽的仪表板印象深刻。Jane Doe 对其功能感到兴奋，承担了在组织中推广该平台的任务。然而，她很快遇到了障碍。由于组织的设置方式，有多个账户和资源分散在多个团队中。为了加入该平台，团队需要执行多个配置步骤，例如打开网络防火墙规则。此外，平台运行的扫描会产生计算和存储成本。团队加入缓慢， citing 更紧迫的优先事项以及对成本或维护的担忧。少数早期采用者遇到意外错误导致生产中断，这使情况雪上加霜。由于访问和工程资源有限，调试这些问题需要大量精力。 Jane 寻求管理层的支持以改善推广，并获得了支持。有了更多的交付经理，Jane 可以同时接触更多团队。加入率增加了，但技术问题的数量也增加了。团队被错误报告、追逐不合作的团队和其他繁忙工作压得喘不过气来。最重要的是，Jane 注意到另一个令人担忧的趋势——加入后，实际上没有人使用该平台。检测结果堆积如山，除了基本配置外，很少有人利用高级功能。她想更深入地研究这个问题，但每个人都忙于追逐团队加入。已经六个月过去了，截止日期即将来临……

不幸的是，尽管投入了更多资源，安全团队现在似乎更专注于不惜一切代价让用户加入，而不是实现实际的安全成果。虽然在某些情况下可能需要一些加入工作，但这次推广本可以做得更好吗？这是第二个网络安全反模式：摩擦软件。

什么创造了摩擦软件？ 🔗

摩擦软件是指在采用和使用过程中产生显著摩擦的安全工具，需要大量手动努力仅仅是为了维持覆盖范围。想象一下将一块大石头上山。斜坡上布满了障碍物和不平坦的表面，使旅程更加困难。你一松手，石头就会滚下来。同样，如果没有持续的加入努力，摩擦软件很快就会用户被抛弃。让我们审视一些摩擦软件的常见原因。

复杂的加入流程 🔗

第一个问题是需要加入。在理想世界中，你的组织有足够的中央平台，允许你向最终用户无形地推出额外的安全控制。一旦你需要用户进行某种手动干预，你的资源需求将开始随用户群的规模而扩展。现在你必须处理用户错误、客户服务和其他官僚开销。然而，我们并不总是生活在理想世界中，某些加入仍然是必要的。考虑大多数（成功的）面向消费者的科技产品如何设计其加入流程。他们优化流程以最大化注册并尽可能减少摩擦，甚至计算点击次数。严格分析真实用户监控和指标以寻找潜在的阻碍因素。未能将类似方法应用于内部工具（包括安全工具）会降低整个组织的生产力。在 Jason Chan 出色的“高速工程安全”博客文章中，他陈述了另一个“明显事实”：

安全团队是集中化团队——通过处理安全，我们支持整个业务。其他集中化团队包括法律、人力资源、设施和 IT。所有集中化团队共享的一条规则——你必须以低于公司增长的速度增长。

在 Jane 的案例研究中，她需要不断增加团队成员以跟上加入操作。如果团队增长受限，这也可能导致员工过度工作、加班以及从其他安全项目团队抽调资源。对于最终用户，Jason 分享了另一个重要见解：

在 Netflix 早期，我们查看了一些数据，显示工程师的平均任期约为 18 到 24 个月。这是让工程师产生效益并为业务做出贡献的时间。你希望如何花费这段时间？不是在安全培训和意识教育上。相反，你希望将资源投资于使你的安全系统和界面简单易用，即使是全新的工程师也能使用。

在 Jane 的情况下，常规软件工程师被迫投入额外时间并进行上下文切换以执行加入以及调试技术问题。实际的总运营成本远高于 Jane 团队纸面上的成本。你的加入流程越不繁重，你为组织释放的价值就越多。这需要摆脱安全孤岛，专注于实际成果，如“识别和解决可利用的漏洞”，而不是虚荣指标，如“覆盖率”或“用户数量”。

弱价值主张 🔗

第二个问题是没有为用户产生价值——尤其是非安全利益。在他的 Substack 中，Ross Haleliuk 谈到了两种类型的组织，其中安全和合规是生存风险——顶级目标如加密货币交易所或受严格监管的行业如医疗保健和金融服务。然而，大多数组织不属于这两类。在这些情况下，安全不是给定的，必须与其他优先事项竞争：

一旦风险变得更高，这种情况就会改变。当安全有可能影响公司在特定日期前交付关键功能、实现季度收入目标或启动关键合作伙伴整合的能力时，安全不能说“不”。真正重要的业务决策，那些具有战略权重的决策，是由产品、工程、进入市场和执行团队做出的。在这些房间里，安全最多是一个顾问，而不是一个有权力说“不”的关键参与者。

你的工具是否让最终用户（而不仅仅是安全团队）的事情变得更简单？它是否帮助他们更好地了解他们关心的事情，如成本归属？还是让他们的生活更艰难？即便如此，如果这是一个真正的安全问题，大多数理性的人愿意接受不便。你有多大信心你的工具产生的中断在这方面产生了真正的价值？

在上面的用户旅程中，未优化的漏洞管理框架最终由于低信噪比而为他人创造了更多繁忙工作。随着时间的推移，这可能导致警报疲劳，最终破坏工具的主要目的。此外，运营的总成本对安全团队是隐藏的，因为所有这些繁忙工作都是由最终用户完成的。

缺乏集成和“安全蔓延” 🔗

在 Jane 的场景中，一个问题缺乏使用。考虑开发者的典型日常工作流程：他们可能从 IDE 跳到 GitHub 或 GitLab，检查 Slack，也许还有一个任务跟踪器，偶尔查看他们的可观察性工具如 DataDog 或 Elastic。他们有多少次兴奋地跳入安全工具或仪表板？可能除非他们真的必须这样做。如果你的工具迫使用户跳出他们通常的工作流程，摸索凭证，并从零开始理解用户界面，它会产生大量额外的摩擦。此外，有时安全团队操作多个工具和平台，每个都有自己独立的界面和仪表板，创建了多个真相来源并迫使不断的上下文切换。

如何避免摩擦软件？ 🔗

内置，而非选择加入 🔗

避免加入摩擦的最佳方法是根本不需要加入。例如，如果你需要云可见性，你可以使用跨整个 AWS 组织的委托管理员权限轻松实现这一点。关键是与平台工程师和其他持有这些杠杆钥匙的内部工具团队合作。然而，一个推论是内置不应破坏任何东西。拥有超级管理员可能很棒，但一旦你拨动一个开关导致生产中断，预计该特权将很快被撤销。这限制了许多内置机制的范围为只读可见性。这就是为什么 Ross Haleliuk 强调可见性是安全团队可以完全控制的少数领域之一：

可见性现在是安全团队的核心功能，这是该角色变得多么复杂的直接结果。今天的安全团队正在应对快速移动的产品路线图、去中心化架构和不断增长的监管压力，通常权限和资源有限。在这种环境中，大多数组织中的所有安全团队被赋予的权力只是获得对其风险的可见性。

虽然这听起来有点宿命论，但重要的是利用这种可见性来帮助优先处理需要更大干预的更高影响任务。可见性突出显示热点，你可以将其带给管理层以证明更强的预防机制是合理的。就此而言，一些预防机制仍然可以以最小中断的方式内置。这些是高信号、检测和阻止工具，如秘密推送保护以防止秘密提交到代码，以及“无形”安全，如注入内部容器注册表的强化容器镜像。为了实现这一点，安全团队必须再次与其他内部工具团队合作，构建首先使这成为可能的平台——常见的 CI/CD 管道、容器注册表、内部包等。在 OGP，安全团队优先处理重要升级——SSO、企业计划、组织/多租户整合——这些为我们解锁了这些内置机制。虽然当时许多这些升级可能没有直接的“安全”链接，但它们实现了超越可见性的更有效干预。

使用强制功能 🔗

有时，并非所有东西都可以无缝内置。你可能需要你的用户执行一些配置步骤，尽管我认为这是缺少高杠杆机制的症状（见 Kelly Shortridge：“每个强化指南建议都是更安全默认值的错失机会”）。无论如何，不得不跟踪和追逐每个人完成每一步都不是一个可扩展的策略。在这种情况下，你可以利用强制功能。这些是用户工作流程中的关键漏斗，你可以在其中实施加入要求以继续工作流程的其余部分。例如，你可能希望所有部署的资源都被正确标记并满足某些强化配置。一位行业同事利用 Kyverno 策略即代码门在允许任何资源部署到组织的中央 Kubernetes 集群之前强制执行这些要求。没有安全配置，就没有生产部署。一些组织定期删除超过一定时间未标记的资源——经典的尖叫测试。所有这些听起来相当苛刻，因为你直接影响了用户部署到或留在生产环境的能力。这就是为什么强制功能必须精心设计：

强制功能失败的原因对用户是清晰且立即可见的。
自我解决失败的强制功能是简单的。

如果你在用户的工作流程中引入强制功能，你必须承诺使其简单易通过。如果需要，对你自己的团队施加 SLA——这是强制功能所有者的责任。

识别并瞄准重心 🔗

安全团队可能犯的最大错误之一是通过他们的工具创建额外的孤岛。有许多安全平台和工具与开发者的日常工作流程分离，但普通开发者不太可能愿意冒险离开他们通常的屏幕，除非他们绝对必须。这些是真正的重心所在。

数据重心 🔗

考虑 Jane 的场景，它要求系统所有者将其数据从其系统发送到安全平台。这真的必要吗？这些数据是否已经存储、丰富和分析在其他地方？这个问题是许多可观察性平台和云服务提供商能够转向利润丰厚的安全领域的原因。虽然它们最初通过提供日志记录和监控功能来解决开发者的问题，但它们很快意识到相同的数据对安全用例是无价的。Google Chronicle 联合创始人 Mike Wiacek 的这篇 LinkedIn 帖子特别有启发性：

2009 年，我正坐在谷歌会议室吃墨西哥卷饼时，被拉入了我职业生涯中最具形成性的安全事件之一：极光行动。对我来说，它不是从红色警报开始的。它是从一个墨西哥卷饼开始的。我们很快最终得到了一个写满 C2 主机名、不断变化的 IOCs 和一个试图追踪 APT 行为者跨越大规模基础设施的团队的白板。有人说：“如果我们能看到每台曾经查找过任何解析到此对手曾经接触过的任何网络块的任何东西的机器，那不是很好吗？” 桌子对面，后来成为我在 Chronicle 的联合创始人的 Shapor Naghibzadeh 说：“我有那个 DNS 数据。全部。” “为什么？怎么做到的？” “感觉有一天可能有用，”他说。那就是解锁的时刻。那时它点击了：👉 安全是一个数据搜索问题。不是一个政策问题。不是一个合规问题。不是一个“勾选框并希望”的问题。

很多时候，开发者和系统维护者已经将他们的日志发送到某个地方，因为这种可见性有助于解决他们自己的问题。Splunk、Elastic、DataDog 和许多其他可观察性平台都从解决这些 problem statements 开始，然后扩展到安全领域。在我们的案例中，当在 OGP 建立我们的检测和响应能力时，我们没有一开始就问：“开发者应该将他们的日志发送到哪里？”相反，我们问：“开发者已经将他们的日志发送到哪里？”并在其上构建我们的安全堆栈。这减少了大量的加入工作，因为开发者可以简单地调整他们现有的工具链（安全工程可以调整这些上游）以添加安全相关的日志，而不是将其发送到一个全新的目的地。

注意力重心 🔗

Jason Chan 还讨论了良好安全工具的另一个重要目标：最大化心流状态。

心流状态，或用于深度工作的 uninterrupted time，必须优化。我们的安全计划必须通过最小化计划外工作、未安排的中断和低价值会议来尊重心流状态。

维持心流状态的一部分是最小化将你带出工作流程的干扰。这就是注意力的重心发挥作用的地方。理想情况下，安全警报和问题直接集成到用户已经在日常访问的平台中，而不是将他们拉入一个他们不熟悉的单独平台。这推动了日志记录和可观察性与 on-call 和 paging 平台的整合——DataDog 最近发布了 DataDog On-Call 的通用可用性，Grafana 发布了其结合的事件响应和管理产品。这里有一个巨大的平台游戏，结合了可观察性、安全和响应。 OGP 安全工程团队的部分工作是在我们的工具和这些注意力重心之间构建这些集成——SlackOps、GitOps 和平台原生警报。一个额外的好处是，当开发者响应这些警报时，他们可以更快地行动，因为他们熟悉现有平台的用户界面和功能，减少了遏制和修复问题的时间。

案例研究：子域名接管 🔗

在 OGP，我们有多个产品团队完全拥有其部署的资源，包括域名。虽然这对开发速度和所有权很好，但这也可能导致基础设施的中央管理不善。因此，我们经历了一些子域名接管报告，因为团队未能维护他们在 Cloudflare 上的域名记录。为了解决这个问题，安全工程团队构建了一个子域名接管监控工具，该工具将从 Cloudflare 的 API 拉取所有域名记录并扫描常见的子域名接管指纹。这比使用攻击面管理工具暴力破解潜在子域名的“由外而内”方法更有效——相反，我们可以直接从 Cloudflare 获取区域记录。然而，由于需要获得对多个 Cloudflare 账户的 API 访问权限，我们面临加入挑战。Cloudflare 缺乏类似于 AWS Organizations 的真正多租户概念（Cloudflare 的租户 API 仅限于渠道和联盟合作伙伴/经销商），因此我们无法通过委托管理机制“无形地”获得访问权限。相反，我们必须手动加入每个账户。虽然这可能仍然作为一次性努力有效，但它无法解决加入未来账户的问题，而不必不断提醒用户这样做——记住，“良好的意图不起作用，机制才起作用”。在这种情况下，我们意识到，如果在 Cloudflare 上为组织的电子邮件域启用了单点登录 (SSO)，所有未来在该域下的登录，即使是在不同的 Cloudflare 账户上，也必须通过 SSO。这使我们能够使用 SSO 作为强制功能加入我们的域名监控工具：

产品团队想要创建一个新的 Cloudflare 账户并被 SSO 阻止（强制功能）。
作为解决 SSO 阻止（可以自动化）的一部分，产品团队被加入到子域名接管工具。

换句话说，“没有子域名接管监控，就没有 Cloudflare 账户”。有趣的是，使用 SSO 作为强制功能相当常见；检查 Sign in with Google 记录是许多“Shadow IT”工具映射组织用户正在使用哪些应用程序的方式。构建该工具的安全工程师 Zhong Liang Ou-Yang 还实现了一个自助服务的 GitOps 加入和漏洞管理工作流程，带有额外的 Slack 警报。这将持续的维护工作最小化为“如果有问题我们会让你知道”，同时确保工程师不必离开他们通常的平台。从长远来看，我们计划构建足够高的杠杆机制，以便我们可以内置子域名接管扫描（Cloudflare，请开放租户 API！）或通过官方的 Cloudflare 开发者平台集成。然而，仅仅拥有这种可见性已经使我们能够快速扫描我们整个攻击面上的其他常见漏洞，展示了构建多个杠杆的重要性。

结论 🔗

在这篇博客文章中，我解释了摩擦软件是如何发生的以及如何避免创建它们。实际上，在异构组织中推出安全工具并不容易。许多组织缺乏高杠杆机制来走“内置”路线，这就是为什么即使在用现有替代方案解决最 critical problems 的同时，也有必要投资创建这些机制。更重要的是，我希望强调这是一个自我延续的循环：如果你继续构建摩擦软件，你的资源需求将线性（或更糟，超线性）增长，将注意力和资源从构建良好机制上转移开，最终吸走房间里所有的氧气。剩下的是一个士气低落、过度工作的安全团队，更专注于虚荣指标而不是实际的安全成果。