WEBVTT

1
00:00:00.160 --> 00:00:02.640
<v Speaker 1>Welcome to the deep dive, where we unpack a stack

2
00:00:02.680 --> 00:00:06.000
<v Speaker 1>of information to deliver the most important nuggets of knowledge,

3
00:00:06.320 --> 00:00:09.679
<v Speaker 1>making you well informed fast. Today we're diving into a

4
00:00:09.679 --> 00:00:12.960
<v Speaker 1>topic that's quickly become well pretty much make or break

5
00:00:13.000 --> 00:00:16.760
<v Speaker 1>for businesses everywhere. Cybersecurity architecture. I mean, we all see

6
00:00:16.800 --> 00:00:23.399
<v Speaker 1>the headlines vulnerable software users getting scammed, accidental misconfigurations. The

7
00:00:23.440 --> 00:00:27.600
<v Speaker 1>potential for disaster is just massive. So how do organizations

8
00:00:27.600 --> 00:00:31.079
<v Speaker 1>actually go about building defiles that are resilient.

9
00:00:31.519 --> 00:00:33.719
<v Speaker 2>Well, what's really fascinating here, I think is that every

10
00:00:33.719 --> 00:00:36.520
<v Speaker 2>single organization, whether they consciously plan for it or not,

11
00:00:36.799 --> 00:00:40.320
<v Speaker 2>will have a cybersecurity architecture. It just exists. So our

12
00:00:40.320 --> 00:00:43.320
<v Speaker 2>mission in this deep dive is to unpack the practical steps.

13
00:00:43.320 --> 00:00:45.679
<v Speaker 2>You know, how do you define, document, validate, and actually

14
00:00:45.880 --> 00:00:48.359
<v Speaker 2>deliver a security vision that works in the real world.

15
00:00:48.679 --> 00:00:50.759
<v Speaker 2>And we'll be drawing from a really insightful guide on

16
00:00:50.799 --> 00:00:54.439
<v Speaker 2>cybersecurity architecture to help shed some light on this pretty

17
00:00:54.439 --> 00:00:55.359
<v Speaker 2>complex field for you.

18
00:00:55.640 --> 00:00:58.520
<v Speaker 1>Okay, so let's maybe start with an analogy. The source

19
00:00:58.600 --> 00:01:02.039
<v Speaker 1>uses a good one. Think about an architect in the

20
00:01:02.039 --> 00:01:06.400
<v Speaker 1>physical world, like would you feel comfortable writing an elevator

21
00:01:06.480 --> 00:01:09.000
<v Speaker 1>up to the fiftieth floor of some skyscraper if the

22
00:01:09.000 --> 00:01:12.239
<v Speaker 1>builders just decided to, I don't know, build it and see.

23
00:01:12.040 --> 00:01:16.159
<v Speaker 2>If it works exactly No way, Right, A physical architect

24
00:01:16.480 --> 00:01:19.879
<v Speaker 2>ensures not just safety, but also what the source calls

25
00:01:20.000 --> 00:01:24.439
<v Speaker 2>fitness of purpose. Imagine building a skyscraper but forgetting the elevators.

26
00:01:24.840 --> 00:01:27.920
<v Speaker 2>That's a massive oversight. Occupants would be outrage and think

27
00:01:27.920 --> 00:01:30.640
<v Speaker 2>of the expense to fix it later. Yeah, if we

28
00:01:30.680 --> 00:01:33.640
<v Speaker 2>connect this to the bigger picture, you know, in enterprise computing,

29
00:01:33.959 --> 00:01:37.359
<v Speaker 2>the role of an architect is really directly analogous. You've

30
00:01:37.359 --> 00:01:42.480
<v Speaker 2>got system architects, network architects, software architects, cloud architects, loads more.

31
00:01:42.640 --> 00:01:45.400
<v Speaker 2>They're all keepers of a vision for their specific area.

32
00:01:45.560 --> 00:01:47.799
<v Speaker 1>Right, And the source material really drives home that point.

33
00:01:47.840 --> 00:01:51.840
<v Speaker 1>Even if an organization completely ignores sound design principles, yeah,

34
00:01:51.879 --> 00:01:54.760
<v Speaker 1>they'll still have a cybersecurity architecture. It's just, like you said,

35
00:01:54.760 --> 00:01:57.599
<v Speaker 1>an unplanned ad hoc one that sort of evolves organically.

36
00:01:58.000 --> 00:02:01.519
<v Speaker 1>So what does this actually mean for someone who wants

37
00:02:02.000 --> 00:02:05.159
<v Speaker 1>a planned, efficient approach? What are the risks of just

38
00:02:05.280 --> 00:02:06.040
<v Speaker 1>letting it happen?

39
00:02:06.439 --> 00:02:10.800
<v Speaker 2>Well, that organic approach, the unplanned one, it almost always

40
00:02:10.919 --> 00:02:15.599
<v Speaker 2>leads to redundant security controls, you know, spending money on

41
00:02:15.599 --> 00:02:19.479
<v Speaker 2>the same thing twice, plus wasted resources and these glaring

42
00:02:19.520 --> 00:02:24.240
<v Speaker 2>gaps that frankly often only get discovered during a breach out. Yeah,

43
00:02:24.280 --> 00:02:26.800
<v Speaker 2>so the real purpose of planning the architecture isn't just

44
00:02:26.800 --> 00:02:30.759
<v Speaker 2>making it look neat. It's about proactively avoiding those really

45
00:02:30.919 --> 00:02:34.120
<v Speaker 2>costly reactive fixes later on. It's about having a strategy.

46
00:02:34.280 --> 00:02:36.919
<v Speaker 1>Okay, So having that strategy is the main goal just

47
00:02:36.919 --> 00:02:39.840
<v Speaker 1>about stopping the bad guys, keeping attackers out or is

48
00:02:39.840 --> 00:02:41.000
<v Speaker 1>there a bigger picture here?

49
00:02:41.199 --> 00:02:44.479
<v Speaker 2>It's definitely broader than just stopping attacks. The core purpose

50
00:02:44.560 --> 00:02:48.199
<v Speaker 2>really is to create a coherent arrangement of security controls. Yes,

51
00:02:48.479 --> 00:02:51.599
<v Speaker 2>but controls it specifically support the information systems.

52
00:02:51.240 --> 00:02:53.280
<v Speaker 1>The one is doing the actual business work.

53
00:02:53.240 --> 00:02:57.039
<v Speaker 2>Exactly, the systems delivering capabilities to the business. It's about

54
00:02:57.039 --> 00:03:00.000
<v Speaker 2>making sure the security approach is well planned, that resources

55
00:03:00.080 --> 00:03:04.479
<v Speaker 2>are used optimally efficiently, and crucially, that the organizational goals

56
00:03:04.479 --> 00:03:07.560
<v Speaker 2>are actually being met. Security is only really useful if

57
00:03:07.560 --> 00:03:09.840
<v Speaker 2>it's attached to the organization's mission, right.

58
00:03:10.159 --> 00:03:14.000
<v Speaker 1>Like increasing market share or enabling a remote workforce, things

59
00:03:14.039 --> 00:03:14.360
<v Speaker 1>like that.

60
00:03:14.479 --> 00:03:18.520
<v Speaker 2>Precisely security needs to enable those things, not hinder them.

61
00:03:18.800 --> 00:03:21.599
<v Speaker 1>Okay, So to protect that mission. We often hear about

62
00:03:21.680 --> 00:03:28.800
<v Speaker 1>the CIA triad confidentiality, integrity, availability, Could you just quickly

63
00:03:28.879 --> 00:03:29.759
<v Speaker 1>refresh us on those.

64
00:03:29.840 --> 00:03:34.000
<v Speaker 2>Absolutely, they're the bedrock. Confidentiality basically making sure information is

65
00:03:34.039 --> 00:03:37.599
<v Speaker 2>only disclosed to authorize people, simple enough. Integrity meaning the

66
00:03:37.639 --> 00:03:40.960
<v Speaker 2>information is reliable, trustworthy and can only be changed by

67
00:03:41.000 --> 00:03:46.159
<v Speaker 2>authorized folks, no unauthorized fiddling. And availability meaning the services,

68
00:03:46.199 --> 00:03:49.439
<v Speaker 2>the systems, they're actually there and working when you need them,

69
00:03:49.560 --> 00:03:51.599
<v Speaker 2>even if there's a disaster or an attack ongoing.

70
00:03:51.680 --> 00:03:54.719
<v Speaker 1>Right, the fundamentals, but the source. It goes beyond just CIA,

71
00:03:54.759 --> 00:03:57.319
<v Speaker 1>doesn't it. It adds some other dimensions that maybe aren't

72
00:03:57.319 --> 00:03:59.319
<v Speaker 1>as commonly discussed it does.

73
00:03:59.800 --> 00:04:02.319
<v Speaker 2>This is where it gets really interesting. I think it

74
00:04:02.400 --> 00:04:05.520
<v Speaker 2>adds effectiveness, resiliency, and depth.

75
00:04:05.960 --> 00:04:06.400
<v Speaker 1>Okay.

76
00:04:06.680 --> 00:04:11.800
<v Speaker 2>Effectiveness is pretty straightforward. Does the control actually reduce risk?

77
00:04:12.520 --> 00:04:16.639
<v Speaker 2>Does it work? Resiliency is fascinating. It's not just about

78
00:04:16.639 --> 00:04:20.560
<v Speaker 2>the network staying up, but the security mechanisms themselves being resilient.

79
00:04:20.759 --> 00:04:23.240
<v Speaker 2>Think of a bane vault. You wouldn't want it to

80
00:04:23.399 --> 00:04:26.560
<v Speaker 2>just unlock if someone pulls the fire alarm nearby. The

81
00:04:26.600 --> 00:04:28.680
<v Speaker 2>security itself needs to withstand disruption.

82
00:04:29.000 --> 00:04:30.759
<v Speaker 1>Uh, okay, that makes sense.

83
00:04:30.800 --> 00:04:34.439
<v Speaker 2>And depth Depth means applying security across all the layers,

84
00:04:34.600 --> 00:04:37.319
<v Speaker 2>you know, the whole network stack, from the physical hardware,

85
00:04:37.639 --> 00:04:39.720
<v Speaker 2>the cables and service or the way up, all the

86
00:04:39.720 --> 00:04:43.079
<v Speaker 2>way up to the application code itself. Security at every level,

87
00:04:43.199 --> 00:04:44.000
<v Speaker 2>not just at the perimeter.

88
00:04:44.160 --> 00:04:47.560
<v Speaker 1>It definitely sounds like a more structured, planned approach. So

89
00:04:47.639 --> 00:04:50.959
<v Speaker 1>how does the guide suggest an architect actually starts this journey?

90
00:04:50.959 --> 00:04:51.560
<v Speaker 1>Where do you begin?

91
00:04:52.199 --> 00:04:55.160
<v Speaker 2>Well, it all starts with establishing context. You absolutely have

92
00:04:55.240 --> 00:04:58.800
<v Speaker 2>to understand the organization's sort of universal laws, universal laws,

93
00:04:59.199 --> 00:05:02.160
<v Speaker 2>what things like, it's core goals, was it trying to achieve,

94
00:05:02.480 --> 00:05:05.040
<v Speaker 2>it's culture, how does it operate? It's risk tolerance, how

95
00:05:05.079 --> 00:05:07.920
<v Speaker 2>much risk is acceptable? Of course, all the compliance requirements.

96
00:05:07.959 --> 00:05:13.199
<v Speaker 2>It's subject to regulation standards. The text emphasizes using this

97
00:05:13.279 --> 00:05:17.680
<v Speaker 2>technique called the seven whys Seven Why get a trace backatolicy?

98
00:05:18.040 --> 00:05:21.439
<v Speaker 2>Like say we're requiring background screening for new hires. Why

99
00:05:21.800 --> 00:05:26.000
<v Speaker 2>to ensure staff are trustworthy? Why to protect sensitive data? Why?

100
00:05:26.519 --> 00:05:29.079
<v Speaker 2>Because that's critical to the business goal of whatever it is.

101
00:05:29.120 --> 00:05:31.720
<v Speaker 2>You keep asking why until you hit that fundamental goal.

102
00:05:32.120 --> 00:05:35.560
<v Speaker 2>Because what works in one company culturally or financially might

103
00:05:35.600 --> 00:05:39.959
<v Speaker 2>be a quote total non starter in another. That context

104
00:05:40.240 --> 00:05:41.360
<v Speaker 2>is everything that makes a.

105
00:05:41.360 --> 00:05:43.240
<v Speaker 1>Lot of sense. And once you have that context, how

106
00:05:43.279 --> 00:05:45.600
<v Speaker 1>do you measure if the architecture you're designing is actually

107
00:05:45.600 --> 00:05:46.120
<v Speaker 1>any good?

108
00:05:46.399 --> 00:05:48.680
<v Speaker 2>The source mentioned some key dimensions it does.

109
00:05:48.839 --> 00:05:51.279
<v Speaker 1>And they seem obvious at first, but the guide adds

110
00:05:51.279 --> 00:05:53.920
<v Speaker 1>a crucial layer. It's not just about technical effectiveness. So

111
00:05:53.959 --> 00:05:58.279
<v Speaker 1>the dimensions are effectiveness, does it reduce risk? Maturity? Is

112
00:05:58.319 --> 00:06:01.560
<v Speaker 1>the process reliable and repeatable, you know like CMMI for

113
00:06:01.639 --> 00:06:03.639
<v Speaker 1>process improvement efficiency?

114
00:06:03.920 --> 00:06:07.560
<v Speaker 2>Is it cost effective? Are we getting value? And importantly,

115
00:06:08.519 --> 00:06:12.240
<v Speaker 2>alignment does it actually fit the organization's skills and culture?

116
00:06:12.439 --> 00:06:14.879
<v Speaker 1>Ah? Okay, so alignment is key.

117
00:06:14.800 --> 00:06:17.040
<v Speaker 2>Hugely key. The source points out. You could have a

118
00:06:17.079 --> 00:06:21.399
<v Speaker 2>security measure that requires say, super specialized digital forensic skills,

119
00:06:21.959 --> 00:06:24.560
<v Speaker 2>but if your organization always outsources that kind of work,

120
00:06:25.279 --> 00:06:28.079
<v Speaker 2>then that control isn't really aligned. Even if it's technically

121
00:06:28.079 --> 00:06:30.759
<v Speaker 2>effective on paper, it won't work well in practice for

122
00:06:30.800 --> 00:06:31.160
<v Speaker 2>your team.

123
00:06:31.240 --> 00:06:36.279
<v Speaker 1>Gotcha, So context established dimensions understirred. Then you build the blueprint,

124
00:06:36.360 --> 00:06:39.079
<v Speaker 1>the actual plan. What's the main goal there? Just writing

125
00:06:39.120 --> 00:06:39.639
<v Speaker 1>it all down?

126
00:06:39.759 --> 00:06:42.199
<v Speaker 2>Well? Yes, but the goal of the documentation is critical.

127
00:06:42.199 --> 00:06:44.800
<v Speaker 2>It's to minimize what the source calls shelfware.

128
00:06:45.000 --> 00:06:48.199
<v Speaker 1>Shelfware like documents that just sit on a shelf exactly.

129
00:06:48.439 --> 00:06:52.040
<v Speaker 2>Digital or physical documents that get created may be approved,

130
00:06:52.240 --> 00:06:55.480
<v Speaker 2>and then nobody looks at them again. They gather dust.

131
00:06:55.720 --> 00:06:58.519
<v Speaker 2>The documentation must be practical, it must be used, and

132
00:06:58.560 --> 00:07:01.519
<v Speaker 2>it must be useful to be a living thing. This

133
00:07:01.560 --> 00:07:03.759
<v Speaker 2>allows others to pick up where you left off, sure,

134
00:07:03.959 --> 00:07:07.480
<v Speaker 2>but it's also absolutely vital for getting buy in from executives,

135
00:07:07.480 --> 00:07:09.680
<v Speaker 2>from the tech teams, from the operations folks who have

136
00:07:09.759 --> 00:07:10.800
<v Speaker 2>to live with it day to day.

137
00:07:10.959 --> 00:07:13.920
<v Speaker 1>Right, buy in seems crucial, and to build that useful

138
00:07:14.000 --> 00:07:16.319
<v Speaker 1>d print, the source says you need to understand three

139
00:07:16.360 --> 00:07:21.399
<v Speaker 1>key things, assets, threats, and risks. What counts as an asset?

140
00:07:21.600 --> 00:07:23.000
<v Speaker 1>Is it just servers and laptops?

141
00:07:23.199 --> 00:07:26.360
<v Speaker 2>No, much Broader assets aren't just the technical kit. They

142
00:07:26.360 --> 00:07:30.439
<v Speaker 2>can be data, customer lists, intellectual property. They can be personnel,

143
00:07:30.519 --> 00:07:34.759
<v Speaker 2>key staff, information itself, or even just money. Basically anything

144
00:07:34.759 --> 00:07:38.199
<v Speaker 2>of value that the organization needs to protect. Understanding those assets,

145
00:07:38.279 --> 00:07:40.399
<v Speaker 2>then figuring out the threats, what bad things could happen

146
00:07:40.439 --> 00:07:43.399
<v Speaker 2>to them, and the resulting risk that forms the core

147
00:07:43.439 --> 00:07:44.240
<v Speaker 2>of your blueprint.

148
00:07:44.399 --> 00:07:48.600
<v Speaker 1>Okay, this sounds methodical, which is good, but the real world,

149
00:07:48.680 --> 00:07:51.800
<v Speaker 1>especially in tech, moves incredibly fast. Doesn't it.

150
00:07:51.839 --> 00:07:55.639
<v Speaker 2>The source really hammers this point about software release cycles

151
00:07:55.680 --> 00:07:59.639
<v Speaker 2>accelerating to this breakneck pace. I mean the stats are

152
00:07:59.680 --> 00:08:04.199
<v Speaker 2>why Amazon deploying new code every second, Google doing over

153
00:08:04.319 --> 00:08:07.800
<v Speaker 2>four million builds a day. How does traditional security planning

154
00:08:07.879 --> 00:08:08.319
<v Speaker 2>keep up?

155
00:08:08.680 --> 00:08:11.759
<v Speaker 1>It often doesn't, which is the problem. That's precisely where

156
00:08:11.800 --> 00:08:15.439
<v Speaker 1>something called system security engineering comes in. There are established

157
00:08:15.439 --> 00:08:18.079
<v Speaker 1>approaches like the one in nisted SP eight hundred and

158
00:08:18.079 --> 00:08:22.160
<v Speaker 1>one sixty one, which is a well respected guide for this, okay,

159
00:08:22.199 --> 00:08:25.959
<v Speaker 1>and the core idea is tailoring your processes so security

160
00:08:26.000 --> 00:08:28.920
<v Speaker 1>gets baked in from the absolute start of development, not

161
00:08:29.079 --> 00:08:31.079
<v Speaker 1>just bolted on the end when it's often too late

162
00:08:31.160 --> 00:08:32.240
<v Speaker 1>or too expensive to fix things.

163
00:08:32.279 --> 00:08:34.039
<v Speaker 2>Probably baked in, not bolted on. I like that.

164
00:08:34.200 --> 00:08:37.159
<v Speaker 1>Yeah. The guide highlights how security needs to be woven

165
00:08:37.200 --> 00:08:40.039
<v Speaker 1>through the entire software development life cycle the SDLC, right

166
00:08:40.080 --> 00:08:42.679
<v Speaker 1>from requirements gathering through the design phase, maybe using threat

167
00:08:42.679 --> 00:08:44.879
<v Speaker 1>modeling tools there to proactively look.

168
00:08:44.679 --> 00:08:48.879
<v Speaker 2>For issues, all the way through testing, verification, and that

169
00:08:48.919 --> 00:08:52.200
<v Speaker 2>continuous quality assurance, often using automated testing.

170
00:08:52.720 --> 00:08:55.519
<v Speaker 1>So security becomes part of the development rhythm, not a

171
00:08:55.559 --> 00:08:56.519
<v Speaker 1>separate hurdle.

172
00:08:56.840 --> 00:08:59.200
<v Speaker 2>That's the goal. Now, what does this look like when

173
00:08:59.200 --> 00:09:02.399
<v Speaker 2>you actually implement and specific things. That's where you create

174
00:09:02.480 --> 00:09:07.519
<v Speaker 2>what the Source calls technical implementation strategies. It's about translating

175
00:09:07.720 --> 00:09:12.240
<v Speaker 2>those high level goals like protect customer data into specific.

176
00:09:11.799 --> 00:09:15.279
<v Speaker 1>Mechanisms, like choosing a specific encryption product.

177
00:09:15.120 --> 00:09:19.639
<v Speaker 2>Exactly, or deciding strategically where to place your VPN concentrators

178
00:09:19.840 --> 00:09:23.519
<v Speaker 2>on the network for remote access. It's making concrete choices,

179
00:09:23.879 --> 00:09:26.480
<v Speaker 2>and it's iterative. You make a choice, you see how

180
00:09:26.519 --> 00:09:29.840
<v Speaker 2>it works, you adjust. The Source uses a great analogy

181
00:09:30.080 --> 00:09:33.320
<v Speaker 2>correcting a one gree error in spaceflight. It's way cheaper

182
00:09:33.360 --> 00:09:35.279
<v Speaker 2>and easier to do it early in the journey than

183
00:09:35.360 --> 00:09:36.840
<v Speaker 2>later on when you're way off course.

184
00:09:37.120 --> 00:09:40.200
<v Speaker 1>Makes sense. So you've made these choices, these technical strategies,

185
00:09:40.279 --> 00:09:42.039
<v Speaker 1>how do you check if they're actually going to hold

186
00:09:42.120 --> 00:09:44.440
<v Speaker 1>up against real attackers? How do you validate them?

187
00:09:44.600 --> 00:09:46.799
<v Speaker 2>This is where some really useful tools come into play.

188
00:09:47.240 --> 00:09:50.519
<v Speaker 2>The source specifically suggests using things like the mi era

189
00:09:50.639 --> 00:09:51.559
<v Speaker 2>AT and TK.

190
00:09:51.519 --> 00:09:55.480
<v Speaker 1>Matrix, AH, yes, ATT and CK. That's pretty well known now.

191
00:09:55.519 --> 00:09:58.879
<v Speaker 2>It is, and for good reason. It's essentially this huge

192
00:09:59.159 --> 00:10:04.000
<v Speaker 2>globally accessed sable knowledge basic catalog really of adversarial tactics

193
00:10:04.000 --> 00:10:07.720
<v Speaker 2>and techniques, all based on real world observations of attackers.

194
00:10:08.279 --> 00:10:11.480
<v Speaker 2>So it helps architects think through how an attacker might

195
00:10:11.519 --> 00:10:15.240
<v Speaker 2>try to achieve their objectives against the specific solutions you've chosen.

196
00:10:15.600 --> 00:10:18.799
<v Speaker 2>It gives you this really high resolution view for evaluating

197
00:10:18.840 --> 00:10:20.600
<v Speaker 2>threats before an attack happens, so.

198
00:10:20.519 --> 00:10:22.639
<v Speaker 1>You can sort of red team your own design using

199
00:10:22.759 --> 00:10:24.600
<v Speaker 1>known attacker methods in a way.

200
00:10:24.759 --> 00:10:27.480
<v Speaker 2>Yes, it provides a structured way to think like an

201
00:10:27.480 --> 00:10:30.159
<v Speaker 2>attacker and find potential weaknesses in your plan.

202
00:10:30.360 --> 00:10:35.200
<v Speaker 1>Okay, great, so planning, implementing, validating. Now how do you

203
00:10:35.279 --> 00:10:38.159
<v Speaker 1>know over time if it's all actually working, if it's

204
00:10:38.159 --> 00:10:39.519
<v Speaker 1>staying effective.

205
00:10:39.240 --> 00:10:42.039
<v Speaker 2>Right, because the job's never really done. That's where telemetry

206
00:10:42.080 --> 00:10:44.159
<v Speaker 2>and strategic metrics become absolutely key.

207
00:10:44.240 --> 00:10:46.840
<v Speaker 1>Telemetry meaning collecting data from the system.

208
00:10:46.960 --> 00:10:50.159
<v Speaker 2>Yeah, collecting operational data. But it's not just about raw numbers.

209
00:10:50.200 --> 00:10:53.000
<v Speaker 2>The source makes a good point just counting, say, the

210
00:10:53.039 --> 00:10:56.000
<v Speaker 2>total number of vulnerabilities, isn't that helpful on its own?

211
00:10:56.080 --> 00:10:57.679
<v Speaker 1>Why not? It seems like a useful.

212
00:10:57.440 --> 00:11:01.080
<v Speaker 2>Number Because your environment changes, Right, you might add hundreds

213
00:11:01.080 --> 00:11:04.320
<v Speaker 2>of new devices, Your total vulnerability count might go up.

214
00:11:04.519 --> 00:11:07.240
<v Speaker 2>But is that because you're doing worse or just because

215
00:11:07.240 --> 00:11:11.039
<v Speaker 2>you have more stuff? So the recommendation is to normalize

216
00:11:11.320 --> 00:11:15.600
<v Speaker 2>your key performance indicators your KPIs instead of total vulnerabilities,

217
00:11:15.679 --> 00:11:18.080
<v Speaker 2>track vulnerabilities per device for instance.

218
00:11:18.200 --> 00:11:21.600
<v Speaker 1>Ah okay, so that gives you a consistent score regardless

219
00:11:21.600 --> 00:11:23.200
<v Speaker 1>of whether your network grows or strengths.

220
00:11:23.360 --> 00:11:25.840
<v Speaker 2>Exactly, it gives you a meaningful way to track if

221
00:11:25.840 --> 00:11:28.320
<v Speaker 2>you're actually improving your security posture over time.

222
00:11:29.159 --> 00:11:33.440
<v Speaker 1>Okay, but let's be real. In any complex project, things

223
00:11:33.519 --> 00:11:36.600
<v Speaker 1>go wrong, stuff happens. What are some of the common

224
00:11:36.639 --> 00:11:40.600
<v Speaker 1>pitfalls or gotchas that architects run into? According to the source.

225
00:11:40.480 --> 00:11:44.480
<v Speaker 2>Oh yeah, the guy definitely addresses the messy reality, and

226
00:11:44.559 --> 00:11:48.159
<v Speaker 2>it highlights several common gotchas, things like scope failures, the

227
00:11:48.200 --> 00:11:52.480
<v Speaker 2>project balloons, out of control requirements, misunderstandings, building the wrong

228
00:11:52.559 --> 00:11:54.720
<v Speaker 2>thing because the needs weren't clear, lack of buy in

229
00:11:54.799 --> 00:11:58.519
<v Speaker 2>we talked about that, super critical communication breakdowns between teams,

230
00:11:59.440 --> 00:12:02.399
<v Speaker 2>and of course just plain old technical issues. Something doesn't

231
00:12:02.399 --> 00:12:06.240
<v Speaker 2>work as expected. And again the source stresses how crucial

232
00:12:06.320 --> 00:12:09.799
<v Speaker 2>good documentation is here not just to prevent problems, but

233
00:12:09.840 --> 00:12:12.559
<v Speaker 2>as a tool to help diagnose and resolve them when

234
00:12:12.559 --> 00:12:13.759
<v Speaker 2>they inevitably pop up.

235
00:12:14.000 --> 00:12:17.080
<v Speaker 1>So the blueprint isn't just for building, it's for troubleshooting too.

236
00:12:17.159 --> 00:12:17.759
<v Speaker 2>Absolutely.

237
00:12:17.919 --> 00:12:20.600
<v Speaker 1>The book also gives some practical tips and tricks from

238
00:12:20.679 --> 00:12:25.559
<v Speaker 1>experienced architects right for navigating these choppy waters. Any that

239
00:12:25.799 --> 00:12:27.559
<v Speaker 1>particularly stood out, Yeah, there were.

240
00:12:27.480 --> 00:12:30.360
<v Speaker 2>Some really good ones. Cultivating empathy was a big one.

241
00:12:30.600 --> 00:12:33.399
<v Speaker 2>Understanding the pressures and perspectives of other teams you need.

242
00:12:33.279 --> 00:12:35.759
<v Speaker 1>To work with mmm important but often overlooked.

243
00:12:35.840 --> 00:12:39.759
<v Speaker 2>Definitely. Another was the idea of having just enough process.

244
00:12:40.480 --> 00:12:44.159
<v Speaker 2>Too little is chaos, sure, but too much process creates drag,

245
00:12:44.399 --> 00:12:48.200
<v Speaker 2>bureaucracy and slows everything down. It's about finding that sweet.

246
00:12:47.879 --> 00:12:50.159
<v Speaker 1>Spot, making security an enabler, not.

247
00:12:50.159 --> 00:12:53.559
<v Speaker 2>A roadblock exactly. And the importance of over communicating was

248
00:12:53.559 --> 00:12:57.240
<v Speaker 2>stressed too, especially when you're implementing changes. You really can't

249
00:12:57.279 --> 00:12:59.480
<v Speaker 2>communicate too much to make sure everyone's on board and

250
00:12:59.559 --> 00:13:00.559
<v Speaker 2>understand why.

251
00:13:00.720 --> 00:13:04.440
<v Speaker 1>That idea of just enough process seems related to another

252
00:13:04.519 --> 00:13:08.879
<v Speaker 1>concept mentioned, Kerkhoff's principle, the idea about designing systems assuming

253
00:13:08.879 --> 00:13:09.799
<v Speaker 1>the details.

254
00:13:09.440 --> 00:13:14.159
<v Speaker 2>Will get out precisely. Kirkhoff's principle basically says, design your

255
00:13:14.159 --> 00:13:17.960
<v Speaker 2>security systems as if all the details about how they work,

256
00:13:18.159 --> 00:13:21.600
<v Speaker 2>except for the secret keys, will eventually become public knowledge.

257
00:13:21.600 --> 00:13:25.039
<v Speaker 1>Anyway, that sounds counterintuitive for security. Don't you want to

258
00:13:25.120 --> 00:13:26.159
<v Speaker 1>keep the design secret.

259
00:13:26.440 --> 00:13:30.360
<v Speaker 2>You'd think so, but the principle argues against security through obscurity.

260
00:13:31.039 --> 00:13:33.919
<v Speaker 2>If your security relies only on keeping the design secret,

261
00:13:34.080 --> 00:13:38.039
<v Speaker 2>it's fragile. More importantly, designing with his openness in mind

262
00:13:38.360 --> 00:13:42.639
<v Speaker 2>actually fosters collaboration. It means others, colleagues, maybe even external

263
00:13:42.679 --> 00:13:46.240
<v Speaker 2>experts can systematically examine the design, poke holes in it,

264
00:13:46.320 --> 00:13:47.879
<v Speaker 2>provide feedback. Ah.

265
00:13:47.919 --> 00:13:50.720
<v Speaker 1>So it makes the design itself stronger because more eyes

266
00:13:50.759 --> 00:13:51.840
<v Speaker 1>have looked at it critically.

267
00:13:52.039 --> 00:13:56.039
<v Speaker 2>Exactly, It encourages rigorous thinking right from the start, rather

268
00:13:56.080 --> 00:13:59.480
<v Speaker 2>than relying on secrecy as a crutch. Ultimately, it leads

269
00:13:59.519 --> 00:14:00.799
<v Speaker 2>to more bless security.

270
00:14:01.039 --> 00:14:05.159
<v Speaker 1>Okay, so all these pieces context blueprint baking it in validating, handling,

271
00:14:05.200 --> 00:14:09.320
<v Speaker 1>Gotcha's communication openness. It sounds like it leads towards a

272
00:14:09.320 --> 00:14:10.159
<v Speaker 1>continuous cycle.

273
00:14:10.320 --> 00:14:13.360
<v Speaker 2>It does. The ultimate goal is future proofing through what

274
00:14:13.399 --> 00:14:18.039
<v Speaker 2>the source calls a virtuous cycle of continuous improvement. It

275
00:14:18.159 --> 00:14:21.240
<v Speaker 2>uses the analogy of a batter and baseball constantly refining

276
00:14:21.279 --> 00:14:24.039
<v Speaker 2>their swing. It's never perfect, you always keep working on it.

277
00:14:24.080 --> 00:14:27.559
<v Speaker 1>So the plan doh, check act cycle PDCA.

278
00:14:27.120 --> 00:14:29.639
<v Speaker 2>Exactly that, planning what you need to do, doing it,

279
00:14:29.960 --> 00:14:32.639
<v Speaker 2>checking the results using those metrics we talk about, and

280
00:14:32.679 --> 00:14:35.240
<v Speaker 2>then acting on those results to adjust and improve the plan.

281
00:14:35.679 --> 00:14:39.679
<v Speaker 2>It's about constantly optimizing your security processes and adapting because

282
00:14:39.679 --> 00:14:42.600
<v Speaker 2>the threats are always evolving and the organization itself changes

283
00:14:42.639 --> 00:14:43.320
<v Speaker 2>over time too.

284
00:14:43.519 --> 00:14:45.919
<v Speaker 1>Wow. Okay, we've definitely covered a lot of ground today,

285
00:14:46.159 --> 00:14:50.120
<v Speaker 1>from figuring out what a cybersecurity architect actually does to

286
00:14:50.440 --> 00:14:54.679
<v Speaker 1>the really critical components of designing secure systems, thinking about

287
00:14:54.720 --> 00:14:57.720
<v Speaker 1>resiliency and depth, and even how to handle the inevitable

288
00:14:57.799 --> 00:15:00.399
<v Speaker 1>challenges along the way. It really underscore or is that

289
00:15:00.519 --> 00:15:04.120
<v Speaker 1>building a robust cybersecurity architecture isn't a one off project.

290
00:15:04.159 --> 00:15:10.240
<v Speaker 1>It's continuous. It requires constant practice, learning and real adaptability.

291
00:15:10.440 --> 00:15:14.159
<v Speaker 2>Absolutely, and remember maybe the most important thing isn't mastering

292
00:15:14.240 --> 00:15:17.639
<v Speaker 2>every single tool or technique right away, it's understanding the

293
00:15:17.679 --> 00:15:20.960
<v Speaker 2>why behind each step. Why are we establishing context, Why

294
00:15:21.039 --> 00:15:23.360
<v Speaker 2>are we documenting this way? Why are we using this metric?

295
00:15:23.879 --> 00:15:26.519
<v Speaker 2>Understanding the why allows you to adapt and innovate as

296
00:15:26.519 --> 00:15:29.240
<v Speaker 2>things change. The ultimate goal is always to make sure

297
00:15:29.320 --> 00:15:33.360
<v Speaker 2>security helps enable the organization's mission, continuously reducing risk while

298
00:15:33.399 --> 00:15:34.559
<v Speaker 2>maximizing opportunity.

299
00:15:34.720 --> 00:15:36.960
<v Speaker 1>Ah that's a great summary. We hope this deep dive

300
00:15:37.399 --> 00:15:40.960
<v Speaker 1>has given you, our listener, a powerful shortcut to being

301
00:15:41.039 --> 00:15:44.879
<v Speaker 1>well informed about cybersecurity architecture. So for you, the learner

302
00:15:44.919 --> 00:15:47.960
<v Speaker 1>listening in, maybe the key takeaway is this, how could

303
00:15:48.000 --> 00:15:50.960
<v Speaker 1>you apply some of these principles, like just enough process

304
00:15:51.240 --> 00:15:54.600
<v Speaker 1>or maybe designing for public knowledge in your own work

305
00:15:54.679 --> 00:15:58.759
<v Speaker 1>or learning, even if it's completely outside cybersecurity. What's maybe

306
00:15:58.840 --> 00:16:01.600
<v Speaker 1>one small iterative change you could make to a process

307
00:16:01.639 --> 00:16:04.480
<v Speaker 1>you care about to start your own little virtuous cycle

308
00:16:04.519 --> 00:16:07.639
<v Speaker 1>of improvement. Something to think about. We've really only scratched

309
00:16:07.679 --> 00:16:09.639
<v Speaker 1>the surface here, of course, There's always so much more

310
00:16:09.679 --> 00:16:12.559
<v Speaker 1>to learn in this field. Keep digging, keep exploring, and

311
00:16:12.600 --> 00:16:14.159
<v Speaker 1>we'll catch you next time on the deep dive