You are on page 1of 4

Building Security In

Editor: Gary McGraw,

Software Security

oftware security is the idea of engineering software things. On the other hand, applica-
tion security is about protecting soft-
so that it continues to function correctly under ware and the systems that software
runs in a post facto way, after devel-
malicious attack. Most technologists acknowledge opment is complete. Issues critical to
this subfield include sandboxing code
this undertaking’s importance, but they need some (as the Java virtual machine does),
protecting against malicious code,
help in understanding how to tackle it. This new department obfuscating code, locking down exe-
cutables, monitoring programs as
GARY aims to provide that help by explor- leverage good software engineering they run (especially their input), en-
MCG RAW ing software security best practices. practice and involve thinking about forcing the software use policy with
Cigital The software security field is a rel- security early in the software life technology, and dealing with exten-
atively new one. The first books and cycle, knowing and understanding sible systems.
academic classes on the topic appeared common threats (including lan- Application security follows nat-
in 2001, demonstrating how recently guage-based flaws and pitfalls), de- urally from a network-centric ap-
developers, architects, and computer signing for security, and subjecting all proach to security, by embracing
scientists have started systematically software artifacts to thorough objec- standard approaches such as pene-
studying how to build secure software. tive risk analyses and testing. Let’s trate and patch4 and input filtering
The field’s recent appearance is one look at how software security fits into (trying to block malicious input) and
reason why best practices are neither the overall concept of operational se- by providing value in a reactive way.
widely adopted nor obvious. curity and examine some best prac- Put succinctly, application security is
A central and critical aspect of the tices for building security in. based primarily on finding and fix-
computer security problem is a soft- ing known security problems after
ware problem. Software defects with ...versus application they’ve been exploited in fielded sys-
security ramifications—including security tems. Software security—the pro-
implementation bugs such as buffer Application security means many dif- cess of designing, building, and test-
overflows and design flaws such as ferent things to many different peo- ing software for security—identifies
inconsistent error handling— ple. In IEEE Security & Privacy maga- and expunges problems in the soft-
promise to be with us for years. All zine, it has come to mean the ware itself. In this way, software secu-
too often, malicious intruders can protection of software after it’s already rity practitioners attempt to build
hack into systems by exploiting soft- built. Although the notion of protect- software that can withstand attack
ware defects.1 Internet-enabled soft- ing software is an important one, it’s proactively. Let me give you a spe-
ware applications present the most just plain easier to protect something cific example: although there is some
common security risk encountered that is defect-free than something rid- real value in stopping buffer overflow
today, with software’s ever-expand- dled with vulnerabilities. attacks by observing HTTP traffic as
ing complexity and extensibility Pondering the question, “What is it arrives over port 80, a superior ap-
adding further fuel to the fire. By any the most effective way to protect soft- proach is to fix the broken code and
measure, security holes in software ware?” can help untangle software avoid the buffer overflow com-
are common, and the problem is security and application security. On pletely.
growing: CERT Coordination one hand, software security is about
Center identified 4,129 reported building secure software: designing practiced by
vulnerabilities in 2003 (a 70 percent software to be secure, making sure operations people
increase over 2002, and an almost that software is secure, and educating One reason that application security
fourfold increase since 2001).2,3 software developers, architects, and technologies such as firewalls have
Software security best practices users about how to build secure evolved the way they have is because

Building Security In

operations people dreamed them up. evolving software is difficult (even if tend to focus on functionality. Obvi-
In most corporations and large orga- the software is not patched every five ously, there are security functions in
nizations, security is the domain of the minutes). If software were in some the world, and most modern soft-
infrastructure people who set up and sense self-protecting (by being de- ware includes security features, but
maintain firewalls, intrusion detection signed defensively and more prop- adding features such as SSL (for
systems, and antivirus engines (all of erly tested from a security perspec- cryptographically protecting com-
which are reactive technologies). tive) or at least less riddled with munications) does not present a
However, these people are opera- vulnerabilities, running a secure net- complete solution to the security
tors, not builders. Given the fact that work could become easier and more problem. Software security is a sys-
they don’t build the software they cost effective. tem-wide issue that takes into ac-
have to operate, it’s no surprise that In the short run, we clearly— count both security mechanisms
their approach is to move standard desperately—must make progress on (such as access control) and design
security techniques “down” to the both fronts. But in the long run, we for security (such as robust design
desktop and application levels. The must figure out ways to build easier- that makes software attacks difficult).
gist of the idea is to protect vulnera- to-defend code. Software security is Sometimes these overlap, but often
ble things (in this case, software) about helping builders do a better they don’t.
from attack, but the problem is that job so that operators end up with an Put another way, security is an
vulnerabilities in the software let ma- easier job. emergent property of a software sys-
licious hackers skirt standard security tem. A security problem is more
technologies with impunity. If this the software likely to arise because of a problem in
were not the case, then the security development a standard-issue part of the system
vulnerability problem would not be life cycle (say, the interface to the database
expanding the way that it is. Clearly, On the road to making such a funda- module) than in some given security
this emphasizes the need to get mental change, we must first agree feature. This is an important reason
builders to do a better job on the that software security is not security why software security must be part
software in the first place. software. This is a subtle point often of a full lifecycle approach. Just as
Protecting a network full of lost on development people who you can’t test quality into a piece of

Introducing Building Security In

T his department is about building systems that include properly
constructed software. Past issues of this magazine have called
attention to the serious problems software practitioners face when it
bifurcation of approaches when it comes to software, into appli-
cation security and software security.3
The core of the problem is that building systems to be secure
comes to security. Most security researchers agree that we have a cannot be accomplished by using an operations mindset. Instead,
pressing problem. In “A Call to Arms: Look Beyond the Horizon,”1 we must revisit all phases of system development and make sure
Jeannette Wing includes “software design and security” as one of that security engineering is present in each of them. When it comes
three critical areas to tackle if security research is to make progress. In to software, this means understanding: requirements, architecture,
“From the Ground Up: The DIMACS Software Security Workshop,”2 I design, coding, testing, validation, measurement, and main-
introduce the software security problem, discuss trends that demon- tenance. This is a far cry from code review and black-box testing!
strate the problem’s growth, and introduce the philosophy of proac- Essentially, this department is about security best practices from
tively attacking the problem at the architectural level. all phases of the software life cycle. My plan is to coauthor a set of
The good news is that technologists and commercial vendors articles with software security practitioners about software security
all acknowledge that the software security problem exists. The bad best practices from the real world. You are welcome and
news is that we have barely begun to instantiate solutions, and encouraged to help!
many proposed solutions are impotent. Not surprisingly, early
commercial solutions to the software security problem tend to take References
an operational stance—that is, they focus on solving the software 1. J. Wing, “A Call to Action: Look Beyond the Horizon,” IEEE Security & Pri-
security problem through late lifecycle activities such as firewalling vacy, vol. 1, no. 6, 2003, pp. 62–67.
(at the application level), penetration testing, and patch man- 2. G. McGraw, “From the Ground Up: The DIMACS Software Security Work-
agement. Because security has tended to be operational in nature shop,” IEEE Security & Privacy, vol. 1, no. 2, 2003, pp. 59–66.
(especially in the corporate world where IT security revolves 3. G. McGraw, “Building Secure Software: Better than Protecting Bad Soft-
around the proper placement and monitoring of network security ware (Point/Counterpoint with Greg Hoglund),” IEEE Software, vol. 19, no.
apparatus), this operational tack is only natural. This leads to a 6, 2002, pp. 57–59. ■ IEEE SECURITY & PRIVACY 81

Building Security In

ket-driven improvement and rapid

Security External Static Penetration
requirements review analysis testing
maturity later this year. As stated
(tools) earlier, code review is a necessary,
Abuse Risk Risk-based Risk but not sufficient, practice for
cases analysis security tests analysis Security achieving secure software. Security
bugs (especially in C and C++) can
be deadly, but architectural flaws are
just as big a problem.
Requirements Design Test Code Test Field Security testing must encompass
and use cases plans results feedback two strategies: testing security func-
tionality with standard functional
Figure 1. Software security best practices applied to various software artifacts. testing techniques, and risk-based se-
Although the artifacts are laid out according to a traditional waterfall model in this curity testing based on attack patterns
illustration, most organizations follow an iterative approach today, which means that and threat models. A good security
best practices will be cycled through more than once as the software evolves. test plan (with traceability back to re-
quirements) uses both strategies. Se-
curity problems aren’t always appar-
software, you can’t spray paint secu- Security should be explicitly at ent, even when we probe a system
rity features onto a design and expect the requirements level. Security re- directly, so standard-issue quality as-
it to become secure. There’s no such quirements must cover both overt surance is unlikely to uncover all the
thing as a magic crypto fairy dust— functional security (say, the use of pressing security issues.
we need to focus on software secu- applied cryptography) and emergent Penetration testing is also useful,
rity from the ground up. characteristics. One great way to especially if an architectural risk
As practitioners become aware of cover the emergent security space is analysis is specifically driving the
software security’s importance, they to build abuse cases. Similar to use tests. The advantage of penetration
are increasingly adopting and evolv- cases, abuse cases describe the sys- testing is that it gives a good under-
ing a set of best practices to address tem’s behavior under attack; build- standing of fielded software in its
the problem. Microsoft has carried ing them requires explicit coverage real environment. However, any
out a noteworthy effort under the of what should be protected, from black-box penetration testing that
rubric of its Trustworthy Comput- whom, and for how long. doesn’t take the software architec-
ing Initiative.5,6 Most approaches in At the design and architecture ture into account probably won’t
practice today encompass training level, a system must be coherent and uncover anything deeply interesting
for developers, testers, and archi- present a unified security architec- about software risk. Software that
tects, analysis and auditing of soft- ture that takes into account security falls prey to canned black-box test-
ware artifacts, and security engineer- principles (such as the principle of ing—which simplistic application
ing. In the fight for better software, least privilege). Designers, architects, security testing tools on the market
treating the disease itself (poorly de- and analysts must clearly document today practice—is truly bad. This
signed and implemented software) is assumptions and identify possible at- means that passing a cursory pene-
better than taking an aspirin to stop tacks. At both the specifications- tration test reveals very little about
the symptoms. There’s no substitute based architecture stage and at the your real security posture, but fail-
for working software security as class-hierarchy design stage, risk ing an easy canned penetration test
deeply into the development process analysis is a necessity—security ana- tells you that you’re in very deep
as possible and taking advantage of lysts should uncover and rank risks so trouble indeed.
the engineering lessons software that mitigation can begin. Disre- Operations people should care-
practitioners have learned over the garding risk analysis at this level will fully monitor fielded systems dur-
years. lead to costly problems down the ing use for security breaks. Simply
Figure 1 specifies one set of best road. External review (outside the de- put, attacks will happen, regardless
practices and shows how software sign team) is often necessary. of the strength of design and imple-
practitioners can apply them to the At the code level, we should mentation, so monitoring software
various software artifacts produced focus on implementation flaws, es- behavior is an excellent defensive
during software development. In the pecially those that static analysis technique. Knowledge gained by
rest of this section, I’ll touch on best tools—tools that scan source code for understanding attacks and exploits
practices. As this department un- common vulnerabilities—can dis- should be cycled back into the de-
folds, we’ll cover each of these areas cover. Several vendors now address velopment organization, and secu-
in much greater detail. this space, and tools should see mar- rity practitioners should explicitly


Building Security In

track both threat models and attack Much work remains to be done 5. L. Walsh, “Trustworthy Yet?” Infor-
patterns. in each of the best practice areas, but mation Security Magazine, Feb. 2003;
Note that risks crop up during all some basic practical solutions should http://infosecuritymag.techtarget.
stages of the software life cycle, so a be adapted from areas of more ma- com/2003/feb/cover.shtml.
constant risk analysis thread, with re- ture research. 6. M. Howard and S. Lipner, “Inside
curring risk tracking and monitoring the Windows Security Push,”
activities, is highly recommended. IEEE Security & Privacy, vol. 1, no. a
T his department’s goal is to cover
many of the best practices
sketched out here in much greater
1, 2003, pp. 57–61.

Gary McGraw is chief technology officer

of Cigital. His real-world experience is
effort detail. You can do two things to help: grounded in years of consulting with
By and large, software architects, de- send feedback to me regarding major corporations and software pro-
velopers, and testers remain blithely which best practices you want to see ducers. He serves on the technical advi-
unaware of the software security covered first, and volunteer to help sory boards of Counterpane, Fortify, and
Indigo. He also is coauthor of Exploiting
problem. One essential form of best develop an article on any individual Software (Addison-Wesley, 2004), Build-
practices involves training software best practice outlined here. With ing Secure Software (Addison-Wesley,
development staff on critical software your help, we can create a decent un- 2001), Java Security (John Wiley & Sons,
1996), and four other books. Contact
security issues. The most effective derstanding of software security best
him at
form of training begins with a de- practices that can be practically ap-
scription of the problem and demon- plied and make a big impact on the
strates its impact and importance. Be-
yond awareness, more advanced
software security training should
software security problem.
As the trinity of trouble—con-
nectedness, complexity, and extensi-
offer coverage of security engineer-
ing, design principles and guidelines,
bility—continues to impact software
security in a negative way, we must
implementation risks, design flaws,
analysis techniques, software ex-
begin to grapple with the problem in
a more reasonable fashion. Integrat-
ploits, and security testing. Each best ing a decent set of best practices into
practice called out earlier is a good
candidate for in-depth training.
the software development life cycle
is an excellent way to do this. Al- BE SECURE.
Software security can and should though software security as a field
borrow from other disciplines in has much maturing to do, it has
computer science and software engi- much to offer to those practitioners
neering when developing and interested in striking at the heart of
evolving best practices. Of particular security problems. Ensure that your networks operate
relevance are safely and provide critical services even in
the face of attacks. Develop lasting security
• security requirements engineering, 1. G. Hoglund and G. McGraw,
• design for security, software archi- Exploiting Software: How to Break solutions, with this peer-reviewed publication.
tecture, and architectural analysis, Code, Addison-Wesley, 2004.
• security analysis, security testing, 2. J. Viega and G. McGraw, Building Top security professionals in the field share
and use of the Common Criteria, Secure Software, Addison-Wesley, information you can rely on:
• guiding principles for software se- 2001; www.buildingsecure
curity and case studies in design • Wireless Security
and analysis, 3. G. McGraw, “From the Ground • Securing the Enterprise
• auditing software for implementa- Up: The DIMACS Software
• Designing for Security
tion risks, architectural risks, auto- Security Workshop,” IEEE Secu-
mated tools, and technology rity & Privacy, vol. 1, no. 2, 2003, Infrastructure Security
developments (code scanning, pp. 59–66. • Privacy Issues
information flow and so on), and 4. G. McGraw, “Testing for Security • Legal Issues
• common implementation risks During Development: Why We
• Cybercrime
(buffer overflows, race conditions, Should Scrap Penetrate-and-
randomness, authentication sys- Patch,” IEEE Aerospace and Elec- • Digital Rights Management and more!
tems, access control, applied cryp- tronic Systems, vol. 13, no. 4, 1998,
tography, and trust management). pp. 13–15. ■ IEEE SECURITY & PRIVACY 83