This is a topic that crops up every few weeks with some of my fellow system engineers. While I’m happy to see that security is finally moved to the forefront of people’s minds, it seems for the most part to cause more confusion then good. Fair enough, as only a few short years ago unless you worked in the government space or a regulated space, data was simply data and no one cared too much about how it was stored or accessed.
Then a certain egotistical individual opted that “truth” outweighs security and forced everyone to wake up, ironically not out of a desire for truth, but to keep information secure. Now when someone talks data (and inevitably storage) one of the questions that’s comes up is “how do we keep it secure”? for the average business world this is a new area so they default to the group of people who have been doing this for decades, government. Government always comes with policy and procedures that are well documented. However like most “new” ideas the desire for them has spread quicker than the understanding of what is being asked.
Like all design questions, this has to be broken down into what are we trying to solve, or in this case protect. One of the tools for protecting data is encryption. How data gets encrypted is for another time, what maters here is that it’s the tool that people first hone in on, specifically data at rest encryption. This can be accomplished from the application layer, to filesystems, down to the disk.
So what is data at rest encryption really protecting me from?
At rest encryption at its core means you are scrambling the data where ever it is written to. This would provide protection from someone swiping a hard drive from the system or compromising the system outside of its filesystem to grab the data. Data in flight or data being processed at the application layer is not encrypted but breeches at those levels aren’t as common as Hollywood would like you to believe. Data is normally compromised where it lives, so at rest encryption is a good place to start in securing it.
So what is this FIPS140 thing?
One of the first things I normally hear after saying the words storage encryption is, “Is it FIPS-140 compliant?” The first time I heard a non-government customer ask me I almost cried from pride. I then quickly discovered they heard the statement from another vendor and were told its super important and anything short of that would lead to 13 year old hackers stealing their identities and selling them to other 13 year old kids for lunch money. This leads to the question then, what is the difference between the two if they are being used interchangeably?
FIPS is a set of standards that covers security of systems and their data. FIPS-140 specifically is the standards around the cryptographic module and its associated software. Well that clears up everything! Not…
Encryption is only one of the elements to the equation. Originally I said I wasn’t going to go into how encryption works, but I lied. A simple version of encryption is the data is tossed into a blender and run on high. Out comes data puree however unlike trying to reassemble your strawberry banana smoothie into its original fruit elements data encryption leaves with a formula to de-puree the data. Now we have a process to scramble the data into something useless AND a way to get it back into a useful state.
This hasn’t really answered what FIPS140-2 is…
Enter FIPS140 standards. FIPS140-2 is rated at 4 levels of security, from 1 to 4. These detail the requirements of the encryption key itself and the security of the crypto module. Level 1 is the softest of the requirements requiring key and data to be separate, and the module to be dedicated. As you move up in the levels the requirements become more stringent, with the addition of making the module tamper resistant and chips that zero out the data if they are broken open.
From a solution standpoint we need to keep the formula to our anti-data puree away from the data. This is known as a key management solution. There are several ways that this can be accomplished from a solution standpoint and each has merits and draw backs. All of them will have one thing in common and that’s keeping the key away from the data, which is a good practice regardless of compliance or regulation.
If we look at key management solutions that would meet FIPS140 requirements like the appliance from Gemalto, KeySecure or IBMs Tivoli Key Manager / Security Key Lifecycle Manager Software both provide methods of managing keys away from the data and easy to use packages to manage multiple encryption devices. They each have merits and draw backs which are a bit beyond scope but they all do about the same thing, which is put keys somewhere safe.
Now, new to the security market we are seeing a wave of “On Box Key Managers”, it goes along with the trend of “Make IT Easier”. Well if we follow the FIPS140 requirements we have established keys and data need to be separated. Traditionally that meant key managers and that eventually becomes misconstrued as “complex”. What these solutions provide is a dedicated chipset that handles key management of the device by removing that function from the primary device.
So what does that mean?
Well if someone walks in and steals a hard drive from your system your key is safely off the disk and the data remains scrambled. However if someone compromises the system the key is still with the data. It meets requirements; all of the check boxes were hit. However eths spirit, as it were, of the requirement has been completely ignored.
It’s a solution that meets a check box but should terrify you if you are concerned from a security standpoint.
This is the point in which we should take a step back and look at what we are trying to accomplish, what we are trying to protect and from whom. I now shall don my NetApp Fedora and speak from a product standpoint.
/puts on Fadora
Someone comes to you and says they are worried that the world is full of hackers who steal data all day long and then bankrupt grandmothers and we need to protect the data from them. These are normally cases being driven by an auditor or senior level management, and their intent is solid. Keep data safe. In these instances no one is thinking about the how, they simply need it done and security is sadly the afterthought. Budgets become a concern because they are always shrinking and requirements are growing. In these cases a solution that simply encrypts the data at rest is good enough. In the NetApp world we would do an ESeries, as the ESeries disk are able to self-encrypt and do not require the key to be moved off system, though it’s still an extremely good idea. Maybe the requirements require some more features then just reliable blocks, in that case a FAS with FlexArray would be added in. In either solution you have kept cost lower as there is no key manager required.
Now the same person comes and says on top of protection from the hackers we need to protect the data from employees, contractors, people with physical access, and the janitor who thinks blinking lights should go in the mop bucket. This is a request that is normally driven by a security team, and they have guidelines they want to see followed. They might even know what level of compliance you should be aiming for. What they are seeking protection from is someone walking off with the physical object, which happens more often than expected. This is not normally from malice but due to neglect such as a drive being lost during shipment or a tape being misplaced when sent into cold storage. If you keep the key with the data then you haven’t protected your data from anyone if they gain access. This is where a solution like FAS with NSE (NetApp Storage Encryption) disk fits in. This requires a key manager to be present, if the solution can’t find the key then the system simply doesn’t boot and the data remains pureed. This is in the spirit of FIPS140-2 (Level 2).
So when the topic of encryption comes up the questions to ask should always be:
What are we trying to protect?
Whom are we trying to protect it from?
If this is simply a check box to make an auditor happy then sadly FIPS compliance isn’t really your concern. You just need the data scrambled and likely in a cost effective manner.
If the requirements are driven because you have security concerns or regulation then things like FIPS140-2 will matter. You can take short cuts to get that check boxed marked but if the system becomes physically compromised then your data is compromised as well.