• Aucun résultat trouvé

Why Implement the Product?

Dans le document Advanced Host Intrusion Prevention with CSA (Page 51-56)

There are many reasons why you would want to deploy a product such as CSA; some reasons are obvious, some less so. This section looks at some obvious reasons first:

For several reasons, you are tired of chasing day-zero exploit issues—by the time you learn of a new critical vulnerability, the folks writing the malicious code that takes advantage of that vulnerability have known about it for weeks, maybe months. Note that in this context, day-zero exploits are defined as vulnerabilities in software exploited or attacked the same day the vulnerability becomes known (zero days from the announcement of the vulnerability to the launch of the attack).

Your anti-virus vendor is not able to keep up or has missed a few key pieces of malicious code (worms, viruses, and so on). Therefore, you want another layer of security.

You are interested in the Cisco Network Admission Control (NAC) and having CSA work with the other pieces of software to help your environment adhere to your security and access policies.

Preventing attacks by using an intrusion prevention product, such as CSA, is more important than just detecting attacks by using an intrusion detection product.

You need additional visibility into your environment’s security posture and want better control of it. BS17799, Sarbanes-Oxley, Health Insurance Portability and Accountability Act (HIPAA) and all the other legal review, certification, and audit issues companies face these days concern you.

CSA can help you in all these areas. Its behaviorally-based policies—which are policies that act based on the behavior of a computer program or system, not the name or signature of a program—can help prevent day-zero attacks or minimize their spread. When you use CSA, you do not have to keep up on signatures or make daily updates. In fact, most enterprise customers do not make more than one or two changes a month after the initial pilot period.

CSA is not a required piece of the NAC security solution, but it can play an integral role in securing endpoints (systems) and helping to secure the end host. It plays this role through its ongoing knowledge of the security of that system and what the network tells it is an acceptable security posture. That acceptable posture includes several factors:

You run the right version of CSA.

You point to the correct MC.

Your CSA is up and running.

You have not mistakenly disabled the CSA.

The NAC solution then makes decisions based on that information and changes your system’s access to the network. These changes are made through the network switches and routers and through CSA via dynamic policy changes called state changes. These changes can raise the security posture of the endpoint system during a period of suspicious activity.

Defining Purpose 31

CSA can also give you valuable visibility into the state of your environment, assisting you with inventory, application-usage tracking, and more to aid in your certification or in the ongoing process tracking for Sarbanes-Oxley, BS17799, HIPAA, and other processes many businesses must follow these days.

What else can CSA offer you? The following list outlines just a few of the less obvious areas in which CSA can assist you:

Application tracking—CSA 4.5 and later provides application tracking. Some of this is useful in gauging compliance with software standards such as the following:

— Is anyone not running Office 2003 Service Pack 1?

— Is anyone still running a vulnerable version of Firefox?

Figure 3-1 shows an example of an Application Deployment and Tracking report design screen in which the report searches the database for

information on all network applications that listen for connections from the network but have not accepted a connection for a specific number of days.

This can be important because, for example, many denial-of-service (DoS) applications might sit dormant on your computers for a long period of time before a connection is made and an instruction given to start attacking.

Figure 3-1 A Report Design Screen for Application Deployment Reporting in Cisco Security Agent 4.5.

Application metering and control—CSA provides answers to the following types of questions:

— How many applications do you have that listen as servers and have not received a connection request in the past 30 days?

— How many applications are not standard server applications. To find the answer to this question, you could request that the CSA show you everything that listens as a server, that is not a Microsoft service, not a known web server application, not a database application, and that did not receive a connection in the past 30 days. Or you might want more information about which applications talk most frequently to which hosts.

Forensic analysis—Perhaps you need some help with the forensic analysis of a worm or piece of vulnerability code. Install CSA on a clean system, establish a set of policies that track every action by any application on the system (such as any file write, read, application execution, buffer overflow, network connection attempt, and so on), but only monitor (logs) the actions. Then attempt to exploit or exercise the vulnerability on your test system to map all the actions taken by a particular piece of code. Note that this is best accomplished within a “safe” virtual PC environment such as VMWare, so that you can control the network access and ensure that you do not attack everyone else. You might suspect that a vendor did something odd in their application but not be sure it is that application. If so, set up a policy for just that application’s executable programs and track it!

Support staff access—Your support staff probably needs broad-based access into users’ systems, so perhaps you want to design a CSA policy geared to that need to ensure support staff’s unrestricted access into every system. However, you do not want to allow the users to have the same unrestricted access. CSA allows you to apply policies based on numerous states, one of which is User or Group. This allows a great deal of flexibility in applying policies based on the state your system is in at that moment.

Patching time—Does using CSA save you from the need to patch again? Well, not quite—patching is eventually necessary, but CSA does give you a window of time.

Normally when a patch is released, you need time to test the patch on noncritical systems and run it through a process that might involve several teams’ analysis of the patch to ensure no adverse effects on existing applications. Here are some things to keep in mind:

— Complete full quality-assurance testing before release to a system

environment. And you can do this in under an hour, right? Given the almost nonexistent time window between the release of a patch to resolve a vulnerability and the spread of a virus, worm, and so on to exploit that vulnerability, you need more time. The resolution time can be limited to hours these days.

Defining Purpose 33

— Because of the behavioral nature of its policies, CSA allows you to have more confidence that your systems are not infected or data destroyed while you take the time to properly test a patch. As an example, it takes only 30 seconds on the Internet today (on an unfiltered connection) to become infected or compromised, so you need time to both test and to get that patch installed.

Dynamic application tagging—CSA behavioral policies take advantage of the ability to dynamically mark an application with various “tags” and then apply policies to that application or the system based on those tags.

The following is an example of dynamic application tagging. Microsoft Word by itself does not necessarily present problems, but what about opening a Microsoft Word document from your network share? The application is tagged as a <Network Application>, and pay a bit more attention to what it does. Now the document you just opened tries to execute some malicious code and open your e-mail address book and e-mail copies of various files on your system to your contacts (along with a copy of the virus). CSA tags that copy of Microsoft Word as a <Suspected Virus Application> and puts some more restrictive rules into effect, stopping both the attack attempt and making sure the user does not have to keep answering question after question as the virus keeps repeating its attacks. However, if you open a second copy of Microsoft Word on the same machine, it is treated as a clean copy, so you are back to the first step of this thought process. This means the new copy of Microsoft Word is considered reasonably trusted again until it does something suspicious.

Source code or intellectual property protection—Every company has intellectual property—information that is worth more kept secret than it would be if it were public. For some companies, it is patentable material, for some it is source code, and for others it is product designs. You can use CSA to protect your data and your applications and system.

The following is an example of protection of intellectual property. You can set up CSA to prevent any data downloaded from an application that talks to the corporate network from being saved to a removable device (such as a writable CD, USB key, and so on). Or maybe you forbid the use of removable media devices altogether. Or you could change the protection “state” of your system depending on where a person is connected, which means that at the office you do not implement as tight a security policy as you do if a person is at the BlackHat security conference in Las Vegas.

In all the areas outlined in the previous list, and in many more, CSA can serve as a flexible tool in your toolbox of security software and can even stretch beyond the area that desktop security software traditionally covers.

Phases

Now that you understand a bit more about what you can do with CSA, this section takes a brief look at the typical phases of a security software rollout and how you should apply them to a deployment of CSA.

To help you understand the deployment phases that apply to your organization and where you might need to apply additional effort, we describe eight broadly defined phases in this section:

Identification of the Project Team

In this stage you need to identify and gather early support from the appropriate groups in your organization that help you have a successful deployment. This chapter discusses this in more detail under the heading

“Important Individuals.”

Scope Development or “The Problem”

In this important phase, you should work as a team to identify two or three key areas that define whether your deployment is a success or not. Some possible areas are discussed in Chapter 4, “Project Implementation Plan.”

Prepilot Work (Information Gathering)

This chapter explains this phase in more detail than the other phases. During prepilot work, you gather all the information you need to properly set and tune your CSA policies and to make key decisions for your pilot and eventual deployment.

Piloting CSA

This phase involves mainly the test group and is related to effectively and efficiently (quickly) testing CSA in your environment. You can then begin to take advantage of the security benefits. This is discussed in more detail in Chapter 4, “Project Implementation Plan.”

Postpilot Analysis

In this phase, your pilot has finished, but what have you learned? Postpilot analysis should feed the metrics you want to gather at deployment time and past that. In this phase, you should also ensure that you gather the data you need to show a return on your investment (ROI).

Deployment Preparation and Training

In this phase, you perform the final testing of your production and development CSA environments in preparation for actual deployment.

Change Management procedures should be in place and tested, personnel with administrative access to CSA should be aware of their responsibilities, and appropriate support staff should be trained on what to expect during and after the deployment.

Dans le document Advanced Host Intrusion Prevention with CSA (Page 51-56)