Generalization of a Constraint Based Intrusion Detection System
In a world rampant with cyber crime, Intrusion Detection System(IDS) provides an effective way to grapple with cyber attacks. An IDS is used to monitor the network traffic and generate alerts for any malicious activities detected. In the IDS designed by our research group, we provide the network constraints as a pattern that defines the network packet sequence and network behavior under an attack-free environment. Any deviation to this pattern is detected by the IDS and a network alert is generated. This specification of constraints is done using a Domain Specific Language(DSL). The DSL that was earlier used as part of our IDS framework was a prototype designed by Hasan et al. Though effective, it had shortcomings. For instance, it worked on limited constraint specific patterns only. Secondly, it did not support use of domain information not available in the packets. Furthermore, it was limited to specifying the constraints only at the network level. Thus due to the limitations of the previous DSL, we have extended the DSL so that it could work against a wide variety of patterns. The new DSL is designed to be more readable and easy to use for specifying constraints. It has also been effective increasing the operator support for the purpose of evaluation of the constraints and provides an easy look-up mechanism for domain information stored by the system. This newly designed DSL can be used to specify constraints at the application data level along with the network level, thus providing the option to specify constraints to read-write network data to a file. The source transformation language TXL, has been used to generate C code as the output of the extended DSL. The constraint engine of the IDS framework runs this C code to detect any anomaly within the network packets. We have devised a two-step mechanism to ensure that the C code generated is accurate. In this process we run the code against, first the packet capture(pcap) file representing a normal scenario with no violations to the specified constraint and then we run it against the pcap file with anomalous packet data. Correct count of failed packets, generated by the constraint engine code for the latter pcap file conforms to its accuracy.