WEBVTT

1
00:00:00.000 --> 00:00:01.800
In this section of the course,

2
00:00:01.800 --> 00:00:04.740
we are going to discuss Security in Systems.

3
00:00:04.740 --> 00:00:07.170
The Security in Systems section of the course

4
00:00:07.170 --> 00:00:10.560
focuses on Domain 2: Security Architecture,

5
00:00:10.560 --> 00:00:13.410
specifically objective 2.2,

6
00:00:13.410 --> 00:00:15.900
which states that given a scenario,

7
00:00:15.900 --> 00:00:18.480
you must be able to implement security

8
00:00:18.480 --> 00:00:22.530
in the early and subsequent states of a system's life cycle.

9
00:00:22.530 --> 00:00:26.340
Securing complex systems requires a proactive strategy

10
00:00:26.340 --> 00:00:29.340
that begins with including security concepts

11
00:00:29.340 --> 00:00:33.030
into every component of the hardware and software life cycle

12
00:00:33.030 --> 00:00:34.530
right from the outset.

13
00:00:34.530 --> 00:00:38.220
Security and systems further requires thorough validation

14
00:00:38.220 --> 00:00:40.620
at each stage of deployment and development

15
00:00:40.620 --> 00:00:43.200
to ensure that vulnerabilities are minimized

16
00:00:43.200 --> 00:00:44.610
and addressed promptly.

17
00:00:44.610 --> 00:00:47.970
Finally, maintaining a strong security posture

18
00:00:47.970 --> 00:00:51.630
also involves continuous evaluation and adaptation

19
00:00:51.630 --> 00:00:53.670
as the secure system evolves.

20
00:00:53.670 --> 00:00:57.060
This secures it against emerging and evolving threats.

21
00:00:57.060 --> 00:01:00.120
As we go through this section, we will cover many topics

22
00:01:00.120 --> 00:01:01.950
related to Security in Systems,

23
00:01:01.950 --> 00:01:05.670
including Hardware Assurance, Security Requirements,

24
00:01:05.670 --> 00:01:08.730
Software Assurance, Supply Chain Assurance,

25
00:01:08.730 --> 00:01:11.160
Pre and Post-deployment Testing,

26
00:01:11.160 --> 00:01:13.740
Continuous Integration/Continuous Deployment

27
00:01:13.740 --> 00:01:17.910
Management and Testing, and End-of-life Considerations.

28
00:01:17.910 --> 00:01:20.640
First, we will look at Hardware Assurance.

29
00:01:20.640 --> 00:01:21.900
Hardware assurance ensures

30
00:01:21.900 --> 00:01:24.960
that physical components are secure, reliable,

31
00:01:24.960 --> 00:01:28.050
and free from malicious alterations or defects.

32
00:01:28.050 --> 00:01:29.430
Hardware assurance concepts

33
00:01:29.430 --> 00:01:32.700
include the certification and validation process.

34
00:01:32.700 --> 00:01:35.760
The certification process is a formal evaluation

35
00:01:35.760 --> 00:01:37.740
that verifies hardware components

36
00:01:37.740 --> 00:01:41.700
meets specific security standards and operate as expected.

37
00:01:41.700 --> 00:01:45.450
Validation is the ongoing process of testing and verifying

38
00:01:45.450 --> 00:01:47.820
that hardware meets its design standards,

39
00:01:47.820 --> 00:01:50.850
especially when updates or changes are made.

40
00:01:50.850 --> 00:01:54.630
For example, a government agency may require hardware

41
00:01:54.630 --> 00:01:55.950
used in critical systems

42
00:01:55.950 --> 00:01:59.280
to undergo a rigorous certification process,

43
00:01:59.280 --> 00:02:02.130
followed by a regular validation check

44
00:02:02.130 --> 00:02:04.980
to ensure the hardware remains secure.

45
00:02:04.980 --> 00:02:08.340
Next, we will explore Security Requirements.

46
00:02:08.340 --> 00:02:11.130
Security requirements are the specific criteria

47
00:02:11.130 --> 00:02:14.010
a system must meet to ensure protection

48
00:02:14.010 --> 00:02:17.070
against security threats and vulnerabilities.

49
00:02:17.070 --> 00:02:19.590
Security requirements can be categorized

50
00:02:19.590 --> 00:02:22.470
as functional or non-functional.

51
00:02:22.470 --> 00:02:24.060
Functional security requirements

52
00:02:24.060 --> 00:02:26.730
define specific security-related behaviors

53
00:02:26.730 --> 00:02:28.920
and features that a system must have,

54
00:02:28.920 --> 00:02:31.320
such as authentication mechanisms,

55
00:02:31.320 --> 00:02:34.260
access controls, and encryption protocols.

56
00:02:34.260 --> 00:02:36.510
Non-functional security requirements

57
00:02:36.510 --> 00:02:38.520
focus on the qualities of the system,

58
00:02:38.520 --> 00:02:42.300
including its performance, reliability, and usability.

59
00:02:42.300 --> 00:02:45.810
A common challenge in security requirement implementations

60
00:02:45.810 --> 00:02:48.060
is security versus usability.

61
00:02:48.060 --> 00:02:49.890
This can require a trade-off,

62
00:02:49.890 --> 00:02:52.140
such as increasing security measures

63
00:02:52.140 --> 00:02:54.060
like multi-factor authentication,

64
00:02:54.060 --> 00:02:57.630
which may reduce user convenience and accessibility.

65
00:02:57.630 --> 00:03:00.720
After that, we will look at Software Assurance.

66
00:03:00.720 --> 00:03:03.000
Software assurance is the process of ensuring

67
00:03:03.000 --> 00:03:05.310
software is developed and maintained

68
00:03:05.310 --> 00:03:06.930
in a way that consistently meets

69
00:03:06.930 --> 00:03:09.390
security and reliability standards.

70
00:03:09.390 --> 00:03:11.820
This protects the software from vulnerabilities

71
00:03:11.820 --> 00:03:13.380
and malicious threats.

72
00:03:13.380 --> 00:03:15.000
Software assurance concepts

73
00:03:15.000 --> 00:03:17.310
include a Software Bill of Materials,

74
00:03:17.310 --> 00:03:19.470
Software Composition Analysis,

75
00:03:19.470 --> 00:03:22.500
and Formal methods of validating software correctness,

76
00:03:22.500 --> 00:03:24.660
safety, and security.

77
00:03:24.660 --> 00:03:27.270
First, a Software Bill of Materials

78
00:03:27.270 --> 00:03:29.910
is a comprehensive list of all components,

79
00:03:29.910 --> 00:03:34.290
libraries, and dependencies used in a software application

80
00:03:34.290 --> 00:03:37.950
to provide transparency in the software's construction.

81
00:03:37.950 --> 00:03:41.010
Next, Software Composition Analysis

82
00:03:41.010 --> 00:03:43.830
involves scanning and analyzing the components

83
00:03:43.830 --> 00:03:46.620
and dependencies of software applications

84
00:03:46.620 --> 00:03:50.580
to identify known vulnerabilities or licensing issues.

85
00:03:50.580 --> 00:03:53.250
Finally, Formal Methods of Validation

86
00:03:53.250 --> 00:03:55.380
are mathematically based techniques

87
00:03:55.380 --> 00:03:58.380
used to verify the correctness and security

88
00:03:58.380 --> 00:04:01.050
of software algorithms and systems.

89
00:04:01.050 --> 00:04:04.470
Next, we will explore Supply Chain Assurance.

90
00:04:04.470 --> 00:04:07.470
Supply Chain Assurance ensures that all components

91
00:04:07.470 --> 00:04:09.750
and processes within the supply chain,

92
00:04:09.750 --> 00:04:11.280
from vendors to delivery,

93
00:04:11.280 --> 00:04:13.830
meet security and quality standards.

94
00:04:13.830 --> 00:04:16.590
This prevents the introduction of vulnerabilities

95
00:04:16.590 --> 00:04:18.480
into the final system.

96
00:04:18.480 --> 00:04:20.310
Supply Chain Assurance concepts

97
00:04:20.310 --> 00:04:24.060
include managing both hardware and software risk.

98
00:04:24.060 --> 00:04:26.400
Supply Chain Risk Management for hardware

99
00:04:26.400 --> 00:04:29.910
focuses on evaluating and securing physical components

100
00:04:29.910 --> 00:04:33.930
from potential threats such as tampering, counterfeit parts,

101
00:04:33.930 --> 00:04:36.000
or vulnerabilities introduced

102
00:04:36.000 --> 00:04:38.640
during manufacturing and distribution.

103
00:04:38.640 --> 00:04:41.460
For software, Supply Chain Risk Management

104
00:04:41.460 --> 00:04:43.560
involves assessing and managing risks

105
00:04:43.560 --> 00:04:46.080
related to third-party software components,

106
00:04:46.080 --> 00:04:48.780
such as vulnerabilities or compliance issues

107
00:04:48.780 --> 00:04:51.780
that could affect the overall security of the system.

108
00:04:51.780 --> 00:04:54.630
For example, a financial institution

109
00:04:54.630 --> 00:04:57.090
ensuring the security of its trading platform

110
00:04:57.090 --> 00:05:00.810
will vet hardware components for integrity and authenticity,

111
00:05:00.810 --> 00:05:04.560
which prevents tampering or the use of counterfeit parts.

112
00:05:04.560 --> 00:05:07.110
Simultaneously, the financial institution

113
00:05:07.110 --> 00:05:09.570
will assess third-party software libraries

114
00:05:09.570 --> 00:05:11.970
for vulnerabilities and compliance issues.

115
00:05:11.970 --> 00:05:15.543
This will ensure that both hardware and software components

116
00:05:15.543 --> 00:05:17.130
meet security standards

117
00:05:17.130 --> 00:05:20.550
to protect the overall financial trading platform.

118
00:05:20.550 --> 00:05:23.940
Following that, we will look at Pre-Deployment Testing.

119
00:05:23.940 --> 00:05:27.120
Pre-Deployment Testing is used to evaluate software

120
00:05:27.120 --> 00:05:30.240
for security vulnerabilities, functional issues,

121
00:05:30.240 --> 00:05:31.740
and performance concerns

122
00:05:31.740 --> 00:05:34.980
before the software is released into a live environment.

123
00:05:34.980 --> 00:05:36.660
Pre-Deployment Testing concepts

124
00:05:36.660 --> 00:05:41.520
include Static Application Security Testing or SAST,

125
00:05:41.520 --> 00:05:45.270
Dynamic Application Security Testing or DAST,

126
00:05:45.270 --> 00:05:49.740
and Interactive Application Security Testing or IAST.

127
00:05:49.740 --> 00:05:51.990
Static Application Security Testing

128
00:05:51.990 --> 00:05:54.330
analyzes source code or binaries

129
00:05:54.330 --> 00:05:57.450
for vulnerabilities without executing the software.

130
00:05:57.450 --> 00:06:00.000
It identifies issues such as coding flaws

131
00:06:00.000 --> 00:06:03.630
and security weaknesses early in the development process.

132
00:06:03.630 --> 00:06:05.970
Dynamic Application Security Testing

133
00:06:05.970 --> 00:06:09.270
examines the running application for vulnerabilities

134
00:06:09.270 --> 00:06:12.450
by simulating attacks to uncover issues

135
00:06:12.450 --> 00:06:16.170
that occurred during runtime, such as injection flaws

136
00:06:16.170 --> 00:06:18.300
or authentication weaknesses.

137
00:06:18.300 --> 00:06:21.930
Interactive Application Security Testing combines elements

138
00:06:21.930 --> 00:06:24.630
of both Static Application Security Testing

139
00:06:24.630 --> 00:06:27.390
and Dynamic Application Security Testing,

140
00:06:27.390 --> 00:06:30.180
by integrating testing with a running application

141
00:06:30.180 --> 00:06:33.660
to provide real-time feedback on vulnerabilities.

142
00:06:33.660 --> 00:06:35.550
As compared to pure static

143
00:06:35.550 --> 00:06:38.130
or Dynamic Application Security Testing,

144
00:06:38.130 --> 00:06:40.470
Interactive Application Security Testing

145
00:06:40.470 --> 00:06:43.230
offers a more comprehensive analysis.

146
00:06:43.230 --> 00:06:45.360
For example, during the development

147
00:06:45.360 --> 00:06:47.460
of a new e-commerce application,

148
00:06:47.460 --> 00:06:49.980
as developers are running functional tests,

149
00:06:49.980 --> 00:06:53.250
an interactive application security testing tool

150
00:06:53.250 --> 00:06:57.150
can dynamically analyze the application in real-time.

151
00:06:57.150 --> 00:07:00.810
This can detect issues such as improper input validation

152
00:07:00.810 --> 00:07:02.700
and insecure data storage.

153
00:07:02.700 --> 00:07:05.550
The Interactive Application Security Testing tool

154
00:07:05.550 --> 00:07:07.410
could then provide immediate feedback

155
00:07:07.410 --> 00:07:08.790
on those vulnerabilities,

156
00:07:08.790 --> 00:07:11.580
allowing developers to address them promptly

157
00:07:11.580 --> 00:07:13.860
before the application is deployed.

158
00:07:13.860 --> 00:07:16.590
Then we will explore Post-Deployment Testing.

159
00:07:16.590 --> 00:07:19.710
Post-Deployment Testing is used to evaluate software

160
00:07:19.710 --> 00:07:22.500
after it has been released into a live environment,

161
00:07:22.500 --> 00:07:25.410
to identify and address any security vulnerabilities

162
00:07:25.410 --> 00:07:27.120
and performance issues.

163
00:07:27.120 --> 00:07:29.130
Post-Deployment Testing concepts

164
00:07:29.130 --> 00:07:31.320
include Vulnerability Analysis

165
00:07:31.320 --> 00:07:35.670
and Runtime Application Self-Protection or RASP.

166
00:07:35.670 --> 00:07:37.740
Vulnerability Analysis involves

167
00:07:37.740 --> 00:07:39.300
scanning the deployed application

168
00:07:39.300 --> 00:07:41.100
for known security weaknesses

169
00:07:41.100 --> 00:07:43.350
that can be exploited by attackers.

170
00:07:43.350 --> 00:07:47.310
Runtime Application Self-Protection is a security technology

171
00:07:47.310 --> 00:07:48.360
that operates within

172
00:07:48.360 --> 00:07:50.640
the Post-Deployment Runtime environment.

173
00:07:50.640 --> 00:07:52.770
It provides real-time protection

174
00:07:52.770 --> 00:07:55.050
by monitoring application behavior

175
00:07:55.050 --> 00:07:57.960
and blocking threats on observed anomalies.

176
00:07:57.960 --> 00:07:59.910
For example, after deploying

177
00:07:59.910 --> 00:08:02.190
a new online banking application,

178
00:08:02.190 --> 00:08:05.430
the bank's Runtime Application Self-Protection tool

179
00:08:05.430 --> 00:08:08.880
may identify an attempted Structured Query Language

180
00:08:08.880 --> 00:08:10.890
or SQL injection attack.

181
00:08:10.890 --> 00:08:14.610
In response, the Runtime Application Self-Protection tool

182
00:08:14.610 --> 00:08:17.220
can automatically block malicious requests,

183
00:08:17.220 --> 00:08:19.410
preventing unauthorized access.

184
00:08:19.410 --> 00:08:23.010
This real-time defense mechanism helps mitigate threats

185
00:08:23.010 --> 00:08:24.330
that could be exploited

186
00:08:24.330 --> 00:08:27.660
despite having static security measures in place.

187
00:08:27.660 --> 00:08:29.400
After that, we will look at

188
00:08:29.400 --> 00:08:32.760
Continuous Integration/Continuous Deployment Management.

189
00:08:32.760 --> 00:08:35.580
Continuous Integration/Continuous Deployment Management

190
00:08:35.580 --> 00:08:39.810
involves automating the process of integrating code changes,

191
00:08:39.810 --> 00:08:42.300
running tests, and deploying applications

192
00:08:42.300 --> 00:08:45.600
which ensure consistent and efficient software delivery.

193
00:08:45.600 --> 00:08:47.760
Continuous Integration/Continuous Deployment

194
00:08:47.760 --> 00:08:49.080
Management concepts

195
00:08:49.080 --> 00:08:53.070
include coding standards and linting, branch protection,

196
00:08:53.070 --> 00:08:55.170
and continuous improvement.

197
00:08:55.170 --> 00:08:57.870
Coding standards and the use of a linting tool

198
00:08:57.870 --> 00:09:01.020
ensure the code adheres to predefined guidelines.

199
00:09:01.020 --> 00:09:02.880
This improves readability

200
00:09:02.880 --> 00:09:06.180
and reduces the risk of introducing security vulnerabilities

201
00:09:06.180 --> 00:09:08.460
or bugs to the software.

202
00:09:08.460 --> 00:09:11.430
Branch Protection involves setting up rules

203
00:09:11.430 --> 00:09:14.100
that control how code changes are merged

204
00:09:14.100 --> 00:09:16.350
into important development branches.

205
00:09:16.350 --> 00:09:19.380
Branch Protection may require code reviews

206
00:09:19.380 --> 00:09:23.100
and automated testing before branch integration.

207
00:09:23.100 --> 00:09:25.050
Continuous Improvement includes

208
00:09:25.050 --> 00:09:27.360
regularly updating and refining

209
00:09:27.360 --> 00:09:30.900
the Continuous Integration/Continuous Deployment pipeline

210
00:09:30.900 --> 00:09:34.020
based on feedback and performance metrics.

211
00:09:34.020 --> 00:09:35.850
Putting these concepts together,

212
00:09:35.850 --> 00:09:38.880
a development team might enforce coding standards

213
00:09:38.880 --> 00:09:43.200
and use a linting tool to identify potential security issues

214
00:09:43.200 --> 00:09:46.200
before code is merged into the main branch

215
00:09:46.200 --> 00:09:48.120
of the version control system.

216
00:09:48.120 --> 00:09:50.310
They will also use Branch Protection

217
00:09:50.310 --> 00:09:53.670
to ensure only reviewed and tested code is deployed

218
00:09:53.670 --> 00:09:55.350
and continuously improve

219
00:09:55.350 --> 00:09:58.680
the Continuous Integration/Continuous Deployment pipeline

220
00:09:58.680 --> 00:10:01.770
by incorporating new security tools and practices

221
00:10:01.770 --> 00:10:04.890
based on the latest threats and vulnerabilities.

222
00:10:04.890 --> 00:10:06.450
Next, we will explore

223
00:10:06.450 --> 00:10:08.940
the Continuous Integration/Continuous Deployment

224
00:10:08.940 --> 00:10:10.380
Testing process.

225
00:10:10.380 --> 00:10:13.110
Continuous Integration/Continuous Deployment testing

226
00:10:13.110 --> 00:10:15.900
systematically evaluates code changes

227
00:10:15.900 --> 00:10:19.110
to identify and address security vulnerabilities

228
00:10:19.110 --> 00:10:20.610
and functional issues

229
00:10:20.610 --> 00:10:23.370
before the code is deployed to production.

230
00:10:23.370 --> 00:10:25.830
Continuous Integration/Continuous Deployment

231
00:10:25.830 --> 00:10:27.840
testing concepts include

232
00:10:27.840 --> 00:10:30.600
Canary Testing, Regression Testing,

233
00:10:30.600 --> 00:10:33.720
Automated Test and Test, Unit Testing,

234
00:10:33.720 --> 00:10:35.580
and Integration Testing.

235
00:10:35.580 --> 00:10:37.860
Canary Testing involves deploying changes

236
00:10:37.860 --> 00:10:40.920
to a small subset of users to monitor for issues

237
00:10:40.920 --> 00:10:42.450
before a full rollout.

238
00:10:42.450 --> 00:10:45.000
In this manner, Canary Testing helps detect

239
00:10:45.000 --> 00:10:47.190
potential security flaws quickly.

240
00:10:47.190 --> 00:10:50.640
Next, Regression Testing ensures new code changes

241
00:10:50.640 --> 00:10:53.910
do not adversely affect existing functionality.

242
00:10:53.910 --> 00:10:56.640
Then, Integration Testing may be used to check

243
00:10:56.640 --> 00:10:59.370
the interaction between different system components,

244
00:10:59.370 --> 00:11:03.240
which identifies issues arising from combined functionality.

245
00:11:03.240 --> 00:11:06.540
Additionally, Automated Test and Retest processes

246
00:11:06.540 --> 00:11:10.080
streamline the identification of bugs and vulnerabilities

247
00:11:10.080 --> 00:11:12.150
by running tests automatically

248
00:11:12.150 --> 00:11:15.750
during the Continuous Integration/Continuous Deployment

249
00:11:15.750 --> 00:11:17.040
testing pipeline.

250
00:11:17.040 --> 00:11:20.430
Finally, Unit Testing focuses on verifying

251
00:11:20.430 --> 00:11:23.850
individual components or functions for correctness.

252
00:11:23.850 --> 00:11:28.680
Last, we will look at End-of-Life or EOL considerations.

253
00:11:28.680 --> 00:11:32.100
End-of-Life considerations involve planning and managing

254
00:11:32.100 --> 00:11:35.670
the security implications of decommissioning or replacing

255
00:11:35.670 --> 00:11:37.590
software and hardware.

256
00:11:37.590 --> 00:11:39.930
Specific End-of-Life considerations

257
00:11:39.930 --> 00:11:43.080
include lifecycle management and data migration.

258
00:11:43.080 --> 00:11:44.970
Lifecycle management ensures

259
00:11:44.970 --> 00:11:47.460
that unsupported software or hardware

260
00:11:47.460 --> 00:11:50.010
is either upgraded or replaced

261
00:11:50.010 --> 00:11:53.340
to avoid exposure to unpatched vulnerabilities.

262
00:11:53.340 --> 00:11:56.250
Data migration and secure deletion practices

263
00:11:56.250 --> 00:11:59.460
must be implemented to protect sensitive information

264
00:11:59.460 --> 00:12:02.550
from unauthorized access during transition.

265
00:12:02.550 --> 00:12:05.670
For example, when decommissioning an old server,

266
00:12:05.670 --> 00:12:07.800
an organization should migrate data

267
00:12:07.800 --> 00:12:10.020
to a new supported system

268
00:12:10.020 --> 00:12:12.720
and securely wipe the old server storage

269
00:12:12.720 --> 00:12:14.460
to prevent data breaches.

270
00:12:14.460 --> 00:12:17.040
To finish things off, we'll take a short quiz

271
00:12:17.040 --> 00:12:20.040
to see what you learned during this section of the course,

272
00:12:20.040 --> 00:12:22.920
and we will review each of those quiz questions fully,

273
00:12:22.920 --> 00:12:26.310
to ensure you can explain why the right answers were right

274
00:12:26.310 --> 00:12:28.350
and the wrong answers were wrong.

275
00:12:28.350 --> 00:12:32.430
So, let's get ready to dive into Security in Systems

276
00:12:32.430 --> 00:12:34.754
in this section of the course!