Everything you want to know about IBM's Infrastructure Security products

Question: "How much throughput is enough for my organization now and how much should I consider for future, so the device I buy will be able to meet my long term requirement?"

Let's try and find an answer to this question.

First and foremost, the placement of the IPS is important. Logical and Physical placement in your network will directly help you to determine the amount of traffic (bandwidth) the IPS is going see.

What do I mean by logical placement? ...Will it be installed between Firewall and Internet or internal network and firewall or DMZ and Internet, etc.

What do I mean by Physical Placement? ...Will it be installed at a centralized data center or will it be installed at country head quarters, etc.

Depending upon the answers to both of these questions, you will have to run some reports on your Network Bandwidth Monitoring tool (assuming you have one) and go back as much as you can to get a trend detailing the amount of traffic at the place where you have decided to install the new IPS device. Observe the peeks in this trend. Also use this trend to make a fair judgement on potential increase in the next couple of years ...at the least.

The logical placement of an IPS is a debatable topic. While it is okay to put an IPS device between a firewall and the Internet, do you think it is important to analyze the traffic which will be blocked by your firewall, anyway? Typically, you would want your first layer of defense to drop everything that is not required. Using an IPS, you can apply intelligence on the traffic which is allowed from your first layer to monitor and block any malicious activity. An IPS facing internet would need much more power compared to the one placed inside the firewall which can be easily avoided.

So you would think, now you have a fair idea of the bandwidth flowing in to and out from your network but there is one more important consideration which probably most people don't think about, which is, Traffic Profiling.

What does Traffic Profiling have to do with throughput on the IPS? Obvious question, right? Here is the answer:

Compressed traffic plays a major role in defining the throughput for an IPS. When you look at your network monitoring graphs, you just get to see the total amount. However, if you have 30% compressed traffic going out from your network with 4:1 compression ratio, the throughput requirement might change completely. Because, assuming you would want the IPS device to analyze the compressed data, the IPS will have to decompress that traffic first and then analyze it. This adds to the load on the IPS not only in terms of amount of data but resource required to do the decompression (processing power) and store the decompressed data in memory for analysis (memory) as well.

Encrypted traffic is another thing you might want to consider if the IPS vendor provides decryption capability. It is good to verify if supported throughput values in datasheet for SSL/TLS inspection, assuming that the appliance you are opting for is capable of analyzing the encrypted traffic.

Additionally, it is important to consider whether you are planning to have a high availability environment with Active-Active configuration. Again, the assumption here is the device you are buying has this capability. Though, in an Active-Active environment, both the devices will have traffic distributed, either device should be capable enough to take the complete load in case one of them fails. I know this sounds very obvious but no harm in including this in your checklist.

Lastly, please remember that all vendors in the market will have various models with different throughput capacity. Only thing that changes in these models is the underlying hardware. The software part of the device - the analysis engine, will typically remain the same. With different models you are providing better hardware to analyze the data quickly.

With this backdrop, IBM has a whole range of IPS models to cater to the need of protecting your network. It may be your remote branch office or your centralized data center. We have a solution to offer. We have a couple of offerings in the network protection domain under our Infrastructure Security portfolio: IBM Security Network Intrusion Prevention System (GX Appliances) and IBM Network Security Protection (XGS Appliances).

One of the sought after features is finally here! IBM's Security NIPS appliances can now send security alert (including IPS and SNORT), health alert, and system alert events into log event extended format (LEEF) for transmission to a syslog server.. A syslog server can be your centralized syslog server or an SIEM solution, doesn't matter. We integrate with it very smoothly. The feature has been tested with our own marked leading SIEM solution QRADAR.

Starting firmware 4.6, we have a new policy called LEEF Log Forwarding (syslog).

Ether way, the policy is pretty simple. "Enable Local Log" option, shown above, lets you save the leef file locally on the appliance's hard disk. You can set a maximum file size (in MB) to ensure that appliance disk space is in check. There will only be one file created if you enable this option and will be rotated after it reaches the maximum file size configured.

The file can be downloaded manually from /var/iss/leef.log or you can download it from LMI as well by navigating to Review Analysis and Diagnostics > Downloads > Logs and Packet Captures.

In the remote syslog configuration, you have to specify the IP Address of the syslog server and the type of alert you want to be sent to it. The selected alerts will be sent to the default syslog UDP port of 514.

You can configure as many syslog servers as you want. You can choose different alerts for different servers or have multiple syslog servers configured to ensure if one fails the events are still reaching to others.

With the new syslog feature in FW4.6, integrating with your SIEM solution becomes easier, efficient and effective.