NetApp's Compliance Isn't Compliant

I came across an interesting tidbit from the NetApp camp today.

It seems their version of compliant archival storage, isn't, well... compliant.

A brief background: archival storage frequently is used to store data (email most prominently) that a regulatory body has determined that a company must keep. Mostly so massive evidence shredding a la Enron doesn't happen again.

You need special storage to meet these requirements (from the SEC, Sarbanes-Oxley, and so on, as well as their respective counterparts in Europe and Asia). Normal file storage doesn't cut it.

EMC has met this need for nearly a decade with Centera. (In fact, there are 3 versions of Centera desinged to meet different compliances objectives.) NetApp has "Compliant SnapLock" and you can find similar umm, hacks, from other vendors.

And I call them hacks for a reason: EMC believes that compliant archival storage should, amongst other things, not have a file system that is exposed to the user. There are a bunch of characteristics I want to see for compliant archival storage, but that is one of the big ones. I am open to correction on this, but I think Centera is the only platform that actually does this.

Now, all this has come to bite NetApp in the proverbial posterior: "...versions of Data ONTAP® prior to 7.2.5 with SLC have been found to have vulnerabilities that could be exploited to circumvent the WORM retention capability." They go on to say: "NetApp cannot stand by the SnapLock user agreement unless the upgrade is performed."

Now this is a really big deal. This is not a trivial little upgrade to OnTAP. This is a big one. There is a reason why thousands of NetApp customers haven't made the lead yet: it is risky and and it hard.

In the words of NetApp themselves: "This upgrade is a one-way procedure."

So, anybody running a version of OnTAP older than 7.2.5 isn't compliant.

I hope you don't have any visits from the auditors scheduled in the next couple of months...

Or years...

Or maybe it is time to explore an alternative?

Comments

[Kostadis Roussos]

Hi,

My name is Kostadis Roussos and I am a Technical Director at NetApp.

In spite of the claims in the original post, NetApp SnapLock Compliance continues to work.

Why did we not communicate before now? We are certain that it would take malicious intent AND more architectural knowledge than anyone other than our own design engineers possess to exploit the issue. The flaw can not be exploited by accident.

Was Customer data at risk? Only if our customers have staff criminally intent on destroying data. It would become apparent very quickly at a customer site if the flaw had been exploited. In fact the key point of note is that no vendor can guarantee with 100% assurance that data will never be lost due to any circumstance.

The Compliance business is all about trust and due diligence. NetApp discovered the flaw during rigorous multi-product testing. We have fixed the flaw in a timely manner.

All software companies have bugs, some are more serious than others. If, in NetApp’s judgement, an earlier warning had been warranted, we would have published it. No customer has reported lost or corrupted Compliance data due to this flaw. This was not an issue which warranted earlier communication. That even a required upgrade notification can be so badly distorted, into an unwarranted assertion that the product was never compliant, only calls into question the motives and credibility of the poster.

Due diligence says customers should upgrade now that we have released versions which fix the flaw.

You can read my blog at
http://blogs.netapp.com/extensible_netapp/

[Scott]

The comment is reasonable and informative so I am putting it up for the readers.

I do understand the "obscurity vs. disclosure" argument when it comes to security flaws. At the end of the day, this is a pretty serious one. It prevents/damages the core function of the software. I can appreciate NetApp's position, but I still wouldn't want to be the one to explain to an auditor how long I was going to be non-compliant for.

Edit: I am going to append this with one more comment. Having incite the invective machine over at NetApp (again), I would love a genuine legal opinion on this: if you store something in a non-compliant way for a year, can you later make it compliant? If a chain of custody is broken, can it be re-forged? If all that data under SnapLock isn't compliant now, and you can't prove that it is authentic now, then upgrading SnapLock is no more than letting the horse out after the barn has burned down. All that data? Never compliant again.