Like a firewall, StormWatch monitors a set of rules that applications must live by--a security code of conduct, you might say. Unlike a firewall, however, StormWatch actually understands how applications behave.
For each application you want to protect, you the administrator need to create a rule, or set of rules, describing how the application behaves. Once you've done so, the StormWatch correlation engine (which lives within the agent) analyzes the proposed action before it accesses or modifies any mission-critical files.
For example, suppose a user receives a virus embedded in an e-mail message, which when opened sends an infected message to 500 people in his Outlook address book within a tenth of a second. A StormWatch agent, armed with a rule that a typical user does not send e-mail to 500 people within a tenth of a second after opening a message, would launch a dialog box asking the user for approval to send out a mass mailing. If the user responds "No," then the agent initiates a dialogue with the StormWatch Management Console, implicating the offending attachment. If the Management Console sees multiple reports of this behavior, it proactively updates all agents to blacklist the offending file, which keeps other machines from starting up a mass mailing with that attachment.
StormWatch agents impose just a small processing load--well below 5 percent of the CPU in my tests. The drain is virtually unnoticeable on desktop systems, and is within tolerance levels for server deployments.
Agents can intercept system calls and prevent unauthorized file or registry edits from happening. The management console communicates with the agents through an SSL connection and keeps the rules on the agent systems updated. So, if you write a new rule, you can easily distribute it to every system that has an agent from the management console.
StormWatch ships with a base set of behavior rules designed to prevent worms, trojans, viruses, distributed port scans, and SYN floods. You can write new rules or modify existing rules. Writing a new rule for a custom application requires knowledge of the application's executables, files, directories accessed, and ports accessed, just as writing a standard firewall rule does. Being proactive about security does have some overhead, and assimilating the required knowledge is certainly one part of that. After writing a rule, you can use StormWatch's Test Mode, which allows you to observe the rules in action through a test scenario.
One drawback to StormWatch is that you need to install the agent on every machine on your network to be adequately protected. However, the user, under direction from the systems manager, can install it with a single click after following the URL on an internal server.
OKENA is currently working on software that observes an application--what files it touches, what network protocols it uses, and what executables it launches--and then makes recommendations about StormWatch rules that would enforce what has been observed. If future StormWatch agents can be programmed to analyze application behavior patterns and script their own rules based on appropriate behavior, we will have a security product that is able to learn independently what it is supposed to protect.