Stopping Computer Crime, Part 2

Catch the culprits through logging, analysis and reporting.

• By Roberta Bragg
• September 01, 2004

It's time we became proactive about stopping computer crime. No matter how good we get at hardening systems; how many bucks we spend on defensive measures or in complying with legislation and initiatives; no matter how carefully we design, create, deploy and maintain secure operating systems, applications and infrastructure; others are spending even more money and time attacking them.

Stopping computer crime requires two basic things: You need to let criminals know it won't be tolerated by reporting and prosecuting, and tell the world what these crimes are and how folks can avoid being a victim.

Collect and Analyze Evidence
It's not enough to know you're under attack, or that you think you're in compliance with relevant laws—you must collect the evidence supporting your assumptions. That means ensuring that appropriate logs are configured and that the data within them is archived and analyzed. Examples of logs to monitor and archive include operating system logs, infrastructure services logs (DNS, DHCP and so on), application logs, intrusion detection system (IDS) and/or intrusion prevention system (IPS) logs, firewall logs, router logs and any other logs that might track problems and evidence of attack. In addition, you may determine that live monitoring using packet analyzers or sniffers is appropriate, especially when there's a possible attack underway. The definition of "appropriate" here depends on your environment's systems and applications combined with organization policy. Questions about the legality of monitoring data also need to be answered.

Collection and analysis of evidence presents another dilemma. The treatment of potential attacks and compromises may be different depending on whether you intend to report a crime to law enforcement or just want to get systems back online and prevent future attacks. In some cases, to not report the crime may be itself a crime. Often, though, you won't know if a prosecutable crime has been committed until further analysis. The definition of prosecutable attack may be difficult. Your organization's response policy should be drafted with the advice of legal counsel. You should be provided with guidelines to follow so that during or after an attack, you know what to do, whom to contact, and when to involve people outside of the company.

Log Like a Lumberjack
Security procedures may need alteration to establish a proper environment in which evidence can be collected and preserved. The following list can serve as a starting point.

• Review current settings for information logging. In addition to logging security events in the security event log, review available logs for services and applications such as Exchange, SQL Server, DNS, Internet Authentication Services (IAS) and so on. By default, many logs aren't used and many events aren't recorded.
  On the other hand, I'm not asking you to blindly collect every possible event in every available log. Collecting records isn't enough; they need to be analyzed. Start by analyzing the types of events most useful to obtain.
• Centralize log collection. It's much easier to review logs if they're all in one place, and much easier to prove they haven't been tampered with if they're being recorded on a machine that hasn't been compromised (If a machine's been hacked, how can you prove the logs haven't been altered?).
  While no Microsoft products provide centralized logging for the event logs, there are third-party products that do the job.
• Create a procedure and policy on evaluating log contents. It should include specific events that may indicate an attack, and how to differentiate between an actual attack and possible misconfiguration or user error that can appear to be an attack. Without some guidelines you'll be lost in the mire.
• Procedures and policies about maintaining accurate time on systems must be established and followed. You must be able to prove that the timestamp on an event or file is accurate. If you can't, you may not be able to determine what happened and thus unable to return systems to pre-attack status. Windows 2000 (server and desktop), Windows XP and Windows Server 2003 can all be time synchronized with a time server, either Internet-based or LAN-based.

CSI: Datacenter
If logs and/or monitoring indicate a possible attack or compromise, determining what happened is the first step in figuring out who's responsible. However, the analysis of such evidence is in itself a unique skill. If you're not experienced with this, bring in an expert. Meanwhile, your incident detection and response program should include procedures for the handling of logs and other evidence. Use the following list to begin or review your current procedures:

• Evidence must be acquired intact, without being altered or damaged. You'll want to make sure that a "bit-by-bit" image of the hard drive (one that captures all the drive, not just the formatted part of it) is obtained by non-invasive techniques.
• Evidence must be gathered from the crime scene. Don't move the computer to another location for examination. Taking it home and poking around a bit, then deciding to call the authorities, won't work.
• Analysis shouldn't alter the data. It's not enough to say you didn't alter it—you'll have to prove it. For example, an image of a system's hard drive—not the hard drive itself—should be used in forensics analysis or preliminary investigation.
• You must be able, in court, to account for the location of evidence and its ownership at all times, from collection to examination to storage. A log should be kept to document this, and the signatures of those who handle the evidence should be collected. Evidence should be kept locked and secured.
• Documentation of policies and procedures for this process should also be maintained.

The most important factor is to use policy and best practice procedures generally recognized by the security community. Get expert advice in establishing such practices; practice the steps; and seek experts for data analysis.

Report the Crime
If you don't report crimes, you're part of the problem. Some may argue that the possibility of prosecution, fines and imprisonment won't deter the bad guys. But what message are we sending by refusing to prosecute criminals? By not acting, we're encouraging sociopathic behavior.

After talking to IT pros in the trenches, along with IT management and corporate executives, I've concluded that most computer crimes aren't reported due to fear. There's a fear that stock market prices will plummet if the public hears of the attack. There's fear about getting fired if your boss decides you could have prevented the attack. You think those big, bad FBI-types will tie up your computer systems in red tape, shutting down your business. You're afraid that somehow you might be treated like the criminal, or that you'll be wasting your time, laughed at or otherwise humiliated. The biggest fear, I think, is fear of the unknown. Sometimes those law enforcement types loom in our minds as scary alien beings.

Get over it.

No professional investigator wants to do anything that would damage your systems, keep you from conducting business, or malign you. You must, however, understand what will happen when you report the crime. You must also know and follow your organization's policy and procedures for communicating with insiders and outsiders if you believe you have evidence of a computer crime.

Create and Follow the Rules of Engagement
The decision to report a crime may not be yours. Your organization should have policies and procedures specifying how incidents are handled, including when to notify law enforcement. If you have such a policy, review it now. If you don't have one, it's time to get started. A policy and its related procedures should consider the following:

• Determine who should be contacted and when. Make a list of individuals within your organization who should be contacted when an attack is underway, and guidelines on when to call. For example, you don't need to call every time there's a port scanned. But you shouldn't have to make the decision on whom to call in the middle of an attack. You should have that information already available. Contact points may be in the technical, management and legal departments.
• Implement a policy that specifies when and whom to contact outside the company and who's responsible for making that contact. Also consider other sources outside your organization. Who should be talking to stockholders or the media?
• Be guarded in security list participation and e-mail discussions with peers. Many lists are public or have only minimal membership requirements. You can't assume that every participant has your best interests in mind. Some may be knowledgeable and helpful. Some may know little and provide the wrong information. Others may join these lists with the sole purpose of gaining information to use in an attack.

Crime Reporting Guidelines
There are several agencies that can get involved when a computer crime occurs. Their involvement may depend on the crime, whether you're making a complaint or just sharing information on an attack, and if you're trying to determine if the incident is a crime. The FBI and Secret Service, for example, share responsibility when a crime crosses state lines. Here's some information on the role played by some U.S. agencies:

• The Secret Service was mandated by the Providing Appropriate Tools Required to Intercept and Obstruct Terrorism (PATRIOT) Act of 2001 to create a national network of Electronic Crimes Task Forces. Find locations at www.ectaskforce.org.
• Contact information for local FBI offices can be found at www.fbi.gov. Many offices have their own Computer Crime Task Force.
• The State Attorney Generals Office for your state can provide you with guidance. The National State Attorney Generals' Web site, www.naag.org, provides contact information by state. They're also building a Computer Crime Point of Contact List, www.naag.org/issues/20010724-cc_list.php, comprised of prosecutors and agencies that work on computer crime law enforcement.
• The Internet Cyber Crimes Complaint Center, www.ic3.gov, serves as a vehicle for criminal complaint referral regarding cyber crime. A partnership between the FBI and the National White Collar Crime Center, it has an online reporting form.

Like any project, security can be easily killed by two things: Lack of support from the executive suite, and lack of support from the average employee. Both are important to avoid.

Getting Executive Buy-in
Start with executive management. You've got to get them on board; without the support of the guys in high places, your offensive security program is doomed. They're the ones whose support will pull other managers into the fold, and who will back you when other managers question your wisdom.

Now don't misunderstand me; I'm not asking you to go around your boss. I'm suggesting that you get the support of someone higher up. You may need your boss's help to do that.

So how do you get management support for security initiatives? How do you get them to agree to report crime and support security awareness within the ranks? The same way you get bucks for defensive programs like firewalls and anti-virus. You talk money—a language management can understand.

If management fears the company's stock price will fall if a crime is reported, point out the cost of getting caught hiding a security incident. If they don't want to pay for security awareness training, show the costs involved in cleaning up after a Code Red-type disaster, then explain how they'll save money by practicing good patch management, a far less expensive task. Detail how much money is lost in sales when an attacker brings down the e-commerce site vs. the cost of training for Web developers. Give them some statistics on how well you resisted the last brute force attack on your remote access servers after users were trained to create strong passwords.

Don't spin your wheels railing at users for doing stupid things like clicking on attachments. Instead, create security awareness training that teaches them safe computer practices. And respect employees. They may be clueless when it comes to good computer security practices, but it's ignorance—not stupidity. Ignorance can be fixed if there's a willingness to educate, instead of berate.

Teamwork is the Key
There's a lot of talk these days about how well the bad guys communicate and collaborate, teaching each other and benefiting from each new attack, and how the good guys should learn from that example. Actually, I think we are communicating more; we're just not collaborating as well as we might.

There's now a strong supply of really smart people who know technology and know something about information security. If we can all get together, we can win the game.