Detection

You can’t possibly conceive of all types of attacks at the time you design and create your application, and you can’t catch all possible security issues during a design review or during testing, a process that is presented in Chapter 9. There’s a chance, then, that you might release your application with a number of security flaws. How do you go about detecting whether any of those flaws are being (or will be) exploited?

Detection involves uncovering information that a pending attack is about to happen or identifying that an attack is underway or has taken place. The techniques you use to detect a cyber attack are similar to the techniques you use to detect other types of attack (or potential attacks) such as a robbery (or potential robbery) of your own home. In the case of your home, you can establish early warning techniques such as a neighborhood block-watch program to enlist the help of neighbors to look out for suspicious activity, such as an unfamiliar car driving around the neighborhood. To detect whether a robbery is in progress or has taken place, you might install a home security system, complete with point-of-entry (doors and windows) detectors and motion detectors, to alert you or the police when a robbery is in progress.

Early Detection

Attempting to detect when an attack such as a robbery is going to occur (early warning) is more difficult than detecting when an attack is in progress. Early warning techniques involve uncovering malicious intent. How do you go about determining a person’s intent? Unless you can read the mind of the attacker, you need to employ other techniques to uncover an attacker’s plan. These techniques require observing the pattern of one or more potential attackers and possibly intercepting proof of the attacker’s plan, such as an e-mail from a potential attacker (sent to another person or posted to a newsgroup) stating that an attack is pending. However, in the case of computer-based attacks, you generally don’t look for any particular attacker, but rather you look for evidence—such as patterns (or anomalies) in such things as system logs, HTTP headers (for on-line applications), and network packets—that suggests someone is formulating an attack. For example, you could monitor for socket packets aimed at your SQL Server TCP port looking for a signature, which would suggest someone is trying to launch a SQL Slammer-style denial of service attack. Even if you uncover evidence that an attack is about to unfold, you might have difficulty proving the attack will indeed take place or identifying the perpetrators involved—just as your neighborhood block-watch program would have difficulty proving to the police that an unfamiliar person driving through your neighborhood is up to no good. You can perform early-warning detection of your own application or system in the following ways:

• Monitor security-related news groups and Web sites (such as www.cert.org) for reports of attacks on applications similar to yours, or attacks on components or systems used by your application. This is much like checking police reports for neighborhood crime activity to see if robberies have increased in your neighborhood. This warns you that a particular attack is more likely to take place, and it gives you a chance to defend against it.

• Provide feedback to your users—such as a notification of a previous failed logon attempt and time of last successful logon attempt—that might indicate someone else tried to log on (or successfully logged on) with the user’s user name and password. You can get help from your users to look for and report suspicious activity (assuming you make the reporting mechanism easy for the user). The equivalent situation in a neighborhood block-watch program would be having a neighbor report suspicious activity such as a stranger trying to get in your front door.

• Design your application to log all suspicious activity. For example, if your application detects that embedded HTML script or SQL is being received as part of a logon user name, the contents of the user name should be written somewhere for review. Also, any logon attempts using unrecognized user names (or multiple failed attempts to log on as a particular user) should be logged. The logs need to be reviewed regularly to see whether a pattern emerges that indicates an attack will take place or has already taken place.

Detecting That an Attack Has Taken Place or Is in Progress

It’s difficult to detect an attack in progress unless you can feel the effects of the attack while it’s happening—such as when a DoS attack slows down your network or application before bringing it down completely. Your main objective is to assure that you can detect when an attack has occurred. The worst possible case is that an attack occurs and is never detected—either because no detection mechanism is in place or the mechanism used to log suspicious activity (audit logs) have been erased or compromised by the attacker.

You should take the following steps to detect whether an application or a system has fallen victim to an attack:

• Log all suspicious activity. In the case of your application, log all unexpected errors that occur (including supporting information such as unexpected variable or parameter values). Use Try…Catch exception handlers throughout your application in conjunction with the System.Diagnostics.EventLog class to log all unexpected errors.

• Configure the computer on which your application runs to log all unscheduled reboots, which might be evidence that an attacker is tampering with system files. Reboots are logged automatically if you are using Windows 2000 Server or Windows Server 2003.

• Log all failed system or application logon attempts.

• Employ an industrial-strength intrusion detection system (IDS) to aid in the detection of system intrusions. Intrusion-detection systems are software applications that employ a variety of automated techniques to positively identify an intrusion or attack. Some of these techniques include:

  • Attack signature detection This technique is similar to how virus scanners detect viruses. The intrusion detection system looks for patterns such as certain types of network packets, certain changes in the files on the system, or certain changes to audit logs that indicate an attack.

  • Anomaly detection With this technique, the intrusion detection system is informed of the expected behavior of an application or computer system. The IDS looks for any deviation from the expected behavior. For example, an IDS might be programmed with the knowledge that statistically only 10 percent of all transactions on your online Web shopping site receive a discounted price, and that the average discount is 15 percent. The system would alert you to a possible attack if it detected that 20 percent of transactions were securing an average discount of 30 percent.

• If there are a large number of computers in your organization, perform hardware inventories—that is, scan the network for all connected systems—to ensure that no unauthorized computers are connected to your network. If an attacker can place a computer (or any other hardware, for that matter, such as a modem connected to an existing computer) within the corporate firewall, the attacker might be able to gain access to other computers within the organization not accessible outside of the firewall.

Determining Whether to Trust Your Detection Mechanisms

To have confidence that your detection mechanism will detect attacks, you must have confidence that the detection mechanisms themselves won’t fall victim to attack. For example, if you rely on audit logs to alert you to suspicious activity, but the attacker is able to alter the logs—erasing any evidence of the attack—your detection mechanisms are meaningless. And worst of all, you don’t have any evidence that your detection mechanism has been incapacitated or that you are under attack!

Your best bet is to implement a multilayered, defense-in-depth approach. Design your application on the premise that the security detection mechanisms you have in place will be compromised. Ask yourself the following questions: What would be a reasonable backup mechanism if my primary detection mechanism fails? What is an alternate way to detect the same sort of attack? Implement redundant mechanisms to detect an attack. For example, have multiple auditing systems log the same failure. If, for instance, your application encounters an error because of insufficient privileges to access a database table, have both your application and the database system log the failure. In addition, use varying approaches in an effort to detect the same attack. For example, take a snapshot of your database at different points in time and analyze the differences, such as changes in the user name list (or other critical information), that should be reflected in your audit logs but aren’t. This might be evidence that an attacker has erased certain activities from the logs. This sort of database comparison (in the absence of audit logs) might be the only way for you to determine exactly what the attacker has done.

Humans: The Key to Success

Although it would be fantastic if automated systems could detect and prevent all forms of attack, the truth is that automated systems can’t be relied upon to always accurately detect when an intrusion takes place. Moreover, the automated systems put in charge of monitoring your network, computer, or application (including the detection code within your application itself) for signs of attack could themselves be compromised by an attacker. Human oversight is required to help determine whether an attack has been made and to ensure that the systems responsible for detecting attacks are working as expected. It takes humans, for example, to regularly look at audit logs and make the judgment whether an attack has taken place. It takes humans to respond to the attack by identifying and isolating the affected systems, determining a fix, applying the fix, and restoring the systems to a safe and productive state.