Security Compliance Models: Checklists vs. Risk

Introduction

There are various of security compliance models that organizations can implement to do business legally and lawfully, adhere to industry standards and appeal to the consumer choice. Each security and compliance model is meant to address specific areas and domains of business. There are models that are required by law, others provide a generic and broad framework that organizations need to define and carve out for their operations, and models that that can be implemented as-is with a few or no changes to a compliance checklist. In this document we take the Health Insurance Portability and Accountability Act (HIPAA), Payment Card Industry Standard (PCI) and Gramm-Leach-Bliley Act (GLBA) security and compliance models, categorize them as risk, checklist or hybrid model and provide relevant information to support the categorization.

Scope

Fig. 1 Security and Compliance Models in scope for this document.

HIPPA - Health Insurance Portability and Accountability Act

Summary

HIPPA, enacted August 21, 1996 by United States Congress and President Bill Clinton, Title I of HIPAA protects health insurance coverage for workers and their families when they change or lose their jobs. Title II of HIPAA, known as the Administrative Simplification (AS) provisions, requires the establishment of national standards for electronic health care transactions and national identifiers for providers, health insurance plans, and employers. [1]

At the same time, Congress recognized that advances in electronic technology could erode the privacy of health information. Consequently, Congress incorporated into HIPAA provisions that mandated the adoption of Federal privacy protections for individually identifiable health information.[2] HSS published a set of rules for Privacy, Security, Enforcement and enacted a final omnibus rule that implements number of provisions of the Health Information Technology for Economic and Clinical Health Act (HITECH Act) [3]

Reasons for the Act

The reason the regulators decided to create a law instead of standards is because they wanted a way to govern the behavior of organizations towards the people’s personal health information. A standard would not have been enough to ensure compliance by the healthcare and related industries. A standard I believe is more effective for products rather than services.

The primary reason for the (AS) provisions is protect against misuse and disclosures of PHI.[2] Under the patchwork of laws existing prior to adoption of HIPAA and the Privacy Rule, personal health information could be distributed—without either notice or authorization—for reasons that had nothing to do with a patient's medical treatment or health care reimbursement. For example, unless otherwise forbidden by State or local law, without the Privacy Rule patient information held by a health plan could, without the patient’s permission, be passed on to a lender who could then deny the patient's application for a home mortgage or a credit card, or to an employer who could use it in personnel decisions. The Privacy Rule establishes a Federal floor of safeguards to protect the confidentiality of medical information. State laws which provide stronger privacy protections will continue to apply over and above the new Federal privacy standards. [4]

Implementation and Audit

1. HHS Security Risk Assessment Tool
2. NIST Cyber Security Framework for HIPPA
3. FTC guidance on Medical Identity theft

HSS Audit Protocol - The OCR HIPAA Audit program analyzes processes, controls, and policies of selected covered entities pursuant to the HITECH Act audit mandate. OCR established a comprehensive audit protocol that contains the requirements to be assessed through these performance audits. The entire audit protocol is organized around modules, representing separate elements of privacy, security, and breach notification. The combination of these multiple requirements may vary based on the type of covered entity selected for review. [6]

PCI– Payment Card Industry - Security Standards

Summary

PCI are a group of standards mandated by the PCI Security Standards Council for the safety of cardholder data across the globe.  Maintaining payment security is required for all entities that store, process or transmit cardholder data. Guidance for maintaining payment security is provided in PCI security standards. These set the technical and operational requirements for organizations accepting or processing payment transactions, and for software developers and manufacturers of applications and devices used in those transactions [7]

Maintaining payment security is serious business. It is vital that every entity responsible for the security of cardholder data diligently follows the PCI Data Security Standards. PCI – PTS for Manufactures creating pin entry devices, PCI PA-DSS for Payment Application and Software developers to adhere to data security standards and PCI DSS secure environments for data security by merchant security providers. [7]

Reasons for the Standards

The reason the regulators, in this case certain players within the banking and ecommerce industry decided to create a set of standards is because they wanted a set of guidelines for protecting their own and the customer interest using the payment cards and related services. As per the PCI security standards council the primary reason for the standards is to protect payment card data from criminal threats and to minimize data breach risk to merchants of all sizes and prevent potential liabilities [8] For example -

1)     Loss of customer confidence in secure payments leading to loss of sales

2)     Reduce cost of reissuing payment cards

3)     Reduce fraud loss because of compromised payment card data

4)     Reduce legal costs, settlements and judgements and fines and penalties

Implementation and Audit

We will use PCI DSS as an example for implementation. The PCI DSS version 1.2 is the global data security standard adopted by the card brands for all organizations that process, store or transmit cardholder data.  It consists of common sense steps that mirror best security practices. [9]

Depending on an organization’s classification or risk level (determined by the individual card brands), processes for validating compliance and reporting to acquiring financial institutions usually follow this track:

·       PCI DSS Scoping – determine what system components are governed by PCI DSS

·       Sampling – examine the compliance of a subset of system components in scope

·       Compensating Controls – QSA validates alternative control technologies/processes

·       Reporting – merchant/organization submits required documentation

·       Clarifications – merchant/organization clarifies/updates report statements (if applicable) upon bank request

Tools for assessing Compliance with PCI DSS The PCI SSC sets the PCI DSS standard, but each card brand has its own program for compliance, validation levels and enforcement. [9]

American Express: www.americanexpress.com/datasecurityDiscover Financial Services: www.discovernetwork.com/fraudsecurity/disc.htmlJCB International: www.jcb-global.com/english/pci/index.htmlMasterCard Worldwide: www.mastercard.com/sdpVisa Inc: www.visa.com/cispVisa Europe: www.visaeurope.com/ais

Qualified assessors. [9]

The Council manages programs that will help facilitate the assessment of compliance with PCI DSS: Qualified Security Assessor (QSA) and Approved Scanning Vendor (ASV). QSAs are approved by the Council to assess compliance with the PCI DSS. ASVs are approved by the Council to validate adherence to the PCI DSS scan requirements by performing vulnerability scans of Internet-facing environments of merchants and service providers. Additional details can be found on our Web site at: www.pcisecuritystandards.org/qsa_asv/find_one.shtml

Self-assessment Questionnaire. [9]

The “SAQ” is a validation tool for organizations that are not required to undergo an on-site assessment for PCI DSS compliance. Different SAQs are specified for various business situations; more details can found on our Web site at:  www.pcisecuritystandards.org/saq/index.shtml. The organization’s acquiring financial institution can also determine if it should complete a SAQ.

GLBA - Gramm-Leach-Bliley Act (Financial Services Modernization Act of 1999)

Summary

GLBA, enacted November 12, 1999 by United States Congress. It repealed part of the Glass–Steagall Act of 1933, removing barriers in the market among banking companies, securities companies and insurance companies that prohibited any one institution from acting as any combination of an investment bank, a commercial bank, and an insurance company. [10]

Reasons for the Act

The reason the regulators decided to create a law instead of standards is because they wanted a way to regulate mergers of financial institutions providing various financial services and govern the behavior of these institutions towards the people’s financial information.

1)     Many of the largest banks, brokerages, and insurance companies desired the Act at the time. The justification was that individuals usually put more money into investments when the economy is doing well, but they put most of their money into savings accounts when the economy turns bad. With the new Act, they would be able to do both 'savings' and 'investment' at the same financial institution, which would be able to do well in both good and bad economic times.[11]

2)     The removal of these regulations, raised significant risks that these new financial institutions would have access to an incredible amount of personal information, with no restrictions upon its use. Prior to GLBA, the insurance company that maintained your health records was distinct from the bank that mortgaged your house and the stockbroker that traded your stocks. Once these companies merge, however, they would have the ability to consolidate, analyze and sell the personal details of their customers' lives. Because of these risks, the GLBA included three simple requirements to protect the personal data of individuals: First, banks, brokerage companies, and insurance companies must securely store personal financial information. Second, they must advise you of their policies on sharing of personal financial information. Third, they must give consumers the option to opt-out of some sharing of personal financial information.[12]

Implementation and Audit

There are three main objectives of GLBA 501(b) that companies need to meet.[15]

·       501(b)(1): Ensure the security and confidentiality of customer records and information

·       501(b)(2): Protect against any anticipated threats or hazards to the security or integrity

of such records.

·       501(b)(3): Protect against unauthorized access or use of such records or information

which could result in substantial harm or inconvenience to any customer.

In order to meet these objectives, a company will need to develop an Information Security Program and Plan.

1)     The FTC issued Safeguards Rules which requires financial institutions under FTC jurisdiction to have measures in place to keep customer information secure. By safeguarding customer information, the financial institutions abide by the law and it also makes good business sense. When the institutions show customers they care about the security of their personal information, they increase their confidence in their company.[13]

2)     ISO 17799 is a good reference for implementing a financial institutions security strategy. establishes guidelines and general principles for initiating, implementing, maintaining, and improving information security management in an organization. [14]

3)     The NIST publications especially 800-68 Rev 1 provide guidance on securing computer systems for IT professionals. [18]

Conclusion

We started with understanding each of the security models, HIPAA, PCI and GLBA. While HIPAA and GLBA are legally binding in their respective domains of healthcare and finance the PCI is more of an industry standard that has come about as a need for reducing legal, operational and sales costs and driving customer confidence by payment card industry.

We found that for HIPAA and GLBA there are many risk based frameworks available to assess and manage risk and implement controls and policies for information security. The abundance of such frameworks also makes it difficult to pick the right one for the given business and makes it more difficult to audit compliance. There is FTC and HHS providing guidance and safeguard rules but the implementation and audit of the frameworks is tedious.

In case of PCI because it is an industry standard that provides specific and clear guidelines, essentially a checklist by the PCI Security Standards council it is much easier to implement and audit.

My personal inference is that wherever there is a need to protect the rights and privileges of citizens a risk based security model is more effective because it allows for broad scenarios of abuse of power and information to be addressed and mitigated. Where there is a need to satisfy a requirement or many requirements that allows business to work together using common controls, technology and infrastructure a checklist type of security model will be required and more effective. I also believe that these security models can be used together as hybrid models to create more specific, measurable and effectivity information security policies.

References and citations

Health Insurance Portability and Accountability Act -https://en.wikipedia.org/wiki/Health_Insurance_Portability_and_Accountability_Act

HHS.gov HIPAA for Professionals - http://www.hhs.gov/hipaa/for-professionals/index.html

HHS.gov Why is the HIPAA Privacy Rule needed? - http://www.hhs.gov/hipaa/for-professionals/faq/188/why-is-the-privacy-rule-needed/index.html

HHS.gov The Security Rule - http://www.hhs.gov/hipaa/for-professionals/security/index.html

HHS.gov Audit Protocol – Current http://www.hhs.gov/hipaa/for-professionals/compliance-enforcement/audit/protocol-current/index.html

PCI Security Council https://www.pcisecuritystandards.org/pci_security

PCI WHY SECURITY MATTERS? https://www.pcisecuritystandards.org/pci_security/why_security_matters

PCI Quick Reference Guide https://www.pcisecuritystandards.org/pdfs/pci_ssc_quick_guide.pdf

Gramm–Leach–Bliley Act - https://en.wikipedia.org/wiki/Gramm%E2%80%93Leach%E2%80%93Bliley_Act

EPIC.org The Gramm-Leach-Bliley Act https://epic.org/privacy/glba/

Financial Institutions and Customer Information: Complying with the Safeguards Rule https://www.ftc.gov/tips-advice/business-center/guidance/financial-institutions-customer-information-complying

ISO/IEC 17799:2005 http://www.iso.org/iso/catalogue_detail?csnumber=3961

NIST.gov Guide to Securing Microsoft Windows XP Systems for IT Professionals http://csrc.nist.gov/publications/PubsSPs.html#800-68