Management, compliance & auditing

Security first: Compliance by design

Introduction

Whether it’s the General Data Protection Regulation (GDPR) or the New York Stop Hacks and Improve Electronic Data Security Act (NY SHIELD), nearly every regulation or industry standard that touches the IT department incorporates “security by design” or “privacy by design.” Meanwhile, organizations increasingly recognize that compliance is not equal to security or privacy. With that in mind, organizations should think about taking a “security first” approach to managing unauthorized access to sensitive data. This is a way to flip the model to “compliance by design.”

What does “security first” mean?

Most organizations with mature compliance and cybersecurity programs already incorporate some level of the “security first” approach to data protection. At the core, your security-first initiative should begin by focusing on how to secure information effectively, then review how the set controls align to mission-critical compliance requirements. 

How does “security first” enable a robust compliance posture?

By focusing on securing data before looking to compliance mandates, organizations can streamline their control settings and then align their actions to regulations or industry standards. Many compliance mandates set forth similar best practices for securing information. For example, take a look at the following compliance requirements:

GDPR Article 32(1)

Taking into account the state of the art, the costs of implementation and the nature, scope, context and purposes of processing as well as the risk of varying likelihood and severity for the rights and freedoms of natural persons, the controller and the processor shall implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk, including inter alia as appropriate:

1. the pseudonymisation and encryption of personal data
2. the ability to ensure the ongoing confidentiality, integrity, availability 

NY SHIELD Section 4, 2(B)(II)(B)

Reasonable technical safeguards such as the following, in which the person or business:

1. Assess risks in network and software design
2. Assesses risks in information processing, transmission and storage
3. Detects, prevents and responds to attacks or system failures
4. Regularly tests and monitors the effectiveness of key controls

Despite the differences in length and language used in these regulations, they both require organizations to undertake regular testing to ensure data processing security. Notice that neither defines specific controls that prove compliance. 

A security-first approach builds compliance into the process by design. If you secure your data and then review the compliance mandates that apply to your organization, you will likely see that you are already maintaining most of the regulation and industry standard controls. 

How to cross-map controls across multiple compliance requirements

Depending on your business and industry, you may need to comply with multiple standards or regulations spanning several areas. Highly regulated industries may focus on the most stringent compliance requirements first, then reverse-engineer their controls to other mandates. While this may be useful, it can also lead to inconsistency across the organization. 

Another concern facing organizations are the ancillary industry standards or regulations with which they need to comply. For example, in the healthcare industry, organizations often need to comply with the Health Insurance Portability and Accountability Act (HIPAA) and the Payment Card Industry Data Security Standard (PCI DSS). 

To ensure compliance with all mandates impacting your business, you should establish a process that aligns your risk-based controls to any specified controls affecting the organization. 

Create a compliance team of internal stakeholders

Although an organization’s security team may be assessing cyber risk and making controls suggestions, you might want to consider putting together a team consisting of IT and line-of-business professionals. IT departments often suffer from “shadow IT risk,” or risk arising from applications that users download to their word devices or personal devices. While many of these applications appear benign, they compromise both the organization’s security and compliance posture. 

Stakeholders on the compliance team should include:

• IT security staff
• At least one member of the senior leadership team
• Line-of-business managers who make IT decisions
• HR department staff

Each of these individuals brings a unique vision to the compliance team. In some cases, they understand the technologies that their staff use the most. In other cases, they may give you a clearer understanding of the ways in which their departments work toward securing data. 

Finally, different lines of business may have different data security requirements, so you should understand their needs to create a clear compliance cross-mapping. 

Identify and aggregate all regulations and industry standards in one location

Many organizations struggle with this step the most. They know the primary compliance requirements they need to meet, but many of those regulations and standards also encompass other frameworks. HIPAA, for example, incorporates the National Institute of Standards and Technology (NIST) framework, among others. 

When looking to consolidate compliance in a single location, you should engage in the following activities:

• Primary regulations for your organization’s industry
• Standards set by your organization’s industry
• Ancillary industry standards that impact your organization
• Cybersecurity frameworks referenced by the standards and regulations impacting your organization

The benefit of taking a security-first approach to compliance is that when mapping controls to the seemingly never-ending list of regulations and industry standards, you can find gaps more easily. 

Take HIPAA and PCI DSS for example. To accept payment, healthcare providers often need to accept credit or debit card payments, which requires them to comply with PCI. Let’s look at what they have to say about it:

HIPAA Encryption 45 CFR §164.3123

(a)(1)(iv) Encryption and decryption (Addressable). Implement a mechanism to encrypt and decrypt electronic protected health information. 

(a)(2)(ii) Encryption (Addressable). Implement a mechanism to encrypt electronic protected health information whenever deemed appropriate. 

PCI DSS Requirement 4

Cyber criminals may be able to intercept transmissions of cardholder data over open, public networks so it is important to prevent their ability to view this data. Encryption is one technology that can be used to render transmitted data unreadable by any unauthorized person.

4.1 Use strong cryptography and security protocols such as TLS, SSH or IPSec to safeguard sensitive cardholder data during transmission over open, public networks (e.g. Internet, wireless technologies, cellular technologies, General Packet Radio Service [GPRS], satellite communications). Ensure wireless networks transmitting cardholder data or connected to the cardholder data environment use industry best practices (e.g., IEEE 802.11i) to implement strong encryption for authentication and transmission. The use of WEP as a security control is prohibited.

Although both mandates discuss encryption, HIPAA’s Technical Safeguards leave the cryptographic method open to interpretation while PCI DSS spells out specific, required methodologies. 

Organizations complying with multiple regulatory and industry standard compliance requirements need to drill down into the detailed requirements that impact them and ensure that they integrate all required controls. 

Compare controls with most stringent requirements

Once organizations have gathered all compliance requirements into a single location, they can now create a list of required controls, best practices controls and current controls in effect. 

This is the “gap analysis” stage. If you started with a security-first approach, however, you likely have few gaps. Continuing with the HIPAA/PCI example, an organization that starting from a security-first position may already incorporate controls such as SSH/TLS protocols or 112-bit key strength. Under HIPAA and earlier PCI releases, 112-bit encryption met the compliance standards. 

However, the most recent release of PCI notes: 

The minimum cryptography requirements for transaction-based operations, as defined in PCI PIN and PTS, are more flexible as there are additional controls in place to reduce the level of exposure. It is recommended that all new implementations use a minimum of 128-bits of effective key strength.

If your organization needs to meet both HIPAA and PCI compliance requirements, you must ensure that you update to 128-bit encryption to maintain a robust posture. This is one example where starting with best practices from a security-first perspective gives you the opportunity to create a mostly-compliant security program but also highlights where gaps can occur as regulations and industry standards evolve when responding to new cybercriminal activities. 

Security-first compliance: Security for compliance by design

As cyber risks continue to evolve, security and privacy compliance requirements will also shift. Organizations taking a check-the-box approach to compliance may find themselves struggling as different regulations and standards require diverse controls. Additionally, compliance requirements leave room for cyberattack errors. 

Regulations and industry standards often lag behind technological advancements because they, by nature, integrate large bureaucratic processes. Committees must review research, work towards commonalities, balance user experience with security controls, and allow for comments on proposed changes. 

Cybercriminals, by nature, are distributed and non-bureaucratic. Therefore, they can continuously evolve their attack methodologies at a more rapid pace. With that in mind, organizations need to focus their compliance as a by-product of their security. Locking down data access and mitigating risk in real-time acts as a better compliance model. 

While security may not equal compliance, it does provide a stronger foundation, particularly with continuous monitoring and documentation of remediation strategies, for proving a robust approach to data protection. 

 

Sources

1. Art. 32 GDPR, Security of processing, Intersoft Consulting
2. Senate Bill S5575B, The New York State Senate
   • 164.312, govinfo.gov
3. PCI DSS Quick Reference Guide, pcisecuritystandards.org
4. Glossary, pcisecuritystandards.org