提高 AWS 及其他公司的安全标准

Clarke (10:27)：
我想，不是所有在 AWS 安全部门工作的开发人员一开始都具有强大的安全工程背景。你们通过什么样的机制来使这些开发人员达到你们为 AWS 安全设置的标准？ 尤其是在构建工具甚至是面向客户的安全产品方面？

Eric (10:50)：
可以从几个角度来考虑这个问题。一方面，亚马逊的安全是构建者的原则。我们不能随心所欲。我们不能仅仅通过在团队中增加工程师来扩展业务。所以，我们的大量工作都是在构建工具。这确实是软件开发，就像您在亚马逊任何其他团队所做的一样，只不过您构建的是安全工具。我们的许多工程师都不是安全工程师，他们没有安全方面的背景。他们不需要具备任何特定的安全专业知识即可加入团队。他们中的一些人对安全充满热情，其中一些人只是喜欢他们正在从事的工作和所处的团队，他们乐于做手头的工作，但他们对安全没有特别的兴趣，这没关系。

Eric (11:37)：
整个安全领域在于弄清楚某些构建者做了什么假设，然后弄清楚如何违反这些假设以将系统推入意想不到的状态。将整个硬盘驱动器的数据塞入该字段时会发生什么？ 将拨盘调到 11 时会发生什么？ 在该字段中输入负数时会发生什么？ 以我的经验，这种思维方式往往是与生俱来的，而且很难教授。

Eric (12:18)：
当我们找到这种思维方式的人时，可以向他们教授所有特定的安全知识，所有日常技术，我们可以很容易地让人们了解它们。我现在每天都在做的事情在我上大学时还不存在，我在大学里学到的基础知识仍然适用，但没有一项具体的技术是这种情况。我们实际上有一个非常强大的计划来增加具有特定安全意识的人员。

Eric (12:46)：
您的问题的答案分为两个方面。有一群人，我们不需要加强他们的安全性。这是一个标准的开发工作。这是一个标准的构建者角色。他们出类拔萃。他们中的一些人确实表达了对安全的兴趣，这很好，我们鼓励这样做。但这不是必需的。然后在另一方面，我们会寻找那些倾向于弄清楚如何破坏东西的人。 提出“如何破坏东西？”的问题自然会导致“该如何修复它们，以免它们再次被破坏？” 所有特定于工作的技能都可以教授。

Clarke (14:03)：
在这一点上，或者我猜是相反的情况，我们的许多客户试图在自己的开发社区建立安全专业知识，他们采取的途径之一是聘请安全专家并让他们加入一个“常规开发团队”，以帮助在该团队中建立安全标准，并基本上拥有安全卫士的心态。这种想法是，我们的安全专家数量有限，因此我们尝试将他们分散到不同的开发团队中，最终让安全水平得到普遍提升。这与 AWS 和亚马逊的方法是否类似，我们如何看待事物，或者因为安全是我们的精神特质，每个人都意识到，“我对我的应用程序的安全负有一定的责任，因此，我将遵循这个流程”? 您能谈谈这是怎么回事吗？

Eric (14:58)：
当然可以！安全性是头等大事。我们从根本上相信，安全性和可扩展性、可用性、低延迟、低抖动一样，都是客户体验的一部分。它存在于我们所构建的所有内容之中。也就是说，安全专业知识并不常见。我们的安全工程师数量没有我们希望的那样多。我的意思是，如果我们的每个开发人员都是安全专家，我会非常开心。我就不会太过紧张。我认为您使用的“安全卫士”这个词很有趣，因为这是我们内部项目的名称，我们在服务团队中寻找有安全意识的人，并对他们进行培训，支持他们提高自身安全技能，这样他们就可以帮助影响整个服务团队。

Eric (16:38)：
然后，在制定重大决策时，他们不必在孤立无助的情况下表态：“作为这里唯一的安全卫士，我觉得它还没有准备好发布，或者我们需要做这些额外的工作。” 他们可以利用整个安全组织，我们可以从客户的角度出发，共同努力，找出对客户来说正确的做法。如果我们提供了一项不安全的服务，这对客户来说是错误的结果，但如果我们不提供该服务……就像没有一个客户会喜欢一项不存在的服务，所以我们必须取得适当的平衡。通过将安全专业知识融入到服务团队中，与服务团队产生深刻的共鸣，然后 AWS 安全团队中的安全专业知识仍然可以与服务团队产生共鸣，但我们更多地扮演审计员的角色，我们可以更快、更好地做出决策。

Clarke (17:28)：
我想这会减轻……再次强调，我在与很多客户的对话中发现，安全部门被认为是不受欢迎的部门，或者是为了让应用程序发布，需要避开的部门。有了您刚才谈到的这个模型，信任的桥梁似乎得到了延伸。在我们的例子中，每个人都意识到，“嗯，安全只是工作的一部分，这就是我们在亚马逊的行事方式”。最终的结果是推出一款更安全的产品。
 
Eric (18:00)：
一段时间前，我们试图提出一个使命宣言。比如，说明 AWS 安全是做什么的？ 我们想出的最好的宣言是保驾护航。这是四个字，我认为它很好地诠释了我们存在的原因。这家公司不是为了从事安全性方面的业务而创建的。它的名称是 Amazon Web Services，而不是 Amazon Security。我们的使命是为客户提供 Web 服务。如果我们不发货，我们就没有在行使使命。我们的工作并不是业务本身。我们的使命是支持业务，而不是业务的原因。如果您没有出色的安全性，您就无法开展这项业务，但我们只是业务的一个方面。
 
Eric (18:44)：
对我们来说最重要的是我们获得的高管支持。显然，安全性非常重要，而且是自上而下的。我们不会说，“我们是安全团队，你必须听我们的。拜托，请注意……” 我没有那个问题。从首席执行官自上而下确定基调。每个人都知道安全性很重要。
 
Clarke (20:04)：
感谢您的回答。那么，在衡量安全程序时，特别是针对在 AWS 中编写代码的开发人员和其他人，您使用哪些关键指标来衡量整个 AWS 开发社区中安全程序的有效性？
 
Eric (20:57)：
我们会在两个方面应用指标。
 
Eric (21:43)：
您不需要测量关闭工单的时间。这个时间本身很好测量。我们要衡量的是我们的响应能力。我们在首次接触时制定了 SLA。例如，如果您向 AWS-security 发送电子邮件，我们已公开声明您将在 24 小时内收到人工回复。我们会测量时间。实际上，我每周都会查看图表，其中会显示“这是我们回复发件人所花费的时间。” 响应能力至关重要。首先，如果您不做出响应，就会失去人们的信任。其次，如果您迅速响应，往往意味着其他好事即将发生。
 
Eric (22:25)：
在工单时效性方面，思路也差不多。
…
每项工作都是一个工单。我们在工单系统中内置了大量自动化功能，以确保如果工单过时，我们会测量服务团队之间的通信间隔时间和安全团队之间的通信间隔时间，以便了解工单何时失效，以及我们向服务团队通信受阻或服务团队向我们通信受阻的时间，并且可以非常快速地显示需要立即关注的工单。但这也为我们提供了数据以便自省和回顾，并找出我们的哪些流程不起作用、我们需要在哪些方面改变人员配置，以及我们需要在哪些方面投资更好的工具。我们衡量了安全性的相关流程，并且发现这实际上推动了正确的安全结果。
 
Eric (23:20)：
我们积极衡量的另一件事物，目的不在于把它做对。我们在应用程序安全方面花费了大量时间，力求设计一个好的服务，但亚马逊绝不会在发布任何产品后置之不理。我们会不断添加功能、不断响应客户反馈，并根据这些反馈迅速调整我们的服务。因此，我们的目标不是安全发布，而是在服务的整个生命周期内保持安全，这意味着您在初始应用程序安全审查期间所做的事情很快就会过时并失去其价值。应用程序安全流程的一部分是确定哪些是不变的，我们总是希望哪些关于服务的陈述是真实的，然后弄清楚我们将如何在代码中验证那些变量。
 
Eric (24:10)：
所以，如果服务应该始终拒绝以这种方式格式化的请求，那么应该有一个 Canary 机制在生产中使用该特别格式化的请求调用该服务，以确保它被拒绝。然后，我们会衡量我们的 Canary 机制。它们覆盖了多大的服务面？ 它们多久运行一次？ 它们的失败频率如何？ 它们多久得到一次异常结果？ 我们会衡量这些流程，验证我们的安全立场。这不是衡量交付的安全性。这很难衡量。这是衡量我们已经建立的安全标准的回归情况。这非常重要，因为总会有另一个安全问题。我们的团队具有创新精神，他们不断推出新的、令人兴奋的服务，而这些服务是我们以前从未获得过的。这是每天激励我工作的另一个因素。
 
Clarke (26:00)：
太棒了。这是一个相关的问题，但是从客户的角度提出的，我们有一些非常非常高级的客户，他们通过 CICD 管道在生产中实施基础设施即代码。另一方面，我们有的客户只是在控制台中进行指向单击活动。根据我的经验，我们的大多数客户都处于中间状态，试图实现基础设施即代码“天堂”。 您会给客户领导层什么建议，真正鼓励他们更多地关注工程而不是运行基础设施的操作指向单击方面？
 
Eric (26:42)：
我没有构建过什么华而不实的东西。我构建了令我无比自豪的东西，在市场上表现出色的东西，无论是 AWS 服务的公共市场还是将服务团队和其他亚马逊人作为客户的内部市场。但它们都是围绕一个想法开始的系统，我们构建了我们认为能够取悦客户的最小的东西，然后我们尽可能快地迭代它。随着时间的推移，它们不断发展。正是这种迭代让您获得了出色的工具。与它们亲近的人认为它们是科学怪人设计的怪物。它就是那块垃圾，就像打包的电线和胶带一样，看起来像是 MacGyver 制造的。但实际上，它们是很棒的工具。它们非常有效。因为它们是针对正在做的工作逐步构建的，所以它们实际上可以做到它们需要做的工作。
 
Eric (27:42)：
当有人进来时，无论是他们加入团队还是我们与客户讨论我们内部的行事方式，他们都会看到我们拥有的一系列工具，我们构建的所有这些机制，数量十分庞大。看起来我无法复制它。第一，您不需要复制它。这是为了处理我们特定的安全问题。但是第二，我们确实没有构建这些东西，我们随着时间的推移不断发展它们，而且它们都是从小规模开始的。这是一种渐进的方法。当我们单纯讨论指标问题时，我谈到了不需要回归，不需要两次解决相同的问题。每天变好一点点。每天逐步提高安全标准，就能实现指数级的增长。
 
Clarke (29:34)：
对于看到该谈话的客户来说，这个想法本质上是从工程设计工作开始，随着时间的推移，让它们变得越来越好，而不是我需要一下子改变我的方法。
 
Eric (29:48)：
完全正确。这种渐进的心态总是会带来回报。而且还必须要有不会杞人忧天的安全专家。我们每天都被风险所包围。过马路有风险，开车有风险，把笔记本电脑接入网络也有风险。我们必须乐于承担适当的风险。安全是一门艺术，我希望它更像是一门科学，但我认为它是一门艺术，管理这些风险，了解哪些风险领域可以接受，哪些风险可以减轻，哪些风险完全不可接受。作为一名安全专家，无论在任何岗位，在任何不安全的地方，您都必须能够介绍这种风险的严重程度。
 
Eric (30:38)：
在安全组织中，当谈到安全时，我们一直使用的一个短语是冷静和精确。如果您说，“这是有史以来最严重的安全漏洞，我们无法修复它”，您就会极大地失去可信度。您已经关闭了所有讨论领域。我们不再在前进的道路上进行协商。您切断了它。相反，如果您说：“这是一个非常令人担忧的问题。我担心这一特定的影响”，则可能会有三条前进道路。我喜欢第一条，它的费用更高，但也具有好处。让我们谈谈我们这时需要做什么。它冷静、精确，开启了对话。我将向您提供我的专业见解，这样我们就可以就业务进行对话。构建此安全工具的工程师需要牢记这一点。他们需要思考，“我怎样才能让业务变得更好？”而不是，“哦，天哪，全都火烧眉毛了，太可怕了。”