Security Requirement Category: Data at Rest

By Alexander Allerdings, Niklas Werth and Philip Betzler.

Security Requirements are requirements that have to be met in a Software Development process to make the software secure. To avoid time and resource costly delays they should be considered from the beginning. In this blog entry we take a closer look at the category Data at Rest.

Below is an incomplete list of nine categories of Security Requirements:

• Auditing and Logging
• Authentication and Authorization
• Session Control
• Input Validation / Output Encoding
• Exception Handling
• Encryption and Integrity
• Data at Rest
• Data in Transit
• Configuration Management

Auditing and Logging:

Auditing and Logging describes the recording of events in different Logs, separated by information level.
Internal programming logging should go to a trace or “normal” log, domain level events (failed or successful logins etc.) should be saved in a audit log. There are specific requirements on how an audit log needs to be secured.

Authentication and Authorization:

Authentication and Authorization describes account handling requirements, such as specific requirements towards password complexity, account deactivation without deletion or cooldown times after wrong login attempts.

Session Control:

Session Control defines measures to identify clients and their active sessions.

Input Validation / Output Encoding:

Input Validation describes the mechanism to validate received input and making sure you’re not getting attacked by SQL injections and this kind of attacks. Output Encoding defines mechanism to encode output to clients.

Exception Handling:

Exception Handling describes how to handle exceptions (writing to log files, free private data and do not send detailed information to user!)

Encryption and Integrity:

Encryption defines what kind of algorithms should be used (only FIPS or BSI approved), that the default setting should always be the highest possible and how the keys should be protected. Integrity defines how to check for integrere data.

Data at Rest:

Data at Rest defines how data that is saved on non volatile memory should be secured.

Data in Transit:

Data in Transit defines how a connection needs to be secured to transport important information.

Configuration Management:

Configuration Management describes the usage of version and configuration management software (Git, etc.), the separation of interfaces and the requirements towards application configurations.

Data at Rest

In this Blog entry we will take a closer look on the Security Requirement Data at Rest.

So, the definition of Data at Rest was listed above, but of what kind of data are we talking?
The definition defines all data as affected, that is saved on non volatile memory, but there are differences of regarding the effects of compromised data.

Big problems can be caused if personal data of customers are hacked, in form of large fines and a damaged reputation. If the only stolen thing is an old file, with absolutely no value the damage is significantly smaller.

Here is a non complete list of important data that should never lay around unsecured:

• Personal Data
• Customer Secrets
• Intellectual Property
• Banking Information
• Configurations
• Passwords
• Programm Source Code
• Architecture overviews
• Backups

What can we do to secure these information properly?
Data that is only used to check information against and is never read should be saved hashed by an secure Hash function with an strong salt vector. Data that has to be read has to be protected by strong cryptographic algorithm. The possibilities vary depending in which kind of environment those data have to be saved.

What kind of attacks are prevented or increased in difficulty by those measurements?

Attacks that are prevented or increased in difficulty are the stealing of whole Computer or Hard Drives or the hacking of the network or PC the data is stored on.

Local Environments

Local Environments are defined by having the data only on one active computer at at time. The data can either be stored on one of his hard drives or mobile storage solutions. The data can be saved in files, or databases on the same computer. Solutions could be the encryption of the hard drive in combination with an encryption of the files and the settings that any database should save their data encrypted as well.

Distributed Systems Environments

Distributed Systems Environments consists of multiple programs executed on multiple computers and they might be locally separated. Data is normally not saved as files on the different computers, but in file databases that provide access to every authorized user/program. Because of the safety requirements of any distributed system there are multiple instances of each program to reduce the probability of downtimes. This means there are multiple instances of the databases to be secured. Each of these instances have to be configured to save the data encrypted, like the local environment computer, and the access to be saved by the means of requirement Authentication and Authorization.

Methods

Hard Drive / File Encryption:

Hard Drive Encryptions encrypt some or all data saved to the hard drive when writing and decrypt them when reading from the Hard Drive. There are two versions of Hard Drive encryptions, the software and the hardware version.

Software Encryptions:
Software Encryptions require an encryption program to run on the computer. When a file should be saved on the Hard Drive they encrypt the data before it is sent to the disk. An example is VeraCrypt, an OS independent OpenSource program, an other is BitLocker, a software that is included in Windows OS. The activation of disk encryption will increase the CPU load, because the data needs to be de-/ encrypted.

Hardware Encryptions:
Hardware Encryptions require specific hard drives or USB drives that are called Self Encrypting Drives (SEDs). These drives de-/encrypt the data themselves and thus reduce the CPU overhead that a Software Encryption would cause.
SEDs cost a price premium. In contrast to the costs stands the limited CPU load gains in capable computer systems.

Database Encryption:

Database Encryption make sure that no saved files or backups of a database are saved in plain text to the file system. They differ in the level of separate encrypted entries.

Transparent/External Database Encryption:
Transparent/External Database Encryption (TDE) is the encryption of the whole database and backups by the Database Management System (DBMS).

Column-Level Encryption:
Column-Level Encryption is the separate encryption of every column in a database, in contrast to TDE which encrypts everything together.

Summary:

In this Blog entry we shortly described different Security Requirements and had an deeper view on the category Data at Rest. We explained what kind of data is meant and how to secure it in different environments. At the end we gave an short overview of the individual possibilities and possible side effects.