quality timeEditors: Nancy Eickelmann ■ Motorola ■ nancy

.eickelmann@motorola.co m

Jane Huffman Hayes ■ University of Kentucky ■ hayes@cs.uk y .ed u

Security and Software Quality:An Interview with Frank Perry

Jane Huffman Hayes, Nancy Eickelmann, and E. Ashlee Holbrook

ne of the fastest growing topics in sys- tems engineering today is security. It’s nearly impossible, and certainly not ad- visable, to neglect security’s role when developing a software system. The ram- ifications of failing to completely andO

correctly address security can be devastating to an organization, not only in compromised data and

financial cost

but also in the

time and en-

ergy spent to recover. One of us, Jane Hayes, sat down with an expert in the field, Frank Perry, to discuss the state of the art and future directions of system security and particularly how it inter- acts with software quality.

Frank Perry has been chief engineer of the System and Network Solutions Group at SAIC for two and a half years. The group of almost10,000 people focuses on network technolo- gies and applications, primarily in the federal market. Prior to joining SAIC, Perry spent two years as the chief technology officer at the US Department of Veteran’s Affairs. He has also served as technical director at the US Navy’s Space and Naval Warfare Systems Command

and at the Defense Information Systems Agency. He received his PhD in electrical engineering with a minor in computer science from the Naval Postgraduate School.

Jane Hayes: Good morning, Dr. Perry. We’ve put together a list of questions from a diverse group of folks from industry, acade- mia, and civil service. We asked them, “If you had a chance to speak with an expert on secu- rity, what questions would you ask dealing with software security and software quality?” One of the overarching questions we heard was “What concerns keep you up at night?”

Frank Perry: I’m not the type of person that loses sleep over very much, but if I were to lose sleep over security concerns, it would be over the state of security on the Internet today and the potential for harm if the wrong set of things were to come together. For example, if you combine a zero-day vulnerability [a secu- rity vulnerability that someone might exploit before it becomes generally known] together with an extremely fast propagation worm, such as a Warhol worm, which can propagate world- wide during its 15 minutes of fame, and if that worm has a hostile payload focused on doing damage or making your machine part of a bot- net, then that’s actually a fairly scary thought.

JH: I’d like to talk a bit about the software development process. Do you have a preferred security process for software development? For example, CLASP [Comprehensive, Lightweight Application Security Process] or perhaps Mi-

12 IEEE SOFTW ARE Published by the IEEE Computer Society 0740-7459/06/$20.00 © 2006 IEEE

QUALITY TIME

crosoft’s Security Development Lifecy- cle process?

FP: I don’t really. More so than argu- ing for a specific “proper-noun” process—CLASP in the Rational Unified Process framework, or someone else’s process in a different framework—the more important issue is to have a process—whatever is right for your orga- nization—and integrate it into a broader set of software development processes. For example, integrate it in the CMMI [Capability Maturity Model Integration] approach and evaluate it as a part of the broader set of processes that the enter- prise uses.

Within our group at SAIC, we’ve embraced CMMI as many others in the industry have. We’ve created our own process asset library to include a num- ber of security-specific processes. Our group has gone through the CMMI ap- praisal and is at maturity level 5. With security, as with many other aspects of the overall software development life cycle, the key issue is to have a process that makes sense for your organization and industry and then tailor it as ap- propriate to individual programs. Even if you begin with something like CLASP, it’s actually a general, high-level, and fairly heavyweight set of processes that are not going to be

appropriate for every project. I don’t think it’s different than other aspects of software develop- ment. Having security processes inte- grated into your overall set of software development processes is the important step.

JH: The next question comes from one of our leaders who has a US De- partment of Defense background, so that will probably show in the ques- tion. Can you tell us about the devel- opment of standards and policies for secure software systems? The DoD threw out their standard 10 years ago in the name of acquisition reform. That action appears, to some, to have been a disaster. Has the DoD recovered?

FP: I think defense is actually doing quite well compared to many other sec- tors in the market today with respect to security standards and policies. If we look back to the early 1980s, we had

Frank Perry

the Rainbow Series of publications, which were very good, very thorough, very complete, and also very difficult to implement. They were ahead of their time with respect to the capabilities of many of the operating systems of the day. You go from there forward through what the DoD has been doing, and you’ll see a focus on Common Criteria certification and National Information Assurance Partnership certification for products in the defense market. If you fast-forward beyond that, you see work that’s been going on in Security-Enhanced Linux, which started at the US National Security Agency. SE Linux has been broadly adopted by the open source community and has the potential to

1 3 M a y / J u n e 2006 IEEE SOFTW ARE

QUALITY TIME

fundamentally change some aspects of the computing platform that have been problematic. I think the DoD actually has its act pretty well together in that regard.

JH: Why is it so difficult to get com- panies to adopt known, sound soft- ware engineering practices when build- ing security-critical software?

FP: Security-critical software is ex- tremely complex, more so than many other aspects of software development. That’s one of the issues—complexity. Another issue is time—the time it takes to deal appropriately with that level of

complexity and to get the right level of assurance in the overall process. It’s also weighing that time versus the counter- balancing force of speed to market and competitiveness. That makes it really difficult. You also have a mindset shift, from the early Internet days when peo- ple were benevolent users to today’s In- ternet where you have to assume malice from the outset. That makes it much more difficult. If you look at crypto- graphic products and implementations, if you look at some of the core crypto- graphic building blocks, it really does take an expert to deal with them. Many software engineers aren’t appro- priately trained to deal with those tasks. One issue this raises is that if we’re go- ing to be successful, we have to inte- grate those products into much larger architectural building blocks. Getting someone to take a low-level crypto- graphic API and integrate it appropri- ately into an overall system environment is really going to tax many software de- velopment organizations.

JH: What have you found to be the most effective security tools?

FP: This really isn’t my area of spe- cialty, so I can’t give you specific an- swers to that question. In general, I look to some of the real experts in that field and am hopeful because of the level of optimism that several of them have expressed. For example, in an in- terview at the European Open Source Conference last year [EuroOSCON2005], Alan Cox was optimistic about the code verification and analysis tools that are finally starting to come into the marketplace—they have real promise for the future. At the same time, though, we’re only at the start of that journey, and it’s going to be a very long time before that becomes pervasive in the industry. It’s certainly not pervasive today.

JH: From the point of view of soft- ware engineering, what tools would you like cryptographers to develop? What cryptographic tools are needed or are inadequate for today’s engineer- ing needs? What will be needed in five or 10 years?

1 3 M a y / J u n e 2006 IEEE SOFTW ARE

FP: I’m not sure I can prognosticate

10 years into the future; that’s a little beyond my crystal ball’s capability. I’ll go back to what I said earlier about the complexity of cryptographic products and security protocols. There are some key examples that have been very suc- cessful. Even though the Distributed Computing Environment was too com- plex to propagate widely, Kerberos as a security mechanism was an integral part of DCE. It’s been very successful and survives to this day in a number of products.

Similarly, if you look at SSL [Secure Sockets Layer] and Transport Layer Se- curity in Web-based applications, you’ll find you’re not really relying on most software engineers to develop or even integrate many of those complex cryptographic products. You leave it to the experts when it comes to designing and implementing cryptographic prod- ucts and secure protocols and integrat- ing them into higher-level architectural building blocks. For most software en- gineers, then, it’s more a question of choosing how to use and configure the building blocks rather than one of devel- opment. You have a much higher prob- ability of success with that approach. DCE and SSL integrated into higher- level building blocks are two key ex- amples. If I look today at architectural constructs such as service-oriented ar- chitectures, I think

we’ll have to take a similar approach if we’re going to have end-to-end security across a distributed chain of service invocations. The mar- ketplace is not there yet.

Another key for foundation mech- anisms like DCE and SSL to be suc- cessful is that they must be standards- based; we have to evolve beyond the interoperability problem stage to a state where the standards are well un- derstood and accepted. People should understand how to profile and imple- ment the standards, and multiple ven- dor implementations should be inter- operable out of the box. That’s the ideal state. We’re making progress both with the new domains like service- oriented architecture and with truly standards-based and interoperable implementations.

JH: What do you feel is the greatest security threat on the horizon, and where should research focus to counter it? That is to say, with new technologies, for example FPGAs [field-programma- ble gate arrays] that let software mod- ules reconfigure themselves or adapt, what kind of security issues do you see surfacing?

FP: There’s a scary thought—adap- tive or self-modifying software and emergent behavior. I’m not sure how to deal with that in a security environ- ment; that’s very challenging and com- plex. Many security issues, however, are not as much about technology as they are about engineering and process, and we have the same issue we just dis- cussed. Certainly new technologies will play a significant role, just as airbags did when they were introduced in auto- mobile safety, but the airbag by itself doesn’t give you a safe ride. The safe ride comes from the airbag integrated intelligently into the overall system— understanding the threat model and in- tegrating not only front- but also side- curtain airbags to protect against the different types of threats that you face in vehicles. Those advances on a sys- tematic level are key to going forward. They’ll most certainly involve new tech- nologies, but progress isn’t just about new technologies.

With defense-in-depth, you decide

what the right mechanisms are at

each layer in your stack for

protection

as well as detection and

reaction.

JH: How secure do you think things are right now? How secure is the Amer- ican “homeland” from potential soft- ware security threats?

FP: It goes to the very first question that you asked. If the wrong set of things were to come together, it would cause a real problem, and the degree of damage would depend on preparation. In the general Internet population, the combination of something like a zero- day exploit, a very high-speed propa- gation mechanism, and a destructive payload could significantly affect a substantial number of private PCs. To the extent that an organization has de- fense-in-depth mechanisms built into their enterprise architecture, from pro- tective mechanisms at each layer of the stack all the way through to detection and reaction mechanisms, the enter- prise should be able to do much better. We must evolve to have those mecha- nisms in place, and again it should be more proactive rather than reactive. Certainly, the enlightened enterprises that focus on defense-in-depth

security are in much better shape, but even there we have a way to go.

JH: What current weaknesses do you see in the area of perimeter-based secu- rity, and also in host-based security?

FP: From time to time, you see ar- guments come up about firewalls get- ting in the way of conducting com- merce and business, so people want to eliminate firewalls and just go with host-based security. Conversely, I’m sure you can find similar arguments for relying only on perimeter-based secu- rity. Today, the appropriate approach in my opinion is defense-in-depth, where you take a layered approach and don’t depend on any single mechanism. With defense-in-depth, you decide what the right mechanisms are at each layer in your stack for protection as well as detection and reaction.

JH: What role does software diver- sity play in our nation’s security? In other words, does a single operating system’s dominance place our national cyberinfrastructure at risk?

FP: Monocultures in any environ-

14 IEEE SOFTW ARE www .computer .org/softwar e

QUALITY TIME

1 5 M a y / J u n e 2006 IEEE SOFTW ARE

ment are less than completely desirable, but you have to counterbalance that with practical realities. We’re in an en- vironment today where the majority of desktops are Windows-based desktops; there aren’t as many Macintosh-based or Linux-based desktops. From an op- erations perspective, it’s something that we have to deal with and put the ap- propriate mechanisms in place. Cer- tainly, [having a single operating sys- tem] does make it easier to have a broader impact more rapidly if some- one compromises or penetrates the de- fense-in-depth structures.

JH: Is security a real system at- tribute or an emergent property that is context, time, and environment based?

FP: It really is an attribute; it has to be a fundamentally built-in attribute to the system through the whole life- cycle process that we’ve talked about. You can’t count on serendipity to have it emerge.

JH: We know that many, most, or maybe all security issues today arise be- cause of implementation errors that make systems vulnerable to certain at- tacks such as buffer overflows. We also know that most of the programs we use have bugs, but are all security problems related to bugs? In particular, if we man- aged to make programs that were error free, would we thereby get rid of

all our security problems?FP: It depends on how you

define bug. If you talk about it in the context of buffer overflows, those are imple- mentation problems—for instance, not doing the appropriate bounds checking, or not testing to discover that someone failed to do the appropriate bounds checking. Conversely, you can find ex- amples of security problems where the implementations were high quality. For example, look at the security problems [we had] in early 802.11 wireless tech- nology with the broken Wired Equiva- lency Protocol, and the correction of those problems in Wi-Fi Protected Ac- cess and the Temporal Key Integrity Protocol, which are secure from the ground up. I’d call that a design-time or an architecture-time issue. It’s a different

class of problem than implementation problems such as buffer overflow. Un- fortunately, you have to have everything right to have a secure implementation.

JH: Finally, are there any questions that you thought our readers would ask that we did not?

FP: This [security and quality] is such a broad topic. There are probably a mil- lion questions across the spectrum in- cluding ones about identity and privacy. Those are important issues; they’re not the same as security, but they have many parallels in our use of networked infor- mation technology. Privacy issues are very significant today, and it’s going to take some time for our society to work through these issues.

AcknowledgmentsWe thank the many

individuals from gov- ernment, industry, and academia who sug- gested excellent questions for this interview as well as security experts to interview. We thank Charlotte and John Gauss for suggesting Frank Perry as a possible interview candidate.

Jane Huffman Hayes is an assistant professor of software engineering in the Computer Science Department at the University of Kentucky. Contact her at hayes@cs.uky .edu.

Nancy Eickelmann is a Distinguished Member of the Technical Staff at Motorola Labs. Contact her at

1 5 M a y / J u n e 2006 IEEE SOFTW ARE

nancy. eickelmann@motorola.com.

E. Ashlee Holbrook is a PhD student in the Depart- ment of Computer Science at the University of Kentucky. Contact her at ashlee@uky.edu.

For more information on this or any other computing topic, please visit our Digital Library at www .computer .org/ publications/dlib.

HowHow totoReachReach UsUs

WritersFor detailed information on submitting articles, write for our Editorial Guidelines (software@computer.org) or access www .computer .org/software/autho r .htm.

Letters to the EditorSend letters to

Editor, IEEE Software10662 Los Vaqueros Circle Los Alamitos, CA 90720 software@computer.org

Please provide an email address or daytime phone number with your letter.

On the WebAccess www.computer.org/software for information about IEEE Software.

SubscribeVisit www .computer .org/subscribe.

Subscription Change of AddressSend change-of-address requests for magazine subscriptions to address.change@ieee.org. Be sure to specify IEEE Software.

Membership Change of AddressSend change-of-address requests for IEEE and Computer Society membership to member.ser vices@ieee.org.

Missing or Damaged CopiesIf you are missing an issue or you

received a damaged copy, contact help@computer .org.

Reprints of ArticlesFor price information or to order reprints, send email to software@computer.org or fax +1 714 821 4010.

Reprint PermissionTo obtain permission to reprint an article, contact the Intellectual Property Rights Office at copyrights @ieee.org.

1 5 M a y / J u n e 2006 IEEE SOFTW ARE