Build software security at the start

It's becoming a common refrain: If software were just written with security in mind, agencies wouldn't have to spend time and money bolting on security features later. These days, industry is trying more to help.John Viega co-founded Secure Software Inc. of McLean, Va., in 2001 and now is chief technology officer. The company last year began releasing its CodeAssure suite to automate the software vulnerability remediation process, and Viega released the Comprehensive Lightweight Application Security Process in April. CLASP, available as a free download at www.securesoftware.com, is a set of practices that formalizes and moves security concerns into the early stages of software development. Viega has written three books on the software security: Building Secure Software (2001), Network Security with OpenSSL (2002) and Secure Programming Cookbook for C and C++ (2003).Viega has worked at Cigital Inc. of Dulles, Va., and was adjunct professor of computer science at Virginia Polytechnic Institute at Blacksburg. He holds B.A. and M.S. degrees in computer science from the University of Virginia.GCN senior writer William Jackson spoke with Viega recently about software security.VIEGA: There are a tremendous number of things that can go wrong; way too many for a developer to keep track of. The average developer has features that they are responsible for. They really can't and shouldn't be thinking about security every step of the way.Security problems can be introduced in every phase of the lifecycle and they often are outside-the-box type problems, and developers don't have time to spend a lot of time thinking outside the box.VIEGA: In terms of building reliable software the answer is yes, it has improved dramatically over the last 30-plus years. You have development methodologies that seem to be reasonably effective, such as Agile Software Development and Rational Unified Process. These are major improvements on the methodologies we were using 10 years ago. Building a totally bug-free system at the end of the day is more difficult than building a system with no security bugs.VIEGA: CLASP is a set of process pieces that can be integrated into any development lifecycle'any software engineering process. The basic idea is that we define a set of activities that have been proven to improve security and allow development organizations to integrate those activities as they see fit. We provide resources to help them do that with minimal effort, such as worksheets and coding guidelines. We also have a 150-page knowledge repository of things that can go wrong that makes for a good reference guide, so the average developer doesn't have to know what a particular problem is. But when that kind of problem becomes a concern, they have a reference they can go to.VIEGA: There are some things that are best practices, but they are not commonly followed. For instance, there are several activities related to security analysis. You can perform security analysis at an architectural level, you can perform it by doing a code review at the implementation level, and you can do it through your testing and quality assurance program. Very little of that happens, and often it is very ad hoc. So this is an attempt to unify the best practices of everybody.There are other things where there were no processes prior to this. For example, CLASP has a methodology for deriving security requirements, which is as repeatable and as thorough as you could expect a requirements analysis to be. Before that, security requirements were whatever the customer happens to pass on, totally devoid of structure.VIEGA: Lightweight means it is low-cost to adopt. We define 24 activities that development organizations can use. But they are as nonintrusive as possible, and there is no expectation that anybody is going to implement all 24. The way we recommend organizations to this is to incrementally add activities. They might use one or two to start, and as they see success implementing those activities they maybe will integrate more.CLASP is very concerned with prioritizing activities, determining the cost of activities and helping people understand what the considerations are in adopting an activity. The CLASP implementation guide provides that information on an activity-by-activity basis, and there are road maps through it.For example, the things you are going to do for new software development are different from the things you are likely to introduce for legacy software development. In new software development, I am probably going to be more interested in solving my problems at an architectural level, whereas if I've already got the software built, I'm going to start by doing more analysis.VIEGA: The process is pretty agnostic and can be broadly applicable. Security basically boils down to a core set of services that are applied to resources, and that is a constant throughout. What does change are the threats to resources. So there are differences between environments, but we have done a good job of taking that into account.VIEGA: I haven't come across anything yet. The closest thing really is in the government space with things like Common Criteria. That is policy-based stuff that boils down to things that should be done in addition to what we're saying.VIEGA: Ultimately, security is an easier problem than reliability in general. We're never going to have bug-free software, and there is at least some hope of building software that is free from security defects. But on the whole, we are not going to get rid of security problems. The best we can hope to do is minimize the impact when security problems arise.However, most security problems fall into a small set of buckets that follow very clear paradigms. Where I think industry can get to is to not have these common problems in their code.VIEGA: We have had some interest from the government in improving their software development practices. In the Navy, for example, they have an advanced understanding of the problem, and they are definitely looking for ways to reduce their risk. That doesn't mean they've started adopting these processes, but they are open to evaluating these things.VIEGA: Everybody that I have dealt with could be doing more. There are plenty of people who are doing a lot. But there are other things that everybody could be doing that would improve security and even reduce cost. People have been addressing the problem late in the development lifecycle, and we're trying to encourage people to address it earlier in the lifecycle.VIEGA: The Defense Department could set up a program that is mandatory for the entire department, and if it was successful could be something that is used by other agencies. I think the Homeland Security Department is a good candidate for a centralized home, although they seem to be more interested in border security and infrastructure security, not cybersecurity. I think that was evidenced by the resignation of Amit Yoran. In an ideal world, that is probably where you would want it, but it's probably up to places like the DOD, where they're more concerned about the problem and they are spending resources on it to come up with a government solution.