 The advanced uses, but the last thing is probably the most important and that is that intrusion detection is not a process, I'm sorry it is a process it's not a product. You'll have to forgive me on the slide there, I'm a stand-in so I was struggling to get this presentation together. Really first off what is intrusion detection and it's the ability to detect attempted break-ins, anomalous behavior and some system misuse-age. And really in the host space world what we see there is file integrity checking as well as audit log monitoring and then of course on the network side we see monitoring of network communications. As far as capabilities are concerned we really have monitoring, recording, notifying, reacting and then of course archiving. And if you look at monitoring you're looking at all of the traffic that is passing a particular network segment as well as on the host side the ability to review host audit logs. What you're ending up doing is having a set of signatures that goes and records things when it sees particular signatures matched. And then of course depending on the policies that you have set in place when it sees a particular event that is matched it can alert an analyst or administrator. This allows the administrator to react dynamically to a situation that might be putting your information resources into a precarious situation. And then lastly of course is keeping that information in archive format so that you can go back for not only prosecution support but so that you can go and do data mining and event correlation. So I like to think of intrusion detection especially network based intrusion detection is the ADT of information security. It just kind of sits and watches for you. It's a misuse based system and really what that means is it's looking to recognize patterns and signatures. This is really the majority of the systems that are out there. NFR securities, NFR product, ISS, Snorts is also written this way. The one thing to note about these systems is that they're really only as good as the programmers who are writing the signatures. So if you have a lot of signatures and they're not very vague then you can get a fairly robust system and not collect too much information. We'll get to anomaly detection in a little bit and then I can answer questions about that. But for the most part just as an upfront you tend to see anomaly detection in government organizations as well as research organizations that have the resources and time to go through and actually do some types of data mining to see more information like that. What intrusion detection is not is a fix-all. A lot of people seem to think that if they have an intrusion detection system that it's going to tell them that someone's trying to break in and that it'll be alright. But that isn't the case. Just like a vulnerability scanner it's telling you that the vulnerability is there or it's telling you that someone is trying to exploit the system but it's not patching the whole. Additionally it's not a firewall. It does not control access in most cases to particular information resources. There are configurations in which you could issue a TCP reset to try and kill a session but generally speaking you don't want to dynamically reconfigure security controls based on intrusion detection. And of course it's not a perfect system. It's prone to false positives and can be somewhat complicated to use as well as fairly immature. In complimenting your existing security controls it's really adding another level of security. I like to think of I like to think of people's organizations from a security standpoint as being like an M&M. It's hard and crunchy on the outside but kind of mushy on the inside. And so when implementing intrusion detection you're adding another layer of security. It also operates in near real time. Obviously there is a certain amount of latency that occurs when you have a system that matches patterns and then sends an alert. But for the most part we consider it to be a real time a real time system. Additionally you can use intrusion detection as a check and balance for security configurations especially things along the nature of firewalls. If certain types of traffic are getting through your firewall that you hadn't intended and your intrusion detection system can pick it up then that would be your check and balance. When you first install intrusion detection systems whether it be network or host or file integrity checking it allows you to get a baseline of information to get a good picture of the security posture. And then of course intrusion detection also allows you to adapt to changes more quickly. Like example I was working for an insurance company when the Melissa virus came out and so we took our intrusion detection systems and wrote a signature so that when it saw the subject header of Melissa that it would issue a TCP reset and it would kill a number of the attempted emails. And then of course ad hoc security needs if you think that there's someone who's looking at a lot of offensive material on the internet you could write signatures to specifically monitor them. So what about your firewall? Intrusion detection complements firewalls in that firewalls provide access and intrusion detection systems allow you to recognize the types of traffic that come in. So a good example would be people that are coming to the con today as they walk into the lobby. They have their badges so they're allowed to come in. That's kind of their access. However they could be carrying a backpack that contained tear gas or firearms or something that could be very harmful to the other attendees and in a real life scenario that could be applied to intrusion detection. So firewalls allow for the right access such as HTTP going through port 80 on a firewall to get to its end host but if it's a malicious string then intrusion detection would be able to pick that up. And then of course intrusion detection isn't just for the perimeter. It can be used on any network segment that has critical information resources or anything that you might want to monitor. So here's your typical firewall log has the date and time and it just kind of says which ports it's going which ports network traffic is going through whether it allowed it or not. And then of course you have off an old dragon display a little bit more information. So this is giving you that it saw SSH version one and some of the information tied to that. Sometimes I like to refer to intrusion detection with the fence analogy really fences protect perimeters a lot a lot along the lines of the way firewalls do but they don't detect suspicious activity and that's what intrusion detection systems do. This goes back to this goes back to the discussion about people coming into the con and what they might bring. So if you don't know what they're bringing but they have the right access that's operating like a firewall whereas if you could see the contents after the access then that would be more like intrusion detection. So now getting into the components of intrusion detection you really have the data collectors a repository in which to keep all your information and then a means by which to display that and then finally event notification so you know what to do with what you're seeing. The different types of intrusion detection systems first you have the misuse based and that's their program for specific use and what you end up having is attack signatures and these attack signatures are written to see different things on the network or different types of behavior on the host and then of course you have anomaly detection and that's something that's looking for things that are more difficult to find for instance you're looking at slow and low attacks or you're looking at the types of users who log on every day from nine to five but then last Tuesday they were on at two o'clock in the morning. So it's much more event trending and correlation and you get into data mining and then of course at the very high end level you have organizations that are now starting to get into using artificial intelligence. There are really three very popular methods of deploying intrusion detection. The first is the network node based intrusion detection which works very much like your regular network probe in that it sits out on the network and it looks at the traffic however it's deployed on a specific host and it only monitors traffic inbound to or outbound from that host. Most everyone is familiar with is the network based intrusion detection where you would have a very inconspicuous probe sitting out on the network that had a stealth interface and it monitors an entire network segment and then finally host based intrusion detection which is also deployed at the host and monitors audit logs and things of that nature. So really the pros that you get with the network node intrusion detection is you're getting the benefit of having the network intrusion detection at the host. It's unconcerned with bandwidth issues because it's not looking at the entire network and depending upon where in the stack encryption is you may be able to work against some encryption. Unfortunately since it is network based intrusion detection it really isn't telling you what the impact on the host is. It's not telling you if critical system files were changed whether or not the systems vulnerable and then of course there's issues of scalability if you're going to if you're going to implement a piece of software out on each host in your network you're going to get into a situation where it may not scale. Network pros and cons I'm really really torn on this because I worked with network based intrusion detection for a number of years and it's just failed me so many times but basically what you've got is the ability to ability to have something that's kind of more bang for your buck. It goes and it monitors an entire network segment. It has no fingerprint out on the network so long as you're operating with a stealth interface and then you've got you know another management interface on another network. The problem with this at once again is that it's unaware of whether or not an attack is successful. Once you start getting into higher bandwidth it starts either dropping packets or it's not fast enough to process everything it's seen so it may get all the packets but it's not detecting all of the all of the exploits. The host based on the other hand is aware of what the system impact is and of course it's it's unconcerned with the bandwidth because it has nothing to do with the network but once again now you're you're losing the network aspect in that you're only looking at system audit logs and accounts and of course because it's limited to one host you get back into the scalability issues. As far as variations of architecture concerned there are there are really four and your first is your stand alone and that would be something where you would have to go out and individually or independently log into each monitor that you had in order to extract the contents of it. This is normally something that you would see deployed in a very large or I'm sorry a very small environment that didn't have money to spend and of course in this type of environment the event correlation becomes extremely difficult because you don't have a centralized data repository for everything to come back to. Generally speaking in a distributed system where you have products such as ISS or Accent or CyberSafe even for the for the host piece what you have is multiple agents reporting back to a command console and that command console can push down information and it makes it easier to correlate events but the problem there is you've got you've got a one to many relationship it's two tiered it's not truly three tiered and so you're only allowed to operate with one analyst at a console at a time and so an ideally distributed environment would be having many agents whether they be host network network node file integrity checking reporting back to a central data repository and then having something such as a GUI client sitting out at your analysts desktop so that they could easily log in and pull all of that information. Then of course I mentioned managed environments because I used to work for a managed security service provider but basically here in this type of environment you have dedicated analysts who do this all of the time those organizations are also held to specific service level agreements for response as well as data archival. There are certain economies of scale because you are utilizing shared architecture and then of course it's minimal network overhead and then finally you know it's it's it's very distributed it gets back into talking about the shared architecture and it's outsourced. As far as architecture concerns with the network base you really need to worry about the bandwidth as we get into faster and faster networks. A lot of the network intrusion detection vendors tout that they can do a hundred megabit or even faster and it's true that some of them are starting to get there but it's still an issue the faster the faster the network the more resources it's going to consume and more difficult. Security is also an issue because when you're having numerous hundreds thousands of agents reporting back it can take up it can consume network overhead as well as consume some of your resources. Network fingerprint it's not really a concern for your network probes that are out there so long as you implement them with a stealth interface but you do see somewhat of a fingerprint with the with the host base and then of course you want to ensure that you've got a reporting back end so that you can gather all of this information and produce something useful for management not only to get more money for the initiative but also so that you can fine tune the systems that you have in place and pinpoint where trouble spots are. Oftentimes the oftentimes implementing intrusion detection becomes segment specific because it can be cost prohibitive. Additionally you need to look at the types of network traffic that you're seeing especially when you want to implement network intrusion detection on something such as a public services network then you could really tune the system to the types of network traffic types of network traffic that you've got as well as operating systems in the applications you have in play there such as DNS or HTTP and things along those lines. There's a lot of debate as to where the best place to deploy intrusion detection is concerned I will offer that you can deploy it to watch the internet or extranet PSN is many people refer to it as a DMZ but by the very nature of the word demilitarized zone it's saying that there's no control whereas most people have public services networks where they have services such as web and DNS and SMTP that is controlled so for the purpose of this presentation I'll just call it public services network. Internal key network segments such as server farms and then of course anything on critical hosts you could implement the host based in the network node based. Really when when implementing on your external or extranet segments you're kind of looking at suspicious activity detection this would be especially true in looking at all of the information that's hitting your firewall and that's hitting your perimeter. Some people would say that well I've got the firewall to block all of this I don't need to see it but since I'm so paranoid I like to see everything that's coming in my network. It's easier to deploy the network intrusion detection on external and extranets unless of course you've got a DS3 or something but normally these tend to be slower links and so you have lower throughput and the devices are able to keep up better. Of course it's not just for the internet and then as I was saying you know I like to put it outside of my firewall the internet or extranet as kind of a catch all to see everything that's coming in. The internal really depends on and when I say internal I'm talking about RFC 1918 addresses oh that's nice my battery is charged. So I'm talking about the internal users in your corporation or firm and it completely depends upon the threat model whether or not you want to monitor what they're doing. Some people choose that they want to do event correlation with the external see what gets through the firewall and then compare the two. Once again that could be considered a check and balance. The way I like to use it is not look at anything coming into that particular network but watch everything that's going out from that network and see where my internal users are going. Of course on the internal network there's always a higher exposure to bandwidth. Little technical difficulty. Okay your critical your critical network segments and public services networks. Here is where you want to focus monitoring on the systems themselves so that would mean implementing host-based intrusion detection looking at key operating systems whether you've got you know 2000 Solaris HPX AIX specific applications the types of traffic you want to be able to narrow it down as much as you can because of the exposure to high bandwidth so this would be an excellent place to implement host-based intrusion detection. And of course we were talking about this earlier but generally speaking the way I like to implement intrusion detection would be to watch everything coming out my network from the internet kind of as a suspicious activity monitor. Watch everything coming in from my business partners because my first responsibility is to protect my own organization. There are some legalities or ethical issues related to ensuring that you're protecting your business partners but my first concern is making sure I'm protected from my business partners as opposed to protecting my business partners from anything else. Additionally as I mentioned earlier I like to watch everything that's going out of my network and then of course I like to watch things that go in and out of my DMZ because I really don't want to see anything initiating from my DMZ I only want to see it responding and of course I would put host-based agents out on the servers on that particular segment. As far as NIC configuration is concerned I had mentioned this a couple of times earlier in the presentation so I'll cover it in depth now. With network-based intrusion detection you really have three ways to go about configuring it there's the dual NIC configuration with a stealth interface so basically you would give it an all-zero IP address and then do an ARP-S and you would end up having a stealth interface and then on the other side you would have either most likely an NRFC 1918 address that went back to a monitoring network so essentially since there's no IP a stack on the stealth interface it's operating in promiscuous mode and the device is essentially broken so someone from the outside is not going to be able to hack through that device to get into your management network. Another type of configuration would be dual NIC without the stealth interface maybe perhaps you want to look at two different network segments on your internal network and you think that the threat isn't such that people will be trying to break the device and then the last would be a single monitored managed interface so you would be basically you would be running in promiscuous mode but you'd also be using that as your management interface to connect to the device. It's important to start looking at false positives once you get your intrusion detection devices up and running it'll give you ideas on how to better design your solution so that it's more intelligent it'll also allow you to better understand the types of services and applications you have running on your network and then again as I mentioned earlier it gives you the baseline of your performance and then by which you can make adjustments and then finally really knowing your level of readiness where you at as far as your security posture is concerned and the types of things that you have going on your network. Data archival is extremely important essentially you have data being saved on the agent and then that agent is sent back to hopefully a central repository. This is the best place to put it to have all of your information resources all of your intrusion detection and having that all come back to a central repository because it eases event correlation it gives you an easier way to look at that information and to make decisions about that it also allows you to make solid backups if all your information is in one place then it's much easier to back up as opposed to running 15 different backups or even hundreds of backups on agents every night. And then lastly of course if you have this gigantic database it gives you the ability to run data mining tools and to do some of the advanced event correlation as well as perform some of the analysis. Custom configuration is really what I'm getting at here is the ability to go in and custom configure any type of misuse system you certainly don't want to buy a system that's not going to allow you to go in and use standard notation and be able to fine-tune the device be able to enter in networks that you want to ignore or wildcards something along those lines because what invariably happens is you get way too much information and when you have too much information it becomes overwhelming for analysts and then they just start ignoring it. Additionally it gives you added functionality and freedom and that comes back to reducing the information. And finally with the ad hoc security needs this would allow you to do something along the lines of create a signature that allowed you to look at the subject line of an email and then of course perhaps issue a TCP reset to try and kill that session. There are different types of custom attack signatures not getting too far into it but you have Unix scripting and a lot of that would be it would be snort proprietary languages intrusion.com's SNPL, NFR has encode, accent has their own language as well. Other products allow you to give a windows based interface where you enter characters or wildcards something along those lines. As far as tax signature creation you really have to be able to take an exploit and compile it in your labs, run the exploit and capture packets and when you capture these packets then you can analyze them for what looks to be an anomaly and then of course when you do that then you can begin to author the signature and the chosen language that you want and once you write that then you can put it into your system and integrate it and see what happens. Here's an example of what I would call a Christmas tree attack and basically what that is if you look in the first 20 bytes of your IP packet where all your flags are at the Christmas tree attack which is old and very basic would be having all of your flags set so you'd have your urge and your act and your push and reset and sin and fin. That's never supposed to happen in anything other than a lab environment so in this particular case you would generate a packet that looked like this and then capture packets using ether rail or whatever you'd like and then you would generate an attack signature that looked for that specific activity. Then of course this is a fairly generic example of a snort signature basically you've got your rule header which is saying you want to alert anytime you see a TCP packet that's sourced from and destined to the following and then of course you use your rule options and so this is a buffer overflow here, Mount D buffer overflow. Some things that people try and do for intrusion detection avoidance for some of the less robust solutions would be to well the example here is the finite nature of attack signatures if it's looking for root in a particular attack signature that's the way it's been programmed then on the command line if you enter you know R03 times and then a backspace and then a T that doesn't exactly match what it's looking for and that would be one way to a very simple way to get around a system. There are still systems that are based like that that actually look at text rather than context. Another thing most products I have actually progressed to the point where they're fairly adept at decoding hex but for a very long time products could not decode hex on the fly and so if you the old IIS colon colon dollar data exploit if you wrote that out in hex you could easily bring down an IIS server and then of course a lot of the products are becoming better with this as well but being able to reassemble TCP packets that are fragmented that used to be a very very efficient way of getting around network based intrusion detection and one of the products that did that very well was a frag router by Doug Song and then of course we really need to think about usable reporting what types of reports are useful to us you know are we looking for top talkers are we looking for event by priority the types of things that become important to us are really independent based on one organization to the next and of course things to think about how often do you want the reports I've seen reports run on a daily basis for event by priority and then of course kind of a weekly summary and even a summary monthly summary at times the key thing is really what do you what do you do with these reports oftentimes you hand someone a report and they don't do anything with it so the daily reports tend to be much more technical in nature where you give those to your analysts and they can go in and analyze traffic and make changes to the system and that whereas your weekly summary reports are something that you would give to executive management where they say oh my gosh I can't believe that somebody tried to hack us and it was 500 times so and you know the last thing is really are the reports read and oftentimes I found that they're not so when you put in pretty pictures then executives usually read them incident response is something that goes hand in hand with intrusion detection so I'll just briefly talk about it here but you really need to have the policies in place oftentimes I've worked with clients to implement intrusion detection solutions and then something happens and they say now what and they're really not sure what to do and so that's something that needs to be defined up front before you get into installing the systems is having the policies in place and your incident response plan is an extension of your security plan it has everything to do with what's important to you in your security plan if you decide that you want to be notified every time someone fails their login three times then that's reacting to that as an extension of the security policy and of course that goes along with what do you do when you see specific traffic how do you rate the severity of an alert and then of course finally possible data forensics touching on event criticality briefly it depends on a number of factors most importantly I would say your security policy and what you've deemed appropriate and important to you what types of intrusion detection that you have employed is going to determine the type of information that you receive back as far as the different levels of an attack are concerned this gets back to the policy this gets back to the types of operating systems and applications you have running on your network you know what's important if you're if you are running if you are running IIS and someone launches an Apache exploit against you it's not going to be very important but if it were the other way around then all of a sudden it would become pertinent so really this is a I would say that this is probably my graphical stolen version of North Cuts criticality metric in in his first book basically what you've got as far as criticality is concerned is you've got your non-focused exploitable attack it's not really something that you're interested in being notified about there's not much not much harm that's going to happen of it so it may be something that you want to report on or saving your systems in case there are other related attacks for your yeah absolutely if someone decides that they're going to if someone decides that they're going to do a random net cat scan of your public services network and all you have is Unix devices it's random so it's not focused and second sure so it's it's random and then the other thing is it's it's not something that's exploitable number two it would be more reconnaissance work people that are looking to gather information about your network they're digging on your DNS they're doing you know they're doing and map scans they want to know what kind of operating systems you have that's definitely something that's higher up on the priority list then of course when people start jabbing at you you know it may be may be random but it is something that could be exploited on your network or the other way around it could be very focused but not exploitable that's something where you really want to start watching what's going on in your network in real time and then start possibly notifying people in your escalation procedures or even a client if you're doing this for someone finally actually not finally you have your focused exploitable this is where you want to immediately contact the business unit to that would be responsible for this information resource certainly something you want to be report on and then of course finally level five is extreme danger focused you know that the system is vulnerable it very well could have been compromised it looks that way judging from your host-based intrusion detection systems you want to immediately notify either the internal or client contact and then begin to to perform either information incident response or disaster recovery and then lastly just kind of throwing this in here is really assessing what your needs are when you're choosing an intrusion detection product there are products out there that are very expensive there are products out there that are open source that require a lot of time in coding and understanding so how robust do you want it to be do you want to spend a lot of money and use half the features or is it something that that you can get away with spending less money and certainly demo the products being able to conduct all of those comparisons to see the different types of things erecting a erecting an intrusion detection lab is is not it's not a huge feat but it does require that a lot of different systems are in there so that you can actually generate the bandwidth necessary and be able to perform exploits on devices in there so you can find out which systems are picking up and which systems aren't and then of course grill the grill the vendors and that's it thanks