WEBVTT

1
00:00:00.000 --> 00:00:01.230
In this lesson,

2
00:00:01.230 --> 00:00:04.320
we will learn about security requirements.

3
00:00:04.320 --> 00:00:05.730
Security requirements,

4
00:00:05.730 --> 00:00:09.240
are the specific criteria a system must meet

5
00:00:09.240 --> 00:00:13.020
to ensure protection against threats and vulnerabilities.

6
00:00:13.020 --> 00:00:15.720
Security requirements can be categorized

7
00:00:15.720 --> 00:00:18.540
as functional or non-functional.

8
00:00:18.540 --> 00:00:20.490
Functional security requirements,

9
00:00:20.490 --> 00:00:24.360
define specific security-related behaviors and features

10
00:00:24.360 --> 00:00:26.070
that a system must have,

11
00:00:26.070 --> 00:00:28.470
such as authentication mechanisms,

12
00:00:28.470 --> 00:00:31.320
access controls and encryption protocols.

13
00:00:31.320 --> 00:00:34.020
Non-functional security requirements focus

14
00:00:34.020 --> 00:00:36.180
on the qualities of the system,

15
00:00:36.180 --> 00:00:40.680
including its performance, reliability and usability.

16
00:00:40.680 --> 00:00:44.460
A common challenge in security requirement implementation,

17
00:00:44.460 --> 00:00:47.160
is security versus usability.

18
00:00:47.160 --> 00:00:49.560
This can require a trade-off,

19
00:00:49.560 --> 00:00:52.290
such as increasing security measures,

20
00:00:52.290 --> 00:00:55.350
like implementing multi-factor authentication,

21
00:00:55.350 --> 00:00:59.430
which may reduce user convenience and accessibility.

22
00:00:59.430 --> 00:01:01.380
Let's learn more about functional,

23
00:01:01.380 --> 00:01:04.020
versus non-functional requirements

24
00:01:04.020 --> 00:01:07.440
and security versus usability trade-offs.

25
00:01:07.440 --> 00:01:11.670
First, we have functional and non-functional requirements.

26
00:01:11.670 --> 00:01:15.090
Let's compare functional and non-functional requirements,

27
00:01:15.090 --> 00:01:18.240
while thinking about a fairytale castle.

28
00:01:18.240 --> 00:01:20.010
Functional security requirements,

29
00:01:20.010 --> 00:01:23.190
are like the specific defenses of the castle.

30
00:01:23.190 --> 00:01:24.240
For example,

31
00:01:24.240 --> 00:01:27.750
a moat with a drawbridge can control access,

32
00:01:27.750 --> 00:01:30.810
while tall walls block invaders,

33
00:01:30.810 --> 00:01:34.110
archers on towers detect and attack enemies

34
00:01:34.110 --> 00:01:37.920
and locks on the gates prevent unauthorized entry.

35
00:01:37.920 --> 00:01:42.480
These defenses represent direct, practical security features

36
00:01:42.480 --> 00:01:46.020
that protect our fairytale castle from threats.

37
00:01:46.020 --> 00:01:48.630
Similarly, in cybersecurity,

38
00:01:48.630 --> 00:01:51.660
functional security requirements include features,

39
00:01:51.660 --> 00:01:53.580
like user authentication,

40
00:01:53.580 --> 00:01:57.720
which ensures only authorized users can access a system.

41
00:01:57.720 --> 00:02:01.080
Authentication mechanisms may involve credentials,

42
00:02:01.080 --> 00:02:04.110
such as passwords, biometric data,

43
00:02:04.110 --> 00:02:06.630
or multi-factor authentication.

44
00:02:06.630 --> 00:02:09.660
Next, access controls can be used

45
00:02:09.660 --> 00:02:13.770
to determine who is permitted to access certain resources,

46
00:02:13.770 --> 00:02:15.990
or areas within the system.

47
00:02:15.990 --> 00:02:19.710
Access controls ensure that users are only allowed

48
00:02:19.710 --> 00:02:22.860
to interact with the parts of the system relevant

49
00:02:22.860 --> 00:02:24.330
to their role.

50
00:02:24.330 --> 00:02:27.360
Finally, encryption protocols are used

51
00:02:27.360 --> 00:02:29.940
to secure communications and data

52
00:02:29.940 --> 00:02:32.370
by converting sensitive information

53
00:02:32.370 --> 00:02:36.120
into unreadable ciphertext during transmission.

54
00:02:36.120 --> 00:02:39.180
Encryption prevents unauthorized parties

55
00:02:39.180 --> 00:02:42.210
from accessing or interpreting data.

56
00:02:42.210 --> 00:02:44.340
These functional security measures,

57
00:02:44.340 --> 00:02:48.390
are the digital equivalent of a castle's physical defenses,

58
00:02:48.390 --> 00:02:52.830
protecting systems from unauthorized access and threats.

59
00:02:52.830 --> 00:02:55.140
Non-functional security requirements,

60
00:02:55.140 --> 00:02:58.650
on the other hand, are like the quality and resilience

61
00:02:58.650 --> 00:02:59.700
of the castle.

62
00:02:59.700 --> 00:03:03.810
For example, the castle's walls must not only be tall,

63
00:03:03.810 --> 00:03:06.450
but strong enough to withstand attack.

64
00:03:06.450 --> 00:03:11.010
The drawbridge must allow authorized individuals in quickly

65
00:03:11.010 --> 00:03:14.070
without giving enemies a chance to enter.

66
00:03:14.070 --> 00:03:18.630
And the structure must endure external forces like storms

67
00:03:18.630 --> 00:03:20.040
without crumbling.

68
00:03:20.040 --> 00:03:21.810
These qualities ensure

69
00:03:21.810 --> 00:03:25.140
that the castle remains operational under pressure,

70
00:03:25.140 --> 00:03:26.640
regardless of the number

71
00:03:26.640 --> 00:03:29.640
of attackers or external challenges.

72
00:03:29.640 --> 00:03:31.230
In cybersecurity,

73
00:03:31.230 --> 00:03:35.040
non-functional security requirements are also important

74
00:03:35.040 --> 00:03:38.940
for ensuring the system's performance and reliability.

75
00:03:38.940 --> 00:03:40.080
For example,

76
00:03:40.080 --> 00:03:43.980
encryption algorithms must be not only robust enough

77
00:03:43.980 --> 00:03:46.350
to prevent attackers from breaking them,

78
00:03:46.350 --> 00:03:49.380
using brute force or cryptographic techniques,

79
00:03:49.380 --> 00:03:51.810
but also be optimized

80
00:03:51.810 --> 00:03:55.650
to avoid significant delays in data processing.

81
00:03:55.650 --> 00:03:57.360
This is because a system

82
00:03:57.360 --> 00:04:01.140
that employs strong encryption, but performs slowly,

83
00:04:01.140 --> 00:04:03.210
can hinder key operations,

84
00:04:03.210 --> 00:04:05.070
particularly in environments

85
00:04:05.070 --> 00:04:08.580
where real-time data processing is critical,

86
00:04:08.580 --> 00:04:12.510
such as financial systems or healthcare networks.

87
00:04:12.510 --> 00:04:15.150
Next, reliability demands

88
00:04:15.150 --> 00:04:17.640
that a system remain operational,

89
00:04:17.640 --> 00:04:21.000
even when subjected to high traffic loads,

90
00:04:21.000 --> 00:04:24.330
hardware failures or partial system outages.

91
00:04:24.330 --> 00:04:26.580
To achieve this, implementing features,

92
00:04:26.580 --> 00:04:30.330
like redundancy and failover mechanisms is essential.

93
00:04:30.330 --> 00:04:33.780
Redundancy ensures that if one component fails,

94
00:04:33.780 --> 00:04:35.010
the system can switch

95
00:04:35.010 --> 00:04:38.130
to backup components or alternate pathways,

96
00:04:38.130 --> 00:04:41.100
maintaining availability and security,

97
00:04:41.100 --> 00:04:43.050
even during disruptions.

98
00:04:43.050 --> 00:04:47.130
In the end, non-functional security requirements guarantee

99
00:04:47.130 --> 00:04:49.470
that the system is not only capable

100
00:04:49.470 --> 00:04:52.140
of defending itself against threats,

101
00:04:52.140 --> 00:04:56.430
but also remains efficient, resilient and robust

102
00:04:56.430 --> 00:04:58.320
under various conditions,

103
00:04:58.320 --> 00:05:00.660
ensuring continuous protection

104
00:05:00.660 --> 00:05:03.270
without compromising performance.

105
00:05:03.270 --> 00:05:06.990
Now, a common challenge in enterprise IT,

106
00:05:06.990 --> 00:05:08.760
is finding the right balance

107
00:05:08.760 --> 00:05:11.280
between making a system secure enough

108
00:05:11.280 --> 00:05:15.210
to protect against threats while keeping it user-friendly

109
00:05:15.210 --> 00:05:17.280
for day-to-day operations.

110
00:05:17.280 --> 00:05:21.810
So, now, we will explore security versus usability.

111
00:05:21.810 --> 00:05:24.630
To discuss security versus usability,

112
00:05:24.630 --> 00:05:28.260
let's go back to our fairytale castle analogy.

113
00:05:28.260 --> 00:05:32.310
You could design a castle with layers of complex defenses,

114
00:05:32.310 --> 00:05:36.210
such as multiple drawbridges, secret passageways

115
00:05:36.210 --> 00:05:37.860
and intricate locks.

116
00:05:37.860 --> 00:05:41.760
But if it's too hard for even the castle's guards to enter,

117
00:05:41.760 --> 00:05:44.910
then, daily operations will grind to a halt.

118
00:05:44.910 --> 00:05:47.190
In this situation, friendly forces,

119
00:05:47.190 --> 00:05:50.580
would spend so much time navigating the defenses

120
00:05:50.580 --> 00:05:53.250
that the castle would become inefficient,

121
00:05:53.250 --> 00:05:55.590
despite being highly secure.

122
00:05:55.590 --> 00:05:58.740
This mirrors what happens in IT environments

123
00:05:58.740 --> 00:06:02.340
when security measures become overly restrictive.

124
00:06:02.340 --> 00:06:04.740
In an enterprise organization,

125
00:06:04.740 --> 00:06:08.910
an example of this balance is multi-factor authentication,

126
00:06:08.910 --> 00:06:10.140
or MFA.

127
00:06:10.140 --> 00:06:13.620
MFA requires users to verify their identity

128
00:06:13.620 --> 00:06:16.530
through two or more forms of authentication,

129
00:06:16.530 --> 00:06:19.350
such as a password or a fingerprint,

130
00:06:19.350 --> 00:06:22.680
or a one-time code sent to their mobile device.

131
00:06:22.680 --> 00:06:25.950
While this adds an essential layer of security,

132
00:06:25.950 --> 00:06:28.530
which is preventing unauthorized access,

133
00:06:28.530 --> 00:06:31.170
even if someone's password is compromised,

134
00:06:31.170 --> 00:06:34.830
it can also slow down legitimate users.

135
00:06:34.830 --> 00:06:38.730
Employees may find the MFA process cumbersome,

136
00:06:38.730 --> 00:06:40.020
especially if they have

137
00:06:40.020 --> 00:06:42.990
to authenticate multiple times a day,

138
00:06:42.990 --> 00:06:44.730
or if the additional factor,

139
00:06:44.730 --> 00:06:48.120
involves using a separate device like a phone.

140
00:06:48.120 --> 00:06:51.150
A cumbersome authentication process can lead

141
00:06:51.150 --> 00:06:54.000
to frustration and lower productivity,

142
00:06:54.000 --> 00:06:55.680
creating a natural tension

143
00:06:55.680 --> 00:06:59.220
between strong security and user convenience.

144
00:06:59.220 --> 00:07:00.750
In most cases,

145
00:07:00.750 --> 00:07:05.130
the security benefits of MFA outweigh the inconvenience

146
00:07:05.130 --> 00:07:06.030
of using it.

147
00:07:06.030 --> 00:07:08.070
But things like single sign-on,

148
00:07:08.070 --> 00:07:10.920
can help make the process more efficient.

149
00:07:10.920 --> 00:07:13.980
Another technical challenge is the implementation

150
00:07:13.980 --> 00:07:15.150
of encryption.

151
00:07:15.150 --> 00:07:18.870
While encryption is used for protecting sensitive data,

152
00:07:18.870 --> 00:07:21.660
it can also introduce latency.

153
00:07:21.660 --> 00:07:25.920
The time it takes to encrypt and decrypt data can lead

154
00:07:25.920 --> 00:07:28.740
to slower performance in applications.

155
00:07:28.740 --> 00:07:30.270
This will cause problems,

156
00:07:30.270 --> 00:07:32.280
particularly in environments

157
00:07:32.280 --> 00:07:35.010
that require real-time processing,

158
00:07:35.010 --> 00:07:37.500
such as financial transaction,

159
00:07:37.500 --> 00:07:40.320
or large data transfer environments.

160
00:07:40.320 --> 00:07:41.760
In some cases,

161
00:07:41.760 --> 00:07:45.870
administrators may have to make tough trade-off choices,

162
00:07:45.870 --> 00:07:48.480
like do they prioritize security

163
00:07:48.480 --> 00:07:51.930
by using more complex encryption algorithms,

164
00:07:51.930 --> 00:07:55.770
or do they sacrifice some level of encryption

165
00:07:55.770 --> 00:07:58.500
to ensure the system runs efficiently?

166
00:07:58.500 --> 00:08:00.540
Another layer of trade-off comes

167
00:08:00.540 --> 00:08:03.060
with access control policies.

168
00:08:03.060 --> 00:08:05.910
Highly granular access controls,

169
00:08:05.910 --> 00:08:09.870
which limit what individual users or groups can do

170
00:08:09.870 --> 00:08:10.950
in a system,

171
00:08:10.950 --> 00:08:15.510
provide strong security, but can make workflows clunky.

172
00:08:15.510 --> 00:08:20.160
For instance, a developer might need multiple approvals just

173
00:08:20.160 --> 00:08:24.180
to access a specific tool or set of data,

174
00:08:24.180 --> 00:08:28.440
always requiring multiple approvals can add up eventually

175
00:08:28.440 --> 00:08:30.690
to delay project timelines.

176
00:08:30.690 --> 00:08:35.100
So, security policies like these can enhance protection

177
00:08:35.100 --> 00:08:37.020
against insider threats,

178
00:08:37.020 --> 00:08:41.250
but they also risk slowing down legitimate users trying

179
00:08:41.250 --> 00:08:43.680
to perform routine tasks.

180
00:08:43.680 --> 00:08:45.630
So, remember,

181
00:08:45.630 --> 00:08:49.530
security requirements are the specific criteria

182
00:08:49.530 --> 00:08:51.450
that a system must meet

183
00:08:51.450 --> 00:08:54.870
to protect against threats and vulnerabilities.

184
00:08:54.870 --> 00:08:56.820
These requirements are divided

185
00:08:56.820 --> 00:09:00.840
into functional and non-functional categories

186
00:09:00.840 --> 00:09:03.360
where functional security requirements,

187
00:09:03.360 --> 00:09:05.430
involve the specific features

188
00:09:05.430 --> 00:09:08.340
and behaviors a system must have,

189
00:09:08.340 --> 00:09:10.710
such as authentication mechanisms,

190
00:09:10.710 --> 00:09:13.110
access controls and encryption.

191
00:09:13.110 --> 00:09:15.960
Non-functional security requirements focus

192
00:09:15.960 --> 00:09:17.640
on the system's qualities,

193
00:09:17.640 --> 00:09:20.760
such as its performance, reliability

194
00:09:20.760 --> 00:09:24.180
and ability to handle stress without failure.

195
00:09:24.180 --> 00:09:27.900
A common challenge in implementing security requirements,

196
00:09:27.900 --> 00:09:29.910
is finding the right balance

197
00:09:29.910 --> 00:09:33.330
between strong security and usability.

198
00:09:33.330 --> 00:09:36.780
This is because more robust security measures,

199
00:09:36.780 --> 00:09:41.733
can sometimes reduce user convenience and system efficiency.

