Software Security


Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Software Security

  1. 1. Building Security In Editor: Gary McGraw, Software Security S 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 80 PUBLISHED BY THE IEEE COMPUTER SOCIETY ■ 1540-7993/04/$20.00 © 2004 IEEE ■ IEEE SECURITY & PRIVACY
  2. 2. 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
  3. 3. 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 breaks 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 82 IEEE SECURITY & PRIVACY ■ MARCH/APRIL 2004
  4. 4. 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 multidisciplinary 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- DON’T offer coverage of security engineer- ing, design principles and guidelines, bility—continues to impact software security in a negative way, we must RUN RUN implementation risks, design flaws, analysis techniques, software ex- begin to grapple with the problem in a more reasonable fashion. Integrat- THE RISK. THE RISK. 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 References 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