Protecting Assets

Most organizations start identifying security risks at the perimeter (usually their firewalls) and move in. Although the perimeter is important, the narrow vision of this strategy has contributed to the sad state of affairs that we face today.

There's been a long-standing holy war in the information security scene that pits the notion of the internal threat against that of the external one. Pundits on the internal threat state that the highest documented financial losses occur because of intrusions instigated by insiders. The opposing school focuses on the rising trend of external attacks. The fact of the matter is that we simply don't have enough data to prove either stance. Much of the speculation is based upon reports such as the annual CSI/FBI reports, which draw upon such a statistically small sample size that it's hard to draw any definitive conclusions.

However, one thing is for certain: In only protecting your perimeter, your organization becomes primed for compromise if either

1. Your perimeter defenses falter or
2. An insider attacks you.

Organizations should look to defend both their perimeter and their internal assets, and should do so by creating a defense-in-depth strategy. Part IV, "The Defenders Toolkit" demonstrates a number of technologies that can aid in this quest. However, it should be noted that by not creating multiple tiers of security, organizations put themselves at risk.

Identifying and Removing Vulnerabilities

One of the most common methods of entry for intruders is through the use of known operating system and network vulnerabilities—vulnerabilities that can usually be remedied through patches or minimal configuration changes. Because of this, it is important that organizations look to implement procedures to discover, evaluate, and mitigate security vulnerabilities in a timely manner. This discovery process should be twofold:

• Use tools such as a vulnerability assessment scanner (see Chapter 11) to discover both new and old vulnerabilities.

• Identify individuals in the organization who are responsible for monitoring weekly security announcements (from SANS SAC, SF BUGTRAQ, and so on) and initiating patching efforts. Chapter 25, "Mining the Data Monster," has more information on keeping on top of the plethora of security information sources available.

Without both efforts operating in succession, you run the risk of being open to some of the most prevalent attacks in the security scene today.

Developing Standardized Build Documents

Small to mid-sized organizations might have an assortment of platforms to support. Large organizations often have dozens. It's not uncommon to have an IT staff tasked with supporting Solaris, Windows NT, NetWare, Linux, HP/UX, AIX, AS/400, and OS/390-based systems. Each of these system types has its own set of security features, and its own set of vulnerabilities. Organizations need to be both aware of these issues as well as continue to operate the systems in a secure manner.

So how can organizations cope with the myriad of potential security nightmares? One method is to standardize the way operating systems are configured and deployed, and then keep an eye on vendor announced updates. Although production servers will have a level of customization applied to them based on function, most systems can be installed with a baseline configuration. If this configuration has been properly hardened from a security perspective, administrators will have an easier time keeping them secure.

One way to arrive at a baseline configuration is to seek a consensus among system administrators and security personnel on what a "secure" configuration of a particular OS should be. This should include necessary patches, service packs, or configuration changes that will improve the security of the target OS. It is important to remember that no operating system is secure out of the box—this is a mistake many organizations make and pay for.

Readers should read Part VI, "Platforms and Security," later in this book to learn about vulnerabilities within specific platforms and to help identify what their strategy will be for securing various platforms (UNIX, Microsoft Windows, NetWare, and so on).

Developing and Deploying Policies and Procedures

Although they have less sex appeal than cutting edge intrusion detection technology, enforced policies are the cornerstone of any strong information security practice. Security officers should think of policy as being the constitution governing the secure operation of their environment. Without approved policies, it is often extremely hard to enforce and defend security actions. Policies are sometimes your last line of defense.

Organizations should have policies that address at least the following issues:

• Acceptable usage
• Data value classification
• Data disclosure and destruction
• Roles and responsibilities
• Change control
• Disaster recovery

Perhaps the hardest part of successful policy implementation is getting upper management approval. Unfortunately, without management approval policies do not hold any weight, and are virtually unenforceable. Policies and procedures are gone over in more detail in Chapter 26.