Consider the payment brand requirement that service providers be PCI DSS compliant. Visa’s Cardholder Information Security Program details that, “In addition to adhering to the PCI DSS, compliance validation is required for all service providers.”[i] Similarly, MasterCard states, on its web page “Site Data Protection and PCI,” “MasterCard requires all Service Providers to be PCI Compliant.”[ii] Additionally, the Payment Card Industry (PCI) Security Standards Council (SSC) defines a service provider as a “business entity that is not a payment brand, directly involved in the processing, storage, or transmission of cardholder data. This also includes companies that provide services that control or could impact the security of cardholder data. Examples include managed service providers that provide managed firewalls, IDS and other services as well as hosting providers and other entities....”[iii]
Now, both Visa and MasterCard provide similar definitions of service providers. Nevertheless, data center and web hosting providers are frequently certain that they need not comply.
We just provide rack space and an Internet connection.
Ok - you have physical access to customer cardholder data environments, and you provide a perimeter firewall to protect facility and tenant Internet communications, right?
You’re a service provider.
We only provide a hosted website to our clients, who may or may not process cardholder data.
So, you manage a hosted application environment that includes initial provisioning and support for a shopping cart?
You’re a service provider.
Though, per Visa,[iv] it is the responsibility of issuers and acquirers to use and ensure merchant use of PCI DSS compliant service providers, I cannot recommend enough that both compliance and periodic risk assessment requirements be added to your organizational third-party access and/or risk management policies. No, an SSAE 16 report alone is not enough.
Consider also the final HIPAA Security Rule, which was issued in 2003 with a 2005 deadline for compliance. Therein, requirement §164.308(a)(1)(ii)(B) states that covered entities must “implement security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level to comply with §164.306(a).” The referenced §164.306(a) requirement further directs covered entities to:
(1) Ensure the confidentiality,
integrity, and availability of all electronic protected health information the
covered entity creates, receives, maintains, or transmits.
(2) Protect against any reasonably
anticipated threats or hazards to the security or integrity of such
information.
(3) Protect against any reasonably
anticipated uses or disclosures of such information that are not permitted or
required under subpart E of this part.
(4) Ensure compliance with this
subpart by its workforce.
As such, it is entirely within reason to conclude, when in the course of risk assessment it is learned that the organizational patch management standard requires quarterly patching with vendor supported applications provided unwritten exception, that risks and vulnerabilities are not being reduced to a “reasonable and appropriate” level that ensures compliance with §164.306(a). Nevertheless, many a covered entity believes that it is compliant, despite such a finding.
HIPAA does not include a specific patch management requirement.
True, but your server patch reports are identifying 89+ days’ worth of critical security patches, and our vulnerability scan results are identifying multiple high-risk vulnerabilities. You are not compliant.
The vendor does not support current patches.
Did the vendor sign a confidentiality agreement committing to protect sensitive data? Does the product as advertised cite tangible security benefits or regulatory adherence? Has your own organization agreed to hold the vendor harmless in the event of a breach? What does your patch management policy require again?
All of our peers of a similar size and complexity follow the same practice.
If one of your peers were to jump off a bridge…
And so it goes across a multitude
of regulations, standards, and frameworks.
Where one says “do not,” somebody has inferred an exception. Where one
says “ensure that,” somebody is certain that their efforts meet the requirement’s
spirit and intent.
Taking a serious approach to risk
management requires commitment. Ensuring
the security of the sensitive information within your custodianship requires
consideration of risk.
In the end, there is little better
than the process, based on the National Institute of Standards and Technology’s
(NIST) Special Publication 800-30, of considering the likelihood and impact of
a threat source or vulnerability when assigning risk, though the Common
Vulnerability Scoring System (CVSS) should not be discounted in the process. Further, compliance risks should near always
be considered as high impact.
To help one come to terms with the
frequently discomforting results of such efforts, perhaps we would each do best
to consider the following five questions as we endeavor to plan our mitigation
and compliance strategies with an eye toward what exactly is an “accepted” risk
and what is truly compliant.
1.
Does the strategy adhere to applicable standard,
framework, or regulatory requirements as written?
2.
Do you have a plan that clearly details what you
will do should the strategy not work?
3.
How would your actions affect customer and public
perception should they garner media attention?
4.
Is there anything more that can reasonably be
done?
5.
How would you feel if your own personal
information was being protected in such a manner?
