Stopping Computer Crime, Part 2
Catch the culprits through logging, analysis and reporting.
- By Roberta Bragg
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.
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,
- 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
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
- 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,
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
- 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.