Narrator: In this lesson,
we're going to talk about legacy systems.
What is a legacy system?
Well, I like to think about a legacy system
as something old.
It's a computer system that's no longer supported
by its vendor, and so no longer can be provided
with security updates and patches.
For instance, if you work in a manufacturing plant,
there might be some system that is critical
to your operations, but it is 20 or 30 years old,
and the person who made that is no longer in business.
Well, you're not going to get
any more security updates or patches for that thing,
but it still works and it still runs,
and it might cost you millions of dollars to replace it.
So what do you do?
Well, you don't patch it, instead,
you start finding compensating controls,
like isolating it onto its own network and things like that
to make sure that that system can keep running
and keep the business operating.
So when we're dealing with legacy systems,
we're dealing with these old systems
that are no longer supported.
A great example of this is if you just look down
into your ICS and SCADA networks,
most of these have outdated things that are still being run.
For example, many of them are still running on Windows XP.
Now, as I'm filming this, I'm already into the 2020s,
and yet Windows XP, which came out all the way back in 2001
is still being talked about.
Why?
Because Windows XP is still in use today,
even though it's end of life,
even though it's end of service,
people still use it in these legacy systems.
The reason is it's too expensive
or too hard to get it out of those networks.
So instead, as security analysts, we have to identify
these legacy systems and put mitigations in place
so we can keep operating them.
Things like making sure those systems
don't connect to the internet.
Instead, we want to make sure we have
additional layers of security.
We want to have firewall in place.
We want to have segmentation and other things like that
to minimize the risk of these legacy systems.
On the other hand, we have another category systems
that are often not supported well,
and these are proprietary systems.
Proprietary systems are systems that are owned
by its developer or vendor where the lack of vendor support
could be an inhibitor to your remediation.
Now, what do I mean by this?
Well, I have a couple of proprietary systems in my business.
It's particular software that we have had coded
by a developer.
Now, it's a third party company,
and so if we need to have updates and security done,
we have to contract them again to get them to support it
because we pay them and they fix the system.
Now that's one simple example of a proprietary system,
but there's actually larger ones too.
For example, if you look at the US Department of Defense,
they've got lots of proprietary systems,
not anyone can just go out and buy
an F16 or an Abrams tank.
These all have different systems
that were built specifically for that purpose,
and so they can't go to Microsoft and say,
"Hey, give me a patch for an Abrams tank."
Instead they have to go back to that original vendor,
and depending on the contract they have
in place with that vendor,
they might get monthly updates, or every six month updates,
or every year updates, or as required updates.
And so that can actually inhibit your remediation
because if you're on a six month cycle
and you identify a vulnerability today,
it might take six months for them
to code you a patch and then send it to you.
So these are issues you have to think about
when you're dealing with proprietary systems.