Protect what you value. Adopting McAfee Host Intrusion Prevention. Best practices for quick success

Transcription

1 Protect what you value. Adopting McAfee Host Intrusion Prevention Best practices for quick success

2 Table of Contents Abstract... 3 Introduction... 3 Need-to-Know Fundamentals... 5 Step 1: Strategize Step 2: Prepare the Pilot Environment... 8 Step 3: Installation and Initial Configuration Step 4: Initial Tuning Step 5 (Optional): Activate Adaptive Mode Step 6: Heightened Protection and Advanced Tuning Step 7: Maintenance and Expansion Next Steps About McAfee, Inc... 17

3 Adopting McAfee Host Intrusion Prevention Best practices for quick success Abstract Blended and zero-day attacks now present more risk than viruses. To safeguard business continuity, preserve data confidentiality, and reduce the pressure to patch, businesses must supplement network-based protection with fine-grained, system-based protection. With the right pilot strategy and some straightforward tuning, you can efficiently deploy McAfee Host Intrusion Prevention (Host IPS) to provide this system protection without disrupting business operations. This paper describes a sequence of steps every administrator should take in order to speed from pilot to broad, successful deployment of McAfee Host IPS. Not a replacement for the McAfee Installation and Product Guides, this paper instead describes the overall strategy for adoption and field-tested best practices throughout the adoption process. Introduction You can direct Host IPS to deliver great value to your organization, reducing patching frequency and urgency, preserving business continuity and employee productivity, protecting data confidentiality, and supporting regulatory compliance. It combines signature and behavioral intrusion prevention system (IPS) protection with a stateful firewall and application blocking to protect all endpoints desktops, laptops, and servers from known and unknown threats. Anything that touches end users and business-critical applications needs to be deployed with care, however, to avoid disrupting business. Risk-sensitive security professionals break down the Host IPS rollout into small, manageable stages that raise protection levels carefully, allow fine-tuning of policies to support business nuances, and minimize end-user change. This slow-but-steady approach provides the maximum protection benefit for the minimum administrative effort, with an elapsed time between one and three months. IPS within Host IPS Host IPS includes three functional groups: the IPS, the firewall, and application blocking. Naturally, all three of these capabilities are beneficial. However, it is best not to initiate all of these functions at once. We suggest you start with the IPS feature, unless regulatory or risk reasons make the firewall your first priority. The IPS function offers critical, universally needed protection against known and zero-day threats. With McAfee predefined policy settings and a modest investment in time, you can quickly get Host IPS started protecting your systems against vulnerabilities and attacks. Once the IPS has been successfully deployed and refined using the tactics in this guide, you will be ready to focus with confidence on activating the firewall and any application blocking functions that match your system and business needs. The software for these added functions will already be installed, since all three functions are part of a single software package. The piloting strategy described here will be applicable in the firewall and application blocking rollouts, although the specific policies, reaction responses, and rules will vary. Tip: If you prefer to start with deployment of a firewall to protect laptops or support payment card industry (PCI) compliance, use the strategy in this guide, but refer to the product manuals for details on defining and activating firewall policies. 3

4 Most administrators can perform these steps themselves. If you prefer, McAfee partners and service professionals can assist you. These experts contributed heavily to this guide. They follow a similar process, as it reliably activates the risk mitigation most businesses need. Let s get started. A few easy stages The recommended pilot sequence follows seven steps: Strategy and planning Preparing the environment Installation and configuration Initial tuning Optional adaptive mode Enhanced protection and advanced tuning Maintenance and expansion beyond IPS Both desktops and servers follow a similar rollout process. However, we recommend more conservative protection starting points and phase timings for your more complex and mission-critical power-user desktops and servers. Implementation distinctions are noted along the way. Notes on timing and expectations For a successful rollout minimal frustration, maximal risk mitigation the adoption process takes from one to three months. Hands-on work occupies just a few days during this period, but time must elapse between stages so that the product can collect the usage data that guides tuning. The biggest variable in your implementation time will be the range of systems and user profiles at your site. The more diverse the user population, the longer it will take to implement Host IPS on all targeted systems. You must activate protections without crippling user productivity and application functionality. Each significant system and user profile merits tuning and testing. Many environments require IT management approval for deployment, migration to blocking mode, and use of the firewall. Factor in extra time for these approvals. Note: All references in this guide point to the McAfee Host Intrusion Prevention 7.0 Product Guide, unless otherwise noted. Potential Pitfalls in IPS Deployments The Top Things NOT to Do 1) Block medium and high signatures without gaining knowledge from logging first. Recommended Best Practice Block only high-severity signatures initially. This level protects against top vulnerabilities, but generates few false events. Medium-level signatures operate on behaviors and usually require at least some tuning to limit support calls. 2) Assume all systems will use the same policies. Segregate desktops to reflect applications and privileges. Start with the simplest systems and create standard usage profiles for major groups. Gradually add more users and more usage profiles as you learn. 3) Perform too little testing on the user experience. Pick a few important user groups, pilot with representative users committed to providing feedback, test that applications still work correctly, and then roll out broadly when policies are proven to work without disrupting productivity. You want to make a positive first impression on users. 4) Treat Host IPS as set and forget. Unlike anti-virus, regular monitoring and regular maintenance are required to maintain the accuracy and effectiveness of protection. Budget time to review logs and update rules at least weekly once you complete deployment. 5) Turn on IPS, firewall, and application blocking simultaneously. 6) Leave the Host IPS, firewall, or application blocking features in adaptive mode indefinitely. 7) Immediately block anything that the system detects as an intrusion. Start with IPS, then add firewall, then add application blocking as needed. You will know how to create policies and be more familiar with the types of protections that are appropriate, and you can correlate changes with results more easily. Use adaptive mode for brief periods when you have time to monitor the rules that are created. Take the time to verify that the traffic you are seeing is indeed malicious. Use packet captures, network IPS, or whatever means you have. 4

5 Need-to-Know Fundamentals Successful adoption begins with a crisp understanding of how the IPS function protects the system, as well as basic policy setting and tuning concepts. How does IPS actually work on the host? The IPS function monitors system and application programming interface (API) calls. It also inspects traffic flowing into or out of a system and examines the behavior of the applications and operating system. Using a combination of signature and behavioral protection, it identifies and blocks hostile attacks as well as exploits that target system vulnerabilities. The behavioral protection envelops applications, allowing each application to access only its own resources and shielding those resources from other applications. Some call this isolation a behavioral bubble. If an application attempts to break out of its bubble by trying to infiltrate another application s files, registry keys, or memory space, the IPS client can block the action and/or log an event. In addition, McAfee s patented generic buffer-overflow protection prevents code execution from illegal memory locations, one of the most common server attacks. Together these IPS styles protect systems against zero-day attacks that target new vulnerabilities without requiring updates and give you time to test patches before you deploy. What are signatures and severity levels? IPS uses signatures patterns of characters and patterns of behavior to identify and prevent malicious activity. Signatures are categorized in a database by severity level, reflecting the danger an attack poses. High Mostly non-behavioral signatures of clearly identifiable security threats or malicious actions, including well-identified exploits. Set these rules to prevent on every system. Medium Signatures of behavioral activity where applications operate outside their envelope. Set these rules to prevent on critical systems, especially web servers and SQL servers. Low Signatures of behavioral activity where applications and system resources are locked and cannot be changed. Setting these rules to prevent increases the security of the underlying system, but requires additional fine-tuning. Information Signatures of behavioral activity where applications and system resources are modified. Changes might indicate a benign security risk or an attempt to access sensitive system information. Events at this level occur during normal system activity and generally are not evidence of an attack. McAfee Avert Labs researchers design IPS rules for specific applications and operating systems, and these signatures are distributed to and maintained on the IPS clients through the McAfee epolicy Orchestrator (epo ) infrastructure. Automatic updates refresh content for the most current protection. Many signatures protect the entire operating system, while some guard commonly exploited applications. Desktop IPS clients contain targeted protection for Internet Explorer and Microsoft Outlook, for example. If Internet Explorer attempts to install a backdoor program, IPS will intercept and deny the application s write file command. For servers, special behavioral signatures target common web and database server attacks, such as directory traversal and SQL injection attacks. What are policies and protection levels? For each severity level, IPS policies define the appropriate reactions: prevent, log, or ignore. Each policy contains rules that define behavior and options to enable or disable application of these reaction rules. Policies are grouped in protection levels. McAfee provides preset basic and advanced protection levels, or you can define your own level of protection. Preconfigured policies include: Basic protection (McAfee default) Prevent highseverity level signatures and ignore the rest Enhanced protection Prevent high- and mediumseverity level signatures and ignore the rest Maximum protection Prevent high-, medium-, and low-severity level signatures and log the rest Prepare for enhanced protection Prevent high and log medium-severity level signatures and ignore the rest Prepare for maximum protection Prevent high- and medium-severity level signatures, log low-severity level signatures, and ignore the rest Warning Log high-severity level signatures and ignore the rest 5

6 Custom protection lets you create or edit policies to define your own IPS protection policy, using the epo console. You can combine any level of severity with prevent, log, or ignore options and adjust the severity of rules as needed. Ask yourself questions such as: What are the specific security exposure areas or recent incidents flagged in audits? Which systems are the most vulnerable? Are mobile laptops a priority? Do regulations mean I must reduce vulnerabilities in a key user community or system group? Configure responses to attacks or suspicious behavior. A security policy may state, for example, that when a client recognizes a medium-level signature, it logs the occurrence of that signature and allows the process to be handled by the operating system, and, when it recognizes a high-level signature, it prevents the process. Multiple-instance policies let you group multiple settings under a single policy umbrella to accommodate different system and user types. You define specific policies for each application, and then layer them together to suit the individual system configuration. For example, you could define two custom policies, one for mail servers and one for database servers. A multiple-instance policy lets you then assign both policies to a system that has both Microsoft Exchange and SQL Server installed. Step 1: Strategize The first step in the first stage is to focus. Think through your system protection strategy, set realistic goals, and create a pilot and deployment plan to match. Define the priorities of the pilot Make sure you understand your security goals and align the pilot process to match. You may need to consciously trade off urgency against your learning curve. You might identify a few specific issues to block immediately, or allow a general monitoring period to simply learn more about what really happens in the client community. Each organization chooses a different balance between protection and productivity. Clear priorities at the beginning streamline the whole process. For many customers, the greatest vulnerabilities are on laptops that leave the controlled enterprise environment. These systems represent excellent first targets for IPS. Some customers would like to bolster key server protections. We suggest these business-critical systems be piloted at a more conservative pace. Write down your key goals, and the next few steps will help you prioritize. Define the pilot environment We recommend you choose a small set of pilot systems on which to run a test adoption. By selecting no more than The Big Picture We re focused on IPS in this guide, but it may help to see the context of an overall Host IPS rollout. In the following example, IPS rolls out in stages, with well-considered additions of firewall and application blocking on specific system types. IPS on laptops and standard desktops IPS on critical servers IPS on power-user desktops Firewall on laptops Expand on server IPS deployment (add firewall, more servers) Add firewall for power-user desktops Explore basic application blocking (learn/blacklist) Step up protections (enforce/whitelist) This is just one example. You could reorder these steps to reflect a more urgent need for firewall, or skip those that are not relevant. Match your organization s goals and risks. 6

7 100 nodes on three subnets, you will be able to move up gradually from initially conservative protection levels. A step-by-step expansion lets you readily manage any issues as they emerge. The question remains: which machines? System class tells Differentiate the major classes of systems and include them selectively in your pilot. From lowest to highest implementation complexity, IPS can support: Standardized end-user desktops or laptops where general-population end users do not have administrative privileges to install or delete applications on their systems. You can create multiple user profiles, each with a defined standard application environment. Customized power-user desktops or laptops where specialized users retain administrative privileges to install their own applications. Power users typically include administrators and software developers. Occasionally, administrative privileges appear as an artifact of the business. Ideally, any systems that don t genuinely require administrative control should have these privileges eliminated to reduce the range of system types that must be profiled and tuned. Servers running dedicated database, web, , or other applications, as well as print and file servers. Lab or real world? Many enterprises require lab testing as a standard step in new product installation. They make images of production machines, either from corporate images or from fresh builds with corporate software, and test these images in a controlled environment before rollout. With IPS, this approach provides the fastest initial baseline of rules, but it is the least effective overall, because it takes out the user variable. Testers artificially mimic user behavior, so they are unlikely to capture genuine detail on legitimate activities. Users and malware always find novel use cases that either generate events that have to be handled immediately or evade detection if unwittingly allowed as an exception for normal behavior. Both of these outcomes consume time and create problems down the road. In our experience, the majority of the learning will happen with live systems in a production environment. The best production testing uses hand-picked machines and objective users performing everyday tasks. This approach provides the most reliable baseline, since real users are really manipulating their systems and applications. They can provide immediate feedback on the impact of changes to protection levels and policies. However, it usually means a slower rollout. For those with the time and resources, a good compromise combines the two models. A lab-test period builds confidence and allows you to become familiar with the processes and policies of Host IPS. After a few usage profiles have been tested, these profiles can be moved to a pilot on production systems. Any activities or applications that may have been missed in the lab test can then be caught in the production pilot. This two-step process suits very conservative organizations. Tip: Administrators should have easy physical access to pilot systems, which typically eliminates unmanned offices and home users from the initial pilot group. Ensure appropriate user representation With an understanding of the system types, you should next identify the usage profiles and machines in your pilot. Include several types of users for a cross-section of your eventual target user community. This breadth will help you create rules and policies that reflect normal business needs and uses. Within a standardized call center or help desk, for instance, you will have managers, front-line support, and back-line support. Be sure to include at least one of each usage profile so that IPS will experience and establish policies for the full spectrum of use. Confirm your rollout strategy Option 1: Simplest first For fast implementation of initial protections and a lowstress learning curve on advanced protections, we suggest activation of basic protection on just your standardized desktops and laptops, accompanied by activation of logging on your power-user desktops and servers. Basic protection is the default policy for IPS. It will block activities that trigger high-severity signatures, requires no tuning, and generates few events. Its settings include: IPS protection is enabled; activities triggering highseverity signatures are blocked, and all other signatures are ignored McAfee applications are listed as trusted applications for all rules except IPS self-protection rules; as trusted applications, they operate without generating exception events 7

8 Predefined applications and processes are protected Firewall, quarantine, and application blocking protection are not enabled Although makes and models of desktops and laptops differ, they fall within a relatively narrow set of variations. Extensive experience allows IPS to cover the high-severity issues with very high accuracy. During the last few years, for example, McAfee has demonstrated that 90 percent or more of Microsoft Patch Tuesday issues were shielded using the out-of-the-box basic protection level. Activating even default protection offers significant immediate value. We strongly recommend this simplest first strategy. Servers may be the most critical systems to protect, but they may also be the trickiest. They require more attention to deploy, as IPS rules must inevitably be adjusted to allow legitimate application operations and reflect the careful performance and system optimization of most servers. Trial-and-error tuning of rules can be dangerous on live, mission-critical systems. Similarly, power-user systems tend to have a diverse set of applications and special privileges, such as the right to run scripts. Activating IPS can spawn a large number of events that must be carefully reviewed to ensure appropriate permission or blocking. Power users and servers merit extra time to understand legitimate usage. Monitoring and logging While activating basic protection on your standard desktop machines, you can also initiate logging of medium-severity issues on these machines. This monitoring will help you discover other events that IPS will flag when you begin locking down controls more tightly. In logging mode, you see the volume of use, as well as the types of use, so you can really learn about the system behavior. We recommend logging in this first phase to ensure no surprises or disruptions. It s a good idea to log events for a full business period, at least a month and perhaps a full quarter, to see the full range of applications and activities. Use the prepare for enhanced protection policy to do this automatically. This setting will prevent high-severity and log medium-severity signatures, but ignore the rest. For your other systems, servers, and power-user desktops, set monitoring and logging for medium and high severity levels. There is no default setting that logs both medium and high levels, so you will need to duplicate an existing policy and customize it. Observing only medium- and high-severity events provides a good level of relevant information without drowning you in details. You will discover the system variations where server platforms are tuned to each specific application instance, or developers have their pet tools and arcane compilers. Tip: Activation of monitoring and logging should not affect system or application operations, but it s always wise to monitor systems closely as IPS goes live, even in a log-only mode. Because IPS works through low-level interaction with applications and operating systems, it is always possible that it may affect performance of some applications. Plan to expand As confidence grows during the pilot, you can move signatures from logging to active enforcement by class of system, tuning rules and refining policies as you learn which activities are legitimate. We describe this process later in this guide. Option 2: Go with basic protection everywhere. For some environments, a legitimate approach is to take advantage of the McAfee expertise packaged in the default settings and deploy the basic protection profile out of the box on all systems. This approach works well for users who want core IPS protections without much tuning or effort. If IPS isn t the primary reason you purchased the product, this strategy provides a minimal-effort deployment that activates immediate protection against the big attacks. Take the plunge Option 1 helps you gain the most protection benefit from your IPS investment. Option 2 presents a reliable, lightweight strategy. Pick the course that matches your risk posture. Step 2: Prepare the Pilot Environment Once your priorities, targets, and protection strategy are defined, you should review your environment to meet technical prerequisites and eliminate any system issues prior to installation. This pre-work will let you focus on the IPS deployment and avoid potential derailments unrelated to the IPS software. Install/update McAfee epo Before installing IPS, you must first have the epo server (minimum of v3.61 with the latest patches) installed, and you must install McAfee Agent (minimum CMA v3.6 Patch 3) on the target hosts. 8

9 More than just using epo to install the application, you will need to have an understanding of policy implementation with epo in order to successfully adopt Host IPS. If you are not already familiar with policy creation using epo, refer to the McAfee epolicy Orchestrator 4.0 Product Guide for details. Why epo? Host IPS requires epo. Unlike McAfee anti-virus systems, where the automated signature (DAT) update infrastructure means that epo can be optional (a set-and-forget model), a Host IPS deployment relies on organization-specific policies and rules that are routinely adjusted as the business and user community change. To support sane and efficient policy maintenance through these transitions, Host IPS takes advantage of the proven infrastructure of epo. Use of epo increases the consistency of policy application, decreases errors, and improves administrator visibility and control. The agent communicates policies to the IPS client The IPS client enforces the policies and generates event information, which it feeds to the agent The agent transmits event information back to epo At scheduled intervals, or on demand, the epo server will pull content and functionality updates from the McAfee repository and the agent will pull them from the server to update the IPS client As policies change, they will be pulled down by the agent to update the IPS client Use epo to set up usage profiles and clients For each distinct usage type web servers, laptops, kiosks you should create a distinct epo usage profile. You will eventually associate these profiles with specific IPS policies, and it will be helpful to have the profiles in place in advance when you need to manage exceptions. epo Server and Repository Server Client Agent Pulls Policy and Content Updates Policy Enforcement Agent Enforces New Policy and Content Updates epo Agent Server Communication McAfee Agent Host IPS client Agent Forwards Events and Client Rules Agent Gathers Events and Client Rules Edit all Host IPS client policies Host IPS Administrator Host IPS Administrator Edit Host IPS client settings Host IPS Client User Tip: epo version 4.0 allows logical tagging of systems. Tags are labels that can be applied to one or more systems manually or automatically. Sort systems into pilot groups based on tags and use tags for report criteria. Group the clients logically. Clients can be grouped according to any criteria that fit in the epo system tree hierarchy. For example, you might group a first level by geographic location and a second level by operating system platform or IP address. We recommend grouping systems by Host IPS configuration criteria, including system type (server or desktop), key applications (web, database, or mail server), and strategic locations (DMZ or intranet). Process overview: IPS installation and maintenance using epo The epo server works with McAfee Agent on each host to install the IPS client on each target system IPS policies are created and maintained within the epo management console The epo server communicates policies to the agent on the host system The naming convention matters. Ideally, you should establish a naming convention easy enough for anyone to interpret. Clients are identified by name in the system tree, in certain reports, and in event data generated by activity on the client. Check for health of pilot systems Now that you have the clients identified, be sure there are no pre-existing system issues that will disrupt deployment. Examine the relevant log files for the epo server, as well as the system event logs. Look for errors or failures that indicate improper configuration and system anomalies that 9

10 may affect the success of the Host IPS installation. Errors should be remediated prior to Host IPS installation. Some key elements to look for: Patch levels Are all drivers and applications up to date? Older media and audio players, Internet Explorer, and drivers for networking cards have been known to create inconsistencies that abort the installation. Apply the latest patches and hot fixes. Incompatible software Are other intrusion detection or firewall applications running on the host? You may need to disable or remove them. Administrative access You must have administrative access to the system. Note whether or not the user has administrative access as well. Why? The user may throw off the test process if they install a new application during the test, so you should be aware of these privileges. Consider placing this system in a different usage profile as a power user if you cannot eliminate end-user administrative access. Organizational considerations Some machines need special attention due to magnifying applications, use of a different language, location-specific applications, and homegrown applications. Consider holding back on these systems until a second phase of the deployment, or excluding these specialized applications from IPS protections until you have time to log and analyze their behaviors. (See Optional Base Policy Configuration in the next section.) Step 3: Installation and Initial Configuration You ve planned. You ve prepared. At last, it s time to deploy. Install Host IPS management software on the epo server and import the Host IPS client software into the epo repository On the epo server system, install the Host IPS management component, either Host IPS server for epo or Host IPS extension for epo 4.0, which provides the interface to Host IPS policy management in the epo console. Import the Host IPS client into the epo repository on the server. Remember to check for any patches or knowledge base articles on the McAfee Service Portal at mcafee.com/eservice/default.aspx. Download updated content from See the McAfee Host Intrusion Prevention 7.0 Installation Guide for details. Set initial protection levels and responses Your earlier investment in strategy and usage profiles pays off now. Implement your strategy by defining or associating protection levels with each usage profile. If you are following a simplest first strategy, you will activate basic protection for your standard desktop usage profiles. Refer to Working with IPS Protection Policies for instructions. Refine baseline policies (optional) Some administrators tweak protection defaults immediately, before starting the deployment. You can elect to automatically protect high-risk applications (those that launch as services or open network-facing ports) and home-grown applications. Applications developed in-house are frequently excluded from IPS at the beginning of a deployment, especially if they listen for network connections. Internal software developers may not be as rigorous as commercial developers in programming expected and secure behaviors. For instance, a program that links to Internet Explorer might inadvertently trigger an Internet Explorer protection signature if the program misbehaves. Since internally developed applications are not typical attack targets, existing unseen and unknown to hackers, they present a lower risk of exploit. Consider adding the IP addresses of your vulnerability scanners to your list of trusted networks. Your existing epo and security policies may provide additional guidance on obvious activities to block or allow for individual usage profiles. Eventually, you can use adaptive mode to selectively define rules for excluded applications and implement protection. This step can be performed when you have established baseline protections and become comfortable with IPS signatures and policies. See Management of Policies for more details. Notify end users and plan escape hatches Before IPS activation, notify users that they are receiving a new protection, and that escape hatches are available in certain cases. This communication will reduce perceived risk to end-user productivity, especially important for users who will be taking laptops on the road. During the pilot, users can override IPS blocking in three ways. The administrator can: Generate a limited-time password Delegate to the end user a specific ability to disable modules Allow end users to completely remove Host IPS if necessary 10

11 You should not hand out these workarounds too liberally: you don t want users to undermine the rollout. Two of these doors will be closed later in the pilot. See Working with Client UI Policies. Enlist the help desk team Let your help desk know that you are about to activate Host IPS. While there should be few issues, they should be prepared to recognize symptoms. You may end up working to prove the innocence of Host IPS in a situation, but that s the normal world of security software administration. Install Host IPS to pilot hosts Start small, installing just a few clients, and expand to more systems in larger increments as confidence grows. Start with one, then 10, then 20, then 50, up to 100 systems. Here s the rollout sequence: 1. Ensure the target hosts are powered on, networked, and communicating to epo 2. Use an epo deployment task to push Host IPS agents to a small set of hosts within the pilot group 3. Validate successful installation. Troubleshoot and make adjustments if needed. 4. Expand to more systems As the installation progresses, check pilot systems for proper operation of the new software and monitor epo logs for server events and any major effect on network performance. There will likely be a few issues that emerge: that s exactly why a pilot and slow rollout are important. 1. Check that the Host IPS service and framework service are started 2. Critical: Run simple applications, such as accounting, document editing, , Internet access, multi-media, or development tools, to test that they operate correctly. Can your users perform their standard jobs? You are looking to demonstrate and validate proper operational detection. 3. If you see issues on the client, you can examine IPS client logs and client operating system logs for errors. See Working with Host Intrusion Prevention Clients. Repeat these steps to expand to more systems until you have populated the pilot group. Tip: Remember to test at each installation or policy change to ensure that end users can perform their jobs successfully. This testing may be the single most valuable activity in ensuring a successful rollout. Step 4: Initial Tuning With your pilot group up and running, you can now wait and watch for a while. Let two days to one week elapse to allow events to accumulate, but don t turn your back on the pilot. Be responsive to any support calls. Daily monitoring It s important for administrators to appreciate that IPS differs from anti-virus or appliances designed to be installed and generally ignored while they manage threats autonomously. From the beginning, allow a few minutes every day to review IPS event logs and monitor activity volumes and types. This habit helps you gain a baseline of normal operational levels and activity patterns. For instance, in daily monitoring you should notice the regular processes and activity levels of server maintenance and application updates. With this knowledge of baseline activities, you will immediately recognize any unusual activity that arises. Eventually, your daily reviews will include refinement of rules, policies, and exceptions as new events occur. Host IPS provides fine-grained control because it can monitor all system and API calls and block those that might result in malicious activity. Similar to a network IPS system, additional rule tuning will be necessary from time to time as applications, business, and policy requirements change. Tip: Often when people are scanning logs, they become jaded by the repetition and miss specifics that would trigger a different rule decision. During extensive reviews, take occasional breaks and come back fresh. Ongoing maintenance of a Host IPS deployment includes monitoring, analyzing, and reacting to activities; changing and updating policies; and performing system tasks, such as setting up user permissions, server tasks, notifications, and content updating. These activities need to be budgeted for at an operational level to maintain the health and effectiveness of the IPS functions. 11

12 Begin tuning to improve protection and enable legitimate business operations For the above list of triggered events, you should now work to: Elevate protection for logged events that should be blocked Eliminate false positives based on legitimate business activities A client can be told to react in one of three ways: Ignore No reaction; the event is not logged, and the process is not prevented Use epo dashboards to monitor events and trends. After a few days, review logs Your accumulating event logs will help you refine policies to balance protection against freedom of access to information and applications. This balance usually differs for each user type. At this stage you will tune policies manually, through epo. Later, we discuss automatic policy generation using adaptive mode. Start by analyzing the logs. Within epo, look at the Events tab of the Host IPS tab under Reporting. You can drill down to the details of an event, such as which process triggered the event, when the event was generated, and which client generated the event. You are looking for red flags, such as spurious false positives or high-severity triggered signatures. Check that processes and services are correct. Applications you expect to run should be running, while applications you don t expect to see should not appear. If you see logged events based on legitimate activities, most common with internally-developed applications, these false positives can be resolved in the next step. Tip: It is fairly common for events to be generated and blocked with no visible effect on the end user or the operation of the application. For example, VMware envelopes and Adobe applications frequently exhibit this behavior. It is safe to ignore these events if you can confirm that the user experience is unchanged. You may be closing a loophole, such as a cross-site scripting vulnerability, that might otherwise be exploited. Log The event is logged, but the process is not prevented Prevent The event is logged, and the process is prevented Tip: Keep a browser window or tab open to the IPS Events section of the epo 4.0 console and use a separate window to manage the IPS product. You won t lose your spot in the system tree or in the policy when you flip back and forth. Tune reaction rules First, for those systems that have been monitoring in log mode, you should invoke prevent mode for any Severity-1 signatures. Create exceptions Next, identify events that flag legitimate behavior that should be allowed, or perhaps allowed and logged. You can reduce these false positives by creating exception rules and trusted applications, or by simply adjusting the reaction responses. Edit exception rules to manage behavior. 12

13 Create exception rules to override a security policy in specific circumstances. You can set a reaction response to ignore and events will no longer be logged. For example, though a policy might deem certain script processing to be illegal behavior, some systems in your engineering groups need to run scripts. Create exceptions for the engineering systems so they can function normally, while the policy continues to prevent scripts on other systems. Make these exceptions part of a server-mandated policy to cover only engineering. Exceptions enable you to reduce false-positive alerts and minimize needless and irrelevant data flowing to the console. By reducing the noise, you will more readily identify important events in your daily monitoring. Tip: Make the exception just generic enough that it will work on all similar systems under the same or similar circumstances. Create trusted applications Trusted applications are application processes that are always permissible. Trusted applications vary by usage profile. You might require certain software applications for normal business in some areas of the company, but not in others. For example, you might permit instant messaging in your technical support organization, but prevent its use in your finance department. You would establish the application as trusted on the systems in technical support to allow this use. Refer to Configuring a Trusted Applications Policy in the product guide for more details. Use queries to obtain data about a particular item and filter the data for specific subsets of that data: for example, highlevel events reported by particular clients for a specified time period. Look for signatures that are triggered most often. Are these day-to-day legitimate business functions that should be allowed? Adjust the severity level to a lower level for these signatures. Some desktop exceptions prove to be erroneous behaviors of legitimate applications, and you do not need to permit these behaviors. Validate that the user application functions correctly and continue blocking. Finally, the qualitative factor: Have you received any user complaints? You should talk directly with users to validate that their applications are operating appropriately. As you make decisions about tuning during the pilot, you follow this process: Edit policies Use epo to edit and create policies and reactions Apply rules selectively Use epo to apply the rules to the target systems (not automatic) Activate the changes When you change Host IPS policies in the epo console, the changes take effect on the managed systems at the next agent-server communication. By default, this interval occurs once every 60 minutes. To enforce policies immediately, you can send an agent wake-up call from the epo console. Test your changes Re-validate operational success for these changes, including compatibility with business systems (allowing legitimate activity). Look to see that IPS network traffic is minimized and that you are reducing the false positives you were targeting. Apply rules more broadly If the new rules work, apply them to relevant systems Continue daily monitoring Refer to Working with IPS Rules Policies, Working with IPS Exceptions, and Managing IPS Events for specific instructions on tuning policies. Configure dashboards and reports Now that you have imposed more order and accuracy on your events, you can use epo to improve organization and communication of IPS information. If you are using epo v4, configure epo dashboards for a quick overview of ongoing policy compliance, event trends, query results, and issues. Save unique dashboards to reflect daily monitoring, weekly reviews, and any management reports. Configure notifications to alert specific individuals when particular events occur. For example, a notification can be sent when a high-severity event triggers on a particular server. Schedule reports to run automatically and be sent to appropriate parties as an message See Management of Information and Notifications for Host IPS Events for more details. 13

14 Wait and watch Monitor events daily for another two weeks or more, checking for help desk calls, anomalies, and false positives. With our relatively conservative rollout strategy, there should not be many support calls or issues, so there should not be many adjustments. Disable escape hatches Disable the workarounds below. This step helps prevent users and malware from circumventing IPS protections. Delegate to the end user a specific ability to disable modules Allow end users to completely remove Host IPS if necessary Step 5 (Optional): Activate Adaptive Mode Meanwhile, your more complex and custom systems have probably been in log mode. Once you have completed a business cycle of logging, you can begin to implement welltargeted rules to create custom policy sets for these systems. These policies can be defined manually, but adaptive mode provides a powerful tool for creating IPS rules based on host activity, without administrator action. As an application is used, a rule will be created to allow each action. Adaptive mode triggers no IPS events and blocks no activity, except for malicious exploits (high signatures). Exceptions that trigger rules will be logged by epo as IPS Client Rules, however, so that you can monitor progress. By setting representative hosts in adaptive mode during the pilot, you can create a tuning configuration for each usage profile or application. IPS then allows you to take any, all, or none of the client rules and convert them to server-mandated policies. When you finish tuning, turn off adaptive mode to tighten the system s intrusion prevention. (In addition to adaptive mode, the firewall and application blocking functions have a learn mode, which requires the administrator or end user to approve rules before they are implemented.) Note that adaptive mode blocks all high-severity alerts by default. If you have only been monitoring to this point, be alert in case this new enforcement affects system behavior, especially for home-grown applications. Use adaptive mode to manage both medium- and highseverity signatures. This combination gives you a good overview of activity without too much noise. Adaptive mode creates exception rules very efficiently. However, it s unlikely that all activities on a given system should be allowed, or you would not be considering new protections. For this reason, you should use adaptive mode for a limited time, you must closely review each rule created (there s only one instance of each rule), and you must de-activate unacceptable rules that adaptive mode creates. When you activate adaptive mode, choose the policy option to Retain Client Rules. Otherwise, the new rules will be deleted at each policy enforcement interval and will need to be relearned. Eventually, when you elect to turn off adaptive mode and move to enforcement, you ll want to turn off Retain Client Rules and eliminate any rule that is not asserted by an epo-delivered policy. The sequence should be: 1. Activate adaptive mode for a specific period (at least a week and up to 30 days) 2. Evaluate exceptions and adaptive rules 3. Deactivate inappropriate rules 4. On the IPS Client Rules tab, move legitimate rules directly to a policy for application to other clients 5. Deactivate adaptive mode 6. Turn off Retain Client Rules if you ve set this option Logging mode helped you understand the frequency of activities. Correspondingly, adaptive mode tells you the full range and type of activities. These two tools used together provide a good functional baseline for your organization s legitimate business activities. You should expect, though, that there will be irregular activities that won t be captured during the pilot cycle, so be prepared to review exceptions and manually create rules on occasion. A user might run a homegrown application once every four months, for example, and miss both the logging and the adaptive mode cycles. 14

15 Important: Adaptive mode allows both legitimate and inappropriate activities. Rules that accept these activities will be created without administrator approval. Only one exception event is logged per rule created, so the same activities go undocumented after the rule is created. You receive only one notice, so you must review and respond diligently in order to prevent unacceptable rules. Best practices with adaptive mode For maximum protection, you can ensure in advance that some signatures are never overridden. Just edit the rules for the signature to disable the Allow Client Rules options. Run clients in adaptive or learn mode for at least a week to encounter all normal activity. Choose times of scheduled activity, such as backups or script processing. As with logging, you can track client exceptions in the epo console, viewing them in regular, filtered, and aggregated views Use the automatically created client rules for each exception to define new, more detailed policies, or add the new rules to existing policies, then apply the updated policies to other clients When you turn on adaptive mode, select the policy option to Retain Client Rules. If you don t, rules will be deleted after each policy enforcement interval. Use adaptive mode for a concrete period during which you can commit to reviewing the exceptions and rules that are created. Deactivate adaptive mode if you cannot review the rules to avoid allowing risky activities. Adaptive mode helps when you need to create rules for a new application. Turn on adaptive mode briefly to exercise the application, and then promote appropriate rules. Tip: Remember to deactivate adaptive mode, so no rules will be created without your knowledge. Please refer to Working with IPS Policies or contact a McAfee partner or service professional for detailed assistance with fine-tuning policies and using adaptive mode. Step 6: Heightened Protection and Advanced Tuning Now that you have established and tuned baseline responses to activities, you can start to increase levels of protection and enforcement. These tuning steps can be performed in the context of day-to-day monitoring, or you may choose to repeat the formal iterative steps of the pilot. After each step, wait at least two weeks before considering additional changes. This time ensures systems are working correctly at their existing levels of protection. Move standardized desktops from basic protection to enhanced protection, by way of prepare for enhanced protection The enhanced protection level will prevent high- and medium-severity level signatures and ignore the rest. By using prepare for enhanced protection, you will take the interim step of logging the medium-severity levels first. As we have discussed with servers and power-user desktops, logging provides detailed knowledge of which activities will be affected when you raise the protection level, guiding accurate policy management and limiting surprises. When you are satisfied that business will continue without disruption, move settings to enhanced protection. Repeat this loop for the other systems in your network. Maximum protection suits the most dedicated and hardened operating environments. Since maximum protection blocks even low-level signatures, it should be deployed very judiciously after extensive testing. Again, use prepare for maximum protection as a proving ground to discover the impact of changes prior to activating maximum protection. Extremely conservative organizations can roll out each change in protection level as its own pilot, following the iterative steps we ve discussed. Remember to enable and disable escape hatches and adaptive mode before and after the testing cycles that validate changes. Continue tuning Review exceptions and any issues that emerge. Manage these as discussed in the initial tuning step. Monitor service desk calls and user comments for any complaints or business issues raised by blocked access, false positives, or new application behavior. These issues should be minimal, but there are always new requirements. 15