Data at rest?

[Deyan]

Hello guys,

I've been debating about that and wanted to check what the Sec community thinks about it. The question is related for encryption of data at rest. In a specific scenario, where a system processes jobs - it draws data from a source, places this data on a temporary storage for a limited amount of time (until it processes the job) and then removes it from there. Some call this type of data - "temp data", however the question was raised if encryption of data at rest is implemented - should it apply for this temp data while it's been processed.

From risk management perspective I would say - if enough security controls are in place on the layers before the data and the average time the data stays in the temporary storage is about an hour - encryption at rest might not be a must as the probability for any intruders to breach everything else and reach it is small having in mind the limited time window. 

From other perspective though, if the data for this system is stated to be encrypted at rest - do you think that this temporary storage where the data is placed until processed - should also be encrypted? If this is not done - would it break the "data at rest" control that applies for the entire system? Hope that made sense 🙂

[Early_Adopter]

Perfect sense.

You are looking at threat to, risk of and impact for a breach of confidentiality here within that time window.

Once a file ha been written to disk it's going to be there until it's deleted, at which stage its still recoverable until the storage it was on is overwritten. So a secure delete function is important to be sure it was removed and scrubbed.

If you are encrypting the file with most tools you are really copying the file and encrypting the copy, so the original file could still be there deleted, but still with a recovery window by an attacker. So unless the files are written encrypted then there might not be much point if the attacker is detemined. One approach I've seen to avoid data remanence in the first place is use of a RAM disk.

Volume encryption generally provides much less security than file encryption when the system is running(little to none dependent on mounting), but can be a good choice if the system is powered down.

Now if the storage is shared and or someone compromises your system and wants to grab files from storage then encryption of temp files makes much more sense.

If you are writing PANs or PII covered under the PCI DSS, or you have similar security standards/regulations then you have to encrypt the files containing this data at rest.

So in summary if you were not worried about compromise based on agreement, risk , impact and cost of control you might choose not to. But if you have shared storage, regulations and standards that need it then yeah , I would definitely encrypt those files.

If the requirement states encrypted at rest for data, then all data written to the filesystem must be encrypted.

[CISOScott]

Another thing to consider is window time. What is the window of time an attacker needs to be able to get into the system,  copy the data, and get it off the system before it is deleted or overwritten? Would you be able to detect that it happened? Would the attacker be able to run data recovery tools on the fly on your network to find deleted files? IF the window of time for successfully hacking it is relatively long, I would say no need to encrypt it, just ensure secure wiping of the area like the poster above me stated. Also, you are talking more about data in transit (sort of) versus data at rest. Your data is not resting for very long. You may have to define a period of time that defines when the data is actually at rest versus in transit. The theory behind data at rest was to ensure if data, that normally did not transit the network but maybe only occasionally, was not vulnerable to being stolen. This came from the idea of people stealing devices. We were already using encryption on data that transited the network, like email and secure file transfer, but the files stored on peoples devices were usually not encrypted. Therefore the data that was "at rest" was not protected. This has changed with the coming of BitLocker and other whole device encryptions. 

So if you are trying to defend your decision to not apply the normal data at rest rules for your organization to this data you will have to gather:

1) How long the data is on the network and what period of time defines data that is at rest?

2) How it is being removed from the network currently (simple file deletion, deletion with overwrite, etc) 

3) Is it possible for someone to restore the data using existing tools available on the network (undelete, shadow copy, etc). You would have to find out if it is a possibility for admins as well as regular users.

4) If 3 is not possible, is it possible to install or run data recovery tools without being detected?

5) If this happens multiple times per day, what happens to the last "transaction" of the day? Does it's data remain until the next batch is run? If so you will need to consider how to protect it as it may have a longer window than the earlier runs.

6) Is it worth the effort or cost savings to not protect it? Is it going to be a huge initiative to protect it or are you just receiving push back from an unwilling/unskilled IT department? Could you defend your position to the CEO or board? Would it be one of those "The intruders got incredibly lucky!" versus "We didn't do our due diligence to protect it." kind of defenses?

Once you have those answers you should be able to more adequately decide if you should encrypt it or not.

[Deyan]

Thank you folks - useful info.