Stopping Computer Crime, Part 2
Date: September 30, 2004Source: Microsoft Certified Professional Magazine
By:
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...
NextOriginal article
Add comment
Email to a Friend
