best practices guide - ibm · contents siteprotector best practices guide, version 2.0 sp5 v...

®

Best Practices GuideVersion 2.0, Service Pack 5

Internet Security Systems, Inc.6303 Barfield RoadAtlanta, Georgia 30328-4233United States(404) 236-2600http://www.iss.net

© Internet Security Systems, Inc. 1994-2005. All rights reserved worldwide. Customers may make reasonable numbers of copies of this publication for internal use only. This publication may not otherwise be copied or reproduced, in whole or in part, by any other person or entity without the express prior written consent of Internet Security Systems, Inc.

Patent pending.

Internet Security Systems, System Scanner, Wireless Scanner, SiteProtector, ADDME, AlertCon, ActiveAlert, FireCell, FlexCheck, Secure Steps, SecurePartner, SecureU, and X-Press Update are trademarks and service marks, and the Internet Security Systems logo, X-Force, SAFEsuite, Internet Scanner, Database Scanner, Online Scanner, Proventia, and RealSecure registered trademarks, of Internet Security Systems, Inc. Network ICE, ICEpac, and ICEcap are trademarks, and BlackICE is a licensed trademark, of Network ICE Corporation, a wholly owned subsidiary of Internet Security Systems, Inc. SilentRunner is a registered trademark of Raytheon Company. Acrobat and Adobe are registered trademarks of Adobe Systems Incorporated. Certicom is a trademark and Security Builder is a registered trademark of Certicom Corp. Check Point, FireWall-1, OPSEC, Provider-1, and VPN-1 are registered trademarks of Check Point Software Technologies Ltd. or its affiliates. Cisco and Cisco IOS are registered trademarks of Cisco Systems, Inc. HP-UX and OpenView are registered trademarks of Hewlett-Packard Company. IBM and AIX are registered trademarks of IBM Corporation. Intel and Pentium are registered trademarks of Intel. Lucent is a trademark of Lucent Technologies, Inc. ActiveX, Microsoft, Windows, and Windows NT are either registered trademarks or trademarks of Microsoft Corporation. Net8, Oracle, Oracle8, SQL*Loader, and SQL*Plus are trademarks or registered trademarks of Oracle Corporation. Seagate Crystal Reports, Seagate Info, Seagate, Seagate Software, and the Seagate logo are trademarks or registered trademarks of Seagate Software Holdings, Inc. and/or Seagate Technology, Inc. Secure Shell and SSH are trademarks or registered trademarks of SSH Communications Security. iplanet, Sun, Sun Microsystems, the Sun Logo, Netra, SHIELD, Solaris, SPARC, and UltraSPARC are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. in the United States and other countries. Adaptive Server, SQL, SQL Server, and Sybase are trademarks of Sybase, Inc., its affiliates and licensers. Tivoli is a registered trademark of Tivoli Systems Inc. UNIX is a registered trademark in the United States and other countries, licensed exclusively through X/Open Company, Ltd. All other trademarks are the property of their respective owners and are used here in an editorial context without intent of infringement. Specifications are subject to change without notice.

Disclaimer: The information contained in this document may change without notice, and may have been altered or changed if you have received it from a source other than ISS or the X-Force. Use of this information constitutes acceptance for use in an “AS IS” condition, without warranties of any kind, and any use of this information is at the user’s own risk. ISS and the X-Force disclaim all warranties, either expressed or implied, including the warranties of merchantability and fitness for a particular purpose. In no event shall ISS or the X-Force be liable for any damages whatsoever, including direct, indirect, incidental, consequential or special damages, arising from the use or dissemination hereof, even if ISS or the X-Force has been advised of the possibility of such damages. Some states do not allow the exclusion or limitation of liability for consequential or incidental damages, so the foregoing limitation may not apply.

Reference herein to any specific commercial products, process, or service by trade name, trademark, manufacturer, or otherwise, does not necessarily constitute or imply its endorsement, recommendation, or favoring by Internet Security Systems, Inc. The views and opinions of authors expressed herein do not necessarily state or reflect those of Internet Security Systems, Inc., and shall not be used for advertising or product endorsement purposes.

Links and addresses to Internet resources are inspected thoroughly prior to release, but the ever-changing nature of the Internet prevents Internet Security Systems from guaranteeing the content or existence of the resource. When possible, the reference contains alternate sites or keywords that could be used to acquire the information by other methods. If you find a broken or inappropriate link, please send an email with the topic name, link, and its behavior to [email protected].

December 13, 2004

http://www.iss.net

mailto:[email protected]

Contents

Contents

Preface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiOverview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiHow ISS Products Are Referenced in the Best Practices Guide. . . . . . . . . . . . . . . . . . xiiiGetting Technical Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvConventions Used in this Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .xvii

Part I: Assessment and PlanningChapter 1: Overview of Security and Implementation Strategies . 3

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3Security Strategies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6Implementation Strategies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Chapter 2: Assessing Your Organization . . . . . . . . . . . . . . . . . . . . . . . 9Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9Determining Which Assets Are Critical . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11Determining the Best Strategy for Your Organization. . . . . . . . . . . . . . . . . . . . . . . . 13Minimum Protection Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16External Threat Protection Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17Internal Threat Protection Strategy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18Maximum Protection Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Chapter 3: Protecting Your Assets . . . . . . . . . . . . . . . . . . . . . . . . . . . 21Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Section A: Deploying Network Protection . . . . . . . . . . . . . . . . . . . . . . . . . . 23Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23Network Intrusion Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24Introducing NPSs to your Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26Network Scanning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27Types of Network Scans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29Minimum Protection Strategy For Networks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31External Threat Protection Strategy for Networks . . . . . . . . . . . . . . . . . . . . . . . . . . 32Internal Threat Protection Strategy for Networks . . . . . . . . . . . . . . . . . . . . . . . . . . 34Maximum Protection Strategy for Networks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

vSiteProtector Best Practices Guide, Version 2.0 SP5

Contents

Section B: Deploying Server and Desktop Protection. . . . . . . . . . . . . . . . . . 39Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39About Host Intrusion Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40Server Sensor and Desktop Audit Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41Host Scanning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43Minimum Protection Strategy for Servers and Desktops . . . . . . . . . . . . . . . . . . . . . 44External Threat Protection Strategy for Servers and Desktops . . . . . . . . . . . . . . . . . 45Internal Threat Protection Strategy for Servers and Desktops. . . . . . . . . . . . . . . . . . 46Maximum Protection Strategy for Servers and Desktops . . . . . . . . . . . . . . . . . . . . . 47

Section C: Examples of Protection Strategies . . . . . . . . . . . . . . . . . . . . . . . 49Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49Example of Minimum Protection Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52Example of the External Threat Protection Strategy. . . . . . . . . . . . . . . . . . . . . . . . . 53Example of the Internal Threat Protection Strategy . . . . . . . . . . . . . . . . . . . . . . . . . 54Example of the Maximum Protection Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

Chapter 4: Organizing Your Assets . . . . . . . . . . . . . . . . . . . . . . . . . . . 57Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57Sensor Command and Control Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59RealSecure Desktop Command and Control Tasks . . . . . . . . . . . . . . . . . . . . . . . . . 60Geographical Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61Policy-Geographical Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62Topological Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63Services Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65Scope of Responsibility Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67Active Directory Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

Chapter 5: Performing Preliminary Tasks . . . . . . . . . . . . . . . . . . . . . 71Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

Section A: Introducing SiteProtector to Your Environment . . . . . . . . . . . . . 73Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73Deploying SiteProtector in a Test Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74Performing Baseline Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

Section B: Protecting Your Organization Against New Threats . . . . . . . . . . 77Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77Obtaining Up-to-Date Information about Threats . . . . . . . . . . . . . . . . . . . . . . . . . . . 79Determining Whether a Check or Signature is Available. . . . . . . . . . . . . . . . . . . . . . 81Protecting Against Threats for Which No Check or Signature Exists . . . . . . . . . . . . . 83

Section C: Deciding When to Tune or Expand Protection . . . . . . . . . . . . . . 85Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

vi

Contents

Chapter 6: Tuning and Updating Your Protection . . . . . . . . . . . . . . 87Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

Section A: Managing Security Policies and Responses . . . . . . . . . . . . . . . . 89Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89Adjusting Default Sensor Policy Levels. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91Modifying Sensor Policy Checks and Signatures . . . . . . . . . . . . . . . . . . . . . . . . . . . 93Customizing Sensor Responses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94Specifying Desktop Responses. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

Section B: Controlling Access to Networks and Hosts . . . . . . . . . . . . . . . 101Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101Controlling Access to Network Segments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102Controlling Access to Desktops Using Protection Levels . . . . . . . . . . . . . . . . . . . . 104Controlling Access to Hosts Using Firewall Rules . . . . . . . . . . . . . . . . . . . . . . . . . 106Configuring Desktop’s Advanced Firewall Settings . . . . . . . . . . . . . . . . . . . . . . . . . 108

Section C: Monitoring and Controlling Host Activity and User Behavior . . 111Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

Section D: Expanding Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113Adjusting Scan Frequency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114Increasing Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

Section E: Updating Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117Working With Updates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119Applying Updates with the Update Manager. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120Applying Updates Manually . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

Part II: Maintaining ProtectionChapter 7: Identifying and Resolving Network Vulnerabilities. . . 125

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

Section A: Identifying and Resolving Vulnerabilities . . . . . . . . . . . . . . . . . . 127Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127Vulnerability Identification and Resolution Process. . . . . . . . . . . . . . . . . . . . . . . . . 129Vulnerability Data Generated by SiteProtector . . . . . . . . . . . . . . . . . . . . . . . . . . . 131Gathering Information About Vulnerability Events . . . . . . . . . . . . . . . . . . . . . . . . . 133Deciding Whether to Resolve Vulnerabilities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134Repairing and Mitigating Vulnerabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

viiSiteProtector Best Practices Guide, Version 2.0 SP5

Contents

Creating a Plan of Action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137Implementing Upgrades and Patches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

Section B: Vulnerability Reports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139Investigating Vulnerabilities in Detail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140Prioritizing Vulnerabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141Vulnerability Remedies by Host . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142Determining Your Company’s State of Security . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

Chapter 8: Identifying and Responding to Threats. . . . . . . . . . . . . 145Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145

Section A: Identifying Threats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147Gathering Information about Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148Suspicious Activity Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150Identifying Related Activity Using Attack Patterns . . . . . . . . . . . . . . . . . . . . . . . . . 152Identifying Related Activity Using Firewall Events . . . . . . . . . . . . . . . . . . . . . . . . . . 155

Section B: Categorizing and Responding to Threats . . . . . . . . . . . . . . . . . 157Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157Evaluating Suspicious Activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158Determining the Severity of an Incident . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159Responding to Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161Collecting Evidence. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164

Section C: Threat Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167Prioritizing Possible Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168Prioritizing Attack Incidents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169Determining the State of Your Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170Determining the Future State of Your Security . . . . . . . . . . . . . . . . . . . . . . . . . . 172Analyzing Trends Among Multiple Sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175

Part III: Implementation StrategiesChapter 9: Managing Scans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179Identifying Hosts On Your Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180Ensuring that Vulnerability Data is Complete and Accurate . . . . . . . . . . . . . . . . . . . 181Scheduling Vulnerability Scans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183Reducing the Time Required to Run Scans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184

viii

Contents

AppendixAppendix A: SiteProtector Reports . . . . . . . . . . . . . . . . . . . . . . . . . . 189

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189

Section A: Creating Reports on the Sensor Analysis Tab . . . . . . . . . . . . . 191Exporting Data on the Sensor Analysis Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192Creating a Report on the Sensor Analysis Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . 194Creating a Custom Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195

Section B: Creating Reports on the Reporting Tab . . . . . . . . . . . . . . . . . . 197Using the Report Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199Creating a Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202Viewing a Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203

Section C: Creating Reports on the Enterprise Dashboard . . . . . . . . . . . 205Printing a report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207Saving a report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208Scheduling a report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211

ixSiteProtector Best Practices Guide, Version 2.0 SP5

Contents

x

Preface

Overview

What the Best Practices Guide offers

The SiteProtector Best Practices Guide provides best practice guidelines and suggestions for securing your network. This guide does not always provide procedures for implementing these guidelines, nor is it a substitute for the installation guides, configuration guides, user guides, and electronic assistance supplied with ISS products.

Audience The following table lists the intended audience for Best Practices Guide:

Part Audience

Part I—Planning and Assessment

Information security architects, security analysts, network administrators, and CISOs—anyone who is responsible for deployment plans, policies, or strategies.

Part II—Maintaining Protection

• Information security architects, security analysts, network administrators, or anyone responsible for developing or updating emergency response plans, vulnerability assessment plans, or deployment plans.

• Security analysts, operators, or anyone responsible for identifying and responding to threats or vulnerabilities and identifying trends and priorities.

Table 1: Audience

xiSiteProtector Best Practices Guide, Version 2.0 SP5

Preface

Part III—Implementation Strategies

Information security architects, risk assessment analysts, deployment managers, or anyone responsible for managing users, scans, and reports or setting up SiteProtector.

Note: Implementation strategies do not explain every facet of implementing and managing SiteProtector; however, they do include guidelines and examples for some important tasks.

Part Audience

Table 1: Audience

xii

How ISS Products Are Referenced in the Best Practices Guide

How ISS Products Are Referenced in the Best Practices Guide

Introduction This topic lists ISS products and defines how they are referred to in this guide. The ISS products discussed in this guide include products that report to SiteProtector, as follows:

● vulnerability assessment

● network protection systems

● server protection systems

● desktop protection systems

Vulnerability assessment

Vulnerability assessment applications, or scanners, perform vulnerability assessments of the network and hosts. Vulnerability assessment applications include the following:

● Internet Scanner

● System Scanner

Network protection systems

Network protection systems handle intrusion detection, intrusion prevention, and response functions on network segments. Network protection systems include the following:

● Network intrusion detection

■ RealSecure Network 10/100

■ RealSecure for Nokia Network 10/100

■ RealSecure Network Gigabit

■ RealSecure Network for Crossbeam

■ Proventia A Series Appliances

● Network intrusion prevention appliances

■ Proventia G Series Appliance, referred to as the Inline Appliance in SiteProtector

● Network integrated security appliances

■ Proventia M Series Appliance, referred to as the Multifunction Appliance in SiteProtector

xiiiSiteProtector Best Practices Guide, Version 2.0 SP5

Preface

Important: The network protection systems referenced in this guide do not include Sentry or Guard.

Server protection systems

Server protection systems handle intrusion detection, intrusion prevention, and response functions on servers. RealSecure Server Sensor monitors log file and kernel-level activity and network traffic to and from a single server, blocking suspicious traffic and intercepting packets before they reach the operating system.

Desktop protection systems

RealSecure Desktop enables SiteProtector to collect and manage data from Desktop agents. Desktop agents referenced in this guide do not include Sentry or Guard.

xiv

Getting Technical Support

Getting Technical Support

Introduction ISS provides technical support through its Web site and by email or telephone.

The ISS Web site The Internet Security Systems (ISS) Resource Center Web site (http://www.iss.net/support/) provides direct access to frequently asked questions (FAQs), white papers, online user documentation, current versions listings, detailed product literature, and the Technical Support Knowledgebase (http://www.iss.net/support/knowledgebase/).

Support levels ISS offers three levels of support:

● Standard

● Select

● Premium

Each level provides you with 24-7 telephone and electronic support. Select and Premium services provide more features and benefits than the Standard service. Contact Client Services at [email protected] if you do not know the level of support your organization has selected.

Hours of support The following table provides hours for Technical Support at the Americas and other locations:

Location Hours

Americas 24 hours a day

All other locations

Monday through Friday, 9:00 A.M. to 6:00 P.M. during their local time, excluding ISS published holidays

Note: If your local support office is located outside the Americas, you may call or send an email to the Americas office for help during off-hours.

Table 2: Hours for technical support

xvSiteProtector Best Practices Guide, Version 2.0 SP5

http://www.iss.net/support/

http://www.iss.net/support/

http://www.iss.net/support/knowledgebase


Preface

Contact information The following table provides electronic support information and telephone numbers for technical support requests:

Contacting X-Force The following table provides Web addresses for information about X- Force, the research and development division of ISS:

Regional Office

Electronic Support Telephone Number

North America Connect to the MYISS section of our Web site:

www.iss.net

Standard:(1) (888) 447-4861 (toll free)

(1) (404) 236-2700

Select and Premium:Refer to your Welcome Kit or call your Primary Designated Contact for this information.

Latin America [email protected] (1) (888) 447-4861 (toll free)

(1) (404) 236-2700

Europe, Middle East, and Africa

[email protected] (44) (1753) 845105

Asia-Pacific, Australia, and the Philippines

[email protected] (1) (888) 447-4861 (toll free)

(1) (404) 236-2700

Japan [email protected] Domestic: (81) (3) 5740-4065

Table 3: Contact information for technical support

Subject Web address

X-Force Security Center and X-Force Database

http://www.iss.net/security_center/

Alerts and Alert Summaries http://www.iss.net/issEn/delivery/xforce/alerts.jsp

Table 4: Web addresses for X-Force information

xvi

http://www.iss.net


http://xforce.iss.net/

http://xforce.iss.net/alerts




Conventions Used in this Guide

Conventions Used in this Guide

Introduction This topic explains the typographic conventions used in this guide to make information in procedures and commands easier to recognize.

In procedures The typographic conventions used in procedures are shown in the following table:

Convention What it Indicates Examples

Bold An element on the graphical user interface.

Type the computer’s address in the IP Address box.Select the Print check box. Click OK.

SMALL CAPS A key on the keyboard. Press ENTER.Press the PLUS SIGN (+).

Constant width

A file name, folder name, path name, or other information that you must type exactly as shown.

Save the User.txt file in the Addresses folder.Type IUSR__SMA in the Username box.

Constant width italic

A file name, folder name, path name, or other information that you must supply.

Type Version number in the Identification information box.

A sequence of commands from the taskbar or menu bar.

From the taskbar, select Start Run.On the File menu, select Utilities Compare Documents.

Table 5: Typographic conventions for procedures

xviiSiteProtector Best Practices Guide, Version 2.0 SP5

Preface

Command conventions

The typographic conventions used for command lines are shown in the following table:

Convention What it Indicates Examples

Constant width bold

Information to type in exactly as shown.

md ISS

Italic Information that varies according to your circumstances.

md your_folder_name

[ ] Optional information. dir [drive:][path] [filename] [/P][/W] [/D]

| Two mutually exclusive choices.

verify [ON|OFF]

{ } A set of choices from which you must choose one.

% chmod {u g o a}=[r][w][x] file

Table 6: Typographic conventions for commands

xviii

®

Part I

Assessment andPlanning

Chapter 1

Overview of Security and Implementation Strategies

Overview

Introduction This chapter provides an overview of the security and implementation strategies discussed in this guide.

Security strategies Security strategies include best practices for SiteProtector and the ISS products that report to it. Security strategies address the typical goals of security operators, security analysts, and managers, and the ongoing tasks they perform. Security strategies consist of the following:

● planning and assessment

● maintaining protection

Implementation strategies

Implementation strategies include guidelines and examples about implementing and managing SiteProtector network scans and reports and setting up the best architecture for your environment.

3SiteProtector Best Practices Guide, Version 2.0 SP5

Chapter 1: Overview of Security and Implementation Strategies

In this chapter This chapter contains the following topics:

Topic Page

Security Strategies 6

Implementation Strategies 8

4

Overview

Diagram of SiteProtector strategies

Figure 1 illustrates the two strategies discussed in this guide:

Figure 1: Diagram of SiteProtector strategies

EvaluateOrganization Protect Network Protect Servers

and Desktops Organize Assets

Install andconfigure Site

Protector

Install andconfigure ISS

agents

Identify and

Resolve

Vulnerabilities

Identify and

Respond to Threats

Tune, Expand, andUpdate Protection

Iden

tify

Tren

ds a

ndPr

iorit

ies

Planning and Assessment

Deployment

Managing Scans

Implementation Strategies

MaintainingProtection

Re-Assess Protection

Security Strategies



Security Strategies

Introduction This topic gives an overview of the following SiteProtector security strategies:

● planning and assessment

● maintaining protection

Planning and assessment

You must plan and assess how you are going to deploy ISS agents before you install SiteProtector, and then, as security risks and network topologies change, you can re-assess your protection strategy. The planning and assessment strategy presents ideal models of protection based on overall organizational goals.

Planning and assessment includes the following tasks:

Evaluating your organization—Assess your organization to determine which security strategy is best.

Protecting your assets—Deploy network protection systems, Internet Scanner applications, Server Sensors, System Scanner applications, and RealSecure Desktop.

Organizing your assets—Organize hosts and important network segments on your network.

Important: Planning and assessment does not address the organizational and technological challenges of deploying ISS agents in organizations with the following characteristics:

● implement non-centralized network security

● lack security best practices

● use non-ISS agents

6

Security Strategies

Maintaining protection

Maintaining your protection includes the following tasks:

Identifying and responding to threats—Determine whether events generated by SiteProtector are threats, and if so, how to respond to them.

Identifying and resolving vulnerabilities—Determine whether vulnerability data generated by SiteProtector means your systems are at risk and, if so, how to resolve those vulnerabilities.

Identifying trends and priorities—Information about the management features of Enterprise Dashboard; including views, reports, and graphs.

Tuning, expanding, and updating protection—Information about adjusting protection, such as policies, responses, and number of hosts scanned. Includes information about adding ISS agents or hosts to scans. This task may require you to revisit planning and assessment tasks periodically.



Implementation Strategies

Introduction Implementation strategies focus on operational tasks. These strategies include scheduling and scanning in addition to improving performance and scalability.

When to use You can use implementation strategies for installing and configuring SiteProtector or for tuning tasks.

Important: This guide does not include every facet of implementing and managing SiteProtector.

Implementation strategy tasks

Implementation strategies include the following:

Managing scans—Guidelines for identifying hosts on your network, scheduling scans, and reducing the time required to run scans.

8

Chapter 2

Assessing Your Organization

Overview

Introduction This chapter helps you establish guidelines for deploying ISS agents on networks and hosts. Use the information in this chapter as a guide in determining which strategy is best for your organization.

Importance of developing a deployment plan

ISS recommends that you establish a deployment plan. A good deployment plan clearly defines how to deploy ISS agents on a network and considers factors specific to your environment. The plan should clearly define the responsibilities of system owners and the policies and procedures necessary for implementing ISS agents.

Caution: This chapter is not a comprehensive guide to developing a deployment plan. For more information about developing a deployment plan, contact Professional Security Services at ISS.

Protecting your organization

To protect your organization, perform the following tasks:

1. Determine which protection strategy or combination of strategies is best, using the guidelines in this chapter.

2. Determine how to protect your network, using the guidelines in Chapter 3, "Protecting Your Assets" on page 21.


Chapter 2: Assessing Your Organization


Topic Page

Determining Which Assets Are Critical 11

Determining the Best Strategy for Your Organization 13

Minimum Protection Strategy 16

External Threat Protection Strategy 17

Internal Threat Protection Strategy 18

Maximum Protection Strategy 19

10

Determining Which Assets Are Critical

Determining Which Assets Are Critical

Introduction In the following chapter, certain hosts and network segments are often referred to as critical. Use the information in this topic to determine which assets on your network are critical. The process of determining which assets are critical is often the result of a combination of factors that vary by organization.

What are critical assets?

A critical asset is any device that contains valuable information or processes, such as:

● network segments

● servers

● desktop computers

● laptop computers

● routers and firewalls

Critical external assets

Critical external assets, referred to as Web-facing, are servers that communicate with the internet, such as the following:

● Web servers

● DNS servers

● mail servers

● SMTP servers

● FTP servers

● databases that process or store e-business information

Critical internal assets

Critical internal assets are servers and desktops that typically contain the following information or processes:

● proprietary, such as trade secrets, marketing and product development information, engineering specifications, and programming code

● internal, such as employee records and payroll information



● customer, such as billing records, customer asset records, and patient records

● processes that control access to other assets, such as domain controllers, Active Directory servers, and kerberos servers

● trust relationships with other critical servers

12

Determining the Best Strategy for Your Organization


Introduction Determining the best protection strategy for your organization is not an exact science. The best protection strategy may be a variation of a strategy or a combination of several strategies.

Types of protection strategies

Table 7 describes the types of protection strategies discussed in this chapter:

Strategies based on level of protection

Table 8 shows protection strategies categorized by the level of protection applied to areas of the network:

This strategy... Is recommended for organizations that...

Minimum see network security as a low priority

External Threat see threats from outside the organization as posing the greatest threat to their security

Internal Threat see threats from inside their organization as posing the greatest threat to their security

Maximum see threats from both inside and outside their organization as posing a threat to their security

Table 7: Types of protection strategies

Strategy DMZ, VPN, and Firewalls

Intranet

Minimum light protection light protection

External Threat heavy protection light protection

Internal Threat light protection heavy protection

Maximum heavy protection heavy protection

Table 8: Strategies based on level of protection



Starting points You may choose to use one protection strategy to start with, and then progress to a different strategy or a combination of strategies. Consider the following possibilities:

● begin with the internal or external threat protection strategy, and then progress to the maximum protection strategy

● begin with the minimum protection strategy, and then progress to either the internal or external threat protection strategy or to the maximum protection strategy

Example of a migration path

Figure 2 provides an example of a migration path, using the protection strategies:

Figure 2: Example of a migration path

Minimum

Internal Threat ProtectionStrategy

External Threat ProtectionStrategy

Maximum ProtectionStrategyOR

14


Protection strategies summary

Figure 3 summarizes how to select a protection strategy. Use this diagram as a guide but do not use it as a substitute for the questions included in this chapter.

Figure 3: Protection strategies summary

Yes

No

No

Yes

No

Yes

No

Yes

Yes

Use m inim um protectionstrategy

No

Does your core businessactivity depend on highly

valuable proprietaryinform ation to which som e

or all em ployess haveaccess?

Does core business activitydepend on internet

resources?

Does your core businessactivity depend on highly

valuable proprietaryinform ation to which som e

or all em ployess haveaccess?

Is any part of your networkexposed to the internet?

Does policy require you toprotect assets regardless of

value or risk?

Use internal threatprotection strategy

Use external threatprotection strategy

Use m axim um protectionstrategyUse m inim um protection

strategy

Use m axim um protectionstrategy



Minimum Protection Strategy

Description The minimum protection strategy provides light protection for the following:

● firewalls and exposed network segments such as DMZs and VPNs

● network segments, servers, and desktops in the intranet

Should you follow this strategy?

Consider the minimum protection strategy if you answer Yes to three or more of the following questions:

Next step To follow the guidelines of the minimum protection strategy, refer to Chapter 3, "Protecting Your Assets" on page 21.

Y N Your organization is at a low risk of attack from both internal and external threats.

Y N Your organization wants some minimal level of protection from common threats and vulnerabilities but does not see network security as being a high priority.

Y N Your organization conducts all of its core business activities in its intranet.

Y N Your organization produces a minimal amount of proprietary information, or limits access to proprietary information to only a few employees.

Y N Your organization does not have significant exposure to the Internet or to remote users.

16

External Threat Protection Strategy

External Threat Protection Strategy

Introduction The external threat protection strategy provides the following protection:

● heavy on firewalls and exposed network segments such as DMZs and VPNs

● light on intranet segments, hosts, and desktops


Consider the external threat protection strategy if you answer Yes to three or more of the following questions:

Next step To follow the guidelines of the external threat protection strategy, refer to Chapter 3, "Protecting Your Assets" on page 21.

Y N Your organization is at a high risk of attack from external threats and at a low risk of attack from internal threats.

Y N Your organization conducts core business activities on the Internet or exposes important internal processes or information to the Internet.

Y N Your organization depends heavily on hosts and network segments that process information from the Internet.

Y N Your organization stores little valuable proprietary information, or limits access to such information to a few select employees.

Y N Your organization contains a large number of users who access the intranet from remote locations.



Internal Threat Protection Strategy

Introduction The internal threat protection strategy provides the following protection:

● light on firewalls and exposed network segments, such as DMZs and VPNs

● heavy on intranet segments, servers, and desktops


Consider using the internal threat protection strategy if you answer Yes to three or more of the following questions.

Next step To follow the guidelines of the internal threat protection strategy, refer to Chapter 3, "Protecting Your Assets" on page 21.

Y N Your organization is at a high risk of attack from internal threats.

Y N Your organization experiences a high turnover of employees, consultants, or contractors.

Y N Your organization exposes important internal processes or information to a large number of employees.

Y N Your organization has valuable proprietary information, trade secrets or customer information to which more than a few select employees have access.

18

Maximum Protection Strategy

Maximum Protection Strategy

Introduction The maximum protection strategy combines the internal and external protection strategies to provide heavy protection on the following:

● firewalls and exposed network segments such as DMZs and VPNs

● network segments, servers, and desktops in the intranet


Consider using this protection strategy if you answer Yes to three or more of the following questions:

Next step To follow the guidelines for the maximum protection strategy, refer to Chapter 3, "Protecting Your Assets" on page 21.

Y N Your organization is at a high risk of attack from both internal threats and external threats.

Y N Your organization is required by company policy or government regulation to protect all assets, regardless of risk or value.

Y N Your organization exposes important internal processes or information to a large number of employees.

Y N Your organization has valuable proprietary information or trade secrets to which more than a few select employees have access.

Y N Your organization holds a position of high responsibility and trust such as medical, government, or fiduciary institutions.

Y N Your organization conducts core business activities on the Internet or exposes important internal processes or information to the Internet.



20

Chapter 3

Protecting Your Assets

Overview

Introduction This chapter discusses the process of protecting networks and hosts using sensors, scanners, and agents.

In this chapter This chapter contains the following sections:

Section Page

Deploying Network Protection 23

Deploying Server and Desktop Protection 39

Examples of Protection Strategies 49


Chapter 3: Protecting Your Assets

22

SECTION A: Deploying Network Protection

Overview

Introduction Network protection is a crucial layer of defense against threats and vulnerabilities. Network protection is important in protecting intranet and Web-facing hosts, routers, and firewalls.

ISS network protection agents

The ISS agents used to protect networks are as follows:


● Internet Scanner application

In this section This section contains the following topics:

Topic Page

Network Intrusion Detection 24

Introducing NPSs to your Environment 26

Network Scanning 27

Types of Network Scans 29

Minimum Protection Strategy For Networks 31

External Threat Protection Strategy for Networks 32

Internal Threat Protection Strategy for Networks 34

Maximum Protection Strategy for Networks 36



Network Intrusion Detection

Introduction This topic discusses network intrusion detection and its role in protecting networks.

Definition: attacks Attacks are malicious attempts to gain access or control of a system, or to deny access to a system by circumventing access controls. Attack methods can vary depending on the means of access and the attacker’s objective. The severity of an attack can range from pinging a firewall to actually gaining control of a host.

Definition: network intrusion detection

Network intrusion detection is the process by which network protection systems and firewalls monitor traffic on your network for possible threats and report them to SiteProtector. Network protection systems use a variety of techniques to identify attacks, such as signatures and protocol analysis.

Proventia G Series Appliance—The Proventia G Series, referred to as an intrusion prevention system (IPS), can monitor and block traffic inline.

Proventia M Series Appliance—The Proventia M Series is a network security integrated appliance that provides firewall, VPN, spam filtering, antivirus, and intrusion prevention.

Proventia A Series Appliance—The Proventia A Series Appliance provides intrusion detection, and monitors and responds to traffic outside the data stream.

Network sensor—The RealSecure Network Sensor is intrusion detection software that monitors and responds to traffic outside the data stream.

Note: You can configure certain firewalls to send audit and intrusion detection events to SiteProtector through the Third Party Module.

Definition: response Network protection systems automatically respond to suspicious traffic by alerting the appropriate individuals, logging information and, in some cases, attempting to disrupt or block traffic, in the case of an IPS.

Note: For more detailed information on tuning responses, refer to Chapter 6, "Tuning and Updating Your Protection" on page 87.

24

Network Intrusion Detection

Level of protection The level of protection provided by network intrusion detection depends on the following:

● the number of network protection systems you deploy

● the location of network protection systems

● the traffic you choose to monitor

● the response levels used

● the level of policy used

Common locations to place network protection systems

Common locations to place network protection systems are as follows:

Firewalls—Software or devices, located in areas of your network that experience high traffic or that screen incoming traffic based on different criteria, such as source address, services, ports, or domain name.

Aggregation points—Areas of your network that experience large amounts of traffic, such as gateways, DMZs, data centers, and inter-departmental links.

How network protection systems monitor traffic

The way in which a network protection system monitors and blocks traffic depends on where it resides in the data stream and how it is configured.

Monitoring traffic inline—Network protection systems that monitor traffic in the data stream provide the most effective way to stop attacks. Network protection systems, such as the Proventia G Series, can analyze traffic throughout the entire TCP/IP stack and block it before it reaches hosts located on that segment. Because these devices actually sit in the data stream, they can add latency, and thus impact network performance.

Monitoring traffic in promiscuous mode—Network protection systems that monitor traffic passively from a location outside the data stream do not impact network performance; however, they do not stop attacks as effectively as inline systems. Systems that monitor traffic in promiscuous mode can be configured to send kill responses or TCP reset commands. These commands attempt to terminate some types of connections but cannot stop attacks that use connectionless protocols, such as UDP.

Reference: For additional information on NPS deployment options, refer to “Introducing NPSs to your Environment” on page 26.



Introducing NPSs to your Environment

Introduction Network protection systems (NPSs) can monitor and block thousands of malicious data streams simultaneously, while allowing legitimate traffic to flow through the network. To avoid necessary disruption to your network, use the guidelines in this topic to introduce NPSs to your environment gradually.

NPS operational modes

NPSs provide three modes that let you control the impact of NPSs on your environment and the way in which they monitor network traffic. The Proventia G Series is the only network protection system that provides these operational modes.

Considerations for using NPS operational modes

Consider the following when you are using operational modes to introduce NPSs to your environment:

Passive monitoring—NPSs that are configured in passive or promiscuous mode use hubs, taps, or span ports to monitor traffic outside the data stream. NSPs configured in this mode do not increase packet latency. Deploy NPSs in passive mode if you are replacing your current passive monitoring system with an NPS or running an NPS with another system in parallel. This approach lets you compare the performance of an NPS with other systems that use a similar configuration.

Inline simulation—NPSs that are configured in inline simulation mode are dedicated network devices that reside in the data stream. Deploy NPSs using this mode so that you can monitor how the NPS performs without blocking. The inline simulation mode is an effective way to tune security policies because it lets you observe the connections that would be disrupted if inline blocking were enabled.

Reference: For guidelines on tuning security policies, refer to “Managing Security Policies and Responses” on page 89.

Inline protection—Inline protection mode fully enables inline blocking. Deploy NPSs in inline protection mode after you have had an opportunity to tune your policy based on the system’s performance in inline simulation mode.

26

Network Scanning

Network Scanning

Introduction The ISS Internet Scanner application identifies vulnerabilities in your network. Network scans are typically launched from devices that are located outside the host or desktop being scanned. These scans discover vulnerabilities that an attacker, who does not have local account privileges, could exploit.

Level of protection The level of protection provided by network scanning depends on the following:

● the location of Internet Scanner instances

● applications on your network

● the hosts you scan

● the frequency of scans

● the access rights of the Internet Scanner instance performing the scan

Access rights Access rights determine the system resources an Internet Scanner application can access when it performs a scan on a host or segment, as follows:

Vulnerability checks—Some vulnerability checks use access rights to determine whether a vulnerability exists without having to actually exploit the vulnerability, and thus avoid possible disruption to systems or services.

Escalating privileges—When running high priority scans, consider escalating access rights. For example, consider scanning with local administrator privileges first and then escalating to more privileged access, such as domain administrator privileges.



Scanning priority Scanning priority is a numerical value used in this chapter to rate the importance of scans. Use scanning priority to determine the frequency of scans or the level of policy to apply. For example, you might choose to perform high priority scans more frequently than low priority scans or you might choose to apply more stringent policies on high priority scans.

Reference: For more information on tuning scans, refer to Chapter 6, "Tuning and Updating Your Protection" on page 87.

28

Types of Network Scans

Types of Network Scans

Introduction The three types of network scans are as follows:

● router

● perimeter

● intranet

Definition: policy A policy is a group of security preferences that determine which threats or vulnerabilities are monitored on networks. Each sensor has a its own set of policies, which are usually grouped based on the level of protection they provide and the host operating system.

Router scans Router—A device that determines a network packet’s most expedient path through a network, using algorithms, protocols, and routing table information. Attackers try to exploit routers by adding their IP addresses to the router’s protocol table to get information. This enables the attacker to retrieve information, such as user passwords and algorithms, that would normally only be accessible to a trusted host.

Router scans—These scans are usually included as part of a perimeter scan. External router scans are important because routers often serve as the first point of attack for attackers.

Perimeter scans Perimeter scans test firewall vulnerabilities. The types of perimeter scans are as follows:

External perimeter scans—Identify whether your external firewall or services that are allowed through the firewall can be compromised. You launch these scans from devices outside your firewall. ISS recommends that you escalate access privileges when you scan, in the following order:

1. Use an outside account with no network privileges to see what an intruder can access.

2. Use a local account or user level privileges to see what an authorized user can access.

3. Use domain administrator privileges to see what an administrator can access.



Internal perimeter scans—Identify whether your internal firewall can be compromised. You launch these scans from devices inside your DMZ, using the same privileges as external perimeter scans.

Intranet scans Intranet scans—Identify vulnerabilities on network segments and hosts inside the intranet.

Database scans—Some Internet Scanner policies identify vulnerabilities on databases.

30

Minimum Protection Strategy For Networks

Minimum Protection Strategy For Networks

Introduction This topic discusses where to place network protection systems and how to perform network scans using the minimum protection strategy.

Network protection system placement

Use the following guidelines to place and configure network protection systems on your network:

Note: If your network contains a VPN or extranet, consider using the external protection strategy described in “External Threat Protection Strategy for Networks” on page 32.

Network scanning guidelines

Use the following guidelines when scanning your network:

● launch perimeter scans from outside the firewall to inside the DMZ and scan only Web-facing hosts

● scan routers located outside your external firewall

Network Area Sensor Placement and Configuration

DMZ network protection system inside your external firewall

intranet network protection system on the major aggregation point to your intranet

Table 9: Network protection system placement



External Threat Protection Strategy for Networks

Introduction This topic discusses where to place network protection systems and how to perform network scans using the external threat protection strategy. The external threat protection strategy protects the following:

● hosts in the DMZ and in the VPN

● intranet hosts that communicate with the DMZ and the VPN

Web-facing and trusted hosts

Web-facing hosts, often referred to as public IP addresses, have open communication with the Internet, and thus are usually more vulnerable than hosts in the intranet. Web-facing hosts often have trusted relationships with hosts in the intranet. Depending on the type of communication allowed, these trusted relationships can expose hosts located in more secure areas of the network to the same threats that Web- facing hosts are exposed to.

E-commerce sites: protection versus availability

To protect e-business sites using the external protection strategy, you must achieve a balance between deploying protection on hosts that process critical business transactions and ensuring that these hosts are available to customers who want to transact business. To maintain this balance, consider the following:

● scan frequently, but avoid vulnerability checks that are known to disrupt critical communication or services

● monitor as much traffic as possible, but avoid policy responses that disrupt communication on servers that process critical transactions

Reference: For more information about critical hosts, refer to “Determining Which Assets Are Critical” on page 11.

32

External Threat Protection Strategy for Networks


Use the following guidelines to place network protection systems on your network:


Use the following guidelines to scan your network with Internet Scanner instances:


DMZ • network protection system inside your external firewall

• network protection system outside your external firewall

• mirror traffic between:

• hosts in the DMZ and hosts which have trusted relationships with those hosts

• hosts in the DMZ and critical hosts in the intranet, such as databases

Note: Placing network protection systems outside your external firewall can generate significant event volume. Consider limiting the signatures in these sensor policies to firewall attacks only. For more information on modifying checks and signatures, refer to Chapter 6, "Tuning and Updating Your Protection"

intranet network protection system on aggregation points in your intranet

VPN network protection system on the aggregation point between your intranet and VPN


Priority Scan Type Hosts Scanned

1 perimeter scan from outside firewall to inside DMZ, using escalating privileges

all Web-facing hosts in DMZ

2 perimeter scan from inside DMZ to intranet, using escalating privileges

Web-facing databases, proxy servers, internal firewall, email servers

3 router scan all Web-facing routers

4 intranet scan all Web-facing hosts

Table 11: Network scanning guidelines



Internal Threat Protection Strategy for Networks

Introduction This topic discusses where to place network protection systems and how to perform network scans using the internal threat protection strategy. The internal threat protection strategy protects critical hosts and segments in the intranet.

Segments that process sensitive information

Sensitive traffic—To effectively protect assets in the intranet, you must identify which network segments process sensitive traffic. Examples of sensitive traffic are as follows:

● traffic going to or coming from Accounting Department file servers

● traffic going to or coming from a Human Resources Department file servers

Proventia M Series Appliance—The Proventia M Series Appliance can provide firewall and intrusion detection in aggregation points that process sensitive information. Consider deploying a Proventia M Series appliance on these critical internal gateways.




DMZ network protection system inside and outside the external firewall

intranet • network protection system on all aggregation points

• Proventia M Series Appliance on aggregation points that process sensitive traffic

• mirror traffic between all critical hosts and hosts to which non-employees (contractors, consultants) have access

• mirror traffic between all hosts that process sensitive information


34

Internal Threat Protection Strategy for Networks


Use the following guidelines to scan your network with Internet Scanner instances:


1 perimeter scan from outside firewall to inside DMZ using escalating privileges

all Web-facing hosts in DMZs


3 intranet scan • all critical hosts

• all hosts to which non-employees (contractors, consultants) have access

• all critical hosts that maintain open communication with hosts to which a large number of employees have access




Maximum Protection Strategy for Networks

Introduction The maximum protection strategy protects critical hosts and network segments on both the external network and the intranet.

VPN considerations If your network has a VPN but does not have a large Web presence, consider combining the following guidelines:

● internal threat protection strategy guidelines

● external threat protection strategy guidelines that apply to VPNs




DMZ • network protection system inside and outside external firewall

• mirror traffic between:

• hosts in the DMZ and hosts which have trusted relationships with those hosts

• hosts in the DMZ and critical hosts in the intranet, such as databases

Note: Placing network protection systems outside your external firewall can generate significant event volume. Consider limiting the signatures in these sensor policies to firewall attacks only.


36

Maximum Protection Strategy for Networks

intranet • network protection system on all aggregation points

• Proventia M Series Appliance on aggregation points that process sensitive traffic

• mirror traffic between all critical hosts and hosts to which non-employees (contractors, consultants) have access

• mirror traffic between all hosts that process sensitive information

VPN network protection system on the aggregation point between your intranet and VPN






Use the following guidelines to scan your network:


1 perimeter scan from outside firewall to inside DMZ using escalating privileges

all Web-facing hosts in DMZs

2 perimeter scan from inside DMZ to intranet using escalating privileges

Web-facing databases, proxy servers, internal firewall, Email servers


4 intranet scan • all critical hosts in the intranet

• all hosts to which non-employees have access

• all hosts that maintain trusted communication with hosts to which a large number of employees have access


38

SECTION B: Deploying Server and Desktop Protection

Overview

Introduction Server and desktop protection provide an important layer of defense against threats and vulnerabilities for hosts located in the intranet and the DMZ. This section explains how to deploy server sensors, System Scanner instances, and RealSecure Desktop agents on your servers and desktops.

ISS agents used for server and desktop protection

The ISS agents used to protect servers and desktops are as follows:

● System Scanner application

● server sensor

● Desktop agents


Topic Page

About Host Intrusion Detection 40

Server Sensor and Desktop Audit Features 41

Host Scanning 43

Minimum Protection Strategy for Servers and Desktops 44

External Threat Protection Strategy for Servers and Desktops 45

Internal Threat Protection Strategy for Servers and Desktops 46

Maximum Protection Strategy for Servers and Desktops 47



About Host Intrusion Detection

Introduction You perform host intrusion detection using the following ISS agents:

● RealSecure Server Sensor for server protection

● RealSecure Desktop for desktop and laptop protection

Level of protection The level of protection that host intrusion detection can provide depends on the following:

● the servers on which you deploy Server Sensors

● the desktops on which you deploy Desktop agents

● the types of Server Sensor and desktop protection logs you enable

Reference: Server sensor logs are an important part of host intrusion detection. For more information about the importance of logs, refer to “Server Sensor and Desktop Audit Features” on page 41.

Firewalls Firewalls are an important part of host intrusion detection because they let you block traffic in line. Server sensor and Desktop let you block traffic from addresses, ports, and ranges of ports and addresses, which can help you contain attacks, mitigate the risk of vulnerabilities, and prevent attackers from accessing critical hosts.

Application and system compliance

The application system and compliance feature of Desktop lets you block unauthorized applications, such as worms and Trojans, from running on your desktop. More specifically, it lets you monitor and protect selected applications, and prevent them from running. This feature is crucial in controlling unauthorized activity on desktops that access the intranet remotely through VPN or dial-up connections, or those that are prone to internal abuse and misuse.

Caution: If not configured properly, application and system compliance can deny authorized users access to their desktops and prevent critical applications from running. Exercise caution when using application and system compliance features.

40

Server Sensor and Desktop Audit Features

Server Sensor and Desktop Audit Features

Introduction Unlike network protection systems, server sensors and Desktop agents can monitor traffic that is above encrypted communication layers. For this reason, server sensor and desktop protection logs can provide useful information about an attack that you would not see with network protection systems. You can enable the following audit features on server sensors and Desktop agents:

● server sensor monitoring of host system logs

● server sensor and desktop protection logs, including packet and evidence logs

Server sensor monitoring of host system logs

Server sensor can monitor system logs generated by the host they reside on. When a server sensor monitors system logs, it can detect unauthorized activity, such as changes to static or executable files. You can configure server sensor to monitor any ASCII log file generated by the host and enable a response when certain patterns are detected.

What type of logging and audit features to enable?

Consider the following when determining whether to enable monitoring of host logs or packet or evidence logs:

● whether a host is critical

● the type of traffic you want to monitor on your host

Caution: Logging can impact host performance, so consider the performance trade-off before you enable logging.



Server sensor and desktop protection logs

The types of server sensor and desktop protection logs are as follows:

Type Description

Packet logs Capture a copy of every network packet that arrives at the local system. Packet logs capture a vast amount of information and use significant system resources.

Evidence logs Capture only the network packets that are triggered by an event. Evidence logs can assist in evidence collection, as well as providing an indication of the attacker’s intention.

Table 16: Server sensor and desktop protection logs

42

Host Scanning

Host Scanning

Introduction Host scanning identifies vulnerabilities that an attacker who is probing network resources can exploit using local account privileges.

Host information identified

Host scanning identifies the following information about a host:

● known vulnerabilities

● whether a host is poorly configured

● misconfigured settings

System baselines A system baseline is a level of security that your organization has determined is acceptable for that host. Once you establish a system baseline, you can compare it periodically with the current level of security to see what has changed. Because you are only viewing deviations from the baseline, the volume of vulnerability information is more manageable.

Reference: For more information on establishing a baseline, refer to the System Scanner User Guide.

Policy compliance You can define a policy in the System Scanner application and then configure System Scanner to check periodically and verify that this policy is being enforced.

Level of protection The level of protection provided by the System Scanner application depends on the following:

● the hosts on which you deploy System Scanner instances

● the frequency with which you scan baseline hosts

● degree of policy compliance



Minimum Protection Strategy for Servers and Desktops

Introduction This topic discusses how to place server sensors using the minimum protection strategy.

Placement of server sensors

Use the following guidelines to place server sensors:

Network Area Location of Agents

DMZ server sensors on all Web servers and databases

Intranet server sensors on all databases that have trusted relationships with hosts in the DMZ

Table 17: Placement of server sensors

44

External Threat Protection Strategy for Servers and Desktops

External Threat Protection Strategy for Servers and Desktops

Introduction This topic discusses where to place server sensors, Desktop agents, and System Scanner instances on your network using the external threat protection strategy.

Desktop protection and VPNs

Desktop and laptop computers located in VPNs can serve as stepping stones to critical hosts on the intranet because attackers often gain control of a VPN device and then exploit the device’s trusted connection with hosts in the intranet. After an attacker has hijacked a VPN, the attacker’s activity is hidden from network monitoring tools until the traffic is decrypted. Desktop agents can protect devices from these kinds of attacks because they stop attacks before an attacker can gain control of the remote device.

Placement of ISS agents

Use the following guidelines to place agents on servers and desktops:


DMZs • server sensors on all servers

• System Scanner instances on all servers

Intranet server sensors on all servers that have trusted relationships with hosts in the DMZ

VPN or remote users

Desktop agents on all laptop computers and desktops

Table 18: Placement of ISS agents



Internal Threat Protection Strategy for Servers and Desktops

Introduction The internal threat protection strategy provides heavy protection for servers and desktops on the intranet and light protection for servers and desktops in the DMZ.




DMZs server sensors on all Web servers

Intranet • server sensors and System Scanner instances on all hosts that are accessible by large numbers of employees, contractors, or consultants

• server sensors on all databases that have trusted relationships with hosts in the DMZ

• server sensors and System Scanner instances on all critical internal hosts

• Desktop agents on all critical desktops and laptop computers, such as those used by key management personnel

• System Scanner instances on all critical desktops and laptop computers, such as those used by key management personnel


46

Maximum Protection Strategy for Servers and Desktops

Maximum Protection Strategy for Servers and Desktops

Introduction This topic discusses how to place server sensors, Desktop agents, and System Scanner instances using the maximum protection strategy.




DMZs server sensors and System Scanner instances on all Web servers in the DMZ

Intranet • server sensors and System Scanner instances on all hosts that are accessible by large numbers of employees, contractors, or consultants

• server sensors and System Scanner instances on all servers that have trusted relationships with hosts in the DMZ

• server sensors on all databases that have trusted relationships with hosts in the DMZ

• server sensors and System Scanner instances on all critical internal hosts

• Desktop agents on all critical desktops and laptop computers

• System Scanner instances on all critical desktops and laptop computers such as those used by key management personnel

VPN or remote users

Desktop agents on all laptop computers and desktops




48

SECTION C: Examples of Protection Strategies

Overview

Introduction This section provides examples of the protection strategies discussed in this chapter. These examples include recommendations for networks, servers, and desktops.

Proventia G Series Appliances that appear in diagrams

Network sensor and Proventia A Series Appliances do not appear in the diagrams in this section. You can substitute the Proventia G Series Appliance that appears in the diagrams with a network sensor or a Proventia A Series Appliance. However, consider the differences between these products, including functionality, performance, and deployment, before you decide to deploy them.

Icon definitions Table 21 defines the icons used in the diagrams:

Icon Software

Proventia G Series Appliance

Proventia M Series Appliance

Server sensor

Table 21: Icon definitions



Internet Scanner

System Scanner

Desktop agent

Icon Software

Table 21: Icon definitions

50

Overview

In this section This section includes the following topics:

Topic Page

Example of Minimum Protection Strategy 52

Example of the External Threat Protection Strategy 53

Example of the Internal Threat Protection Strategy 54

Example of the Maximum Protection Strategy 55



Example of Minimum Protection Strategy

Introduction This topic provides an example of the minimum protection strategy. The goal of this strategy is to provide light protection in the DMZ and in the intranet.

Network diagram of the minimum protection strategy

Figure 4 shows the placement of sensors, scanners, and agents as recommended by the minimum protection strategy:

Figure 4: Network diagram of minimum protection strategy

52

Example of the External Threat Protection Strategy

Example of the External Threat Protection Strategy

Introduction This topic provides an example of the external threat protection strategy. The goal of this strategy is to provide heavy protection in the DMZ and light protection in the intranet.

Network diagram of the external threat protection strategy

Figure 5 shows the placement of sensors, scanners, and agents as recommended by the external threat protection strategy:

Figure 5: Network diagram of external threat protection strategy



Example of the Internal Threat Protection Strategy

Introduction This topic provides an example of the internal threat protection strategy. The goal of this strategy is to provide light protection in the DMZ and heavy protection in the intranet.

Network diagram of the internal threat protection strategy

Figure 6 shows the placement of sensors, scanners, and agents as recommended by the internal threat protection strategy:

Figure 6: Network diagram of the internal threat protection strategy

54

Example of the Maximum Protection Strategy

Example of the Maximum Protection Strategy

Introduction This topic provides an example of the maximum protection strategy. The goal of this strategy is to provide heavy protection in the DMZ and heavy protection in the intranet.

Network diagram of the maximum protection strategy

Figure 7 shows the placement of sensors, scanners, and agents as recommended by the maximum protection strategy:

Figure 7: Network diagram of the maximum protection strategy



56

Chapter 4

Organizing Your Assets

Overview

Introduction This chapter provides models for host and sensor grouping in the SiteManager and site grouping in the Enterprise Dashboard.

Why use grouping models?

A grouping model can help you protect your assets more efficiently by grouping hosts and sensors according to tasks you perform frequently. A grouping model uses several criteria, such as geography and topology, to group hosts and sensors.

Data analysis tasks You can perform the following data analysis tasks in SiteProtector:

● monitor and analyze events in the Site Manager

● monitor site data and identify trends in the Enterprise Dashboard

Command and control

The command and control tasks you perform in SiteProtector depend upon the sensor or agent type and whether the tasks are performed on an individual or a group of sensors or agents. Command and control tasks as they relate to grouping are discussed in the following topics:

● “Sensor Command and Control Tasks” on page 59

● “RealSecure Desktop Command and Control Tasks” on page 60


Chapter 4: Organizing Your Assets

Criteria used to group assets

Use the following criteria to create grouping models for hosts and sensors:

Geography—Groups assets according to geographic location.

Topology—Groups assets according to the location in network, such as DMZ, intranet, or VPN, or the Active Directory structure.

Services—Groups assets according to the services running on the host, such as ftp, telnet, and SMTP.

Business function—Groups assets according to the business function in an organization, such as sales, human resources, or accounting.

Scope of responsibility—Groups assets according to the security analyst or system administrator who is responsible for security.

Policy—Groups assets according to policy level applied.


Topic Page

Sensor Command and Control Tasks 59

RealSecure Desktop Command and Control Tasks 60

Geographical Model 61

Policy-Geographical Model 62

Topological Model 63

Services Model 65

Scope of Responsibility Model 67

Active Directory Model 68

58

Sensor Command and Control Tasks

Sensor Command and Control Tasks

Introduction This topic discusses the command and control tasks that you can perform on the following in the Site Manager grouping tree:


● server sensor


Sensor policies Sensor policies control the types of events the sensor detects and how it behaves. Sensor policies let you control individual security preferences, such as the specific exploits or vulnerabilities detected by the sensor and how the sensor responds when activity matches certain signatures. The types of sensor policies follow:

Policies that you apply to sensors and appliances—Control the types of signatures, audit actions, and responses enabled in addition to configuration settings. Also, specify the firewall rules enabled on server sensors.

Internet Scanner application policies—Control the types of vulnerability and system identification checks enabled.

Sensor command and control tasks

The command and control tasks you can perform on network and server sensors and Internet Scanner instances on the Site Manager grouping tree are as follows:

● apply X-Press Updates

● apply policies

● apply global responses

● launch scans

Important: To avoid incompatibility conflicts, do not group sensors that use different software versions. For example, do not place 6.5 network sensors and 7.0 network sensors in the same group.



RealSecure Desktop Command and Control Tasks

Introduction This topic discusses the command and control tasks that you can perform on Desktop agents in the Site Manager grouping tree. You can perform command and control tasks on the following:

● individual agents

● policy subscription groups

Desktop protection policies

Desktop protection policies contain several components, including firewall rule sets, IDS configuration, response rule sets, and application control lists.

Policy subscription groups

Desktop protection policies are associated with groups, not individual agents. You apply policy to policy subscription groups in the SiteProtector grouping tree. An agent can subscribe to only one policy subscription group. The Active Directory hierarchy can provide a good framework for creating policy subscription groups.

Individual agents You can perform the following command and control tasks on individual agents:

Phone home—Instructs the agent to contact the desktop controller for updates.

Change policy subscription group—Changes the policy group the agent subscribes to.

Note: You cannot set policies on individual Desktop agents. An agent must subscribe to a policy subscription group to use that group’s policy.

60

Geographical Model

Geographical Model

Introduction The geographical model groups assets according to geography and business function. This topic discusses the advantages of each layer in the model.

Geographical model diagram

Figure 8 is a diagram of the geographical model:

Figure 8: Geographical model diagram

Geography layer Consider using the geography layer for Enterprise Dashboard groups. The geography layer lets you do the following:

● compare data from different locations in your organization

● identify trends and priorities

Business function layer

The business function layer lets you monitor hosts located in specific departments, such as sales and accounting, that may contain critical information or process sensitive traffic.

New York San Francisco Atlanta Chicago

Geography

BusinessFunction

HR Accounting HR AccountingSalesHR Accounting HR AccountingSales

SiteManager

Dashboard



Policy-Geographical Model

Introduction Similar to the geographical model, the policy-geographical model groups assets according to geography and sensor or agent policy. This topic discusses the advantages of each layer in the model.

Policy-geographical model diagram

Figure 9 is a diagram of the policy-geographical model:

Figure 9: Policy-geographical model diagram

Geography layer The geography layer lets you do the following:

● compare data from different locations in your organization

● identify trends and priorities

Policy layer The policy layer groups assets based on the policy level that is being applied to sensors or agents. Because Desktop agents are grouped based on policy subscription, the policy layer is a good way to organize Desktop agents.

New York San Francisco Chicago Los Angeles

Geography

PolicyMinimum Maximum Minimum MaximumMedium

Minimum Maximum Minimum MaximumMedium

62

Topological Model

Topological Model

Description The topological model groups assets according to topology, geography, and services. This topic discusses the advantages of each layer in the model.

Topological model diagram

Figure 10 is a diagram of the topological model:

Figure 10: Topological model diagram

Topology layer The topology layer lets you do the following:

● monitor assets in more vulnerable areas, such as DMZs, more closely

● apply more stringent polices to hosts in the DMZ as opposed to hosts in more secure areas

● manage the scanning of multiple collision domains more efficiently

● monitor events from firewalls and network sensors in the same context

DMZs Internal Networks

WebServers

SMPTServers

FTPServers

New York

WebServers

SMPTServers

FTPServers

San Francisco

NT ServersDatabaseServers

UnixServers

New York

NT Servers DatabaseServers

UNIXServers

San Francisco

Topology

Geography

ServicesDesktopsDesktops



Services layer The services layer lets you do the following:

● apply policies to server sensors that are grouped according to a service or operating system

● manage the application of scan policies more efficiently

● scan groups of hosts based on services

64

Services Model

Services Model

Description The services model groups assets according to services, topology, and business function. This topic discusses the advantages of each layer in the model.

Services model diagram

Figure 11 shows the services model example:

Figure 11: Services model diagram

Services layer The services layer lets you do the following:

● monitor for exploits targeted against services or operating systems

● apply policies to server sensors that are based on service or operating system

● scan groups of hosts based on services

Topology layer The topology layer lets you monitor assets in vulnerable areas, such as DMZs, more closely.

Database Servers NT Servers

DMZ

HR AccountingSales

Internal Network DMZ

HR AccountingSales

Internal Network

Services

Topology

BusinessFunction



Business function layer

Consider using the business function layer for Desktop agents. The business function layer lets you do the following:

● monitor hosts located in specific departments, such as sales and accounting, that may contain critical information or process sensitive traffic

● monitor Desktop agents in each department in your organization

66

Scope of Responsibility Model

Scope of Responsibility Model

Description The scope of responsibility model groups assets according to scope of responsibility and topology. This topic discusses the advantages of each layer in the model.

Scope of responsibility model diagram

Figure 12 shows the scope of responsibility example:

Figure 12: Scope of responsibility model diagram

Scope of responsibility layer

Consider using the scope of responsibility layer for Enterprise Dashboard groups. The scope of responsibility layer lets you do the following:

● monitor the progress of individuals responsible for security

● monitor activity from a large number of agents, such as Desktop agents, under one individual or group’s responsibility

Topology layer Consider using the topology layer for Site Manager groups. The topology layer lets you do the following:

● apply more stringent polices to hosts in the DMZ as opposed to hosts in less exposed subnets

● combines data from network sensors and firewalls in the same area of the network into the same context

NT Administrator Unix Administrator

DMZ Internal Network DMZ Internal Network

Scope ofResponsibility

Topology

Dashboard

SiteManager



Active Directory Model

Introduction The Active Directory model groups hosts according to the Active Directory hierarchy. This topic discusses the advantages of using the Active Directory model in the SiteProtector grouping tree.

Active Directory model

Active Directory lets you group assets according to the topology of your network or your business model and update this structure periodically. This flexibility can help you apply policies and responses more efficiently.

Active Directory provides detailed information that uniquely identifies hosts and users, which can help you investigate incidents or track down hosts or users.

Active Directory information that is imported to SiteProtector

The advantages of using Active Directory to import or retrieve information are as follows:

Organizational hierarchy—SiteProtector lets you add Active Directory’s organizational hierarchy, including domains, forests, and trees to the grouping tree. Active Directory identifies objects by their fully qualified path, which includes the name of the object and its exact location in the Active Directory tree.

Active Directory can provide an accurate and complete inventory of your desktops so that you do not have to generate this information from scratch or by less efficient means. This also prevents you from duplicating network topology in Active Directory and SiteProtector.

Host configuration information—Active Directory provides the DNS name, computer name, and operating system for each host in the directory. (SiteProtector queries the DNS server to retrieve the host’s IP address.) In some environments, SiteProtector can retrieve host information more efficiently from an Active Directory server than by updating or scanning hosts individually.

User account information—SiteProtector retrieves the user’s full name, phone number, login domain, and fully qualified path to the Active Directory user object. Use this information to determine which users are currently logged on to a host.

68

Active Directory Model

Diagram Figure 13 shows an example of the Active Directory model. Domains and containers shown in this example are denoted by their DNS name.

Figure 13: Active Directory model

Department layer The department layer lets you do the following:

● group assets according to the business model that is reflected in your Active Directory hierarchy

● apply more stringent policies and responses to server sensors installed on servers in the Finance department as opposed to servers in the Engineering department

WorkstationsComputer Computer Computer

mycompany.net

Engineeringeng.mycompany

.net

Financefin.mycompany.

net

Accountingacct.fin.mycomp

any.net

Purchasingpurch.fin.mycom

pany.net

Payrollpayr.fin.mycomp

any.net

Computer Computer Computer Computer Computer Computer

Department

Group



Group layer The group layer lets you do the following:

● achieve a more granular control of security policy

● apply more stringent policies to server sensors installed on servers in the Payroll department as opposed to servers in the Purchasing department

Workstations layer The workstations layer contains individual hosts. This layer provides the framework for creating Desktop policy subscription groups especially if your Active Directory structure is similar to your security model.

70

Chapter 5

Performing Preliminary Tasks

Overview

Introduction This chapter discusses the role of tuning, expanding, and updating SiteProtector in maintaining protection.


Section Page

Introducing SiteProtector to Your Environment 73

Protecting Your Organization Against New Threats 77

Deciding When to Tune or Expand Protection 85


Chapter 5: Performing Preliminary Tasks

72

SECTION A: Introducing SiteProtector to Your Environment

Overview

Introduction This section describes preliminary tasks you should perform before tuning, expanding, and updating your protection. These tasks help you introduce SiteProtector to your environment gradually so that you can effectively evaluate the software’s impact on your environment.

Performing preliminary tasks

Perform preliminary tasks in the following order:

1. Run SiteProtector in a test environment.

2. Run SiteProtector in a production environment.

3. Perform baseline tasks.


Topic Page

Deploying SiteProtector in a Test Environment 74

Performing Baseline Tasks 75



Deploying SiteProtector in a Test Environment

Introduction To determine the impact of SiteProtector on your environment, you should run it in a test environment first.

Definition: test environment

A test environment is a staging area where you can deploy new software without negatively impacting production systems. A test environment replicates the production environment as much as possible so that you can effectively evaluate the behavior of the software.

Two types of tests Consider performing the following in a test environment:

Unit tests—Performed only on lab servers and usually done first.

Integration tests—Performed on lab servers but also on some production servers so that you gradually introduce SiteProtector into the production environment.

Considerations Consider the following when evaluating SiteProtector:

● To test whether the sensors are detecting events properly, launch scans from an Internet Scanner instance against hosts and segments in the test environment.

● To avoid incompatibility conflicts, install SiteProtector on servers that do not contain files or registry settings from earlier SiteProtector releases.

● Test remote access capabilities, including the deployment manager’s capacity to perform automatic updates via the Web.

● Test sensor communication across LAN links.

74

Performing Baseline Tasks

Performing Baseline Tasks

Introduction To more effectively manage events over time, consider using the Site Manager baseline feature. The baseline feature lets you track specific changes in activity between two time periods.

When to baseline Baseline the Site Manager Console when you want to do the following:

● compare activity between two time periods such as last month’s versus this month’s activity

● perform routine event monitoring

How often Depending on event volume, you may baseline several times per day or several times per week. More importantly, you should baseline whenever you begin running SiteProtector in production.

Best views to use when baselining

Use the following SiteProtector views when baselining:

● Event Name

● Vulnerability Name

How to perform baselining

To baseline the Site Manager Console:

1. Open the Site Manager, and then select a view.

2. Are you are comparing activity between two time periods?

■ If yes, type a date in the End box of the date range.

■ If no, leave the date in the End box blank.

3. Review the events that occurred since you opened the Site Manager Console or since the last time you baselined.

4. Investigate events.

Reference: For more information on investigating events, refer to the following chapters:

■ Chapter 7, "Identifying and Resolving Network Vulnerabilities" on page 125.

■ Chapter 8, "Identifying and Responding to Threats" on page 145.



5. Categorize events appropriately as either exceptions or incidents.

6. Set the time and date filter to the current time.

The Console clears events that remain in the view.

7. Repeat process as often as necessary.

76

SECTION B: Protecting Your Organization Against New Threats

Overview

Introduction This section discusses the guidelines for determining whether you are vulnerable to threats and protecting your network against threats.

Obtaining up-to-date protection

The most common way to find out about a new threat or vulnerability is through industry security advisories, such as X-Force advisories. However, on occasion, you may receive information about a threat or vulnerability from an unofficial source such as a news report, email, or Web site. To maintain up-to-date protection, you should know how to access specific information about the following:

● policies currently applied to your sensors and scanners

● latest attacks and vulnerabilities, for which you may or may not be protected

In this section This section includes the following topics:

Topic Page

Obtaining Up-to-Date Information about Threats 79

Determining Whether a Check or Signature is Available 81

Protecting Against Threats for Which No Check or Signature Exists

83



Determining whether you are protected

Use Figure 14 as a guide to determine whether you are protected against threats:

Figure 14: Determining whether you are protected

Did the informationcome from an ISS

advisory?

Yes

No

Is a check orsignature currently

available?

Yes

Upgrade to thelatest XPU

Verify thatappropriate

checks/sigs areenabled

No

Do current sensorpolicies contain these

checks/sigs?

No

Yes

Consider doing one or more of the followinguntil check or signature can be obtained:

monitor vulnerability for specified period of timeturn off systems that run vulnerable servicesadjust firewall rules to prevent access to vulnerableservicesadd host based agents to help track activity on vulnerabilehostsblock services that should not be running.add user-defined signatures to protect against that threat

Do ISS resourcescontain exploit?

Yes

No

Search ISSresourcesincluding

messages rec'dfrom mailing lists

78

Obtaining Up-to-Date Information about Threats

Obtaining Up-to-Date Information about Threats

Introduction To obtain up-to-date information about threats, do the following:

● register for ISS mailing lists and advisories

● consult the following:

■ X-Force Research Web site

■ vendors for security advisories

Tips for searching resources

When doing searches, use common identifiers, such as the following:

● vendor bulletin numbers

● standards organizations such as CVE, SANS, and CERT

Reference: For more information on standards organizations, refer to “Protecting Against Threats for Which No Check or Signature Exists” on page 83.

Registering for ISS services

To receive up-to-date information about ISS products, threats, and vulnerabilities, register for the following ISS services:

ISS mailing lists

● To receive information about the latest X-Press Updates, new product or service announcements, select the Subscribe link at http://xforce.iss.net/xforce/maillists/index.php and then select ISSForum.

● To receive information about the latest attacks and vulnerabilities, select the Subscribe link at http://xforce.iss.net/xforce/maillists/index.php and then select the X-Force Alerts and Advisories link.

Note: Consider storing information you receive from ISS mailing lists in a searchable location so that you can access it easily.



X-Force Threat Analysis Service—enables proactive security management through the following:

● comprehensive evaluation of global online threat conditions

● detailed analyses tailored for specific customer needs

To register for the X-Force Threat Analysis Service, go to http://xforce.iss.net/xftas.

Consulting the X-Force Research Website

To access up-to-date information about threats and vulnerabilities, consult the X-Force Research Website at http://xforce.iss.net. When browsing the X-Force Web site, consider searching the following Web pages:

● X-Force database search

● X-Force alerts and advisories

● Daily AlertCon

Consulting vendors for security advisories

To access up-to-date information about vulnerabilities affecting a specific product, consult the software vendor. Many vendors maintain Web sites with up-to-date information about vulnerabilities, including the impact of vulnerabilities, affected software, and the availability of patches.

80

Determining Whether a Check or Signature is Available

Determining Whether a Check or Signature is Available

Introduction To determine whether a check or signature is available for a particular threat, verify whether the X-Force has developed the check or signature and, if so, whether your current policies contain the check or signature.

Checks and signatures

Checks and signatures enable protection against specific attacks and vulnerabilities. Enabling or disabling checks and signatures requires that you create a custom policy. In SiteProtector, you must derive a custom policy from a default policy. Checks and signatures are as follows:

● Network and server sensor policies detect suspicious patterns in network traffic or system activity that could indicate an attack. Some protection systems use a sophisticated hybrid intrusion technology that can detect traffic at several layers of the protocol stack and identify what is abnormal traffic for a particular environment.

● Internet Scanner application policies contain checks, which detect known vulnerabilities on networks, systems, and services.

Tips for searching sensor policies

When searching policies for checks or signatures, consider the following:

● Network sensor and server sensor policies share many of the same signatures, so search both policies when trying to locate signatures.

● If a check is available for a particular exploit, then try to locate the corresponding signature, and vice versa.

Procedure To determine whether a check or signature is available:

1. Search the information resources for more information about the threat.

Note: Threats often have several different names. When you perform searches, use variations of the threat name. Also, the threat name may not be the same as the name of the check or signature.

2. Were you able to locate the threat?

■ If yes, then go to Step 3.

■ If no, then go to the topic “Protecting Against Threats for Which No Check or Signature Exists” on page 83.



3. From the information available in ISS resources, determine the following:

■ the name of the check or signature

■ the service release or X-Press update that contains the check or signature

4. Open current sensor policies and then search for the check or signature.

Note: To locate a check or signature, you may have to search more than one policy.

5. Does your current policy contain the appropriate check or signature?

■ If yes, then go to Step 6.

■ If no, upgrade to the X-Press Update that contains the appropriate check or signature, and then go to Step 6.

6. Verify that the check or signature is enabled.

82



Introduction When a check or signature for a particular threat does not exist, consider implementing temporary protection measures until an X-Press Update can be downloaded and the appropriate checks or signatures enabled or until permanent solutions can be implemented.

Checks without signatures and vice versa

Vulnerability checks may exist for a particular exploit but the corresponding intrusion detection signature may not be available and vice versa. Also, intrusion detection signatures may exist in server sensor policies for a particular threat and not in network sensor policies and vice versa.

Temporary measures

When possible, consider doing the following until a check or signature can be obtained:

● closely monitor the vulnerability associated with this threat

● disable systems that run vulnerable services

● block access to vulnerable ports using firewall rules (server sensor, RealSecure Desktop)

● as a last resort, block vulnerable services at the firewall

● stay abreast of all security advisories and alerts, including those provided by the X-Force

Note: Blocking services at the firewall is not always reliable. Certain network events can re-enable a blocked service. Using a host firewall to block vulnerable ports is often more cost-effective and reliable.

Additional sources for current threats and vulnerabilities

In addition to consulting ISS resources, consult the following standards organizations about threats:

CERT Coordination Center—The CERT Coordination Center (CERT/CC) is operated by Carnegie Mellon University and provides information about handling computer security incidents and vulnerabilities, developing information and training to help you improve security at your site. For more information, go to http://www.cert.org/



SANS Institute—The System Administration, Networking and Security Institute provides news digests, research summaries, security alerts, and research papers. For more information, go to http://www.sans.org/index.php

CVE—Common Vulnerabilities and Exposures is a list of standardized names for vulnerabilities and other information security exposures that is maintained by the Mitre Corporation. Use CVE to identify universal names for threats and vulnerabilities that may have more than one name. For more information, go to http://www.cve.mitre.org.

84

SECTION C: Deciding When to Tune or Expand Protection

Overview

Introduction This section helps you choose how to tune or expand protection.

Prerequisites Before you tune protection, you should have analyzed devices on your network and disabled policy signatures or checks that do not apply.

Reviewing the planning and assessment chapters

For many tuning tasks, consider reviewing the chapters on planning and assessment. These chapters are as follows:

● Chapter 2, "Assessing Your Organization" on page 9

● Chapter 3, "Protecting Your Assets" on page 21

When to tune protection

Use the following table as a guide when choosing how to tune protection:

If you want to... Then consider this... Where to find information

Expand protection as part of an ongoing plan

• add sensors to new hosts and segments

• add hosts to scans

• “Assessing Your Organization” on page 9

• “Protecting Your Assets” on page 21

increase default policy levels on some or all of your sensor policies

“Adjusting Default Sensor Policy Levels” on page 91

Expand protection because the size of your network has increased

• add sensors to hosts

• add hosts to scans

• “Assessing Your Organization” on page 9

• “Protecting Your Assets” on page 21

Table 22: When to tune protection



Tune protection against a specific threat

• install XPUs on some or all agents

• enable the appropriate signatures or checks in sensor policies

• increase responses on selected signatures

• “Protecting Your Organization Against New Threats” on page 77

• “Modifying Sensor Policy Checks and Signatures” on page 93

• “Customizing Sensor Responses” on page 94

• “Controlling Access to Desktops Using Protection Levels” on page 104

Decrease the volume of data generated by RealSecure components

• enable per event filters in the policy editor to filter false positives

• create exceptions to filter false positives

• disable checks and signatures that generate a significant number of events but add little value to your protection

• decrease default policy levels

• “Modifying Sensor Policy Checks and Signatures” on page 93

• “Controlling Access to Desktops Using Protection Levels” on page 104

• “Adjusting Default Sensor Policy Levels” on page 91

If you want to... Then consider this... Where to find information

Table 22: When to tune protection

86

Chapter 6

Tuning and Updating Your Protection

Overview

Introduction This chapter discusses tuning and updating protection, and includes topics about modifying sensor policies and scans, adding sensors to hosts, and adding hosts to scans.

Importance of an ongoing security plan

To effectively tune, expand, and update protection, ISS recommends that you establish an ongoing security plan. Similar to a deployment plan, a security plan describes how you will expand and tune your coverage over a specified period of time. The plan should include existing security goals and accommodate changes you expect your organization to undergo. It should also address procedures for dealing with software and security content upgrades in addition to new threats and vulnerabilities.

Note: This chapter provides information about some things you should consider when tuning, expanding, and updating protection. It is not a comprehensive guide to developing an ongoing security plan. For more information on developing an ongoing security plan, contact Professional Security Services at ISS.


Chapter 6: Tuning and Updating Your Protection

Why tune, expand, or update protection?

Consider tuning, expanding, and updating protection when one or more of the following occur:

● an increase in protection is specified by an ongoing security plan

● a new threat or vulnerability emerges

● the size of your network increases

● organization security priorities change

● event volume increases beyond what your staff can manage successfully


Section Page

Managing Security Policies and Responses 89

Controlling Access to Networks and Hosts 101

Monitoring and Controlling Host Activity and User Behavior 111

Expanding Protection 113

Updating Protection 117

88

SECTION A: Managing Security Policies and Responses

Overview

Introduction This section discusses the role of modifying security policies and responses in tuning your protection.

Types of sensor policies

The types of sensor policies that can be applied in the SiteProtector Console are as follows:


● server sensor

● Internet Scanner

● RealSecure Desktop

How Desktop policies are different from sensor policies?

Unlike sensors, Desktop agents are often deployed on hundreds, sometimes thousands, of hosts. Desktop agents differ from sensors in the following ways:

● you cannot easily enable or disable specific signatures on Desktop policies but you can adjust protection levels, firewall settings, and the applications that are allowed to run on the host

● you apply policies to policy subscription groups, not individual agents

● policy updates happen when agents communicate with desktop controller at predefined intervals called heartbeats



Default sensor policies

Default policies are available for sensors and Internet Scanner instances that report to SiteProtector. Adjusting default policy levels provides an easy way to tune protection because you do not have to edit a policy. However, default policies do not let you fine tune protection against specific attacks, nor do they let you reduce event volume by check or signature.


Topic Page

Adjusting Default Sensor Policy Levels 91

Modifying Sensor Policy Checks and Signatures 93

Customizing Sensor Responses 94

Specifying Desktop Responses 98

90

Adjusting Default Sensor Policy Levels

Adjusting Default Sensor Policy Levels

Introduction Adjusting default sensor policy levels lets you make broad adjustments to your protection without having to modify the individual security preferences contained in a policy.

Note: Default policies for Desktop agents are not currently designed for the types of adjustments discussed in this topic.

Coordinating default policy levels among sensors

To effectively tune your protection, consider coordinating default policy levels among sensors and scanners. Maintaining protection requires that you maintain some consistency among default policies applied to sensors deployed across your network.

Note: Before you coordinate default policies among different sensors, you should be familiar with how each policy impacts your security posture. For more information, refer to the policy documentation for the particular sensor policy.

Policy adjustments You adjust default policies by increasing or decreasing the level of protection provided by the policy. For example, you would increase protection by migrating from an original network sensor policy to a maximum policy. Adjust default policies as follows:

● increase or decrease default policy levels applied to network sensors and server sensors

● increase or decrease default policy levels applied to scans

Reference: You can also make broad adjustments to firewall rulesets by adjusting desktop protection levels. For more information, refer to “Controlling Access to Desktops Using Protection Levels” on page 104.

Proventia M Series Appliance policy inheritance

SiteProtector lets you selectively apply policy settings to Proventia M Series Appliances so that appliances can inherit policy settings from devices that are located higher in the grouping tree. For example, you could choose to apply the same firewall and antivirus settings to all Proventia M appliances in your site while creating different intrusion prevention settings for each device. This gives you more granular control of your security and lets you more effectively manage large deployments of appliances.



When to increase default policy levels

Increase default policy levels when you want to increase protection. For example, an ongoing security plan might include a strategy for gradually increasing policy levels at certain intervals. When you increase policy levels, you can also increase the volume of events you must manage.

When to decrease default policy levels

Decrease default policy levels if you want to reduce the volume of events you must manage. To reduce event volume, first consider filtering at the Site Manager Console. Decrease default policy levels only as a last resort.

92

Modifying Sensor Policy Checks and Signatures

Modifying Sensor Policy Checks and Signatures

Introduction To fine tune protection against a specific threat, consider modifying the vulnerability check or intrusion detection signature that detects the threat.

Caution: Before you modify checks and signatures, carefully consider the consequences of doing so.

Definition: event filter

Event filters let you filter events generated by network and server sensors at the policy level by criteria such as tag name, source, destination, and port. You configure event filters by editing sensor policies.

Two ways to modify intrusion detection signatures

Modify signatures using the following methods:

● disable all responses on a signature, effectively turning off the signature

● create an event filter

When to modify checks and signatures

When to modify intrusion detection signatures—Use the following as a guide to modifying signatures:

● To decrease the volume of false positives or false alarms, first consider filtering at the SiteProtector Console or creating an event filter in the sensor policy. If filtering is not effective, then consider disabling the signature that is causing the volume.

● To protect your network against a particular threat or vulnerability, consider enabling signatures on attacks that are known to exploit this vulnerability until the vulnerability can be resolved.

When to modify checks—To decrease the volume of false positives or false alarms, first consider filtering at the Site Manager Console. If filtering is not effective, then consider disabling the check that is causing the volume.



Customizing Sensor Responses

Introduction To increase protection against a specific threat, consider customizing responses for signatures in sensor policies. You can customize responses in the following policies:

● Proventia M Series Appliance

● Proventia G Series Appliance

● Proventia A Series Appliance

● network sensor

● server sensor

Why use responses?

Responses can be used to do the following:

● alert the appropriate individuals so that they can stop an attack in its early stages

● enable automatic responses that impede or block part or all traffic associated with an attack

● report or log important information about an attack

How responses work

Responses let you enable predefined actions that are performed automatically when traffic matches a certain signature. You can enable more than one response for a particular signature. Some responses are enabled by default.

Some protection systems can apply combinations of response parameters for traffic that matches certain criteria. For example, the Proventia G Series Appliance lets you block future traffic by IP, port, and protocol as well as specify the duration and percentage of traffic you are blocking.

User-defined responses

You can create your own responses for certain signatures. For example, you can create TCL scripts to run third-party security tools, such as forensics and logging tools, when certain traffic is detected. Server sensor’s fusion scripting allows you to create an extra layer of validation that is otherwise not provided with signature pattern matching. This can decrease the volume of false positives and, thus, reduce the time required to manage events. Creating user-defined responses requires an in-depth security knowledge and familiarity with sensor policies.

94


When to customize responses

Consider customizing responses based on the following criteria:

Attack severity—Enable disruptive responses, such as blocking and disabling logon privileges, for high severity attacks. Enable less disruptive responses, such as email notifications and logs, for low severity attacks. Consider enabling some type of notification or logging for all signatures, regardless of severity.

Caution: Some attacks cannot be blocked effectively using certain responses. Consider enabling notification responses, such as email or pager notifications, so that key personnel can take immediate action.

Attacks that could exploit known vulnerabilities—When you discover a new vulnerability on a host, enable stronger responses on signatures that are known to exploit this vulnerability until the vulnerability can be repaired.

Default sensor responses

Use Table 23 as a guide to customizing responses based on the severity of an attack. Network protection systems include network sensor products and the Proventia appliances:

Response type

Protection systems supported

Description

banner server sensor Sends warning to the intruder that the activity has been detected

display • network protection systems

• server sensor

Displays events in the Site Manager Console

Table 23: Default sensor responses



drop • Proventia G

• Proventia M

Drops all or part of the traffic associated with event. Three types of drop responses follow:

• ConnectionWithReset—drops all packets on the connection in which the event occurred and sends a TCP reset packet.

• Connection—drops all packets on the connection in which the event occurred.

• Packet—drops the packet that triggered the event.

Note: The drop response is available only with Proventia appliances that are configured to monitor traffic inline.

dynamic blocking or quarantine

• Proventia G

• Proventia M

Blocks any subsequent packets that meet the same criteria that is specified in the response. The criteria is as follows:

• victim address

• victim port

• intruder address

• intruder port

• ICMP code

• ICMP type

Note: Dynamic blocking is available only with Proventia appliances that are configured to monitor traffic inline.

email • network protection systems

• server sensor

Sends an email to the administrator when the specified event is detected

Response type


Description


96


Reference: For more information about responding to suspicious traffic, refer to Chapter 8, "Identifying and Responding to Threats" on page 145.

Log or display

• network protection systems

• server sensor

LogEvidence—Creates a copy of the packet that triggers an event and stores it in a log on the sensor.

LOGDB—Stores event in database.

LogWithRaw—Logs all packets associated with the event and stores the data in one or more packet files. The files can be displayed in the Event Details window in SiteProtector.

OPSEC network protection systems

Sends a message to a CheckPoint Firewall-1 instructing the firewall to block the intruder for a user-specified period of time

RSKILL • Proventia A

• network sensor

• server sensor

Kills the connection by issuing a TCP reset packet to each party in the session

SNMP trap • network protection systems

• server sensor

Sends an SNMP trap when an event is detected

Suspend • server sensor Suspends the user's account (that is, the user is logged out) and the account is temporarily disabled

Response type


Description




Specifying Desktop Responses

Introduction Similar to network and server sensors, RealSecure Desktop uses responses to alert individuals of an impending attack. The following policy components are crucial in maintaining protection on your network. For each desktop protection signature, you can specify the following:

● actions

● criteria

Coordinating responses with other ISS agents

Use desktop protection responses in conjunction with server and network sensor responses when possible. Consider the following when coordinating desktop protection responses with the sensors deployed on your network:

● If you specified responses for signatures in your network and server sensor policies, consider applying similar responses to desktop protection signatures.

● If you blocked or allowed traffic from or to certain ports on server sensors located in the same domain or area, then consider using similar rule sets on your Desktop agents.

● If scanner applications detect vulnerabilities on your desktops, consider applying stronger responses to signatures that are known to exploit those vulnerabilities until the vulnerability can be resolved.

Actions Desktop specifies certain actions that are performed automatically when traffic matches the response criteria. The available actions are as follows:

● notifies specified individuals by email

● notifies specified individuals by pager

● sets an SNMP trap for the offending intruder

98

Specifying Desktop Responses

Criteria Desktop specifies criteria that must be matched before a response action is performed. The response criteria is as follows:

● the type of signature the action applies to

● the intruder’s IP address or range of addresses the action applies to

● the target IP address or range of addresses the action applies to



100

SECTION B: Controlling Access to Networks and Hosts

Overview

Introduction You can configure agents to function similar to the way a traditional firewall functions. You can block traffic based on ports and IP addresses and, in some cases, specific protocols. This section discusses the role of network protection systems, server sensor, and RealSecure Desktop in controlling access.


Topics Page

Controlling Access to Network Segments 102

Controlling Access to Desktops Using Protection Levels 104

Controlling Access to Hosts Using Firewall Rules 106

Configuring Desktop’s Advanced Firewall Settings 108



Controlling Access to Network Segments

Introduction Network protection systems (NPSs) can control traffic that originates from outside the network or between network gateways. This topic discusses general guidelines for using network protection systems to control access to network segments.

Reference: For more specific information on, refer to the “Introducing NPSs to your Environment” on page 26.

Difference between NPSs and firewalls

Most packet filtering firewalls control traffic based on IP address, port, protocol, or application. NPSs that are configured for intrusion prevention can control traffic more selectively, blocking or limiting malicious traffic while allowing legitimate traffic to pass.

Considerations Consider the following when configuring network protection systems to block traffic:

Block traffic that is not normal for a network segment—Consider blocking traffic that is not normal for that network segment. For example, Web traffic is usually not required for critical engineering labs to function and is often restricted by policy. As a policy enforcement measure, you may want to block incoming and outgoing traffic on port 80 or any unsolicited HTTP traffic on these segments.

Deploy promiscuous NPSs on high availability segments—Consider deploying network protection systems in promiscuous mode on segments where availability and performance is critical. For example, consider deploying a promiscuous NPS to monitor traffic between a Web server cluster and a database cluster that processes a high volume of customer transactions.

Consider inline blocking in environments where patching is difficult to implement—Certain segments on your network may contain servers that cannot be patched in a timely manner. Therefore, vulnerabilities may exist on these hosts for an indefinite period of time. Furthermore, patches may introduce incompatibilities between systems or require extensive testing to implement. Consider configuring inline blocking on these segments so that you can prevent attacks that are likely to succeed.

102

Controlling Access to Network Segments

Consider dynamic blocking for exploits that use heavy traffic—Attackers often use packet floods to disable hosts. Packet floods are difficult to stop because they can originate from multiple IP addresses, including trusted internal addresses, and masquerade as legitimate traffic. The dynamic blocking response can block packet floods once they have been detected for a specified period of time, and limit the number of events that appear in the console. It can also vary the percentage of traffic blocked so that it reduces the impact of a packet flood while allowing legitimate traffic to get through. Consider enabling dynamic blocking responses on signatures that detect packet floods, such as SYN or ICMP floods, or StreamDOS attacks.



Controlling Access to Desktops Using Protection Levels

Introduction In large organizations, desktop and laptop computers number in the thousands. Desktop protection levels let you apply predefined security settings to large groups of agents. This topic discusses the role of protection levels in controlling access to large numbers of desktop and laptop computers.

How are desktops different from servers and network segments?

Desktops require a different approach to protection than servers or network segments because they have the following:

● a wider range of applications installed on them

● multiple access points (VPNs, dial-up modems)

● different configurations than servers or network segments

● more likely to be misconfigured due to misuse

Desktop protection levels

Desktop defines firewall rule sets according to broad categories of security settings, called protection levels. These protection levels apply increasing degrees of protection by accepting or blocking network traffic through entire ranges of UDP and TCP ports. You can also add or remove IP addresses or ports from the ranges specified in the protection levels.

Reconfiguring protection levels

Desktop can automatically reconfigure protection levels based on changes in the computer’s status, as follows:

Adaptive protection—Automatically adapts each agent’s protection level according to the location the device is connecting from, such as external, internal, or VPN locations.

Dynamic firewall—If the IDS engine detects an attack on a specific port, the engine dynamically blocks all traffic from that host for a pre-defined period of time.

Considerations Use protection levels to vary protection across your network based on the location and the criticality of the assets. Consider increasing protection levels in the following situations:

104

Controlling Access to Desktops Using Protection Levels

● desktops located in more vulnerable areas of the network, such as those communicating through VPNs or dial-up modems (see adaptive protection)

● desktops and laptops that contain valuable proprietary information, trade secrets, sensitive employee records, or customer information

● desktops and laptops used by upper management and human resources personnel



Controlling Access to Hosts Using Firewall Rules

Introduction Use RealSecure Desktop and server sensor firewall rules to fine tune the way hosts accept or reject traffic. Host firewalls should enforce the security policy of the host.

Blocking traffic Before blocking traffic, verify that you are not denying authorized traffic or duplicating host IDS or network firewall restrictions unnecessarily.

Advanced firewall settings

You can configure Desktop advanced firewall settings to block traffic based on ranges of source and destination IP addresses and ports. For more specific guidelines on filtering traffic based on ports or protocol types, refer to “Configuring Desktop’s Advanced Firewall Settings” on page 108.

Firecell signatures You can create server sensor firecell signatures to block traffic based on an IP address, a range of IP addresses, port, or protocol type (IP, TCP, UDP, and ICMP).

Considerations for creating host firewall rules

Consider the following when modifying advanced firewall settings or firecell signatures:

Deny non-Internet traffic from external IP addresses—In most circumstances, desktops or servers located in the internal network should not receive unsolicited traffic from an external IP address. Also, log unauthorized communication attempts from external addresses for evidence and tracking purposes.

Deny external traffic to critical servers—Servers that contain critical data should not connect to the Internet even if the traffic is legitimate and routed through the DMZ.

Deny traffic on ports used by services commonly exploited by attackers—Attackers use a wide range of services to exploit hosts. These services use certain ports to communicate with hosts. Block the ports used by these services, especially if the traffic originates from external source addresses. However, verify that you are not denying authorized traffic or duplicating host IDS or network firewall restrictions unnecessarily. Also block ports that correspond to services not used by the host.

106

Controlling Access to Hosts Using Firewall Rules

Reference: For a complete list of services commonly exploited by attackers, consult standards organizations, such as CVE, SANS, and CERT. For more information, refer to “Obtaining Up-to-Date Information about Threats” on page 79.

Deny traffic from known intruders—If you know that an intruder is attempting to access the network through a specific IP address, consider blocking this address. However, this method is not foolproof because the same attacker can change IP addresses and, even worse, masquerade as a trusted address. For more information on containing threats, refer to “Responding to Attacks” on page 161.

Note: Server sensors later than version 6.0 do not support blocking of outbound traffic.



Configuring Desktop’s Advanced Firewall Settings

Introduction Use RealSecure Desktop’s advanced firewall settings to achieve more granular control over network traffic, especially desktops or laptops that are communicating from remote locations. This topic provides guidelines for configuring advanced firewall settings to filter by the following criteria:

● IP addresses

● TCP and UDP protocols

● IP type

Role of intrusion prevention signatures

Desktop has a robust set of intrusion prevention signatures that can block malicious attacks. Use advanced firewall features to complement these intrusion prevention signatures.

IP addresses The most common way to filter Desktop traffic is by IP address. Consider filtering traffic by IP address to accomplish the following goals:

● prevent users from accessing network domains or hosts that are off limits

● prevent users from browsing the Internet

● limit network access to remote users when they are not communicating through an authorized VPN

TCP and UDP protocols

Use these guidelines for blocking traffic on TCP and UDP ports.

Blocking remote login and file transfer services—Because these services are sometimes permitted at the gateway and are transmitted in clear text, attackers often use Telnet and file transfer protocol (FTP) to gain access to desktops. Attackers often try to establish Telnet connections on port 23 so that they can log on and execute commands on the destination host.

Attackers use the FTP protocol to transfer malicious files to a compromised host. Trivial file transfer protocol (TFTP) is even more vulnerable to abuse. Remote employees, especially technical support personnel, may be required to use these protocols to access client systems. Even if these protocols are disabled by default, they may be enabled

108

Configuring Desktop’s Advanced Firewall Settings

unintentionally by users. Consider blocking FTP, TFTP, and Telnet traffic on your desktops if there is no legitimate use for them.

Note: Network administrators use Telnet and file transfer services to perform network troubleshooting. Consider the legitimate uses of these services in your organization before you block them.

Blocking peer-to-peer services—Peer-to-peer services can make desktops vulnerable, create legal liability due to the unauthorized sharing of content, and use significant network bandwidth. Consider creating a policy for acceptable use that prohibits the use of peer-to-peer services and the downloading of copyrighted material. Consider blocking the ports used by peer-to-peer services. Keep in mind that traffic from some peer-to-peer programs, such as Kazaa, can easily be reconfigured to use non-default ports.

Filtering traffic by IP type

Use the IP type filter in Advanced Firewall settings to filter IP layer protocols. The ICMP protocol is probably the most exploited protocol that runs on the IP layer.

Blocking ICMP traffic—Attackers use outbound ICMP to perform reconnaissance and launch denial of service attacks on vulnerable desktops. They can wrap malicious commands in inbound ICMP packets and, thus, create covert channels. Consider blocking inbound and outbound ICMP messages, especially ICMP replies, if there is no legitimate use for them.



110

SECTION C: Monitoring and Controlling Host Activity and User Behavior

Overview

Introduction Use Desktop’s application and system compliance to control activity on computers across your enterprise. These features let you require or prohibit certain applications from running on desktops, including unknown and antivirus applications.

Important: Some features described in this topic may not be available in the current Desktop release.

Application and system compliance

Application and system compliance provides an additional layer of protection by letting you control the software applications that can run on desktop computers. Desktop can identify these applications by their location on the drive or by registry entry, or detect if the application is running. It can also perform actions based on when the application was modified. Application and system compliance settings let you require, prohibit, and limit the behavior of applications that you specify, as follows:

Required applications—Using application and system compliance, you can maintain and enforce protection against computer viruses across the enterprise. You can require users to run a specific antivirus application and definition file and block users from accessing the network when their definition files are out-of-date. You can also specify different antivirus applications for each policy subscription group.

Prohibited applications—You can configure Desktop to identify prohibited applications and then block these applications when users attempt to install or run them.



Unknown applications—You can block all unknown applications, or notify the user when unknown applications attempt to run on a desktop or attempt to access the network. If you are blocking all unknown applications, consider specifying a list of applications that users are allowed to use to ensure that they are not prevented from performing legitimate tasks.

Caution: If not configured properly, application and system compliance can deny authorized users access to their desktops and prevent critical applications from running. Exercise caution when using this feature.

112

SECTION D: Expanding Protection

Overview

Introduction This section gives guidelines for expanding protection.


Topic Page

Adjusting Scan Frequency 114

Increasing Protection 115



Adjusting Scan Frequency

Introduction Scanning frequency determines how up-to-date your vulnerability data is. To keep vulnerability data up-to-date, consider adjusting the frequency of both network and host scans.

Event correlation accuracy

When using the SecurityFusion Module, scanning frequency can affect the accuracy of event correlation. For example, if you repair a vulnerability after you run a scan, SiteProtector continues to show the host as vulnerable until you run the scan again. Other factors, such as filtering and the age of vulnerability data, may also affect the accuracy of event correlation.

When to increase scan frequency

Consider increasing scan frequency when you want to do the following:

Adopt a stronger model of protection—An ongoing security plan might include procedures for escalating protection over time. For example, you may decide to scan certain hosts more frequently.

Respond to increased risk—The risk of attack to a group of hosts is greater than previously thought. For example, if you know that certain hosts are being reconfigured, consider increasing how often they are scanned until the repairs are completed.

Reference: For more information about scan frequency, refer to Chapter 9, "Managing Scans" on page 179.

When to decrease scan frequency

Consider decreasing scan frequency if you determine that the assets you are scanning are either less vulnerable or less critical than previously thought.

114

Increasing Protection

Increasing Protection

Introduction Increasing protection involves the following tasks:

● adding sensors or agents to hosts

● adding hosts to scans

Adding sensors to hosts

Reasons for adding sensors to hosts are as follows:

To adopt a stronger model of protection—For example, if you are migrating from the minimum protection strategy to the external threat strategy, you will probably want to add additional sensors to DMZ hosts and possibly to your intranet.

To expand the size of your network—Use the current model of protection as a guide to adding sensors to hosts you have added to your network.

Adding hosts to scans

Reasons for adding hosts to scans are as follows:

To adopt a stronger model of protection—For example, if you are migrating from the minimum protection strategy to the external threat strategy, you will probably want to add hosts to your DMZ scans.

To expand the size of your network—Use your current model of protection as a guide to adding sensors to hosts you have added to your network.

Reference: For more information about protection strategies, refer to the chapters in Part 1: Assessment and Planning of this manual.



116

SECTION E: Updating Protection

Overview

Introduction This section describes the process of updating your protection using X-Press Updates, service releases, and full upgrades.

Methods used to apply updates

You can apply updates from the Site Manager, as follows:

● manually

● using the SiteProtector Update Manager

Types of updates SiteProtector lets you update sensors, scanners, and components from the Site Manager Console using the SiteProtector Update Manager. The three ways to update protection follow:

X-Press Updates—Update SiteProtector and sensors, scanners, and agents to the latest protection. Contain new and updated checks and signatures for policies and updates to ISS documentation.

Service releases—Contain updates to software binary code. However, they occasionally include updates to security content. May be released concurrently with X-Press updates.

Full upgrades—Represent a major release of the software. They always include binary code and security content.

Important: You cannot update the Proventia M Series Appliance and the System Scanner application from the SiteProtector console.

SiteProtector components updated

Updates contain updates for one or more of the following software components:

● application server

● sensor controller

● event collector

● Desktop Controller



● Deployment Manager

● SiteProtector Console

● database

Sensors, scanners, and agents updated

ISS releases separate updates for each sensor or agent type. These updates are not combined with SiteProtector updates or other sensor updates. You can apply updates to the following from the SiteProtector Console:

● Proventia G Series Appliance

● Proventia A Series Appliance

● network sensor

● server sensor


Note: You cannot apply updates to the Proventia M Series Appliance or System Scanner from the SiteProtector Console.


Topic Page

Working With Updates 119

Applying Updates with the Update Manager 120

Applying Updates Manually 121

118

Working With Updates

Working With Updates

Introduction This topic discusses the updating of Desktop agents and sensor checks and signatures, and the X-Press Update notification process.

Updating Desktop agents

You apply updates to the desktop controller. You cannot apply X-Press Updates to individual agents. RealSecure Desktop agents can only receive updates when they contact the desktop controller.

Sensor checks and signatures added with updates

When you apply an update to a sensor that reports to SiteProtector, the update adds new checks and signatures to the default and custom policies of the sensors and scanners that report to SiteProtector.

Default policies—Adds and enables new checks and signatures, where appropriate, based on the default policy type.

Customized policies—Adds new checks and signatures but does not enable them automatically. You must enable new checks and signatures added to customized policies.

Important: ISS recommends that you update all sensors of a particular type (network or server) at the same time. Otherwise, you may push signatures contained in updated policies to sensors that are not configured to use them.

Automatic X-Press Update notification process

SiteProtector periodically checks the ISS Web site to determine if new updates are available. When SiteProtector discovers a new update, it retrieves the update and places it in the appropriate directory in your system.



Applying Updates with the Update Manager

Introduction The Update Manager lets you apply updates to all components, sensors, and scanners in your configuration. The Update Manager tries to maintain compatibility between versions, policies, and licenses, while also providing flexibility. The Update Manager does the following:

● applies cumulative updates

● permits rollbacks

● recovers from failed updates

Cumulative updates If a sensor or component requires cumulative updates, the Update Manager installs the required updates automatically. If the updates required to bring the application current are not available, then the Update Manager stops the update process before any change can take effect.

Note: Internet Scanner application updates are not cumulative. You cannot skip updates. You must apply these updates in the required sequence.

Rollbacks Most sensor and scanner updates let you roll back to the previous version. If the last update applied contained several versions, the Update Manager only uninstalls the last version contained in the update. You cannot roll back updates to SiteProtector core components. Instead, you must uninstall the current version, and then reinstall the previous version.

Recovery from failed updates

Before it performs an update, the Update Manager checks the appropriate files to determine whether they can be updated. It also backs up the files it is replacing. If the Update Manager determines that a file cannot be updated, it stops the update process, and then restores the files it has already replaced.

120

Applying Updates Manually

Applying Updates Manually

Introduction This topic discusses the process of applying updates using the Manual Upgrader.

Manual Upgrader As a security hardening measure, organizations sometimes restrict Internet access to servers that have security applications installed on them. Security professionals often must manually transfer update files between computers, and then reconstruct the proper directory structure so that the updates can be applied successfully. The Manual Upgrader utility lets you automate the transfer of these updates and also maintains the proper directory structure.

Where do I get a Manual Upgrader?

You can download the Manual Upgrader from the ISS Web site.

Internet Scanner application updates

Internet Scanner updates are not cumulative. You must apply Internet Scanner application updates in the order in which they are released. You cannot skip an update.

Network and server sensor updates

Network sensor and server sensor updates are cumulative. You can apply the latest update to your system even if you have not applied other updates in the sequence.

Desktop controller updates

Desktop controller updates are cumulative. You can apply the latest update to your system even if you have not applied other updates in the sequence.



122

®

Part II

MaintainingProtection

Chapter 7

Identifying and Resolving Network Vulnerabilities

Overview

Introduction This chapter discusses the role of identifying and resolving network vulnerabilities in maintaining protection. It also includes sample portions of some reports that provide important vulnerability information.


Section Page

Identifying and Resolving Vulnerabilities 127

Vulnerability Reports 139


Chapter 7: Identifying and Resolving Network Vulnerabilities

126

SECTION A: Identifying and Resolving Vulnerabilities

Overview

Introduction This section discusses the role of identifying and responding to threats in maintaining protection.

Importance of an vulnerability assessment plan

To effectively identify and resolve vulnerabilities, ISS recommends that you establish a vulnerability assessment plan. A good vulnerability assessment plan establishes the following:

● which hosts to include in scans

● frequency of scans

● who is responsible for affected systems

● process by which vulnerabilities are reported, tracked, and resolved

● vulnerability assessment team’s area of responsibility, including

■ organizational structure of team

■ relationship to upper management

■ services provided

Caution: This chapter is not a comprehensive guide for developing a vulnerability assessment plan. For more information on developing a vulnerability assessment plan, contact Professional Services at ISS.


Topic Page

Vulnerability Identification and Resolution Process 129

Vulnerability Data Generated by SiteProtector 131

Gathering Information About Vulnerability Events 133

Deciding Whether to Resolve Vulnerabilities 134

Repairing and Mitigating Vulnerabilities 135



Creating a Plan of Action 137

Implementing Upgrades and Patches 138

Topic Page

128

Vulnerability Identification and Resolution Process

Vulnerability Identification and Resolution Process

Introduction This topic provides an overview of the vulnerability identification and resolution process.

How to identify and resolve vulnerabilities

To identify and resolve vulnerabilities:

1. Gather information about vulnerability events using the guidelines on page 133.

2. Determine whether to resolve vulnerabilities using the guidelines on page 134.

3. Resolve vulnerabilities using the guidelines on page 135.

4. Create an action plan to resolve vulnerabilities using the guidelines on page 137.

5. Implement fixes using the guidelines on page 138.



Diagram of vulnerability identification and resolution process

Figure 15 illustrates the vulnerability identification and resolution process:

Figure 15: Diagram of vulnerability identification and resolution process

Run scanGather informationabout vulnerability

events

Resolvevulnerability?

Yes

Repairvulnerability?

No

monitor vulnerabilityfor specified period oftimeturn off systems thatrun vulnerableservicesadjust firewall rules toprevent access tovulnerable services

apply vendor-supplied patches andupgradesreconfigurevulnerable systems

Develop actionplan for repair

NoCategorize as

exception

Categorize asincident

Yes

130

Vulnerability Data Generated by SiteProtector

Vulnerability Data Generated by SiteProtector

Introduction This topic explains the types of vulnerability data generated by SiteProtector, categories of vulnerabilities, and vulnerabilities associated with specific attacks.

Definition: vulnerability

A vulnerability is a known flaw on your network that can be exploited.

Vulnerability data types

The types of vulnerability data generated by SiteProtector are as follows:

Network-based—Information generated by Internet Scanner instances. Attackers usually exploit these vulnerabilities by accessing a service that is exposed to other machines on the network. Network-based vulnerabilities can occur on both hosts and networks.

Host-based—Information detected by the System Scanner application. Attackers exploit host-based vulnerabilities by logging onto the host, as a local or a remote user.

Categories of vulnerabilities

Vulnerability categories are as follows:

Vendor-specific—Due to commercial software or hardware that is not secured properly such as software bugs, missing operating system patches, and services.

Improper configuration—Administrators improperly configuring software and hardware, such as poorly defined policies for password creation or unauthorized changes to system configurations, including uninstalling patches and hot fixes.

Improper user activity—Unauthorized use or neglect on the part of users sharing directories to unauthorized parties, failing to use or update anti-virus software, and using dial-up modems to circumvent firewalls.



Vulnerabilities associated with specific attacks

Descriptions of vulnerabilities associated with specific attacks follow:

Vulnerability Description

Backdoor A hole in the security of a system or application due to one of the following:

• a security flaw

• a hidden means of access

Buffer or field overflow A system flaw that lets an attacker submit code into a variable that exceeds the field length of the variable. The code then runs, providing access for the attacker.

Default accounts and inappropriate access privileges

A user account enabled by default, predefined accounts, or accounts with access to more resources and commands than is appropriate for the level of access.

Weak access control A system misconfiguration that weakens access control, such as permitting the use of blank or null passwords, or easily guessed passwords.

Information vulnerability A system flaw that provides reconnaissance information about a host, such as the version of an operating system.

Table 24: Vulnerabilities associated with specific attacks

132

Gathering Information About Vulnerability Events

Gathering Information About Vulnerability Events

Introduction After you scan your network, you must gather information about vulnerability events generated by the scan or scans. Use analysis views to drill down to important details about vulnerability events.

Gathering information using analysis views

Use the following SiteProtector analysis views to gather information about vulnerabilities:

Reference: For more information on how to use SiteProtector’s analysis views, refer to the SiteProtector Help.

View Description

Vuln Analysis-Vuln Name Provides high level information about the types of vulnerabilities detected on your network.

Vuln Analysis-Host Provides a good starting point for determining whether critical hosts are affected by this vulnerability.

Vuln Analysis-Object Provides detailed information about the host, such as ports, share names, registry keys, users, or files, that may be affected by the vulnerability.

Vuln Analysis-Detail Provides detailed information about the vulnerabilities detected on your network.

Table 25: Gathering information using analysis views



Deciding Whether to Resolve Vulnerabilities

Introduction This topic includes questions to help you in determining which vulnerabilities to resolve.

Deciding whether to resolve vulnerabilities

Use the following questions when determining whether a vulnerability should be resolved:

Does the vulnerability affect critical assets? The most important factor in determining whether to resolve a vulnerability is whether the host or segment affected by the vulnerability is critical.

Reference: For more information on how to determine which assets in your network are critical, refer to Chapter 2, "Assessing Your Organization" on page 9.

What’s the worst-case scenario if this vulnerability were exploited? The impact of an attack can vary. Some vulnerabilities allow attackers to potentially disable all the critical hosts in an organization while other vulnerabilities provide attackers with information that has little or no value.

How widely used is the platform that is affected by the vulnerability? The number of hosts running the platform affected by the vulnerability may determine whether this vulnerability will be exploited. Generally, the more hosts that are running a vulnerable platform, the more likely it is that the platform will be attacked.

Does the vulnerability require advanced skill to exploit? Most attackers lack advanced hacking techniques; therefore, they are not likely to exploit a vulnerability if it requires advanced skills.

Can the vulnerability be exploited by an outsider? Vulnerabilities that can be exploited by users remotely, without using local account privileges, open the door to a large number of potential attackers.

134

Repairing and Mitigating Vulnerabilities

Repairing and Mitigating Vulnerabilities

Introduction When you decide to resolve a vulnerability, do one of the following:

● repair the vulnerability

● mitigate the risk of the vulnerability

Repairing The most effective way to resolve a vulnerability is to repair it. When you repair a vulnerability, you repair or reconfigure the system so that the system affected is no longer vulnerable.

Mitigating When you mitigate a vulnerability, you attempt to lessen the impact of the vulnerability, but you do not eliminate it. Consider mitigating vulnerabilities as a temporary measure.

Exceptions and incidents

SiteProtector provides a simple way to categorize vulnerabilities, as follows:

● If you choose to resolve a vulnerability, categorize it as an incident.

● If you choose to ignore a vulnerability, categorize it as an exception.

Baseline feature Consider using the baseline feature to track vulnerabilities that have been repaired or mitigated.

What to do about vulnerabilities that cannot be resolved immediately

In special situations, consider categorizing a vulnerability as an exception especially if you know that a significant period of time will elapse before you can resolve it.



Resolving vulnerabilities

Use Table 26 as a guide when resolving vulnerabilities:

Reference: For more information on repairing vulnerabilities, refer to “Implementing Upgrades and Patches” on page 138.

Methods Task Incident or Exception

Repair vulnerability Apply vendor-supplied patches or upgrades

Categorize as an incident until patch or upgrade has been implemented and tested.

Reconfigure vulnerable systems

1. Categorize as an incident until vulnerable systems have been successfully re-configured.

2. Categorize as an exception and schedule it to expire when the system can be successfully patched or upgraded.

Mitigate vulnerability Monitor vulnerability for a specified period of time

Categorize as an incident.

Turn off systems that run vulnerable services

1. Categorize as an incident until vulnerable services are turned off.

2. Categorize as an exception and schedule it to expire when the system can be successfully patched or upgraded.

Adjust firewall rules to prevent access to vulnerable systems

Note: This approach is not foolproof. Attackers can circumvent firewall rules to access vulnerable hosts.

1. Categorize as an incident until vulnerable services are blocked.

2. Categorize as exception and schedule it to expire after the system can be successfully patched or upgraded.

Table 26: Resolving vulnerabilities

136

Creating a Plan of Action

Creating a Plan of Action

Introduction Once you decide how to repair or mitigate a vulnerability, you should create a plan that includes detailed information about the vulnerability, how you plan to resolve it, and how you plan to test it after it is resolved.

How to create an action plan

The following is a list of information to include in an action plan:

● detailed description of the vulnerability

● list of systems affected by the vulnerability

● description of how you will repair or mitigate the vulnerability, including detailed implementation procedures, such as designating responsible parties and contacting system owners

● description of how you will assess the impact of the solution, including testing and rollback procedures



Implementing Upgrades and Patches

Introduction After you create an action plan for repair, you should implement upgrades and patches.

Definition: upgrade An upgrade is a new version of, or an addition to, a hardware or software product that is already installed. Upgrades usually include new features and redesigned components.

Definition: patch A patch is a temporary fix for software or hardware, which usually addresses a specific bug or flaw. Patches usually do not include new features or redesigned components.

How to ensure successful implementation

To implement upgrades and patches successfully, you must do the following:

● test the new software or reconfiguration

● obtain cooperation from system owners and business managers who are responsible for devices being patched or upgraded

Questions to consider when implementing upgrades and patches

Use the following questions as a guide when implementing upgrades and patches:

● Will the system be more vulnerable while it is being repaired?

● Will patched and unpatched systems co-residing on your network present incompatibilities?

● Could the fix you are implementing to repair one vulnerability create another?

● Will the fix require extensive testing? If so, have you allowed enough time?

Next step Re-scan your network to determine if vulnerabilities have been repaired successfully.

138

SECTION B: Vulnerability Reports

Overview

Introduction This section contains information about some specific reports that you may want to use to identify your vulnerabilities. It also includes sample reports that are useful in identifying and resolving vulnerabilites.

Reference For more information about the reports discussed in this chapter, see the following:

● Appendix A, "SiteProtector Reports" on page 189


Topic Page

Investigating Vulnerabilities in Detail 140

Prioritizing Vulnerabilities 141

Vulnerability Remedies by Host 142

Determining Your Company’s State of Security 143



Investigating Vulnerabilities in Detail

Introduction Use the Vulnerability Analysis Details report to investigate vulnerabilities in detail. The Vulnerability Analysis Detail report provides information including tag name, severity, status, target IP address, DNS name, object type, object name, source port, and user name.

Reference: For detailed information on repairing or mitigating vulnerabilities, refer to “Repairing and Mitigating Vulnerabilities” on page 135.

Portion of sample Vulnerability Analysis Detail report

Figure 16 is a portion of a Vulnerability Analysis Detail report. This sample report was created on the Sensor Analysis tab with Vuln Analysis - Detail selected in the Load analysis view field.

Figure 16: Portion of a sample Vulnerability Analysis Detail report

Reference: For information on creating this report, see “Creating Reports on the Sensor Analysis Tab” on page 191.

140

Prioritizing Vulnerabilities

Prioritizing Vulnerabilities

Introduction Use the Vulnerabilities by Host report to determine the order in which to repair or to mitigate them. The Vulnerabilities by Host report sorts vulnerabilities detected on your network according to the host, sorted by severity (high, medium, and low). The report provides the IP address, DNS name, or NetBIOS address information about each host and includes the total number of vulnerabilities and the percentage of the total for the severity level.

Sample Vulnerabilities by Host report

Figure 17 is a portion of a Vulnerabilities by Host report. This sample report was created on the Sensor Analysis tab with Vuln Analysis - Host selected in the Load analysis view field.

Figure 17: Portion of a sample Vulnerabilities by Host report

Reference: For information on creating this report, see “Creating Reports on the Sensor Analysis Tab” on page 191.



Vulnerability Remedies by Host

Introduction Use the Vulnerability Remedies by Host report to determine how to repair vulnerabilities. The report lists detected vulnerabilites by host and provides remediation information about how to resolve them.

Sample Vulnerability Remedies by host report

Figure 18 is a portion of a Vulnerability Remedies by Host report. This sample report was created on the Reporting tab using the Vulnerability Remedies by Host report template.

Figure 18: Portion of a sample Vulnerability Remedies by Host report

Reference: For information on creating this report, see “Creating Reports on the Reporting Tab” on page 197.

142

Determining Your Company’s State of Security

Determining Your Company’s State of Security

Introduction To maintain effective security, you must be able to identify trends across your organization, evaluate the overall effectiveness of the security measures you have implemented, and verify the current and future state of your security. This section discusses how to identify trends.

Definition: trend analysis

Trend analysis identifies meaningful patterns of activity over time so that you can adjust your protection accordingly. Trend analysis helps you to do the following:

● identify the direction and scope of a pattern of activity

● determine whether a pattern of activity is potentially damaging

● anticipate future behavior

Reference For examples of reports you can use to analyze trends, see the following:

● “Determining the State of Your Security” on page 170

● “Determining the Future State of Your Security” on page 172

● “Analyzing Trends Among Multiple Sites” on page 175



144

Chapter 8

Identifying and Responding to Threats

Overview

Introduction This chapter discusses the role of identifying and responding to threats in maintaining protection. It also includes sample portions of several reports that provide important information on threats.

Importance of an emergency response plan

ISS recommends that you establish an emergency response plan. A good emergency response plan includes an internal emergency response team. The plan should clearly define the responsibilities for responding to computer security incidents, as follows:

● overall goals of the plan

● the emergency response team’s area of responsibility, including:

■ organization structure

■ relationship to upper management

■ services provided

● information flow when an incident occurs

Caution: This chapter is a not comprehensive guide to developing an emergency response plan. For more information on developing an emergency response plan, contact Professional Security Services at ISS.


Chapter 8: Identifying and Responding to Threats

Threat identification and response diagram

Use Figure 19 as a guide to identifying and responding to a threat:

Figure 19: Threat identification and response diagram


Gather informationabout intrusion

events

Is the event(s)an attack?

Yes

Are youvulnerable?

No


Yes


Respond to attackbased on severity Collect evidence

Are youblocking this

attack?

Yes

No

Does event(s)occur frequently?

Yes

No Categorize asexception

No


Is the attacksignificant?

Yes

No

Identify possiblerelated attacks

Don't know

Section Page

Identifying Threats 147

Categorizing and Responding to Threats 157

Threat Reports 167

146

SECTION A: Identifying Threats

Overview

Introduction This section discusses the criteria for gathering information about suspicious activity and determining whether it is a threat.

Threat identification Threat identification is the process of monitoring network traffic for suspicious or malicious activity and then analyzing the details of the traffic for patterns. Distinguishing between attacks, false positives, and false alarms requires that you understand the impact of events on your environment.

Events that are not attacks

The following describes the events that are not attacks:

False positives—Events that are incorrectly identified as suspicious.

False alarms—Events that were correctly identified as suspicious but are not seen as a threat, such as unsuccessful attacks and audit events.


Topic Page

Gathering Information about Events 148

Suspicious Activity Criteria 150

Identifying Related Activity Using Attack Patterns 152

Identifying Related Activity Using Firewall Events 155



Gathering Information about Events

Introduction When you see an unusual pattern in the volume or type of events on your SiteProtector Console, you should gather more information about the activity using the following features in the Site Manager:

● views

● guided questions

● date ranges

● Active Directory information

● attack patterns

Reference: For more information about how to use analysis views, see the following:

● “Creating Reports on the Sensor Analysis Tab” on page 191

How to inquire about events?

In the Site Manager, do the following to inquire about an event or group of events:

● use SiteProtector views to focus your inquiry

● select guided questions in the right-click menu to locate information about events

● use the attack pattern information provided by the optional SecurityFusion Module when available to determine the type of exploit and scope of attack

SiteProtector views Table 27 lists some views on the Analysis tab in SiteProtector that you use to gather information about events. The Event Analysis-Event Name and Event Analysis-Target are most likely to be starting points for your inquiry.

View Description

Event Analysis-Event Name

Provides high level information about the types of events detected on your network.

Table 27: SiteProtector views

148

Gathering Information about Events

Active Directory information

Use Active Directory information to determine the users that are currently logged on an internal host. SiteProtector retrieves the user’s full name, the phone number, the domain, and the fully qualified path to the Active Directory user object. SiteProtector can retrieve user names from Active Directory even if the hosts are not imported from Active Directory or are imported from a different Active Directory forest.

Guided questions in right-click menus

When you right-click an event in the analysis pane, the menu presents several guided questions about the event selected. You can continue to gather more information about the event by selecting additional questions. Examples of these questions follow:

● What are the targets of this attack?

● What are the sources of this attack?

● What are the target objects of this attack?

Event Analysis-Target Provides a good starting point for determining which hosts are possible targets of attacks. These hosts may or may not be the ultimate target of the attack.

Event Analysis-Attacker Provides a good starting point for determining the hosts from which the suspicious traffic originated. These could be hosts inside or outside your network from which the intruder is launching an attack.

Event Analysis-Target Object

Provides detailed information about the target host, such as ports, share names, registry keys, users, or files, that may be affected by an attack. Use this view to obtain more detailed information about specific hosts affected by the suspicious activity.

View Description

Table 27: SiteProtector views (Continued)



Suspicious Activity Criteria

Introduction You evaluate suspicious activity by determining the following:

● whether an event is an attack

● the significance of an attack

● whether an attack is a threat

Determining whether an event is an attack

Events that are not attacks should be ignored or categorized as exceptions. Consider the following when determining whether an event is an attack:

Authorized vulnerability scans—These can generate a large volume of suspicious traffic within a short period of time. This traffic is usually correctly identified as suspicious but is not an attack. However, distinguishing between internal scans and scans initiated by an attacker is difficult. If the scan is being performed by an Internet Scanner instance, consider filtering these events from the Site Manager Console.

Internet Scanner Scan attack pattern—You can configure the Internet Scanner Scan attack patterns to ignore the following:

● ignore scans that were launched from authorized IP addresses or by Internet Scanner applications registered in SiteProtector

● ignore individual or groups of IP addresses, DNS names, or computer names that are targets of scans launched by Internet Scanner

False positives—When a sensor misinterprets normal network activity as an attack. For example, a sensor that interprets a Web address containing a strange character as an HTTP-Shells attack could be considered a false positive.

150

Suspicious Activity Criteria

Determining the significance of an attack

Before you decide to investigate an attack, consider its significance. Attacks that deny services to users, networks, systems, or other resources are more significant than pre-attack probes. Consider categorizing attacks that are not significant as exceptions. If they occur frequently, consider categorizing them as incidents.

Do the following to determine whether an attack is significant:

● Compare the attack activity with the characteristics in the incident severity categories described in “Determining the Severity of an Incident” on page 159.

● Consider the severity of the event (high, medium, and low) displayed in the Site Manager Console.

Determining whether an attack is a threat

Consider the following when determining whether an attack is a threat:

Automatic blocking of attacks—If you are blocking an attack at a firewall or at a sensor, then it may not be a threat to your network. If you know that an attack is being blocked, consider categorizing it as an incident. In some cases, SiteProtector’s optional SecurityFusion Module confirms that certain events are being blocked by sensors.

Target of attack is not vulnerable—If the target host is not vulnerable, then the attack is probably not a threat. Consider categorizing these attacks as incidents and then attempt to identify possible related activity. The two ways to determine whether a host is vulnerable are as follows:

● use the optional SecurityFusion Module on the Site Manager Console to filter all attacks which your network is not vulnerable to

● review current vulnerability data provided by an Internet Scanner instance or a System Scanner instance on the specific hosts targeted by the attack

Caution: Vulnerability data that is not up-to-date may be inaccurate and may provide a false sense of security about your network.

Host operating system not susceptible—The host is running an operating system that is not susceptible to this attack. A Windows host being attacked by an exploit that can only compromise UNIX hosts is an example of an operating system that is not susceptible.



Identifying Related Activity Using Attack Patterns

Introduction To determine the existence of related attack activity, use the optional SecurityFusion Module attack patterns.

Attack patterns The SecurityFusion Module recognizes patterns of activity that indicate serious security incidents and precursors of attacks. These patterns are consolidated into a single incident, which makes monitoring event data more manageable.

Categories included in this topic

This topic divides attack patterns into the following categories. Throughout the course of an attack scenario, attackers often deploy several exploits that fall into more than one of these categories:

● information gathering

● break-in attempts

● denial of service attacks

● evasion

Important: The list of attack patterns included in this topic is not exhaustive. For a complete list, refer to the SecurityFusion Module Help.

Information gathering

Attackers use a wide variety of methods to gather information in advance of an attack. Some methods are benign, such as performing Whois queries or reverse lookups on target systems. Other methods are more intrusive, such as active probing of network resources for detailed information about hosts, operating systems, network topology, and access points.

The following attack patterns are associated with information gathering:

Network probing—These patterns identify attackers who are probing a host for preliminary information. Attackers perform these types of probes early in an attack so that they can gain information about how to perform more targeted reconnaissance or break-ins. For example, to identify potential attack targets, attackers often sweep entire subnets using information gathering tools, such as ping or Nmap, to determine which hosts are active.

152

Identifying Related Activity Using Attack Patterns

Targeted probing—These patterns identify attackers who are probing for information about specific services, protocols, or applications running on a host. The objective is to narrow the inquiry to a handful of vulnerabilities that attackers are likely to exploit successfully. For example, attackers often scan firewalls for port 53 (UDP) to identify where DNS servers are listening so that they can attempt to access valuable host information contained on these servers or, worse, redirect trusted communication to an untrusted host.

Breakin attempts Breakins are attempts to obtain unauthorized access using techniques such as buffer overflows and brute force attacks. Attackers often use break in attempts in combination with other types of exploits, such as denial of service and evasion attacks.

Logon attempts—These patterns identify attackers who repeatedly log on to hosts usually within a short time period. Because many points of access exist, attackers attempt to log on to a range of services, applications, and operating systems, including database, email, and instant messaging programs.

Targeted break-in attempts—These patterns identify attackers who launch a combination of attacks from a single source address so that they can gain control of a host. These patterns often include an unauthorized log in followed or preceded by the following:

● unauthorized execution of malicious code that enables systems to run on the target host

● evasion or denial of service attacks

Denial of service attacks

Denial of service attacks (DOSs) prevent systems or applications from functioning properly. The objective of these attacks is often to do the following:

● perform acts of vandalism

● disable communication between hosts

For example, a distributed denial of service attack (DDoS) launches a series of attacks from several compromised hosts against a target host. The target host usually accepts the requests because they are seen as routine traffic. The high volume of requests quickly consumes 100 percent of the host’s CPU resources.



Evasion Evasion occurs when attackers attempt to impersonate trusted hosts or services or hide their attacks by fragmenting them in such a way that network monitoring tools cannot determine that they are malicious. A TCP overlap exploit is a good example of evasion because it constructs connections with overlapping data, which causes network monitoring tools to misinterpret the intent of the connection and erroneously accept the traffic. ICMP overlap exploits function similarly but are less likely to be filtered by network monitoring tools because ICMP traffic is often required for network troubleshooting.

154

Identifying Related Activity Using Firewall Events

Identifying Related Activity Using Firewall Events

Introduction Use the events SiteProtector’s Third Party Module collects from firewalls to determine if attackers are probing your network or if unauthorized activity occurs on your firewall. The topic describes firewall events that may indicate that an attacker is attempting to, or has succeeded in, accessing the firewall.

Firewall policy or object changes

Attackers attempt to change firewall policies or objects so that they can gain access to trusted groups or services. For example, if an attacker successfully adds a login account to a Web server group, the attacker can then use these trusted servers to launch attacks against your internal network. System Administrators can inadvertently change policies or objects when they re-configure firewalls and, thus, create opportunities for attackers.

Unsuccessful logins to the firewall

Several unauthorized logins to a firewall or a host from the same source may indicate that an attacker is attempting to gain access to your network.

Ping sweeps and port scans

Attackers use a variety of tools to determine the active hosts on a network and the services that are listening. Attackers can use this information to determine which systems and applications are vulnerable or misconfigured. Firewall IDS events provide information about reconnaissance activities that often precede attacks.



156

SECTION B: Categorizing and Responding to Threats

Overview

Introduction This section discusses guidelines for evaluating suspicious activity and determining how to respond. It also includes sample of reports that are useful in determining threats.

Response process The process of responding to a threat includes everything from configuring sensor and agent responses to taking legal action against an attacker.


Topic Page

Evaluating Suspicious Activity 158

Determining the Severity of an Incident 159

Responding to Attacks 161

Collecting Evidence 164



Evaluating Suspicious Activity

Introduction This topic discusses how to evaluate suspicious activity and categorize the activity appropriately.

Definition: incident An incident is an important event. When you determine that an attack is a threat, categorize it as an incident.

Definition: exception An exception is an event that you determine is one of the following:

● not a significant threat

● cannot be addressed immediately

Guidelines for incidents and exceptions

Use Table 28 as a guide to determining whether an event is an incident or exception:

If an intrusion is... Then...

a false positive or false alarm that continues to originate from the same source and target IP

categorize it as an incident

a false positive or false alarm that is a one-time occurrence

categorize it as an exception

an event that cannot be determined categorize the event as an incident until you confirm what it is

Table 28: Guidelines for incidents and exceptions

158

Determining the Severity of an Incident

Determining the Severity of an Incident

Introduction After you determine that an attack is a threat, determine the severity level based on the scope and impact of the incident.

Reference: See “Prioritizing Attack Incidents” on page 169 for an example of a report that prioritizes incidents.

Scope The scope of an incident refers to the number of systems or applications affected by an incident, or to the number of attempts by the intruder to access the system or application.

Impact The impact of an incident is the degree of actual damage, or the degree of potential damage, caused by an incident.

How to determine the severity of an incident

Use the guidelines in Table 29 to categorize incidents based on severity:

Severity Level Characteristics

1 • small numbers of system probes, scans and similar activities detected on internal systems

• isolated instances of known computer viruses or worms easily handled by deployed antivirus software

2 • small numbers of system probes, scans and similar activities detected on internal systems

• intelligence received concerning threats to which your organization may be vulnerable

• increased risk of attack in general

Table 29: How to determine the severity of an incident



Next step Determine how to respond to the attack.

3 • significant level of network probes, scans, and similar activities detected indicating a pattern of concentrated reconnaissance

• penetration or denial of service attack(s) attempted with no impact to your organization

• widespread instances of a known computer virus or worm, easily handled by deployed anitvirus software

• isolated instances of a new computer virus or worm that cannot be handled by deployed antivirus software

• increased risk of attack to limited number of assets

4 • penetration or denial of service attack or attacks detected with limited impact on organization

• minimally successful, easy to control or counteract• small number of systems compromised

• little or no loss of confidential data

• no loss of critical systems or applications

• widespread instances of a known computer virus or worm that cannot be handled by deployed antivirus software

• small risk of negative financial or public relations impact

• a verified attack but limited to certain assets

5 • successful penetration or denial of service attacks detected with significant impact on organization

• very successful, difficult to control or counteract

• large number of systems compromised

• significant loss of confidential data

• loss of critical systems or applications

• significant risk of negative financial or public relations impact

• significant systems degradation/loss due to a virus or worm outbreak that is not handled by installed antivirus software

• a verified widespread attack

Severity Level Characteristics

Table 29: How to determine the severity of an incident (Continued)

160

Responding to Attacks


Introduction After you have determined the severity level of an attack, you can respond to the attack by alerting authorities, containing the attack, or preparing for legal action.

Definition: manual blocking

Manual blocking contains an attack while it is occurring by severing the attacker’s communication. Examples of manual blocking are as follows:

● executing block commands

● modifying firewall rules at both the network and the host level to block the attacker’s communication

Types of responses The types of responses to attacks are as follows:

Monitoring—The process of tracking the activity of the incident.

Communication—The process of alerting individuals or systems to an incident, either manually or automatically. This communication can be automated by defining responses in the network sensor and server sensor policies.

Containment—The process of preventing the incident from causing further damage to the affected application or system, or preventing the incident from spreading to other applications or systems in the network. You contain an incident by manually blocking the attacker’s communication while it is ongoing. However, you can also contain attacks by doing the following:

● repair vulnerabilities on affected hosts

● delete any unauthorized user account created by attacker

● shut down affected hosts

● install host protection, such as server sensors or Desktop agents, on affected hosts

Legal—The process of collecting evidence and, in some cases, preparing for legal action. This response varies according to the severity of the incident.



Reference: For more information about using responses in RealSecure sensors, refer to the RealSecure Network Sensor Policy Guide and the RealSecure Server Sensor Policy Guide.

Determining an appropriate response

Use the incident severity guidelines described in the previous topic to determine the appropriate response or responses to an attack:

If the incident severity level is... then consider...

1 • logging incident activity

• fixing vulnerable systems exposed to the attacker

• tracking the incident

• updating patches, virus software, and firewall rules




• blocking the attacker’s communication







• activating incident response team if available





• restricting all access to compromised system

• collecting evidence and prepare for legal action

• activating incident response team

Table 30: Determining an appropriate response

162


Next step If you determine that you need to collect additional evidence, go to the next topic, “Collecting Evidence” on page 164.





• restricting all access to compromised system

• collecting evidence and prepare for legal action

• activating incident response team

• shutting down all affected systems until they can be repaired

If the incident severity level is... then consider...

Table 30: Determining an appropriate response



Collecting Evidence

Introduction This topic discusses general guidelines for collecting evidence, including types of evidence and the qualifications employees should possess for collecting evidence.

Important: Improper handling of evidence can result in the evidence being disqualified in legal proceedings. A knowledgeable computer forensics professional can ensure that evidence is handled properly.

Types of evidence You can collect several types of evidence depending on the specific nature of the threat. The types of evidence are as follows:

Network intrusion—System logs, user logs, proxy logs, router and firewall logs, forensic images.

Email threats—Logs from mail servers, routers and firewalls. Individual PCs, laptops connected to the network, and forensic images.

Internal employee activity—System logs, mail server logs, user logs, proxy logs, router, physical security logs, firewall logs, and individual workstations.

Important: Because you may not know the scope or severity of an attack until later, ISS recommends that you collect as much evidence as possible regardless of the seriousness of the threat.

Sensor and agent log analysis

Server sensor and Desktop agent logs provide an excellent source of evidence. Logs can provide general to very detailed information about an attack depending on the type of logging that is enabled on a sensor or agent.

Reference: For more information about server sensor logs, refer to Chapter 3, "Server Sensor and Desktop Audit Features" in this Guide.

164

Collecting Evidence

Qualifications for collecting evidence

Employees should have adequate training and experience in the following areas:

● rules of evidence

● evidence integrity and continuity

● legal processes

● proper documentation



166

SECTION C: Threat Reports

Overview

Introduction This section contains information about specific reports that you may want to use to identify threats.

Reference For more information on the reports in this chapter, see the following:

● Appendix A, "SiteProtector Reports" on page 189

● SiteProtector Help


Topic Page

Prioritizing Possible Attacks 168

Prioritizing Attack Incidents 169

Determining the State of Your Security 170

Determining the Future State of Your Security 172

Analyzing Trends Among Multiple Sites 175



Prioritizing Possible Attacks

Introduction You may want to prioritize possible attacks to determine which ones are the greatest threat to your security. The Attack Trend report lists threats in order of their severity (high, medium, and low), along with the time range in which the threat occurred and the total number of attacks.

Sample Attack Trend by Month report

Figure 20 shows a portion of the Attack Trend by Month report. This sample report was created on the Reporting tab, using the Attack Trend report template with the Month option selected in the Filter Settings.

Figure 20: Portion of the Attack Trend by Month report


168

Prioritizing Attack Incidents

Prioritizing Attack Incidents

Introduction To prioritize attack incidents, you must have an accurate picture of the most important attack incidents at a particular point in time. The Attack Incidents report provides a snapshot of the most important attack incidents. Depending on your selections, the report can be sorted by severity level (high, medium, low) and can include source and target count information, a description of the incident, and the time and date the incident was created.

Reference: For detailed information on identifying threats, refer to “Identifying Threats” on page 147.

Sample Attack Incidents report

Figure 21 shows a portion of the Attack Incidents report. This sample report was created on the Reporting tab using the Attack Incidents report template.

Figure 21: Portion of the Attack Incidents report




Determining the State of Your Security

Introduction To maintain effective security, you must be able to determine your state of security at any given time. Use SiteProtector Current State Comparison reports to determine how vulnerable your organization is, and to what degree attackers are exploiting these vulnerabilities. Examples of current state comparison reports are included in this topic.

What event data should you include?

ISS recommends that you generate a separate report for each of the following:

● vulnerabilities

● attacks

● attacked vulnerabilities

Note: Attacked vulnerabilities appear only if you have the optional SecurityFusion Module installed.

Sample Current State Comparison report—vulnerabilities only

Figure 22 shows a portion of the Current State Comparison report. This sample report was created on the Enterprise Dashboard using the Current State Comparison tab with only vulnerabilities selected.

Figure 22: Portion of the Current State Comparison report—vulnerabilities only

170

Determining the State of Your Security

Sample Current State Comparison report—attacks only

Figure 23 shows a portion of the Current State Comparison report. This sample report was created on the Enterprise Dashboard using the Current State Comparison tab with only attacks selected.

Figure 23: Portion of the Current State Comparison report—attacks only

Sample Current State Comparison report—attacked vulnerabilities only

Figure 24 shows a portion of the Current State Comparison report. This sample report was created on the Enterprise Dashboard using the Current State Comparison tab with only attacked vulnerabilities selected.

Figure 24: Portion of the Current State Comparison report—attacked vulnerabilities only

Reference For information on creating these reports, see “Creating Reports on the Enterprise Dashboard” on page 205.



Determining the Future State of Your Security

Introduction To maintain effective security, you must be able to identify trends in your security. Trends help you to determine whether attacks are becoming more frequent and whether your network is becoming more vulnerable. Use SiteProtector detailed reports, referred to as monthly trend reports, to determine how your security is performing over a defined period of time. Examples of these reports are included in this topic.

What event data should you include?

ISS recommends that you generate a separate report for each of the following:

● vulnerabilities

● attacks

Note: Attacked vulnerabilities appear only if you have the optional SecurityFusion Module installed.

172

Determining the Future State of Your Security

Sample Monthly Trend report—vulnerabilities

Figure 25 shows a portion of the Vulnerability Trend by Month report. This sample report was created on the Reporting tab, using the Vulnerability Trend report template with the Month option selected in the Filter Settings.

Figure 25: Portion of the Vulnerability Trend by Month report



Sample Monthly Trend report—attacks only

Figure 26 shows a portion of the Attack Trend by Month report that includes attacks only. This sample report was created on the Reporting tab using the Attack Trend report template and Month selected for the Filter Settings.

Figure 26: Portion of the Attack Trend by Month report

Reference For information on creating these reports, see Appendix A, "Creating Reports on the Reporting Tab" on page 189.

174

Analyzing Trends Among Multiple Sites

Analyzing Trends Among Multiple Sites

Introduction Use the views in the right pane of the Enterprise Dashboard to periodically monitor groups or sites. Each view compares and organizes the data for the sites in a graph or chart format. The tabs are as follows:

● metrics

● current state comparison

● comparison

● detail

Goals of Management reports

You use trend reports to accomplish many goals. The most important goals of trend reports are as follows:

Current state of security—The current attack and vulnerability counts for each site in your enterprise.

Future state of security—The trend of attack and vulnerability counts for the past several months.

When to analyze trends

Analyze trends when you want to compare the security statistics of one site or a group of sites with another site or group of sites. You can compare trends by selecting the groups or sites you want to analyze. Depending on your organization, consider analyzing trends daily.



176

®

Part III

ImplementationStrategies

Chapter 9

Managing Scans

Overview

Introduction This chapter discusses how to implement and manage network scans in your environment using the Internet Scanner application.


Topic Page

Identifying Hosts On Your Network 180

Ensuring that Vulnerability Data is Complete and Accurate 181

Scheduling Vulnerability Scans 183

Reducing the Time Required to Run Scans 184


Chapter 9: Managing Scans

Identifying Hosts On Your Network

Introduction To identify hosts on your network, consider performing discovery scans as follows:

● after you install SiteProtector to generate host information

● periodically to identify new hosts on the network

Definition: discovery scan

Discovery scans use the Internet Scanner discovery policies. These policies identify the host operating system, services currently running on the system, and perform basic vulnerability checks.

Purpose of launching discovery scans

Discovery scans provide useful information about hosts on your network without running time-consuming checks enabled in other Internet Scanner policies. A discovery scan can help you to do the following:

● identify new hosts on a network

● determine the following:

■ how to segment scans across network and which policies to use

■ whether host operating systems are up-to-date or in compliance with company standards

■ whether the users accessing the network are authorized to do so

■ whether you have sufficient IT staff to support all the platforms on your network

Host information provided by discovery scans

Discovery scans add the following information to the host table:

● IP Address

● NetBIOS Name

● DNS Name

● OS Name

● NetBIOS Domain Name

Note: If a host does not respond to Internet Scanner connection requests, it will not be added to the host table.

180

Ensuring that Vulnerability Data is Complete and Accurate

Ensuring that Vulnerability Data is Complete and Accurate

Introduction To ensure that vulnerability data is complete and accurate, do the following:

● maintain scan consistency

● ensure that all hosts are accessible

● use the highest level of user access possible

Maintaining consistency between scans

To maintain consistency, consider doing the following:

● use the same policy and XPU level as the previous scan when verifying that vulnerabilities have been repaired

● use the same account privileges and scanner configuration as the previous scan

● apply XPUs and scanner policies between scan cycles

● vary scan times to scan hosts that may not be available during your normal scanning schedule

● coordinate your scanning with intrusion detection efforts so that you identify vulnerabilities that might be exploited

Ensuring hosts are accessible

To ensure that hosts are accessible, do the following:

Ensure that hosts are available—A host may be unavailable due to the following conditions:

● turned off

● not connected to the IP network

● running nonstandard services

● communicating through nonstandard ports



Ensure that firewalls are allowing communication—Certain firewall configurations block the traffic Internet Scanner uses to establish connections with hosts, such as:

● ICMP requests

● communication from the host used by the Internet Scanner instance

Note: You can achieve best performance if the Internet Scanner instance is located in the same segment as the assets you are scanning.

Use highest level of user access

To access all system resources, ISS recommends that you escalate access rights when you scan. Use domain administrator privileges when scanning critical domains or hosts. Scans using domain administrator rights can require significant time to complete.

182

Scheduling Vulnerability Scans

Scheduling Vulnerability Scans

Introduction Schedule scans when they will least impact your network, and when they can generate useful data.

Considerations When preparing a vulnerability scan schedule, consider doing the following:

Coordinate with system owners—Always coordinate scan times with system owners.

Allow for multiple time zones—If you have a network that services more than one time zone, consider staggering scan sessions so that you accommodate users in all the time zones.

Adhere to company policy—Schedule your scans so that you avoid scanning when devices are not available. Company policy may require that certain devices, such as desktops, be shut down at the following times:

● at the close of business

● during periodic maintenance

Avoid critical servers during peak times—To avoid impacting system performance, do not scan critical application servers during peak times when large numbers of users may be attempting to access those servers.

When to scan certain hosts

Table 31 provides some suggestions for scheduling scans:

Time of day Type of scan

Early morning Desktops

Midday Non-critical NT and UNIX servers

Evening/late night • Critical application servers

• Printer servers

Table 31: When to scan certain hosts



Reducing the Time Required to Run Scans

Introduction Network scans can generate large amounts of data. They can also be time consuming and can impact the performance of the Internet Scanner instance and the network. To reduce the time required to run scans, consider doing the following:

● improve network bandwidth and accessibility

● limit the number of hosts included in scans

● reduce default policy levels or limit the number of vulnerability checks in policy

Improving network bandwidth and accessibility

To improve network bandwidth and accessibility, consider doing the following:

Improve network bandwidth—How quickly devices on your network respond to packets sent to them affects scan times. Ping responses or Internet Control Message Protocol (ICMP) echo requests that are longer than 50 milliseconds can increase scan times significantly. If you experience slow ping response, determine whether your network bandwidth is sufficient.

Improve accessibility—Perimeter scans that are configured to scan without ping responses take longer. If you must reduce scan times, consider moving the scanning device to a location inside the firewall.

Limit hosts included in scans

To limit the hosts included in scans, consider doing the following:

Limit the overall number of hosts—ISS recommends that you scan no more than 2500 hosts per scan session. If you exceed this number, the scans may not be completed successfully. The maximum number of hosts you are able to scan in one session will vary according to the performance of your network and the device on which the scanner engine is installed.

Limit domain controller hosts—Domain controller hosts with a large registry of user accounts can take longer to scan because of the user account enumeration and password checking. Consider disabling these checks when scanning domain controllers or removing these hosts from scans.

184

Reducing the Time Required to Run Scans

Reducing default policy levels

Medium to high level scan polices take longer to run than low level policies. As a last resort, consider reducing default policy levels or limiting the number of vulnerability checks in the policy.

Reference: For more information on default policies, refer to Chapter 6, "Adjusting Default Sensor Policy Levels" on page 107.



186

TM

Appendix

Appendix A

SiteProtector Reports

Overview

Introduction You can create reports in the following locations within SiteProtector:

● Sensor Analysis tab

Note: “Sensor Analysis” is the default of this tab, but the name changes depending on the selected Vulnerability Analysis view.

● Reporting tab

● Enterprise Dashboard

This appendix explains how to create reports from each of these locations.


Appendix A: SiteProtector Reports

Creating SiteProtector reports

Table 32 lists the kinds of reports you can create in SiteProtector and where you create them:

In this appendix This appendix contains the following sections:

A report created on the... Contains this type of information...

Sensor Analysis tab Flexible and customizable reports based on analysis views

Note: The default name of this tab is “Sensor Analysis,” although the tab name changes depending on the selected Vulnerability Analysis view.

Reporting tab Formatted, graphical management-level reports with limited customization

Enterprise Dashboard Reporting of trend and summary information across multiple sites, including site comparisons and same group comparisons

Table 32: Creating reports in SiteProtector

Section Page

Creating Reports on the Sensor Analysis Tab 191

Creating Reports on the Reporting Tab 197

Creating Reports on the Enterprise Dashboard 205

190

SECTION A: Creating Reports on the Sensor Analysis Tab

Introduction This section explains how to export data to use in creating reports on the Analysis tab.

Note: The default name of this tab is “Sensor Analysis,” although the name of the tab changes depending on the Vulnerability Analysis view that you select.

Reference: For more information about creating and manipulating reports on the Sensor Analysis tab, see the SiteProtector Help.

Analysis View Features

Reports created on the Sensor Analysis tab include the following features:

● flexibility

● standard views (pre-defined)

● customizable views

● allows drill-down and fast analysis

● dynamic


Topic Page

Exporting Data on the Sensor Analysis Tab 192

Creating a Report on the Sensor Analysis Tab 194

Creating a Custom Report 195



Exporting Data on the Sensor Analysis Tab

Introduction On the Sensor Analysis tab, you select the data that you want to export and use to create your reports.

Standard views You use the Sensor Analysis tab views to select the data you want to export and use to create your report. The standard (pre-defined) views include the following:

● Event Analysis - Attacker

● Event Analysis - Detail Time

● Event Analysis - Details

● Event Analysis - Event Name

● Event Analysis - Incidents

● Event Analysis - OS

● Event Analysis - Sensor

● Event Analysis - Target Object

● Event Analysis - Target

● Vuln Analysis - Detail

● Vuln Analysis - Host

● Vuln Analysis - Object

● Vuln Analysis - Vuln Name

Filters You can use the SiteProtector filters to control the information that is displayed in the Sensor Analysis tab. To view a list of all of the current filters, use the Advanced icon on the Sensor Analysis toolbar. Following are some important things to know about the filters:

● Filters are stored on the client machine and not in the Site DB.

● Filters are temporary. Filter settings are not saved in an analysis file. If you log off, the filter no longer exists.

● You can save the filter and column settings in an analysis file. This file is stored on the client, and you can reload it as needed.

192

Exporting Data on the Sensor Analysis Tab

Columns Add columns to present more detailed information. The columns available for display in the analysis views are as follows:

● count columns—To display information about the count, or number, of events on an analysis view

● event columns—To display information about events on an analysis view

● target and source columns—To display information about a target or source on an analysis view

● time columns—To display information about the date or time that an event occurred

Report formats You can print or save reports created from data exported on the Sensor Analysis tab in any of the following formats:

● hypertext markup language (HTML)

● comma-separated value (CSV)

● portable document format (PDF)

You can also copy and paste the report data into email, spreadsheet, or text files.



Creating a Report on the Sensor Analysis Tab

Introduction Creating a report on the Sensor Analysis tab involves select and exporting the appropriate data, and then using the exported data to create the report.

Procedure To create a report on the Sensor Analysis tab:

1. In the Site Manager grouping tree, select the group or subgroup you want to use, and then click the Sensor Analysis tab.

2. Select the analysis view for the type of report you want to generate.

3. Select Analysis Data Export Print Data.

The Print window opens.

4. On the General tab, specify the following:

■ the printer

■ the pages to print

■ the number of copies to print

5. Use the Page Setup tab to change the paper size and orientation, if desired.

6. Click Print.

Note: If you schedule more than 10 reports to run at the same time, while the first report runs, the subsequent 9 reports are queued in the Analysis Data Export Jobs pane and may fail.

194

Creating a Custom Report

Creating a Custom Report

Introduction You can customize a report by adding or removing the standard columns, or by rearranging the order of the columns before you generate the report.

Procedure To create a report with custom data columns:

1. In the Site Manager grouping tree, select the group you want to use, and then select the Sensor Analysis tab.

2. Select the analysis view for the type of report you want to generate.

3. Select Analysis Configure Add/Remove Data Columns.

The Advance Filter window appears.

4. In the Displayed pane, select the columns you want to remove, and then click Remove.

5. In the Available pane, select the columns you want to add to the report, and then click Add.

6. Use the Up and Down buttons to sort the names in the Available pane.

7. Click OK.

8. From the Analysis menu, select Data Export Export Data.

9. In the Open window, type the name of the report, and then click Save.



196

SECTION B: Creating Reports on the Reporting Tab

Introduction The reports you create from the Reporting tab are high-level management reports that help you identify trends across your organization, evaluate the overall effectiveness of security measures, and verify the current and future state of your security. This topic explains how to use the Reporting tab to create reports.

Reference: For more information about creating and manipulating reports on the Reporting tab, see the SiteProtector Help.

Features Reports created on the Reporting tab include the following features:

● non-analysis static reports

● pre-defined templates

● customization options

● intended for managers, executives, and analysts

● weekly, monthly, and yearly summary data

Report categories The reports are grouped into the following categories:

● assessment

● attack activity

● Desktop protection

● management

● SecurityFusion

● virus activity

Report formats You can print or save reports created on the Reporting tab in any of the following formats:

● portable document format (PDF) - the default


● comma-separated value (CSV)



Things to be aware of

When creating report templates, keep the following in mind:

● Do not schedule more than 10 jobs at the same time. While the first report is processing, the next 10 jobs are queued, and then any additional jobs fail.

● Some reports may produce more than 30 pages. If so, using the HTML format causes the text in the report to overlap and become unreadable. When running a report that may result in 30 or more pages, use the PDF or CSV formats.


Topic Page

Using the Report Templates 199

Creating a Report 202

Viewing a Report 203

198

Using the Report Templates


Introduction SiteProtector provides pre-defined report templates that you can use to generate reports from the Reporting tab. These templates contain all of the parameters needed to generate a report, including headers, footers, filters, and format.

You can use the pre-defined templates or have the templates customized to fit your specific needs. Contact Professional Services to customize a report.

Reporting tab templates

Table 33 describes the reports you can create on the Reporting tab:

Category Report Name Description

Assessment Top Vulnerabilities Lists the top vulnerabilities by frequency for a specified group and time.

Vulnerabilities by Group

Compares vulnerabilities across subgroups of a selected group.

Vulnerability by OS Compares vulnerability counts by operating systems.

Vulnerabilities by Host

Lists the top hosts by number of vulnerabilities for a specified group and time.

Operating System Summary

Displays percentage and number of hosts by operating system discovered during an automated network scan.

Vulnerability Counts Lists detected vulnerabilities by total number and by percentage.

Table 33: Reporting tab reports



Host Assessment Summary

Lists discovered hosts and identifies network services and vulnerabilities for each host.

Vulnerability Counts By Host

Lists the number and severity of vulnerabilities for each host.

Operating System Summary By Host

Lists the operating systems detected on the network.

Service Summary Identifies the network services detected on the scanned hosts.

Vulnerability Names By Host

Lists detected vulnerabilities by DNS name, IP address, and the name of each vulnerability detected.

Vulnerability Summary By Host

Lists detected vulnerabilities by DNS name, IP address, operating system, and the name of each vulnerability detected.

Host Assessment Detail

Lists discovered hosts with detailed information about network services and vulnerabilities.

Service Summary By Host

Identifies the network services detected on each scanned host.

Vulnerability Remedies By Host

Lists detected vulnerabilities by host and includes remediation information.

Vulnerability Detail By Host

Lists detected vulnerabilities by host. Provides the DNS name, IP address, operating system type, and remediation information.


Table 33: Reporting tab reports (Continued)

200


Attack Activity Attacks by Group Compares attack counts across subgroups of a selected group.

Top Attacks Lists the top attack names by frequency for a specified group and time.

Top Sources of Attack

Lists the top attack sources by frequency for a specified group and time.

Top Targets of Attack Lists the top attack targets by frequency for a specified group and time.

Desktop Desktop Protection Displays counts of hosts protected and not protected with version details.

Management Attack Trend Attack activity by Day/Week/Month/Quarter/Year.

Protection Report Displays total counts of hosts protected and unprotected by ISS host protection agents.

Attack Incidents Lists all security incidents created for a specified time.

Virus Activity Trend Virus activity by Day/Week/Month/Quarter/Year.

Vulnerability Trend Vulnerabilities by Day/Week/Month/Quarter/Year.

SecurityFusion Attack Status Summary

Displays counts of fusion status events for a selected group and time.

Virus Activity Top Virus Activity Lists the top viruses by frequency for a specified group and time.

Virus Activity by Group

Compares virus activity across subgroups of a selected group.

Virus Activity by Host Lists the top hosts by amount of virus activity for a specified group and time.


Table 33: Reporting tab reports (Continued)



Creating a Report

Introduction Creating a report on the Reporting tab involves selecting the desired report template, defining the report variables, and then generating the report.

Procedure To create a report from the Reporting tab:

1. On the Site Manager, click the Reporting tab.

2. Select the report template that you want to use.

3. Right-click the template name, and then select Run Report.

The Run Report dialog opens.

4. On the Report Specification tab, enter the Report Title and optional Report Description.

5. In the Report Period section, select Standard Time Period or Custom, and then select the time period for the report.

6. Select the settings you want to use for the custom report.

Note: See the SiteProtector Help for more detailed information about creating a report.

7. On the Recurrence tab, enter the Recurrence pattern, Event Time, and Range of recurrence information, if desired.

8. Click OK.

The information about the job displays in the Report Jobs pane.

Note: If you schedule more than 10 reports to run at the same time, while the first report runs, the subsequent 9 reports are queued and may fail.

202

Viewing a Report

Viewing a Report

Introduction Once you create a report on the Reporting tab, view the report to verify that it contains the correct information.

Procedure To view a custom report based on a particular template:

1. On the Site Manager, select the Reporting tab.

2. Select the report template for which you want to see the custom report.

3. Right-click, and then select List Reports on the menu.

The Reports for Group window opens and displays the custom reports based on the selected template.

4. Select the report you want to open, and then click View.

The read-only report opens.



204

SECTION C: Creating Reports on the Enterprise Dashboard

Introduction The Enterprise Dashboard contains information about multiple sites reporting to the Enterprise Dashboard. The reports you create from the Enterprise Dashboard provide trend and summary information, identifying meaningful patterns of activity over time so you can determine your organization’s state of security and adjust your protection accordingly.

Reference: For more information about creating and manipulating reports on the Enterprise Dashboard, see the SiteProtector Help.

Features Reports created from the Enterprise Dashboard include the following features:

● reporting across multiple sites

● site comparisons

● same group comparisons

● trends and summaries

Enterprise Dashboard views

Use the tabs in the right pane of the Enterprise Dashboard to periodically monitor groups or sites. Each view compares and organizes the data for the sites in a graph or chart format. You can save or print this information in report format. The tabs include the following:

● metrics

● current state comparison

● comparison

● detail



Report formats You can print or save reports created on the Enterprise Dashboard in the following formats:


● portable document format (PDF)


Topic Page

Printing a report 207

Saving a report 208

Scheduling a report 209

206

Printing a report

Printing a report

Introduction Creating a report on the Enterprise Dashboard involves selecting the type of report you want to create, the date filters, and the printer settings.

Procedure To print a report from the Enterprise Dashboard:

1. In the Enterprise Dashboard, select the Site and group you want to use.

2. In the right-hand pane, select the tab for the type of report you want to create from the following:

■ Metrics

■ Current State Comparison

■ Comparison

■ Detail

3. Set the Start Date and End Date filters to display the time and date for the data you want to use.

4. Select the severity filter check boxes you want to use.

5. On the Site Manager menu bar, select Reporting Print Report.

The Print window opens.

6. Change the print settings, if desired.

7. Click Print.

Note: If you schedule more than 10 reports to run at the same time, while the first report runs, the subsequent 9 reports are queued in the Scheduled Jobs pane and may fail.



Saving a report

Introduction Saving a report on the Enterprise Dashboard involves selecting the type of report you want to create, the date filters, and the file type.

Procedure To save a report from the Enterprise Dashboard:

1. In the Enterprise Dashboard, select the Site and group you want to use.


■ Metrics


■ Comparison

■ Detail

3. Set the Start Date and End Date filters to display the time and date for the data you want to use.

4. Select the severity filter check boxes you want to use.

5. On the Site Manager menu bar, select Reporting Save Report.

The Save window opens.

6. Use the Save in arrow to designate a location for the saved report.

7. In the File name box, type the name for the file.

8. Use the File type arrow to select one of the following formats:

■ CSV

■ PDF

■ HTML

9. Click Save.

Note: Vulnerability information is not available when you save a report using the Enterprise Dashboard.

208

Scheduling a report

Scheduling a report

Introduction Scheduling an Enterprise Dashboard report involves selecting the type of report you want to create, the date filters, and the output settings.

Procedure To generate a report according to a schedule:

1. In the grouping tree, select the group or subgroup you want to use.


■ Metrics


■ Comparison

■ Detail

3. Set the Start Date and End Date filters to display the time and date you want to use.

4. On the Site Manager menu bar, select Reporting Schedule Report.

The New Report Creation Schedule window opens.

5. In the Output Parameters section, do the following:

■ type the fully qualified path or the path based on the Universal Naming Convention (UNC) for the report in the File name box

■ specify the interval of time the report should cover

■ designate the format to use

■ if you want the report to recur on a daily, weekly, or monthly basis, click Edit Schedule to establish a schedule

By default, the report is generated immediately. If you specified a relative path instead of a fully qualified path, the report is saved in the Application Server\Temp folder.

6. In the Current View Selection section, review the display of selections.

7. Do you wish to use the selections displayed?

■ If yes, click OK.

The report is scheduled.



■ If no, click Cancel, and then repeat Steps 1 through 6 to reselect the settings.

8. Click OK.

Vulnerability information is not available when you schedule a report using the Enterprise Dashboard.

210

Indexattacks 147
a
access controlinappropriate or weak 132scanning with highest level of user

access 182vulnerabilities due to improper user

activity 131action plan for vulnerabilities 137actions, used in desktop protection

responses 98adding hosts to scans 115aggregation points 37aggregation points, defined 25alerts and advisories, ISS 79Analysis tab

reports 190analyzing

trends among multiple sites 175application and system compliance 40, 111assessing your organization 9

external threat protection strategy 17internal threat protection strategy 18maximum protection strategy 19minimum protection strategy 16

Attack Incidents report 201Attack Status Summary report 201Attack Trend report 168, 201

SiteProtector Best Practices Guide, Version 2.0 SP5

attack severity 94automatic blocking of 151break-in attempts 153definition 24exception 158false alarms 147false positives 147incidents 158information gathering 152operating system not susceptible 151related activity 152severity 95significance 151target not vulnerable 151that exploit known vulnerabilities 95

Attacks by Group report 201attacks, prioritizing 168audit features 41

bbackdoor 132banner responses 95baseline tasks 75baselines, system 43best practices, security xibest protection strategy to use 13–14blocking 151, 161break-in attempts 153buffer overflow 132

211

Index

ccategories for report templates 197CheckPoint Firewall, blocking 97checks

temporary measures when not available 83that disrupt critical communication or

services 32without corresponding signatures 83

choke points.See aggregation pointscolumns

count 193event 193target and source 193time 193

command and control tasksdesktop protection 60sensor 59

communication, responding to attacks 161containment, responding to attacks 161conventions, typographical

in commands xviiiin procedures xviiin this manual xvii

count columns 193creating reports 190

Sensor Analysis tab 191criteria, used in desktop protection

responses 99critical hosts 41, 47, 182

avoiding during peak times 183in DMZ 36in intranet 33–35, 37–38, 46vulnerabilities that affect 134

current state of security 170

212

dDaily AlertCon 80data export

Sensor Analysis tab 192default policies 90

adjusting 91demilitarized zone.See DMZdenial of service 153deployment plan 9desktop protection

in VPN 45, 47Desktop Protection report 201discovery scans 180display responses 95DMZ 31, 33

scanning hosts in 31servers and desktops in 46–47

documentationStrategy Guide

audience xipurpose xi

domain administrator rights, role in scanning 182

domain controller hosts, role in scanning 184DoS.See denial of servicedrop responses 96dynamic blocking responses 96

eEmail

responses 96threats 164

emergency response plan, importance of 145

Index

Enterprise Dashboardin geographical model 61in scope of responsibility model 67reports 190

escalating privileges 27, 33, 35, 38evasion 154Event Analysis-Event Name view 148Event Analysis-Source view 149Event Analysis-Target Object view 149Event Analysis-Target view 149event columns 193event filters 86, 93events

cannot be determined 158decreasing volume 86

evidence, types 164exceptions 86, 136, 158

135categorizing false positives and false alarms

as 158categorizing vulnerabilities as 135

expanding protection 115as part of an ongoing plan 85because size of network has increased 85

exporting dataSensor Analysis tab 191

external scans.See perimeter scansexternal threat protection strategy

example 53illus 53overview 13when to use 17

external traffic to critical servers 106

ffalse alarms 147, 158false positives 147, 150, 158Filters 192


filtersSensor Analysis tab 192

Firecell signatures 106firewalls

adjusting rules to prevent access 130, 136blocking scans 182definition 25grouping data from 63rule sets used in desktop protection 106rules 106scanning routers outside of 31unsuccessful logins to 155

fusion.See SecurityFusion Modulefuture state of security 172

ggrouping models

geographical 61illus 61–63, 65policy 62scope of responsibility 67services 65topological 63

grouping sensors using different software versions 59

guided questions. See questions in right-click menus

hHost Assessment Detail report 200Host Assessment Summary report 200

213

Index

hostsavailability during scans 181limiting number included in scans 184not susceptible to attack 151

iICMP requests 182, 184ignoring authorized scans using attack patterns

attack patterns 150impact of an incident 159improper configuration, vulnerabilities due

to 131incidents 136, 158

attacks categorized as 158categorizing vulnerabilities as 135–136false positives and false alarms categorized

as 158prioritizing 169security levels 159

information gathering 152information resources, security

CERT Coordination Center 83CVE 84mailing lists, ISS 79SANS Institute 83X-force threat and advisory service 80

inline protection 26inline simulation 26integration tests 74internal threat protection strategy

illus 54overview 13when to use 18

214

Internet Scanner 150intranet scans 30–31, 33, 35, 38scanning E-commerce sites 32scanning guidelines 31, 33, 35, 38See also perimeter scansSee also router scans

Internet Scanner Scan 150Internet Security Systems

technical support xvWeb site xv

intranet scans 31intranets

network traffic in 33–34protecting with minimum protection

strategy 31scanning in 33, 35, 38servers and desktops in 45–47

intrusion detectiondefinition 24

investigating vulnerabilities 140

llog on attempts 153LOGDB responses 97LogEvidence responses 97logging 41

collecting evidence 164evidence logs 42impact on server performance 41packet logs 42

LogWithRaw 97

Index

mmanual blocking 161Manual Upgrader 121maximum protection strategy

illus 55overview 13when to use 19

minimum protection strategyillus 52overview 13when to use 16

monitoringof host system logs 41role in responding to attacks 161

multiple sitesanalyzing trends 175

nnetwork sensor

outside firewall 33placement

DMZ 31, 33–34, 36intranet 33–34, 37VPN 33

RealSecure Network Sensor 7.0 81whether they are detecting events

properly 74non-Internet traffic from external IP

addresses 106notification process, X-Press Updates 119


oongoing security plan, importance of 87operating system

grouping according to 64–65Operating System Summary by Host

report 200Operating System Summary report 199operational modes, Proventia G 26OPSEC responses 97

ppassive monitoring 26patches

role in repairing vulnerabilities 136, 138security advisories 80

perimeter scans 33, 35, 38phone home 60ping responses, role in scanning 184policies

default and customized 119policy

adjusting default policies 91–92compliance 43maintaining between scans 181modifying checks and signatures 93reducing levels of default scan policies 184scanning priority 28subscription groups 60

ports used by services commonly exploited by attackers 106

prioritizingvulnerabilities 141

prioritizing attacks 168prioritizing security incidents 169probes.See information gathering

215

Index

probingnetwork 152targeted 153

prohibited applications, in desktop protection policies 111

protection levelsdefinition 104

Protection Report 201protection strategies

migration path 14overview 13

Proventia G Series 26Proventia M Series Appliance 34, 37

qqualifications, collecting evidence 165questions in right-click menus 148–149

rreconaissance.See information gatheringremote access, testing SiteProtector for 74repairing vulnerabilities 135–136report templates 199

categories 197creating a report 202viewing a report 203

reporting 189

216

Reporting tabcreating a report 202report categories 197report templates 199reports 190templates 197viewing a report 203

Index

reports 189Attack Incidents 201Attack Status Summary 201Attack Trend 168, 201Attacks by Group 201creating 190Desktop Protection 201Enterprise Dashboard 190Host Assessment Detail 200Host Assessment Summary 200Operating System Summary 199Operating System Summary by Host 200Protection Report 201Reporting tab 190Security Incidents 169Sensor Analysis tab 190Service Summary 200Service Summary by Host 200Top Attacks 201Top Sources of Attack 201Top Targets of Attack 201Top Virus Activity 201Top Vulnerabilities 199views for Sensor Analysis tab 192Virus Activity by Group 201Virus Activity by Host 201Virus Activity Trend 201Vulnerabilities by Group 199Vulnerabilities by Host 199Vulnerability by Host 141Vulnerability by OS 199Vulnerability Counts 199Vulnerability Counts by Host 200Vulnerability Detail by Host 200Vulnerability Names by Host 200Vulnerability Remedies by Host 200Vulnerability Summary by Host 200Vulnerability Trend 201

required applications, in desktop protection policies 111


responsesdefault 95definition 24desktop protection 98reasons for using 94types 95user-defined 94

router scans 31, 33, 35, 38RSKILL responses 97

sscan frequency

event correlation accuracy 114when to increase 114

scanning guidelinesexternal threat protection strategy 33internal threat protection strategy 35maximum threat protection strategy 38minimum protection strategy 31

scanning priority 28scans

adding hosts 115types of network scans 29–30

scope of an incident 159searching sensor policies 81security incidents

prioritizing 169Security Incidents report 169SecurityFusion Module 148, 151sensitive traffic

grouping according to 61grouping hosts that process 66mirroring using network sensor 34, 37

217

Index

Sensor Analysis tabdata export 192exporting data for analysis reports 191filters 192reports 190views 192

server sensormonitoring of host system logs 41placement 45

DMZ 44, 46–47intranet 44–47

whether they are detecting events properly 74

service releases 117Service Summary by Host report 200Service Summary report 200services

grouping according to 64–65signatures

limiting to firewall attacks only 33temporary measures when not available 83without corresponding checks 83

Site Managergrouping tree 60in geographical model 61in scope of responsibility model 67tasks performed in grouping tree 59

SiteProtector reports 189sites, multiple

analyzing trends among 175SNMP trap responses 97starting points for protection strategies 14state of security

current 170future 172

Strategy Guideaudience xipurpose xi

stronger model of protection, adopting a 115suspend responses 97system identification checks 59

218

System Scannerhost scanning 43in deployment models 50–55level of protection 43placement 45–47

ttarget and source columns 193targeted break-in attempts 153TCP ports, blocking ranges of 104TCP reset packet, used in RSKILL response 97technical support, Internet Security Systems xvtemplates for reports 199test environment, guidelines for deploying

SiteProtector 74Third Party Module 155threat identification

illus 146threats

identification of 157protecting against illus 78

time columns 193Top Attacks report 201Top Sources of Attack report 201Top Targets of Attack report 201Top Virus Activity report 201Top Vulnerabilities report 199traffic from known intruders 107trusted hosts 32typographical conventions xvii–xviii

uUDP ports, blocking ranges of 104

Index

unit tests 74unknown applications, in desktop protection

policies 112updating protection 117upgrades 117

role in repairing vulnerabilities 138

vvendors

bulletin numbers 79consulting 80patches supplied by 136vulnerabilities specific to 131

viewsbest for baselining Site Manager Console 75best for gathering information about possible

attacks 148Sensor Analysis tab 192

Virus Activity by Group report 201Virus Activity by Host report 201Virus Activity Trend report 201VPN

desktops and laptops in 45, 47protecting with application control 40protecting with external threat protection

strategy 33role of desktop protection 45without large web presence 36


vulnerabilitiesadvanced hackers that exploit 134best views for monitoring 133categories of 131data generated by authorized scans 150exploited by an outsider 134informational 132investigating 140mitigating 135–136monitoring 136resolving 135target of attack not vulnerable 151that cannot be resolved immediately 135worse case scenario if exploited 134

Vulnerabilities by Group report 199Vulnerabilities by Host report 199vulnerabilities, prioritizing 141vulnerability assessment scans

developing a plan 183managing large scans 184

Vulnerability by Host report 141Vulnerability by OS report 199Vulnerability Counts by Host report 200Vulnerability Counts report 199Vulnerability Detail by Host report 200vulnerability identification and resolution process,

illus 130Vulnerability Names by Host report 200Vulnerability Remedies by Host report 200Vulnerability Summary by Host report 200Vulnerability Trend report 201

wWeb site, Internet Security Systems xvWeb-facing hosts 31–33, 35, 38

219

Index

xX-Force Research Website 80X-Press Updates 117–121

checks and signatures added to sensor policies 119

determining the correct update 121ISS mailing lists 79maintaining between scans 181notification process 119

220

Internet Security Systems, Inc. Software License Agreement

THIS SOFTWARE PRODUCT IS PROVIDED IN OBJECT CODE AND IS LICENSED, NOT SOLD. BY INSTALLING, ACTIVATING, COPYING OR OTHERWISE USING THIS SOFTWARE PRODUCT, YOU AGREE TO ALL OF THE PROVI-SIONS OF THIS SOFTWARE LICENSE AGREEMENT (“LICENSE”). IF YOU ARE NOT WILLING TO BE BOUND BY THIS LICENSE, RETURN ALL COPIES OF THE SOFTWARE PRODUCT AND LICENSE KEYS TO ISS WITHIN FIF-TEEN (15) DAYS OF RECEIPT FOR A FULL REFUND OF ANY PAID LICENSE FEE. IF THE SOFTWARE PRODUCT WAS OBTAINED BY DOWNLOAD, YOU MAY CERTIFY DESTRUCTION OF ALL COPIES AND LICENSE KEYS IN LIEU OF RETURN.1. License - Upon payment of the applicable fees, Internet Security Systems, Inc. (“ISS”) grants to you as the only end user (“Licensee”) a

nonexclusive and nontransferable, limited license for the accompanying ISS software product and the related documentation (“Software”) and the associated license key(s) for use only on the specific network configuration, for the number and type of devices, and for the time period (“Term”) that are specified in ISS’ quotation and Licensee’s purchase order, as accepted by ISS. ISS limits use of Software based upon the number of nodes, users and/or the number and type of devices upon which it may be installed, used, gather data from, or report on, depending upon the specific Software licensed. A device includes any network addressable device connected to Licensee’s network, including remotely, including but not limited to personal computers, workstations, servers, routers, hubs and printers. A device may also include ISS hardware delivered with pre-installed Software and the license associated with such shall be a non-exclusive, nontransfera-ble, limited license to use such pre-installed Software only in conjunction with the ISS hardware with which it is originally supplied and only during the usable life of such hardware. Except as provided in the immediately preceding sentence, Licensee may reproduce, install and use the Software on multiple devices, provided that the total number and type are authorized by ISS. Licensee acknowledges that the license key provided by ISS may allow Licensee to reproduce, install and use the Software on devices that could exceed the number of devices licensed hereunder. Licensee shall implement appropriate safeguards and controls to prevent loss or disclosure of the license key and unauthorized or unlicensed use of the Software. Licensee may make a reasonable number of backup copies of the Software and the associated license key solely for archival and disaster recovery purposes. In connection with certain Software products, ISS licenses security content on a subscription basis for a Term and provides Licensee with a license key for each such subscription. Content sub-scriptions are licensed pursuant to this License based upon the number of protected nodes or number of users. Security content is regu-larly updated and includes, but is not limited to, Internet content (URLs) and spam signatures that ISS classifies, security algorithms, checks, decodes, and ISS’ related analysis of such information, all of which ISS regards as its confidential information and intellectual property. Security content may only be used in conjunction with the applicable Software in accordance with this License. The use or re-use of such content for commercial purposes is prohibited. Licensee’s access to the security content is through an Internet update using the Software. In addition, unknown URLs may be automatically forwarded to ISS through the Software, analyzed, classified, entered in to ISS’ URL database and provided to Licensee as security content updates at regular intervals. ISS’ URL database is located at an ISS facility or as a mirrored version on Licensee’s premises. Any access by Licensee to the URL database that is not in conformance with this License is prohibited. Upon expiration of the security content subscription Term, unless Licensee renews such content subscription, Lic-ensee shall implement appropriate system configuration modifications to terminate its use of the content subscription. Upon expiration of the license Term, Licensee shall cease using the Software and certify return or destruction of it upon request.

2. Migration Utilities – For Software ISS markets or sells as a Migration Utility, the following shall apply. Provided Licensee holds a valid license to the ISS Software to which the Migration Utility relates (the “Original Software”), ISS grants to Licensee as the only end user a nonexclusive and nontransferable, limited license to the Migration Utility and the related documentation (“Migration Utility”) for use only in connection with Licensee’s migration of the Original Software to the replacement software, as recommended by ISS in the related documentation. The Term of this License is for as long as Licensee holds a valid license to the applicable Original Software. Licensee may reproduce, install and use the Migration Utility on multiple devices in connection with its migration from the Original Software to the replacement software. Licensee shall implement appropriate safeguards and controls to prevent unlicensed use of the Migration Utility. Licensee may make a reasonable number of backup copies of the Migration Utility solely for archival and disaster recovery purposes.

3. Third-party Products - Use of third party product(s) supplied hereunder, if any, will be subject solely to the manufacturer’s terms and conditions that will be pro-vided to Licensee upon delivery. ISS will pass any third party product warranties through to Licensee to the extent authorized. If ISS supplies Licensee with Crystal Decisions Runtime Software, then the following additional terms apply: Licensee agrees not to alter, disassemble, decompile, translate, adapt or reverse-engineer the Runtime Software or the report file (.RPT) format, or to use, distribute or integrate the Runtime Software with any general-purpose report writing, data analysis or report delivery product or any other product that performs the same of similar functions as Crystal Decisions’ product offerings; Licensee agrees not to use the Software to create for distribution a product that converts the report file (.RPT) format to an alternative report file format used by any general-pur-pose report writing, data analysis or report delivery product that is not the property of Crystal Decisions; Licensee agrees not to use the Runtime Software on a rental or timesharing basis or to operate a service bureau facility for the benefit of third–parties unless Licensee first acquires an Application Service Provider License from Crystal Decisions; Licensee may not use the Software or Runtime Software by itself or as part of a system to regularly deliver, distribute or share Reports outside of the Runtime Software environment: (a) to more than fifty (50) end users directly, or (b) to a location that is accessible to more than 50 end users without obtaining an additional license from Crystal Decisions; CRYSTAL DECISIONS AND ITS SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESS, OR IMPLIED, INCLUDING WITHOUT LIMITATION THE WARRANTIES OF MERCHANTABILITY, FIRNESS FOR A PARTICULAR PURPOSE, AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. CRYSTAL DECISIONS AND ITS SUPPLIERS SHALL HAVE NO LIABILITY WHATSOEVER UNDER THIS AGREEMENT OR IN CONNECTION WITH THE SOFTWARE. In this section 3 “Software” means the Crystal Reports software and associated documen-tation supplied by ISS and any updates, additional modules, or additional software provided by Crystal Decisions in connection therewith; it includes Crystal Decisions’ Design Tools, Report Application Server and Runtime Software, but does not include any promotional software of other software products provided in the same package, which shall be governed by the online software license agreements included with such promotional software or software product.

4. Beta License – If ISS is providing Licensee with the Software, security content and related documentation as a part of an alpha or beta test, the following terms of this Section 4 additionally apply and supercede any conflicting provisions herein or any other license agreement accompanying, contained or embedded in the subject Beta Software or any associated documentation. ISS grants to Licensee a nonexclusive, nontransferable, limited license to use the ISS alpha/pro-totype software program, security content, if any, and any related documentation furnished by ISS (“Beta Software”) for Licensee’s evaluation and comment (the “Beta License”) during the Test Period. ISS’ standard test cycle, which may be extended at ISS’ discretion, extends for sixty (60) days, commencing on the date of delivery of the Beta Software (the “Test Period”). Upon expiration of the Test Period or termination of the License, Licensee shall, within thirty (30) days, return to ISS or destroy all copies of the Beta Software, and shall furnish ISS written confirmation of such return or destruction upon request. Licensee will provide ISS information reasonably requested by ISS regarding Licensee’s experiences with the installation and operation of the Beta Software. Licensee agrees that ISS shall have the right to use, in any manner and for any purpose, any information gained as a result of Licensee’s use and evaluation of the Beta Software. Such information shall include but not be limited to changes, modifications and corrections to the Beta Software. Licensee grants to ISS a perpetual, royalty-free, non-exclusive, transferable, sublicensable right and license to use, copy, make derivative works of and distribute any report, test result, suggestion or other item resulting from Licensee’s evaluation of its installation and operation of the Beta Software. If Licensee is ever held or deemed to be the owner of any copyright rights in the Beta Software or any changes, modifications or corrections to the Beta Software, then Licensee hereby irrevocably assigns to ISS all such rights, title and interest and agrees to execute all documents necessary to implement and confirm the letter and intent of this Section. Licensee acknowledges and agrees that the Beta Software (including its existence, nature and specific features) constitute Confidential Information as defined in Section 18. Licensee fur-ther agrees to treat as Confidential Information all feedback, reports, test results, suggestions, and other items resulting from Licensee’s evaluation and testing of the Beta Software as contemplated in this Agreement. With regard to the Beta Software, ISS has no obligation to provide support, maintenance, upgrades, modifications, or new releases. However, ISS agrees to use its reasonable efforts to correct errors in the Beta Software and related documentation within a rea-sonable time, and will provide Licensee with any corrections it makes available to other evaluation participants. The documentation relating to the Beta Software may be in draft form and will, in many cases, be incomplete. Owing to the experimental nature of the Beta Software, Licensee is advised not to rely exclusively on the Beta Software for any reason. LICENSEE AGREES THAT THE BETA SOFTWARE AND RELATED DOCUMENTATION ARE BEING DELIVERED “AS IS” FOR TEST AND EVALUATION PURPOSES ONLY WITHOUT WARRANTIES OF ANY KIND, INCLUDING WITHOUT LIMITATION ANY IMPLIED WAR-RANTY OF NONINFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. LICENSEE ACKNOWLEDGES AND AGREES THAT THE BETA SOFTWARE MAY CONTAIN DEFECTS, PRODUCE ERRONEOUS AND UNINTENDED RESULTS AND MAY AFFECT DATA NETWORK SERVICES AND OTHER MATERIALS OF LICENSEE. LICENSEE’S USE OF THE BETA SOFTWARE IS AT THE SOLE RISK OF LICENSEE. IN NO EVENT WILL ISS BE LIABLE TO LICENSEE OR ANY OTHER PERSON FOR DAMAGES, DIRECT OR INDIRECT, OF ANY NATURE, OR EXPENSES INCURRED BY LICENSEE. LICENSEE’S SOLE AND EXCLUSIVE REMEDY SHALL BE TO TERMINATE THE BETA SOFTWARE LICENSE BY WRITTEN NOTICE TO ISS.

5. Evaluation License - If ISS is providing Licensee with the Software, security content and related documentation on an evaluation trial basis at no cost, such license Term is 30 days from installation, unless a longer period is agreed to in writing by ISS. ISS recommends using Software and security content for evalua-tion in a non-production, test environment. The following terms of this Section 5 additionally apply and supercede any conflicting provisions herein. Licensee agrees to remove or disable the Software and security content from the authorized platform and return the Software, security content and documentation to ISS upon expiration of the evaluation Term unless otherwise agreed by the parties in writing. ISS has no obligation to provide support, maintenance, upgrades, mod-ifications, or new releases to the Software or security content under evaluation. LICENSEE AGREES THAT THE EVALUATION SOFTWARE, SECURITY CON-TENT AND RELATED DOCUMENTATION ARE BEING DELIVERED “AS IS” FOR TEST AND EVALUATION PURPOSES ONLY WITHOUT WARRANTIES OF ANY KIND, INCLUDING WITHOUT LIMITATION ANY IMPLIED WARRANTY OF NONINFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PAR-TICULAR PURPOSE. IN NO EVENT WILL ISS BE LIABLE TO LICENSEE OR ANY OTHER PERSON FOR DAMAGES, DIRECT OR INDIRECT, OF ANY NATURE, OR EXPENSES INCURRED BY LICENSEE. LICENSEE’S SOLE AND EXCLUSIVE REMEDY SHALL BE TO TERMINATE THE EVALUATION LICENSE BY WRITTEN NOTICE TO ISS.

6. Covenants - ISS reserves all intellectual property rights in the Software, security content and Beta Software. Licensee agrees: (i) the Software, security content or Beta Software is owned by ISS and/or its licensors, is a valuable trade secret of ISS, and is protected by copyright laws and international treaty provisions; (ii) to take all reasonable precautions to protect the Software, security content or Beta Software from unauthorized access, disclosure, copying or use; (iii) not to modify, adapt, translate, reverse engineer, decompile, disassemble, or otherwise attempt to discover the source code of the Software, security content or Beta Software; (iv) not to use ISS trademarks; (v) to reproduce all of ISS’ and its licensors’ copyright notices on any copies of the Software, security content or Beta Software; and (vi) not to transfer, lease, assign, sublicense, or distribute the Software, security content or Beta Software or make it available for time-sharing, service bureau, managed services offering, or on-line use.

7. Support and Maintenance – Depending upon what maintenance programs Licensee has purchased, ISS will provide maintenance, during the period for which Licensee has paid the applicable maintenance fees, in accordance with its prevailing Maintenance and Support Policy that is available at http://docu-ments.iss.net/maintenance_policy.pdf. Any supplemental Software code or related materials that ISS provides to Licensee as part of any support and mainte-nance service are to be considered part of the Software and are subject to the terms and conditions of this License, unless otherwise specified.

8. Limited Warranty - The commencement date of this limited warranty is the date on which ISS furnishes to Licensee the license key for the Software. For a period of ninety (90) days after the commencement date or for the Term (whichever is less), ISS warrants that the Software or security content will conform to material operational specifications described in its then current documentation. However, this limited warranty shall not apply unless (i) the Software or security content is installed, implemented, and operated in accordance with all written instructions and documentation supplied by ISS, (ii) Licensee notifies ISS in writing of any nonconformity within the warranty period, and (iii) Licensee has promptly and properly installed all corrections, new versions, and updates made available by ISS to Licensee. Furthermore, this limited warranty shall not apply to nonconformities arising from any of the following: (i) misuse of the Software or security content, (ii) modification of the Software or security content, (iii) failure by Licensee to utilize compatible computer and networking hardware and software, or (iv) interac-tion with software or firmware not provided by ISS. If Licensee timely notifies ISS in writing of any such nonconformity, then ISS shall repair or replace the Soft-ware or security content or, if ISS determines that repair or replacement is impractical, ISS may terminate the applicable licenses and refund the applicable license fees, as the sole and exclusive remedies of Licensee for such nonconformity. THIS WARRANTY GIVES LICENSEE SPECIFIC LEGAL RIGHTS, AND LICENSEE MAY ALSO HAVE OTHER RIGHTS THAT VARY FROM JURISDICTION TO JURISDICTION. ISS DOES NOT WARRANT THAT THE SOFTWARE OR THE SECURITY CONTENT WILL MEET LICENSEE’S REQUIREMENTS, THAT THE OPERATION OF THE SOFTWARE OR SECURITY CONTENT WILL BE UNINTERRUPTED OR ERROR-FREE, OR THAT ALL SOFTWARE OR SECURITY CONTENT ERRORS WILL BE CORRECTED. LICENSEE UNDERSTANDS AND AGREES THAT THE SOFTWARE AND THE SECURITY CONTENT ARE NO GUARANTEE AGAINST UNSOLICITED E-MAILS, UNDESIRABLE INTERNET CONTENT, INTRUSIONS, VIRUSES, TROJAN HORSES, WORMS, TIME BOMBS, CANCELBOTS OR OTHER SIMILAR HARMFUL OR DELETERIOUS PROGRAMMING ROUTINES AFFECTING LICENSEE’S NETWORK, OR THAT ALL SECURITY THREATS AND VULNERA-BILITIES, UNSOLICITED E-MAILS OR UNDESIRABLE INTERNET CONTENT WILL BE DETECTED OR THAT THE PERFORMANCE OF THE SOFTWARE AND SECURITY CONTENT WILL RENDER LICENSEE’S SYSTEMS INVULNERABLE TO SECURITY BREACHES. THE REMEDIES SET OUT IN THIS SECTION 8 ARE THE SOLE AND EXCLUSIVE REMEDIES FOR BREACH OF THIS LIMITED WARRANTY.

9. Warranty Disclaimer - EXCEPT FOR THE LIMITED WARRANTY PROVIDED ABOVE, THE SOFTWARE AND SECURITY CONTENT ARE EACH PROVIDED “AS IS” AND ISS HEREBY DISCLAIMS ALL WARRANTIES, BOTH EXPRESS AND IMPLIED, INCLUDING IMPLIED WARRANTIES RESPECTING MER-CHANTABILITY, TITLE, NONINFRINGEMENT, AND FITNESS FOR A PARTICULAR PURPOSE. LICENSEE EXPRESSLY ACKNOWLEDGES THAT NO REPRESENTATIONS OTHER THAN THOSE CONTAINED IN THIS LICENSE HAVE BEEN MADE REGARDING THE GOODS OR SERVICES TO BE PRO-VIDED HEREUNDER, AND THAT LICENSEE HAS NOT RELIED ON ANY REPRESENTATION NOT EXPRESSLY SET OUT IN THIS LICENSE.

10. Proprietary Rights - ISS represents and warrants that ISS has the authority to license the rights to the Software and security content that are granted herein. ISS shall defend and indemnify Licensee from any final award of costs and damages against Licensee for any actions based on infringement of any U.S. copyright, trade secret, or patent as a result of the use or distribution of a current, unmodified version of the Software and security content, but only if ISS is promptly noti-fied in writing of any such suit or claim, and only if Licensee permits ISS to defend, compromise, or settle same, and only if Licensee provides all available infor-mation and reasonable assistance. The foregoing is the exclusive remedy of Licensee and states the entire liability of ISS with respect to claims of infringement or misappropriation relating to the Software and security content.

11. Limitation of Liability - ISS’ ENTIRE LIABILITY FOR MONETARY DAMAGES ARISING OUT OF THIS LICENSE SHALL BE LIMITED TO THE AMOUNT OF THE LICENSE FEES ACTUALLY PAID BY LICENSEE UNDER THIS LICENSE, PRORATED OVER A THREE-YEAR TERM FROM THE DATE LICENSEE RECEIVED THE SOFTWARE. OR SECURITY CONTENT, AS APPLICABLE, IN NO EVENT SHALL ISS BE LIABLE TO LICENSEE UNDER ANY THEORY INCLUDING CONTRACT AND TORT (INCLUDING NEGLIGENCE AND STRICT PRODUCTS LIABILITY) FOR ANY SPECIAL, PUNITIVE, INDIRECT, INCI-DENTAL OR CONSEQUENTIAL DAMAGES, INCLUDING, BUT NOT LIMITED TO, COSTS OF PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES, DAMAGES FOR LOST PROFITS, LOSS OF DATA, LOSS OF USE, OR COMPUTER HARDWARE MALFUNCTION, EVEN IF ISS HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

12. Termination - Licensee may terminate this License at any time by notifying ISS in writing. All rights granted under this License will terminate immediately, without prior written notice from ISS, at the end of the term of the License, if not perpetual. If Licensee fails to comply with any provisions of this License, ISS may imme-diately terminate this License if such default has not been cured within ten (10) days following written notice of default to Licensee. Upon termination or expira-tion of a license for Software, Licensee shall cease all use of such Software, including Software pre-installed on ISS hardware, and destroy all copies of the Software and associated documentation. Termination of this License shall not relieve Licensee of its obligation to pay all fees incurred prior to such termination and shall not limit either party from pursuing any other remedies available to it.

13. General Provisions - This License, together with the identification of the Software and/or security content, pricing and payment terms stated in the applicable ISS quotation and Licensee purchase order (if applicable) as accepted by ISS, constitute the entire agreement between the parties respecting its subject matter. Standard and other additional terms or conditions contained in any purchase order or similar document are hereby expressly rejected and shall have no force or effect. ISS Software and security content are generally delivered to Customer by supplying Customer with license key data. If Customer has not already down-loaded the Software, security content and documentation, then it is available for download at http://www.iss.net/download/. All ISS hardware with pre-installed Software and any other products not delivered by download are delivered f.o.b. origin. This License will be governed by the substantive laws of the State of Georgia, USA, excluding the application of its conflicts of law rules. This License will not be governed by the United Nations Convention on Contracts for the International Sale of Goods, the application of which is expressly excluded. If any part of this License is found void or unenforceable, it will not affect the validity of the balance of the License, which shall remain valid and enforceable according to its terms. This License may only be modified in writing signed by an autho-rized officer of ISS.

14. Notice to United States Government End Users - Licensee acknowledges that any Software and security content furnished under this License is commercial computer software and any documentation is commercial technical data developed at private expense and is provided with RESTRICTED RIGHTS. Any use, modification, reproduction, display, release, duplication or disclosure of this commercial computer software by the United States Government or its agencies is subject to the terms, conditions and restrictions of this License in accordance with the United States Federal Acquisition Regulations at 48 C.F.R. Section 12.212 and DFAR Subsection 227.7202-3 and Clause 252.227-7015 or applicable subsequent regulations. Contractor/manufacturer is Internet Security Systems, Inc., 6303 Barfield Road, Atlanta, GA 30328, USA.

15. Export and Import Controls; Use Restrictions - Licensee will not transfer, export, or reexport the Software, security content, any related technology, or any direct product of either except in full compliance with the export controls administered by the United States and other countries and any applicable import and use restrictions. Licensee agrees that it will not export or reexport such items to anyone on the U.S. Treasury Department’s list of Specially Designated Nationals or the U.S. Commerce Department’s Denied Persons List or Entity List or such additional lists as may be issued by the U.S. Government from time to time, or to any country to which the United States has embargoed the export of goods (currently Cuba, Iran, Iraq, Libya, North Korea, Sudan and Syria) or for use with chemical or biological weapons, sensitive nuclear end-uses, or missiles. Licensee represents and warrants that it is not located in, under control of, or a national or resident of any such country or on any such list. Many ISS software products include encryption and export outside of the United States or Canada is strictly controlled by U.S. laws and regulations. ISS makes its current export classification information available at http://www.iss.net/export. Please contact ISS’ Sourc-ing and Fulfillment for export questions relating to the Software or security content ([email protected]). Licensee understands that the foregoing obligations are U.S. legal requirements and agrees that they shall survive any term or termination of this License.

16. Authority - Because the Software is designed to test or monitor the security of computer network systems and may disclose or create problems in the operation of the systems tested, Licensee and the persons acting for Licensee represent and warrant that: (a) they are fully authorized by the Licensee and the owners of the computer network for which the Software is licensed to enter into this License and to obtain and operate the Software in order to test and monitor that com-

puter network; (b) the Licensee and the owners of that computer network understand and accept the risks involved; and (c) the Licensee shall procure and use the Software in accordance with all applicable laws, regulations and rules.

17. Disclaimers - Licensee acknowledges that some of the Software and security content is designed to test the security of computer networks and may disclose or create problems in the operation of the systems tested. Licensee further acknowledges that neither the Software nor security content is fault tolerant or designed or intended for use in hazardous environments requiring fail-safe operation, including, but not limited to, aircraft navigation, air traffic control systems, weapon systems, life-support systems, nuclear facilities, or any other applications in which the failure of the Software and security content could lead to death or per-sonal injury, or severe physical or property damage. ISS disclaims any implied warranty of fitness for High Risk Use. Licensee accepts the risk associated with the foregoing disclaimers and hereby waives all rights, remedies, and causes of action against ISS and releases ISS from all liabilities arising therefrom.

18. Confidentiality - “Confidential Information” means all information proprietary to a party or its suppliers that is marked as confidential. Each party acknowledges that during the term of this Agreement, it will be exposed to Confidential Information of the other party. The obligations of the party (“Receiving Party”) which receives Confidential Information of the other party (“Disclosing Party”) with respect to any particular portion of the Disclosing Party’s Confidential Information shall not attach or shall terminate when any of the following occurs: (i) it was in the public domain or generally available to the public at the time of disclosure to the Receiving Party, (ii) it entered the public domain or became generally available to the public through no fault of the Receiving Party subsequent to the time of disclosure to the Receiving Party, (iii) it was or is furnished to the Receiving Party by a third parting having the right to furnish it with no obligation of confidential-ity to the Disclosing Party, or (iv) it was independently developed by the Receiving Party by individuals not having access to the Confidential Information of the Disclosing Party. Each party acknowledges that the use or disclosure of Confidential Information of the Disclosing Party in violation of this License could severely and irreparably damage the economic interests of the Disclosing Party. The Receiving Party agrees not to disclose or use any Confidential Information of the Disclosing Party in violation of this License and to use Confidential Information of the Disclosing Party solely for the purposes of this License. Upon demand by the Disclosing Party and, in any event, upon expiration or termination of this License, the Receiving Party shall return to the Disclosing Party all cop-ies of the Disclosing Party’s Confidential Information in the Receiving Party’s possession or control and destroy all derivatives and other vestiges of the Disclos-ing Party’s Confidential Information obtained or created by the Disclosing Party. All Confidential Information of the Disclosing Party shall remain the exclusive property of the Disclosing Party.

19. Compliance - From time to time, ISS may request Licensee to provide a certification that the Software and security content is being used in accordance with the terms of this License. If so requested, Licensee shall verify its compliance and deliver its certification within forty-five (45) days of the request. The certification shall state Licensee’s compliance or non-compliance, including the extent of any non-compliance. ISS may also, at any time, upon thirty (30) days prior written notice, at its own expense appoint a nationally recognized software use auditor, to whom Licensee has no reasonable objection, to audit and examine use and records at Licensee offices during normal business hours, solely for the purpose of confirming that Licensee’s use of the Software and security content is in compliance with the terms of this License. ISS will use commercially reasonable efforts to have such audit conducted in a manner such that it will not unreason-ably interfere with the normal business operations of Licensee. If such audit should reveal that use of the Software or security content has been expanded beyond the scope of use and/or the number of Authorized Devices or Licensee certifies such non-compliance, ISS shall have the right to charge Licensee the applicable current list prices required to bring Licensee in compliance with its obligations hereunder with respect to its current use of the Software and security content. In addition to the foregoing, ISS may pursue any other rights and remedies it may have at law, in equity or under this License.

20. Data Protection - The data needed to process this transaction will be stored by ISS and may be forwarded to companies affiliated with ISS and possibly to Lic-ensee’s vendor within the framework of processing Licensee’s order. All personal data will be treated confidentially.

Revised March 16, 2004.