你能通过Rekt测试吗？ - Trail of Bits博客
区块链开发者面临的最大挑战之一是客观评估自身安全态势并衡量其进展。为解决这个问题，由Trail of Bits CEO Dan Guido领导的Web3安全专家工作组在今年早些时候召开会议，创建了一个用于分析区块链团队安全状况的简单测试。我们称之为Rekt测试。
Rekt测试模仿了The Joel Test。25年前由软件开发人员Joel Spolsky开发的The Joel Test用12个简单的"是/否"问题取代了确定软件团队成熟度和质量的复杂流程。区块链行业需要类似的东西，因为当今复杂的指导更多是令人沮丧而非提供信息。
Rekt测试专注于最简单、最普遍适用的安全控制措施，帮助团队评估安全态势和衡量进展。组织对这些问题的"是"回答越多，就越能信任其运营质量。这不是区块链安全团队的最终清单，而是开始就重要安全控制措施进行知情讨论的一种方式。
在今年早些的"思想汇聚"会议上，一组行业领袖被挑战解决区块链生态系统中缺乏网络安全标准的问题。其中一场讨论由Trail of Bits CEO Dan Guido主持。其他参与者包括Nathan McCauley（Anchorage Digital）、Lee Mount（Euler Labs）、Shahar Madar（Fireblocks）、Mitchell Amador（Immunefi）、Nick Shalek（Ribbit Capital）等。通过他们的讨论，创建了Rekt测试：
Rekt测试
- 你是否记录了所有参与者、角色和权限？
- 你是否保存了所有依赖的外部服务、合约和预言机的文档？
- 你是否有书面且经过测试的事件响应计划？
- 你是否记录了攻击你系统的最佳方式？
- 你是否对所有员工进行身份验证和背景调查？
- 你是否有团队成员在其角色中明确定义了安全职责？
- 你是否要求生产系统使用硬件安全密钥？
- 你的密钥管理系统是否需要多人和物理步骤？
- 你是否为系统定义关键不变量并在每次提交时测试它们？
- 你是否使用最佳自动化工具来发现代码中的安全问题？
- 你是否进行外部审计并维护漏洞披露或漏洞赏金计划？
- 你是否考虑并减轻了滥用系统用户的途径？
区块链技术的格局多样化，不仅限于区块链，还包括去中心化协议、钱包、托管系统等，每个都有独特的安全细微差别。Rekt测试问题的后续解释反映了该小组达成的最佳实践共识，绝非详尽或绝对。Rekt测试的目的不是建立严格的基准，而是激发区块链社区中有意义的安全对话。因此，请将此解释视为这一关键对话的垫脚石。
1. 你是否记录了所有参与者、角色和权限？
全面记录所有影响区块链产品的参与者、角色和权限至关重要，因为这明确了谁可以访问系统资源以及他们被授权执行什么操作。参与者指与系统交互的实体；角色是分配给参与者或组的预定义权限集；权限定义特定权利和许可。
彻底记录这些实体有助于进行全面测试，使开发人员（和外部审计员）能够识别安全漏洞、不当访问控制、去中心化程度以及特定妥协场景中的潜在暴露。解决这些问题增强了系统的整体安全性和完整性。文档还作为审计员的参考点，比较实际访问权限与记录的权限，识别任何差异，并调查潜在安全风险。
2. 你是否保存了所有依赖的外部服务、合约和预言机的文档？
与外部智能合约、预言机和桥的交互是区块链应用程序预期许多关键功能的基础。新的区块链应用程序或服务也可能依赖组织外部开发的金融代币的假定安全态势，这增加了其复杂性和攻击面。因此，即使将最佳安全程序集成到软件开发过程中的组织也可能成为破坏性安全事件的受害者。
记录区块链系统使用的所有外部服务（如云托管服务和钱包提供商）、合约（如DeFi协议）和预言机（如定价信息）至关重要，以识别风险暴露并减轻事件影响。这样做将帮助您回答以下基本问题：
- 我们如何知道外部依赖项遭受安全事件？
- 我们宣布安全事件的具体条件是什么？
- 当我们检测到一个事件时，我们将采取什么步骤？
回答这些问题将帮助您在不可避免地发生安全事件影响您无法控制的依赖项时做好准备。您应该能够注意到依赖项输出、接口或假定程序状态的任何变化（无论是否无害）；评估其安全影响；并采取必要的后续步骤。这将限制对您系统的安全影响，并帮助确保其不间断运行。
3. 你是否有书面且经过测试的事件响应计划？
虽然区块链领域的安全与传统产品安全不同（更集中或封闭的系统可能更容易控制），但两者都需要有效的事件响应计划，以帮助在面临安全事件时保持弹性。该计划应包括通过自动和手动程序识别、遏制和修复事件的步骤。组织应提供培训，确保所有团队成员熟悉该计划，并应包括通过内部和带外渠道沟通事件的步骤。该计划应定期测试，以确保其最新和有效，特别是考虑到区块链安全世界变化的速度。您应创建自己的事件响应（IR）计划，并可以使用此Trail of Bits指南作为资源。
对于区块链系统，IR计划通过确保组织不过度依赖任何单个人来减轻关键人员风险尤为重要。该计划应预测关键人员可能不可用或受胁迫的场景，并概述确保运营连续性的步骤。开发人员应考虑分散访问控制、实施基于法定人数的批准并记录程序，以便多个团队成员准备好响应。
对于区块链系统，事件响应应该是主动的，而不仅仅是被动的，这一点尤其重要。合约应在创建IR计划时使用诸如保护启动之类的策略来设计，以逐步部署新代码。开发人员应考虑是否希望在合约中包含可暂停功能，以及协议的哪些部分应该或不应该可升级或去中心化，因为这会影响团队在事件期间的能力。
4. 你是否记录了攻击你系统的最佳方式？
通过构建记录所有潜在攻击系统途径的威胁模型，您可以了解现有安全控制是否足以减轻攻击。威胁模型应直观地展示产品的整个生态系统，包括软件开发之外的信息，如应用程序、系统、网络、分布式系统、硬件和业务流程。它应识别系统的所有弱点，并清楚解释攻击者如何利用它们，结合相关现实世界攻击的信息，帮助您避免犯同样的错误。
这些信息将帮助您了解是否将精力集中在正确的位置——即，您当前减轻攻击的努力是否与攻击最可能发生的方式和位置一致。它将帮助您了解对系统的成功攻击会是什么样子，以及您是否充分准备好检测、响应和遏制它。一个好的威胁模型应消除意外，使您的团队能够有意识地规划缓解措施。
5. 你是否对所有员工进行身份验证和背景调查？
假名开发在区块链行业很常见，但它阻碍了问责制、合同执行以及在区块链产品利益相关者之间建立信任。恶意行为者可以利用缺乏身份验证和背景调查来干扰产品开发、窃取资金或造成其他严重损害，而机构将没有或有限的手段惩罚他们。近年来，朝鲜黑客使用虚假Linkedin账户申请真实职位，并冒充公司提供欺诈性职位。这些做法直接导致了严重黑客攻击，包括Axie Infinity的5.4亿美元损失。
因此，公司必须了解所有员工的身份并进行背景调查，包括使用公共假名的员工。公司还必须在访问控制和监控方面达到额外的成熟度；例如，他们应根据员工的角色、背景和居住地（即考虑当地法律和管辖权）围绕运营安全做出谨慎决策。
6. 你是否有团队成员在其角色中明确定义了安全职责？
团队中需要有一个人负责确保区块链系统的安全。针对区块链技术的威胁迅速发展，即使是一次安全事件也可能是毁灭性的。只有专门的安全工程师才有时间、知识和技能集来识别威胁、分类事件和修复漏洞，这有助于在产品开发过程中建立信任。
理想情况下，此人将创建并监督一个专门团队，将安全作为其工作职责的首要任务，最终拥有使组织能够对此列表中的其他问题回答"是"的倡议。他们将监督跨部门工作，与开发人员、管理员、项目负责人、高管等合作，确保安全实践包含在组织的所有方面。
7. 你是否要求生产系统使用硬件安全密钥？
凭据填充、SIM交换攻击和鱼叉式网络钓鱼几乎已经抵消了密码和SMS/推送双因素认证的保护能力。对于有价值处于危险中的高风险组织，防钓鱼硬件密钥是唯一合理的选择。应使用特殊硬件密钥访问公司资源，包括电子邮件、聊天、服务器和软件开发平台。应特别小心保护生产中任何非常困难或无法逆转的操作。
在组织内部使用这些密钥是 competent 链外基础设施管理的主要指标。如果这对您的IT团队来说似乎是一项繁重的工作，请不要气馁。2016年，谷歌发布的一项研究表明，实施这些密钥很简单，在其5万名员工中很受欢迎，并且能有效抵御恶意攻击。U2F硬件令牌，如YubiKey和Google Titan，是硬件密钥的不错选择。
8. 你的密钥管理系统是否需要多人和物理步骤？
如果单个人维护控制您系统的密钥，他们可以在没有相关利益相关者共识的情况下单方面做出具有过大影响的更改。如果攻击者破坏了他们的凭据，他们可以获得核心资产的完全控制权。
相反，密钥管理应设置为需要多人共识或法定人数以及物理访问才能做出重要决策。多人完整性是高风险行业（如国防和传统金融）使用的有效安全策略；它们一举保护免受攻击者、内部威胁（例如，恶意员工）和胁迫的侵害。在选择基于法定人数设置的可信个体集时，选择既可信又适当激励的人至关重要，因为包括不合适或不对齐的个体可能会破坏系统对胁迫的抵抗能力。通过额外要求物理密钥管理（例如，使用物理保险箱或气隙设备存储密钥），您将显著降低任何个人的欺诈、盗窃、滥用或错误风险，或者如果任何个人的密钥或密钥片段被泄露。
区块链组织应使用多签名或多方计算（MPC）控件和冷存储解决方案，至少用于持有大部分资产的中心钱包，或选择使用合格的托管人，具体取决于特定法规和需求。解锁多签名钱包的密钥应存储在可信硬件上，例如硬件安全模块（HSM）、安全飞地或防篡改硬件钱包。
必须仔细部署和配置可信硬件以限制其攻击面。例如，绝不应可提取秘密，并应避免网络连接。组织还应建立基于阈值、受影响钱包、目的地和发起交易的关键人员等参数的严格资金转移程序。
9. 你是否为系统定义关键不变量并在每次提交时测试它们？
不变量是在程序执行过程中必须保持为真的条件。不变量可以针对整个系统（例如，任何用户都不应拥有超过总供应量的代币）或针对特定功能（例如，compute_price函数不能导致免费资产）。理解和定义不变量有助于开发人员明确系统的预期行为，并帮助安全工程师评估这些行为是否符合期望。这为安全测试提供了路线图，并减少了意外结果和故障的可能性。
定义不变量首先用简单的英语记录关于系统的假设。这些不变量应涵盖广泛的功能和加密属性及其有效状态、状态转换和高级行为。规范良好的系统可能有数百个属性：您应首先关注最重要的属性，并不断努力改进其覆盖深度。为确保代码遵循不变量，必须在整个开发过程中使用自动化工具（如模糊测试器或基于形式方法的工具）进行测试。
10. 你是否使用最佳自动化工具来发现代码中的安全问题？
自动化安全工具是成功安全策略的基线要求。完全自动化的工具，如静态分析器，自动发现常见错误且维护需求低，而半自动化工具，如模糊测试器，允许开发人员更进一步检查逻辑问题。有许多此类工具可用，但我们推荐使用顶级安全工程师积极使用的工具，并且有已发现错误的可靠记录。
Trail of Bits的智能合约安全工具使用最先进的技术，可以集成到您的CI系统和编辑/测试/调试周期中。它们包括Echidna，一个用于Solidity智能合约的模糊测试器，和Slither，一个用于Solidity智能合约的静态分析器。在开发和测试过程中自动化使用这些工具有助于开发人员在部署前捕获关键安全错误。
11. 你是否进行外部审计并维护漏洞披露或漏洞赏金计划？
要识别区块链代码中的漏洞，仅依赖内部安全团队是不够的。相反，组织必须与拥有现代区块链技术深入知识的外部审计员合作，涵盖低级实现、金融产品及其基本假设，以及为现代应用程序提供动力的库、服务、桥和其他基础设施。（跟踪区块链安全事件的网站上充满了有时未为复杂变更寻求外部指导的公司。）
安全审计员帮助识别漏洞，并提供重组开发和测试工作流程的建议，以便这些漏洞不会再次出现。在寻找审计时，重要的是要澄清哪些组件正在审查中，哪些被排除，以及应投入的努力水平，包括通过使用工具。通过了解审计的好处和局限性，组织可以在审计结束后专注于需要改进的其他领域。
此外，漏洞披露或漏洞赏金计划可以通过为用户或研究人员在发现错误时提供公开可访问的联系选项来增强您的安全态势。通过建立这些计划，组织表现出与独立错误猎人合作的意愿——而没有这些计划，他们可能会在社交媒体上公开披露错误，甚至为了自身利益利用它们。虽然这些计划提供许多好处，但考虑其局限性和陷阱很重要。例如，漏洞赏金猎人不会提供提高系统安全成熟度或长期减少错误可能性的建议。此外，您的团队仍将负责分类错误提交，这可能需要持续的专用资源。
12. 你是否考虑并减轻了滥用系统用户的途径？
许多针对区块链的攻击，如网络钓鱼、Twitter/Discord诈骗和"杀猪盘"，试图欺骗用户在使用您的产品时采取不可挽回的行动。即使组织拥有最专业设计的安全系统来保护自己，其用户可能仍然脆弱。例如，区块链应用程序通常依赖加密签名，这增加了网络钓鱼尝试的可能性。开发人员应考虑使签名易于识别（例如，使用EIP-712），并应创建和推广指导以最小化滥用风险。
为避免此类攻击，组织的安全策略应包括滥用测试，您的团队考虑攻击者如何造成社会、心理和物理伤害。了解重大财务或社会伤害的风险将帮助您的团队评估必要的流程和缓解措施。例如，如果您的协议用户包括高影响力利益相关者，如退休基金，基于协议费用创建保险基金可能有助于在发生妥协时使用户完整。
不要被Rekt
这12项控制措施不是决定您安全态势的唯一行动，但我们相信它们将增强每个开发人员的软件和运营安全，即使区块链技术快速发展。此测试不应作为一次性练习；这些问题具有持久价值，并应随着组织继续增长和开发新产品而提供路线图。对这些问题的"是"回答并不意味着您将完全避免安全事件，但它可以使您和您的团队能够避开行业中最糟糕的标签：被rekt。
如果您喜欢这篇文章，请分享： Twitter LinkedIn GitHub Mastodon Hacker News