Meet the Encryption Sifters
The Jedi master Yoda once said, “Fear is the path to the dark side.” For hackers, extortion leads that way too. According to the FBI, in May of this year a group known as DarkSide attacked Colonial Pipeline, the pipeline operator that supplies the East Coast with almost half its fuel. DarkSide caused the pipeline to be temporarily shut down and demanded ransom in exchange for 100 gigabytes of data stolen during the attack. In response, President Biden issued an executive order that, among other things, directs government agencies to improve security in their software supply chains by implementing encryption. It also directs the Office of Management and Budget (OMB) Director to update standard contract language in the Federal Acquisition Regulations to reflect enhanced security requirements. According to OMB, this year the federal government will spend $97 billion on information technology, so that new contract language is a big deal.
Contract provisions that address encryption are increasingly common in the private sector too. That’s why LegalSifter has developed a family of encryption Sifters—our name for algorithms that look for specific issues in contracts—to see whether contract provisions addressing encryption are present or missing.
Encryption uses a mathematical function to scramble text, transforming readable data (plaintext) into an undecipherable form of data (ciphertext). If parties to a transaction expect to share confidential information, the contract expressing that transaction might provide for encryption as a security practice one or more parties are to use when transmitting and storing data. Like all technology, encryption becomes obsolete over time, so it’s best to consult personnel with relevant technical knowledge to ensure choices reflected in the contract make sense and that the contract refers to encryption accurately.
Encryption is a complex subject, but our Sifters break it down into manageable portions. One of our Sifters is Information Security: Encryption Standards, which looks for references to standards for implementing encryption. There are many kinds of encryption, so in contracts it’s best to be specific in describing encryption. Generally that’s accomplished by referring to standards.
Several influential organizations publish encryption standards to guide computer-system operators. They include the National Institute of Standards and Technology (NIST), the International Organization for Standardization (ISO), the American National Standards Institute (ANSI), the Institute of Electrical and Electronics Engineers (IEEE), and the Payment Card Industry Security Standards Council. When deciding which encryption standards to refer to in a contract, ask a specialist—otherwise, those standards might not make sense. For example, some contracts refer to the Data Encryption Standard (DES)—encryption technology that was developed in the 1970s and is now obsolete. Other contracts refer to Secure Sockets Layer (SSL)—technology that security professionals now consider insecure. And still others refer to encryption key length (measured in “bits”), even though key length by itself can’t be counted on to stop a hacker from breaking the encryption.
Information Security: Encrypting Passwords is a Sifter that looks for, yes, references to encrypting passwords. Passwords are a particularly sensitive form of data, so encrypting passwords is a standard security practice used in transmitting and storing data. It follows that a contract might refer to encrypting passwords in describing a party’s current security practices or security practices it’s required to implement.
Computer users tend to reuse passwords, so if a hacker discovers a user’s password on one system, they might be able to infiltrate that user’s accounts on other systems. In the technical literature on encryption, it’s common for authors to distinguish data at rest (data that is stored on a system) and data in transit (data that is moving through a system but isn’t stored on it). When passwords are at rest, the Open Web Application Security Project (OWASP) recommends, in almost all circumstances, that systems store hashed passwords instead of encrypted passwords. That’s because hashing is a one-way function, which means the plaintext can never be retrieved. By contrast, encryption is a two-way function best used when the original plaintext needs to be retrieved.
To protect against a known weakness of hashing, OWASP recommends salting—adding a random string of characters to a password before running the hashing algorithm. When passwords are stored without a salted hash, parties have sued, claiming breach of contract and unreasonable data security practices. So if a contract says passwords are encrypted, it’s prudent to consult with your organization’s computer security professionals to determine whether passwords are stored encrypted or salted and hashed. You might have to adjust contract language so it accurately reflects security practices.
Encrypting data on portable devices presents a different set of challenges, so we built Information Security: Encrypting Data on Portable Devices and Removable Media. Portable devices come in many types, and they might be encrypted in different ways. Portable devices might be secured by full disk encryption (encrypting all data on the device), volume encryption or virtual disk encryption (encrypting designated parts of the device), or file/folder encryption (encrypting designated folders or files on the device). Which is appropriate depends on the type of storage, how data is stored on the device, how much information needs to be protected, where the device is stored and used, and what technical threats need to be mitigated.
As with encryption generally, when describing encryption for portable devices and removable media, it’s best to be specific. Drafters might point to company security policies or NIST Special Publication 800-111, Guide to Storage Encryption Technologies for End User Devices.
Other Sifters in the family are Information Security: Encryption Key Management and Information Security: Encrypting Data at Rest and in Transit. And rounding out the family is Information Security: Encryption, which looks for any references to encryption. It’s best used in contexts where you might not expect encryption to be addressed.
Like a good Jedi, these Sifters will help you stay away from the dark side when drafting contracts. The encryption family of Sifters, like LegalSifter Review generally, saves you time, helps you make informed decisions, and reduces the risk of unpleasant surprises.