Posts

Showing posts with the label ir

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 eac...

Marcus Ranum Highlights from USENIX Class

Image
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 con...

Way to Go Joanna

Image
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-bas...

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. Anti-Virus is not (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. 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 begin...

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! :) Anti-Virus is not (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. 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, wi...

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...

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 wit...

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 a...

Investigative Leads for Network Security Monitoring

Image
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 http://www.derkeiler.com/Mailing-Lists/securityfocus/focus-ids/2004-11/0067.html">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 fo...

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 t...

Kudos for Proper Incident Handling at The Register

Image
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 ...

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" (whe...

Benefits of Short Term Incident Containment

Image
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 ...

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...

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 de...

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 departu...