SD Secure Start: July 2003

--Cracked Code: An Interview with Eugene Spafford
--To Catch a Thief: Intrusion Detection

Dr. Eugene Spafford, a.k.a. Spaf, is a Professor of Computer Sciences at Purdue University. His research focuses primarily on information security, computer crime investigation and information ethics. If you use a firewall, thank him -- he brought the term to networking in 1990.

Q: Given the current state of security, what worries you the most these days?

A: I'm not sure there's one thing I can pick out. We have so many vulnerabilities throughout the system -- in the software that's deployed, in the development processes, in operations, in networks. With all the places we're using software, we have so few people who are appropriately trained in using the security tools that we have and in understanding how security really works. It's a massive problem.

Q: In your testimony before the House Science Committee, you talked about how information security data was often withheld by companies and governments because they consider it sensitive and proprietary. What should be done to make that data available to those whose work might benefit from it?

A: There are valid reasons why we would want to keep some of that information proprietary -- because it does contain sensitive information. But unless we start sharing information [about security breaches] and understanding the magnitude of the problem, and have some real data balanced with some real applications, those of us trying to do research in academia and in industry aren't going to be able to build real solutions. So we have to come up with an attitude change -- admitting to security problems should not necessarily be a mark of shame. It happens. In fact, it happens more often than we'd like to admit. That may mean developing some trusted parties that can sanitize the information, and perhaps some of the ISACs -- the information sharing and analysis centers -- are a way to do that.

Q: You also said that it was largely because of industry practices that we currently face security problems. What blame should we lay at the corporate doorstep?

A: There's a little bit of shared responsibility in a number of places. But primarily with industry, what I see is they have a responsibility to produce goods that are not harmful to the customer, insofar as they should anticipate common threats and use a due standard of care. That's true of any vendor or any service provider. It's not an issue of software being goods or a service -- it's something that you pay money to somebody else to get. Over the years, there's been a steady pressure to produce the cheapest, fastest code possible. And many known good practices for producing better software -- including using safer languages and more testing and putting self-checks in the code -- have all been avoided because they make the code bigger or slower or more expensive to produce.

Now, arguably, the public has been trained to measure code based on those issues and to want it faster and cheaper. So there's some blame to be laid on the public, but the vendors have helped cultivate that view, because that's what they've advertised and pushed. And in some cases, in some markets, all the credible competition has been driven out. I would argue that in some sense it's similar to the tobacco companies saying we're just selling people what they want. But the response to that is that you're selling a dangerous product and you should appropriately safeguard it. That's one of the things that I think really we can lay at the feet of industry.

And the second is creating the impression somehow that software can't be written reliably. I would argue that the trusted computing paradigm that's being talked about, not only by Microsoft, but by many other companies, is continuing this impression that it's not possible to write relatively robust, correct software unless you do something really, really special. I don't believe that's true. If you train the programmers well, if you give them the right tools and you write the code appropriately, a lot of the current problems relating to security difficulties could be fixed, simply by applying techniques that we already know how to apply. We have to start holding responsible the people who write the code; the companies that write the code. So when it goes wrong, we don't call it a computer virus; we call it a Microsoft virus. Or instead of calling it a computer break-in, we call it a flaw in IBM or Oracle software, because they didn't code it properly.

Q: Has the law gone too far in criminalizing technology rather than behavior?

A: I definitely think so. The Digital Millennium Copyright Act lawsuit that was brought [unsuccessfully] against ElcomSoft is an excellent example of that. We've had cases of researchers who have been threatened by media companies. We've had researchers who've had to self-censor their work. For people working in academia, even the threat of a lawsuit is not something they can defend against -- it's too expensive. So it's had a chilling effect on research.

>>TO CATCH A THIEF

Effective incident response against network intruders
by Jay Lyman

Your firewall is in place. Your antivirus software is updated regularly, and you check daily to make sure you have all of the latest OS and server patches. The only way in is through your virtual private network (VPN). By all accounts, you should be able to sleep easy -- but you know better.

Intelligence and information gathering have progressed to the point that most computer attacks are quickly reported. However, there are still many vulnerabilities, unreported bugs and complex worms out there. In addition, the double threat posed by Trojan-horse worms that leave systems vulnerable to later attack by intruders is growing. It may just be a matter of time before everybody is hit. No matter what preventative measures administrators take, intrusions on the company network, Web defacements and virus outbreaks are often inevitable.

Forrester Research Analyst Laura Koetzle stresses that a comprehensive security policy is the most important item to start with when defending a computer network and its data -- whether the threat is the latest mass-mailing virus, an exploit that's making

the rounds among hackers or an internal compromise. "Having a coherent policy -- what to do, who to call, what to shut down, the first-fix things -- is important," she says.

Vincent Weafer, director of Symantec Security Response, agrees. "First and foremost is having a security policy in the first place," he says. "People forget about that and focus on the products and techniques. When they then get into an incident response, they may destroy evidence or not know what to do."

Log and Load
Knowing just what to do in an incident response situation can be difficult, given the lack of public discourse on the subject. Despite this, companies are often reluctant to discuss the details of their own security breaches. For example, Exodus Communications declined to discuss its ongoing case against accused hacker Jerome Heckenkamp, who also allegedly broke into the systems of many large companies including eBay, Juniper Networks, E-Trade and Cygnus in 1999.

Yet it's becoming harder to keep attacks quiet, according to SecurityFocus Incident Analyst Ryan Russell -- particularly given the Web defacements that often accompany intrusions. "Now, it's basically not possible to hide if you get nailed properly," he says. "Only the really big-profile cases get prosecuted, but that doesn't mean [administrators] shouldn't gather evidence and go to law enforcement."

Russell emphasizes that reporting attacks and intrusions, despite the potential negative connotations and damage to customer relationships, is an integral part of reacting to security breaches. By reporting even minor incidents to law enforcement, he explains, companies can work together to add to the total existing body of evidence.

Take, for instance, the "Mafiaboy" case, in which a Canadian teenager pleaded guilty in January 2001 to charges of mischief stemming from his denial-of-service (DoS) attacks on major websites. His targets included Yahoo, CNN.com, Amazon and eBay, all of which later helped to condemn him. "Apparently he had been doing it for a while -- a known perpetrator -- and nothing was done," Russell says. "Now that he's charged, there's a laundry list of charges against him."

Jill Knesek, director of Exodus's Cyber Attack Tiger Team (CATT), is a former FBI agent who was involved in the cases against both Mafiaboy and convicted computer criminal Kevin Mitnick. Knesek says attack victims should contact law enforcement in the case of unauthorized access that has resulted in damage of $1,000 or more. "The company should identify the source IP [address] of the attacker and contact the owners of that IP to ask their assistance in obtaining any logs or data associated with [it]," she says. Mitnick adds that law enforcement can send an order to request the preservation of evidence under federal law 18 USC 2703(f).

Even if cases don't go to court, a high number of reported incidents could help pressure ISPs into taking action, including terminating questionable accounts. "You're not going to get a whole lot of satisfaction out of law enforcement," Russell admits. "One of the things you can do is go to the ISP." Russell explains that while law enforcement is ill-prepared to handle all of the cyber-crime that's out there, attack and intrusion victims can still present their evidence to ISPs. These companies often have policies in place that allow them to boot abusers from their networks.

Plan of Attack
To present evidence, you must first gather usage logs, IP traces and other signs of cyber trespassing. Symantec's Weafer explains that any and all information that can be collected about an incident -- network audit logs, anti-virus logs, router firewall logs and file changes -- can be useful both for securing the network and taking action against an intruder or data thief. "Anything that will give you a trace back to where the intruder came in and what [he is] doing. It's all giving you information about what's happening in your environment," he says.

Thus, sometimes the best plan of action is knowing when not to act. If you intend to pursue a case against an intruder, be prepared to wait a couple of days before taking action. Although it's often difficult to convince upper management to let an intruder run rampant through your network, it may be the only way to gather enough evidence to prove trespassing and take action.

Weafer doesn't deny that pretending to ignore attacks can be frustrating. Yet, he says, once they've broken in, attackers can be used to guide administrators and security pros to the cause of the attack. "You may want to watch them to see how they're getting in, and to learn about their attack techniques to learn the true source of the problem," Weafer says. "That's the hard part, particularly in the middle of an incident. You may not be able to do much for the day except the lesson learned, so that you can go back and improve your overall security."

Forrester's Koetzle remembers one company that "really had it down." Every time it experienced an attack or security breach, she explains, the company sent out a survey to security, network administrators and other IT staff to reconstruct the event from all angles. "They would look at what worked, what didn't, time lost, time spent dealing with the attack, and assess the real [incident] so they could do it better next time," she says.

To protect the network, you not only have to thwart attacks, but understand how the attack was perpetrated: thus, vulnerabilities can be corrected and your response improved with each attack. "You can't recover unless you know how you're broken into," says Russell. "A lot of times, you can be running a pretty secure ship and go back and find a hundred holes. There's always the possibility you're going to get broken into."

Effective Evidence
Forrester's Koetzle says that despite the temptation to fix a problem, incident response is all about preservation of the moment. To effectively respond, you must leave the damage alone -- at least temporarily. "You treat the systems as a crime scene and preserve exactly what happened," she says. "You can't repair the damage. If you do, there's no evidence of what happened."

Exodus's Knesek also advises proceeding with caution. "All systems that can be removed from the network should be, to avoid damage or corruption of the evidence," she says, explaining that the most common mistake when gathering and presenting proof of hack data is accessing the evidence prior to imaging the disk. "An image copy of all hard drives should be made. All investigative activities should be well documented and chain of custody forms maintained for any and all evidentiary data."

Weafer concurs. "You have to be careful. You don't want to destroy evidence or make matters worse," he says. "You may have to disconnect a machine. You may not want to power off because there may be critical data you want to save."

"Many companies attempt to analyze the drives for evidentiary data to identify the attacker, the vulnerability that was exploited and/or any files left behind," Knesek explains. "When searching drives for the data, many of the commands used will modify directory or file dates and time stamps. This activity is also being logged to the log files and can modify or corrupt valuable evidence.

"If this immediate analysis is necessary to protect additional corporate assets, a detailed log of all activities performed with date and time stamps should be maintained to explain modifications to the data," she says. When presented to law enforcement and in court, the "best evidence rule" applies. The original is the best, but it's understood that this isn't possible in many cases.

"Companies aren't able to turn over all of their systems and network devices to law enforcement in support of a case," Knesek says. "Usually, images of all hard drives that may contain evidence are obtained by the company, a third-party vendor or law enforcement. This evidence is write-protected and stored in a secure location where access is logged and monitored. All analysis of the data should be performed on a copy, and not the original or the imaged drive being used as evidence."

According to SecurityFocus's Russell, it's important to show that the log process, intrusion detection and tracking are all ongoing, everyday processes. "Something from a victim could be generated on-the-fly or fake," Russell says. "It needs to be part of the regular process, and what the evidence looks like as part of the regular business process is key."

Tools of The Trade
Just as the threats from viruses, crackers and other Internet evils are becoming more numerous and complex, the ability to identify intruders is also improving. A popular tool for analyzing network attacks is an intrusion detection system (IDS), a new breed of security software that's capable of investigating network traffic to recognize suspect, irregular patterns.

Different forms of IDSes include:

--Anomaly detection picks out traffic, protocols or packets that appear out of the ordinary.

--Misuse detection systems work similarly to anti-virus programs to identify known threats based on signatures.

--Passive systems simply identify and log security compromises.

--Reactive systems block malicious activity or access, rather than simply recording the incident.

Network-based intrusion detection systems (NIDS) exist as independent entities on the network and analyze every packet individually. The other variety of IDS is host-based, where all traffic to and from an individual machine or host is monitored. IDS security surpasses preventative measures like firewalls because it analyzes an intrusion and attempts to determine its source. Best of all, they're a great value. "You can get a decent IDS firewall for free," says Russell.

Once intruders have been identified, you can trap them using deception software known as a honeypot. However, Forrester's Koetzle warns that it's often difficult to calibrate security software properly, to the right point of sensitivity. "A lot of administrators have trouble discerning the signal from the noise," she says. "IDSes tend to -- if installed improperly -- send a lot of false positives. You spend the first week going through hours and hours of wild goose chases, and actually, nothing's happening."

SecurityFocus Analyst Ryan Russell says his company's Aris Analyzer, an attack registry that lets users upload IDS logs, can help make sense of a recorded attack. "We'll give information on what the attack means," Russell says. "IDSes aren't helpful in determining what it is. [Aris] is a way to manage the reporting process, and it adds value to IDSes. You can actually interact with the rest of the world and see what they're seeing."

Russell says communication through security mailing lists and programs like Aris, which collected some 100 million IDS logs in nine months, is helping to increase awareness of the dangers that lurk around networks and aid in response by sharing information and experience.

"Regardless of the tool you use, you should find out, 'Is this a danger to me? What does it mean?'" says McAfee.com Security Architect Sam Curry. McAfee's Visual Trace service, which is based on technology that the company acquired from security tools vendor NeoWorx, is about "collecting as much information as possible so you can share it in a community."

The service, described by McAfee as "caller ID for your computer," maps the trails of various attacks, offering time and place information that security experts say is crucial to pinpointing trouble spots, and then following up with action. Capable of tracking down an attacker's geographical region, ISP and even street address, the service also provides links to law enforcement and ISPs for fighting back.

Team Effort
Forrester's Koetzle points out another resource for information about network attacks -- one that many companies often don't consider or even realize is available to them. Consulting firms like AtStake and security monitoring outfits like Counterpane can provide valuable insight, strategies and techniques that you may have overlooked if you lack first-hand experience with network attacks.

"There's absolutely no way, short of disconnecting every computer you have and sitting back in an office and not working, that you can make your network secure," Koetzle insists. In many cases, even the most elaborate security measures end up doing little more than lulling administrators into a false sense of security. The best approach is to pool your team's resources and formulate a plan to respond to security breaches when they do occur.

Teams that know exactly what to do with different boxes, and whom to contact for the latest Internet affliction on the network have thought-out security policies, Koetzle says. She emphasizes that in addition to applying defensive technologies, network defenders must "do the boring preparatory work" if they want to take on an attacker in the right way. "It's all about keeping up with the universe of threats and keeping updated," she says. "Vulnerabilities are going to happen. It's all in how you respond to them."