Presenter: Design vulnerabilities. 2 2
In this lesson, we're going to talk 3 3
about some software design vulnerabilities 4 4
and what are some things you can do to overcome them. 5 5
Now, when it comes to vulnerabilities, 6 6
vulnerabilities often arise 7 7
from the general design of your software code. 8 8
And so if you do bad software code design, 9 9
you're going to have a lot more vulnerabilities. 10 10
So in this lesson, we're going to focus on three main types. 11 11
We have insecure components, insufficient logging 12 12
and monitoring, and weak or default configurations. 13 13
Now, when we talk about insecure components, what is this? 14 14
Well, it's really any code that's used 15 15
or invoked outside of the main program development process. 16 16
So when you're dealing with this 17 17
and you start dealing with insecure components, 18 18
this can come from a lot of different areas. 19 19
For instance, it could come from code reuse. 20 20
Now, this is where you take one block 21 21
of code from somewhere else in the program 22 22
just copy and paste it and use it again. 23 23
Or you take it from one application 24 24
and put it into another application. 25 25
A lot of times people go onto Stack Exchange and they'll go 26 26
and copy people's code and put it into their own. 27 27
Now, there's nothing wrong with doing that initially 28 28
but if you're ever using code and you don't know 29 29
if it's secure or not, you could be bringing 30 30
in vulnerabilities into your program by doing that. 31 31
And so this is why we consider it an insecure component. 32 32
Another thing we might use is a third party library. 33 33
Anytime you bring in a library to do some function for you, 34 34
you are importing that code into your program. 35 35
And so you might bring in a dynamic link library 36 36
in Windows or a shared object library 37 37
in Linux, and that might give you the ability to 38 38
do network connections or do cryptography. 39 39
But if those things were not secure, 40 40
you now brought that insecurity into your program. 41 41
And the third thing is software development toolkits. 42 42
Again, SDKs are really helpful as a programmer 43 43
because I don't have to go 44 44
and create all those pre-built functions, but 45 45
if the person who built those pre-built functions 46 46
didn't do a good job, 47 47
you're bringing in those vulnerabilities as well. 48 48
And the other issue with these three areas is 49 49
especially with STKs and third party libraries 50 50
is sometimes they built it thinking it was good 51 51
and then six months later, there's a vulnerability to it. 52 52
If you're using an old version 53 53
of a library or an old version of an SDK, 54 54
you aren't using the latest and greatest patched one 55 55
and therefore you're missing those security fixes 56 56
and you're bringing in those insecurities into your program. 57 57
The second area we want to talk 58 58
about is insufficient logging and monitoring. 59 59
Now, this is any program that does not properly record 60 60
or log detailed enough information for an analyst to 61 61
perform their job when there's an incident that happens. 62 62
So if I create a program and I don't have any kind 63 63
of logging and monitoring, well, that's not going to be very 64 64
good for my analysts who have to deal 65 65
with the incident response later. 66 66
So we want to make sure we're always setting up our logging 67 67
and our monitoring to support our use case. 68 68
And that way we can answer the who, the what, the when, 69 69
the where, and the how, when things go wrong. 70 70
Now, what is your use case? 71 71
Well, that's up to you and your organization. 72 72
You're going to determine how much logging you want, 73 73
how long you want to store it for, and all those details 74 74
like we talked about back in our logging lessons. 75 75
The third area we want to talk about is weak 76 76
or default configurations. 77 77
Now, this is any program that uses ineffective credentials 78 78
or configurations, or one in which the defaults 79 79
have not been changed for security. 80 80
When you're dealing with weak or default configurations, 81 81
there are lots of these things out there in the marketplace 82 82
and they are running amuck in a lot of people's networks. 83 83
Now, many applications choose simply to run 84 84
as route or local admin. 85 85
That's their default configuration. 86 86
You need to ask yourself 87 87
does this program really need to be root? 88 88
Does this program really need to be an admin? 89 89
And if not, don't let it run that way 90 90
because you want to use lease privileges. 91 91
Also, sometimes you have some of these programs 92 92
and by default, their permissions are really vague. 93 93
They're really permissive, and so they allow a lot of files 94 94
and directories to be read and right and executed to 95 95
and this would be a weak configuration. 96 96
Another place I see this all the time is when 97 97
you're using hardware appliances where you're 98 98
using some kind of software that has a password 99 99
and username already built in 100 100
and it's often something like administrator administrator 101 101
or admin admin or route route. 102 102
This is a week or default configuration 103 103
that should be changed immediately 104 104
once you install it into the environment. 105 105
Now, what's the best practice to prevent some 106 106
of these weaknesses? 107 107
Well, the biggest one is to utilize scripted installations 108 108
and baseline configuration templates to 109 109
secure your applications during install. 110 110
So if I'm going to install some program, 111 111
there should be a security configuration template 112 112
or a scripted installation that actually goes through 113 113
and makes those things more secure. 114 114
This would be something that your organization does itself 115 115
or something provided by the manufacturer.