GUEST BLOG: Five steps to take when securing your data with multi-factor authenticationBlog
September 06, 2022
Computer data exists in different states at different times: data in transit (information flowing through a network); data in use (active data that is being accessed and manipulated by a computer program); and data-at-rest, known as DAR, or data that is physically housed in a storage device like a solid-state drive. Many cybersecurity solutions focus on securing data in transit and data in use, but neglect securing DAR.
President Biden’s “Executive Order on Improving the Nation’s Cybersecurity,” enacted on May 12, 2021, directs all branches of the federal government to improve their resilience to cybersecurity threats. This order directly calls out the need to secure data-at-rest (DAR) with encryption and multi-factor authentication (MFA).
MFA requires a user to provide multiple pieces of evidence that combine to verify a user’s identity. Depending on the application, MFA may be required at login or perhaps when trying to access an application or even a particular folder or file. MFA combines two or more independent credentials: what the user knows (password, for example), what the user has (an authentication app, for example), and what the user is (biometric palm vein scan, for example). Since most MFA implementations use two factors, it’s often called two-factor authentication, or 2FA.
There are five important considerations when protecting your data with MFA.
1. Understand the sensitivity of your data: First, note that not all data is subject to the same levels of protection. In the U.S., since all federal departments are part of the executive branch, the data-classification system is governed by executive order rather than by law. As of 2009, information may currently be classified at one of three levels: confidential, secret, and top secret. Subsequent executive orders may change these classifications and the levels of protection associated with each classification.
2. Use self-encrypting drives: Sensitive data needs to be encrypted, executive orders notwithstanding. Self-encrypting drives (SEDs) encrypt data as it’s written to the drive, which has a self-contained drive encryption key (DEK). The key and encryption process are transparent to users.
SEDs encrypt everything on the drive, which is called full-disk encryption (FDE), including operating system (OS), applications, and data. On-drive encryption is called hardware FDE (HWFDE) and uses an embedded encryption engine (EE), which should provide 256-bit AES encryption.
An SED should adhere to the TCG Opal standard, a secure standard for managing encryption and decryption in the SED. SEDs are often certified to Federal Information Processing Standards (FIPS), developed by the National Institute of Standards and Technology (NIST). For example, a FIPS 140-2 L2 certification assures that the SED’s EE has been properly designed and secured; the L2 ensures that there is visible evidence of any attempt to physically tamper with the drive.
The National Information Assurance Partnership (NIAP) is responsible for the U.S. implementation of the Common Criteria (CC), an international standard (ISO/IEC 15408) for IT product security certification. CC is a framework that forms the basis for a government-driven certification scheme required by federal agencies and critical infrastructure.
3. Employ pre-boot authentication: A designated security officer or administrator will define the user roles and identity management used to authenticate access to the SED. The password security that forms part of an OS is notoriously weak and subject to hacking, so the first level of authorization acquisition (AA) should occur prior to the booting of the OS, in which case it is known as pre-boot authentication (PBA).
Each user should have an individually assigned password, which authorizes the SED to use its cryptographic key to unlock the data. The security officer should have the ability to add new users and revoke access to existing users. When a user’s access is revoked, that user won’t even be able to boot the OS.
A more robust PBA implementation will include MFA.
4. Multi-factor authentication methods: In addition to a username/password, MFA requires another form of authentication. One approach is to use a security dongle, such as a YubiKey, containing a license key or some other cryptographic protection mechanism that the user plugs into a device USB port. The U.S. Department of Defense (DoD), including civilian employees and contractor personnel, uses a smartcard called the common access card (CAC), in which case the computer must be equipped with a physical card reader.
Other MFA methods include applications, often on smartphones, that provide a one-time code synced to the device or system asking for authentication. Also taking advantage of the ubiquity of smartphones is an SMS-based system that will include a one-time code in a text message.
5. Provide the ability to destroy the data: There are various scenarios in which it may be necessary to destroy any data stored on the SED. A benign case is when an organization decides to upgrade its computers and/or drives, transfer computers and/or drives within the organization, or dispose of or recycle the computers and/or drives outside the organization. A worst-case scenario is when an unauthorized entity gains control of the drive with the intent of accessing the data.
Using standard operating system-based “delete” functions to remove files and folders is not sufficient because experienced hackers can still retrieve some or all the data. SEDs that are used to store confidential data should support special hardware functions to perform secure erase (write zeroes into every area where data is stored on the drive) and crypto erase (wipe any cryptographic keys stored on the drive, thereby rendering any encrypted data stored on the drive unreadable and useless to a bad actor).
To address the worst-case scenario, the organization’s designated security officer should have the ability to define erase procedures to be automatically initiated by the drive itself; for example, failing AA a specified number of times should cause the drive to self-erase.
In the case of a SED equipped with appropriate PBA, any data stored on the disk will essentially be invisible until AA has taken place, thereby preventing bad actors from cloning the drive to circumvent the restricted number of permitted attempts at AA.
To sum up …
Some organizations mistakenly assume that employing MFA such as fingerprint scans or facial recognition after the OS has booted offers a high level of confidence. However, once the OS has booted, any data on its drives is exposed to sophisticated hackers or potentially nation-state bad actors.
The highest levels of confidence and security are achieved by using MFA as part of a PBA environment implemented using HWFDE realized on a FIPS + CC certified and validated SED.
CDSG director of marketing Chris Kruell leads the sphere of marketing activities, including corporate branding, corporate and marketing communications, product marketing, marketing programs, and marketing strategy. Chris previously was VP of marketing at ERP-Link and hardware startup Lightfleet. He was a marketing director at Sun Microsystems and held several marketing positions in the high-tech industry. Chris holds a BS degree from Cornell University and an MA degree from Hamline University.
CDSG (CRU Data Security Group) • https://cdsg.com/