Upload
g
View
218
Download
0
Embed Size (px)
Citation preview
April 2002 99
S E C U R I T Y
M ost organizations managecomputer security riskreactively by investing intechnologies designed toprotect against known
system vulnerabilities and monitorintrusions as they occur. However,firewalls, cryptography, and antivirusprotection address the symptoms, notthe root cause, of most security prob-lems. Buying and maintaining a fire-wall, for example, is ineffective if exter-nal users can access remotelyexploitable Internet-enabled applica-tions through it.
Because hackers attack software,improving computer security dependson proactively managing risks associ-ated with software and software devel-opment. The current “penetrate andpatch” approach of fixing broken soft-ware only after it has been compromisedis insufficient to control the problem.
A GROWING PROBLEMAbout 20 new security holes are
reported each week in postings to theBugTraq mailing list (http://online.securityfocus.com/archive/1), and thisnumber is growing. Even “tried andtrue” software is not as safe as oncethought—people continue to exposevulnerabilities that have existed formonths, years, and even decades.
Why are modern computing systemssusceptible to software security prob-lems? Software is not necessarily anyworse than it has ever been, but three
major trends have changed the riskenvironment in which it exists.
ConnectivityGrowing Internet connectivity has
increased the number of attack vectorsas well as the ease of exploiting soft-ware. As people, businesses, and gov-ernments become more dependent onthe network-enabled communicationthat information systems provide, theybecome vulnerable to attacks from dis-tant sources. Malicious hackers nolonger need physical access to a systemto exploit its software.
ExtensibilitySun Microsystems’ popular Java
platform and Microsoft’s new .NETFramework are designed to easilyaccept mobile code updates and exten-sions that let system functionalityevolve incrementally. Operating sys-tems support extensibility throughdynamically loadable device driversand modules; applications such asword processors, e-mail clients, spread-sheets, and Web browsers do so
through scripting, controls, compo-nents, and applets. Preventing softwarevulnerabilities from slipping in as un-wanted extensions is a major chal-lenge. Understanding how a systemmay be extended in the future is essen-tial to getting a handle on system risks.
ComplexityPreventing vulnerabilities from com-
promising an operating system dependson the proper functioning of both thekernel and end-user applications. Themore complex systems and applica-tions become, the harder it is to avoid
bugs. Use of unsafe programming lan-guages such as C and C++ that do notprotect against buffer overflows andother simple kinds of attacks exacer-bates the problem.
The complexity of operating systemshas increased dramatically during thepast decade. For example, Microsoft’sWindows XP has 40 million lines ofcode compared to the 3 million inWindows 3.1. Formally analyzingtoday’s simplest desktop systems toprove that they are secure is impossi-ble, not to mention the enterprise-widesystems that businesses and govern-ments use.
SOFTWARE RISK MANAGEMENTMany software vendors incorrectly
equate security software—often a setof add-on features such as cryptogra-phy—with software security. However,software security is an emergent prop-erty of a complete system, not a feature.After a product has been publicly com-promised, vendors scramble to rush outa patch that ironically serves as anattack map for exploiting unpatched
Managing SoftwareSecurity RisksGary McGraw, Cigital
System designers and developers must take a more proactive role in building secure software.
100 Computer
S e c u r i t y
systems. Because most systems remainunpatched, this is a serious problem.
A better alternative is to incorporatesoftware security as deeply into the soft-ware development process as possible,taking advantage of the engineeringlessons software practitioners havelearned over the years. Finding andremoving bugs in a software systemthrough careful design, implementation,and testing is several orders of magni-tude more cost-effective than trying tofix a problem after a product’s release.
The key to achieving software secu-rity is a risk management approach thatrelies on expert knowledge of bothsecurity problems and the security toolsavailable to combat them. Buildingsecure software is like building a house.Correct use of security-critical systemcalls at the implementation level (suchas string manipulation calls in C andC++) is like using solid bricks insteadof bricks made of sawdust. The kindsof bricks you use are important to theintegrity of your house, but even moreimportant—if you want to keep badthings out—is having four walls and aroof in the design.
Implementation Ferreting known problems out of
software implementations is not acomplete solution, but this is an impor-tant source of security risk thatdeserves attention. Static analysis toolssuch as ITS4 (http://www.cigital.com/its4) and the parser-based SourceScope(http://www.cigital.com/solutions/security.html) can find many suchproblems in source code; runtime solu-tions are also available but not as effec-tive. Rule sets for C, C++, and, to alesser extent, Java are in common usetoday. Research using aspect-orientedprogramming to fix vulnerabilitiesautomatically via syntactic transfor-mation is ongoing.
Seven top implementation-level prob-lems are:
Buffer overflows. A buffer overflowoccurs when too much data is writteninto a fixed-size storage location. Bothheap overflows (in memory) and stackoverflows (on the runtime stack) areproblems, but “stack smashing” hasreceived the most attention. Thisinvolves overflowing a vulnerablebuffer in such a way that overwritinga function return address circumventsprogram control flow.
Buffer overflows have been causingserious security problems for decadesand now account for almost half of all
major security bugs resulting in CERTCoordination Center (http://www.cert.org/) advisories. These attacks occurprimarily because the standard Clibrary has many unsafe string opera-tions and no bounds checks on arrayand pointer references. C and C++ pro-grammers writing security-critical codecan avoid this problem by learningwhich system calls and library func-tions to watch out for and using codescanners.
Race conditions. A race conditionoccurs when an attacker takes advan-tage of assumptions made by a pro-grammer in a multiprocess environ-ment. They crop up in situations inwhich a set of operations that shouldbe atomic (for example, check foraccess; access) happen in serial, and anattacker can interleave an attack.
Race conditions occur only in envi-ronments where multiple threads orother asynchronous processes thatcould potentially interact take placesimultaneously. They are difficult todetect, especially if you’re not lookingfor them—a program that seems towork fine may still harbor them—aswell as to fix. Race conditions willcontinue to be an insidious problem asmultithreading, multiprocessing, anddistributed computing become moreprevalent.
Access control. A system mustdetermine which resources each authen-ticated user can access. Misuse of com-plex access-control systems, especiallyfile systems, is a common source of soft-ware security problems. The access-con-trol mechanisms used in populardistributed computing architectures andmobile code systems, including Corba(common object request broker archi-tecture) and Enterprise JavaBeans, areamong the most complicated.
Randomness. Random numbers areimportant for generating unguessablecryptographic material, among otherthings. Assuming that C’s rand(), a call to a statistically sound pseudo-random number generator, producescryptographic randomness leads toserious problems such as guessable
Resources
The following resources provide additional information on the challengesand benefits of improving software security.
• M. Bishop and M. Dilger, “Checking for Race Conditions in File Access,”Computing Systems, vol. 9, no. 2, 1996, pp. 131-152.
• G. McGraw and E. Felten, Securing Java: Getting Down to Business withMobile Code, John Wiley & Sons, New York, 1999; http://www.securingjava.com/.
• G. McGraw and G. Morrisett, “Attacking Malicious Code: A Report tothe Infosec Research Council,” IEEE Software, July/Aug., 2000, pp. 33-41.
• J. Viega and G. McGraw, Building Secure Software: How to Avoid Secu-rity Problems the Right Way, Addison-Wesley, Reading, Mass., 2001;http://www.buildingsecuresoftware.com.
• D. Wagner et al., “A First Step Towards Automated Detection of BufferOverrun Vulnerabilities,” Proc. 7th Network and Distributed SystemSecurity Symp. (NDSS 00), Internet Society, Reston, Va., 2000, pp. 3-17.
April 2002 101
nologies for automated analysis ofsoftware security at the architecturallevel lag significantly behind imple-mentation tools. Architectural riskanalysis thus remains a high-expertisepractice. Hiring an expert is the bestway to counter design problems.
Following a set of general principlesfor developing secure software systemscan help those new to security avoidsome common pitfalls. In BuildingSecure Software: How to Avoid SecurityProblems the Right Way (Addison-Wesley, Reading, Mass., 2001; http://www.buildingsecuresoftware.com/),John Viega and I present 10 design-levelguidelines:
• Secure the weakest link.• Practice defense in depth.• Fail securely.• Follow the principle of least priv-
ilege.• Compartmentalize.• Keep it simple.• Promote privacy.• Remember that hiding secrets is
hard.• Be reluctant to trust.• Use your community resources.
A mature software risk managementapproach involves applying these prin-ciples intelligently and making subtletradeoffs.
T he root of most security problemsis software that fails in unex-pected ways when under attack.
Good security practices can help ensurethat software behaves properly. Safety-critical and high-assurance systemdesigners have always taken great painsto analyze and track software behav-ior, and security-critical system design-ers must follow suit. The most pressingcurrent need is a better understandingof architectural-level risks and flaws. �
Gary McGraw is the Chief TechnologyOfficer at Cigital, a software risk man-agement company based in Dulles, Vir-ginia. Contact him at [email protected].
crypto. Programmers must carefullyconsider sources of randomness andrely on measuring a physical propertysuch as a chip’s heat signature.Physical devices for randomness existbut are not in common use.
Cryptography. One sweeping recom-mendation applies to every use of cryp-tography, which is a complex field bestleft to experts: Never “roll your own”cryptography! Simple and commonimplementation errors render cryptouseless. If possible, use a crypto libraryapproved by a real cryptographer.Other common mistakes include failingto apply cryptography when it’s calledfor and incorrectly applying it when youhave properly identified a need.
Input validation. Software architectsand developers tend to make poorassumptions about who and what istrustworthy, just as most people do.Sound security practice dictates extend-ing trust only out of necessity.
Passwords. Like many security tech-nologies, passwords are conceptuallysimple and elegant, but areas of vul-nerability remain, particularly withrespect to storage and user authenti-cation. Systems designers and devel-opers should learn about passwordsystems and pitfalls discovered overthe years before implementing a pass-word system.
ArchitectureCarefully crafting and analyzing
software design to counter security riskis the most important and least under-stood undertaking when buildingsecure software. Unfortunately, nogood standard language for describingand manipulating software design cur-rently exists. Lacking the ability tospecify an application formally, tech-
The root of most security problems
is software that fails in unexpected ways when under attack.
MOBILE AND UBIQUITOUS SYSTEMS
NEW FOR 2002, the IEEE Computer andCommunications Soci-eties present
IEEEPervasiveComputingThis new quarterly magazine aims
to advance pervasive computing by
bringing together its various
disciplines, including
• hardware technology
• software infrastructure
• real-world sensing and
interaction
• human-computer interaction
• systems considerations such as
scalability, security, and privacy.
Led by Editor in Chief
M. Satyanarayanan, the founding
editorial board features leading
experts from UC Berkeley,
Stanford, Sun Microsystems,
and Intel.
Don’t miss the
premier issue —
subscribe now!
http://computer.org/pervasive