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 [email protected].

--------------------------------------------------------------------------------

***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
([email protected]).

--------------------------------------------------------------------------------

I hope this newsletter has been informative and helpful. Your comments and 
feedback are most welcome. Send me your feedback... ([email protected])

Thanks,

Steve Rakitin
[email protected]

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