The Life Cycle of an Attack

Viruses and worms have been around for many years and over time have taken advantage of numerous vulnerabilities in both operating system and application code. Initially, new worms and viruses would show up every few weeks. Over time, this became every few days. Today, new viruses, worms, and variants of existing ones appear every few hours.

Today s programming languages have made it increasingly easy to make minor modifications to existing virus code so that the variant is at least as destructive as the original. Most importantly, the code is modified such that existing virus definitions or signatures no longer match. Because the signature no longer matches the malicious code, the security mechanism utilizing the signature definition is not an effective defense without an update that includes the new signature to match the altered pattern within the malicious code. To take this concept one step further, virus developers today write destructive code that is distributed across the Internet bundled with a developer s kit of sorts, so any individual with malicious intent and the capability to run a command-line executable (complete with built-in help files) can create his own undefined variant in just a few seconds. Armed with this knowledge, you may ask yourself, "How do I efficiently and effectively defend against constantly mutating code in time to protect my environment?"

To address this concern, CSA differs from older technologies. CSA does not care what the virus or worm looks like or how the binary 1s and 0s line themselves up to create a damaging payload. CSA is more focused on the behavior of an application and defining whether the behavior is "good" or "bad" to decide whether the action attempting to occur should be allowed or denied. CSA s internal mechanisms and implementation of the centrally defined rule set decide what is considered good and bad behavior. An example of a behavioral decision could be that a command shell such as cmd.exe is a normal "good" behavior that is allowed on an agent-protected system as long as the command shell is started by a user and not by a process launched by downloaded content.

Looking back over the history of malicious code, a pattern begins to form: All malicious code performs the same root actions. Not all viruses follow the same steps in exactly the same order, but they do attempt to use the following processes to be defined as successful penetrations:

• Probe Locate other systems via any method such as ping, traceroute, e-mail, port scans, and so on.

• Penetrate Gain access to the previously located or randomly selected systems through mechanisms such as e-mail attachments, downloaded content from web pages, buffer overflows, or even back doors such as the Windows hidden shares (ADMIN$, C$, and so on).

• Persist Methods by which the virus/worm will continue to be present on the infected system after deletion or reboot such as insertion into registry Run keys, initialization files, or service installation.

• Propagate Move from system to system using transports such as e-mail, Trojan horse-infected files, and other vulnerable network services.

• Paralyze Destroy files or entire file systems using various corruption, deletion, or formatting procedures. Other possibilities include simply crashing the system continuously so that it is unusable or tying up CPU cycles to make the system unresponsive to user-desired functions.

You can see that because all viruses and worms behave the same, it can be a more successful strategy to monitor and analyze the behavior of an attack rather than attempting to match it to a signature, which may not yet exist. CSA identifies the code as malicious by its inappropriate interaction with the host system and therefore can prevent previously unknown day-zero attacks.