Incident Severity Ratings

Much of digital security focuses on pre-compromise activities. Not as much attention is paid to what happens once your defenses fail. My friend Bamm brought this problem to my attention when he discussed the problem of rating the severity of an incident. He was having trouble explaining to his management the impact of an intrusion, so he asked if I had given any thought to the issue.

What follows is my attempt to apply a framework to the problem. If anyone wants to point me to existing work, please feel free. This is not an attempt to put a flag in the ground. We're trying to figure out how to talk about post-compromise activities in a world where scoring vulnerabilities receives far more attention.

This is a list of factors which influence the severity of an incident. It is written mainly from the intrusion standpoint. In other words, an unauthorized party is somehow interacting with your asset. I have ordered the options under each category such that the top items in each sub-list is considered worst, and the bottom is best. Since this is a work in progress I put question marks in many of the sub-lists.

1. Level of Control




• Domain or network-wide SYSTEM/Administrator/root


• Local SYSTEM/Administrator/root


• Privileged user (but not SYSTEM/Administrator/root


• User


• None?




2. Level of Interaction




• Shell


• API


• Application commands


• None?




3. Nature of Contact




• Persistent and continuous


• On-demand


• Re-exploitation required


• Misconfiguration required


• None?




4. Reach of Victim




• Entire enterprise


• Specific zones


• Local segment only


• Host only




5. Nature of Victim Data




• Exceptionally grave damage if destroyed/altered/disclosed


• Grave damage if destroyed/altered/disclosed


• Some damage if destroyed/altered/disclosed


• No damage if destroyed/altered/disclosed




6. Degree of Friendly External Control of Victim




• None; host has free Internet access inbound and outbound


• Some external control of access


• Comprehensive external control of access




7. Host Vulnerability (for purposes of future re-exploitation




• Numerous severe vulnerabilities


• Moderate vulnerability


• Little to no vulnerability




8. Friendly Visibility of Victim




• No monitoring of network traffic or host logs


• Only network or host logging (not both)


• Comprehensive network and host visibility




9. Threat Assessment




• Highly skilled and motivated, or structured threat


• Moderately skilled and motivated, or semi-structured threat


• Low skilled and motivated, or unstructured threat




10. Business Impact (from continuity of operations plan)




• High


• Medium


• Low




11. Onsite Support




• None


• First level technical support present


• Skilled operator onsite

Based on this framework, I would be most worried about the following -- stated very bluntly so you see all eleven categories: I worry about an incident where the intruder has SYSTEM control, with a shell, that is persistent, on a host that can reach the entire enterprise, on a host with very valuable data, with unfettered Internet access, on a host with lots of serious holes, and I can't see the host's logs or traffic, and the intruder is a foreign intel service, and the host is a high biz impact system, and no one is on site to help me.

What do you think?

Read More

Marcus Ranum Highlights from USENIX Class

Because I was teaching at USENIX Security this month I didn't get to attend Marcus Ranum's tutorial They Really Are Out to Get You: How to Think About Computer Security. I did manage to read a copy of Marcus' slides.

Because he is one of my Three Wise Men of digital security, I thought I would share some of my favorite excerpts. Some of the material paraphrases his slides to improve readability here.

• Marcus asked how can one make decisions when likelihood of attack, attack consequences, target value, and countermeasure cost are not well understood. His answer helps explain why so many digital security people quote Sun Tzu:
  
  The art of war is a problem domain in which successful practitioners have to make critical decisions in the face of similar intangibles.
  
  I would add that malicious adversaries are also present in war, but not present in certain other scenarios misapplied to security (like car analogies) where intelligent adversaries aren't present.


• Marcus continues this thought by contrasting "The Warrior vs The Quant":
  
  Statistics and demographics (i.e., insurance industry analysis of automobile driver performance by group) [fails in digital security] because there is no enemy perturbing the actuarial data... and "perturbing your likelihoods" is what an enemy does! It's "innovation in attack or defense. (emphasis added)


• Marcus offers two definitions for security which I may quote in the future:
  
  A system is secure when it behaves as expected; no less and certainly no more.
  
  A system is secure when the amount of trust we place in it matches its trustworthiness.


• Marcus debunks the de-perimeterization movement by explaining that a perimeter isn't just a security tool:
  
  A perimeter is a complexity management tool.
  
  In other words, a perimeter is a place where one makes a stand regarding what is and what is not allowed. I've also called that a channel reduction tool.


• Here's an incredible insight regarding the many "advanced" inspection and filtering devices that are supposed to be adding "security" by "understanding" more about the network and making blocking decisions:
  
  At a certain point the complexity [of the firewall/filter] makes you just as likely to be insecure as the original application.
  
  He says you're replacing "known bugs" (in the app) with "unknown bugs" (in the "prevention" device).


• I love this point:
  
  Insiders and counter-intelligence: What to do about insider threat?
  
  
  
  • Against professionals: lose
  
  
  • Against idiots: IDS (Idiot Detection System) works; detect stupidity in action
  
  
  
  This is so true. I'd extend the "idiot" paradigm further by adding EDS (Eee-diot Detection System). (Cue "Stimpy, you eee-diot!" if you need pronunciation help here.)


• Finally, Marcus slams the idea that one can use an equation to quantify risk. He calls "Risk = Threat X Vulnerability X Asset Value" one wild guess times another wild guess times another wild guess. I agree with this but I would say the concept of separating out those variables helps one understand how Risk changes as one variable changes with the others held constant.
  
  Marcus also offers two approaches to dealing with risk:
  
  
  
  
  1. Think of all possible disasters, rank by likelihood, prepare for Top 10. (9/11 showed this doesn't work.
  
  
  2. Build nimble response teams and command/control structures for fast and effective reaction to threats as they materialize.
  
  
  
  Regarding number one, Marcus obviously thinks that is a waste of time. However, one could argue that if policymakers had paid attention to the intelligence that was available and prepared, the situation could have been different. That's where threat intelligence on capabilities and intentions and attack patterns can be helpful for modeling attacks.
  
  Regarding number two, I am so pleased to read this. It's why I'm building a CIRT at my new job. This comment also resonates with something Gadi Evron said during his talk on the "Estonia Cyberwar":
  
  No one is judged anymore by how they prevent incidents. Everyone gets hacked. Instead, organizations are judged by how they detect, respond, and recover.
  

Read More

Way to Go Joanna

I briefly met Joanna Rutkowska at Black Hat Federal 2006 when she spoke about rootkits. Today I saw she was interviewed by Dark Reading and said the following:

Still, she worries that security technology and research is too prevention-oriented and doesn't emphasize detection enough. "The whole industry is focusing on prevention, and we have all those anti-exploitation technologies, which are very helpful indeed. But I'm so surprised that no one cares about detection," she says. "Every time there's prevention, there is some bypass method" created.

Without detection, there's no way to know if an attacker has grabbed administrative access to a machine, she says. And if you can't see that an attacker has infiltrated the system, nothing in that system will be "reliable" anymore. "The scary part is that once an attacker [gets] into the system, we can't reliably read system memory, neither using software-based, nor hardware-based, methods. That means we can't answer the question of whether the system is clean or not," she says. (emphasis added)

Wow. I am so pleased to read someone of Johanna's caliber stressing the need for detection. I have been working on slides for ShmooCon and I plan to talk about this very subject, and you probably know I've been saying for years that prevention eventually fails. Her comment about reliability of evidence relates to my TaoSecurity Pyramid of Trust, where I mentioned Johanna with respect to her techniques to defeat memory capture.

Read More

Incident Response Clarifications

Recently I posted Five Thoughts on Incident Response. Based on the comments and some blog responses I wanted to clarify what I originally posted. The first three items seemed to attract the most attention so I'll only address those.

1. Anti-Virus is (or should not be) an incident response tool. The emphasis here is on response. I agree that AV is often an incident detection tool, and ideally an incident avoidance tool. However, if you think AV is going to help recover from a totally compromised system, you are probably going to be upset by the results.


2. Your default incident recovery strategy should be to rebuild from scratch. The emphasis here is on recovery. I am not saying your default incident response strategy should be to rebuild from scratch. Your default response strategy should be to investigate to determine how the victim was compromised, what aspects of Confidentiality/Integrity/Availability were violated, and so on. I agree that any response which begins with re-imaging the victim is a recipe for failure.


3. SPAN ports should not be the default traffic access option. I'm standing by this one. The only time SPAN ports are superior to taps is the situation where intra-switch traffic needs to be seen. Otherwise, spend a few dollars and get a product designed to grant reliable traffic access. I'm talking about professional ways to perform incident response here. Hardware is the easiest thing to gain budget for in any organization. It's easier to buy a piece of hardware than it is to send a person to training, or hire new help, or bring in outside consultants, or any other activity that could benefit a security shop.

I appreciate the other recommendations I've seen. These are only a few big thoughts which struck me based on recent engagements. I have over a dozen recommendations in my Network Security Operations class and I think I cover similar material in Extrusion Detection.

Read More

Five Thoughts on Incident Response

Speaking of incidents, I thought it might be interesting to share a few brief observations based on incidents I've worked recently. Please remember this is a blog post. If you expect thorough explanations of these points with footnotes, historical references, arguments to the contrary expertly swept aside, etc., please wait for a future book! :)

1. Anti-Virus is (or should not be) an incident response tool. I am baffled when I see machines compromised, and the owners think a magic signature from their AV vendor is going to save the day. In this day and age intruders who gain kernel level control of a host often disable AV and will not give up the fight so easily. My second point relates to this one.


2. Your default incident recovery strategy should be to rebuild from scratch. By scratch I mean reinstallation from original trusted media and re-installation of applications and data.
   
   Today, in 2007, I am still comfortable saying that existing hardware can usually be trusted, without evidence to the contrary, as a platform for reinstallation. This is one year after I saw John Heasman discuss PCI rootkits (.pdf). I was lucky enough to spend a few hours chatting with John and fellow NGS Software guru David Litchfield after John's talk on firmware rootkits (.pdf). John's talks indicate that the day is coming when even hardware that hosted a compromised OS will eventually not be trustworthy.
   
   One day I will advise clients to treat an incident zone as if a total physical loss has occurred and new platforms have to be available for hosting a reinstallation. If you doubt me now, wait for the post in a few years where I link back to this point. In brief, treat an incident like a disaster, not a nuisance. Otherwise, you will be perpetually compromised.


3. SPAN ports should not be the default traffic access option. I cannot tell you how much time, effort, and frustration has accompanied the use (or attempted use) of SPAN ports in incident response situations.
   
   
   
   • "The SPAN port is already used."
   
   
   • "The SPAN port can't do that." (although it probably can, the network engineer either doesn't know how to set it up or doesn't want it configured to help the security team)
     
   • "Do you see anything? No? Try now. No? Try now. No?"
   
   
   • "You only see half the traffic? Wait, try this. Now you see double? Ok, try now."
   
   
   
   For Pete's sake, buy a tap, put it in the proper place, and stand back while the packets are collected properly.


4. A Linux live CD is not a substitute for a real network security monitoring platform. Upon realizing that Cisco MARS is not an incident response solution, I was desperate to collect some form of useful network-centric data at one client site. In a last-ditch attempt to salvage a bad situation my on-site colleague deployed a Network Security Toolkit live CD on top of a box previously running Linux natively. I was able to SSH into it, mount the local filesystem, and start writing packets to the hard drive using Tshark's ring buffer. This is absolutely making the best out of a mess, which is standard incident response behavior.
   
   I would ask anyone who turns to a live CD for their monitoring needs to avoid the temptation to think Snort on a live CD on spare, old hardware is anything like Snort on properly sized, configured, deployed hardware. Furthermore, Snort != monitoring. Live CDs are fine for assessment work but they are nearly worthless for packet capture. Needless to say I was able to talk my colleague through a FreeBSD installation and was soon collecting data in a somewhat better environment.


5. When you are compromised, you are probably not facing a zero-day exploit unique to you and not capable of being prevented. When you are compromised you're most likely suffering from some fairly modern variant of attack code that nevertheless contains exploits dating back to 2002. For some reason people seem to feel better if they think the incident is caused by some uber elite intruder who saved up his killer 0-day just for their enterprise. In reality someone probably connected an infected laptop physically to the network, or via VPN, and found a way to get a worm or other malware to the segment of the enterprise running "production" machines that never get patched.

Do you have any IR stories or lessons to share? Please post them as comments or write on your blog, then post a link here as a comment. Thank you.

Read More

Non-Technical Means Unearth Best Intrusions

Thanks again to the latest SANS NewsBites, I learned of an interesting trade secret theft case. From the CNET News story:

"John O'Neil, former CEO of Business Engine Software, pleaded guilty in a San Francisco federal court on Wednesday to conspiracy to download and steal the trade secrets of software competitor Niku over a 10-month period...

From October 2001 until July 2002, Business Engine used the passwords to gain unauthorized access to Niku's systems more than 6,000 times and downloaded over 1,000 confidential documents containing trade secrets, the complaint alleged. The stolen documents included technical specifications, product designs, prospective customers, customer proposals, client account information and pricing.

Niku discovered the break-in after a Business Engine salesman made an unsolicited call to one of Niku's prospective clients, a Nike employee who happened to be related to Niku's chief information officer, Warren Leggett. The call raised suspicion because the Nike employee was not ordinarily responsible for software purchasing decisions, had never heard of Business Engine and had no idea how the salesman had obtained his contact information, according a declaration by Leggett.

The incident prompted Leggett to examine his company's computer logs and files from his recent meeting with Nike. He quickly determined from a trail of Internet network addresses that someone from outside the company had been stealing files. Leggett was able to trace the intrusions back to Business Engine by using Internet domain registration information and publicly available Internet tools." (emphasis added)

Whoa. Niku has been 0wn3d for 10 months, and accessed "more than 6,000 times," before a freak family relation caused the right gears to mesh. What kind of security did Niku have (or not have) that would let a compromise continue undetected and unimpeded for so long?

The sad fact is that many of the most interesting intrusions (i.e., not worms, or bots, or viruses) are discovered by non-technical means. Once a company is clued in to the fact they have a breach, the question becomes one of scoping the incident. For example:

• What happened/is happening?


• What systems are or may be affected?


• What information did the intruder copy, change, or destroy? (violations of confidentiality, integrity, or availability)


• When did the intruder first gain unauthorized access?


• When was the last time the intruder accessed victim systems?

Most organizations are not collecting the NSM data they need to answer these questions. Is yours?

Read More

Investigating the Paris Hilton Incident

More details are emerging regarding the Paris Hilton cellphone incident. I'd like to use this case to take a look at the various approaches used to perform incident response. The first two methods are technical, and the third is non-technical.

First we have the assessment approach. This involves probing target systems which may have been involved in the incident. Assessors look for security weaknesses in services and applications they believe could have yielded the information acquired by the intruders. Jack Koziol's recent blog entry is an example of this approach.

In my opinion this method is least likely to yield useful information, and is often a waste of time, as far as determining the details of the incident at hand. The assessment approach is largely speculation, albeit with access to some or all of the systems which could have been victimized. From a forensic standpoint, this is a poor way to investigate an intrusion. Assessors typically interact directly with victimized or potentially victimized systems. Their "investigation" risks damaging evidence that could be retrieved by a forensic investigator. Despite the harm caused by this method, I have read the CSO of an immense security company advocate this approach in her most recent book.

The assessment approach is useful for incident recovery. It is important to know the scope of a target's vulnerabilities before declaring a case "solved." It does no good to patch one hole if three remain open. I wrote about combining assessment with incident response in a whitepaper for Foundstone titled Expediting Incident Response with Foundstone ERS. Jack's probing of the T-Mobile site is valuable in that it shows they still have problems. The assessment method may in some cases yield the answer to a problem by constructing an experiment resembling the incident. Professor Feynman's O-ring in ice water experiment shows the power of doing "what-if" incident response. The problem I've seen in the digital realm is that the assessment-minded conduct their "investigation" on the original evidence (the victimized systems), thereby spoiling information for the next phase...

The second technical way to investigate an incident is the forensic method. This process centers on examining digital evidence collected from victimized or potentially victimized systems in a forensically sound manner. Evidence is acquired carefully, in accordance with procedures most likely to withstand an adversarial legal system. This contrasts starkly with the assessment method, where assessors typically "race to root" on the target and then declare "victory."

The weakness of the forensic method lies in the lack of evidence or an absence of useful evidence. I have performed many incident responses where I only acquired case-solving information by collecting it with my own products and processes. Frequently the victim has not enabled sufficient logging, or he has trounced the evidence by performing his own amateur investigation. While the former is usually not excusable, the second can often not be avoided. If an administrator suspects something is wrong with one of her servers, she is most likely going to check it out before calling in outside forensic help. Unfortunately, this destroys evidence that could have been collected in a fairly easy manner.

The third way to investigate an intrusion is the law enforcement method. I do not necessarily mean law enforcement is involved, although they are most likely to follow this technique. Rather, I am referring to a non-technical, human source-oriented means of investigating an incident. This method relies on cultivating informants, interviewing various parties, and conducting open research on threats that may have had the capabilities and intentions to harm a victim.

Several examples can be found on the Web. Brian McWilliams reports the following:

"An anonymous source provided O'Reilly Network with a screen grab, proving he was able to access the contents of Hilton's T-Mobile inbox as of Tuesday morning. Another image confirmed that Hilton's 'secret answer' was her dog's name."

This Rootsecure.net story mixes the assessment and law enforcement methods, but it points to the existence of tMobile_exploit_tools.zip, a program to gain access to T-Mobile Web accounts.

Incidentally, CSC posted an advisory last August saying "T-mobile Wireless and Verizon Northwest are vulnerable to caller-ID authentication spoofing, enabling arbitrary compromise of customer
voicemail/message center." Essentially, the phones can be set up to trust callers and play voicemail based on caller ID, which can be spoofed.

The law enforcement method can be the most successful means to resolve an intrusion. It is especially helpful when digital evidence is lacking. Often an investigator (most likely a real law enforcement agent) can acquire evidence pointing to the physical intruder, usually by speaking with informants. The law enforcement agents then obtain digital, hard-copy, and physical evidence by obtaining a search warrant for the suspected intruder's home or office. This is generally the only way to tie a person to a keyboard, which is the best means to successfully prosecute an intruder.

Read More

ChoicePoint Data Theft Worse Than Initially Reported

As I originally suspected the ChoicePoint fraud case has expanded to a national scope. The Associated Press is reporting that half a million people across the United States may have had their information stolen. Attorneys general from 38 states have demanded that ChoicePoint warn any victims in their states, beyond those in California. So far a 41-year-old Nigerian, Olatunji Oluwatosin, has been sentenced to 16 months in jail. According to AP, Oluatosin "was arrested on Oct. 27 when ChoicePoint faxed him some paperwork at a Kinko's store in a sting operation. He pleaded no contest and did not agree to help authorities in the probe."

Politicians are getting angry, according to AP: "On Wednesday, Sen. Dianne Feinstein, D-Calif., called for hearings on her proposed national version of the California law, while Sen. Bill Nelson, D-Fla., asked federal regulators Friday to oversee data-brokering companies the same way they do other companies that handle financial and medical records. New York state legislator James Brennan asked his state to suspend an $800,000 ChoicePoint contract until the company agreed to warn any New York residents whose data might have been exposed."

Suspend until ChoicePoint sends a letter? How about cancelling the contract instead?

Update: Check out this great quote by Adam Shostack:

I hope Richard, at TaoSecurity, takes Choicepoint to IDS kindergarden.

Read More

Investigative Leads for Network Security Monitoring

When I worked incident response for Foundstone, my boss Kevin Mandia taught me about "investigative leads." This is a Bureau/law enforcement term for items which are recognized as important in a report but require additional scrutiny. I have several network security monitoring investigative leads which I have not yet had time to follow. I list them here in the event one or more of my readers have checked them out:

• In November Dave Aitel of Immunity, Inc. posted an announcement of his company's CANVAS Reference Implementation (CRI). CANVAS is a penetration testing toolkit consisting of private exploits written by Immunity, Inc. The CRI is a subset of CANVAS, available for free under NDA, aimed at those wishing to test IDS and layer 7 firewalls (aka "IPS"). I plan to try this out soon, but don't expect public results due to the NDA.


• There's an extended focus-ids thread discussing the need for packet capture and the problems of doing so in high bandwidth environments. Anyone who has seen my Amazon.com Wish List will notice I am researching hardware-based approaches to the problem, like network processors, FPGAs, and microcontrollers.


• A friend pointed me to l7-filter, an "Application Layer Packet Classifier for Linux." This looks really cool. Along with the upcoming release of Snort 2.3 with integrated inline capabilities, I'm being forced to deploy one or more Linux boxes to try these features. If l7-filter is able to profile traffic running on arbitrary ports, it will give open-source-bound NSM analysts a powerful new capability.


• If you have trouble justifying your monitoring duties, you'll face less resistance if you share Wanted: Chief Espionage Officer with the doubting parties. I have yet to read all of this article, but it's a detailed look at (illegal) corporate intelligence gathering.

Regarding the third point -- would anyone care to suggest a Linux distro for my snort-inline and l7-filter projects? I'm going to be running on minimal hardware without X. I'm leaning toward Debian or Slackware and away from Fedora Core, Mandrake, and Gentoo. I'd like a Linux distro that uses the kernel.org kernel as-is, or as much as possible. Is there such a thing? Coming from BSD-land, I'm not current on the Linux scene. Thank you.

Read More

Pros and Cons of Outsourcing Security Tasks

Jian Zhen of LogLogic wrote two helpful articles for ComputerWorld. The first lists ten benefits of outsourcing security functions, and the second lists seven potential drawbacks. I largely agree with his analysis, particularly concerning the advantages of leveraging centralized security expertise.

A managed security service that does nothing but handle security issues all day long has a much higher level of security situational awareness than an overtasked administrator with multiple responsibilities. How is a general purpose administrator who has to deal with users, stop spam, recover backups, install patches, and maintain infrastructure going to know more about the latest types of attacks and defenses than a dedicated security professional?

Companies who can afford to maintain specialized security teams probably don't need to oursource these functions. A quick way to determine if a company probably doesn't need to outsource security tasks is to check to see if they are members of FIRST. (I almost had a heart attack when I saw that www.first.org was updated. One of the last vestiges of 1994-era HTML has fallen!)

These articles follow a helpful one by Bill Brenner from August 2004, Firms to seek more security help from outsiders. He reports "Unable to keep up with security holes, attacks and government regulations, enterprises will turn to outside firms for 90% of their security by 2010, according to Yankee Group."

Read More

Kudos for Proper Incident Handling at The Register

The UK-based news site The Register was victimized by an advertisement provider, Falk AG, beginning Saturday. The ads served by Falk AG were carriers for the Bofra worm, which uses a buffer overflow in FRAME, IFRAME, and EMBED elements of pre-XP SP2 Internet Explorer.

The Register promptly issued a warning on Sunday morning, followed by a statement on restoration of service this morning. The Register estimates the number of visitors who could have been affected by this event, which is a good way to scope the extent of the incident.

Falk AG has also owned up to the incident, although its wording leaves a little to be desired. From the company's statement:

"Early Saturday morning (20.11.2004) an unauthorized individual exploited a weakness in a load balancer on the European AdSolution network. The purpose of the exploit was to establish a redirect to malicious code through a javascript component of Falk’s ad delivery... Unauthorized access was possible only as a result the intentional exploitation of a weak point of a network load balancer located in the EU datacenter. Once accessed, the individual was able to modify a configuration which forced the redirect to the malicious code."

I like the mention of a "weakness" and a "weak point." That sounds like press-speak for misconfiguration, or unpatched vulnerability. Although Falk has many clients, on Dutch news site Nu.nl has reported on the event, along with The Reg.

According to this site, Falk has a history of serving up Trojaned ads. Maybe that will give me some traffic to inspect for my next book?

Read More

Improving Windows Baselining with Tlist.exe

Several people provided feedback on my Simple Post-Installation Baselines on Windows Blog entry. First, Beau Monday reminded me of his FirstOnScene incident response scripts. I haven't tried these out but you might want to see if they make life easier for your first responders.

Second, Harlan Carvey pointed out the program tlist.exe shipped with the Debugging Tools for Windows. This is apparently not the same tlist.exe found on some Windows systems. You can obtain tlist.exe by downloading and installing the debugging tools, and then copying the tlist.exe binary elsewhere.

I tested the independence of tlist.exe by running it on a system where no special debugging tools were installed, and where I did not have administrator privileges.

Here is an excerpt of tlist.exe output. This tool is especially helpful because it shows the full path for executables. This allows you to differentiate between a 'svchost.exe' started from "C:\WINDOWS\system32" (where it belongs) and "C:\WINDOWS\system32\temp" (where it doesn't):

c:\>tlist.exe -v



 0    0 System Process  

     Command Line: 

 0    4 System          

     Command Line: 

 0  376 smss.exe        

     Command Line: \SystemRoot\System32\smss.exe

     Process StartTime: 10/18/2004 6:54:42 AM

 0  652 csrss.exe       Title: 

     Command Line: C:\WINDOWS\system32\csrss.exe 

 ObjectDirectory=\Windows SharedSection=1024,3072,512 Windows=On

 SubSystemType=Windows ServerDll=basesrv,1

 ServerDll=winsrv:UserServerDllInitialization,3

 ServerDll=winsrv:ConServerDllInitialization,2

 ProfileControl=Off MaxRequestThreads=16

     Process StartTime: 10/18/2004 6:54:46 AM

 0  676 winlogon.exe    

     Command Line: winlogon.exe

     Process StartTime: 10/18/2004 6:54:48 AM

 0  720 services.exe    Svcs:  Eventlog,PlugPlay

     Command Line: C:\WINDOWS\system32\services.exe

     Process StartTime: 10/18/2004 6:54:49 AM

 0  732 lsass.exe       Svcs:  PolicyAgent,ProtectedStorage,SamSs

     Command Line: C:\WINDOWS\system32\lsass.exe

     Process StartTime: 10/18/2004 6:54:49 AM

 0  888 svchost.exe     Svcs:  DcomLaunch,TermService

     Command Line: C:\WINDOWS\system32\svchost -k DcomLaunch

     Process StartTime: 10/18/2004 6:54:50 AM

 0  952 svchost.exe     Svcs:  RpcSs

     Command Line: C:\WINDOWS\system32\svchost -k rpcss

     Process StartTime: 10/18/2004 6:54:51 AM

 0 1040 svchost.exe     Svcs:

 AudioSrv,BITS,Browser,CryptSvc,Dhcp,dmserver,ERSvc,

 EventSystem,FastUserSwitchingCompatibility,helpsvc,

 lanmanserver,lanmanworkstation,Netman,Nla,RasMan,

 Schedule,seclogon,SENS,SharedAccess,ShellHWDetection,

 srservice,TapiSrv,Themes,TrkWks,W32Time,winmgmt,wscsvc,

 wuauserv,WZCSVC

     Command Line: C:\WINDOWS\System32\svchost.exe -k netsvcs

     Process StartTime: 10/18/2004 6:54:51 AM

 0 1124 svchost.exe     Svcs:  Dnscache

     Command Line: C:\WINDOWS\system32\svchost.exe -k NetworkService

     Process StartTime: 10/18/2004 6:54:51 AM

 0 1228 svchost.exe     Svcs:  LmHosts,RemoteRegistry,SSDPSRV,WebClient

     Command Line: C:\WINDOWS\system32\svchost.exe -k LocalService

     Process StartTime: 10/18/2004 6:54:52 AM

 0 1364 CCSETMGR.EXE    Svcs:  ccSetMgr

     Command Line: "C:\Program Files\Common Files\Symantec Shared\ccSetMgr.exe"

     Process StartTime: 10/18/2004 6:54:54 AM

 0 1392 CCEVTMGR.EXE    Svcs:  ccEvtMgr

     Command Line: "C:\Program Files\Common Files\Symantec Shared\ccEvtMgr.exe"

     Process StartTime: 10/18/2004 6:54:54 AM

 0 1556 spoolsv.exe     Svcs:  Spooler

     Command Line: C:\WINDOWS\system32\spoolsv.exe

     Process StartTime: 10/18/2004 6:54:55 AM

 0 1940 NAVAPSVC.EXE    Svcs:  navapsvc

     Command Line: "C:\Program Files\Norton AntiVirus\navapsvc.exe"

     Process StartTime: 10/18/2004 6:55:02 AM

 0 1972 NeTmSvNT.exe    Svcs:  NetTimeSvc

     Command Line: "C:\Program Files\NetTime\NeTmSvNT.exe"

     Process StartTime: 10/18/2004 6:55:03 AM

 0  324 NMSSvc.Exe      Svcs:  NMSSvc

     Command Line: C:\WINDOWS\system32\NMSSvc.exe

     Process StartTime: 10/18/2004 6:55:06 AM

 0  480 SAVSCAN.EXE     Svcs:  SAVScan

     Command Line: "C:\Program Files\Norton AntiVirus\SAVScan.exe"

     Process StartTime: 10/18/2004 6:55:07 AM

 0  896 svchost.exe     Svcs:  stisvc

     Command Line: C:\WINDOWS\system32\svchost.exe -k imgsvc

     Process StartTime: 10/18/2004 6:55:09 AM

 0 1024 symlcsvc.exe    Svcs:  Symantec Core LC

     Command Line: "C:\Program Files\Common Files\Symantec Shared\CCPD-LC\symlcsvc.exe"

     Process StartTime: 10/18/2004 6:55:10 AM

 0  768 SymWSC.exe      Svcs:  SymWSC

     Command Line: "C:\Program Files\Common Files\Symantec Shared\Security Center\SymWSC.exe"

     Process StartTime: 10/18/2004 6:55:11 AM

...

 0 1844 msmsgs.exe      Title: 

     Command Line: "C:\Program Files\Messenger\msmsgs.exe" -Embedding

     Process StartTime: 10/20/2004 8:52:04 AM

 0 3504 msiexec.exe     Svcs:  MSIServer

     Command Line: C:\WINDOWS\system32\msiexec.exe /V

     Process StartTime: 10/20/2004 8:52:35 AM

 0 2156 cmd.exe         Title: Command Prompt - tlist.exe -v 

     Command Line: "C:\WINDOWS\system32\cmd.exe" 

     Process StartTime: 10/20/2004 8:53:26 AM

 0  172 dllhost.exe     Svcs:  COMSysApp  Mts:   System Application

     Command Line: C:\WINDOWS\system32\dllhost.exe

 /Processid:{02D4B3F1-FD88-11D1-960D-00805FC79235}

     Process StartTime: 10/20/2004 8:54:09 AM

 0 2412 tlist.exe       

     Command Line: tlist.exe -v 

     Process StartTime: 10/20/2004 8:54:37 AM

There is a lot you can do with this data. I'm pointing it out because a small amount of work done prior to a compromise when a system is in a trusted post-installation state can make identifying and responding to compromise quicker, cheaper, and easier.

Read More

Benefits of Short Term Incident Containment

One of the regulars in the #snort-gui IRC channel of irc.freenode.net asked me the following question via email. This is an excerpt, and my response follows:

"I am very interested to hear your insight on the topic of 'incident containment' via TCP resets... I am concerned about whether or not incident containment should even be used. From a purely technical standpoint it seems like 'Sure, it's better than just leaving the connection live. It's helping to interfere, after-all.'

But when I think about it in a real-world application, it seems like many malicious hackers will notice TCP resets as a clear sign they have been spotted. It seems like this understanding on their part will cause them to attempt to shoot in again even if only for the brief seconds required to 'rm -rf /'.

The alternative, no TCP resets, it seems the intruder will most likely think their presence is yet unknown and they may be content with their backdoor...

I guess the overall idea is in some ways it seems safer to -not- implement 'incident containment' via TCP resets. If their access is limited to a lower level user access or something then sure TCP resets may be great in preventing them from escalating their privs further, but if they have gained root/admin access it seems very dangerous to try such an ad-hoc method of temporary containment.

Are TCP resets effective enough to prevent last-ditch efforts at wiping a machine?"

This is a good question. I will frame my answer using the concepts in The Tao of Network Security Monitoring. Let's start by describing a scenario. You're performing network security monitoring, and your sensor generates alert data indicating the compromise of your Web server. You check your session data and realize the intruder has connected to a back door installed as part of the initial exploit. Reviewing your full content data, you see the intruder has root level access on the target. (If the full content data were encrypted, preventing useful review of the back door communications, I would assume root level access anyway.)

The question at this point is "what now?" Your level of situational awareness is good, since you know the intrusion attempt succeeded and the intruder has control of the target. (If you were not following NSM principles and were not collecting alert, session, and full content data using something like Sguil, you'd still be at the alert review process wondering what the alert meant!) Now you have to decide what you value more: information about the threat or controlling the threat.

If you're running a Honeynet, the answer is clear: you value information about the threat. You will not take actions to deny further access to the intruder. What if the target is a normal production system? The decision to limit intruder further access depends on the knowledge the victim already possesses about the intruder.

In this scenario, we saw the method of entry and its effects. If we value learning the intruder's ultimate goal (vandalism, espionage, theft, etc.), we should not interfere with his back door. This is very risky, especially if we see credit card databases transferred to Russia while we sit and watch the intruder.

If we value recovering the security of the target, we should definitely cut off the intruder's access. In the case I described, I would immediately implement Short Term Incident Containment (STIC) to deny further intruder access (more on how shortly).

In a different scenario, we might stumble upon an indicator that a victim is compromised, without knowledge of the initial point of entry. For example, a review of our statistical NSM data could show an increase in ICMP traffic. Closer review of full content data shows the ICMP traffic does not meet normal standards and is indicative of an ICMP-based back door. Learning of an intrusion in progress is more common than seeing an intrusion from start to finish, in my incident response consulting experience.

In a case where we do not know how the intruder gained access, or how many targets he has compromised, we would probably value intelligence gathering over containment. In other words, we might let the intruder maintain access so as to determine his modus operandi and what other systems he has compromised. Once we have a sense of the scope of the compromise, we might then institute STIC.

The original question mentioned 'TCP resets.' These are a way for a sensor to spoof reset traffic to fool the source and destination hosts into thinking they each want to end an active connection. This technique is offered as a way for a sensor sitting off-line to interrupt an intrusion attempt. I've used this technique since 1998 and I can report it is not foolproof for a variety of reasons. TCP resets should be used as a last-ditch STIC method.

The best way to limit an intruder's manueverability is to use an access control device. This is best done with a true firewall, although stateful router ACLs can be applied as well. Sometimes a target will be cut off from the outside world after an attack, and then reconnected with special access control measures taken to limit an intruder's manueverability. This is called "fishbowling" a target.

As for whether an intruder will try to quickly destroy a target to eliminate evidence: I never consider this when making the deny/allow decision. You've got to decide whether you value information about the threat or controlling the threat.

I follow the rule that it is unwise to 'hack back' or otherwise touch intruders, since I don't want to tip off intruders that I've seen their activities. (Some consider deterrence a valid goal of NSM operations, and there is evidence that the Air Force had the best results deterring intruders due to its vigilance. I don't think the same applies to the commercial world because .gov is more willing to pursue and prosecute than .com or .edu.) I consider shutting down remote access and thereby alerting the intruder a necessary step when the victim values controlling the threat.

Any time an intruder has root level access, the situation should be immediately considered extremely poor. The only mitigating factor is the level of knowledge you have of the intruder's activity on the target. If your NSM operation has complete awareness of the intruder's actions, you may recover without completely rebuilding the target. If you have any doubt as to what actions the intruder may have taken on the target, I recommend a complete rebuild from trusted sources.

I talk more about STIC, the decision to watch intruders, and related issues in my book. Thank you for the question, and I look forward to comments and other queries.

Read More

Simple Post-Installation Baselines on Windows

I just finished setting up a new Windows XP SP2 system on a Shuttle SB52G2 for my wife. This box screams compared to the 1998-era PII 333 MHz tower it replaced.

Now that the installation is done and I've loaded all the software we expect to use on the system and all appropriate patches, I've taken a few simple steps to record a baseline configuration. I use the free PsTools suite from SysInternals.com to record key aspects of the operating system and installed software. Here are the tools I run and sample output for each. All of this information is redirected into text files that I store on the system and on a separate system for safekeeping. I ran all of these programs without administrator privileges.

Believe it or not, but not everyone who breaks into your Windows systems is a Uber Elite hacker. Sometimes they tools used by intruders or malware leaves evidence in output such as this. If you can compare this listing, taken in a known good state, to later records, you might discover unauthorized software. It is best to update these records each time you apply a service pack or hotfix.

PsInfo: This utility records essential system information, like patch levels and installed applications:

c:\>psinfo -h -s -d



System information for \\SCOUT:



Volume Type       Format     Label                      Size       Free   Free

    A: Removable                                                            0%

    C: Fixed      NTFS                               15.0 GB    11.8 GB    78%

    D: Fixed      NTFS       data                    59.5 GB    55.9 GB    94%

    E: CD-ROM                                                               0%

OS Hot Fix    Installed



KB834707      10/16/2004

KB885884      10/16/2004

Q147222       10/12/2004

Applications:

7-Zip 4.09 beta

Adobe Acrobat - Reader 6.0.2 Update 6.0.2

Adobe Download Manager 1.2 (Remove Only)

Adobe Photoshop Album 2.0 Starter Edition 2.00.100

Adobe Reader 6.0.1 006.000.001

AutoUpdate 1.0

Avance AC'97 Audio

CC_ccStart 2.0.0.635

DivX 5.2.1

DivX Player 2.5.5

Intel(R) 82845G Graphics Driver Software

Intel(R) PRO Ethernet Adapter and Software

Intel(R) PRO Intelligent Installer 2.01.0000

IrfanView (remove only)

LiveReg (Symantec Corporation) 2.4.2.2295

LiveUpdate 2.5 (Symantec Corporation) 2.5.55.0

MSRedist 1.0.0.0

MWSnap 3 3.0.0.74

Macromedia Shockwave Player

Microsoft Baseline Security Analyzer 1.2.1 1.2.4013.0

Microsoft Money 2002 10.0.80

Microsoft Money 2002 System Pack 10.0.80

Microsoft Office XP Standard 10.0.6626.0

NetTime 2.0

Norton AntiVirus 2004 10.00.00

Norton AntiVirus 2004 (Symantec Corporation) 10.00.00

Norton AntiVirus Parent MSI 10.0.0

Norton AntiVirus SYMLT MSI 10.0.0

Norton WMI Update 2005.1.0.111

PDFCreator 0.8.0

QuickTime

RealPlayer

SymNet 4.7.1

Symantec Script Blocking Installer 1.0.0

WebFldrs XP 9.50.7523

WinMX

Windows XP Hotfix - KB834707 20040929.110854

Windows XP Hotfix - KB885884 20040924.025457

ccCommon 2.0.0.635

iTunes 4.6.0.15

iTunes 4.6.0.15

PsList: This tool lists all processes running on the system. Again, you might notice an unauthorized process by comparing a later listing to this one taken under post-installation conditions. While the PsInfo output was easy to ready, it can be more difficult to make sense of processes based solely on their names.

c:\>pslist



PsList 1.26 - Process Information Lister

Copyright (C) 1999-2004 Mark Russinovich

Sysinternals - www.sysinternals.com



Process information for SCOUT:



Name                Pid Pri Thd  Hnd   Priv        CPU Time    Elapsed Time 

Idle                  0   0   1    0      0     0:34:33.093     0:00:00.000

System                4   8  55  266      0     0:00:09.468     0:00:00.000

smss                372  11   3   21    164     0:00:00.984     0:40:50.680

csrss               664  13  11  498   1680     0:00:20.765     0:40:47.946

winlogon            688  13  20  532   7468     0:00:05.125     0:40:46.540

services            736   9  15  296   1912     0:00:07.703     0:40:45.540

lsass               748   9  20  366   3720     0:00:05.375     0:40:45.446

svchost             892   8  20  206   3008     0:00:01.343     0:40:44.086

svchost             960   8  11  376   1844     0:00:06.828     0:40:43.680

svchost            1000   8  72 1459  13024     0:00:11.953     0:40:43.461

svchost            1080   8   6  101   1252     0:00:00.343     0:40:42.665

svchost            1160   8  15  212   1656     0:00:00.328     0:40:42.071

CCSETMGR           1268   8   6  183   2400     0:00:00.765     0:40:40.774

CCEVTMGR           1296   8  22  202   2584     0:00:00.484     0:40:40.336

spoolsv            1460   8  14  144   3520     0:00:03.281     0:40:39.571

NAVAPSVC           1580   8  11  241   5648     0:00:11.937     0:40:39.071

NeTmSvNT           1616   8   7   74    844     0:00:01.203     0:40:38.805

NMSSvc             1668   8   6  136   1964     0:00:01.781     0:40:38.415

SAVSCAN            1724   8   7   60   8240     0:00:08.546     0:40:37.993

svchost            1768   8   8  135   3424     0:00:01.218     0:40:37.540

symlcsvc           1796   8   4   78    784     0:00:00.265     0:40:37.040

SymWSC             1904   8   8  254   7448     0:00:10.062     0:40:36.024

alg                 240   8   6  105   1016     0:00:00.078     0:40:31.149

explorer           2740   8  11  325  11004     0:00:11.218     0:28:14.425

PROMon             3692   8   4   85    776     0:00:01.406     0:28:08.753

igfxtray           3764   8   1   58   1228     0:00:00.203     0:28:08.659

hkcmd              1156   8   2   67   1348     0:00:00.281     0:28:08.503

SOUNDMAN           3384   8   1   42   1708     0:00:00.031     0:28:08.409

CCAPP              1676   8  22  336   5092     0:00:04.156     0:28:08.347

NetTime            3716   8   2   33    744     0:00:00.203     0:28:08.284

iTunesHelper       3160   8   4  104    800     0:00:00.171     0:28:08.128

qttask             3144   8   2   38    500     0:00:00.125     0:28:08.066

iPodService        2220   8   6  112   1896     0:00:00.203     0:28:06.144

LUCOMS~1           3824   8   5  132   2244     0:00:00.578     0:28:04.925

cmd                3368   8   1   31   1928     0:00:00.578     0:05:26.631

msmsgs             4056   8   4  149   1176     0:00:00.156     0:00:17.109

pslist             3036  13   2   70    680     0:00:00.046     0:00:00.046

Netstat: Recently Windows has added the ability to show the process id (PID) of the process that opens a listening socket. That means the old netstat command can show the PID responsible for open sockets on a Windows system if passed the -o switch:

c:\>netstat -nao



Active Connections



  Proto  Local Address          Foreign Address        State           PID

  TCP    0.0.0.0:135            0.0.0.0:0              LISTENING       960

  TCP    0.0.0.0:445            0.0.0.0:0              LISTENING       4

  TCP    127.0.0.1:1025         0.0.0.0:0              LISTENING       240

  TCP    127.0.0.1:1078         0.0.0.0:0              LISTENING       1676

  TCP    192.168.2.11:139       0.0.0.0:0              LISTENING       4

  UDP    0.0.0.0:445            *:*                                    4

  UDP    0.0.0.0:500            *:*                                    748

  UDP    0.0.0.0:1031           *:*                                    1080

  UDP    0.0.0.0:1032           *:*                                    1080

  UDP    0.0.0.0:1033           *:*                                    1080

  UDP    0.0.0.0:1034           *:*                                    1080

  UDP    0.0.0.0:1035           *:*                                    1080

  UDP    0.0.0.0:4500           *:*                                    748

  UDP    127.0.0.1:123          *:*                                    1000

  UDP    127.0.0.1:1900         *:*                                    1160

  UDP    192.168.2.11:123       *:*                                    1000

  UDP    192.168.2.11:137       *:*                                    4

  UDP    192.168.2.11:138       *:*                                    4

  UDP    192.168.2.11:1900      *:*                                    1160

You can get similar but not exactly the same output with Foundstone's Fport program:

c:\>fport

FPort v2.0 - TCP/IP Process to Port Mapper

Copyright 2000 by Foundstone, Inc.

http://www.foundstone.com



Pid   Process            Port  Proto Path                          

960                  ->  135   TCP                                 

4     System         ->  139   TCP                                 

4     System         ->  445   TCP                                 

240                  ->  1025  TCP                                 

1676  ccApp          ->  1078  TCP   C:\Program Files\Common Files\Symantec Shared\ccApp.exe



0     System         ->  123   UDP                                 

0     System         ->  137   UDP                                 

0     System         ->  138   UDP                                 

960                  ->  445   UDP                                 

4     System         ->  500   UDP                                 

240                  ->  1031  UDP                                 

1676  ccApp          ->  1032  UDP   C:\Program Files\Common Files\Symantec Shared\ccApp.exe

4     System         ->  1033  UDP                                 

0     System         ->  1034  UDP                                 

0     System         ->  1035  UDP                                 

0     System         ->  1383  UDP                                 

0     System         ->  1900  UDP                                 

0     System         ->  4500  UDP 

PsService: The last program I like to run shows the services that load under Windows. Only a few are shown for demonstration purposes:

c:\>psservice

PsService v2.12 - local and remote services viewer/controller

Copyright (C) 2001-2004 Mark Russinovich

Sysinternals - www.sysinternals.com



SERVICE_NAME: Alerter

DISPLAY_NAME: Alerter

Notifies selected users and computers of administrative alerts. If the service is

 stopped, programs that use administrative alerts will not receive them. If this

 service is disabled, any services that explicitly depend on it will fail to start.

 TYPE    : 20 WIN32_SHARE_PROCESS 

 STATE    : 1  STOPPED

          (NOT_STOPPABLE,NOT_PAUSABLE,IGNORES_SHUTDOWN)

 WIN32_EXIT_CODE   : 1077 (0x435)

 SERVICE_EXIT_CODE : 0  (0x0)

 CHECKPOINT   : 0x0

 WAIT_HINT   : 0x0



SERVICE_NAME: ALG

DISPLAY_NAME: Application Layer Gateway Service

Provides support for 3rd party protocol plug-ins for Internet Connection Sharing and

 the Windows Firewall.

 TYPE    : 10 WIN32_OWN_PROCESS 

 STATE    : 4  RUNNING

          (STOPPABLE,NOT_PAUSABLE,IGNORES_SHUTDOWN)

 WIN32_EXIT_CODE   : 0  (0x0)

 SERVICE_EXIT_CODE : 0  (0x0)

 CHECKPOINT   : 0x0

 WAIT_HINT   : 0x0



SERVICE_NAME: AppMgmt

DISPLAY_NAME: Application Management

Provides software installation services such as Assign, Publish, and Remove.

 TYPE    : 20 WIN32_SHARE_PROCESS 

 STATE    : 1  STOPPED

          (NOT_STOPPABLE,NOT_PAUSABLE,IGNORES_SHUTDOWN)

 WIN32_EXIT_CODE   : 1077 (0x435)

 SERVICE_EXIT_CODE : 0  (0x0)

 CHECKPOINT   : 0x0

 WAIT_HINT   : 0x0

Again, in a situation where you expect an intrusion, comparing new data to this baseline can help identify suspicious processes or services.

If you want to collect even more data, assume administrator privileges and run Listdlls. Listdlls displays all of the DLLs loaded on a Windows system.

If you're wondering how I identify potential intrusions on Windows systems, the answer is simple. One of the host-based steps involves "live response," or the collection of volatile information using certain Windows tools. My IR toolkit includes these and other tools. Quite often I can identify suspicious entries in records like those shown, and having a baseline in hand makes that job much easier. Of course, truly skilled intruders will use kernel mode rootkits to hide their presence. Under those conditions, other techniques must be applied.

Read More

Romanian Hacker and Friends Indicted

A friend and former Foundstone colleague informed me of the indictment of a Romanian (Calin Mateias, 24, of Bucharest) and five Americans for conspiring to steal more than $10 million US in computer equipment from Ingram Micro of Santa Ana, California. I worked this case two years ago as a Foundstone consultant and helped detect and remove the intruder's X-based back doors from Ingram Micro systems.

I commend Ingram Micro for publicly pursuing these intruders in court. This is one of the best ways to encourage other companies to go forward with prosecution, which is a form of deterrence. This CRN article says Ingram Micro is trying to reassure its value added resellers that its systems are secure. While I worked there, Ingram Micro was outsourcing its IT services to ACS, but security remained a "core competency" handled by Ingram Micro employees. As far as I am concerned, Ingram Micro handled the intrusions properly. I was very impressed by the way their CIO decided to take essentially whatever actions were necessary to remove the intruder from his network. This is one of the few times I've seen a CIO "get it."

Looking at IM's stock chart, the company seems to have taken a slight hit these past few days. The whole market has done poorly recently, so I don't attribute IM's performance to the hacker stories.

This case has appeared at CyberCrime.gov, so the public will be able to track its progress. At least one of the case studies in my The Tao of Network Security Monitoring: Beyond Intrusion Detection is based on my experience responding to this intrusion.

This InternetNews article says:

"According to officials at the Department of Justice (DoJ), the case was handled by the FBI cyber crimes squad, the Romanian National Police, 14 FBI field offices and the FBI's legal attache office in Bucharest.

Brian Hoffstadt, assistant U.S. Attorney at the DoJ, said authorities are working with the Romanian government to decide whether Mateias will be tried in Romanian or extradited to the United States to face charges.

'It's just a decision that hasn't been made yet -- which justice system is going to prosecute him,' he said.

Hoffstadt said there is still work to be done regarding the sentencing and fines that will be assessed against the defendants if they should lose their case. Mateias, if charged in a U.S. court, could get up to 90 years in prison and fined to repay Ingram Micro as well as other damages. The five Americans could face between five and 35 year prison sentences if convicted. More information will become available at the arraignment later this month."

During the incident response, I was asked when Ingram Micro would be "secure." I said they would be secure when the threat was eliminated. This could only be done via an arrest, prosecution, and conviction. Too many security professionals focus on the vulnerability side of the "risk = threat X vulnerability X asset value" equation. Sure, vulnerability is the one factor that administrators hope to control, but they can decrease the threat by supporting legal action against intruders. Ingram Micro understood this and I'm glad they worked with the authorities to arrest these perpetrators.

Read More

Incident Handling (INCH) IETF Working Group

This weekend at BSDCan Michael Richardson mentioned a security-oriented IETF working group I'd never heard of before. It's called Incident Handling and its purpose is "to define a data format for exchanging security incident information used by a CSIRT." Also:

"The working group has created four documents. A data model named the Incident Object Description Exchange Format (IODEF), and an associated implementation in an XML DTD, is the format defined for exchanging incident data. The IODEF conforms to a set of requirements for a Format for INcident Report Exchange (FINE). Additionally, guidelines for implementors are provided."

Although the official working group site links to the project schedule and the documents they've written, working group chair Roman Danyliw's unoffical site is informative too. (Yes, that's the same Roman who developed ACID.) The INCH mailing list archive shows plenty of recent activity. This is a nice departure from the archive for the Intrusion Detection Exchange Format working group.

Read More