13.7. Thoughts on Evolution of IRS Technology

We anticipate that for IRSs to be widely deployed, they will have to evolve in several directions over the coming years, including:

• Ability to withstand unpredictable attack scenarios. It is inconceivable that all attack scenarios would be “programmed” in the IRS. The IRS should, therefore, be able to extrapolate strategies available in its knowledge base and take responses to hitherto unseen attacks. This will be an important requirement since polymorphic worms, viruses, and other forms of attacks are rampant in today’s security landscape. In this matter, there is a delicate balancing game between learning from the past and being agile to respond to future attacks. It is possible to build up large knowledge bases and do exact matches with them to choose appropriate responses from the history. However, this may affect the ability of the system to respond quickly. Also, in taking lessons from the past, the IRS should take into account the fact that the impact of the attack may be different even though the attack steps may be the same. Thus, a more drastic or quicker response may be called for.

• Dynamic responses with changing network configurations. The IRS will have to deal with topology and configuration changes in the distributed system. It may take inputs from change notification software systems, such as Tripwire, and modify its response strategies accordingly. In any medium- to large-size distributed system, there are multiple administrators responsible for maintaining the system. The tools are often not standardized or uniform across different administrators. Thus, modifying the tools to send notification to the IRS seems daunting. A more feasible approach appears to be software to observe the resultant changes and notify the IRS. A change in the configuration may render some responses unnecessary (such as a critical service being made accessible from only inside the corporate network) or some responses more critical (such as a service being made Web accessible).

• Interaction with other components of the security framework. The response strategy decided on by the IRS is predicated on confidence placed on other components of the security framework, such as IDS, change notification software, firewalls, and so on. The confidence placed on these components should not be predefined constant values. The confidence should change as new software is installed, rules updated, or configurations change. This also indicates why a probabilistic framework for the IRS seems the promising avenue, rather than deterministic response decisions. On another point, the IRS may depend on various basic functionalities in the system, such as firewalls or an access control system, to deploy the computed responses.

• Separation of policy and mechanism. It is important for the IRS to provide mechanisms for determining the appropriate response based on security policy settings. As far as practicable, the two aspects should be clearly delineated. This will enable a system administrator to set the policy, which can be at various levels of abstraction, such as a paranoid versus laissez faire policy at the system-wide level, to policy levels for individual services. In the absence of this, an IRS will not have buy-in for production systems.

• User interface design. Visualizing the different effects of an attack and its responses in a distributed environment is inherently challenging. The speed of the processes (attacks as well as responses) makes this a particularly daunting task. However, for critical functions, all the stake holders (system administrators to chief information officers of an organization) will likely have a human-digestible form of the information available to them. This should include online tools that let them visualize the network while an attack or its responses are being deployed, as well as offline tools that will aid in forensics action.