George Wainblat

George Wainblat

George Wainblat joined Unbound in June 2017 as Director of Product Management. George brings a wealth of experience in leading multi-disciplinary product, engineering and business units at global hi-tech companies as well as startups.

Encryption & Regulation

How Do I Encrypt Thee? Let Me Count the Ways

In our recent blog post on NY-DFS compliance requirements, we discussed the significant role of encryption as a means for financial institutions to implement security controls over non-public data in their possession.

Encryption is an intricate topic, as there are multiple ways to analyze various encryption methods and their applicability to different use cases within financial institutions. In this blog post, we’ll analyze contrasting encryption types and approaches, coupled with considerations for key management and regulatory compliance.

Data States

First, let’s have a look at the different states of digital data, and respective encryption methods:

  • Data at Rest – data that is not actively moving from device to device or network to network such as data stored on a hard drive, laptop, flash drive, or archived/stored in some other way. For protecting data at rest, enterprises can simply encrypt sensitive files prior to storing them and/or choose to encrypt the storage drive itself.
  • Data in Motion / Transit – data actively moving from one location to another, such as across the internet or through a private network. For protecting data in transit, enterprises often choose to encrypt sensitive data prior to transmission and/or use encrypted connections (i.e. HTTPS, TLS and FTPS) to protect the contents of data in transit.
  • Data in Use – data which is stored in a non-persistent memory, typically in computer random-access memory (RAM), CPU caches or registers while actively being processed by computing equipment. Data in use is particularly difficult to encrypt because it is actively being processed and encryption may impact performance or make processing impossible altogether.

Encryption Approaches

Beyond differences associated with the varied data states, today a range of encryption approaches are available, offering varied levels of functionality and granularity.

  • Full Disk Encryption – uses disk encryption software or hardware to encrypt every bit of data that goes on a disk or storage device (such as SAN or NAS) to prevent unauthorized access to data storage.
  • File System Encryption – is a form of disk encryption where individual files or directories are encrypted by the file system itself. This contrasts with full disk encryption where the entire partition or disk, in which the file system resides, is encrypted. This is the way to handle encryption of unstructured data types such as emails, documents, images and A/V files.
  • Database Encryption – the process of converting data, within a database, from plain text format into a meaningless cipher text by means of a suitable algorithm. Database encryption can be provided at the file or column level. Several technologies have been developed, for example Transparent Data Encryption (TDE) employed by Microsoft SQL, IBM DB2 and Oracle DB and MongoDB to encrypt database files, and Always Encrypted utilized by SQL Server databases allows encryption of sensitive data inside client applications to prevent encryption keys’ exposure in the database engine.
  • App-level Encryption – a data-security solution that, at the application level, encrypts sensitive data, so only authorized parties can read it. This solution may support different mechanisms such as format-preserving encryption (FPE), order-preserving encryption (OPE) and tokenization. For example, with FPE, a 16-digit credit card number remains a 16-digit number after the encryption process. This scheme is useful when third parties process information that needs to be encrypted, but the application using it should be oblivious of the change.

The following figure depicts the different encryption schemes compared complexity and granularity wise. The higher up the stack that encryption is executed, the greater the overall protection (since it stays encrypted through the rest of the encryption layers, i.e. app-level encryption keeps certain data fields unencrypted, and thus more comprehensive protection would require file-system encryption), but this comes with the cost of increased complexity. It’s far easier to encrypt an entire hard drive than a single field in an application, at least in real world implementations: By giving up granularity, you gain simplicity. One must also pay close attention to the underlying infrastructure that is been used, as in ephemeral containers there is no possibility to encrypt the disk, and there is a need to go up the stack to keep the data protected.

Cryptographic Algorithms

In addition, there is a need to select the right encryption algorithm suitable for the use case, such as encryption, signing and validation, utilizing the appropriate encryption scheme.

  • Symmetric encryption – used to ensure confidentiality. Communication partners must hold the same key to encrypt or decrypt a message. Examples: 3DES, AES.
  • Asymmetric (or public key) encryption – used to ensure confidentiality. In the case of message transmission, a sender uses the recipient’s public key to encrypt the message, while the recipient uses the corresponding private key for decryption. The recipient’s public key is accessible to the sender via a trusted key directory. Examples: RSA, ECIES.
  • MAC (Message Authentication Code) – used to guarantee message authenticity and integrity. Communication partners must hold the same key. Examples: HMAC, CMAC.
  • Signatures – employ asymmetric cryptography for non-repudiable authentication. To sign a message, it is usually hashed with a cryptographic hash function to obtain a short message digest. The digest is then transformed with the signer’s private key to obtain a signature. Any holder of the signer’s public key can check if a signature authenticates a message under the corresponding private key, but public key holders are unable to generate signatures themselves. As such the signature uniquely authenticates the message as originating from the signer, enabling non-repudiation services. Examples: RSA, ECDSA.

Further, one must consider the relevant key size according to the exact threat model.

Key Management & Protection

The discussion of the various pros and cons of each of the above methodologies wouldn’t be complete without analyzing where the keys are located and how they are protected and managed. Below we describe the typical encryption key management methods in use today.

  • Full Disk Encryption – these keys are often stored on a Trusted Platform Module (TPM)—a secure cryptoprocessor embedded in the motherboard—rather than on the disk, to allow encryption of the entire hard disk.
  • File System Encryption – implementations can span from utilizing encryption built into the operating system which utilizes keys that are typically located on the hard disk, unprotected from a potential adversary, to dedicated encryption products storing the keys securely in an HSM.
  • Database Encryption – various solutions for database encryption differ in the location of the encryption keys:
    • HSM – database encryption can use hardware security module (HSM) to provide enhanced security for sensitive data. An HSM is used to store the master encryption key used for transparent data encryption.
    • Vault – The secret backends allow vault to handle any type of secret data, including database credentials and encryption keys.
    • CSP KMS – To manage the keys used for encrypting and decrypting your Cloud database (i.e. AWS RDS), one can utilize the native CSP Key Management Service, scaled for the cloud. It allows to create encryption keys and define the policies that control how these keys can be used and audited.
    • Within the database – Master encryption keys are typically co-located with data on the same database server, while there is no well-defined separation of duties between database administrators and security administrators.
  • App-level Encryption – To combat the challenges in today’s cybersecurity environment, application developers have been implementing various security methodologies such as HSMs; encryption keys are rarely stored within the application itself.

Regulations

Compliance with privacy and security regulations is an essential part of an organization’s operational process. In the financial industry, the decision to use encryption is often mandated by one or more of the regulations that the organization is subject to. Below, we review a number of relevant regulations and how they relate to encryption.

  • PCI-DSS – Payment Card Industry Security Standards Council assists merchants and financial institutions understand and implement standards for security policies, technologies and ongoing processes that protect their payment systems from breaches and theft of cardholder data. Cardholder data should be unreadable anywhere it is stored by using strong cryptography (i.e. disk encryption) with associated key-management processes and procedures. Secret and private keys used to encrypt/decrypt cardholder data should be stored within a secure cryptographic device. Strong cryptography and security protocols (i.e. TLS, IPsec and SSH) should be used to safeguard sensitive cardholder data during transmission over open, public networks.
  • NY DFS – new set of regulations from the New York state Department of Financial Services that places new cybersecurity requirements on all financial institutions operating in NY state. Requires implementing encryption to protect nonpublic information held or transmitted by the covered entity and 3rd party service provider’s, both in transit over external networks and at rest.
  • GDPR – The General Data Protection Regulation imposes new rules on companies, government agencies, non-profits, and other organizations that offer goods and services to people in the EU, or that collect and analyze data tied to EU residents. Requires the use of data encryption, pseudonymization and tokenization to protect the personal data (PII) of EU citizens.
  • GLBA – The Gramm–Leach–Bliley Act is US federal law that requires financial institutions to explain how they share and protect their customers’ private information. Encryption of the account number is one of the methods to limit sharing account number information for marketing purposes.
  • SEC – The Securities & Exchange Commission issued guidance for publicly traded companies as to disclosure obligations with respect to matters involving cybersecurity risk and incidents, as these issues are among the most significant factors that make an investment in the company speculative or risky. It also addresses the importance of cybersecurity policies and procedures and the application of disclosure controls and procedures.
  • CFTC – Commodity Futures Trading Commission agency of the US government regulates futures and option markets aiming to protect market users and their funds, consumers, and the public from fraud, manipulation, and abusive practices related to derivatives and other products. Requires the use of encryption for certain data types and transfers.
  • FINRA – Financial Industry Regulatory Authority is a non-governmental organization that regulates member brokerage firms and exchange markets. A regulatory notice requires encryption of information provided via portable media device.
  • IIROC – Investment Industry Regulatory Organization of Canada is a national self-regulatory organization, overseeing all investment dealers and trading activity on debt and equity markets in Canada. Provision requires to protect customer information, which may include the encryption of such data, further protecting the encryption keys to ensure the confidentiality of client information.
  • FCA – Financial Conduct Authority is a financial regulatory body that regulates financial firms providing services to consumers and maintains the integrity of the financial markets in the UK. Require encryption of customer data in motion, at rest and backed-up.

Summary

In this blog we have reviewed different data states, encryption approaches, schemes and algorithms, discussed key management and various regulations.

The financial industry today faces the double challenge of securing larger and larger volumes of sensitive information, and addressing a growing range of security and privacy regulations. With an obvious need to adhere to these regulations, in order to protect from data breaches and preserve a reputation for trustworthiness, comes a large dose of complexity when it comes to implementing encryption. An expert view is required for institutions to implement the optimal encryption schemes that address their particular environment and operations.

Subscribe to BLOG

shares