IDS/IPS Choices: Benefits, Drawbacks, and Configurations

IDs choices uh is the mic on I don't know uh no it is not that that would be a good thing thank you

sorry okay how about now is that better all right all right excellent now we're in working order all right so now that everybody can actually hear what I'm saying welcome uh as said my name is forgotten or Brian uh talking about some IDs choices and networks uh Network architecture uh so little bit history slightly jaded on IDs kind of started uh at source fire so a little bit of love for snort um hopefully do most people know what an IDs is hopefully yes no maybe okay some of you anyway all right um so along the way I ended up uh taking over a few things so running a nice little CTF and running another bsides up in

Maryland and a hacker space and other strange things along the way uh pretty much my entire career has been around the sock world and defensive architecture so that's been kind of fun uh the last sock I worked in we actually combined these two things does anyone know roughly what the left is supposed to represent PLC industrial Control Systems so I actually had the pleasure of building probably one of the first uh industrial control system Security operation centers designed around specifically monitoring uh a series of power grids both power distribution transmission and getting some generation so that was kind of fun lots of interesting environments to have snort in um now I end up uh teaching folks

about snorton sock work as well as uh teaching a lovely class up in Maryland under3 um so we end up teaching a lot of classes that unallocated because hacker spaces and free classes are always good so uh one of the things over the years I kind of put together uh the phases of sock monor um kind of the current status quo and a lot of uh socks I've walked into have been uh somewhere around fa flailing kind of sad but uh organizations tend to look at okay we have tickets we need to close tickets we're getting alerts we don't know what these mean we get more alerts than we can deal with so we're going to rush to

close every single ticket we can and not much thought of actually what can we do to prevent uh these alerts in the future a lot of times a lot of these issues don't get fixed don't get addressed no one's looking at how do we deal with this problem uh one specific sock had a million events a day on the ids's for six analysts clearly we weren't able to close those tickets but not an uncommon thing so kind of call that flailing right if you can't close most of your tickets you're missing stuff and you don't know what you're missing it's kind of scary um kind of the first step in my mind arguably one and two can be

interchanged I want visibility in my network what do I have what what's there what should be there you know seems kind of obvious seems very similar to like sans's top 20 has things like an asset list sprun along the same lines um so visibility and detection of known threats so what's out there that everybody knows about that there's solid rules for that have been tested all over the place that we know how to block we know how to prevent we know how to deal with these things when we get an alert for this it's not going to be a false positive it's not going to be some random thing it's going to be an actual

issue that we need to deal with so those two things are kind of the starting point when I end up walking into most sock operation ations those are the first two things we discuss on this is where to go first uh next is preventing the actual known exploits right if you can block ransomware and neutrino and some of the other exploit kits and really basic attacks that we know how to detect cleanly we're not seeing much in the way of false positives it's a clear Next Step Right seems reasonable I've not found many organizations that have gotten to this point where they're effectively blocking all known exploits that are clean that are you have alerts

for you know these are always going to be true and then kind of the next phase as much as the threat folks hate to hear this to me once you have those known threats dealt with then we can start to really look at threats that we may not have such a guarantee on things like this bad IP address or this bad user agent string that may or may not be an actual issue might be just somebody with a love for Internet Explorer 4.0 for example um thank you HP uh or it might you know I would rather deal with that after I've dealt with known issues before I deal with the supposed industrial control system

malware that was actually HP open view thousands of times a day actually about 100 thousand so kind of some story time so there was a breach recently um getting well recently as arguable at this point but uh one of the most well-known breaches as far as what they've disclosed on how a breach actually happened came through at least I got as much the story as I have for any breach I've heard of so in this particular retail example um they had had a lovely HVAC vendor up in Pennsylvania that got fished happens in most organizations at this point if it's large enough fishing is a real problem and it's going to happen our goal as

Security Professionals is to prevent it from going forward prevent lateral movement and from them being able to walk around the network for months or years before we deal with it seems like a reasonable possibility it's good to try to prevent fishing but trusting the user to do an 100% job of detecting good fishing attempts probably not right even it Security Professionals get fished it's hard sometimes so kind of that point where okay they got fished fine they had saved the credentials for our lovely retail Target for remote access um again the ability one the ability to do remote access based on a single credential is probably a bad plan right two Factor authentication not that

expensive anymore we can reasonably do that not too hard take some work so they were able to connect still the one of the few details that I haven't been able to get was did they connect through did they pivot through or did they actually connect from another site that would be a fun question for anyone working at the tar at the Target organization um so if they were hopefully they've blocked it so that only valid IP addresses and whatnot could have remote access that would be another reasonable thing that they probably didn't have set up so okay HVAC vendor now attacker gets into the particular store and they're able to get to the HVAC system makes

sense then they're able to move to the point of sale network not so good segmentation is something we learned in the 90s in theory but not yet today apparently uh we still struggle with segmentation across most it networks today think most almost all have segmentation issues in different points so once they were in the point of sale Network they uploaded some stage one malware seems fine right grab take a look around see what they are playing with so that they were able to okay learn to lay the land upload stage two start to collect credit cards okay in memory malware kind of tough but in this case uh their Protection Systems ironically uh fire eye uh ended up detecting the

stage 2 m so from that point there was about a 3-day period between initial detection and when credit cards being started being exfilled so a 3-day period on detection and they still hadn't remediated it who knows how long later so all the credit cards were able to be exfilled so kind of a bad response to detection but beyond that what is the easiest way way to find a ton of data leaving your network anybody know for a prize if you have just a massive amount of data yes sir net flow yeah that's right when you see come get your

prize card leaving your network you can probably see that it's probably going over a chain channel that you don't necessarily transmit a gig of data or whatever that is in text worth of credit card data right regardless of the fact it was credit card data if you have a gig of FTP and you don't normally use FTP outbound it's kind of weird so net flow would have been a fun way to detect that Beyond any DLP solutions that yeah not a big fan of those I haven't seen much success with it but before we go damning our particular retailer we really have to be careful cuz you know the old saying people in glass houses shouldn't throw stones

right is your organization really that much different I mean it's kind of bad but like do you have a full asset list of every device do you know what Mac addresses should be there do you have good segmentation in your network everywhere from say separation between different departments so I know HR and finance should be on wouldn't say restricted networks but more protected than say you know uh random receiving and shipping or whatever depending on what your company does there's certain areas that you want to protect a little more segment off having very flat networks with very little segmentation is too common today having two Factor authentication on every single remote connection from outside in to me this seems like a

completely reasonable thing and not Che not expensive to do anymore there really isn't there's more and more vendors in the space it's not just RSA anymore they always had some options but now things like Duo and other companies have done a good job of making it very easy oof is free if you really have the time to implement all of it so the there's reasonable Solutions out there to work on these problems um response time to all tickets under 3 days is probably the most difficult one for most socks out there um a lot fall behind quickly and never really catch up part of that goes back to security engineering but we'll come back to that

in a minute application white listing especially on uh high value devices so point of s systems as well as industrial Control Systems come with one major awesome point for protection we know exactly what's going to be on there and most of them are very similar so creating an application white list for point of sale is Trivial and you can test it industrial Control Systems a little harder but most organizations today have servers and other things that they can build application Whit list profiles for additionally endpoints you can do application white listing pretty well deploy it in test mode and see what's triggering stuff and then enforce mode so these are features out there that a lot of

organizations could easily implement but they take time engineering resources these things are hard sometimes so if you were under the same situation where you had someone coming after you how how much different would you organization B again while Target was a great example of a breach where they released all the information almost there's not many where we have these lovely case studies where they release almost every detail of a breach for us to learn from so that's kind of a hard problem but uh specifically IDs is kind of my bread butter and potatoes of the sock operation so talking about that now a little bit more detail so kind of the four most common ids's that I find today

in organizations uh snort and cata the two almost Brothers bro IDs uh which is kind of a different type of tool and then fire eye obviously they're here today and having fun um so break it down a little bit uh snort from what I've seen is the most popular again kind of a jaded view given most of the time when I'm being brought in uh it's for snort Source fire type gear uh being open source and then the corporate support through Source fire uh kind of nice uh if you want to do big deployments um signature base started out in 1998 kind of an interesting story with that one sniffer and more was how the name

came about I took some research to find sirotta uh kind of the offshoot of snort um in 2010 they forked the snort project to go a slightly different direction for sharata still signature based but kind of a slightly different uh goal for syot ver snort and probably the most known difference is it's multi-threaded although if you're doing a deployment big enough where a single thread is not sufficient with reasonable Hardware you probably should you know look at an Enterprise tool at that point instead of an open source but I myself done 10 10 gig deployments of Open Source snort it's doable it's difficult but doable uh bro IDs is actually the oldest of the group um started out at one the

National Labs uh 20 years ago over 20 years ago and kind of some interesting automated details you can actually pull net flow out of BR as well which I thought was kind of interesting first playing with it a lot of power but probably to me the biggest component of it is it gives you a lot more visibility into what's going on in your network today where we have everchanging networks that no one has documentation for asset lists are hard being able to have a dynamic tool to do visibility and to see what's in my network what's there and notice changes not just net flow but in data types can be really really helpful and about 10 years ago was

actually when bro really started to get going ironically um through funding from what I've seen primarily for industrial Control Systems Department of energy actually pushed for bro really hard and kind of funded a lot of its ability to move to a bun from a bunch of guys doing development when they had free time in the National Lab to a full-on funded project that could sustain and really make a huge difference over the last few years it's gotten way more popular with the ever expanding networks to get that visibility and fire eye um kind of a customized snort and cucko combined with some other as they call it magic and hunting um unfortunately this is the

only close Source product of the group um also started about 10 years ago but my only concern is you can't really get detail of why something was detected and work on false positives you kind of have to rely on them to do that and I like fine tuning so to me uh you kind of come to a Crossroads what should I use uh this is a common question that a lot of wordss end up looking at and just picking one without really looking at differences so to me kind of the the bro is a little bit off on its own gives you the visibility but not really detection of threats so it gives you number one in

that lovely phase cycle not necessarily two and three maybe three maybe it'll block I'm sorry it doesn't even have the ability to do blocking because three prevention of known threats again bro is not something you can really drop traffic on so you come down primarily in my head to snort vers sarot and also bull setwise emerging threats versus Source fire and these two kind of go at uh the problem in two different ways so Source fire and S and snort are designed to look for specific threats they're engineered to be better at looking for explicit threats not necessarily IP addresses or threat indicators whereas cirata and emerging threats are designed more around I hear this IP is bad maybe we should look at

it it's actually engineered to be more efficient on IP based rules and other uh non guaranteed indicators so that's kind of an interesting detail from literally talking with developers last year at security onion con right after security onion con based on the emerging threats guy who's finally getting that one of them in the room and having the conversation of why do you do IP based wools for snort they're awful in design they don't work very well and oh we're primarily cata is cata designed for that I don't know it was a sales guy kind so ended up contacting some of the Developers for cata turns out they do prioritize IP based rules way more than say uh others so one of

the first things in analysis stack was IP based rules seems reasonable it's a different methodology um Source fire and Cisco well sourcefire says if you have an IP based Rule and you think it's bad that's called a firewall rule yeah lock it but eh I don't know to me once you've gotten your known threats that's when you can start to take care of maybe this is bad so there's place for both but one is better one component one is better than another so security engineering is kind of hard it's a little complex kind of like this right so which logs are helpful kind of an easy question once you've been in a sock World a while but

when you start looking at how to configure snort it can be pretty daunting there's roughly 2,000 lines of configuration for snort in addition to the 30,000 or so available rules so that's a lot of information a lot of choices and the documentation once you know all about it it can be a decent enough reminder but it doesn't really teach you how to use the product how to configure it in either snort or sharata both running this problem as a matter of fact even while working at source fire and after the best documentation I've seen for how snort is designed comes off the personal blog of somebody who never worked in engineering he worked in product

support he ran I know this is unreadable at this distance um blind seeker.com swiki has this lovely chart literally goes through the components of house snort processes traffic piece by piece this is the only document I have seen that goes anywhere near this much detail on how detection works at What stages certain things get thrown out when certain components uh analyze traffic and depending on how or what component has an issue with traffic where it detects where it drops where it Falls over and then again this is off a personal blog there was no document remotely close to this while I worked at source fire and my friends who are still there tell me they still haven't seen

anything like it so kind of a hard problem when you really don't have documentation for design on how things work so deployment kind of a another fun detail obviously security onion fan favorite here um is one of the deployment options out there comes as an ISO really if you're going for production um the iso is not so great you have six different guies do you really want a VM with six goys with all your company's protected data and security are you really going to go through changing all the passwords for all the goys all the databases everything thing the P there is a way to distri uh deploy security onion via a package so you choose the packages you

want please love a God do not deploy the iso in production for protection of your organization um I know there's Guides Online of how to do it with the package system it's way better uh Rock NSM is another tool similar to security onion uh couple of differences in that they chose one guey one database uh or one database Tool uh they have all the things together and they added Google steganographer which is kind of a cool open source free pack uh full pack capture tool um and then Autos snort same guy who did the design uh made a tool where you set up your system and then you run his script and it will download and install all the tools uh

snort you choose a goey you choose thing so much easier I don't know different deployment options so steps forward when you go back to your organization get them get the sock to start to really look at what's in their Network and start to look at what are the things that are causing us the most tickets if you have more tickets than you can manage like most everybody solving that problem of okay 10% of our tickets are this particular rule it's good place to start um does anyone have any questions yes

sir I would probably never deploy all the rules at once there's too many that aren't applicable the environment um P pork is a lovely script that allows you to categorically decide what rules to use what rules not to use um I normally would start with one of the predefined policies so there's three available uh security over connectivity connectivity over security and balanced and then turn on and off categories and Rule types based on that um and I turn off there's a bunch of really annoying ones things like Echo requests p Echo reply these aren't useful rules um unless you're just trying to drive yourself insane so there's just lot of those rules and so turning it on get starting with what you

think is about right and going adjusting from there turning on specific threats you are concerned about and certain ones you aren't by OS by application it's a good place to start um it is a living process it is something that takes a sign ific amount of time to work on other questions yes

ma'am so that's not necessarily particular to an IDs but more basic network analysis uh that's something that's learned there's not really a great mechanism to learn how to identify good vers bad yet um um it's kind of one of the hard problems of the sock world and finding an answer is kind of like how do you learn decision-making right that's not a uh question that I can answer in a minute I'm still working on how to figure out what the best way to teach uh basic network analysis as far as is this bad or not it's not an easy problem so that's a different problem that's not a stage of how far in an out in ability

to see your sock is that's more around um your people specifically do they have the skills right this is more maturity of an overall sock rather than maturity of individuals if someone in the sock can't figure out how to detect if traffic is bad that's more of a fundamental people problem um and I know a lot of the way that people start is literally jump in and hope you don't drown again that's a large problem for the sock community that we haven't had answered a lot of it is keep going analyzing that particular traffic until you know what it is if you don't know what it is figure it out first the tenacity to do that is

hard I'm out of time here I think uh I will be around after um as far as understanding what know Bine [Music] give this