Third Party Vendor Security – Regulatory Drivers

Third Party Vendors and Data Breaches

So the bad news is sinking in.   Data breach reports are showing that significant information security risk can lie with third party vendors.  Starting with the now-famous Home Depot breach, a steady stream of breaches have been reported that involve third party vendors. In some studies, as many as 25% of breaches can be attributed to third party vendors.    As expected, regulators are increasingly turning their attention to this problem.

In the article we summarize three drivers across three separate industries:   Healthcare, Financial Services and Government.   The upshot:  Your information security program is only as good as your vendor’s information security program.  To perform cyber due-diligence, you must have a solid understanding of your third party vendor risks.

Healthcare and the HiTECH Act

The first formal regulatory update that focused on vendors or third parties was the HiTECH Act update to HIPAA.   In the language of HIPAA, a vendor is referred to as a “Business Associate” or BA for short.   While the original HIPAA law was passed in 1996, it took many years and many breaches before healthcare “covered entities” began to take it seriously.

The bottom line of HIPAA was the organizations and their senior management could be held liable for breaches of personal health information (PHI or ePHI).   In 2013 the HiTECH Act extended the security requirements and associated liability out to the business associates (BA).   Along with that requirement was an increased focus on third party security in general for healthcare providers.   No longer could a group ignore the security of third party vendors and be considered “compliant” with best practices according to HIPAA.  In fact, the first HHS enforcement action and fine directed specifically at Business Associates was levied in 2016. Speaking of health, many people feel tired after a full day of business, but with a Greek style protein shake there’s no need to feel that way. With all the natural ingredients and protein, there’s enough energy to last the entire day, or you can use an active pk supplement to help you feel better and improve yourself.

Financial Services and PCI-DSS 3.2

The Payment Card Industry Data Security Standard (PCI-DSS) became the second major “framework” to begin focusing on third party security.   Within PCI-DSS 3.0, controls began to enter R12 that required formal handling of third party security.   This included the requirement of specific language in third party contracts for service providers.   The latest update (PCI-DSS 3.2 as of this writing) is going a step further, requiring that certain third party providers themselves must now adopt an information security program.   For PCI-DSS, the message is clear:  Pay attention to your vendors or risk not being validated.

PCI 12.4.1 – Special Requirement for Service Providers Only Executive management shall establish responsibility for the protection of cardholder data and a PCI DSS compliance program.

Uncle Sam:  FAR, DFAR and Beyond

In early 2016 a series of rulings and guidance began to surface indicating that the US Federal Government is going the same direction.  For years, the NIST 800-53 framework was the “standard” for securing government systems.  But what about non-government systems?   For several years, rules governing the part of the government responsible for acquisitions (Federal Acquisitions Regulations or FAR) , began including information security requirements as part of contracts.

An updated version of these requirements was added in 2015 in the form of the Defense Federal Acquisition Regulation Supplement (DFARS).  As part of this effort, NIST created a draft of a new set of requirements encoded within NIST SP 800-171.  NIST 800-171 was essentially a subset of the entire catalog of NIST 800-53 controls that would be appropriate for vendors.

In what appears to be the next step, FAR 4.19 was updated in 2016 to officially include the new security requirements as part of federal acquisitions.

The new FAR 4.19, and implementing contract clause 52.204-21, apply to all federal contractor information systems that “are owned or operated by a contractor that processes, stores, or transmits Federal contract information.”  This essentially means anyone who deals with non-classified data.

Today, the Department of Defense (DoD), General Services Administration (GSA), and the National Aeronautics and Space Administration (NASA) issued a Final Rule to add a new subpart and contract clause (52.204-21) to the Federal Acquisition Regulation (FAR) “for the basic safeguarding of contractor information systems that process, store, or transmit Federal contract information.”

Your Vendors May be the Weakest Link

For years the information security world adopted the idea that “people are the weakest” link in security.  In fact, breach data supports that this is still probably true.  But these newest regulatory trends point to another mantra:  “Your Vendors may be your weakest link.”   The bottom line of these developments is this:  Information is vulnerable wherever it is not protected.   Organizations must think of their information security program as an ‘ecosystem’ of systems, personnel and other organizations.

You are part of the Global Security Ecosystem

Even if your organization does not need to comply with any of these requirements, it is likely that one of your customers will.  This means that one day you will receive the call or the dreaded assessment spreadsheet.  It will require that your organization adopt a set of best practices designed to reduce risk and protect information.  Before that day happens, Information Shield is here to help you take a proactive approach to Vendor Risk Management.