Converting Snort Signatures to Cisco IDS/IPS

[edowd]

Hi,

Has anyone figured out an easy way to convert custom SNORT signatures to the Cisco IDS? There seem to be a lot of parameters that don't really match in the Cisco World to the Snort world and I am wondering if this is something that people are trying to do as security is generating the Snort signatures way before Cisco generated their signatures. Also there are other signatures that may nevery be released by Cisco because they are built outside of normal channels.

Has anyone every seen something that maps or converts snort signatures to Cisco IDS/IPS?

[mhellman]

I've never seen such a thing (converter from Snort to Cisco IDS). My 2 cents...it won't be easy. I just grabbed the last sig in the bleeding edge malware rules and pasted it below. As best I can tell, in order to do this is Cisco IDS you'd need a META signature with 6 components(one for each uricontent keyword)....good luck with that;-)

alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg: "BLEEDING-EDGE MALWARE K8l.info Spyware Activity"; flow: to_server,established; uricontent:"/media/servlet/view/dynamic/url/zone?"; nocase; uricontent:"zid="; nocase; uricontent:"&pid="; nocase; uricontent:"&DHWidth="; nocase; uricontent:"&DHHeight="; nocase; uricontent:"Ref="; nocase; classtype: policy-violation; sid: 2003451; rev:1;)

[attmidsteam]

No, we've looked also and the engines are just too different. It is a completely manual process and requires a high degree of knowledge of both the Snort & Cisco engines. Also, the more complicated snort engines are going to be a PITA to convert. FYI, there is a converter for Snort to Dragon signatures.

[clausonna]

There is a program available now that will convert rules from Snort format to Cisco format:  http://s2c.sourceforge.net/

The code still needs some work, but the author (cisspdude) is actively developing it and has been very responsive to bug fixes and  feature requests.

I'll stay out of the debate on Cisco vs Snort for sensors, but as far as signatures go, EmergingThreats.net wins hands-down for malware detection sigs.  They publish in Snort format, hence my interest in converting them to Cisco.

[mhellman]

While that is interesting and I can appreciate the desire to have this capability, IMHO it would be risky (foolish?) to use that in a production environment, especially if you are inline.  Using with CSM would be a total recipe for disaster. I'll never get the fascination with other IDS/IPS products trying to convert/read Snort signatures. I know WHY people want to do it (I like the emerging threats rules too)...but these are not commodity items with perfectly interchangeable detection capabilities. This is guaranteed to be brittle over time.  Besides, if you prefer the Snort rules...why not just Snort?

[clausonna]

I think people's interests in converting Snort sigs is a reflection on the quality of those sigs, and/or the lack of quality sigs in the other IPSes.  For Cisco, to me this means the malware detection and botnet 'phone home' sigs that are in EmergingThreats (ET) but completely missing in Cisco.

Yes, I agree that just blindly converting a bunch of snort sigs and sticking them on Cisco sensors is extremely foolish + risky.  And yes, IPS sensors have differing capabilities and functionality.  But there are -many- ET sigs that are high quality, high fidelity, and are based on a very simple set of URI regexs.  I deployed IPS sensors (inline) to block attacks and prevent malware - why WOULDN'T I do everything I can to get the most value from them?

I have already converted a bunch of ET rules, deployed them to a few dozen Cisco sensors, and have been able to track down hundreds of infected machines that I wouldn't have detected otherwise.  Nothing crashed or otherwise put me in the doghouse while doing this, because I did it carefully and logically.

I don't have experience with the commercial SourceFire snort sensors, but managing the open source ones are a challenge (and I am quite comfortable in the *nix world), and I'm also not going to put a beige box "inline".  Perhaps if I was to revisit the issue (and had the budget) I'd look at replacing Cisco IPS, but right now there are far too many benefits to even consider that.  I have what I have.  Cisco has great sensors and a lot of other plusses; if they improved their malware detection abilities then we'd be in even better shape. What's really lacking is a community to discuss custom rules and/or improving Cisco IPS in general.

[mhellman]

I applaud you for doing this, you're a whole lot braver than I.  We use real Snort where we want Snort rules. We have pretty much default configurations and the sensors crash-and-burn during normal signature updates from CSM.  Heck, ALL of the sensors puked during a sig update a few months ago. The notion of installing a bunch of custom signatures, generated autonomously, just doesn't make sense in that kind of environment.

[mikecrowe4ICS_2]

Another case where this kind of conversion might be used: where specific signatures are required to be implemented, but the signatures are published using the Snort format.  This can be the case in heirarchical organizations, especially when there are multiple levels of operation with no centralized management.

I'm glad to see something like this being done - it could be really useful.

[golly_wog]

.

[attmidsteam]

No, nothing has changed.  This post might get deleted but there are far superior alternatives if you wish to run Snort based signatures without the management, licensing, stability, expense, and lack of IPv6 management that is a Cisco sensor.

[mhellman]

+1. You do know there is a commercial version of Snort right.

We can't manage the few sensors we have with the Cisco CSM product (sensor down in India at this very moment because of a failed signature update...and it happens all the time). I shudder at the thought of trying to manage 500 sensors.

[attmidsteam]

You are lucky, we have > 1500 Cisco sensors around the world right now and lose ~100 on each signature pack (due to crashing).  The last dozen signature packs have also had numerous issues which has made life especially difficult (nothing really new since we've seen it all in the last six years).  You also don't want to know what a licensing hassle that many sensors is or how many man hours is required to keep them running.  The commercial version of snort works well and that company is very responsive to issues (they have been to us but we spend a lot of money on such things. :-).  The snort signature format is also very well understood and being plaintext has many benefits for scripting.

[mhellman]

Are you using CSM?  If so, version 4?

[attmidsteam]

We are testing version 4 but so far it doesn't feel all that different (or better).  We have 6 different 3.3.1 CSM servers right now.  I'm sure the next version will totally solve all outstanding issues...  .

[Bryantray]

I would like to break into this stream of comment; to gain some info that is important to us.

We sell a product called Traffic IQ PRO, I won’t go on about it you can search the web for info. The objective is to enhance the capability of the device(s) make it easier to manage and hence lengthen the life of the asset.

I believe that using such a product would help you resolve many of the issues mentioned here. BUT what I would really like to know is an answer to the following:

We produce between 50 and 100 new traffic files each month (Exploits) and have a library of approaching 5000 such threats for auditing and testing your IPS/IDS etc. Along with these, we issue a security rule to allow an immediate fix of any issue identified in the audit. These in the SNORT format using as much generic syntax as we can to allow import or conversion into other manufacturers devices. We do realise this is not always a straight conversion and they do need some knowledge by the end user. We could write these rules as specific manufacturers rules, but have not realised this is a major issue until now.

I would welcome any comment as to whether you feel it of benefit that we supply rules in CISCO syntax, our rules or for that any other pcap you care to send to us. TO be clear, we would not do this for free but the cost would be minimal if enough people were interested in Traffic IQ. We could arrange an attractive price for Cisco group.

Let me know an I will investigate the practicality.