All right, vulnerabilities, again, can be
categorized as weak configurations, default installations, application flaws.
We actually have a slide for each one of
these, so let's go through them one at a time.
Okay, mis configurations or weak configurations.
Most systems installed with security or
functionality and ease of use in mind, not security.
So anything that's turned on that is not necessary should be turned off.
That would be a default configuration in secure protocols, open port services, open
permissions, unsecured root accounts, that thing.
Our default installation or default configurations, just talked about it.
And then application flaws.
We've become accustomed to patching our software.
It's just the way it is.
It's a fact of life that we're going to be applying software patches.
Vulnerabilities are discovered all the time.
Patches come out all the time.
Patches should be tested and deployed in a timely fashion.
Buffer overflows, memory leaks, resource exhaustion, DLL injection, etc.
There are tons of examples of application flaws.
In poor patch management, patches are again replacement code.
They need to be tested and applied.
Patches that are unapplied leave a system vulnerable.
And we've seen some pretty disastrous
results of poor patch management over the years.
Probably one of the most notable was a
certain credit bureau that had a certain number of million credit records
compromised for a patch that was over a month old, an Apache patch.
That was the Equifax data breach.
Our design flaws.
I know lots of developers and I have nothing but respect for developers.
I am not a developer, so again, kudos to
the developers, but man, they take a bad rap.
So we'll hear all sorts of examples of poor coding practices or sloppy
programming or design flaws, which sounds like the developers are sitting around not
taking their job seriously, which is not the case.
When you look at developing an application
and considering all the security issues, that's a lot to address.
So invariably, design flaws, programming errors are going to happen.
We have a lot of emphasis on secure
software development life cycles these days.
But back years ago, security was not the developer's responsibility.
It was somebody else's.
So design flaws or misuse case testing and so forth, it's definitely going to happen.
Operating system flaws.
The operating system itself may have
vulnerabilities which lead to exploitation.
Some of the best examples of this over the
years are things like the Microsoft SMB protocol issues.
You got Eternal Blue, you got MS 08067, the old RPC DECOM.
Invariably, you're going to find errors in
software, the operating system, drivers, services, applications, etc.
Our default passwords.
Default passwords should definitely be changed.
Why?
Because otherwise, people know what the password is.
You go online, you type in default passwords in Google, and you'll see a few
pages of websites dedicated to the catalog of default passwords.
Default passwords need to be changed.
Zero day vulnerabilities.
Zero day vulnerabilities are
vulnerabilities that have no fix, no security fix.
They're previously unknown, and as such,
no patch has been written, and zero day vulnerabilities are a favorite in the
underground, Dark Web, H acker underground, because there is no defense.
Those zero day exploits
are 100 % guaranteed to be successful since there's no fix for it.
Zero day vulnerabilities are unpatched vulnerabilities.
Legacy platform vulnerabilities.
When you've got obsolete or familiar codes, legacy platforms that are no longer
supported, then vulnerabilities go unpa cped.
So Microsoft every so often discontinues support for 2003, XP, Vista, and so forth.
In OT environments operational technology, you might still run into some Server 2003
operating systems which is no longer supported.
So any vulnerabilities discovered in that
OS are not being patched due to outdated or unsupported software.
System Sprawl or Undocuated Assets.
System Sprawl is where you've got a huge
number of services that get forgotten about.
They do different functions.
You've got partially used resources and so forth.
But when you stand something up and it doesn't make it into an inventory that can
qualify as sprawl or und documented assets.
When you've got systems on your network,
those systems are a potential attack point or attack vector.
Und documented means you're not taking into account the security when you do your
vulnerability management and you're not addressing the security risks.
Improper certificate and key management.
Certificates and key management may lead to vulnerabilities that allow attackers to
perform password cracking and data exfiltration tags.
We'll talk a bit more about certificates a
little bit later in the course, but outdated, expired certificates, not signed
by trusted publishers, these can definitely be problems.
Third party risks.
When third party services or products have access to privileged systems and
applications, through which financial information, customer and
employee data, and processes in enterprise supply chain can be compromised.
There's a lot of third party service
providers out there, a lot of as a services.
When those services become compromised, the data they have access to is
potentially compromised, and there you have it.
Vendor management, supply chain risk,
outsourced code development, data storage, cloud based versus on premise risks.
That's going to wrap up our first module.
We got a lot of vocabulary words out of that one, a lot of definitions.
Your course will have a little bit more detail and examples of when you read
through that on your second or third pass through.
That gives us some starter terminology to apply in later modules.
That's going to wrap us up for Module 1. Up next, Module 2.