WEBVTT

1
00:00:00.040 --> 00:00:02.200
<v Speaker 1>Hey, they're deep divers. Ever, feel like you're trying to

2
00:00:02.200 --> 00:00:04.280
<v Speaker 1>build a digital fortress, but you're kind of drowning in

3
00:00:04.320 --> 00:00:08.919
<v Speaker 1>blueprints and all that security jargon. Well, today we're throwing

4
00:00:08.919 --> 00:00:11.279
<v Speaker 1>you a lifeline. We're diving straight into the heart of

5
00:00:11.359 --> 00:00:16.800
<v Speaker 1>cloud security, specifically Microsoft Azure network security. We've got an

6
00:00:16.879 --> 00:00:20.359
<v Speaker 1>incredible guide for this, a really comprehensive book by Nicholas

7
00:00:20.399 --> 00:00:23.719
<v Speaker 1>Dacola and Anthony Roman. Think of this deep dive as

8
00:00:23.760 --> 00:00:26.519
<v Speaker 1>your shortcut, you know, getting the solid grasp on the

9
00:00:26.640 --> 00:00:29.800
<v Speaker 1>essential strategies, the tools you actually need to build a

10
00:00:29.800 --> 00:00:33.280
<v Speaker 1>secure network in Azure without getting totally lost in the weeds.

11
00:00:33.560 --> 00:00:38.399
<v Speaker 1>We're definitely aiming for some aha moments today because honestly,

12
00:00:38.479 --> 00:00:41.320
<v Speaker 1>protecting your cloud it isn't just like a good idea,

13
00:00:41.560 --> 00:00:42.880
<v Speaker 1>it's absolutely critical.

14
00:00:43.039 --> 00:00:45.119
<v Speaker 2>Indeed, Yeah, our mission here is really to distill the

15
00:00:45.159 --> 00:00:47.240
<v Speaker 2>most vital insights from this guide. We want to help

16
00:00:47.280 --> 00:00:49.840
<v Speaker 2>you grasp not just what Azure offers in network security,

17
00:00:49.920 --> 00:00:52.920
<v Speaker 2>but maybe more importantly, why each piece matters, why it's

18
00:00:52.960 --> 00:00:56.000
<v Speaker 2>a crucial brick in your overall defense strategy. We'll uncover

19
00:00:56.079 --> 00:00:58.679
<v Speaker 2>how to fortify your digital assets right from the ground up,

20
00:00:59.000 --> 00:01:01.399
<v Speaker 2>really exploring the fundations of your cloud fort.

21
00:01:01.679 --> 00:01:04.719
<v Speaker 1>Okay, so let's kick things off by setting the scene

22
00:01:04.920 --> 00:01:08.439
<v Speaker 1>this digital fort moving to the cloud. It feels liberating,

23
00:01:08.519 --> 00:01:11.400
<v Speaker 1>doesn't it. You get the speed, the flexibility, it's all

24
00:01:11.400 --> 00:01:14.560
<v Speaker 1>incredibly appealing. But when it comes to security, a lot

25
00:01:14.599 --> 00:01:18.560
<v Speaker 1>of organizations still seem to think the cloud provider just

26
00:01:18.599 --> 00:01:22.120
<v Speaker 1>handles everything. Is that really the case? What are the

27
00:01:22.120 --> 00:01:26.599
<v Speaker 1>most dangerous misconceptions there around that shared responsibility model and

28
00:01:26.599 --> 00:01:28.640
<v Speaker 1>why do they persist.

29
00:01:28.799 --> 00:01:31.719
<v Speaker 2>That's a really crucial starting point because what's often overlooked

30
00:01:31.840 --> 00:01:36.719
<v Speaker 2>is this shared responsibility model. Microsoft does secure the cloud itself,

31
00:01:36.799 --> 00:01:40.200
<v Speaker 2>you know, the underlying infrastructure, the physical data centers, the

32
00:01:40.239 --> 00:01:44.239
<v Speaker 2>global network, the hypervisor running your vms. They spend billions

33
00:01:44.239 --> 00:01:47.200
<v Speaker 2>on that making sure that foundation is rock solid. But you,

34
00:01:47.319 --> 00:01:50.000
<v Speaker 2>as the customer, you're responsible for security in the cloud.

35
00:01:50.159 --> 00:01:53.319
<v Speaker 2>That means your data, your applications, and critically, how you

36
00:01:53.359 --> 00:01:56.480
<v Speaker 2>can figure your network within your Azure environment. The misconception

37
00:01:56.560 --> 00:01:59.959
<v Speaker 2>that Microsoft handles it all well. It often persists because

38
00:02:00.079 --> 00:02:03.480
<v Speaker 2>the underlying stuff is so robust, but that security doesn't

39
00:02:03.519 --> 00:02:08.000
<v Speaker 2>automatically extend to your configurations. Misunderstandings there, Frankly, they're often

40
00:02:08.039 --> 00:02:09.960
<v Speaker 2>the root cause of major vulnerabilities.

41
00:02:10.000 --> 00:02:12.400
<v Speaker 1>That difference between security of the cloud and security in

42
00:02:12.439 --> 00:02:15.080
<v Speaker 1>the cloud. Yeah, yeah, that's vital. And to really hammer

43
00:02:15.120 --> 00:02:18.639
<v Speaker 1>home how critical that customer responsibility is, the book brings

44
00:02:18.719 --> 00:02:22.759
<v Speaker 1>up well a prime example, the capital Ie breach back

45
00:02:22.800 --> 00:02:26.879
<v Speaker 1>in July twenty nineteen. Over one hundred million accounts exposed.

46
00:02:27.479 --> 00:02:29.840
<v Speaker 1>And it wasn't a physical break in, right, not a

47
00:02:29.879 --> 00:02:33.719
<v Speaker 1>flaw on Microsoft's core systems. Instead, it all stemmed from

48
00:02:33.719 --> 00:02:37.879
<v Speaker 1>a misconfigured web application firewall and oversight on the customer

49
00:02:37.960 --> 00:02:40.400
<v Speaker 1>side that led an attack or pivot from on prem

50
00:02:40.439 --> 00:02:42.680
<v Speaker 1>systems into the cloud services.

51
00:02:42.280 --> 00:02:43.960
<v Speaker 2>A digital oversight exactly.

52
00:02:44.039 --> 00:02:46.400
<v Speaker 1>That breach is a stark reminder and if we zoom

53
00:02:46.400 --> 00:02:48.240
<v Speaker 1>out a bit, it connects to a bigger trend. We've

54
00:02:48.280 --> 00:02:51.960
<v Speaker 1>seen reports from Verizon and trust Wave back in twenty

55
00:02:52.000 --> 00:02:55.000
<v Speaker 1>twenty they showed cloud attacks literally doubled, made up over

56
00:02:55.039 --> 00:02:57.919
<v Speaker 1>twenty percent of all reported breaches, and web applications were

57
00:02:57.960 --> 00:02:58.800
<v Speaker 1>a primary target.

58
00:02:58.960 --> 00:03:02.840
<v Speaker 2>So this really forces organizations to evolve their thinking. That

59
00:03:03.000 --> 00:03:06.000
<v Speaker 2>old classic perimeter model, you know, where everything behind the

60
00:03:06.000 --> 00:03:09.120
<v Speaker 2>corporate firewall was just trusted, It just doesn't cut it anymore.

61
00:03:09.319 --> 00:03:13.520
<v Speaker 2>We need a modern identity based perimeter, often called zero trust.

62
00:03:13.840 --> 00:03:17.840
<v Speaker 2>It's designed to contain attacks at every single layer network, application,

63
00:03:18.039 --> 00:03:21.680
<v Speaker 2>identity data. Your digital fort needs wall sure, but also

64
00:03:21.919 --> 00:03:23.680
<v Speaker 2>internal checkpoints, lots.

65
00:03:23.439 --> 00:03:26.080
<v Speaker 1>Of them understood. So okay, before we get into the

66
00:03:26.120 --> 00:03:29.599
<v Speaker 1>really sophisticated defenses, we need to understand the ground our

67
00:03:29.639 --> 00:03:31.719
<v Speaker 1>ford is built on. What are the basic building blocks?

68
00:03:31.759 --> 00:03:34.039
<v Speaker 1>What are we actually protecting here in an Azure network?

69
00:03:34.199 --> 00:03:37.280
<v Speaker 2>Right? The fundamentals. The most basic piece, the actual ground

70
00:03:37.360 --> 00:03:40.599
<v Speaker 2>you build on, is the virtual network the v net.

71
00:03:40.840 --> 00:03:44.400
<v Speaker 2>Think of it like your own private, isolated canvas in

72
00:03:44.439 --> 00:03:47.439
<v Speaker 2>the cloud, a private network. It's similar to maybe a

73
00:03:47.479 --> 00:03:50.280
<v Speaker 2>local switch and a traditional data center, but it comes

74
00:03:50.280 --> 00:03:53.520
<v Speaker 2>with all those cloud benefits baked right in. You get scaling,

75
00:03:53.800 --> 00:03:58.879
<v Speaker 2>high availability, and really important critical isolation. All your ritual machines,

76
00:03:58.919 --> 00:04:01.759
<v Speaker 2>your vms, and even platform as a service resources pay

77
00:04:01.840 --> 00:04:04.599
<v Speaker 2>us when you use things like private link. They attach

78
00:04:04.719 --> 00:04:07.319
<v Speaker 2>directly to this v net. It's where yourself lives, where

79
00:04:07.360 --> 00:04:10.120
<v Speaker 2>it communicates, and where it stays logically separate from the

80
00:04:10.120 --> 00:04:11.400
<v Speaker 2>public Internet by default.

81
00:04:11.479 --> 00:04:13.680
<v Speaker 1>Okay, so I set up my v net, my plot

82
00:04:13.680 --> 00:04:16.839
<v Speaker 1>of land. What if I need multiple plots, like different

83
00:04:16.879 --> 00:04:18.800
<v Speaker 1>sections from my fort? If I have multiple v nets,

84
00:04:18.839 --> 00:04:21.519
<v Speaker 1>do they just magically talk to each other? Or are

85
00:04:21.560 --> 00:04:22.879
<v Speaker 1>those divisions secure right away?

86
00:04:23.240 --> 00:04:26.279
<v Speaker 2>Ugh, good question. No, not by default, and that's actually

87
00:04:26.319 --> 00:04:29.120
<v Speaker 2>a security feature, not a limitation. To get them talking,

88
00:04:29.199 --> 00:04:31.920
<v Speaker 2>you have to explicitly set up v net teering. This

89
00:04:31.959 --> 00:04:35.240
<v Speaker 2>connects them directly. And what's really crucial from a security

90
00:04:35.279 --> 00:04:38.360
<v Speaker 2>angle is that all the traffic between these peered v nets,

91
00:04:38.720 --> 00:04:44.120
<v Speaker 2>it travels exclusively over Microsoft's high speed private backbone network.

92
00:04:44.480 --> 00:04:48.319
<v Speaker 2>It never hits the public Internet. That drastically reduces your exposure.

93
00:04:48.759 --> 00:04:51.600
<v Speaker 2>And this peering, it's foundational for a lot of common

94
00:04:51.720 --> 00:04:55.000
<v Speaker 2>secure architectures, especially that hub and spoke model we should

95
00:04:55.000 --> 00:04:55.920
<v Speaker 2>probably touch on later.

96
00:04:56.079 --> 00:04:59.079
<v Speaker 1>Got it, keeping internal traffic off the public Internet. That

97
00:04:59.120 --> 00:05:02.319
<v Speaker 1>makes sense. But what about those Azure pest services, things

98
00:05:02.399 --> 00:05:06.560
<v Speaker 1>like Azure scl database or Azure storage accounts. They often

99
00:05:06.600 --> 00:05:10.600
<v Speaker 1>seem Internet facing by default, right, how do we keep

100
00:05:10.639 --> 00:05:13.040
<v Speaker 1>them locked down inside our private.

101
00:05:12.680 --> 00:05:16.480
<v Speaker 2>Fort That's precisely where private link becomes. While an indispensable

102
00:05:16.560 --> 00:05:19.199
<v Speaker 2>tool in your security kit, what it does is allow

103
00:05:19.279 --> 00:05:22.279
<v Speaker 2>you to connect these Azure pes services directly to your

104
00:05:22.360 --> 00:05:26.759
<v Speaker 2>VNT using private IP. Addresses the huge implication here. Your

105
00:05:26.759 --> 00:05:30.759
<v Speaker 2>internal resources can access these patas services securely, but the

106
00:05:30.800 --> 00:05:34.360
<v Speaker 2>PATA service itself doesn't need any public RP address. This

107
00:05:34.560 --> 00:05:38.199
<v Speaker 2>massively shrinks its attack surface. All communication stays within your

108
00:05:38.199 --> 00:05:41.519
<v Speaker 2>private v net. It basically eliminates a major path for

109
00:05:41.560 --> 00:05:42.480
<v Speaker 2>external threats.

110
00:05:42.800 --> 00:05:45.759
<v Speaker 1>So it's like having a secure secret tunnel directly into

111
00:05:45.839 --> 00:05:48.600
<v Speaker 1>your database completely bypassing the public front.

112
00:05:48.399 --> 00:05:50.519
<v Speaker 2>Gate exactly like that. Yeah, a private entrance.

113
00:05:50.600 --> 00:05:54.079
<v Speaker 1>Okay, so we've got a building blocks, our secure plot

114
00:05:54.120 --> 00:05:57.399
<v Speaker 1>of land. The v net are private roads between plots,

115
00:05:57.439 --> 00:06:01.079
<v Speaker 1>vnet peering and these secure tunnels to cloud services private link.

116
00:06:01.720 --> 00:06:04.720
<v Speaker 1>Now how do we start assembling these putting them together

117
00:06:04.759 --> 00:06:07.560
<v Speaker 1>into a structure that's actually secure. Is there like a

118
00:06:07.600 --> 00:06:09.959
<v Speaker 1>master blueprint for our digital fort Yeah?

119
00:06:09.959 --> 00:06:12.920
<v Speaker 2>This gets us to a really important architectural point. How

120
00:06:12.920 --> 00:06:15.639
<v Speaker 2>do we make sure we're building securely right from the start,

121
00:06:15.759 --> 00:06:19.040
<v Speaker 2>not just trying to bolt security on afterwards. The Azure

122
00:06:19.160 --> 00:06:22.839
<v Speaker 2>Well Architected Framework is pretty much that blueprint. It lays

123
00:06:22.839 --> 00:06:26.800
<v Speaker 2>out five pillars for cloud excellence, and security isn't just

124
00:06:26.839 --> 00:06:28.759
<v Speaker 2>one pillar, it's kind of woven through all of them.

125
00:06:29.399 --> 00:06:32.079
<v Speaker 2>The authors really stress this. They say, if you don't

126
00:06:32.120 --> 00:06:34.720
<v Speaker 2>secure your architecture, there might be no returns at all.

127
00:06:35.560 --> 00:06:38.959
<v Speaker 2>It's a good reminder, right, A grand design is useless

128
00:06:39.040 --> 00:06:40.399
<v Speaker 2>if the defenses just.

129
00:06:40.480 --> 00:06:43.600
<v Speaker 1>Crumble makes sense, And one of the core principles they

130
00:06:43.639 --> 00:06:49.160
<v Speaker 1>really emphasize is network segmentation. That's a breaking things up right, Yeah,

131
00:06:49.279 --> 00:06:52.399
<v Speaker 1>smaller isolated rooms within the fort. Why is that so powerful?

132
00:06:52.560 --> 00:06:56.519
<v Speaker 2>Exactly? Segmentation is really a direct application of the principle

133
00:06:56.560 --> 00:06:59.959
<v Speaker 2>of least privilege, but applied to network traffic. Instead of

134
00:07:00.120 --> 00:07:02.839
<v Speaker 2>having a big, flat, open network where everything can talk

135
00:07:02.879 --> 00:07:06.680
<v Speaker 2>to everything else, which is bad, you logically group resources,

136
00:07:07.240 --> 00:07:09.920
<v Speaker 2>maybe by function, for instance, separating your web servers from

137
00:07:09.959 --> 00:07:12.720
<v Speaker 2>your app servers and those from your databases. Put them

138
00:07:12.720 --> 00:07:16.600
<v Speaker 2>on different subnets or even different venuts. Then you strictly

139
00:07:16.680 --> 00:07:20.639
<v Speaker 2>limit the traffic between these segments, only allow what's absolutely necessary.

140
00:07:20.879 --> 00:07:25.399
<v Speaker 2>The critical security advantage. It can slow or prevent lateral

141
00:07:25.439 --> 00:07:29.199
<v Speaker 2>movement by an attacker or even a malicious insider.

142
00:07:28.959 --> 00:07:30.160
<v Speaker 1>Right stuffs them moving around.

143
00:07:30.240 --> 00:07:34.160
<v Speaker 2>Yeah, if one machine gets compromised, the attacker can't just

144
00:07:34.279 --> 00:07:39.000
<v Speaker 2>easily pivot at all to grab sensitive data in another segment.

145
00:07:39.040 --> 00:07:39.800
<v Speaker 2>It contains the.

146
00:07:39.759 --> 00:07:42.759
<v Speaker 1>Breach like blast doors between sections of the fort.

147
00:07:42.839 --> 00:07:44.879
<v Speaker 2>Perfect analogy blast doors.

148
00:07:45.000 --> 00:07:46.720
<v Speaker 1>And this seems to lead us straight to the idea

149
00:07:46.720 --> 00:07:49.519
<v Speaker 1>of zero trust. It's definitely more than just a buzzword,

150
00:07:49.560 --> 00:07:51.959
<v Speaker 1>isn't it. Sounds like the philosophy behind those blast doors.

151
00:07:52.040 --> 00:07:56.160
<v Speaker 2>Absolutely zero trust is a fundamental shift, a change in mindset.

152
00:07:56.360 --> 00:08:00.319
<v Speaker 2>It essentially eliminates the trust based on network location. It

153
00:08:00.360 --> 00:08:03.319
<v Speaker 2>operates on the assumption of breach, so it verifies every

154
00:08:03.319 --> 00:08:05.800
<v Speaker 2>single request no matter where it comes from inside outside

155
00:08:05.839 --> 00:08:08.839
<v Speaker 2>doesn't matter. A really powerful example of this in Azure,

156
00:08:08.959 --> 00:08:12.759
<v Speaker 2>especially for admin access, is using Azure Bastion or maybe

157
00:08:12.839 --> 00:08:17.199
<v Speaker 2>Azure Security Centers just in time JITVM access. Instead of

158
00:08:17.279 --> 00:08:20.519
<v Speaker 2>leaving say RDP or SSH ports just open to the

159
00:08:20.560 --> 00:08:23.480
<v Speaker 2>Internet all the time, which is incredibly risky, very risky,

160
00:08:23.600 --> 00:08:26.639
<v Speaker 2>these services let you manage vms only through the secure

161
00:08:26.759 --> 00:08:30.000
<v Speaker 2>Azure portal, or they open those ports only on demand

162
00:08:30.360 --> 00:08:34.120
<v Speaker 2>for a very limited time and only to specific authorized

163
00:08:34.159 --> 00:08:39.000
<v Speaker 2>source ips. It dramatically shrinks your attack surface. For administrative access,

164
00:08:39.240 --> 00:08:41.200
<v Speaker 2>think of it as having a really strict guard at

165
00:08:41.240 --> 00:08:43.919
<v Speaker 2>every single admin entrance, checking IDs every time.

166
00:08:44.039 --> 00:08:46.720
<v Speaker 1>So instead of that big open drawbridge, it's a guarded gate,

167
00:08:47.480 --> 00:08:50.759
<v Speaker 1>the tough bouncer at checking credentials constantly. The book also

168
00:08:50.759 --> 00:08:53.559
<v Speaker 1>talks quite a bit about hubben Spoke topology as a

169
00:08:53.600 --> 00:08:56.080
<v Speaker 1>best practice for structuring our fort Can you elaborate on

170
00:08:56.080 --> 00:08:56.480
<v Speaker 1>that model?

171
00:08:56.639 --> 00:08:59.440
<v Speaker 2>Yes, The hubbin spoke. It's a very widely adopted model.

172
00:08:59.480 --> 00:09:03.000
<v Speaker 2>It's secure, it's scalable. Imagine a central hub vnut that's

173
00:09:03.039 --> 00:09:06.080
<v Speaker 2>the core of your fort. This hub handles shared services,

174
00:09:06.120 --> 00:09:09.879
<v Speaker 2>things like connectivity back to your on premises networks, and crucially,

175
00:09:09.919 --> 00:09:12.840
<v Speaker 2>it's where you put centralized security devices like your main firewall.

176
00:09:12.960 --> 00:09:14.519
<v Speaker 1>Okay, the central point right.

177
00:09:14.360 --> 00:09:17.200
<v Speaker 2>Then you have spoke vnets these attached to the hub.

178
00:09:17.840 --> 00:09:22.320
<v Speaker 2>Each spoke hosts your isolated worklows or applications. Now, all

179
00:09:22.360 --> 00:09:25.159
<v Speaker 2>the traffic, whether it's between different spokes, or going to

180
00:09:25.279 --> 00:09:27.159
<v Speaker 2>and from your on prem network, or even out to

181
00:09:27.159 --> 00:09:28.799
<v Speaker 2>the internet, it gets routed through the hub.

182
00:09:29.080 --> 00:09:31.799
<v Speaker 1>H Okay, everything goes through the center exactly.

183
00:09:32.279 --> 00:09:36.360
<v Speaker 2>And this central routing allows for consistent security, inspection, logging,

184
00:09:36.399 --> 00:09:39.799
<v Speaker 2>and control across your whole Azure environment. It's a really

185
00:09:39.799 --> 00:09:43.360
<v Speaker 2>effective way to manage and secure a large complex setup.

186
00:09:43.559 --> 00:09:47.080
<v Speaker 1>Makes sense. So, speaking of central control, if the hub

187
00:09:47.200 --> 00:09:50.320
<v Speaker 1>is the nerve center, we need a really smart, really

188
00:09:50.360 --> 00:09:53.720
<v Speaker 1>strong gatekeeper there to monitor and manage all that traffic

189
00:09:53.759 --> 00:09:57.679
<v Speaker 1>flowing through. What's that ultimate gatekeeper in Azure, that.

190
00:09:57.679 --> 00:10:01.000
<v Speaker 2>Central gatekeeper for your Azure fort That would be Azure firewall.

191
00:10:01.679 --> 00:10:04.480
<v Speaker 2>What's really powerful about it is that it's a managed service,

192
00:10:04.559 --> 00:10:07.679
<v Speaker 2>its platform as a service or a POTTUS, and it's

193
00:10:07.679 --> 00:10:11.200
<v Speaker 2>a stateful firewall. Being cloud native means it's highly available,

194
00:10:11.279 --> 00:10:14.240
<v Speaker 2>has built in auto scaling, so it can handle huge

195
00:10:14.279 --> 00:10:17.720
<v Speaker 2>traffic spikes without you having to manage the underlying infrastructure

196
00:10:17.840 --> 00:10:21.480
<v Speaker 2>or worry about capacity. Its whole purpose is to centrally

197
00:10:21.480 --> 00:10:24.720
<v Speaker 2>govern and log all their traffic flows using a debops approach.

198
00:10:24.960 --> 00:10:28.080
<v Speaker 2>It gives you that single pane of glass for network security.

199
00:10:28.159 --> 00:10:30.399
<v Speaker 1>That's a great point about pious. Now a lot of

200
00:10:30.399 --> 00:10:33.840
<v Speaker 1>people know about network security groups nsgs. They also apply

201
00:10:34.000 --> 00:10:38.240
<v Speaker 1>rules to traffic. So how is Azure firewall different. When

202
00:10:38.279 --> 00:10:40.919
<v Speaker 1>would you use one versus the other or maybe both?

203
00:10:40.960 --> 00:10:42.559
<v Speaker 1>That seems to a common confusion point.

204
00:10:42.639 --> 00:10:45.679
<v Speaker 2>Absolutely, it is a very common question. Think of NSG's

205
00:10:45.799 --> 00:10:51.080
<v Speaker 2>like localized security guards. They're decentralized. You apply NSG rules

206
00:10:51.159 --> 00:10:55.639
<v Speaker 2>directly to individual network interfaces and ICs or maybe entire subnets.

207
00:10:56.000 --> 00:10:58.120
<v Speaker 2>They provide micro segmentation within.

208
00:10:57.879 --> 00:10:59.720
<v Speaker 1>A v net okay, granular control.

209
00:11:00.399 --> 00:11:03.399
<v Speaker 2>Azure Firewall, on the other hand, that's your centralized command

210
00:11:03.480 --> 00:11:06.720
<v Speaker 2>center firewall. It typically lives in your hub vnet and

211
00:11:06.799 --> 00:11:10.480
<v Speaker 2>it controls traffic for multiple spoke networks. The best practice

212
00:11:10.559 --> 00:11:14.840
<v Speaker 2>almost always it's to use both both. Yeah, use Azure

213
00:11:14.879 --> 00:11:17.679
<v Speaker 2>Firewall for your north south traffic that's stuff going in

214
00:11:17.720 --> 00:11:20.120
<v Speaker 2>and out to the Internet, and also for broader east

215
00:11:20.159 --> 00:11:24.360
<v Speaker 2>west traffic between different vnts. Then use nsgs for that

216
00:11:24.559 --> 00:11:28.879
<v Speaker 2>fine grained micro segmentation within your spoke subnets. They act

217
00:11:28.879 --> 00:11:33.559
<v Speaker 2>as those internal security checkpoints for specific resources. Layered defense,

218
00:11:33.720 --> 00:11:34.360
<v Speaker 2>layer defense.

219
00:11:34.399 --> 00:11:37.759
<v Speaker 1>Got it. So the firewall sits in the hub, how

220
00:11:37.799 --> 00:11:39.759
<v Speaker 1>do we actually make sure all the right traffic goes

221
00:11:39.799 --> 00:11:43.519
<v Speaker 1>through it? How do we prevent things from sneaking around

222
00:11:43.519 --> 00:11:44.279
<v Speaker 1>the side? Right?

223
00:11:44.320 --> 00:11:47.159
<v Speaker 2>Because the firewall can only inspect traffic that's actually sent

224
00:11:47.240 --> 00:11:49.759
<v Speaker 2>to it. You achieve this first by setting up vnet

225
00:11:49.799 --> 00:11:51.320
<v Speaker 2>peering between your hub and spokes.

226
00:11:51.320 --> 00:11:52.960
<v Speaker 1>Like we talked about.

227
00:11:52.679 --> 00:11:55.559
<v Speaker 2>Then, and this is absolutely key. You apply user defined

228
00:11:55.639 --> 00:11:59.879
<v Speaker 2>roots or udrs to your spoke subnets. These udrs ex

229
00:12:00.000 --> 00:12:02.960
<v Speaker 2>ixlicitly tell the traffic, say anything destined for the Internet

230
00:12:03.039 --> 00:12:05.200
<v Speaker 2>or maybe for another spoke. Your next top is the

231
00:12:05.200 --> 00:12:07.159
<v Speaker 2>Azure firewalls private IP address.

232
00:12:07.200 --> 00:12:09.679
<v Speaker 1>Ah, Okay, you're directing the traffic exactly.

233
00:12:10.000 --> 00:12:13.480
<v Speaker 2>Without those udrs, traffic might just find another path bypassing

234
00:12:13.480 --> 00:12:17.080
<v Speaker 2>your central firewall entirely leaving a massive gap. The udrs

235
00:12:17.120 --> 00:12:20.120
<v Speaker 2>are like the traffic director at every junction, forcing cars

236
00:12:20.120 --> 00:12:21.440
<v Speaker 2>through the main security gate.

237
00:12:21.720 --> 00:12:24.159
<v Speaker 1>That's a brilliant analogy. Okay, so it handles the rounding.

238
00:12:24.440 --> 00:12:28.639
<v Speaker 1>Now beyond just basic allowed NY rules based on IPS imports,

239
00:12:29.480 --> 00:12:32.200
<v Speaker 1>what advanced stuff does azure firewall brank. This is where

240
00:12:32.200 --> 00:12:35.039
<v Speaker 1>it gets really interesting, right, What makes it a smart gatekeeper?

241
00:12:35.120 --> 00:12:38.480
<v Speaker 2>Oh? Definitely. It has a constantly growing list of really

242
00:12:38.519 --> 00:12:41.679
<v Speaker 2>powerful features that take it way beyond a simple packet filter.

243
00:12:41.960 --> 00:12:44.519
<v Speaker 2>For instance, it's DNS settings. It can act as a

244
00:12:44.600 --> 00:12:48.039
<v Speaker 2>DNS proxy. This lets you use fully qualified domain names

245
00:12:48.159 --> 00:12:51.120
<v Speaker 2>fqdns like dot Microsoft, dot Com in your rules, not

246
00:12:51.200 --> 00:12:54.039
<v Speaker 2>just IP addresses, which makes rules way easier to manage,

247
00:12:54.080 --> 00:12:57.039
<v Speaker 2>much easier, and maybe more importantly, it forces all DNS

248
00:12:57.080 --> 00:13:00.320
<v Speaker 2>queries through that central point, so you get visibility and

249
00:13:00.360 --> 00:13:02.960
<v Speaker 2>you can control where your applications are actually trying to

250
00:13:02.960 --> 00:13:07.919
<v Speaker 2>connect no shadow DNS servers. Another powerful one is forced tunneling.

251
00:13:08.039 --> 00:13:11.720
<v Speaker 2>This lets you route all outbound Internet traffic through another appliance,

252
00:13:11.720 --> 00:13:14.080
<v Speaker 2>maybe an on prem firewall what they call an NVA,

253
00:13:14.679 --> 00:13:19.279
<v Speaker 2>a network virtual appliance. Okay, useful for certain compliance scenarios

254
00:13:19.279 --> 00:13:22.519
<v Speaker 2>where you need extra inspection and a snack control its

255
00:13:22.519 --> 00:13:25.639
<v Speaker 2>you preserve the original source IP in some cases, which

256
00:13:25.679 --> 00:13:29.759
<v Speaker 2>is vital for logging and troubleshooting. But most critically, Azure

257
00:13:29.759 --> 00:13:34.720
<v Speaker 2>Firewall offers deep traffic inspection. This includes integrating with Microsoft's

258
00:13:34.759 --> 00:13:38.720
<v Speaker 2>threat intelligence feed, so it automatically blocks known malicious ips

259
00:13:38.759 --> 00:13:41.279
<v Speaker 2>and domains huge value right there. Yeah, that's but if

260
00:13:41.320 --> 00:13:43.639
<v Speaker 2>you really want to level up, Azure Firewall premium goes

261
00:13:43.679 --> 00:13:47.120
<v Speaker 2>even further. It adds things like TLUS termination. This lets

262
00:13:47.159 --> 00:13:50.480
<v Speaker 2>the decrypt outbound HTTPS traffic, which is usually a big

263
00:13:50.480 --> 00:13:53.639
<v Speaker 2>blind spot, inspect it for threats, and then re encrypt it.

264
00:13:53.919 --> 00:13:57.000
<v Speaker 1>Vital visibility wow inspecting encrypted traffic.

265
00:13:57.279 --> 00:14:00.679
<v Speaker 2>Yeah. It also brings powerful intrusion to techtion and prevention

266
00:14:00.799 --> 00:14:05.440
<v Speaker 2>systems idsps, using signatures to block known exploits and full

267
00:14:05.679 --> 00:14:08.080
<v Speaker 2>URL filtering so you can get more granular than just

268
00:14:08.200 --> 00:14:11.799
<v Speaker 2>fqtns blocking specific website paths for example.

269
00:14:12.000 --> 00:14:14.440
<v Speaker 1>So definitely not just a basic traffic cock It's like

270
00:14:15.080 --> 00:14:18.960
<v Speaker 1>a constantly learning, deep diving security analyst for your whole

271
00:14:19.039 --> 00:14:21.399
<v Speaker 1>network parameter. And I see it has different kinds of

272
00:14:21.480 --> 00:14:22.960
<v Speaker 1>rules too, for different layers.

273
00:14:23.039 --> 00:14:26.679
<v Speaker 2>Yes, it organizes its intelligence effectively. You've got network rules.

274
00:14:26.679 --> 00:14:29.200
<v Speaker 2>Those are for layer thirty four traffic based on IPS

275
00:14:29.320 --> 00:14:32.960
<v Speaker 2>ports protocols typically use for that east west traffic between vnuts.

276
00:14:33.200 --> 00:14:35.879
<v Speaker 2>Then you have application rules. These are layer seven looking

277
00:14:35.960 --> 00:14:39.919
<v Speaker 2>at the actual application data. FQDNS HTTP headers mostly used

278
00:14:39.919 --> 00:14:43.879
<v Speaker 2>for controlling outbound Internet access, and finally DNT rules that

279
00:14:43.919 --> 00:14:47.039
<v Speaker 2>stands for a destination network address translation. You use these

280
00:14:47.080 --> 00:14:49.000
<v Speaker 2>when you need to publish an internal service to the

281
00:14:49.039 --> 00:14:52.799
<v Speaker 2>Internet using the firewalls. Public IP it translates the incoming

282
00:14:52.799 --> 00:14:56.000
<v Speaker 2>public request to the internal private IP and these rules.

283
00:14:56.080 --> 00:14:59.480
<v Speaker 2>They're processed in a very specific order DN at first,

284
00:14:59.559 --> 00:15:03.600
<v Speaker 2>then network rules than application rules. Understanding that order is

285
00:15:03.639 --> 00:15:06.799
<v Speaker 2>critical so you don't accidentally allow something you meant to block.

286
00:15:06.639 --> 00:15:11.000
<v Speaker 1>Right, order matters. Okay, so we've got this robust central firewall,

287
00:15:11.080 --> 00:15:15.399
<v Speaker 1>solid network foundations, zero trust principles guiding us. But a

288
00:15:15.480 --> 00:15:18.759
<v Speaker 1>truly secure for it needs multiple layers. Right, It's not

289
00:15:18.840 --> 00:15:21.000
<v Speaker 1>just the main gate. What else is in the Azure

290
00:15:21.080 --> 00:15:25.399
<v Speaker 1>security arsenal to protect maybe specific weak points or guard

291
00:15:25.440 --> 00:15:29.399
<v Speaker 1>against those overwhelming acts of nature in the digital world.

292
00:15:29.559 --> 00:15:33.080
<v Speaker 2>Absolutely, defense and depth. Even with a great central firewall,

293
00:15:33.240 --> 00:15:37.360
<v Speaker 2>you need specialized protection for specific things, especially your web applications.

294
00:15:37.679 --> 00:15:41.159
<v Speaker 2>That's where the Azure Web Application Firewall ORBF comes in.

295
00:15:41.480 --> 00:15:44.360
<v Speaker 2>Unlike the network firewall operating at lower layers, the WF

296
00:15:44.360 --> 00:15:48.000
<v Speaker 2>gives you crucial Layer seven protection. It's specifically designed to

297
00:15:48.080 --> 00:15:51.279
<v Speaker 2>spot and block common web attacks, things like SEQL injection,

298
00:15:51.440 --> 00:15:56.559
<v Speaker 2>cross site scripting, remote code execution. It can even manage sophisticated.

299
00:15:55.919 --> 00:15:58.519
<v Speaker 1>Bods focus on web attacks exactly.

300
00:15:58.559 --> 00:16:01.919
<v Speaker 2>It acts as that extra layer right at the application's

301
00:16:01.919 --> 00:16:05.399
<v Speaker 2>front door. You typically attach it to Azure Application Gateway

302
00:16:05.399 --> 00:16:08.559
<v Speaker 2>for regional apps or Azure front Door for global apps.

303
00:16:08.960 --> 00:16:12.159
<v Speaker 2>It sits right in front, scrutinizing every single web request

304
00:16:12.159 --> 00:16:14.840
<v Speaker 2>before it even touches your application code. It's like the

305
00:16:14.840 --> 00:16:17.000
<v Speaker 2>specialized bodyguard just for your web apps.

306
00:16:17.080 --> 00:16:20.440
<v Speaker 1>Makes sense, a bodyguard for the VIP applications. And what

307
00:16:20.519 --> 00:16:25.279
<v Speaker 1>about those massive, just overwhelming distributed denial of service attacks dios,

308
00:16:25.720 --> 00:16:28.200
<v Speaker 1>the ones designed just to flood your services and knock

309
00:16:28.240 --> 00:16:30.720
<v Speaker 1>them offline. How do we stop the fort from being

310
00:16:30.759 --> 00:16:32.600
<v Speaker 1>completely overwhelmed.

311
00:16:32.279 --> 00:16:34.240
<v Speaker 2>For that kind of brute force attack. We turn to

312
00:16:34.320 --> 00:16:37.960
<v Speaker 2>AZUREDDOS protection. It's absolutely crucial if you have any public

313
00:16:37.960 --> 00:16:41.360
<v Speaker 2>facing service. Now. Azure provides a basic tier which protects

314
00:16:41.399 --> 00:16:44.759
<v Speaker 2>the Azure platform itself, but the standard tier that provides

315
00:16:44.840 --> 00:16:48.799
<v Speaker 2>enhanced dedicated protections specifically for your public IP addresses.

316
00:16:48.840 --> 00:16:50.039
<v Speaker 1>Okay, dedicated protection.

317
00:16:50.440 --> 00:16:54.639
<v Speaker 2>Yeah. This includes things like dynamic adaptive mitigation thresholds. It

318
00:16:54.720 --> 00:16:58.279
<v Speaker 2>learns your normal traffic patterns and adjusts automatically. It also

319
00:16:58.320 --> 00:17:01.320
<v Speaker 2>gives you cost protection against auto scaling during an attack,

320
00:17:01.360 --> 00:17:04.680
<v Speaker 2>which is huge. Means you won't get a massive surprise

321
00:17:04.720 --> 00:17:07.160
<v Speaker 2>bill just because you were attacked. Oh that's important, and

322
00:17:07.200 --> 00:17:09.920
<v Speaker 2>you get detailed metrics and logs to understand what happened.

323
00:17:10.200 --> 00:17:13.160
<v Speaker 2>It's designed to protect against those high volume layer three

324
00:17:13.200 --> 00:17:17.000
<v Speaker 2>attacks and protocol level layer four attacks. It acts like

325
00:17:17.039 --> 00:17:20.960
<v Speaker 2>a massive intelligent floodgate, diverting the malicious traffic away before

326
00:17:21.000 --> 00:17:22.440
<v Speaker 2>it swamps your fords.

327
00:17:22.200 --> 00:17:25.680
<v Speaker 1>Gates, a smart floodgate. I like that. Okay. So we

328
00:17:25.720 --> 00:17:29.559
<v Speaker 1>have all these amazing tools, the firewall, WAFD, TOS, protection, bastion.

329
00:17:31.039 --> 00:17:34.839
<v Speaker 1>They must be generating a ton of information, right, logs, alerts.

330
00:17:35.200 --> 00:17:36.720
<v Speaker 1>How do we keep track of it all? How do

331
00:17:36.759 --> 00:17:39.279
<v Speaker 1>we correlate events and actually make sense of it for

332
00:17:39.319 --> 00:17:43.319
<v Speaker 1>our overall security posture? Visibility seems key here see what's

333
00:17:43.319 --> 00:17:44.160
<v Speaker 1>happening inside the.

334
00:17:44.119 --> 00:17:46.839
<v Speaker 2>Fort Absolutely if we connect this to the bigger picture,

335
00:17:47.279 --> 00:17:51.559
<v Speaker 2>all these services they generate vital diagnostic logs. Logs from

336
00:17:51.559 --> 00:17:56.759
<v Speaker 2>Azure Firewall, WAF, DITOS Protection, Asher, Bastion, even really granular

337
00:17:56.920 --> 00:17:59.319
<v Speaker 2>NSG flow logs you can get via network Watch your

338
00:17:59.319 --> 00:18:03.200
<v Speaker 2>traffic analytic. The absolute best practice feed all of these

339
00:18:03.240 --> 00:18:07.359
<v Speaker 2>logs into a central, unified place like Azure Monitor Log

340
00:18:07.359 --> 00:18:09.880
<v Speaker 2>Analytics that gives you your single source of truth for

341
00:18:09.920 --> 00:18:12.799
<v Speaker 2>all security events, one place to look exactly, and from

342
00:18:12.839 --> 00:18:16.319
<v Speaker 2>there you can leverage more advanced services for proactive threat

343
00:18:16.359 --> 00:18:20.079
<v Speaker 2>detection and response. There's Azure Sentinel that's Microsoft's cloud native

344
00:18:20.119 --> 00:18:24.319
<v Speaker 2>sam security information and event management and also SOO Security Orchestration,

345
00:18:24.440 --> 00:18:28.240
<v Speaker 2>Automation and Response Solution. Centinel gives you centralized incident management,

346
00:18:28.480 --> 00:18:33.000
<v Speaker 2>advanced analytics to spot weird anomalies, automated responses using playbooks,

347
00:18:33.119 --> 00:18:36.079
<v Speaker 2>and really powerful threat hunting capabilities. It's kind of like

348
00:18:36.079 --> 00:18:38.839
<v Speaker 2>having a two hundred and forty seven Security Operations Center

349
00:18:38.880 --> 00:18:40.079
<v Speaker 2>at SOOC.

350
00:18:39.759 --> 00:18:42.440
<v Speaker 1>Built for the cloud. The SOOC in the cloud.

351
00:18:42.400 --> 00:18:45.200
<v Speaker 2>And you also have Azure Security Center. This gives you

352
00:18:45.279 --> 00:18:50.000
<v Speaker 2>Cloud security Posture Management or CSPM. It provides continuous recommendations,

353
00:18:50.119 --> 00:18:53.359
<v Speaker 2>helps enforce security policies, and bubbles up alerts from Azure

354
00:18:53.359 --> 00:18:57.359
<v Speaker 2>Defender across your entire Azure environment and even hybrid setups.

355
00:18:57.599 --> 00:19:00.519
<v Speaker 2>Think of security center as your overall fort commander, constantly

356
00:19:00.519 --> 00:19:02.480
<v Speaker 2>telling you where your walls might be weak and where

357
00:19:02.519 --> 00:19:04.039
<v Speaker 2>potential threats are emerging. Wow.

358
00:19:04.119 --> 00:19:07.319
<v Speaker 1>Okay, so putting it all together, what does this all

359
00:19:07.319 --> 00:19:10.279
<v Speaker 1>mean for you? Are deep diver listening in. We've really

360
00:19:10.319 --> 00:19:12.960
<v Speaker 1>journeyed through the complexities of as your network security, haven't

361
00:19:12.960 --> 00:19:17.000
<v Speaker 1>we From understanding that crucial shared responsibility model, the real

362
00:19:17.039 --> 00:19:20.119
<v Speaker 1>threats driving the need for it, to building secure foundations

363
00:19:20.119 --> 00:19:24.119
<v Speaker 1>with v nets, peering, private link architecting with zero trust

364
00:19:24.119 --> 00:19:26.680
<v Speaker 1>in that hub and spoke model, and deploying these powerful

365
00:19:26.720 --> 00:19:31.480
<v Speaker 1>tools like Azure Firewall wf DDAs protection, all while making

366
00:19:31.519 --> 00:19:34.160
<v Speaker 1>sure we have the intelligence the visibility to monitor everything.

367
00:19:34.559 --> 00:19:37.799
<v Speaker 2>Yeah, and knowledge is really most valuable when it's understood

368
00:19:37.799 --> 00:19:40.839
<v Speaker 2>and actually applied. Right. What we've discussed today, it's all

369
00:19:40.839 --> 00:19:44.359
<v Speaker 2>about combining these different resources, these tools and concepts into

370
00:19:44.440 --> 00:19:48.920
<v Speaker 2>a truly holistic network security strategy. It's about creating a

371
00:19:49.000 --> 00:19:52.480
<v Speaker 2>layered defense, one that secures your assen deployments at every

372
00:19:52.480 --> 00:19:54.920
<v Speaker 2>critical point, from the network draft itself all the way

373
00:19:55.000 --> 00:19:58.680
<v Speaker 2>up to application delivery, and ensuring you have that crucial visibility,

374
00:19:58.720 --> 00:20:01.880
<v Speaker 2>to monitor, to respond, and importantly, to adapt as the

375
00:20:01.920 --> 00:20:02.880
<v Speaker 2>threats evolve.

376
00:20:02.680 --> 00:20:08.359
<v Speaker 1>Precisely, defense in depth, visibility and adaptability. And with that

377
00:20:08.640 --> 00:20:10.720
<v Speaker 1>we'll leave you with this provocative thought to chew on

378
00:20:10.799 --> 00:20:14.160
<v Speaker 1>for your own exploration, considering the layer defenses of your

379
00:20:14.200 --> 00:20:18.200
<v Speaker 1>own digital fort Thinking about everything we've covered, what specific

380
00:20:18.240 --> 00:20:21.079
<v Speaker 1>part of your cloud environment needs its digital drawbridge raised

381
00:20:21.079 --> 00:20:25.039
<v Speaker 1>a bit higher, or perhaps its centuries upgraded. Next, keep digging,

382
00:20:25.240 --> 00:20:28.680
<v Speaker 1>stay curious, most importantly, stay secure. We'll catch you on

383
00:20:28.720 --> 00:20:29.559
<v Speaker 1>the next deep dive.