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]

“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]

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:

“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 disciplines are directly involved in achieving what is being called “software assurance” as shown below…

[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.

Software security issues started gaining traction soon after the September 11 th 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:

“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:

• “[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 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
• Deployment and Operations
• Incident Management
• Measurement
• Penetration Testing
• Project Management
• Requirements Engineering
• Risk Management
• 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]