Chapter 3. Building a Roadmap for Securing Your Enterprise

IN THIS CHAPTER

·        Proactive Versus Reactive Models

·        Benchmarking Your Current Security Posture

·        Identifying Digital Assets

·        Protecting Assets

·        Incident Response

·        Training Users and Administrators

·        Tying It All Together

This chapter will arm you with the guidelines necessary to survive the information security onslaught. The odds are stacked in this battle, and not in the favor of the defenders. If there is to be any hope of coming out of the war victorious, you need a serious strategy. This chapter is designed to give you an introduction to that strategy in the form of an information security roadmap.

Proactive Versus Reactive Models

We have a saying in the consulting field in regard to IT security spending: "The easiest client to sell security services to is the one that just got attacked." Unfortunately, the statement is as sad as it is true. The simple fact of the matter is that most organizations only react to security threats, and, often times, those reactions come after the damage has already been done. For example, patching your legacy systems after an intruder has already stolen your customer records won't help regain consumer confidence. Starting a log monitoring effort after a contractor has sent your research and development data to an overseas competitor will not bring back your competitive advantage. Convincing executives to encrypt their high-value data after their laptops have already been stolen won't reverse their earlier mistakes.

Although all these tactics are positive and encouraged courses of action, they don't stop the problems before they occur. It is for this reason alone that, when operating in a catch-up mode, security programs will only be marginally successful at best. The key to a successful information security program resides in taking a pro-active stance towards security threats, and attempting to eliminate vulnerability points before they can be used against you. By defining and organizing the information security effort beforehand, organizations stand a chance against the seemingly endless onslaught of security threats in the world today.

This is, of course, easier said then done. However, if pro-active security measures are done right, there is a light at the end of the tunnel. You'll want to perform the following tasks to launch a pro-active security program:

·        Understand where the corporation's assets reside

·        Reduce the number of vulnerability and exposure points

·        Secure systems and infrastructure equipment

·        Develop, deploy, and enforce security policies

·        Develop, deploy, and enforce standardized OS configuration and lock-down documents

·        Train administrators, managers, and developers on relevant areas of information security

·        Implement an incident-response program

·        Implement a threat-identification effort

·        Implement a self-audit mechanism

·        Educate, educate, educate, and educate

By getting these efforts off the ground, you can help place your organization in the driver's seat, and help reduce the amount of time you spend chasing your tail.

Benchmarking Your Current Security Posture

Security administration is not about achieving some unobtainable goal of absolute security. Instead, it's about managing risk. There will never be "absolute" security when it comes to computing environments, but there are ways to effectively minimize risk levels through reducing the number of vulnerabilities.

The first thing most people do when they inherit the responsibility of securing an environment is panic. The second thing they usually do is attempt to ascertain the current state of affairs. Understanding the state of the terrain is essential before moves can be made to secure it. This is why most security efforts begin with an assessment of some sort. Whether this assessment comes from an outside third party, or through the use of well-trained internal staff, the following areas should be investigated:

·        The current state of the security policies

·        The current state of security on the network

·        The current state of the system security

·        The current state of security of network applications

·        The current state of employee awareness

·        The current state of management awareness

·        The current state of information security–training efforts

Often times, organizations hire outside consulting firms to assess either all of, or particular components of, the previous list. Although few organizations have all these efforts defined and operating efficiently, it's important to document the status of these efforts. Documentation can be used for a number of things later on, such as aiding in the production of status reports, benchmarking progress, gaining further security funding, and identifying areas that need the most help. Regardless of how it is done, or by whom, getting a good idea of where you presently are can help you define where you want to be headed.

This third edition of Maximum Security can be used to help with many of these needs. For example, Chapter 11 covers the selection of vulnerability assessment tools that can help identify system security holes. Part VI, "Platforms and Security," can help with some of the details surrounding the securing of specific operating systems. Finally, Chapter 26, "Policies, Procedures, and Enforcement," can help with policy definition efforts.

Identifying Digital Assets

When presented with the term asset identification, most IT folks think of asset management, or asset tracking, in the literal sense of the term. Although tracking physical assets is important, rarely do organizations take the time to granularly identify or quantify the value associated with their digital assets. For example, an e-commerce delivery system might comprise a dozen Web servers, a few database servers, a merchant gateway, and various pieces of supporting infrastructure equipment. For example, let's say that a sample medium-sized e-commerce deployment runs around $400,000 in hardware. The machines and systems themselves have a book value that is easy enough to calculate. A little bit more difficult to identify might be the costs associated with a site-wide outage. One would have to calculate hourly or daily revenue losses, as well as the costs associated with expenses necessary to respond to the problem, and any other outage-based costs.

Drilling a little deeper into our example, let us also suppose that the customer records and the purchasing trend data for this e-commerce initiative are stored on a single, internal database server. Again, the financial value of the hardware is easy enough to identify and record. But what happens when that server is compromised, and its data is leaked to the public? There will then be some less tangible, but very important items at risk: consumer confidence, industry reputation, and perhaps even legal liability. So the value of the server, and the data on it, might be a lot higher then what was initially thought.

Why does this matter? Back to the concept of managing risks. In an ideal world, every server, network device, and piece of data would be sufficiently protected. Unfortunately, we don't live in that world. Reality states that we have to choose our battles wisely, as there are only a finite number of them that we can fight. By identifying key assets, and protecting those assets first, organizations can maximize the effectiveness of their risk mitigation efforts.

Readers should note that there have been entire books written on asset identification and data value classification, and how they relate to overall risk analysis. Although many of the areas of true risk analysis are outside the scope of this book, there are some basics areas to look at in the IT field that can help you get started. For example, the following areas are often classified as "high value":

·        Payroll information

·        Research and development data

·        Source code

·        Marketing strategies

·        Financial systems

·        Sales information

·        Customer data

·        Financial reports

·        Miscellaneous proprietary data

Remember, certain data, and certain systems, are more critical than others. It is up to the security officers and the business to determine what systems and data are the most valuable. Remember to choose your battles wisely—if you can only wage war on a few fronts, make sure they are the fronts that really count.

Brooke Paul, one of the contributing authors of this book, wrote an introduction to Risk Assess ment for Network Computing that readers might find useful. It can be found at: http://www.networkcomputing.com/1121/1121f3.html

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.

The CSI/FBI report is not available in electronic format, but you can request a hardcopy of it directly from CSI: http://www.gocsi.com/fbi_survey.htm

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

A.       Your perimeter defenses falter or

B.      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.

One of the easiest ways to stay on top of the onslaught of vulnerability announcements is to subscribe to the NWC/SANS Security Alert Consensus (SAC) newsletter. SAC supplies a summarized, customizable report of the week's vulnerability discoveries to more than 100,000 subscribers. Pulling from more than 70 sources of information, SAC is extremely thorough. You can find this information at http://www.sans.org/nwcnews/.

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.

Incident Response

The ability to respond to a security threat or incident is becoming increasingly more important in today's world. The efficiency with which an organization responds to a given threat can make the difference between a thwarted attack, and tomorrow morning's headline story. Unfortunately, organizations often don't realize this fact until it's too late. However, this shortcoming can be avoided with a pro-active incident response model. Hammering out incident response (IR) policies and procedures beforehand will not only save embarrassment, but time and money as well.

Although today's information security challenges call for a defined IR strategy, the real-world need for incident response pre-dates computers by more then a century. Before taking a look at this need, let's take a brief look at the history and certification of one of the oldest security devices—the safe.

"Tan," a member of the hacker think-tank L0pht, published a paper in the late '90s on the need for a Cyber Underwriters Laboratory. He drew some interesting comparisons between the origins of the UL rating system for safes and the current challenges in the field of security certification. He begins the paper by providing a brief history of the Underwriters Laboratory:

Underwriters Laboratories was founded in 1894 by an electrical inspector from Boston, William Henry Merrill. In 1893, Chicago authorities grew concerned over the public safety due to the proliferation of untamed DC circuits and the new, even more dangerous technology of AC circuits. These new and little-understood technologies threatened our society with frequent fires, which caused critics to question whether the technology could ever be harnessed safely. Merrill was called in and set up a one-room laboratory with $350.00 in electrical test equipment and published his first report on March 24, 1894.

Back in Boston, insurance underwriters rejected Merrill's plans for a non-biased testing facility for certification of electrical devices. Chicago, however, embraced the idea. Merrill took advantage of the situation in Chicago to get up and running and within months had support at the national level.

Today, UL has tested more than 12,500 products world-wide and is a internationally recognized authority on safety and technology. The UL mark of approval has come to provide an earned level of trust between customers and manufacturers and safely allowed our society to leverage hundreds of inventions that would have otherwise been unfit for public use.

You can find Tan's paper at http://www.l0pht.com/~tan/ul/CyberUL.html.

Today, the UL labs are famous for testing many products, one of them being industrial-strength safes. Infamous cryptography expert Bruce Schneier has often pointed out that part of the UL rating for safes is based on how long it will take an attacker to break into the unit. For example, a rating of TL-15 signifies 15 minutes with the use of tools (saws, hammers, carbide-tipped drills, and so on), whereas a rating of TRTL-30 signifies 30 minutes with the use of tools (TL) and a torch (TR). Now, in the real world, these times are important because they set some level of expectation regarding how long an organization has to respond to an attack. For example, if you know that the police and your security guards will be able to detect and respond to an intruder in less than 5 minutes, a TL-15 rated safe might be sufficient for your organization. If, however, you will be thwarting skilled attackers and your response ability is closer to 20 minutes, you might be better off with a device touting a rating of TRTL-30.

Now, transferring this over to the world of information security, this method of approaching the problem has its problems. For example, Tan states in his paper:

The first problem is that if a security system is defeated in the physical world, it is typically very obvious to those who come into work on Monday and see that the money is gone and the safe is in pieces. Detection of a cyber intrusion is typically NOT very obvious to those who come into work on Monday. Because of this fact, safe crackers have very limited time to crack a vault. Hackers, on the other hand, have unlimited time to crack a system. Once they get in, safe crackers typically REMOVE items which then become 'missing'. Hackers typically COPY items unless their motives are political rather than financial, leaving the originals and the system intact. For cyber intrusions to become less surreptitious, intrusion detection needs to mature and become more widely deployed if 'time'is to be a meaningful factor in the process.

The author's points are extremely valid. Making matters worse, Tan assumes that you have something watching your systems, and the ability to respond to such cracking attempts if or when you detect them. Most organizations have neither.

If businesses do not have the ability to properly identify and respond to an attack, attackers will always have the upper hand. In order to be effective at thwarting intruders, security officers should

·        Monitor key assets

·        Consider deploying some method of intrusion detection. (See Chapter 12, "Intrusion Detection Systems (IDS)." )

·        Possess some type of incident response capability

In addition, at a bare minimum, organizations should look to define

·        Who is responsible for responding to security threats

·        What the escalation procedures are

·        The "call list" for decision making should a business-critical decision need to be made

Again, pro-active measures on the IR front will save organizations both time and money.

Two good primers on incident response:

Allaire's Incident Response Guide: http://www.allaire.com/DocumentCenter/Partners/ASZ_ASWPS_Incident_Response.pdf

The SANS Computer Security Incident Handling Step-by-Step Paper: http://www.sansstore.org/

Training Users and Administrators

I've run into administrators in numerous organizations who claim, "Security is not my problem—it's the problem of the security folks." As silly as this statement might sound, many old-school system and network administrators foolishly subscribe to this philosophy. This is not an easy challenge to overcome, but one you must work with, or around, to be successful. Put frankly, security is everyone's responsibility…and everyone's problem. It only takes one vulnerability, one weak link, to break the entire chain.

Unfortunately, getting this message into everyone's head is easier said then done. However, there are a few things that can help the cause:

·        Make sure that the general security policies (like AUPs) are distributed to all employees.

·        Embark on an awareness campaign. This will help to ensure that the general user population understands the threats, as well as help to reaffirm that there is an information security effort within the organization.

·        Identify an executive sponsor who is willing to publish memos to the rest of the company stressing the importance of strong security practices. Again, if it doesn't come from the top, it's hard to enforce.

·        Build responsibility matrices that clearly identify specific security responsibilities within the organization. With management backing, this can be used to drive home the point that security is everyone's duty.

Tying It All Together

As daunting as each of the tasks in this chapter might seem, the most important thing to remember is that efforts must be started to address them in unison. For example, protecting your perimeter won't help with internal intruders when your systems aren't secured. By the same token, even if your systems are secured, it will be hard to defend yourself from distributed denial of service attacks when your network security is in shambles. Finally, even if you have most of the technology problems under wraps, this won't stop your users from making damaging security blunders.

Overwhelmed yet? Don't be. Rare are the organizations that have managed to get on top of all of these issues, which is precisely why defense in-depth strategies are so popular; they help reduce single points of security failure. By building your security strategy around many of these foundational concepts, you can create tiers of protection. Your organization's overall security strength will ultimately depend on how many of these efforts get off the ground, and how successful each of them becomes.

This book can help you with many of the areas you'll need to address. Use it to help identify what you want to protect. Use it to learn about various information security technologies, and how they can make your life easier. Use it to learn about operating system security, network security, and application security. Use it to gain a holistic view of the information security landscape, and learn how to leverage this knowledge in today's technological age.

Summary

In order for organizations to operate a successful information security program, they need to combine technology with discipline. In today's world, the security scene operates at an extraordinary pace and slows down for no one. Without covering the basics and forming a pro-active security model, organizations will be caught in an endless game of catch-up—game that they will ultimately lose.

This book presents many of the foundational principles needed to operate secure computing environments. This book also explains some of the basics: how IP networks work, how vulnerabilities are exploited, and how operating systems are both exploited and protected. The next chapter focuses on one of the most fundamental components security personnel need to understand: TCP/IP.