The challenge is that all of these individual logs by themselves
can often be, you know, just typical cloud operations.
But if you can add some kind of logic on top of it, where
it's looking at, okay, now this is atypical, you know, list
S3 bucket, that's a normal call, but a hundred of them?
Welcome to Screaming in the Cloud.
I'm Corey Quinn.
This promoted guest episode is brought to us by our
friends at Sysdig, where Maya Levine is a product manager.
Maya, thank you for joining me.
Thanks so much for having me, Corey.
Sysdig secures cloud innovation with the power of runtime insights.
From prevention to defense, Sysdig prioritizes the risks that matter most.
Secure Every Second with Sysdig.
Learn more at Sysdig, S-Y-S-D-I-G, dot-com.
Our thanks as well to Sysdig for sponsoring this ridiculous podcast.
So, let's start at the very top.
Product management means an awful lot of
things to an awful lot of different companies.
Where do you start and stop?
For me, product management is all about understanding what are your pain points.
When I'm thinking of customers, what is hard for them?
What are the problems that they really need help solving?
And obviously, Sysig is looking at that from
a cloud and container security point of view.
And what have you found?
What is the painful part about, I guess,
cloud security other than to be unflattering?
All of it.
Yeah, I was gonna say, where do I start?
Yeah, it's like, it seems like a target rich environment.
There's a lot of challenges.
One thing that has come up a lot in this past year is just
how quickly attackers are able to execute their attacks.
And we found that the average cloud attack takes about 10 minutes.
And when we think about that, it becomes painfully obvious
that we need some kind of cloud detection and response or CDR
as uh, You know, this industry is so fond of their acronyms.
We do love our acronyms dearly.
It's some of the things we won't get away from.
Yes, too many.
Do you find the speed of attack increasing is in part, I
guess, due to the fact that it is cloud, where there's a
consistent set of standards of how things are deployed?
If you have an S3 bucket, getting access to that looks an awful
lot the same as getting access to another company's S3 bucket.
Whereas back in the days of data centers, where everyone runs their
own bespoke little unicorn, it took a lot more time and was less.
Automation friendly, I guess, is probably the best way to frame that?
Or do you think there's something else to it?
Uh, at first, maybe we saw that cloud attacks were harder for attackers
because the complexity of cloud systems, I think, is harder to understand.
But what we've seen in recent times is that attackers are becoming
more well versed in cloud native technologies, and they're embracing
the same things that we are when we are adopting cloud, right?
Ease of deployment and automation services and all of those things
are being utilized and utilized well in different cloud breaches.
What I find interesting in the, some of the areas that you personally
have been focusing on has been around the idea of identity.
One of my frequent talking points that I trot out from time to time
is that the internet long ago took a collective vote and decided
that our email inboxes were the cornerstone of our online identities.
Get access to someone's inbox and for most
purposes you can become them on the internet.
How has that manifested in, like, a more
infrastructure centric way when it comes to cloud?
Because an awful lot of folks are talking about identity these days.
How does that, what is the, I guess, the impact of that on CDR, as you put it?
The impact is that credentials are usually, what we're
seeing is the initial access point for attackers.
And I think that we can't always control how
attackers make their way into our environment.
Where CDR is helpful.
is that we can be notified once they're in
there, um, and, you know, respond effectively.
But going back to the identities and the credentials, I
always like to make the analogy of a key left under the mat.
If I'm a robber and I'm, you know, scoping out homes, That's the first place
I'm going to look is these known places where people are leaving their keys.
And when it comes to secrets harvesting, attackers know where to look.
And this can be things like serverless function code, IAC software.
These files often contain credentials.
Or secrets or other sensitive information, and they're often overlooked.
There's a, yeah, but I found a number of things doing suspicious work, some of
which in production products, which is never terrific, where they would just
scan the local environment of your dev environment and find any credentials
that were being used to access AWS in this case, and then just silently
send them up to the company server so they could take action on your behalf.
Now, doing that with permission is one thing, but when
people were surprised to discover this, they didn't.
really have the traction they did ever again and haven't been heard from since.
There's a, there's a certain approach to, I guess, consent of customers.
But there's also the sense as well of looking at most laptop
environments or desktop environments that I've worked in.
Over time, I start to see sloppiness where I've stashed credentials
in dot files all over the place because that's where they have to be.
There's no better way for a lot of systems to start adopting that.
And.
I guess I like to ideally hope that people clean up their hygiene
once things start moving into production a little bit more, but
the constant drumbeat of breaches seems to suggest otherwise.
Yeah, I mean, SaaS applications are also a huge attack service.
We, we see credentials being left everywhere from repos to AD to Slack.
You know, I really do think that attackers
are better than we are at secrets management.
And the reason why is the motivation is different here.
Uh, for them.
Getting access to a really privileged long term credential can be their
golden ticket to get lots of money and execute their attack successfully.
And for defenders, this usually isn't the highest priority item for them.
I have to give customers some credit here because whenever I'm puttering
around and building code badly, as a general rule, my options are
I can either embed the credential temporarily, quote unquote, in
the code or I can go half an hour out of my way and bring in extra
libraries and do the responsible handling of credentials or whatnot.
When I don't even know if the thing is going to work or
not, the temptation to take the shortcut is terrific.
Getting to a point of being able to do that and stop doing that
requires significant scaffolding on the development experience side.
That I can't necessarily blame people who are under time pressure to bypass.
That's the given pull between development and security that we often see, right?
It's between the quickness that we can deploy amazing features
to our customers versus, you know, kind of securing and locking
things down and making sure that it's done in a safe way.
And I don't think one or the other is correct, right?
There needs to be a balance between the two.
Think of something like employing a secrets management system.
This just reduces your likelihood of credential leaks.
If you can keep your keys and your credentials in a centralized location
and provide an API to dynamically retrieve them, it'll reduce the likelihood
that your credentials are going to be inadvertently left in files.
And on some level, I keep waiting for.
Some IDE to come up with a simple drop in replacement for
this that's transparent, does all the correct things on
the back end, but developers don't have to worry about it.
Instead, it seems like developers aren't worrying about it.
These things make their way into production, and
that's where what you do seems to come into play.
Yeah.
And, um, again, there's two aspects that I think
security practitioners should be thinking about.
The first is on the prevention side.
This is where the identity hygiene and the
misconfiguration part is going to be helpful.
You know, how can I lock things down and harden and
just prevent attacks from happening in the first place?
But it's not complete without the runtime security side.
And this runtime security piece should be able to detect at real time.
Because of how quickly we're seeing cloud
attacks are happening, it's not enough.
to be notified about weird malicious behavior an hour after it happened.
You know, if an attack takes 10 minutes to
execute, you can see why that's too late.
It's always been, if you're kind of catching these things relatively
quickly, there's always the big question that how long has it been going on?
How, what have they had access to?
What in the environment can I trust versus
what should be considered compromised?
And I guess every time I've been looped in on the early
stages of a breach, There's been this massive confused fog
over everything where no one really knows what's going on.
People are making wild hypotheses and throwing them
around to see what sticks, and people in some cases are
overreacting, uh, misinformation runs rampant, etc, etc.
It always tends to feel like regardless of how mature the
processes are, there's a bit of a sudden surprise fire drill.
Everyone's running around screaming for help.
Totally.
And I honestly recommend actually doing fire drills, you know, trying to putting
your systems under stress and seeing how things happen in, in an simulated way.
And so when things really do happen, you know, at least you've kind of
practiced it a couple of times, but yeah, I think that it is, it is a challenge.
It's, it's hard to understand the scope and that's where part
of what you need in a cloud detection and response solution.
is actually the ability to see things
after they've crossed a detection boundary.
So what do I mean by that?
We've actually, Sysdig’s Threat Research Team has actually observed
attacks where the threat actors moved laterally from an AWS
environment To an EC2 compute instance, to an on premises server.
And typically when we think of lateral movement,
we think of going from one account to another.
And the reason why this type of lateral movement is a challenge for
defenders is because once an attacker moves from AWS into EC2, CloudTrail
no longer provides any information about what the attacker is doing.
To see what the attacker is doing on the EC2, you
need, you know, security at runtime on that workload.
And so the, the kind of challenge here is that you need to be able
to see these logs, see these detections occurring from all of these
different areas and have kind of a solution, ideally, that can tie
these things together and show, you know, this is what happened in
CloudTrail, and then this is what happened on runtime on the compute.
And the challenge is being able to correlate those, those actions
and being able to kind of see and paint the picture of the attack.
Do you find that, uh, I, I guess modern cloud technologies, Kubernetes
being one example of this, are, are leading to novel forms of
breaches, or is it effectively still the same things we used to see
in the old days of three tier web apps running on mobile devices?
We can't say it's the same.
There's, I think, It depends on what you're talking about.
Attackers goals are usually financial.
That's not going to change unless you're talking about,
you know, espionage, which is a whole different thing.
But most attackers are after your money or after money in general.
And they're just looking, they're just
finding new ways to get money in the cloud.
It's more often going to be, you know, crypto miners, or we're still
seeing ransomware happening in the cloud as well as on premises.
So I think, yeah, the motives are the same, but the techniques are different.
Even along that, those lines, you folks recently had a blog post
about coining the term LLMjacking, where people would grab credentials
for something like OpenAI or whatnot, and then use those credentials
either for malicious purposes or to not have to pay for it themselves.
Can you give any color on what that looks like?
It would not have occurred to me that that would be something
that people would use directly since, I guess I'm stuck in the old
world where, yeah, I'm going to, I'm going to basically capture
access to a bunch of compute resources and use them to mine
cryptocurrency, which is super economical in someone else's account.
But I hadn't made the leap yet to using LLMs directly as a revenue generator.
Yeah, it was an interesting attack.
So we saw them gain access with stolen credentials, again, the
initial access point, and start targeting specific LLM models,
uh, that were hosted by cloud providers, like Anthropic’s Claude.
And so they're using scripts to check credentials against
a bunch of different AI services like OpenAI and Bedrock.
And they're checking the capabilities and quotas of
these stolen credentials without triggering any alarms.
Um, and using kind of a reverse proxy to basically manage and then sell access.
To these compromised LLM accounts.
Once these companies wind up, uh, sorry, once these companies wind up, uh,
being compromised on an LLM key, how long does the credential remain good for?
Because it always struck me as, oh, you start getting access
to something and you blow the bill to the stratosphere,
people find out relatively quickly and turn it off.
Ideally, that gets noticed within minutes or
hours and practiced days or a week or two.
The way you're talking about this sounds almost like
it's a, it's a more persistent, longer term breach.
You know, anyone who discovers this and shuts it
down, they kind of eliminate that for themselves.
But yeah, we were seeing that they, the attackers would disrupt legitimate
LLM usage by maximizing quota limits and changing things in the setting.
So maybe it doesn't trigger as many alarms as usual.
Um, there was a potential for significant financial
damage here, something like $46,000 a day.
So that's something that hopefully your billing would notify you about for sure.
But even just one day, that's, that can be a lot of money for an organization.
Weird confessions here.
I started noticing that in an open AI key of mine two months ago for,
I was using it for a system to generate internal placeholder text.
And it went from costing me about 10 15 a month or so to starting to get a
number of series where it was costing me basically 8 10 every three days.
It was increased usage, and I never bothered to track it down and figure
out Okay, is this just due to a weird logic bug, or I'm seeing a lot
more throughput through that system, or something external doing it?
Because it's an open AI key, there's no auditability that
I'm able to discover to figure out, all right, what are those
queries, what is being used, what time of day, and correlate that.
So I shrugged, I wound up turning the key
off and didn't have to worry about it again.
But it does make me wonder now that you're saying that.
With any new technology and anything new that's kind of buzzing
in the industry, we can expect attackers to also be into the buzz.
And so, especially for AI, security for AI,
I say starts with just a visibility aspect.
Where do you have AI packages.
Where do you have AI deployed in your environment?
Um, is there any shadow deployments of, you know, developers
that spun it up somewhere that you aren't aware of?
And, um, then layer on top of that, what risks
do these workloads or wherever, uh, have, right?
Just typical risks, you know, are they misconfigured in some egregious way?
Are they, you know,
The only place these credentials lived was inside of AWS Secrets Manager.
So if that got popped, we all have different things to worry about.
But so I'm wondering now, okay, where else would they have been picked up?
Now, of course, thinking it through a bit more logically, the
reason I generally dismissed it was that if this had been a
breach, I have a sneaking suspicion that seven bucks every three
days would not have been the sign of, uh, of, of compromise.
It also is directionally in line, at least with the right order of magnitude
for, for traditional usage, which is why I was mostly okay letting it slide.
But now I really am starting to wonder.
I may have to dig into the CloudTrail logs.
I mean, it's cool that you have these CloudTrail logs to look at, right?
It's some kind of audit and logging system to be able to go back.
And that's a problem with cloud.
Often you're dealing with resources that may not even exist anymore, right?
They’re very dynamic.
And so.
You need to have some kind of ability to look
back and try to understand what happened.
In the cloud, every second counts.
Sysdig stops cloud attacks in real time by instantly detecting
changes in risk with runtime insights and open source Falco.
We correlate signals across workloads, identities, and services to
uncover hidden attack paths and prioritize the risks that matter most.
Discover more at Sysdig, S-Y-S-D-I-G, dot-com.
Audit logging is incredibly expensive at scale,
but not having it can be even more expensive.
It's one of those areas where it's a complete waste of money
until suddenly it's very much not and that that instance
pays for everything you've ever spent and then more on it.
But it's sometimes difficult to get leaders on
board with Thinking through these responsibilities.
That's part of the reason I believe that CISO is a C level position.
It's not just some director of security somewhere.
It has to be fought for on some level in boardrooms.
A hundred percent.
And I think there could, there can be an element of prioritization here.
Um, we witnessed an attack, uh, recently this year where we saw an attacker,
you know, got access into the environment and then they checked it.
to see if an S3 bucket had versioning enabled, which
basically allows, uh, you know, customers to easily
restore data if something happened to it on that S3 bucket.
And it was enabled, so they disabled it and then deleted
all the data, exfiltrated the whole ransomware bit.
Um, and so having CloudTrail on data events, like exfiltrating data, that's
can be really, really expensive, but maybe it's worth it prioritizing it for
certain data storage where you know you have really critical data being stored.
Customer data, HIPAA data, whatever it is.
And then ideally, defense in depth, we have an SCP
that disables the removal of versioning policies, etc.
There are ways to do this, but they're all very obvious.
After you really should have thought about that, because it seems to me
that most people's understanding of attack vectors has not matured to
the level of understanding that, no, no, no, not only are some of these
attackers as good at cloud as you are, many of them are markedly better.
Yeah, I mean, it depends on the company, right?
Some companies are completely born in cloud, cloud native, they live and
breathe that, and a lot of companies are coming to us with old mindsets, right?
There's no longer the same perimeter to secure.
There's, it's different.
It's different in the cloud.
And it is really difficult actually to understand
the complexity of all of the systems involved, right?
We're asking people to be so in depth with so
many different technologies and tools and systems.
And that's challenging.
That's hard.
I I'm not one here to say.
Oh, you know, humans, we suck and we just were really bad at this.
And I think humans are the weakest link, but that's very understandable
because I think what we're asking of people is difficult.
We do not evolve in this environment.
These are advancements in the last couple hundred years.
And a quote I heard from Swift on security on Twitter
that I really love and has resonated has been of all the
levers available to you, Human nature is not one of them.
You will not be able to change it.
And that's, that is the realistic truth of it.
I, I get very tired of security awareness trainings that
basically castigate employees for things of, if you click
the wrong link in an email, you could destroy the company.
Well, frankly, that sounds like a failure on the part of corporate security.
If one person clicking a link brings everything down, maybe focus on the other
side of that equation because, spoiler, we all click the wrong link sometimes.
That Again, is human nature.
Uh, the attacker has to get lucky once, defenders only have to lose once.
And that's, there's an, there's an unequal parity here.
So, not to sound like a Debbie Downer here, but I have to
ask then, so if, if breach is inevitable, what can people do?
Before I answer that question, I will say that it is proven that
Educating and those annoying trainings actually do have an effect.
They reduce the risk of people clicking on phishing
links or doing those kinds of things significantly.
There was some Forbes study that I saw that it
really actually does reduce that likelihood.
Again, that chance is not eliminated entirely.
Very fair.
I am an overly negative cynic on that.
I'm not trying to dunk on people who make mistakes.
We all make mistakes.
I make them in triplicate, generally speaking.
But yes, I definitely accept what you're saying.
Part of why these trainings are annoying is that they're not coming at it
from the perspective of, Hey, this is so understandable to make this mistake.
That you clicked on a link that looked exactly like The font and
button and copy and everything that this company usually has.
It is an understandable mistake to make.
In fact, we're seeing things that are even more understandable.
There was a breach where somebody kind of, you know, stole MFA credentials.
To, to, I think it was Uber's VPN and they kept, you know, trying
to log in repeatedly and then contacted that person on WhatsApp and
pretended to be IT support and convince them to reset their credentials.
And all I'm saying is that if somebody can be tricked to clicking
a phishing email link, they're They can almost certainly be tricked
into accepting a notification from their employer's own MFA.
And overconfidence is absolutely one of those problems.
Oh, I'm far too smart to ever click a link like that.
Really?
You've never gotten a push notification?
Sounded important at two in the morning when you're getting home from the bar?
Really?
You're at your best then?
What's your secret?
I'd like to be, I'd like to be functional then as well.
But yeah, the idea of flooding the MFA codes, uh, and click here to
accept through Duo, historically, people just start spamming them until
eventually people got annoyed and hit the OK button and then they were in.
Because it's easier to believe that your IT team has misconfigured
something that's spamming you instead of know this is an actual attack.
There's a, there is an awareness issue.
A hundred percent.
And I think, and, and also, I mean, we talked earlier about
developers leaving their credentials in all sorts of locations.
That's also an awareness issue, right?
They, I don't think many of them are thinking, Hey,
this is a great, this is like me going out of town and
leaving the key under the mat for weeks and weeks, right?
I don't think they're thinking about it in that term and maybe
just framing it in that term can be helpful to reducing it.
But at the same time, I firmly believe that we should expect to be breached.
We can't control.
how attackers get in always, right?
There's zero day threats that we learn about all the time.
And so that's where the runtime piece comes in, right?
You want to prevent, you want to harden, you want to do everything you
can to make it hard for attackers to take advantage of your systems.
But you also need to operate under the assumption that things
can go wrong, and you, and what do you do when that happens?
I like carrying things through one step further,
to a level of turning things back around again.
For example, when AWS releases a new service, sometimes what I like
to do is very carefully bound an IAM policy to just that service,
and then leak some credentials with that policy attached onto GitHub.
Then people will, of course, subvert it almost
instantly, get the thing to mine cryptocurrency.
Great.
Now I can kill the credentials, I can stop whatever Bitcoin
mining thing it is, and then figure it's mostly configured for
the purposes that I need it, and off to production it goes.
I'm mostly kidding here, but there's an uncomfortable element of truth to it.
You, and it appears that I'm not the only person
who finds a lot of these things confusing.
You've given a talk, uh, several times now, called
IAMConfused, which, Talk about titles that really resonate with me.
My God, I am the confused deputy.
Uh, please tell me about your talk.
Yeah, it was, uh, so I, one of the things I run
at Sysdig is our identity security solution.
And I was kind of baffled at how many, uh, organizations
I saw that recognized the importance of, of zero trust
around least permissive, but hadn't prioritized it.
As a major, you know, initiative that they, there
are other things kind of took higher precedence.
So I created this talk where I walk through eight real life
examples of breaches that occurred in the past year or two
that utilize identities in some way to achieve their goal.
Just to highlight the fact that almost every single breach
that you hear about on the news took advantage of mismanaged
identities or secrets, uh, or permissions in some way.
Yeah.
Increasingly, people hear about these things.
Oh, there was a hack.
Generally, it feels like they fall into two big categories.
One is the provider themselves wound up leaking data somewhere,
or it's the credential stuffing approach where people wound up
using the same password everywhere with poor password hygiene.
Increasingly, though, it starts to seem like quote unquote hacking.
is mostly taking advantage of either social engineering or else
weak credential management, sometimes one combined with the other.
Is that materially changing in cloud?
We're seeing more of that, less of that, or is that always the way of things?
It is really what we're seeing as the most common initial vector, initial
access point for attackers is getting their hands on some kind of credentials,
whether that's buying them on the dark web from, you know, a previous
breach that got kind of leaked, taking advantage of password reuse, um,
or finding those kind of long term credentials that are stored somewhere.
There's many, many different ways that attackers can gain that initial access,
but once they're in, there's all sorts of crazy stuff that they can and do do.
Um, but it's really about, I think for me, highlighting that,
again, you can't control always how they get in, but if you are not
adhering to least permissive, what you're doing is kind of giving
them a gift to go and do whatever they want to do and, and escalate
however they want to escalate and move to wherever they want to move.
Um, and that's, That should scare you.
That should be scary.
It's one of those unfortunate areas where there
just isn't a lot of, I guess, wiggle room.
It's unfortunate because there's, you can't fix human nature, you
can't, there's also an inherent trust built into society as a whole.
Bruce Schneer wound up writing a book about that a while back.
Uh, It's, uh, the, uh, trust required, the embedded
trust for, uh, that societies need to survive and thrive.
It's, you can't, you know, people don't generally take a paranoid baseline
of assuming every person talking to them is out to, out with ill intent.
So I do have a lot of empathy for these things.
I'm also increasingly of the mind that a That a strong defense isn't enough.
Assume you're going to get breached, you need to
be able to detect and respond to that rapidly.
Otherwise, it leads to the M&M security.
Once you're through the thick candy shell, everything inside
is gooey and chocolatey, and you can basically have a field
day in there until everything comes crumbling down around you.
I've used to be fairly dismissive of response approaches as
opposed to, uh, as far as detection goes rather than prevention.
But now it's, yeah, you, you, the reality is assume people will get in.
How do you mitigate, detect, and stop that damage quickly?
Yeah, and I know that you've talked to some other people
about this 5 5 5 benchmark that Sysdig is, is talking about.
And this is really, I think, driving this point home.
If, if cloud attacks are happening in 10 minutes
or less, How can we match that speed, right?
So, you do need to detect, we're saying
within five seconds of that signal occurring.
Whether this is a log from an application or cloud,
a system call, something from network traffic.
needs to be real time so that you can correlate and triage in around
five minutes and initiate some kind of response in five minutes.
The, uh, the idea of being able to detect things in five minutes
is tricky, especially when things like CloudTrail can often
take 20 to wind up announcing, Oh, hey, this thing changed.
It's fair to that team.
Their responsiveness has improved over
the years, but there's still no guarantee.
There's no public SLA around when events will, when
you can count on them being there for things like that.
So it's a, It's a bit of a best effort at the moment.
That's true.
Um, I will say though on the, so on the correlating and triage
piece, this is another place where good identity things can help you.
Um, because if you can stitch actions that attacker took between
identities and between different environments together with a common
thread, which is the identity that helps you to paint a picture of that.
I think more important on, on what you just said in
the, Response side, how do you respond in five minutes?
Many of these needs to be automated.
You're not going to manually be able to respond
with the speed of attacker's automation.
So there are auto response actions that are available in the cloud.
And some actions do need to be manual.
Obviously, you know, I wouldn't automate an
action that could take down your entire website.
I would Propagate that up to the right person
to see if that's kind of what's needed.
Um, but whatever you can automate, that is what's
going to help you to respond at the correct speed.
And you just alluded to something as well that's been the bane of my existence.
Uneven levels of audit coverage.
Okay, we know someone got into the VPN and then connected
from there to a Bastion host and did some things.
We're not entirely sure what.
We can analyze traffic returns and see that there were, there was
some encrypted traffic going to the database, some to a web server.
But we don't really know what it was or what it
contains, so that's a big hole in our understanding.
It's, it's tricky to get holistic coverage of these things, of what
you'll need from an audit perspective, but it absolutely needs to be done.
Yeah, and I think that's one of the, the biggest
challenges for us security vendors, right?
It's a pain point that we're trying to solve for is
how Can we help you find that needle in the haystack?
You're drowning in noise, right?
It's great that we have all these logs and all these
audit things, but the problem now is that we've become
kind of over and inundated and overwhelmed with them.
And sometimes the indicator of compromise that's
within Those logs gets buried in all of them.
There's no good answers that I can see here.
I wish there were otherwise.
But I really don't see how they are, how there's a better
path forward that is going to be, I guess, clear enough.
Something will get there, but not, uh, but it just
still seems like there's still so much work to be done.
At the moment, being aware of it happens, computers are going to be able
to react faster than humans can and having a plan seem to be like the
baseline, do the work, everything else sort of extends downstream from that.
The good news is, is that the techniques that attackers do aren't that
different across a bunch of, uh, across a bunch of different breaches.
For example, most attackers, once they make it
into your environment, will do some reconnaissance.
They'll enumerate, they'll try to find out,
what can I access with my current credentials?
What other credentials can I get access to?
And so they're making calls like, list S3
buckets, list that, list, list, list, right?
All of these calls, calls that are pretty
typical in a normal cloud day to day operation.
However, what's not typical is seeing them happen,
you know, there was 100 calls within a minute.
That should be an indication that there's malicious activity potentially here.
And that's kind of what we're trying to do.
We're trying to add Extra logic on top of it, because the challenge is
that all of these individual logs by themselves can often be, you know,
just typical cloud operations, but if you can add some kind of logic on
top of it, where it's looking at, okay, now this is atypical, you know,
list S3 bucket, that's a normal call, but a hundred of them, not so much.
And okay.
That's, that's one of our, uh, DevOps people.
They're presumed trusted.
Sure, but when their activity begins to look very different than what
it normally does, and possibly that's a correlation of, okay, because
their tooling tends to work through Python, why are they suddenly making
requests from Golang, that's a little odd, they start to be able to identify
heuristically, that there are, something fishy might be afoot, but ugh, it
seems like it's, it's such a great ideal, but getting there is such a hard part.
It is, but we, we, we are getting there.
I think I, I'm, I'm not, you know, I think the security and
attackers, that's always going to be this cat and mouse game, right?
Where, uh, threats innovate in some way, and then we innovate
to kind of defend against it and, and there's always going
to be that push and pull, but I think if we can embrace.
These kind of automations and these logic and machine learning
in a way that that is actually effective for security.
I don't think that AI is the silver bullet that everyone,
you know, says, uh, we can just run it and then that's it.
You know, we don't have to do, Uh, our jobs anymore.
Uh, but I do think that there are use cases where AI can help us and
cutting through the noise and finding these abnormalities is one of those.
I really want to thank you for taking the time to speak with me today.
If people want to learn more, where's the best place for them to go?
Uh, they can visit Sysdig.
com or reach out to me directly on LinkedIn.
And perfect, we'll put links to both of those in the show notes.
Thank you so much for taking the time to speak with me today.
I really do appreciate it.
Thank you, Corey.
Maya Levine, Product Manager at Sysdig.
I'm Cloud Economist Corey Quinn, and this is Screaming in the Cloud.
If you've enjoyed this podcast, please leave a five
star review on your podcast platform of choice.
Whereas if you hated this podcast, please leave a 5 star review on
your podcast platform of choice, along with an angry, insulting comment
that no doubt will not be attributed to you because that platform
provider wound up getting breached due to poor credential management.