NEWS AT SEI
This library item is related to the following area(s) of work:Security and Survivability
This article was originally published in News at SEI on: June 1, 2008
This column is based on a podcast recorded with Julia Allen and posted to CERT’s Podcast Series: Security for Business Leaders. Julia Allen is a senior researcher with CERT, working on security governance and software assurance. Bill Pollak, who interviewed her, is the manager of communications for the SEI.
Bill Pollak: Generally we think of security as an operational IT issue focused on defending our computers and networks from attackers and from security breaches; or we think of security as information security, concerned with protecting information in digital form.But in this conversation we’re discussing software security.What is software security and how is it different from IT or information security?
Julia Allen: In much of our work at CERT and in the software and IT communities at large, we’re all familiar with IT security—defending networks and defending systems from attack. With all of the compliance issues that are emerging today around the protection of personally identifiable information, we’re all becoming much more sensitive to issues of information security.
Software security is just starting to make it onto the radar screen for organizations. In a nutshell, the objective of software security is to build better, defect-free software. Typically software has many defects and quite a few of these tend to be the source of security vulnerabilities that show up in our operational systems and networks.So another way to think about software security is developing software that is more able to resist attack.And in the face of an attack—a successful attack—it’s better able to tolerate the attack and recover from the attack as quickly as possible.
So to net it out, secure software is less vulnerable to attack and a little bit more bulletproof. IT security tends to be more about detecting and responding to incidents, finding and patching vulnerabilities—more remedial or reactive.For software security, the idea is to get in front of the issue by building more robust software. Software defects are identified and addressed much earlier in the software development lifecycle. It’s more preventive or more proactive, if you will. The intent is to put better products in the field so we can eliminate some of the issues we’re dealing with today.
Bill Pollak: Why do business leaders need to pay more attention to software security?
Julia Allen: There are probably two major trends or topics that are worthy of business leader consideration.The first one is that attackers are getting much smarter and the second one is that it’s just good business. I’ll say a little bit more about both of these.
What we’re seeing is that the attacker community is becoming much more sophisticated in their approaches. In fact, this is actually a well-funded profession with a very robust underground economy where sensitive information including personal identities and credit card information is being bought and sold quite freely.As a community, we’ve gotten better at protecting our networks, our IT infrastructures, and our information. As a result, attackers are now focusing on the more vulnerable parts of our systems, which are the applications, particularly web-facing applications.They are the primary gateway to sensitive data. So this is where software security can really provide an advantage.That’s the part about the attackers becoming a bit more sophisticated and kind of upping the ante. Another thing to think about here is that an attacker only requires one entry point into a system whereas software developers and IT staff need to anticipate and defend all entry points—which is a nearly impossible requirement.So that’s one aspect of why business leaders need to pay attention.
In terms of it being just good business, we’re seeing more and more indicators that the market place is starting to demand it, particularly from organizations that develop software. They’re saying, “We want secure products and we’re not going to put your product into our infrastructure unless it’s secure.”The total cost of ownership for software, 50 to 80 percent, depending on whose numbers you pay attention to, is in the maintenance and operations of software.So that’s where a huge amount of the cost is going because of the poor quality of software that’s going into production.What we’ve observed is that upwards of 50 percent of operational software vulnerabilities are actually design flaws that could have been discovered much earlier in the lifecycle.And in fact, you can predict anywhere from 100 to 1,000 times cost and schedule savings in some instances by identifying and correcting defects early in the lifecycle versus later.
Again, to net it out, we really can’t keep up or get ahead of the curve by dealing with security as strictly an operational issue.We need to find a way to deploy better products in the field.
Bill Pollak: How did software get to be so insecure?
Julia Allen: At the Software Engineering Institute and elsewhere, we’ve seen many instances where software is growing in complexity; we keep adding to it and we keep changing it.Our marketplaces and our customers want new features, new functions, new services, faster.And more software means more vulnerabilities.
Complexity is compounded when you take into account how connected we are today in terms of the Internet; the fact that software development, assembly, and integration are happening globally; the fact that we’re always adding new components and new pieces; and the fact that we’re interfacing a very complex system with other complex systems creating systems of systems issues.
This is exacerbated by more and more third party software where we as an organization have responsibility for putting the whole system together but we’re not developing most of it ourselves. We have to apply the same rigor, requirements, processes, and service level agreements on our suppliers as we do on ourselves.
When you think about all of these different factors, it’s really hard even for a very talented development team to get their heads around these issues and try and figure out how to tackle all of this complexity.When you throw security into the mix, it’s a pretty daunting undertaking.
Bill Pollak: How is developing software with security in mind different from normal software development?
Julia Allen: This is the crux of the message I want to get across, which is how to think with a security mind-set.There are a couple of factors to point out here. The first is to think about security from the beginning of the lifecycle.Security, at least historically, tends to be an afterthought if it’s thought about at all. Engineering for more secure software needs to be tackled from the very beginning, when you’re going through acquisition, when you’re going through requirements specification, all the way through the lifecycle.
Using other non-functional, quality attributes like performance or reliability as examples, think about security during requirements, during design, during architecture, and all the way through implementation, test, and deployment.
Probably the toughest challenge for software project managers, architects, designers, and engineers is that they need to learn to think like an attacker.We often think about what the software should do, what the functions, features, and capabilities are. But we rarely think about what the software should not do.And I would hazard a guess that we really don’t think about what it should do and not do when it’s under attack.
And certainly last but not least, address security as a risk management issue throughout the development lifecycle.Constantly assess, at each lifecycle phase, what the highest areas of vulnerability and risk are and address the highest risks first. Fully recognize, as you go through the lifecycle, that software security risks are likely to change quite a bit depending on what kind of applications you’re building and what kind of services the software is providing. The risks and priorities for tackling them need to be assessed on a continuous basis.
Bill Pollak: Could you provide some examples of known good practices for developing more secure software?
Julia Allen: The good news is that there is an emerging body of knowledge, experience, and practice that organizations that build and buy software are starting to identify. As I mentioned earlier, the first key practice is to integrate software security practices into your existing development lifecycle. We’re not suggesting adding a whole new process or a whole new development strategy, method, or lifecycle definition.Take your existing lifecycle and add these practices to it.
During requirements engineering and architecture and design, we recommend a practice called misuse and abuse cases. These are helpful when you’re adding a new requirement or a feature into your requirements. Give some serious thought to how the feature could be unintentionally misused or intentionally abused by an attacker.For example, given a requirement to interface a web server and a database server for some type of user-facing application, often a developer will assume that the connection between the web server and the database server can always be trusted.Defining and exercising a misuse or abuse case can actually challenge this assumption by describing scenarios and various ways to exercise the software under the assumption that the interface is untrusted.
Another example of good practice is the development of what we call attack patterns. Attack patterns describe a class of vulnerability, how that vulnerability can be exploited, and what kind of attacker skill is required.You can use attack patterns throughout the lifecycle to say, “Okay, if I were an attacker, how would I break this design or how would I infiltrate this particular piece of code?”
Some of the more mature practices are in the secure coding area. There’s lots of great guidance on secure coding practices for different languages, using code analysis and other scanning techniques.Last but not least is security testing. Techniques include white box and black box testing as well as threat modeling where you can take an attack pattern and fold it into your testing suite. Tried and true penetration testing can also be very helpful.
Bill Pollak: What are some of the effective ways that project managers can get started?
Julia Allen: Well, obviously don’t try to boil the ocean on the first day.Think about taking small steps from the beginning.Probably one of the best ways to get started is to take a look at the competencies and skills of your current development team and enhance them with some security experts.The organizations that have had great success tackling secure software development have security experts co-resident with software development teams, helping guide, educate, and inform them as they go through their development.
The highest return on investment is to add security practices as early in the lifecycle as possible because that’s where you get the greatest benefit.But adding practices early in the lifecycle isn’t as mature of a practice, for example, during requirements elicitation and engineering or during the early stages of architecture and design.So most organizations today are starting out with secure coding practices, code analysis, peer review, and doing various types of lower-level testing to tease out some of the defects that might have gotten through to code.These are the most mature practices that are in use today, so many organizations start with these.
In all of our improvement-initiative work at the SEI and independent of any particular practice, there are several tried and true ways to get started.First you have to understand what you’re trying to do. Why do we care about secure software engineering?Why are we doing this? What are we hoping to accomplish?Make sure the incentives are clear. Get good buy in from your sponsors so you can have a sustainable improvement initiative.Find some early pilots, just a small number, and make sure to demonstrate some early results.Make sure people understand this is going to take time.Like a lot of things in software, it’s a never-ending journey because the threat, requirements, and risk landscapes are always changing. We always say “communicate, communicate, communicate,” right? So make sure to conduct regular awareness training and ongoing education.
While putting secure software engineering practices in place is much easier on a new project where you have a clean slate to start with, we’re getting some good case studies from the field that describe the harder issue of legacy systems—systems that are already deployed, perhaps where you have third-party software. Subjecting that software to some rigorous scrutiny may be more challenging but can produce the highest payoff.
Allen, Julia; Barnum, Sean; Ellison, Robert; McGraw, Gary; & Mead, Nancy. Software Security Engineering: A Guide for Project Managers, Boston, MA: Addison Wesley, 2008. An excerpt from the book’s Preface is available on the Build Security In website.
The Department of Homeland Security Software Assurance Program’s Build Security In website
Julia Allen’s podcast: “Building More Secure Software.”
Nancy Mead’s podcast: “Identifying Software Security Requirements Early, Not After the Fact.”
Gary McGraw’s podcast: “How to Start a Secure Software Development Program.”
The views expressed in this article are the author's only and do not represent directly or imply any official position or view of the Software Engineering Institute or Carnegie Mellon University. This article is intended to stimulate further discussion about this topic.
For more information
Please tell us what you
think with this short
(< 5 minute) survey.