HOW MUCH TO LOG

The amount of logging you do depends on storage space and processing power because intensive logging can consume significant resources and cause system instability. Anyone who tells you to log everything conceivable is not helping you. In the real world, such an approach is impractical. You need to anticipate what you need, in order to pinpoint the most relevant information to log.

■■ Warning signs of an onslaught of packets from a denial-of-service (DoS)

attack or worm (intrusion)

■■ Application inputs causing buffer overflows, which then allow for the

execution of arbitrary code chosen by the hacker (both an intrusion and a vulnerability)

An often overlooked, but highly useful, approach to intrusion detection involves studying performance/utilization statistics and looking for trends. This can help you understand if, for example, you are under a DoS attack or if a hacker has made his or her way into your network. I’m reminded of a com- pany (the world’s third-largest corporation at the time) for which my group managed a private network. My group provided regular detailed network uti- lization statistics, and we had noticed a sudden change in network usage along a few of the links and thought it might be an intruder. The customer con- firmed that there was absolutely no justification for this increased usage. In fact, an intruder was on the network and moving large amounts of data between systems.

If you detect a DoS attack, the minimum response is address and protocol disablement and filtering. DoS attacks take advantage of the fact that without adequate filtering, routers will deliver traffic wherever a hacker wishes, regardless of source IP address, destination address, or traffic protocol type. Systems can thus be overloaded and brought to a standstill. We all know we need to filter, but many of us think this should occur only at the firewall. Wrong. You should also configure routers that have the computing power to handle filtering to do so. And follow this essential principle: Disable any com- ponents you don’t absolutely need, and cut off the traffic at the earliest possi- ble point of entry. Other guidelines include the following:

■■ Establish a solid security escalation path with your Internet service

provider (ISP) that lets you quickly notify its engineers to filter DoS- based traffic upstream, within the ISP’s network. Ask your ISP about its procedures for coordinating filtering with its peering partners in response to DoS attacks. Don’t allow yourself to be put on hold with a customer service rep during a DoS attack.

■■ Running systems close to the capacity of the CPU, the memory, the

available storage, and the network bandwidth maximizes vulnerability to a DoS attack. Therefore, monitor resource usage within your system; look for suspicious increases in usage; and allocate sufficient spare capacity to accommodate sudden, unexpected increases in load. Though you may not be able to protect against the largest distributed DoS attacks this way, a hacker accessing a few computers and bom- barding your system shouldn’t necessarily be able to overwhelm your capacity quickly.

■■ Consider the deployment of anti-DoS tools within your network. These

tools work to predict the onset of a DoS attack and help you take proac- tive steps to protect your network.

■■ Perform intrusion detection and vulnerability analysis at every layer of

the security stack and on all computing elements, including the desk- top, servers, network routers, and so forth.

■■ Give serious consideration to deploying desktop-level firewalls and

intrusion detection systems because employees routinely violate policies or otherwise fall prey to malicious software that, when launched from their desktop, can affect not only them but also the rest of the corporate network. This is specially true for laptops because users often install their own software on these systems (despite your content and executable management policies that may prohibit this), and when connecting them to the Internet, laptops can be easily infected in one way or another.

■■ Watch over your intrusion detection and vulnerability analysis systems.

Few things bring a hacker more joy than compromising your intrusion and vulnerability analysis systems. One common hack is to replace your version intrusion detection software with the hacker’s own neutralized (ineffective) version of it. For example, those that use Tripwire and store the Tripwire executable and integrity files on the same system they are protecting represent ideal targets for this type of attack. Protect your intrusion and vulnerability analysis systems. Avoid administering your systems so that the protectors (intrusion detection and vulnerability analysis systems) fall to a hacker as easily, and at the same time, as the systems they are protecting.

The intrusion detection and vulnerability analysis architecture is reliant on tight policies regarding the manner (timeliness, chain of command, response method) in which intrusions and suspected vulnerabilities are addressed. Out- line detailed procedures to take, in accordance with policies, to address intrud- ers and suspected vulnerabilities. These policies and procedures should integrate tightly with incident response procedures.

13. Securing Software: Starting at the Source

For software you have deployed or have developed in-house, conduct a formal security review to assess its potential vulnerability. As part of this review, address any other policies and procedures relating to software disablement, pro- tocol filtering, and protocols used by the software. Assess whether your vendor is able to keep up with needed security patches. On an ongoing basis, assess whether your vendor or your in-house development staff has demonstrated a reasonable track record of producing software that is less vulnerable to hacks.

Information stored in temporary areas (caches, temporary files) for perfor- mance or other reasons leaves nice holes for hackers to jump in. Memory man- agement and buffer management are key to secure software design. Define policies for how software under your control, such as software you develop or have developed for you, functions relative to memory management. It should include procedures for deploying code-checking utilities that attempt to detect the kind of buffer exploits hackers employ to execute arbitrary programs on your hacked systems.

Within your operating system and application server environments, com- puter programs pass data (for example, transactions) back and forth among each other and, in doing so, choose to inherently trust each other, or not. The way that software processes trust each other—that is, the way trust is assigned, delegated, and inherited—is an important part of security and should not be overlooked. It affects how much control a hacker can have over your application or collection of applications and, eventually, business, based on compromise of a single process. If, for example, you have assigned your Web server process full trust (full permission to access everything within the computer) and a hacker compromises that Web server process, he or she will also inherit the permissions assigned to that process. Therefore, the hacker will have full permission to do what he or she wants on the entire computer. In this example, it behooves you to assign only minimal permissions, not all, to your Web server process.

14. Securing Time Services: Keeping Your Eye on the Clock

If you’re wondering what time could possibly have to do with security, con- sider that many of your security systems fully rely on time synchronization among network devices. For example, Microsoft server environments (Win- dows 2000/XP) rely on a security scheme called Kerberos. Kerberos is used to authenticate you to all Windows resources in the network (file servers and so forth). If a hacker tampers with or otherwise destroys time services in the net- work, he or she destroys Kerberos and thus everyone’s ability to reach servers and other resources on the network. For most businesses, that means action pretty much grinds to a halt. Also, public-key infrastructure (PKI; see Chapter 5) relies heavily on synchronized time so that your authentication credentials, called digital certificates, can be determined to be valid or not (to determine if they have expired).

Consider another, simpler example: the logs of your devices. These logs record the valid actions of users and administrators to keep track of security- related events and to track the actions of hackers. If hackers can modify or otherwise change time, they can effectively confound your ability to rely on time stamps in log records.

15. Staff Management: Managing Employees and Contractors

It’s essential to know who you are bringing into your organization. That means you must conduct in-depth background checks. Most companies are far too lax in this area, and the result may be inviting a highly untrustworthy individual into a highly trusted position. Let me give you an example from my own expe- rience. Years ago I was all set to hire a staff engineer for a position that would report to a manager in my organization. This engineer made it through all of the interviews, and human resources informed me we were ready to offer him the job. But just prior to presenting him the job offer, I decided to give him a call (he had indicated I could call him at his current work number if needed). I discov- ered he was no longer with his previous employer, which I found somewhat sur- prising because he gave no indication he would leave before getting an offer. I also noticed that his employer was not very talkative about the engineer’s exit, I got the idea it had not been voluntary. I decided to dig further and, in the process, discovered some amazing information.

First though, my company’s human resources department did, as a matter of course, request a background check (police, FBI) on new employees; in this case, it could often take as long as seven months to get the result from this applicant’s city of residence. Clearly, the human resources department had not really completed the background check, as I had been led to believe. By the time I was done completing my own, I discovered the individual we were about to hire had lied in numerous places on his application, the most glaring being in regard to past incarceration—it turns out he had robbed a bank a few years earlier. I think you get my point.

Another important part of staff management is how you handle termina- tion. If a staff member is in a sensitive position, with access to business-critical systems, do not unexpectedly terminate that person and continue to allow open and unmonitored access to critical systems. Obviously, termination should be an important aspect of your staff management policies and proce- dures, factoring in, of course, how tightly you want or need to run your orga- nization. Just bear in mind that a great deal of system hacks are performed by disgruntled employees.