IPS Deployment

IPS deployment

 

Intrusion Prevention Systems (IPS) inspect packets, analysing traffic for signatures or policy violations, in an attempt to prevent attacks.  Generally, these devices do not decrypt encrypted traffic but instead apply a predefined policy or signature set across all network traffic.   An IPS can be thought of a generic, system wide, protection device.

The above diagram illustrates a common deployment model of IPS behind a Firewall and in front of a WAF.

Web Application Firewalls (WAF) are for HTTP/HTTPS applications, and provide a specialist protection service at the application layer.  Since WAFs often terminate an encrypted session, they have an advantage of being privy to payload data. They provide protection for web servers by having a deep knowledge of the application flows e.g. GET, POST, HEAD, JavaScript, SQL, HTML, XML, and Cookies. They can apply rules to these conversations and prevent common Web attacks such as cross-site scripting and SQL injection.  

WAF and IPS functions in general complement each other, and should be used in tandem for a best defense in depth strategy.    With WAF deployed behind an IPS, the IPS can be observed to catch many attacks at the perimeter, however the WAF still sees intrusion attempts that have evaded IPS protections. Hence WAF provides another layer of valuable bespoke protection.  Some attacks may get through the garden gate but subsequently get blocked at the front door!

Typical Protections:

Firewall:	Controls permitted E2E traffic flows. Protects from Scanning, Untrusted endpoints and IP spoofing
IPS:	Generic service protection from viruses, worm exploits and known malicious traffic signatures
WAF:	Protects web servers (http/https) from XSS, SQL Injection, Buffer Overflow, Hacking

Key Considerations when deploying an IPS

·         IPS should be deployed inline of zones that require protection.

·         Select platform with sufficient hardware resources. An inline IPS shouldn't become the traffic bottleneck.

·         Deploy IPS as IDS initially, monitor, analyse, and carefully plan a phased move to full IPS mode.

·         Define an agreed generic policy for signature deployment i.e. what severity of signature should be enabled in PROTECT.

·         Define what traffic the IPS should be protecting: Inbound, outbound or both.

·         By monitoring IDS reports define IPS Exceptions to exclude flows determined out of scope. This can be as granular as required e.g.  It could be as wide as determining outbound flows are out of scope, or determining that specific signatures are not relevant for certain trusted flows.   This will have dual benefit of reduced overall IPS load and reduced false positives.

·         Create scheduled signature update policy.  It is important to bring new protections into production as soon as possible to reduce exposure from emerging threats.

·         Define IPS reporting of signatures fired in DETECT only.

Consider using a dedicated SOC to monitor 'out of policy' DETECT signatures. It requires some time and effort to monitor an IPS. If this activity is within scope of a busy general support environment it will require discipline to devote resource to this task, alongside other priority Incidents.

·         Allow time for review of IPS reporting, and required remediation actions against IPS report.

Someone with insight into the monitored environment will need to assess highlighted threats and determine if mitigation is prudent. e.g. should a signature been tuned from DETECT to PREVENT or does this alert represent a false positive that requires exclusion.

·         Plan for ongoing and extensive IPS Tuning

To get an IPS to an optimal state, providing best protection, and without firing false positives requires significant analyse effort and tuning.  To keep the IPS in this state requires a continuous 'monitor and adjust' framework to be in place.