WEBVTT

1
00:00:00.160 --> 00:00:03.720
<v Speaker 1>Welcome to the deep dive. Imagine your digital network is

2
00:00:03.759 --> 00:00:07.400
<v Speaker 1>like a really complex fault Okay, now, picture new cracks

3
00:00:07.440 --> 00:00:11.439
<v Speaker 1>forming every single day, often places you'd least expect, and

4
00:00:11.480 --> 00:00:14.279
<v Speaker 1>there are unknown eyes constantly probing for weaknesses.

5
00:00:14.359 --> 00:00:16.280
<v Speaker 2>Yeah, it's a constant battleground out.

6
00:00:16.120 --> 00:00:19.440
<v Speaker 1>There, exactly. So today we're taking a deep dive into

7
00:00:19.480 --> 00:00:23.519
<v Speaker 1>the critical world of network performance and security. Our mission,

8
00:00:23.960 --> 00:00:25.960
<v Speaker 1>we want to pull out the most crucial, the most

9
00:00:26.000 --> 00:00:31.399
<v Speaker 1>actionable insights from Chris Chapman's really foundational book Network Performance

10
00:00:31.399 --> 00:00:35.640
<v Speaker 1>and Security, Testing and analyzing using open source and low

11
00:00:35.679 --> 00:00:36.359
<v Speaker 1>cost tools.

12
00:00:36.479 --> 00:00:38.960
<v Speaker 2>It's a great source packed with practical.

13
00:00:38.560 --> 00:00:41.119
<v Speaker 1>Stuff, it really is. And this isn't just about theory, right.

14
00:00:41.640 --> 00:00:44.200
<v Speaker 1>Our goal is to give you a practical roadmap. Think

15
00:00:44.200 --> 00:00:47.200
<v Speaker 1>of it as a shortcut to understanding how to spot vulnerabilities,

16
00:00:47.240 --> 00:00:50.320
<v Speaker 1>actually harden your infrastructure and even test its resilience.

17
00:00:50.399 --> 00:00:53.679
<v Speaker 2>Now without getting totally overwhelmed by all the technical details.

18
00:00:53.920 --> 00:00:59.719
<v Speaker 1>Precisely, we'll uncover some surprising facts and really practical steps

19
00:00:59.719 --> 00:01:02.679
<v Speaker 1>that are directly relevant to you listening right now, because,

20
00:01:02.719 --> 00:01:04.959
<v Speaker 1>let's face it, in a world that depends entirely on

21
00:01:05.000 --> 00:01:09.040
<v Speaker 1>digital connections, your quality of experience, your productivity, even your

22
00:01:09.120 --> 00:01:11.640
<v Speaker 1>data is safety. It all hinges on a network that

23
00:01:11.799 --> 00:01:13.400
<v Speaker 1>secure and performs well.

24
00:01:13.680 --> 00:01:16.840
<v Speaker 2>Absolutely, whether you're prepping for a big meeting, trying to

25
00:01:16.840 --> 00:01:18.480
<v Speaker 2>stay current, or just curious.

26
00:01:18.599 --> 00:01:20.640
<v Speaker 1>Yeah, if you fit any of those, this deep dive

27
00:01:20.680 --> 00:01:23.879
<v Speaker 1>is definitely for you. Okay, So let's unpack this core truth.

28
00:01:24.120 --> 00:01:28.879
<v Speaker 1>The sources really highlight our networks. They're under continuous assault,

29
00:01:29.480 --> 00:01:32.280
<v Speaker 1>and not just from outside attackers, but often from within

30
00:01:32.400 --> 00:01:34.760
<v Speaker 1>what we mistakenly call a trusted zone.

31
00:01:34.959 --> 00:01:37.640
<v Speaker 2>That internal threat is often underestimated totally.

32
00:01:37.680 --> 00:01:40.400
<v Speaker 1>And what's really unsettling is this idea of the unknown unknown.

33
00:01:40.439 --> 00:01:43.840
<v Speaker 1>So those devices, those configurations we don't even realize are

34
00:01:43.920 --> 00:01:44.280
<v Speaker 1>on our.

35
00:01:44.200 --> 00:01:48.599
<v Speaker 2>Network lurking there, which brings up a critical point. What

36
00:01:48.920 --> 00:01:52.799
<v Speaker 2>happens when those attacks or maybe just poor performance actually

37
00:01:52.840 --> 00:01:55.560
<v Speaker 2>impacts you. We're all used to what the book calls

38
00:01:55.599 --> 00:01:57.840
<v Speaker 2>the web dial tone expectation.

39
00:01:57.719 --> 00:02:01.439
<v Speaker 1>Right, the idea that it's just always there, always on, predictable.

40
00:02:01.040 --> 00:02:03.319
<v Speaker 2>Exactly, and when you hit a four h four error

41
00:02:03.359 --> 00:02:06.799
<v Speaker 2>where things are just slow, it's not just annoying, it

42
00:02:06.920 --> 00:02:11.319
<v Speaker 2>directly impacts productivity. Chapman points out if authentication takes more

43
00:02:11.360 --> 00:02:15.280
<v Speaker 2>than four seconds, or a web page more than seven seconds.

44
00:02:14.879 --> 00:02:17.000
<v Speaker 1>To load, people just leave, They click away.

45
00:02:17.159 --> 00:02:21.120
<v Speaker 2>Most users just abort. Think about that loss of efficiency.

46
00:02:21.280 --> 00:02:25.120
<v Speaker 2>Even voice quality like on a VOYIP call has a benchmark,

47
00:02:25.159 --> 00:02:27.520
<v Speaker 2>the MOS score. You really want that at four point

48
00:02:27.520 --> 00:02:29.960
<v Speaker 2>two or higher. Anything less feels off.

49
00:02:30.120 --> 00:02:32.719
<v Speaker 1>Okay, and here's where it's really interesting for me, this

50
00:02:32.840 --> 00:02:36.840
<v Speaker 1>whole concept of trust in security. Ah Chatman makes this

51
00:02:36.919 --> 00:02:40.919
<v Speaker 1>really powerful statement. He says trust is a non controllable,

52
00:02:41.400 --> 00:02:44.560
<v Speaker 1>non measurable assumption that someone will always do the right thing.

53
00:02:44.840 --> 00:02:46.639
<v Speaker 1>He basically calls it soft security.

54
00:02:46.680 --> 00:02:49.599
<v Speaker 2>It's intangible, isn't it. You can't configure trust exactly.

55
00:02:49.680 --> 00:02:53.039
<v Speaker 1>And then there's this alarming statistic he includes sixty percent

56
00:02:53.039 --> 00:02:55.439
<v Speaker 1>of employees who are fired have been found to steal data.

57
00:02:55.479 --> 00:02:56.919
<v Speaker 2>Wow, sixty percent.

58
00:02:57.319 --> 00:03:01.800
<v Speaker 1>Yeah, So, relying purely on trust, it's just fundamentally incompatible

59
00:03:01.800 --> 00:03:05.319
<v Speaker 1>with a robust security policy. So for you listening, you

60
00:03:05.360 --> 00:03:10.039
<v Speaker 1>expect your network to work flawlessly. Sure, but understanding these vulnerabilities,

61
00:03:10.039 --> 00:03:14.919
<v Speaker 1>these well unrealistic expectations about trust, that's crucial for being

62
00:03:15.000 --> 00:03:17.199
<v Speaker 1>proactive about your own digital safety day to day.

63
00:03:17.360 --> 00:03:18.240
<v Speaker 2>Couldn't agree more.

64
00:03:18.759 --> 00:03:23.360
<v Speaker 1>So, Okay, if trust is bad for security, then visibility

65
00:03:23.439 --> 00:03:24.240
<v Speaker 1>must be good. Right.

66
00:03:24.439 --> 00:03:27.159
<v Speaker 2>Visibility is everything, It's the foundation So the.

67
00:03:27.080 --> 00:03:30.759
<v Speaker 1>First absolutely critical step is getting organized with a thorough

68
00:03:30.800 --> 00:03:33.800
<v Speaker 1>network audit. Our source really drives home this point. What

69
00:03:33.879 --> 00:03:34.680
<v Speaker 1>you think is on your.

70
00:03:34.520 --> 00:03:37.599
<v Speaker 2>Network can be worlds apart from what's actually there, right.

71
00:03:37.599 --> 00:03:40.960
<v Speaker 1>And it only takes one undocumented, maybe unpatched device, that

72
00:03:41.000 --> 00:03:43.280
<v Speaker 1>old PC in the lab everyone forgot about, or a

73
00:03:43.319 --> 00:03:44.719
<v Speaker 1>private server someone stuck under a.

74
00:03:44.719 --> 00:03:46.719
<v Speaker 2>Desk, uh huh, the classic shadow it.

75
00:03:47.080 --> 00:03:50.400
<v Speaker 1>Exactly, that becomes the perfect beachhead for malware or bot nets.

76
00:03:50.599 --> 00:03:53.680
<v Speaker 1>And then you're looking at a massive, expensive cleanup job.

77
00:03:53.840 --> 00:03:56.719
<v Speaker 2>And the real insight you get from doing this exhaustive audit,

78
00:03:57.319 --> 00:03:59.800
<v Speaker 2>it isn't just knowing what you have, it's realizing how

79
00:03:59.879 --> 00:04:01.360
<v Speaker 2>much which you didn't know you had.

80
00:04:01.719 --> 00:04:03.960
<v Speaker 1>That's a great way to put it, turning those unknown

81
00:04:04.039 --> 00:04:05.080
<v Speaker 1>unknowns into.

82
00:04:04.840 --> 00:04:08.120
<v Speaker 2>Nones precisely, that's your first real line of defense and

83
00:04:08.199 --> 00:04:11.039
<v Speaker 2>the scope of this audit, while it's pretty comprehensive, you

84
00:04:11.120 --> 00:04:14.520
<v Speaker 2>need to document basically every single device that touches your network.

85
00:04:14.719 --> 00:04:16.759
<v Speaker 1>Okay, break that down. What kind of devices?

86
00:04:16.879 --> 00:04:22.399
<v Speaker 2>Well, first host assets, think fixed PCs, laptops, tablets, smartphones.

87
00:04:22.639 --> 00:04:26.120
<v Speaker 2>You need the basics, make model, but also IP address

88
00:04:26.199 --> 00:04:29.480
<v Speaker 2>and massy address, the OS version, all the installed.

89
00:04:29.040 --> 00:04:30.480
<v Speaker 1>Software approved and unapproved.

90
00:04:30.519 --> 00:04:33.600
<v Speaker 2>Oh absolutely, you need to know what's actually running and

91
00:04:33.720 --> 00:04:36.600
<v Speaker 2>even who owns the device. Then you've got mobile assets.

92
00:04:37.040 --> 00:04:38.759
<v Speaker 2>These are trickier because they come and go.

93
00:04:38.920 --> 00:04:41.360
<v Speaker 1>You have laptops phones, right, The.

94
00:04:41.279 --> 00:04:44.720
<v Speaker 2>Book suggests something pretty clever placing asset tags inside the

95
00:04:44.720 --> 00:04:48.120
<v Speaker 2>battery case for laptops harder to remove. Helps with tracking.

96
00:04:48.279 --> 00:04:49.639
<v Speaker 1>That's smart, Okay? What else?

97
00:04:49.920 --> 00:04:53.120
<v Speaker 2>Virtualized servers they add another layer You need more than

98
00:04:53.160 --> 00:04:56.920
<v Speaker 2>just standard server stuff. Think VM profiles, snapshot states, the

99
00:04:57.040 --> 00:04:59.680
<v Speaker 2>data stores they're attached to, and the whole network functions

100
00:04:59.680 --> 00:05:03.199
<v Speaker 2>of virtu ualization chain. That's NFV where network services run

101
00:05:03.240 --> 00:05:05.600
<v Speaker 2>in software right up to the physical network card.

102
00:05:05.879 --> 00:05:08.720
<v Speaker 1>So really deep visibility into the virtual layer.

103
00:05:08.720 --> 00:05:12.680
<v Speaker 2>Two, you have to tools like HWI, NFO or just

104
00:05:12.800 --> 00:05:16.240
<v Speaker 2>built in system info commands are key here and don't

105
00:05:16.240 --> 00:05:19.360
<v Speaker 2>forget hypervisor admin accounts critical to document those.

106
00:05:19.240 --> 00:05:21.399
<v Speaker 1>Got it? What about the network gear itself?

107
00:05:21.560 --> 00:05:28.160
<v Speaker 2>Yep, network element objects, switches, routers again, make model adamin credentials,

108
00:05:28.319 --> 00:05:30.959
<v Speaker 2>port types like is it one gig or ten gig?

109
00:05:31.000 --> 00:05:34.199
<v Speaker 2>And what connects? Where you're basically drawing a living network

110
00:05:34.240 --> 00:05:37.240
<v Speaker 2>map and you need to version control the configurations so

111
00:05:37.319 --> 00:05:39.399
<v Speaker 2>you track every single change.

112
00:05:39.120 --> 00:05:41.480
<v Speaker 1>Okay, that makes sense, like source control for your network.

113
00:05:41.199 --> 00:05:44.279
<v Speaker 2>Configure kind of Yeah. And finally, and this is often

114
00:05:44.360 --> 00:05:50.040
<v Speaker 2>overlooked information assets your data house. So most places have

115
00:05:50.120 --> 00:05:53.680
<v Speaker 2>really weak rules about where data is stored. Chatman stresses

116
00:05:53.720 --> 00:05:57.399
<v Speaker 2>classifying info maybe level ABC, with strict policies for each

117
00:05:57.480 --> 00:05:59.920
<v Speaker 2>like level A data your most sensitive stuff. It can

118
00:06:00.040 --> 00:06:02.079
<v Speaker 2>cannot be stored on a local PC, never in a

119
00:06:02.079 --> 00:06:05.079
<v Speaker 2>public cloud, not accessible from the Internet period.

120
00:06:05.240 --> 00:06:08.920
<v Speaker 1>That's really strict, but necessary if you're serious about protecting it.

121
00:06:09.040 --> 00:06:11.800
<v Speaker 2>Yes, okay, that is a ton of information to gather

122
00:06:11.839 --> 00:06:14.240
<v Speaker 2>and manage. How do you keep track of it all? Yeah,

123
00:06:14.319 --> 00:06:17.240
<v Speaker 2>you definitely need a system. The book points towards needing

124
00:06:17.240 --> 00:06:20.959
<v Speaker 2>a network management system in NMS. It actually recommends spice

125
00:06:20.959 --> 00:06:22.639
<v Speaker 2>works is a good open source option.

126
00:06:22.839 --> 00:06:25.920
<v Speaker 1>Spie works. Okay, is setting that up complicated?

127
00:06:26.040 --> 00:06:28.639
<v Speaker 2>It needs to be done strategically. You need a dedicated

128
00:06:28.720 --> 00:06:32.279
<v Speaker 2>server for it, pretty high end and definitely isolated, probably

129
00:06:32.279 --> 00:06:34.680
<v Speaker 2>a modern Windows server machine.

130
00:06:34.240 --> 00:06:36.399
<v Speaker 1>And you put that somewhere super secure.

131
00:06:36.199 --> 00:06:39.600
<v Speaker 2>Absolutely in a very secure zone. But here's the counterintuitive part.

132
00:06:40.160 --> 00:06:44.199
<v Speaker 2>You don't typically install firewall software directly on the NMS

133
00:06:44.240 --> 00:06:44.959
<v Speaker 2>server itself.

134
00:06:45.120 --> 00:06:45.759
<v Speaker 1>Really, why not?

135
00:06:46.120 --> 00:06:49.639
<v Speaker 2>You want to minimize its own attack surface. Instead, you

136
00:06:50.199 --> 00:06:55.680
<v Speaker 2>carefully open specific pinholes point security policies on your internal

137
00:06:55.720 --> 00:06:58.759
<v Speaker 2>firewalls to let the NMS scan the network segments it

138
00:06:58.839 --> 00:06:59.199
<v Speaker 2>needs to.

139
00:07:00.160 --> 00:07:03.000
<v Speaker 1>So the protection is on the surrounding firewalls, letting the

140
00:07:03.079 --> 00:07:04.800
<v Speaker 1>NMS do its job exactly.

141
00:07:04.920 --> 00:07:07.519
<v Speaker 2>It needs tools like windp cap and a MIP installed

142
00:07:07.560 --> 00:07:10.600
<v Speaker 2>two for standing. But the big takeaway from the audit

143
00:07:10.639 --> 00:07:14.360
<v Speaker 2>process is this knowing what you have is the absolute

144
00:07:14.399 --> 00:07:15.959
<v Speaker 2>fundamental layer of defense.

145
00:07:16.519 --> 00:07:17.839
<v Speaker 1>Without it, you're just You're.

146
00:07:17.720 --> 00:07:21.000
<v Speaker 2>Fighting blind and just one forgotten device can bring the

147
00:07:21.040 --> 00:07:21.879
<v Speaker 2>whole thing down.

148
00:07:22.160 --> 00:07:25.399
<v Speaker 1>Okay, so audit complete, you have this incredibly detailed picture

149
00:07:25.399 --> 00:07:26.839
<v Speaker 1>of your network. What's next?

150
00:07:27.079 --> 00:07:30.680
<v Speaker 2>Right now? You lock it down, harden the infrastructure itself.

151
00:07:31.120 --> 00:07:35.680
<v Speaker 2>And this means really moving beyond that old simplistic trusted

152
00:07:35.800 --> 00:07:38.000
<v Speaker 2>versus untrusted mindset.

153
00:07:38.319 --> 00:07:41.720
<v Speaker 1>You mean treating everything is potentially untrusted pretty much.

154
00:07:41.839 --> 00:07:45.759
<v Speaker 2>It's about internal segmentation, breaking your network into smaller, more

155
00:07:45.759 --> 00:07:47.759
<v Speaker 2>defensible zones, even internally.

156
00:07:47.959 --> 00:07:49.480
<v Speaker 1>So how does that look in practice?

157
00:07:49.600 --> 00:07:52.399
<v Speaker 2>Well, it applies everywhere from the edge right to the core.

158
00:07:52.720 --> 00:07:55.800
<v Speaker 2>For core network hardening, the rule is simple but powerful.

159
00:07:55.920 --> 00:07:59.279
<v Speaker 2>If you don't absolutely need a service or protocol running,

160
00:08:00.240 --> 00:08:00.759
<v Speaker 2>turn it off.

161
00:08:00.800 --> 00:08:02.360
<v Speaker 1>Get rid of the unnecessary stuff.

162
00:08:02.399 --> 00:08:06.439
<v Speaker 2>Exactly. Disable things like telnet old routing protocols like RIP

163
00:08:06.560 --> 00:08:10.680
<v Speaker 2>if you're not using them. Unencrypted HTTP management interfaces just

164
00:08:10.720 --> 00:08:11.920
<v Speaker 2>reduce the attack surface.

165
00:08:12.360 --> 00:08:13.759
<v Speaker 1>What about managing the devices?

166
00:08:13.920 --> 00:08:18.480
<v Speaker 2>Always always encrypt management sessions use SSH, configure it robustly,

167
00:08:18.560 --> 00:08:22.560
<v Speaker 2>set session timeouts, limit log in attempts. Basic hygiene, but

168
00:08:22.680 --> 00:08:23.759
<v Speaker 2>critical and logging.

169
00:08:23.800 --> 00:08:24.680
<v Speaker 1>You mentioned that earlier.

170
00:08:24.759 --> 00:08:29.319
<v Speaker 2>Critical logging is huge for incident response for forensics, but

171
00:08:29.439 --> 00:08:31.360
<v Speaker 2>it's not just about having logs. They need to be

172
00:08:31.439 --> 00:08:33.600
<v Speaker 2>time correlated across all devices.

173
00:08:33.840 --> 00:08:36.679
<v Speaker 1>Ah, so you can piece together what happened when precisely.

174
00:08:36.919 --> 00:08:40.559
<v Speaker 2>That means you need a dedicated, accurate NTP time source

175
00:08:40.639 --> 00:08:44.879
<v Speaker 2>like a gpscinc server and a centralized cyslog server. Both

176
00:08:44.879 --> 00:08:47.399
<v Speaker 2>of those need to be in a secure core zone themselves.

177
00:08:47.440 --> 00:08:51.120
<v Speaker 1>Okay, what about protecting against fake traffic spoofing?

178
00:08:51.440 --> 00:08:55.480
<v Speaker 2>Good question. Anti spoofing protection is vital, especially at the edge,

179
00:08:55.519 --> 00:08:59.679
<v Speaker 2>but also useful internally things like unicast reverse path forwarding

180
00:09:00.360 --> 00:09:01.279
<v Speaker 2>or URFP.

181
00:09:01.559 --> 00:09:02.120
<v Speaker 1>What does that do?

182
00:09:02.399 --> 00:09:05.240
<v Speaker 2>It basically checks if the source IP address on an

183
00:09:05.240 --> 00:09:08.799
<v Speaker 2>incoming packet is actually reachable via the interface it arrived on.

184
00:09:09.320 --> 00:09:13.519
<v Speaker 2>Helps block packets with forged source ips. And IP source guard,

185
00:09:13.600 --> 00:09:17.320
<v Speaker 2>which uses DHCP snooping data to build dynamic access lists,

186
00:09:17.360 --> 00:09:21.120
<v Speaker 2>binding ips to mday's and ports. Even just enabling basic

187
00:09:21.159 --> 00:09:24.320
<v Speaker 2>port security on switches helps catch MAC spoofing attempts.

188
00:09:24.399 --> 00:09:27.480
<v Speaker 1>So multiple layers there. Now, what about performance? People always

189
00:09:27.519 --> 00:09:28.679
<v Speaker 1>complain about slowness.

190
00:09:28.799 --> 00:09:32.440
<v Speaker 2>Right, optimizing performance with QoS quality of service. Often just

191
00:09:32.480 --> 00:09:34.519
<v Speaker 2>throwing more bandwidth at a problem isn't the fix.

192
00:09:34.840 --> 00:09:36.320
<v Speaker 1>Yeah, upgrades don't always help.

193
00:09:36.440 --> 00:09:41.559
<v Speaker 2>Instead, classifier traffic, put services into buckets, network abmin, business critical,

194
00:09:41.639 --> 00:09:44.960
<v Speaker 2>business standard, best effort, whatever makes sense for you. Then

195
00:09:45.120 --> 00:09:49.039
<v Speaker 2>use QoS like diffserve markings at layer three to tell

196
00:09:49.039 --> 00:09:52.519
<v Speaker 2>the network what's important. So even if some malware or

197
00:09:52.559 --> 00:09:55.120
<v Speaker 2>a botnet starts hogging bandwidth.

198
00:09:54.559 --> 00:09:57.559
<v Speaker 1>The network knows to prioritize the critical stuff exactly.

199
00:09:57.879 --> 00:10:00.000
<v Speaker 2>Your important applications stay responsive.

200
00:10:00.240 --> 00:10:04.120
<v Speaker 1>What about wide area networks connections between sites WAN security?

201
00:10:04.320 --> 00:10:06.559
<v Speaker 2>This is a big one. We tend to think of

202
00:10:06.600 --> 00:10:10.279
<v Speaker 2>our WAN links as inside and trusted.

203
00:10:09.960 --> 00:10:11.480
<v Speaker 1>Because they connect our offices. Right.

204
00:10:11.559 --> 00:10:13.919
<v Speaker 2>Yeah, but that's a dangerous assumption. The book is clear,

205
00:10:14.200 --> 00:10:17.320
<v Speaker 2>treat your WAN as its own untrusted security zone.

206
00:10:17.360 --> 00:10:19.360
<v Speaker 1>Okay, so encrypt everything.

207
00:10:19.679 --> 00:10:23.200
<v Speaker 2>Strong encryption is non negotiable. Think AES two five six

208
00:10:23.200 --> 00:10:26.879
<v Speaker 2>with robust hashing like SA five twelve using X point

209
00:10:26.879 --> 00:10:30.399
<v Speaker 2>five zero nine certificates. Often this means dedicated hardware encryption

210
00:10:30.480 --> 00:10:31.559
<v Speaker 2>boxes between sites.

211
00:10:31.759 --> 00:10:32.799
<v Speaker 1>Right. How about wi fi?

212
00:10:33.399 --> 00:10:36.919
<v Speaker 2>Always a headache organizational Wi Fi best practice? Think DMZ

213
00:10:37.039 --> 00:10:40.639
<v Speaker 2>for wireless, set up two ssas one for internal trusted,

214
00:10:40.720 --> 00:10:44.399
<v Speaker 2>use strong password, mixed case number symbols, and don't broadcast

215
00:10:44.399 --> 00:10:47.639
<v Speaker 2>the sad name it it YEP, and then a separate

216
00:10:47.679 --> 00:10:50.480
<v Speaker 2>guest network. It's okay to broadcast that one, but all

217
00:10:50.559 --> 00:10:53.360
<v Speaker 2>guest traffic must be tunneled directly out to your Internet

218
00:10:53.399 --> 00:10:57.080
<v Speaker 2>security zone, no access to the internal network, and make

219
00:10:57.120 --> 00:11:00.480
<v Speaker 2>them accept terms. Maybe use two step authentication if possible

220
00:11:00.519 --> 00:11:01.039
<v Speaker 2>for guests.

221
00:11:01.279 --> 00:11:03.720
<v Speaker 1>Okay, separating those makes a lot of sense. What about

222
00:11:03.720 --> 00:11:05.480
<v Speaker 1>the main Internet connection itself?

223
00:11:05.759 --> 00:11:09.600
<v Speaker 2>Your external firewall and Internet connection. This is where you

224
00:11:09.639 --> 00:11:14.039
<v Speaker 2>need serious hardware. The book recommends high end firewalls, the

225
00:11:14.159 --> 00:11:16.000
<v Speaker 2>kind based on A six or.

226
00:11:15.919 --> 00:11:19.159
<v Speaker 1>FPGA's dedicated hardware for speed, right.

227
00:11:19.000 --> 00:11:21.639
<v Speaker 2>Because they need to do deep packet inspection and handle

228
00:11:21.679 --> 00:11:24.679
<v Speaker 2>lots of connections without slowing down. They let you do

229
00:11:24.759 --> 00:11:28.679
<v Speaker 2>really granular control too, like maybe allow Skype chat but

230
00:11:28.960 --> 00:11:30.519
<v Speaker 2>block Skype file transfers.

231
00:11:30.639 --> 00:11:32.480
<v Speaker 1>Ah control within the application itself.

232
00:11:32.600 --> 00:11:36.200
<v Speaker 2>Yes, and use firewalls between your internal zones too to

233
00:11:36.360 --> 00:11:40.879
<v Speaker 2>sandbox risk. For remote users, IPsec VPN is generally preferred

234
00:11:40.879 --> 00:11:45.600
<v Speaker 2>over SSLVPN, using per user authentication and certificates and all

235
00:11:45.639 --> 00:11:48.159
<v Speaker 2>that remote traffic needs to be inspected by the firewalls,

236
00:11:48.240 --> 00:11:50.200
<v Speaker 2>intrusion prevention and dedoss engines.

237
00:11:50.240 --> 00:11:52.559
<v Speaker 1>One last thing you mentioned, yeah printers really?

238
00:11:52.679 --> 00:11:56.519
<v Speaker 2>Oh yeah, locking down printers. People forget them, but they're

239
00:11:56.519 --> 00:12:01.639
<v Speaker 2>basically network connected computers with their own vulnerabilities. Interfaces, different protocols.

240
00:12:01.679 --> 00:12:02.440
<v Speaker 1>Okay, so what do you do?

241
00:12:02.519 --> 00:12:07.360
<v Speaker 2>Treat them seriously? Enable HTTPS only for the web management interface,

242
00:12:07.759 --> 00:12:12.159
<v Speaker 2>Use strong passwords that you actually rotate. Restrict SMMP access

243
00:12:12.200 --> 00:12:15.120
<v Speaker 2>so only your NMS can talk to it. Disabled telnet

244
00:12:15.159 --> 00:12:18.919
<v Speaker 2>if it's somehow still enabled. Use secure printing protocols like

245
00:12:18.960 --> 00:12:20.480
<v Speaker 2>IPP over TLS.

246
00:12:20.559 --> 00:12:23.919
<v Speaker 1>Oh wow. Okay. The big picture here is definitely layers.

247
00:12:24.080 --> 00:12:28.120
<v Speaker 2>It absolutely is a truly secure infrastructure is defense in depth.

248
00:12:28.519 --> 00:12:32.039
<v Speaker 2>Every device, every protocol, every potential path for traffic needs

249
00:12:32.039 --> 00:12:35.200
<v Speaker 2>scrutiny and being aggressive about disabling services you don't need.

250
00:12:35.399 --> 00:12:38.320
<v Speaker 2>That drastically shrinks the area attackers can target right.

251
00:12:38.600 --> 00:12:40.679
<v Speaker 1>Less surface area means fewer potential holes.

252
00:12:40.720 --> 00:12:41.200
<v Speaker 2>You got it.

253
00:12:41.320 --> 00:12:44.159
<v Speaker 1>Okay, let's shift focus a bit. Let's talk about the endpoint,

254
00:12:44.320 --> 00:12:47.000
<v Speaker 1>the client computer. For many of us, that's a Windows machine,

255
00:12:47.559 --> 00:12:51.120
<v Speaker 1>and the sources are really clear on this. The client

256
00:12:51.200 --> 00:12:53.639
<v Speaker 1>is often a major point of attack, maybe even the

257
00:12:53.639 --> 00:12:54.840
<v Speaker 1>weakest link in the whole chain.

258
00:12:55.039 --> 00:12:58.360
<v Speaker 2>It frequently is. Unfortunately, it's where the user interacts directly,

259
00:12:58.480 --> 00:12:59.639
<v Speaker 2>clicks on things.

260
00:12:59.679 --> 00:13:02.559
<v Speaker 1>So hardening that client is crucial. What are the key steps.

261
00:13:02.840 --> 00:13:06.759
<v Speaker 2>It's fundamentally about minimizing that attack surface and maximizing the

262
00:13:06.759 --> 00:13:11.919
<v Speaker 2>built in protections. First off, software control big one. Users

263
00:13:11.919 --> 00:13:16.039
<v Speaker 2>should never have administrator or even power user rights.

264
00:13:16.039 --> 00:13:18.720
<v Speaker 1>Full stop, standard user accounts only. Yes.

265
00:13:19.120 --> 00:13:22.159
<v Speaker 2>Instead, you use things like software restriction policies pushed out

266
00:13:22.200 --> 00:13:25.559
<v Speaker 2>via group policy, maybe with w MII filtering for targeting.

267
00:13:25.960 --> 00:13:29.320
<v Speaker 2>You basically whitelist only the approved applications that are allowed

268
00:13:29.360 --> 00:13:29.720
<v Speaker 2>to run.

269
00:13:29.799 --> 00:13:32.240
<v Speaker 1>So users literally can install random stuff they.

270
00:13:32.159 --> 00:13:36.960
<v Speaker 2>Download exactly, no accidentally installing infected executables or those annoying

271
00:13:37.120 --> 00:13:40.840
<v Speaker 2>browser toolbars that come bundled with things. Next, User account

272
00:13:40.879 --> 00:13:42.320
<v Speaker 2>control UAC.

273
00:13:42.200 --> 00:13:43.840
<v Speaker 1>That pop up everyone loves to hate.

274
00:13:43.879 --> 00:13:46.720
<v Speaker 2>That's the one. Turn it up to its highest setting. Yes,

275
00:13:46.759 --> 00:13:49.039
<v Speaker 2>it can be annoying, but it adds a really crucial

276
00:13:49.159 --> 00:13:53.399
<v Speaker 2>layer prompting for authorization before software installs or system changes.

277
00:13:53.759 --> 00:13:56.159
<v Speaker 2>It stops a lot of automated malware in its tracks.

278
00:13:56.200 --> 00:13:59.320
<v Speaker 1>Okay, makes sense. What about the networking side of Windows itself?

279
00:13:59.600 --> 00:14:04.120
<v Speaker 2>Yeah, Hardening Windows networking disable unnecessary stuff. If you're not

280
00:14:04.200 --> 00:14:07.120
<v Speaker 2>using IPv six internally, turn it off on the clients.

281
00:14:07.480 --> 00:14:10.720
<v Speaker 2>Same for things like IGMP or Universal Plug and Play

282
00:14:10.840 --> 00:14:13.559
<v Speaker 2>UPMP is notoriously problematic for security.

283
00:14:13.759 --> 00:14:14.960
<v Speaker 1>How do you check what's running?

284
00:14:15.039 --> 00:14:18.639
<v Speaker 2>You want to minimize listening ports, run netstat ab and

285
00:14:18.759 --> 00:14:21.919
<v Speaker 2>en in the command prompt that shows you which executables

286
00:14:21.960 --> 00:14:24.799
<v Speaker 2>are listening on which ports. If you see something listening

287
00:14:24.799 --> 00:14:27.600
<v Speaker 2>that you don't recognize, our need, investigate and remove it.

288
00:14:27.759 --> 00:14:29.960
<v Speaker 1>Good tip. What about other Windows services?

289
00:14:30.080 --> 00:14:33.799
<v Speaker 2>Right? Disabling unnecessary services? Windows comes with a lot of

290
00:14:33.840 --> 00:14:36.840
<v Speaker 2>services running by default. There are great resources online, like

291
00:14:36.879 --> 00:14:39.679
<v Speaker 2>the black Viper blog mentioned in the source that list

292
00:14:39.720 --> 00:14:43.039
<v Speaker 2>services and whether they're typically safe to disable. Think about

293
00:14:43.080 --> 00:14:47.039
<v Speaker 2>things like IP helper, offline files, parental controls if it's

294
00:14:47.039 --> 00:14:51.559
<v Speaker 2>corporate machine, fax service, home group listeners, Bluetooth support if

295
00:14:51.600 --> 00:14:54.279
<v Speaker 2>you don't use bluetooth, proper roles. If you don't need it,

296
00:14:54.440 --> 00:14:56.960
<v Speaker 2>disable it again. Reducing the attack surfaces.

297
00:14:57.000 --> 00:14:59.279
<v Speaker 1>Okay, browsers are obviously huge, too.

298
00:14:59.360 --> 00:15:04.600
<v Speaker 2>Huge browser heartening. Ideally standardize the organization on one browser.

299
00:15:04.639 --> 00:15:07.600
<v Speaker 2>The source recommends Chrome because it removed the old insecure

300
00:15:07.840 --> 00:15:12.039
<v Speaker 2>NPPI plugin system, but whatever you choose, the absolute crucial

301
00:15:12.080 --> 00:15:17.240
<v Speaker 2>thing is enable automatic updates, always be patched always. Then

302
00:15:17.360 --> 00:15:20.960
<v Speaker 2>configure the settings tightly, for ie, set the internet zone

303
00:15:21.000 --> 00:15:25.120
<v Speaker 2>to high, enable protected mode, smart screen, ActiveX filtering, tracking protection,

304
00:15:25.600 --> 00:15:29.320
<v Speaker 2>turn off third party browser extensions unless explicitly.

305
00:15:28.799 --> 00:15:31.320
<v Speaker 1>Approved, and for Chrome or Firefox.

306
00:15:30.919 --> 00:15:35.440
<v Speaker 2>Similar principles. Configure privacy settings, aggressively block third party cookies,

307
00:15:35.559 --> 00:15:38.759
<v Speaker 2>enable fishing and malware protections, and do not track requests.

308
00:15:38.840 --> 00:15:42.039
<v Speaker 2>And a big one, never allow the browser to save passwords.

309
00:15:42.200 --> 00:15:44.759
<v Speaker 2>Convenience versus security. Security wins here.

310
00:15:44.919 --> 00:15:47.519
<v Speaker 1>Good point. What about Java still a thing?

311
00:15:47.919 --> 00:15:53.120
<v Speaker 2>Still a thing, still needs attention Java security. Keep it updated,

312
00:15:53.240 --> 00:15:56.360
<v Speaker 2>but only from the official Java dot com site. Make

313
00:15:56.440 --> 00:15:59.600
<v Speaker 2>sure only the latest version is installed, uninstall old ones

314
00:16:00.120 --> 00:16:02.720
<v Speaker 2>in the Java control panel, set the security level too

315
00:16:02.879 --> 00:16:06.720
<v Speaker 2>high or very high, and be very strict about adding

316
00:16:06.759 --> 00:16:10.919
<v Speaker 2>exceptions to the security prompts. Only allow internal trusted applications

317
00:16:10.960 --> 00:16:12.360
<v Speaker 2>if absolutely necessary.

318
00:16:12.600 --> 00:16:15.519
<v Speaker 1>Okay, so these are all really concrete steps someone listening

319
00:16:15.559 --> 00:16:17.360
<v Speaker 1>can take, maybe even check on their own machine.

320
00:16:17.480 --> 00:16:21.440
<v Speaker 2>Absolutely, it's about transforming that potential weak link into a

321
00:16:21.519 --> 00:16:24.279
<v Speaker 2>much more robust part of the overall network defense.

322
00:16:24.440 --> 00:16:27.240
<v Speaker 1>All right, so we've audited, we've hardened the infrastructure, we've

323
00:16:27.240 --> 00:16:30.320
<v Speaker 1>hardened the client. Feels like we've built a pretty solid fortress.

324
00:16:30.320 --> 00:16:32.559
<v Speaker 2>It's a good start, But how do you know it's solid?

325
00:16:32.639 --> 00:16:35.759
<v Speaker 2>How do you know the defenses actually work against real

326
00:16:35.799 --> 00:16:36.840
<v Speaker 2>world techniques?

327
00:16:37.120 --> 00:16:40.799
<v Speaker 1>Ah? Right? Testing? This is where penetration testing comes.

328
00:16:40.600 --> 00:16:46.120
<v Speaker 2>In, exactly, penetration testing and deep traffic analysis. Because the attackers,

329
00:16:46.639 --> 00:16:50.480
<v Speaker 2>they're sophisticated, they use multi stage attacks. They might be

330
00:16:50.519 --> 00:16:54.600
<v Speaker 2>after data, trying industrial espionage, even engaging in cyber warfare.

331
00:16:54.639 --> 00:16:57.240
<v Speaker 2>You have to test your defenses against those kinds of threats.

332
00:16:57.360 --> 00:16:59.440
<v Speaker 1>So you need to think like an attacker to defend.

333
00:16:59.200 --> 00:17:03.519
<v Speaker 2>Against themsolutely do understand our techniques. The book mentions things

334
00:17:03.559 --> 00:17:07.920
<v Speaker 2>like knock down attacks, finding backdoors, multi step multi host

335
00:17:07.920 --> 00:17:11.960
<v Speaker 2>attacks to spread bots, reconnaissance to gather info, scanning for

336
00:17:12.039 --> 00:17:16.880
<v Speaker 2>open ports, gaining access, maybe creating hidden admin accounts, maintaining

337
00:17:16.920 --> 00:17:20.640
<v Speaker 2>that access, and then covering their tracks, deleting logs.

338
00:17:20.880 --> 00:17:22.319
<v Speaker 1>So how do you test against that well.

339
00:17:22.319 --> 00:17:25.119
<v Speaker 2>The testing philosophy is key. Security audits aren't a one

340
00:17:25.119 --> 00:17:28.200
<v Speaker 2>and done thing. They're perishable. They need to be done regularly.

341
00:17:28.599 --> 00:17:31.119
<v Speaker 2>The source suggests monthly, which is pretty frequent, but definitely

342
00:17:31.119 --> 00:17:33.319
<v Speaker 2>trigger one after any major network change or when a

343
00:17:33.319 --> 00:17:37.440
<v Speaker 2>big new vulnerability is announced. And critically, never assume the

344
00:17:37.480 --> 00:17:41.359
<v Speaker 2>internal network is safe. Test from the inside too. Threats

345
00:17:41.400 --> 00:17:43.480
<v Speaker 2>can absolutely originate internally.

346
00:17:43.599 --> 00:17:46.319
<v Speaker 1>Okay, what tools do you use for this? The book

347
00:17:46.400 --> 00:17:47.480
<v Speaker 1>mentions Colie Linux.

348
00:17:47.759 --> 00:17:50.759
<v Speaker 2>Yeah, Colilinux is sort of the Swiss army knife for this.

349
00:17:51.319 --> 00:17:55.680
<v Speaker 2>It's a Linux distribution packed with security and penetration testing tools.

350
00:17:56.119 --> 00:17:58.160
<v Speaker 2>One of the most powerful tools within it is.

351
00:17:58.279 --> 00:18:01.720
<v Speaker 1>Metasploy metasploit heard of it? What does it do?

352
00:18:02.079 --> 00:18:05.480
<v Speaker 2>It's an open source framework. It contains a huge database

353
00:18:05.480 --> 00:18:09.200
<v Speaker 2>of known exports. You can search for exploits targeting specific

354
00:18:09.279 --> 00:18:13.559
<v Speaker 2>software like Windows versions or applications like mysequel. You set

355
00:18:13.559 --> 00:18:16.799
<v Speaker 2>your target, configure any options the exploit needs, and then

356
00:18:16.839 --> 00:18:18.200
<v Speaker 2>you type exploit and.

357
00:18:18.160 --> 00:18:20.119
<v Speaker 1>It tries to break in ethically of.

358
00:18:20.079 --> 00:18:23.599
<v Speaker 2>Course, ethically yes, It launches the attack, and if it's successful,

359
00:18:23.720 --> 00:18:26.119
<v Speaker 2>metasploit can deliver a payload. Often that's the.

360
00:18:26.039 --> 00:18:27.960
<v Speaker 1>Mitipriter shell and that sounds bad.

361
00:18:28.079 --> 00:18:31.000
<v Speaker 2>It is. The book calls it the keys to the Kingdom.

362
00:18:31.079 --> 00:18:33.799
<v Speaker 2>It gives the tester or an attacker deep control over

363
00:18:33.839 --> 00:18:37.319
<v Speaker 2>the compromise machine. They can run commands, browse files, even

364
00:18:37.440 --> 00:18:40.960
<v Speaker 2>enable keyloggers to capture passwords or turn on remote desktop.

365
00:18:41.079 --> 00:18:44.160
<v Speaker 1>Okay, scary stuff. So how do you protect against that

366
00:18:44.279 --> 00:18:45.519
<v Speaker 1>kind of penetration attack?

367
00:18:45.640 --> 00:18:48.680
<v Speaker 2>Protecting your assets requires that layered defense we talked about.

368
00:18:49.559 --> 00:18:53.960
<v Speaker 2>For instance, use different vendors for your IDSPS systems, maybe

369
00:18:53.960 --> 00:18:57.000
<v Speaker 2>one at the main internet edge, another vendor's product protecting

370
00:18:57.039 --> 00:19:00.559
<v Speaker 2>the data center zone. Diversity helps catch things one might miss.

371
00:19:01.039 --> 00:19:05.319
<v Speaker 2>Configure firewall rules with really strict pinholes. Only allow the

372
00:19:05.359 --> 00:19:09.240
<v Speaker 2>specific protocols and ports needed for applications to work, drop

373
00:19:09.319 --> 00:19:13.359
<v Speaker 2>and log everything else, especially unauthorized outbound traffic that can

374
00:19:13.359 --> 00:19:14.440
<v Speaker 2>be a sign of compromise.

375
00:19:14.759 --> 00:19:15.880
<v Speaker 1>What about on the switches?

376
00:19:16.200 --> 00:19:20.359
<v Speaker 2>Use access control lists ecls on your distribution layer switches.

377
00:19:21.000 --> 00:19:24.599
<v Speaker 2>Enforce your intended traffic flows. For example, make a rule

378
00:19:24.599 --> 00:19:27.279
<v Speaker 2>that application servers are only allowed to talk to database

379
00:19:27.319 --> 00:19:29.720
<v Speaker 2>servers on the specific ports they need and nowhere else.

380
00:19:29.960 --> 00:19:32.839
<v Speaker 2>On Linux servers, use iptuples or NF tables.

381
00:19:32.440 --> 00:19:35.480
<v Speaker 1>Firewalls, so controlling traffic flow internally.

382
00:19:35.000 --> 00:19:39.119
<v Speaker 2>Is key, hugely important. But there's another piece understanding valid traffic.

383
00:19:39.400 --> 00:19:40.559
<v Speaker 2>You need a baseline.

384
00:19:40.640 --> 00:19:41.759
<v Speaker 1>What does normal look like?

385
00:19:42.039 --> 00:19:44.640
<v Speaker 2>Exactly? You can't spot an attack if you don't know

386
00:19:44.680 --> 00:19:48.039
<v Speaker 2>what normal traffic patterns are for your network. Document the

387
00:19:48.079 --> 00:19:52.440
<v Speaker 2>expected protocols, source the destination IPS port numbers for your applications.

388
00:19:53.000 --> 00:19:56.319
<v Speaker 2>So if suddenly your internal only application server tries to

389
00:19:56.359 --> 00:19:58.839
<v Speaker 2>connect to a random IP address on the Internet.

390
00:19:58.640 --> 00:20:01.039
<v Speaker 1>Using httcs, that's a huge red flag.

391
00:20:00.839 --> 00:20:03.960
<v Speaker 2>Massive red flag. That baseline is critical context.

392
00:20:04.039 --> 00:20:05.599
<v Speaker 1>Okay, how do you get that baseline? How do you

393
00:20:05.640 --> 00:20:06.319
<v Speaker 1>see the traffic?

394
00:20:06.480 --> 00:20:09.920
<v Speaker 2>Tools like wireshark, it's a fantastic free packet sniffer. Use

395
00:20:09.960 --> 00:20:12.559
<v Speaker 2>it to capture traffic at strategic points near the core,

396
00:20:12.640 --> 00:20:14.119
<v Speaker 2>at zone boundaries.

397
00:20:13.720 --> 00:20:15.039
<v Speaker 1>And just look at packets flying by.

398
00:20:15.240 --> 00:20:17.599
<v Speaker 2>You can, but it's more powerful than that. You can

399
00:20:17.640 --> 00:20:20.920
<v Speaker 2>create capture filters to only grab specific traffic, like not

400
00:20:21.160 --> 00:20:23.720
<v Speaker 2>net ten point one point zero two four to see

401
00:20:23.720 --> 00:20:27.640
<v Speaker 2>traffic leaving your local subnet, and then use display filters

402
00:20:27.680 --> 00:20:31.000
<v Speaker 2>to analyze the captured data. For example, that materpreter shell

403
00:20:31.039 --> 00:20:34.599
<v Speaker 2>we mentioned it might use a specific suspicious user agent

404
00:20:34.720 --> 00:20:36.759
<v Speaker 2>string in its web traffic. You can filter for that

405
00:20:37.319 --> 00:20:41.079
<v Speaker 2>or look for custom HTTP headers maybe you've implemented internally

406
00:20:41.119 --> 00:20:44.519
<v Speaker 2>as a sort of secret handshake to validate legitimate internal

407
00:20:44.519 --> 00:20:45.160
<v Speaker 2>web traffic.

408
00:20:45.440 --> 00:20:46.920
<v Speaker 1>Interesting can it find malware?

409
00:20:47.200 --> 00:20:50.039
<v Speaker 2>It can help. You can do raw HGX searches with

410
00:20:50.119 --> 00:20:53.839
<v Speaker 2>in packet data for known malware signatures. It also has

411
00:20:53.960 --> 00:20:57.480
<v Speaker 2>GeoIP mapping, so you can see geographically where traffic is

412
00:20:57.519 --> 00:20:58.799
<v Speaker 2>going to or coming from.

413
00:20:58.960 --> 00:21:01.079
<v Speaker 1>Powerful toolout automated detection.

414
00:21:01.519 --> 00:21:04.359
<v Speaker 2>That's where Snort comes in. It's a leading open source

415
00:21:04.759 --> 00:21:09.640
<v Speaker 2>IDs SIS intrusion detection and prevention system. It analyzes traffic

416
00:21:09.720 --> 00:21:11.920
<v Speaker 2>in real time against a set of rules, looking for

417
00:21:11.960 --> 00:21:15.039
<v Speaker 2>patterns of attack like what kind of patterns, DDAs attempts,

418
00:21:15.279 --> 00:21:20.519
<v Speaker 2>buffer overflows, port scans specific malware communication patterns. Chapman even

419
00:21:20.559 --> 00:21:24.279
<v Speaker 2>details how to build a high performance appliance specifically for Snort,

420
00:21:24.599 --> 00:21:28.079
<v Speaker 2>using fast CPUs, lots of RAM, and high speed Intel

421
00:21:28.160 --> 00:21:31.920
<v Speaker 2>nies because deep packet inspection takes serious horsepower at high speeds.

422
00:21:32.119 --> 00:21:35.039
<v Speaker 2>Where do you deploy Snort Definitely at your Internet edge,

423
00:21:35.160 --> 00:21:38.920
<v Speaker 2>but also crucially between your internal security zones. You can

424
00:21:38.920 --> 00:21:41.720
<v Speaker 2>figure it with your network layout home that external in

425
00:21:41.759 --> 00:21:45.200
<v Speaker 2>its configuration file snort dot CoV it can log alerts

426
00:21:45.240 --> 00:21:47.279
<v Speaker 2>to syslog or even a database.

427
00:21:47.480 --> 00:21:49.720
<v Speaker 1>Okay, is there anything that ties these tools together?

428
00:21:50.079 --> 00:21:54.799
<v Speaker 2>Yes, Security Onion it's a fantastic Linux distribution specifically designed

429
00:21:54.799 --> 00:21:58.480
<v Speaker 2>for security monitoring. It integrates tools like s Nortai and

430
00:21:58.559 --> 00:22:03.079
<v Speaker 2>other IDs called brow zeke log analysis tools, and visualization

431
00:22:03.200 --> 00:22:06.759
<v Speaker 2>front ends like Snorby, so it's like an analytics platform exactly.

432
00:22:06.799 --> 00:22:09.920
<v Speaker 2>It typically build a Security Onion sensor with powerful hardware,

433
00:22:10.359 --> 00:22:13.880
<v Speaker 2>lots of storage for packet capture, strong CPUs, You can

434
00:22:13.880 --> 00:22:17.920
<v Speaker 2>figure management and monitoring interfaces, enable the IDs engines. Bro

435
00:22:18.160 --> 00:22:20.799
<v Speaker 2>is great for extracting files transferred over the network for

436
00:22:20.799 --> 00:22:24.160
<v Speaker 2>a later analysis. Snorbe gives you a nice web interface

437
00:22:24.200 --> 00:22:28.920
<v Speaker 2>to see alerts categorized by severity sensor protocol. You can

438
00:22:28.960 --> 00:22:32.319
<v Speaker 2>set up email alerts for critical events, and another tool

439
00:22:32.400 --> 00:22:35.359
<v Speaker 2>often used with it, Skullgill, lets you monitor events in

440
00:22:35.440 --> 00:22:38.680
<v Speaker 2>real time and even reconstructs sessions, like seeing the commands

441
00:22:38.720 --> 00:22:40.759
<v Speaker 2>and attacker tried during an FTP session.

442
00:22:40.839 --> 00:22:43.440
<v Speaker 1>Wow, that's like looking over their shoulder pretty much.

443
00:22:43.559 --> 00:22:46.880
<v Speaker 2>It's powerful for understanding exactly what happened or is happening.

444
00:22:47.200 --> 00:22:49.920
<v Speaker 2>So yeah, this whole section really shows how sophisticated attacks are,

445
00:22:49.960 --> 00:22:52.079
<v Speaker 2>but also how you can use these powerful tools, many

446
00:22:52.119 --> 00:22:55.559
<v Speaker 2>of them open source to proactively test, detect, and offend.

447
00:22:55.799 --> 00:22:58.839
<v Speaker 1>It's a whole different level of visibility in defense, it

448
00:22:58.920 --> 00:23:02.599
<v Speaker 1>really is. Okay, so we've covered security pretty intensely, but

449
00:23:02.640 --> 00:23:06.960
<v Speaker 1>the book title also mentions performance. How do we tackle that?

450
00:23:07.160 --> 00:23:11.160
<v Speaker 1>How do we ensure that smooth, reliable quality of experience

451
00:23:11.240 --> 00:23:11.799
<v Speaker 1>for users?

452
00:23:11.880 --> 00:23:15.480
<v Speaker 2>Right? Because security is crucial, but if the network is unusable,

453
00:23:15.680 --> 00:23:18.400
<v Speaker 2>that's a problem too. It's not just about raw speed

454
00:23:18.440 --> 00:23:20.880
<v Speaker 2>like bandwidth numbers, It's about how it feels the.

455
00:23:20.960 --> 00:23:23.920
<v Speaker 1>Quality of experience or QoE exactly.

456
00:23:24.279 --> 00:23:29.039
<v Speaker 2>And testing this properly involves avoiding false positives. Vendor spec

457
00:23:29.079 --> 00:23:32.319
<v Speaker 2>sheets like those RFC two five four four numbers they quote.

458
00:23:32.480 --> 00:23:35.200
<v Speaker 2>They might not reflect your real world performance under your

459
00:23:35.240 --> 00:23:37.279
<v Speaker 2>specific traffic conditions, So.

460
00:23:37.279 --> 00:23:38.640
<v Speaker 1>Lab numbers aren't real world.

461
00:23:38.519 --> 00:23:41.680
<v Speaker 2>Numbers, often not. Chapman has a great line test to

462
00:23:41.720 --> 00:23:44.359
<v Speaker 2>the worst case and measure the best result. You need

463
00:23:44.400 --> 00:23:47.680
<v Speaker 2>to generate traffic that actually emulates your network's behavior.

464
00:23:47.759 --> 00:23:49.359
<v Speaker 1>How do you generate that test traffic?

465
00:23:49.480 --> 00:23:51.880
<v Speaker 2>Austinato is a great open source tool for this. It's

466
00:23:51.920 --> 00:23:55.559
<v Speaker 2>a multi stream traffic generator. It lets you build custom

467
00:23:55.599 --> 00:24:00.640
<v Speaker 2>packets layer by layer, MME, IP, TCPUDP, headers. You can

468
00:24:00.640 --> 00:24:03.480
<v Speaker 2>set different frame sizes from tiny sixty four byte ones

469
00:24:03.519 --> 00:24:06.519
<v Speaker 2>up to jumbo frames, control the rate precisely. You can

470
00:24:06.559 --> 00:24:09.319
<v Speaker 2>even strip it with Python for complex scenarios, so.

471
00:24:09.240 --> 00:24:12.319
<v Speaker 1>You can mimic different kinds of application traffic precisely.

472
00:24:12.720 --> 00:24:15.799
<v Speaker 2>And for just measuring raw throughput, jitter and packet loss

473
00:24:15.799 --> 00:24:19.359
<v Speaker 2>between two points, IPERF three is the standard tool. You

474
00:24:19.440 --> 00:24:21.920
<v Speaker 2>run it in server mode on one machine, client mode

475
00:24:21.920 --> 00:24:24.559
<v Speaker 2>on another, and it tells you the actual TCP or

476
00:24:24.680 --> 00:24:27.440
<v Speaker 2>UDP performance between them. Simple but essential.

477
00:24:27.640 --> 00:24:31.319
<v Speaker 1>What about testing over distance like a whan, The experience

478
00:24:31.359 --> 00:24:32.519
<v Speaker 1>there is often very different.

479
00:24:32.680 --> 00:24:35.400
<v Speaker 2>Ah, Yes, you need wine emulation. You can't just test

480
00:24:35.440 --> 00:24:37.400
<v Speaker 2>on your fast local land and assume it'll be the

481
00:24:37.440 --> 00:24:40.440
<v Speaker 2>same for remote users. Tools like WAYNM, which is also

482
00:24:40.480 --> 00:24:44.279
<v Speaker 2>open source, let you artificially introduce latency, jitter, packet loss,

483
00:24:44.319 --> 00:24:46.759
<v Speaker 2>bandwidth constraints to simulate wine conditions.

484
00:24:46.839 --> 00:24:48.599
<v Speaker 1>How do you know what values to simulate?

485
00:24:48.920 --> 00:24:51.799
<v Speaker 2>The book gives some rules of thumb for latency. Figure

486
00:24:51.799 --> 00:24:55.000
<v Speaker 2>about one millisecond for every one hundred kilometers of fiber distance.

487
00:24:55.079 --> 00:24:57.440
<v Speaker 2>Then maybe multiply by one point three to account for

488
00:24:57.480 --> 00:25:02.200
<v Speaker 2>real world paths equipment delays. For Internet VPNs, It suggests

489
00:25:02.279 --> 00:25:05.200
<v Speaker 2>testing with maybe a worst case three percent packet loss

490
00:25:05.240 --> 00:25:06.559
<v Speaker 2>to see how applications cope.

491
00:25:06.599 --> 00:25:10.400
<v Speaker 1>Okay, so you simulate the bad conditions, then what then

492
00:25:10.400 --> 00:25:10.720
<v Speaker 1>you need?

493
00:25:10.880 --> 00:25:15.000
<v Speaker 2>Clear QoE benchmarks for web applications. Define what good means

494
00:25:15.039 --> 00:25:17.240
<v Speaker 2>for you. For example, is a web page loading in

495
00:25:17.319 --> 00:25:20.720
<v Speaker 2>under half a second good? Maybe over sixty seconds is poor.

496
00:25:21.160 --> 00:25:26.000
<v Speaker 2>Define thresholds also track errors, distinguished between direct service errors

497
00:25:26.039 --> 00:25:28.119
<v Speaker 2>like a four oh four where you might tolerate zero,

498
00:25:28.519 --> 00:25:31.119
<v Speaker 2>and subtle errors maybe a graphical glitch where you might

499
00:25:31.119 --> 00:25:32.720
<v Speaker 2>tolerate one per one thousand views.

500
00:25:32.759 --> 00:25:34.640
<v Speaker 1>Having objective measures yes.

501
00:25:34.599 --> 00:25:37.200
<v Speaker 2>So when users complain you have something to compare against.

502
00:25:37.519 --> 00:25:40.400
<v Speaker 2>And when debugging QE issues you need a systematic approach.

503
00:25:40.480 --> 00:25:41.160
<v Speaker 1>Where do you start?

504
00:25:41.359 --> 00:25:43.880
<v Speaker 2>Talk to the user first, what did they expect? What

505
00:25:44.079 --> 00:25:48.240
<v Speaker 2>actually happened? How often is it random, periodic? Is it

506
00:25:48.279 --> 00:25:52.480
<v Speaker 2>an obvious error or just slow? Then check for recent

507
00:25:52.559 --> 00:25:55.759
<v Speaker 2>network changes. Is the problem isolated to them or is

508
00:25:55.799 --> 00:25:59.759
<v Speaker 2>it widespread? If it's isolated, start at their PC, new

509
00:25:59.799 --> 00:26:04.119
<v Speaker 2>software installed, run a malware scan, check their TCP stack

510
00:26:04.160 --> 00:26:07.799
<v Speaker 2>settings using netsch in TCP show global, look at CPU

511
00:26:07.839 --> 00:26:11.640
<v Speaker 2>and RAM usage, check browser plugins or settings. Work outwards

512
00:26:11.640 --> 00:26:12.559
<v Speaker 2>from the user.

513
00:26:12.559 --> 00:26:14.640
<v Speaker 1>Logical troubleshooting process exactly.

514
00:26:15.000 --> 00:26:17.599
<v Speaker 2>So this performance side is about having the right tools

515
00:26:17.640 --> 00:26:20.400
<v Speaker 2>to simulate, measure and benchmark so you can sure the

516
00:26:20.400 --> 00:26:23.799
<v Speaker 2>network isn't just secure but actually delivers that good quality

517
00:26:23.799 --> 00:26:24.519
<v Speaker 2>of experience.

518
00:26:24.720 --> 00:26:26.440
<v Speaker 1>That makes a lot of sense. Now, One of the

519
00:26:26.480 --> 00:26:29.359
<v Speaker 1>really empowering things in Chapman's book is this idea that

520
00:26:29.400 --> 00:26:33.359
<v Speaker 1>you don't always have to buy expensive proprietary boxes. He

521
00:26:33.440 --> 00:26:35.880
<v Speaker 1>makes a strong case for building your own network elements

522
00:26:35.960 --> 00:26:36.759
<v Speaker 1>using open source.

523
00:26:36.960 --> 00:26:39.839
<v Speaker 2>He really does, and there are compelling reasons. Potentially better

524
00:26:39.880 --> 00:26:42.599
<v Speaker 2>costs per megabit, using your budget, more efficiently and honestly

525
00:26:42.640 --> 00:26:45.599
<v Speaker 2>often greater control and even security because you know exactly

526
00:26:45.599 --> 00:26:46.200
<v Speaker 2>what's running.

527
00:26:46.440 --> 00:26:49.759
<v Speaker 1>But can open source software on standard hardware really keep

528
00:26:49.839 --> 00:26:50.759
<v Speaker 1>up these days?

529
00:26:50.880 --> 00:26:55.039
<v Speaker 2>Yes, with modern multi core CPUs, fast RAM, and especially

530
00:26:55.079 --> 00:26:58.200
<v Speaker 2>smart network interface cards and ices like the Intel ones

531
00:26:58.240 --> 00:27:01.279
<v Speaker 2>mentioned by seven to ten, for four by five, five

532
00:27:01.400 --> 00:27:04.680
<v Speaker 2>twenty for ten G plus open source driver technologies like

533
00:27:04.799 --> 00:27:08.759
<v Speaker 2>DPTK or PFRNG, you can achieve line rate packet forwarding

534
00:27:08.799 --> 00:27:12.240
<v Speaker 2>without needing specialized A six at least for many use cases.

535
00:27:12.319 --> 00:27:14.000
<v Speaker 1>Okay, so what kind of elements can you build?

536
00:27:14.000 --> 00:27:17.799
<v Speaker 2>He mentions a router, YEP, A router using something like VOS.

537
00:27:18.119 --> 00:27:21.039
<v Speaker 2>It's Linux based, comes as an installable image or a

538
00:27:21.119 --> 00:27:24.880
<v Speaker 2>virtual machine. It supports enterprise routing protocols like OSPF and

539
00:27:24.960 --> 00:27:29.119
<v Speaker 2>BGP and has basic firewall capabilities. Too great for edge

540
00:27:29.200 --> 00:27:32.599
<v Speaker 2>routing or internal segmentation. What about a switch, openb switch

541
00:27:32.759 --> 00:27:35.839
<v Speaker 2>or OVS. It's a powerful open source virtual switch. You

542
00:27:35.880 --> 00:27:39.680
<v Speaker 2>can create bridges, add physical or virtual ports, do vland tagging.

543
00:27:40.079 --> 00:27:42.599
<v Speaker 2>It's heavily used in data centers, cloud environments for those

544
00:27:42.680 --> 00:27:45.119
<v Speaker 2>NF chains we talked about, or as part of software

545
00:27:45.160 --> 00:27:46.880
<v Speaker 2>defined networking with open flow.

546
00:27:46.880 --> 00:27:49.400
<v Speaker 1>Okay load balancer. Those are usually expensive.

547
00:27:49.480 --> 00:27:53.160
<v Speaker 2>You can build one. Zen looad Balancer ZLB is mentioned

548
00:27:53.200 --> 00:27:55.799
<v Speaker 2>as an open source option. It gives you a virtual IP,

549
00:27:55.960 --> 00:27:58.119
<v Speaker 2>a VIP that sits in front of a pool of

550
00:27:58.160 --> 00:28:00.839
<v Speaker 2>back end servers. It can distribute to traffic using different

551
00:28:00.839 --> 00:28:04.279
<v Speaker 2>methods like round robin or based on server load. Absolutely

552
00:28:04.400 --> 00:28:06.759
<v Speaker 2>critical for high availability and maintenance.

553
00:28:07.000 --> 00:28:10.640
<v Speaker 1>DHCP server seems basic but necessary, easy to do with

554
00:28:10.680 --> 00:28:11.240
<v Speaker 1>open source.

555
00:28:11.599 --> 00:28:15.359
<v Speaker 2>The book suggests the standard ic DHCP server on a

556
00:28:15.359 --> 00:28:19.440
<v Speaker 2>Buntu Linux simple configuration file to define your IP address scopes,

557
00:28:19.480 --> 00:28:22.680
<v Speaker 2>default router, DNS servers, then lock it down with basic

558
00:28:22.720 --> 00:28:26.279
<v Speaker 2>firewall rules allowing UDP ports to sixty seven and sixty eight.

559
00:28:26.200 --> 00:28:28.000
<v Speaker 1>And finally a web server stack.

560
00:28:28.720 --> 00:28:31.680
<v Speaker 2>Yeah, for a standard web server setup, something like turnkey

561
00:28:31.799 --> 00:28:35.680
<v Speaker 2>lampy is great. It's a pre integrated virtual appliance with Linux, Apache,

562
00:28:35.759 --> 00:28:38.839
<v Speaker 2>Myseql and PHP already set up. It includes webmen for

563
00:28:38.960 --> 00:28:42.799
<v Speaker 2>easy web based administration, making configuration even setting up SSL

564
00:28:42.880 --> 00:28:43.519
<v Speaker 2>much simpler.

565
00:28:43.640 --> 00:28:46.279
<v Speaker 1>So really, a whole range of core network functions can

566
00:28:46.319 --> 00:28:48.200
<v Speaker 1>be built cost effectively with open source.

567
00:28:48.240 --> 00:28:50.519
<v Speaker 2>Absolutely it opens up a lot of possibilities, giving you

568
00:28:50.559 --> 00:28:53.279
<v Speaker 2>powerful secure solutions, often without the vendor lock in or

569
00:28:53.359 --> 00:28:54.200
<v Speaker 2>high price tags.

570
00:28:54.480 --> 00:28:57.079
<v Speaker 1>Okay, one final area. Let's say you're not building it yourself,

571
00:28:57.079 --> 00:29:00.240
<v Speaker 1>you're evaluating a commercial product your service. How how do

572
00:29:00.279 --> 00:29:03.279
<v Speaker 1>you make sure the vendor is actually delivering on security,

573
00:29:03.480 --> 00:29:04.960
<v Speaker 1>not just giving you marketing fluff.

574
00:29:05.200 --> 00:29:09.079
<v Speaker 2>Excellent question. You need to ask tough specific questions in

575
00:29:09.119 --> 00:29:14.599
<v Speaker 2>your kindness request for proposal RFP or evaluation process like

576
00:29:14.640 --> 00:29:19.519
<v Speaker 2>what well, first protocol stack verification? Don't just accept their claims.

577
00:29:19.799 --> 00:29:22.839
<v Speaker 2>Demand a list of every single protocol stack their device

578
00:29:22.960 --> 00:29:26.839
<v Speaker 2>uses internally, and crucially, ask for a fuzzing test.

579
00:29:26.599 --> 00:29:28.519
<v Speaker 1>Report for each one. Fuzzing What's that?

580
00:29:28.880 --> 00:29:32.160
<v Speaker 2>Fuzzing is an automated testing technique where you throw invalid,

581
00:29:32.240 --> 00:29:35.200
<v Speaker 2>unexpected or random data at an input, in this case

582
00:29:35.440 --> 00:29:38.599
<v Speaker 2>the protocol stat to see if it crashes or behaves unexpectedly.

583
00:29:39.119 --> 00:29:42.400
<v Speaker 2>It's great for finding vulnerabilities like buffer overflows that attackers

584
00:29:42.440 --> 00:29:45.039
<v Speaker 2>love to exploit. If they haven't fuzzed their stacks, that's

585
00:29:45.079 --> 00:29:45.599
<v Speaker 2>a red flag.

586
00:29:45.680 --> 00:29:46.319
<v Speaker 1>Okay, good one.

587
00:29:46.359 --> 00:29:50.359
<v Speaker 2>What else malware mitigation ask about their anti malware capabilities

588
00:29:50.440 --> 00:29:53.880
<v Speaker 2>if it's relevant to the product get reports. Ask how

589
00:29:53.880 --> 00:29:57.359
<v Speaker 2>often their signature databases are updated, and importantly, ask about

590
00:29:57.400 --> 00:30:00.559
<v Speaker 2>both poll schedules, how often the device checks for updates

591
00:30:00.880 --> 00:30:04.319
<v Speaker 2>and push schedules how quickly they push out emergency updates

592
00:30:04.319 --> 00:30:05.359
<v Speaker 2>for zero day threats.

593
00:30:05.599 --> 00:30:08.720
<v Speaker 1>Understanding the update cadence makes sense.

594
00:30:08.759 --> 00:30:12.200
<v Speaker 2>And maybe the most critical one. Mixed class attacks and

595
00:30:12.279 --> 00:30:15.920
<v Speaker 2>services testing this is key. Don't just ask how it

596
00:30:15.920 --> 00:30:19.559
<v Speaker 2>performs normally or how it blocks attacks in isolation. Ask

597
00:30:19.680 --> 00:30:23.200
<v Speaker 2>them to provide test data showing valid application traffic performance

598
00:30:23.240 --> 00:30:26.519
<v Speaker 2>with no attacks running, and then the same valid traffic

599
00:30:26.559 --> 00:30:29.799
<v Speaker 2>performance while the device is simultaneously under attack or undergoing

600
00:30:29.799 --> 00:30:31.079
<v Speaker 2>a security audit stand.

601
00:30:31.000 --> 00:30:33.519
<v Speaker 1>Ah, so how does it perform under pressure exactly?

602
00:30:33.680 --> 00:30:36.119
<v Speaker 2>You want to know were all the attacks actually blocked

603
00:30:36.160 --> 00:30:39.640
<v Speaker 2>and crucially, how much did your legitimate traffic performance degrade

604
00:30:39.640 --> 00:30:42.720
<v Speaker 2>while the device was busy fighting off the attack. Ideally,

605
00:30:42.759 --> 00:30:46.319
<v Speaker 2>the answer should be all attacks blocked, zero degradation to

606
00:30:46.400 --> 00:30:47.000
<v Speaker 2>valid traffic.

607
00:30:47.079 --> 00:30:48.920
<v Speaker 1>That seems like a high bar it is.

608
00:30:48.880 --> 00:30:51.039
<v Speaker 2>But that's what you should be aiming for and asking

609
00:30:51.160 --> 00:30:55.000
<v Speaker 2>vendors to demonstrate. These aren't just casual questions. They're critical

610
00:30:55.039 --> 00:30:57.680
<v Speaker 2>inquiries you need to make to ensure any new gear

611
00:30:57.799 --> 00:31:01.559
<v Speaker 2>or code actually meets your securities standards and doesn't become

612
00:31:01.640 --> 00:31:02.839
<v Speaker 2>your next vulnerability.

613
00:31:03.200 --> 00:31:07.559
<v Speaker 1>That's really practical advice for evaluating vendors. Well, just like that,

614
00:31:08.000 --> 00:31:11.200
<v Speaker 1>we've covered a huge amount of ground. We've journeyed through

615
00:31:11.200 --> 00:31:15.400
<v Speaker 1>this really intricate landscape of network performance and security. We

616
00:31:15.480 --> 00:31:18.359
<v Speaker 1>went from understanding those subtle impacts of just a slow

617
00:31:18.440 --> 00:31:21.759
<v Speaker 1>web page load all the way to the pre sophisticated

618
00:31:21.759 --> 00:31:25.640
<v Speaker 1>tactics of penetration testers. We've dug into the vital importance

619
00:31:25.680 --> 00:31:29.519
<v Speaker 1>of audits, learned about hardening infrastructure and clients, and even

620
00:31:29.559 --> 00:31:32.559
<v Speaker 1>saw the power of open source tools for building and testing.

621
00:31:32.680 --> 00:31:34.319
<v Speaker 2>It really touches on the whole life cycle.

622
00:31:34.440 --> 00:31:37.920
<v Speaker 1>It does, and hopefully for you listening, you now have

623
00:31:38.000 --> 00:31:41.839
<v Speaker 1>a deeper understanding of those unknown unknowns we started with,

624
00:31:42.240 --> 00:31:45.920
<v Speaker 1>and maybe a more practical toolkit to identify, analyze, and

625
00:31:46.000 --> 00:31:48.000
<v Speaker 1>mitigate threats on your own networks.

626
00:31:48.160 --> 00:31:52.759
<v Speaker 2>These aren't just abstract ideas, they're actionable insights exactly.

627
00:31:53.160 --> 00:31:55.119
<v Speaker 1>This is stuff you can use to build a genuinely

628
00:31:55.200 --> 00:31:59.480
<v Speaker 1>resilient network. So, as you reflect on this deep dis

629
00:31:59.599 --> 00:32:03.640
<v Speaker 1>here's a final thought to leave you with, What unrecognized device,

630
00:32:03.920 --> 00:32:07.440
<v Speaker 1>what forgotten policy? What unaudited private server lurking in your

631
00:32:07.519 --> 00:32:10.559
<v Speaker 1>environment might just be the beachhead for the next attack.

632
00:32:10.640 --> 00:32:12.519
<v Speaker 2>Yeah, where's your hidden vulnerability?

633
00:32:12.759 --> 00:32:15.839
<v Speaker 1>And maybe more importantly, how will you use some of

634
00:32:15.880 --> 00:32:18.640
<v Speaker 1>the knowledge from today to find it before an attacker

635
00:32:18.680 --> 00:32:21.720
<v Speaker 1>does start that audit? Maybe re evaluate where your trust

636
00:32:21.720 --> 00:32:25.200
<v Speaker 1>boundaries really are, and just keep exploring. Because its continuous

637
00:32:25.200 --> 00:32:28.799
<v Speaker 1>battle for network security, it's one where knowledge truly is power.