WEBVTT
1
00:00:01.360 --> 00:00:08.480
Involve, Solve Evolve. Welcome to
cloud Crunch, the podcast for any large
2
00:00:08.640 --> 00:00:13.279
enterprise planning on moving to or is
in the midst of moving to the cloud.
3
00:00:13.800 --> 00:00:20.600
Hosted by the cloud computing experts from
Second Watch. Michael Elliott, Executive
4
00:00:20.640 --> 00:00:27.679
director of Marketing and Fred Bliss,
CTO of all Things Data at second Watch
5
00:00:29.480 --> 00:00:50.240
and now here are your hosts of
cloud Crunch. Welcome back to a new
6
00:00:50.280 --> 00:00:54.320
season of cloud Crunch. In this
season, we're going to focus on AWS
7
00:00:54.399 --> 00:00:59.520
Reinvent, the biggest cloud conference in
the world, kicking off November. Our
8
00:00:59.560 --> 00:01:03.439
intent is to enable you the viewer, the opportunity to immerse yourself and how
9
00:01:03.519 --> 00:01:08.000
cloud has evolved since last year on
topics like preparing and building a center of
10
00:01:08.040 --> 00:01:12.840
excellence, extracting data insights with you
know many refer to as data analytics,
11
00:01:14.439 --> 00:01:19.159
managing a cloud native environment, and
data center evacuation. Now joining me today
12
00:01:19.239 --> 00:01:25.000
is Fred Bliss, CTO of Data
Insights and Joey Brown, Senior consultant,
13
00:01:25.000 --> 00:01:29.000
both here at second Watch. Welcome
to cloud Crunch, Fred and Joey.
14
00:01:29.359 --> 00:01:34.040
Thanks Michael, happy to be here. Thanks having alright great Joey. So
15
00:01:34.840 --> 00:01:40.079
today we're gonna focus on cybersecurity analytics, and I'll have to admit not a
16
00:01:40.159 --> 00:01:42.000
subject I'm strong at. So I'm
happy to have both of you here to
17
00:01:42.120 --> 00:01:49.359
kind of discuss where this is evolving, because as we look at cybersecurity in
18
00:01:49.439 --> 00:01:53.319
my background, it is always an
extreme interest, but not a lot of
19
00:01:53.359 --> 00:01:57.840
money being paid to actually do anything
about it until there's an issue. So
20
00:01:57.879 --> 00:02:00.400
this should be a really interesting discussion. So one kind of start off with
21
00:02:00.480 --> 00:02:06.319
kind of questions around you know,
what are we talking about here from a
22
00:02:06.439 --> 00:02:10.719
cybersecurity perspective that hasn't been talked about
by every c so out there. What
23
00:02:10.759 --> 00:02:15.199
I'm seeing now is UM. You
know, as part of every data project,
24
00:02:15.199 --> 00:02:20.240
we'd always have security part of it, governance part of it. UM.
25
00:02:20.319 --> 00:02:23.800
For highly regulated industries there be a
component of risk and compliance, but
26
00:02:24.080 --> 00:02:28.759
you know, kind of checking the
box. Uh. And that's changing.
27
00:02:28.879 --> 00:02:32.240
And a big component of that is
we've got a lot of multinational global organizations.
28
00:02:32.639 --> 00:02:36.960
UH. If you look around the
world, countries like UM, you
29
00:02:37.000 --> 00:02:38.960
know India for example. You know, we've already seen the effects of g
30
00:02:39.080 --> 00:02:44.360
d p R over the last couple
of years UM in India. Now there's
31
00:02:44.520 --> 00:02:49.039
a lot of regulation kind of changing
kind of by the day with data residency
32
00:02:49.080 --> 00:02:53.840
and data sovereignty laws. Um,
you've got AI ethics, UM and transparency
33
00:02:54.520 --> 00:03:00.080
regulations coming out, executive orders coming
out. Data privacy regulations are absolutely I
34
00:03:00.080 --> 00:03:05.479
mean at the state and federal level. And now what we're seeing as organizations
35
00:03:05.560 --> 00:03:09.560
actually empowering and putting money behind UM
some of these data privacy teams. So
36
00:03:10.120 --> 00:03:15.240
the same data that's being used for
security purposes that might live in a single
37
00:03:15.360 --> 00:03:21.560
purpose UM sim tool uh now serve
a lot of other purposes. Depending on
38
00:03:21.599 --> 00:03:24.479
which hat you're wearing, Joey,
I'll let you kind of take it from
39
00:03:24.599 --> 00:03:28.520
what you're seeing on an I said, yeah, I think on the idea
40
00:03:28.560 --> 00:03:30.280
side, we see a lot of
request for you know, we want to
41
00:03:30.280 --> 00:03:34.199
get a lot of security analytics who
want to get the dashboards we want to
42
00:03:34.240 --> 00:03:43.000
get um, you know, visualization
of things UM and UM uh. Sometimes
43
00:03:43.000 --> 00:03:45.439
it seems like they maybe want to
skip some of the detective controls, like
44
00:03:45.479 --> 00:03:47.840
maybe can we just get the dashboard
of at actually collecting any of the logs
45
00:03:49.000 --> 00:03:53.800
and kind of get the cart before
the horse some of the time. Uh.
46
00:03:53.080 --> 00:03:55.319
Sometimes so you really want to make
sure you know, cover your bases
47
00:03:55.360 --> 00:03:59.280
if you collect, if you're collecting
all of the data that you can possibly
48
00:03:59.319 --> 00:04:02.240
get everywhere. Then you can be
in a position where you can even switch
49
00:04:02.280 --> 00:04:05.439
different ways to do analytics. You
can have different dashboards, you can try
50
00:04:05.439 --> 00:04:08.879
different products because the logs are all
there. But if you're starting out with
51
00:04:09.479 --> 00:04:14.080
has quicksite compared to Tableau compared to
you know, some other some other dashboard,
52
00:04:14.800 --> 00:04:16.199
You've got to get the data first, right. So, uh,
53
00:04:16.279 --> 00:04:20.439
and some of the areas for security
complainants, you know, we I'd like
54
00:04:20.439 --> 00:04:25.920
to say that there we talked about
them where they're kind of one thing,
55
00:04:25.959 --> 00:04:28.680
and then we try to tell our
clients sometimes well you should really think about
56
00:04:28.720 --> 00:04:30.800
them separately. You know, compliance
isn't really security. But some of those
57
00:04:30.800 --> 00:04:35.680
tools, like you're saying, Fred
really starting to bleed together. Databs has
58
00:04:35.839 --> 00:04:41.759
ATBs Audit Manager now and it'll it'll
check a lot of the your your audit
59
00:04:41.800 --> 00:04:45.040
logs and your I M logs and
things like that, and it'll set you
60
00:04:45.120 --> 00:04:47.759
up for those compliance reports that you
need. You know, an auditor shows
61
00:04:47.800 --> 00:04:49.839
up and says that we want to
see these resources and want to see the
62
00:04:49.879 --> 00:04:55.600
history of these resources. They're already
there. So some of the security logging
63
00:04:55.600 --> 00:05:00.439
things start to start to bleed into
in the compliance. Yeah, the whole
64
00:05:00.519 --> 00:05:05.360
um idea of what tools should I
use for dashboards is really the wrong question,
65
00:05:05.480 --> 00:05:09.879
right, I mean, it's all
about what what data should we collect
66
00:05:09.879 --> 00:05:14.160
and what signals do we care about? Because um, I mean it's not
67
00:05:14.199 --> 00:05:17.680
just dashboards, right, There's there's
a million different products that you can um
68
00:05:17.720 --> 00:05:20.319
that you can elaborate the same data
for. I imagine, right, and
69
00:05:21.519 --> 00:05:28.879
are seeing customers that have more than
one uh, that have more than one
70
00:05:28.959 --> 00:05:32.560
place where they're collecting security logs right, Honestly, not as often as I
71
00:05:32.560 --> 00:05:35.519
would like. I would I would
like it where they where people had more
72
00:05:35.759 --> 00:05:39.839
more dashboards, more more more tools, like where somebody says, well,
73
00:05:39.839 --> 00:05:43.839
we picked open search or we picked
you know this, you to this tool,
74
00:05:43.920 --> 00:05:46.800
so let's go with that. I
wish people had more flexibility to they
75
00:05:46.839 --> 00:05:49.759
have all the logs in one place
and they can try different products instead of
76
00:05:49.759 --> 00:05:53.360
focusing on when we picked this one
and it doesn't have this feature. But
77
00:05:53.399 --> 00:05:56.279
that's what we're going that, you
know, all the logs should be in
78
00:05:56.319 --> 00:05:59.319
one place and they should be able
to be consumed by whatever they want.
79
00:06:00.600 --> 00:06:03.600
And I think we've we've heard a
lot and we've recorded in prior episodes Fred
80
00:06:03.639 --> 00:06:06.959
with you know, we picked the
tool, now how do we apply it
81
00:06:08.000 --> 00:06:10.720
to all these things? But I
want to kind of go back. What
82
00:06:10.920 --> 00:06:15.120
is all the data that you can
collect and then you can bring into a
83
00:06:15.199 --> 00:06:19.079
central repository. Well when you um, you know it depending on the depending
84
00:06:19.120 --> 00:06:24.560
on the cloud and the use cases
of of freach client. There's a lot
85
00:06:24.600 --> 00:06:28.720
of inbound and outbound you know,
but um, it's not just all the
86
00:06:28.759 --> 00:06:33.959
application logging and inbound logs and network
logs and things like that. But um,
87
00:06:34.279 --> 00:06:40.519
the um if you can get again
them all in one one place you
88
00:06:40.560 --> 00:06:46.199
can start doing. You can you
can look at authentication versus authorization. You
89
00:06:46.199 --> 00:06:51.319
know, you can see failed authentication
attempts, or you can also see authenticating
90
00:06:51.360 --> 00:06:55.920
people are trying to access things that
they're not necessarily authorized to do. Or
91
00:06:55.959 --> 00:07:00.920
you could another thing that people don't
maybe bring in as often as they should,
92
00:07:00.959 --> 00:07:05.000
our DNS look ups resources they have
in an environment that are trying to
93
00:07:05.000 --> 00:07:11.800
make calls outside. Do you see
that you have some machine making road calls
94
00:07:11.839 --> 00:07:15.800
to some DNS server, some bitcoin
wallet or something like that. That's that's
95
00:07:15.800 --> 00:07:20.160
pretty suspicious. So so you know, it's not just about network firewall logs
96
00:07:20.160 --> 00:07:24.319
and laugh logs and you don't want
to look at c d M s and
97
00:07:24.360 --> 00:07:28.120
see why are we suddenly getting a
lot of traffic in India or something like
98
00:07:28.160 --> 00:07:31.160
that. Yeah. And and from
a data and analytics standpoint, UM,
99
00:07:31.319 --> 00:07:34.600
what we see business users UM,
and a lot of these compliance and risk
100
00:07:34.600 --> 00:07:40.839
teams care about is who's accessing specifically
what data? Right? UM, what
101
00:07:40.920 --> 00:07:45.279
do you think about healthcare and hip
ip? Right? UM? You need
102
00:07:45.399 --> 00:07:48.800
you need to absolutely make sure that
the right people are accessing the right data.
103
00:07:49.360 --> 00:07:54.600
And why right if you need to
go investigate and look into you know,
104
00:07:54.639 --> 00:07:59.959
a couple of different records for a
healthcare organization, UM, you need
105
00:08:00.000 --> 00:08:01.759
a reason why. You need a
trace ability of of what that look like
106
00:08:01.800 --> 00:08:05.600
at a point in time. And
so that means not just knowing, um,
107
00:08:05.680 --> 00:08:09.959
who access what, but what did
the data structures look like? Because
108
00:08:09.959 --> 00:08:13.160
you might be looking back a year, two years UM at a point in
109
00:08:13.160 --> 00:08:16.439
time of what those data structures look
like, and what those look like two
110
00:08:16.560 --> 00:08:20.160
years ago might not be what they
look like today. And so that means
111
00:08:20.560 --> 00:08:22.800
when you're collecting all this data,
UM, enjoy, I'm sure you see
112
00:08:22.839 --> 00:08:24.879
this as well. It's not about
what tools do I use? At the
113
00:08:24.959 --> 00:08:30.160
end, it's how do I start
to collect and model this data so that
114
00:08:30.240 --> 00:08:31.919
I can look at all of it
at a point in time and see,
115
00:08:33.000 --> 00:08:35.519
these are all the DNS records coming
in. It's a lot of data,
116
00:08:35.639 --> 00:08:39.559
right, But I think we're at
a point where the technology can can handle
117
00:08:39.600 --> 00:08:43.799
that well. And and some you
know, an older technology that everybody loved.
118
00:08:43.080 --> 00:08:46.840
When when you know it's all the
rage elastic search now is you know
119
00:08:48.320 --> 00:08:52.159
it's going more towards the open search
version. Um, that's that's what it
120
00:08:52.200 --> 00:08:54.120
promises. You get all your lodge
there, and I just want to look
121
00:08:54.120 --> 00:08:58.000
at this time slice. Um.
You know we have a security incident and
122
00:08:58.000 --> 00:09:01.960
we had something some blip at the
time. Um, let's look at all
123
00:09:01.960 --> 00:09:03.399
of the logs from that time and
see what was going on, and then
124
00:09:03.440 --> 00:09:05.960
you'll find out like, are we
looking at an outage? Here? Is
125
00:09:07.080 --> 00:09:09.279
a security incident? Incident? Um? So when you can really get it
126
00:09:09.320 --> 00:09:13.159
down to a specific times life and
start looking at all the logs there,
127
00:09:13.720 --> 00:09:16.240
nobody wants to look at network flow
log as well. Nobody I want to
128
00:09:16.279 --> 00:09:18.320
hang out with. But um,
but when when you have it in the
129
00:09:18.399 --> 00:09:24.159
last search and you can just narrow
it down to one one tiny times lives
130
00:09:24.200 --> 00:09:28.440
you can you can see here's the
network traffic, everything that's happening in this
131
00:09:28.480 --> 00:09:35.600
one one or two minutes. That
can really shorten the cycle for your response
132
00:09:35.639 --> 00:09:41.600
time and a detective, you know, all your incident response plans and stuff
133
00:09:41.639 --> 00:09:45.279
like that. Joey, let me
let me ask you a quick question.
134
00:09:45.320 --> 00:09:48.279
I mean security, This is not
a new topic, at least from a
135
00:09:48.320 --> 00:09:54.559
security perspective. So what's different with
this capability that doesn't already exist? And
136
00:09:54.600 --> 00:10:00.919
how do you maybe to add on
to that to UM? What uh are
137
00:10:01.240 --> 00:10:05.320
you seeing multiple like I guess,
multiple different teams managing multiple systems? So
138
00:10:05.360 --> 00:10:11.120
are there different security response teams depending
on which wind a business or application or
139
00:10:11.399 --> 00:10:16.919
Cleveland cloud? Uh? Sort of
like you'll have people that do UM.
140
00:10:16.080 --> 00:10:20.519
You know, here's our instant response
plan and they're thinking about it. You
141
00:10:20.519 --> 00:10:24.519
know, they go through a lot
of exercise where we've got a VM somewhere
142
00:10:24.639 --> 00:10:28.480
and our incidet's response plan is,
Okay, we're going to isolate this VM
143
00:10:28.519 --> 00:10:31.639
and we'll go through drills like that. Okay, we find out that we're
144
00:10:31.639 --> 00:10:33.919
gonta learned that there's something funny going
on with this VM. It's making strange
145
00:10:33.960 --> 00:10:37.519
calls. We're going to isolate it, we're gonna investigate it, we're gonna
146
00:10:37.559 --> 00:10:39.679
find out what the root cause was. We're going to try to put it
147
00:10:39.320 --> 00:10:43.840
UH in a quarantine environment and that
it's used to go through those exercises with
148
00:10:45.240 --> 00:10:50.039
um VM. But when it's UM
data in your cloud storage, it's in
149
00:10:50.480 --> 00:10:56.200
S three or it's in cloud storage
and it's there's an ex filtration event and
150
00:10:56.279 --> 00:11:00.399
now there's nothing to isolate. You're
not you have if you're in VM mode
151
00:11:00.679 --> 00:11:05.000
and you're not thinking more like across
services, it could be you want to
152
00:11:05.000 --> 00:11:09.080
try to apply those response plans to
different things, and then the other you
153
00:11:09.080 --> 00:11:13.480
will have a different team or maybe
the same team doing a different exercise for
154
00:11:13.559 --> 00:11:18.159
like UM disaster recovery over disaster recovery, here's my set of things, or
155
00:11:18.159 --> 00:11:22.000
we go through this checklift. So
even if even sometimes it's the same team,
156
00:11:22.000 --> 00:11:26.919
it's they sort of think about it
has two totally different activities. But
157
00:11:26.799 --> 00:11:33.200
those drills should be opportunities for you
to look at to be captured all the
158
00:11:33.240 --> 00:11:35.200
logs, you know, not just
here's here's the here's how we would isolate
159
00:11:35.240 --> 00:11:39.000
a VM, or here's how we
would here's how we would look at some
160
00:11:39.120 --> 00:11:43.039
data expiltration event, but why wouldn't
where would our logs be for these events?
161
00:11:43.639 --> 00:11:46.080
And then how would we how would
we be able to do security analytics
162
00:11:46.879 --> 00:11:52.679
on a drill? I think that's
spot on. And what I'm seeing and
163
00:11:52.759 --> 00:11:58.320
hearing UM from C suite and UH
interactual lever level folks at enterprises is you've
164
00:11:58.360 --> 00:12:03.519
got a lot of these UM goal
purpose sim tools and legacy ones that just
165
00:12:03.559 --> 00:12:07.480
don't work for modern security teams.
UM. You know, Joey, when
166
00:12:07.519 --> 00:12:11.879
you think about UM a big enterprise
customer that's got I mean, you've got
167
00:12:11.879 --> 00:12:15.399
Azure with Sentinel, You've got a
WS with their solution, You've got GCP
168
00:12:15.879 --> 00:12:20.879
now with their acquisition of Mania and
there in their solution. All of that
169
00:12:20.000 --> 00:12:24.600
data is being ingested into those systems. But now you need to ingest the
170
00:12:24.679 --> 00:12:28.799
data from all those systems in your
system, right. Well yeah, when
171
00:12:28.799 --> 00:12:33.279
you ask them, yes, if
you ask UH Azure Sentinel, they'll say,
172
00:12:33.519 --> 00:12:37.159
no, exactly ingested all over here. We can take all of it.
173
00:12:37.200 --> 00:12:39.240
You know when we when we when
we look at as your sentinel,
174
00:12:39.240 --> 00:12:41.120
they're like, here's how you ship
your aw S looks, there's how you
175
00:12:41.120 --> 00:12:43.480
ship cloud trail to sentinel. That's
how you ship everything, give it all
176
00:12:43.519 --> 00:12:46.440
the up. So, um,
it's easy for us to say, hey,
177
00:12:46.440 --> 00:12:48.879
you should just record everything, you
know, hey, get all your
178
00:12:48.919 --> 00:12:52.960
logs everywhere. But when you've got
your ad A d over here, and
179
00:12:52.960 --> 00:12:54.799
then you've got your AWS environment over
there, and then you've got a data
180
00:12:54.840 --> 00:12:58.679
team on g CP, Yeah,
it does get into a situation. Well,
181
00:12:58.759 --> 00:13:03.279
now we kind of do have to
pick one central pository for for logs
182
00:13:03.320 --> 00:13:09.840
maybe, and we do see unfortunately
a lot of companies bok at the cost
183
00:13:09.919 --> 00:13:15.759
of log storage. You know,
it's you can get into dozens of dollars
184
00:13:15.799 --> 00:13:18.639
that they didn't plan for, you
know, or sometimes hundreds of dollars that
185
00:13:18.679 --> 00:13:22.200
they didn't plan to spend that quarter. It's but in the grand scheme of
186
00:13:22.240 --> 00:13:26.960
what their their cloud spend is log
stories should be the least of their concerns.
187
00:13:28.159 --> 00:13:31.799
You know, it compresses. You
really only need to know you can
188
00:13:31.799 --> 00:13:35.279
figure out your your life cycle of
that data. If we're talking about security
189
00:13:35.320 --> 00:13:37.279
incidents, yeah, you might need
to hang onto it for years, but
190
00:13:37.320 --> 00:13:41.720
you only need to keep it pretty
hot for thirty days. So don't don't
191
00:13:41.799 --> 00:13:45.840
don't don't skimp on the on the
log storage, please enjoy. Just to
192
00:13:45.879 --> 00:13:50.039
be clear, to be clear,
when you say hundreds of dollars, there's
193
00:13:50.039 --> 00:13:52.159
a few more zeros after that.
Well, not necessarily, it'll be like
194
00:13:52.320 --> 00:13:56.759
you'll have a calm with people.
Well, you gotta turn on your flow
195
00:13:56.799 --> 00:14:00.919
logs and this this VPC or something
so we can get inbound and outbound accepts
196
00:14:00.919 --> 00:14:01.720
and rejects and everything for the network
thing. No no, no, no,
197
00:14:01.720 --> 00:14:03.720
no no, that's a sandbox.
That's a devil. That's a deav
198
00:14:03.840 --> 00:14:09.399
environment. We don't want to pay, and we want to pay an extra
199
00:14:09.480 --> 00:14:13.600
hundred dollars. It's just dead environment. The people who take over your account
200
00:14:13.639 --> 00:14:16.159
don't care what kind of environment it
is. They want to spend a bitcoin
201
00:14:16.200 --> 00:14:18.600
miners, they don't, they don't
care for this. This is a deav
202
00:14:18.600 --> 00:14:20.240
account. Don't spend a bitcoin miners
there, you know. So you you
203
00:14:20.320 --> 00:14:24.840
want all of that, all of
the security logging in all of your environments,
204
00:14:24.879 --> 00:14:26.960
not just the not just the problem. I think that's a great point.
205
00:14:28.200 --> 00:14:31.360
Um. The cost of storage is
something you know, I see that
206
00:14:31.399 --> 00:14:37.440
I think is kind of a left
behind thought of you know, bad experiences
207
00:14:37.600 --> 00:14:41.000
of getting hit with huge spending bills
because you've got geo, replicated data of
208
00:14:41.039 --> 00:14:45.159
the same data, copied multiple times, and bad governance policies, and you
209
00:14:45.200 --> 00:14:46.720
weren't really looking into it. But
you're right at the end of the day,
210
00:14:46.720 --> 00:14:50.000
all of this. If you've got
it in Calm their storage, and
211
00:14:50.039 --> 00:14:52.519
you've got it well modeled, it
compresses and it becomes a tiny little fraction
212
00:14:52.559 --> 00:14:56.559
and one. And I thought the
cost uh, and you know, shipping
213
00:14:56.600 --> 00:15:01.679
logs back and forth between clouds.
The I heard an interesting anecdote that,
214
00:15:01.480 --> 00:15:05.480
um, if you're using Sentinel,
if you're using AWS solution and just you
215
00:15:05.480 --> 00:15:09.320
know, shipping them back and forth, the eat risk costs of doing that
216
00:15:11.279 --> 00:15:15.879
has got a significantly outweigh the costs
of storing it within your own data lake
217
00:15:15.919 --> 00:15:18.159
and data warehouse solution for this purpose, right, Yeah, and that's why
218
00:15:18.159 --> 00:15:20.919
a lot of a lot of times
the the ingestion is free. But yeah,
219
00:15:20.960 --> 00:15:28.600
but I gotta pay the other guy
to ship it. Yeah, so
220
00:15:28.840 --> 00:15:31.679
I think they become really good ingestion
tools. But now you've got this wealth
221
00:15:31.720 --> 00:15:35.440
of data that can be used again
not just for the I T teams,
222
00:15:35.039 --> 00:15:41.840
um to unify this data and remove
some of that alert fatigue in reactive responses.
223
00:15:41.879 --> 00:15:46.360
But you know, combine that with
all the different regulatory data that you
224
00:15:46.399 --> 00:15:50.919
need to keep track of. It's
it's changing quickly, right, Yeah,
225
00:15:50.000 --> 00:15:54.200
And and a lot of times you'll
find that the I'm just gonna say a
226
00:15:54.240 --> 00:15:56.240
lot of times to find that,
you know, a cloud cloud provider solution
227
00:15:56.320 --> 00:16:00.159
might be, you know, for
analytics, you know GCP, it's just
228
00:16:00.200 --> 00:16:03.399
get everything into into big Query.
I just just just let everything in the
229
00:16:03.399 --> 00:16:06.559
big quirre. It starts sounding pretty
expensive because maybe you're not familiar with how
230
00:16:06.600 --> 00:16:10.919
easy it is to expire data in
big Query, whereas in red shift just
231
00:16:10.960 --> 00:16:12.720
pull your lugs into red Shift.
That sounds insane. It's it's it's it's
232
00:16:12.759 --> 00:16:17.480
really expensive. But you know,
it's not necessarily the tool you would use
233
00:16:17.519 --> 00:16:22.200
in US. And that's kind of
where I want to kind of start towards
234
00:16:22.200 --> 00:16:26.200
wrapping up. So it is taking
all of this data, and that's where
235
00:16:26.200 --> 00:16:30.039
I want to understand, fred Enjoy, what is it. So it's bringing
236
00:16:30.120 --> 00:16:36.279
all this data into some type of
repository that may or may not be on
237
00:16:36.279 --> 00:16:38.200
one of the cloud providers. Help
me understand that just a little bit.
238
00:16:38.960 --> 00:16:41.039
Yeah, I mean it's at the
end of the day, it's et L
239
00:16:41.320 --> 00:16:45.840
and it's the same thing we do, uh, day in and day out
240
00:16:45.879 --> 00:16:49.080
on all of our analytics projects.
Instead of now bringing in data from the
241
00:16:49.240 --> 00:16:53.879
RP to understand, uh, what
did our sales pipeline look like last month
242
00:16:55.000 --> 00:16:59.960
versus this month, it's now bringing
all this telemetry data that Joey is talking
243
00:17:00.200 --> 00:17:03.799
all this log data. Um,
you know a w S access logs.
244
00:17:04.440 --> 00:17:08.559
Um, if you've got a data
warehouse or often an enterprises. I see
245
00:17:08.640 --> 00:17:15.720
multiple data warehouses who touched what?
There's a significant human capital cost of digging
246
00:17:15.759 --> 00:17:18.960
into audit bugs and all these different
things when they happen, but they need
247
00:17:18.039 --> 00:17:22.440
to be able to produce who touched
what when, what were they using?
248
00:17:22.240 --> 00:17:27.440
And all of that infrastructure that gets
built. Um, that's all data in
249
00:17:27.480 --> 00:17:30.440
telemetry data that can be brought into
one place. You know, email logs
250
00:17:30.480 --> 00:17:33.799
in Officer sixty five logs, octalogs, you could go on and on.
251
00:17:33.920 --> 00:17:40.319
Right. Yeah, I think the
biggest eye opener for me. What I
252
00:17:40.359 --> 00:17:44.279
tell people now is you know,
I was trying out a new lake formation
253
00:17:44.279 --> 00:17:48.400
blueprint thing in my sandbox in AWS, um, my second watch sandbox,
254
00:17:48.440 --> 00:17:52.400
and um, you know it's gonna
pull pull in some cloud trail logs and
255
00:17:52.480 --> 00:17:56.279
do some deucem antalymks on it because
I don't have a ton of data to
256
00:17:56.279 --> 00:17:59.720
play with when I'm doing data lake
type activities. But I've got a bunch
257
00:17:59.720 --> 00:18:03.400
of cloud trail logs in my sandbox. Well then when I forgot about it
258
00:18:03.440 --> 00:18:07.559
for a week or two, somebody
at second Watch Alergy that my sandbox seven
259
00:18:07.839 --> 00:18:12.799
uh in just a few days.
So um, companies should should think about
260
00:18:12.799 --> 00:18:17.359
the amount of data that they have
as you know, how do we get
261
00:18:17.359 --> 00:18:18.480
it all into one place. You
use it as a data lake experiment,
262
00:18:18.559 --> 00:18:22.319
use it as you know, get
it into you know it's some of the
263
00:18:22.400 --> 00:18:27.400
security stuff is sensitive. Great,
now you have a perfect a perfect playground
264
00:18:27.440 --> 00:18:33.319
to start sanitizing data or giving this
auditor access to this data, but not
265
00:18:33.440 --> 00:18:36.480
giving this person access to you know, some kind of p I I or
266
00:18:36.799 --> 00:18:40.200
people's addresses, stuff like that.
So companies do have the data, and
267
00:18:40.240 --> 00:18:44.160
they do want those data lake tools. They want to get started with it.
268
00:18:44.279 --> 00:18:45.960
Start with your own security data,
get it all in one place,
269
00:18:47.240 --> 00:18:49.240
do it as a data lake exercise
and a security exercise at the same time.
270
00:18:49.279 --> 00:18:53.680
Analytics is analytics, right, I
think that's a good point in Michael,
271
00:18:53.759 --> 00:18:56.480
you know, to add onto what
Joey said, which a spot on
272
00:18:57.359 --> 00:19:02.279
UH. You're not going to every
single use case and every single signal that
273
00:19:02.319 --> 00:19:06.359
you need right on day one,
but you've got all these different tools and
274
00:19:06.400 --> 00:19:08.920
they're going to come and go.
That's your data. Um. I mean,
275
00:19:08.960 --> 00:19:14.279
if you think about your you know, even just like you know Microsoft
276
00:19:14.279 --> 00:19:19.559
Defender, your mccafee lugs. UM, if you're migrating from let's say Officer
277
00:19:19.759 --> 00:19:25.160
sixty five to Google workspace, get
all that Officer sixty five telemetry data out
278
00:19:26.039 --> 00:19:27.960
and then once you figure out how
you want to use it, model it
279
00:19:29.000 --> 00:19:33.160
into you know, different data marks
or different data warehouses, and then from
280
00:19:33.200 --> 00:19:34.839
there you can put the dashboards on
in it. At that point, it
281
00:19:34.880 --> 00:19:41.519
doesn't matter what dashboard tool you're using, because your data is modeled and you
282
00:19:41.519 --> 00:19:42.880
can use quicksite, you can use
whatever, you can use all of them.
283
00:19:44.039 --> 00:19:48.640
Right. I want to thank you
Fred and Joey for joining us UH
284
00:19:48.680 --> 00:19:52.599
to discuss cybersecurity analytics. You know, kind of a tool that really doesn't
285
00:19:52.640 --> 00:19:57.519
exist out there and something that we
are working on. It's not it's not
286
00:19:57.720 --> 00:20:02.160
necessarily a tool that we're going to
build. It's a capability where we can
287
00:20:02.240 --> 00:20:07.920
build. So a lot of opportunity
to really evolve your security posture and how
288
00:20:08.000 --> 00:20:11.480
you look at stuff. So any
final words for the audience, Fred or
289
00:20:11.559 --> 00:20:18.119
Joey, keep in mind that it's
your data treated just like you would treat
290
00:20:18.480 --> 00:20:22.160
application data or data LAK data,
and that you already want to do analytics
291
00:20:22.200 --> 00:20:26.440
on. Don't I don't think of
it as anything other than like you said,
292
00:20:26.519 --> 00:20:30.039
E t L it's it's it's a
data pipeline. It gets processed at
293
00:20:30.039 --> 00:20:33.680
the end, or it gets analyzed
at the end. The analytics and the
294
00:20:33.720 --> 00:20:36.319
dashboards and anything all happen at the
end. Get the collection on the front
295
00:20:37.039 --> 00:20:40.640
and figure out how to how to
store it as cheaply as possible and get
296
00:20:40.680 --> 00:20:44.160
whatever you TL you need on it, and then do the analytic Yeah.
297
00:20:44.160 --> 00:20:48.279
And then for for business teams that
are spending up new governance privacy compliance teams
298
00:20:48.319 --> 00:20:53.119
within or even these capabilities within existing
uh lbs, UM, don't reinvent the
299
00:20:53.160 --> 00:20:57.920
whale. UH. Don't go down
the same path of buying very single purpose
300
00:20:57.920 --> 00:21:02.839
built tools UH that claim they can
do everything. This is your data.
301
00:21:03.240 --> 00:21:07.160
UM. There's a million different machine
learning and AI use cases that you can
302
00:21:07.160 --> 00:21:12.000
do once you have all this data. UM, be creative and uh,
303
00:21:12.279 --> 00:21:17.119
and look at this as um,
you've got a ton of data and a
304
00:21:17.160 --> 00:21:22.880
million different use cases that you can
start finally unlocking. Awesome. Well,
305
00:21:22.920 --> 00:21:25.799
Fred, thank you for joining us, Joey as well, and to the
306
00:21:25.839 --> 00:21:29.480
audience, thank you for listening to
our show. This podcast is intended to
307
00:21:29.519 --> 00:21:33.160
add value to any large enterprise that
is planning on moving to or is currently
308
00:21:33.200 --> 00:21:37.680
focused on leveraging the value of the
cloud. Send your comments or suggestions to
309
00:21:37.759 --> 00:21:47.680
cloud Crunch at second watch dot com. You've been listening to cloud Crunch with
310
00:21:47.720 --> 00:21:52.240
Michael Elliott and Fred Bliss. For
more information, check out the blog second
311
00:21:52.279 --> 00:21:57.480
watch dot com, forward slash,
cloud dash block, or reach out to
312
00:21:57.559 --> 00:22:00.279
second watch on Twitter and LinkedIn.
1
00:00:01.360 --> 00:00:08.480
Involve, Solve Evolve. Welcome to
cloud Crunch, the podcast for any large
2
00:00:08.640 --> 00:00:13.279
enterprise planning on moving to or is
in the midst of moving to the cloud.
3
00:00:13.800 --> 00:00:20.600
Hosted by the cloud computing experts from
Second Watch. Michael Elliott, Executive
4
00:00:20.640 --> 00:00:27.679
director of Marketing and Fred Bliss,
CTO of all Things Data at second Watch
5
00:00:29.480 --> 00:00:50.240
and now here are your hosts of
cloud Crunch. Welcome back to a new
6
00:00:50.280 --> 00:00:54.320
season of cloud Crunch. In this
season, we're going to focus on AWS
7
00:00:54.399 --> 00:00:59.520
Reinvent, the biggest cloud conference in
the world, kicking off November. Our
8
00:00:59.560 --> 00:01:03.439
intent is to enable you the viewer, the opportunity to immerse yourself and how
9
00:01:03.519 --> 00:01:08.000
cloud has evolved since last year on
topics like preparing and building a center of
10
00:01:08.040 --> 00:01:12.840
excellence, extracting data insights with you
know many refer to as data analytics,
11
00:01:14.439 --> 00:01:19.159
managing a cloud native environment, and
data center evacuation. Now joining me today
12
00:01:19.239 --> 00:01:25.000
is Fred Bliss, CTO of Data
Insights and Joey Brown, Senior consultant,
13
00:01:25.000 --> 00:01:29.000
both here at second Watch. Welcome
to cloud Crunch, Fred and Joey.
14
00:01:29.359 --> 00:01:34.040
Thanks Michael, happy to be here. Thanks having alright great Joey. So
15
00:01:34.840 --> 00:01:40.079
today we're gonna focus on cybersecurity analytics, and I'll have to admit not a
16
00:01:40.159 --> 00:01:42.000
subject I'm strong at. So I'm
happy to have both of you here to
17
00:01:42.120 --> 00:01:49.359
kind of discuss where this is evolving, because as we look at cybersecurity in
18
00:01:49.439 --> 00:01:53.319
my background, it is always an
extreme interest, but not a lot of
19
00:01:53.359 --> 00:01:57.840
money being paid to actually do anything
about it until there's an issue. So
20
00:01:57.879 --> 00:02:00.400
this should be a really interesting discussion. So one kind of start off with
21
00:02:00.480 --> 00:02:06.319
kind of questions around you know,
what are we talking about here from a
22
00:02:06.439 --> 00:02:10.719
cybersecurity perspective that hasn't been talked about
by every c so out there. What
23
00:02:10.759 --> 00:02:15.199
I'm seeing now is UM. You
know, as part of every data project,
24
00:02:15.199 --> 00:02:20.240
we'd always have security part of it, governance part of it. UM.
25
00:02:20.319 --> 00:02:23.800
For highly regulated industries there be a
component of risk and compliance, but
26
00:02:24.080 --> 00:02:28.759
you know, kind of checking the
box. Uh. And that's changing.
27
00:02:28.879 --> 00:02:32.240
And a big component of that is
we've got a lot of multinational global organizations.
28
00:02:32.639 --> 00:02:36.960
UH. If you look around the
world, countries like UM, you
29
00:02:37.000 --> 00:02:38.960
know India for example. You know, we've already seen the effects of g
30
00:02:39.080 --> 00:02:44.360
d p R over the last couple
of years UM in India. Now there's
31
00:02:44.520 --> 00:02:49.039
a lot of regulation kind of changing
kind of by the day with data residency
32
00:02:49.080 --> 00:02:53.840
and data sovereignty laws. Um,
you've got AI ethics, UM and transparency
33
00:02:54.520 --> 00:03:00.080
regulations coming out, executive orders coming
out. Data privacy regulations are absolutely I
34
00:03:00.080 --> 00:03:05.479
mean at the state and federal level. And now what we're seeing as organizations
35
00:03:05.560 --> 00:03:09.560
actually empowering and putting money behind UM
some of these data privacy teams. So
36
00:03:10.120 --> 00:03:15.240
the same data that's being used for
security purposes that might live in a single
37
00:03:15.360 --> 00:03:21.560
purpose UM sim tool uh now serve
a lot of other purposes. Depending on
38
00:03:21.599 --> 00:03:24.479
which hat you're wearing, Joey,
I'll let you kind of take it from
39
00:03:24.599 --> 00:03:28.520
what you're seeing on an I said, yeah, I think on the idea
40
00:03:28.560 --> 00:03:30.280
side, we see a lot of
request for you know, we want to
41
00:03:30.280 --> 00:03:34.199
get a lot of security analytics who
want to get the dashboards we want to
42
00:03:34.240 --> 00:03:43.000
get um, you know, visualization
of things UM and UM uh. Sometimes
43
00:03:43.000 --> 00:03:45.439
it seems like they maybe want to
skip some of the detective controls, like
44
00:03:45.479 --> 00:03:47.840
maybe can we just get the dashboard
of at actually collecting any of the logs
45
00:03:49.000 --> 00:03:53.800
and kind of get the cart before
the horse some of the time. Uh.
46
00:03:53.080 --> 00:03:55.319
Sometimes so you really want to make
sure you know, cover your bases
47
00:03:55.360 --> 00:03:59.280
if you collect, if you're collecting
all of the data that you can possibly
48
00:03:59.319 --> 00:04:02.240
get everywhere. Then you can be
in a position where you can even switch
49
00:04:02.280 --> 00:04:05.439
different ways to do analytics. You
can have different dashboards, you can try
50
00:04:05.439 --> 00:04:08.879
different products because the logs are all
there. But if you're starting out with
51
00:04:09.479 --> 00:04:14.080
has quicksite compared to Tableau compared to
you know, some other some other dashboard,
52
00:04:14.800 --> 00:04:16.199
You've got to get the data first, right. So, uh,
53
00:04:16.279 --> 00:04:20.439
and some of the areas for security
complainants, you know, we I'd like
54
00:04:20.439 --> 00:04:25.920
to say that there we talked about
them where they're kind of one thing,
55
00:04:25.959 --> 00:04:28.680
and then we try to tell our
clients sometimes well you should really think about
56
00:04:28.720 --> 00:04:30.800
them separately. You know, compliance
isn't really security. But some of those
57
00:04:30.800 --> 00:04:35.680
tools, like you're saying, Fred
really starting to bleed together. Databs has
58
00:04:35.839 --> 00:04:41.759
ATBs Audit Manager now and it'll it'll
check a lot of the your your audit
59
00:04:41.800 --> 00:04:45.040
logs and your I M logs and
things like that, and it'll set you
60
00:04:45.120 --> 00:04:47.759
up for those compliance reports that you
need. You know, an auditor shows
61
00:04:47.800 --> 00:04:49.839
up and says that we want to
see these resources and want to see the
62
00:04:49.879 --> 00:04:55.600
history of these resources. They're already
there. So some of the security logging
63
00:04:55.600 --> 00:05:00.439
things start to start to bleed into
in the compliance. Yeah, the whole
64
00:05:00.519 --> 00:05:05.360
um idea of what tools should I
use for dashboards is really the wrong question,
65
00:05:05.480 --> 00:05:09.879
right, I mean, it's all
about what what data should we collect
66
00:05:09.879 --> 00:05:14.160
and what signals do we care about? Because um, I mean it's not
67
00:05:14.199 --> 00:05:17.680
just dashboards, right, There's there's
a million different products that you can um
68
00:05:17.720 --> 00:05:20.319
that you can elaborate the same data
for. I imagine, right, and
69
00:05:21.519 --> 00:05:28.879
are seeing customers that have more than
one uh, that have more than one
70
00:05:28.959 --> 00:05:32.560
place where they're collecting security logs right, Honestly, not as often as I
71
00:05:32.560 --> 00:05:35.519
would like. I would I would
like it where they where people had more
72
00:05:35.759 --> 00:05:39.839
more dashboards, more more more tools, like where somebody says, well,
73
00:05:39.839 --> 00:05:43.839
we picked open search or we picked
you know this, you to this tool,
74
00:05:43.920 --> 00:05:46.800
so let's go with that. I
wish people had more flexibility to they
75
00:05:46.839 --> 00:05:49.759
have all the logs in one place
and they can try different products instead of
76
00:05:49.759 --> 00:05:53.360
focusing on when we picked this one
and it doesn't have this feature. But
77
00:05:53.399 --> 00:05:56.279
that's what we're going that, you
know, all the logs should be in
78
00:05:56.319 --> 00:05:59.319
one place and they should be able
to be consumed by whatever they want.
79
00:06:00.600 --> 00:06:03.600
And I think we've we've heard a
lot and we've recorded in prior episodes Fred
80
00:06:03.639 --> 00:06:06.959
with you know, we picked the
tool, now how do we apply it
81
00:06:08.000 --> 00:06:10.720
to all these things? But I
want to kind of go back. What
82
00:06:10.920 --> 00:06:15.120
is all the data that you can
collect and then you can bring into a
83
00:06:15.199 --> 00:06:19.079
central repository. Well when you um, you know it depending on the depending
84
00:06:19.120 --> 00:06:24.560
on the cloud and the use cases
of of freach client. There's a lot
85
00:06:24.600 --> 00:06:28.720
of inbound and outbound you know,
but um, it's not just all the
86
00:06:28.759 --> 00:06:33.959
application logging and inbound logs and network
logs and things like that. But um,
87
00:06:34.279 --> 00:06:40.519
the um if you can get again
them all in one one place you
88
00:06:40.560 --> 00:06:46.199
can start doing. You can you
can look at authentication versus authorization. You
89
00:06:46.199 --> 00:06:51.319
know, you can see failed authentication
attempts, or you can also see authenticating
90
00:06:51.360 --> 00:06:55.920
people are trying to access things that
they're not necessarily authorized to do. Or
91
00:06:55.959 --> 00:07:00.920
you could another thing that people don't
maybe bring in as often as they should,
92
00:07:00.959 --> 00:07:05.000
our DNS look ups resources they have
in an environment that are trying to
93
00:07:05.000 --> 00:07:11.800
make calls outside. Do you see
that you have some machine making road calls
94
00:07:11.839 --> 00:07:15.800
to some DNS server, some bitcoin
wallet or something like that. That's that's
95
00:07:15.800 --> 00:07:20.160
pretty suspicious. So so you know, it's not just about network firewall logs
96
00:07:20.160 --> 00:07:24.319
and laugh logs and you don't want
to look at c d M s and
97
00:07:24.360 --> 00:07:28.120
see why are we suddenly getting a
lot of traffic in India or something like
98
00:07:28.160 --> 00:07:31.160
that. Yeah. And and from
a data and analytics standpoint, UM,
99
00:07:31.319 --> 00:07:34.600
what we see business users UM,
and a lot of these compliance and risk
100
00:07:34.600 --> 00:07:40.839
teams care about is who's accessing specifically
what data? Right? UM, what
101
00:07:40.920 --> 00:07:45.279
do you think about healthcare and hip
ip? Right? UM? You need
102
00:07:45.399 --> 00:07:48.800
you need to absolutely make sure that
the right people are accessing the right data.
103
00:07:49.360 --> 00:07:54.600
And why right if you need to
go investigate and look into you know,
104
00:07:54.639 --> 00:07:59.959
a couple of different records for a
healthcare organization, UM, you need
105
00:08:00.000 --> 00:08:01.759
a reason why. You need a
trace ability of of what that look like
106
00:08:01.800 --> 00:08:05.600
at a point in time. And
so that means not just knowing, um,
107
00:08:05.680 --> 00:08:09.959
who access what, but what did
the data structures look like? Because
108
00:08:09.959 --> 00:08:13.160
you might be looking back a year, two years UM at a point in
109
00:08:13.160 --> 00:08:16.439
time of what those data structures look
like, and what those look like two
110
00:08:16.560 --> 00:08:20.160
years ago might not be what they
look like today. And so that means
111
00:08:20.560 --> 00:08:22.800
when you're collecting all this data,
UM, enjoy, I'm sure you see
112
00:08:22.839 --> 00:08:24.879
this as well. It's not about
what tools do I use? At the
113
00:08:24.959 --> 00:08:30.160
end, it's how do I start
to collect and model this data so that
114
00:08:30.240 --> 00:08:31.919
I can look at all of it
at a point in time and see,
115
00:08:33.000 --> 00:08:35.519
these are all the DNS records coming
in. It's a lot of data,
116
00:08:35.639 --> 00:08:39.559
right, But I think we're at
a point where the technology can can handle
117
00:08:39.600 --> 00:08:43.799
that well. And and some you
know, an older technology that everybody loved.
118
00:08:43.080 --> 00:08:46.840
When when you know it's all the
rage elastic search now is you know
119
00:08:48.320 --> 00:08:52.159
it's going more towards the open search
version. Um, that's that's what it
120
00:08:52.200 --> 00:08:54.120
promises. You get all your lodge
there, and I just want to look
121
00:08:54.120 --> 00:08:58.000
at this time slice. Um.
You know we have a security incident and
122
00:08:58.000 --> 00:09:01.960
we had something some blip at the
time. Um, let's look at all
123
00:09:01.960 --> 00:09:03.399
of the logs from that time and
see what was going on, and then
124
00:09:03.440 --> 00:09:05.960
you'll find out like, are we
looking at an outage? Here? Is
125
00:09:07.080 --> 00:09:09.279
a security incident? Incident? Um? So when you can really get it
126
00:09:09.320 --> 00:09:13.159
down to a specific times life and
start looking at all the logs there,
127
00:09:13.720 --> 00:09:16.240
nobody wants to look at network flow
log as well. Nobody I want to
128
00:09:16.279 --> 00:09:18.320
hang out with. But um,
but when when you have it in the
129
00:09:18.399 --> 00:09:24.159
last search and you can just narrow
it down to one one tiny times lives
130
00:09:24.200 --> 00:09:28.440
you can you can see here's the
network traffic, everything that's happening in this
131
00:09:28.480 --> 00:09:35.600
one one or two minutes. That
can really shorten the cycle for your response
132
00:09:35.639 --> 00:09:41.600
time and a detective, you know, all your incident response plans and stuff
133
00:09:41.639 --> 00:09:45.279
like that. Joey, let me
let me ask you a quick question.
134
00:09:45.320 --> 00:09:48.279
I mean security, This is not
a new topic, at least from a
135
00:09:48.320 --> 00:09:54.559
security perspective. So what's different with
this capability that doesn't already exist? And
136
00:09:54.600 --> 00:10:00.919
how do you maybe to add on
to that to UM? What uh are
137
00:10:01.240 --> 00:10:05.320
you seeing multiple like I guess,
multiple different teams managing multiple systems? So
138
00:10:05.360 --> 00:10:11.120
are there different security response teams depending
on which wind a business or application or
139
00:10:11.399 --> 00:10:16.919
Cleveland cloud? Uh? Sort of
like you'll have people that do UM.
140
00:10:16.080 --> 00:10:20.519
You know, here's our instant response
plan and they're thinking about it. You
141
00:10:20.519 --> 00:10:24.519
know, they go through a lot
of exercise where we've got a VM somewhere
142
00:10:24.639 --> 00:10:28.480
and our incidet's response plan is,
Okay, we're going to isolate this VM
143
00:10:28.519 --> 00:10:31.639
and we'll go through drills like that. Okay, we find out that we're
144
00:10:31.639 --> 00:10:33.919
gonta learned that there's something funny going
on with this VM. It's making strange
145
00:10:33.960 --> 00:10:37.519
calls. We're going to isolate it, we're gonna investigate it, we're gonna
146
00:10:37.559 --> 00:10:39.679
find out what the root cause was. We're going to try to put it
147
00:10:39.320 --> 00:10:43.840
UH in a quarantine environment and that
it's used to go through those exercises with
148
00:10:45.240 --> 00:10:50.039
um VM. But when it's UM
data in your cloud storage, it's in
149
00:10:50.480 --> 00:10:56.200
S three or it's in cloud storage
and it's there's an ex filtration event and
150
00:10:56.279 --> 00:11:00.399
now there's nothing to isolate. You're
not you have if you're in VM mode
151
00:11:00.679 --> 00:11:05.000
and you're not thinking more like across
services, it could be you want to
152
00:11:05.000 --> 00:11:09.080
try to apply those response plans to
different things, and then the other you
153
00:11:09.080 --> 00:11:13.480
will have a different team or maybe
the same team doing a different exercise for
154
00:11:13.559 --> 00:11:18.159
like UM disaster recovery over disaster recovery, here's my set of things, or
155
00:11:18.159 --> 00:11:22.000
we go through this checklift. So
even if even sometimes it's the same team,
156
00:11:22.000 --> 00:11:26.919
it's they sort of think about it
has two totally different activities. But
157
00:11:26.799 --> 00:11:33.200
those drills should be opportunities for you
to look at to be captured all the
158
00:11:33.240 --> 00:11:35.200
logs, you know, not just
here's here's the here's how we would isolate
159
00:11:35.240 --> 00:11:39.000
a VM, or here's how we
would here's how we would look at some
160
00:11:39.120 --> 00:11:43.039
data expiltration event, but why wouldn't
where would our logs be for these events?
161
00:11:43.639 --> 00:11:46.080
And then how would we how would
we be able to do security analytics
162
00:11:46.879 --> 00:11:52.679
on a drill? I think that's
spot on. And what I'm seeing and
163
00:11:52.759 --> 00:11:58.320
hearing UM from C suite and UH
interactual lever level folks at enterprises is you've
164
00:11:58.360 --> 00:12:03.519
got a lot of these UM goal
purpose sim tools and legacy ones that just
165
00:12:03.559 --> 00:12:07.480
don't work for modern security teams.
UM. You know, Joey, when
166
00:12:07.519 --> 00:12:11.879
you think about UM a big enterprise
customer that's got I mean, you've got
167
00:12:11.879 --> 00:12:15.399
Azure with Sentinel, You've got a
WS with their solution, You've got GCP
168
00:12:15.879 --> 00:12:20.879
now with their acquisition of Mania and
there in their solution. All of that
169
00:12:20.000 --> 00:12:24.600
data is being ingested into those systems. But now you need to ingest the
170
00:12:24.679 --> 00:12:28.799
data from all those systems in your
system, right. Well yeah, when
171
00:12:28.799 --> 00:12:33.279
you ask them, yes, if
you ask UH Azure Sentinel, they'll say,
172
00:12:33.519 --> 00:12:37.159
no, exactly ingested all over here. We can take all of it.
173
00:12:37.200 --> 00:12:39.240
You know when we when we when
we look at as your sentinel,
174
00:12:39.240 --> 00:12:41.120
they're like, here's how you ship
your aw S looks, there's how you
175
00:12:41.120 --> 00:12:43.480
ship cloud trail to sentinel. That's
how you ship everything, give it all
176
00:12:43.519 --> 00:12:46.440
the up. So, um,
it's easy for us to say, hey,
177
00:12:46.440 --> 00:12:48.879
you should just record everything, you
know, hey, get all your
178
00:12:48.919 --> 00:12:52.960
logs everywhere. But when you've got
your ad A d over here, and
179
00:12:52.960 --> 00:12:54.799
then you've got your AWS environment over
there, and then you've got a data
180
00:12:54.840 --> 00:12:58.679
team on g CP, Yeah,
it does get into a situation. Well,
181
00:12:58.759 --> 00:13:03.279
now we kind of do have to
pick one central pository for for logs
182
00:13:03.320 --> 00:13:09.840
maybe, and we do see unfortunately
a lot of companies bok at the cost
183
00:13:09.919 --> 00:13:15.759
of log storage. You know,
it's you can get into dozens of dollars
184
00:13:15.799 --> 00:13:18.639
that they didn't plan for, you
know, or sometimes hundreds of dollars that
185
00:13:18.679 --> 00:13:22.200
they didn't plan to spend that quarter. It's but in the grand scheme of
186
00:13:22.240 --> 00:13:26.960
what their their cloud spend is log
stories should be the least of their concerns.
187
00:13:28.159 --> 00:13:31.799
You know, it compresses. You
really only need to know you can
188
00:13:31.799 --> 00:13:35.279
figure out your your life cycle of
that data. If we're talking about security
189
00:13:35.320 --> 00:13:37.279
incidents, yeah, you might need
to hang onto it for years, but
190
00:13:37.320 --> 00:13:41.720
you only need to keep it pretty
hot for thirty days. So don't don't
191
00:13:41.799 --> 00:13:45.840
don't don't skimp on the on the
log storage, please enjoy. Just to
192
00:13:45.879 --> 00:13:50.039
be clear, to be clear,
when you say hundreds of dollars, there's
193
00:13:50.039 --> 00:13:52.159
a few more zeros after that.
Well, not necessarily, it'll be like
194
00:13:52.320 --> 00:13:56.759
you'll have a calm with people.
Well, you gotta turn on your flow
195
00:13:56.799 --> 00:14:00.919
logs and this this VPC or something
so we can get inbound and outbound accepts
196
00:14:00.919 --> 00:14:01.720
and rejects and everything for the network
thing. No no, no, no,
197
00:14:01.720 --> 00:14:03.720
no no, that's a sandbox.
That's a devil. That's a deav
198
00:14:03.840 --> 00:14:09.399
environment. We don't want to pay, and we want to pay an extra
199
00:14:09.480 --> 00:14:13.600
hundred dollars. It's just dead environment. The people who take over your account
200
00:14:13.639 --> 00:14:16.159
don't care what kind of environment it
is. They want to spend a bitcoin
201
00:14:16.200 --> 00:14:18.600
miners, they don't, they don't
care for this. This is a deav
202
00:14:18.600 --> 00:14:20.240
account. Don't spend a bitcoin miners
there, you know. So you you
203
00:14:20.320 --> 00:14:24.840
want all of that, all of
the security logging in all of your environments,
204
00:14:24.879 --> 00:14:26.960
not just the not just the problem. I think that's a great point.
205
00:14:28.200 --> 00:14:31.360
Um. The cost of storage is
something you know, I see that
206
00:14:31.399 --> 00:14:37.440
I think is kind of a left
behind thought of you know, bad experiences
207
00:14:37.600 --> 00:14:41.000
of getting hit with huge spending bills
because you've got geo, replicated data of
208
00:14:41.039 --> 00:14:45.159
the same data, copied multiple times, and bad governance policies, and you
209
00:14:45.200 --> 00:14:46.720
weren't really looking into it. But
you're right at the end of the day,
210
00:14:46.720 --> 00:14:50.000
all of this. If you've got
it in Calm their storage, and
211
00:14:50.039 --> 00:14:52.519
you've got it well modeled, it
compresses and it becomes a tiny little fraction
212
00:14:52.559 --> 00:14:56.559
and one. And I thought the
cost uh, and you know, shipping
213
00:14:56.600 --> 00:15:01.679
logs back and forth between clouds.
The I heard an interesting anecdote that,
214
00:15:01.480 --> 00:15:05.480
um, if you're using Sentinel,
if you're using AWS solution and just you
215
00:15:05.480 --> 00:15:09.320
know, shipping them back and forth, the eat risk costs of doing that
216
00:15:11.279 --> 00:15:15.879
has got a significantly outweigh the costs
of storing it within your own data lake
217
00:15:15.919 --> 00:15:18.159
and data warehouse solution for this purpose, right, Yeah, and that's why
218
00:15:18.159 --> 00:15:20.919
a lot of a lot of times
the the ingestion is free. But yeah,
219
00:15:20.960 --> 00:15:28.600
but I gotta pay the other guy
to ship it. Yeah, so
220
00:15:28.840 --> 00:15:31.679
I think they become really good ingestion
tools. But now you've got this wealth
221
00:15:31.720 --> 00:15:35.440
of data that can be used again
not just for the I T teams,
222
00:15:35.039 --> 00:15:41.840
um to unify this data and remove
some of that alert fatigue in reactive responses.
223
00:15:41.879 --> 00:15:46.360
But you know, combine that with
all the different regulatory data that you
224
00:15:46.399 --> 00:15:50.919
need to keep track of. It's
it's changing quickly, right, Yeah,
225
00:15:50.000 --> 00:15:54.200
And and a lot of times you'll
find that the I'm just gonna say a
226
00:15:54.240 --> 00:15:56.240
lot of times to find that,
you know, a cloud cloud provider solution
227
00:15:56.320 --> 00:16:00.159
might be, you know, for
analytics, you know GCP, it's just
228
00:16:00.200 --> 00:16:03.399
get everything into into big Query.
I just just just let everything in the
229
00:16:03.399 --> 00:16:06.559
big quirre. It starts sounding pretty
expensive because maybe you're not familiar with how
230
00:16:06.600 --> 00:16:10.919
easy it is to expire data in
big Query, whereas in red shift just
231
00:16:10.960 --> 00:16:12.720
pull your lugs into red Shift.
That sounds insane. It's it's it's it's
232
00:16:12.759 --> 00:16:17.480
really expensive. But you know,
it's not necessarily the tool you would use
233
00:16:17.519 --> 00:16:22.200
in US. And that's kind of
where I want to kind of start towards
234
00:16:22.200 --> 00:16:26.200
wrapping up. So it is taking
all of this data, and that's where
235
00:16:26.200 --> 00:16:30.039
I want to understand, fred Enjoy, what is it. So it's bringing
236
00:16:30.120 --> 00:16:36.279
all this data into some type of
repository that may or may not be on
237
00:16:36.279 --> 00:16:38.200
one of the cloud providers. Help
me understand that just a little bit.
238
00:16:38.960 --> 00:16:41.039
Yeah, I mean it's at the
end of the day, it's et L
239
00:16:41.320 --> 00:16:45.840
and it's the same thing we do, uh, day in and day out
240
00:16:45.879 --> 00:16:49.080
on all of our analytics projects.
Instead of now bringing in data from the
241
00:16:49.240 --> 00:16:53.879
RP to understand, uh, what
did our sales pipeline look like last month
242
00:16:55.000 --> 00:16:59.960
versus this month, it's now bringing
all this telemetry data that Joey is talking
243
00:17:00.200 --> 00:17:03.799
all this log data. Um,
you know a w S access logs.
244
00:17:04.440 --> 00:17:08.559
Um, if you've got a data
warehouse or often an enterprises. I see
245
00:17:08.640 --> 00:17:15.720
multiple data warehouses who touched what?
There's a significant human capital cost of digging
246
00:17:15.759 --> 00:17:18.960
into audit bugs and all these different
things when they happen, but they need
247
00:17:18.039 --> 00:17:22.440
to be able to produce who touched
what when, what were they using?
248
00:17:22.240 --> 00:17:27.440
And all of that infrastructure that gets
built. Um, that's all data in
249
00:17:27.480 --> 00:17:30.440
telemetry data that can be brought into
one place. You know, email logs
250
00:17:30.480 --> 00:17:33.799
in Officer sixty five logs, octalogs, you could go on and on.
251
00:17:33.920 --> 00:17:40.319
Right. Yeah, I think the
biggest eye opener for me. What I
252
00:17:40.359 --> 00:17:44.279
tell people now is you know,
I was trying out a new lake formation
253
00:17:44.279 --> 00:17:48.400
blueprint thing in my sandbox in AWS, um, my second watch sandbox,
254
00:17:48.440 --> 00:17:52.400
and um, you know it's gonna
pull pull in some cloud trail logs and
255
00:17:52.480 --> 00:17:56.279
do some deucem antalymks on it because
I don't have a ton of data to
256
00:17:56.279 --> 00:17:59.720
play with when I'm doing data lake
type activities. But I've got a bunch
257
00:17:59.720 --> 00:18:03.400
of cloud trail logs in my sandbox. Well then when I forgot about it
258
00:18:03.440 --> 00:18:07.559
for a week or two, somebody
at second Watch Alergy that my sandbox seven
259
00:18:07.839 --> 00:18:12.799
uh in just a few days.
So um, companies should should think about
260
00:18:12.799 --> 00:18:17.359
the amount of data that they have
as you know, how do we get
261
00:18:17.359 --> 00:18:18.480
it all into one place. You
use it as a data lake experiment,
262
00:18:18.559 --> 00:18:22.319
use it as you know, get
it into you know it's some of the
263
00:18:22.400 --> 00:18:27.400
security stuff is sensitive. Great,
now you have a perfect a perfect playground
264
00:18:27.440 --> 00:18:33.319
to start sanitizing data or giving this
auditor access to this data, but not
265
00:18:33.440 --> 00:18:36.480
giving this person access to you know, some kind of p I I or
266
00:18:36.799 --> 00:18:40.200
people's addresses, stuff like that.
So companies do have the data, and
267
00:18:40.240 --> 00:18:44.160
they do want those data lake tools. They want to get started with it.
268
00:18:44.279 --> 00:18:45.960
Start with your own security data,
get it all in one place,
269
00:18:47.240 --> 00:18:49.240
do it as a data lake exercise
and a security exercise at the same time.
270
00:18:49.279 --> 00:18:53.680
Analytics is analytics, right, I
think that's a good point in Michael,
271
00:18:53.759 --> 00:18:56.480
you know, to add onto what
Joey said, which a spot on
272
00:18:57.359 --> 00:19:02.279
UH. You're not going to every
single use case and every single signal that
273
00:19:02.319 --> 00:19:06.359
you need right on day one,
but you've got all these different tools and
274
00:19:06.400 --> 00:19:08.920
they're going to come and go.
That's your data. Um. I mean,
275
00:19:08.960 --> 00:19:14.279
if you think about your you know, even just like you know Microsoft
276
00:19:14.279 --> 00:19:19.559
Defender, your mccafee lugs. UM, if you're migrating from let's say Officer
277
00:19:19.759 --> 00:19:25.160
sixty five to Google workspace, get
all that Officer sixty five telemetry data out
278
00:19:26.039 --> 00:19:27.960
and then once you figure out how
you want to use it, model it
279
00:19:29.000 --> 00:19:33.160
into you know, different data marks
or different data warehouses, and then from
280
00:19:33.200 --> 00:19:34.839
there you can put the dashboards on
in it. At that point, it
281
00:19:34.880 --> 00:19:41.519
doesn't matter what dashboard tool you're using, because your data is modeled and you
282
00:19:41.519 --> 00:19:42.880
can use quicksite, you can use
whatever, you can use all of them.
283
00:19:44.039 --> 00:19:48.640
Right. I want to thank you
Fred and Joey for joining us UH
284
00:19:48.680 --> 00:19:52.599
to discuss cybersecurity analytics. You know, kind of a tool that really doesn't
285
00:19:52.640 --> 00:19:57.519
exist out there and something that we
are working on. It's not it's not
286
00:19:57.720 --> 00:20:02.160
necessarily a tool that we're going to
build. It's a capability where we can
287
00:20:02.240 --> 00:20:07.920
build. So a lot of opportunity
to really evolve your security posture and how
288
00:20:08.000 --> 00:20:11.480
you look at stuff. So any
final words for the audience, Fred or
289
00:20:11.559 --> 00:20:18.119
Joey, keep in mind that it's
your data treated just like you would treat
290
00:20:18.480 --> 00:20:22.160
application data or data LAK data,
and that you already want to do analytics
291
00:20:22.200 --> 00:20:26.440
on. Don't I don't think of
it as anything other than like you said,
292
00:20:26.519 --> 00:20:30.039
E t L it's it's it's a
data pipeline. It gets processed at
293
00:20:30.039 --> 00:20:33.680
the end, or it gets analyzed
at the end. The analytics and the
294
00:20:33.720 --> 00:20:36.319
dashboards and anything all happen at the
end. Get the collection on the front
295
00:20:37.039 --> 00:20:40.640
and figure out how to how to
store it as cheaply as possible and get
296
00:20:40.680 --> 00:20:44.160
whatever you TL you need on it, and then do the analytic Yeah.
297
00:20:44.160 --> 00:20:48.279
And then for for business teams that
are spending up new governance privacy compliance teams
298
00:20:48.319 --> 00:20:53.119
within or even these capabilities within existing
uh lbs, UM, don't reinvent the
299
00:20:53.160 --> 00:20:57.920
whale. UH. Don't go down
the same path of buying very single purpose
300
00:20:57.920 --> 00:21:02.839
built tools UH that claim they can
do everything. This is your data.
301
00:21:03.240 --> 00:21:07.160
UM. There's a million different machine
learning and AI use cases that you can
302
00:21:07.160 --> 00:21:12.000
do once you have all this data. UM, be creative and uh,
303
00:21:12.279 --> 00:21:17.119
and look at this as um,
you've got a ton of data and a
304
00:21:17.160 --> 00:21:22.880
million different use cases that you can
start finally unlocking. Awesome. Well,
305
00:21:22.920 --> 00:21:25.799
Fred, thank you for joining us, Joey as well, and to the
306
00:21:25.839 --> 00:21:29.480
audience, thank you for listening to
our show. This podcast is intended to
307
00:21:29.519 --> 00:21:33.160
add value to any large enterprise that
is planning on moving to or is currently
308
00:21:33.200 --> 00:21:37.680
focused on leveraging the value of the
cloud. Send your comments or suggestions to
309
00:21:37.759 --> 00:21:47.680
cloud Crunch at second watch dot com. You've been listening to cloud Crunch with
310
00:21:47.720 --> 00:21:52.240
Michael Elliott and Fred Bliss. For
more information, check out the blog second
311
00:21:52.279 --> 00:21:57.480
watch dot com, forward slash,
cloud dash block, or reach out to
312
00:21:57.559 --> 00:22:00.279
second watch on Twitter and LinkedIn.
