Don’t “Protect To the Regulation”

Sometimes sanitized as a “compliance-driven security framework,” implementing security measures to match regulations is a poor plan.

Visa’s Cardholder Information Security Program (CISP) and MasterCard’s Site Data Protection (SDP) require retailers, their third-party processors and anyone else who handles sensitive card data to meet specific requirements relating to the protection of payment data. While they have specific requirements, meeting these requirements is not an indemnification from civil action. For example, Heartland met the current requirements and was found liable.

Meeting requirements is like a school “teaching to the test.” A good education cannot be accomplished by teaching the material that will be on the test and nothing more. Responsible information availability, information confidentiality, information integrity and information authenticity (in aggregate, information security) cannot be accomplished by compliance with regulations.

• Regulations may be imposed by contract (e.g., PCI DSS), by state and federal legislation (e.g., SOX, HIPAA), or by case law (a “prudent person” or standard practice decision).
• Regulations change. Addressing today’s standards guarantees re-addressing your implementation later.
• Regulations exist to avoid the most egregious irresponsible behavior. Your goal is higher.
• A one-size-fits-all appropriate regulation would be difficult to write and soon obsolete. Your concerns include availability, confidentiality, integrity and authenticity, not just fines and criminal prosecution.

Note, for example, that with only PCI DSS regulations in mind, the FTC held TJX accountable for not implementing stricter and reasonable controls (such as stronger administrator passwords and encrypted wireless transmissions). State laws, notably Nevada Revised Statutes Title 597, Section 970 (NRS 597.970) and Massachusetts Privacy Law (MA 201 CMR 17) require encryption of personally identifiable information in transmission and at rest. See, for example, the ReveNews blog postings for June 8, 2009 and June 9, 2009. (Good news for encryption vendors and for Liquid Machines.)

Still, be familiar with specific applicable regulations, particularly with regard to audit requirements. For example, co-mingling systems that process PCI information with systems that do not will make the PCI audit larger and more expensive. Design to keep the audit simple. Include a mechanism which confirms that out-of-scope items are indeed out-of-scope.

Audit to the Regulation.