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