They only way companies can change the way the organization builds software is leadership from the CEO.
Step 2 of 2:
senior architect of security researchIBM
We hear so much about the need for companies to focus on secure software development. Why should software security be a priority?
Ryan Berg: About 12 years ago, I worked at a company called BBN and at the time one of the things we introduced at BBN was the first managed firewall services. So back 12 years ago, one of the greatest threats to an organization was access to the network. That's what everyone was concerned about. Firewalls came around and you needed an advanced degree just to configure a firewall. But one of the biggest requests that came in to our network operation center was: "Can you open this port for me?" As more and more application services came onto the network, they tried to open the firewall more and more to make them work. At the time the applications and Web applications were pretty bad. The threat landscape at the time was Web defacement. Then the Web started to evolve and about five years ago we saw more and more dynamic content pushed onto the Web and more actual business functions happening. The firewall still provides a baseline of security, but you allow port 80 and you allow a freeway of activity into your network. What used to be a closed off sense of what was internal and what was external is now evaporated. It appears that most organizations, once they're doing business on the Internet, allowing traffic in and out of their network on port 80, they've essentially allowed an open door for access into your infrastructure.
A lot of applications have become Web-based and it seems like attackers are no longer going after vulnerabilities in operating systems, they're going after browser flaws and other Web-facing application flaws, aren't they?
Berg: As the operating system vendors have done a good job closing the doors on the operating system, what people are realizing is that the attackers are really after the data. There is an economy for the data that you have. The business analytics folks want access to that data because that's what drives their business and the hackers want that data because that's what drives their business. The way to get access to that data is no longer going through the network and breaching an operating system. Hackers are looking to see if the application itself has access to that data and then they are trying to subvert that application directly. They're trying to make a legitimate request for the data in a nefarious way. That's why we see attacks like SQL injection and cross-site scripting (XSS) being such a prevalent style of attack. They're just ways that an attacker can subvert the normal functionality of the application. It may have some software defects, poor design or poor coding quality in it.
Where does a company begin if it's going to make software security a priority and what person within the organization should lead that effort?
Berg: I think it starts with the CEO. You have to transform the way in which you think about building software. They only way companies can change the way the organization builds software is leadership from the CEO. I've talked to a lot of organizations and it's not that developers don't want to do the right thing. They don't want to write bad code. But the developer isn't being told that this is an essential function in the way in which we do business. The software needs to be delivered to include security. In order for that to be a standard that the developers can uphold themselves, it has to come all the way down from the top of the organization. I've never talked to an organization that doesn't care about the quality of their software. If you care about the quality of the software then you have to care about the security of it, because you can't have quality software that's insecure. Organizations spend a lot on quality. There are QA engineers that are on staff and there to test the product. But in order to test for security, you need people there. They're not likely to be the same quality engineers because it's a different skill set. There needs to be an enterprise commitment and an enterprise spend on that function.
Once that commitment is made there are a number of different models out there that can be used as a guide. There's the Building Security in Maturity Model (BSIMM) that's helpful. Microsoft makes its SDL widely available. What is your take on these different models? Is that a good place to begin?
Berg: The one thing I like about BSIMM is that it really isn't a model. BSIMM outlines what a number of organizations are doing. You get some statistical relevance of what the top organizations are doing in common. BSIMM doesn't tell you whether you should or should not be doing something. It just tells you what these top software organizations are doing. The Microsoft SDL is built around what works for Microsoft. They have a certain kind of applications they develop. The original SDL is mostly focused on their operating system: shrink wrapped, off-the-shelf software. If you don't develop that kind of software, maybe that model doesn't necessarily fit for you. But that doesn't mean you can't use that model, or pieces of that model. The bigger thing to take away is that you should have a model. If you don't' have that, you're chasing your own tail.
From what you're seeing out there, do most organizations have the general foundation in place? Are enterprises at least aware of it right now and beginning to build out better software development processes?
Berg: It depends on the market. We see certain verticals like the financial market, which has risk all over it. So they are on the leading edge of really taking secure application development seriously. They have risk managers. They have security engineers and a security program. All of these pieces are more often in place in most financial organizations. That does differ in other parts of the world. In the U.S., financial firms are ahead of some financial organizations in other parts of the world. Part of that is driven by regulation. Certainly, PCI has been a driver and forcing function for the financial services. Next behind financial services, you see retail. PCI and the financial services put that downward pressure on retail. Once you get to the individual independent software vendor (ISV), they're really left dragging their feet. Until the hammer drops, they don't see the economic benefit. You see the larger ISV organizations making it a priority, but once you get past the Fortune 1000, your mileage may vary. They are really not doing a lot unless they're on the front page of the New York Times.
Are some of these changes going to be driven by customer requirements or will there be a regulatory need to improve software security among smaller ISVs?
Berg: I hate to see it come to more regulation. We all know that regulations don't always get it right and you can cause people to get into that checkbox mentality, doing the minimal amount of work to satisfy a requirement. I would like to see more pull from organizations that are consuming software to begin to ask questions of people who are providing that software. We're seeing it more and more. I think you see large organizations with big buying power have more control and say in the security of their software. When you have the buying power like a Fortune 500 or Fortune 1000 company then you have the ability to sway and make these things requirements and part of the way you acquire the software.