WEBVTT

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

2
00:00:01.440 --> 00:00:04.710
we will learn about Integrity Use Cases.

3
00:00:04.710 --> 00:00:08.790
Use cases related to integrity involve maintaining

4
00:00:08.790 --> 00:00:12.150
the accuracy and trustworthiness of data,

5
00:00:12.150 --> 00:00:17.100
or software to ensure its functionality and security.

6
00:00:17.100 --> 00:00:22.050
Specific use cases include knowing the software provenance,

7
00:00:22.050 --> 00:00:25.470
as well as software and code integrity.

8
00:00:25.470 --> 00:00:29.400
Software provenance ensures the origin and history

9
00:00:29.400 --> 00:00:33.240
of software components are known and secure.

10
00:00:33.240 --> 00:00:36.630
Software and code integrity ensures that software

11
00:00:36.630 --> 00:00:39.990
and code have not been altered from their original

12
00:00:39.990 --> 00:00:41.460
and trusted state.

13
00:00:41.460 --> 00:00:44.070
Let's learn more about software provenance

14
00:00:44.070 --> 00:00:47.280
as well as software and code integrity.

15
00:00:47.280 --> 00:00:50.670
First, we have software provenance.

16
00:00:50.670 --> 00:00:54.900
Software provenance is all about understanding the origin

17
00:00:54.900 --> 00:00:58.170
and history of software components used

18
00:00:58.170 --> 00:01:00.540
within an organization.

19
00:01:00.540 --> 00:01:04.350
Software provenance answers critical questions like,

20
00:01:04.350 --> 00:01:08.430
where did this software come from and can I trust it?

21
00:01:08.430 --> 00:01:10.680
This involves knowing exactly

22
00:01:10.680 --> 00:01:14.880
who developed each piece of software, where it originated,

23
00:01:14.880 --> 00:01:17.610
and how it has changed over time.

24
00:01:17.610 --> 00:01:20.940
In an enterprise setting, software provenance

25
00:01:20.940 --> 00:01:24.150
is often managed through version control systems

26
00:01:24.150 --> 00:01:25.470
such as Git.

27
00:01:25.470 --> 00:01:29.370
Git tracks every change made to the code base.

28
00:01:29.370 --> 00:01:33.030
Recording details like what changes were made,

29
00:01:33.030 --> 00:01:35.880
when were they made, and by whom.

30
00:01:35.880 --> 00:01:38.970
This creates a comprehensive history

31
00:01:38.970 --> 00:01:40.950
of the software's development,

32
00:01:40.950 --> 00:01:43.380
allowing organizations to audit

33
00:01:43.380 --> 00:01:47.310
and trace the entire evolution of their code.

34
00:01:47.310 --> 00:01:51.630
Version control not only helps with tracking changes,

35
00:01:51.630 --> 00:01:54.960
but also provides a mechanism to roll back

36
00:01:54.960 --> 00:01:59.700
to previous trusted versions if any issues are detected.

37
00:01:59.700 --> 00:02:03.810
Another critical component of managing software provenance

38
00:02:03.810 --> 00:02:08.100
is the use of a software bill of materials (SBOM).

39
00:02:08.100 --> 00:02:11.130
An SBOM is like a detailed recipe

40
00:02:11.130 --> 00:02:14.910
that lists all the ingredients, components, libraries,

41
00:02:14.910 --> 00:02:18.960
and dependencies that make up a software application.

42
00:02:18.960 --> 00:02:22.560
An SBOM provides a transparent view

43
00:02:22.560 --> 00:02:26.910
of what is inside the software, including third party

44
00:02:26.910 --> 00:02:29.370
and open source components.

45
00:02:29.370 --> 00:02:34.370
Next, Software Composition Analysis (SCA) Solutions

46
00:02:34.380 --> 00:02:39.120
such as Snyk, Black Duck, or WhiteSource can be used

47
00:02:39.120 --> 00:02:43.020
to scan Software Bills of Material to verify

48
00:02:43.020 --> 00:02:47.040
that all components are sourced from trusted origins.

49
00:02:47.040 --> 00:02:51.600
In this way, Software Composition Analysis tools can check

50
00:02:51.600 --> 00:02:54.540
for vulnerabilities, licensing issues,

51
00:02:54.540 --> 00:02:56.370
and signs of tampering.

52
00:02:56.370 --> 00:02:59.790
For instance, Software Composition Analysis

53
00:02:59.790 --> 00:03:04.790
or SCA tools can detect if a seemingly legitimate component

54
00:03:05.190 --> 00:03:08.323
has been swapped with a compromised version.

55
00:03:08.323 --> 00:03:12.510
SCA tools do this by scanning the code base,

56
00:03:12.510 --> 00:03:16.650
and analyzing all components and dependencies used

57
00:03:16.650 --> 00:03:18.330
in the application.

58
00:03:18.330 --> 00:03:22.440
They identify each component including its version,

59
00:03:22.440 --> 00:03:25.080
and compare it against a known database

60
00:03:25.080 --> 00:03:29.160
of trusted components and security vulnerabilities.

61
00:03:29.160 --> 00:03:33.390
By maintaining a detailed inventory of components,

62
00:03:33.390 --> 00:03:37.410
SSCA tools can flag any discrepancies,

63
00:03:37.410 --> 00:03:42.120
such as an unexpected version or a component sourced

64
00:03:42.120 --> 00:03:45.630
from an unverified repository.

65
00:03:45.630 --> 00:03:50.010
SCA tools also check the integrity of each component

66
00:03:50.010 --> 00:03:53.730
by compelling cryptographic hashes against those

67
00:03:53.730 --> 00:03:55.560
from known sources.

68
00:03:55.560 --> 00:03:57.510
If the hash doesn't match,

69
00:03:57.510 --> 00:04:00.900
it indicates that the component may have been tampered with

70
00:04:00.900 --> 00:04:04.380
or replaced with a compromised version.

71
00:04:04.380 --> 00:04:06.480
This process helps ensure

72
00:04:06.480 --> 00:04:10.200
that only the correct secure versions of components

73
00:04:10.200 --> 00:04:12.600
are used, protecting the software

74
00:04:12.600 --> 00:04:15.720
from potential security threats introduced

75
00:04:15.720 --> 00:04:17.580
through the supply chain.

76
00:04:17.580 --> 00:04:20.700
By using these tools and practices,

77
00:04:20.700 --> 00:04:24.450
enterprises maintain comprehensive records

78
00:04:24.450 --> 00:04:28.290
of their software's development and composition.

79
00:04:28.290 --> 00:04:32.280
This level of transparency allows organizations

80
00:04:32.280 --> 00:04:35.520
to trace each component back to its source,

81
00:04:35.520 --> 00:04:40.020
verify its integrity, and ensure that the software complies

82
00:04:40.020 --> 00:04:42.030
with security standards.

83
00:04:42.030 --> 00:04:45.420
In this way, provenance tracking helps guard

84
00:04:45.420 --> 00:04:47.610
against supply chain attacks

85
00:04:47.610 --> 00:04:51.660
where malicious actors try to insert compromised components

86
00:04:51.660 --> 00:04:54.780
during the software development process.

87
00:04:54.780 --> 00:04:58.800
Second, we have software code and integrity.

88
00:04:58.800 --> 00:05:02.340
Software code and integrity are used for ensuring

89
00:05:02.340 --> 00:05:05.460
that software remains secure, reliable,

90
00:05:05.460 --> 00:05:09.420
and unchanged from its original trusted state.

91
00:05:09.420 --> 00:05:13.380
This is particularly important in enterprise environments

92
00:05:13.380 --> 00:05:17.310
where unauthorized changes can introduce vulnerabilities

93
00:05:17.310 --> 00:05:19.050
or malicious code.

94
00:05:19.050 --> 00:05:23.520
To maintain integrity, organizations use a combination

95
00:05:23.520 --> 00:05:27.060
of cryptographic hashes and code signing.

96
00:05:27.060 --> 00:05:31.320
Cryptographic hashes create a unique digital footprint

97
00:05:31.320 --> 00:05:33.840
for each version of the code.

98
00:05:33.840 --> 00:05:38.070
These hashes are stored securely and are recalculated,

99
00:05:38.070 --> 00:05:41.790
and compared to the original hash each time the code

100
00:05:41.790 --> 00:05:45.180
is accessed, modified, or deployed.

101
00:05:45.180 --> 00:05:46.770
If the hashes match,

102
00:05:46.770 --> 00:05:50.430
it confirms that the code has not been altered.

103
00:05:50.430 --> 00:05:53.640
This helps detect unauthorized modifications

104
00:05:53.640 --> 00:05:55.890
in code very early.

105
00:05:55.890 --> 00:06:00.210
Next, code signing adds another layer of security

106
00:06:00.210 --> 00:06:03.210
by allowing developers to sign their code

107
00:06:03.210 --> 00:06:05.490
with a digital certificate issued

108
00:06:05.490 --> 00:06:08.160
by a trusted certificate authority.

109
00:06:08.160 --> 00:06:11.550
The code itself is often not encrypted,

110
00:06:11.550 --> 00:06:15.840
instead a hash of the code is created and the hash

111
00:06:15.840 --> 00:06:19.230
is encrypted with the developer's private key.

112
00:06:19.230 --> 00:06:23.010
Forming a digital signature attached to the code.

113
00:06:23.010 --> 00:06:25.620
During verification, the system uses

114
00:06:25.620 --> 00:06:29.580
the developer's public key to decrypt the signature,

115
00:06:29.580 --> 00:06:33.090
which was encrypted with the developer's private key

116
00:06:33.090 --> 00:06:35.550
revealing the original hash.

117
00:06:35.550 --> 00:06:39.240
The system then generates a new hash on its own

118
00:06:39.240 --> 00:06:41.850
from the downloaded code and compares it

119
00:06:41.850 --> 00:06:46.380
to the decrypted hash signed by the developer's private key.

120
00:06:46.380 --> 00:06:49.770
If they match, it confirms the code is authentic

121
00:06:49.770 --> 00:06:51.270
and unaltered.

122
00:06:51.270 --> 00:06:55.080
If not, that code is flagged as untrusted.

123
00:06:55.080 --> 00:06:58.800
For example, when a developer signs their code,

124
00:06:58.800 --> 00:07:02.370
a hash of their code is created and encrypted

125
00:07:02.370 --> 00:07:04.380
with their private key.

126
00:07:04.380 --> 00:07:07.800
This signature is then distributed with the code

127
00:07:07.800 --> 00:07:09.630
when someone downloads it.

128
00:07:09.630 --> 00:07:13.920
Upon download, the user system checks the certificate,

129
00:07:13.920 --> 00:07:18.240
decrypts the signature using the developer's public key

130
00:07:18.240 --> 00:07:20.280
and compares the hashes to ensure

131
00:07:20.280 --> 00:07:22.980
the code has not been tampered with.

132
00:07:22.980 --> 00:07:27.120
This process is automated in the continuous integration

133
00:07:27.120 --> 00:07:31.530
and continuous deployment pipelines using tools like Jenkins

134
00:07:31.530 --> 00:07:36.330
or GitLab CL, where security plugins verify signatures

135
00:07:36.330 --> 00:07:39.540
and check hashes for every code change.

136
00:07:39.540 --> 00:07:42.420
By integrating these types of checks,

137
00:07:42.420 --> 00:07:45.810
enterprises can effectively protect their software

138
00:07:45.810 --> 00:07:48.390
against unauthorized modifications,

139
00:07:48.390 --> 00:07:50.730
ensuring that the software remains

140
00:07:50.730 --> 00:07:53.400
in its original secure state.

141
00:07:53.400 --> 00:07:57.780
So remember, software provenance tracks the origin

142
00:07:57.780 --> 00:08:00.270
and history of software components,

143
00:08:00.270 --> 00:08:04.680
helping organizations verify where their software came from

144
00:08:04.680 --> 00:08:06.960
and whether it can be trusted.

145
00:08:06.960 --> 00:08:09.900
Enterprises use Version Control Systems

146
00:08:09.900 --> 00:08:14.310
and Software Bills of Material to maintain detailed records

147
00:08:14.310 --> 00:08:17.190
of all changes and components used.

148
00:08:17.190 --> 00:08:21.300
Next, Software Composition Analysis tools can scan

149
00:08:21.300 --> 00:08:23.700
these records to ensure that components

150
00:08:23.700 --> 00:08:27.780
are from trusted sources and have not been compromised.

151
00:08:27.780 --> 00:08:31.260
Then software and code integrity ensures

152
00:08:31.260 --> 00:08:34.710
that software remains secure and unchanged

153
00:08:34.710 --> 00:08:38.070
through cryptographic hashes and code signing.

154
00:08:38.070 --> 00:08:42.360
This also confirms that the code has not been altered.

155
00:08:42.360 --> 00:08:46.260
These practices work together as integrity use cases

156
00:08:46.260 --> 00:08:50.010
to protect software from unauthorized modifications

157
00:08:50.010 --> 00:08:53.643
and maintain its security and reliablity.