- Building Security In Editor Gary Mcgraw Gem Cigital Com Software Security Oftware Security Is The Idea Of Engineering 1 (245.73 KiB) Viewed 75 times
Building Security In operations people dreamed them up. In most corporations and large orga- nizations, security is the domain of the infrastructure people who set up and maintain firewalls, intrusion detection systems, and antivirus engines (all of which are reactive technologies). evolving software is difficult (even if the software is not patched every five minutes). If software were in some sense self-protecting (by being de- signed defensively and more prop- erly tested from a security perspec- tive) or at least less riddled with vulnerabilities, running a secure net- work could become easier and more cost effective. However, these people are opera- tors, not builders. Given the fact that they don't build the software they have to operate, it's no surprise that their approach is to move standard security techniques "down" to the desktop and application levels. The gist of the idea is to protect vulnera- ble things (in this case, software) from attack, but the problem is that vulnerabilities in the software let ma- tend to focus on functionality: Obvi- ously, there are security functions in the world, and most modern soft- ware includes security features, but adding features such as SSL (for cryptographically protecting com- munications) does not present a complete solution to the security problem. Software security is a sys- temn-wide issue that takes into ac- count both security mechanisms (such as access control) and design for security (such as robust design that makes software attacks difficult). Sometimes these overlap, but often they In the short run, we clearly- desperately-must make progress on both fronts. But in the long run, we must figure out ways to build easier- to-defend code. Software security is about helping builders do a better job so that operators end up with an easier job. licious hackers skirt standard security technologies with impunity. If this ...in the software development life cycle were not the case, then the security vulnerability problem would not be expanding the way that it is. Clearly, this emphasizes the need to get builders to do a better job on the software in the first place. Put another way, security is an emergent property of a software sys- tem. A security problem is more likely to arise because of a problem in a standard-issue part of the system (say, the interface to the database module) than in some given security feature. This is an important reason why software security must be part of a full lifecycle approach. Just as you can't test quality into a piece of On the road to making such a funda- mental change, we must first agree that software security is not security software. This is a subtle point often lost on development people who Protecting a network full of Introducing Building Security In This department is about building systems that include properly Past magazine bifurcation of approaches when it comes to software, into appli- cation security and software security 3 attention to the serious problems software practitioners face when it comes to security. Most security researchers agree that we have a pressing problem. In "A Call to Arms: Look Beyond the Horizon,"1 Jeannette Wing includes "software design and security" as one of three critical areas to tackle if security research is to make progress. In "From the Ground Up: The DIMACS Software Security Workshop,"21 introduce the software security problem, discuss trends that demon- strate the problem's growth, and introduce the philosophy of proac- tively attacking the problem at the architectural level. The core of the problem is that building systems to be secure cannot be accomplished by using an operations mindset. Instead, we must revisit all phases of system development and make sure that security engineering is present in each of them. When it comes to software, this means understanding: requirements, architecture, design, coding, testing, validation, measurement, and main- tenance. This is a far cry from code review and black-box testing! Essentially, this department is about security best practices from all phases of the software life cycle. My plan is to coauthor a set of articles with software security practitioners about software security best practices from the real world. You are welcome and encouraged to help! References The good news is that technologists and commercial vendors all acknowledge that the software security problem exists. The bad news is that we have barely begun to instantiate solutions, and many proposed solutions are impotent. Not surprisingly, early commercial solutions to the software security problem tend to take an operational stance-that is, they focus on solving the software security problem through late lifecycle activities such as firewalling (at the application level), penetration testing, and patch man- agement. Because security has tended to be operational in nature (especially in the corporate world where IT security revolves around the proper placement and monitoring of network security apparatus), this operational tack is only natural. This leads to a 1. J. Wing, "A Call to Action: Look Beyond the Horizon," IEEE Security & Pri- vacy, vol. 1, no. 6, 2003, pp. 62-67. 2. G. McGraw, "From the Ground Up: The DIMACS Software Security Work- shop," IEEE Security & Privacy, vol. 1, no. 2, 2003, pp. 59-66. 3. G. McGraw, "Building Secure Software: Better than Protecting Bad Soft- ware (Point/Counterpoint with Greg Hoglund)," IEEE Software, vol. 19, no. 6, 2002, pp. 57-59. www.computer.org/security/ 81 IEEE SECURITY & PRIVACY Authorized licensed use limited to: ULAKBIM UASL-Bahcesehir University. Downloaded on May 29,2021 at 21:52:26 UTC from IEEE Xplore. Restrictions apply.
Building Security In Security requirements Abuse cases. Risk-based security tests Risk analysis Security breaks ket-driven improvement and rapid maturity later this year. As stated earlier, code review is a necessary, but not sufficient, practice for achieving secure software. Security bugs (especially in C and C++) can be deadly, but architectural flaws are just as big a problem. A Test Design Code Field Requirements and use cases Test results plans feedback Figure 1. Software security best practices applied to various software artifacts. Although the artifacts are laid out according to a traditional waterfall model in this illustration, most organizations follow an iterative approach today, which means that best practices will be cycled through more than once as the software evolves. Security testing must encompass two strategies: testing security func- tionality with standard functional testing techniques, and risk-based se- curity testing based on attack patterns and threat models. A good security test plan (with traceability back to re- quirements) uses both strategies. Se- curity problems aren't always appar- ent, even when we probe a system directly, so standard-issue quality as- surance is unlikely to uncover all the pressing security issues. software, you can't spray paint secu- rity features onto a design and expect it to become secure. There's no such thing as a magic crypto fairy dust- we need to focus on software secu- rity from the ground up. Security should be explicitly at the requirements level. Security re- quirements must cover both overt functional security (say, the use of applied cryptography) and emergent characteristics. One great way to cover the emergent security space is to build abuse cases. Similar to use cases, abuse cases describe the sys- tem's behavior under attack; build- ing them requires explicit coverage of what should be protected, from whom, and for how long. As practitioners become aware of software security's importance, they are increasingly adopting and evolv- ing a set of best practices to address the problem. Microsoft has carried out a noteworthy effort under the rubric of its Trustworthy Comput- ing Initiative 5.6 Most approaches in practice today encompass training for developers, testers, and archi- tects, analysis and auditing of soft- ware artifacts, and security engineer- ing. In the fight for better software, treating the disease itself (poorly de- signed and implemented software) is better than taking an aspirin to stop the symptoms. There's no substitute for working software security as deeply into the development process as possible and taking advantage of the engineering lessons software practitioners have learned over the years. At the design and architecture level, a system must be coherent and present a unified security architec- ture that takes into account security principles (such as the principle of least privilege). Designers, architects, and analysts must clearly document assumptions and identify possible at- tacks. At both the specifications- based architecture stage and at the class-hierarchy design stage, risk analysis is a necessity-security ana- lysts should uncover and rank risks so that mitigation can begin. Disre- garding risk analysis at this level will lead to costly problems down the road. External review (outside the de- sign team) is often necessary. Penetration testing is also useful, especially if an architectural risk analysis is specifically driving the tests. The advantage of penetration testing is that it gives a good under- standing of fielded software in its real environment. However, any black-box penetration testing that doesn't take the software architec- ture into account probably won't uncover anything deeply interesting about software risk. Software that falls prey to canned black-box test- ing which simplistic application security testing tools on the market today practice is truly bad. This means that passing a cursory pene- tration test reveals very little about your real security posture, but fail- ing an easy canned penetration test tells you that you're in very deep trouble indeed. Figure 1 specifies one set of best practices and shows how software practitioners can apply them to the various software artifacts produced during software development. In the rest of this section, I'll touch on best. practices. As this department un- folds, we'll cover each of these areas in much greater detail. At the code level, we should focus on implementation flaws, es- pecially those that static analysis tools-tools that scan source code for common vulnerabilities-can dis- cover. Several vendors now address this space, and tools should see mar- Operations people should care- fully monitor fielded systems dur- ing use for security breaks. Simply put, attacks will happen, regardless of the strength of design and imple- mentation, so monitoring software behavior is an excellent defensive technique. Knowledge gained by understanding attacks and exploits should be cycled back into the de- velopment organization, and secu- rity practitioners should explicitly 82 IEEE SECURITY & PRIVACY MARCH/APRIL 2004 Authorized licensed use limited to: ULAKBIM UASL-Bahcesehir University. Downloaded on May 29,2021 at 21:52:26 UTC from IEEE Xplore. Restrictions apply. Risk analysis External review Static analysis (tools) Penetration testing.
Building Security In track both threat models and attack patterns. Note that risks crop up during all stages of the software life cycle, so a constant risk analysis thread, with re- curring risk tracking and monitoring activities, is highly recommended. Much work remains to be done in each of the best practice areas, but some basic practical solutions should be adapted from areas of more ma- ture research. ...as a multidisciplinary effort By and large, software architects, de- velopers, and testers remain blithely unaware of the software security problem. One essential form of best practices involves training software development staff on critical software security issues. The most effective form of training begins with a de- scription of the problem and demon- strates its impact and importance. Be- yond awareness, more advanced software security training should offer coverage of security engineer- ing, design principles and guidelines, implementation risks, design flaws, analysis techniques, software ex- ploits, and security testing. Each best practice called out earlier is a good candidate for in-depth training. his department's goal is to cover many of the best practices sketched out here in much greater detail. You can do two things to help: send feedback to me regarding which best practices you want to see covered first, and volunteer to help develop an article on any individual best practice outlined here. With your help, we can create a decent un- derstanding of software security best practices that can be practically ap- plied and make a big impact on the software security problem. As the trinity of trouble-con- nectedness, complexity, and extensi- bility continues to impact software security in a negative way, we must begin to grapple with the problem in a more reasonable fashion. Integrat- ing a decent set of best practices into the software development life cycle is an excellent way to do this. Al- though software security as a field has much maturing to do, it has much to offer to those practitioners interested in striking at the heart of security problems. Software security can and should borrow from other disciplines in computer science and software engi- neering when developing and evolving best practices. Of particular relevance are References • security requirements engineering, • design for security, software archi- tecture, and architectural analysis, security analysis, security testing, and use of the Common Criteria, • guiding principles for software se- curity and case studies in design and analysis, 1. G. Hoglund and G. McGraw, Exploiting Software: How to Break Code, Addison-Wesley, 2004. 2. J. Viega and G. McGraw, Building Secure Siftware, Addison-Wesley, 2001; www.buildingsecure software.com. 3. G. McGraw, "From the Ground Up: The DIMACS Software Security Workshop," IEEE Secu- rity & Privacy, vol. 1, no. 2, 2003, pp. 59-66. • auditing software for implementa- tion risks, architectural risks, auto- mated tools, and technology developments (code scanning, information flow and so on), and common implementation risks (buffer overflows, race conditions, randomness, authentication sys- ters, access control, applied cryp- tography, and trust management). 4. G. McGraw, "Testing for Security During Development: Why We Should Scrap Penetrate-and- Patch," IEEE Aerospace and Elec- tronic Systems, vol. 13, no. 4, 1998, pp. 13-15. www.computer.org/security/ IEEE SECURITY & PRIVACY 83 Authorized licensed use limited to: ULAKBIM UASL-Bahcesehir University. Downloaded on May 29,2021 at 21:52:26 UTC from IEEE Xplore. Restrictions apply. 5. L. Walsh, "Trustworthy Yet?" Ir for- mation Security Magazine, Feb. 2003; http://infosecuritymag.techtarget. com/2003/feb/cover.shtml. 6. M. Howard and S. Lipner, "Inside the Windows Security Push," IEEE Security & Privacy, vol. 1, no. 1, 2003, pp. 57-61. Gary McGraw is chief technology officer of Cigital. His real-world experience is grounded in years of consulting with major corporations and software pro- ducers. He serves on the technical advi- sory boards of Counterpane, Fortify, and Indigo. He also is coauthor of Exploiting Software (Addison-Wesley, 2004), Build- ing Secure Software (Addison-Wesley, 2001), Java Security John Wiley & Sons, 1996), and four other books. Contact him at [email protected]. REACH HIGHER Advancing in the IEEE Computer Society can ele- vate your standing in the profession. Application to Senior-grade membership recognizes ✓ten years or more of professional expertise Nomination to Fellow-grade membership recognizes ✓exemplary accomplishments in computer engineering GIVE YOUR CAREER A BOOST UPGRADE YOUR MEMBERSHIP computer.org/join/grades.htm