Eddie Schwartz on His Year as RSA's CISO

Shift In Thinking that Infosec Is Purely a Security Problem

CISOs shouldn't be tied too closely to specific guidance and processes when new threats emerge or their organization has suffered a breach, says RSA CISO Eddie Schwartz.

Schwartz, whose employer RSA experienced an advanced-persistent-threat attack in 2011, says chief information security officers need to constantly adjust where to spend time and money on a security program.

"If you're just trying to match up your security program to ISO-27001 and that's your sole objective, it's not going to get you where you need to go necessarily relative to facing advanced adversaries," Schwartz says in an interview with Information Security Media Group's Eric Chabrow [transcript below].

If an organization, for example, places a large percentage of its budget toward low confidence-level pre-breach technologies, or the technologies it invested in had no value post-breach, it's time to address that imbalance. "You need to raise the confidence level relative to pre-breach, which would mean looking at it [through] next generation, pre-breach technologies," he says.

Schwartz emphasizes that standards like ISO-27001 - specifications for information security management systems - shouldn't be ignored. "It's great for helping you establish a benchmark for pre-breach tooling," he says. But the organization's security program constantly needs to be evaluated and examined by everyone in the organization in order to make adjustments that lead to benefits and cost savings over time.

In the interview, Schwartz:

  • Raises what he characterizes as fair questions CISOs should ask themselves in assessing how to spend money their organizations earmark for IT security;
  • Cautions his fellow CISOs not to be tied too closely to specific guidance and processes developed at a time when different types of threats dominated;
  • Discusses media hype in reporting cyber incidents and the impact that has on how organizations approach IT security.

In part one of the interview [see CISO Success Requires Collaboration], Schwartz talks about the importance for CISOs to spend more time together discussing their common IT security challenges.

From 2007 to mid-2011, Schwartz served as chief security officer at NetWitness, like RSA, an EMC-owned network security provider of real-time network forensics and automated threat analysis. Before joining NetWitness, Schwartz served as chief technology officer of ManTech Security Technologies, senior vice president of operations of Guardent and executive vice president of operations for Predictive Systems. Besides being CISO at Nationwide Insurance, Schwartz worked as a senior computer scientist for CSC and a Foreign Service officer with the U.S. State Department.

ERIC CHABROW: As we resumed our conversation, I asked if significant changes occurred in RSA's IT security organization.

EDDIE SCHWARTZ: I think some of the things that may be of interest to some of your listeners would be, for example, ways that we've been thinking about how to make security more effective overall. Talking to my peers, thinking about how we do things, some security officers - including myself - used to have a view of the world of, "If I can just get a grip on all of this myself," for example issues that are security hygiene-related such as patch management, asset management, vulnerability management, some of these core things that you really need to do well. As you step back from that, you say, "Are we as security people really the best people to be doing this anyway?" The reality is that if you look across IT, they're very good at so many things and they're much better at it in a lot of cases than security people are. They're better at managing to SLAs. They're better at managing to quality standards in a lot of cases, and so it's to build partnerships.

I built a fantastic partnership with RSA's CIO, where the CIO and other people within the IT organization help to drive for results and drive to excellence around some of the metrics that are critical to doing a good job with security. For example, we shifted the approach a little bit away from thinking about something that's purely a security problem and thinking about it as a shared space that we all have, where we all share in the goals, we all share in the success or failure and frankly we're all rewarded for good outcome if we do a good job. That's important. The expression is that people do what they get paid to do. We all have to be incentivized to have the right activity and I think the tone from the top has been very good here on that, and it has pervaded itself throughout the organization.

CHABROW: Any reluctance from anyone in the organization to accept more responsibility for IT security if that's not their core job?

SCHWARTZ: No. Like any place where you work, I think people always will look at the net of their job and say, "Did I plan for this? How do I figure this out?" I think in today's world - and this is not just true at RSA, it's certainly true anywhere that you look around - people are saying, "How do I accomplish all of the things I'm asked to do today?" Because certainly while everyone realizes that there needs to be a greater focus on security and there needs to be a high emphasis on this, you still have to work within the constraints of resources and planning and budgets.

Our challenge as security professionals is to continue to figure out ways to do these things so that they also align well with the objectives on the business side. In the past, security people somewhat had the luxury of just saying, "Let's slap a cost tax on something. Let's slap an expense line on something, and because it's security related, we will get the money." I think many of us are also thinking in terms of how we can build good hygiene, good security practices into things that IT is already doing, into things that application developers are doing on the business side. It really is driving security away from a compliance mentality, away from a technology mentality, towards a business-focused mentality where business feels that this is really a cost of doing business. I need to find a way to embed it in that cost. Hopefully in the end, if it's done right, it will be close to some gain for them.

CHABROW: It sounds as if you can't really segment or silo organizations, whether it's IT security, IT or even the business units. They all have responsibilities when it comes to security.

SCHWARTZ: And it's not really a mistake. It's more like an evolution. In the past, security professionals have tried to create these monolithic security organizations and do everything themselves. When some new information technology comes up, they go, "Oh my gosh. Do we have anybody who knows anything about technology x, y and z? Of course we don't." But the reality is that the people who truly understand this are the folks in either IT or in the business that owns this very technology that's being proposed. Why would we pull that out of the business and give it to security to deal with as opposed to creating good security champions, good security processes and a doctrine around how to build a secure environment, whether it's at the application layer or at the infrastructure layer? Through that process of threat modeling and building a software development lifecycle that builds security into these environments, they get the right outcome.

Then what we do is we help measure that outcome. We monitor and we measure that outcome and we make sure that it's done in a repeatable and mature fashion. Security has evolved that way and the business in this way also owns its own resource. They're not paying a tax. They're not throwing money down a rat hole and saying, "Why did I give you all this money and what am I getting for it?"

CHABROW: When you became a chief information security officer, there wasn't a big bureaucracy built around you. You basically came in there, looked at what was there and tried to organize IT security at RSA using existing organizations.

SCHWARTZ: Certainly. As part of the division of EMC, EMC had a fantastic global security organization that's run by Dave Martin, and Dave had already been running for a while this organization with certain constructs around it. I have a dual and reporting relationship; part of my reporting is to Dave. One of the things I didn't want to do is reinvent the wheel completely in terms of RSA as a division. I wanted to take the best thing that Dave's organization had to offer in terms of services that were pertinent to what I was doing at RSA, but then there's uniqueness to our division as a security division. There were things that we needed to do that sort of fell outside of that. Also at EMC, because we build software and hardware and we manufacture things, we also have a product security office that's run by a fellow named Eric Baize and it's a very, very mature operation. Between these two operations and then what I do, those are three legs of a stool where essentially we use each other's processes, we build upon each other's processes and where one of us is ahead of the game, we'll test something out. If the other two can benefit from what one of the others is doing, so be it, and it's been a great relationship that way because it has allowed us to move quickly on some initiative that might have been back-burners for one or the other of us.

CHABROW: There's been a lot more general media attention on vulnerabilities and attacks on organizations. Do you think some of that's misdirected, that they're focusing too much on one type of activity where there are more serious things going on? And if so, what's getting too much attention?

SCHWARTZ: There's certainly hype cycles that happen. If you look at the last couple of years and certainly since our breach, there has been a hype cycle around APT. If you have been to security conferences over the last year and a half to two years, it seems like you go up to every vendor booth and you'll either see APT or cloud security hanging on the booth, and if a vendor is really good they will do APT detection in the cloud. What will happen is a lot of people's fears and a lot of public discussion of issues, whether informed or not, tend to drive the agenda a little bit. A lot of that unfortunately is not a hundred percent accurate.

Having said that, I do think that there's room for discussion around certain types of topics. For example, there's room for discussion around what I call the idea of, "What's the right tooling relative to this space?" And tooling could be technology-related; it could be people-related; it could be process-related. If you believe the idea that you're going to be breached at some point, a breach is a seminal event that may or may not have implications to it. In other words, you could have a breach but the breach may not result in any damage if you're put on the other side of the breach.

Prior to a breach, we always talk about the notion of preventative technologies, preventative processes, and people that are involved with everything associated with prevention; and that would even include all of the stuff associated with good security hygiene, governance and things of that sort. There's an investment you're going to make and there's a confidence level you're going to have around pre-breach tooling. Most security investments fall into that space today. I'm not saying that's a bad thing. The question though is what should that investment level be and what should everybody be doing around that, and what should the focus be in today's world of advanced threats where that's our focus in a lot of cases - advanced threats and adversaries relative to material assets versus the gullible approach which says let's secure everything.

But then the other side too is, assuming that we're going to be breached at some point and we don't want the breach to be material. We don't want the breach to have a bad result to it. What does the post-breach tooling look like? In other words, what kinds of people should we have working for us? What should they be doing in that context? What technologies are effective in that post-breach context and what processes might I need to change? For example, do I need people doing threat intelligence? Do I need people doing malware analysis? And if I can't find those people or can't afford them, is there a service provider or is there some other way I can get access to those capabilities? These are all things to think about.

Then, step back from what you're doing and say, "Maybe I'm doing things the way I thought was valuable in 2002." Even though I've talked with CISOs for a long time, the last time I was a CISO was around that time. So I've done all kinds of work in security since then, but if I came into this job thinking the way I thought then I would be worthless. If your playbook as a CISO has not changed in the last seven years, just for the sake of argument, you're in deep trouble. I think it's really important for organizations to step back from things like the hype and some of the things like ATP or whatever the focus is from the vendor community and say, "Okay, but what does security management really mean to me now? What does the business care about? Is it about the material assets above all else? Who's coming after those material assets and what's my preparation level? Is my security program tooled properly to handle that?" That's a fair question for any of us right now.

CHABROW: Now let me make sure I understand the point that you're making. People are going to be breached. Therefore, I've got to look at my investments at what I need to do once that occurs.

SCHWARTZ: What I'm saying, just for the sake of argument, is this. Suppose you looked across all of your investments and you said, "I have $4 million to spend on security today relative to technology." And then you looked across your cost and you said, "I've got technology refresh to do. I've got operation and maintenance cost to deal with relative to certain technologies." And you realize that the line share of these costs, 80-90 percent, was going towards technologies that had a low confidence level relative to either pre-breach approaches or had no value relative to post-breach. That would mean that there's an imbalance they need to address, because you need, first of all, to raise the confidence level relative to pre-breach, which would mean looking at it next generation pre-breach technologies.

Some of those old school firewalls and AVs wouldn't fit into those categories so you need to drive the cost out of that stuff, and then again post-breach technologies, where are you on that? There's the whole framework that many leading organizations have put in place today that needs close examination by just about everybody. Where are you on that?

Then, it's not just technology. You can have a lot of technology in the world and you're not going to get anywhere so the issue is then stepping back. Say you've got a data center for technology but you're disorganized and you don't have people that understand any of this. There are service providers that can provide you the right the services. Or you're living on an island and you're just looking at your own data versus collaborating with others or having providers that bring in data that enriches your organization's data.

These are all questions that people need to ask themselves. Where am I on this continuum? Some of it goes against traditional approaches. If you're just trying to match up your security program to ISO-27001 and that's your sole objective, or you follow some methodology that's ten years old, it's not going to get you where you need to go necessarily relative to facing up to advanced adversaries. Now I'm not saying that you drop ISO-27001 or you drop your firewall, but what I'm saying is that ISO-27001 is great for helping you establish a benchmark for pre-breach tooling, but it shouldn't be the sole factor in determining what to spend your time and money on in your security program.




Around the Network

Our website uses cookies. Cookies enable us to provide the best experience possible and help us understand how visitors use our website. By browsing inforisktoday.eu, you agree to our use of cookies.