1
00:00:06,480 --> 00:00:09,450
- In this lesson 14.7,
we're gonna focus in

2
00:00:09,450 --> 00:00:11,670
on secure coding.

3
00:00:11,670 --> 00:00:14,370
Now, secure coding is the
practice of writing code

4
00:00:14,370 --> 00:00:17,010
in a way that prioritizes security,

5
00:00:17,010 --> 00:00:19,500
minimizes vulnerabilities or weaknesses

6
00:00:19,500 --> 00:00:24,180
and reduces the risk of
exploitation by attackers.

7
00:00:24,180 --> 00:00:25,710
Now, secure coding follows

8
00:00:25,710 --> 00:00:28,110
established coding best practices,

9
00:00:28,110 --> 00:00:29,760
adheres to security principles,

10
00:00:29,760 --> 00:00:32,220
and utilizes secure coding techniques

11
00:00:32,220 --> 00:00:34,890
to build secure, survivable,

12
00:00:34,890 --> 00:00:38,584
remember, that's a system
property survivable software.

13
00:00:38,584 --> 00:00:39,840
Now, how do we get there

14
00:00:39,840 --> 00:00:41,327
to a place where we
really feel comfortable

15
00:00:41,327 --> 00:00:44,700
and confident that we're
really doing secure coding?

16
00:00:44,700 --> 00:00:46,440
Well, there are a couple of precursors.

17
00:00:46,440 --> 00:00:48,300
One is having developer training.

18
00:00:48,300 --> 00:00:49,650
It's important that our developers

19
00:00:49,650 --> 00:00:52,950
understand secure coding techniques,

20
00:00:52,950 --> 00:00:56,400
practices, standards, you know,
what they should be doing,

21
00:00:56,400 --> 00:01:00,150
what tools they can use,
having very clear requirements,

22
00:01:00,150 --> 00:01:01,650
what are our security requirements

23
00:01:01,650 --> 00:01:03,780
and our privacy requirements?

24
00:01:03,780 --> 00:01:05,340
And doing threat modeling,

25
00:01:05,340 --> 00:01:08,190
which is looking at what
are the most likely threats?

26
00:01:08,190 --> 00:01:11,430
What are the threats that
we really need to harden

27
00:01:11,430 --> 00:01:15,303
our software against so
that it is survivable?

28
00:01:16,500 --> 00:01:18,450
So absolutely critical, right?

29
00:01:18,450 --> 00:01:22,410
That we're defining our security
and privacy requirements

30
00:01:22,410 --> 00:01:25,050
not in the middle, not at the end,

31
00:01:25,050 --> 00:01:28,260
but at the beginning of
the development cycle.

32
00:01:28,260 --> 00:01:29,880
The beginning of every development cycle,

33
00:01:29,880 --> 00:01:32,580
there should be an agreed
upon minimum acceptable level

34
00:01:32,580 --> 00:01:36,000
of security and privacy
requirements, and they are codified,

35
00:01:36,000 --> 00:01:39,060
they're documented, that
we have key milestones

36
00:01:39,060 --> 00:01:41,400
and deliverables are defined.

37
00:01:41,400 --> 00:01:44,850
Because when security
requirements are not identified,

38
00:01:44,850 --> 00:01:45,690
then the security

39
00:01:45,690 --> 00:01:48,960
of the resulting system can't
effectively be evaluated.

40
00:01:48,960 --> 00:01:49,793
We can't say,

41
00:01:49,793 --> 00:01:51,630
"Okay are we getting the
level of security we want

42
00:01:51,630 --> 00:01:54,777
if we haven't even said
what it is we need?"

43
00:01:56,700 --> 00:01:59,190
The threat modeling is
used to anticipate threats

44
00:01:59,190 --> 00:02:01,170
to which the software will be subject to

45
00:02:01,170 --> 00:02:04,140
and the attack surface
that could be exploited.

46
00:02:04,140 --> 00:02:05,970
Remember, the attack surface is the sum

47
00:02:05,970 --> 00:02:09,600
of all possible entry points,
vulnerabilities, and avenues

48
00:02:09,600 --> 00:02:12,330
and attack that an attacker can exploit

49
00:02:12,330 --> 00:02:15,270
to compromise a system or application.

50
00:02:15,270 --> 00:02:17,880
So our threat modeling
involves identifying

51
00:02:17,880 --> 00:02:20,610
applicable threats and developing

52
00:02:20,610 --> 00:02:22,230
threat mitigation strategies

53
00:02:22,230 --> 00:02:25,890
that are implemented in
our design, in our code,

54
00:02:25,890 --> 00:02:27,543
and in our test cases.

55
00:02:30,510 --> 00:02:34,920
So I wanna share with you some
secure coding best practices.

56
00:02:34,920 --> 00:02:37,200
I'd love these best practices,
and these actually came

57
00:02:37,200 --> 00:02:40,593
from the Software Engineering
Institute at Carnegie Mellon.

58
00:02:41,640 --> 00:02:44,280
Keep it simple, heed security policy,

59
00:02:44,280 --> 00:02:47,190
input validation, output validation,

60
00:02:47,190 --> 00:02:51,097
secure cookies, code signing,
effective QA processes,

61
00:02:51,097 --> 00:02:53,790
and sanitize data sent to other systems.

62
00:02:53,790 --> 00:02:55,830
Now, we've talked about
some of these already

63
00:02:55,830 --> 00:02:57,390
but one of the reasons I really like these

64
00:02:57,390 --> 00:03:00,660
is because not only they
secure coding best practices

65
00:03:00,660 --> 00:03:02,430
but on the most part,

66
00:03:02,430 --> 00:03:06,600
these are best practices for
our entire infrastructure.

67
00:03:06,600 --> 00:03:08,880
So number one, keep it simple, right?

68
00:03:08,880 --> 00:03:10,500
Simplicity means fewer errors

69
00:03:10,500 --> 00:03:12,805
and a less complex assessment process.

70
00:03:12,805 --> 00:03:14,385
Everything we're designing,

71
00:03:14,385 --> 00:03:17,370
we should design to keep it simple, right?

72
00:03:17,370 --> 00:03:19,380
It's less errors when we're making it

73
00:03:19,380 --> 00:03:21,960
and it's much easier to assess it.

74
00:03:21,960 --> 00:03:24,240
Heed security policy.

75
00:03:24,240 --> 00:03:26,100
In this case, we're
talking about for our code

76
00:03:26,100 --> 00:03:29,040
we wanna architect and design
for security requirements.

77
00:03:29,040 --> 00:03:30,390
But isn't that true of everything

78
00:03:30,390 --> 00:03:33,510
from our Windows group policy
to how we set our routers

79
00:03:33,510 --> 00:03:36,240
to what we're doing in
our wireless networks.

80
00:03:36,240 --> 00:03:38,307
You know, what everything we're doing,

81
00:03:38,307 --> 00:03:40,053
we should be architect and designing

82
00:03:40,053 --> 00:03:41,670
for our security requirements.

83
00:03:41,670 --> 00:03:43,860
The next is input validation,

84
00:03:43,860 --> 00:03:46,620
validating input before
passing or processing.

85
00:03:46,620 --> 00:03:49,650
And we talked about input
validation a while back

86
00:03:49,650 --> 00:03:51,656
in terms of an injection attack, right?

87
00:03:51,656 --> 00:03:54,480
Injection is when code

88
00:03:54,480 --> 00:03:56,730
or instructions are injected
that are then passed

89
00:03:56,730 --> 00:03:59,940
to the processor and executed, right?

90
00:03:59,940 --> 00:04:01,920
And so what is the result?

91
00:04:01,920 --> 00:04:03,660
Well, we saw things
like injection attacks,

92
00:04:03,660 --> 00:04:05,910
cross-site scripting,
cross-site request forgery,

93
00:04:05,910 --> 00:04:07,557
all very, very dangerous attacks.

94
00:04:07,557 --> 00:04:09,101
And so we wanna make sure

95
00:04:09,101 --> 00:04:12,330
that we are validating all our input

96
00:04:12,330 --> 00:04:13,890
before passing or processing.

97
00:04:13,890 --> 00:04:15,360
We saw that in those attacks.

98
00:04:15,360 --> 00:04:18,060
That's also gonna be true within our code.

99
00:04:18,060 --> 00:04:20,160
The same thing for output validation.

100
00:04:20,160 --> 00:04:22,953
We wanna validate output before returning.

101
00:04:24,030 --> 00:04:26,220
Secure cookies is that
we wanna require cookies

102
00:04:26,220 --> 00:04:28,560
to be encrypted in transit.

103
00:04:28,560 --> 00:04:31,200
We can flag it with a secure attribute.

104
00:04:31,200 --> 00:04:32,670
Code signing, we wanna ensure

105
00:04:32,670 --> 00:04:34,950
that we're digitally signing executables

106
00:04:34,950 --> 00:04:39,420
and scripts to confirm
authenticity and integrity.

107
00:04:39,420 --> 00:04:41,280
Remember, what's a digital signature?

108
00:04:41,280 --> 00:04:43,320
A digital signature is going to be a hash

109
00:04:43,320 --> 00:04:47,253
or a message digest that is
signed with a private key.

110
00:04:48,630 --> 00:04:51,120
We're gonna use effective QA processes.

111
00:04:51,120 --> 00:04:53,250
Well, I think we should be
using effective QA processes

112
00:04:53,250 --> 00:04:54,810
in everything we do, right?

113
00:04:54,810 --> 00:04:55,950
We're gonna use effective

114
00:04:55,950 --> 00:04:58,860
and easy to use quality assurance testing

115
00:04:58,860 --> 00:05:01,290
and evaluation processes.

116
00:05:01,290 --> 00:05:04,260
And lastly, trust but verify, right?

117
00:05:04,260 --> 00:05:07,093
We really always wanna sanitize
data sent to other systems.

118
00:05:07,093 --> 00:05:08,760
There may be some situations

119
00:05:08,760 --> 00:05:10,590
where we decide it is trustworthy,

120
00:05:10,590 --> 00:05:13,650
but whenever there's
the least bit of doubt,

121
00:05:13,650 --> 00:05:15,063
we're going to sanitize.

122
00:05:16,410 --> 00:05:18,720
All great secure coding practices,

123
00:05:18,720 --> 00:05:20,763
all great best practices in general.

124
00:05:22,260 --> 00:05:23,093
All right, that my friends,

125
00:05:23,093 --> 00:05:25,800
brings us two a three-second challenge.

126
00:05:25,800 --> 00:05:27,660
Five challenge questions,
three seconds each.

127
00:05:27,660 --> 00:05:28,493
Let's do it.

128
00:05:29,610 --> 00:05:32,370
This process is used
to anticipate threats.

129
00:05:32,370 --> 00:05:34,563
One, two, three.

130
00:05:35,430 --> 00:05:36,930
It's gonna be threat modeling.

131
00:05:37,830 --> 00:05:40,923
Number two, the basis
of injection attacks.

132
00:05:42,000 --> 00:05:44,910
One, two, three.

133
00:05:44,910 --> 00:05:47,280
It's gonna be poor input validation

134
00:05:47,280 --> 00:05:49,953
or non-existent input validation.

135
00:05:51,030 --> 00:05:53,490
Number three, a cryptographic method

136
00:05:53,490 --> 00:05:56,883
to confirm authenticity and integrity.

137
00:05:58,740 --> 00:06:01,320
One, two, three.

138
00:06:01,320 --> 00:06:04,410
It's gonna be code signing or
having a digital signature.

139
00:06:04,410 --> 00:06:06,560
That's really what we
mean by code signing.

140
00:06:08,670 --> 00:06:11,010
Number four, property that describes

141
00:06:11,010 --> 00:06:14,163
an application's ability
to withstand attack.

142
00:06:15,810 --> 00:06:17,403
One, two, three.

143
00:06:18,510 --> 00:06:20,433
And that's gonna be survivability.

144
00:06:21,360 --> 00:06:24,480
And lastly, number five, all of the points

145
00:06:24,480 --> 00:06:27,663
where an attacker can try to
enter or extract data from.

146
00:06:28,770 --> 00:06:30,513
One, two, three.

147
00:06:31,470 --> 00:06:33,273
That's gonna be your attack surface.

148
00:06:35,310 --> 00:06:36,840
All right, let's do a security-in-action.

149
00:06:36,840 --> 00:06:40,020
This one's about our developers
and developer training.

150
00:06:40,020 --> 00:06:40,980
You've been tasked

151
00:06:40,980 --> 00:06:44,040
with creating introductory
secure coding training

152
00:06:44,040 --> 00:06:46,920
for the application development team.

153
00:06:46,920 --> 00:06:49,860
The first three topics that
you're going to introduce

154
00:06:49,860 --> 00:06:53,670
are keep it simple, heed
security requirements,

155
00:06:53,670 --> 00:06:55,503
and validate input.

156
00:06:56,580 --> 00:07:00,390
So I want you to be able
to really be concise

157
00:07:00,390 --> 00:07:03,420
as you're introducing these
topics to these developers.

158
00:07:03,420 --> 00:07:05,940
So in one sentence, I want you to explain

159
00:07:05,940 --> 00:07:09,390
why each one of these topics is important.

160
00:07:09,390 --> 00:07:10,710
Now, trying to explain anything

161
00:07:10,710 --> 00:07:13,020
in one sentence is always a challenge

162
00:07:13,020 --> 00:07:14,880
but if you can boil it
down to one sentence,

163
00:07:14,880 --> 00:07:16,950
you really understand the concept.

164
00:07:16,950 --> 00:07:18,540
So go ahead and put me on pause

165
00:07:18,540 --> 00:07:22,470
and then write one sentence
about why keep it simple,

166
00:07:22,470 --> 00:07:26,460
heed security requirements and
validate input are important.

167
00:07:26,460 --> 00:07:27,573
Then come on back.

168
00:07:29,310 --> 00:07:30,630
Well here's how you might explain

169
00:07:30,630 --> 00:07:32,793
how the topic is important.

170
00:07:33,900 --> 00:07:37,200
Simplicity means fewer
opportunities for error

171
00:07:37,200 --> 00:07:40,023
and a less complex assessment process.

172
00:07:41,550 --> 00:07:43,650
Heeding requirements will result

173
00:07:43,650 --> 00:07:47,370
in survivable resilience
software that is aligned

174
00:07:47,370 --> 00:07:49,293
with the needs of the organization.

175
00:07:50,310 --> 00:07:54,210
Input validation will
prevent dangerous injection,

176
00:07:54,210 --> 00:07:55,590
cross-site scripting,

177
00:07:55,590 --> 00:07:59,070
and cross-site request forgery attacks.

178
00:07:59,070 --> 00:08:03,780
So that's why each one of
these topics is important.

179
00:08:03,780 --> 00:08:06,240
Being able to explain
that to your developers,

180
00:08:06,240 --> 00:08:08,400
making that relationship,
getting them excited

181
00:08:08,400 --> 00:08:11,340
about having secure code,
that's pretty awesome.

182
00:08:11,340 --> 00:08:14,070
And that is definitely security-in-action.

183
00:08:14,070 --> 00:08:15,930
There's your word cloud, not too big

184
00:08:15,930 --> 00:08:17,160
but you know what to do.

185
00:08:17,160 --> 00:08:19,140
Make sure just like in every other lesson

186
00:08:19,140 --> 00:08:21,540
before you move on, that
you just sort of stare

187
00:08:21,540 --> 00:08:23,070
at this word cloud and then speak them,

188
00:08:23,070 --> 00:08:24,600
speak it out loud, right?

189
00:08:24,600 --> 00:08:26,400
Make sure that you understand the concepts

190
00:08:26,400 --> 00:08:27,960
and the terms and that
you're comfortable with them

191
00:08:27,960 --> 00:08:30,030
and confident that you can explain them.

192
00:08:30,030 --> 00:08:32,640
And then when you're ready,
well, we've got a quiz to do.

193
00:08:32,640 --> 00:08:33,590
I'll see you there.