最后一件事，我一直是爱德华·戴明的极客，所以我最近开了一个播客，有点像我的激情叫做深刻。如果你感兴趣，或者你想谈谈戴明，或者你知道，当戴明你想讨论的事情，就联系我，很高兴听到你的消息。这是万亿美元的API。所以six star实际上是红帽和谷歌的合作成果，但它有可能扩展电子信任的整个概念，并以我所说的，你知道我所说的东西交易信任的方式分发。不管怎样，我知道我很快地讲了一些，但我的目的是对我所说的安全问题做一个概览。谢谢你！我是约翰·威利斯。我可以在J.威利斯红帽公司或自行车lubuntu找到。或者你可以上我们的播客。
所以当我开始考虑今年的演讲时，我做的一件事就是问这个问题。
当我开始写主题演讲的时候，我经常这样做。这是2021年的安全问题。
我问自己这个问题，如果DevOps从未存在过，DevSecOps会是什么样子?所以，如果我们考虑DevSecOps，你知道，眼镜肯定已经掉下来了，对吧?换句话说，我们在我们的管道上增加了很多安全性，我们建立了一些非常棒的DevSecOps参考架构，许多不存在的自动化被捆绑在我们的DevOps上，或者管道等等。但在某些方面，就像左边的图片，你知道，我们有没有试着把一个方形的钉子塞进一个圆洞里?很多好的事情都熬过来了。但我想问的问题是，如果DevOps从未存在过呢?
DevSecOps是什么样的?换句话说，我们是否被迫进入了一个围绕DevOps的模型或偏见?再次强调，我不是在批评我们所做的出色工作，而是在质疑，如果我们刚开始使用DevSecOps的概念，而不是试图将安全性与DevOps模式捆绑在一起，我们的做法会有什么不同?举几个例子，我只举一个，就是三道防线的概念。很多时候，当我走进一个大商店，我和人们交谈，他们给我看他们的DevSecOps参考架构。我说，是的，那真的很酷。
太棒了。他们做了所有你需要做的好事。
他们做的是，你知道，他们基本上在运输方面保持良好的卫生，小批量的，所有的那种好的DevOps原则。
但他们也在做SASS或DAST，所有这些都在进行中。你可能会在一个良好的DevSecOps参考体系结构中找到所有的东西。但同时，我们将讨论如何遵循三道防线模型。有不同的版本，其中一个是由内部审计师协会提出的。这就是设计鼓励组织建造这些墙的地方，对吧?
第三条线是内部审计，第二条线是风险所有者，第一条线是实际控制人员负责实施控制。这个设计基本上是基于筒仓，防火墙，如果你愿意，你知道，某种防火墙到不同的组或筒仓，换句话说，第二组会抓住第一组，第三组会抓住第二组。这是一种反模式，依我看，那是不合时宜的事。你知道，如果我们想想，DevOps最初的意图，事实上，最初的人物，这是Andrew clay Schafer，我在红帽公司为他工作。他是我多年的好朋友，DevOps运动的创始人之一。
早在2009年，我们开始讨论最初的速度，O 'Reilly的速度会议，我们讨论了一些想法，甚至更多，John Ospar给出了他著名的10次部署，一天的闪烁。
Andrew在同一天做了一个名为敏捷基础架构的演讲。在他的演讲中，他展示了这个，你知道，这个著名的“困惑之墙”的角色，Dev和Ops有不同的目标，总是有这种墙和不合作。然后，我认为，如果我们回到康威定律或者这句格言，我们会发现一个组织的设计系统反映了他们的沟通结构。如果在开发和运维之间有一堵墙，我们在过去一年的DevOps对话中成功地推倒了这堵墙，但如果你没有，你的组织设计如何交付软件，如何沟通，所有这些事情，就会成为沟通的一面镜子，或者是一个地方的那种墙。所以我想说的是，这三道防线是一个很好的反模式的例子，我们可能应该有DevSecOps，但我们觉得这是一个正常的做法。
但它确实是这两堵混乱的墙，我们在设计上，不允许合作。从某种意义上说，创造了，你知道，一些不能通过的方形钉子，你知道，如果你没有这个特别的某种程度上的授权或组织结构到位，审计之间就会有更好的协作。
我的意思是，这是我们今天发现的一个大问题是如何让服务交付团队中的审计人员参与讨论?如何让风险控制部门与监管控制部门进行对话?我们在大型组织中并没有看到很多积极的活动。还有关于组织行为的拉曼定律。我想，你知道，我们不会把这些都讲一遍，但是我有点…
我喜欢第二条，第二定律，如果你愿意的话，那就是任何改变的倡议都会被简化为超载新术语的发现，基本上意味着与现状相同。换句话说，这是问题的一部分，对吧?
甚至当你开始尝试合作时，当然，如果你有墙，你在内部风险或风险控制所有者和人员服务交付团队之间有这种合作，他们会，即使你把他们放在同一个房间里进行对话，如果他们不自由交流，他们基本上会。基本上，哦，是的，我们这样做，好的，很好。他们会在超载和术语上达成一致，或者走出房间，不是真正的交流，而是某种程度上的同意。所有这些问题都是真实的，但当我们开始思考后云时代、原生世界或后云原生开发的复杂性时，我们发现这些高风险的机会变得更加突出，差距也更大。所以有这三个原则是普遍适用的，无论你是在后云原生世界，我用这个词，这可能是一个可怕的词，后云原生现代化，我的意思是，事情正在发生，你知道，你的微服务，你的云原生开发，你的容器化，你的集群，你的，你知道，甚至你的功能。
不管怎样，你应该考虑如何证明我们是安全的如何证明我们是安全的?我们如何做到这两点，但在后云原生世界，情况变得更糟，对吧?
因为服务网格的复杂性，我们可以继续下去。问题是，如果我们问我们如何证明它是安全的，我们今天在大多数组织中是如何做到的?
Pre或post cloud，我们通常使用服务ServiceNow或ci Records。我们记录了人类的对话，是的，我要做这个，但我准备好了。然后有人问了一个问题，嗯，你知道，如果发生了什么，你知道，在你投入生产之前，我想看看这个。这些都是主观的对话。然后你怎么证明呢?事实是，你真的不知道，对吧?
只不过这是一次审计。也许一年一次，你有三四十天的审计时间，高工作量，低效率。但我想在这里提出的问题是，如果我们以不同的方式做安全，也许证明我们如何安全应该更加客观，或者明确，以及你如何证明它应该是不可变的和即时的，所以为了能够做到这两点，以及需要发生什么不同的安全2021从隐式安全转向基于明确证明的安全，对吧?在这个例子中，不是在ServiceNow记录中隐含的，而是对自动化显式的。或者，更具体地说，让我们改变我们做事的主观本质，再一次变成客观的，可验证的，就像人类一样，让我们继续在主观事物上制作电子的，也许是数字的签名，我们可以在没有任何人为干预的情况下展示，并且是可验证的我们会展示一些例子。所以我所做的就是说，好吧，有这样一个概念，我想说的是所谓现代治理，又何谓转型?如果我们看看后云原生世界，对吧?
如果我们看一下安全，我们讨论DevSecOps, DevSecOps对话中一直困扰我的一件事是，一旦你开始描述，你知道，我们从DevOps继承的文化和行为模式，对吧?
非常好的东西。但是突然之间，现在你看看所有这些安全的事情，它是相当广泛的横向传播。所以，你知道，我总是谈论DevSecOps，有人会来问我，约翰，这个怎么样，那个怎么样?我觉得很难用一个词来形容大我们有一种安全感。所以当我在这篇关于云原生世界的文章中开始思考这种现代的东西时，这篇文章中真正重要的事情之一是云原生世界，对吧?对我来说，它可以归结为三件事，我可以说，这是现代治理，这是我们需要从主观到客观和可验证的思考，好吧，有很多东西。所以风险是其中之一，防御和信任。所以如果我们看风险，我们从主观改变管理转向电子，你知道吗，数字签名证明和控制在管道中，自动化，没有人为干预然后，我们进入可验证性，这可能是像连续验证或混沌，混沌工程师，或安全，混沌工程。所以我们不断地验证我们在交付和认证过程中设置的东西，对吧?您知道，也许这个端口永远不应该作为这种配置定义的一部分打开。我们来测试一下。或者这个漏洞永远不应该出现在生产环境中的容器映像中。好吧，让我们启动一个容器映像，看看这个漏洞会发生什么。
在防御方面，我们从主观检测和反应开始对于智能和数据湖，人们不断地获取所有的信息，你知道，创建某种元数据，使你的信息规范化，对来自多个云，多个通道，任何地方的信息进行装饰非常紧张。我们接下来要讲的是香农·利兹，她是我的一位良师益友，她已经讲过了。
她称之为对手分析，这是可验证的，也就是你不断地使用自动化从外到内攻击环境。最后，在信托中，在现代治理中，我们从外围基础转向零信任架构，对吧?
几乎每个人都知道这个备忘录，但甚至没有信任架构还不够好，因为，你知道，如果你看看我们遇到的很多重大漏洞，它们通常是账户接管或服务器端请求伪造。所以即使在零信任的环境中，如果你可以，模仿或伪造你的身份，特别是在云环境中，那里有很多共享的环境授权，比如元数据服务器，一旦你妥协了，所以我们从可验证转向更多的分布式信任模型，在那里我们有这些信任圈和集群。我会稍微讲一下这个。因此，如果我们以不同的方式看待风险，你知道，我们正在努力做的是减少审计工作量，提高审计效率。而且，你知道，我们正在使用自动化的客观的，不可变的证据，对吧，谈论数字签名的证据，你知道，我们正在使用持续的审计和验证，有点像安全混乱工程。
早在2019年，我就向一群行业领导者做了演讲，我们创建了DevOps，自动化参考架构，在那里我们展示了如何创建这些不同的阶段，创建门控和认证。
这是数字签名的证据。多年来，我们在最初的指南中增加了，我们有75个证明，这将是你在管道中的证据点。但正如你所看到的，我们已经扩展了这一点，例如，你可以看到像单元测试覆盖率这样的东西，也许是百分比变化大小，圈复杂度，拉取请求分支策略，干净的依赖关系。然后，你知道，进入构建阶段，你知道，所有的东西都将在构建阶段，像SAS扫描，像JFrog x射线。然后是包阶段，当然，Artifactory是一个很好的例子，我们可以做工件版本，包度量。你知道，再一次，用JFrog x射线之类的东西进行容器扫描。然后进入预舱，你知道，一直这样下去。
的一件事,我们发现,在我们建立的参考体系结构,这种分期,和能力的证明的…酬劳不同的控制点和证据,实际上有意义开始思考,可能是由某种类型的DSL,你知道,一种风险是代码或政策DSL的意图可能是合作,合作,你知道,类似的第三道防线,再一次,打破这些墙，第二行和第一行，所有这些都协作创建了一个YAML文件。你可能会笑，但现在确实有几家银行在做这件事，他们的合作是一种人工制品。你知道，就像拉曼定律一样，如果协议是你必须创建一个DSL工件而不是对一些进入变更记录的冗词达成协议，那么就不太可能产生过多的术语。
就像我说的，我们从2019年开始，我们写了这个参考架构，我们现在实际上正在写第二个版本，应该会在今年夏天晚些时候发布。
这很有趣。第一个版本只是一个死记硬背、枯燥乏味的参考架构。但这一次，我们从凤凰项目中偷了一页我们实际上创建了一个公司叫做无限投资我们讨论他们是如何通过审计的。这很有趣。
我想提的另一件事是今年早些时候我有这个机会，被邀请给太阳风公司的一些高管做一个报告。
我们都听说过太阳风公司的漏洞。我的一个朋友问我，他知道我对自动化管理的热情我们正在研究。以下工作。所以我做了一个演讲，我能做的就是我出去看了一些非常优秀的，你知道的，对实际杀伤链的解释实际上渗透到了太阳风公司，而不是其他使用太阳风公司软件的人。所以CrowdStrike和mitre实际上可能有两篇最好的文章我想做的一件事是展示，你知道，这不是一个完美的例子，而是展示了很多事情在这里发生了几年，实际上可以通过这种方式来强调他们谈论安全的方式不同，特别是自动化治理。这是迁徙纸。CrowdStrike非常具体，那篇博客文章。
这是一本关于mitre在做什么以及整个过程的好书。所以两者都是很好的组合。所以我所做的是，我进入并采取了在mitre攻击策略中描述的东西，只是用一个自动化的治理结构来玩，你知道，再一次，我们会把所有这些都看一遍你可以阅读这些，幻灯片将是可用的，但是像，你知道，一个真正让我脱颖而出的是代码签名。
CrowdStrike的一个特点是经常出现散列不匹配。
如果你知道漏洞是如何发生的，基本上，他们可以坐在那里，等待并破坏MS构建，这样他们就可以将自己的代码添加到交付中。这些都是代码不匹配的证据。
签名不匹配或散列不匹配，可以用彩色散列码签名证明或门捕获。
也有日志伪装的例子，所以一个不可变的日志结构可以被使用，图像扫描，有各种各样的事情，这些可能是，你知道，非常高的红旗，或者开发中的门，或者至少，你知道，从持续遵守或自动治理结构的即时验证。所以，你知道，我们谈论某种现代风险解决方案，绝对是自动化治理，在红帽，我一直在研究一些叫做Plagos的工具，类似于软件工厂，当然我有JFrog产品套件。hth华体会最新官方网站同样，在最初的论文中，我们所做的一件事，我们关注的是
Grafeas的认证存储库存储，但有一些真正优秀的开发人员在基于Merkle树的six store中。
当然，Red Hat在合规操作、高级集群管理方面有一些有趣的工具，我是它的忠实粉丝。这就是为什么在过去的四五年里，我几乎每年都在SwampUP演讲。
JFrog人工制品，x射线，所有的工具，然后我们讨论持续验证。同样，如果你还没有看过这个软件构建的材料，这些是一些有趣的行业正在发生的事情。
这是一个很吸引人的话题，我打算写一篇博客文章来讲述正在发生的事情以及这里的转变，我认为，这是一个非常重要的部分。如果我们谈论防御，我之前提到的三点中的第二点，风险，防御和信任，如果我们从不同的角度来看待防御。所以在国防方面，基本上我们要做的是减少国防工作量。同样的思想，减少辛劳，增加功效。
开始寻找一种更统一的方法来模拟和模拟，所有这些信息都来自四面八方，但肯定是多云传递，然后开始考虑创建一个通用元来创建智能网络数据湖，在欺骗技术上更先进。我讲了很多关于Shannon Leach的研究，对手分析，一个非常有趣的话题。
这是我和一群人一起完成的另一份工作报告。
我们专注于云，自动化云治理。这就像
早前的一篇论文，是知识共享的成果，可用。一些参与最初研究的组织在第二篇论文写到一半的时候，比如联邦快递，高盛，cygnar等等。所以很多大型组织。基本上，再一次，尝试在来自所有这些不同云提供商的所有数据之间创建这种共性，以便为我们的GRC目的聚合。我们最终称之为云安全通知框架。
Onug是赞助组织，他们五月刚在这里开了一个大型会议，你可以找到很多关于我们讨论的信息。但基本上创造这个的想法
我们可以从不同的云提供商处获取数据，但真正重要的是，允许聚合共同的问题，比如来自AWS的一个事件或来自Google或Azure的另一个事件可能具有相同的含义，但结构的上下文将会不同，那么你如何规范它?但更困难的是如何获得共同的元数据，比如部门，账户，资源名，这些都是不同的。所以我们做了一些非常好的工作。让我们慢慢来，你知道，解决方案是这些智能，网络数据湖，如果你感兴趣的话，我绝对建议你，Onug…
我们刚刚开了春季会议，我们讨论了云安全通知框架，mitre攻击框架，你知道，很棒的东西，寻找逃逸，开放逃逸，网络范围，另一个有趣的话题。然后对于对手分析，像这样的东西，除了Shannon Leach的工作，真的没有其他产品。hth华体会最新官方网站她在很多会议上都谈到过这个问题。最后在信托方面有所不同，所以第三条腿，我们很快地过一遍，因为这里有很多，这些都应该是他们自己的介绍，我只是给你们一个不同的调查。
我们讨论了零信任架构，基于自动控制的评估，FedRAMP文档中使用的一些东西，有一些
有很棒的工具，我会指出的。
分发秘密管理，当然，保险库是一个很好的工具。但我认为世界会变得比跳马更复杂，对吧?
我们会给你看一些东西。在分布式信任中，一个主要的我想说的关于信任的观点是，我们需要从南北模式转变，你知道，如果你想想，像身份验证和我们是怎么做的，即使在我们有复杂的容器集群，服务网格基础设施的世界里，我们仍然在使用，你知道，在精神上，我们需要南北，我们需要东西方，就像交易安全或信任和安全舱。
非常有趣的东西。
我将向你们展示一些技术。所以对于零信任，NIST 800 207。Spiffy是一个非常有趣的工具，我称之为东西方信任。然后是six store，这是一个由红帽公司开发的工具它最初是基于谷歌的Trillian，它最初是为了证书的透明度，但它实际上有审计功能。而six store是一个简化的工具来提取内部的api，所以six store实际上是红帽和谷歌的合作成果但它有可能将整个信任的概念电子化并以我所说的东西方交易信任的方式进行分发不管怎样，我知道我很快地讲了一些但我的目的是对整个问题有一个概观，我称之为不同的安全问题。
谢谢，我是约翰·威利斯。
可以通过Jwillis@redhat.com找到我或者@botchagalupe。
