Podcasts about belak

Our adventurers are delving deeper into the Sunless Citadel in search of the dreaded Gulthias Tree and the twisted druid Belak the Outcast. Can they save the captives in time?

Anna Belak, Director of the Office of Cybersecurity Strategy at Sysdig, joins Corey on Screaming in the Cloud to discuss the newest benchmark for responding to security threats, 5/5/5. Anna describes why it was necessary to set a new benchmark for responding to security threats in a timely manner, and how the Sysdig team did research to determine the best practices for detecting, correlating, and responding to potential attacks. Corey and Anna discuss the importance of focusing on improving your own benchmarks towards a goal, as well as how prevention and threat detection are both essential parts of a solid security program. About AnnaAnna has nearly ten years of experience researching and advising organizations on cloud adoption with a focus on security best practices. As a Gartner Analyst, Anna spent six years helping more than 500 enterprises with vulnerability management, security monitoring, and DevSecOps initiatives. Anna's research and talks have been used to transform organizations' IT strategies and her research agenda helped to shape markets. Anna is the Director of Thought Leadership at Sysdig, using her deep understanding of the security industry to help IT professionals succeed in their cloud-native journey. Anna holds a PhD in Materials Engineering from the University of Michigan, where she developed computational methods to study solar cells and rechargeable batteries.Links Referenced: Sysdig: https://sysdig.com/ Sysdig 5/5/5 Benchmark: https://sysdig.com/555 TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. I am joined again—for another time this year—on this promoted guest episode brought to us by our friends at Sysdig, returning is Anna Belak, who is their director of the Office of Cybersecurity Strategy at Sysdig. Anna, welcome back. It's been a hot second.Anna: Thank you, Corey. It's always fun to join you here.Corey: Last time we were here, we were talking about your report that you folks had come out with, the, “Cybersecurity Threat Landscape for 2022.” And when I saw you were doing another one of these to talk about something, I was briefly terrified. “Oh, wow, please tell me we haven't gone another year and the cybersecurity threat landscape is moving that quickly.” And it sort of is, sort of isn't. You're here today to talk about something different, but it also—to my understanding—distills down to just how quickly that landscape is moving. What have you got for us today?Anna: Exactly. For those of you who remember that episode, one of the key findings in the Threat Report for 2023 was that the average length of an attack in the cloud is ten minutes. To be clear, that is from when you are found by an adversary to when they have caused damage to your system. And that is really fast. Like, we talked about how that relates to on-prem attacks or other sort of averages from other organizations reporting how long it takes to attack people.And so, we went from weeks or days to minutes, potentially seconds. And so, what we've done is we looked at all that data, and then we went and talked to our amazing customers and our many friends at analyst firms and so on, to kind of get a sense for if this is real, like, if everyone is seeing this or if we're just seeing this. Because I'm always like, “Oh, God. Like, is this real? Is it just me?”And as it turns out, everyone's not only—I mean, not necessarily everyone's seeing it, right? Like, there's not really been proof until this year, I would say because there's a few reports that came out this year, but lots of people sort of anticipated this. And so, when we went to our customers, and we asked for their SLAs, for example, they were like, “Oh, yeah, my SLA for a [PCRE 00:02:27] cloud is like 10, 15 minutes.” And I was like, “Oh, okay.” So, what we set out to do is actually set a benchmark, essentially, to see how well are you doing. Like, are you equipped with your cloud security program to respond to the kind of attack that a cloud security attacker is going to—sorry, an anti-cloud security—I guess—attacker is going to perpetrate against you.And so, the benchmark is—drumroll—5/5/5. You have five seconds to detect a signal that is relevant to potentially some attack in the cloud—hopefully, more than one such signal—you have five minutes to correlate all such relevant signals to each other so that you have a high fidelity detection of this activity, and then you have five more minutes to initiate an incident response process to hopefully shut this down, or at least interrupt the kill chain before your environments experience any substantial damage.Corey: To be clear, that is from a T0, a starting point, the stopwatch begins, the clock starts when the event happens, not when an event shows up in your logs, not once someone declares an incident. From J. Random Hackerman, effectively, we're pressing the button and getting the response from your API.Anna: That's right because the attackers don't really care how long it takes you to ship logs to wherever you're mailing them to. And that's why it is such a short timeframe because we're talking about, they got in, you saw something hopefully—and it may take time, right? Like, some of the—which we'll describe a little later, some of the activities that they perform in the early stages of the attack are not necessarily detectable as malicious right away, which is why your correlation has to occur, kind of, in real time. Like, things happen, and you're immediately adding them, sort of like, to increase the risk of this detection, right, to say, “Hey, this is actually something,” as opposed to, you know, three weeks later, I'm parsing some logs and being like, “Oh, wow. Well, that's not good.” [laugh].Corey: The number five seemed familiar to me in this context, so I did a quick check, and sure enough, allow me to quote from chapter and verse from the CloudTrail documentation over an AWS-land. “CloudTrail typically delivers logs within an average of about five minutes of an API call. This time is not guaranteed.” So effectively, if you're waiting for anything that's CloudTrail-driven to tell you that you have a problem, it is almost certainly too late by the time that pops up, no matter what that notification vector is.Anna: That is, unfortunately or fortunately, true. I mean, it's kind of a fact of life. I guess there is a little bit of a veiled [unintelligible 00:04:43] at our cloud provider friends because, really, they have to do better ultimately. But the flip side to that argument is CloudTrail—or your cloud log source of choice—cannot be your only source of data for detecting security events, right? So, if you are operating purely on the basis of, “Hey, I have information in CloudTrail; that is my security information,” you are going to have a bad time, not just because it's not fast enough, but also because there's not enough data in there, right? Which is why part of the first, kind of, benchmark component is that you must have multiple data sources for the signals, and they—ideally—all will be delivered to you within five seconds of an event occurring or a signal being generated.Corey: And give me some more information on that because I have my own alerter, specifically, it's a ClickOps detector. Whenever someone in one of my accounts does something in the console, that has a write aspect to it rather than just a read component—which again, look at what you want in the console, that's fine—if you're changing things that is not being managed by code, I want to know that it's happening. It's not necessarily bad, but I want to at least have visibility into it. And that spits out the principal, the IP address it emits from, and the rest. I haven't had a whole lot where I need to correlate those between different areas. Talk to me more about the triage step.Anna: Yeah, so I believe that the correlation step is the hardest, actually.Corey: Correlation step. My apologies.Anna: Triage is fine. It's [crosstalk 00:06:06]—Corey: Triage, correlations, the words we use matter on these things.Anna: Dude, we argued about the words on this for so long, you could even imagine. Yeah, triage, correlation, detection, you name it, we are looking at multiple pieces of data, we're going to connect them to each other meaningfully, and that is going to provide us with some insight about the fact that a bad thing is happening, and we should respond to it. Perhaps automatically respond to it, but we'll get to that. So, a correlation, okay. The first thing is, like I said, you must have more than one data source because otherwise, I mean, you could correlate information from one data source; you actually should do that, but you are going to get richer information if you can correlate multiple data sources, and if you can access, for example, like through an API, some sort of enrichment for that information.Like, I'll give you an example. For SCARLETEEL, which is an attack we describe in the thread report, and we actually described before, this is—we're, like—on SCARLETEEL, I think, version three now because there's so much—this particular certain actor is very active [laugh].Corey: And they have a better versioning scheme than most companies I've spoken to, but that's neither here nor there.Anna: [laugh]. Right? So, one of the interesting things about SCARLETEEL is you could eventually detect that it had happened if you only had access to CloudTrail, but you wouldn't have the full picture ever. In our case, because we are a company that relies heavily on system calls and machine learning detections, we [are able to 00:07:19] connect the system call events to the CloudTrail events, and between those two data sources, we're able to figure out that there's something more profound going on than just what you see in the logs. And I'll actually tell you, which, for example, things are being detected.So, in SCARLETEEL, one thing that happens is there's a crypto miner. And a crypto miner is one of these events where you're, like, “Oh, this is obviously malicious,” because as we wrote, I think, two years ago, it costs $53 to mine $1 of Bitcoin in AWS, so it is very stupid for you to be mining Bitcoin in AWS, unless somebody else is—Corey: In your own accounts.Anna: —paying the cloud bill. Yeah, yeah [laugh] in someone else's account, absolutely. Yeah. So, if you are a sysadmin or a security engineer, and you find a crypto miner, you're like, “Obviously, just shut that down.” Great. What often happens is people see them, and they think, “Oh, this is a commodity attack,” like, people are just throwing crypto miners whatever, I shut it down, and I'm done.But in the case of this attack, it was actually a red herring. So, they deployed the miner to see if they could. They could, then they determined—presumably; this is me speculating—that, oh, these people don't have very good security because they let random idiots run crypto miners in their account in AWS, so they probed further. And when they probed further, what they did was some reconnaissance. So, they type in commands, listing, you know, like, list accounts or whatever. They try to list all the things they can list that are available in this account, and then they reach out to an EC2 metadata service to kind of like, see what they can do, right?And so, each of these events, like, each of the things that they do, like, reaching out to a EC2 metadata service, assuming a role, doing a recon, even lateral movement is, like, by itself, not necessarily a scary, big red flag malicious thing because there are lots of, sort of, legitimate reasons for someone to perform those actions, right? Like, reconnaissance, for one example, is you're, like, looking around the environment to see what's up, right? So, you're doing things, like, listing things, [unintelligible 00:09:03] things, whatever. But a lot of the graphical interfaces of security tools also perform those actions to show you what's, you know, there, so it looks like reconnaissance when your tool is just, like, listing all the stuff that's available to you to show it to you in the interface, right? So anyway, the point is, when you see them independently, these events are not scary. They're like, “Oh, this is useful information.”When you see them in rapid succession, right, or when you see them alongside a crypto miner, then your tooling and/or your process and/or your human being who's looking at this should be like, “Oh, wait a minute. Like, just the enumeration of things is not a big deal. The enumeration of things after I saw a miner, and you try and talk to the metadata service, suddenly I'm concerned.” And so, the point is, how can you connect those dots as quickly as possible and as automatically as possible, so a human being doesn't have to look at, like, every single event because there's an infinite number of them.Corey: I guess the challenge I've got is that in some cases, you're never going to be able to catch up with this. Because if it's an AWS call to one of the APIs that they manage for you, they explicitly state there's no guarantee of getting information on this until the show's all over, more or less. So, how is there… like, how is there hope?Anna: [laugh]. I mean, there's always a forensic analysis, I guess [laugh] for all the things that you've failed to respond to.Corey: Basically we're doing an after-action thing because humans aren't going to react that fast. We're just assuming it happened; we should know about it as soon as possible. On some level, just because something is too late doesn't necessarily mean there's not value added to it. But just trying to turn this into something other than a, “Yeah, they can move faster than you, and you will always lose. The end. Have a nice night.” Like, that tends not to be the best narrative vehicle for these things. You know, if you're trying to inspire people to change.Anna: Yeah, yeah, yeah, I mean, I think one clear point of hope here is that sometimes you can be fast enough, right? And a lot of this—I mean, first of all, you're probably not going to—sorry, cloud providers—you don't go into just the cloud provider defaults for that level of performance, you are going with some sort of third-party tool. On the, I guess, bright side, that tool can be open-source, like, there's a lot of open-source tooling available now that is fast and free. For example, is our favorite, of course, Falco, which is looking at system calls on endpoints, and containers, and can detect things within seconds of them occurring and let you know immediately. There is other EBPF-based instrumentation that you can use out there from various vendors and/or open-source providers, and there's of course, network telemetry.So, if you're into the world of service mesh, there is data you can get off the network, also very fast. So, the bad news or the flip side to that is you have to be able to manage all that information, right? So, that means—again, like I said, you're not expecting a SOC analyst to look at thousands of system calls and thousands of, you know, network packets or flow logs or whatever you're looking at, and just magically know that these things go together. You are expecting to build, or have built for you by a vendor or the open-source community, some sort of dissection content that is taking this into account and then is able to deliver that alert at the speed of 5/5/5.Corey: When you see the larger picture stories playing out, as far as what customers are seeing, what the actual impact is, what gave rise to the five-minute number around this? Just because that tends to feel like it's a… it is both too long and also too short on some level. I'm just wondering how you wound up at—what is this based on?Anna: Man, we went through so many numbers. So, we [laugh] started with larger numbers, and then we went to smaller numbers, then we went back to medium numbers. We align ourselves with the timeframes we're seeing for people. Like I said, a lot of folks have an SLA of responding to a P0 within 10 or 15 minutes because their point basically—and there's a little bit of bias here into our customer base because our customer base is, A, fairly advanced in terms of cloud adoption and in terms of security maturity, and also, they're heavily in let's say, financial industries and other industries that tend to be early adopters of new technology. So, if you are kind of a laggard, like, you probably aren't that close to meeting this benchmark as you are if you're saying financial, right? So, we asked them how they operate, and they basically pointed out to us that, like, knowing 15 minutes later is too late because I've already lost, like, some number of millions of dollars if my environment is compromised for 15 minutes, right? So, that's kind of where the ten minutes comes from. Like, we took our real threat research data, and then we went around and talked to folks to see kind of what they're experiencing and what their own expectations are for their incident response in SOC teams, and ten minutes is sort of where we landed.Corey: Got it. When you see this happening, I guess, in various customer environments, assuming someone has missed that five-minute window, is a game over effectively? How should people be thinking about this?Anna: No. So, I mean, it's never really game over, right? Like until your company is ransomed to bits, and you have to close your business, you still have many things that you can do, hopefully, to save yourself. And also, I want to be very clear that 5/5/5 as a benchmark is meant to be something aspirational, right? So, you should be able to meet this benchmark for, let's say, your top use cases if you are a fairly high maturity organization, in threat detection specifically, right?So, if you're just beginning your threat detection journey, like, tomorrow, you're not going to be close. Like, you're going to be not at all close. The point here, though, is that you should aspire to this level of greatness, and you're going to have to create new processes and adopt new tools to get there. Now, before you get there, I would argue that if you can do, like, 10-10-10 or, like, whatever number you start with, you're on a mission to make that number smaller, right? So, if today, you can detect a crypto miner in 30 minutes, that's not great because crypto miners are pretty detectable these days, but give yourself a goal of, like, getting that 30 minutes down to 20, or getting that 30 minutes down to 10, right?Because we are so obsessed with, like, measuring ourselves against our peers and all this other stuff that we sometimes lose track of what actually is improving our security program. So yes, compare it to yourself first. But ultimately, if you can meet the 5/5/5 benchmark, then you are doing great. Like, you are faster than the attackers in theory, so that's the dream.Corey: So, I have to ask, and I suspect I might know the answer to this, but given that it seems very hard to move this quickly, especially at scale, is there an argument to be made that effectively prevention obviates the need for any of this, where if you don't misconfigure things in ways that should be obvious, if you practice defense-in-depth to a point where you can effectively catch things that the first layer meets with successive layers, as opposed to, “Well, we have a firewall. Once we're inside of there, well [laugh], it's game over for us.” Is prevention sufficient in some ways to obviate this?Anna: I think there are a lot of people that would love to believe that that's true.Corey: Oh, I sure would. It's such a comforting story.Anna: And we've done, like, I think one of my opening sentences in the benchmark, kind of, description, actually, is that we've done a pretty good job of advertising prevention in Cloud as an important thing and getting people to actually, like, start configuring things more carefully, or like, checking how those things have been configured, and then changing that configuration should they discover that it is not compliant with some mundane standard that everyone should know, right? So, we've made great progress, I think, in cloud prevention, but as usual, like, prevention fails, right? Like I still have smoke detectors in my house, even though I have done everything possible to prevent it from catching fire and I don't plan to set it on fire, right? But like, threat detection is one of these things that you're always going to need because no matter what you do, A, you will make a mistake because you're a human being, and there are too many things, and you'll make a mistake, and B, the bad guys are literally in the business of figuring ways around your prevention and your protective systems.So, I am full on on defense-in-depth. I think it's a beautiful thing. We should only obviously do that. And I do think that prevention is your first step to a holistic security program—otherwise, what even is the point—but threat detection is always going to be necessary. And like I said, even if you can't go 5/5/5, you don't have threat detection at that speed, you need to at least be able to know what happened later so you can update your prevention system.Corey: This might be a dangerous question to get into, but why not, that's what I do here. This [could 00:17:27] potentially an argument against Cloud, by which I mean that if I compromise someone's Cloud account on any of the major cloud providers, once I have access of some level, I know where everything else in the environment is as a general rule. I know that you're using S3 or its equivalent, and what those APIs look like and the rest, whereas as an attacker, if I am breaking into someone's crappy data center-hosted environment, everything is going to be different. Maybe they don't have a SAN at all, for example. Maybe they have one that hasn't been patched in five years. Maybe they're just doing local disk for some reason.There's a lot of discovery that has to happen that is almost always removed from Cloud. I mean, take the open S3 bucket problem that we've seen as a scourge for 5, 6, 7 years now, where it's not that S3 itself is insecure, but once you make a configuration mistake, you are now in line with a whole bunch of other folks who may have much more valuable data living in that environment. Where do you land on that one?Anna: This is the ‘leave cloud to rely on security through obscurity' argument?Corey: Exactly. Which I'm not a fan of, but it's also hard to argue against from time-to-time.Anna: My other way of phrasing it is ‘the attackers are ripping up the stack' argument. Yeah, so—and there is some sort of truth in that, right? Part of the reason that attackers can move that fast—and I think we say this a lot when we talk about the threat report data, too, because we literally see them execute this behavior, right—is they know what the cloud looks like, right? They have access to all the API documentation, they kind of know what all the constructs are that you're all using, and so they literally can practice their attack and create all these scripts ahead of time to perform their reconnaissance because they know exactly what they're looking at, right? On-premise, you're right, like, they're going to get into—even to get through my firewall, whatever, they're getting into my data center, they don't do not know what disaster I have configured, what kinds of servers I have where, and, like, what the network looks like, they have no idea, right?In Cloud, this is kind of all gifted to them because it's so standard, which is a blessing and a curse. It's a blessing because—well for them, I mean, because they can just programmatically go through this stuff, right? It's a curse for them because it's a blessing for us in the same way, right? Like, the defenders… A, have a much easier time knowing what they even have available to them, right? Like, the days of there's a server in a closet I've never heard of are kind of gone, right? Like, you know what's in your Cloud account because, frankly, AWS tells you. So, I think there is a trade-off there.The other thing is—about the moving up the stack thing, right—like no matter what you do, they will come after you if you have something worth exploiting you for, right? So, by moving up the stack, I mean, listen, we have abstracted all the physical servers, all of the, like, stuff we used to have to manage the security of because the cloud just does that for us, right? Now, we can argue about whether or not they do a good job, but I'm going to be generous to them and say they do a better job than most companies [laugh] did before. So, in that regard, like, we say, thank you, and we move on to, like, fighting this battle at a higher level in the stack, which is now the workloads and the cloud control plane, and the you name it, whatever is going on after that. So, I don't actually think you can sort of trade apples for oranges here. It's just… bad in a different way.Corey: Do you think that this benchmark is going to be used by various companies who will learn about it? And if so, how do you see that playing out?Anna: I hope so. My hope when we created it was that it would sort of serve as a goalpost or a way to measure—Corey: Yeah, it would just be marketing words on a page and never mentioned anywhere, that's our dream here.Anna: Yeah, right. Yeah, I was bored. So, I wrote some—[laugh].Corey: I had a word minimum to get out the door, so there we are. It's how we work.Anna: Right. As you know, I used to be a Gartner analyst, and my desire is always to, like, create things that are useful for people to figure out how to do better in security. And my, kind of, tenure at the vendor is just a way to fund that [laugh] more effectively [unintelligible 00:21:08].Corey: Yeah, I keep forgetting you're ex-Gartner. Yeah, it's one of those fun areas of, “Oh, yeah, we just want to basically talk about all kinds of things because there's a—we have a chart to fill out here. Let's get after it.”Anna: I did not invent an acronym, at least. Yeah, so my goal was the following. People are always looking for a benchmark or a goal or standard to be like, “Hey, am I doing a good job?” Whether I'm, like a SOC analyst or director, and I'm just looking at my little SOC empire, or I'm a full on CSO, and I'm looking at my entire security program to kind of figure out risk, I need some way to know whether what is happening in my organization is, like, sufficient, or on par, or anything. Is it good or is it bad? Happy face? Sad face? Like, I need some benchmark, right?So normally, the Gartner answer to this, typically, is like, “You can only come up with benchmarks that are—” they're, like, “Only you know what is right for your company,” right? It's like, you know, the standard, ‘it depends' answer. Which is true, right, because I can't say that, like, oh, a huge multinational bank should follow the same benchmark as, like, a donut shop, right? Like, that's unreasonable. So, this is also why I say that our benchmark is probably more tailored to the more advanced organizations that are dealing with kind of high maturity phenomena and are more cloud-native, but the donut shops should kind of strive in this direction, right?So, I hope that people will think of it this way: that they will, kind of, look at their process and say, “Hey, like, what are the things that would be really bad if they happened to me, in terms of sort detection?” Like, “What are the threats I'm afraid of where if I saw this in my cloud environment, I would have a really bad day?” And, “Can I detect those threats in 5/5/5?” Because if I can, then I'm actually doing quite well. And if I can't, then I need to set, like, some sort of roadmap for myself on how I get from where I am now to 5/5/5 because that implies you would be doing a good job.So, that's sort of my hope for the benchmark is that people think of it as something to aspire to, and if they're already able to meet it, then that they'll tell us how exactly they're achieving it because I really want to be friends with them.Corey: Yeah, there's a definite lack of reasonable ways to think about these things, at least in ways that can be communicated to folks outside of the bounds of the security team. I think that's one of the big challenges currently facing the security industry is that it is easy to get so locked into the domain-specific acronyms, philosophies, approaches, and the rest, that even coming from, “Well, I'm a cloud engineer who ostensibly needs to know about these things.” Yeah, wander around the RSA floor with that as your background, and you get lost very quickly.Anna: Yeah, I think that's fair. I mean, it is a very, let's say, dynamic and rapidly evolving space. And by the way, like, it was really hard for me to pick these numbers, right, because I… very much am on that whole, ‘it depends' bandwagon of I don't know what the right answer is. Who knows what the right answer is [laugh]? So, I say 5/5/5 today. Like, tomorrow, the attack takes five minutes, and now it's two-and-a-half/two-and-a-half, right? Like it's whatever.You have to pick a number and go for it. So, I think, to some extent, we have to try to, like, make sense of the insanity and choose some best practices to anchor ourselves in or some, kind of like, sound logic to start with, and then go from there. So, that's sort of what I go for.Corey: So, as I think about the actual reaction times needed for 5/5/5 to actually be realistic, people can't reliably get a hold of me on the phone within five minutes, so it seems like this is not something you're going to have humans in the loop for. How does that interface with the idea of automating things versus giving automated systems too much power to take your site down as a potential failure mode?Anna: Yeah. I don't even answer the phone anymore, so that wouldn't work at all. That's a really, really good question, and probably the question that gives me the most… I don't know, I don't want to say lost sleep at night because it's actually, it's very interesting to think about, right? I don't think you can remove humans from the loop in the SOC. Like, certainly there will be things you can auto-respond to some extent, but there'd better be a human being in there because there are too many things at stake, right?Some of these actions could take your entire business down for far more hours or days than whatever the attacker was doing before. And that trade-off of, like, is my response to this attack actually hurting the business more than the attack itself is a question that's really hard to answer, especially for most of us technical folks who, like, don't necessarily know the business impact of any given thing. So, first of all, I think we have to embrace other response actions. Back to our favorite crypto miners, right? Like there is no reason to not automatically shut them down. There is no reason, right? Just build in a detection and an auto-response: every time you see a crypto miner, kill that process, kill that container, kill that node. I don't care. Kill it. Like, why is it running? This is crazy, right?I do think it gets nuanced very quickly, right? So again, in SCARLETEEL, there are essentially, like, five or six detections that occur, right? And each of them theoretically has a potential auto-response that you could have executed depending on your, sort of, appetite for that level of intervention, right? Like, when you see somebody assuming a role, that's perfectly normal activity most of the time. In this case, I believe they actually assumed a machine role, which is less normal. Like, that's kind of weird.And then what do you do? Well, you can just, like, remove the role. You can remove that person's ability to do anything, or remove that role's ability to do anything. But that could be very dangerous because we don't necessarily know what the full scope of that role is as this is happening, right? So, you could take, like, a more mitigated auto-response action and add a restrictive policy to that rule, for example, to just prevent activity from that IP address that you just saw, right, because we're not sure about this IP address, but we're sure about this role, right?So, you have to get into these, sort of, risk-tiered response actions where you say, “Okay, this is always okay to do automatically. And this is, like, sometimes, okay, and this is never okay.” And as you develop that muscle, it becomes much easier to do something rather than doing nothing and just, kind of like, analyzing it in forensics and being, like, “Oh, what an interesting attack story,” right? So, that's step one, is just start taking these different response actions.And then step two is more long-term, and it's that you have to embrace the cloud-native way of life, right? Like this immutable, ephemeral, distributed religion that we've been selling, it actually works really well if you, like, go all-in on the religion. I sound like a real cult leader [laugh]. Like, “If you just go all in, it's going to be great.” But it's true, right?So, if your workflows are immutable—that means they cannot change as they're running—then when you see them drifting from their original configuration, like, you know, that is bad. So, you can immediately know that it's safe to take an auto-respon—well, it's safe, relatively safe, take an auto-response action to kill that workload because you are, like, a hundred percent certain it is not doing the right things, right? And then furthermore, if all of your deployments are defined as code, which they should be, then it is approximately—[though not entirely 00:27:31]—trivial to get that workload back, right? Because you just push a button, and it just generates that same Kubernetes cluster with those same nodes doing all those same things, right? So, in the on-premise world where shooting a server was potentially the, you know, fireable offense because if that server was running something critical, and you couldn't get it back, you were done.In the cloud, this is much less dangerous because there's, like, an infinite quantity of servers that you could bring back and hopefully Infrastructure-as-Code and, kind of, Configuration-as-Code in some wonderful registry, version-controlled for you to rely on to rehydrate all that stuff, right? So again, to sort of TL;DR, get used to doing auto-response actions, but do this carefully. Like, define a scope for those actions that make sense and not just, like, “Something bad happened; burn it all down,” obviously. And then as you become more cloud-native—which sometimes requires refactoring of entire applications—by the way, this could take years—just embrace the joy of Everything-as-Code.Corey: That's a good way of thinking about it. I just, I wish there were an easier path to get there, for an awful lot of folks who otherwise don't find a clear way to unlock that.Anna: There is not, unfortunately [laugh]. I mean, again, the upside on that is, like, there are a lot of people that have done it successfully, I have to say. I couldn't have said that to you, like, six, seven years ago when we were just getting started on this journey, but especially for those of you who were just at KubeCon—however, long ago… before this airs—you see a pretty robust ecosystem around Kubernetes, around containers, around cloud in general, and so even if you feel like your organization's behind, there are a lot of folks you can reach out to to learn from, to get some help, to just sort of start joining the masses of cloud-native types. So, it's not nearly as hopeless as before. And also, one thing I like to say always is, almost every organization is going to have some technical debt and some legacy workload that they can't convert to the religion of cloud.And so, you're not going to have a 5/5/5 threat detection SLA on those workloads. Probably. I mean, maybe you can, but probably you're not, and you may not be able to take auto-response actions, and you may not have all the same benefits available to you, but like, that's okay. That's okay. Hopefully, whatever that thing is running is, you know, worth keeping alive, but set this new standard for your new workloads. So, when your team is building a new application, or if they're refactoring an application, can't afford the new world, set the standard on them and don't, kind of like, torment the legacy folks because it doesn't necessarily make sense. Like, they're going to have different SLAs for different workloads.Corey: I really want to thank you for taking the time to speak with me yet again about the stuff you folks are coming out with. If people want to learn more, where's the best place for them to go?Anna: Thanks, Corey. It's always a pleasure to be on your show. If you want to learn more about the 5/5/5 benchmark, you should go to sysdig.com/555.Corey: And we will, of course, put links to that in the show notes. Thank you so much for taking the time to speak with me today. As always, it's appreciated. Anna Belak, Director at the Office of Cybersecurity Strategy at Sysdig. I'm Cloud Economist Corey Quinn, and this has been a promoted guest episode brought to us by our friends at Sysdig. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice, along with an angry, insulting comment that I will read nowhere even approaching within five minutes.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business, and we get to the point. Visit duckbillgroup.com to get started.

When a team is just starting with 900hp in a street-driven 4g63 powered EVO drag car, you know big things are coming!Use ‘PODCAST75' for $75 off your first HPA course here: https://hpcdmy.co/hpa-tuned-inWhy a 4g63 instead of a 4g64, nitrous for turbo spool and a 400hp boost, fire ring cylinder sealing and more from Jimmy Assaad of ERS Evolution Racing Spares as he runs us through this street-driven roll racer that has its long-term sights set on the 1/4 mile.Putting down 900hp at 50psi on a rolling road dyno using pump E85 to start with, this Micks Motorsport-built 4g63 is no joke, with 1500hp at around 80psi running methanol fuel being a longer-term plan for the drag strip with the addition of a few more Siemens fuel injectors. A Platinum Racing Products-supplied Precision 8085 Next Gen turbo takes care of the boost with an Emtron electronics package, including a KV12 ECU and ED10M dash logger managing almost everything on the car via 50 odd sensors.The Bullet Cylinder Heads billet 4g63 block runs copper gasket & aluminium bronze fire ring cylinder sealing setup, aluminium rods, custom pistons and non-MIVEC head with aftermarket cams package, all combinations that have been tried and tested over the years.With an 18-inch SSR wheel package for the street and a 15-inch Belak package for the track wrapped in 275 Hoosiers, no compromises need to be made when it comes to comfort vs. grip, and a Wilwood brake package still fits under the 15inch rim nicely to haul things up at the end of a run.A paddle-shifted Holinger Engineering sequential, Active Traction Service (ATS) carbon clutch and a retained active centre differential (ACD) round off the drivetrain, with carbon clutches being more common in circuit racing but likely to hold up fine for drag racing, too.At the time of filming, the immediate goals are to see what power can be made while still running pump E85 at 60-65psi of boost with a 400hp nitrous shot on tap for further testing.

Anna Belak, Director of The Office of Cybersecurity Strategy at Sysdig, joins Corey on Screaming in the Cloud to discuss the findings in this year's newly-released Sysdig Global Cloud Threat Report. Anna explains the challenges that teams face in ensuring their cloud is truly secure, including quantity of data versus quality, automation, and more. Corey and Anna also discuss how much faster attacks are able to occur, and Anna gives practical insights into what can be done to make your cloud environment more secure. About AnnaAnna has nearly ten years of experience researching and advising organizations on cloud adoption with a focus on security best practices. As a Gartner Analyst, Anna spent six years helping more than 500 enterprises with vulnerability management, security monitoring, and DevSecOps initiatives. Anna's research and talks have been used to transform organizations' IT strategies and her research agenda helped to shape markets. Anna is the Director of The Office of Cybersecurity Strategy at Sysdig, using her deep understanding of the security industry to help IT professionals succeed in their cloud-native journey.Anna holds a PhD in Materials Engineering from the University of Michigan, where she developed computational methods to study solar cells and rechargeable batteries.Links Referenced: Sysdig: https://sysdig.com/ Sysdig Global Cloud Threat Report: https://www.sysdig.com/2023threatreport duckbillgroup.com: https://duckbillgroup.com TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. This promoted guest episode is brought to us by our friends over at Sysdig. And once again, I am pleased to welcome Anna Belak, whose title has changed since last we spoke to Director of the Office of Cybersecurity Strategy at Sysdig. Anna, welcome back, and congratulations on all the adjectives.Anna: [laugh]. Thank you so much. It's always a pleasure to hang out with you.Corey: So, we are here today to talk about a thing that has been written. And we're in that weird time thing where while we're discussing it at the moment, it's not yet public but will be when this releases. The Sysdig Global Cloud Threat Report, which I am a fan of. I like quite a bit the things it talks about and the ways it gets me thinking. There are things that I wind up agreeing with, there are things I wind up disagreeing with, and honestly, that makes it an awful lot of fun.But let's start with the whole, I guess, executive summary version of this. What is a Global Cloud Threat Report? Because to me, it seems like there's an argument to be made for just putting all three of the big hyperscale clouds on it and calling it a day because they're all threats to somebody.Anna: To be fair, we didn't think of the cloud providers themselves as the threats, but that's a hot take.Corey: Well, an even hotter one is what I've seen out of Azure lately with their complete lack of security issues, and the attackers somehow got a Microsoft signing key and the rest. I mean, at this point, I feel like Charlie Bell was brought in from Amazon to head cybersecurity and spent the last two years trapped in the executive washroom or something. But I can't prove it, of course. No, you target the idea of threats in a different direction, towards what people more commonly think of as threats.Anna: Yeah, the bad guys [laugh]. I mean, I would say that this is the reason you need a third-party security solution, buy my thing, blah, blah, blah, but [laugh], you know? Yeah, so we are—we have a threat research team like I think most self-respecting security vendors these days do. Ours, of course, is the best of them all, and they do all kinds of proactive and reactive research of what the bad guys are up to so that we can help our customers detect the bad guys, should they become their victims.Corey: So, there was a previous version of this report, and then you've, in long-standing tradition, decided to go ahead and update it. Unlike many of the terrible professors I've had in years past, it's not just slap a new version number, change the answers to some things, and force all the students to buy a new copy of the book every year because that's your retirement plan, you actually have updated data. What are the big changes you've seen since the previous incarnation of this?Anna: That is true. In fact, we start from scratch, more or less, every year, so all the data in this report is brand new. Obviously, it builds on our prior research. I'll say one clearly connected piece of data is, last year, we did a supply chain story that talked about the bad stuff you can find in Docker Hub. This time we upleveled that and we actually looked deeper into the nature of said bad stuff and how one might identify that an image is bad.And we found that 10% of the malware scary things inside images actually can't be detected by most of your static tools. So, if you're thinking, like, static analysis of any kind, SCA, vulnerability scanning, just, like, looking at the artifact itself before it's deployed, you actually wouldn't know it was bad. So, that's a pretty cool change, I would say [laugh].Corey: It is. And I'll also say what's going to probably sound like a throwaway joke, but I assure you it's not, where you're right, there is a lot of bad stuff on Docker Hub and part of the challenge is disambiguating malicious-bad and shitty-bad. But there are serious security concerns to code that is not intended to be awful, but it is anyway, and as a result, it leads to something that this report gets into a fair bit, which is the ideas of, effectively, lateralling from one vulnerability to another vulnerability to another vulnerability to the actual story. I mean, Capital One was a great example of this. They didn't do anything that was outright negligent like leaving an S3 bucket open; it was a determined sophisticated attacker who went from one mistake to one mistake to one mistake to, boom, keys to the kingdom. And that at least is a little bit more understandable even if it's not great when it's your bank.Anna: Yeah. I will point out that in the 10% that these things are really bad department, it was 10% of all things that were actually really bad. So, there were many things that were just shitty, but we had pared it down to the things that were definitely malicious, and then 10% of those things you could only identify if you had some sort of runtime analysis. Now, runtime analysis can be a lot of different things. It's just that if you're relying on preventive controls, you might have a bad time, like, one times out of ten, at least.But to your point about, kind of, chaining things together, I think that's actually the key, right? Like, that's the most interesting moment is, like, which things can they grab onto, and then where can they pivot? Because it's not like you barge in, open the door, like, you've won. Like, there's multiple steps to this process that are sometimes actually quite nuanced. And I'll call out that, like, one of the other findings we got this year that was pretty cool is that the time it takes to get through those steps is very short. There's a data point from Mandiant that says that the average dwell time for an attacker is 16 days. So like, two weeks, maybe. And in our data, the average dwell time for the attacks we saw was more like ten minutes.Corey: And that is going to be notable for folks. Like, there are times where I have—in years past; not recently, mind you—I have—oh, I'm trying to set something up, but I'm just going to open this port to the internet so I can access it from where I am right now and I'll go back and shut it in a couple hours. There was a time that that was generally okay. These days, everything happens so rapidly. I mean, I've sat there with a stopwatch after intentionally committing AWS credentials to Gif-ub—yes, that's how it's pronounced—and 22 seconds until the first probing attempt started hitting, which was basically impressively fast. Like, the last thing in the entire sequence was, and then I got an alert from Amazon that something might have been up, at which point it is too late. But it's a hard problem and I get it. People don't really appreciate just how quickly some of these things can evolve.Anna: Yeah. And I think the main reason, from at least what we see, is that the bad guys are into the cloud saying, right, like, we good guys love the automation, we love the programmability, we love the immutable infrastructure, like, all this stuff is awesome and it's enabling us to deliver cool products faster to our customers and make more money, but the bad guys are using all the same benefits to perpetrate their evil crimes. So, they're building automation, they're stringing cool things together. Like, they have scripts that they run that basically just scan whatever's out there to see what new things have shown up, and they also have scripts for reconnaissance that will just send a message back to them through Telegram or WhatsApp, letting them know like, “Hey, I've been running, you know, for however long and I see a cool thing you may be able to use.” Then the human being shows up and they're like, “All right. Let's see what I can do with this credential,” or with this misconfiguration or what have you. So, a lot of their initial, kind of, discovery into what they can get at is heavily automated, which is why it's so fast.Corey: I feel like, on some level, this is an unpleasant sharp shock for an awful lot of executives because, “Wait, what do you mean attackers can move that quickly? Our crap-ass engineering teams can't get anything released in less than three sprints. What gives?” And I don't think people have a real conception of just how fast bad actors are capable of moving.Anna: I think we said—actually [unintelligible 00:07:57] last year, but this is a business for them, right? They're trying to make money. And it's a little bleak to think about it, but these guys have a day job and this is it. Like, our guys have a day job, that's shipping code, and then they're supposed to also do security. The bad guys just have a day job of breaking your code and stealing your stuff.Corey: And on some level, it feels like you have a choice to make in which side you go at. And it's, like, which one of those do I spend more time in meetings with? And maybe that's not the most legitimate way to pick a job; ethics do come into play. But yeah, there's it takes a certain similar mindset, on some level, to be able to understand just how the security landscape looks from an attacker's point of view.Anna: I'll bet the bad guys have meetings too, actually.Corey: You know, you're probably right. Can you imagine the actual corporate life of a criminal syndicate? That's a sitcom in there that just needs to happen. But again, I'm sorry, I shouldn't talk about that. We're on a writer's strike this week, so there's that.One thing that came out of the report that makes perfect sense—and I've heard about it, but I haven't seen it myself and I wanted to dive into on this—specifically that automation has been weaponized in the cloud. Now, it's easy to misinterpret that the first time you read it—like I did—as, “Oh, you mean the bad guys have discovered the magic of shell scripts? No kidding.” It's more than that. You have reports of people using things like CloudFormation to stand up resources that are then used to attack the rest of the infrastructure.And it's, yeah, it makes perfect sense. Like, back in the data center days, it was a very determined attacker that went through the process of getting an evil server stuffed into a rack somewhere. But it's an API call away in cloud. I'm surprised we haven't seen this before.Anna: Yeah. We probably have; I don't know if we've documented before. And sometimes it's hard to know that that's what's happening, right? I will say that both of those things are true, right? Like the shell scripts are definitely there, and to your point about how long it takes, you know, to stopwatch, these things, on the short end of our dwell time data set, it's zero seconds. It's zero seconds from, like, A to B because it's just a script.And that's not surprising. But the comment about CloudFormation specifically, right, is we're talking about people, kind of, figuring out how to create policy in the cloud to prevent bad stuff from happening because they're reading all the best practices ebooks and whatever, watching the YouTube videos. And so, you understand that you can, say, write policy to prevent users from doing certain things, but sometimes we forget that, like, if you don't want a user to be able to attach user policy to something. If you didn't write the rule that says you also can't do that in CloudFormation, then suddenly, you can't do it in command line, but you can do it in CloudFormation. So there's, kind of, things like this, where for every kind of tool that allows this beautiful, programmable, immutable infrastructure, kind of, paradigm, you now have to make sure that you have security policies that prevent those same tools from being used against you and deploying evil things because you didn't explicitly say that you can't deploy evil things with this tool and that tool and that other tool in this other way. Because there's so many ways to do things, right?Corey: That's part of the weird thing, too, is that back when I was doing the sysadmin dance, it was a matter of taking a bunch of tools that did one thing well—or, you know, aspirationally well—and then chaining them together to achieve things. Increasingly, it feels like that's what cloud providers have become, where they have all these different services with different capabilities. One of the reasons that I now have a three-part article series, each one titled, “17 Ways to Run Containers on AWS,” adding up for a grand total of 51 different AWS services you can use to run containers with, it's not just there to make fun of the duplication of efforts because they're not all like that. But rather, each container can have bad acting behaviors inside of it. And are you monitoring what's going on across that entire threatened landscape?People were caught flat-footed to discover that, “Wait, Lambda functions can run malware? Wow.” Yes, effectively, anything that can bang two bits together and return a result is capable of running a lot of these malware packages. It's something that I'm not sure a number of, shall we say, non-forward-looking security teams have really wrapped their heads around yet.Anna: Yeah, I think that's fair. And I mean, I always want to be a little sympathetic to the folks, like, in the trenches because it's really hard to know all the 51 ways to run containers in the cloud and then to be like, oh, 51 ways to run malicious containers in the cloud. How do I prevent all of them, when you have a day job?Corey: One point that it makes in the report here is that about who the attacks seem to be targeting. And this is my own level of confusion that I imagine we can probably wind up eviscerating neatly. Back when I was running, like, random servers for me for various projects I was working on—or working at small companies—there was a school of thought in some quarters that, well, security is not that important to us. We don't have any interesting secrets. Nobody actually cares.This was untrue because a lot of these things are running on autopilot. They don't have enough insight to know that you're boring and you have to defend just like everyone else does. But then you see what can only be described as dumb attacks. Like there was the attack on Twitter a few years ago where a bunch of influential accounts tweeted about some bitcoin scam. It's like, you realize with the access you had, you had so many other opportunities to make orders of magnitude more money if you want to go down that path or to start geopolitical conflict or all kinds of other stuff. I have to wonder how much these days are attacks targeted versus well, we found an endpoint that doesn't seem to be very well secured; we're going to just exploit it.Anna: Yeah. So, that's correct intuition, I think. We see tons of opportunistic attacks, like, non-stop. But it's just, like, hitting everything, honeypots, real accounts, our accounts, your accounts, like, everything. Many of them are pretty easy to prevent, honestly, because it's like just mundane stuff, whatever, so if you have decent security hygiene, it's not a big deal.So, I wouldn't say that you're safe if you're not special because none of us are safe and none of us are that special. But what we've done here is we actually deliberately wanted to see what would be attacked as a fraction, right? So, we deployed a honey net that was indicative of what a financial org would look like or what a healthcare org would look like to see who would bite, right? And what we expected to see is that we probably—we thought the finance would be higher because obviously, that's always top tier. But for example, we thought that people would go for defense more or for health care.And we didn't see that. We only saw, like, 5% I think for health—very small numbers for healthcare and defense and very high numbers for financial services and telcos, like, around 30% apiece, right? And so, it's a little curious, right, because you—I can theorize as to why this is. Like, telcos and finance, obviously, it's where the money is, like, great [unintelligible 00:14:35] for fraud and all this other stuff, right?Defense, again, maybe people don't think defense and cloud. Healthcare arguably isn't that much in cloud, right? Like a lot of health healthcare stuff is on-premise, so if you see healthcare in cloud, maybe, you, like, think it's a honeypot or you don't [laugh] think it's worth your time? You know, whatever. Attacker logic is also weird. But yeah, we were deliberately trying to see which verticals were the most attractive for these folks. So, these attacks are infected targeted because the victim looked like the kind of thing they should be looking for if they were into that.Corey: And how does it look in that context? I mean, part of me secretly suspects that an awful lot of terrible startup names where they're so frugal they don't buy vowels, is a defense mechanism. Because you wind up with something that looks like a cat falling on a keyboard as a company name, no attacker is going to know what the hell your company does, so therefore, they're not going to target you specifically. Clearly, that's not quite how it works. But what are those signals that someone gets into an environment and says, “Ah, this is clearly healthcare,” versus telco versus something else?Anna: Right. I think you would be right. If you had, like… hhhijk as your company name, you probably wouldn't see a lot of targeted attacks. But where we're saying either the company and the name looks like a provider of that kind, and-slash-or they actually contain some sort of credential or data inside the honeypot that appears to be, like, a credential for a certain kind of thing. So, it really just creatively naming things so they look delicious.Corey: For a long time, it felt like—at least from a cloud perspective because this is how it manifested—the primary purpose of exploiting a company's cloud environment was to attempt to mine cryptocurrency within it. And I'm not sure if that was ever the actual primary approach, or rather, that was just the approach that people noticed because suddenly, their AWS bill looks a lot more like a telephone number than it did yesterday, so they can as a result, see that it's happening. Are these attacks these days, effectively, just to mine Bitcoin, if you'll pardon the oversimplification, or are they focused more on doing more damage in different ways?Anna: The analyst answer: it depends. So, again, to your point about how no one's safe, I think most attacks by volume are going to be opportunistic attacks, where people just want money. So, the easiest way right now to get money is to mine coins and then sell those coins, right? Obviously, if you have the infrastructure as a bad guy to get money in other ways, like, you could do extortion through ransomware, you might pursue that. But the overhead on ransomware is, like, really high, so most people would rather not if they can get money other ways.Now, because by volume APTs, or Advanced Persistent Threats, are much smaller than all the opportunistic guys, they may seem like they're not there or we don't see them. They're also usually better at attacking people than the opportunistic guys who will just spam everybody and see what they get, right? But even folks who are not necessarily nation states, right, like, we see a lot of attacks that probably aren't nation states, but they're quite sophisticated because we see them moving through the environment and pivoting and creating things and leveraging things that are quite interesting, right? So, one example is that they might go for a vulnerable EC2 instance—right, because maybe you have Log4J or whatever you have exposed—and then once they're there, they'll look around to see what else they can get. So, they'll pivot to the Cloud Control Plane, if it's possible, or they'll try to.And then in a real scenario we actually saw in an attack, they found a Terraform state file. So, somebody was using Terraform for provisioning whatever. And it requires an access key and this access key was just sitting in an S3 bucket somewhere. And I guess the victim didn't know or didn't think it was an issue. And so, this state file was extracted by the attacker and they found some [unintelligible 00:18:04], and they logged into whatever, and they were basically able to access a bunch of information they shouldn't have been able to see, and this turned into a data [extraction 00:18:11] scenario and some of that data was intellectual property.So, maybe that wasn't useful and maybe that wasn't their target. I don't know. Maybe they sold it. It's hard to say, but we increasingly see these patterns that are indicative of very sophisticated individuals who understand cloud deeply and who are trying to do intentionally malicious things other than just like, I popped [unintelligible 00:18:30]. I'm happy.Corey: This episode is sponsored in part by our friends at Calisti.Introducing Calisti. With Integrated Observability, Calisti provides a single pane of glass for accelerated root cause analysis and remediation. It can set, track, and ensure compliance with Service Level Objectives.Calisti provides secure application connectivity and management from datacenter to cloud, making it the perfect solution for businesses adopting cloud native microservice-based architectures. If you're running Apache Kafka, Calisti offers a turnkey solution with automated operations, seamless integrated security, high-availability, disaster recovery, and observability. So you can easily standardize and simplify microservice security, observability, and traffic management. Simplify your cloud-native operations with Calisti. Learn more about Calisti at calisti.app.Corey: I keep thinking of ransomware as being a corporate IT side of problem. It's a sort of thing you'll have on your Windows computers in your office, et cetera, et cetera, despite the fact that intellectually I know better. There were a number of vendors talking about ransomware attacks and encrypting data within S3, and initially, I thought, “Okay, this sounds like exactly a story people would talk about some that isn't really happening in order to sell their services to guard against it.” And then AWS did a blog post saying, “We have seen this, and here's what we have learned.” It's, “Oh, okay. So, it is in fact real.”But it's still taking me a bit of time to adapt to the new reality. I think part of this is also because back when I was hands-on-keyboard, I was unlucky, and as a result, I was kept from taking my aura near anything expensive or long-term like a database, and instead, it's like, get the stateless web servers. I can destroy those and we'll laugh and laugh about it. It'll be fine. But it's not going to destroy the company in the same way. But yeah, there are a lot of important assets in cloud that if you don't have those assets, you will no longer have a company.Anna: It's funny you say that because I became a theoretical physicist instead of experimental physicist because when I walked into the room, all the equipment would stop functioning.Corey: Oh, I like that quite a bit. It's one of those ideas of, yeah, your aura just winds up causing problems. Like, “You are under no circumstances to be within 200 feet of the SAN. Is that clear?” Yeah, same type of approach.One thing that I particularly like that showed up in the report that has honestly been near and dear to my heart is when you talk about mitigations around compromised credentials at one point when GitHub winds up having an AWS credential, AWS has scanners and a service that will catch that and apply a quarantine policy to those IAM credentials. The problem is, is that policy goes nowhere near far enough at all. I wound up having fun thought experiment a while back, not necessarily focusing on attacking the cloud so much as it was a denial of wallet attack. With a quarantined key, how much money can I cost? And I had to give up around the $26 billion dollar mark.And okay, that project can't ever see the light of day because it'll just cause grief for people. The problem is that the mitigations around trying to list the bad things and enumerate them mean that you're forever trying to enumerate something that is innumerable in and of itself. It feels like having a hard policy of once this is compromised, it's not good for anything would be the right answer. But people argue with me on that.Anna: I don't think I would argue with you on that. I do think there are moments here—again, I have to have sympathy for the folks who are actually trying to be administrators in the cloud, and—Corey: Oh God, it's hard.Anna: [sigh]. I mean, a lot of the things we choose to do as cloud users and cloud admins are things that are very hard to check for security goodness, if you will, right, like, the security quality of the naming convention of your user accounts or something like that, right? One of the things we actually saw in this report it—and it almost made me cry, like, how visceral my reaction was to this thing—is, there were basically admin accounts in this cloud environment, and they were named according to a specific convention, right? So, if you were, like, admincorey and adminanna, like, that, if you were an admin, you've got an adminanna account, right? And then there was a bunch of rules that were written, like, policies that would prevent you from doing things to those accounts so that they couldn't be compromised.Corey: Root is my user account. What are you talking about?Anna: Yeah, totally. Yeah [laugh]. They didn't. They did the thing. They did the good accounts. They didn't just use root everybody. So, everyone had their own account, it was very neat. And all that happened is, like, one person barely screwed up the naming of their account, right? Instead of a lowercase admin, they use an uppercase Admin, and so all of the policy written for lowercase admin didn't apply to them, and so the bad guy was able to attach all kinds of policies and basically create a key for themselves to then go have a field day with this admin account that they just found laying around.Now, they did nothing wrong. It's just, like, a very small mistake, but the attacker knew what to do, right? The attacker went and enumerated all these accounts or whatever, like, they see what's in the environment, they see the different one, and they go, “Oh, these suckers created a convention, and like, this joker didn't follow it. And I've won.” Right? So, they know to check with that stuff.But our guys have so much going on that they might forget, or they might just you know, typo, like, whatever. Who cares. Is it case-sensitive? I don't know. Is it not case-sensitive? Like, some policies are, some policies aren't. Do you remember which ones are and which ones aren't? And so, it's a little hopeless and painful as, like, a cloud defender to be faced with that, but that's sort of the reality.And right now we're in kind of like, ah, preventive security is the way to save yourself in cloud mode, and these things just, like, they don't come up on, like, the benchmarks and, like the configuration checks and all this other stuff that's just going, you know, canned, did you, you know, put MFA on your user account? Like, yeah, they did, but [laugh] like, they gave it a wrong name and now it's a bad na—so it's a little bleak.Corey: There's too much data. Filtering it becomes nightmarish. I mean, I have what I think of as the Dependabot problem, where every week, I get this giant list of Dependabot freaking out about every repository I have on Gif-ub and every dependency thereof. And some of the stuff hasn't been deployed in years and I don't care. Other stuff is, okay, I can see how that markdown parser could have malicious input passed to it, but it's for an internal project that only ever has very defined things allowed to talk to it so it doesn't actually matter to me.And then at some point, it's like, you expect to read, like, three-quarters of the way down the list of a thousand things, like, “Oh, and by the way, the basement's on fire.” And then have it keep going on where it's… filtering the signal from noise is such a problem that it feels like people only discover the warning signs after they're doing forensics when something has already happened rather than when it's early enough to be able to fix things. How do you get around that problem?Anna: It's brutal. I mean, I'm going to give you, like, my [unintelligible 00:24:28] vendor answer: “It's just easy. Just do what we said.” But I think [laugh] in all honesty, you do need to have some sort of risk prioritization. I'm not going to say I know the answer to what your algorithm has to be, but our approach of, like, oh, let's just look up the CVSS score on the vulnerabilities. Oh, look, 600,000 criticals. [laugh]. You know, you have to be able to filter past that, too. Like, is this being used by the application? Like, has this thing recently been accessed? Like, does this user have permissions? Have they used those permissions?Like, these kinds of questions that we know to ask, but you really have to kind of like force the security team, if you will, or the DevOps team or whatever team you have to actually, instead of looking at the list and crying, being like, how can we pare this list down? Like anything at all, just anything at all. And do that iteratively, right? And then on the other side, I mean, it's so… defense-in-depth, like, right? I know it's—I'm not supposed to say that because it's like, not cool anymore, but it's so true in cloud, like, you have to assume that all these controls will fail and so you have to come up with some—Corey: People will fail, processes will fail, controls will fail, and great—Anna: Yeah.Corey: How do you make sure that one of those things failing isn't winner-take-all?Anna: Yeah. And so, you need some detection mechanism to see when something's failed, and then you, like, have a resilience plan because you know, if you can detect that it's failed, but you can't do anything about it, I mean, big deal, [laugh] right? So detection—Corey: Good job. That's helpful.Anna: And response [laugh]. And response. Actually, mostly response yeah.Corey: Otherwise, it's, “Hey, guess what? You're not going to believe this, but…” it goes downhill from there rapidly.Anna: Just like, how shall we write the news headline for you?Corey: I have to ask, given that you have just completed this report and are absolutely in a place now where you have a sort of bird's eye view on the industry at just the right time, over the past year, we've seen significant macro changes affect an awful lot of different areas, the hiring markets, the VC funding markets, the stock markets. How has, I guess, the threat space evolved—if at all—during that same timeframe?Anna: I'm guessing the bad guys are paying more than the good guys.Corey: Well, there is part of that and I have to imagine also, crypto miners are less popular since sanity seems to have returned to an awful lot of people's perspective on money.Anna: I don't know if they are because, like, even fractions of cents are still cents once you add up enough of them. So, I don't think [they have stopped 00:26:49] mining.Corey: It remains perfectly economical to mine Bitcoin in the cloud, as long as you use someone else's account to do it.Anna: Exactly. Someone else's money is the best kind of money.Corey: That's the VC motto and then some.Anna: [laugh]. Right? I think it's tough, right? I don't want to be cliche and say, “Look, oh automate more stuff.” I do think that if you're in the security space on the blue team and you are, like, afraid of losing your job—you probably shouldn't be afraid if you do your job at all because there's a huge lack of talent, and that pool is not growing quick enough.Corey: You might be out of work for dozens of minutes.Anna: Yeah, maybe even an hour if you spend that hour, like, not emailing people, asking for work. So yeah, I mean, blah, blah, skill up in cloud, like, automate, et cetera. I think what I said earlier is actually the more important piece, right? We have all these really talented people sitting behind these dashboards, just trying to do the right thing, and we're not giving them good data, right? We're giving them too much data and it's not good quality data.So, whatever team you're on or whatever your business is, like, you will have to try to pare down that list of impossible tasks for all of your cloud-adjacent IT teams to a list of things that are actually going to reduce risk to your business. And I know that's really hard to do because you're asking now, folks who are very technical to communicate with folks who are very non-technical, to figure out how to, like, save the business money and keep the business running, and we've never been good at this, but there's no time like the present to actually get good at it.Corey: Let's see, what is it, the best time to plant a tree was 20 years ago. The second best time is now. Same sort of approach. I think that I'm seeing less of the obnoxious whining that I saw for years about how there's a complete shortage of security professionals out there. It's, “Okay, have you considered taking promising people and training them to do cybersecurity?” “No, that will take six months to get them productive.” Then they sit there for two years with the job rec open. It's hmm. Now, I'm not a professor here, but I also sort of feel like there might be a solution that benefits everyone. At least that rhetoric seems to have tamped down.Anna: I think you're probably right. There's a lot of awesome training out there too. So there's, like, folks giving stuff away for free that's super resources, so I think we are doing a good job of training up security folks. And everybody wants to be in security because it's so cool. But yeah, I think the data problem is this decade's struggle, more so than any other decades.Corey: I really want to thank you for taking the time to speak with me. If people want to learn more, where can they go to get their own copy of the report?Anna: It's been an absolute pleasure, Corey, and thanks, as always for having us. If you would like to check out the report—which you absolutely should—you can find it ungated at www.sysdig.com/2023threatreport.Corey: You had me at ungated. Thank you so much for taking the time today. It's appreciated. Anna Belak, Director of the Office of Cybersecurity Strategy at Sysdig. This promoted guest episode has been brought to us by our friends at Sysdig and I'm Cloud Economist Corey Quinn.If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice along with an insulting comment that no doubt will compile into a malicious binary that I can grab off of Docker Hub.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.

Hello and welcome to Get It Started Get It Done, the Banyan Security podcast covering the security industry and beyond. In this episode, our host and Banyan's Chief Security Officer Den Jones speaks with Anna Belak, a former Gartner analyst and cloud, container, and Kubernetes buff. We hope you enjoy Den's discussion with Anna Belak. About Anna Belak, Director, Office of Cybersecurity StrategyAnna has nearly ten years of experience researching and advising organizations on cloud adoption with a focus on security best practices. As a Gartner Analyst, Anna spent six years helping more than 500 enterprises with vulnerability management, security monitoring, and DevSecOps initiatives. Anna's research and talks have been used to transform organizations' IT strategies and her research agenda helped to shape markets. Anna is the Director of Thought Leadership at Sysdig, using her deep understanding of the security industry to help IT professionals succeed in their cloud-native journey.Anna holds a PhD in Materials Engineering from the University of Michigan, where she developed computational methods to study solar cells and rechargeable batteries.

Guest:  Dr Anna Belak, Director of Thought Leadership at Sysdig, former Gartner analyst Questions: Analysts (and vendors) coined a log of “C-something acronyms” for cloud security, and two of the people on this episode were directly involved in some of them. What do you make of all the cloud security acronym proliferation? What is CSPM? What gets better when you deploy it? What is CWPP? Does anything get better when you deploy it? What is CNAPP? What gets better when you deploy it? What is CIEM, Anton's least fave acronym? Now, what about CDR?  Resources: Gartner acronym glossary “Container Security: The Past or The Future?” (ep54, with Anna as well) “Automate and/or Die?” (ep3) “Impersonating Service Accounts in GCP and Beyond: Cloud Security Is About IAM?” (ep60) “Powering Secure SaaS … But Not with CASB? Cloud Detection and Response?” (ep76) “Does the World Need Cloud Detection and Response (CDR)?” “Announcing Virtual Machine Threat Detection now generally available to Cloud customers” Sysdig Threat Report Blog 2022 Sysdig Cloud-Native Threat Report  Anatomy of Cloud Attacks

Avtro recenzije: Iztok Ilich Bere Renato Horvat Vprašanje staroverstva na Slovenskem se je v zadnjih desetih letih – po knjigah Borisa Čoka V siju mesečine in Pavla Medveščka Iz nevidne strani neba in po veliki razstavi v Goriškem muzeju ter vrsti polemik – večkrat znašlo v ospredju pozornosti strokovne in širše javnosti. Zbornik Staroverstvo v Sloveniji med religijo in znanostjo že v naslovu nakazuje, da nesoglasja še zdaleč niso razčiščena. Niti na najosnovnejši ravni ne: ali gre za soočanje z ostanki skrivnega verovanja na zahodnem robu slovenskega ozemlja, ali za sicer zanimive ugotovitve, ki pa zahtevajo še temeljito znanstveno preučevanje, ali morda le za konstrukt, utemeljen na nepreverjenih ali celo potvorjenih in izmišljenih pričevanjih in dokazih. Med etnologi, antropologi, arheologi in raziskovalci z drugih področij humanistično-družboslovnih ved, ki so tem vprašanjem namenili pozornost, sta se izoblikovali dve struji: ena verjame v verodostojnost gradiva in želi ovrednotiti znanje in prakse starovercev, druga pa bolj razmišlja o diskurzih, skupnosti in identiteti, ki jih poraja – po njihovem mnenju – neverodostojno gradivo. Tem dilemam je bil v zadnjih dveh letih namenjen ciljnoraziskovalni projekt Popis, analiza in ovrednotenje primarnih in sekundarnih virov slovenskih raziskovalcev o »posoškem staroverstvu«. V marsičem nasprotujoči si izsledki sodelujočih so zdaj zbrani v knjigi, ki sta jo uredili Saša Babič in Mateja Belak. Namen avtorjev Katje Hrobat Virloget, Matjaža Bizjaka, Cirile Toplak, Lenarta Škofa, Miha Miheliča in Andreja Pleterskega ni bil potrditev ali vnaprejšnje zanikanje pristnosti virov, zgodb, znanj in svetišč, marveč njihovo kritično ovrednotenje in umestitev v zgodovinski, prostorski in družbeni kontekst. Poleg tega so, kot pripominjata urednici, iskali potencial, ki ga tako gradivo ima, in prek pozitivne naklonjenosti nizali spoznanja in predvidevanja o veri v naravo in njeno moč. Da ne bi ostalo le pri njihovih znanstvenih sodbah in dvomih, so v dodatku prepustili prostor tudi za objavo gradiva, v katerem Rudi Čop in Franc Šturm poskušata na podlagi meritev aplikativno dokazati znanje staroverske družbe in s tem eksplicitno izkazati popolno prepričanost v t. i. staroverski sistem. Do verodostojnosti Medveščkovih virov zadržana etnologinja Katja Hrobat Virloget polemizira s posameznimi raziskovalci z obeh strani. Poudarja, da je vsakršno etnografsko gradivo treba jemati s kritično distanco, in ugotavlja, da je prav razdeljenost med etnologi, ki širši javnosti ne ponujajo sprejemljivih napotkov za sprejemanje gradiva o starovercih, pripeljala do laičnih raziskovanj in s tem tudi stranpoti. Med drugim navaja vrsto analogij med Medveščkovimi zapisi o starovercih in tradicijskimi verovanji – zlasti o čaščenju babe, arhaičnega mitskega bitja – na katera je tudi sama naletela na Krasu in drugod. Zgodovinar Matjaž Bizjak dodaja oris poselitvene zgodovine srednjega Posočja, poglavitnega območja raziskovanja staroverstva na Slovenskem. Politologinja Cirila Toplak, ki zaupa verodostojnosti Medveščkovih navedb, pa se nato posebej opredeljuje do besednih zvez »posoško staroverstvo« oziroma »zahodnoslovensko naravoverstvo«. Filozof Lenart Škof v eseju Elementi slovenske prvotne religije primerja Medveščkovo poročilo in interpretacijo staroverstva v knjigi Iz nevidne strani neba s sodobnimi teorijami domorodnih religij. Specifično versko okolje slovenske avtohtone religije – ki ga v zgodovinski povesti Umirajoči bog Triglav po svoje upodablja tudi France Bevk – pa nato predstavi kot elementarno religijo in teologijo narave. Arheolog Miha Mihelič se v nadaljevanju posveča verovanju v boga Belina, sorodnega Belenu iz keltskega panteona, in v magično zdravilno moč ključa sv. Belina. V njem vidi srednjeveško-novoveško spajanje krščanskih in staroverskih, iz prazgodovine izvirajočih elementov, ki so bili vsaj v začetku 20. stoletja še živi v ustnem izročilu zahodne Slovenije. Največ prostora – z uvodnim zapisom Kratko o knjigi in s sklepno razpravo Verovanje host v sklopu staroverstva na Slovenskem in verovanja starih Slovanov – je pripadlo arheologu, etnologu in zgodovinarju Andreju Pleterskemu, avtorju spremne študije v Medveščkovi ključni knjigi iz leta 2015. Tukaj dopolnjuje nekatere takratne ugotovitve. Znova opozarja na pogosto protislovne izjave Medveščkovih sogovornikov in med drugim posebej pojasnjuje pomen host, političnih skupnosti s svojim družbenim redom, ki vključuje izvajanje avtoritete hostarjev, tudi s prisilo, kot vzpostavljanje in vzdrževanje sodelovanja navznoter in neodvisnosti navzven. Opozarja tudi na pomen tročanov, najpogosteje s kamni vzpostavljenih trikotnikov svetih mest, katerih učinka staroverci niso znali pojasniti, so ga pa poznali. Tako postane jasno, še piše Pleterski, zakaj so ljudje tako vztrajno spravljali v obup tiste krščanske duhovnike, ki niso mogli razumeti, kaj ljudem sveta mesta pomenijo, in so bili prepričani, da gre za nagajanje hudiča. »Če razumemo staroverstvo,« sklene, »razumemo čas in način življenja, v katerem sta bili religija in znanost še eno in isto.«

Anna Belak, Director of Thought Leadership at Sysdig, shares her story from physics to cyber. Anna explains how she went into college with the thinking of getting a physics degree and then for her PhD decided to switch to material science and engineering. Both were not something she enjoyed and ultimately decided to go into cyber. She shares some advice on how you should never limit yourself to your degree, as well as always learning new skills and honing in on skills you already have. She say's by doing these things it will make you into a unicorn, meaning if you are good at one thing and teach yourself to be good at something else, you will become that much more valuable. Anna hopes she makes an impact with the people she works with, she hopes they will want to work with her even long after she leaves a company. We thank Anna for sharing her story.

Anna Belak, Director of Thought Leadership at Sysdig, shares her story from physics to cyber. Anna explains how she went into college with the thinking of getting a physics degree and then for her PhD decided to switch to material science and engineering. Both were not something she enjoyed and ultimately decided to go into cyber. She shares some advice on how you should never limit yourself to your degree, as well as always learning new skills and honing in on skills you already have. She say's by doing these things it will make you into a unicorn, meaning if you are good at one thing and teach yourself to be good at something else, you will become that much more valuable. Anna hopes she makes an impact with the people she works with, she hopes they will want to work with her even long after she leaves a company. We thank Anna for sharing her story.

Simon Belak je bil eden prvih inženirjev podjetja Metabase v Silicijevi dolini, tehnični direktor podjetja Go Opti, je soustanovitelj Hekovnika, danes pa tudi svetovalec različnim podjetjem. Komentiramo aktualno dogajanje v Ukrajini, Rusi so v mestu Melitopolj zasegli kmetijsko mehanizacijo podjetja John Deere, ki je stroje izklopilo na daljavo. Podjetje sicer ne slovi po dobrodelnosti, si lasti veliko količino podatkov in kmetom ne dovoli posega v stroj brez pooblaščenih oseb podjetja. Spominjamo se še iPoda, 21 let starega izdelka, ki je spremenil način poslušanja glasbe. Apple je najavil, da se od njega poslavljajo in ga umikajo iz proizvodnje. Traktorji so računalniki John Deere turned tractors into computers — what's next? - The Verge iPod je šel po gobe The music lives on - Apple Apple releases iPod - Slashdot Priporočilo Airtable | Create apps that perfectly fit your team's needs Notion – One workspace. Every team. Metabase | Business Intelligence, Dashboards, and Data Visualization   Pišite nama na odbita@rtvslo.si. Na tem naslovu zbirava ideje za teme in odgovarjava na vprašanja. 

Simon Belak je pomagal več ducatom podjetij postati data-driven in postaviti ali nadgraditi svoje podatkovne oddelke in podatkovno infrastrukturo. Poleg svetovalnega dela je bil tekom svoje kariere eden prvih inženirjev na Metabase iz Silicijeve doline, kjer je vodil razvoj umetne inteligence in pripeljal produkt do tega, da ga dnevno uporablja preko 50.000 podjetji, med drugim Swisscom, N26, Revolut, SpaceX, Adidas. Pred tem je bil tehnični direktor na GoOpti, kjer je s svojim delom podatkovno podprl GoOptijevo mednarodno širitev, izboljšal profitabilnost za 35%, vzpostavil growth hacking procese in pomagal pri pridobitvi serija A investicije tveganega kapitala. Kot soustanovitelj Hekovnika – prve startup šole v Sloveniji – je pustil neizbrisljiv pečat na slovenski startup sceni. Simon je iskan predavatelj doma in po svetu, zavzet mentor in viden član programerske in growth hacking skupnosti. Naj quote: A change of perspective is worth 80 IQ points - A. Kay Naj knjiga: nimam najljubše, ampak knjiga, ki mi je zelo pri srcu in jo skoraj vsakemu priporočam in vsebuje veliko prvin, ki jih zelo cenim je: The Origin of Consciousness in the Breakdown of the Bicameral Mind Naj serija: serij gledam zelo malo. Prva, ki mi pade na pamet je Dirk Gently's Holistic Detective Agency Hobiji: surfanje, gorsko kolesarjenje, restavriranje starodobnih avtomobilov Najljubša hrana: na svetu je preveč jedi, da bi imel najljubšo v smislu, da bi se k njej znova in znova vračal. Rad kuham (navezava kuhanje - hekanje) Najljubši podjetnik: bolj kot razmišljam, bolj se mi zdi, da je dober podjetnik vedno tudi deeply flawed. Ljudje od katerih sem se ogromno naučil: Kristjan Pečanec, Sameer al Sakran (CEO Metabase). Zanimiva oseba mi je Musk. Naj app: Emacs Nauki za naše poslušalce: · Malo dinamik je zares linearnih. Dvakrat večje, dvakrat hitrejše, dvakrat krajše se bo obnašalo več kot dvakrat drugače. Če denimo iterirate dvakrat hitreje, bo pot vašega posla povsem drugačna. · Vsako orodje (in pod to štejem tudi procese in mentalne modele) deluje "na obeh koncih". S svojimi danostmi vpliva na to kako razmišljamo in pristopamo k problemom. Nehote bomo kar je preprosto počeli pogosto, tistemu kar ima veliko trenja pa se bomo izogibali. Analizirati svet okoli nas skozi prizmo UX je zato ena ključnih praks za (samo)izboljševanje. · Najbolj impactful stvar, ki jo lahko naredite (zase in za svoje podjetje) je redna, namerna in sistematična pol urna introspekcija vsak teden.

-Having a fan buy you a beer after he punches you in the mouth -The wildest fights over 22 seasons and Belak vs Cairns -Running a 3 or 4 man system and when to trump your partner -The difference reffing & playing between the EIHL and Danish Metal Ligaen -The best and worst chirper in hockey... Dease & when hockey was hockey

Simon Belak is a visionary; he speaks with outstanding clarity and has a true leader's heart. Working with Metabase has sharpened his skill in product leadership, and today he'll be sharing his line of work with us and walking us through how he can build high leverage teams for his former company, Metabase. Product leadership has become an increasingly important subject in our field. It focuses on specific challenges on those leading product teams and is accountable for product performance and customer satisfaction. Someone can do this by leading a team with a product-centric strategy. Product leaders progress through creating cross-functional influence, product work, and scale. Listen to this episode, and gain value on Simon's insights about the topic. Show notes   [3:29] The personal growth that he gets from such a different lifestyle is reflected in his leadership.  [4:27] Simon's definition of product leadership. [4:47] The fundamental difference between management and leadership. [7:10] Leadership should be fundamentally about enabling people. [8:35] To earn leadership, you have to show that you're always trying to better your team. [9:57] Taking into account the long-term vision of Product-Led in their company. [11:17] The evolution of leadership at Metabase  [15:23] Metabase created an environment where people can open up their thoughts and feelings without worrying about judgment. [18:39] How do you build a high leverage team? [21:36] How can a person adapt to Metawork? [23:54] The most value starts after you do Metawork in the long term. [26:26] The importance of acknowledging how fast the market is changing. [28:08] Actionable recommendations on developing and implementing new leadership strategies. [28:13] Interaction between company culture and leadership. [28:56] Implementing completely bottom-up and very concrete practices. [31:35] How does Simon get into this business meditative state? [34:50] Don't think about solutions. Think about the problem harder. Create a hypothesis about the situation and provide solutions on how you can attest to the problem. [36:58] Start with introspection sessions. About Simon Belak During his time at Metabase, his time was split between data science, product leadership, and producing engineering work. Simon brings complex topics and simplifies them so people can understand them better. He is exceptionally customer-focused and helps you go beyond your boundaries by challenging your beliefs. Profile Simon's Twitter Simon's LinkedIn

About AnnaAnna has nearly ten years of experience researching and advising organizations on cloud adoption with a focus on security best practices. As a Gartner Analyst, Anna spent six years helping more than 500 enterprises with vulnerability management, security monitoring, and DevSecOps initiatives. Anna's research and talks have been used to transform organizations' IT strategies and her research agenda helped to shape markets. Anna is the Director of Thought Leadership at Sysdig, using her deep understanding of the security industry to help IT professionals succeed in their cloud-native journey.Anna holds a PhD in Materials Engineering from the University of Michigan, where she developed computational methods to study solar cells and rechargeable batteries.How do I adapt my security practices for the cloud-native world?How do I select and deploy appropriate tools and processes to address business needs?How do I make sense of new technology trends like threat deception, machine learning, and containers?Links: Sysdig: https://sysdig.com/ “2022 Cloud-Native Security and Usage Report”: https://sysdig.com/2022-cloud-native-security-and-usage-report/ Twitter: https://twitter.com/aabelak LinkedIn: https://www.linkedin.com/in/aabelak/ Email: anna.belak@sysdig.com TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: Today's episode is brought to you in part by our friends at MinIO the high-performance Kubernetes native object store that's built for the multi-cloud, creating a consistent data storage layer for your public cloud instances, your private cloud instances, and even your edge instances, depending upon what the heck you're defining those as, which depends probably on where you work. It's getting that unified is one of the greatest challenges facing developers and architects today. It requires S3 compatibility, enterprise-grade security and resiliency, the speed to run any workload, and the footprint to run anywhere, and that's exactly what MinIO offers. With superb read speeds in excess of 360 gigs and 100 megabyte binary that doesn't eat all the data you've gotten on the system, it's exactly what you've been looking for. Check it out today at min.io/download, and see for yourself. That's min.io/download, and be sure to tell them that I sent you.Corey: This episode is sponsored by our friends at Oracle HeatWave is a new high-performance query accelerator for the Oracle MySQL Database Service, although I insist on calling it “my squirrel.” While MySQL has long been the worlds most popular open source database, shifting from transacting to analytics required way too much overhead and, ya know, work. With HeatWave you can run your OLAP and OLTP—don't ask me to pronounce those acronyms again—workloads directly from your MySQL database and eliminate the time-consuming data movement and integration work, while also performing 1100X faster than Amazon Aurora and 2.5X faster than Amazon Redshift, at a third of the cost. My thanks again to Oracle Cloud for sponsoring this ridiculous nonsense.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. Once upon a time, I went to a conference talk at, basically, a user meetup. This was in the before times, when that wasn't quite as much of a deadly risk because of a pandemic, and mostly a deadly risk due to me shooting my mouth off when it wasn't particularly appreciated.At that talk, I wound up seeing a new open-source project that was presented to me, and it was called Sysdig. I wasn't quite sure on what it did at the time and I didn't know what it would be turning into, but here we are now, what is it, five years later. Well, it's turned into something rather interesting. This is a promoted episode brought to us by our friends at Sysdig and my guest today is their Director of Thought Leadership, Anna Belak. Anna, thank you for joining me.Anna: Hi, Corey. I'm very happy to be here. I'm a big fan.Corey: Oh, dear. So, let's start at the beginning. Well, we'll start with the title: Director of Thought Leadership. That is a lofty title, it sounds like you sit on the council of the Lords of Thought somewhere. Where does your job start and stop?Anna: I command the Council of the Lords of thought, actually. [laugh].Corey: Supply chain issues mean the robe wasn't available. I get it, I get it.Anna: There is a robe. I'm just not wearing it right now. So, the shortest way to describe the role is probably something that reports into engineering, interestingly, and it deals with product and marketing in a way that is half evangelism and half product strategy. I just didn't feel like being called any of those other things, so they were like, “Director of Thought Leadership you are.” And I was like, “That sounds awesome.”Corey: You know, it's one of those titles that people generally don't see a whole lot of, so if nothing else, I always liked those job titles that cause people to sit up and take notice as opposed to something that just people fall asleep by the time you get halfway through it because, in lieu of a promotion, people give you additional adjectives in your title. And we're going to go with it. So, before you wound up at Sysdig, you were at Gartner for a number of years.Anna: That's right, I spent about six years at Gartner, and there half the time I covered containers, Kubernetes, and DevOps from an infrastructure perspective, and half the time I spent covering security operations, actually, not specifically with respect to containers, or cloud, but broadly. And so my favorite thing is security operations, as it relates to containers and cloud-native workloads, which is kind of how I ended up here.Corey: I wouldn't call that my favorite thing. It's certainly something that is near and dear to the top of mind, but that's not because I like it, let's put it [laugh] that way. It's one of those areas where getting it wrong is catastrophic. Back in 2017, when I went to that meetup in San Francisco, Sysdig seemed really interesting to me because it looked like it tied together a whole bunch of different diagnostic tools, LSOF, strace, and the rest. Honestly—and I mean no slight to the folks who built out this particular tool—it felt like DTrace, only it understood the value of being accessible to its users without basically getting a doctorate in something.I like the idea, and it felt like it was very much aimed at an in-depth performance analysis story or an observability play. But today, it seems that you folks have instead gone in much more of a direction of DevSecOps, if the people listening to this, and you, will pardon the term. How did that happen? What was that product evolution like?Anna: Yeah, I think that's a fair assessment, actually. And again, no disrespect to DTrace of which I'm also a fan. So, we certainly started out in the container observability space, essentially because this whole Docker Kubernetes thing was exploding in popularity—I mean, before it was exploding, it was just kind of like, peaking out—and very quickly, our founder Loris, who is the co-founder of Wireshark, was like, “Hey, there's a visibility issue here. We can't see inside these things with the tools that we have that are built for host instrumentation, so I'm going to make a thing.” And he made a thing, and it was an awesome thing that was open-sourced.And then ultimately, what happened is, the ecosystem of containers and communities evolved, and more and more people started to adopt it. And so more people needed kind of a more, let's say, hefty, serious tool for observability, and then what followed was another tool for security because what we actually discovered was the data that we're able to collect from the system with Sysdig is incredibly useful for noticing security problems. So, that caused us to kind of expand into that space. And today we are very much a tool that still has an observability component that is quite popular, has a security component which is it's fairly broad: We cover CSPM use cases, we cover [CIEM 00:05:04] use cases, and we are very, kind of let's say, very strong and very serious about our detection response and runtime security use cases, which come from that pedigree of the original Sysdig as well.Corey: You can get a fairly accurate picture of what the future of technology looks like by taking a look at what my opinion of something is, and then doing the exact opposite of that. I was a big believer that virtualization, “Complete flash in the pan; who's going to use that?” Public cloud, “Are you out of your tree? No one's going to trust other companies with their holy of holies.” And I also spent a lot of time crapping on containers and not actually getting into them.Instead, I leapfrogged over into the serverless land, which I was a big fan of, which of course means that it's going to be doomed sooner or later. My security position has also somewhat followed similar tracks where, back when you're running virtual machines that tend to be persistent, you really have to care about security because you are running full-on systems that are persistent, and they run all kinds of different services simultaneously. Looking at Lambda Functions, for example, in the modern serverless world, I always find a lot of the tooling and services and offerings around security for that are a little overblown. They have a defined narrow input, they have a defined output, there usually aren't omnibus functions shoved in here where they have all kinds of different code paths. And it just doesn't have the same attack surface, so it often feels like it's trying to sell me something I don't need. Security in the container world is one of those areas I never had to deal with in anger, as a direct result. So, I have to ask, how bad is it?Anna: Well, I have some data to share with you, but I'll start by saying that I maybe was the opposite of you, so we'll see which one of us wins this one. I was an instant container fangirl from the minute I discovered them. But I crapped out—Corey: The industry shows you were right on that one. I think the jury [laugh] is pretty much in on this one.Anna: Oh, I will take it. But I did crap on Lambda Functions pretty hard. I was like, “Serverless? This is dumb. Like, how are we ever going to make that work?” So, it seems to be catching on a little bit, at least it. It does seem like serverless is playing the function of, like, the glue between bits, so that does actually make a lot of sense. In retrospect, I don't know that we're going to have—Corey: Well, it feels like it started off with a whole bunch of constraints around it, and over time, they've continued to relax those constraints. It used to be, “How do I package this?” It's, “Oh, simple. You just spent four days learning about all the ins and outs of this,” and now it's, “Oh, yeah. You just give it a Docker file?” “Oh. Well, that seems easier. I could have just been stubborn and waited.” Hindsight.Anna: Yeah, exactly. So, containers as they are today, I think are definitely much more usable than they were five-plus years ago. There are—again there's a lot of commercial support around these things, right? So, if you're, you know, like, a big enterprise client, then you don't really have time to fool around in open-source, you can go in, buy yourself a thing, and they'll come with support, and somebody will hold your hand as you figure it out, and it's actually quite, quite pleasant. Whether or not that has really gone mainstream or whether or not we've built out the entire operational ecosystem around it in a, let's say, safe and functional way remains to be seen. So, I'll share some data from our report, which is actually kind of the key thing I want to talk about.Corey: Yeah, I wanted to get into that. You wound up publishing this somewhat recently, and I regret that as of the time of this recording, I have not yet had time to go into it in-depth, and of course eviscerate it in my typical style on Twitter—although that may have been rectified by the time that this show airs, to be very clear—but it's the Sysdig “2022 Cloud-Native Security and Usage Report”.Anna: Please at me when you Twitter-shred it. [laugh].Corey: Oh, when I read through and screenshot it, and I'd make what observations that I imagine are witty. But I'm looking forward to it; I've done that periodically with the Flexera, “State of the Cloud” report for last few years, and every once in a while, whatever there's a, “We've done a piece of thought leadership, and written a report,” it's, “Oh, great. Let's make fun of it.” That's basically my default position on things. I am not a popular man, as you might imagine. But not having had the chance to go through it in-depth, what did this attempt to figure out when the study was built, and what did you learn that you found surprising?Anna: Yeah, so the first thing I want to point out because it's actually quite important is that this report is not a survey. This is actual data from our actual back end. So, we're a SaaS provider, we collect data for our customers, we completely anonymize it, and then we show in aggregate what in fact we see them doing or not doing. Because we think this is a pretty good indicator of what's actually happening versus asking people for their opinion, which is, you know, their opinion.Corey: Oh, I love that. My favorite lies that people tell are the lies they don't realize that they're telling. It's, I'll do an AWS bill analysis and, “Great. So, tell me about all these instances you have running over in Frankfurt.” “Oh, we don't have anything there.”I believe you're being sincere when you say this, however, the data does show otherwise, and yay, now we're in a security incident.Anna: Exactly.Corey: I'm a big believer of going to the actual source for things like this where it's possible.Anna: Exactly. So, I'll tell you my biggest takeaway from the whole thing probably was that I was surprised by the lack of… surprise. And I work in cloud-native security, so I'm kind of hoping every single day that people will start adopting these modern patterns of, like, discarding images, and deploying new ones when they found a vulnerability, and making ephemeral systems that don't run for a long time like a virtual machine in disguise, and so on. And it appears that that's just not really happening.Corey: Yeah, it's always been fun, more than a little entertaining, when I wind up taking a look at the aspirational plans that companies have. “Great, so when are you going to do”—“Oh, we're going to get to that after the next sprint.” “Cool.” And then I just set a reminder and I go back a year later, and, “How's that coming?” “Oh, yeah. We're going to get to that next sprint.”It's the big lie that we always tell ourselves that right after we finished this current project, then we're going to suddenly start doing smart things, making the right decisions, and the rest. Security, cost, and a few other things all tend to fall on the side of, you can spend infinite money and infinite time on these things, but it doesn't advance what your business is doing, but if you do none of those things, you don't really have a business anymore. So, it's always a challenge to get it prioritized by the strategic folks.Anna: Exactly. You're exactly right because what people ultimately do is they prioritize business needs, right? They are prioritizing whatever makes them money or creates the trinkets their selling faster or whatever it is, right? The interesting thing, though, is if you think about who our customers would be, like, who the people in this dataset are, they are all companies who are probably more or less born in the cloud or at least have some arm that is born in the cloud, and they are building software, right? So, they're not really just your average enterprises you might see in a Gartner client base which is more broad; they are software companies.And for software companies, delivering software faster is the most important thing, right, and then delivering secure software faster, should be the most important thing, but it's kind of like the other thing that we talk about and don't do. And that's actually what we found. We found that people do deliver software faster because of containers and cloud, but they don't necessarily deliver secure software faster because as is one of our data points, 75% of containers that run in production have critical or high vulnerabilities that have a patch available. So, they could have been fixed but they weren't fixed. And people ask why, right? And why, well because it's hard; because it takes time; because something else took priority; because I've accepted the risk. You know, lots of reasons why.Corey: One of the big challenges, I think, is that I can walk up and down the expo hall at the RSA Conference, which until somewhat recently, you were not allowed to present that or exhibit at unless you had the word ‘firewall' in your talk title, or wound up having certain amounts of FUD splattered across your banners at the show floor. It feels like there are 12 products—give or take—for sale there, but there are hundreds of booths because those products have different names, different messaging, and the rest, but it all feels like it distills down to basically the same general categories. And I can buy all of those things. And it costs an enormous pile of money, and at the end of it, it doesn't actually move the needle on what my business is doing. At least not in a positive direction, you know? We just set a giant pile of money on fire to make sure that we're secure.Well, great. Security is never an absolute, and on top of that, there's always the question of what are we trying to achieve as a business. As a goal—from a strategic perspective—security often looks a lot like, “Please let's not have a data breach that we have to report to people.” And ideally, if we have a lapse, we find out about it through a vector that is other than the front page of The New York Times. That feels like it's a challenging thing to get prioritized in a lot of these companies. And you have found in your report that there are significant challenges, of course, but also that some companies in some workloads are in fact getting it right.Anna: Right, exactly. So, I'm very much in line with your thinking about this RSA shopping spree, and the reality of that situation is that even if we were to assume that all of the products you bought at the RSA shopping center were the best of breed, the most amazing, fantastic, perfect in every way, you would still have to somehow build a program on top of them. You have to have a process, you have to have people who are bought into that process, who are skilled enough to execute on that process, and who are more or less in agreement with the people next door to them who are stuck using one of the 12 trinkets you bought, but not the one that you're using. So, I think that struggle persists into the cloud and may actually be worse in the cloud because now, not only are we having to create a processor on all these tools so that we can actually do something useful with them, but the platform in which we're operating is fundamentally different than what a lot of us learned on, right?So, the priorities in cloud are different; the way that infrastructure is built is a little different, like, you have to program a YAML file to make yourself an instance, and that's kind of not how we are used to doing it necessarily, right? So, there are lots of challenges in terms of skills gap, and then there's just this eternal challenge of, like, how do we put the right steps into place so that everybody who's involved doesn't have to suffer, right, and that the thing that comes out at the end is not garbage. So, our approach to it is to try to give people all the pieces they need within a certain scope, so again, we're talking about people developing software in a cloud-native world, we're focused kind of on containers and cloud workloads even though it's not necessarily containers. So that's, like, our sandbox, right? But whoever you are, right, the idea is that you need to look to the left—because we say ‘shift left'—but then you kind of have to follow that thread all the way to the right.And I actually think that the thing that people most often neglect is the thing on the right, right? They maybe check for compliance, you know, they check configurations, they check for vulnerabilities, they check, blah, blah, blah, all this checking and testing. They release their beautiful baby into the world, and they're like, okay, I wash my hands of it. It's fine. [laugh]. Right but—Corey: It has successfully been hurled over the fence. It is the best kind of problem, now: Someone else's.Anna: It's gone. Yeah. But it's someone else's—the attacker community, right, who are now, like, “Oh, delicious. A new target.” And like, that's the point at which the fun starts for a lot of those folks who are on the offensive side. So, if you don't have any way to manage that thing's security as it's running, you're kind of like missing the most important piece, right? [laugh].Corey: One of the challenges that I tend to see with a lot of programmatic analysis of this is that it doesn't necessarily take into account any of the context because it can't. If I have, for example, a containerized workload that's entire job is to take an image from S3, run some analysis or transformation on it then output the results of that to some data store, and that's all it's allowed to talk to you, it can't ever talk to the internet, having a system that starts shrieking about, “Ah, there's a vulnerability in one of the libraries that was used to build that container; fix it, fix it, fix it,” doesn't feel like it's necessarily something that adds significant value to what I do. I mean, I see this all the time with very purpose-built Lambda Functions that I have doing one thing and one thing only. “Ah, but one of the dependencies in the JSON processing library could turn into something horrifying.” “Yeah, except the only JSON it's dealing with is what DynamoDB returns. The only thing in there is what I've put in there.”That is not a realistic vector of things for me to defend against. The challenge then becomes when everything is screaming that it's an emergency when you know, due to context, that it's not, people just start ignoring everything, including the, “Oh, and by the way, the building is on fire,” as one of—like, on page five, that's just a small addendum there. How do you view that?Anna: The noise insecurity problem, I think, is ancient and forever. So, it was always bad, right, but in cloud—at least some containers—you would think it should be less bad, right, because if we actually followed these sort of cloud-native philosophy, of creating very purp—actually it's called the Unix philosophy from, like, I don't know, before I was born—creating things that are fairly purposeful, like, they do one thing—like you're saying—and then they disappear, then it's much easier to know what they're able to do, right, because they're only able to do what we've told them, they're able to do. So, if this thing is enabled to make one kind of network connection, like, I'm not really concerned about all the other network connections it could be making because it can't, right? So, that should make it easier for us to understand what the attack surface actually is. Unfortunately, it's fairly difficult to codify and productize the discovery of that, and the enrichment of the vulnerability information or the configuration information with that.That is something we are definitely focusing on as a vendor. There are other folks in the industry that are also working on this kind of thing. But you're exactly right, the prioritization of not just a vulnerability, but a vulnerability is a good example. Like, it's a vulnerability, right? Maybe it's a critical or maybe it's not.First of all, is it exposed to the outside world somehow? Like, can we actually talk to this system? Is it mitigated, right? Maybe there's some other controls in place that is mitigating that vulnerability. So, if you look at all this context, at the end of the day, the question isn't really, like, how many of these things can I ignore? The question is at the very least, which are the most important things that I actually can't ignore? So, like you're saying, like, the buildings on fire, I need to know, and if it's just, like, a smoldering situation, maybe that's not so bad. But I really need to know about the fire.Corey: This episode is sponsored in part by LaunchDarkly. Take a look at what it takes to get your code into production. I'm going to just guess that it's awful because it's always awful. No one loves their deployment process. What if launching new features didn't require you to do a full-on code and possibly infrastructure deploy? What if you could test on a small subset of users and then roll it back immediately if results aren't what you expect? LaunchDarkly does exactly this. To learn more, visit launchdarkly.com and tell them Corey sent you, and watch for the wince.Corey: It always becomes a challenge of prioritization, and that has been one of those things that I think, on some level, might almost cut against a tool that works at the level that Sysdig does. I mean, something that you found in your report, but I feel like, on some level, is one of those broadly known, or at least unconsciously understood things is, you can look into a lot of these tools that give incredibly insightful depth and explore all kinds of neat, far-future, bleeding edge, absolute front of the world, deep-dive security posture defenses, but then you have a bunch of open S3 buckets that have all of your company's database backups living in them. It feels like there's a lot of walk before you can run. And then that, on some level, leads to the wow, we can't even secure our S3 buckets; what's the point of doing anything beyond that? It's easy to, on some level, almost despair, want to give up, for some folks that I've spoken to. Do you find that is a common thing or am I just talking to people who are just sad all the time?Anna: I think a lot of security people are sad all the time. So, the despair is real, but I do think that we all end up in the same solution, right? The solution is defense in depth, the solution is layer control, so the reality is if you don't bother with the basic security hygiene of keeping your buckets closed, and like not giving admin access to every random person and thing, right? If you don't bother with those things, then, like, you're right, you could have all the tools in the world and you could have the most advanced tools in the world, and you're just kind of wasting your time and money.But the flipside of that is, people will always make mistakes, right? So, even if you are, quote-unquote, “Doing everything right,” we're all human, and things happen, and somebody will leave a bucket open on accident, or somebody will misconfigure some server somewhere, allowing it to make a connection it shouldn't, right? And so if you actually have built out a full pipeline that covers you from end-to-end, both pre-deployment, and at runtime, and for vulnerabilities, and misconfigurations, and for all of these things, then you kind of have checks along the way so that this problem doesn't make it too far. And if it does make it too far and somebody actually does try to exploit you, you will at least see that attack before they've ruined everything completely.Corey: One thing I think Sysdig gets very right that I wish this was not worthy of commenting on, but of course, we live in the worst timeline, so of course it is, is that when I pull up the website, it does not market itself through the whole fear, uncertainty, and doubt nonsense. It doesn't have the scary pictures of, “Do you know what's happening in your environment right now?” Or the terrifying statistics that show that we're all about to die and whatnot. Instead, it talks about the value that it offers its customers. For example, I believe its opening story is, “Run with confidence.” Like, great, you actually have some reassurance that it is not as bad as it could be. That is, on the one hand, a very uplifting message and two, super rare. Why is it that so much of the security industry resorts to just some of the absolute worst storytelling tactics in order to drive sales?Anna: That is a huge compliment, Corey, and thank you. We try very hard to be kind of cool in our marketing.Corey: It shows. I'm tired of the 1990s era story of, “Do you know where the hackers are?” And of course, someone's wearing, like, a ski mask and typing with gloves on—which is always how I break into things; I don't know about you—but all right, we have the scary clip art of the hacker person, and it just doesn't go anywhere positive.Anna: Yeah. I mean, I think there certainly was a trend for a while have this FUD approach. And it's still prevalent in the industry, in some circles more than others. But at the end of the day, Cloud is hard and security is hard, and we don't really want to add to the suffering; we would like to add to the solution, right? So, I don't think people don't know that security is hard and that hackers are out there.And you know, there's, like, ransomware on the news every single day. It's not exactly difficult to tell that there's a challenge there, so for us to have to go and, like, exacerbate this fear is almost condescending, I feel, which is kind of why we don't. Like, we know people have problems, and they know that they need to solve them. I think the challenge really is just making sure that A) can folks know where to start and how to build a sane roadmap for themselves? Because there are many, many, many things to work on, right?We were talking about context before, right? Like, so we actually try to gather this context and help people. You made a comment about how having a lot of telemetry might actually be a little bit counterproductive because, like, there's too much data, what do I do well—Corey: Here's the 8000 findings we found that you fail—great. Yeah. Congratulations, you're effectively the Nessus report as a company. Great. Here you go.Anna: Everything is over.Corey: Yeah.Anna: Well, no shit, Nessus, you know. Nessus did its thing. All right. [laugh].Corey: Oh, Nessus was fantastic. Nessus was—for those who are unaware, Nessus was an open-source scanner made by the folks at Tenable, and what was great about it was that you could run it against an environment, it would spit out all the things that it found. Now, one of the challenges, of course, is that you could white-label this and slap whatever logo you wanted on the top, and there were a lot of ‘security consultancies' that use the term incredibly… lightly, that would just run a Nessus report, drop off the thick print out. “Here's the 800 things you need to fix. Pay me.” And wander on off into the sunset.And when you have 800 things you need to fix, you fix none of them. And they would just sit there and atrophy on the shelf. Not to say that all those things weren't valid findings, but you know, the whole, you're using an esoteric, slightly deprecated TLS algorithm on one of your back-end services, versus your Elasticsearch database does not have a password set. Like, there are different levels of concern here. And that is the problem.Anna: Yeah. That is in fact one of the problems we're aggressively trying to solve, right? So, because we see so much of the data, we're actually able to piece together a lot of context to gives you a sense of risk, right? So, instead of showing all the data to the customer—the customer can see it if they want; like, it's all in there, you can look at it—one of the things we're really trying to do is collect enough information about the finding or the event or the vulnerability or whatever, so we can kind of tell you what to do.For example, one you can do this is super basic, but if you're looking at a specific vulnerability, like, let's say it's like Log4j or whatever, you type it in, and you can see all your systems affected by this thing, right? Then you can, in the same tool, like, click to the other tab, and you can see events associated with this vulnerability. So, if you can see the systems that the vulnerability is on and you can see there's weird activity on those systems, right? So, if you're trying to triage some weird thing in your environment, during the Log4j disaster, it's very easy for you to be like, “Huh. Okay, these are the relevant systems. This is the vulnerability. Like, here's all that I know about this stuff.”So, we kind of try to simplify as much as possible—my design team uses the word ‘easify,' which I love; it's a great word—to easify, the experience of the end-user so that they can get to whatever it is they're trying to do today. Like, what can I do today to make my company more secure as quickly as possible? So, that is sort of our goal. And all this huge wealth of information we gather, we try to package for the users in a way that is, in fact, digestible. And not just like, “Here's a deluge of suffering,” like, “Look.” [laugh]. You know?Corey: This is definitely complicated in the environment I tend to operate in which is almost purely AWS. How much more complex is get when people start looking into the multi-cloud story, or hybrid environments where they have data center is talking to things within AWS? Because then it's not just the expanded footprint, but the entire security model works slightly differently in all of those different environments as well, and it feels like that is not a terrific strategy.Anna: Yeah, this is tough. My feelings on multi-cloud are mostly negative, actually.Corey: Oh, thank goodness. It's not just me.Anna: I was going to say that, like, multi-cloud is not a strategy; it's just something that happens to you.Corey: Same with hybrid. No one plans to do hybrid. They start doing a cloud migration, realize halfway through some things are really hard to move, give up, plant the flag, declare victory, and now it's called hybrid.Anna: Basically. But my position—and again, as an analyst, you kind of, I think, end up in this position, you just have a lot of sympathy for the poor people who are just trying to get these stupid systems to run. And so I kind of understand that, like, nothing's ideal, and we're just going to have to work with it. So multi-cloud, I think is one of those things where it's not really ideal, we just have to work with it. There's certainly advantages to it, like, there's presumably some level of mythical redundancy or whatever. I don't know.But the reality is that if you're trying to secure a pile of junk in Azure and a pile of junk in AWS, like, it'd be nice if you had, like, one tool that told you what to do with both piles of junk, and sometimes we do do that. And in fact, it's very difficult to do that if you're not a third-party tool because if you're AWS, you don't have much incentive to, like, tell people how to secure Azure, right? So, any tool in the category of, like, third-party CSPM—Gartner calls them CWPP—kind of, cloud security is attempting to span those clouds because they always have to be relevant, otherwise, like, what's the point, right?Corey: Well, I would argue cynically there's also the VC model, where, “Oh, great. If we cover multiple cloud providers, that doubles or triples our potential addressable market.” And, okay, great, I don't have those constraints, which is why I tend to focus on one cloud provider where I tend to see the problems I know how to solve as opposed to trying to conquer the world. I guess I have my bias on that one.Anna: Fair. But there's—I think the barrier to entry is lower as a security vendor, right? Especially if you're doing things like CSPMs. Take an example. So, if you're looking at compliance requirements, right, if your team understands, like, what it means to be compliant with PCI, you know, like, [line three 00:28:14] or whatever, you can apply that to Azure and Amazon fairly trivially, and be like, “Okay, well, here's how I check in Azure, and here's how I check in Amazon,” right?So, it's not very difficult to, I think, engineer that once you understand the basic premise of what you're trying to accomplish. It does become complicated as you're trying to deal with more and more different cloud services. Again, if you're kind of trying to be a cloud security company, you almost have no choice. Like, you have to either say, “I'm only doing this for AWS,” which is kind of a weird thing to do because they're kind of doing their own half-baked thing already, or I have to do this for everybody. And so most default to doing it for everybody.Whether they do it equally well, for everybody, I don't know. From our perspective, like, there's clearly a roadmap, so we have done one of them first and then one of them second and one of the third, and so I guarantee you that we're better in some than others. So, I think you're going to have pluses and minuses no matter what you do, but ultimately what you're looking for is coverage of the tool's capabilities, and whether or not you have a program that is going to leverage that tool, right? And then you can check the boxes of like, “Okay. Does it do the AWS thing? Does it do this other AWS thing? Does it do this Azure thing?”Corey: I really appreciate your taking the time out of your day to speak with me. We're going to throw a link to the report itself in the [show notes 00:29:23], but other than that, if people want to learn more about how you view these things, where's the best place to find you?Anna: I am—rarely—but on Twitter at @aabelak. I am also on LinkedIn like everybody else, and in the worst case, you could find me by email, at anna.belak@sysdig.com.Corey: And we will of course put links to that in the [show notes 00:29:44]. Thank you so much for taking the time to speak with me today. I appreciate it.Anna: Thanks for having me, Corey. It's been fun.Corey: Anna Belak, Director of Thought Leadership at Sysdig. I'm Cloud Economist Corey Quinn and this is streaming on the cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice, along with an angry comment telling me not only why this entire approach to security is awful and doomed to fail, but also what booth number I can find you at this year's RSA Conference.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.Announcer: This has been a HumblePod production. Stay humble.

Anna Belak learned about containers and security as a Gartner industry analyst. She is now the Director of Thought Leadership at Sysdig, who have just published their latest annual Cloud Native Security and Usage Report. Anna joins Craig to dicuss the report’s findings. Do you have something cool to share? Some questions? Let us know: web: kubernetespodcast.com mail: kubernetespodcast@google.com twitter: @kubernetespod News of the week Chaos Mesh moves to Incubation in CNCF Episode 121, with Ed Huang Google raises payouts for Kubernetes vulnerabilities 2021 VRP roundup Sysdig teams up with Snyk, Snyk teams up with Sysdig $25m investment in KubeCost Episode 124, with Webb Brown Links from the interview Sysdig Cloud Native Security and Usage Report 2022 The last time we had a materials engineer on the show Tricking a rock into thinking Why Software is Eating The World Can analysis be worthwhile? Is the theater really dead? Industry analysts Anna Belak at Gartner Doge. Much wow Sysdig $2.5 billion valuation Beginnings Source code Episode 91, with Leonardo Di Donato Tectonic Summit, 2015 Loris Degioanni Episode 137, with Michael Gerstenhaber Sysdig’s changing reports: 2017 2018 2019 2020 2021 GKE Autopilot Are we human, or are we dancer? Anna Belak on Twitter

Danes je moj rojstni dan. Mlada sem 34 let in v to posebno edicijo našega podcasta sem povabila gosta, s katerim sem v letu 2022 preživela največ časa. Ponovno je z nami vsespološno razgledan podatkovni znanstvenik Simon Belak, s katerim sva ta mesec okronala prvo kohorto za storitvene dejavnosti, zdaj pa že pridno delava na ediciji kohorte za produkte. Na Instragramu sva zbrala tudi nekaj vaših vprašanj, ki jih v epizodi obdelava, tako da na primeren način proslavimo to naše prijetno druženje. Nova kohorta: https://growthlabacademy.thinkific.com/courses/live-masterclass-with-simon-belak-and-maja-voje-product-scaling-cohort --- Obišči nas na družbenih omrežjih: Instagram: https://www.instagram.com/reneseansa_podcast/ Facebook: https://www.facebook.com/Reneseansa/ Poveži se z Majo: https://majavoje.com/

Kako s svojim znanjem ustvarimo 6- ali 7-mestni svetovalni posel, ki prinaša dodano vrednost podjetjem po celem svetu? Znova je z nami ekscelenca podatkovne znanosti v Sloveniji, soustanovitelj skupine Growth Hacking Slovenia in gledališki režiser Simon Belak. S Simonom sva letos staknila glave in pripravila nekaj čisto posebnega … o tem projektu boste prvič izvedeli prav v tem podcastu. Povezave: Masterclass s Simonom in Majo: https://bit.ly/3G1qrOi https://www.linkedin.com/in/simonbelak/ https://twitter.com/sbelak https://www.facebook.com/groups/1870456883232512/ https://anchor.fm/reneseansa/episodes/Simon-Belak-Mad-Scientist-eemnsi https://www.linkedin.com/in/majavoje/

V epizodi #66 je bil moj gost Simon Belak, strokovnjak ter akter na področjih informacijske tehnologije, filozofije in gledališča. Dotakneva se tematik, kot so: Interdisciplinarnost in ustvarjanje Altruizem kot gonilo Nalaganje spretnosti in znanj Nasvet za prve korake v karieri Pozicioniranje na trgu za mlade Poraba časovnega kapitala Pot proti cilju in stanje flowa Produktivnost in prokrastinacija Dualizem Jezik in tehnologija Umetna inteligenca v 21. stoletju Resolucija ============================= Pridruži se kot podpornik kanala AIDEA

Ron Belak is an avid backcountry fisherman and author of several books and many articles. His first book, Fly Fishing Colorado's Backcountry, details how to effectively fish Colorado’s remote alpine lakes and streams. His second book, published in April of 2021, is called The Fishing Guide to 800 High Lakes in Colorado, and discusses 800 lakes in the state that Ron and other anglers have personally fished. He has also published around 80 articles in the Colorado Outdoors magazine. In this episode, we discuss backcountry alpine lakes specifically. Ron details his motivations for getting off the beaten path, the gear he brings for day trips and overnight trips, fly selection, seasonal changes, finding good fishing spots, and much more!   Website:  www.ronbelak.com Fly Fishing Colorado's Backcountry The Fishing Guide to 800 High Lakes in Colorado

Pred dnevi je umrla dramska igralka Ljerka Belak. Po študiju na ljubljanski igralski akademiji je dolgo nastopala v Slovenskem ljudskem gledališču v Celju, pozneje tudi v Mestnem gledališču ljubljanskem. V naklonjen spomin gledalcev se je zapisala tudi s televizijskimi in filmskimi vlogami. Njena posebna ljubezen pa je bil radio. Bila je voditeljica radijskih oddaj pa tudi senzibilna interpretka literarnih besedil. V oddaji Naši umetniki pred mikrofonom bomo ponovili pogovor, ki ga je leta 2015 - takrat je Ljerka Belak prejela Borštnikov prstan - z igralko posnela Tadeja Krečič. Foto: MMC RTV SLO/Ksenja Tratnik

Izhodišče oddajePogovor o je bilo geslo letošnjega Tedna Karitas »Slišim te«. Zgosti smo skušali odgovoriti na vprašanje, kako slišati ljudi izranljivih skupin. Osredotočili smo se na osebe s težavami vduševnem zdravju, starejše in dolgotrajno brezposelne. O tem sogovorili Edo P. Belak, Marija Puc in Saraja Špec. Kaj pomeniposlušati, pa nam je povedala psihologinja in mediatorka ŠpelaTušek.

Standing at 6 foot 7 in the NHL, Chris McAllister was a giant among regular folk. Chris played 8 seasons in the NHL and took on some of the leagues toughest customers at the time.With fights against guys such as Parker, Kocur, Belak, Oliwa and many many more. Don't get me started on how tough of a team he had in junior with the Blades either. Hear what it was like fighting these big boys and the life of an NHL enforcer!

Simon Belak je "mad scientist" pri ameriškem podjetju Metabase, ki razvija istoimensko orodje za pregledovanje, analizo in vizualizacijo podatkov. Je digitalni nomad in nekdanji CTO pri podjetju GoOpti. Nepogrešljivo prispeva k spletnim skupnostim, kot sta Growth Hacking Slovenia in Slovenski developerji, v prostem času pa se ukvarja z gorskim kolesarstvom. V podkastu boste izvedeli: Kaj dela mad scientist na Metabaseu Kaj žene Simona, da prispeva k odprtokodnim rešitvam O urejenosti podatkov pri data-driven podjetjih O ciljih podatkovne strategije podjetij Katere metrike bi moralo spremljati prav vsako podjetje (pa jih ne)? Kako začeti kariero v podatkovni znanosti? O remotu delu, ki ga je Metabase gojil že pred pandemijo koronavirusa O avtomatizaciji dela za večjo produktivnost Zakaj ima na kolesarjenju ob sebi vedno beležko Povezave: Simon Belak na LinkedInu Simon Belak na Twitterju Simonove prezentacije na SlideShare Metabase Simonova bralna priporočila: Borges: Labyrinths in Aleph The Origin of Consciousness in the Breakdown of the Bicameral Mind Gödel, Escher, Bach: An Eternal Golden Braid

The party fights through the Twilight Grove and confronts the Outcaste, Belak. They recover the apple from the Gulthias Tree and exit the Sunless Citadel with survivors, Sharwyn and Sir Braford.

Former NHL Forward Cam Janssen joins First Up with Michael and his former teammate Carlo Colaiacovo to discuss his time in the league, playing with Carlo, his fight with Wade Belak and more.

Knight Dental Group has been around for a long time. It only makes sense that if you have a symposium in Florida that most of the attendees will have some connection with Knight Dental. Barb was able to get 4 associates (current and past) to sit down and chat. -Sharon Belak who is a LONG-time employee who talks about how she got started there and the competitiveness to be successful. -Dan LaRock talks about going from the Air Force to Knight Dental to his current position at DSG. -Mirza Hadzijusufovic goes from a weapons designer in Bosnia to a CAD dental designer at Knight -John Bosker worked with Barb when she was a innocent little kid (hard to imagine). John now runs his own lab Marquis Dental Laboratories. http://dentallabfoundation.org/wp-content/uploads/2018/12/RFF-6.0-Logo-1.jpg Support the Foundation For Dental Laboratory Technology (http://dentallabfoundation.org/) by supporting the Race For the Future 6.0 (http://dentallabfoundation.org/news-events/race-future-6-0/). Order a VFTB Special Edition shirt and all profits will go toward this wonderful event to raise money for education within our industry. https://www.bonfire.com/voices-from-the-benchrace-for-the-future-60/ We also dare all to participate in this year’s triathlon August 24 - 25, 2019 in Chicago. https://www.chicagotriathlon.com/ Special Guests: Dan LaRock, John Bosker, Mirza Hadzijusufovic, and Sharon Belak.

Show Notes Metabase (https://www.metabase.com/) Matic Jurglič (https://www.parallelpassion.com/18) Tribuna (https://tribuna.si/) Everything is a Remix (https://www.everythingisaremix.info/) Dunbar's number (https://en.wikipedia.org/wiki/Dunbar%27s_number) Decision fatigue (https://en.wikipedia.org/wiki/Decision_fatigue) Wikiloc (https://www.wikiloc.com/) Lego Technic (https://en.wikipedia.org/wiki/Lego_Technic) Recommendations Lisp, Smalltalk, and the Power of Symmetry (https://insearchofsecrets.com/2014/08/04/lisp-smalltalk-and-the-power-of-symmetry/) Learnable programming (http://worrydream.com/LearnableProgramming/) The Future of Programming (http://worrydream.com/dbx/) A Conversation with Alan Kay (https://www.doc.ic.ac.uk/~susan/475/AlanKay.html) Interview with Alan Kay (http://www.drdobbs.com/architecture-and-design/interview-with-alan-kay/240003442) Dan Ingalls on the History of Smalltalk and the Lively Kernel (https://www.infoq.com/interviews/ingalls-smalltalk) IT’s Dirty Little Secret (https://medium.com/morning-light/its-dirty-little-secret-32940b894b24) Simon Belak Twitter (https://twitter.com/sbelak) Instagram (https://instagram.com/sbelak) Parallel Passion Patreon (https://www.patreon.com/parpaspod) Twitter (https://www.twitter.com/parpaspod) Instagram (https://www.instagram.com/parpaspod) Facebook (https://www.facebook.com/parpaspod) Credits Danny Halarewich (https://unsplash.com/@dhalarewich) for the header photo Tina Tavčar (https://twitter.com/tinatavcar) for Parallel Passion logo Jan Jenko (https://twitter.com/JanJenko) for intro/outro music

Our heroes finally face the true evil in the undreground citadel. Will the be able to defeat this evil. Or will it overcome them and destroy Sharwin, Sir Bradford and perhaps even Geth? tune in to find out! Folks as with any podcast theres always sound quality issues ep8 has a tremendous amount of them please be patient as we are trying the best we can with what we have. please remember if you would like to support us check us out on Pateron, Twitch, YouTube  and iTunes. Thanks again for all your Support. All sounds are creative commmoms 0 or 3.0 License or Non Commerical. All music is by Kevin MacLeod (incompetech.com)Licensed under Creative Commons: By Attribution 3.0 Licensehttp://creativecommons.org/licenses/by/3.0/  

The ladies set off for the Singing Sands, on the trail of Belak's lost love, and member of the Seven Joys.    Hail the Void is a roleplay podcast where we'll follow a core campaign in the Dungeons and Dragons 5E universe, with occasional drifts into other narratives as we explore the vast array of roleplay systems there are out there, as well as a few of our own! We'll also feature talking-head style sessions, where we talk about our experiences with roleplay, what roleplay means to us, and how it has effected our lives. If you have a comment, idea for a magical item our heroes might encounter, a roleplay system you would like to see featured, or a story of your own roleplay experience you would like to share with the world, here's how you can contact us! Facebook Twitter Instagram Email: hailthevoidpod@gmail.com T-Shirts are available at: store.hailthevoid.com Want to help support the show? You can contribute at Patreon.com/hailthevoid! Every bit of coin helps us with hosting costs and equipment upgrades. If you have not the coin to spend, you can help us out a ton by subscribing, rating and sharing our show from your favorite podcasting platform. Let you friends know how much you like the show! Our theme song is comprised of Andalusian Ground by Batholomew Faire (used with permission, support them by buying their CD's here: https://store.cdbaby.com/Artist/BartholomewFaire), and Hail the Void by Jeremy Cooney. All rights reserved.   This episode also included the following music: Moorland - Kevin MacLeod (incompetech.com) Licensed under Creative Commons: By Attribution 3.0 License http://creativecommons.org/licenses/by/3.0/    Magic Forest - Kevin MacLeod (incompetech.com) Licensed under Creative Commons: By Attribution 3.0 License http://creativecommons.org/licenses/by/3.0/    Desert City - Kevin MacLeod (incompetech.com) Licensed under Creative Commons: By Attribution 3.0 License http://creativecommons.org/licenses/by/3.0/    Also soundscapes created by Sword Coast Soundscapes! Support them over at their Bandcamp page.   Enjoy the show, and as always, Hail the Void.   

The fantastical finale of our first chapter. The Fellows face off against Belak as they near the end of their rescue mission. Twitter / Facebook / Email / Swansea Fringe Festival

In the garden galleries of Belak's subterranean laboratory, the Fellows find themselves trapped between a nesting fire snake and the head gardener. This episode is not sponsored by Wyevale (the biggest garden centre retailer in the UK). Twitter / Facebook / Email / Swansea Fringe Festival

On today's episode, the gang faces off with Belak, and Tumaini has reservations about who the good guys and bad guys are.   Hail the Void is a roleplay podcast where we'll follow a core campaign in the Dungeons and Dragons 5E universe, with occasional drifts into other narratives as we explore the vast array of roleplay systems there are out there, as well as a few of our own! We'll also feature talking-head style sessions, where we talk about our experiences with roleplay, what roleplay means to us, and how it has effected our lives. If you have a comment, idea for a magical item our heros might encounter, a roleplay system you would like to see featured, or a story of your own roleplay experience you would like to share with the world, here's how you can contact us! Facebook: facebook.com/hailthevoid Twitter: @hailthevoidpod Email: hailthevoidpod@gmail.com T-Shirts are available at: store.hailthevoid.com Want to help support the show? You can contribute at Patreon.com/hailthevoid! Every bit of coin helps us with hosting costs and equipment upgrades. If you have not the coin to spend, you can help us out a ton by subscribing, rating and sharing our show from your favorite podcasting platform. Let you friends know how much you like the show! Our theme song is comprised of Andalusian Ground by Batholomew Faire (used with permission, support them by buying their CD's here: https://store.cdbaby.com/Artist/BartholomewFaire), and Hail the Void by Jeremy Cooney. All rights reserved.  This episode also included the following music:   Ossuary 6 - Air Kevin MacLeod (incompetech.com) Licensed under Creative Commons: By Attribution 3.0 License http://creativecommons.org/licenses/by/3.0/   "Dragon and Toast" Kevin MacLeod (incompetech.com) Licensed under Creative Commons: By Attribution 3.0 License http://creativecommons.org/licenses/by/3.0/   "The Seven Joys" Bartholomew Faire Used with Permission, from the album "The Red Book" https://store.cdbaby.com/Artist/BartholomewFaire     Enjoy the show, and as always, Hail the Void. 

On this weeks episode, the gang makes their way through the Grove proper, and gets their first glimpse of their quarry, Belak the druid.  Hail the Void is a roleplay podcast where we'll follow a core campaign in the Dungeons and Dragons 5E universe, with occasional drifts into other narratives as we explore the vast array of roleplay systems there are out there, as well as a few of our own! We'll also feature talking-head style sessions, where we talk about our experiences with roleplay, what roleplay means to us, and how it has effected our lives. If you have a comment, idea for a magical item our heros might encounter, a roleplay system you would like to see featured, or a story of your own roleplay experience you would like to share with the world, here's how you can contact us! Facebook: facebook.com/hailthevoid Twitter: @hailthevoidpod Email: hailthevoidpod@gmail.com T-Shirts are available at: store.hailthevoid.com Want to help support the show? You can contribute at Patreon.com/hailthevoid! Every bit of coin helps us with hosting costs and equipment upgrades. If you have not the coin to spend, you can help us out a ton by subscribing, rating and sharing our show from your favorite podcasting platform. Let you friends know how much you like the show! Our theme song is comprised of Andalusian Ground by Batholomew Faire (used with permission, support them by buying their CD's here: https://store.cdbaby.com/Artist/BartholomewFaire), and Hail the Void by Jeremy Cooney. All rights reserved.   This episode also included the following music:  Galgook - Air Kevin MacLeod (incompetech.com) Licensed under Creative Commons: By Attribution 3.0 License http://creativecommons.org/licenses/by/3.0/   Exotic Battle Kevin MacLeod (incompetech.com) Licensed under Creative Commons: By Attribution 3.0 License http://creativecommons.org/licenses/by/3.0/     Enjoy the show, and as always, Hail the Void.

The group returns to the Sunless Citadel to end Belak’s reign of twiggy terror. Season 4 is played using Dungeons & Dragons Fifth Edition.

Violence and conflict is a common thread that runs throughout history and across all cultures. It disrupts local, national and international communities, and results in war, displacement and death. One strategy to addressing violence and conflict is through a public health approach. The Violence Prevention and Restoration (PAR) Model, developed by the International Center for Compassionate Organizations (ICCO) explains how violence begins, spreads, and infects others much like a thought borne pathogen or virus. This KNOW NOW program featured Ari Cowan and Tony Belak, Director General and Associate Director of ICCO, who discussed how the proliferation of international conflicts and violence in communities can be prevented by utilizing the PAR Model. Xiao Yin Zhao, Executive Director of the World Affairs Council of Kentucky and Southen Indiana, hosted this call.

On this weeks episode, the gang explores Oakhurst amidst the setup for the Midsummer Festivities, Rook meets a merchant who's children's fate is entwined with his own, and mom's character meets the group! Hail the Void is a roleplay podcast where we'll follow a core campaign in the Dungeons and Dragons 5E universe, with occasional drifts into other narratives as we explore the vast array of roleplay systems there are out there, as well as a few of our own! We'll also feature talking-head style sessions, where we talk about our experiences with roleplay, what roleplay means to us, and how it has effected our lives. If you have a comment, idea for a magical item our heros might encounter, a roleplay system you would like to see featured, or a story of your own roleplay experience you would like to share with the world, here's how you can contact us! Facebook: facebook.com/hailthevoid Twitter: @hailthevoidpod Email: hailthevoidpod@gmail.com Our theme song is comprised of Andalusian Ground by Batholomew Faire (used with permission, support them by buying their CD's here: https://store.cdbaby.com/Artist/BartholomewFaire), and Hail the Void by Jeremy Cooney. All rights reserved. This episode also included the following music: Suonatore di Liuto Kevin MacLeod (incompetech.com) Licensed under Creative Commons: By Attribution 3.0 License http://creativecommons.org/licenses/by/3.0/   Heavy Heart Kevin MacLeod (incompetech.com) Licensed under Creative Commons: By Attribution 3.0 License http://creativecommons.org/licenses/by/3.0/   Enjoy the show, and as always, Hail the Void. 

Pravljico Mravljinček potepinček pripoveduje Ljerka Belak, priljubljena dramska igralka, na klavirju pa jo spremlja Blaž Jurjevčič. Napisala jo je Damjana Kenda Hussu, ilustriral Marko Rop. Pravljica je bila ustvarjena v sodelovanju z oddajo Lahko noč, otroci! v produkciji Radia Slovenija z režiserko Špelo Kravogel in urednico oddaje Aljo Verbole. Prisluhnite Lahkonočnicam, sodobnim zvočnim pravljicam sodobnih slovenskih avtorjev na www.lahkonocnice.si.

On this episode we will discuss Star Trek at the movies, how has Star Trek changed since the first movie in1979 to today, and a Star Trek Discovery update. This week on Star Trek History will cover "A Taste of Armageddon", fan favorite. "Yesterday's Enterprise" and "Doctor Bashir, I Presume". Gm Chris will wrap up the show with a review of the Romulan Blind Booster, IRW Belak, on his segment, Star Trek Attack Wing - Ships of the Line. Phone lines will be open (646)668-2433, and, we would love to hear from you. QAPLA'

Belak Industries is a wheel manufacturer based out of Miami, FL focused primarily on Honda drag racing. Damian Borroto established Belak Industries in 2012 after a decade working in multiple Honda speed shops in the Miami area, and eventually opening his own shop, TD Autowerkes. Damian has a “can-do, make-it-happen attitude” and he survived some serious setbacks in the last year. In 2014 he had his race car and trailer stolen, only to get pieces of it back. So he set out to build another car, and did! But on it’s first outing, a freak accident caused it to wreck, and total the chassis. Now he’s on to building his third SFWD race car and he hasn’t even considered giving up! Game Changing Product: ID1700, Belak Wheels, AEM Infinity, FTW Fuel Most useful software program: Windows Favorite App: Pandora, WhatsApp, Instagram   Favorite Shop Tool: Hammer!... and his Dyno

In this week's episode of Arena Radio, we discuss...- Blue Jackets Gone Mad- Jagr's Butt- Belak's Depression- Byfuglien's Eating Disorder- Shanahan Shenanigans- Joe Nieuwendyk For President- Dill Pickle Chips... again- Ashtin's Professional Career- and of course... Sir Mixalot!... and much, much more.Don't you dare miss it!

As the season approaches we flip up the format a little for this episode as we start chatting about the Sharks as the teams heads into their first pre-season game of the 2011/2012 season. Then we take a look around the rest of the NHL. We close by touching upon the tragedies that have happening in the hockey world since our last podcast.

Tom Callahan talks with Preds forward Wade Belak