Data Encryption in Finance
Regulatory Compliance Is Always a Smart Investment
Today, encryption is a staple of the professional world, as virtually every industry that deals with personal and/or sensitive data relies on encryption to protect that data. Those that don’t encrypt put themselves at risk for stiff government penalties, fines, lawsuits, and more.
In the world of finance, data security is serious business, and there are plenty of regulations, both domestic and international, that companies should and must heed. So, as client and customer bases grow across borders, maintaining compliance is an even larger beast to tame. Furthermore, small businesses shouldn’t fall prey to the assumption that multinational corporations are the only entities that need to be worried about complying with regulations. Breaches can happen just as easily, if not more so, to small operations, resulting in massive fines, expensive lawsuits, and vanishing customers, or more likely, all three.
Markets fluctuate daily, but regulations and their associated encryption requirements aren’t as fickle. To put it in business terms, encryption is just another type of risk management, and those that know how to properly assess and manage risks usually succeed. Understanding the basics of encryption in finance, where data “lives” and how it moves, is the difference between what a business must do and what it (really) should do, and how all of this helps financial organizations to stay on the right side of relevant regulations.
Taking Stock of Encryption in Business and Finance
When discussing the regulations that govern how financial institutions protect sensitive data, the regulation on most experts’ tongues is the Gramm–Leach–Bliley Act (GLBA, colloquially pronounced “glibba”). Passed in 1999, the GLBA was a major change for banks and other financial institutions in that it established and mandated a framework to make these institutions keep their clients’ data private. Institutional penalties for GLBA infractions can run up to $100,000 per violation, and an institution’s officers and directors can be individually fined $10,000 per violation. Additionally, jail time may result if a violation is deemed a criminal act, so complying with GLBA should be a top priority.
The key text of the GLBA where encryption is concerned is §6801 of Title 15, Chapter 94, Subchapter I. It stipulates that institutions must “insure the security and confidentiality of customer records and information, protect against any anticipated threats or hazards to the security or integrity of such records, and protect against unauthorized access to or use of such records or information which could result in substantial harm or inconvenience to any customer.”
Although there’s no direct mention of encryption, the phrase “anticipated threats” clearly identifies the need for it. Encryption at multiple levels will help protect customer data. For data at rest, whole-disk encryption is ideal (particularly on mobile devices and other forms of portable storage), while folder-level encryption may be suitable on servers where customer information is isolated to specific folders. Databases should be encrypted as well, and the best practice for accessing sensitive data remotely is to use a VPN.
Another critical regulation is the Sarbanes-Oxley Act (SOX). Slightly newer than GLBA, SOX arose largely in response to instances of corporate accounting malfeasance at the turn of the century, particularly the Enron and WorldCom scandals. The focus of SOX isn’t strictly encryption, but there’s enough focus on safeguarding data that encryption can’t be ignored. SOX sections 302 and 404 are most relevant to encryption. In short, these passages require public U.S. companies to report their financial information accurately and disclose any information pertaining to employee fraud. Additionally, companies must disclose any shortcomings in the internal control of this information, as well as any changes to those internal controls.
Encryption and data security play a vital role in this internal control since they can show that a company’s relevant financial information hasn’t been tampered with and that only approved individuals can read it. As far as the IT side of compliance is concerned, the preferred framework most businesses turn to is COBIT. Within COBIT, a series of controls known as DS5 provide guidance for SOX compliance. DS5, and in particular DS5.7, DS5.8, and DS5.11 deal with encryption. When financial data is in transit, it should be encrypted, and a business needs to carefully manage who has access to cryptographic keys.
Finally, businesses involved with the securities industry should familiarize themselves with the Financial Industry Regulatory Authority (FINRA), successor to the National Association of Securities Dealers (NASD). Although FINRA isn’t a regulatory agency within the government itself, it does act with the authority of Congress, so its requirements carry a lot of weight. To wit, in 2015 alone FINRA socked brokers and firms with $95 million in fines. FINRA’s procedures, as described by the Securities and Exchange Commission’s Regulation S-P, specifically §248.30, borrow their language word for word from the key text of the GLBA. Hence, the best practices for complying with GLBA should spare securities firms from FINRA’s wrath, as well.
The important regulations, and the considerable fines associated with non-compliance, rather decisively lay out the need for encryption to maintain the security of sensitive data. However, the issue of how precisely to do so isn’t as clear cut. Despite this, businesses can find solid, established recommendations for putting an encryption plan in place. As an example, the National Institute of Standards and Technology (NIST) Special Publication 800-111 sets forth encryption best practices for a number of end user scenarios. The document recommends using AES encryption and urges organizations to consider stronger algorithms and larger key sizes as they become available.
The U.S. government relies on FIPS 140-2 to validate the strength of various encryption solutions, and the Federal Information Processing Standard Publication 140-2 (FIPS 140-2) authenticates the security of cryptographic modules. Within FIPS 140-2 stand four levels of increasing security. Level 1 requires that a solution use an approved algorithm or security function; the device itself requires no physical security. Level 2 requires a form of physical security that can present evidence of an unauthorized access attempt, such as a tamper-proof seal. A Level 3 solution provides a countermeasure that thwarts access, use, or modification of the cryptographic module if the solution itself detects a physical breach. Level 4, the pinnacle of FIPS 140-2, takes protection even further. Level 4 detects environmental variations (such as voltage and/or temperature) outside of a specified range and takes action to destroy cryptographic keys when it detects a breach.
Chasing Compliance:
How Regulations and Encryption Fit Together
Encryption is terrific…in theory. Data stays protected, and confidential information remains locked away from the wrong eyes. In reality, though, compliance costs money, whether from purchasing hardware and software, hiring a consultant, both, or possibly more. When pursuing protection, is it possible to go overboard and encrypt more than necessary?
In some instances, a particular regulation will mandate encryption in clear, unmistakable terms; those that don’t adhere to these terms will be in violation of the law. Other times, regulations remain vague about requiring encryption, leaving murky waters for businesses to navigate. For example, a regulation may require that sensitive and/or personal data be protected without explicitly stipulating that it be protected via encryption—a less than ideal situation.
For times when the law confounds, security experts can provide clarity. A consensus among experts regarding data protection protocols results in commonly accepted best practices. The term isn’t exclusive to regulations and encryption, but it can nonetheless help guide companies that encounter nebulous regulations. If there are questions about implementing encryption that aren’t spelled out in a particular law, following industry best practices will keep a business protected.
Taking Stock of Encryption in Business and Finance
When discussing the regulations that govern how financial institutions protect sensitive data, the regulation on most experts’ tongues is the Gramm–Leach–Bliley Act (GLBA, colloquially pronounced “glibba”). Passed in 1999, the GLBA was a major change for banks and other financial institutions in that it established and mandated a framework to make these institutions keep their clients’ data private. Institutional penalties for GLBA infractions can run up to $100,000 per violation, and an institution’s officers and directors can be individually fined $10,000 per violation. Additionally, jail time may result if a violation is deemed a criminal act, so complying with GLBA should be a top priority.
The key text of the GLBA where encryption is concerned is §6801 of Title 15, Chapter 94, Subchapter I. It stipulates that institutions must “insure the security and confidentiality of customer records and information, protect against any anticipated threats or hazards to the security or integrity of such records, and protect against unauthorized access to or use of such records or information which could result in substantial harm or inconvenience to any customer.”
Although there’s no direct mention of encryption, the phrase “anticipated threats” clearly identifies the need for it. Encryption at multiple levels will help protect customer data. For data at rest, whole-disk encryption is ideal (particularly on mobile devices and other forms of portable storage), while folder-level encryption may be suitable on servers where customer information is isolated to specific folders. Databases should be encrypted as well, and the best practice for accessing sensitive data remotely is to use a VPN.
Another critical regulation is the Sarbanes-Oxley Act (SOX). Slightly newer than GLBA, SOX arose largely in response to instances of corporate accounting malfeasance at the turn of the century, particularly the Enron and WorldCom scandals. The focus of SOX isn’t strictly encryption, but there’s enough focus on safeguarding data that encryption can’t be ignored. SOX sections 302 and 404 are most relevant to encryption. In short, these passages require public U.S. companies to report their financial information accurately and disclose any information pertaining to employee fraud. Additionally, companies must disclose any shortcomings in the internal control of this information, as well as any changes to those internal controls.
Encryption and data security play a vital role in this internal control since they can show that a company’s relevant financial information hasn’t been tampered with and that only approved individuals can read it. As far as the IT side of compliance is concerned, the preferred framework most businesses turn to is COBIT. Within COBIT, a series of controls known as DS5 provide guidance for SOX compliance. DS5, and in particular DS5.7, DS5.8, and DS5.11 deal with encryption. When financial data is in transit, it should be encrypted, and a business needs to carefully manage who has access to cryptographic keys.
Finally, businesses involved with the securities industry should familiarize themselves with the Financial Industry Regulatory Authority (FINRA), successor to the National Association of Securities Dealers (NASD). Although FINRA isn’t a regulatory agency within the government itself, it does act with the authority of Congress, so its requirements carry a lot of weight. From 2015 through 2019, FINRA socked brokers and firms with $678 million in fines and restitution. FINRA’s procedures, as described by the Securities and Exchange Commission’s Regulation S-P, specifically §248.30, borrow their language word for word from the key text of the GLBA. Hence, the best practices for complying with GLBA should spare securities firms from FINRA’s wrath, as well.
The important regulations, and the considerable fines associated with non-compliance, rather decisively lay out the need for encryption to maintain the security of sensitive data. However, the issue of how precisely to do so isn’t as clear cut. Despite this, businesses can find solid, established recommendations for putting an encryption plan in place. As an example, the National Institute of Standards and Technology (NIST) Special Publication 800-111 sets forth encryption best practices for a number of end user scenarios. The document recommends using AES encryption and urges organizations to consider stronger algorithms and larger key sizes as they become available.
The U.S. government relies on FIPS 140-2 to validate the strength of various encryption solutions, and the Federal Information Processing Standard Publication 140-2 (FIPS 140-2) authenticates the security of cryptographic modules. Within FIPS 140-2 stand four levels of increasing security. Level 1 requires that a solution use an approved algorithm or security function; the device itself requires no physical security. Level 2 requires a form of physical security that can present evidence of an unauthorized access attempt, such as a tamper-proof seal. A Level 3 solution provides a countermeasure that thwarts access, use, or modification of the cryptographic module if the solution itself detects a physical breach. Level 4, the pinnacle of FIPS 140-2, takes protection even further. Level 4 detects environmental variations (such as voltage and/or temperature) outside of a specified range and takes action to destroy cryptographic keys when it detects a breach.
Encryption and Security in Brief
Before learning how to protect data, it’s useful to know a little more about the data itself — specifically where it resides. For our purposes, data exists in the following three “states”: at rest, in transit, and in use. Data at rest refers to data located in persistent storage, such as a hard drive. This could be as simple as a saved document or image. Data in transit is any data sent or received across a network. Downloading a file from the Internet or transferring a file between two computers on a local area network are both cases of data in transit. Data in use is a little trickier, but it essentially means any data that a computer’s CPU is actively processing or data temporarily stored within a system’s RAM.
Encryption is a deep, complicated subject that many experts devote their lives to mastering, but having a rudimentary grasp of the key terms and concepts will help healthcare organizations better understand what it takes to be compliant. Ideally, sensitive data should be secure enough that unauthorized parties can’t even access or obtain it. Even if data falls into their hands, though, they definitely shouldn’t be able to read it. That’s where encryption comes in.
Encryption transforms data to make it unreadable without authorized access. In this case, authorized access comes in the form of a decryption key, which is fairly self-explanatory. When the right people have the key, they can read your encrypted data; the wrong people who don’t have the key cannot.
Many encryption methods exist, as do different instances when encryption is necessary. Encrypting data stored on a hard drive is one example, while accessing a business’s network remotely over a virtual private network is another. Unfortunately, when it comes to compliance, there’s no universal standard for encrypting data. The regulations that govern how each industry handles data may not dictate the same encryption requirements.
People with a passing familiarity with encryption may have heard of 128-bit, 192-bit, or 256-bit encryption. This refers to the “size” of the key, in bits, necessary to decrypt data. A 128-bit key corresponds to a total of 2128 possible keys; a 256-bit key represents 2256 possibilities. Generally, a larger key requires more time to crack via brute force methods (where an attacker uses a computer, or multiple computers, to “guess” the key). Security experts agree that it would take modern computers billions of years to brute-force a 128-bit key. Radical advancements in computing technology (quantum computing, for example) would be necessary to break 256-bit encryption.
Of all the encryption methods, AES (Advanced Encryption Standard) receives the lion’s share of attention, and for good reason. The NSA uses AES to encrypt data, which ought to be proof enough of its security. AES can use 128-bit, 192-bit, or 256-bit keys and thus far has been extremely resistant to attempts at exploiting potential weaknesses. Several cryptographers have tried to break AES, but none have succeeded.
If there’s a downside to AES, it would be in the computational cost of its operation. For many years, most digital encryption on computers was performed “in software,” where the systems CPU performed all of the necessary encrypt/decrypt operations. This work proved exceptionally cumbersome for general purpose processors and could bring a lower-end system to its knees. Only relatively recently have Intel’s AES New Instructions (AES-NI) and other innovations integrated specific encryption acceleration silicon into CPUs (thus running “in hardware”) and made the burden of encryption computation negligible. This also applies to the encryption of external drives, including flash drives. Somewhere, a component crunch those encryption processes, and if there’s no dedicated acceleration behind the work, other applications running on the system may suffer.
In addition to protecting data via encryption, it’s important to authenticate both data and communications (i.e., transmitted files and messages) to ensure that the data received matches the data sent. Verifying data arrived from true and trusted sources is another key aspect of maintaining security, which is why security professionals recommend cryptographic hashing. A hash is a number produced from a string of text that acts like a digital fingerprint. When someone sends a message, for example, they can generate a hash and include it with the message. The recipient of the message can then create a hash of the received message and compare it with the original hash. If the two match, the message’s authenticity is confirmed. Spoofing a hash is virtually impossible, so this tactic offers one way to ensure files and messages weren’t tampered with.
Encryption can — and should — happen in a variety of ways in a variety of situations. Windows BitLocker drive encryption is an example of one essentially free solution in the consumer space. Other times, certain hardware may be handy for encrypting data without the need for separate software. Such “self-encrypting” hardware options exist for large hard drives as well as portable flash drives. Web traffic can be encrypted using SSL (Secure Socket Layer), and the list goes on. Simply put, if desired, diligent users can keep their data encrypted wherever it goes.
Pay Now, or Pay Very Dearly Later
With global identity theft losses totaling in the billions of dollars and with non-compliance violations resulting in multi-million-dollar fines and settlements, protecting sensitive data is as crucial now as it’s ever been. If a business or organization within the finance, banking, or securities industry has questions about securing relevant data, a proper risk assessment is the first step to instituting compliance.
Encryption will be the correct answer most of the time, but leaving data unsecured is the wrong answer every time.