1
00:00:00,000 --> 00:00:14,200
We'll kick it off here.

2
00:00:14,200 --> 00:00:17,760
Hope everyone's ready for Christmas and the holidays.

3
00:00:17,760 --> 00:00:22,760
But good afternoon, everyone, or good morning if you're joining from the West Coast.

4
00:00:22,760 --> 00:00:23,760
What is today, Andres?

5
00:00:23,760 --> 00:00:30,440
It's Wednesday, December 13th and welcome to the latest episode of Security in 45.

6
00:00:30,440 --> 00:00:37,360
We've got a great show for you today as we're going to talk about an introduction to securing

7
00:00:37,360 --> 00:00:38,360
the cloud.

8
00:00:38,360 --> 00:00:43,560
If you've been on the show before, no slides, just good conversation.

9
00:00:43,560 --> 00:00:46,320
That's kind of the motto for the show.

10
00:00:46,320 --> 00:00:48,800
Hope you all had a great Thanksgiving.

11
00:00:48,800 --> 00:00:50,360
Christmas right around the corner.

12
00:00:50,360 --> 00:00:54,160
Down in Miami, are you doing the traditional Thanksgiving?

13
00:00:54,160 --> 00:00:57,520
Did you do the traditional Thanksgiving meal or how was it?

14
00:00:57,520 --> 00:00:58,520
I actually did.

15
00:00:58,520 --> 00:01:03,240
It was, I believe it was the second time I made, we made turkey.

16
00:01:03,240 --> 00:01:07,960
I'm probably not going to take all the credit for that one.

17
00:01:07,960 --> 00:01:14,280
It was good that night, but the next day it was terrible.

18
00:01:14,280 --> 00:01:16,040
No good leftovers there.

19
00:01:16,040 --> 00:01:19,200
Yeah, but no, Mike, this is nice.

20
00:01:19,200 --> 00:01:21,280
Really I'm very excited for today.

21
00:01:21,280 --> 00:01:25,960
We do have two great experts on cloud security.

22
00:01:25,960 --> 00:01:33,520
We have Sudhir Desai and Edmund Nicholas from the security team of Cisco.

23
00:01:33,520 --> 00:01:39,440
Two technical solution experts and this is going to be super exciting.

24
00:01:39,440 --> 00:01:45,080
We're going to pretty much just talk about, you know, high level, how do we approach security

25
00:01:45,080 --> 00:01:46,560
in the cloud.

26
00:01:46,560 --> 00:01:54,360
And basically today is going to be part one of the two parts that we have on cloud security.

27
00:01:54,360 --> 00:01:56,320
So today we're going to cover some basics.

28
00:01:56,320 --> 00:02:03,880
We're going to go over a few pain points, things that we see in the cloud every day.

29
00:02:03,880 --> 00:02:08,980
And then the next section, the next session, which is going to be next month, we're going

30
00:02:08,980 --> 00:02:13,720
to talk about one of our own Cisco's product called multi-cloud defense.

31
00:02:13,720 --> 00:02:18,280
We're going to touch a little bit on that today, but we're going to just leave it for

32
00:02:18,280 --> 00:02:19,280
the next one.

33
00:02:19,280 --> 00:02:21,960
So it's a great topic today.

34
00:02:21,960 --> 00:02:22,960
Well, outstanding.

35
00:02:22,960 --> 00:02:28,160
You know, in terms of cloud security as a topic, I think it's something that people

36
00:02:28,160 --> 00:02:34,880
traditionally have less knowledge and awareness about compared to like a traditional on-premise

37
00:02:34,880 --> 00:02:41,720
security stack, you know, in terms of vulnerabilities, how do we even approach that in terms of

38
00:02:41,720 --> 00:02:44,040
security or do we even need to secure it?

39
00:02:44,040 --> 00:02:47,720
So we're going to have a good conversation today.

40
00:02:47,720 --> 00:02:54,120
Now like you mentioned, this is an introduction and we will follow up next session with more

41
00:02:54,120 --> 00:02:55,560
detail.

42
00:02:55,560 --> 00:02:58,040
Like you mentioned, Andre's multi-cloud defense.

43
00:02:58,040 --> 00:03:01,200
Ed and Sudhir, we're so excited to have you guys.

44
00:03:01,200 --> 00:03:03,600
Sudhir, I've known you a long time at Cisco.

45
00:03:03,600 --> 00:03:09,840
You came in years ago with the Sourcefire for Firepower Acquisition and got to work

46
00:03:09,840 --> 00:03:10,840
with you in TAC.

47
00:03:10,840 --> 00:03:11,840
You're like a legend.

48
00:03:11,840 --> 00:03:14,640
You've been working in the security field for over 25 years.

49
00:03:14,640 --> 00:03:16,640
So this is going to be a great show.

50
00:03:16,640 --> 00:03:21,360
Let's kick it off and we will get right to it.

51
00:03:21,360 --> 00:03:26,000
Ed, first question we'll throw out to you.

52
00:03:26,000 --> 00:03:27,600
Everybody's moving to the cloud.

53
00:03:27,600 --> 00:03:32,800
Like what's with the trend of all these companies moving resources into the cloud?

54
00:03:32,800 --> 00:03:34,200
Clearly there are benefits there.

55
00:03:34,200 --> 00:03:35,440
Otherwise we wouldn't be do it.

56
00:03:35,440 --> 00:03:37,480
I'll open that up to you.

57
00:03:37,480 --> 00:03:45,320
Yeah, so first, thanks Mike, Andre's for having me and Sudhir here to talk about cloud security.

58
00:03:45,320 --> 00:03:50,640
Really when I have these discussions around cloud security with folks, we really talk

59
00:03:50,640 --> 00:03:54,960
about like, all right, what is the as a service model?

60
00:03:54,960 --> 00:03:57,120
How do we consume this module?

61
00:03:57,120 --> 00:04:00,100
Because that's really the difference here.

62
00:04:00,100 --> 00:04:05,760
So at the very highest level, like the benefits of that as a service module is probably like

63
00:04:05,760 --> 00:04:09,400
software as a service or SaaS as some people might say.

64
00:04:09,400 --> 00:04:12,720
This is where you can just consume applications as needed.

65
00:04:12,720 --> 00:04:17,840
We have things like Workday and SAP and Salesforce and there's thousands of billions of other

66
00:04:17,840 --> 00:04:21,320
SaaS platforms out there, but you just consume them.

67
00:04:21,320 --> 00:04:25,520
This is very beneficial because you don't have to deploy anything like that.

68
00:04:25,520 --> 00:04:31,640
The second thing is what about like maybe platform as a service, like PaaS we call them.

69
00:04:31,640 --> 00:04:33,120
So think of it this way.

70
00:04:33,120 --> 00:04:34,760
Like database as a service.

71
00:04:34,760 --> 00:04:37,500
That is a platform as a service.

72
00:04:37,500 --> 00:04:39,520
So how do we consume that?

73
00:04:39,520 --> 00:04:41,760
Think of something like a MongoDB.

74
00:04:41,760 --> 00:04:43,680
That's a platform as a service.

75
00:04:43,680 --> 00:04:48,480
They'll provide you the database and you can just go use the database any way you want.

76
00:04:48,480 --> 00:04:53,880
Build your own tables, do all that type of thing, which is basically a platform and you

77
00:04:53,880 --> 00:04:56,360
use it, you consume it as a service.

78
00:04:56,360 --> 00:04:59,680
And then we're all familiar with infrastructure as a service.

79
00:04:59,680 --> 00:05:04,360
And really what we think over here is like, we have virtual private clouds or VNets.

80
00:05:04,360 --> 00:05:06,080
We have networks.

81
00:05:06,080 --> 00:05:07,440
We have databases.

82
00:05:07,440 --> 00:05:10,320
We have instances, that type of thing.

83
00:05:10,320 --> 00:05:15,440
But we can spend these things out and down as we need them and consume them only as we

84
00:05:15,440 --> 00:05:19,240
want them and be charged only as we need them.

85
00:05:19,240 --> 00:05:23,120
So that's really the benefit of going to the cloud.

86
00:05:23,120 --> 00:05:27,000
It's the service model that it provides.

87
00:05:27,000 --> 00:05:31,320
That's really awesome.

88
00:05:31,320 --> 00:05:33,440
Yeah, no.

89
00:05:33,440 --> 00:05:34,440
It's interesting.

90
00:05:34,440 --> 00:05:41,640
I mean, what I get to see about cloud is so many things combined, so many possibilities,

91
00:05:41,640 --> 00:05:45,000
so many nice things and cool things that you can do.

92
00:05:45,000 --> 00:05:52,240
So that always resonates with me because even though cloud has been around for a long time,

93
00:05:52,240 --> 00:05:58,860
I don't know if it's probably 10 years, 15 years or something like that, but it's kind

94
00:05:58,860 --> 00:06:03,840
of new for everybody, unless you're dedicated on working on cloud.

95
00:06:03,840 --> 00:06:05,520
So that was really good.

96
00:06:05,520 --> 00:06:07,720
Thank you for sharing that.

97
00:06:07,720 --> 00:06:12,440
And one thing I think is interesting is how you just mentioned there's different ways

98
00:06:12,440 --> 00:06:14,160
companies are using it.

99
00:06:14,160 --> 00:06:18,360
You mentioned maybe just using a particular application as a service or doing that whole

100
00:06:18,360 --> 00:06:19,920
platform as a service.

101
00:06:19,920 --> 00:06:25,280
So I guess one of the benefits there I see is flexibility in terms of how your company

102
00:06:25,280 --> 00:06:28,600
operates and you can truly get out of it what you want.

103
00:06:28,600 --> 00:06:32,680
If you just want something as a service that's already made and you just get an account and

104
00:06:32,680 --> 00:06:37,760
you can log in or do we want to kind of customize this with that platform as a service and get

105
00:06:37,760 --> 00:06:38,760
that deployed?

106
00:06:38,760 --> 00:06:40,760
Yeah, that's correct.

107
00:06:40,760 --> 00:06:41,760
Awesome.

108
00:06:41,760 --> 00:06:45,840
Well, Sudhir, I have the next question for you.

109
00:06:45,840 --> 00:06:50,320
This one's going to be just a comparison.

110
00:06:50,320 --> 00:06:56,120
Actually, we want you to go over, if you don't mind, the three main cloud providers that

111
00:06:56,120 --> 00:07:03,680
we get to see and what are the differences if there's anything similar between them?

112
00:07:03,680 --> 00:07:07,240
But if you can share your experience with us, that'll be awesome.

113
00:07:07,240 --> 00:07:08,240
Yeah.

114
00:07:08,240 --> 00:07:16,480
So in the US, at least the three major cloud providers I see are Google, Amazon and Microsoft

115
00:07:16,480 --> 00:07:22,840
with Google Cloud Platform, AWS and Azure respectively.

116
00:07:22,840 --> 00:07:28,320
By the US there are a couple, I know in East Asia, Alibaba or Alibaba is one of the major

117
00:07:28,320 --> 00:07:29,320
ones.

118
00:07:29,320 --> 00:07:32,800
And in Eastern Europe, we have Yandex.

119
00:07:32,800 --> 00:07:37,120
So those are two others that are kind of to be aware of.

120
00:07:37,120 --> 00:07:43,520
But definitely here in the US and between the three, I would say they are much more

121
00:07:43,520 --> 00:07:49,440
similar than they are different because as we were talking about spinning up applications,

122
00:07:49,440 --> 00:07:55,120
doing different things like that, all three of them give you the platform and say, hey,

123
00:07:55,120 --> 00:07:57,560
give us your application, we'll host it.

124
00:07:57,560 --> 00:08:02,480
Or they may have applications already existing from different vendors and all of them do

125
00:08:02,480 --> 00:08:04,080
essentially the same thing.

126
00:08:04,080 --> 00:08:12,880
But the main differences, and I think we'll chat about this a bit more further on in the

127
00:08:12,880 --> 00:08:17,880
webinar, but a few of the main differences are that if you want something simple that

128
00:08:17,880 --> 00:08:23,520
you can just spin up immediately without having to know a lot, definitely Azure could be a

129
00:08:23,520 --> 00:08:27,240
way to go just because of how it's architected on the back end.

130
00:08:27,240 --> 00:08:33,440
Or if you want something that's a bit more network control centric, or if you want something

131
00:08:33,440 --> 00:08:38,800
that gives you more controls, Google Cloud is definitely one that does that.

132
00:08:38,800 --> 00:08:43,720
Or like we have at Cisco with the majority of our applications being built first for

133
00:08:43,720 --> 00:08:49,360
AWS just because we know how to do that and we know how to work with AWS.

134
00:08:49,360 --> 00:08:59,040
And all three of them also provide the ability to do scaling and do load balancing across

135
00:08:59,040 --> 00:09:06,880
instances such as Ed was working on a project earlier, I think it was with one of the Cisco

136
00:09:06,880 --> 00:09:14,720
Lives where he presented on clustering within AWS with firewalls.

137
00:09:14,720 --> 00:09:19,960
So you can just spin up a whole cluster and say, hey, give all these firewalls, you can

138
00:09:19,960 --> 00:09:25,480
have much smaller firewalls so your cost is lower, but you have multiples of them.

139
00:09:25,480 --> 00:09:29,040
And it round robins the traffic between those firewalls.

140
00:09:29,040 --> 00:09:31,280
Or you can do load-based scaling.

141
00:09:31,280 --> 00:09:39,200
So if you have the need to rapidly expand your firewalling capabilities, great.

142
00:09:39,200 --> 00:09:45,760
You hit a button or you get an alarm coming in from the system saying, well, your load

143
00:09:45,760 --> 00:09:48,600
is going above 80%.

144
00:09:48,600 --> 00:09:50,360
Give me some more firewalls.

145
00:09:50,360 --> 00:09:58,720
And so Terraform as the example for the automation side of it can go and spin up more firewalls

146
00:09:58,720 --> 00:10:04,600
for you and then bring them back down once your load lowers.

147
00:10:04,600 --> 00:10:12,360
So I think those are pretty much the benefits and then the little differences here and there.

148
00:10:12,360 --> 00:10:15,640
It's interesting hearing like, yeah, it's a good point that I guess when you say they

149
00:10:15,640 --> 00:10:21,240
are more similar as opposed to, I guess maybe that's the way I think of it is they're offering

150
00:10:21,240 --> 00:10:22,960
the same basic service.

151
00:10:22,960 --> 00:10:26,100
It's just how they're customizing it a little bit differently.

152
00:10:26,100 --> 00:10:31,920
I mean, in terms of one offer has a bigger catalog of services and the other can have

153
00:10:31,920 --> 00:10:35,160
their little unique parts about them.

154
00:10:35,160 --> 00:10:39,880
Do you guys find that customers are using all three?

155
00:10:39,880 --> 00:10:45,360
One customer, how common is it to be like, in my organization, I'm spreading out that

156
00:10:45,360 --> 00:10:48,640
multi-cloud environment?

157
00:10:48,640 --> 00:10:55,120
I mean, I see obviously in the larger enterprise, diversity is definitely good.

158
00:10:55,120 --> 00:10:57,600
You don't want to have all your eggs in one basket.

159
00:10:57,600 --> 00:11:03,360
And so a lot of my enterprise customers are saying, hey, we want to diversify in two,

160
00:11:03,360 --> 00:11:08,040
three, maybe even four different public clouds or even private cloud.

161
00:11:08,040 --> 00:11:10,520
So think of it that way.

162
00:11:10,520 --> 00:11:12,720
So it's very normal for us to span across all.

163
00:11:12,720 --> 00:11:20,240
That's why they have security to be able to reach into all three or four or five clouds

164
00:11:20,240 --> 00:11:27,120
is very important, especially in the larger organizations.

165
00:11:27,120 --> 00:11:31,920
And I was going to say, I've seen pretty much the same thing, especially after AWS East

166
00:11:31,920 --> 00:11:34,260
went down a few months ago.

167
00:11:34,260 --> 00:11:41,000
A couple of my customers said, well, we had everything in AWS that went very poorly for

168
00:11:41,000 --> 00:11:42,000
us.

169
00:11:42,000 --> 00:11:45,240
Let's diversify and get out into the other clouds.

170
00:11:45,240 --> 00:11:56,000
I will say that the word multi-cloud started to make trends at that time.

171
00:11:56,000 --> 00:11:59,680
What about cloud infrastructure?

172
00:11:59,680 --> 00:12:05,080
I think it's confusing.

173
00:12:05,080 --> 00:12:08,000
How do packets work in the cloud, for example?

174
00:12:08,000 --> 00:12:14,240
If I'm real familiar with just the traditional IP based network, is that how the cloud works?

175
00:12:14,240 --> 00:12:15,760
How's my data working there?

176
00:12:15,760 --> 00:12:19,760
How do we talk about or learn about those differences?

177
00:12:19,760 --> 00:12:21,800
Well, a little bit.

178
00:12:21,800 --> 00:12:29,440
So IP is still IP and packets, datagrams are still packets and datagrams, but there is

179
00:12:29,440 --> 00:12:30,440
a big difference.

180
00:12:30,440 --> 00:12:35,980
And it's the way you want to consume it, especially when we're talking about securing the cloud,

181
00:12:35,980 --> 00:12:38,660
but specifically what are you securing?

182
00:12:38,660 --> 00:12:44,200
Because them constructs that you have in a traditional network, like you have your segments

183
00:12:44,200 --> 00:12:49,000
and your VLANs, your route domains, you have your NAT, you have all this stuff that you're

184
00:12:49,000 --> 00:12:50,520
used to having.

185
00:12:50,520 --> 00:12:54,200
And we kind of have that all in public cloud as well, but it's different.

186
00:12:54,200 --> 00:12:55,200
It's virtualized.

187
00:12:55,200 --> 00:12:59,440
There's some things that you're not going to get, like there's no layer two in public

188
00:12:59,440 --> 00:13:00,440
cloud.

189
00:13:00,440 --> 00:13:03,120
So we have to take that into consideration.

190
00:13:03,120 --> 00:13:10,040
But really, them boxes, them IP addresses, them VLANs, them static things that we're

191
00:13:10,040 --> 00:13:15,000
used to configuring, they're not really there in the public cloud.

192
00:13:15,000 --> 00:13:16,560
They're served a little bit differently.

193
00:13:16,560 --> 00:13:18,560
So we serve services, right?

194
00:13:18,560 --> 00:13:23,280
That segment, that segmentation inside a public cloud is a little bit different, right?

195
00:13:23,280 --> 00:13:27,120
So in VPCs, like you think of a traditional network, right?

196
00:13:27,120 --> 00:13:31,920
I have a segment, I have a VLAN, I have a subnet inside there, but you're not going

197
00:13:31,920 --> 00:13:37,080
to be able to, you're not only going to be using them resources inside them VPCs, right?

198
00:13:37,080 --> 00:13:40,800
You're going to be using resources that are extended way behind that.

199
00:13:40,800 --> 00:13:44,080
Like we already talked about database as a service, right?

200
00:13:44,080 --> 00:13:49,240
We have database, you're going to be using maybe some serverless functions.

201
00:13:49,240 --> 00:13:52,240
You might be using like managed Kubernetes.

202
00:13:52,240 --> 00:13:54,600
You may be using container services.

203
00:13:54,600 --> 00:13:59,700
Like these are all things that we were able to spin up and spin down.

204
00:13:59,700 --> 00:14:03,640
And obviously things that you can just build inside.

205
00:14:03,640 --> 00:14:08,280
Like when I talk about the difference between what I get with AWS as compared to what I

206
00:14:08,280 --> 00:14:14,040
get with Microsoft Azure is a lot of my services in Microsoft are going to be your standard

207
00:14:14,040 --> 00:14:15,680
Microsoft services, right?

208
00:14:15,680 --> 00:14:20,080
I'm going to get Exchange, I'm going to get AD inside the cloud and not have to worry

209
00:14:20,080 --> 00:14:21,080
about it.

210
00:14:21,080 --> 00:14:25,200
But in AWS, I might be more dev-centric, so more DevOps.

211
00:14:25,200 --> 00:14:29,400
I might be using CI-CD code pipeline inside there.

212
00:14:29,400 --> 00:14:33,960
Like these are things that we need to start to understand how to secure.

213
00:14:33,960 --> 00:14:39,760
A lot of info on that one.

214
00:14:39,760 --> 00:14:41,200
And it's, we get to see it.

215
00:14:41,200 --> 00:14:44,160
We get to see a confusion.

216
00:14:44,160 --> 00:14:48,800
I do remember when you mentioned the layer two piece, no ARP.

217
00:14:48,800 --> 00:14:52,520
Yeah, it was interesting.

218
00:14:52,520 --> 00:15:00,840
I know there's a few things in differences between the networking inside of Azure and

219
00:15:00,840 --> 00:15:05,800
AWS, but that's interesting stuff to know.

220
00:15:05,800 --> 00:15:11,360
And it's interesting, like, because as Ed, you were given that overview there, I was

221
00:15:11,360 --> 00:15:14,560
kind of thinking about, yeah, you do hear about differences like with load balancing

222
00:15:14,560 --> 00:15:22,480
with firewalls and certain caveats when you do that type of feature in the cloud in terms

223
00:15:22,480 --> 00:15:27,160
of, yeah, like you said, there's no layer two network and you got to think about it

224
00:15:27,160 --> 00:15:28,160
differently.

225
00:15:28,160 --> 00:15:29,160
Definitely.

226
00:15:29,160 --> 00:15:33,880
Yeah, well, think about it like I said, in every EC2 instance, there's more likely that

227
00:15:33,880 --> 00:15:37,440
EC2 instance isn't just serving up one application.

228
00:15:37,440 --> 00:15:41,760
That EC2 instance is probably doing multiple things, probably has containers built inside

229
00:15:41,760 --> 00:15:42,760
of it.

230
00:15:42,760 --> 00:15:44,240
You need to know how to secure that.

231
00:15:44,240 --> 00:15:46,960
You need to know what's going on inside of that device.

232
00:15:46,960 --> 00:15:51,720
So a firewall outside there or an IPS device outside is only going to give you north-south

233
00:15:51,720 --> 00:15:52,720
visibility.

234
00:15:52,720 --> 00:15:56,800
It's not going to give you what's going on east-west inside of the application itself.

235
00:15:56,800 --> 00:15:59,560
Yeah, that's true.

236
00:15:59,560 --> 00:16:04,080
Yes, people's moving to the cloud, but what about this?

237
00:16:04,080 --> 00:16:07,840
And I don't know if everybody just asked the same question.

238
00:16:07,840 --> 00:16:13,080
I think we do at some point, but we think is our data safe?

239
00:16:13,080 --> 00:16:17,680
Can we assume that this thing going to be always available?

240
00:16:17,680 --> 00:16:25,440
I know we mentioned some of the fails of multiple clouds and things like that, but what do you

241
00:16:25,440 --> 00:16:26,440
think?

242
00:16:26,440 --> 00:16:34,240
If you can share with us when somebody is thinking about that, what would you say?

243
00:16:34,240 --> 00:16:43,280
I would say that there is no responsibility on the cloud vendor to keep it safe unless

244
00:16:43,280 --> 00:16:49,740
you have entered into a specific contract with the cloud vendor to provide any sort

245
00:16:49,740 --> 00:16:52,640
of security.

246
00:16:52,640 --> 00:16:58,120
Going about this another way, I know in the federal space there are specific clouds, like

247
00:16:58,120 --> 00:17:05,840
specific instances of AWS cloud or Azure that do provide a bit more security so that the

248
00:17:05,840 --> 00:17:13,240
frameworks that those clouds have to meet, the security frameworks can be actually in

249
00:17:13,240 --> 00:17:14,240
implemented.

250
00:17:14,240 --> 00:17:19,640
So, there are additional pieces of security that are provided by the vendor in that case.

251
00:17:19,640 --> 00:17:22,760
But for the most part, your data is your data.

252
00:17:22,760 --> 00:17:29,060
You need to make sure that, again, utilizing the principle of least privilege, you need

253
00:17:29,060 --> 00:17:37,120
to make sure that only the people, only the objects, only the other scripts that need

254
00:17:37,120 --> 00:17:42,360
to have access to that specific data have access to that specific data.

255
00:17:42,360 --> 00:17:49,840
And I think in the cloud, a lot of it, we just kind of think of like, yeah, we're just

256
00:17:49,840 --> 00:17:53,760
tossing stuff to the cloud and it's accessible from anywhere.

257
00:17:53,760 --> 00:18:01,240
But then we forget that the confidentiality, integrity, and availability of the data is

258
00:18:01,240 --> 00:18:03,840
a big balancing game.

259
00:18:03,840 --> 00:18:10,480
The most secure computer is in the Marianas trench encased in 10 feet of concrete.

260
00:18:10,480 --> 00:18:14,040
But that's not feasible for availability of the data.

261
00:18:14,040 --> 00:18:22,280
So you definitely need to make sure that when you put data into the cloud, that you're putting

262
00:18:22,280 --> 00:18:27,160
acceptable industry recognized security around that.

263
00:18:27,160 --> 00:18:31,720
We have a bunch of components here or products here at Cisco that can help with that.

264
00:18:31,720 --> 00:18:34,040
I'm not going to get onto the Cisco piece.

265
00:18:34,040 --> 00:18:40,440
But it's like whatever you do put the data, yeah, as I mentioned before, whatever you

266
00:18:40,440 --> 00:18:46,240
put the data into the cloud, you have to make sure that you are taking responsibility for

267
00:18:46,240 --> 00:18:50,520
that data and not just leaving it around.

268
00:18:50,520 --> 00:18:56,520
Whether that's encryption, whether that's something like a web application firewall

269
00:18:56,520 --> 00:19:05,280
front end in front of your applications, or if there are any data recovery sites you might

270
00:19:05,280 --> 00:19:09,240
use, let's say, hey, I have three or four instances of this data.

271
00:19:09,240 --> 00:19:15,440
We were talking about it before in terms of the multiple clouds where AWS may go down,

272
00:19:15,440 --> 00:19:23,240
but do we have business continuity elsewhere in AWS with another region or Google Cloud

273
00:19:23,240 --> 00:19:26,480
or Azure for the US market?

274
00:19:26,480 --> 00:19:35,040
But yeah, it's definitely on you, the consumer, to ensure your data is protected at all times.

275
00:19:35,040 --> 00:19:43,960
And I think it's important to know that there's a few, I don't want to say just procedures

276
00:19:43,960 --> 00:19:52,640
or things, but just frameworks, like the one, the customer responsibility matrix and the

277
00:19:52,640 --> 00:19:54,840
framework for cloud architecture.

278
00:19:54,840 --> 00:19:58,920
So yeah, those are things that exist in the cloud world.

279
00:19:58,920 --> 00:20:06,160
And I guess it's interesting and important to know them.

280
00:20:06,160 --> 00:20:10,640
I just, before we get on to the next question briefly, I just think that's maybe the biggest

281
00:20:10,640 --> 00:20:15,720
takeaway from today's conversation is, yeah, don't assume your data is safe in the cloud.

282
00:20:15,720 --> 00:20:21,120
Like, and it's just further evidence of having your network and security teams working well

283
00:20:21,120 --> 00:20:22,120
together.

284
00:20:22,120 --> 00:20:27,280
Like it's one thing to make that data available, but like, man, don't make any assumptions

285
00:20:27,280 --> 00:20:28,280
there.

286
00:20:28,280 --> 00:20:29,280
Excellent.

287
00:20:29,280 --> 00:20:30,280
Okay.

288
00:20:30,280 --> 00:20:38,440
Since the cloud is not completely safe, how about some examples of recent attacks maybe

289
00:20:38,440 --> 00:20:43,480
that some of us or some people on the call here today have maybe heard about, maybe on

290
00:20:43,480 --> 00:20:48,200
the news, any that you'd want to touch on there?

291
00:20:48,200 --> 00:20:51,040
And Mike, so there's a couple of things a couple of years ago.

292
00:20:51,040 --> 00:20:56,080
I don't know if you guys remember, there's a big data breach at Facebook where they had

293
00:20:56,080 --> 00:21:04,200
like 530 million user accounts compromised and nothing Facebook had to pay out $5 billion

294
00:21:04,200 --> 00:21:05,880
in damages or something like that.

295
00:21:05,880 --> 00:21:06,880
Something crazy.

296
00:21:06,880 --> 00:21:11,640
And that was just exposed from a vulnerability within one of their applications.

297
00:21:11,640 --> 00:21:17,680
Now, obviously vulnerability management is a big piece, but how do we tie that together

298
00:21:17,680 --> 00:21:19,920
within the cloud itself?

299
00:21:19,920 --> 00:21:27,680
Like taking another use case here, like a few years before that, inside that Alibaba

300
00:21:27,680 --> 00:21:32,000
cloud, they got hacked for like a billion user accounts.

301
00:21:32,000 --> 00:21:37,160
And that was done because of like their own misconfigured cloud resources had like no

302
00:21:37,160 --> 00:21:38,960
authentication or authorization.

303
00:21:38,960 --> 00:21:42,400
They just went in and took it.

304
00:21:42,400 --> 00:21:48,960
And then obviously without the break any chops, but LinkedIn also leaked like 500 million

305
00:21:48,960 --> 00:21:55,720
profiles, but that was from just like a bot on the web, just scraping data from it.

306
00:21:55,720 --> 00:22:03,560
So the idea here is we really need to be able to secure the cloud itself, but like we also

307
00:22:03,560 --> 00:22:08,840
need to secure what's in the cloud by using things like posture management.

308
00:22:08,840 --> 00:22:13,760
So cloud security posture management is a big thing inside of cloud.

309
00:22:13,760 --> 00:22:17,800
And what that does is allow you to see exactly what is exposed.

310
00:22:17,800 --> 00:22:23,400
What's the attack surface of the cloud resources that you have out there?

311
00:22:23,400 --> 00:22:28,600
And then also take it a step further, adding in the attack surface management as well.

312
00:22:28,600 --> 00:22:31,760
So what's that blast radius within that cloud?

313
00:22:31,760 --> 00:22:35,120
How far can an attacker actually get into your environment?

314
00:22:35,120 --> 00:22:41,640
I always take a say, like, I mean, we talked about this the other day, but when you have

315
00:22:41,640 --> 00:22:46,840
like an S3 bucket that's just exposed to the public, that's pretty easy to figure out.

316
00:22:46,840 --> 00:22:51,400
So, you know, any cloud security posture management is going to say, yeah, don't do this.

317
00:22:51,400 --> 00:22:52,400
This is bad.

318
00:22:52,400 --> 00:22:53,400
Right.

319
00:22:53,400 --> 00:22:58,080
But what happens if that S3 bucket is then attached to an EC2 instance that is attached

320
00:22:58,080 --> 00:23:03,040
to a web front end that is exposing that, and there's some sort of vulnerability within

321
00:23:03,040 --> 00:23:07,800
there that allows all the data in your S3 bucket to be exposed on that web front end.

322
00:23:07,800 --> 00:23:12,760
Like, these are things that we need to map together in cloud security posture management,

323
00:23:12,760 --> 00:23:18,880
attack surface management, and a whole bunch of other products and solutions that I'll

324
00:23:18,880 --> 00:23:25,000
talk about maybe a little bit later will kind of give you more information around what's

325
00:23:25,000 --> 00:23:29,880
going on around your application and your cloud.

326
00:23:29,880 --> 00:23:31,880
Yeah.

327
00:23:31,880 --> 00:23:40,400
I know we've talked internally at some point about those things, like, for example, and

328
00:23:40,400 --> 00:23:48,360
we gave a really good example, but I've also seen a lot of S3 buckets being publicly available

329
00:23:48,360 --> 00:23:53,640
just because they were misconfigured or there were some sloppy configurations that, you

330
00:23:53,640 --> 00:23:58,320
know, were not finished, were not locked down in the ass.

331
00:23:58,320 --> 00:24:04,240
And then we get to see a lot of data being exfiltrated from those customers.

332
00:24:04,240 --> 00:24:12,160
And at that point, it's part of that message about the customer responsibility, right?

333
00:24:12,160 --> 00:24:14,160
So it's a risk.

334
00:24:14,160 --> 00:24:15,960
Definitely it's a risk.

335
00:24:15,960 --> 00:24:21,480
And that number, like the Facebook one, like $5 billion, it's just incredible to think

336
00:24:21,480 --> 00:24:22,480
about.

337
00:24:22,480 --> 00:24:28,000
I mean, talk about saving money by being proactive with your security as opposed to paying after.

338
00:24:28,000 --> 00:24:30,000
I mean, it's incredible.

339
00:24:30,000 --> 00:24:31,000
Yeah.

340
00:24:31,000 --> 00:24:34,600
Facebook's big, but $5 billion stings Facebook.

341
00:24:34,600 --> 00:24:35,600
Yeah.

342
00:24:35,600 --> 00:24:42,200
This is going to be a super open question, but what do we do?

343
00:24:42,200 --> 00:24:43,880
What are the first things that we do?

344
00:24:43,880 --> 00:24:48,400
We start thinking of when we start deploying these things, workloads to the cloud and things

345
00:24:48,400 --> 00:24:49,520
like that.

346
00:24:49,520 --> 00:24:51,240
How do we prevent attacks?

347
00:24:51,240 --> 00:24:56,000
How do we secure resources that we have inside of the cloud?

348
00:24:56,000 --> 00:24:57,000
What are options?

349
00:24:57,000 --> 00:25:02,000
If we see that as an alternative.

350
00:25:02,000 --> 00:25:03,280
Yeah.

351
00:25:03,280 --> 00:25:06,240
So I can take that really quickly.

352
00:25:06,240 --> 00:25:10,840
I would say utilize the tools in the cloud.

353
00:25:10,840 --> 00:25:16,880
Each cloud provider has a set of security tools that are built for it.

354
00:25:16,880 --> 00:25:21,800
And then if you have multiple clouds, or even if you have a single cloud provider, but you

355
00:25:21,800 --> 00:25:31,280
want to normalize that your risk exposure across your entire infrastructure, you can

356
00:25:31,280 --> 00:25:35,880
go with a product like Multi-Cloud Defense, which we'll talk about.

357
00:25:35,880 --> 00:25:40,560
I think we have another session coming up on that, but something like Multi-Cloud Defense,

358
00:25:40,560 --> 00:25:47,560
which gives you the ability to say, this is what our security posture needs to be.

359
00:25:47,560 --> 00:25:52,380
We want that security posture to be, I guess I just gave a thumbs up somehow.

360
00:25:52,380 --> 00:25:57,580
We want that security posture to be available across our entire environment, across each

361
00:25:57,580 --> 00:26:03,560
one of our public cloud vendors that we're utilizing.

362
00:26:03,560 --> 00:26:11,640
And so utilizing something like that as well to ensure that unified posture is a good thing.

363
00:26:11,640 --> 00:26:15,400
Also multi-factor authentication is always good.

364
00:26:15,400 --> 00:26:22,560
I know here at Cisco, it was a bit of a headache once we migrated to multi-factor with Duo,

365
00:26:22,560 --> 00:26:30,960
but now that we've really gotten into, now that we've really seen how easy it is to use

366
00:26:30,960 --> 00:26:35,640
multi-factor authentication once it has been set up, because I think that's the biggest

367
00:26:35,640 --> 00:26:38,160
hurdle is actually getting everything set up.

368
00:26:38,160 --> 00:26:44,860
Once you get a good workflow going, even through multi-factor authentication, it doesn't take

369
00:26:44,860 --> 00:26:51,120
much longer than what it did before to actually get, to have that data available to you.

370
00:26:51,120 --> 00:26:55,360
And again, as I said before, it's definitely about that balance between availability and

371
00:26:55,360 --> 00:27:04,560
security or availability and confidentiality, where as long as you have access and you're

372
00:27:04,560 --> 00:27:09,360
ensuring that access is controlled, that you're good to go.

373
00:27:09,360 --> 00:27:15,240
I will also say that on the backend, it would also help something like multi-cloud defense

374
00:27:15,240 --> 00:27:23,860
or any other log storage that you can have to go through and check your audit logs and

375
00:27:23,860 --> 00:27:28,820
make sure that you have a product that will help you looking through audit logs and flagging

376
00:27:28,820 --> 00:27:36,280
any anomalous behavior, such as a service account that you don't expect to change permissions

377
00:27:36,280 --> 00:27:38,120
on a file as an example.

378
00:27:38,120 --> 00:27:40,880
Well, what if it does change permissions on a file?

379
00:27:40,880 --> 00:27:48,320
You may never know unless you have something on the backend saying, hey, we see this behavior,

380
00:27:48,320 --> 00:27:54,200
we think it's bad, let's escalate an incident for it.

381
00:27:54,200 --> 00:27:58,840
I think one thing that's coming around within Cisco at least that we can do it, that we

382
00:27:58,840 --> 00:28:06,400
can help use is like FDR, where it can push events to the foreground that you may want

383
00:28:06,400 --> 00:28:11,320
to say, you should look at this behavior, it doesn't look good to us, let's just make

384
00:28:11,320 --> 00:28:19,860
sure it is actually good or it's bad, and then we can go forward and do more of a deep

385
00:28:19,860 --> 00:28:22,960
dive investigation on it.

386
00:28:22,960 --> 00:28:25,040
That's true.

387
00:28:25,040 --> 00:28:32,520
I think we do have some interesting capabilities inside of FDR that can see that traffic, and

388
00:28:32,520 --> 00:28:37,800
they can raise events or incidents and things like that, so that's a pretty cool interesting

389
00:28:37,800 --> 00:28:40,560
plug on XDR.

390
00:28:40,560 --> 00:28:44,120
I like that idea, Sudhir, that's like a good proactive approach.

391
00:28:44,120 --> 00:28:48,840
Ed gave the example of Facebook having to pay all that money back, but to your point,

392
00:28:48,840 --> 00:28:53,880
you were just bringing up something that's proactive.

393
00:28:53,880 --> 00:28:59,360
Maybe it's just anomalous, it's an incident, or maybe it's an event, not a true incident,

394
00:28:59,360 --> 00:29:02,360
but we're just being proactive about it.

395
00:29:02,360 --> 00:29:07,800
The other thing that just came to my mind is with something like XDR, whether it's Cisco

396
00:29:07,800 --> 00:29:14,280
XDR or not, but combining all our telemetry from the on-prem that we're familiar with,

397
00:29:14,280 --> 00:29:23,320
but also with the cloud and those flow logs that we've been talking, so very cool.

398
00:29:23,320 --> 00:29:29,600
I think we've been having a really interesting conversation, and if you want to learn more

399
00:29:29,600 --> 00:29:34,800
about this type of thing, how did you guys get started, or where do you recommend someone

400
00:29:34,800 --> 00:29:35,800
listening to this?

401
00:29:35,800 --> 00:29:42,040
I want to learn a little bit more about the cloud, how it works, and securing it specifically.

402
00:29:42,040 --> 00:29:47,240
Where's a good place to get started without getting bombarded with too many details?

403
00:29:47,240 --> 00:29:57,000
Yeah, I always tell people to go to the Cloud Security Alliance homepage, so that's cloudsecurityalliance.org.

404
00:29:57,000 --> 00:30:03,080
This will get you up and running as far as anything cloud, anything cloud-native.

405
00:30:03,080 --> 00:30:08,960
It'll give you best practices, it'll go through cloud compliance, it'll give you top threats.

406
00:30:08,960 --> 00:30:14,560
It'll give you all that type of stuff if you're taking a look and digging into, hey, what's

407
00:30:14,560 --> 00:30:19,880
the cloud actually exposed to?

408
00:30:19,880 --> 00:30:25,000
And then obviously the other ones is SANS, because SANS.org does a really good job of

409
00:30:25,000 --> 00:30:31,000
bringing together some very detailed information around cloud security awareness, cloud security

410
00:30:31,000 --> 00:30:38,560
awareness training, DevSecOps, AppSec, so application security.

411
00:30:38,560 --> 00:30:43,720
The one thing that people, I think, get a little bit confused around is what's the difference

412
00:30:43,720 --> 00:30:47,560
between DevOps, DevSecOps, and application security?

413
00:30:47,560 --> 00:30:56,040
They're all really different things, but DevSecOps is really just part of DevOps, but it's got

414
00:30:56,040 --> 00:30:58,240
its own little niche.

415
00:30:58,240 --> 00:31:03,800
And then the other thing that I really want people to start to dive into, and I would

416
00:31:03,800 --> 00:31:10,000
say the biggest thing, is cloud-native application protection.

417
00:31:10,000 --> 00:31:15,600
So I talked a little bit earlier about cloud security posture management, attack surface

418
00:31:15,600 --> 00:31:16,600
management.

419
00:31:16,600 --> 00:31:24,120
Well, a lot of tools out there today are geared towards taking them, too, as well as workload

420
00:31:24,120 --> 00:31:34,840
protection, container Kubernetes protection, API security, CI, CD security, repo security,

421
00:31:34,840 --> 00:31:39,520
all this stuff, code security, application security, and rolling it in the one platform

422
00:31:39,520 --> 00:31:46,480
so you can start pivoting through all these things into one interface.

423
00:31:46,480 --> 00:31:52,760
So now, if I have an EC2 instance that's running Kubernetes master or is running a Kubernetes

424
00:31:52,760 --> 00:31:56,920
stuff, and it has containers running on it, and it's got workloads running it, and then

425
00:31:56,920 --> 00:32:01,880
workloads have APIs, and then APIs and code are running through a CI, CD pipeline, you

426
00:32:01,880 --> 00:32:07,600
want to stitch this all together and give you one holistic view of all the security

427
00:32:07,600 --> 00:32:08,600
in there.

428
00:32:08,600 --> 00:32:15,840
And that's what CNAP, cloud-native application protection, is going to be able to give you.

429
00:32:15,840 --> 00:32:21,840
So the first one you mentioned was cloudsecurityalliance.org, and then CNAP.

430
00:32:21,840 --> 00:32:24,720
What does CNAP stand for one more time?

431
00:32:24,720 --> 00:32:28,440
Cloud-native application protection platform.

432
00:32:28,440 --> 00:32:35,480
Write this down because I'm going to check these out as well, so thank you.

433
00:32:35,480 --> 00:32:37,640
We always get to learn so much when we do this.

434
00:32:37,640 --> 00:32:38,640
I know.

435
00:32:38,640 --> 00:32:39,640
I love these.

436
00:32:39,640 --> 00:32:40,640
All right.

437
00:32:40,640 --> 00:32:46,960
I guess we're going to move to the next one, and this is going to be pretty much a segue

438
00:32:46,960 --> 00:32:54,040
into multi-cloud defenses that we're going to ponder off to our next episode or next

439
00:32:54,040 --> 00:32:55,040
month.

440
00:32:55,040 --> 00:33:03,520
But I know everybody on this call knows that Cisco came up recently with a new thing called

441
00:33:03,520 --> 00:33:08,400
the Cloud Protection Suite.

442
00:33:08,400 --> 00:33:14,600
This is if you can tell us a little bit about what...

443
00:33:14,600 --> 00:33:22,160
And this is just going to be a point product inside of this suite of software for our customers.

444
00:33:22,160 --> 00:33:27,560
But if you don't mind, Siddharth, if you can expand on the multi-cloud defense, what is

445
00:33:27,560 --> 00:33:28,560
it?

446
00:33:28,560 --> 00:33:33,760
We're going to expand more on it, but if you can give us a little teaser on that and add

447
00:33:33,760 --> 00:33:38,840
if at the end you want to add something, feel free to add it.

448
00:33:38,840 --> 00:33:40,560
Yeah, sure.

449
00:33:40,560 --> 00:33:48,680
So multi-cloud defense, what I mentioned briefly before, Cisco, as you guys know, loves snapping

450
00:33:48,680 --> 00:33:52,280
up companies that provide extra security for us.

451
00:33:52,280 --> 00:34:00,160
I came from an acquisition 10 years ago now, 11 years ago now, and we're always trying

452
00:34:00,160 --> 00:34:04,640
to innovate as well as purchase to innovate.

453
00:34:04,640 --> 00:34:11,640
And so recently we purchased Valtix, which essentially is the same thing as multi-cloud

454
00:34:11,640 --> 00:34:13,320
defense.

455
00:34:13,320 --> 00:34:23,840
And their three main products were protecting Oracle Cloud, AWS, as well as Azure Cloud.

456
00:34:23,840 --> 00:34:29,320
And that's kind of the background.

457
00:34:29,320 --> 00:34:33,560
And I will say if you haven't heard of it or you're not familiar with it, and maybe

458
00:34:33,560 --> 00:34:41,960
you're familiar with Tetration or Secure Workload, where we have agents that run inside of a

459
00:34:41,960 --> 00:34:49,040
virtualization environment that dictate the firewall status and the firewall rules of

460
00:34:49,040 --> 00:34:54,180
every single workload running within that environment, that's essentially what multi-cloud

461
00:34:54,180 --> 00:34:57,600
defense, what Valtix is and what they do.

462
00:34:57,600 --> 00:35:03,120
And so what we can do is we say, hey, actually, as I mentioned before regarding that single

463
00:35:03,120 --> 00:35:10,800
security posture, normalizing your risk profile, it allows you to say, cool, we have a set

464
00:35:10,800 --> 00:35:12,680
of APIs on the side.

465
00:35:12,680 --> 00:35:13,680
We're going to go in.

466
00:35:13,680 --> 00:35:17,000
We're going to set up some virtual private containers.

467
00:35:17,000 --> 00:35:21,280
We're going to set up some networks inside of the cloud.

468
00:35:21,280 --> 00:35:27,480
And we're going to pass all the data through, make sure that it is secure, make sure that

469
00:35:27,480 --> 00:35:33,120
the firewalls in those pieces of software do what they need to do and make sure that

470
00:35:33,120 --> 00:35:35,240
your data is safe.

471
00:35:35,240 --> 00:35:41,360
That's kind of the 10,000 foot view of multi-cloud defense.

472
00:35:41,360 --> 00:35:42,360
But yeah.

473
00:35:42,360 --> 00:35:47,640
I always like to tell people the multi-cloud defense is take all them firewalls.

474
00:35:47,640 --> 00:35:50,840
You can't take a physical firewall and stick it in the cloud.

475
00:35:50,840 --> 00:35:53,840
It doesn't fit.

476
00:35:53,840 --> 00:36:01,800
The idea is take a security appliance, put it into your cloud, cloud natively.

477
00:36:01,800 --> 00:36:05,120
What that means is let's use cloud constructs to build it.

478
00:36:05,120 --> 00:36:08,120
Let's not stick a firewall in there.

479
00:36:08,120 --> 00:36:15,440
And then let's allow that to then inspect all the data as it's going through your VPCs

480
00:36:15,440 --> 00:36:22,360
and between VPCs, ingress, egress, everything, and then apply things like traditional firewall

481
00:36:22,360 --> 00:36:30,640
rules, but also web application firewall, IPS, AV, anti-malware, so on and so on.

482
00:36:30,640 --> 00:36:34,720
This way you don't have to worry about stitching, routing stuff through a firewall anymore.

483
00:36:34,720 --> 00:36:36,320
It just does it natively.

484
00:36:36,320 --> 00:36:41,200
And then you have that one policy over all three different clouds.

485
00:36:41,200 --> 00:36:45,120
So AWS, Azure, GCP, you have one policy.

486
00:36:45,120 --> 00:36:50,640
And then you have all your dynamic rules and dynamic objects bubbled up into that one policy.

487
00:36:50,640 --> 00:36:52,520
And then you're ready to go.

488
00:36:52,520 --> 00:36:56,120
And you deploy the whole thing via automation.

489
00:36:56,120 --> 00:37:01,160
Does that one, just to kind of round this up, does the one policy mean I don't have

490
00:37:01,160 --> 00:37:06,480
to know about the details of each individual cloud?

491
00:37:06,480 --> 00:37:07,480
Does that help with that?

492
00:37:07,480 --> 00:37:08,480
Okay.

493
00:37:08,480 --> 00:37:09,480
Yes, exactly.

494
00:37:09,480 --> 00:37:10,480
Okay.

495
00:37:10,480 --> 00:37:16,480
Well, that's going to be a great, great topic for next month, but a nice little overview

496
00:37:16,480 --> 00:37:17,480
there.

497
00:37:17,480 --> 00:37:18,480
Quick time check.

498
00:37:18,480 --> 00:37:19,480
We're looking good, Andres.

499
00:37:19,480 --> 00:37:26,800
I think we've got time for some dad jokes here if you guys are okay with this.

500
00:37:26,800 --> 00:37:27,880
Now let's get right to it.

501
00:37:27,880 --> 00:37:34,720
So really interesting question I was thinking about, because we're talking about data storage

502
00:37:34,720 --> 00:37:37,480
in the cloud.

503
00:37:37,480 --> 00:37:39,480
And I've heard people ask about this.

504
00:37:39,480 --> 00:37:45,840
Is it true that if it's raining, that we need to be a little concerned about our data getting

505
00:37:45,840 --> 00:37:49,200
wet and potentially corrupt?

506
00:37:49,200 --> 00:37:54,680
Yeah, no, I think you definitely have to worry about that.

507
00:37:54,680 --> 00:38:04,240
I don't know how to kind of explain how that happens, but if it rains, you're screwed.

508
00:38:04,240 --> 00:38:09,520
So now that seems to me like we need a product for that, like some type of waterproof thing

509
00:38:09,520 --> 00:38:13,080
that can go around our resources in the cloud.

510
00:38:13,080 --> 00:38:14,080
Excellent.

511
00:38:14,080 --> 00:38:15,080
Okay.

512
00:38:15,080 --> 00:38:16,640
We already have it.

513
00:38:16,640 --> 00:38:17,640
It's called Umbrella.

514
00:38:17,640 --> 00:38:20,560
All right.

515
00:38:20,560 --> 00:38:31,080
I hope I don't mess this one up, but here's a million dollar idea probably.

516
00:38:31,080 --> 00:38:33,840
If anybody going to steal it, just let me know.

517
00:38:33,840 --> 00:38:36,920
But is it a good idea or maybe a stupid idea?

518
00:38:36,920 --> 00:38:42,880
But what about a security application, security app where if you cough on your computer, your

519
00:38:42,880 --> 00:38:48,240
antivirus will tell you, will start running and tell you if you're sick or not.

520
00:38:48,240 --> 00:38:53,240
What about that?

521
00:38:53,240 --> 00:38:55,280
I think you're a little bit late to that one, man.

522
00:38:55,280 --> 00:38:58,080
I think Apple already does it.

523
00:38:58,080 --> 00:39:01,120
So you can cough on your phone and it'll be like, oh, you're contagious.

524
00:39:01,120 --> 00:39:02,120
Stay away from others.

525
00:39:02,120 --> 00:39:03,120
Yeah.

526
00:39:03,120 --> 00:39:07,120
I think it's more like COVID one time.

527
00:39:07,120 --> 00:39:13,920
That's a great idea, but we're going to think of something else if we want to retire early.

528
00:39:13,920 --> 00:39:14,920
Yeah, I know.

529
00:39:14,920 --> 00:39:15,920
Someone's already done that.

530
00:39:15,920 --> 00:39:25,000
One thing, some people, it's been like a trend, a lot of people going vegan and even just

531
00:39:25,000 --> 00:39:29,640
like vegetarian, but have you heard about that new technique people are doing when they

532
00:39:29,640 --> 00:39:37,040
go to the grocery store so that they don't walk down the canned meat aisle and get tempted?

533
00:39:37,040 --> 00:39:44,160
They have, it's called like a spam filter.

534
00:39:44,160 --> 00:39:45,160
That's terrible.

535
00:39:45,160 --> 00:39:48,680
Who doesn't like spam?

536
00:39:48,680 --> 00:39:49,680
I know.

537
00:39:49,680 --> 00:39:51,880
I mean, I think even vegetarians should like it.

538
00:39:51,880 --> 00:39:52,880
Exactly.

539
00:39:52,880 --> 00:39:53,880
It's fake.

540
00:39:53,880 --> 00:39:57,600
Who doesn't eat that?

541
00:39:57,600 --> 00:39:59,600
All right.

542
00:39:59,600 --> 00:40:01,520
All right.

543
00:40:01,520 --> 00:40:07,040
The next one is going to be fun, but have you guys heard about this cyber criminal that

544
00:40:07,040 --> 00:40:09,360
was able to get into heaven?

545
00:40:09,360 --> 00:40:15,120
Funny thing is that he apparently found the password to the gate that had not been changed

546
00:40:15,120 --> 00:40:17,320
in about 2000 years.

547
00:40:17,320 --> 00:40:18,800
Oh man.

548
00:40:18,800 --> 00:40:24,240
You know, you would think they'd have better security than that.

549
00:40:24,240 --> 00:40:29,120
Or at least like, or at least like an MFA, even with the bad password, if they have basic

550
00:40:29,120 --> 00:40:34,040
MFA in heaven, they still wouldn't have been able to get in.

551
00:40:34,040 --> 00:40:37,120
I got to go confession just from hearing that.

552
00:40:37,120 --> 00:40:38,120
Right.

553
00:40:38,120 --> 00:40:41,120
What do we got?

554
00:40:41,120 --> 00:40:45,240
Time for two more, you think?

555
00:40:45,240 --> 00:40:46,240
We started a little bit late.

556
00:40:46,240 --> 00:40:47,240
What do you think, Andre?

557
00:40:47,240 --> 00:40:50,760
Two more?

558
00:40:50,760 --> 00:40:54,280
What would sting more?

559
00:40:54,280 --> 00:40:59,880
If you were like, you know, paying ransomware because you did not have your security in

560
00:40:59,880 --> 00:41:05,000
layers or having to peel actual layers of onions.

561
00:41:05,000 --> 00:41:06,000
Onions.

562
00:41:06,000 --> 00:41:07,000
Onions.

563
00:41:07,000 --> 00:41:08,000
Onions.

564
00:41:08,000 --> 00:41:09,000
Yeah.

565
00:41:09,000 --> 00:41:10,000
Onions are the worst.

566
00:41:10,000 --> 00:41:15,920
But what if it was Facebook for $5 billion?

567
00:41:15,920 --> 00:41:18,920
I'll take 5 billion.

568
00:41:18,920 --> 00:41:22,600
All right.

569
00:41:22,600 --> 00:41:31,600
And I guess the last one, this one is very, very with the theme of this month, but does

570
00:41:31,600 --> 00:41:35,560
Santa have any cybersecurity concerns?

571
00:41:35,560 --> 00:41:38,960
I don't know.

572
00:41:38,960 --> 00:41:46,360
I think maybe seeing as he is who he is, he may be worried about Talos shutting down his

573
00:41:46,360 --> 00:41:47,360
botnet.

574
00:41:47,360 --> 00:41:56,320
I don't know.

575
00:41:56,320 --> 00:42:00,080
Well I know I have truly enjoyed this session.

576
00:42:00,080 --> 00:42:04,480
I think one of the best sessions we've had.

577
00:42:04,480 --> 00:42:08,280
Just a quick recap of today's topic.

578
00:42:08,280 --> 00:42:12,400
So I thought it was interesting talking about the benefits of moving to the cloud.

579
00:42:12,400 --> 00:42:15,120
We all know everyone's doing it, but why are they doing it?

580
00:42:15,120 --> 00:42:19,600
But getting that as a service model that's just instantly available and then having the

581
00:42:19,600 --> 00:42:23,600
redundancy and the availability is huge.

582
00:42:23,600 --> 00:42:28,800
We talked about and compared AWS to Azure, GCP.

583
00:42:28,800 --> 00:42:33,280
Sudhir you touched nicely on maybe thinking about them being kind of more similar than

584
00:42:33,280 --> 00:42:37,840
they are different, but they each have their unique differences in terms of what they're

585
00:42:37,840 --> 00:42:44,080
offering, how they work, and then in terms of offerings of each cloud.

586
00:42:44,080 --> 00:42:51,240
And then Ed, nice example comparing kind of like quote unquote routing between an on-prem

587
00:42:51,240 --> 00:42:56,800
network and then moving to the cloud where we've got APIs and we've got containerization

588
00:42:56,800 --> 00:42:58,640
there.

589
00:42:58,640 --> 00:43:00,200
And then the risks in the cloud.

590
00:43:00,200 --> 00:43:04,760
I thought one of the main takeaways, I said this earlier, but just being aware of that

591
00:43:04,760 --> 00:43:10,520
misconception that just because you drop something in the cloud doesn't mean it's secure.

592
00:43:10,520 --> 00:43:16,960
So just being aware that safety and security do need to be layered in on top of whatever

593
00:43:16,960 --> 00:43:17,960
you put there.

594
00:43:17,960 --> 00:43:19,560
So just some takeaways for me.

595
00:43:19,560 --> 00:43:20,560
Yeah.

596
00:43:20,560 --> 00:43:29,000
And from my point of view, I think just thinking about those specific tech tags that we talked

597
00:43:29,000 --> 00:43:34,960
about a few minutes ago, make sure that if you're implementing things to a cloud, make

598
00:43:34,960 --> 00:43:36,700
sure you secure them.

599
00:43:36,700 --> 00:43:41,160
If you don't know, if you're not sure what you need to secure, I guess there's an app

600
00:43:41,160 --> 00:43:42,160
for that.

601
00:43:42,160 --> 00:43:45,800
There's a few services for that, of course.

602
00:43:45,800 --> 00:43:51,400
Then I know along the hand with that one, cloud security posture management, that's

603
00:43:51,400 --> 00:43:56,120
another thing that be on the lookout for.

604
00:43:56,120 --> 00:44:03,440
And the next few things, basics on securing the cloud, make sure that you go and we're

605
00:44:03,440 --> 00:44:10,520
probably going to put it on the event on the communication community space that we have

606
00:44:10,520 --> 00:44:11,800
for the cloud security alliance.

607
00:44:11,800 --> 00:44:16,560
This is a really good recommendation.

608
00:44:16,560 --> 00:44:19,840
Same thing for cloud native application protection.

609
00:44:19,840 --> 00:44:21,760
There's more information there.

610
00:44:21,760 --> 00:44:25,400
Again, same thing that I just mentioned, there's an app for that.

611
00:44:25,400 --> 00:44:31,420
And the last part on multi-cloud defense.

612
00:44:31,420 --> 00:44:35,440
There's actually three things that I do really like about multi-cloud defense, just to give

613
00:44:35,440 --> 00:44:42,800
you some info for, to look for the next webinar, network visibility, routing and connectivity,

614
00:44:42,800 --> 00:44:44,280
and then security automation.

615
00:44:44,280 --> 00:44:50,760
Those are three key pillars of the actual multi-cloud defense piece.

616
00:44:50,760 --> 00:44:53,680
So super, super nice, Mike.

617
00:44:53,680 --> 00:44:58,800
I guess this has been another one that it's super, super informative and I've learned

618
00:44:58,800 --> 00:44:59,800
a lot.

619
00:44:59,800 --> 00:45:06,040
Don't forget to fill out the survey at the end, Aiden from Indiana State University won

620
00:45:06,040 --> 00:45:09,160
our survey fill out challenge.

621
00:45:09,160 --> 00:45:14,600
He's sporting some nice swag right now, but I do want to give a special thank you to Ed

622
00:45:14,600 --> 00:45:17,240
and Sudhir, just amazing conversation.

623
00:45:17,240 --> 00:45:21,200
Thank you both so much for, and not just for the show, but all you do in the industry to

624
00:45:21,200 --> 00:45:24,780
help keep people around the world secure.

625
00:45:24,780 --> 00:45:27,320
Our next call is going to be part two.

626
00:45:27,320 --> 00:45:32,200
So January 17th, Cisco's cloud native security solution.

627
00:45:32,200 --> 00:45:34,480
Again, it's called multi-cloud defense.

628
00:45:34,480 --> 00:45:39,360
Again, please fill out the survey if you can so you can wear a hoodie or whatever you want.

629
00:45:39,360 --> 00:45:41,080
We'll send out a gift card to the winner there.

630
00:45:41,080 --> 00:45:44,680
I hope you all have enjoyed the session as much as I have.

631
00:45:44,680 --> 00:45:46,240
Happy holidays, everyone.

632
00:45:46,240 --> 00:45:48,720
We will see you in 2024.

633
00:45:48,720 --> 00:46:00,800
Thanks guys.