WEBVTT

1
00:00:00.110 --> 00:00:01.440
In this lesson,

2
00:00:01.440 --> 00:00:04.650
we will learn about development and deployment.

3
00:00:04.650 --> 00:00:08.640
Development and deployment involves creating, configuring,

4
00:00:08.640 --> 00:00:13.140
and releasing cloud-based applications and infrastructure.

5
00:00:13.140 --> 00:00:15.720
Development and deployment should ensure

6
00:00:15.720 --> 00:00:19.080
that security best practices are integrated

7
00:00:19.080 --> 00:00:21.870
throughout the entire process.

8
00:00:21.870 --> 00:00:25.140
Development and deployment includes tools,

9
00:00:25.140 --> 00:00:27.491
such as Terraform and Ansible,

10
00:00:27.491 --> 00:00:31.650
as well as concepts such as package monitoring.

11
00:00:31.650 --> 00:00:36.259
Terraform is an infrastructure as code, or IaC, tool,

12
00:00:36.259 --> 00:00:40.470
automating the provisioning of cloud infrastructure.

13
00:00:40.470 --> 00:00:42.960
Ansible is another automation tool

14
00:00:42.960 --> 00:00:46.020
that focuses on configuration management,

15
00:00:46.020 --> 00:00:49.740
application deployment, and task automation.

16
00:00:49.740 --> 00:00:53.070
Finally, package monitoring involves tracking

17
00:00:53.070 --> 00:00:56.051
and analyzing the security and integrity

18
00:00:56.051 --> 00:01:01.051
of software packages and dependencies used in development

19
00:01:01.590 --> 00:01:05.370
to prevent vulnerabilities from being introduced

20
00:01:05.370 --> 00:01:07.110
during deployment.

21
00:01:07.110 --> 00:01:10.470
Let's learn more about Terraform, Ansible,

22
00:01:10.470 --> 00:01:12.360
and package monitoring.

23
00:01:12.360 --> 00:01:14.850
First, we have Terraform.

24
00:01:14.850 --> 00:01:19.500
Terraform is an infrastructure as code, or IaC, tool

25
00:01:19.500 --> 00:01:21.450
that automates the provisioning

26
00:01:21.450 --> 00:01:24.420
and management of cloud infrastructure.

27
00:01:24.420 --> 00:01:27.930
By writing code to define infrastructure,

28
00:01:27.930 --> 00:01:31.161
Terraform allows teams to create, update,

29
00:01:31.161 --> 00:01:35.014
and manage resources like servers, databases,

30
00:01:35.014 --> 00:01:37.590
and networking components.

31
00:01:37.590 --> 00:01:42.090
For example, a development team might use Terraform

32
00:01:42.090 --> 00:01:46.334
to define and deploy a secure virtual private cloud,

33
00:01:46.334 --> 00:01:50.430
including setting up subnets, security groups,

34
00:01:50.430 --> 00:01:52.830
and access control lists.

35
00:01:52.830 --> 00:01:56.700
By using a version-controlled configuration file,

36
00:01:56.700 --> 00:02:00.840
the team could ensure that every environment, development,

37
00:02:00.840 --> 00:02:05.280
staging, and production follows the same security policies

38
00:02:05.280 --> 00:02:06.900
and network structure,

39
00:02:06.900 --> 00:02:10.470
reducing the risk of misconfigurations.

40
00:02:10.470 --> 00:02:14.730
Another key advantage of Terraform is its ability

41
00:02:14.730 --> 00:02:17.910
to work across multiple cloud providers,

42
00:02:17.910 --> 00:02:22.910
such as Amazon Web Services, or AWS, Microsoft Azure,

43
00:02:23.425 --> 00:02:28.020
and Google Cloud Platform, or GCP.

44
00:02:28.020 --> 00:02:32.220
This means that an organization can manage complex

45
00:02:32.220 --> 00:02:36.660
multi-cloud environments from a single code base.

46
00:02:36.660 --> 00:02:40.050
Terraform also has a feature called state

47
00:02:40.050 --> 00:02:44.340
that tracks the real-time state of deployed resources,

48
00:02:44.340 --> 00:02:46.800
ensuring that any changes made

49
00:02:46.800 --> 00:02:49.230
to the infrastructure are deliberate

50
00:02:49.230 --> 00:02:52.860
and in line with the defined configuration.

51
00:02:52.860 --> 00:02:57.540
For instance, if a security setting is accidentally modified

52
00:02:57.540 --> 00:03:01.044
in the cloud, Terraform can detect this drift

53
00:03:01.044 --> 00:03:03.450
and help return the infrastructure

54
00:03:03.450 --> 00:03:06.540
to its intended and secure state.

55
00:03:06.540 --> 00:03:09.480
Second, we have Ansible.

56
00:03:09.480 --> 00:03:11.490
Ansible is an automation tool

57
00:03:11.490 --> 00:03:14.970
that focuses on configuration management,

58
00:03:14.970 --> 00:03:16.980
application deployment,

59
00:03:16.980 --> 00:03:21.450
and task automation across cloud environments.

60
00:03:21.450 --> 00:03:25.500
Unlike Terraform, which provisions infrastructure,

61
00:03:25.500 --> 00:03:27.690
Ansible is used to configure

62
00:03:27.690 --> 00:03:32.580
and manage the applications running on that infrastructure.

63
00:03:32.580 --> 00:03:35.730
For example, after using Terraform

64
00:03:35.730 --> 00:03:40.170
to set up a virtual machine, the team could use Ansible

65
00:03:40.170 --> 00:03:44.760
and an Ansible playbook to install security patches,

66
00:03:44.760 --> 00:03:49.320
configure firewalls, and deploy necessary software.

67
00:03:49.320 --> 00:03:54.320
Ansible operates using playbooks which are simple YAML,

68
00:03:54.330 --> 00:03:57.450
or Yet Another Markup Language, files

69
00:03:57.450 --> 00:04:02.010
that describe the tasks to be executed, making them easy

70
00:04:02.010 --> 00:04:07.010
to read, write, and manage automation processes with.

71
00:04:07.080 --> 00:04:11.880
One of Ansible's strengths is its agentless architecture,

72
00:04:11.880 --> 00:04:15.780
meaning Ansible does not require any special software

73
00:04:15.780 --> 00:04:18.990
to be installed on the servers it manages.

74
00:04:18.990 --> 00:04:23.790
Instead, Ansible uses secure connections like Secure Shell,

75
00:04:23.790 --> 00:04:27.630
or SSH, to communicate with systems,

76
00:04:27.630 --> 00:04:29.100
making it lightweight

77
00:04:29.100 --> 00:04:33.330
and easy to integrate into existing environments.

78
00:04:33.330 --> 00:04:37.200
For example, if an organization needs to ensure

79
00:04:37.200 --> 00:04:40.350
that all servers have the latest version

80
00:04:40.350 --> 00:04:45.120
of a web server package with secure configuration settings,

81
00:04:45.120 --> 00:04:46.860
they can write a playbook

82
00:04:46.860 --> 00:04:49.620
that applies these changes across hundreds

83
00:04:49.620 --> 00:04:51.990
of servers simultaneously.

84
00:04:51.990 --> 00:04:54.000
This ensures consistency

85
00:04:54.000 --> 00:04:58.770
and helps avoid configuration drift, enhancing the security

86
00:04:58.770 --> 00:05:02.880
and reliability of cloud-based applications.

87
00:05:02.880 --> 00:05:06.690
Third and last, we have package monitoring.

88
00:05:06.690 --> 00:05:10.170
Package monitoring is the process of tracking

89
00:05:10.170 --> 00:05:12.210
and analyzing the security

90
00:05:12.210 --> 00:05:15.270
and integrity of software packages

91
00:05:15.270 --> 00:05:19.950
and dependencies used in development and deployment.

92
00:05:19.950 --> 00:05:21.180
This is important

93
00:05:21.180 --> 00:05:24.630
because vulnerabilities can be introduced

94
00:05:24.630 --> 00:05:28.170
through outdated or compromised packages,

95
00:05:28.170 --> 00:05:31.290
leading to potential security risks

96
00:05:31.290 --> 00:05:33.900
in the deployed application.

97
00:05:33.900 --> 00:05:37.530
For example, a development team might use

98
00:05:37.530 --> 00:05:42.360
open source libraries to speed up the deployment process,

99
00:05:42.360 --> 00:05:45.600
but if one of those libraries contains

100
00:05:45.600 --> 00:05:47.294
a known vulnerability,

101
00:05:47.294 --> 00:05:51.330
it could expose the application to attacks.

102
00:05:51.330 --> 00:05:55.830
Package monitoring tools like OWASP Dependency-Check

103
00:05:55.830 --> 00:05:59.334
and the Node Package Manager, or npm audit,

104
00:05:59.334 --> 00:06:02.490
regularly scan these dependencies

105
00:06:02.490 --> 00:06:04.950
to ensure that no insecure

106
00:06:04.950 --> 00:06:07.635
or outdated versions are being used

107
00:06:07.635 --> 00:06:10.260
in the deployment pipeline.

108
00:06:10.260 --> 00:06:13.286
To effectively implement package monitoring,

109
00:06:13.286 --> 00:06:17.700
organizations can use tools that automatically scan

110
00:06:17.700 --> 00:06:20.954
and track dependencies for vulnerabilities

111
00:06:20.954 --> 00:06:23.400
and security issues.

112
00:06:23.400 --> 00:06:27.030
OWASP Dependency-Check is a widely used tool

113
00:06:27.030 --> 00:06:29.700
that scans project dependencies

114
00:06:29.700 --> 00:06:32.460
for known vulnerabilities across various

115
00:06:32.460 --> 00:06:34.230
programming languages.

116
00:06:34.230 --> 00:06:38.640
While npm audit focuses on scanning dependencies

117
00:06:38.640 --> 00:06:42.600
in JavaScript and Node.js projects.

118
00:06:42.600 --> 00:06:46.555
By integrating these tools into a continuous integration

119
00:06:46.555 --> 00:06:50.790
pipeline, teams can be notified when vulnerabilities

120
00:06:50.790 --> 00:06:55.140
are found, allowing them to address the issues quickly

121
00:06:55.140 --> 00:06:58.350
and ensure secure software deployment.

122
00:06:58.350 --> 00:07:02.845
This proactive approach helps teams maintain up-to-date

123
00:07:02.845 --> 00:07:07.173
and secure software packages, significantly reducing

124
00:07:07.173 --> 00:07:11.700
the attack surface of cloud-based applications.

125
00:07:11.700 --> 00:07:15.060
Package monitoring is essential in preventing

126
00:07:15.060 --> 00:07:19.770
vulnerabilities from being introduced during development,

127
00:07:19.770 --> 00:07:24.150
and by using tools like the OWASP Dependency-Check

128
00:07:24.150 --> 00:07:29.130
and npm audit, organizations can enhance their security

129
00:07:29.130 --> 00:07:33.090
posture and safeguard their cloud applications.

130
00:07:33.090 --> 00:07:35.430
Now, let's do a demonstration

131
00:07:35.430 --> 00:07:39.240
of the node package manager or npm.

132
00:07:39.240 --> 00:07:40.710
In this demonstration,

133
00:07:40.710 --> 00:07:44.100
I'm using a parrot security operating system

134
00:07:44.100 --> 00:07:48.630
and node.js and npm, the node packet manager,

135
00:07:48.630 --> 00:07:50.550
are already installed.

136
00:07:50.550 --> 00:07:54.720
So the first thing we're going to do is create a directory

137
00:07:54.720 --> 00:07:57.840
to initialize the node packet manager in.

138
00:07:57.840 --> 00:08:00.690
We'll do that with the mkdir command,

139
00:08:00.690 --> 00:08:05.100
and our folder or our directory will be called Demo.

140
00:08:05.100 --> 00:08:08.160
Now let's navigate to that directory.

141
00:08:08.160 --> 00:08:12.420
Then let's initialize npm, the node package manager,

142
00:08:12.420 --> 00:08:14.010
within that directory.

143
00:08:14.010 --> 00:08:15.030
There we go.

144
00:08:15.030 --> 00:08:18.900
Now let's install three different packages

145
00:08:18.900 --> 00:08:21.363
that are known to have vulnerabilities.

146
00:08:22.435 --> 00:08:25.930
We'll do this with npm install lodash@4.17.11.

147
00:08:30.840 --> 00:08:35.237
Npm install express@4.16.0.

148
00:08:38.790 --> 00:08:43.790
And npm install jquery@3.3.0.

149
00:08:46.710 --> 00:08:51.030
Now let's take a look at the packages that are installed.

150
00:08:51.030 --> 00:08:54.030
We'll do this with the npm list command,

151
00:08:54.030 --> 00:08:57.720
and you can see that we have three packages installed.

152
00:08:57.720 --> 00:09:00.030
Let's use the node package manager

153
00:09:00.030 --> 00:09:03.150
or npm audit to scan for vulnerabilities

154
00:09:03.150 --> 00:09:05.460
in these installed packages.

155
00:09:05.460 --> 00:09:08.580
As you can see, there are 45 vulnerabilities

156
00:09:08.580 --> 00:09:11.880
that are discovered, two low level vulnerabilities,

157
00:09:11.880 --> 00:09:16.500
13 moderate, 23 high, and seven critical.

158
00:09:16.500 --> 00:09:18.510
We can look through some of the details

159
00:09:18.510 --> 00:09:23.190
of these vulnerabilities in the command line output above.

160
00:09:23.190 --> 00:09:26.370
You can see that npm, the node package manager,

161
00:09:26.370 --> 00:09:28.890
also sometimes suggests fixes

162
00:09:28.890 --> 00:09:31.260
such as upgrading to a secure version

163
00:09:31.260 --> 00:09:33.090
of the vulnerable package.

164
00:09:33.090 --> 00:09:35.310
Also, at the end it says to address

165
00:09:35.310 --> 00:09:37.650
all of these issues all at once,

166
00:09:37.650 --> 00:09:40.980
just use the npm audit fix command.

167
00:09:40.980 --> 00:09:42.720
Let's go ahead and try that.

168
00:09:42.720 --> 00:09:45.750
It's going through and fixing everything that it can.

169
00:09:45.750 --> 00:09:49.080
Now, let's take a look at that npm audit again

170
00:09:49.080 --> 00:09:52.500
and see if it fixed all the vulnerabilities, and it did.

171
00:09:52.500 --> 00:09:54.210
It fixed all vulnerabilities

172
00:09:54.210 --> 00:09:57.390
and is now finding zero vulnerabilities.

173
00:09:57.390 --> 00:10:00.750
For more complex issues, we would need to manually review

174
00:10:00.750 --> 00:10:04.230
and update dependencies to resolve the vulnerabilities.

175
00:10:04.230 --> 00:10:08.537
And in a real world scenario, we would integrate npm audit

176
00:10:08.537 --> 00:10:13.158
or similar tools into a continuous integration pipeline.

177
00:10:13.158 --> 00:10:15.697
This would ensure that package monitoring

178
00:10:15.697 --> 00:10:19.777
happens automatically during every build or deployment,

179
00:10:19.777 --> 00:10:24.390
preventing vulnerable packages from being introduced.

180
00:10:24.390 --> 00:10:27.420
And this is the end of our demonstration.

181
00:10:27.420 --> 00:10:32.420
So remember, development and deployment involve building,

182
00:10:32.820 --> 00:10:36.540
configuring, and releasing cloud-based applications

183
00:10:36.540 --> 00:10:38.040
and infrastructure

184
00:10:38.040 --> 00:10:42.420
with security integrated throughout the entire process.

185
00:10:42.420 --> 00:10:46.320
Tools like Terraform and Ansible play a key role

186
00:10:46.320 --> 00:10:48.690
in automating these tasks,

187
00:10:48.690 --> 00:10:51.900
where Terraform helps automate the provisioning

188
00:10:51.900 --> 00:10:54.206
of cloud infrastructure by defining

189
00:10:54.206 --> 00:10:57.177
and managing resources through code,

190
00:10:57.177 --> 00:11:01.350
ensuring consistency across environments.

191
00:11:01.350 --> 00:11:04.078
And Ansible focuses on configuring

192
00:11:04.078 --> 00:11:07.260
and managing the applications running

193
00:11:07.260 --> 00:11:09.210
on that infrastructure,

194
00:11:09.210 --> 00:11:12.270
allowing for easy automation of tasks

195
00:11:12.270 --> 00:11:16.140
like software updates and security patches.

196
00:11:16.140 --> 00:11:18.480
Last, package monitoring.

197
00:11:18.480 --> 00:11:21.990
Using tools like the OWASP Dependency-Check

198
00:11:21.990 --> 00:11:25.726
and the Node Package Manager, or npm audit,

199
00:11:25.726 --> 00:11:29.097
ensure the security of software dependencies

200
00:11:29.097 --> 00:11:32.318
by tracking vulnerabilities in packages,

201
00:11:32.318 --> 00:11:35.850
helping organizations keep their applications

202
00:11:35.850 --> 00:11:38.373
secure and up-to-date.

