| QUESTION & ANSWER |
Build accountability for security into the development process |
 |
By Colleen Frye, News Writer
12 Jan 2006 | SearchAppSecurity.com |
|
|
Top security expert Howard Schmidt's has viewed IT security from nearly every angle. He was once vice president and chief security strategist at eBay as well as chief security officer at Microsoft, where he co-founded Microsoft's Trustworthy Computer Security Strategies Group. He has also served the current Bush administration, heading up cybersecurity initiatives. Schmidt, currently president and chief executive of R&H Security Consulting LLC in Issaquah, Wash., talked with SearchAppSecurity.com recently about holding software developers and the development process accountable for application security.You recently said individual application developers need to be held personally accountable for security. What are some specific ways developers can be and should be held accountable?
Howard Schmidt: Let me clarify that. A lot of people are [saying] I said we should hold developers accountable as opposed to holding the development process accountable. And there's a distinction.
When I talk about accountability, it's the development process. Most people, when we work for an organization, go through a semi-annual or annual review process. We set goals; we set what our requirements are going to be for the period. We generally have a manager who measures us on that, and we get pay raises, bonuses, stock options based on the goals we set forth.
Now here's where the individual piece comes in. When a developer establishes their annual or semi-annual goals and requirements, part of that should be not only writing faster, cooler, and tighter, but also more secure. And that should be something by which people should be measured against as part of the accountability and responsibility of the development process. We're starting to see that take place in some companies now [as] part of the software development life cycle.
But in the broader sense, there's basically three things we need to do. One, make sure that we put requirements on their development work which take into account the time it would take to build security in, as opposed to this tremendous pressure to roll stuff out whether it's good or not. The second is they need to have the training. And third, which gets into the way to solve the problem now, is give them the tools that are automated.
|  | | Security expert Howard Schmidt
| |
How should companies or corporate development organizations be held accountable?
Schmidt: First and foremost, it's got to come from the executive ranks, [who] say, 'Yeah, we do have issues around being first to market, but we also need to make sure that this is done in a secure manner.' So the culture of security has got to come from the top down, whether it's on the consumer side or the enterprise side.
The second thing they need to do is to make sure the tools are available. This way you can shorten the entire process by making sure the tools and training are there. You shorten the time that it's in testing mode, [and] you shorten the time it's in QA mode because a lot of the things are built into it from the outset, which actually saves you money.
I think that's what a lot of us are moving toward now, to make sure the tools are there. As you start to put the tools to check for security conditions, as well as the normal compiling stuff, in the development kits, you can reduce the separation of security from development.You shouldn't have to be a security specialist in development; you should be a developer who also has security built into your tools.
You've said that security requires the same attention any business goal needs. How can companies be convinced that security is a business goal?
Schmidt: You see situations with Oracle and Sun and Microsoft, and government contracts, and large procurers of software, who said effectively, 'We want better quality, we want better engineering,' and demanding that be part of it. So I think the market forces are driving it, as well as many companies recognize that people just aren't going to buy the stuff if they don't start doing a better job. So the message is very clear, and from what I've seen, particularly the major software houses like Microsoft, Cisco, HP, that's part of their mantra -- not only are they going to make really great products, but they're going to make very secure products as well.
|
|
|
|
|
You shouldn't have to be a security specialist in development; you should be a developer who also has security built into your tools.
Howard Schmidt
President and CEO, R&H Security Consulting
|
|
|
|
|
|
|
|
|
|
Many developers don't have the skills needed to write secure code. Are software vendors addressing this or do they need to do training?
Schmidt: It goes across the board. Some of the large software houses actually do that. When we rolled out Trustworthy Computing, Microsoft shut down development for six weeks, and we did training for the developers that were there at the time. In many cases the books that have been written by Gary MacGraw, David LeBlanc and Michael Howard have been given out. When you get hired for the job you get a copy of a book that tells you how to write secure code. So to that level I think we're making good progress, and I would venture the next generations we see at Oracle, Microsoft, Cisco, IBM, HP, we'll find less bugs in them than we ever have in the past.
The other part I worry about, though, is the stuff that's developed in-house, whether it's a Web-type application or whether it's internal development -- the customized line of business applications that lay on top of some of these things. That's where I think we also need to focus some of our energies, because I think everybody focuses on the big software houses but you've got to remember some of these things are developed in-house. What we've seen happen lately, as the big software houses get better at security, the bad guys start focusing on other applications out there.
How do we get corporate developers to write more secure code?
Schmidt: There has to be that message that this is important, that the culture of secure development is that you just don't run something out of skunkworks and put it into mission-critical applications. That's got to be a mindset change, which is slow coming.
Should corporations adopt their own security development lifecycles, like Microsoft's SDL?
Schmidt: Absolutely. The minute somebody starts sitting down and developing code [you've] got to look at the security features that are part of it when you're developing it, and then you've got to move through that entire life cycle of making sure that it's coded securely, tested securely, quality controlled securely. And then have a gating mechanism in there: If it doesn't meet the security criteria it goes back to get fixed before it goes out.
Are corporations moving in that direction?
Schmidt: It really varies. For some of the big e-commerce sites that do a lot of their own development [and] have a lot of Internet-facing Web properties, they're pretty sensitive to that and they do a pretty good a job. You've got other companies that basically say, 'We're behind the firewall, so we don't need to worry about it,' then they find out there's a vulnerability that gets exploited, and next, somebody's in their network. So it's a slow process for some of those companies that don't think they've got such a great Web presence.
Application security testing has typically been under the purview of security specialists outside the development organization. Will shifting this responsibility to the developer require organizational changes?
Schmidt: It's hard to say what the long-term result will be. I think initially it will continue to be the same structure. You'll have the development teams, and you'll do code checking in and checking out. You'll have code testers, because you still have to test the functionality even though security is being automated out, then you have quality assurance, so you'll still see that fundamentally take place. What it will look like in the future, you could be in a position where there's less work for the quality assurance people because things are being automated, which means one, it will be cheaper, and two, you're going to be able to get code out faster. And that in turn might result in a change in the future, but I don't see a change in the short term.
|
|
|
|
