1 2 Previous Next

SANbytes: Where SAN and NAS are ONTAP

25 Posts authored by: chiragc

b9.png

By Ron LaPedis and Maryling Yu

 

 

Mare: Ron, I've been meaning to ask you a question, but I've been afraid to for fear you'll laugh at me.

Ron: Mare, you know there’s no such thing as a stupid question.

 

 

Mare: Okay, well, you've talked a lot about encrypting data-at-rest. I was just hoping you'd explain further, because I didn't realize that data could get tired or need any rest.

Ron: I take it back. There is such a thing as a stupid question.

 

 

 

Mare: (Punches Ron in the arm)

Ron: Ow! Data can be tiered, or retired, but it never gets just plain old “tired.” The term, “data-at-rest” refers to data that is being stored somewhere, whether it be on disk, tape, CD-ROM, or DVD. There are two other places that data can be: on a communications line or storage area network (data-in-flight), or in computer memory being accessed by an application (data-in-use).

 

 

 

Mare: Okay, so remember some 3-4 years back when TJ Maxx (TJX) made the news with headlines that screamed that they had lost customer credit card data for millions of customers?

Ron: Yes, what about it?

 

 

 

Mare: I was wondering if they ever figured out what happened in that situation, and whether the use of NetApp technologies could have helped prevent that leak?

Ron: That, on the other hand, is a good question.

 

 

 

Mare: (Punches Ron in the arm -- again)

 

Ron: Ow! The truth is, the whole story may never be known. But what we do know brings up a very important point: as we’ve said before in this blog, data security is more than just encryption, and certainly more than just encryption of data-at-rest.

 

In the TJ Maxx case, we believe that hackers broke into a wireless network at a TJ Maxx store in Miami and rode their internal network to their Framingham, MA data center, where they got information on 45.7 million cards that were used between January 2003 and Nov 23 of the same year.

The data appears to have been encrypted, but there were other problems. First of all, Payment Card Industry (PCI) regulations state that full magnetic stripe info, the card verification code, and PIN block data should not be retained, but apparently it was at TJ Maxx. The company said that they "generally" stopped storing Track 2 data for transactions after September 2003, and by April 3, 2006, they had begun to mask payment card PIN data.

Secondly, TJ Maxx also believes that the hackers had access to the decryption tool for the encryption software that they used to protect cardholder information.

 

 

Mare: So, back to my original question, if NetApp plays in the “data-at-rest” space, could NetApp storage encryption technology have helped prevent this leak?

Ron: I’m getting there! Well, if implemented along with other controls like securing wireless networks, not storing unnecessary information, and properly separating duties, the data-at-rest encryption offered by NetApp as well as our key management appliance might have helped protect TJ Maxx’s data from disclosure. You see, since our encryption and key management appliances store keys and encrypt data in a hardware module (as opposed to software), it might have been harder for the hackers to gain access to it. But it’s hard to say, since we’ll never know the whole story, nor will we know what information was actually stolen.

 

 

 

Mare: Gotcha. Well, it’s food for thought, anyway, for companies who need to comply with PCI.

Ron: It absolutely is! And Mare, that gives me an idea for our next topic – we’ll discuss PCI in our next post.  Stay tuned.

 

 

 

Mare: Um, aren’t you forgetting to say something like, “Mare, you’re brilliant!”

Ron: Don’t push it.

By Ron LaPedis and Maryling Yu

 

 

 

 

 

 

 

 

compliance regulations books.jpeg

 

 

 

Mare: Ron, in our last post, you said that our next post would be about data immutability. Isn't the "immuter" something from a Star Trek episode? What's that got to do with anything?

Ron: Um, that would be the "Transmuter" used in the Catspaw Halloween episode, but since Halloween is coming up, I'll forgive you for your ignorance.

 

 

Mare: Oh, thank you so much. I was just trying to sound geekier so I could fit in with you.

Ron: Um, okay. Whatever floats your boat. Anyway, immutability means “unchanging over time or unable to be changed.” In the context of storage, another term that can be used for immutable data is “read-only.”

 

 

Mare: Then why confuse the heck out of everyone with the term, “immutable?” Why not just say “read-only?”

Ron: We use the term “immutable” rather than “read-only” because immutable data not only cannot be changed, but also cannot be deleted. Many organizations are required by law to keep permanent records of emails, business and financial transactions, and so on.

These records can be requested under Freedom of Information (FOI) laws, or subpoenaed in court cases as part of the e-discovery process. The organization storing the records may need to prove beyond a shadow of a doubt that the records were not changed or erased since they were created, and this is where immutability comes in.

 

 

Mare: Can you give me an example of what kind of company this would apply to?

Ron: Sure. One example is the requirement for Electronic Storage of Broker-Dealer Records mandated by the US Securities and Exchange Commission (SEC). Rule 17a-4 requires that electronic storage media preserve the records exclusively in a non-rewriteable and non-erasable format. Traditionally, immutable data was placed on write-once-read-many (WORM) drives such as optical platters, CD-ROMs, DVDs, or similar physical media. However, this leads to a financial and space problem, as the amount of stored physical media constantly grows larger and larger.

 

 

Mare: Yeah, I can imagine. All those disks just piling up and up and up. Like a graveyard for 1s and 0s.

Ron: You’re strange, Mare.

 

 

Mare: Well, you’re the one who said “Halloween.”

Ron: Anyway, SnapLock™ from NetApp is a radically different solution to the problem. Rather than using WORM media, SnapLock stores immutable data within our highly efficient storage arrays with all of the benefits of compression and deduplication. SnapLock is certified for Sec 17a-4 and many other regulations, and it is being used today to protect over 30 petabytes of storage for over 2,000 customers. Our tamper-proof ComplianceClock™ supports both volume default and file-by-file retention policies.

 

 

Mare: Wait, come again? Volume default? File retention? Can you speak English, please?

Ron: Once the clock is set, the files are protected from modification and deletion until the retention time is reached. Retention time can be increased but not decreased, and policy settings can prevent even administrators from deleting files before the retention date.

This is how SnapLock is much better than physical WORM media, which is all-or-nothing. You cannot discard WORM media until every file on it has expired, while SnapLock automatically reclaims disk space as each file’s retention date is reached.

 

 

 

Mare: When you say “reclaim disk space,” what happens to the retained file that was previously occupying that disk space and then reached its retention time? Does it just get deleted?

Ron: Can you say, “bye-bye?” Yes, when a file’s retention date is reached, it is deleted. This of course means that if you want to have an offline copy of the file after it hits its retention time, you should back it up to tape or another location.

 

 

Mare: O-kayyyyy…and with that, I’ve had just about as much techno-geek talk today as I can handle. Where should people go for more information about NetApp SnapLock?

Ron: Yes, I can see your eyes glazing over. They can check out our SnapLock product page. Come back next time for our discussion of data in flight.

blog8.jpg

By Ron LaPedis and Maryling Yu

 

Mare: Hey Ron, as you know, a critical factor in NetApp’s success has been our storage efficiency - the unique ability to minimize the amount of storage required while maximizing the speed, performance, and value that we provide to customers.
Ron : This is indeed true. What are you trying to say?

 

Mare: Well, as you know, NetApp has several key technologies that underlie our ability to offer storage efficiency as a value proposition: data compression, data deduplication, WAFL, and Snapshot copies. It’s these technologies that have put us squarely in Gartner's Leaders Quadrant.
Ron : Um, is there a point anywhere in the not-too-distant future?

 

Mare: Well, I was just wondering if you could comment on the statement that "security breaks storage efficiency."
Ron : Ah. That is indeed a true statement. I could write volumes on this subject. In fact, why don’t you just stop talking and let me drive from here?

 

Mare: Um, oooo-kay. Take it away, Ron.
Ron : You’ve probably heard that there are tradeoffs between security versus usability and efficiency. Well, you heard right. The objective is to implement the required security in such a manner that usability and efficiency remain acceptable.

 

Mare: But acceptable to who?
Ron : Ahem, I think you mean, “acceptable to whom.” (And I thought you were going to stop talking). In any case, acceptable to whom is outside the scope of this particular entry, but I think that you can guess that there are several populations that will have differing opinions on what usability and efficiency are acceptable. For example, the IT department, the auditors, and the end users who actually need access to the resource on a day-to-day basis might have very different ideas about what acceptable means to them. Today we’re just going to talk about why encrypted data cannot be de-duped nor compressed without compromising the security of the information.

 

     As I noted in a previous entry, two places that encryption of data at rest can be implemented are A) inside of the storage media (using self-encrypting disk drives (SED) or self-encrypting tape drives) and B) outside of the storage media using fabric-based appliances, in-line encryption appliances, or software.
With Option A, the data is automatically encrypted and decrypted within the storage media itself and only unencrypted data is presented to the storage array once the drives are unlocked by an administrator. Since unencrypted data can be deduped and compressed, the NetApp storage array controller can work its storage efficiency magic just as it can with any other disk drive.

 

Mare: Okay. But what about when you’re using Option B, encrypting your data at rest outside of the storage media, with a fabric-based encryption switch or appliance?
Ron : Well, let me give you a little encryption history. One of the earliest forms of encryption was the simple substitution cipher and it was used by Caesar to send messages to his legions. In this method, a different letter replaces each letter of a message. For example, every “A” is replaced by “X,” every “B” by “G,” so on and so forth.

 

Mare: So if I encrypt the word “book”, I might get “luur”? I don’t understand why I can’t compress the new words and still look for patterns to dedupe.
Ron : Assuming that the data was encrypted with a substitution cipher you could do that. However substitution ciphers are very easy to hack. You see, every language has patterns in it that will help decode a message. For example, “E” is the most-used letter in the English language, so in order to read a message encrypted with this type of cipher, a hacker starts by replacing the most used letter in a coded message with an “E” and continues deciphering.

 

Mare: Oh! Just like Wheel of Fortune!
Ron : No, not exactly like Wheel of Fortune, but we can use that to illustrate my point that once a few letters are discovered, humans are good at determining the rest of the message.

 

Mare: Can I buy a vowel?
Ron : I’m going to pretend you didn’t just ask that. To prevent this type of attack, all of the commercially available encryption algorithms implement block-mode encryption. This method encrypts a block of data at a time rather than individual characters. Even if the source contains a run of the same letter, you will never see a run within the encrypted data. Similarly, if two identical blocks of data are encrypted, the result will not be the same. So if you encrypt the word “book” twice, you might get “H7lp” and “k2jT.”

 

NetApp data compression looks for and replaces repeating patterns, but since encrypted data should not have repeating patterns, it cannot be compressed. Therefore, if you want to compress data, it must be done before it is encrypted.  Similarly, NetApp deduplication removes duplicate blocks on disk.  But as we learned, encryption scrambles all of the data, so even if two blocks hold the same logical data, the encrypted contents most likely will not be the same. Thus, there is nothing to be deduplicated. Unlike compression, which can be done as part of the encryption process, deduplication cannot be done on encrypted data, even if the data is encrypted within the storage array. Of course, since self-encrypting drives present unencrypted data to the storage array, dedupe is supported when using them.

 

Mare: But can’t the dedupe algorithms within the storage array decrypt the existing data so that it can do the comparison?
Ron : In theory, I guess it could, but for maximum security, data should be compartmentalized by assigning different encryption keys to each user or set of users and storing them in a key manager. If the encryption was done inside of the storage array, it might be possible to dedupe files that are encrypted using the same key, but most encryption is done by specialized hardware before it even reaches the storage array.

 

 

Mare: Yikes. So none of a company’s data can be deduped if they also need encryption?

Ron : No, that’s not necessarily true because encryption can be set at such a granular level that it is possible to create volumes where only part of the data on the volume is encrypted. Of course, you would not expect to get much in the way of capacity savings if you do run dedupe on the encrypted data, but it is still possible to achieve savings on the rest of the volume.


Finally, not all of your data needs to be encrypted. If you are using virtual desktops such as Citrix VDI, you can use granular encryption to avoid encrypting the operating system and applications.  Only user profiles and data need to be encrypted. And combining NetApp Storage Encryption self-encrypting drives with higher-level encryption means that all of your data is protected if a drive goes missing, is repurposed, or sold.

 

Mare: So, let me summarize to see if I’ve got it. If encryption is done inside the array, then you can compress, but not dedupe it (unless the SEDs present unencrypted data to the storage array first). If encryption is done outside the array, then you can neither compress it, nor dedupe it. Have I got that straight?
Ron : I guess you were paying attention after all. Next time, we’ll be back to talk about data immutability.

7.jpg

By Ron LaPedis and Maryling Yu

 

 

 

 

Ron: So Mare, I gave you a homework assignment in our last blog, where I asked you to define what "data loss" means to you.

 

Mare: Yes, you did. And I always do my homework.

 

 

 

Ron: And what did you come up with?

 

Mare: Well, to me, "data loss" means a lot of things. There are just so many ways to "lose" data. 

 

 

 

Ron: Yes! Let's contrast that to the phrase, "I lost my keys," for example. When you say, "I lost my keys," I know that you don’t have them. They could have been misplaced or stolen. If you had them when you got home but can't find them an hour later, you probably just temporarily misplaced them. If, on the other hand, you left them on your table with your laptop at Starbucks while you picked up your Iced Grande Decaf Soy No-Whip White Mocha, they're probably stolen.

 

Mare: Well, with my luck, they're probably stolen. And how did you know that's what I drink, anyway? 

 

 

 

Ron: Because I'm the one who stole your keys while you were ordering that drink. Just kidding! My point is, when you say, "I lost my customer data," you could mean a number of different things. It could be that your data became corrupted. It could be that it’s not on the storage array anywhere. It could be that it's there, but the power went out and it became lost to you temporarily. It could be that disaster struck, and the equipment is destroyed (and maybe even the building). Or, perhaps it was stolen by a hacker or otherwise disclosed in error. It could have been purposely deleted, perhaps maliciously, in violation of company policy or government regulations.

 

Mare: Yes, that's exactly what I meant. There are so many ways to "lose" data versus just two ways to lose my keys.

 

 

 

 

Ron: Well, no matter how you lost your data, or what "data loss" means to you, NetApp has you covered, as long as you planned ahead.

 

Mare: What does planning ahead entail?

 

 

 

 

 

Ron: Let's take the case where the data just isn't on the disk or has somehow been corrupted. Planning ahead in that scenario meant that you would have worked with your business units to determine their data RTO and RPO.

 

Mare: Wait, what does this have to do with Star Wars?

 

 

 

Ron: No, Mare, not C-3PO. RTO = Recovery Time Objective, or how long can they do without the data. RPO = Recovery Point Objective, or the length of the window (days, hours, minutes, or seconds) during which data may be lost because it has not been backed up or replicated before disaster destroyed the master copy. Once armed with the business unit's requirements, you would select from the IDP (Integrated Data Protection) solutions smorgasbord offered by NetApp. Here are a few of your choices:

  • Snapshot ™ - The original and most functional point-in-time copy technology
  • SnapMirror ® - Synchronous or asynchronous data replication to local or remote disk
  • SnapProtect - A disk-to-disk-to-tape backup and recovery management solution
  • SnapVault ® - A disk-to-disk backup solution based on Snapshot copies

 

Mare: Is there a reason to have both backup and replication?

 

 

 

Ron: Absolutely. Replicated data is not a backup! If a person or application goes rogue and corrupts or deletes your primary data, the corruption or deletion would be replicated as well. They only way to recover is to go to a pre-corruption or pre-deletion backup.

 

Mare: Ah, I see. So if I'm worried about data corruption or deletion, then I need to have a backup and recovery plan and a replication plan. What if I'm also worried about bad people? And what if I have to comply with certain laws because of the industry I'm in?

 

 

 

Ron: If you're worried about your data falling into the wrong hands, then you need to think about ways to encrypt that data. And if you're worried about regulatory compliance, then you need to consider a way to make data immutable (that is, read-only). At NetApp, we have solutions for all of these issues as part of our Integrated Data Protection portfolio, and all of them come with the NetApp operating system.

 

Mare: Well, shoot, it sounds like we just solved world hunger. What is there left to blog about?

 

 

 

Ron: Not quite. Next time, we’ll discuss the tradeoffs between encryption and storage efficiency. And in the future, we can talk about data immutability and other integrated data protection topics. And don’t worry, Mare, we'll make the complicated-sounding as painless as possible to read about.

 

 

b6.png


By Ron LaPedis and Maryling Yu

 

 

 


Ron, last time you promised that you’d tell us the skinny behind FIPS validation, and I've been waiting with bated breath ever since.


Sure, Mare. You can stop holding your breath now. FIPS testing is done by independent National Institute of Standards and Technology ("NIST")- accredited FIPS 140 testing laboratories. Please note: FIPS is not a certification, it's a validation. This choice of word is extremely important because these labs can only validate what they are asked to validate. In particular, they will validate that the cryptographic module is implemented correctly per the applicable FIPS 140-2 level. The labs cannot certify that an overall product implementation is secure enough to meet your organization's needs.


Oh no. Sounds like another "caveat" or some kind of "buyer-beware" language.

 


It is. A great example of this is what happened in the secure-USB-flash-drive debacle of 2009. On January 4, 2010, the security trade press reported that certain hardware-encrypted USB flash drives had been hacked. This is not exactly true, since it was really the unlocking software that was hacked. Simply put, these drives used software on the host computer that would accept your password, determine if it was correct, then send an unlock signal to the drive. The problem is that the unlock signal had nothing to do with the password. Let me explain.


(Yes, please do. Can’t wait to hear this one.)


Stop rolling your eyes. Now, think of an electronic keypad used to open a door. You enter a code and if the code is correct, the door opens. Or, more specifically, the keypad completes a circuit that tells the door to open. The brute force way to open the door is to pry the keypad off the wall. When you do that, you will see two wires that complete the circuit when the correct code is entered. In other words, it does not matter what code you enter, since you can take the keypad off the wall and connect the two wires.


(Suddenly I’m not feeling all that safe in my home).


No comment. Anyway, all of the hacked USB flash drives use AES 256-bit hardware encryption. Since AES 256-bit hardware encryption is pretty much un-crackable, the penetration testing experts (also called white hat hackers) decided to crack the password-checking mechanism.

 


(You mean, they decided to "pry the keypad off the wall and connect the two wires?")

 


Exactly. When analyzing the drive unlock program that ran on Microsoft Windows, these security experts found a rather blatant flaw. During a successful authentication procedure, they found that the program always sent the same set of characters to the drive after entry of a valid password. Going back to the electronic door keypad analogy, this set of characters essentially "connects the two wires" to unlock the drive. To "pry the keypad off the wall," figuratively speaking, the experts wrote a small program that would send the appropriate unlock characters to the drive, regardless of the password entered. As a result, they gained immediate access to the data on the drive.

 


(I knew it. I'm just not smart enough to be a criminal. I would never have thought of that.)


Even though validating the user's password and unlocking the drive was a key part of the drive's security syste,, the software module was OUTSIDE of the FIPS 140-2 security boundary and therefore was not evaluated by the testing lab.

 


(So, whose fault was that that it wasn't included?)


A very good question and that is the key point. The testing lab only validates what the company submitting the product asks them to test. If the company defines a security boundary that doesn't include key parts of the system, as was done in this case, companies that buy the product could be at risk of data disclosure or worse.


(So how can I prevent this from happening to me?)


Before you buy any system that uses encryption to protect your information, you must not only understand what FIPS validation is and is not, but more importantly, you must also decide (correctly) whether a specific device will  (or will not) meet your organization’s requirements. Finally, I would recommend that you ensure that the manufacturer (not the vendor) of the encryption product you are purchasing is security-savvy and can prove beyond a doubt that the design and implementation of their product is secure.


(In our last post, Ron, you promised you'd give a list of questions to ask vendors before assuming that the product they are selling you is secure. I've gotta keep you honest here.)


Yes, I did promise that, so here goes. These are the questions you might want to ask before plunking down a big chunk of change on security products:

  • How is the security boundary defined and what functions are performed outside of it?
  • Do symmetric or private encryption keys ever leave the security boundary without being protected (i.e., by "wrapping" them with keys that never leave the security boundary)?
  • Is user authentication performed inside of the security boundary?
  • Do any of your security components come from countries that might want to do harm to my country?1
  • Has your security implementation been evaluated by an independent lab?


Because we feel so strongly about protecting our customers' data, NetApp has partnered with Brocade and SafeNet to provide our storage fabric-based encryption solutions for this very reason. We are the storage experts and they are the security experts, so it's a perfect match.

 


Next time we'll discuss why the word, "loss" has so many different meanings when it comes to digital assets. While you’re waiting, your homework is to write a paragraph on what "Data Loss" means to you.

 

 

 

 

  1 Acting deputy secretary of the DHS National Protection and Programs Directorate, Greg Schaffer, admitted on the record that DHS is aware of instances where electronics imported into the United States have been pre-loaded with malware, spyware, and other cyber-security threats.

Who Gives a Flip about FIPS?

Posted by chiragc Jun 22, 2011

5.png


By Ron LaPedis and Maryling Yu

 

Okay Ron: what is FIPS, what is 140-2, and what do these various levels mean? (And do I really want to know?)

 

FIPS stands for "Federal Information Processing Standard." This is a set of U.S. government standards for use in computer systems by all non-military government agencies and by government contractors, one of which is publication 140, version 2 (140-2), establishing the Cryptographic Module Validation Program.

 

(In English, please? That would help.)

 

In English, this means that the US government has come up with a set of specifications for software and hardware that can encrypt digital data. FIPS 140-2 calls out four different levels of protection, with each level adding additional features to prevent or detect if a hacker can gain access to the "cryptographic material," or encryption keys.

 

(So each level is more "stringent" than the one before? Does that mean Level 3 is more badass than Level 2?)

 

Well, to put it simply, yes. You can look at it that way, Mare. If you like WW II spy movies as much as I do, you'll remember that each agent has a copy of the secret codebook that specifies which encryption key is used for what and when.

 

(Sorry Ron, I am not old enough to have watched any WWII spy movies - at least, that's what I keep telling myself).

 

Well, you can imagine that if the enemy captured a codebook, then they could decode the good guys' messages–and then the good guys would be sunk. So, the codebook needed to be protected at all costs, including burning it or sending it to the bottom of the sea if capture was imminent. In fact, you can think of the codebook as a key manager, so look for that phrase in a blog post later on in this series.

 

(All right, codebook = key manager. Got it.)

 

But getting back to the explanation at hand…within publication 140-2, four levels of physical tamper security are called out:

  1. No specific physical security mechanisms are required (usually for software)
  2. Requires features that show evidence of tampering
  3. Must have a high probability of detecting and responding to attempts at physical access, use, or modification of the cryptographic module
  4. Provide a complete envelope of protection around the cryptographic module with the intent of detecting and responding to all unauthorized attempts at physical access

 

Level 1 provides no protection whatsoever and just shows that the algorithm and implementation of it meet FIPS compliance. Level 2 validated devices need to show the user that the keys may have been accessed (but doesn’t need to destroy them), while levels 3 and 4 require the cryptographic module to actively prevent access to the keys, perhaps by erasing them if there is a chance that an attacker might access them. So yes, each level is more "badass" than the last, to put it in Mare's "technical" terms.

 

(Cool!)

 

For commercial and most government systems, Level 3 validation is good enough. But for military and other homeland security applications, level 4 might be required (and you can surmise why that would be).

 

(That's all for this week, folks. In our next post, Ron will explain what FIPS validation does and does not mean and what questions you should ask your vendor before buying a FIPS validated encryption system.)

By Ron LaPedis and Maryling Yu

 

(Of course, doodies need to be separated, too, but that’s a topic for another time on my motherhood blog.)


Why do we want to separate duties? Because this prevents a rogue from being able to both steal data AND cover it up (kind of like why you want one person to write the check in a company, and another person to sign it, or why you don’t want your accountant to be your auditor). Right.

 

How do you properly set up separation of duties? By following these rules:

  • A “Root” or “super-user” account is allowed complete access to the system or network. (So anyone logged on to this account has unlimited power that can be used for good or for evil?) Exactly. And because some people are evil, the password used to access this account should be locked away and never used except in case of dire emergency.
  • Since the “super-user” account is all-powerful, it becomes a juicy target for hackers. In case it somehow gets compromised, the “super-user” account should be prevented from changing the password of any other account and should not be able to log on to any other account either. Further, it should not have any access to the security subsystem.
  • One or more security administrator accounts should be created, each with specific, limited authority, and assigned to a separate individual as follows:   
    • The administrator who can create, roll, and alter security logs has no other system access.
    • The administrator who can modify security subsystem settings cannot access the logs, nor modify user settings.
    • The administrator who can modify user security settings cannot alter the security subsystem nor access the logs.

 

 

 

(So you’re saying that a company has to hire 3 full-time employees just to have a proper separation of duties? Seems like a lot of dough to spend.) Well, yes. No one ever said security was going to be cheap. But you should weigh this against possible losses due to theft of company secrets or improper disclosure of company confidential information.

 

(But this doesn’t prevent the employees from going into cahoots and stealing data together.) That’s called “collusion.” And no, separating duties does not prevent it. However, the chances of two or more employees getting together to perform criminal acts is much lower than that of a lone wolf acting on his/her own.

 

Similarly, system, backup, and application accounts should also all be separated.

  • The administrator who can back up and restore files and databases should not be able to read and write them.
  • The administrator who can start and stop applications and databases should not be able to access them.
  • Applications and databases should be owned by “frozen” accounts. This will help prevent anyone from logging on to this account where they might have full access to an application or database

 

 

By wisely separating duties, encrypting your files and databases, and securing them to specific users and computers, you will create an environment that provides much more in-depth defense of your critical applications and data. These settings will make it much more difficult for an attacker because he won’t be able to log in to the accounts that own the applications and databases.

 

And to increase the overall security of your encryption, ask if FIPS 140-2 Level 3 validated hardware is used to 1) generate and store the encryption keys, and 2) encrypt and decrypt the data you are trying to protect. (Say what? Come again?). Don’t worry, this will be the topic of our next post.

 

 

ntapcloud.jpg

By Ron LaPedis and Maryling Yu

 

Last week we ended with "the most secure encryption system in the world is totally useless if a hacker can get to the data as an authorized user," so let's take a look at what could transpire.

A hacker could do something like the following:

 

  1. Find a weak spot in the targeted organization's network through targeted probing or an advanced persistent threat (APT). (For encryption newbies like me, APT is basically when a bunch of really smart and really bad people try really hard over a period of time to break into a specific entity's systems.)
  2. Gain access to one or more accounts on one or more computers on the targeted network and use this access to determine which computer or storage module has access to the data he wants. (Or she, as there are smart and not-so-nice women hackers out there too. Aren't there?)
  3. Gain elevated privileges on the computer and access the targeted files.
  4. Exfiltrate the files and bam! The deed is done.

 

(Wait, something's wrong. I'm understanding Ron so far.)

Since FDE drives are decrypted as soon as they are powered up, the attacker may hit pay dirt as soon as step 1, since s/he does not need to target a specific system, but can use any system that has access to the disks holding the data s/he is interested in. (Yes, Ron did end that last sentence in a preposition, but he was just trying to fit in with the rest of us.)

 

 

When granular encryption is implemented, it can be much more difficult to attack the system because specific data can be encrypted and secured to specific accounts and computers. That is, only a specific account on a specific computer has the ability to view the decrypted data. Now the attacker not only needs to find out which computer has access to the data s/he wants, but also needs to find out which account(s) have access to the data. If the proper separation of duties is implemented, gaining elevated privileges may not help the attacker.

 

What is the proper "separation of duties," you ask? Well, as it turns out, I asked that, too. Stay tuned for our next post on this topic.as.png

By Ron LaPedis and Maryling Yu

 

locker.png
Last time, we discussed (well, more accurately: Ron schooled me on) how implementing encryption at the storage layer alone (i.e., only Full Disk Encryption or FDE) can leave data vulnerable to “exfiltration.” But the storage layer is not the only place where one can have encryption; one can also encrypt data at the storage network or fabric layer, too.  (Even I know that.)

 

Whether you operate a Storage Area Network (SAN) or use Network Attached Storage (NAS), you can add substantial protection by dropping in an encrypting switch or appliance. By doing this, your data gets encrypted from the time it hits the first fabric switch. But more importantly, depending on the functionality of the encryption solution you choose, administrators can use unique encryption keys and enforce granular access policies. This means that data can be separately encrypted at the LUN, client, department, group, user, server instance, and share level. Unlike FDE, this solution can allow an administrator to isolate data access to specific computers and users. (This means that they can lock out, for example,obviously dangerous people like Ron, but not nice people, like me.)

 

Of course, this assumes that your administrator remembered to set the proper encryption and access policies. Since accidents do happen, FDE makes a great backstop in case drives are repurposed. So if you use network-based encryption in addition to FDE, your data is a lot safer than it would be with FDE alone. But there is one more requirement that has nothing at all to do with encryption: proper separation of duties. To more fully understand how network-based encryption augments, but not necessarily cements, your security strategy, consider this: the most secure encryption system in the world is totally useless if a hacker can get to the data as an authorized user.

 

(And now that we’ve surpassed the optimal blog word count, Ron will just have to save his pontifications for next time.)

 

But until then, you can check out these links below for more information on NetApp’s approach to FC and SAN encryption.

For information on our Fibre Channel SAN encryption products

For a preview of what’s coming soon

By Troy Eberlein

Just announced: NetApp SnapProtect Software

As you may have already seen, today NetApp announced the release of SnapProtectTM management software, our newest addition to the NetApp Integrated Data Protection portfolio. SnapProtect is a backup application designed to accelerate and simplify backup and recovery across disk and tape through the integration of NetApp Snapshot copies and thin replication with traditional backup management.

 

NetApp SnapProtect includes all the reporting, scheduling and catalog functionality that you would expect from a mature backup application, but uses low impact Snapshots as the backup medium to improve speed and efficiency of their backup operations.  A unified catalog, for instance,  tracks backups across disk and tape, accelerating search and restore operations. SnapProtect is also a virtualization and application-aware software that integrates with NetApp FAS and V-Series to create a Snapshot backup in a matter of seconds.  Backups are captured at the array-level without impacting the applications and virtual infrastructures running on top of your NetApp storage.

 

For disk-to-disk backup, we leverage SnapVault replication.  With SnapVault under SnapProtect management we can track and hold months, even years, of backups on secondary disk while reducing the amount of data that must be transferred - without heavy-weight client side dedupe.  SnapProtect also eliminates the need for intermediary backup servers because SnapVault is a point-to-point replication technology. And for long distance data protection, SnapProtect software has the ability to manage SnapMirror replication policies. This allows customers to start converging data protection into a single workflow for simplicity of management. When it’s time to move data to tape, SnapProtect software can handle that too with NDMP or media agent assisted backups, all from the same management interface.

 

SnapProtect software also allows you to enjoy the benefits of NetApp's innovative storage efficiency technologies, which are widely recognized in the industry and can reduce storage usage on primary and secondary disk by up to 90% to optimize IT efficiency.

 

More information on how SnapProtect software can modernize your backup and recovery strategy can be found on the http://www.netapp.com/us/snapprotect

By Ron LaPedis and Maryling Yu

 

Ron LaPedis is a bona fide security expert, and NetApp’s Security Solutions Marketing Manager. You’d have to have bionic body parts to be geekier than he is on the topic of encryption and security. I, on the other hand, have the technological knowledge of a high school cheerleader (but alas, not the looks) (editor’s note: yes, she does). So, we make a good team when it comes to translating securit-ese into plain English. Because if I can understand it, then so can everybody else.

 

Take the bomb that Ron recently dropped on me: Full disk encryption (FDE) alone may NOT protect your data from theft or disclosure.” Say what? I thought encryption = security. Well, Ron says no, and that it’s time to wake up and smell the coffee. How come?


Basically, Ron broke it down for me as follows:


When encryption is implemented only at the storage array level (which uses FDE), the data is only protected when the disks are powered OFF. As soon an authorized user flips the “ON” switch, the data on the disks is decrypted and available to anyone with permission to connect. This is also true of laptop FDE implementations; unless the laptop is powered off, the data is not protected.

 

 

He then asked me, “How often do you actually power off your laptop versus putting it in a hibernating state?” Sheesh, I just put the lid down…am I not turning it off? I got an eyeball roll for that one.

 

So what good is FDE then? Well, FDE protects data if the drives are shipped from one location to another, sent back to the manufacturer for spare or upgrade exchange, or sold/ repurposed. FDE also acts as a backup plan in case higher-level encryption (for my sake and that of other encryption newbies, higher-level refers to layers higher than storage, i.e., network or server) is not enabled either by accident or on purpose.

 

 

Stay tuned for next time, as Ron attempts to break down, and I attempt to absorb, NAS/SAN encryption.


Picture1.png

By Nathan Moffitt

 

Over the last few months we’ve seen an uptick in customers asking whether NetApp can provide a 3 site disaster recovery solution that leverages parallel replication streams.  The easy answer is yes – we can.  But it raises an important question – do you, the customer, really need it? To answer the second question let’s take a step back and examine what 3 site DR is.  3 site DR refers to a disaster recovery strategy running across devices in different facilities.

 

Picture1.jpg

Figure 1

 

 

 

This can be accomplished via a cascade relationship (Figure 1) or parallel synchronous and asynchronous replication streams (see Figure 2).  In this blog we’ll focus on the second configuration.

 

Picture2.jpg

Figure 2

 

 

In this context a 3 site deployment begins with the primary storage array replicating data synchronously to a nearby site.  The maximum distance between nodes will vary based on line latency and I/O processing speed of the storage system, but this will be less than 200km. Otherwise the host application can experience response lags due to latency that impact application behavior.  Since this replication method requires I/O to be committed on both nodes before an acknowledgement is sent to the host, the secondary node will be synced with the primary node; delivering zero data loss at the storage level.

 

NetApp can accomplish this part of the deployment with either SnapMirror sync or MetroCluster.  Choosing which product to use will depend on some specific considerations that we can discuss in another article.

 

Next, the primary storage array is configured to replicate data asynchronously to a more distant site (Note: This will result in additional overhead on the primary storage array because it has to manage 2 different replication policies).  The maximum distance between these nodes is often much longer (e.g. across state or country boundaries) and is bounded by both networking considerations (line latency, available bandwidth) as well as business requirements (RPO, cross-nation information privacy).  NetApp accomplishes this using asynchronous SnapMirror.

 

In the event of a primary site outage, services will failover to the synchronous DR site so that operations can continue with an up to date copy of the data.  The asynchronous replication policy will then be updated so that the ‘new primary’ (the sync DR site) is replicating to the 3rd system (the async DR site).

 

 

From a ‘completeness’ standpoint this is great, you get zero data loss and continued DR operation in the event of an outage.  But from a budgetary standpoint?  The price tag can be pretty high when you consider that you need:

  • 3 sites.  For organizations with data centers running in 3 or more sites, this may not be an issue.  But for many organizations the cost of DR facilities at 2 other sites – even if it’s co-lo space – can be cost prohibitive.
  • 3 sets of storage (and servers to run the apps).  This will raise both your capital expenditures (the gear) and operational expenditures (power, cooling, staff time).
  • Network lines between all sites.  This cost should not be under-estimated.  High speed lines with sufficient bandwidth to meet RPOs can be very expensive.
  • Backup.  This one may seem obvious, but it can become an interesting discussion point.  If you intend to have the sync site become the new primary site after an outage, you may want a backup infrastructure there too.  If you are concerned about 2 outages….

 

 

Together these factors can easily double or triple the acquisition and ongoing cost of providing DR for an application workload.  That means less available budget for other tasks or dropping DR for another application workload.

So is it really worth it?  Maybe. (If only it were a binary question!)  There are certain applications where this level of redundancy is worth the extra cost – and the extra performance overhead of running 2 replication policies on the primary storage array.

 

 

This could be for services that are critical to many people (e.g. power) or have financial / legal impacts (e.g. trading operations).  But for most application workloads it’s not needed or there are alternative methods of accomplishing a similar goal.  Two such alternatives are:

  • Using backups as a temporary DR strategy. Many customers find that they can execute a 2 site DR strategy and use backup as the next line of defense in the event of another outage.  RTOs and RPOs may be longer but costs will be lower.
  • Using a service provider (DRaaS) to provide temporary DR functions.  As an on-demand strategy this is likely to be more cost effective than maintaining another set of gear / site.  Of course you need to also consider the time to re-baseline.

 

 

In every case though you should always consider end user impact.  As BC planners will tell you, people (consumers, staff, etc) are a large factor in any DR solution.  If the people who use your applications cannot access them in a timely fashion, then DR is of limited value.  The implication then is that if you implement a 3 site DR solution of any type, be sure you have enough bandwidth to handle the user load at the failover location(s).

If you decide to move forward, there are probably still things you can do to mitigate costs.  A few options include:

  • NetApp deduplication to reduce capacity consumption / network utilization.
  • SnapMirror network compression to the asynchronous site to reduce network utilization.
  • FlexClone of the async site so that it serves multiple purposes (you still buy the gear but now it’s also being used for dev, business intelligence, etc).

 

 

Obviously there is a lot more depth that we can go into here, but hopefully this helps outline what 3 site DR is and the considerations of implementing it in a parallel stream configuration.  If you want to discuss how to set it up or go deeper into planning, let us know or contact your local rep.

 

Cheers,

NLM

Do you Have Dead Beat Data?

Posted by chiragc Jul 19, 2010

Would you buy a storage array, plug it in and then leave it idle on the floor of your data center?  Probably not, because even if you ran the most philanthropic of companies, you’d rather not expend money or floor space on storage capacity that isn’t adding value on a daily basis.

 

So then why would you keep a storage array full of data that’s doing nothing?  Why would you spend money storing dead beat data?

 

The typical response I get when I ask this question is ‘I don’t have any data that’s doing nothing.’  But is that really true?  Lets ignore for a second the old .ppt and .xls files on your file shares because while these files may not be used often, they represent only a fraction of your overall storage footprint.

 

Instead let’s consider the data that can easily double your storage footprint:  your disaster recovery and backup copies. This data spends the bulk of its life in an idle state, hanging about and doing nothing – much like my first college roommate who only got up to let in the pizza delivery guy.

 

Don’t get me wrong, this data is important and has tremendous potential to help the organization in case of a site outage, system failure or data loss.  But on a day-to-day basis it adds no value back and is a constant target for budget cuts and delayed upgrades (much as my roommate, who could have been a great surgeon, became a victim of scholarship cuts due to his lack of activity).

 

Over the years this has led me to ask the question:  Can we put data protection to work for other purposes?  Can we take what management often treats as ‘dead beat data’ and use it to earn value for the organization beyond risk mitigation (as well as improve budgetary funding)?

 

The answer is yes.  There are a number of ways you can use data protection to drive business efforts from test (accelerating business processes) to business intelligence (enhancing business strategy) to eDiscovery (meeting compliance requirements).  Not only does this increase the value data protection provides, it results in greater efficiency – because you are getting greater use of your assets.

 

NetApp Integrated Data Protection, enables you can do accomplish these activities faster and at a lower cost, especially when used in conjunction with FlexClones.  To learn more – check out the white paper that we wrote with the Mesabi Group.

 

Cheers,

Nathan Moffitt

By Jeremy Merrill, Jim Lanson and Nathan Moffitt (not a law firm).

 

Part I and Part II

 

So what about deployment SLAs?  Here the goal is to reduce the amount of ‘stuff’ that your team must roll out to production and the steps required to do it.  This enables you to have new systems up faster and less time is spent in the data center when adding new DP services.  This is not only critical for keeping business partners happy and meeting roll out schedules / change management windows – it keeps your staff from being consumed with manual labor.

 

Storage clustering deployment usually involves roll out of 2 arrays, installation of host side software (drivers) and failover scripts to manage I/O as well as the creation of volume relationships for failover. All of these steps taking time and in the case of scripts periodic testing / updates.  MetroCluster automates storage failover and I/O without requiring scripts or host-side software to manage the storage.  Even complex replication relationships are simplified because MetroCluster works at an aggregate level which can contain multiple volumes.  This also reduces risk because when a new volume is created on one side, it is automatically protected on the other array.  Together this can reduce roll out time to under 10 minutes.

 

While host-based replication may require software installation and configuration, array-based replication deployments tend to be much simpler.  The service is activated and relationships between volumes (or qtrees) defined between the 2 storage arrays.  This process can be accomplished in minutes via the command line or even faster if Protection Manager policies were created previously for another system and can be applied onto the new system.  We wouldn’t say NetApp has a ‘significant’ advantage here over most array-based replication products but it is definitely faster to deploy than products which again require host-side software and middleware storage (or clusters of storage).

 

For backup the benefits can be more significant.  Deploying a new backup solution requires installation of backup agents, backup servers (with backup software), specialized backup storage and potentially host upgrades for LAN-free backups.  When a backup solution is already in place you will still need to deploy agents, upgrade hosts and – depending on performance / capacity loads – additional backup servers and specialized backup storage.  As you know this isn’t easy.  It’s cumbersome to roll out and even once it’s deployed you have to add the host to the backup rotation, apply the schedule and (with tape) allocate drives and media pools.

 

SnapVault eliminates roughly 90% of this deployment overhead.  In a basic configuration there are no backup servers to deploy, no specialized agents or host upgrades required, no complicated schedules to apply and no specialized backup storage.  There’s just a NetApp FAS system talking to a NetApp FAS system.  Licenses are activated, schedules are configured in minutes and you’re done.

 

Now, we said basic because obviously we can add more value by adding on Protection Manager and SnapManagers.  Adding Protection Manager will add a step to deployment, but since it manages backup and replication policies versus managing and acting as an intermediary for LAN based client backups, you only need to deploy one Protection Manager system not multiple backup servers.  You also gain the advantage of being able to:

 

 

  • Apply existing policies to new systems cutting down configuration time
  • Get alerts about unprotected storage (how many servers do you know that have rolled into a data center and not been added to the backup rotation causing you to get sidetracked).
  • Use a single management console for replication and backup
  • Automatically provision Secondary (backup or DR) storage based on selected policies

 

 

There are also the SnapManagers.  Again this will increase deployment times because an agent is being installed.  But it’s worth it if you have an application or infrastructure that requires quiescing.  Without SnapManagers you get a crash consistent copy of data which can take longer to recover.  You also don’t get the application specific recovery functionality we talked about before.  

 

So with the addition of SnapManagers and Protection Manager are deployment times for traditional backup applications and SnapVault at parity?  Not really.  Again, there is no deployment / maintenance of multiple backup servers, no need to upgrade hosts and no need to roll out specialized backup storage. For an average size environment (> 30 servers) the deployment of SnapVault with Protection Manager and SnapManagers will still be faster to deploy than a traditional backup environment.

 

table.png

 

Finally, there needs to be a discussion around wants and needs.  While everyone will want zero data loss, there is the monetary consequence – usually quite significant.  What are the bare minimum requirements and what are the “real” requirements?  Typically a happy medium can be found between the needs and wants.  At NetApp we’re happy to discuss this and help you design a solution that delivers that balance without overloading your budget.

By Jeremy Merrill, Jim Lanson and Nathan Moffitt (not a law firm).

 

As mentioned in Part 1, when you think about speed in the design of a data protection strategy – you really need to step back and think about “can I meet my recovery SLAs – as well as my deployment SLAs”.  In this part of the blog we’ll look at how NetApp can help you meet both goals.

 

To start, let’s look at recovery SLAs.  When recovering from an outage the RTO and RPO will vary based on the importance of the application (business process) and the level of outage you are looking to protect against.  When protecting against local and metropolitan issues for mission critical applications the RPO is usually zero and the RTO minutes to hours based on the time it takes to:

  • Failover the application, servers and storage
  • Roll back to a specific consistency point
  • Restart dependent applications
  • Re-establish user connections

 

 

Application dependencies can eat up a large portion of the RTO so it is critical that server and storage failover rapidly.  NetApp offers MetroCluster – a stretch storage clustering solution – to enable an effective zero RPO by providing array-based synchronous mirroring at the aggregate level. This method uses a FC interconnect for low latency and enables a lower mirroring overhead   by avoiding duplicate writes on each controller (instead writes go directly to the disks).  Recovery from any single component failure is transparent to the host.  In the event of the loss of a site, failover can be performed with a single command (or automated) making all data services available almost immediately.  Alternatively SnapMirror Sync to achieve a zero RPO over IP networks.  RTO is slightly longer due to the fact that replication relationships must be broken before use (however this can be reduced by using the Protection Manager Failover function).

 

This solution works well for shorter distances (200km or less) but over longer distances, latencies will occur (speed of light, etc).  In this case a synchronous solution is not advisable due to the impact in I/O commit to both systems.  For longer distances a semi-synchronous (up to ~500Km) or asynchronous (long haul, lines with greater latency) solution is advisable.  These solutions provide a similar RTO to synchronous SnapMirror but a longer RPO of minutes to hours – which is still significantly better than tape RPOs and RTOs.

 

To improve RPO over these longer distances SnapMirror Async  (volume SnapMirror) leverages primary deduplication and native network compression.  As you might think, deduplication improves RPO by reducing the amount of data that must be transferred and allowing more frequent transfers to occur.  SnapMirror network compression can also be enabled to allow more frequent transfers (although you probably wouldn’t use it in conjunction with deduplication).  In this case data is compressed (up to 70% reduction) before it’s sent and then decompressed before it’s written to disk.  When used with an increased SnapMirror window sizing this can accelerate traffic on high bandwidth/high latency networks.

 

For backup recovery points, NetApp offers SnapVault which performs D2D replication in a purely async mode.  SnapVault enables you to keep a handful of snapshots on the production storage (which is usually the higher end disk) and store more, longer term snapshots on the secondary storage (usually the lower end, higher density disk).  SnapVault can be used to reduce RPO from the typical 24 hours to as little as 1 hour (note: using local snapshots in conjunction with SnapVault enables RPOs of minutes).

 

SnapVault has the ability to restore an entire dataset, or just an incremental amount of data (assuming some of the data still resides on the production system).  And since it’s a direct disk-to-disk transfer, RTOs are significantly faster than tape (minutes versus hours) and can even be faster than other disk appliances that require you to restore through the backup application.  In addition, since SnapVault doesn’t modify the data from the original format so a simple CIFS/NFS connection can be used and end users can restore single files by using copy/paste for a lower RTO.

 

All of these technologies can be used with NetApp SnapManagers, application specific data protection agents.  SnapManagers automate the process of quiescing I/O, putting the application into a ‘hot backup mode’ (if needed), creating an application-consistent snapshot copy and activating replication to a remote system.  To reduce RTOs, SnapManagers will include application specific recovery functionality (e.g. Exchange single mailbox restore or VM failover).

 

RPO / RTO benefits at a glance.

 

NetApp   Product

RPO /   RTO Enabled

MetroCluster

Zero   RPO and RTO of seconds (for storage) from clustering

SnapMirror

  • RPO of   zero or minutes to hours based on distance
  • RTO of   minutes (for storage) with app integrated failover
  • RPO   acceleration by transferring less data

SnapVault

  • Flexible   RPO of minutes or hours – not just 24 hours
  • RTO of   minutes (for storage) using block level incrementals
  • RTO   acceleration through end user restores

SnapManagers

RTO   acceleration through application consistent & specific recovery

Filter Blog

By author: By date:
By tag: