Wednesday, July 18, 2012

Why You Don’t (Do) Need to Be Compliant

People generally don’t like to be told what to do. Worse, when they have made a strong commitment to what exactly they believe to be prudent, learning that they may have miscalculated along the way can be a gut-wrenching experience. In fact, when they are forced to confront absolutes that are fundamentally different from their established beliefs, the process of working toward resolution can at times prove quite difficult. As a result, individuals in assessor or auditor roles frequently become what I term “professional deliverers of bad news.” 

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?

No comments:

Post a Comment