BRENDAN FOLEY: Hi, everyone.
My name is Brendan Foley, a customer engineer
here at Google.
I'm joined today by James Spiteri, a product marketing
director at Elastic.
We're both very happy to be here today
and to talk to you about how teams and organizations can
utilize the Elasticsearch platform on Google Cloud
to investigate and prevent application exploits.
We'll also talk about the advantages
of combining application observability and security
events into the same platform.
And we'll see this live in a demo.
We all know that data is at the heart of the modern enterprise
and, needless to say, at the heart
of modern security analytics.
Unfortunately, security teams have long
relied on what we consider traditional security events.
Think endpoint logs, firewall logs, et cetera.
While these are, of course, important,
the events which occurred in December
showed how those are simply not enough.
Following the events which occurred in December,
it became even more evident why these different solutions
shouldn't be siloed.
James, why don't you go ahead and explain what you'll
be seeing as part of the demo.
JAMES SPITERI: Yeah, awesome.
Thanks, Brendan.
Before we shift into the demo, I'll just quickly
talk through the slide that I have here
to show the setup we'll be using for this particular use
case, which was the log for shell exploits, which
are the events Brendan was referring to in December.
So we've got the vulnerable Java application running here
on our hosts.
And we've just exploited it with log4shell.
This application is instrumented using our Java APM agent, so
Application Performance Monitoring, which
is going to give us really deep insight into exactly
what the application is doing.
And that data is being streamed into an Elastic Stack hosted
on Google Cloud.
Here's a demo now to talk about the other infrastructure
elements and everything else we have running on our machines,
and how we can use the different solutions within Kibana
to investigate this exploit.
OK.
So let's dive right into the demo.
So first things first.
I just wanted to show you all the components
that I've set up for the purpose of today.
So we've got an Elastic cluster running out of Google Cloud,
specifically in the Belgium region.
And this is the Elastic Cloud Console
but you can also invoke the creation
of these clusters through Google Cloud platform itself.
And we have various different regions that you can use.
From the Google side, we've got a couple of compute instances
that we'll be monitoring.
We have Google Cloud buckets, which
is going to be used for an Elastic feature called
Searchable Snapshots.
It is just an ordinary Google Cloud bucket,
but it's going to be used for a very powerful purpose.
We've got a Pub/Sub topic primarily collecting our Google
Cloud firewall logs.
And, of course, the Google Cloud firewall rules themselves.
This one, specifically, is going to be doing
the bulk of the work for us.
Now that we have everything set up,
let's see what it looks like on the Elastic side.
So we've got our Elastic agent, Google Cloud platform
integration, which is collecting primarily the Pub/Sub events.
We've got our Elastic agent also running our endpoint security
integration on those compute instances.
Now, I've said that we've exploited
a vulnerable application with the log4shell exploit.
Let's see what we're able to find now
within Elastic with all these Google data sets.
So looking at our alerts view inside of Elastic Security,
we have a couple of different things that we can see.
Primarily, we saw an alert for a suspicious Java chat
process followed by a couple of malware prevention alerts.
The exploit I invoked from log4shell does just that.
It does try to download malicious files and run them.
This is exploits I've seen from honeypot data.
So this is what people have been trying to exploit in the wild.
We can see here, thanks to the Elastic endpoint
and the security views, we get a very nice process
to review of what happened.
And again, the malware prevention alerts, as well as
some threat intel indicator matches.
These are all standard out of the box rules by the way.
So it's not like I created anything custom
for this specific exploit.
We do have some threat intelligence enrichments, here.
And we can see that this is now giving a high-risk profile, as
well.
But from a security analyst perspective,
I don't know that this is log4shell, right?
I have no idea that it was exploited.
But, thankfully, I have all the applications
on this host using our Application Performance
Monitoring, APM.
Since they're Java applications, it's very easy for us
to instrument.
So I'm going to pivot to that view.
It's within the exact same console.
We're going from security to observability instead.
And I've got my application running in Google Cloud.
You can see it's very clearly indicated over there.
And I can see a couple of transactions which happened.
If we click on the transaction, we'll
be able to get pretty much everything
that application did at that point in time.
I'm just going to go to the first sample, here.
And we can see that it was invoked by via curl
because I ran this manually.
But first thing we see is the main instance
of the transaction being invoked.
It was a Java application.
Yes, we know that.
But we can see in the request header
this is what that exploit looked like, right.
To the eyes of the analyst, it ended up
being the coded Base64 command.
But they hadn't seen this yet.
There weren't any logs or alerts stating that--
or I should say with this content.
We got this from the application view, which is great to see.
But what is even more interesting
is what happens right after.
So thanks to this application view,
we can see that right after the main transaction was invoked,
a GET request to this random IP on this random port was made.
And it was actually invoked via the JNDI manager
from log4j, which is exactly what log4shell does.
And you can see it tried to download
this class, which is, again, very indicative of log4shell.
So if I'm a security analyst, I had my security alerts trigger,
pivoted to this application view,
and then I have pretty much all the information
I need to put two and two together based on what,
even if I just did one second of research
online about JNDI manager, I can-- probably going
to tell that this log4shell.
Now, we've basically seen what happened today, right?
But what I want to do is use that Searchable Snapshot
feature I was talking about to dive a bit deeper.
So what Searchable Snapshots allows you to do
is store data on very cheap storage, like archive storage,
like a Google Cloud bucket, but still
be able to search it as if it was data from today.
So I have a timeline here where I'm going to do just that.
Here's a correlation from today which
I ran, which, essentially, I'm looking for processes
like curl and wget.
And within a 2-minute time period,
we want to see if those processes made any network
connections on our Google Cloud firewall data.
And we can see that happening right here.
We've correlated based off of the destination IP.
And thanks to the rich information
I get out of my logs coming from Pub/Sub,
this is really easy for me to understand
what happened because all the detail is provided in there.
But if I wanted to go back, and, say, let's now search,
instead of today, let's go over the last one year,
Elasticsearch in the background knows
that it should use the Searchable Snapshots.
So we do that automatically.
As an analyst, you don't have to decide where to look from.
So my data from July 22, 2021, is telling me, listen,
you've had requests to that IP address
that was hosting the malware.
And we've gone and looked on that archive.
This is set up in our index lifecycle management policy.
So you can see here, I have a frozen face,
which goes into that Searchable Snapshot repository.
And just to show you, as well, if you look at the data storage
size for those logs stored in the snapshot,
on the physical storage of my cluster,
it's saying 0 bytes, which is--
which means it's all in the archive.
So there's nothing--
I'm not using expensive storage for my compute instances.
And that's pretty much it from a demo perspective.
We'll wrap up with a couple of more slides.
BRENDAN FOLEY: Thanks for that, James.
Hopefully, you all saw how powerful
it can be to combine application data with security data
into a single platform, such as the Elastic Stack.
Thank you all for joining and enjoy
the rest of the conference.