This post was triggered by yet another innocuous EMC press release, this one announcing that many of our platform products have been certified under the Common Criteria Information Technology Security Evaluation.
Don't know about the Common Criteria? Wikipedia has a decent write-up on the basics, but only goes so far.
No, this is not just a federal government thing -- it's got wider applicability than you might think.
And, once again, the real story is what goes on behind the scenes ...
Secure Products vs. Security Products
One of EMC's core beliefs is that -- ultimately -- people will want security features embedded in just about everything they buy. Sure, there'll be a market for specialized security products -- but the broader need will be for products that are designed to be secure, tested to be secure, deployed securely, managed securely and supported securely.
Common Criteria certification address a part (and only a part!) of this overall requirement, e.g. third-party testing of a subset of product security.
But making products secure -- really secure -- required an out-of-the-box approach that I don't think is done too often in our industry.
See what you think.
Designed In, Not Bolted On
Several years back, EMC started taking product security very, very seriously. The story hasn't gotten out as much as I'd like, but it's there to be told -- and we're learning (slowly) to tell it.
We started by funding and forming the EMC Product Security Office -- a centralized function to make sure that we looked at every product -- and every process -- in pursuit of product security. Eric Baize (a great guy, BTW) has been leading this function for quite a while now, and has not only built up his own team considerably, but has secured the participation and engagement of just about every group at EMC.
We established our own EMC Product Security Profile (PSP) that goes significantly beyond things like Common Critera, version 2 of which now lists over 80 stringent security requirements that EMC products must meet to be designated "EMC secure". Version 1 had been out for a while, and -- when we saw that most of our products were going to be compliant -- of course, it was time to ratchet things up to Version 2!
Requirements are a good start, but integrating secure practices into development are even better. As a result, the team defined the EMC Security Development Lifecycle (SDL) which integrates security thinking into every aspect of a product: from conception to end-of-life. We augmented this investment by joining SAFECode as a founding member to share best practices with others in the industry.
We also realized that security had to be done consistently across multiple product stacks, so -- as a result -- a core team developed the EMC Common Security Platform, which speaks to stronger authentication protocols, common log formats and standardized key management across the EMC domain. As a result, many of our groups are adopting this common "security backbone" for current and future products.
Secure Deployment, Secure Support
It doesn't matter how well you design and test the security features in your product. They have to be deployed securely using recommended practices, and -- ultimately supported securely.
We've gotten a pretty good start in our Global Services organization by adding security considerations to all the standard architecture-and-design work we already do. So, for example, as we design a SAN, or a backup environmnent, or an archiving environment, we're routinely building and implementing it using secure practices.
The initial temptation was to offer these consulting engagements as a separate service; but -- at the end of the day -- why would you keep it separate? Security has to be designed in, not added on ...
"Secure support" means a couple of related things. As an initial example, we started offering secure support credentials for when EMC support personnel have to work on customer equipment, either locally or remotely. Credentials are individually issued for specific types of work in specific timeframes; everything is logged and audited on separate devices.
Another example is a fast response capability (the EMC Product Security Response Center) when the inevitable vuln is discovered, or if you're just curious as to what's going on.
And, Of Course, It Never Hurts To Check ...
And, very recently, we've started being invited into customer environments to have a look around; not only as to how they've deployed various security features, but are the required processes in place to keep things secure?
This sort of periodic "check up" makes sense for all sorts of things: security, high availability, backup and recovery, and so on. Never hurts to have another set of experienced eyes look things over.
Nobody Is Perfect
I don't think there's a absolutely secure product that can be guaranteed to be securely deployed and managed. Perfection isn't only unobtainable, it's unrealistic and probably not cost-effective.
But, on the other hand, infrastructure vendors have to take overall environmental security very, very seriously. And, if you're a vendor of a point solution, you need to make sure you're fitting into broader security frameworks that the larger vendors are establishing.
EMC's focus on product security isn't surprising when you think about it. Tens of thousands of organizations around the world trust us with their most precious asset -- their information.
Going forward? I think product security -- not the spec, but the processes around it -- will be an important differentiator in an increasingly competitive marketplace.
And I think certain astute customer will expect more than hand-waving in answer to the question "are your products really secure?"
Comments