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.
