WEBVTT

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

2
00:00:01.200 --> 00:00:04.080
we will learn about hardware assurance.

3
00:00:04.080 --> 00:00:07.350
Hardware assurance ensures that physical components

4
00:00:07.350 --> 00:00:09.390
are secure, reliable,

5
00:00:09.390 --> 00:00:13.380
and free from malicious alterations or defects.

6
00:00:13.380 --> 00:00:15.060
Hardware assurance concepts

7
00:00:15.060 --> 00:00:18.960
include the certification and validation process.

8
00:00:18.960 --> 00:00:22.590
The certification process is a formal evaluation

9
00:00:22.590 --> 00:00:24.750
that verifies hardware components

10
00:00:24.750 --> 00:00:28.800
meet specific security standards and operate as expected.

11
00:00:28.800 --> 00:00:31.470
Validation is the ongoing process

12
00:00:31.470 --> 00:00:33.210
of testing and verifying

13
00:00:33.210 --> 00:00:35.760
that hardware meets its design standards,

14
00:00:35.760 --> 00:00:39.120
especially when updates or changes are made.

15
00:00:39.120 --> 00:00:42.330
Let's learn more about hardware certification

16
00:00:42.330 --> 00:00:44.730
and validation processes.

17
00:00:44.730 --> 00:00:47.280
First, we have certification.

18
00:00:47.280 --> 00:00:49.860
Certification is the formal process

19
00:00:49.860 --> 00:00:52.560
of evaluating hardware components

20
00:00:52.560 --> 00:00:55.770
to ensure they meet specific security standards

21
00:00:55.770 --> 00:00:57.840
and operate as expected.

22
00:00:57.840 --> 00:01:01.860
A widely recognized framework for hardware certification

23
00:01:01.860 --> 00:01:04.740
is the Common Criteria, or CC.

24
00:01:04.740 --> 00:01:07.230
The common criteria is used to assess

25
00:01:07.230 --> 00:01:09.450
how well a product can defend

26
00:01:09.450 --> 00:01:11.880
against defined security threats.

27
00:01:11.880 --> 00:01:13.710
The depth of the evaluation,

28
00:01:13.710 --> 00:01:17.580
known as the Evaluation Assurance Level, or EAL,

29
00:01:17.580 --> 00:01:21.814
varies based on how critical the system or product is.

30
00:01:21.814 --> 00:01:26.400
EAL levels vary from EAL 1, functionally tested,

31
00:01:26.400 --> 00:01:30.960
to EAL 7, formally verified design and tested.

32
00:01:30.960 --> 00:01:34.710
Higher levels of certification such as EAL 7

33
00:01:34.710 --> 00:01:36.750
require more rigorous testing

34
00:01:36.750 --> 00:01:38.730
and may be used to certify

35
00:01:38.730 --> 00:01:42.210
classified government or defense systems.

36
00:01:42.210 --> 00:01:46.020
For example, if a manufacturer designs a new chip,

37
00:01:46.020 --> 00:01:47.580
they might submit the chip

38
00:01:47.580 --> 00:01:50.550
for evaluation under the Common Criteria

39
00:01:50.550 --> 00:01:52.260
to obtain certification.

40
00:01:52.260 --> 00:01:53.880
The certification process

41
00:01:53.880 --> 00:01:57.390
ensures the chip meets strict security requirements

42
00:01:57.390 --> 00:02:01.830
laid out through Protection Profiles and Security Targets.

43
00:02:01.830 --> 00:02:05.190
A Protection Profile describes potential threats

44
00:02:05.190 --> 00:02:07.560
and countermeasures for evaluation.

45
00:02:07.560 --> 00:02:10.500
For instance, a chip's Protection Profile

46
00:02:10.500 --> 00:02:13.980
might require protection against physical tampering,

47
00:02:13.980 --> 00:02:16.740
the use of strong encryption to safeguard data,

48
00:02:16.740 --> 00:02:18.870
and a secure boot process.

49
00:02:18.870 --> 00:02:21.570
Next, a Security Target would describe

50
00:02:21.570 --> 00:02:24.600
how the product will meet the security requirements

51
00:02:24.600 --> 00:02:26.763
defined in the Protection Profile.

52
00:02:26.763 --> 00:02:29.430
For instance, the chip's Security Target

53
00:02:29.430 --> 00:02:32.940
may specify the implementation of tamper resistance

54
00:02:32.940 --> 00:02:35.280
to protect against physical tampering,

55
00:02:35.280 --> 00:02:38.430
strong encryption mechanisms to safeguard the data,

56
00:02:38.430 --> 00:02:40.110
and a secure boot process

57
00:02:40.110 --> 00:02:44.193
to ensure that only verified, trusted software is executed.

58
00:02:44.193 --> 00:02:46.470
Additionally, a Security Target

59
00:02:46.470 --> 00:02:49.410
might detail features like access control

60
00:02:49.410 --> 00:02:51.810
to ensure that only authorized users

61
00:02:51.810 --> 00:02:55.500
can interact with critical components of the chip.

62
00:02:55.500 --> 00:02:59.280
Common Criteria certification is particularly valuable

63
00:02:59.280 --> 00:03:02.880
in high-security sectors such as national defense,

64
00:03:02.880 --> 00:03:05.820
government systems, and critical infrastructure,

65
00:03:05.820 --> 00:03:07.650
where hardware vulnerabilities

66
00:03:07.650 --> 00:03:10.110
could have severe consequences.

67
00:03:10.110 --> 00:03:13.140
Another key initiative for hardware security

68
00:03:13.140 --> 00:03:15.270
is the Trusted Foundry Program.

69
00:03:15.270 --> 00:03:16.920
The Trusted Foundry Program

70
00:03:16.920 --> 00:03:20.400
is part of the U.S. Department of Defense's efforts

71
00:03:20.400 --> 00:03:24.780
to secure the manufacturing of critical hardware components.

72
00:03:24.780 --> 00:03:26.310
The program was established

73
00:03:26.310 --> 00:03:28.740
to address a significant concern:

74
00:03:28.740 --> 00:03:31.920
the risk that malicious components or backdoors

75
00:03:31.920 --> 00:03:35.640
could be inserted during the manufacturing process.

76
00:03:35.640 --> 00:03:38.670
Such vulnerabilities could be exploited later,

77
00:03:38.670 --> 00:03:41.730
potentially compromising the security of devices

78
00:03:41.730 --> 00:03:44.910
and posing serious risks to defense systems

79
00:03:44.910 --> 00:03:47.370
and sensitive government infrastructure.

80
00:03:47.370 --> 00:03:51.090
So, to mitigate this risk, the Trusted Foundry Program

81
00:03:51.090 --> 00:03:53.820
certifies manufacturing facilities

82
00:03:53.820 --> 00:03:57.030
that adhere to stringent security protocols.

83
00:03:57.030 --> 00:03:59.790
These protocols include access control,

84
00:03:59.790 --> 00:04:02.250
ensuring only authorized personnel

85
00:04:02.250 --> 00:04:03.720
handle sensitive hardware,

86
00:04:03.720 --> 00:04:07.020
supply chain security, which requires components

87
00:04:07.020 --> 00:04:09.450
to be sourced from trusted suppliers,

88
00:04:09.450 --> 00:04:12.180
and data and communication security

89
00:04:12.180 --> 00:04:15.660
where sensitive information is protected through encryption.

90
00:04:15.660 --> 00:04:18.270
Certified facilities also undergo

91
00:04:18.270 --> 00:04:20.580
regular audits and inspections

92
00:04:20.580 --> 00:04:23.730
to ensure compliance with these protocols.

93
00:04:23.730 --> 00:04:27.780
As a result, only Trusted Foundry-certified facilities

94
00:04:27.780 --> 00:04:31.290
are authorized to produce specific microelectronics

95
00:04:31.290 --> 00:04:34.830
and hardware components vital to national security.

96
00:04:34.830 --> 00:04:38.280
This certification provides a high level of assurance

97
00:04:38.280 --> 00:04:40.620
that products have not been tampered with

98
00:04:40.620 --> 00:04:43.230
or compromised during production.

99
00:04:43.230 --> 00:04:45.720
Now, let's explore validation.

100
00:04:45.720 --> 00:04:48.450
Validation is the ongoing process

101
00:04:48.450 --> 00:04:52.740
of testing and verifying that hardware continues to meet

102
00:04:52.740 --> 00:04:55.140
its design and security standards,

103
00:04:55.140 --> 00:04:58.140
especially after updates or changes.

104
00:04:58.140 --> 00:05:02.160
This ensures that even after initial certification,

105
00:05:02.160 --> 00:05:05.490
hardware remains secure and reliable.

106
00:05:05.490 --> 00:05:08.220
One critical framework for validation

107
00:05:08.220 --> 00:05:11.460
is the National Institute of Standards and Technology,

108
00:05:11.460 --> 00:05:12.293
or NIST,

109
00:05:12.293 --> 00:05:15.720
800-161 publication.

110
00:05:15.720 --> 00:05:19.620
This publication focuses on supply chain risk management

111
00:05:19.620 --> 00:05:23.730
for information and communication technology systems.

112
00:05:23.730 --> 00:05:25.470
This standard provides guidance

113
00:05:25.470 --> 00:05:27.960
to federal agencies and contractors

114
00:05:27.960 --> 00:05:31.470
to identify, assess, and manage risks

115
00:05:31.470 --> 00:05:32.880
throughout the information

116
00:05:32.880 --> 00:05:35.850
and communication technology supply chain.

117
00:05:35.850 --> 00:05:40.850
NIST 800-161 also emphasizes the need

118
00:05:40.920 --> 00:05:42.900
for continuous validation

119
00:05:42.900 --> 00:05:45.930
by putting in place checks and controls

120
00:05:45.930 --> 00:05:48.480
at each stage of the hardware's development,

121
00:05:48.480 --> 00:05:50.910
manufacturing, and delivery.

122
00:05:50.910 --> 00:05:54.360
Similarly, NIST 800-171

123
00:05:54.360 --> 00:05:57.780
sets guidelines for protecting sensitive information,

124
00:05:57.780 --> 00:06:02.640
specifically Controlled Unclassified Information, or CUI,

125
00:06:02.640 --> 00:06:06.000
in non-federal systems and organizations.

126
00:06:06.000 --> 00:06:08.040
This is particularly important

127
00:06:08.040 --> 00:06:11.400
for contractors working with the federal government.

128
00:06:11.400 --> 00:06:13.320
For instance, if a contractor

129
00:06:13.320 --> 00:06:17.010
is building hardware components for a government project,

130
00:06:17.010 --> 00:06:22.010
NIST 800-171 outlines how to safeguard CUI,

131
00:06:22.530 --> 00:06:24.060
both during the development

132
00:06:24.060 --> 00:06:27.000
and throughout the lifecycle of the hardware.

133
00:06:27.000 --> 00:06:28.950
This validation process

134
00:06:28.950 --> 00:06:31.740
ensures that sensitive data is protected

135
00:06:31.740 --> 00:06:35.340
and ensures the hardware is not just physically secure,

136
00:06:35.340 --> 00:06:38.970
but also capable of handling sensitive information

137
00:06:38.970 --> 00:06:40.770
without compromise.

138
00:06:40.770 --> 00:06:44.160
Finally, the Internet of Things, or IoT,

139
00:06:44.160 --> 00:06:47.370
Cybersecurity Improvement Act of 2020

140
00:06:47.370 --> 00:06:51.960
establishes cybersecurity requirements for IoT devices

141
00:06:51.960 --> 00:06:54.300
used by the federal government.

142
00:06:54.300 --> 00:06:57.090
The act mandates that IoT devices,

143
00:06:57.090 --> 00:06:59.370
including their hardware components,

144
00:06:59.370 --> 00:07:01.740
meet specific security standards,

145
00:07:01.740 --> 00:07:04.620
such as vulnerability management, patching,

146
00:07:04.620 --> 00:07:06.270
and authentication.

147
00:07:06.270 --> 00:07:10.200
If a company is developing an IoT sensor or device

148
00:07:10.200 --> 00:07:11.460
for government use,

149
00:07:11.460 --> 00:07:14.730
they must validate that it complies with these standards

150
00:07:14.730 --> 00:07:16.710
from development to deployment

151
00:07:16.710 --> 00:07:20.160
and throughout the device's operational lifecycle.

152
00:07:20.160 --> 00:07:23.760
So remember, hardware assurance ensures

153
00:07:23.760 --> 00:07:26.970
that physical components are secure, reliable,

154
00:07:26.970 --> 00:07:29.610
and free from tampering and defects.

155
00:07:29.610 --> 00:07:32.190
This involves two key processes,

156
00:07:32.190 --> 00:07:34.860
certification and validation.

157
00:07:34.860 --> 00:07:38.610
Certification is the formal evaluation process.

158
00:07:38.610 --> 00:07:40.230
Certification verifies

159
00:07:40.230 --> 00:07:43.440
that hardware meets specific security standards.

160
00:07:43.440 --> 00:07:45.930
An example of a certification framework

161
00:07:45.930 --> 00:07:47.850
is the Common Criteria.

162
00:07:47.850 --> 00:07:49.770
The Common Criteria assesses

163
00:07:49.770 --> 00:07:53.550
how well a product defends against security threats.

164
00:07:53.550 --> 00:07:56.850
Next, validation is the ongoing process

165
00:07:56.850 --> 00:07:58.590
of testing and verifying

166
00:07:58.590 --> 00:08:02.250
that hardware continues to meet these standards over time,

167
00:08:02.250 --> 00:08:05.490
especially after updates or changes.

168
00:08:05.490 --> 00:08:10.485
Frameworks like NIST 800-161 and NIST 800-171

169
00:08:11.700 --> 00:08:15.390
provide guidelines for managing supply chain risks

170
00:08:15.390 --> 00:08:17.610
and protecting sensitive information,

171
00:08:17.610 --> 00:08:21.720
ensuring hardware remains secure throughout its lifecycle.

172
00:08:21.720 --> 00:08:24.630
Finally, the Internet of Things, or IoT,

173
00:08:24.630 --> 00:08:27.690
Cybersecurity Improvement Act of 2020

174
00:08:27.690 --> 00:08:29.580
sets cybersecurity standards

175
00:08:29.580 --> 00:08:33.090
for IoT devices used by the federal government.

176
00:08:33.090 --> 00:08:36.510
It requires devices to meet strict security measures,

177
00:08:36.510 --> 00:08:39.960
like vulnerability management and authentication.

178
00:08:39.960 --> 00:08:44.010
This act ensures IoT devices remain secure

179
00:08:44.010 --> 00:08:45.600
throughout their lifecycle,

180
00:08:45.600 --> 00:08:47.550
protecting government systems

181
00:08:47.550 --> 00:08:51.153
from risks posed by IoT devices.