Software Security: The Big Picture. Part 1
Brian Chess, Chief Scientist at Fortify Software
Hi there! My name is Brian Chess. I’m Chief Scientist at Fortify Software. We were acquired by HP at the end of last year, and we’re excited to join the HP family.
Today I’m talking about software security in the big picture. I tell you this is a real departure for me; I kind of came at computer security backwards. I started in grad school in 1995 or so, talking about how you could find security vulnerabilities by looking at the code that developers write, and you could get rid of security problems way before people actually ran into them in deployed scenarios. The academics were very encouraging to me, and it took me 7 short years to finish a Ph.D. on that topic.
And I should have known it was a trap that they were way too happy about the stuff that I was doing, because about a year after I finished grad school I stated this company, Fortify, in order to try and bring some of that stuff I had been working on into the real world. And what I found when I got into the real world was a lot of people were saying: “You want me to what? Wait…Fix the code? You don’t understand!” Eventually, what I came to understand was I was trying to sell them a smoke alarm when their house was on fire, and they were a little distracted by all the problems that were in front of them right this second; and talking about going back and fixing things pre-production was just not the first concern.
But I’m persistent and I stuck with it. And I think it paid off. I think we’ve gotten to a point in 2011 where people are much more accepting of the idea that security has to be built into the software we deploy. So, of course that means it’s time for me to move on.
We pay a lot to try and protect software in production, and generally results aren’t too good.
What I’m talking about today is what happens when we take code out of the developers’ hands, put in the data center and start to watch it run. Everyone accepts now that we’ve got to try and build security in, but of course we can’t ever be perfect at it. So we at Fortify started looking at what’s going to happen when you start to get some data in that code. When you look at the code statically you don’t have any data. When you’ve got data you can start to find vulnerabilities related to that data, you can start to block attacks in production; and that was my introduction to, I think, where a lot of people start with software security, and that is in the production environment. So, this is a little bit about what I’ve learned over last year or two when it comes to protecting code in production.
First half of this presentation is a complaint. The complaint starts like this: I think we pay a lot to try and protect software in production, and generally results aren’t too good. If you’ve ever been to the RSA show floor, there’re 400 or so odd vendors out there, almost all of them willing to sell you a “solution”. And the interesting thing about the “solutions” is they are very much focused on components. We know that attackers don’t go after components; they are interested in the weakest link – anything they need to do in order to get into a system. If you first go on to the RSA show floor you might think it looks like Disneyland; but after you’ve been there for a little while it starts to look a little bit more like Home Depot, because we’re asking people to assemble their own solutions from all of these little components that they put together.
So, who’s responsible for making sure that it all comes together and that the parts sum up to be a good whole? Gosh, we still put that on the customers’ back. That means integrating multiple sources of events and data and prioritizing what’s important, because every vendor out there will tell you: “We’re the ones who found the critical vulnerability; you need to take our results into account and they need to be top of the heap.”
The CISO’s Dilemma
Now I want you to think about this problem from the CISO’s perspective, and when I say CISO I don’t mean that literally, you could think of it as a figurative term for anyone who’s trying to think about the big picture, somebody who’s trying to think about end-to-end security in the data center.
Constituents of software security assurance
Clearly, you need to be concerned about what you’re putting into that data center; you need to make sure that security is part of what you’re deploying. Then you need to think about what you do once you deploy that software – you need to be secure when the software is being operated. That means best practices when it comes to configuration. It means monitoring and making sure you’re keeping up with the latest risks and threats. And if that’s not enough of a challenge, you need to do this for the maximum possible risk reduction at the minimum possible cost. The CISO is responsible for that full spectrum of balancing that equation.
They go to their team and they say: “Hey team, how are we doing? Is this gonna work out? Reassure me.” The team may be newly back from the RSA show floor, comes back talking about the firewall, and they talk about monitoring the database, and they talk about the penetration testing of the network and the penetration testing of the application, and the web app firewall that we need to deploy, and the data loss prevention solution; and the list goes on and on and on. And that CISO has to wonder – what does all of this add up to? Well, I guess I’m some sort of revealing here, but what I think it adds up to… hmm, incoherent mess; that’s tough talk, let’s see if I can back it up.
Also Read:
Posted in: News
Leave a Comment (0) ↓