In a world where millions of customer and contact records are commonly stolen, how do you keep your data safe? First, lock the door to your office. Now you’re good, right? Oh wait, you are still connected to the internet. Disconnect from the internet. Now you’re good, right? What if someone sneaks into the office and accesses your computer? Unplug your computer completely. You know what, while you are at it, pack your computer into some plain boxes to disguise it. Oh wait, this is crazy, not very practical and only somewhat secure.
The point is, as we try to determine what kind of security we need, we also have to find a balance between functionality and security. A lot of this depends on the type of data we are trying to protect. Is it financial, healthcare, government related, or is it personal, like pictures from the last family camping trip. All of these will have different requirements and many of them are our clients’ requirements. As a company dealing with such diverse clientele, Service Objects needs to be ready to handle data and keep it as secure as possible, in all the different states that digital data can exist.
So what are the states that digital data can exist in? There are a number of states and understanding them should be considered when determining a data security strategy. For the most part, the data exists in three states; Data in Motion/transit, Data at Rest/Endpoint and Data in Use and are defined as:
Data in motion/transit
“…meaning it moves through the network to the outside world via email, instant messaging, peer-to-peer (P2P), FTP, or other communication mechanisms.” – http://csrc.nist.gov/groups/SNS/rbac/documents/data-loss.pdf
Data at rest/endpoint
“data at rest, meaning it resides in files systems, distributed desktops and large centralized data stores, databases, or other storage centers” – http://csrc.nist.gov/groups/SNS/rbac/documents/data-loss.pdf
“data at the endpoint, meaning it resides at network endpoints such as laptops, USB devices, external drives, CD/DVDs, archived tapes, MP3 players, iPhones, or other highly mobile devices” – http://csrc.nist.gov/groups/SNS/rbac/documents/data-loss.pdf
Data in use
“Data in use is an information technology term referring to active data which is stored in a non-persistent digital state typically in computer random access memory (RAM), CPU caches, or CPU registers. Data in use is used as a complement to the terms data in transit and data at rest which together define the three states of digital data.” – https://en.wikipedia.org/wiki/Data_in_use
How Service Objects balances functionality and security with respect to our clients’ data, which is at rest in our automated batch processing, is the focus of this discussion. Our automated batch process consists of this basic flow:
- Our client transfers a file to a file structure in our systems using our secure ftp. [This is an example of Data in motion/transit]
- The file waits momentarily before an automated process picks it up. [This is an example of Data at rest]
- Once our system detects a new file; [The data is now in the state of Data in use]
- It opens and processes the file.
- The results are written into an output file and saved to our secure ftp location.
- Input and output files remain in the secure ftp location until client retrieves them. [Data at rest]
- Client retrieves the output file. [Data in motion/transit]
- Client can immediately choose to delete all, some or no files as per their needs.
- Five days after processing, if any files exist, the automated system encrypts (minimum 256 bit encryption) the files and moves them off of the secure ftp to another secure location. Any non-encrypted version is no longer present. [Data at rest and data in motion/transit]
- This delay gives clients time to retrieve the results.
- 30 days after processing, the encrypted version is completely purged.
- This provides a last chance, in the event of an error or emergency, to retrieve the data.
We encrypt files five days after processing but what is the strategy for keeping the files secure prior to the five day expiration? First off, we determined that the five and 30 day rules were the best balance between functionality and security. But we also added flexibility to this.
If clients always picked up their files right when they were completed, we really wouldn’t need to think too much about security as the files sat on the secure ftp. But this is real life, people get busy, they have long weekends, go on vacation, simply forget, whatever the reason, Service Objects couldn’t immediately encrypt and move the data. If we did, clients would become frustrated trying to coordinate the retrieval of their data. So we built in the five and 30 day rule but we also added the ability to change these grace periods and customize them to our clients’ needs. This doesn’t prevent anyone from purging their data sooner than any predefined thresholds and in fact, we encourage it.
When we are setting up the automated batch process for a client, we look at the type of data coming in, and if appropriate, we suggest to the client that they may want to send the file to us encrypted. For many companies this is standard practice. Whenever we see any data that could be deemed sensitive, we let our client know.
When it is established that files need to be encrypted at rest, we use industry standard encryption/decryption methods. When a file comes in and processing begins, the data is now in use, so the file is decrypted. After processing, any decrypted file is purged and what remains is the encrypted version of the input and output files.
Not all clients are concerned or require this level of security but Service Objects treats all data the same, with the utmost care and the highest levels of security reasonable. We simply take no chances and always encourage strong data security.
