Food for Thought—An e-newsletter published by Software Quality Consulting, Inc. April 2006, Vol. 3 No. 4 Exploitable Software To view a web version of this newsletter, click on the following link: http://www.swqual.com/newsletter/vol3/no4/vol3no4.html. -------------------------------------------------------------------------------- Welcome to Food for Thought(TM), an e-newsletter from Software Quality Consulting (http://www.swqual.com/index.html?Intro). I've created free subscriptions for my valued business contacts. If you find this newsletter informative, I encourage you to continue reading. Feel free to pass this newsletter along to colleagues by clicking this Forward Email link (http://ui.constantcontact.com/roving/sa/fp.jsp?plat=i&p=f&m=sctz69n6). If you’ve received this newsletter from a colleague and would like to subscribe, please click this Enter New Subscription link (http://www.swqual.com/newsletter/Subscribe.htm?Newsletter). If you don't wish to receive this newsletter, click the SafeUnSubscribe(TM) link at the bottom of this newsletter, and you won’t be bothered again. Your continued feedback on this newsletter is most welcome. Please send your comments and suggestions to info@swqual.com. -------------------------------------------------------------------------------- ***In This Issue*** In This Months’ Topic, I discuss software security... Regular features to look for each month are: - Monthly Morsels Hints, tips, techniques and reference info related to this month’s topic - Calendar Conferences, workshops, and meetings of interest to software engineers, QA engineers and anyone interested in software development -------------------------------------------------------------------------------- ***This Month’s Topic*** EXPLOITABLE SOFTWARE: NEW SECURITY CONCERNS IN A POST-9/11 WORLD “The wonderful thing about the Internet is that everything is connected. The horrible thing about the Internet is that everything is connected.” Vinton Cerf, co-inventor of TCP/IP Last summer the Washington Post (and later Time magazine) reported on an incident that generated much interest within the US Government... “Web sites in China are being used heavily to target computer networks in the [ US] Defense Department and other US agencies, successfully breaching hundreds of unclassified networks, according to several U.S. officials. Classified systems have not been compromised, the officials added. But US authorities remain concerned because, as one official said, even seemingly innocuous information, when pulled together from various sources, can yield useful intelligence to an adversary.” [2] Dubbed “Titan Rain”, this is but one of thousands of attacks against networks in the US and UK. In 2004, the US Dept of Defense (DoD) reported that there were over 79,000 attempts to breach its various computer networks. Of those, approximately 1,300 were successful. [2] //// Read the //// Time Magazine article about //// Titan Rain... //// (http://www.time.com/time/nation/article/0,8599,1098371,00.html) “Probes as a prelude to attacks are continually increasing. Systems in large organizations such as DoD and Microsoft are probed several hundred thousand times per month. Actual attacks are increasing as well. Many attackers exploit already identified vulnerabilities – often as soon as they can compare the old versions to fixed (patched) versions of the software and analyze what changed. They can then attack any non-patched copies of the software. The time between the announcement of vulnerability and attempted exploits of the vulnerability has diminished from months to a few days, if even that long. Some vulnerabilities are even exploited as ‘zero-day,’ meaning that the exploit appears before the vulnerability is formally disclosed.” [1] //// Read the Washington //// Post article //// about //// Titan Rain... //// (http://www.washingtonpost.com/wp-dyn/content/article/2005/08/24/AR2005082402318_pf.html) The US government has been concerned about “exploitable software” for some time. The US Dept of Homeland Security (DHS) has undertaken an ambitious project to address this issue. A January 2006 report from DHS titled Secure Software Assurance Common Body of Knowledge states that: (https://buildsecurityin.us-cert.gov/bsi/docs/Secure%20Software%20Assurance%20CBK%20DRAFT%20v09%20010906.pdf) //// For more real stories of actual attacks - check //// out the US Dept //// of Justice //// webpage. //// (http://www.cybercrime.gov/ccdocs.htm) “Software Assurance has become critical because dramatic increases in business and mission risks are now known to be attributable to exploitable software...” [1] The implications of this report are far-reaching. DHS is currently working with standards groups, such as IEEE, to incorporate security requirements and “software assurance” best practices into software engineering standards. //// Many networks may be vulnerable... //// “Researcher //// Michael Lynn quit //// his job at Internet Security Systems last [August], //// then defied ISS //// and Cisco by revealing that unpatched Cisco routers can //// be hacked by a buffer-overflow exploit. Until then, corporate network //// managers were largely unaware //// of the risk.” [6] //// Read more... //// (http://www.networkworld.com/news/2005/080105-blackhat.html) Many disciplines are directly involved in achieving what is being called “software assurance” as shown below (see web version at http://www.swqual.com/newsletter/vol3/no4/vol3no4.html)[1] Currently the view within the security community is that is it very difficult to “add” security to exploitable software. Rather, the preferred approach is to identify security requirements and apply “secure software best practices” (discussed below) throughout the software development lifecycle. “Security is not just a question of security functionality; the properties desired must be shown to hold wherever required throughout the system – e.g. the security functionality cannot be bypassed anywhere. Because security properties are emergent systems properties, security is an omnipresent issue throughout the software lifecycle.” [1] The diagram [7] below illustrates this approach (see web version at http://www.swqual.com/newsletter/vol3/no4/vol3no4.html). //// The need to build secure software //// has led to a new vocabulary that //// is quickly //// becoming part of the vernacular. Understanding //// these terms is an important first //// step in educating yourself about //// this critical topic. //// (http://www.swqual.com/newsletter/vol3/no4/vocabulary.pdf) Software security issues started gaining traction soon after the September 11th attacks. And while most technologists agree that there are many significant security issues to address, there is still some disagreement on the best approaches for addressing these issues: //// Point //// Counter-point //// Discussion //// on building secure software vs. patching existing software //// (http://www.cigital.com/papers/download/appsec-vs-ss.pdf) “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 management. 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 bifurcation of approaches when it comes to software, into application security and software security. 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 maintenance. This is a far cry from code review and black-box testing!” [7] One school of thought says that building software to be secure from the ground up rather than applying security patches to fielded software is a better solution because: //// “Many security incidents are the result of exploits against defects in the //// design or code of software. The approach most commonly employed to address //// such defects is to //// attempt to retroactively bolt //// on devices that make it more difficult for those defects to be exploited. //// This is not a //// solution that gets //// to the root cause //// of the problem //// and threat.” [13] - “[Most] software operates in a hostile networked environment. - Extensible systems such as Java virtual machines and .NET common runtime environments (not to mention dynamically loaded libraries) are becoming common and introduce mobile code risks. - System complexity is rising.” [8] But what to do about all the fielded software? Are band-aid fixes worth the effort? One security expert’s opinion is: “Band-aids do not fix the disease, they protect the wound. They are designed to ‘detect the bad,’ but they do nothing to stop the threat of an unknown attack.” [9] Most software companies are focused on quarterly results and most software engineers are not aware of secure software best practices. The result is that we should expect the number of attacks to increase and an increasing number of these attacks will prove to be successful... SECURE SOFTWARE BEST PRACTICES... One of the objectives of the draft DHS report mentioned above is to build a Secure Software Assurance Body of Knowledge. Part of the Body of Knowledge includes Best Practices. The DHS website Build Security In (https://buildsecurityin.us-cert.gov/portal/index.html) lists a few areas where best practices have been identified. This is a work in progress since we are in a reactive mode and it will take some time before we can get ahead of the “bad guys,” if that’s even possible... Content areas where work is actively being done to develop and disseminate examples of secure software best practices include: - Architectural Risk Analysis - Assembly, Integration & Evolution - Code Analysis (http://www.cigital.com/papers/download/bsi5-static.pdf) - Deployment and Operations - Incident Management - Measurement - Penetration Testing (http://www.cigital.com/papers/download/bsi6-pentest.pdf) - Project Management - Requirements Engineering - Risk Management (http://www.cigital.com/papers/download/bsi3-risk.pdf) - Security Testing - Threat Modeling - Training & Awareness - White Box Testing These areas where secure software best practices are being developed represent the view that secure software is best developed using a proactive approach rather than relying on being reactive. But it will take more than best practices to truly address this problem. We need to change how we think about security... “Learning how to think about security means adopting a different mindset than we’ve had in the past. As a community, software developers have been thinking too much like ‘good guys’ and thus ended up developing insecure software because they failed to predict attack scenarios. The only way to effectively develop good security in software is to learn to think like the ‘bad guys.’ Thinking like the adversary helps us to better identify and mitigate threats.” [10] This is a new and emerging field - the IEEE publication Security & Privacy just began publication in 2003. There is much to learn here and everyone in the software community needs to be aware of the potential for harm... SUMMARY Since society has come to rely on software to such a significant extent, exploitable software has the potential to affect everyone. Every day new brings new cases of identity theft and stolen personal financial information. Many companies have suffered loss of confidential or proprietary information through exploitable software and lax policies. Operating systems and anti-virus software are constantly being updated to reflect new and devious attempts to access information on personal computers. As developers and testers, we have a responsibility to take reasonable steps to ensure that, to the extent possible, software we develop is as secure as possible. Every application accessible through the Internet has the potential to offer the “bad guys” yet another opportunity for exploitation... “Dependency on information technology makes software assurance a key element of national security and homeland security. Software vulnerabilities jeopardize intellectual property, consumer trust, business operations and services, and a broad spectrum of critical infrastructure, including everything from process control systems to commercial application products. Software enables and controls the nation’s critical infrastructure, and in order to ensure the integrity of key assets within that infrastructure, the software must be reliable and secure. However, informed consumers have growing concerns about the scarcity of practitioners with requisite competencies to build secure software. They have concerns with suppliers’ capabilities to build and deliver secure software with requisite levels of integrity and to exercise a minimum level of responsible practice. Because software development offers opportunities to insert malicious code and to unintentionally design and build exploitable software, security-enhanced processes and practices – and the skilled people to perform them – are required to build trust into software.” [1] ‘Till next time... //// “Driven by awareness of //// the rampant //// worldwide //// explosion in exploitation of software vulnerabilities, demand is //// growing for low-defect, secure software, in both //// the defense and commercial sectors.” [1] //// “Current, commonplace software specification, design, implementation, //// and testing practices provide users with //// software //// containing numerous defects and security vulnerabilities.” [1] -------------------------------------------------------------------------------- ***Monthly Morsels*** Every month in this space you’ll find additional information related to this month’s topic. - References: [1] Samuel T. Redwine, Jr. (Editor). Secure Software Assurance: A Guide to the Common Body of Knowledge to Produce, Acquire, and Sustain Secure Software, version 0.9 (Draft). US Department of Homeland Security, January 9, 2006 [2] Bradley Graham “ Hackers Attack Via Chinese Web Sites - U.S. Agencies' Networks Are Among Targets”, Washington Post, August 25, 2005; A01 [3] Sean Barnum and Gary McGraw, “ Knowledge for Software Security”, IEEE Security & Privacy, March/April 2005, p. 74-78. [4] Brad Arkin, Scott Stender, and Gary McGraw, “Software Penetration Testing”, IEEE Security & Privacy, Jan/Feb 2005, p. 84-87. [5] Gary McGraw and Douglas Verdon, “Risk Analysis in Software Design”, IEEE Security & Privacy, May/June 2004, p. 32-37. [6] Ellen Messmer and Phil Hochmuth, “ Router flaw sparks battle”, Network World, 08/01/05 [7] Gary McGraw, “ Software Security”, IEEE Security & Privacy, March/April 2004, p. 80-83. [8] Gary McGraw, “ Building Secure Software: Better Than Protecting Bad Software”, IEEE Software, November/December 2002, p. 29-31. [9] Greg Hogland, “ Security Band-Aids: More Cost-Effective than Secure Coding”, IEEE Software, November/December 2002, p. 28-30. [10] James A. Whittaker and Richard Ford “ How to Think About Security”, IEEE Security & Privacy, March/April 2006, p. 68-71. [11] Dan Sullivan,The Definitive Guide to Information Theft Preventione-book, Nexus Realtime Publishers. (http://nexus.realtimepublishers.com/DGITP.htm) [12] Gary McGraw, et. al., “ Misuse and Abuse Cases: Getting Past the Positive”, IEEE Software, May/June 2004, p. 32-34. [13] CERT Coordination Center (http://www.cert.org/) [14] Richard C. Linger, et. al., “ Life-Cycle Models for Survivable Systems” Software Engineering Institute, CMU/SEI-2002-TR-026, October 2002. - Books Hoglund, Greg, and Gary McGraw. Exploiting Software: How to break code, Addison-Wesley, 2004. Anderson , Ross J., Security Engineering: A Guide to Building Dependable Distributed Systems, John Wiley and Sons, 2001. - On line Resources CERT Coordination Center (http://www.cert.org/) Cigital White Papers on Security (http://www.cigital.com/resources/gem/) ACM Risk Digest (http://catless.ncl.ac.uk/Risks) IEEE Computer Security & Privacy Technical Journal (http://www.computer.org/portal/site/security/) -------------------------------------------------------------------------------- ***Calendar*** Every month you’ll find news here about local and national events that are of interest to the software community ... - A panel discussion on Offshore Outsourcing sponsored by the Boston SPIN and the Software Quality Group of New England (SQGNE) will be held on Tuesday May 16th. Find out more... (http://www.swqual.com/links/upcoming.html) - Software Quality Calendar There are many organizations that sponsor monthly meetings, workshops, and conferences of interest to software professionals. Find out what’s happening... (http://www.swqual.com/links/upcoming.html) - Workshops Offered by Software Quality Consulting Software Quality Consulting offers workshops in many topics related to software process improvement. Get more info... (http://www.swqual.com/seminars/courses.html) -------------------------------------------------------------------------------- ***About SQC*** Software Quality Consulting provides consulting, training, and auditing services tailored to meet the specific needs of clients. We help clients fine-tune their software development processes and improve the quality of their software products. The overall goal is to help clients achieve Predictable Software Development(TM) – so that organizations can consistently deliver quality software with promised features in the promised timeframe. To learn more about how we can help your organization, visit our web site (http://www.swqual.com/index.html?AboutSQC) or send us an email (info@swqual.com). -------------------------------------------------------------------------------- I hope this newsletter has been informative and helpful. Your comments and feedback are most welcome. Send me your feedback... (info@swqual.com) Thanks, Steve Rakitin info@swqual.com Food for Thought, Predictable Software Development, Act Like a Customer, and ALAC are trademarks of Software Quality Consulting, Inc. Copyright 2006. Software Quality Consulting, Inc. All rights reserved. Graphic design by Sage Studio