IDS mailing list archives
RE: Target based IDS review and discussion in Information Security
From: "Craig H. Rowland" <crowland () cisco com>
Date: Tue, 13 Jan 2004 13:36:57 -0600
Hi Marty and List,
Hi Craig, Very quickly, I'll touch on a couple things. I really don't want to turn this into a big thread if at all possible.
No problem. This will be my last post on this for a while. Discussions like this are often only resolved by users deciding what approach suits their needs the best.
[snip]For example: 1) A URL attack is seen by the sensor affecting Windows IIS. 2) A check is made if the attacked OS is Windows. 3) A *low-impact* external assessment is made if available. 4) If Windows, then log onto the host and check forrelevant hotfixes,patches, etc. for the vulnerability. 5) If the system is not patched, retrieve the log files andsearch forsuccessful signs of the attack. 6) If the attack traces are found in the log, then escalatethe alert.7) Administrator can view the chronological event log wegenerated ofeach and every step we took to investigate the attack (from IDS detection to final resolution and reason why weupgraded/downgraded).8) Administrator can view the actual log files retrieved from the impacted host to manually verify if the attack wassuccessful or not.(The above process happens in a very fast and automated fashion.)[snip]So in the definition of target IDS generally given you'd be able to only accomplish steps 1-3 reliably (step 3 may not be low-impact) and perhaps step 4 patch checks with certain Windows probes. Howeversteps 5-8 aretotally out of the question. That's why we don't follow thetraditionaltargeted IDS philosophy. I think admins want more concretedata aboutsecurity incidents on their network and deeper automatedinvestigationsare required to handle this task.The problem is that if you don't do prediscovery you can't trust the information you get back after the attack. Once the host is compromised you can't believe anything it tells you IMHO.
However both active and passive prediscovery fail in a number of cases: 1) On very large networks often scanning large numbers of hosts will take too long and be too disruptive. 2) On networks that are very dynamic with a lot of DHCP, VPN users, or people moving between wireless access points, the data becomes stale quickly. 3) On systems where users made changes to the config that don't show up on the network until attacked. 4) Background changes and updates to network systems through automated patch distribution systems, etc. 5) ... It's been our experience that most attacks/attackers leave traces on systems that can be spotted even though the system itself may be compromised. Even if the root attack can't be seen, the system config/state often reveals it was likely the attack worked. Automating the investigative process also gives administrators an advantage because they rarely know everything to look for to validate detected attacks. Heck, I've been doing this stuff for over a decade now and the last few years have seen so many new attacks come out that I don't even pretend to know them all any more, let alone what to look for on a host for each and every one. That's why this problem needs automation in a big way. By automating the process of investigation you bring consistency and repeatability even if your admin staff have different levels of experience dealing with these issues. With CTR we can say "We looked at this box and it wasn't patched against this attack and here are the log files from the system so you can see what was reported yourself." Lastly, the gap left between a reported attack (even one that was validated with prediscovery) and the time the admin does anything is critical for response purposes. Every second, minute, hour, day, the attacker is left alone on the computer without admin action is serious business. CTR helps reduce this window of opportunity because we will, when warranted, quickly grab system logs and other data from the host in real-time. If the admin isn't around to do anything at the moment, at least they have a set of data that wasn't laying on a host being edited by the attacker to cover their trail. If we reported that file X was present and patch X wasn't applied and then suddenly the admin looks and it's gone and the system is patched, well they better be suspicious that something is wrong.
I think you miss quite a bit of data just watching the wire and not connecting to the host and see what is going on directlyfrom within. How about in the case of welchia? The host gets popped and the vuln is patched in one shot, step 3 fails and the system is none the wiser. In
This was just one example. The checks may look for different issue depending on what the attack is. So for instance on certain Trojan horse activity we may check for known suspicious registry keys and dropper files, etc. It varies. Also Welchia leaves plenty of information around to see something happened even if the system appears patched. In this particular case though the worm would have had to download and apply the hotfix within the 1-2 seconds it takes for CTR to connect to the host and look around. In this instance we don't have a Welchia agent directly created because this likelihood is pretty small and the detected signature applies to multiple attack possibilities.
the event of a successful overflow or other admin/root granting remote attacks, the configuration of the host after the attack may be nothing like what's required to elevate your level of suspicion.
Possibly and I'll go one further: As the CTR methodologies become more ingrained in the Cisco architecture we're expecting attackers to adapt their techniques to counter our current techniques, etc. The moment attackers begin altering their methods to defeat CTR (or other targeted IDS methods) is an indicator of success in the battle. You forced the opponent to change strategy which happens all the time when effective countermeasures are used. I would never (and I doubt you would) say that counters won't evolve to bypass *any* security product, in fact effective security means new attacks will emerge (and helps ensure our job security). If attackers suddenly gave up one day it would make things really boring and frankly I think many of these attacks are clever even if they are keeping us all up over the weekends. When the attacks change, so will CTR (and other solutions). However, in the same vein an attacker could also have their attack initiate a DHCP release/renew, grab a new IP address, and initiate an encrypted back channel communication out to the attacker over the HTTP SSL port. This would completely bypass data collected actively/passively by a TIDS as the system has a new IP. When the admin went looking for the affected host they may not find it out of hundreds (thousands) of addresses in the DHCP pool. This is of course assuming the admin even knows what to look for given the number of attacks that exist now. So all approaches have their potential weaknesses...
This is why we are focusing on automated attack investigation and response. Doing straight targeted IDS doesn't always provide the answers people want and isn't capable of directlycollecting forensicinformation from the affected host for automated or manual investigations.Automated forensics are useful and a nice step forward but if the attacker evades the IDS or disables the forensics systems once he's on the host then you've got a problem. The methodology described also reveals a lot of information about the security posture of the site that's being hit (i.e. Cisco CTR is in use) and what countermeasures are appropriate to reduce the chances of being detected in the future. In the worst case it could also be used to suggest what the configuration of the IDS is...
CTR doesn't have any presence on the host (we currently use ordinary login credentials like any other user) so there isn't a local agent to disable. This was a deliberate design to ensure the attacker has as little knowledge of possible as to what protection the host has, what CTR may look for, and how they may go about avoiding detection. However, as pointed out above, I think all approaches have limitations given the ingenuity of attackers. I'd expect administrators worth their title to apply security solutions in layers for maximum effect. Doing otherwise is a serious mistake. This probably means a combination of products.
So perhaps the definition of targeted IDS should expand to include actual on-host investigation techniques, or wecan create anew buzzword to encompass what it is that CTR actually does above straight targeted-IDS.Automated network forensics? I think TIDS has a concise definition right now, I'm not in favor of extending it.
That's OK. I'll let the marketing guys come up with something. I'm not really good at this stuff. Thanks, -- Craig --------------------------------------------------------------------------- ---------------------------------------------------------------------------
Current thread:
- Target based IDS review and discussion in Information Security Joel Snyder (Jan 08)
- Re: Target based IDS review and discussion in Information Security Martin Roesch (Jan 09)
- Re: Target based IDS review and discussion in Information Security Joel Snyder (Jan 09)
- Re: Target based IDS review and discussion in Information Security Jeff Nathan (Jan 12)
- RE: Target based IDS review and discussion in Information Security Craig H. Rowland (Jan 12)
- Re: Target based IDS review and discussion in Information Security Martin Roesch (Jan 13)
- RE: Target based IDS review and discussion in Information Security Craig H. Rowland (Jan 13)
- Re: Target based IDS review and discussion in Information Security Ron Gula (Jan 13)
- Re: Target based IDS review and discussion in Information Security Joel Snyder (Jan 09)
- Re: Target based IDS review and discussion in Information Security Andy Cuff [Talisker] (Jan 12)
- Re: Target based IDS review and discussion in Information Security Martin Roesch (Jan 12)
- Re: Target based IDS review and discussion in Information Security Martin Roesch (Jan 09)
- <Possible follow-ups>
- Re: Target based IDS review and discussion in Information Security Richard Bejtlich (Jan 13)
- RE: Target based IDS review and discussion in Information Security Teicher, Mark (Mark) (Jan 13)