>> Vendor risk. The learning objectives
for this lesson are to explain vendor risk,
to perform vendor risk assessments,
and to explore the shared responsibility model.
Let's get started. Vendor risk.
You may have done everything that was necessary
to secure the network of
your enterprise but all companies
are doing business with other vendors.
Some of these vendors may even need to connect
to your network and have access to your data.
We need to make sure that they're doing
everything to protect that as well.
This creates a unique challenge
to us as security practitioners
because we don't have a lot of control over
their network and what they're doing.
I've mentioned this several times throughout the course,
but it bears mentioning again that
the Target hack all happened because of
the HVAC vendor that was connected to Target's network.
Target itself didn't get hacked
but they came in through the back door,
through the HVAC vendor into Target's network.
We want to really take care when
we're looking at doing business with another vendor,
especially if they're going to be
connecting directly to us.
The shared responsibility model.
This is where the responsibility for securing apps, data,
and the workloads that are in a Cloud environment
are shared between the customer
and the Cloud Service Provider.
Different areas will be assigned to each,
but identifying these and
ensuring they are being performed is critical.
Before you choose any level
of service in the Cloud model,
you want to be sure what you're responsible
for and what your Cloud
service provider is responsible for.
Then you can go about making sure that each of those
are doing the things that they are responsible for.
The Cloud service models,
we're going to begin with the software as a service.
This is the lowest level of responsibility
for the customer because the facilities,
utilities, the physical security, the platform,
and the apps are all the
responsible of the Cloud service provider.
They're simply giving you access to an app that's it.
You're not responsible for anything,
they're responsible for it all.
Next, we have platform as a service,
and this is where the OS and the apps are
now your responsibility as a customer.
Everything else still stays
with the Cloud service provider,
but those two are now under your control.
Then last we have infrastructure as a service.
This is where the CSP only provides
the infrastructure utilities and the physical security,
more of the responsibility
has now shifted to the customer.
Here's a good visual that will help
you understand this better.
You can see with a SaaS model that
the customer is not really responsible for anything.
We move over to the platform as
a service now they're responsible for
the apps and the OS
and then finally with the infrastructure as a service,
they're responsible for the platform,
the apps, and the OS.
This is a good visual to help you
see what level of responsibility based on
what service model so you
understand what you would be
responsible for and what
your CSP would be responsible for.
Vendor assessments. Whenever you're
looking to do business with a new vendor,
you want to make sure that you do
a proper vetting on that new vendor.
You might want to look at, for example,
have a third-party audit and
other proof that that vendor is stable,
that their finances are good,
and just what are their cybersecurity capabilities.
Now, depending on what type of vendor it is and
what level of access to
your network and your data they have,
will determine how thorough
this vetting process would be.
Here are some considerations
that you want to think about when
you're choosing a new vendor. Vendor lock-in.
This is when the customers are
completely dependent on the vendor
because changing is either
too expensive or it's impossible.
Before you go into a relationship with a new vendor,
you want to make sure is this going to happen to us?
If that's what you're looking for,
if that's not a problem, just make
sure that it's not a surprise for you later.
Vendor lockout. This is when
a vendor's product will not
work with other vendors' products.
They will not allow it to integrate and that could
cause problems if you need that level of integration,
you need to know this going in. Vendor viability.
Will a vendor be in business in the future?
Are they growing or expanding in their field?
You want to make sure that before you allow this,
that are they going to be purchased by someone else
or are they even going to be here in two years?
Source code escrow.
This is where the vendor-developed products
have their source code placed at
a third party so that it is
available should they go out of business.
Support availability.
What is the level of support
that that vendor will provide?
What is the service level agreement?
How fast will they respond?
You want to make sure all this is documented out before
you engage in any agreement with them.
Meeting client requirements.
These are the formal measures
that are used to evaluate if
the vendor's products or
services meet the needs of the customer.
Then also we want to consider
their incident reporting requirements.
How and how quickly will the vendor notify
the customer of any incidents at the vendor,
such as breaches or downtime?
You want to make sure that you understand
that especially if they have access
to your data in a HIPAA situation, for example, PHI,
if a third party to a covered entity,
which is the grouping that
HIPAA law relates to
the third party known as a business associate.
If they were to have a breach,
it goes straight up stream
back to the covered entity and they're responsible.
You want to make sure that that business associate
is letting the covered entity
know about that breach since
ultimately the covered entity will also be responsible.
You want to ensure that if your vendor has
a breach and somehow impacts you,
you want to know about it.
There's also geographic considerations.
Globalization has increased how vendors may be spread
out over a number of countries and each of
those countries will have their own laws
on the data security,
privacy, and even copyright.
Legal jurisdictions have become extremely important,
especially with compliance frameworks like
the GDPR. Instructor side note.
I once worked with a medical provider
who had outsourced his billing
operations to an Indian firm.
This is quite common now,
but at that time it wasn't a common thing.
It was still fairly unheard of and it was because they
were very inexpensive compared
to billers here in the United States.
Their billing company had an employee that
for whatever reason decided that he wasn't paid
enough and wasn't paid fairly from
the billing company in
India and instead of trying to work it out,
he decided to steal all of the data for
the different sites they were doing billing for.
It took over six months for
the billing company to let
the medical provider know about this.
But that is a breach under
HIPAA because now that information,
that PHI is outside of the direct control
of this billing company
and it is now considered a breach.
But because this was a company overseas and again,
this was back when this wasn't common,
the medical provider had no recourse because he
couldn't do anything against that company
and he had no way to get it resolved.
If that company chose not to pay,
then the data was never going to be given back and it was
a very messy situation and ultimately, against my advice,
this provider chose not to report this
as a HIPAA breach, but unfortunately,
it was 40,000 plus
patient's data that had been
stolen and they chose not to do it.
That includes all the credit
card numbers that might have been used,
all those social security numbers,
all of that was now in the hands of
this one individual that was already disgruntled.
Vendor assessment tools.
Once you've established a relationship,
you need to consider doing
an ongoing assessment of the vendor
just to make sure that they're
staying within the bounds of your agreement.
Vendor policies are the levels
of service and the expectations from the customer.
These should be monitored for
compliance on a regular basis.
Supply chain diversity.
Supply chain includes all of the suppliers,
vendors, and partners that are
used to deliver a product to the market.
Many of the most notable breaches in
history have come from supply chain attacks.
Supply chain visibility is understanding how all
of the vendor-supplied parts and
services are produced and delivered.
Also, how they will impact
your organization's operations or your finished products.
Third-party assessments.
A third party assessment is performed by
another party different from the vendor.
An objective view of the vendor's stability and
capabilities is the goal of this assessment.
Here are some examples.
The Cloud Security Alliance, CSA,
security trust and risk, or Star.
This is the ability of a CSP to
adhere to the key principles in transparency,
auditing and best practices for security.
The system and organization controls or SOC.
This uses standards created by
the American Institute of Certified Public
Accountants for the evaluation of policies,
processes, and procedures to
protect technology and financial operations.
These are both third party
services they could come in and
evaluate your vendor to ensure that
they're adhering to their level of responsibility.
We also have the International
Organization of Standards, ISO.
They'll do an audit of compliance with ISO 27,000 for
cybersecurity and then you have
Cybersecurity Maturity Model Certification, CMMC.
These are standards created by
the US Department of Defense to help fortify
the DoD supply chain by requiring suppliers to
prove they have a mature cybersecurity capability.
Vendor technical considerations.
When we're looking to choose a vendor,
there are some technical things that
we also want to give some thought to.
Testing and evaluation allows
us to ensure that the vendor
and/or their products are meeting
the service level that we are expecting it to be.
Is the product working the way we want it to?
Is the service performing the way we need it to?
Network segmentation is where we want
to ensure that the systems that are managed
by vendors should be
isolated from the rest of the organization's network.
Transmission control ensures that
any connection between the customer and
the vendor is secured
and free from being intercepted or infiltrated.
This may be a good example of using a VPN.
Then shared credentials should be a no-no.
Every vendor employee should have
their own unique account on any customer resources.
This establishes accountability for
any activity that is done on
customer devices by the vendor.
You don't want an account just named vendor for example,
where all the employees of
the vendor can log in remotely.
It needs to be a specific account
where it's first name, last name,
or whatever so that anything
that happens can be tracked back to
that specific individual rather than
just a generic vendor company name.
Let's summarize. We went over vendor risk.
We also discussed the shared responsibility model
and the different Cloud service types.
We went over vendor assessments and what
globalization means for all of this.
Then we went over vendor assessment tools.
Let's do some example questions.
Question 1, this describes
when a product does not allow integration
with third party products or services. Vendor lockout.
Question 2, all of the suppliers, vendors,
and partners needed to deliver a product
or service. Supply chain.
Question 3, the blank was
developed by the US Department of Defense to
ensure Department of Defense suppliers
had a mature security program.
Cybersecurity Maturity Model Certification or CMMC.
Finally Question 4,
the ability to understand
how all vendor-supplied parts are
produced and delivered and how this
impacts an organization's operation is.
Supply chain visibility or SCV.
Hope this lesson was helpful for
you, and I'll see you in the next one.