Stuxnet-Hysteria Aside, What Are the Enterprise Implications?
by Eirik Iverson, Product Management
Set aside the IT magazines’ doom and gloom about Stuxnet. Its a threat because it combines multiple exploit attack codes into a lethal cocktail. Neither one of these attack binaries is particularly unusual. Adapting to this threat can be simple. But sticking with the typical enterprise security posture as-is, makes organizations an easy target.
The highly publicized and vaunted Stuxnet attack on Iranian nuclear infrastructure computers consisted of four exploits in a single package. Most consumer and even targeted enterprise attacks only use one. Some use two attack exploits. More on that later. Attacks with one or two exploits are typically quite sufficient for cyber criminals because the vast majority of consumer and enterprise computers are protected by software and/or network appliances that rely on virus signatures and heuristics. These technologies limit protection to stopping malware that has been seen before by anti-virus vendors.
Cyber criminals employ easy to use software called ‘malware kits’ that alter the appearance of attack code. The result is unsettling. Against malware samples a week or less old, Cyveillance measured an average detection rate of just 19% for AV products. AV-Comparatives conducted a similar test that also included heuristics, which have similar limitations. They reported a rate of 44%. Both used actual samples found in the wild, meaning something must have detected them. Secunia took a different approach using unique malware samples that it created, resulting in a detection rate of under 10%. This has caused a shift towards post-infection detection, making those AV full scans that typically run at night increasingly too important to ignore. So, keep those PCs on at night! This alone won’t solve the problem. There are more and more polymorphic malware code available for sale on the black market. This stuff changes itself periodically to avoid post-infection detection.
Check out more endpoint security articles here.
Do you know what percentage of your reported AV detections are from full scans versus real-time detections? How long were these full scan detected infections running? What is the average, highest, and lowest number of days between full scans for your computer population? How often do you scan a statistically significant sample of your computers with a boot AV product to test your security posture? These questions and others were very important long before Stuxnet was reported. However, Stuxnet means that infections can be a lot more lethal.
Stuxnet and the ensuing copy cats are lethal because they include at least a second attack code binary that exploits a privilege escalation vulnerability. These vulnerabilities don’t always get a high priority in patch management because many don’t consider them a major risk alone. But combined, they enable the attackers to dig deeper into a targeted PC, rooting malware such that no host-based software can detect it (i.e., 3rd generation rootkit). Stuxnet included not one but two privilege escalation exploits in its cocktail so they could systematically compromise any computer.
Stuxnet featured another aspect that is relevant to enterprises in many but not all industries. It sought to hijack control software made by Siemens, presumably to damage costly nuclear infrastructure run by Iran. This was probably accomplished this via inter-process code injections into the control software from malware running in the same PC. This does NOT require that there be a vulnerability (i.e., programming mistake) in the control software; Windows APIs facilitate this routinely. Very few security products effectively block these inter-process code injections either because they cannot or they are too disruptive and complex. Inter-process code injection attacks effectively transform an application into something else, or selectively alter its behavior. The latter requires sophisticated analysis of the targeted application’s idiosyncrasies and is uncommon but increasingly affordable in the cyber crime world. Stuxnet-like threats are particularly relevant to energy/utility industries, which can suffer serious damage to their infrastructure. Healthcare and manufacturing face similar risks. In addition the already widespread online banking fraud per Banking Trojans, Stuxnet-like malware can readily compromise enterprise financial systems.
The Enterprise Needs Another Layer of Protection in its Security Posture
There are a variety of products from many vendors that might stop Stuxnet attacks. Forget about host intrusion prevention system (HIPS) standalone products or HIPS features included in an endpoint security software suite. Deployed HIPS features/products are either disabled completely or severely under-utilized because they are too complex and disruptive. The much hyped Aurora attacks on three dozen large enterprises in early 2010 reportedly included Symantec according to the Washington Post. If Symantec isn’t using its HIPS capabilities to effectively stop attacks, then forget HIPS. Many folk have, including Cisco, which end-of-lifed its HIPS product.
Application whitelisting products show greater promise than HIPS products. Still, there are some points that IT personnel should consider. First, what is the level of effort required to enumerate all of the things on a PC that may launch (i.e., run)? Commercial whitelists help administrators with the daunting task of enumerating what we call pre-launch controls. Even so, creating and maintaining whitelists for the system-space (i.e., Windows and Program Files directories) is far from a trivial effort. Seek explicit level of effort quotes from organizations that have done this. Second, look for application whitelisting products with post-launch controls. As mentioned earlier, applications can be hijacked and coerced to do harm. We cannot trust our software applications! A few application whitelisting products provide what some call ‘write protection’. This means that the files that make up the whitelisted applications cannot be altered. Further narrow your search by choosing from these few that not only ‘write protect’ whitelisted ’stuff” but also prevent the addition of unknown files/code into system-space. Third, choose a product whereby both its pre-launch and post-launch application controls are enforced by kernel-level mechanisms. Fourth, your choice must include post-launch controls that block malicious inter-process code injections as well as block modifications to critical system resources such as the master boot record (MBR).
A point worth repeating: the level of effort to deploy and maintain is extremely important. In deploying an application whitelisting and control product, one is NOT replacing existing security assets (e.g., anti-virus/spyware, firewall, intrusion detection/prevention, patch management, endpoint security policy enforcement, data loss prevention, information asset inventory systems, next-generation firewall, etc.) but adding an additional layer.
Why AppGuard Enterprise is Probably the Easiest and Most Effective Application Whitelisting and Control Solution
The default AppGuard Enterprise policy blocks a Stuxnet-like attack.
Over 90% of the effort required to maintain application whitelists (i.e., pre-launch controls) involves enumerating what may run in system-space. AppGuard Enterprise radically diminishes the importance of doing this for system-space because of its extensive post-launch application controls. Administrators still must define whitelists for user-space (i.e., where least privilege users/processes can write). Such lists are 1000s of times smaller than system-space whitelists, typically just a few items per policy group. Next, administrators need to view the results from a process audit that identifies applications in use that are not subject to AppGuard post-launch controls. These prevent an application and any executable/process it spawns from harming the PC. They also can prevent an application from stealing sensitive documents in user folders designated private. So, assume the audit identifies a half-dozen applications in use that are not ‘guarded’. Adding these to the ‘guard list’ merely requires their full path name. However, not all of these applications even need to be guarded, though you can. Essentially, one only needs to guard at-risk applications such as web browsers, email, popular productivity software (e.g., MS Office), media players, instant messengers. But most of these are already on the ‘guard list’ by default. Defining the pre-launch and post-launch controls for a policy group can literally take just a few minutes. And, this combination of pre-launch and post-launch controls yields more robust protection from malware and other data loss risks.
In just one phone call, we can define a highly effective protection policy for an organization as a managed service or just a free trial before doing it yourself.