Discover LinuxSecurity Features
Securing Vulnerable Software
This is not alarmism. It is an honest and rational statement of the current security risk born by organizations with networked computer systems.
The software running on your systems was written by people. People make mistakes. People are more prone to make mistakes when performing complicated and difficult tasks. Unfortunately, designing and writing secure software is a difficult and tedious process. As a result, the software you use contains flaws causing security vulnerabilities.
Since you do not have the option of running software without vulnerabilities, the challenge is to mitigate the risks the vulnerabilities can cause.
Cyclic Security Process
Managing the risk created by vulnerable software is currently a cyclic process. Consequently, security is a continual cost center. Furthermore, if the process stops or breaks down, earlier gains in risk reduction are effectively lost, since an attacker only needs to find one way in. The heart of the cycle is the sequence of events below:
- Vulnerability, "V-19" is discovered in program "e-serve" versions 1.2 - 1.5.
- V-19 is publicly announced.
- You audit your systems for vulnerable versions of e-serve.
- You increase the monitoring of the systems running a vulnerable e-serve.
- Exploit, "r00t-19", for V-19 is released.
- An IDS signature to spot r00t-19 is released.
- You update your IDS's rule-set with the r00t-19 signature.
- You develop an action plan for recovery from r00t-19 attacks.
- The e-serve vendor releases version 1.6, which fixes the V-19 vulnerability. But, may introduce other vulnerabilities.
- You upgrade e-serve on a test system to make sure that version 1.6 works properly in your environment.
- You deploy e-serve 1.6 on all production systems.
- You update your IDS rule-sets to reduce the priority of r00t-19 attacks, since they can not succeed now.
Perhaps the worst aspect of the security cycle above is that you do not, and can not, control the start of the cycle. Instead, some arbitrary individual makes a discovery that kicks off the cascade of risk, cost, and work in the security cycle. Running a close second for the worst aspect of the security cycle is that even when you follow best practices, your systems are unavoidably open to attacks for large blocks of time. This is a game you can not win.
There has to be a better approach. Today, vulnerability discovery dictates the risk associated with connecting systems to the Internet. The attackers constantly have the upper hand, is it any wonder that they usually win?
The existence of security vulnerabilities in software is an unavoidable fact. Methods for securing systems in spite of their vulnerabilities are needed in order to break out of the current security cycle. Breaking out of the security cycle requires changing the impact of software vulnerabilities. Once the impact of vulnerabilities is mitigated, effort can be directed at forward progress, instead of responding to vulnerabilities just to maintain status quo.
Behavioral Intrusion Prevention
A few simple observations about software form the framework of a security approach that mitigates vulnerabilities rather than responding to them.
- Software executes in quantifiable patterns.
- Software execution variation is measurable.
- The source of the variation can be isolated.
- Targeted countermeasures can be deployed against the source.
When an attacker exploits a vulnerability in an application, they cause the application to begin executing in a different way. In fact, the PURPOSE of the exploit is to change the application's execution. If we can spot the change in execution behavior soon enough, we should be able to stop the vulnerability from being used to compromise the system. This is the rationale behind the behavioral approach to intrusion prevention. Attacks can be stopped before they inflict damage, without needing specific rules to spot each attack or attack type.
Successful behavioral intrusion prevention requires meeting three challenges. First, execution observation must be able to spot changes in the execution caused by exploiting any vulnerability. Second, this observation must be made soon enough to take corrective measures before the system is compromised. Third, policies governing the responses need to be established.
Security is a process, and with behavioral intrusion prevention, it is a process under your control. When your business practices change, the usage patterns of your software unsuprisingly change accordingly. New software (and upgrades of existing software) creates new execution behavior. With behavioral intrusion prevention these events require you to revisit and potentially update your policies and countermeasures.
Instead of uncontrollable outside events setting off a cycle of work and risk, business decisons require the creation or modification of policies. Modifying the policies and countermeasures becomes just another step in the process of deploying software or changing business practices.
Behavioral intrusion prevention stops attacks before they succeed, rather than reporting their success. If for some reason you want attacks to succeed, behavioral intrusion prevention lets you do this as well; apply passive countermeasures. In most cases though, your business is better off stopping attacks than letting them continue.
Signature and rule-based intrusion detection systems are not sufficient to prevent attacks from succeeding. Current IDS techniques can not deal with the inescapable fact that software contains security vulnerabilities. Behavioral intrusion prevention can help by observing and stopping attacks as soon as a vulnerability exploitation occurs. By stopping attacks this soon, the risk associated with software vulnerabilities can be mitigated.
Cylant, a division of Software Systems International, develops technologies and systems for measuring the execution behavior of running software. Cylant provides tools to observe the behavior of running software and measure that behavior against a stored behavioral baseline.