Sabtu, 19 Agustus 2017

Functionality Testing a IDS/IPS

Intrusion Prevention Systems (IPS) were considered to be the consequence of Intrusion Detection Systems (IDS) around 15 years ago. IDS were to help to recognize and react to attack attempts and successful attacks. IPS go one step further and attempt to stop ongoing attacks as early as possible. This should improve the already existing security of an environment.
Even though IDS and IPS have been on the market for years and many a product has gone on sale, they are a bit of a mystery. Administrators either can’t comprehend the functionality of the systems at all or, if they can, they have great difficulty doing so. Traditionally, network-based solutions, known as HIDS/HIPS are deployed. The possibilities of a systematic functionality test and an illustration thereof is the goal of this article.

Goal

The goal of the functionality test of an IDS/IPS is to find out if the solution is working properly. The definition of properly changes, depending on the test case.
Usually, the systems have to detect an attempted attack as just that. This will result in an action that defines how the attack is being handled. This can be a passive action, preferably offered by the IDS:
  • Logging
  • Notification
  • Alerting
However, these actions can also be active actions. These are mainly the task of an IPS:
  • Stopping the attempted attack
  • Stopping communication between attacker and the target
  • Stopping communication coming from the attacker in general
In a test case, these actions are to be provoked deliberately. They are to be targeted, controlled and comprehensive.

Initial Situation

For a functionality test to take place, there need to be certain prerequisites in place. Basically, an attack scenario needs to be created, in which the IDS/IPS can perform its functions. In a host-based solution, it is necessary for the traffic to either tangent the IDS/IPS (passive sensors) or for the traffic to be re-routed via the IDS/IPS (inline system).
The easiest case is when the defined target system is protected by the IDS/IPS. An attacker will be put in an as-realistic-as-possible position where his attempts at accessing the target will be checked by the IDS/IPS.
Ideally, the data traffic will be logged at both end points (source and target) as well as on any and all systems in between – in particular on the IDS/IPS systems. That way, the exact minutiae of the test can be known.
This becomes interesting when a security component has a direct impact on communications. For example when a proxy transforms protocols or an IPS stops an attempted attack in the middle of said attempt. In that case, logging between source and target can be compared to determine the exact time and influence of the actions.

Testing

After the preparations for testing have concluded, the test proper can begin. During a test, various test cases are being initiated. All of those cases must fulfil these requirements:
  • Clearly defined.
  • As simple as possible
  • No complex third-party-software (such as exploits)
The easiest way to go about it is to use the tools that are freely available and that are also used during penetration testing. The following tools are recommended:
  • Nmap: The open source tool for analysis and scanning can be used without much hassle for many a scanning task.
  • hping3: The tool that crafts individual packets can be used to build specific patterns of attack.
However, there can be situations in which fairly complex exploits need to be simulated. In such cases, testers should rely on standardized frameworks such as Metasploit or ATK. The use of dedicated exploits is problematic. Not only are they not always comprehensively standardized but they also are usually of questionable origin, leading to the risk of getting infected with a Trojan.

Documentation

Each of the test cases has to be documented separately. In this documentation, certain basic points of information are mandatory to include in order to maintain the desired level of quality:
  • ID
  • Designation
  • Command
  • Output
  • Log (i.e. pcap)
  • Result
The result of a relatively small functionality test with an easily comprehensive number of test cases can look as follows:

ID Designation Command Result
1 TCP FIN Scan nmap -PN -sF -vv -d1 <target> -oA nmap_sf NOT DETECTED
2 TCP Xmas Scan nmap -PN -sX -vv -d1 <target> -oA nmap_sx DETECTED
3 Ping +++ATH DoS ping -c 3 -p 2b2b2b415448300d <target> PREVENTED
4 Land DoS hping3 -V -c 10000 -d 120 -S -w 64 -p 445 -s 445 -flood --rand-source <target> NOT DETECTED

If an attack has been detected correctly, then this can be filed as a success. However, if the IDS does not detect an attack, then an investigation into the reasons for the failure of detection must be launched. In an ideal case, if such a thing exists when the IDS failed, it’s due to the misconfiguration of the IDS/IPS or one of the filters that are being used.

If the cause of the failure can’t be found – many commercial solutions do not publish the functionality of their filters (such as HP Tipping Point) – then the vendor should be contacted in order to get an explanation for the failure. Transparency is of the utmost importance in order to maintain trust in and quality of a solution.

Summary

IDS and IPS are important elements in the security architecture of an environment. Targeted functionality tests should be undertaken to check if the systems do their job properly. To do this, testers must create an attack scenario that is as realistic as possible in which the systems can show their functionality.
By using targeted, comprehensive and simple test cases testers can try to provoke an expected action. If this action happens, this can be considered a success. If it doesn’t happen, though, then the cause of the failure must be investigated. Misconfiguration or errors in the deployed product can be responsible. Functionality tests are of vital importance to the security of an environment and the trust that is put into a product used in said environment.

Links

Tidak ada komentar:

Posting Komentar