WEBVTT

1
00:00:00.180 --> 00:00:01.950
<v ->In this section of the course,</v>

2
00:00:01.950 --> 00:00:03.570
we are going to discuss

3
00:00:03.570 --> 00:00:06.210
integrated security and automation.

4
00:00:06.210 --> 00:00:09.480
The integrated security and automation section of the course

5
00:00:09.480 --> 00:00:12.960
focuses on domain three, security engineering,

6
00:00:12.960 --> 00:00:15.990
specifically objective 3.6,

7
00:00:15.990 --> 00:00:18.210
which states that, given a scenario,

8
00:00:18.210 --> 00:00:21.900
you must be able to use automation to secure the enterprise.

9
00:00:21.900 --> 00:00:23.730
Integrated security and automation

10
00:00:23.730 --> 00:00:25.290
are critical to maintaining

11
00:00:25.290 --> 00:00:28.410
a proactive and efficient security posture.

12
00:00:28.410 --> 00:00:30.120
By automating tasks,

13
00:00:30.120 --> 00:00:32.760
such as patching and vulnerability management,

14
00:00:32.760 --> 00:00:35.940
organizations can swiftly address security gaps,

15
00:00:35.940 --> 00:00:38.250
reducing the likelihood of breaches.

16
00:00:38.250 --> 00:00:41.430
Furthermore, implementing dynamic security controls

17
00:00:41.430 --> 00:00:45.240
allows for real-time adaptation to emerging threats,

18
00:00:45.240 --> 00:00:48.090
ensuring continuous protection across the network.

19
00:00:48.090 --> 00:00:50.160
Lastly, cloud automation

20
00:00:50.160 --> 00:00:53.520
combined with the use of application programming interfaces

21
00:00:53.520 --> 00:00:55.500
and software development kits

22
00:00:55.500 --> 00:00:58.080
simplifies the management and security

23
00:00:58.080 --> 00:01:01.260
of complex distributed cloud environments,

24
00:01:01.260 --> 00:01:02.970
making it easier to maintain

25
00:01:02.970 --> 00:01:05.490
robust security measures at scale.

26
00:01:05.490 --> 00:01:07.230
As we go through this section,

27
00:01:07.230 --> 00:01:08.850
we will cover many topics

28
00:01:08.850 --> 00:01:11.970
related to integrated security and automation,

29
00:01:11.970 --> 00:01:14.610
including configuration files,

30
00:01:14.610 --> 00:01:17.940
automated patching, dynamic security controls,

31
00:01:17.940 --> 00:01:20.880
security orchestration, automation, and response,

32
00:01:20.880 --> 00:01:23.100
or SOAR, cloud automation,

33
00:01:23.100 --> 00:01:25.860
cloud application programming interfaces,

34
00:01:25.860 --> 00:01:29.490
software development kits, vulnerability management,

35
00:01:29.490 --> 00:01:32.640
and the Security Content Automation Protocol.

36
00:01:32.640 --> 00:01:36.090
First, we will look at configuration files.

37
00:01:36.090 --> 00:01:39.720
Configuration files in integrated security and automation

38
00:01:39.720 --> 00:01:43.170
are essential for defining the settings and parameters

39
00:01:43.170 --> 00:01:45.630
that guide the automated processes

40
00:01:45.630 --> 00:01:48.810
and security controls within the environment.

41
00:01:48.810 --> 00:01:51.600
Configuration file formats include

42
00:01:51.600 --> 00:01:54.480
Yet Another Markup Language, or YAML,

43
00:01:54.480 --> 00:01:57.540
the Extensible Markup Language, or XML,

44
00:01:57.540 --> 00:02:01.020
JavaScript Object Notation, or JSON,

45
00:02:01.020 --> 00:02:04.560
and Tom's Obvious Minimal Language, or TOML.

46
00:02:04.560 --> 00:02:06.720
These language formats are used

47
00:02:06.720 --> 00:02:08.760
to structure configuration files,

48
00:02:08.760 --> 00:02:12.210
and each has its own syntax and use cases.

49
00:02:12.210 --> 00:02:15.060
YAML is often favored for its readability

50
00:02:15.060 --> 00:02:17.040
in complex configurations.

51
00:02:17.040 --> 00:02:20.970
XML is used for its strict hierarchal structure.

52
00:02:20.970 --> 00:02:25.140
JSON is lightweight and commonly used for data exchange,

53
00:02:25.140 --> 00:02:29.250
and TOML is designed to be easy to read and simple to write.

54
00:02:29.250 --> 00:02:30.930
In an enterprise environment,

55
00:02:30.930 --> 00:02:33.090
different configuration file formats

56
00:02:33.090 --> 00:02:35.220
might be used for various components

57
00:02:35.220 --> 00:02:37.980
to optimize readability and functionality.

58
00:02:37.980 --> 00:02:39.840
For instance, YAML could be used

59
00:02:39.840 --> 00:02:42.780
to define the deployment settings for an application,

60
00:02:42.780 --> 00:02:45.450
specifying the resources, services,

61
00:02:45.450 --> 00:02:47.700
and security groups that need to be provisioned

62
00:02:47.700 --> 00:02:49.320
in a cloud infrastructure.

63
00:02:49.320 --> 00:02:53.370
An XML file might be employed to configure a web service

64
00:02:53.370 --> 00:02:55.440
outlining the security policies,

65
00:02:55.440 --> 00:02:58.740
user authentication protocols, and access controls

66
00:02:58.740 --> 00:03:01.260
in a structured hierarchical format.

67
00:03:01.260 --> 00:03:03.420
JSON could be used to manage

68
00:03:03.420 --> 00:03:06.300
application programming interface responses,

69
00:03:06.300 --> 00:03:10.500
enabling seamless data interchange between services

70
00:03:10.500 --> 00:03:12.540
by structuring data in a lightweight

71
00:03:12.540 --> 00:03:14.790
and easily parseable format.

72
00:03:14.790 --> 00:03:16.800
Meanwhile, TOML could be used

73
00:03:16.800 --> 00:03:19.230
for configuring a monitoring tool,

74
00:03:19.230 --> 00:03:22.920
setting parameters like log file paths, alert thresholds,

75
00:03:22.920 --> 00:03:24.750
and reporting intervals.

76
00:03:24.750 --> 00:03:28.170
Next, we will explore automated patching.

77
00:03:28.170 --> 00:03:29.940
Automated patching is the process

78
00:03:29.940 --> 00:03:32.790
of automatically applying software updates

79
00:03:32.790 --> 00:03:35.790
and security patches to systems and applications

80
00:03:35.790 --> 00:03:38.100
without manual intervention.

81
00:03:38.100 --> 00:03:40.230
Automated patching involves scheduling

82
00:03:40.230 --> 00:03:43.710
or triggering updates based on predefined criteria

83
00:03:43.710 --> 00:03:46.500
such as the severity of a vulnerability

84
00:03:46.500 --> 00:03:48.750
or a predefined maintenance window.

85
00:03:48.750 --> 00:03:50.130
Scheduling and triggering

86
00:03:50.130 --> 00:03:53.040
ensure that network disruptions are minimized

87
00:03:53.040 --> 00:03:56.250
and that organizations stay ahead of potential threats

88
00:03:56.250 --> 00:03:59.460
by ensuring all systems are consistently updated

89
00:03:59.460 --> 00:04:01.800
with the latest security fixes.

90
00:04:01.800 --> 00:04:05.310
For example, an organization might use automated patching

91
00:04:05.310 --> 00:04:07.770
to deploy critical security updates

92
00:04:07.770 --> 00:04:10.290
across its server fleet overnight,

93
00:04:10.290 --> 00:04:12.930
ensuring that vulnerabilities are patched properly

94
00:04:12.930 --> 00:04:15.300
without waiting for manual approval

95
00:04:15.300 --> 00:04:19.050
or risking exposure in downtime during business hours.

96
00:04:19.050 --> 00:04:22.680
After that, we will look at dynamic security controls.

97
00:04:22.680 --> 00:04:25.590
Dynamic security controls are adaptive measures

98
00:04:25.590 --> 00:04:28.320
that automatically adjust security settings

99
00:04:28.320 --> 00:04:32.400
in response to changing conditions or detected threats

100
00:04:32.400 --> 00:04:35.010
in order to maintain continuous protection.

101
00:04:35.010 --> 00:04:38.640
Dynamic security controls include event-based triggers

102
00:04:38.640 --> 00:04:40.650
and auto-containment.

103
00:04:40.650 --> 00:04:44.190
Event-based triggers are specific conditions or incidents

104
00:04:44.190 --> 00:04:46.830
such as a detected malware signature

105
00:04:46.830 --> 00:04:48.870
or an unusual network pattern.

106
00:04:48.870 --> 00:04:50.880
These conditions or incidents

107
00:04:50.880 --> 00:04:53.460
activate dynamic security controls,

108
00:04:53.460 --> 00:04:57.360
initiating automated responses to these emerging threats.

109
00:04:57.360 --> 00:04:59.640
Auto-containment is the process where

110
00:04:59.640 --> 00:05:03.450
potentially harmful activities or suspicious entities

111
00:05:03.450 --> 00:05:06.810
are automatically isolated from the rest of the network

112
00:05:06.810 --> 00:05:09.300
to prevent the spread of infection.

113
00:05:09.300 --> 00:05:12.960
Auto-containment allows for further analysis and remediation

114
00:05:12.960 --> 00:05:15.000
of suspicious indicators.

115
00:05:15.000 --> 00:05:18.000
For example, if a security system detects

116
00:05:18.000 --> 00:05:22.350
unusual traffic patterns indicative of a potential attack,

117
00:05:22.350 --> 00:05:24.840
an event-based trigger could activate

118
00:05:24.840 --> 00:05:28.800
auto-containment measures to isolate the affected device,

119
00:05:28.800 --> 00:05:30.540
preventing the threat from spreading

120
00:05:30.540 --> 00:05:33.660
while security teams investigate the incident.

121
00:05:33.660 --> 00:05:35.550
Next, we will explore

122
00:05:35.550 --> 00:05:40.050
security orchestration, automation, and response, or SOAR,

123
00:05:40.050 --> 00:05:43.620
Security orchestration, automation, and response platforms

124
00:05:43.620 --> 00:05:46.440
include a suite of tools and processes

125
00:05:46.440 --> 00:05:49.440
that streamline and automate security operations,

126
00:05:49.440 --> 00:05:52.920
enabling organizations to detect, respond to,

127
00:05:52.920 --> 00:05:55.350
and mitigate threats more efficiently.

128
00:05:55.350 --> 00:05:59.070
Security orchestration automation and response platforms

129
00:05:59.070 --> 00:06:02.970
may integrate with security information and event,

130
00:06:02.970 --> 00:06:06.360
or SIM systems, to efficiently analyze

131
00:06:06.360 --> 00:06:09.090
security data from various sources,

132
00:06:09.090 --> 00:06:13.500
allowing for a centralized view of threats and incidents.

133
00:06:13.500 --> 00:06:16.530
Security orchestration, automation, and response

134
00:06:16.530 --> 00:06:19.050
platform implementation concepts

135
00:06:19.050 --> 00:06:21.720
include playbooks and runbooks.

136
00:06:21.720 --> 00:06:24.180
Playbooks are predefined workflows,

137
00:06:24.180 --> 00:06:27.120
typically outlined in incident response plans

138
00:06:27.120 --> 00:06:28.860
that detail steps to be taken

139
00:06:28.860 --> 00:06:32.070
in response to specific types of security events.

140
00:06:32.070 --> 00:06:36.690
Runbooks execute these playbook workflows step by step,

141
00:06:36.690 --> 00:06:40.470
incorporating automation to efficiently carry out the tasks.

142
00:06:40.470 --> 00:06:42.180
As a security orchestration,

143
00:06:42.180 --> 00:06:45.750
automation, and response platform executes a runbook.

144
00:06:45.750 --> 00:06:48.390
It may pause at predefined steps

145
00:06:48.390 --> 00:06:51.450
to wait for human intervention before proceeding.

146
00:06:51.450 --> 00:06:53.640
Additionally, a security orchestration,

147
00:06:53.640 --> 00:06:55.800
automation, and response platform

148
00:06:55.800 --> 00:06:59.070
can leverage machine learning and artificial intelligence

149
00:06:59.070 --> 00:07:01.320
to enhance detection accuracy,

150
00:07:01.320 --> 00:07:03.090
predict potential threats,

151
00:07:03.090 --> 00:07:05.460
and optimize response actions,

152
00:07:05.460 --> 00:07:08.340
further improving the efficiency and effectiveness

153
00:07:08.340 --> 00:07:10.080
of the security operations.

154
00:07:10.080 --> 00:07:12.450
In practice, when a security information

155
00:07:12.450 --> 00:07:14.100
and event management system

156
00:07:14.100 --> 00:07:16.170
detects a potential phishing attack,

157
00:07:16.170 --> 00:07:19.770
the security orchestration automation and response platform

158
00:07:19.770 --> 00:07:23.580
might automatically trigger a playbook that uses a runbook

159
00:07:23.580 --> 00:07:26.100
to isolate the affected email account,

160
00:07:26.100 --> 00:07:27.750
scan for further threats,

161
00:07:27.750 --> 00:07:30.000
and notify the security team,

162
00:07:30.000 --> 00:07:31.830
all while documenting the incident

163
00:07:31.830 --> 00:07:34.140
for compliance and analysis.

164
00:07:34.140 --> 00:07:37.950
Following that, we will look at cloud automation.

165
00:07:37.950 --> 00:07:40.740
Cloud automation uses tools and processes

166
00:07:40.740 --> 00:07:44.040
to manage, deploy, and secure cloud resources,

167
00:07:44.040 --> 00:07:46.140
and applications efficiently.

168
00:07:46.140 --> 00:07:48.300
Cloud automation concepts include

169
00:07:48.300 --> 00:07:51.510
containerization and infrastructure as code.

170
00:07:51.510 --> 00:07:52.980
Let's take a minute to discuss

171
00:07:52.980 --> 00:07:55.320
each of these in further detail.

172
00:07:55.320 --> 00:07:57.630
Containerization allows applications

173
00:07:57.630 --> 00:07:59.940
to be packaged with their dependencies

174
00:07:59.940 --> 00:08:02.730
into isolated units called containers.

175
00:08:02.730 --> 00:08:05.970
Containerization ensures execution consistency

176
00:08:05.970 --> 00:08:07.680
across different environments,

177
00:08:07.680 --> 00:08:10.500
which is essential for maintaining security

178
00:08:10.500 --> 00:08:13.260
and reducing vulnerabilities during deployment.

179
00:08:13.260 --> 00:08:15.900
Next, infrastructure as code

180
00:08:15.900 --> 00:08:19.110
is a practice where infrastructure configurations

181
00:08:19.110 --> 00:08:21.990
are defined and managed through code.

182
00:08:21.990 --> 00:08:23.850
Infrastructure as code enables

183
00:08:23.850 --> 00:08:26.940
automated, consistent, and repeatable deployments

184
00:08:26.940 --> 00:08:28.440
of cloud resources,

185
00:08:28.440 --> 00:08:31.650
which enhances security by reducing human error

186
00:08:31.650 --> 00:08:34.080
and enabling simple version control.

187
00:08:34.080 --> 00:08:36.120
For example, an organization

188
00:08:36.120 --> 00:08:38.280
might use infrastructure as code

189
00:08:38.280 --> 00:08:42.450
with tools like Terraform or AWS CloudFormation

190
00:08:42.450 --> 00:08:46.050
to automate the deployment of a containerized application

191
00:08:46.050 --> 00:08:49.650
using a containerization engine, such as Docker,

192
00:08:49.650 --> 00:08:52.230
across multiple cloud environments.

193
00:08:52.230 --> 00:08:54.330
This ensures that each container,

194
00:08:54.330 --> 00:08:57.330
regardless of the cloud provider it exists on,

195
00:08:57.330 --> 00:09:01.020
is consistently configured with the same security settings,

196
00:09:01.020 --> 00:09:05.700
network policies, access controls, and encryption standards.

197
00:09:05.700 --> 00:09:08.730
By automating the entire deployment process,

198
00:09:08.730 --> 00:09:11.850
an organization can quickly scale the application

199
00:09:11.850 --> 00:09:14.820
while maintaining strict security compliance

200
00:09:14.820 --> 00:09:17.820
and minimizing the risk of configuration drift

201
00:09:17.820 --> 00:09:19.140
or human error.

202
00:09:19.140 --> 00:09:22.110
Then we will explore cloud application

203
00:09:22.110 --> 00:09:26.160
programming interfaces and software development kits.

204
00:09:26.160 --> 00:09:29.070
Cloud application programming interfaces

205
00:09:29.070 --> 00:09:31.980
and software development kits enable developers

206
00:09:31.980 --> 00:09:35.220
to interact with cloud services programmatically.

207
00:09:35.220 --> 00:09:36.540
Programmatic interaction

208
00:09:36.540 --> 00:09:40.260
enables the automation and integration of security controls

209
00:09:40.260 --> 00:09:42.420
directly into applications

210
00:09:42.420 --> 00:09:44.520
through functions such as webhooks.

211
00:09:44.520 --> 00:09:47.820
Webhooks are user-defined callbacks

212
00:09:47.820 --> 00:09:50.490
that trigger automated workflows or actions

213
00:09:50.490 --> 00:09:54.960
in response to specific events within the cloud environment.

214
00:09:54.960 --> 00:09:58.680
Webhooks prompt real-time communication between services.

215
00:09:58.680 --> 00:10:00.900
Use cases for these webhooks include

216
00:10:00.900 --> 00:10:02.670
automating security alerts,

217
00:10:02.670 --> 00:10:04.140
provisioning resources,

218
00:10:04.140 --> 00:10:06.810
or triggering incident response processes

219
00:10:06.810 --> 00:10:09.330
based on predefined conditions.

220
00:10:09.330 --> 00:10:11.820
For example, a webhook could be set up

221
00:10:11.820 --> 00:10:14.430
to automatically trigger a security scan

222
00:10:14.430 --> 00:10:16.800
whenever a new instance is deployed

223
00:10:16.800 --> 00:10:19.710
via a cloud application programming interface,

224
00:10:19.710 --> 00:10:21.690
ensuring that all new resources

225
00:10:21.690 --> 00:10:24.240
are immediately checked for vulnerabilities

226
00:10:24.240 --> 00:10:26.940
and compliance with security policies.

227
00:10:26.940 --> 00:10:30.150
Next, we will look at vulnerability management.

228
00:10:30.150 --> 00:10:33.090
Vulnerability management is the continuous process

229
00:10:33.090 --> 00:10:35.160
of identifying, assessing,

230
00:10:35.160 --> 00:10:37.740
and mitigating security vulnerabilities

231
00:10:37.740 --> 00:10:41.160
within an organization systems and applications.

232
00:10:41.160 --> 00:10:44.070
Vulnerability management concepts include

233
00:10:44.070 --> 00:10:48.720
the Security Content Automation Protocol, or SCAP framework,

234
00:10:48.720 --> 00:10:53.070
and its associated Common Platform Enumeration, or CPE,

235
00:10:53.070 --> 00:10:56.400
Common Vulnerabilities and Exposures, or CVE

236
00:10:56.400 --> 00:11:00.720
and Common Vulnerability Scoring System, or CVSS tool.

237
00:11:00.720 --> 00:11:04.020
The Security Content Automation Protocol framework

238
00:11:04.020 --> 00:11:06.810
standardizes the format and nomenclature

239
00:11:06.810 --> 00:11:09.600
for managing and communicating vulnerabilities.

240
00:11:09.600 --> 00:11:13.560
Within the Security Content Automation Protocol framework,

241
00:11:13.560 --> 00:11:16.860
Common Platform Enumeration, or CPE,

242
00:11:16.860 --> 00:11:20.490
provides a standardized way to identify applications,

243
00:11:20.490 --> 00:11:22.710
operating systems, and hardware,

244
00:11:22.710 --> 00:11:26.640
while Common Vulnerabilities and Exposures, or CVEs,

245
00:11:26.640 --> 00:11:30.840
offer a unique identifier for each known vulnerability.

246
00:11:30.840 --> 00:11:34.350
Additionally, the Common Vulnerabilities Scoring System,

247
00:11:34.350 --> 00:11:37.590
or CVSS, is used to assess the severity

248
00:11:37.590 --> 00:11:39.510
of identified vulnerabilities,

249
00:11:39.510 --> 00:11:43.230
enabling organizations to prioritize their response

250
00:11:43.230 --> 00:11:46.200
based on the potential vulnerability impact.

251
00:11:46.200 --> 00:11:50.880
For example, a vulnerability management tool like tenable.io

252
00:11:50.880 --> 00:11:55.680
might use common platform to identify specific versions

253
00:11:55.680 --> 00:11:58.320
of operating systems, applications,

254
00:11:58.320 --> 00:12:02.310
and hardware in an organization's IT environment.

255
00:12:02.310 --> 00:12:03.840
It could then cross-reference

256
00:12:03.840 --> 00:12:06.570
these common platform enumeration identifiers

257
00:12:06.570 --> 00:12:08.400
with the CVE database

258
00:12:08.400 --> 00:12:10.530
to detect known vulnerabilities

259
00:12:10.530 --> 00:12:12.660
associated with each component.

260
00:12:12.660 --> 00:12:15.150
In this manner, the tool might identify

261
00:12:15.150 --> 00:12:18.090
a critical buffer overflow vulnerability

262
00:12:18.090 --> 00:12:20.610
in a specific version of a web server,

263
00:12:20.610 --> 00:12:24.120
as well as other vulnerabilities within the infrastructure.

264
00:12:24.120 --> 00:12:26.250
Tenable.io could then apply

265
00:12:26.250 --> 00:12:29.520
Common Vulnerabilities Scoring Systems scores

266
00:12:29.520 --> 00:12:32.280
to the vulnerabilities based on factors

267
00:12:32.280 --> 00:12:34.980
such as exploitability and impact.

268
00:12:34.980 --> 00:12:38.340
This process would enable the organization's security team

269
00:12:38.340 --> 00:12:40.350
to prioritize patching efforts,

270
00:12:40.350 --> 00:12:43.860
focusing first on the vulnerabilities with the highest

271
00:12:43.860 --> 00:12:46.800
Common Vulnerabilities Scoring Systems scores

272
00:12:46.800 --> 00:12:50.340
to mitigate the most significant risks first.

273
00:12:50.340 --> 00:12:52.320
Finally, we will explore

274
00:12:52.320 --> 00:12:56.100
the Security Content Automation Protocol, or SCAP.

275
00:12:56.100 --> 00:12:59.070
The Security Content Automation Protocol framework

276
00:12:59.070 --> 00:13:02.160
standardizes the format and exchange of information

277
00:13:02.160 --> 00:13:04.320
related to security vulnerabilities,

278
00:13:04.320 --> 00:13:07.110
configurations, and compliance.

279
00:13:07.110 --> 00:13:09.540
Security Content Automation Protocol

280
00:13:09.540 --> 00:13:13.020
enables automated and consistent security management.

281
00:13:13.020 --> 00:13:15.990
Security Content Automation Protocol components

282
00:13:15.990 --> 00:13:19.770
include the Open Vulnerability and Assessment Language,

283
00:13:19.770 --> 00:13:20.700
or OVAL,

284
00:13:20.700 --> 00:13:22.800
and the Extensible Configuration

285
00:13:22.800 --> 00:13:27.000
Checklist Description Format, or XCCDF.

286
00:13:27.000 --> 00:13:29.580
The Open Vulnerability and Assessment Language

287
00:13:29.580 --> 00:13:33.180
is a security content automation protocol component

288
00:13:33.180 --> 00:13:35.550
that provides a standardized language

289
00:13:35.550 --> 00:13:38.040
for encoding security advisories.

290
00:13:38.040 --> 00:13:40.770
The Open Vulnerability and Assessment Language

291
00:13:40.770 --> 00:13:43.650
enables automated vulnerability assessments

292
00:13:43.650 --> 00:13:45.390
and compliance checking.

293
00:13:45.390 --> 00:13:48.990
the Extensible Configuration Checklist Description Format,

294
00:13:48.990 --> 00:13:50.880
or XCCDF,

295
00:13:50.880 --> 00:13:54.510
is a Security Content Automation Protocol component

296
00:13:54.510 --> 00:13:56.820
that defines security checklists

297
00:13:56.820 --> 00:14:00.780
and configuration settings in a machine-readable format.

298
00:14:00.780 --> 00:14:04.350
The Extensible Configuration Checklist Description Format

299
00:14:04.350 --> 00:14:07.800
permits automated policy enforcement and auditing.

300
00:14:07.800 --> 00:14:10.530
For example, an organization might use

301
00:14:10.530 --> 00:14:13.770
Security Content Automation Protocol tools

302
00:14:13.770 --> 00:14:15.300
to automate the process

303
00:14:15.300 --> 00:14:18.450
of scanning its systems for vulnerabilities using

304
00:14:18.450 --> 00:14:21.900
Open Vulnerability and Assessment Language definitions,

305
00:14:21.900 --> 00:14:24.540
then apply Extensible Configuration

306
00:14:24.540 --> 00:14:27.090
Checklist Description Format checklists

307
00:14:27.090 --> 00:14:30.120
to ensure compliance with internal security policies

308
00:14:30.120 --> 00:14:31.860
and industry regulations,

309
00:14:31.860 --> 00:14:35.130
ultimately streamlining the entire security assessment

310
00:14:35.130 --> 00:14:37.170
and remediation process.

311
00:14:37.170 --> 00:14:40.140
To finish things off, we'll take a short quiz

312
00:14:40.140 --> 00:14:43.110
to see what you learned during this section of the course,

313
00:14:43.110 --> 00:14:46.650
and we will review each of those quiz questions fully

314
00:14:46.650 --> 00:14:49.620
to ensure you can explain why the right answers were right

315
00:14:49.620 --> 00:14:51.390
and the wrong answers were wrong.

316
00:14:51.390 --> 00:14:54.000
So let's get ready to dive into

317
00:14:54.000 --> 00:14:56.400
integrated security and automation

318
00:14:56.400 --> 00:14:58.563
in this section of the course.