I have recently been requested to review a McAfee HIPS solution and look at the possibility of using Snort signatures. Now this doesnt make sense to me, as Snort signatures are network based signatures, not host-based. I had a quick look at the Snort site and can see no mention of host intrusion based sigs following the rule structure in Appendix A if the HIPS product guide.
Can somebody tell me:
- Am I going mad?
- Do snort actually produce signatures for HIPS products?
I was also asked the question on whether it would be worth adding something into the support process that dictated that when a NIPS (Snort or vendor) sig was released that dealt with a specific vuln, a check/request was kicked off to see if that vuln was covered in a suitable HIPS signature. In *my* opinion, I dont think there is a great benefit to this, as a) chasing up these things can be quite time consuming, b)it isnt always the case that both a NIPS and HIPS sig exists for the same vuln, depending on the vuln, and c) if the processes for both NIPS and HIPS products are in place, all available and relevant sigs should be caught regardless.
Comment would be greatly appreciated on this - open to alternative viewpoints!
Thanks in advance,
You are not going mad.
Network-based IDS/IPS look for specific patterns of IP traffic. Host-based IDS/IPS may also look at traffic patterns, but are also worried about file integrity. And when you have different tools with different organizations supporting them, you are not likely to have identical signature sets.
Also, I have never seen a way to convert Snort or other third party NIDS/NIPS into a signature set that the McAfee HIPS can interpret. They are different tools and format their rules differently. Unless Snort specifically produces "equivalent" rules for other products, which I would also call unlikely. It sounds to me like the person asking the question doesn't really understand 1) IDS/IPS in general 2) the relationship that COTS vendors have with each other.
As for the support process...I don't fully agree that all available sigs would be caught regardless. There could potentially be some timeframe in between when an update is released for a specific vulnerability, and when that update is rolled into the next regularly published signature set. I would suggest that you develop a process to handle these on a case by case basis (what is the risk of a specific vulnerability that is being addressed, what is the time frame until it gets rolled in to a normal signature set release, is that timeframe acceptable to your organization, etc). I would look at doing this for all portions of your security program that require updates (IDS/IPS, anti-virus, etc).
Regarding catching available sigs, I agree - my weak wording for c) regarding processes in my own mind covered your point regarding timeframes between update releases and published sig sets, so that was my bad! Just to ensure we are on same page, an example of this in my mind would be a McAfee NSP UDS, which has to be manually assessed by *somebody* with a decision on whether to deploy it or wait for it to be rolled in to the full sig sets (usually an additional risk is while it is in 'UDS' status, it is likely not to have been through a rigorous QA process). With regards to McAfee HIPS, I cannot recall seeing anything like this (ie out of band to the normal HIPS Security Content updates - let me know if there is, as this may have been something I have missed!
Many thanks for your swift response, glad to know I have some modicum of sanity left :-D