The Importance of Checking Software Risk and Software Quality: A Wake-Up Call to Firms Across the Globe

If you’ve read the news lately, you’ve seen headline after headline (some, even on our blog) about computer glitches, technical failures, software risk, and hacks.  The health of applications is now under more microscopic attention than ever before – because no matter whether internal or external causes prompt a software outage, the security and stability of your applications are paramount.

Seeking Independence from Being Hacked

While it was far from being the “shot heard ‘round the world” of Revolutionary War fame, the cyber attack on the Pacific Northwest National Laboratory over July 4th weekend this year did represent a significant first blow in the search for liberty for that organization – specifically, liberty from being hacked.
As reported in InformationWeek, PNNL, a Richland, WA-based R&D lab under contract to the Department of Energy:
“discovered what it described as a ‘sophisticated’ targeted attack on its systems the Friday before the holiday, compelling the organization to temporarily shut down most of its internal network services, including email, SharePoint, its wireless LAN, voicemail, and Internet access. PNNL also blocked internal traffic while investigating and mitigating the attack. The lab says no classified or sensitive information was accessed in the attack.”
In the weeks following the attack, PNNL revealed that the attack had been a two-pronged cyber-assault on its systems. The perpetrators first “exploited an undisclosed bug in the server, and then rigged it with a malicious payload that planted an Adobe Flash zero-day exploit on victims’ machines.”
The attack was one of literally hundreds perpetrated upon government agencies and their contractors this year. It came only days before the Department of Defense revealed one of its private contractors had been the victim of the largest cyber theft of sensitive files – 24,000 – in the government’s history.
The issue for the government remains, how does it defend itself from these attacks and proclaim its independence from hackers?
We Hold These Truths Self-Evident
Former Fed CIO Vivek Kundra identified at least part of the problem with the government’s cyber-security plans prior to his stepping down in August. He said the problem was not lacking for potential solutions, but rather lacking in the implementation of them. He even went so far as to charge his successor with less planning for IT and more focus on its execution. Of this he said,
“My advice would be to be aware of entropy and make sure that you’re really, really focused on execution, not just on policies. You need to roll up your sleeves and get some work done.”
By his own admission, US government IT under Kundra had serious shortcomings in bringing projects to fruition, including data center consolidation, cloud computing and continuous security monitoring.
The GAO went one step further in its investigation into the government’s preparedness for cyber attacks and openly questioned the DoD’s ability to keep up with the threats of cyberspace. Among the chief issues identified by the GAO were the multiple and often contradictory government publications that discuss how to handle cyber threats. These documents cannot even come to a consensus regarding terminology and job responsibilities.
Our Lives, Our Fortunes, and Our Sacred Honor
That the cyber attack on the PNNL labs revealed yet another software vulnerability is not insignificant, nor is it lost on the government, fortunately. The action plan the Department of Homeland Security unveiled in July is among the first to acknowledge that internal IT systems and not just external relationships are one of the keys to cyber defense.
The DHS recognizes the fact that any cyber security policy needs to include automated structural analysis of application software. By identifying areas where the applications in use may not live up to optimal software quality standards, the government can work toward plugging the holes and give cyber infiltration efforts fewer points to breach.
Software is just one small part of the plan. The lion’s share looks toward diplomatic and external measures as well as procedural items. Nevertheless, if the software being used by the government lacks in terms of structural quality, hackers – independent or supported by foreign governments – will find a way to exploit it. By identifying those holes in the software, though, it gives the government the chance to identify potential breach points and close vulnerabilities that serve as entry points to future hackers.
So while the Department of Defense–and its contractors, such as PNNL–may not yet be prepared to withstand a cyber attack, by beginning to address the structural quality of their application software they may indeed begin to declare their independence from hackers.

To be Forewarned is to be Forearmed

Let me start by saying that RSA is a name I generally equate with security of enterprise systems. That belief made it even more surprising a few weeks ago when I read that the security giant had been the victim of a cyber attack.
In an open letter on the RSA web site, RSA Executive Chairman Art Coviello reported that, “Recently, our security systems identified an extremely sophisticated cyber attack in progress being mounted against RSA.” He went on to explain that the attack has been classified as an Advanced Persistent Threat (APT) and that it “resulted in certain information being extracted from RSA’s systems.”
A short time later, Uri Rivner, Head of New Technologies, Consumer Identity Protection, at RSA, the Security Division of EMC, discussed details of the attack on RSA’s official security blog site, Speaking of Security. Rivner revealed that the attack began as a phishing email sent to employees of the company that included an Excel spreadsheet. He said, “The spreadsheet contained a zero-day exploit that installs a backdoor through an Adobe Flash vulnerability (CVE-2011-0609).”
Rivner is quick to add a side note that Adobe did release a patch for the exploit so it could no longer be breached. He also goes into vivid detail about how the attack unfolded, reporting:
The spreadsheet contained a zero-day exploit that installs a backdoor through Adobe Flash vulnerability (CVE-2011-0609). Adobe has already released an emergency patch for the zero-day. The exploit injects malicious code into the employee’s PC, allowing full access into the machine. The attacker in this case installed a customized remote administration tool known as Poison Ivy RAT variant; if you are familiar with APTs you will recognize Poison Ivy as it has been used extensively in many other attacks, including GhostNet.
Analyzing the Attack
Fortunately for RSA, they are very security savvy – it’s their business to be – and were able to detect the attack relatively quickly and act upon it, which minimized its impact. However, Rivner notes that in the 18 months before the attack on RSA, there were numerous other instances where “attackers had months to do digital “shoulder surfing” on the attacked users, map the network and the resources, and start looking for a path to the coveted assets they desired.”
In pinning down the reason this attack succeeded, Rivner says the key was the human factor. Had the employees within the organization not opened the Excel spreadsheet, the malware would not have found its way into the system and the breach would not have occurred.
There is a great deal of truth to that. The human factor is a definite weak link in the security chain of all companies. Particularly when it comes to attacks in the forms of Trojan Horses, Phishing scams, et al, there needs to be human involvement for them to get a foothold within the network.
But there’s a deeper issue here that I think Rivner glosses over in his assessment of the attack and that is the “zero-day vulnerability” that existed in the Adobe software and gave the injected malware a breach point.
Lock it Down
When it comes to the structural quality of application software, I often defer to an analogy of the way a house is built. The first step is to ensure the foundations is solid, free of cracks and infiltration points, then a sturdy frame is constructed on top of it with the outer layer of the house build around and on top of it.
To ensure optimal quality for application software, equal attention to sound foundations and frames is needed. In deference to current demands to produce executable applications quickly, new software is frequently built on top of old software. Herein lies a problem, though, as often developers either do a cursory manual check of the quality of that software or simply take for granted that the existing code was structurally solid. Unfortunately, cyber thieves are smarter today than when the foundation software was built – even if that was just 18 months ago – so there may be holes in the original software that can be exploited now that would not have been exploited when the code was originally written.
Similar attention is needed when it comes to the software built atop the frame and foundation. The walls need to be sturdy and any possible weak points need to be locked down to prevent entry; that is the real first line of defense for the structure. In an enterprise setting there are many simple, housekeeping rules for writing code that’s not vulnerable to attack. But most developers are either unaware of these rules, or they are only responsible for a piece of the input validation.  If points of vulnerability within the structure are not addressed during the build process, even the best security system – whether for a house or software – will only tell you when someone or something has breached your structure; it won’t keep them out.
Don’t Give Intruders a Point to Exploit!
Automated software analysis provides the means to see the whole application, and go beyond one developer’s view of something like input validation that lets a hacker in, or any business transaction that might fail on its own.  Automated measurement of that analysis provides management the means to track, incentivize and ensure that security, stability and efficiency traps are not introduced either inadvertently or maliciously into the enterprise software. In this way, if you can see the potential threat, you can eliminate it before it becomes a future security problem.
With all due respect to RSA, top-of-the-line security systems are all well and good for identifying when an attack is occurring, but the ultimate baseline for security should be assessing the structural quality of the application software before it is deployed to find and then fix potential breach points.
You have been “forewarned.”