In-Depth
Resolved for 2007: No More Lying
The release of CERT information raises a controversy between storage security vendors.
Just before the holidays, I received an e-mail from a press agent for Decru, a maker of storage security appliances and not long ago purchased by NAS maker Network Appliance, that was purportedly "spilling the beans" on a deficit in a competitor’s products. Before you raise your eyebrows, understand that tattling is about the only way that the industry has to police itself.
What made this document interesting was the supposed validation of its claims by the United States Computer Emergency Readiness Team (CERT), which, according to e-mail, had "issued an alert this week that NeoScale’s CryptoStore 700 series appliances fail to properly perform two-factor authentication." There was a link to the CERT Vulnerability Note, creating the impression of a fact-based hit, and something for users of NeoScale’s product to be legitimately concerned about.
I queried NeoScale CEO Barbara Nelson on the matter to get her perspective. She wrote back, explaining that Decru "sent a barrage of different e-mails to customers, partners, analysts and press. In the piece to customers and partners, they completely fabricated information describing a serious security problem that flat out doesn’t exist, and then cut and pasted the CERT doc to look like that was what the CERT was about."
Nelson added, "We did have a very low-level vulnerability reported in a CERT—although it was an issue with legacy product and it is not an issue in our product shipping. Obviously this information is conveniently omitted."
While I was not shown the "cut and paste" version of the Decru release described by Nelson (mine just had a link to the document at CERT), there did seem to be misrepresentation of the depth and breadth of the problem. Apparently the whole matter can be resolved via a simple firmware upgrade—and that is according to CERT.
Nelson seemed to take the matter in stride, "All in all, surprising lack of ethics given they are now part of NetApp. I’m flattered they are resorting to desperate tactics—perhaps it’s an indication of the competitive pressure we are applying to win deals."
The official position of NeoScale on this matter came down to three points, which I recount here in full:
First, NetApp/Decru created a targeted marketing campaign "misrepresenting the CERT report—Decru used some pivotal language in their communication that was simply incorrect: ‘An attacker who obtains a user password can "gain access to the System Key" without presenting a smartcard.’ This statement is completely false, is not included anywhere in the CERT advisory, and has nothing whatsoever to do with the CERT advisory."
Second, NetApp/Decru said this is a "significant vulnerability"—"CERT categorizes reported vulnerabilities according to a ‘Severity Metric’ that ranges from 0 to 180 (180 being the most severe). This particular vulnerability is rated "Not Critical" at 0.64 (zero point six four). In CERT terminology, a significant vulnerability is one that would be handled with a CERT Technical Alert (as opposed to an advisory like this) and is indicated by a Severity Metric of over 40."
Third, CERT advisory contains three sections: Description, Impact, and Solution—"In the screenshot that NetApp/Decru e-mailed, they conveniently omitted the third section giving the impression this was an unfixed problem. The third section contained the fact that a software upgrade would address the problem, details of exactly how NeoScale has fixed the problem and the fact that it was already fixed in v2.6."
The response seemed plausible, complete, and consistent with what I know about CERT, NeoScale products, and the integrity of Barbara Nelson. While I am not naïve about the ways of marketing, I have to admit that this little exchange between two leaders in the appliance-based storage security market left a bad taste in my mouth.
Decru’s Side of the Story
I contacted Decru with a copy of Nelson’s rebuttal in hand and received a different take on the story. Kevin Brown, vice president of marketing, said that after the CERT vulnerability hit the press, Decru did forward links to the official CERT web site to select press and analysts who cover storage security. "The first question we get in situations like this is, ‘Does this type of vulnerability affect Decru?’ It’s obviously important for us to address any concerns of this type."
Additionally, Brown said, links and excerpts from the CERT site were distributed internally "to educate our teams about the vulnerability, and how to respond to any customer questions about Decru’s authentication. In a few cases, individual customers were forwarded the CERT links and excerpts to address any questions."
That much of the story told by Nelson is true, but her subsequent statements were filled with inaccuracies, according to Brown. He noted that the language Nelson found objectionable in the Decru release pertaining to a "misrepresentation of the CERT report" was in error. The language cited by CERT, part of a Vendor Statement on a sub-page of the CERT web site, was posted by NeoScale, then altered by NeoScale a few days later. Brown contends, and sent along before-and-after screenshots of the Vendor Statement pages from CERT to make his case, that Decru did not misrepresent the language on the CERT site. "This statement by NeoScale is 100 percent false. The language in question regarding the System Key was NeoScale’s own—it was excerpted directly from the NeoScale Vendor Statement posted on a sub-page of the CERT Website."
Brown also took exception to Nelson’s dismissal of the advisory as not critical. CERT’s rating scheme, he noted, factors in many variables (he provided a link to the scoring criteria used by CERT) and that even if Nelson and CERT weighted the problem as insignificant, the Department of Energy’s rating system would classify the threat as MEDIUM, and did in their advisory of the NeoScale vulnerability.
He agreed with Nelson that the problem had been fixed, but stated that this was a "moot point" since "CERT only posts vulnerabilities once they are fixed." He said that his concern was that "the fact that the flaw was ‘already fixed’ in new versions of the product does nothing to mitigate the impact on hundreds of installed base units that may need to be updated."
The bottom line, Brown said, is that "based on the factual information above, Decru clearly did not distribute any ‘deceptive’ statements or ’half-truths.’ I’ll let you be the judge of whether NeoScale can say the same."
Brown had prefaced his remarks in an e-mail cover letter stating his position: "Even though we were taken aback by some of NeoScale’s statements, our approach has been to de-escalate the situation and avoid a protracted ‘he said, she said’ volley." Frankly, I think the whole issue could have been avoided by simply not broadcasting the CERT advisory about a competitor’s wares to every media outlet in town—especially once the issue had been resolved.
The Bottom Line: Finding Solutions
At the end of the day, this story is not about "he said, she said." It is about finding solutions to the tricky issues of storage security.
Companies are sincerely seeking encryption techniques to safeguard data that is outside the confidence zone of the corporate premise. The amount of sensitive or secret data that is being recorded to removable media and shipped offsite on a daily, weekly or monthly basis is staggering, and commonsense dictates that it should all be protected against unauthorized disclosure.
Encryption, despite the emphasis it places on restore timeframes (getting your data back following a disaster), seems like the order of the day. Many readers of this column are looking for a solution.
Appliance-based encryption techniques make some sense when there is an existing infrastructure and you just want to drop a solution in front of your tape library. You need to balance not only the operational ramifications of such a solution (encrypt speeds and backup windows/decrypt speeds and restoral timeframes), but also other factors such as heat generation. Many encryption appliances are essentially software loaded on over-clocked PCs and they produce more heat than just about any other product in your rack. So users need to consider the need for spot coolers or an overall increase in HVAC services before deploying many of these products.
I used the word s "many products" because going the appliance route usually entails deployment of encryption systems that don’t have a lot of ports. Consider what data needs to be encrypted, where it is coming from (in terms of storage arrays), where it is flowing (in terms of tape devices), and how many ports you need to handle the load and its architectural flow paths. It isn’t rocket science, but it isn’t a walk in the park either.
Once homework is done, other factors must be considered. If data is to be restored at an alternate site in response to a disaster or some other interruption, think about what is required to do the restore. Is there a wait for the next appliance off the line to arrive at the recovery site before data restoration can begin? Is there a software alternative? What about decrypt keys? Are they hardware based or is there a copy of the key in software that can be used to get at encrypted tape data needed?
Frankly, I am not wild about security appliances. I am even less enthusiastic about them when non-issues and half-truths are raised by one vendor in an effort to clobber another vendor in the press. Why doesn’t the industry compare different approaches, developing a matrix to show the real capabilities of products, their performance characteristics, and modes of operation? While we are at it, let’s compare the merits of software-based schemes and on-library schemes for data encryption versus appliances.
I’d be happy to help. To their credit, both Nelson and Brown have indicated an interest in participating in such an effort. I will follow up with both of them.
Developing a strategy for securing data is daunting enough without deceptive press releases and conveniently edited CERT reports. How about everyone agreeing to make 2007 about illumination, not prevarication? Your opinion is welcome: jtoigo@toigopartners.com.