Presenter: Software assessments. 2 2
In this lesson, we're going to talk about the different types 3 3
of software assessments, 4 4
because it's really important for you 5 5
to have a comprehensive testing program 6 6
that validates the effectiveness 7 7
of your protection of confidentiality, 8 8
integrity, and availability within your software. 9 9
If you're doing any kind of web application development 10 10
or software development, it is really crucial 11 11
that you have a comprehensive testing program in place. 12 12
Now, the things we're going to talk about in this lesson 13 13
include things like static code analysis, 14 14
formal verification, user acceptance testing or UAT 15 15
and security regression testing. 16 16
Now, when we talk about static code analysis, 17 17
this is the process of reviewing uncompiled source code 18 18
either manually or using automated tools. 19 19
So let's pretend that one 20 20
of my web developers created a program 21 21
so you could take quizzes on our website. 22 22
Now that web application is written in some kind of code, 23 23
and if somebody wanted to look at that code, line by line, 24 24
and see how it works, that would be a static code analysis. 25 25
Now, in addition to doing it manually, 26 26
we could use automated tools though. 27 27
Now these automated tools can reveal issues 28 28
ranging from faulty logic to insecure libraries, 29 29
before you even start running that application. 30 30
Now, these automated tools are essentially 31 31
software that will scan the source code 32 32
for signatures of known issues. 33 33
Now, a lot of these use different databases 34 34
for these known issues. 35 35
For example, we've mentioned OWASP before. 36 36
OWASP is a really popular place 37 37
to find these coding vulnerabilities, 38 38
and there's a top 10 for application security risks 39 39
or injection vulnerabilities 40 40
and you can look at those 41 41
and load those into your automated tools as well. 42 42
Now, just because you have an automated tool, 43 43
doesn't mean you can just scan it 44 44
with a tool and forget about it. 45 45
No, these tools are not an adequate substitute 46 46
for human judgment. 47 47
Instead, we should use these automated tools 48 48
to get the first pass through that software code, 49 49
and then we should put a human on it 50 50
to look through it as well. 51 51
By doing this one two punch, 52 52
you're going to get a lot better results 53 53
because a lot of times the human will catch things 54 54
the automated tool won't, 55 55
and the automated tool will catch things the human won't. 56 56
Now, when you're doing these things, 57 57
these are known as code reviews. 58 58
Now, code reviews are this manual process, 59 59
and it's a process of peer review 60 60
of uncompiled source code by other developers. 61 61
So let's say one of my web developers wrote a program. 62 62
He emails it to me and I read through it. 63 63
That would be a peer review code review. 64 64
Now, there's lots of other types you can do. 65 65
We can do something known 66 66
as an over-the-shoulder code review. 67 67
This is where the person who wrote the code will sit 68 68
at the keyboard and explain exactly what they did, 69 69
and then I might stand behind them 70 70
and look over their shoulder 71 71
to see the code as they're explaining it. 72 72
Another way you can do it is by doing paraprogramming. 73 73
This is more of an interactive way 74 74
where they write a section and I write a section, 75 75
and while I'm writing my section, 76 76
they're looking over my shoulder 77 77
and when they're writing a section, 78 78
I'm looking over their shoulder. 79 79
And so that way we can try to catch mistakes. 80 80
That oversight allows us to catch different assumptions. 81 81
For instance, I might go, 82 82
"Hey why are you using that variable declaration? 83 83
That doesn't make sense. 84 84
You're making a faulty assumption," 85 85
and then I can call them out on that 86 86
and we can get those things fixed. 87 87
By doing this, you can bring up level of knowledge as well 88 88
because a more experienced person can help 89 89
a junior coder or a junior coder might be able 90 90
to show a new way of doing things to that senior coder. 91 91
It does work both ways, and so doing these code reviews 92 92
and peer programming can really help 93 93
the security of your programs. 94 94
Now, another thing we can do is what's called 95 95
a formal verification method. 96 96
Now, this is a process of validating software design 97 97
through mathematical modeling 98 98
of expected inputs and outputs. 99 99
Now, why might we use a formal verification method 100 100
instead of just doing a static code review? 101 101
Well, a lot of times there are these things 102 102
known as corner cases. 103 103
And when you're doing a formal verification method 104 104
these are used in critical software 105 105
where corner cases have to be eliminated. 106 106
Now, what do I mean by a corner case? 107 107
Well, let's say I had a program 108 108
that does something like a self-driving car. 109 109
Well, a self-driving car 110 110
has a lot of different code in it, 111 111
and most of the time the self-driving car 112 112
is going to be driving on a road 113 113
and it needs to be able to detect objects 114 114
like a hole in the road or a person on the side of the road 115 115
or a car in front of them, 116 116
and they need to be able to see these things using 117 117
its sensors and its logic to be able to drive the car. 118 118
Now, a corner case might be what does the car do 119 119
if that person on the side road jumps out in front of me? 120 120
Now the car only has two options. 121 121
It can try to stop, but it won't be able to in time, 122 122
and it will hit the person, or it can swerve to the left 123 123
and crash into the other car, 124 124
or it can swerve to the right 125 125
and hit that other person on the side of the road. 126 126
All of these are bad options. 127 127
In this case, this would be known as corner cases, 128 128
because these are all bad options that we'd want to avoid, 129 129
but if you have to choose one of them, 130 130
which one are you going to choose? 131 131
And so we have to be able to go through 132 132
into a formal verification method of all the software, 133 133
especially in something that's a critical environment, 134 134
like a car that weighs 2000 or 3000 pounds barreling 135 135
down the highway at 60 miles an hour. 136 136
That's a great place for using formal verification methods. 137 137
Another thing we might use 138 138
is what's called User Acceptance Testing. 139 139
Now, user acceptance testing or UAT 140 140
is beta testing by your end users 141 141
that proves a program is usable 142 142
and fit for purpose in real world conditions. 143 143
So back in the late nineties and early 2000s, 144 144
I owned a company doing web development. 145 145
That's where I started out. 146 146
And when I was doing web development back then, 147 147
we did a lot of user acceptance testing. 148 148
So I would sit down with somebody, 149 149
you would tell me exactly what you want this website to do, 150 150
you'd tell me all the features you want, 151 151
what you want the design to look like, all of that stuff. 152 152
We gather all the requirements, 153 153
we plan out the design, we code it, and we do our testing. 154 154
We're going to do code reviews, static code reviews. 155 155
We're going to do automated code reviews. 156 156
We might even do formal verification methods 157 157
if we're doing something for 158 158
say a bank or something like that. 159 159
Now, once we do all of that, 160 160
we now need to get into the user acceptance testing. 161 161
This is where we're going to put hands-on end users 162 162
on the system and see how they react. 163 163
This allows us to gather feedback from those end users, 164 164
identify any workflow issues we may have overseen 165 165
and ensure that it meets their particular use case. 166 166
So if I was building a website for a bank, for instance, 167 167
I might think that I've coded it exactly right 168 168
and the bank might have thought 169 169
that I coded it exactly right. 170 170
But then we put a user on the system, 171 171
they go, well this doesn't make sense. 172 172
When I try to transfer money from one account to another 173 173
I have to go through 17 clicks to do it. 174 174
That isn't very good. 175 175
And so that end user, who's representing the customer 176 176
might go, "We're not going to accept this. 177 177
Go back and recode it. 178 178
Or in version 2.0, you need to fix this." 179 179
This is the idea of user acceptance testing. 180 180
This is more about the end functionality and fit. 181 181
Does it do what it's supposed to do? 182 182
And is it doing it in a well thought out way 183 183
that makes it easier for the user to use? 184 184
The final thing we're going to talk about here 185 185
is security regression testing. 186 186
Now, this is the process of checking 187 187
that updates the code do not compromise 188 188
the existing security functionality 189 189
or capability of the code itself. 190 190
Now, why is this important? 191 191
Well, because every time you install a patch 192 192
or an update or some kind of new piece of software, 193 193
you run the risk of breaking things. 194 194
And so if I take a new security update, 195 195
and I install it on my network and I didn't test it first, 196 196
well guess what, 197 197
I might have introduced new bugs 198 198
or I might have broken features. 199 199
So instead we want to do a security regression testing. 200 200
We're going to set it up in a lab, we're going to test that thing 201 201
and make sure we didn't break something else 202 202
when we fixed it. 203 203
Security regression testing is going to enable 204 204
the identification of security mechanisms 205 205
that have worked before 206 206
but are now broken after the latest changes. 207 207
This is a common problem 208 208
because one of the things we say as a programmer is that 209 209
I can add one piece of code to fix something, 210 210
but I might end up breaking three or four other things. 211 211
Anytime you add a change, 212 212
there's a possibility something's going to get broken. 213 213
And so one of the things you always want to go back 214 214
and check is that you didn't break 215 215
any of your security mechanisms, 216 216
because that would be a bad thing for us, 217 217
especially since we're trying to be cybersecurity experts 218 218
by being cybersecurity analysts.