WEBVTT

1
00:00:00.000 --> 00:00:01.230
In this lesson,

2
00:00:01.230 --> 00:00:04.470
we will learn about technical attack surface.

3
00:00:04.470 --> 00:00:06.990
The technical attack surface is the sum

4
00:00:06.990 --> 00:00:09.270
of all potential entry points

5
00:00:09.270 --> 00:00:13.110
within an organization's technology infrastructure

6
00:00:13.110 --> 00:00:15.960
that could be exploited by an attacker.

7
00:00:15.960 --> 00:00:19.290
Technical attack surface concepts include:

8
00:00:19.290 --> 00:00:22.290
Architecture reviews, Data flows,

9
00:00:22.290 --> 00:00:25.260
Trust boundaries, and Code reviews.

10
00:00:25.260 --> 00:00:29.040
Architecture reviews involve evaluating the design

11
00:00:29.040 --> 00:00:33.300
and structure of a system to identify weaknesses

12
00:00:33.300 --> 00:00:36.120
or misconfigurations that could be targeted

13
00:00:36.120 --> 00:00:37.710
by a threat actor.

14
00:00:37.710 --> 00:00:40.620
Data flows are examined to understand

15
00:00:40.620 --> 00:00:45.620
how information moves within and between network systems.

16
00:00:45.810 --> 00:00:48.180
Trust boundaries define the points

17
00:00:48.180 --> 00:00:52.680
where data transitions from one level of trust to another.

18
00:00:52.680 --> 00:00:57.120
And last, code reviews involve the detailed examination

19
00:00:57.120 --> 00:01:00.390
of source code to detect vulnerabilities.

20
00:01:00.390 --> 00:01:04.770
Let's learn more about architecture reviews, data flows,

21
00:01:04.770 --> 00:01:07.590
trust boundaries, and code reviews.

22
00:01:07.590 --> 00:01:10.830
First, we have architecture reviews.

23
00:01:10.830 --> 00:01:13.680
Architecture reviews examine the design

24
00:01:13.680 --> 00:01:15.660
and structure of a system

25
00:01:15.660 --> 00:01:19.020
to identify potential security weaknesses

26
00:01:19.020 --> 00:01:22.860
or misconfigurations that attackers might exploit.

27
00:01:22.860 --> 00:01:25.320
This review is ideally conducted

28
00:01:25.320 --> 00:01:28.350
in the early stages of system design

29
00:01:28.350 --> 00:01:31.860
to ensure that architecture meets security goals

30
00:01:31.860 --> 00:01:35.550
and includes secure configurations, data flows,

31
00:01:35.550 --> 00:01:37.560
and system interactions.

32
00:01:37.560 --> 00:01:41.430
For instance, an architecture review might reveal

33
00:01:41.430 --> 00:01:44.280
that sensitive data is stored centrally

34
00:01:44.280 --> 00:01:47.340
and is accessible from multiple networks.

35
00:01:47.340 --> 00:01:51.090
This could increase risk if an attacker gains access

36
00:01:51.090 --> 00:01:53.490
to any one of those networks,

37
00:01:53.490 --> 00:01:56.670
prompting the team to restructure the design

38
00:01:56.670 --> 00:01:58.650
to segment access.

39
00:01:58.650 --> 00:02:02.340
Additionally, the Microsoft Threat Modeling Tool

40
00:02:02.340 --> 00:02:07.340
and OWASP's Threat Dragon can assist in architecture reviews

41
00:02:07.680 --> 00:02:11.730
by visualizing components and performing threat modeling.

42
00:02:11.730 --> 00:02:14.130
Architecture reviews also help

43
00:02:14.130 --> 00:02:18.270
to identify insecure default configurations

44
00:02:18.270 --> 00:02:22.140
or third-party dependencies within the infrastructure.

45
00:02:22.140 --> 00:02:23.220
For example,

46
00:02:23.220 --> 00:02:27.390
if a system relies on several third-party applications,

47
00:02:27.390 --> 00:02:30.990
each with its own unique protocols, policies,

48
00:02:30.990 --> 00:02:33.000
and security controls,

49
00:02:33.000 --> 00:02:34.530
these differences might lead

50
00:02:34.530 --> 00:02:38.160
to inconsistencies that attackers could exploit.

51
00:02:38.160 --> 00:02:40.830
So if during a review,

52
00:02:40.830 --> 00:02:43.410
the team finds an infrastructure component

53
00:02:43.410 --> 00:02:46.260
with inadequate authentication controls,

54
00:02:46.260 --> 00:02:48.990
they can address the vulnerability quickly

55
00:02:48.990 --> 00:02:51.600
to strengthen the system's security.

56
00:02:51.600 --> 00:02:53.520
Finally, by documenting

57
00:02:53.520 --> 00:02:56.430
and addressing architectural weaknesses,

58
00:02:56.430 --> 00:03:01.290
a security team can ensure all architectural aspects align

59
00:03:01.290 --> 00:03:03.300
with security goals.

60
00:03:03.300 --> 00:03:07.020
This reduces the system's technical attack surface,

61
00:03:07.020 --> 00:03:11.040
ultimately making the overall infrastructure more resilient

62
00:03:11.040 --> 00:03:12.480
to attack.

63
00:03:12.480 --> 00:03:15.330
Second, we have data flows.

64
00:03:15.330 --> 00:03:18.510
Data flow analysis focuses on understanding

65
00:03:18.510 --> 00:03:21.960
how data moves within and across systems,

66
00:03:21.960 --> 00:03:23.160
highlighting areas

67
00:03:23.160 --> 00:03:26.760
where sensitive information might be exposed.

68
00:03:26.760 --> 00:03:30.330
This analysis not only maps out pathways,

69
00:03:30.330 --> 00:03:35.250
but also helps teams understand data types, sensitivity,

70
00:03:35.250 --> 00:03:38.820
and security needs along each segment.

71
00:03:38.820 --> 00:03:43.820
Mapping data flows ensures information follows secure routes

72
00:03:43.950 --> 00:03:47.460
and doesn't inadvertently cross insecure

73
00:03:47.460 --> 00:03:49.530
or untrusted channels.

74
00:03:49.530 --> 00:03:52.230
For example, a team might find

75
00:03:52.230 --> 00:03:54.240
that sensitive customer data

76
00:03:54.240 --> 00:03:59.010
is being transmitted in plain text between internal servers,

77
00:03:59.010 --> 00:04:02.160
exposing it to potential interception.

78
00:04:02.160 --> 00:04:05.010
In response, they could implement encryption

79
00:04:05.010 --> 00:04:09.750
for all sensitive data transfers to secure these exchanges.

80
00:04:09.750 --> 00:04:11.190
Tools like Visio

81
00:04:11.190 --> 00:04:15.990
or Lucidchart are often used to map data flows visually,

82
00:04:15.990 --> 00:04:20.850
aiding in spotting areas needing stronger security measures.

83
00:04:20.850 --> 00:04:23.970
Though, specialized security tools may be used

84
00:04:23.970 --> 00:04:26.460
for more in-depth analysis.

85
00:04:26.460 --> 00:04:31.440
Examining data flows also allows security teams to verify

86
00:04:31.440 --> 00:04:35.070
that access controls are appropriately placed.

87
00:04:35.070 --> 00:04:39.090
For example, let's say a data flow review uncovers

88
00:04:39.090 --> 00:04:41.640
that accounting data is accessible

89
00:04:41.640 --> 00:04:45.150
by employees in unrelated departments.

90
00:04:45.150 --> 00:04:49.140
The team might then set up stricter access controls

91
00:04:49.140 --> 00:04:54.030
to ensure only authorized personnel can view financial data.

92
00:04:54.030 --> 00:04:57.450
So through regular data flow analysis,

93
00:04:57.450 --> 00:05:01.320
organizations can better control how data is accessed

94
00:05:01.320 --> 00:05:02.190
and shared,

95
00:05:02.190 --> 00:05:06.390
reducing opportunities for unauthorized access.

96
00:05:06.390 --> 00:05:09.240
Third, we have trust boundaries.

97
00:05:09.240 --> 00:05:12.030
Trust boundaries are the points within a system

98
00:05:12.030 --> 00:05:14.400
where data moves between zones

99
00:05:14.400 --> 00:05:16.500
with different levels of trust,

100
00:05:16.500 --> 00:05:20.910
such as between an internal network and the internet,

101
00:05:20.910 --> 00:05:24.720
a public-facing web server and an internal database,

102
00:05:24.720 --> 00:05:28.650
or an application interface and a backend system.

103
00:05:28.650 --> 00:05:32.160
Understanding how the data moves across these zones

104
00:05:32.160 --> 00:05:35.130
and boundaries enables managing access

105
00:05:35.130 --> 00:05:38.160
and implementing security controls.

106
00:05:38.160 --> 00:05:41.940
For example, in a standard enterprise network,

107
00:05:41.940 --> 00:05:46.200
a trust boundary exists between the internal network

108
00:05:46.200 --> 00:05:47.850
and the internet.

109
00:05:47.850 --> 00:05:49.710
Without proper controls,

110
00:05:49.710 --> 00:05:53.190
this boundary could allow an external attacker

111
00:05:53.190 --> 00:05:56.160
to access internal resources.

112
00:05:56.160 --> 00:05:59.160
Understanding this, setting up firewalls,

113
00:05:59.160 --> 00:06:01.230
or implementing network segmentation

114
00:06:01.230 --> 00:06:04.470
at these boundaries can help restrict access

115
00:06:04.470 --> 00:06:08.370
and limit the potential for unauthorized access.

116
00:06:08.370 --> 00:06:11.640
So managing trust boundaries ensures

117
00:06:11.640 --> 00:06:15.840
that only trusted entities can access sensitive areas

118
00:06:15.840 --> 00:06:18.540
of the network or application.

119
00:06:18.540 --> 00:06:22.200
If an organization is processing payment information,

120
00:06:22.200 --> 00:06:23.400
for instance,

121
00:06:23.400 --> 00:06:24.780
it needs to ensure

122
00:06:24.780 --> 00:06:29.070
that data remains in a secure zone within the network

123
00:06:29.070 --> 00:06:34.050
and does not cross into areas with lower security levels.

124
00:06:34.050 --> 00:06:38.190
Tools like Azure's Trust Boundary Analysis assist

125
00:06:38.190 --> 00:06:41.820
in defining and controlling these types of boundaries.

126
00:06:41.820 --> 00:06:44.460
So by monitoring trust boundaries

127
00:06:44.460 --> 00:06:47.250
and enforcing security controls,

128
00:06:47.250 --> 00:06:51.030
organizations can prevent data from being exposed

129
00:06:51.030 --> 00:06:54.540
or accessed by unauthorized users.

130
00:06:54.540 --> 00:06:58.530
Fourth and last, we have code reviews.

131
00:06:58.530 --> 00:07:01.590
Code reviews identify vulnerabilities

132
00:07:01.590 --> 00:07:04.200
in source code before deployment.

133
00:07:04.200 --> 00:07:08.550
Code analysis during reviews includes static analysis,

134
00:07:08.550 --> 00:07:11.910
dynamic analysis, side-channel analysis,

135
00:07:11.910 --> 00:07:15.960
reverse engineering, software composition analysis,

136
00:07:15.960 --> 00:07:17.580
and fuzz testing.

137
00:07:17.580 --> 00:07:21.360
Let's talk about each of these in just a little more detail.

138
00:07:21.360 --> 00:07:23.370
Static analysis is used

139
00:07:23.370 --> 00:07:26.520
to inspect code without executing it.

140
00:07:26.520 --> 00:07:30.630
This can be done manually or with tools like SonarQube

141
00:07:30.630 --> 00:07:32.490
or Checkmarx.

142
00:07:32.490 --> 00:07:33.840
If done manually,

143
00:07:33.840 --> 00:07:36.540
a person will examine the code for issues,

144
00:07:36.540 --> 00:07:41.370
such as insecure authentication or vulnerable library use,

145
00:07:41.370 --> 00:07:44.670
while automated tools will scan on their own

146
00:07:44.670 --> 00:07:48.090
for known vulnerabilities, misconfigurations,

147
00:07:48.090 --> 00:07:50.490
or common coding errors.

148
00:07:50.490 --> 00:07:53.280
Using both types of static analysis,

149
00:07:53.280 --> 00:07:57.450
manual review and automated tools, is recommended.

150
00:07:57.450 --> 00:07:58.680
In contrast,

151
00:07:58.680 --> 00:08:02.610
dynamic analysis tests code while it's executing

152
00:08:02.610 --> 00:08:05.820
in a controlled environment, like a sandbox,

153
00:08:05.820 --> 00:08:10.740
to observe interactions with the host system during runtime.

154
00:08:10.740 --> 00:08:13.590
A sandbox is an isolated environment

155
00:08:13.590 --> 00:08:17.160
that can monitor how code interacts with the network

156
00:08:17.160 --> 00:08:19.530
and the host it is installed on

157
00:08:19.530 --> 00:08:22.800
without affecting the actual host machine.

158
00:08:22.800 --> 00:08:25.590
Developers may use dynamic analysis

159
00:08:25.590 --> 00:08:27.600
and sandbox isolation

160
00:08:27.600 --> 00:08:31.770
to monitor malware behavior on a virtual machine,

161
00:08:31.770 --> 00:08:33.720
noting modified files,

162
00:08:33.720 --> 00:08:35.010
new processes,

163
00:08:35.010 --> 00:08:39.360
or registry changes that the malware attempts to make.

164
00:08:39.360 --> 00:08:41.850
Additionally, tools like Burp Suite

165
00:08:41.850 --> 00:08:45.660
can capture network traffic during dynamic analysis,

166
00:08:45.660 --> 00:08:50.550
acting as a proxy to monitor and manipulate data exchanges.

167
00:08:50.550 --> 00:08:53.160
Additionally, side-channel analysis,

168
00:08:53.160 --> 00:08:55.740
a subset of dynamic analysis,

169
00:08:55.740 --> 00:08:58.710
focuses on observing indirect outputs,

170
00:08:58.710 --> 00:09:02.010
like network traffic or system responses,

171
00:09:02.010 --> 00:09:04.620
often through tools like Wireshark

172
00:09:04.620 --> 00:09:07.110
to understand code behavior.

173
00:09:07.110 --> 00:09:10.200
Next, reverse engineering is a process

174
00:09:10.200 --> 00:09:15.200
that helps analysts understand complex or obfuscated code,

175
00:09:15.420 --> 00:09:19.020
and is especially useful for proprietary software

176
00:09:19.020 --> 00:09:23.460
or malware where source code is not fully available.

177
00:09:23.460 --> 00:09:27.570
Tools like IDA Pro, which is a decompiler,

178
00:09:27.570 --> 00:09:31.230
and OllyDbg, which is a debugger,

179
00:09:31.230 --> 00:09:35.790
can help pull apart code into its executable components

180
00:09:35.790 --> 00:09:39.030
for analysis and reverse engineering.

181
00:09:39.030 --> 00:09:42.900
A decompiler like IDA Pro can convert code

182
00:09:42.900 --> 00:09:44.850
into assembly language

183
00:09:44.850 --> 00:09:46.770
for detailed inspection,

184
00:09:46.770 --> 00:09:50.070
while a debugger like OllyDbg

185
00:09:50.070 --> 00:09:53.400
enables step-by-step code execution,

186
00:09:53.400 --> 00:09:57.060
helping to identify specific code steps.

187
00:09:57.060 --> 00:10:01.260
So by examining underlying instructions like this,

188
00:10:01.260 --> 00:10:03.960
analysts can uncover hidden functions

189
00:10:03.960 --> 00:10:08.550
or vulnerabilities that might otherwise be overlooked.

190
00:10:08.550 --> 00:10:13.020
Next, software composition analysis, or SCA,

191
00:10:13.020 --> 00:10:14.910
may be used to identify

192
00:10:14.910 --> 00:10:17.370
and manage third-party components,

193
00:10:17.370 --> 00:10:19.980
such as open source libraries,

194
00:10:19.980 --> 00:10:23.340
to ensure they are secure and compliant.

195
00:10:23.340 --> 00:10:24.360
This is helpful

196
00:10:24.360 --> 00:10:27.960
because attackers frequently target vulnerabilities

197
00:10:27.960 --> 00:10:30.180
in widely used libraries.

198
00:10:30.180 --> 00:10:33.240
So SCA tools like Snyk

199
00:10:33.240 --> 00:10:35.430
and WhiteSource can be used

200
00:10:35.430 --> 00:10:40.430
to help teams identify outdated or insecure dependencies,

201
00:10:40.950 --> 00:10:45.570
recommending updates or mitigations to align the code base

202
00:10:45.570 --> 00:10:47.760
with security standards.

203
00:10:47.760 --> 00:10:49.980
Finally, fuzz testing,

204
00:10:49.980 --> 00:10:51.300
or fuzzing,

205
00:10:51.300 --> 00:10:55.560
injects randomized data into executing code

206
00:10:55.560 --> 00:10:58.890
to find weaknesses in input handling.

207
00:10:58.890 --> 00:11:00.938
Tools like the Peach Fuzzer

208
00:11:00.938 --> 00:11:05.938
and WSFuzzer are used to test how applications respond

209
00:11:06.000 --> 00:11:08.430
to unexpected inputs,

210
00:11:08.430 --> 00:11:11.850
uncovering errors that could be exploited.

211
00:11:11.850 --> 00:11:15.330
So remember, the technical attack surface

212
00:11:15.330 --> 00:11:18.210
includes all potential entry points

213
00:11:18.210 --> 00:11:21.750
in an organization's technology infrastructure

214
00:11:21.750 --> 00:11:24.690
that could be exploited by attackers.

215
00:11:24.690 --> 00:11:28.380
Key components in managing this surface include:

216
00:11:28.380 --> 00:11:31.470
architecture reviews, data flows,

217
00:11:31.470 --> 00:11:34.590
trust boundaries, and code reviews.

218
00:11:34.590 --> 00:11:38.610
Architecture reviews evaluate a systems design

219
00:11:38.610 --> 00:11:40.410
to spot weaknesses,

220
00:11:40.410 --> 00:11:43.380
ensuring configurations are secure

221
00:11:43.380 --> 00:11:45.840
and data storage is protected.

222
00:11:45.840 --> 00:11:48.000
Data flow analysis examines

223
00:11:48.000 --> 00:11:51.120
how information moves across systems,

224
00:11:51.120 --> 00:11:56.010
identifying areas where sensitive data might be exposed.

225
00:11:56.010 --> 00:11:59.670
Trust boundaries define points where data transitions

226
00:11:59.670 --> 00:12:02.100
between different security levels,

227
00:12:02.100 --> 00:12:06.510
such as between internal networks and the internet.

228
00:12:06.510 --> 00:12:10.440
And by managing these boundaries with tools like firewalls

229
00:12:10.440 --> 00:12:11.910
and segmentation,

230
00:12:11.910 --> 00:12:15.630
teams can restrict access to critical areas.

231
00:12:15.630 --> 00:12:19.290
Finally, code reviews detect vulnerabilities

232
00:12:19.290 --> 00:12:23.460
in source code through static and dynamic analysis,

233
00:12:23.460 --> 00:12:27.480
ensuring applications are resilient before deployment.

234
00:12:27.480 --> 00:12:31.410
Together, these practices secure the infrastructure,

235
00:12:31.410 --> 00:12:33.510
reducing the attack surface,

236
00:12:33.510 --> 00:12:36.333
and strengthening system defenses.