[Excerpted from "You've Been Breached: Responding To A Database Compromise," a new report posted today in Dark Reading's Database Security Tech Center.]

It’s 3 a.m., and you get the call: There has been a breach. You don't know much about it, just what the first responder could quickly relay. Upon arriving and assembling your team, you realize the situation is very serious. A database containing highly sensitive information has been compromised.

During the years, we have seen attacks move from Web server defacements to organized crime rings attempting to steal data -- anything from credit card and Social Security numbers to customer records and unreleased product designs. Criminal enterprises from Eastern Europe, Asia, and the United States are making a lot of money targeting your databases.

Now you need to figure out how the breach happened, what the damage is, and the best way to fix it -- and then make very sure it never happens again.

In all breach incidents, one of the first decisions is whether to contact the authorities. This choice must be made early in the process because it can have a dramatic effect on how the incident is handled.

Even if your organization decides not to contact the authorities at the outset, you might want to do so later. All data handling, collection, tracking, labeling, and storage operations must be conducted using methods that preserve evidence in its original form and maintain the chain of custody.

Before you are able to react and fix the problem, you must understand what has occurred. Which databases were compromised? Was it a single database or multiple? A single database server or multiple servers? How did the intruders get access to the network and the databases? What was stored in those databases, and what was accessed?

Focus on one area at a time. Having an incident response plan that organizes these questions, the steps to be taken, and who is involved at each point will help you streamline your approach and ensure you don't miss anything.

Once the server is known, contain it. To protect data from any further loss or harm, take the server offline or restrict all access to it in some way. This can be tricky.

If you don't have a redundant system, or if you have not determined what has been compromised, then the decision must be made whether to halt this business operation and restrict all access to the databases, to cut over to redundant systems, or possibly to find a way to leave the potentially compromised system online and continue to operate in a limited capacity.

Your forensics effort should begin right away. Review access rights and logins on the system, and ensure all accounts enabled are valid and access rights are correctly configured. This may provide insight into how the breach occurred.

If your database server maintains logs, then start reviewing them. If the logs are in a central repository, then so much the better because you needn't disturb the compromised system. You will later need to go back and copy all of those logs for evidence. For now, work from copies where you can so you don't risk damaging the forensic evidence.

Database administrators often disable transaction logs for fear of affecting database performance, especially on lower-end systems. If that's the case, you will need to refer to other logs, such as those that track activity on systems or applications.

If the attack was the result of an insider, then the evidence will be very different than in the case of an external attacker. The attack will most likely be conducted using valid login credentials.

To get a detailed perspective on how to analyze log information, identify the source of the breach, and remediate the problem, download the full report.

Have a comment on this story? Please click "Discuss" below. If you'd like to contact Dark Reading's editors directly, send us a message.