-: Design vulnerabilities.
In this lesson, we're going to talk about
some software design vulnerabilities and what
are some things you can do to overcome them.
Now, when it comes to vulnerabilities,
vulnerabilities often arise from the general design
of your software code.
And so, if you do bad software code design,
you're going to have a lot more vulnerabilities.
So, in this lesson, we're going to focus on three main types.
We have insecure components,
insufficient logging and monitoring,
and weak or default configurations.
Now, when we talk about insecure components,
what is this?
Well, it's really any code that's used or invoked outside
of the main program development process.
So, when you're dealing with this and you start dealing
with insecure components,
this can come from a lot of different areas.
For instance, it could come from code reuse.
Now, this is where you take one block of code
from somewhere else in the program, just copy and paste it
and use it again, or you take it from one application
and put it into another application.
A lot of times, people go on to stack exchange
and they'll go and copy people's code
and put it into their own.
Now, there's nothing wrong with doing that initially,
but if you're reusing code and you don't know if it's secure
or not, you could be bringing in vulnerabilities
into your program by doing that.
And so, this is why we consider it an insecure component.
Another thing we might use is a third-party library.
Anytime you bring in a library to do some function for you,
you are importing that code into your program.
And so, you might bring in a dynamic link library in Windows
or a shared object library in Linux,
and that might give you the ability
to do network connections or do cryptography.
But if those things were not secure,
you now brought that insecurity into your program.
And the third thing is software development toolkits.
Again, SDKs are really helpful as a programmer
because I don't have to go and create all
those prebuilt functions.
But if the person who built those prebuilt functions,
didn't do a good job,
you're bringing in those vulnerabilities as well.
And the other issue with these three areas is especially
with SDKs and third party libraries,
is sometimes they built it thinking it was good.
And then six months later, there's a vulnerability to it.
If you're using an old version of a library
or an old version of an SDK,
you aren't using the latest and greatest patched one,
and therefore, you're missing those security fixes,
and you're bringing in those insecurities into your program.
The second area we want to talk about
is insufficient logging and monitoring.
Now, this is any program that does not properly record
or log detailed enough information for an analyst
to perform their job when there's an incident that happens.
So, if I create a program and I don't have any kind
of logging and monitoring, well,
that's not going to be very good for my analysts
who have to deal with the instant response later.
So, we want to make sure we're always setting up our logging
and our monitoring to support our use case,
and that way, we can answer the who, the what, the when,
the where, and the how, when things go wrong.
Now, what is your use case?
Well, that's up to you and your organization.
You're going to determine how much logging you want,
how long you want to store it for, and all those details,
like we talked about back in our logging lessons.
The third area we want to talk about
is weak or default configurations.
Now, this is any program that uses ineffective credentials
or configurations or one in which the defaults
have not been changed for security.
When you're dealing with weak or default configurations,
there are lots of these things out there in the marketplace,
and they are running amok, in a lot of people's networks.
Now, many applications choose simply to run
as root or local admin, that's their default configuration.
You need to ask yourself,
does this program really need to be root?
Does this program really need to be an admin?
And if not, don't let it run that way
because you want to use least privileges.
Also, sometimes you have some of these programs
and by default, their permissions are really vague,
they're really permissive.
And so, they allow a lot of files and directories to be read
and write and execute it too,
and this would be a weak configuration.
Another place I see this all the time
is when we're using hardware appliances
or using some kind of software that has a password
and username already built in,
and it's often something like administrator administrator,
or admin admin, or root root.
This is a weak or default configuration
that should be changed immediately once
you install it into the environment.
Now, what's the best practice to prevent some of
these weaknesses?
Well, the biggest one is to utilize scripted installations
and baseline configuration templates
to secure your applications during install.
So, if I'm going to install some program,
there should be a security configuration template
or a scripted installation that actually goes through
and makes those things more secure.
This would be something that your organization does itself
or something provided by the manufacturer.