云安全先驱 Rich Mogull 加入 FireMon 团队

DisruptOps 加入 FireMon 已有七个月，其使命是通过改进安全运营来提升安全成效。我很高兴地宣布，DisruptOps 联合创始人 Rich Mogull 将以云安全高级副总裁的身份加入我们，继续开拓云安全运营的未来。Rich 拥有置身于未来安全运营中的经验，并亲眼见证了源自 SRE 与 DevOps 运动的策略与战术如何在全新的分布式安全运营模式下同时带来有效性与效率，这将是 FireMon 客户未来取得成功成效的关键。在他正式上任前，我与 Rich 进行了一次对话。

<Matt Eberhart，FireMon 首席运营官> Rich，欢迎您以云安全高级副总裁的身份加入 FireMon 团队。您长期担任 DisruptOps 的顾问，最初还是其创始人，能否谈谈您决定全职加入的原因？

<Rich Mogull，FireMon 云安全高级副总裁> 我可以说是因为怕错过吗？说到底，是因为我看到了摆在我们面前的机会，并且希望比担任顾问时更深入地参与其中。我们花了数年时间，把我在 Black Hat 临时拼凑出来的一个演示，打造成一款功能完备的云安全运营产品。FireMon 的收购并不是终点，反而为这把火添了更多燃料。

我看到了改进安全运营方式（尤其是在云中）的巨大机会，而这并不是我愿意袖手旁观的事。担任这一职务不仅让我能够继续践行我们对 DisruptOps 的愿景，还让我们得以借助 FireMon 的其他产品线，在更广阔的舞台上施展。例如，DisruptOps 在纯云场景中表现最佳，而现在我们可以将其延伸至混合环境和零信任环境。此外，我们还获得了强大的云网络安全能力，而云网络安全即便从零开始也是最难管理的领域之一。

FireMon 正在酝酿一些非常出色的成果，全职加入让我能够以顾问身份无法企及的方式影响我们所构建的解决方案。这也让我能够为社区带来的不只是言语和幻灯片。

<Matt> 在您的安全职业生涯中，您扮演过许多角色，也一向乐于分享自己的观点。您对我进入云安全领域的历程影响很大。哪些趋势让您感到振奋？这些趋势又如何体现在您在 FireMon 的新职务中？

<Rich> 十多年前我刚踏入云安全领域时，属于一小群被告知“没有哪家真正的企业会上云”的人。如今，所有人和所有业务都在向云迁移，而且在很多情况下，迁移速度快于企业 IT 和安全团队所能支撑的程度。

最令人振奋的趋势是，各组织正在采用云原生的做事方式。诚然，现在仍处于早期阶段，仍有不少地方沿用旧有的安全实践，但已有更多人理解云的不同之处以及它需要自己的一套方法。我还要把 DevOps 也加进来，让局面再稍微“混乱”一点。

我们正处于安全运营思路与执行方式发生代际转变的早期阶段。一切都在变得更加分布式、事件驱动和自动化。

除了云的使用率和重要性整体上升之外，当前还有几个我觉得非常有意思、也很有趣的趋势。过去一两年，我在云上的事件响应方面投入了大量时间，这也影响了我反馈给产品团队的建议。得益于云中 API 的无处不在，有些在本地环境中难以实现的事情，在云中却可以做得非常出色。

身份与访问管理也正在迅速升温，这得益于即时（just-in-time）能力与基于属性的访问控制的融合。20 年前，我在一份早已尘封的 Gartner 研究报告中提出了“动态授权”的概念，而如今我们已具备大规模实现基于风险的身份验证与授权的能力。这是一项颠覆性的变革，而且来得正是时候——我们正把所有管理界面放到互联网上，并允许管理员通过不受信任网络上的个人设备进行访问。

最后一个趋势对我们来说并不新鲜，但才刚刚开始真正获得关注。在 DisruptOps，我们很早就针对如今人们所称的 ClickOps 构建产品。为了显得更“讨嫌”一些，我把它叫作 ClickSec。我非常喜欢这样的理念：把安全通知连同一键修复方案直接推送到应用或环境负责人手中。让我们打破一些壁垒吧。

<Matt> 您长期以来对担任急救第一响应人的热情一直让我着迷。这如何塑造了您对安全的看法以及您观察世界的方式？

<Rich> 呵……在 Twitter 上关注我的人都知道，我对自己的应急救援工作总是滔滔不绝。我 16 岁做救生员，19 岁成为急救技术员，22 岁成为急救医护人员。如今我主要专注于灾害响应，但我也做过消防、滑雪巡逻、山地救援以及其他各种零散工作。那些是我人生中最具塑造性的岁月，那份工作真正奠定了我的为人以及我看待事物的方式。

从事急救工作会赋予你一种特定的决策方式。我们受过训练，要在极短的时间内评估极度混乱的局面，而且往往是在条件简陋甚至充满敌意的环境中。急救医护人员是回答“危重还是不危重”的高手，他们在缺乏其他临床医生所拥有的诊断工具的情况下，仍能制定行动方案。在安全领域，尤其是在事件响应中，我们常常处于同样的境地：在无法获得完整信息的情况下做出关键决策，并且需要随着情况的变化不断重新审视自己的决策。

退一步看，还有关于风险和人的更宏观的视角。人的行为决定一切，我们不能假设可以用某种技术手段去弥补系统性或行为性的问题。我们的技术需要顺应人的行为，而不是假定行为会改变。这就像一位心脏病发作却不愿去医院的病人——我是花一个小时跟他争辩呢？还是直接告诉他的配偶，天黑前他们可能需要一家靠谱殡仪馆的电话？这两种做法中，有一种在把人送上救护车方面要有效得多。

<Matt> 这个问题的答案我心里有数，也庆幸我离您够远、您揍不到我，不过……《星际迷航》还是《星球大战》？为什么？

<Rich> 哎呀，两个我都喜欢，但新作品都有点良莠不齐。《发现号》和《皮卡德》让我有些失望。说真的，现在《奥维尔号》把“星际迷航”拍得比“星际迷航”本身还地道。最近的《星球大战》电影也不全然如我所愿，但大多数剧集拍得非常出色。我尤其期待《阿索卡》，因为除去最初的几部电影，《义军崛起》大概是我最喜欢的星球大战作品。
但如果必须选一个，那就是《星球大战》。它的画卷更宏大，玩转的是奇幻与原型；而《星际迷航》更像是一篇关于人性与乐观主义的论述。我想，上了年纪的我大概是变得太愤世嫉俗了，无法把《星际迷航》排在前面。

<Matt> FireMon 和 DisruptOps 都关注安全卫生。我听您说过——在安全领域，关键往往不只是知道该做什么，而是能否在正确的时间做正确的事。未来的安全卫生应该是什么样子？

<Rich> 您希望这篇文章写多长？好吧……我尽量说得简短（一些）。

正如我前面提到的，在安全发展的大部分历史中，我们一直依赖各自为政的壁垒。其实不只是安全，我们几乎所有 IT 运营都是这么处理的。这些壁垒并非随意形成；它们是我们当时构建和管理技术的方式所带来的自然结果。在数据中心里，总得有人负责网络，另有人负责服务器，还有人负责安全。物理架构天然形成了收口点，因为我们不可能让所有人随意跑来跑去自己插线。IT 由稀缺性所定义。

云打破了其中的许多格局。任何人只要有一张额度足够的信用卡，就能通过几次 API 调用构建成千上万的定制网络和服务器。收口点消失了，人人都是管理员，而现在我们都在追赶，试图找出仍能管理风险的最佳方式。

安全卫生的未来，在于重塑运营方式，以适应 IT 运营本身日益分布式的特性。在我看来，理想状态是由安全团队定义管理风险的“规则”，这些规则随后被编写成策略、基础设施即代码模板，以及用于检测性、预防性和响应性控制的其他工具。然后由各个团队管理自己的日常问题，安全团队则负责统筹关注，并在发生重大事件时介入处理。

我们利用自动化近乎实时地识别问题和偏差，然后在可能的情况下，把问题连同推荐的修复方案（或自动化按钮）直接推送给拥有该环境的团队。与此同时，该问题也会出现在安全团队的未决问题清单中，以供跟踪和验证。预防性护栏固然出色，但无法覆盖所有情况，因此我们需要恰当的控制组合，在管理风险的同时减少摩擦、支撑高速交付。

安全卫生是多种要素的组合：安全基线模板，配置、威胁与事件监控，预防性护栏（在可行时），以及发现问题并把问题和修复方案分派给能够当场采取行动的人。一切都更加协同、更加实时。目前，这在很大程度上表现为以 IaC/DevOps 作为良好的起点，并以 ClickOps 来维持成果，但我们确实还只处于最初阶段。

<Matt> 感谢您分享这些见解，Rich。欢迎加入 FireMon！目前 RSA 2022 将以线下形式举办。我和 Rich 都会参加，期待在现场与您相见。