Handling Assessments with Vague Compliance Requirements

This article discusses how compliance regulations leave objectives open to interpretation and the methods to employ when approaching an assessment of a customer’s location.

Compliance is either straightforward with clear directions or “subject to interpretation”. Most compliance rules remain vendor neutral because configurations are situational. For instance, PCI requires a firewall when sensitive data traverses an open network. It does not dictate a specific manufacturer or configuration when fulfilling this objective.

An authoritative body assumes the following when a covered entity must satisfy a set of requirements:

Use technology to satisfy objectives when reasonable and appropriate.
Document implementation and justify decisions.
Prevent willful neglect.

The difficulty with compliance is the generalization of steps required to be compliant. Given the PCI example above, firewall hardware must be in place. It is a plain English requirement that satisfies the objective. Laws like Sarbanes-Oxley (SOX) and Gramm-Leach-Bliley Act (GLBA) do not have these requirements and require “institutions secure personal information”. How should institutions do this?

Government regulations often map to NIST standards such as Special Publication 800-53 (Recommended Security Controls for Federal Information Systems and Organizations) or 800-171 (Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations). The difference between these standards is the protection of information systems used within the federal government and the other is for unclassified information stored on third-party systems.

NIST standards go hand in hand with most compliance in the United States. They do the research, perform test scenarios, and establish the standard. This makes NIST 800-171 so important: it gives financial and legal institutions an IT security baseline. They may not have the know-how to do so themselves and a specialized technology provider can assist.

Use technology to satisfy objectives when reasonable and appropriate

Satisfying objectives may require implementing new technology. For instance, a compliance rule for the Payment Card Industry Data Security Standards (PCI DSS) states the following:

The first rule for PCI compliance confirms the installation and maintenance of a firewall. The objectives that follow set the ground rules for the necessary minimal functions of the firewall.

It is clear that meeting these objectives calls for proper edge hardware. Without a firewall, these requirements are not fulfilled and would be non-compliant. As shown in each objective, there is no defined configuration for firewall rules because they are situational. A small business who processes a handful of payments per month versus a chain retailer handling thousands of card transactions per minute would have their own unique setup.

Since compliance requirements do not specify a manufacturer, configuration, or cost limitations, an entity seeking approval can install what is necessary for their business needs. Does this mean a business can buy a $30 router from a retail store to protect its business transactions? Possibly, but it would need documentation and justification.

Document implementation and justify decisions

The other side of the coin is the justification of organizations compliance decisions. When asked to install a firewall, the goal is obvious. A firewall protects against unauthorized inbound and outbound network traffic. A firewall with zero customization is more secure than not having one at all. Specific conditions clear the fog surrounding the question “Does this meet the objective?”.

Another piece of the puzzle is complete documentation on why implementations meet the minimum requirements. For example, when the Office of Civil Rights (OCR) arrives at a doctor’s office for an audit, they are not there to schedule a future appointment. They are there to inspect two things on the spot: decisions made to secure the environment and the documentation justifying those decisions. Implementing technology without knowledge of what it does or if it is working is willful neglect.

The Health Insurance Portability and Accountability Act (HIPAA) notes a series of required and addressable standards necessary for compliance with the law. Section 164.308(a)(1)(i): Security Management Process, has a requirement called Risk Analysis with the following implementation specification:

Differing from the PCI specification of having a firewall in place, conducting an assessment under HIPAA is a requirement. Unsurprisingly, this is rather vague and poses many questions:

What is considered ‘accurate and thorough’?
Does the assessment have to be done in-house or a third party auditor?
What is considered a risk or vulnerability?
What format must the assessment be performed and documented?
What frequency can the assessment be performed?

These requirements remain open-ended, giving covered entities flexibility to secure their environment. A small medical practice could perform an assessment once per year while a large hospital chain would do this many times per year. There is no one size fits all configuration that entities must follow, providing the opportunity to scale if necessary.

Having the freedom to choose a means of protecting confidential data benefits the implementer as well. If a covered entity is relying on third party support to follow policies, they can use experience and skill to put proper safeguards in place. That said, industry knowledge of the technology installed can show justification for its purpose in the environment.

The HIPAA regulation has two types of implementation specifications: required and addressable. These specifications describe how flexible generic regulations can be when implementing technology. A direct quote from the Health and Human Services (HHS) Frequently Asked Questions:

What is the difference between addressable and required implementation specifications in the Security Rule? Answer: If an implementation specification is described as “required,” the specification must be implemented. The concept of "addressable implementation specifications" was developed to provide covered entities additional flexibility with respect to compliance with the security standards. In meeting standards that contain addressable implementation specifications, a covered entity will do one of the following for each addressable specification: (a) implement the addressable implementation specifications; (b) implement one or more alternative security measures to accomplish the same purpose; (c) not implement either an addressable implementation specification or an alternative. The covered entity’s choice must be documented. The covered entity must decide whether a given addressable implementation specification is a reasonable and appropriate security measure to apply within its particular security framework. For example, a covered entity must implement an addressable implementation specification if it is reasonable and appropriate to do so, and must implement an equivalent alternative if the addressable implementation specification is unreasonable and inappropriate, and there is a reasonable and appropriate alternative. This decision will depend on a variety of factors, such as, among others, the entity's risk analysis, risk mitigation strategy, what security measures are already in place, and the cost of implementation. The decisions that a covered entity makes regarding addressable specifications must be documented in writing. The written documentation should include the
factors considered as well as the results of the risk assessment on which the decision was based.( https://www.hhs.gov/hipaa/for-professionals/faq/2020/what-is-the-difference-between-addressable-and-required-implementation-specifications/index.html)

This information applies to the other legislation mentioned earlier: SOX and GLBA. The Safeguards Rule of GLBA “requires financial institutions under FTC jurisdiction to have measures in place to keep customer information secure.” And much like HIPAA, the elements are open to interpretation. An excerpt from the Elements (compliance objectives) clause shows this:

Employee training and management;
- Information systems, including network and software design, as well as information processing, storage, transmission and disposal; and
- Detecting, preventing and responding to attacks, intrusions, or other systems failures.

The Elements of GLBA are vague and leave room for interpretation. There is no solid path to a solution but signs that point an entity in the right direction. Conclusively, compliance comes down to reducing the overall risk of a data breach. A system 100% defensible against accidental data loss is close to impossible. Reducing the volume of risk is the end goal of compliance.

A key takeaway with any form of compliance is documentation. Documenting solutions and justifying its purpose is most important during an audit. Maintaining a list of objectives with justification reduces negligent security incidents. While it is not probable to prevent all incidents, it is possible to reduce the risk of malicious events.

Prevent willful neglect

When securing personal information, conducting proper due diligence is crucial for compliance. Failure to do so may impose hefty fines and jail time for those involved. The fines and penalties for regulations vary, but they contain a central theme: mess up, pay up. Financial penalties are generally used as a deterrent against willful neglect.

Regulations have their own penalties when a covered entity breaches regulatory law.

Sarbanes-Oxley (SOX), also known as the "Public Company Accounting Reform and Investor Protection Act" (in the Senate) and "Corporate and Auditing Accountability, Responsibility, and Transparency Act" (in the House).

Purpose: An Act to protect investors by improving the accuracy and reliability of corporate disclosures made pursuant to the securities laws, and for other purposes.
Penalties: Section 906 addresses criminal penalties for certifying a misleading or fraudulent financial report. Under SOX 906, penalties can be upwards of $5 million in fines and 20 years in prison, or both.

Gramm-Leach-Bliley Act (GLBA), also known as the Financial Services Modernization Act.

Purpose: An Act to enhance competition in the financial services industry by providing a prudential framework for the affiliation of banks, securities firms, and other financial service providers, and for other purposes.
Penalties: Imprisonment for up to 5 years, steep fines or both. A financial institution can be fined up to $100,000 for each violation; officers and directors can be fined up to $10,000 for each violation.

Health Insurance Portability and Accountability Act (HIPAA)
- Tier 1: Unaware of the HIPAA violation and by exercising reasonable due diligence would not have known HIPAA Rules had been violated.
- Tier 2: Reasonable cause that the covered entity knew about or should have known about the violation by exercising reasonable due diligence.
- Tier 3: Willful neglect of HIPAA Rules with the violation corrected within 30 days of discovery.
- Tier 4: Willful neglect of HIPAA Rules and no effort made to correct the violation within 30 days of discovery.

Purpose: An Act To amend the Internal Revenue Code of 1986 to improve portability and continuity of health insurance coverage in the group and individual markets, to combat waste, fraud, and abuse in health insurance and health care delivery, to promote the use of medical savings accounts, to improve access to long-term care services and coverage, to simplify the administration of health insurance, and for other purposes.
Penalties:

Every law is different from fines and penalties varying between industries. The financial rules are not as black and white when it comes to the type of violation: unaware or willful neglect. When an organization is unaware of a violation and fixes the issue, they are most likely to pay the monetary fine without jail time. Willful neglect is the lack of remediation of a known issue and will more likely end with fines and jail time for those aware of the violation.

When assessing and securing a customer’s site for compliance, here are some tips to remember:

Exercise proper due diligence by reducing the risk of a data breach.
Prevent willful neglect and remedy problems as soon as possible.
Report breaches to the proper authorities as required by the regulation.
Stress to the client that compliance is their responsibility.

Where To Go From Here

Assessing a customer site would be easier if defined standards already existed. Fortunately, NIST standards provide one of the best methods of helping a client reduce their risk. Below is a list of templates available in myITprocess to help MSPs audit and secure IT environments. Note that these recommendations are for non-federal systems.

NIST Special Publication 800-171 - Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations
NIST CyberSecurity Framework 1.1 - Framework for Improving Critical Infrastructure Cybersecurity
Center for Internet Security - CIS Controls 7.1 are global industry best practices endorsed by leading IT security vendors and governing bodies.
UK Cyber Essentials - Cyber Essentials is a simple but effective, Government-backed scheme that will help you to protect your organisation, whatever its size, against a whole range of the most common cyber attacks.

Complete list of Compliance Templates available for myITprocess (as of 5/2/19):

National Institute for Standards and Technology (NIST)

800-53 - Recommended Security Controls for Federal Information Systems and Organizations
800-171 - Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations
CSF 1.1 - Framework for Improving Critical Infrastructure Cybersecurity

Health Insurance Portability and Accountability Act (HIPAA)

United States legislation provides data privacy and security provisions for safeguarding medical information.

Personal Information Protection and Electronic Documents Act (PIPEDA)

A Canadian law relating to data privacy, it governs how private sector organizations collect, use, and disclose personal information in the course of commercial business.

Payment Card Industry Data Security Standards (PCI DSS)

The Payment Card Industry Data Security Standard (PCI DSS) is an information security standard for organizations that handle branded credit cards from the major card schemes.

Center for Internet Security Controls (CIS)

CIS Controls are global industry best practices endorsed by leading IT security vendors and governing bodies.

International Organization for Standardization (ISO)

ISO creates documents that provide requirements, specifications, guidelines or characteristics that can be used consistently to ensure that materials, products, processes, and services are fit for their purpose.

UK Cyber Essentials

Cyber Essentials is a simple but effective, Government-backed scheme that will help you to protect your organisation, whatever its size, against a whole range of the most common cyber attacks.

General Data Protection Regulation (GDPR)

The General Data Protection Regulation (GDPR) is a legal framework that sets guidelines for the collection and processing of personal information of individuals within the European Union (EU).

System and Organization Controls (SOC)

These reports are intended to meet the needs of a broad range of users that need detailed information and assurance about the controls at a service organization relevant to security, availability, and processing integrity of the systems the service organization uses to process users’ data and the confidentiality and privacy of the information processed by these systems.