address some of these security concerns. The report offers some specific guidance about not just the protections required, but how to afford them.
X: Okay, let’s run through the recommendations. [For clarity, the council’s recommendations are in bold type below.—Editor]
AC: The very first recommendation is to rein in the things that you are doing [as a security officer]. Chances are that you are protecting things that don’t need protecting, and you aren’t focusing on the things that pose the most risk. The second recommendation follows on that—it says make sure the services you get are competitive. Either outsource them, or if your outsource provider isn’t working effectively, change your provider. The third element is, don’t say no [when workers propose adopting new technologies]—say yes, but here’s how. Information security guys are no there to be the Dr. No’s of the company. They are the ones who should be involved up front, so that you’re doing it right.
Item four speaks to cloud computing. It’s that you should shift from protecting the container to protecting the data. If you are outsourcing your infrastructure to the cloud, then you don’t own the containers anymore. How am I authenticating people who access my cloud environment? How does the cloud provider ensure that my data doesn’t get commingled with somebody else’s? In the event of a breach, is the data encrypted? How is data leakage prevented? How can the provider prove that the environment is working in accordance with my policies? These are all things for which products and technologies are available, and some of these do come from RSA, which positions us as particularly strategic to the rest of EMC. With VMware [a virtualization company in which EMC has controlling interest], and with so much of the data center relying on EMC storage, we are right at the forefront of the cloud computing phenomenon.
The fifth recommendation follows on that—it’s to protect the data itself with advanced monitoring techniques. We have shifted from static technologies that say “yes or no” to technologies that say “bend but don’t break.” These technologies are behavior-based; they look for anomalies. They are far more cost-effective and less intrusive and easier to deploy, and that’s the way security is trending generally.
The last two elements are things that the technology community should take to heart, and also each vertical industry. It’s clear that no one vendor can do it all—but it’s also clear that there are so many point products that fraudsters can just figure out how to navigate around each of them. There needs to be a technological ecosystem to counter the fraud ecosystem—which means the vendors need to figure out ways to get their products and technologies to work together. I hate standards bodies—they move too slowly, and they tend to work toward the least common denominator. But there are ways to move more quickly, by reaching out to partners. We have reached out to Microsoft and Cisco to create de facto standards that we then open up to other people to get on board.
[The last element is that] it’s also in the interest of [companies within specific industries] to tell each other how they’re getting attacked and exploited. They make each other smarter. It’s almost like a neighborhood watch. If JP Morgan Chase gets hit by a phishing attack, we know that within a day or a week that that attack is going to hit Citigroup and eventually Barclays and Bank of China.
X: This is the fourth report issued by the Security for Business Innovation Council in the last 14 months. How have the group’s recommendations changed over that time?
AC: It’s a continuum. If you looked at all four reports you’d find a level of consistency. The first one was about how to make the security guys more relevant inside their companies—how to know the business so you can add value, know what projects are in the offing so you can get in ahead of the game. The second one was about the risk-reward equation—so much of security is based on what is level of risk you’re willing to take. There are some approaches you can take to mastering that equation. The third one was in the heat of the economic meltdown, so it was all about being more cost effective.
X: Who reads these reports, and what kind of feedback to you get about them?
AC: We’ve gotten tremendous feedback. We get a lot of hits from security people. Journalists have eaten them up pretty well, too. We feel like we’re educating a large group, by calling on some of the best minds that are out there. It’s just another way we provide leadership in the marketplace.
X: Changing the subject—I wanted to ask you for your perspective on this emerging area called “governance, risk, and compliance,” or GRC. There are quite a few companies around Boston now that call themselves GRC software providers. Why do you think this is happening here, and do you see GRC as an important market for RSA and EMC?
AC: I’ll quote one of our own technical guys who is trying to get his arms around a definition of GRC. He said, “You could stick a ham sandwich under the umbrella of GRC.” It’s a big, amorphous term that could mean anything to anyone. Even within EMC, you’ve got our resource management group saying, “We are the GRC of EMC,” and you’ve got the content management and archiving group saying, “No, we’re the GRC of EMC.” Fortunately, cooler heads have prevailed, and we have a unifying story that we are actually taking to market in the next quarter.
But you’ve got a real challenge there. Is GRC about information risk? Is it about operational risk? Is it about business risk? Should you be doing all three together? How does one interconnect to the other? My view of it is that it’s too