PRESENTER: Welcome to Cloud Security Basics, a series where
we explain the ins and outs of securing your application
on Google Cloud.
Sound fun?
Then stick around, because in this episode,
you'll learn about why you shouldn't
log into a compromised server instance during a breach.
[MUSIC PLAYING]
[PHONE BUTTONS DIALING]
BRAD ACTOR: Greetings, cloud detective.
Last episode, you used Google Cloud's Operations suite
to track down a compromised employee.
But this time, I have finally gotten into your system.
I really have.
I repeat, I have breached your system.
So riddle me this.
What can you do about it now that I'm on the inside?
Hurry up as fast as you can.
Try to get me out before I swap all of the employee photos
with cat photos.
FEMALE SPEAKER: OK.
So here's what we know.
Brad Actor says he's breached my system, which
is a strange thing for an attacker to do.
And I haven't received any alerts
from my monitoring system.
Maybe I should log in and see what I can find.
Actually, no.
That could be playing into exactly what Brad Actor wants.
I almost just made a really big mistake
and logged into the compromised instance.
But many attackers plan for this exact response
and actually try to steal admin credentials as they log in
to fix the breach.
So a general rule here is to avoid logging
into a compromised server during a breach.
Hmm.
So how can I see if Brad Actor really
did breach my system without compromising it further?
Well, luckily, we've set up an external store
for our security logs that we can still
check out what happened.
By putting our forensic artifacts in a separate place--
in this case, a Google Cloud project--
we can examine the problem without alerting the attacker.
This lets us better understand what's happening.
And we can watch and record their actions to tip off
local authorities if needed.
We set this up by using Google Cloud Operation Suite's Export
feature in combination with sinks,
which are basically filtered exports for log entries.
The supported destinations for sinks
can be a cloud storage bucket, a Pub/Sub topic, a BigQuery
table, or a Cloud Logging bucket.
So we created a sink in our application program, the one
Brad Actor says he compromised.
And we copied those logs into a Cloud Logging bucket
in our logs monitoring project.
We ended up using a Cloud Logging bucket
because unlike logs data that's stored in Cloud Storage,
logs stored in Cloud Logging are indexed, optimized,
and delivered to let you analyze your logs in close
to real time.
Another benefit of this approach is
that it allows us to set up a system where
we view all of our project logs in one place,
simplifying monitoring everything in our cloud
environment.
Looking through my logs, I don't see any suspicious activity.
Hmm.
I guess it's best to be patient and wait this one out and see
if anything does pop up.
Uh-oh, I got it.
Now, that's just devious.
BRAD ACTOR: Drats, detective.
You foiled my plan.
It's true.
I didn't fully breach your system.
But I was hoping to steal your credentials
when you attempted to log in.
It would have been a mistake to immediately log
into the supposedly compromised server.
But I know you would have examined your audit logs, which
means you must have set up a separate security environment
for your forensic files.
Well played, detective.
Well played.
That's all from me for now.
But I will come back more devious and mischievous
than ever in the near future.
PRESENTER: So there you have it-- another episode
of Cloud Security Basics.
For more information about securing your cloud
environment, be sure to check out
the links in the description below.
So stay tuned for the rest of the Cloud Security Basic
series, because when it comes to security,
you can't let bad actors win.
[MUSIC PLAYING]