By Mike Bridges
President and COO, Paperclip
Compliance has become the way we measure what cybersecurity actions are necessary to defend our electronic assets. The process of cybersecurity rulemaking and subsequent examinations for compliance (e.g., SOC2, ISO, SEC, FINRA, HIPAA) sets the roadmap for organizations.
Cybersecurity compliance embodies our collective institutions of standards via controls, rules, regulations, and laws—yet these institutions often have differing agendas and confused messaging.
What we do know is that cybercrime continues to grow despite the “Defense in Depth” approach we pursue today—often driven by compliance. We utilize a mix of products and services designed to play “hide and seek” without solving the challenge of data protection and privacy.
Epistemology is a philosophy that explores the nature and limits of human knowledge. It is concerned with one’s knowledge in relation to reality: what do I know and how did I learn it? In cybersecurity, our knowledge is what we learn from previous cyber-attacks. Yet, our reality is that we cannot successfully predict or prevent the next attack until it happens.
“We cannot solve our problems with the same level of thinking that created them.”
~Albert Einstein.
Encryption of all data, all the time must be the No. 1 requirement for cybersecurity compliance, and more important, action. Encryption greatly reduces the attack surface available to threat actors and protects the organization’s most critical asset, it’s data.
In a 2022 Ponemon study of nearly 6,000 individuals in 17 countries/regions, only 62% said their organizations have an overall encryption plan that is applied consistently across the entire enterprise[1]. Encryption is the best way to protect data in all stages—when data is transferred, when data is stored, and when data is in use.
Yet, compliance frameworks are behind on encryption, and until its more widely adopted we will continue to see a rise in data theft. Here are some of the ways we can change compliance to be more effective:
Encryption in Motion was first introduced in 2002 with SSL/TLS encryption. This use of encryption was to shut down the easy theft of data across the Internet. Google reported its adoption was 50% by 2013, and in 2023 has reached 95%. Compliance now requires encryption for data moving across the Internet but does not require the same for traffic inside the enterprise, the internal private network. Not securing the internal network makes it very easy for threat actors to conduct lateral movement throughout the entire enterprise consuming all plaintext traffic. Compliance needs to expand the use of Encryption in Motion beyond external communications to include internal communications.
Encryption at Rest has proven to be very effective for off-line data (e.g., removable media, backups, mobile, unstructured content) when proper key strength and key management is employed. Compliance does recognize that the exfiltration of encrypted data does not constitute a breach. Recently HIPAA HITECH expanded that “safe harbor” exemption to include the language, and the encryption keys were not exfiltrated.
Encryption in Use is the missing component—the solution that could significantly reduce cyber-attacks. Encryption in Use is defined as the ability to do computations on encrypted data while the data remains encrypted. Today at the end of everybody’s keyboard is plaintext data, or the online data necessary to conduct business. Computer systems need plaintext data to process, display, and report on. This is our business as our operations rely on the immediate availability of vast amounts of readily searchable data. For example, the customer service department for a mobile communications company relies on terabytes of data to be decrypted and ready as plain text just to respond to your billing request.
The reality is that computer systems only process a fraction of the data we store unencrypted in plaintext. Think of that customer service rep trying to display your billing information by searching for one record out of millions of possibilities. That’s millions of customers whose data, while stored in plaintext, is now exposed. This is an ideal data buffet for threat actors looking to steal sensitive data. With Encryption in Use, the customer service reps request would have searched encrypted data while only decrypting the single record requested, and only within that authorized application.
There are some encryption controls required by our leading compliance institutions, but they’re not explicit. Pay attention to the parsing of language that requires encryption action and evidence, specifically should/shall versus must; “should” is used to give advice, “shall” is considered may, as where “must” is mandatory.
The above table summarizes the requirements for encryption of the three states of data in motion, at rest, and in use.
Below is a list of common compliance frameworks, and my personal rating of their encryption requirements:
- 5 keys = Best – complete encryption requirement (rest, motion, in use)
- 4 keys = Better – complete encryption requirement (rest, motion)
- 3 keys = Good – partial encryption requirement (rest, motion)
- 2 keys= Bad – suggest encryption (rest, motion)
- 1 key = Worst – up to organization
GDPR – 2 keys
The EU’s General Data Protection Regulation (GDPR) is designed to protect an individual’s identity and privacy. GDPR, like others reference “state-of-the-art data protection” measures and only mentions encryption as a possible solution. They do recognize if encrypted data is stolen, it is not considered a breach.
Encryption in Motion
- GDPR refers to ISO/IEC 27001 for information security standards and other national IT-security guidelines.
- GDPR Art. 83(2)(c) authorities must positively consider the use of encryption in the amount of a fine imposed.
Encryption at Rest
- GDPR has no explicit encryption requirements; the regulation does require you to enforce security measures and safeguards to protect individual’s data and privacy. Organizations shall implement appropriate technology, policies, and procedures to ensure a level of security appropriate to the risk.
GDPR’s stance to rely on “state-of-the-art data protection” is sending a message to their companies and organizations to “please just do something.” GDPR does have extraordinary fining authority and to date have imposed over €4 billion. These fines against companies and organizations for weak cyber security practices could be mitigated in the future with effective and explicit requirements.
ISO 27001 – 2 Keys
International Organization for Standardization (ISO) is an organization of standards bodies from more than 160 countries. ISO 27001 is their information security standards, framework, and guidelines for establishing, implementing, and managing cybersecurity. ISO 27001 does not explicitly address cryptography, because cryptographic controls are governed across many countries with different relevant laws, legislation, and regulations. For instance, some countries may have certain restrictions on the use of cryptography, whereas others may prohibit its use altogether.
ISO 27001, A.18.1.5 Regulation of cryptographic controls[3]
Encryption and Motion
- The confidentiality of information being transferred on portable media or across networks must be protected by the use of appropriate encryption techniques.
- Encryption shall be used whenever appropriate on all remote access connections to the organization’s network and resources.
ISO 27001 does not clearly address cryptography; ISO is clearly vague because it focuses on the access process and not on specific requirements.
Encryption at Rest
- Classified information shall only be taken for use away from the organization in an encrypted form unless its confidentiality can otherwise be assured.
- Section 10.1.1 – A policy on the use of cryptographic controls for protection of information should be developed and implemented.
ISO promotes the establishment of security teams to build a process to identify risk and their cryptographic needs to mitigate this risk.
HIPPA – 3 keys
The US Department of Health and Human Services (HHS) created the Health Insurance Portability and Accountability Act (HIPAA) in 1996. Its primary goal was to stop the release of an individual’s medical records without their permission. Protected Health Information (PHI) is a highly valued target for threat actors because they can use your identity to see a doctor, get prescription drugs or to file claims with your insurance company in your name.
HIPAA Technical Safeguards, Security Rule (45 CFR §164.312)
Encryption in Motion
- (A-iv) Encryption and decryption (Addressable). Implement a mechanism to encrypt and decrypt electronic protected health information.
Encryption at Rest
- (E2-ii) Encryption (Addressable). Implement a mechanism to encrypt electronic protected health information whenever deemed appropriate.
HIPAA keeps its rules on encryption vague promoting best practices while citing technology is always changing every few years. HIPAA specifications are Required (e.g., must) or Addressable (e.g., stronger than should or shall). Addressable means you must address the specification in some way that mitigates the risk.
Protected data needs to be kept secure from breaches, and the best way to do that is to encrypt your data. Recently HIPAA released its standards and certification criteria for Electronic Health Records (EHR) solutions must be able to encrypt and decrypt health information in order to qualify for the Medicare EHR Incentive Program.
HITECH Act – 3 keys
The HIPAA “HITECH” Amendment, states that Cover Entities and Business Associates must, “Implement a mechanism to encrypt Electronic Protected Health Information (ePHI) whenever deemed appropriate.”
Encryption in Motion
- Implement security measures to ensure that electronically transmitted electronic protected health information is not improperly modified without detection until disposed of.
Encryption at Rest
- Encryption is left up to Covered Entities to determine appropriate and necessary use.
HIPAA’s mission is to protect individuals’ sensitive and identifiable health information, which is why they implemented requirements for encryption. HITECH encryption requirements are nonexistent or weak at best. They, like others, rely on security “best practices” as it is today. As we know, doing the same thing over again will yield the same results.
SOC 2 – 3 Keys
Service Organization Control (SOC 2) is a cybersecurity compliance framework managed by the American Institute of Certified Public Accountants (AICPA) and developed by Assurance Services Executive Committee (ASEC) subcommittee. A SOC 2 examination evaluates and reports on the controls your organization has implemented to safeguard customer data, along with other best practices that fulfill the trust service criteria. By demonstrating data at-rest (off-line) and data in-transit are properly encrypted, your organization demonstrates to your customers that their data will be secured.
Encryption in Motion
- Data should always be encrypted if it is “in transit” across public networks such as the internet. If data is “in transit” across non-public networks such as your internal systems, encryption is not required.[2]
Encryption at Rest
- Data “at rest,” information stored on removable media such as tape or USB drives, must be encrypted, however data on non-removable media such as servers is not required to be encrypted.
The control is very clear about encrypting off-line data removed from the enterprise but does not include off-line data stored on internal servers. There are no controls concerning online data.
- Detects Unauthorized Changes to Software and Configuration Parameters. Processes are in place to detect changes to software and configuration parameters that may be indicative of unauthorized or malicious software.
The next two standard bodies have done a good job in publishing requirements designed to protect sensitive data, credit cards and the electric grid.
PCI DSS – 4 keys
Payment Card Industry’s (PCI) Data Security Standards (DSS) require businesses to encrypt credit card account numbers saved in their databases as well as ensure that data remains secure when being transferred outside the company. PCI DSS 3.2.1 will be replaced by PCI DSS 4.0 on 3/31/2024 with clarifications about card data storage types, persistent or non-volatile storage and non-persistent or volatile storage. Persistent storage (e.g., servers, databases, cloud) must be encrypted. Non-persistent storage (e.g., CPU, RAM) does not require encryption but the data must be removed as soon as possible.
PCI Data Security Standard version 3.2.1:[4]
Encryption in Motion
- 4.1 Use strong cryptography and security protocols 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 to implement strong encryption for authentication and transmission.
Encryption at Rest
- 2.3 Using strong cryptography, encrypt all non-console administrative access
- 3.2 Do not store sensitive authentication data after authorization (even if it is encrypted).
- 3.5 Document and implement procedures to protect any keys used for encryption of cardholder data from disclosure and misuse.
- 3.6 Fully document and implement key management processes and procedures for cryptographic keys used for encryption of cardholder data.
PCI standards are well documented with enough detail whereby the vendor community can create solutions and have them PCI certified. PCI Security Standards Council (PCI SSC) has validated devices, components, software applications and services that have been assessed by a third party for compliance against corresponding PCI SSC.
Here’s one example of helpful detail, Persistent storage encryption includes but is not limited to hard disks, backup drives, removable storage media and further to identify types of data, event log files, history files, trace files, database contents, memory/crash dump files.
NERC CIP – 4 keys
North American Electric Reliability Corporation (NERC) is a not-for-profit international regulatory authority whose mission is to assure the effective and efficient reduction of risks to the reliability and security of the grid.
Encryption in Motion
- CIP-005-5: Cyber Security – Electronic Security Perimeter(s)
Wherever your organization’s data is stored, it needs to be properly protected with secure access points. A few key components in this standard are anti-malware updates, multi-factor authentication, and remote access encryption.
Encryption at Rest
- CIP-011-3Cyber Security — Information Protection Method(s) to protect and securely handle Bulk Electric System Cyber System Information (BCSI) to mitigate risks of compromising confidentiality. Implementation of electronic technical method(s) to protect electronic BCSI (e.g., data masking, encryption, hashing, tokenization, cipher, electronic key management).
NERC is another good example for detailing their encryption requirements. NERC is subject to oversight from the Federal Energy Regulatory Commission and are aligning themselves with FedRAMP standards.
The last two standards come from the US federal government and are considered cornerstones referenced through many other civilian and defense security certifications.
NIST 800-171 – 4 keys
National Institute of Standards and Technology (NIST) since the early 1900s have created laboratories to measure products and services and their adherence to standards. In 2014, NIST published its Cybersecurity Framework designed to reduce the risk of cyber-attacks.
NIST 800-171 stipulates that organizations must implement cryptographic controls for the protection of Controlled Unclassified Information (CUI).
Encryption in Motion
- 13.8, Implement cryptographic mechanisms to prevent unauthorized disclosure of CUI during transmission unless otherwise protected by alternative physical safeguards. Compliance does not require data in motion encryption for internal and private networks.
Encryption at Rest
- 1.19, Encrypt CUI on mobile devices, (laptops, tablets, mobile phones) that store CUI. Compliance does not require data at rest encryption for desktops or servers.
NIST standards go down the middle of the road—encryption for mobile devices and encryption for public communications but no requirements for internal encryption for storage or traffic, their guidance infers that perimeter security is adequate.
CMMC – 4 keys
The Department of Defense’s (DoD) Cybersecurity Maturity Model Certification (CMMC) is an assessment framework and assessor certification program designed to increase the trust in measures of compliance to a variety of standards published by the National Institute of Standards and Technology. CMMC is a cybersecurity maturity model rather than a regulation.
Encryption in Motion
- CMMC level 3 requires that encryption be used for data in motion (e.g., CUI, FCI, passwords, and more).
Encryption at Rest
- CMMC level 3 requires that encryption be used for data at rest (e.g., CUI, FCI, passwords, and more).
CMMC is a roadmap with five levels of maturity primarily used as requirements for government proposal request and contracting. Cybersecurity and Infrastructure Security Agency (CISA) has a similar maturity model whereby in their level 5 compliance they explicitly mention encryption in use, the only reference in this research addressing the concept of always encrypted.
Conclusion
Our cybersecurity standards institutions are failing us. They suffer from epistemic certainty. They use only their basic knowledge of cyber-attacks as a guide, then are surprised when the next attack happens. We are ignoring the repetition of the same outcome: stolen plaintext data.
“Insanity is doing the same thing over and over and expecting different results.”
~Albert Einstein
Rather than stay with the status quo, imagine a platform where the critical data was always encrypted. This level of encryption completely removes the value, and therefore the motivation, for threat actors.
Today most of our compliance focuses on cloud solutions and not on-premises infrastructures. The current movement to separate vendors into cloud solutions or on-premises solutions is emerging. The US federal government has the most stringent security requirements for cloud solution providers called FedRAMP. FedRAMP certification requires tested and approved devices, software, storage, and components.
Because organizations rely on cybersecurity standards institutions to mandate effective cybersecurity controls, these institutions must stop their passive aggressive approach to securing data and acknowledge that encrypted data is a paramount minimum for any truly impactful cyber-defense.
###
[1] Global Encryption Trends Study, PONEMON INSTITUTE, 2022
[2] Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy presents control criteria established by the Assurance Services Executive Committee (ASEC) of the AICPA, 2022
[3] American National Standards Institute, ISO/IEC 27001, 2022
[4] Payment Card Industry Data Security Standard version 3.2.1, 2018