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