Marco Ermini, Network Security Manager will discuss top risks in using Network Intrusion Detection and Prevention.

1. Top risks associated in implementing
Network Intrusion Prevention Systems
Marco Ermini
Vodafone Technology – Information Services / ICT Security department
8th July, 2010
1 Presentation title in footer Confidentiality level on title master January 3, 2013
Department on title master Version number on title master

2. How can this help you?
What is and is not about – but it can help for
This presentation is not about…
> …explaining what NIPS are – but let’s be clear about what you can expect
> …choosing a vendor/brand – but we will gain some instrument useful for that
> …discussing if you need a NIPS or not, or which other technology do you need
> … “off the shelves” or “vendor provided” best practices
– you can just Google for “be s t p ra c tic e s intrus io n p re ve ntio n” - that will do the job!
> I assume you need and want NIPS, or you already have NIPS, and you want to be
aware of the rop risks associated with…
– …selection
– …configuration
– …deployment
– …management
What you are looking for, are best practices to make your investment worth
2 Presentation title in footer Version number on title master January 3, 2013
Confidentiality level on title master
Department on title master

3. W is speaking?
ho
This is not a bio…
W are you listening to me? – 1/
hy 2
> I am supposed to know what I am talking about
> Yes, that’s my daily job. No, I am not a trainer or something like that
> No, this is not academia or pure science. There is hardly here!
> I know what the market offers. Everyone can download Snort. It’s not about that
> I have a realistic – and holistic – view about this technology
> Yes, I have been under real attacks. And not just once! And I am aware of risks
> I am a customer of NIPS. I don’t sell them. I will not try to contact you and sell you
anything 
> Yes, this will be my personal, partial, questionable, but realistic point of view
You are not drinking from the fountain of truth 
(for what that matters, this never happens…)
3 Presentation title in footer Version number on title master January 3, 2013
Confidentiality level on title master
Department on title master

4. W is this for?
ho
Why do you care?
W are you listening to me? – 2/
hy 2
> You are a security or network engineer, and need to…
– be aware of the risks associated with this deployment
– are thinking/need to deploy NIPS into your networks
> You are just curious
– graduate student getting into the network and/or security job World
– experienced security or network personnel trying to understand risks associated
with NIPS
This is meant to be an interactive presentation.
You are welcome to share your expectation, doubts, questions!
4 Presentation title in footer Version number on title master January 3, 2013
Confidentiality level on title master
Department on title master

5. W are the top risk categories with NIPS? 1/
hat 2
There are both intrinsic risks and mistakes
W are the common mistakes with NIPS?
hat
> They are deployed in the wrong place in the network
> No monitoring or ineffective monitoring – no one is there around that can
access and use them when it is needed
> There is no tuning – they are deployed and then forgot
– Are running the “suggested” or “default” rule sets from the supplier
– No protection because of fear of false positives
– Too aggressive protection causes false positives
– A new one coming: thinking it is enough to send events to a SIEM
> Are confused with NIDS (detection) – I know IDS + I know Firewalls = I
know NIPS? Wrong…
> Not having operational procedures for their management and set up
5 Presentation title in footer Version number on title master January 3, 2013
Confidentiality level on title master
Department on title master

6. W are the top risk categories with NIPS? 2/
hat 2
There are both intrinsic risks and mistakes
W are the intrinsic risks with NIPS?
hat
> Think they are a “transparent wire” on the network – wrong: they do
interfere with network traffic
> They are not optimised because of lack of knowledge and skills of
managers/technicians/consultants
> They are not optimised because lack of knowledge of the inner networks
and applications they are defending
> There are false expectations about the technology
– it is assumed they are invincible and/or protect against “0-days attacks”
or DDoS
– you are subject to (vendors-diffused?) urban legends (“behavioural
based”? “auto-learn”?)
– they are deployed even when other technologies (DAM, WAF, etc.) would
be more appropriate
> Signature or normalisation behaviour are often not testable
6 Presentation title in footer Version number on title master January 3, 2013
Confidentiality level on title master
Department on title master

7. Compulsory checklist for NIPS deployment
If you don’t do that, you are doomed
> Do not plan on the fact that they can’t be bypassed. In many cases, they will be.
– Ever heard of “TSL/SSL”, “event horizon” and “inspect 512 bytes only”?
> Do not plan on the fact that they cannot be detected. They often can be.
> You need to use them in conjunction with other instruments
– Coordination between different departments of your organisation
> You need to update, patch the NIPS, and update their signatures
> You need to continually follow and profile the design of your network, applications,
business
> They will not protect you against real 0-days or DDoS (despite what vendors say)
> You cannot treat them as NIDS – they are a specific tool (i.e., cannot afford false
positives)
> You need to establish a metric and evaluate the real improvements over the overall
security
> You need to have operational procedures to use NIPS on the network
> You need to enable useful signatures and test them in production
> You need to spend money if you want a good product
7 Presentation title in footer Version steps, you better avoid the risk and don’t deploy
January 3, 2013
Confidentiality level on title master
If you are not prepared for those number on title master
Department on title master

8. W can I have from NIPS?
hat
What does my company need?
I can use NIPS for…
> Mitigate and prevent specific attacks. For the rest, you need to integrate with other
tools
– Will not protect against all of the web application attacks, DDoS, malware…
– Will protect against many – but if you want a locked down environment, you need
to complement with other tools
– 100% protection is not realistic, 0-days and DDoS protection are (mostly)
marketing
> As an effective tool for immediate reaction to threats
– They are in-line, ready and conceived to be used to react to attacks
> Enforce company policies
– Security is a process, not a product (Bruce Schneier). NIPS must be part of the
process
– Many can do traffic shaping/policing
– Some can communicate with NAC/NAP or firewalls
– CISO/CSO position: job security comes first – packet loss in not an option
> Can do tunnel inspection, stop exploits, detect anomalies and normalise traffic,
detect scans…
8 Presentation title in footer Version number on title master January 3, 2013
Confidentiality level on title master
Department on title master
They can be an effective tool if understood and used wisely

9. Border deployment best practices
Border edges of the Data Centre/border routers
> Can be the first barrier against malware and attacks against publically-exposed
services
– Cannot do miracles, generally do not inspect TLS/SSL/VPN/encrypted protocols
– Often cannot scan inside emails – mail servers today use SMTP over TLS
– Will only detect what is in the their event horizon – or add latency (“network
tarpiting”)
> Better have them working in conjunction with other tools that work on the border
routers/firewalls
– Before or after routers/firewalls? Depends on your policies and requirements
> They can apply traffic policing/shaping
– Probably the best tool against P2P/Skype/etc.
> Fine-Tuning is difficult and management of it can turn to nightmare
> You need to pre-emptively discuss with your ISP and establish a network security
policy
> Evaluate the impact on the performances, discuss fragmentation/flooding attacks
with vendor
> Remain realistic: they will add latency and will be bypassed
9 Presentation title in footer Version number on title master January 3, 2013
Confidentiality level on title master
Department on title master

10. Inner deployment best practices
Protection of the services
> They can be deployed strategically in front of an important service
– Achieving compliance? PCI-DSS? SOX?
– Web Application protection (HTML/JavaScript/IFRAME attacks, SQL Injection,
CSS, …)
> They can sit around in the network (more typical for NIDS deployment)
– Enterprise Office network – connected with NAC/NAP and block the rogue clients
on the switch
– Inside a DMZ/production segment – need to create a specific profile – can hook to
VPN concentrators
> What is your policy?
– I want to prevent everything that is attempted against me – deploy wide rule set
– I want only to protect against attacks that can hit me – deploy specific rule set
> What is the default fall-back scenario?
– Pass-through or drop?
> Which signatures to use? Generic, vulnerability based, exploit based?
Again: remain focused on making them an useful tool!
10 Department on title mastertitle in footer Version number on title master
Presentation January 3, 2013
Confidentiality level on title master

11. Determine which signatures you want in place
How to evaluate and tune your rule set
> Three main kinds of signatures
– Generic – standard pattern matching – easy to evade
– usually shellcodes/dumb behaviour (brute force login attempts, non standard
port usage,…)
– often will trigger on unsecure but “corporate accepted” behaviours (login as
root,...)
– need to tune thresholds/trigger points
– Vector based –more advanced pattern – less easy to evade, less prone to false
positives
– protection against a v ulne ra bility , not an e x p lo it
– needs more powerful and “smart” engine, and a performing device – network
latency…
– Exploit based – protection against a specific attack – trivial to evade
– minimum false positives
– link cleaning against “script kiddies”
> Establish your baseline for a specific environment/sensor
> Tune the other normalisation or behavioural parameters based on the applications
11 Presentation title in footer Version number on title master January 3, 2013
Confidentiality level on title master
you have
Department on title master

12. Baseline rule set tuning and deployment
Measure security improvements (or worsening…)
Suggestion for a best practice
> Agree on a deployment window
– Verify if important things are going to happen… don’t deploy before a new release
of a software or a brand new service for the public “goes live”!
> Monitor - for a couple of hours thereafter
– inside the maintenance window for “immediate” issues – customer-facing services
blocked?
> Monitor - for a couple of days thereafter
– for “slow on-set” issues – administrative access, less often used services
> Have a roll-back plan available – for the maintenance window and “slow on-set”
issues
> Create a periodic report over the differences within the baseline
– Intelligence reports are preferred by CISO/CSO – but you need a tool to specify
– If you prefer: a report about attacks mitigated/prevented/observed
> Make the report visible to the upper management
Something changes in the service/
network? Repeat the process!
12 Department on title mastertitle in footer Version number on title master
Presentation January 3, 2013
Confidentiality level on title master

13. Monitoring
Don’t forget them!
> Monitor against profiles/rule sets that are useful
– You need to have a network diagram/map of your networks and services
– You need to profile
– the services you are protecting
– the traffic of your networks
– After this, you need then to tailor your rule sets again and repeat the process
> Attention to outsourced managed SOC: some uses statistical tools on which I have
concerns
> There is no magic wand, or bayesian-behavioural-self adapting etc. – this is
marketing
> You need correlation with other tools – anti viruses, firewalls, NIDS, network
scanners…
> You need to have personnel monitoring 24X7X365 that can also access and know
how to use the NIPS, and processes and procedures to act in case of incident
Again: remain focused on making them an useful tool!
13 Department on title mastertitle in footer Version number on title master
Presentation January 3, 2013
Confidentiality level on title master

14. Measure effectiveness
Because you have to renew your contracts sooner or later 
> How they did behave under attack?
– Have they detected it at all?
– Have they been useful in mitigating it?
– Were they manageable under attack?
> Peer with other NIPS customers
– Different companies, also from different market segments
> Do not blindly believe the vendors. Use basic math.
> Be paranoid
> Finally: create reports that are readable
– Your management doesn’t understand a bunch of IP addresses and the signature
names
Again: remain focused on making them an useful tool!
14 Department on title mastertitle in footer Version number on title master
Presentation January 3, 2013
Confidentiality level on title master

15. Correlation and SOC
Effective security 24X7X365
Some best practices
> Do not import all of your events into your SEM/SIM tool
– Often you just overwhelm it, even with NIPS
– Do not work “statistically” and blindly about your network architecture and
applications
> The policies/rule sets you deployed on the NIPS have an impact on what you get!
– Sometimes you pay the SEM/SIM license or the outsourced SOC by the number
of events you are sending them!
> Does the SOC (either out-sourced or in-sourced) have access to the NIPS?
– Have you defined a user management for the NIPS?
– What about operational procedures?
– What about technical skills of the personnel?
> Forensic importance – but balance with event database’s growth and disk space
Again and again: remain focused on making them an useful tool!
15 Department on title mastertitle in footer Version number on title master
Presentation January 3, 2013
Confidentiality level on title master

16. Thank you.
Any question?
16 Presentation title in footer Confidentiality level on title master January 3, 2013
Department on title master Version number on title master