防御安全播客第276期
摘要
在第276期防御安全播客中，主持人Jerry Bell和Andrew Kalat讨论了多个安全话题，包括瑞典农场挤奶机器遭勒索软件攻击导致奶牛死亡的事件、IT行业补丁管理的问题，以及微软发布的令人担忧的可蠕虫化IPv6漏洞补丁。节目还涵盖了一项关于AWS凭证在公共场合暴露和利用的深入研究，强调了自动化补丁和建立健壮凭证管理系统的紧迫性。主持人以幽默和深入的技术讨论吸引听众，旨在揭示关键的网络安全挑战。
时间线
- 00:00 介绍和轻松闲聊
- 01:14 挤奶机器人勒索事件
- 04:47 补丁管理挑战
- 05:41 CrowdStrike中断和补丁策略
- 08:24 定期维护和自动化的重要性
- 15:01 技术债务和所有权问题
- 18:57 漏洞管理和利用
- 25:55 漏洞补丁优先级
- 26:14 AWS凭证公开案例研究
- 29:06 凭证利用速度
- 31:05 容器镜像漏洞
- 37:07 教授安全开发实践
- 40:02 微软IPv6安全漏洞
- 43:29 播客总结和社交媒体推广
链接
文字记录
Jerry: 今天是2024年8月15日星期四，这是防御安全播客的第276期。我是Jerry Bell，今晚和我一起的是Andrew Kalat先生。
Andrew: 晚上好，Jerry。再次从你的南方据点出发，我看到了。
Jerry: 再次，也是最后两周的时间，然后我会回来。
Andrew: 好吧，希望下次你回来时，又会有一个飓风要躲避。
Jerry: 天哪，我希望不是。
Andrew: 你好吗，先生？
Jerry: 我很好。这几周很棒，我期待着回家待一会儿，然后再回来。你呢？
Andrew: 我很好，老兄。夏天快结束了，期待即将到来的秋季旅行，只是悠闲地度过。活在梦中。
Jerry: 我们会弥补上周关于风暴的闲聊，直接进入一些故事。但首先提醒一下，我们表达的观点和意见是我们个人的，不代表我们的雇主。
Andrew: 确实。这很重要，因为他们可能会解雇我。你试过。
Jerry: 我会的。所以今晚的第一个故事非常感人。
Andrew: 我对这些人有些不满。
Jerry: 很好。非常感人。这个故事来自安全事务，标题是“罪犯控制了奶牛挤奶机器人，导致奶牛死亡”。现在，我会告诉你标题比实际故事更耸人听闻。当我看到标题时，我想，天哪，有人黑了一个机器人， somehow 杀死了奶牛，但 no，那并不是实际发生的事情。
Andrew: 现在， also，让我们 upfront 说，奶牛的死亡是可怕的，我们不是在轻描淡写。但我们会稍微利用这个故事。
Jerry: 那是真的。
Andrew: 我几乎用完了奶牛的双关语。
Jerry: 谢天谢地。所以，这里发生的是，瑞典的一个农场他们的挤奶机器，我猜是挤奶机器被勒索软件了，农民注意到他无法再管理系统，联系了该系统的支持。他们说，不，你被勒索软件了。实际上，挤奶机器本身似乎很容易恢复运行，但 apparently 在攻击中丢失的是关于奶牛的重要健康信息，包括一些奶牛何时被授精。因此，他们不知道其中一头怀孕的奶牛应该已经分娩，但实际上没有。所以它。结果情况是，奶牛的胎儿不幸在母牛体内死亡，农民直到发现奶牛 lethargic 躺在它的畜栏里才知道，他们叫了兽医。不幸的是，那时已经太晚，无法拯救奶牛。这是一个不幸的情况，勒索软件攻击确实导致了死亡。
Andrew: 是的，我认为为了准确性，我想它是在瑞士。
Jerry: 是瑞士吗？好吧。我知道它以 S W 开头。
Andrew: 那很公平。你很接近。是欧洲。
Jerry: 都在那里。
Andrew: 但是的，我猜在这个理论中，如果他们有一个更好的跟踪日期，当奶牛被授精时，他们会知道奶牛在分娩中处于痛苦，可以更主动地做些什么来拯救奶牛和 potentially 小牛。不幸的是，因为他们没有这些数据，因为它在这个被勒索软件的挤奶机器人机器中，我们最终得到了一头死奶牛和一头死小牛。
Jerry: 所以没有过多 grill 农民。我在想，那个，
Andrew: 哇！
Jerry: 对不起。我在想，他们 clearly 有恢复的能力。他们认为机器操作的重要方面，即挤奶，他们能够相当快地恢复运行。但似乎他们 unaware 这个其他信息是 kind tied 到同一个系统。我不 fully understand。似乎比我在脑海中 envision 的更复杂。但 very clearly 他们没有想过所有 potential harm。一个好的教训，我认为对我们所有人。
Andrew: 我觉得我们 butcher 了这个故事。
Jerry: 今天的下一个故事来自 register.com，标题是“补丁管理似乎仍然糟糕，因为没人想要这份工作”不能停止笑。好吧。
Andrew: 一头奶牛死了！那是悲剧！
Jerry: 我在笑你糟糕的幽默尝试。
Andrew: 我不能在那里 work leather。我试了。我一直在尝试想出一个皮革双关语。
Andrew: 是的，这是一个有趣的问题，我们在这里 struggle with，即我们有多少次通过自动化或快速补丁拯救了自己的屁股而不知道？证明那个负面是非常困难的。所以非常 difficult to。Weigh the pros and cons empirical data showing where automatic patching or rapid patching solved a problem or avoided a problem versus when patching broke something。Cause all we know about is when it breaks, like when a Microsoft patch rolls out and breaks and that sort of thing。And it’s one of those things where it has to be perfect every time is the feeling from a lot of folks。And if it, if every time we have a problem, we break some of that trust。It hurts the credibility of auto patching or, rapidly patching。The other thing that comes to mind is I would love to get more IT folks and technical operations folks and SREs and DevOps folks, with the concept of patching as just part of regular maintenance。That is, just built into their process。A lot of times it feels like a patch is an interrupt driven or toil type work that they have to stop what they’re doing to go work on this。Where, in my mind, at least the way I look at it from a risk manager perspective, unless something’s on fire or is a known RCE or known exploited, certain criteria。I’m good。Hey, take patch on a monthly cadence and just catch everything up on that monthly cadence, whatever it is。I can work within that cadence。If I’ve got something that I think is a higher priority, we can try to interrupt that or drive a different cadence to get that patched or mitigated in some way。But the problem often is that, Okay。Every one of these patches seems to be like a one off action if you’re not doing automatic patching in some way, that is very Cognitively dissonant with what a lot of these teams are doing and I don’t know how to get Across very well that you will always have to patch it was all this will never stop So you have to plan for it。You have to build time for that。You have to build Automation and cycles for that and around it and it’ll be a lot less painful It’s it feels like pushing the rock up the hill on that one。
Jerry: 我的一个观察是 fast patching 的一个障碍是对 downtime 的 reluctance and, or the potential impacts from downtime。And I think that dovetails with what you just said, in part, that concern stems from the way we design our IT systems and our IT environments。If we design them in a way that they’re not patchable without interrupting operations, then my view is we’ve not been successful in designing the environment to meet the business。And that’s something that, that I tried hard to drive and just thinks in some aspects I was successful and others I was not。But I think that is one of the real key things that, that we as a it leader or security leaders really need to be imparting in the teams is that when we’re designing things, it needs to be, Maintainable as a, not as a, like you described it as an interrupt, but as an, in the normal course of business without heroic efforts, it has to be maintainable。You have to be able to patch, you have to be able to take the system down。You can’t say that gosh, this system is so important。Like we can’t, we take it down。We’re going to lose millions of dollars ever。Like we can’t take it down。Not a good, it’s not a good look。You didn’t design it right。
Jerry: And there was like, there was a quote related to what you just said in, at the end of this article, it said I think it mostly comes down to quote, I think it mostly comes down to technical debt。You explained it’s very, it’s a very unsexy thing to work on。Nobody wants to do it and everyone feels like it should be automated, but nobody wants to take responsibility for doing it。You added the net effect is that nothing gets done and people stay in the state of technical debt。Where they’re not able to prioritize it。
Andrew: That’s not a great place to be。
Andrew: Yeah, like in what time frame? In what? I don’t know。I feel like what he’s talking about maybe is They only have the ability to automatically patch up to 85 percent of the deployed software in their environment。
Jerry: That could be, it’s a little ambiguous。
Andrew: It is。And from my perspective, there’s actually a couple different things where we’re talking about here, and we’re not being very specific。We’re talking about I。T。Operations are talking about corporate I。T。Solutions and systems and servers。For an IT house, I work in a software shop, so we’ve got the whole software side of this equation, too, for the code we’re writing and keeping all that stuff up to date, which is a whole other complicated problem that, some of which I think would be inappropriate for me to talk about, but, so there’s, it’s doubly difficult, I think, if you’re a software dev shop to keep all of your components and dependencies and containers and all that stuff up to date。
Jerry: Absolutely。Absolutely。I will also say that A couple of other random thoughts on my part, this, in my view, gets harder or gets more complicated, the larger in larger organizations, because you end up having these kind of siloed functions where responsibility for patching isn’t necessarily clear, whereas in a smaller shop。You may have an IT function who’s responsible end to end for everything, but in large organizations, oftentimes you’ll have a platform engineering team or who’s responsible for, let’s say, operating systems。And then you may have a, that, that team is a service provider for other other parts of the business。And those other parts of the business may not have a full appreciation for what they’re responsible for from an application perspective, and especially in larger companies where, they’re want to reduce head count and cut costs, the, those application type people in my, my experience, as well as the platform team are are ripe targets for reductions。And when that happens。You end up in this kind of a weird spot of having systems and no clear owner on who’s actually responsible。You may even know that you have to patch it, but you may not know whose job it is。
Jerry: So these are pragmatic problems that in my experience。They present themselves as salt is a sand in the gears, right? They make it very difficult to move swiftly。And that’s what in my ex in my experience drives that heroic effort, especially when something important comes down the line, because now you have to pay extra attention because that something is not going to, that there isn’t a well functioning process。And I think that’s。Something as an industry, we need to focus on。Oh, go ahead。
Andrew: I was just gonna say, in my mind, some of the ways you solve this, and these are usually said difficult to do, but proper。I should define that。Maintained asset management, I。T。asset management is key。And in my mind, you’ve got to push your business to make sure that somebody has accountability to every layer of that application。And push your business to say, hey, if we’re not willing to invest in maintaining this, and nobody’s going to take ownership of it, it shouldn’t be in our environment。must be well owned。This is, it’s like when you adopt a dog。Somebody’s got to take care of it。And you can’t just neglect it in the backyard。So we run into stuff all the time where it’s just, Oh, nobody knows what that is。Then get rid of it。attack surface。That’s a single thing out there is something that could be attacked。If it’s about being maintained, that becomes far riskier from an attack surface perspective。So I think that, and I also think about, Hey, tell people before you go buy a piece of software, do you have the cycles to maintain it? Do you have the expertise to maintain it?
Jerry: The business commitment to fund its ongoing operations, right?
Andrew: Exactly。I don’t know。It gets stickier。And now we have this concept of SaaS, where a lot of people are buying software and not even thinking about the backend of it because it’s all just auto magic to them。So they get surprised when it’s,