main

Book Cover
Cisco Security Agent
By Chad Sullivan
...............................................
Publisher: Cisco Press
Pub Date: June 01, 2005
ISBN: 1-58705-205-9
Pages: 456

Table of Contents | Index
Overview
Prevent security breaches by protecting endpoint systems with Cisco Security Agent (CSA), the Cisco host Intrusion Prevention System Learn the basics of endpoint security and why it is so important in today's security landscape Protect endpoint systems from hackers, viruses, and worms with host intrusion prevention security Prevent "Day-Zero" attacks with the first book on CSA deploymentEndpoint systems, being the point of execution for the malicious code, is where the most effective counter-intrusion mechanisms should be placed. Cisco Security Agent (CSA) is an important part of the network security puzzle that can help organizations secure their end systems. Its many capabilities include preventing "Day Zero" worm attacks, end system virus attacks, and Trojan horses; acting as a distributed firewall; performing an operating system lockdown; and performing application control. With the vast array of features, capabilities, and complexities associated with CSA, users need expert guidance to help them implement and maintain this important new security device and use it to maximum effect. This book presents a detailed explanation of CSA, illustrating the use of the product in a step-by-step fashion.Cisco Security Agent presents a complete view of host intrusion prevention with CSA, including basic concepts, installations, tuning, and monitoring and maintenance. Part I discusses the need for end point security. Part II helps readers understand CSA building blocks. Part III delves into the primary concern of new customers, that being installation. Part IV covers monitoring and reporting issues. Part V covers CSA analysis features. Part VI discusses creating policies and CSA project implementation plans. Maintenance is covered in Part VII.


Table of Contents

Book Cover
Cisco Security Agent
By Chad Sullivan
...............................................
Publisher: Cisco Press
Pub Date: June 01, 2005
ISBN: 1-58705-205-9
Pages: 456

Table of Contents | Index

Copyright
About the Author
 | About the Technical Reviewers
Acknowledgments
This Book Is Safari Enabled
Foreword
 | Command Syntax Conventions
Introduction
 | Who Should Read This Book?
 | How This Book Is Organized
Part I. The Need for Endpoint Security
 | Chapter 1. Introducing Endpoint Security
 |  | The Early Days: Viruses and Worms
 |  | The Present: Blended Threats
 |  | The Insider
 |  | Understanding Point Security Weaknesses
 |  | Using Attack-Detection Methods
 |  | Establishing a Security Policy
 |  | Summary
 | Chapter 2. Introducing the Cisco Security Agent
 |  | Intrusion Prevention and Intrusion Detection Technologies
 |  | The Life Cycle of an Attack
 |  | CSA Capabilities
 |  | CSA Components Overview
 |  | CSA Communication
 |  | CSA's Role Within SAFE
 |  | Summary
Part II. Understanding the CSA Building Blocks
 | Chapter 3. Understanding CSA Groups and Hosts
 |  | The Relationship Between Groups and Hosts
 |  | Understanding CSA Groups
 |  | Understanding CSA Hosts
 |  | Summary
 | Chapter 4. Understanding CSA Policies, Modules, and Rules
 |  | The Relationship Between Policies, Modules, and Rules
 |  | Establishing Acceptable Use Documents and Security Policies
 |  | CSA Rules
 |  | CSA Rule Modules
 |  | CSA Policies
 |  | Summary
 | Chapter 5. Understanding Application Classes and Variables
 |  | Using Application Classes
 |  | Introducing Variables
 |  | Summary
Part III. CSA Agent Installation and Local Agent Use
 | Chapter 6. Understanding CSA Components and Installation
 |  | General CSA Agent Components Overview
 |  | CSA Installation Requirements
 |  | Agent Kits
 |  | Summary
 | Chapter 7. Using the CSA User Interface
 |  | Windows Agent Interface
 |  | Linux Agent Interface
 |  | Solaris Agent Interface
 |  | Summary
Part IV. Monitoring and Reporting
 | Chapter 8. Monitoring CSA Events
 |  | Status Summary
 |  | Event Log
 |  | Event Monitor
 |  | Event Log Management
 |  | Event Sets
 |  | Alerts
 |  | Summary
 | Chapter 9. Using CSA MC Reports
 |  | Audit Trail Reporting
 |  | Event Reporting
 |  | Group Detail Reporting
 |  | Host Detail Reporting
 |  | Policy Detail Reporting
 |  | Report Viewing
 |  | Creating a Sample Report
 |  | Summary
Part V. Analyzing CSA
 | Chapter 10. Application Deployment Investigation
 |  | Using Application Deployment Investigation
 |  | Using Application Deployment Reports
 |  | Summary
 | Chapter 11. Application Behavior Analysis
 |  | Understanding Application Behavior Investigation Components
 |  | Configuring Application Behavior Investigation
 |  | Using Application Behavior Investigation on the Remote Agent
 |  | Analyzing Log Data
 |  | Viewing Behavior Reports
 |  | Exporting the Behavior Analysis Report Data
 |  | Analyzing UNIX Application Behavior
 |  | Creating Behavior Analysis Rule Modules
 |  | Summary
Part VI. Creating Policy, Implementing CSA, and Maintaining the CSA MC
 | Chapter 12. Creating and Tuning Policy
 |  | Creating Policy
 |  | Tuning Policy
 |  | Summary
 | Chapter 13. Developing a CSA Project Implementation Plan
 |  | Planning for Success
 |  | The Project Plan
 |  | Outlining the Project Phases
 |  | Summary
 | Chapter 14. CSA MC Administration and Maintenance
 |  | CSA Licensing
 |  | CSA MC Registration Control
 |  | CSA MC Component Sharing
 |  | CSA MC Role-Based Access Control
 |  | Other CSA MC Administrative Features
 |  | CSA MC Backup and Restore Procedures
 |  | Summary
Part VII. Appendixes
 | Appendix A. VMS and CSA MC 4.5 Installation
 |  | VMS v2.3 Components
 |  | Installation
 |  | Summary
 | Appendix B. Security Monitor Integration
 |  | Adding the CSA MC to the Security Monitor
 |  | Configuring the Security Monitor
 |  | Verifying Connectivity
 |  | Viewing Events in the Security Monitor
 |  | Summary
 | Appendix C. CSA MIB
 |  | CSA MC MIB Definitions
Index


Copyright

Copyright © 2005 Cisco Systems, Inc.

Published by

Cisco Press
800 East 96th Street
Indianapolis, IN 46240 USA

All rights reserved. No part of this book may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording, or by any information storage and retrieval system, without written permission from the publisher, except for the inclusion of brief quotations in a review.

Printed in the United States of America 1 2 3 4 5 6 7 8 9 0

First Printing June 2005

Library of Congress Cataloging-in-Publication Number: 2004106254

Warning and Disclaimer

This book is designed to provide information about Cisco Security Agent. Every effort has been made to make this book as complete and as accurate as possible, but no warranty or fitness is implied.

The information is provided on an "as is" basis. The author, Cisco Press, and Cisco Systems, Inc., shall have neither liability nor responsibility to any person or entity with respect to any loss or damages arising from the information contained in this book or from the use of the discs or programs that may accompany it.

The opinions expressed in this book belong to the author and are not necessarily those of Cisco Systems, Inc.

Trademark Acknowledgments

All terms mentioned in this book that are known to be trademarks or service marks have been appropriately capitalized. Cisco Press or Cisco Systems, Inc., cannot attest to the accuracy of this information. Use of a term in this book should not be regarded as affecting the validity of any trademark or service mark.

Corporate and Government Sales

Cisco Press offers excellent discounts on this book when ordered in quantity for bulk purchases or special sales.

For more information please contact: U.S. Corporate and Government Sales 1-800-382-3419
corpsales@pearsontechgroup.com
For sales outside the U.S. please contact: International Sales international@pearsoned.com

Feedback Information

At Cisco Press, our goal is to create in-depth technical books of the highest quality and value. Each book is crafted with care and precision, undergoing rigorous development that involves the unique expertise of members from the professional technical community.

Readers feedback is a natural continuation of this process. If you have any comments regarding how we could improve the quality of this book, or otherwise alter it to better suit your needs, you can contact us through e-mail at feedback@ciscopress.com. Please make sure to include the book title and ISBN in your message.

We greatly appreciate your assistance.

Credits

Publisher | John Wait
Editor-in-Chief | John Kane
Executive Editor | Brett Bartow
Cisco Representative | Anthony Wolfenden
Cisco Press Program Manager | Nannette M. Noble
Production Manager | Patrick Kanouse
Acquisitions Editor | Michelle Grandin
Development Editor | Dayna Isley
Copy Editor and Indexer | Keith Cline
Technical Editors | Jeff Asher and David Marsh
Team Coordinator | Tammi Barnett
Cover Designer | Louisa Adair
Composition | Interactive Composition Corporation

Corporate Headquarters
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706
USA
www.Cisco.com
Tel: 408 526-4000
800 553-NETS (6387)
Fax: 408 526-4100

European Headquarters
Cisco Systems International BV
Haarlerbergpark
Haarlerbergweg 13-19
1101 CH Amsterdam
The Netherlands
www-europe.cisco.com
Tel: 31 0 20 357 1000
Fax: 31 0 20 357 1100

Americas Headquarters
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706
USA
www.cisco.com
Tel: 408 526-7660
Fax: 408 527-0883

Asia Pacific Headquarters
Cisco Systems, Inc.
Capital Tower
168 Robinson Road
#22-01 to #29-01
Singapore 068912
www.cisco.com
Tel: +65 6317 7777
Fax: +65 6317 7799

Cisco Systems has more than 200 offices in the following countries and regions. Addresses, phone numbers, and fax numbers are listed on the Cisco.com Web site at www.cisco.com/go/offices.

Argentina • Australia • Austria • Belgium • Brazil • Bulgaria • Canada • Chile • China PRC • Colombia • Costa Rica • Croatia • Czech Republic • Denmark • Dubai, UAE • Finland • France • Germany • Greece • Hong Kong SAR • Hungary • India • Indonesia • Ireland • Israel • Italy • Japan • Korea • Luxembourg • Malaysia • Mexico • The Netherlands • New Zealand • Norway • Peru • Philippines • Poland • Portugal • Puerto Rico • Romania • Russia • Saudi Arabia • Scotland • Singapore • Slovakia • Slovenia • South Africa • Spain • Sweden • Switzerland • Taiwan • Thailand • Turkey • Ukraine • United Kingdom • United States • Venezuela • Vietnam • Zimbabwe

Copyright © 2003 Cisco Systems, Inc. All rights reserved. CCffi, CCSP, the Cisco Arrow logo, the Cisco Powered Network mark, the Cisco Systems Verified logo, Cisco Unity, Follow Me Browsing, FormShare, iQ Net Readiness Scorecard, Networking Academy, and ScriptShare are trademarks of Cisco Systems, Inc.; Changing the Way We Work, Live, Play, and Learn, The Fastest Way to Increase Your Internet Quotient, and iQuick Study are service marks of Cisco Systems, Inc.; and Aironet, ASIST, BPX, Catalyst, CCDA, CCDP, CCffi, CCNA, CCNP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, the Cisco IOS logo, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Empowering the Internet Generation, Enterprise/Solver, EtherChannel, EtherSwitch, Fast Step, GigaStack, Internet Quotient, IOS, IP/TV, iQ Expertise, the iQ logo, LightStream, MGX, MICA, the Networkers logo, Network Registrar, Packet, PIX, Post-Routing, Pre-Routing, RateMUX, Registrar, SlideCast, SMARTnet, Strata View Plus, Stratm, SwitchProbe, TeleRouter, TransPath, and VCO are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the U.S. and certain other countries.

All other trademarks mentioned in this document or Web site are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (0303R)

Printed in the USA

Dedications

This book is dedicated . . .

To my wife Jennifer for her patience and encouragement.

To my three little angels—Avery, Brielle, and Celine—for their amazing ability to learn and their continuous challenge for me to do the same.

And to God, for providing me the ability to identify the many opportunities to succeed that have crossed my path.


About the Author

Chad Sullivan is a consulting systems engineer for Cisco Systems based out of Atlanta who specializes in security on the Advanced Technologies Team. He is highly certified and currently holds three CCIEs (Security, Routing & Switching, and SNA/IP), Cisco CCSP, and Cisco INFOSEC, as well as a CISSP and CHSP from ISC2. Chad has focused predominantly on security as a specialty for a number of years and has been a member of the Cisco Security and VPN Virtual Team for the past five years as well as a member of several security professional societies.


About the Technical Reviewers

Jeff Asher is a network systems engineer/security engineering practice manager at Internetwork Engineering in Charlotte, North Carolina, where he is currently deploying endpoint security systems to an enterprise network of more than 6000 workstations and 350 servers. Jeff has earned several certifications, including Microsoft Certified System Engineer and CCNP. He earned a bachelor of arts degree from Virginia Polytechnic Institute and State University.

David Marsh is a security consultant for the Cisco Systems World Wide Security Practice and lives in Atlanta. He has focused on security for a number of years and holds Cisco certifications such as CCNP, CCDP, and CCSP as well as industry certifications such as CISSP, MCNE, and MCSE. David has an MBA from Georgia State University and is looking at pursuing the GIAC GSE after he wraps up his CCIE (Security). He is currently engaged in security architecture consulting for some of the top Cisco customers and has no spare time.


Acknowledgments

I first want to thank Debra Malver, who constantly provided any and all information and assistance I required. I want to thank everyone at Cisco Press who was involved in the creation of this book, including Michelle Grandin, Brett Bartow, Dayna Isley, and Tammi Barnett. (I cannot say thank you enough to Dayna Isley, who has shaped this book more than anyone will ever know.) Special thanks to David Marsh and Jeff Asher for reviewing the content of the manuscript and ensuring its accuracy. Also, to David Marsh, thanks for his friendship and for constantly challenging me to think differently. To the driving forces of the "Dream Team" for continuing to challenge me to drive harder, faster, and further that I believed possible, including Tyler Pomerhn, Mike Purcell, and Mason Harris. To Dave Swink for his practical CSA insight and implementation guidance. To Lamar Tulley and Seth Judd, who are more the same than they realize. To Tyler Durden for providing an escape when it was needed. To all of my Cisco coworkers, who have had to listen to my rants regarding the trials and tribulations during my writing cycle, including Joe Stinson, Steve Gyurindak, John Dodson, Jamey Heary, Paul Ostrowski, and anyone and everyone else who has crossed my path during the past year. To Jeff Wells, who played a great role in the early stages of this book s development and in shaping Chapter 1. To the Cisco CSA Team, including Ted Doty, Jeff Mitchell, Marcus Gavel, Johnathan Hogue, and Josh Huston for providing assistance when needed, both directly and indirectly. To a friend and former manager, Dan Zatyko, who helped shape my career in more ways than he may know. To my mother and father for believing in my potential and keeping me focused even when I pushed it away. To my sister, Ashley, who drives me to succeed in competition to her continued success. To my in-laws, Royce and Phyllis Lynn, for providing spiritual guidance. To Kevin Mahler for helping me to understand the writing process and for providing many needed contacts to further my career. And finally, to the Academy . . . (The music plays, and I am ushered off stage.)


This Book Is Safari Enabled

The Safari® Enabled icon on the cover of your favorite technology book means the book is available through Safari Bookshelf. When you buy this book, you get free access to the online edition for 45 days.

Safari Bookshelf is an electronic reference library that lets you easily search thousands of technical books, find code samples, download chapters, and access technical information whenever and wherever you need it.

To gain 45-day Safari Enabled access to this book:

  • Go to http://www.ciscopress.com/safarienabled

  • Complete the brief registration form

  • Enter the coupon code 1111-1111-1111-1111-1111

If you have difficulty registering on Safari Bookshelf or accessing the online edition, please e-mail customer-service@safaribooksonline.com.


Foreword

I encountered computer and network security very early in my career. My first job out of college in the early 1980s was with the National Security Agency, and two things immediately became clear. First, the government—and especially the Defense Department—were about the only people who were remotely interested in computer security. Second, there were a lot of ways that security could go wrong.

Some things have changed dramatically since then. Everyone is aware of computer security issues to some degree now, even if this awareness is only about viruses and spyware. It is both gratifying and concerning to now be able to explain my job to my mother in 10 seconds ("You know the hackers? We re trying to stop them").

However, some things have not changed much, if at all—there are still a lot of ways that security can go wrong. We ve tried many approaches to stopping attacks, but most of these have struggled to keep up with the rate of change in technology. When we block ports, applications use port 80 (web). When we inspect the packets, the applications use SSL. The rate of change is accelerating, and since attacks can fit themselves into any of these nooks and crannies, it remains easy to miss something.

This was why the Okena Stormwatch agent (now the Cisco Security Agent [CSA]) is such a shock to people who have been involved in security for a long time. In many ways, it seems to violate everything that we ve learned about how to protect your systems. No, you don t need to update it to get the latest protection. Yes, your applications very well may be vulnerable, but CSA will keep them from being exploited. Yes, it will indeed stop an attack that it s never seen before. In a sense, one of the hardest things about CSA is the mental shift from what we have been used to.

However, once that shift happens, the current hustle and bustle of our lives—getting the update, testing the update, looking at the new exploit—becomes much simpler. While there are still a lot of ways that security can go wrong, CSA provides a defense even when something is wrong. I remember the e-mail that came around from our system administrator that said, "There s something attacking our web server. We re not sure what it is, but Stormwatch is blocking it." That was the Nimda worm—the first of a long line of attacks stopped by CSA.

This book provides great detail on how to use CSA, but also provides background on how CSA works. Anyone interested in CSA, and especially anyone who uses it day to day, will find this book to be indispensable.

Ted Doty
Product Manage
Security Technology Group
Cisco Systems, Inc.
May 2005


Command Syntax Conventions

The conventions used to present command syntax in this book are the same conventions used in the IOS Command Reference. The Command Reference describes these conventions as follows:

  • Boldface indicates commands and keywords that are entered literally as shown.

  • Italics indicate arguments for which you supply actual values.

  • Vertical bars ( | ) separate alternative, mutually exclusive elements.

  • Square brackets [ ] indicate optional elements.

  • Braces {} indicate a required choice.

  • Braces within brackets [{}] indicate a required choice within an optional element.


Introduction

Endpoint protection has quickly become a "must have" rather than a "nice to have" security mechanism in today s fast-paced world. Numerous worms, viruses, Trojan horses, bots, and other security malware circulate and grow on the Internet at an alarming rate, and you need to counter these effectively with appropriate technologies. The endpoint, being the point of execution for the malicious code, is where you should place the most effective counter mechanisms. This reality has prompted the industry to understand the need for such software to be developed. The Cisco Security Agent (CSA) software provides the protection necessary to combat these threats. Viruses and worms are no longer simply viewed as a nuisance, but rather as theft and vandalism. The threats are real, and the protective mechanisms required need to be more robust than those used previously.


Who Should Read This Book?

This book is designed to enable readers to discover the CSA product with or without having a running product in front of them. This book first introduces the architecture and components of the system and then examines the configuration of rules and policy. Anyone who is investigating the CSA product or endpoint protection in general will gain insight into the product from this book. Those involved in a production rollout will find the information contained herein a valuable ongoing reference.


How This Book Is Organized

This book is structured to allow the reader to proceed from cover to cover in a natural learning and discovery process. The book is organized into 7 major sections composed of 14 chapters and 3 appendixes.

  • Part I "The Need for Endpoint Security," covers the basics of why endpoint security is so important to today s rapidly changing security landscape.

    • Chapter 1, "Introducing Endpoint Security," discusses endpoint security and the need for this technology.

    • Chapter 2, "Introducing the Cisco Security Agent," discusses CSA and the security mechanisms that can be deployed as protection for a computing environment.

  • Part II, "Understanding the CSA Building Blocks," covers the basic components you must thoroughly understand when attempting to deploy the CSA architecture.

    • Chapter 3, "Understanding CSA Groups and Hosts," discusses using groups and hosts in the CSA architecture and how the two components are related.

    • Chapter 4, "Understanding CSA Policies, Modules, and Rules," describes the components necessary to build and manipulate policy for the systems you want to protect. These building blocks are broken down into individual rules so that you can better understand what control mechanisms are available and how to use them.

    • Chapter 5, "Understanding Application Classes and Variables," discusses some of the CSA objects that simplify ongoing maintenance and usability of the software through the use of reusable elements.

  • Part III, "CSA Agent Installation and Local Agent Use," covers the agents themselves, how you can implement them, and how the user can interact with the agent locally.

    • Chapter 6, "Understanding CSA Components and Installation," discusses the local agent components and installation process on various operating system platforms.

    • Chapter 7, "Using the CSA User Interface," discusses how users should use the local agent interface that may be available to them as defined by the central security policy.

  • Part IV, "Monitoring and Reporting," covers the CSA Management Console s reporting and monitoring capabilites.

    • Chapter 8, "Monitoring CSA Events," explores the event database on the management server and how you can view and filter the information.

    • Chapter 9, "Using CSA MC Reports," discusses the report mechanisms available to the CSA administrator. These reports provide detailed information for the CSA architecture components.

  • Part V, "Analyzing CSA," covers the advanced CSA analysis features added in the 4.5 version of the product.

    • Chapter 10, "Application Deployment Investigation," explores the new Application Deployment Investigation feature capable of providing reports regarding all installed applications, hotfixes, service packs, and applications connecting to the network as a client or server.

    • Chapter 11, "Application Behavior Analysis," discusses the new capability of the CSA agent to collect detailed information regarding a specific process and how it uses and is used by system resources.

  • Part VI, "Creating Policy, Implementing CSA, and Maintaining the CSA MC," covers policy as a whole comprised of the various building blocks and a methodology that the company should follow when attempting to implement CSA. You also learn about information required to keep a CSA deployment running efficiently and how to provide the necessary level of backup required in case of a system failure

    • Chapter 12, "Creating and Tuning Policy," examines the methods used to tune policy such that it controls your environment without impacting usability.

    • Chapter 13, "Developing a CSA Project Implementation Plan," lays out a detailed implementation plan that takes you through the various stages and steps of a CSA deployment.

    • Chapter 14, "CSA MC Administration and Maintenance," discusses administering and maintaining the CSA architecture, including administrative access roles and backups.

  • Part VII, "Appendixes," covers additional installation and management information.

    • Appendix A, "VMS and CSA MC 4.5 Installation,"discusses basic single-server installation of the CiscoWorks VMS product along with the CSA MC.

    • Appendix B, "Security Monitor Integration,"discusses integrating the CSA MC with the Security Monitor component of CiscoWorks VMS.

    • Appendix C, "CSA MIB,"introduces the CSA MIB that can be used with various SNMP management systems.


Part I: The Need for Endpoint Security

Chapter 1 Introducing Endpoint Security

Chapter 2 Introducing the Cisco Security Agent


Chapter 1. Introducing Endpoint Security

This chapter covers the following topics:

  • The early days: viruses and worms

  • The present: blended threats

  • The insider

  • Understanding point security weaknesses

  • Using attack-detection methods

  • Establishing a security policy

Computer viruses, worms, and spyware have changed the face of computing over its long history. In just the past few years, the world has witnessed an acceleration of the number of exploits released and the number of endpoints that can be compromised in a given time. These damaging trends have caused the networking community to renew their focus on security.

The new exploits and rapid propagation techniques seen today are not the only reasons security is pushing to the top of many organizations list of concerns. Changes in the world s political landscape, the ever-growing concern of corporate espionage, cyber-attacks or cyber-warfare, and the dramatic increase in identity theft are all driving this new security awareness.

In this chapter, you explore the evolution and general effect of viruses, worms, and spyware along with a view to where they may be heading. In addition, you learn about other important security issues on the endpoint.


The Early Days: Viruses and Worms

This section explores the initiation and evolution of the automated attack against computing infrastructures, including early virus and worm behavior and the drivers shaping these behaviors.

Virus Emergence and Early Propagation Methods

The concept of the computer worm or virus is not new. Those who created early computing machines conceived of malicious code or data nearly concurrently with their hardware discoveries. Early researchers used such code in elaborate games such as Core Wars in attempts to learn more about computing and how unexpected interaction between processes affects the computing environment.

The computer virus really started to have an effect at the onset of early business and consumer networking. In the mid-1980s, networking was likely to be done via sneakernet, the term for using floppy disks to move computer programs and data from machine to machine. The earliest examples of widespread computer viruses utilized this method to propagate themselves. Often, the virus would reside in the boot sector of the floppy disk or attach itself to executable files. When users then moved that disk to another machine and tried to boot from it or run executables on it, the virus copied itself into memory and waited to jump on the next clean boot sector or executable encountered. Although this form of propagation may today seem slow and primitive, it was remarkably effective. Note that this class of malicious tools was effective because it utilized the behavior of the attacked system itself as a weapon.

Viruses mutate and evolve to match their environment and to take advantage of new infection vectors. Those who write the viruses drive this mutation and evolution in the interest of getting the greatest possible impact. The first viruses were effective precisely because of the way computers operated and the way people interacted with them. The viruses took advantage of the following facts:

  • PCs booted via floppy disks, which provided boot sector viruses fertile ground for reproduction.

  • Floppy disks often contained application code and data along with boot code, which application viruses easily infected.

  • People regularly shared floppy disks as a convenient way to exchange information, which enabled these early viruses to proliferate.

In addition to their simple spreading behavior, viruses often contained some sort of pay-load. Payload is a common term used to describe what is being delivered to the targeted destination; in this case, the payload was malicious and destructive code along with some identifying information. The virus payload is what usually made the virus famous and often led to the name of the virus in question. Some viruses did nothing more than place an occasional message on the user s screen. Others might jumble keystrokes occasionally. Truly nasty viruses deleted files or destroyed the boot sector itself. Often, these viruses remained inactive within the executable files and in the computer s memory until a particular trigger date that would activate the malicious virus.

Throughout the late 1980s until the present, those who write malicious code have taken advantage of the increasingly well-connected nature of machines, operating systems, and applications, and their code has mutated and evolved accordingly. A thorough understanding of the inherent behavior of the target system is crucial to the creation of successful virus code—crucial in fact to any attack against a particular system. To defend a system, you must have this same understanding of system behavior, architecture, and communication.

LAN Propagation

The advent of the LAN provided the traditional virus with new propagation opportunities. These networks removed the floppy disk and human mobility requirement and replaced them with much faster electrons moving through copper wire. With such systems, files and applications are shared with speeds orders of magnitude greater than with sneakernet.

With the introduction of LANs, viruses at first stuck to their old method of operating and continued to propagate, at much higher rates, through infected application files. The problem was compounded by the fact that LANs usually contain one or more file servers, which are devices that act as central repositories for user files and facilitate file sharing. If a virus infected an executable in this environment, it often was not long before the entire server s complement of user executable files was likewise infected.

The WAN and Internet

After the emergence of the LAN in business computing, business soon realized the productivity gains possible by joining the LANs of their own branches and those of their partners and customers across geographically dispersed areas. This new "super network" is called a WAN. A WAN provides the virus with an even more vast and extended network and gives an infected business the dubious honor of being able to spread their infection to their partners or customers.

With the emergence of the Internet as a valuable business tool, all of these LANs and WANs at thousands of businesses around the world had the potential to be joined, creating the "network of networks." Rapidly realized on a global scale, this convergence represents the terminal opportunity for virus code because of the great potential for sharing infected files and creates a new kind of vulnerable system. That system is the entire Internet itself.

The Network Worm

Writers of malicious code soon realized they could build a new type of attack, one that would be independent of executable files and would instead attack systems themselves via their network connection. This new attack, called a network worm, was automatic and usually did not rely on a user s interaction for infection of a vulnerable system to occur. As a result, this approach is a far more rapid and advanced method of spreading malicious code than the virus and one that takes advantage of the architecture and behavior of the large network.

Like the virus, the worm may contain and carry a malicious payload. Curiously (and luckily) few worms have done so. Most worms have caused damage due to denial of service (DoS) that results from their rapid propagation. The worm s ability to use all local CPU and network resources on the infected machine often renders them unusable.

The first known instance of a widespread network worm attack was the Morris worm of the late 1980s. This worm attacked machines connected to local networks and the Internet via the IP protocol suite. At the time of the Morris worm, the Internet was a loose affiliation of universities, government entities, and a handful of forward-looking high-tech businesses. Because of the ubiquity of certain operating systems on the Internet at the time, the Morris worm rapidly infected a considerable percentage of available hosts and, because of its propagation method, swamped CPU and communication resources on the infected machine, causing such machines to become unusable. It is generally accepted that the creator of this worm was performing research rather than attempting to cause trouble, but the damage done was considerable. The whole tech world was suddenly awakened to this new and alarming threat.

The Single Environment and Its Consequences

The success of a worm or virus depends heavily on the prevalence of the target system or application in the environment under attack. The Morris worm was powerful because many machines were connected and running a limited set of software possibilities. The worm easily could discover new vulnerable hosts for infection. As each new host became infected, that host in turn found many "neighbor" machines to infect.

Over the past decade, the Microsoft Windows environment has become the computing platform of choice for most of the world s PC users, business or individual. As a result, nearly 90 percent of the machines connected to the Internet are of the same general type and run the same basic networking, operating system, and application code. Although this commonality fosters productivity for connected users because of the ease of sharing, worms also benefit from such an environment and are easily "shared." A single-vendor computing environment fully interconnected with high-speed data links is fertile ground for aggressive malicious code. Combining today s interconnected high-speed networks such as Ethernet LANs, optical WANs, and always-on home Internet connections (cable modems and DSL) with interconnected machines operated by identical software presents easy targets to the network worm or virus.


The Present: Blended Threats

Just as computers have become more complex and efficient with new productivity features, so have security threats become complex and efficient. Just about any feature you have come to love over time can be exploited and used against you or others if not appropriately implemented and correctly secured. To help illustrate this concept, you need look no further than your favorite e-mail program. If someone releases an exploit that compromises a system running a vulnerable e-mail application, the exploit may inappropriately send unauthorized e-mails containing a virus to everyone in the local address book. These e-mails appear to come from the local user s address; therefore, they have a much better chance of compromising the receiver s machine because the receiver believes the e-mail was sent by a trusted source, such as a colleague, friend, or family member.

Blended threats combine propagation mechanisms, exploits, persistence, and damaging payloads. In the past, each of these pieces would need to be manually executed in the proper sequence to fully "own" a system. Today, these pieces are bundled together to automatically execute at the appropriate time. The fact that they are bundled together into simple-to-launch executables makes anyone with a computer a potential script kiddie. Script kiddies are individuals who are incapable of developing malicious code but instead use the available tools to attack systems. Although not necessarily the most dangerous individuals, script kiddies are by far the most common and pose a very large threat simply due to the number of attacks they can generate with little or no knowledge of what they are doing. In most cases, they are not attempting to gain access to a specific system but rather are seeking to gain access to any system.

Blended threats can be very damaging in a very short period of time. The next sections look at some of the features of a blended threat that make this automated system so damaging.

Delivery and Propagation Mechanisms

For a blended threat to compromise many machines in a short period of time, it needs to be transmitted machine to machine very quickly. Today, the most likely way for such a tool to propagate is via the IP protocol using some specific TCP or UDP Layer 4 communication. You have witnessed in recent years many different protocol paths between hosts, but the most common method of automatic threat propagation continues to be e-mail, Microsoft Windows Distributed Component Object Model (DCOM) and Remote Procedure Call (RPC) communication protocols, and automatically downloaded content received from web pages using HTTP or HTTPS while surfing the Internet.

Another important piece of the typical blended threat is the built-in scanning mechanism. Via scanning mechanisms, such as port scans and ping sweeps, the blended threat attempts to locate other vulnerable systems from the vantage point of the already compromised machine. Regardless of the way a compromised host searches for targets, after they are located the blended threat moves on to the second phase of its attack: exploitation.

The Bundled Exploit

A propagating blended threat needs to locate vulnerable systems to compromise. A vulnerability is a security hole in a system s code or configuration that can be compromised via an exploit. This vulnerability can be just about anywhere software is running, such as part of an operating system, a script on an application server, a protocol stack, or an end user s application.

An exploit is the method, software, script, shell code, and so on that is used to compromise a system vulnerability to gain unauthorized control of or access to the system s resources. Some exploits may automatically compromise an endpoint through a known or unknown vulnerability (you learn more about unknown or day-zero attacks in Chapter 2, "Introducing the Cisco Security Agent") such as a buffer overflow with injected shell code. Other methods may require a user to open and execute the infected file to be successful in gaining access or rights to a system. Who would do such a thing? Unfortunately, many people with myriad motivations. Hackers, those who write exploit code, have become very creative over time and have employed many and varied ways of tricking computer users into executing their malicious code. An example of this is to send an e-mail to an individual with an attachment that appears to be a website, such as www.company.com, but is actually a COM file that causes undesirable effects when executed by the host operating system. In any case, after the exploit has gained unauthorized and unapproved access and rights, the blended threat can then repropagate to other systems and may also attempt persistence on the endpoint.

Persistence

After the hacker has penetrated the system and the hacker s tool has moved on to attempting to locate other systems from its new vantage point, the typical blended threat attempts to become persistent on the endpoint such that any basic attempt to clean or stop the virus or worm will only be temporarily successful. Often either the next reboot or some other restart mechanism allows the virus to maintain its nefarious hold on the infected system. There are many ways for a program to auto-start itself. Among others, these methods include the following:

  • Inserting into the Windows system registry Run or RunOnce keys

  • Inserting into the Windows Startup group

  • Inserting into startup scripts or initialization files of Windows or UNIX systems

  • Registering itself as a Windows service

  • Replacing or editing a file or service that already has access to the system using common Trojan methods

  • Creating or modifying a cron job on a UNIX system

These are only a few of the many creative persistence methods available. To ensure survival, complex blended threats employ as many of the previous methods as possible. Remember: The goal of any virus, worm, or blended threat is typically to compromise as many systems as possible as quickly as possible; therefore, guaranteeing that the malicious code will restart after being terminated or rebooted is a great way to continue its mission. When the blended threat has propagated and become persistent, it can deliver the final blow to the endpoint that has become its temporary home: paralyzing or destructive behavior.

Paralyzing or Destructive Behavior

After the blended threat has used the compromised system for all it can, it attempts to destroy the end system or at the very least make it unusable. Many security professionals refer to this action as the damaging payload. Some methods to paralyze or destroy an end system are as follows:

  • Delete or modify the NTLDR file or other important system files in specific Microsoft operating systems

  • Remove or modify portions of the Windows registry

  • Delete or modify device files or drivers

  • Create runaway processes to render the local system unusable

  • Randomly write to the local file system to fill up the usable storage or corrupt files

  • Format or otherwise destructively alter the storage systems

Many of today s blended threats have not been truly destructive, but many have paralyzed endpoints. A major concern in the security industry is what will happen when destructive rather than nuisance types of threats become the norm.

The Global Implications

At this point, you see the potential for severe and far-reaching destruction due to these automated attack tools. For example, consider the Slammer worm. Slammer attacked the Microsoft SQL database server engine and gained database administrator privileges before propagating to other systems. Because of its architecture and targets, the Slammer worm propagated extremely rapidly, reaching worldwide in less than half an hour and infecting hundreds of thousands of hosts, many thousands of them representing critical systems for the businesses and governments involved.

Imagine if instead of merely propagating rapidly Slammer had also either deleted database records or files or, even worse, made subtle alterations to the database data administered by the infected SQL management process. Such an attack would have caused untold worldwide destruction and economic chaos and made mitigation of Slammer infections more expensive by an order of magnitude.

What is truly alarming is that there was no way to predict the Slammer attack or prepare for it in a general sense. Available patches and firewall best practices would have limited its spread, but there is no guarantee that today s fix will stop tomorrow s issue. None of the normal security methods used to mitigate attacks takes the behavior of the attacked system into account. As a result, the security community is always chasing the attackers and repairing infected systems rather than stopping them before the attack.

Spyware

Beyond the typical virus and worm, other threats impact many personal home computers and enterprise networks. One of these major threats today is spyware. Spyware is an application that runs on a system and performs undesirable reconnaissance that the system owner is unaware of. In most cases, spyware is loaded much like a Trojan horse. It is commonly hidden in another application that the user intended to install. An example is a program that is installed along with the latest freeware game the user downloaded. Unknown to the user, the game not only installed itself but also installed another application that monitors the users keystrokes watching for usernames and passwords, logs every website visited, can turn on the microphone and webcam attached to the system, and can open the locally installed e-mail application to steal the local address book. All of this information can be transmitted back to a collection point, which the spyware creator harvests from time to time, gathering information about everyone who has installed the freeware game.

Cases of similar spyware that automatically installs as a result of a vulnerability in the common JPEG files used on websites have also occurred. Just viewing a page with an exploited image can cause your system to unwillingly participate in the spyware creator s data-collection system. As you can see, an action as simple as installing a program that was "desired," can cause many "undesired" results, including identity theft or loss of intellectual property.


The Insider

Most of this chapter so far has focused on automated tools such as viruses, worms, and spyware. Because these threats have grabbed the majority of headlines over the past few years, they received the majority of the focus in this introductory material. Viruses, worms, and spyware do not, however, represent the majority of potential security problems on a given infrastructure. In addition to them, there are many others, not the least of which are those caused by the insider.

An insider is a person who has some level of permission on the protected network. Insiders either work for a company and are therefore trusted on its network or are a member of your family at home and are therefore trusted on your home network. They are on the inside. Many security managers focus strongly on outside threats and ignore the real threat of the insider. The insider already has the type of privilege that an outside attacker desires. They are already positioned to steal or do direct damage to an infrastructure.

Some insiders, such as disgruntled employees, cause damage or breaches in security will-fully. Examples of an insider attack include willful destruction of data, data theft, and password theft.

Others, however, with the purest of motivation and believing they have the company s interest at heart, cause damage or breaches by nothing more than ignorance or carelessness.

They may write their passwords down on sticky notes and leave them where others can find them, dispose of confidential information in a nonsecure manner, or unwittingly download Trojan horse files from the Internet that create back doors for hackers.

The network security manager must be just as aware of and vigilant against these insiders as against the outside attacker. These insider issues are far more difficult to detect and prevent than the more well-known and obvious ones. As with the other attacks discussed in this chapter, it is the behavior of the systems under attack that makes them vulnerable.


Understanding Point Security Weaknesses

Point security refers to the security strategy of protecting individual devices or systems with no overall plan or view toward integration of the different tactics employed. This section explores the weakness of this security method by defining point security and illustrating common attacks on the point security approach.

Using Point Security Products

Just a few short years ago, many people believed that securing a network meant adding a firewall to the perimeter and adding passwords to network resources. This simplistic approach proved to be an unsuccessful strategy in securing networks. Attackers began using well-known protocols for transporting their malicious code and causing widespread DoS attacks. Many of these attacks would compromise known vulnerabilities in common application layer protocols such as FTP, TFTP, SMTP, and HTTP. Servers running these particular services are often behind a firewall. However, because firewalls traditionally only limit connections to end systems over desired acceptable ports, coupled with the fact that communication to these services is required from an untrusted network such as the Internet, firewalls cannot stop the hacker from gaining a legitimate connection to the server. If the application server was compromised, the hacker could use it as a jumping point to connect to other systems that would not typically be visible from the outside world.

To combat the inherent problems with firewalls at the time, security administrators began using other techniques to attempt detection of malicious behavior. A device commonly used to accomplish this task is an Intrusion Detection Sensor/System (IDS). By pattern matching sniffed packets using known attack signatures as a baseline, this device proved to be fairly successful in alerting the security team when a known attack was underway.

IDS technology still has its place in network security today, but its reliance on signature definition updates is still its major flaw; however, a great deal of time and effort is being put into making this technology a much more efficient and successful way to defeat both the known and unknown threat, including taking actions specific to the threat encountered. Regardless, when placed at the edge of the network, an IDS can only see what passes by its sensing interface and is therefore commonly still an edge security mechanism (although this is not always the case).

Most typical network security mechanisms—passwords, firewalls, and IDSs—are standalone technologies, known as point security because they individually secure a single point in the network or only cover one point of your security needs. The best designs possible include a combination of each security mechanism mentioned previously as well as additional controls such as Host Intrusion Prevention software and physical security controls.

Candy Shell Security

Many networks around the world have a very similar security issue: The security mechanisms are at the edge attempting to deny access to the network from abroad. These edge security mechanisms do not focus on the internal portion of the network with advanced security products that could protect the endpoints effectively. This issue is known as candy shell security by many security professionals.

Candy shell security refers to a network that has a hard candy shell or strong perimeter security but easily compromised endpoints, which are the soft chewy center in this analogy. If you rely on signature-based technologies such as network IDS and perimeter defenses to protect your most valuable resources, you are guaranteeing a treat for the hackers and blended threats will come knocking on your door.

Backdoor Attack Vectors

Throughout this book, you will learn about many endpoint security vulnerabilities and endpoint-specific infection and exploitation methods common today. Many of these methods are considered back doors because they circumvent candy shell perimeter security measures. One issue perimeter detection methods face today (in addition to relying on signatures) is encryption. E-mailing a virus that is encrypted in a password-protected zip file is a very popular way of slipping a virus past network virus scanners. Encrypted files are not the only problem. Sometimes, the transfer mechanism itself is the issue. Many worms today are beginning to propagate via encrypted protocols such as Secure Sockets Layer (SSL) and Secure Shell (SSH). Network scanners and pattern-matching techniques have no chance to detect a downloaded virus if it is encrypted.

Encrypted communication is very common today, and many organizations have had viruses and worms enter through this communication path. Two different network mechanisms that use this communication path are web page e-mail applications and IPSec VPN. Enterprise users often utilize personal e-mail accounts via web pages that use SSL encryption from corporate computing assets. IPSec VPN tunnels are not as common for the everyday corporate user, but many corporate partners may connect to the enterprise via this mechanism and thereby provide an unsecured path between the two organizations.

Although you may believe that an encrypted stream is the only way malicious code may enter your network, do not forget the old standby known as the sneakernet method of propagation. Today s sneakernet is in some ways even more damaging because it does not rely on floppy disks with limited storage but rather media such as USB keys, CD-Rs, and DVD-Rs. Network security devices cannot detect transported code that is not physically passing through the various security inspection devices located at the perimeter or pervasively throughout the network architecture.


Using Attack-Detection Methods

This section explores some methods of computer network attack detection in use today and attempts to draw conclusions based on their success against well-known attacks and in concert with other common defense strategies.

Signature-Based Attack Detection

A signature in the context of attack detection is a pattern of data that characterizes or defines a particular attack or exploit. Signature-based attack detection relies on a list of known signatures and an engine to compare data either on a network or scanned by a process on a system to this signature list. If a match with a list item is discovered, the matching system generates an alert indicating the match and the expected severity.

Log File Scraping

Log file scraping refers to the act of watching system logs for particular log entry types. The log entries are compared to a list of types that indicate suspicious behavior, much like the signature-based detection. When these particular types are encountered, they are either correlated with other activities on the system or alarmed directly as attack evidence. Note that in this method, the damage is usually done by the time the alarm is generated; therefore, this type of attack detection is called reactive detection.

Application Fingerprinting

Computer applications such as SQL, word processors, and web server programs are composed of one or more executable files and a number of supporting files such as dynamic link libraries (DLLs), object libraries, configuration files, and the like. Some of these files change during the execution of the application program, but many of them, called static files, do not. These static files are usually the core application executable and DLL or object files. One attack-detection method that relies on this fact that static files should never change is called application fingerprinting. Application fingerprinting tools create lists of checksums for each static file in an application suite. A checksum is a unique mathematical result of an operation performed on the static file in question. Periodically, the application fingerprinting tool reruns the checksum generator on each protected file and compares the results with the stored value. A change in the checksum indicates a change in the associated file. Any such change generates an alert. As with the log file scraping method, this is purely reactive: An alarm indicates that the damage has already occurred.

Behavior-Based Attack Detection

Behavior-based or anomaly detection is relatively new in the security realm and holds great promise in attack detection and mitigation. Unfortunately, many companies have latched on to the term as a marketing tool and apply it to tools that do little or no behavior-based detection. This detection method is difficult to write and implement, because the system to be protected must be characterized to a high degree of abstraction and accuracy. After doing so, you must define allowed and questionable behaviors.

The beauty of this system is that it is the first type of attack-detection system that works just as successful attacks do: It takes advantage of the behavior of the system itself to do its job. When you move from the reactive role of checking for damage to the active role of denying damaging behavior, you can finally eliminate many types of threats. Moreover, you eliminate them in a general sense so that you protect your network from tomorrow s threats as well. Anomaly-based security systems represent the sophisticated future of reliable threat detection and mitigation. The Cisco Security Agent (CSA) is an example of a behavior-based security mechanism. Throughout this book, you learn the behavior mechanisms the CSA product uses and the many ways to implement policy to securely control agent-protected systems.

Automation

In nearly every case, those attempting to detect or mitigate security issues should implement an automated detection method. Automation of the detection method rather than manual human-driven multistep processes provides consistency and certainty to the process. Freeing the IT or security staff from mundane and repetitive tasks, the automated system can allow them to instead work on anomalies or focus their talents on more difficult engineering or design issues.


Establishing a Security Policy

Every corporation and organization should have a security policy that outlines the acceptable uses of computing resources and processes that are in place to protect the systems and their included data. Security policies are important because their included specifications allow you to define how the various security mechanisms in your organization are implemented. The next sections discuss the need for security policies.

Understanding the Need for a Security Policy

An organization s security policy may be the single most important document the entity maintains. A security policy is a comprehensive set of rules defining the acceptable use of computing resources. These rules may be related to how devices are physically secured, which individuals are allowed to access specific types of information, types of allowed access into and out of the network, and any other facet that pertains to information security.

The state of the security policy at many organizations is dismal. Policies are either generic, having been downloaded or copied from another company s policy, or poorly written. Because the policy does not match the business, the business needs, and the specific computing environment, it is not completely valid and is often ignored or dismissed as invalid. Some companies have no written policy at all. The reasons for these problems are manifold, one being that written policies are often crafted in the following way:

  1. An IT manager or employee, tired of addressing crises caused by security issues, realizes that a policy is needed. This person tries to create one through the proper channels, but cannot get anyone interested. As a result, the manager or employee searches the web and finds an example policy somewhere, downloads it, fills in some blanks, prints it out, and calls it the company s policy.

  2. This policy is posted on the company s intranet site, and an e-mail is sent to the rest of the company notifying everyone of its existence. There might even be a voicemail announcement.

  3. The IT manager or employee then finds that no one follows the policy and may at first be puzzled, then dismayed, and finally resigned to this fact as more violations of the policy occur. Calls to other departments are met with stonewalling and outright defiance. Management does not back the policy. In the end, the IT department finds itself with a dusty, worthless tome about which no one cares.

What went wrong here? Why did the policy fail? Why is the IT department still running around putting out fires caused by common and repeated security issues?

The answer is that the pile of paper on the IT manager s desk labeled "Security Policy" is not the policy at all, and never was. The company s real security policy is the collected security beliefs of its decision makers. This is a crucial point. Companies with real and effective policy documents realize this fact and attempt to codify these beliefs and then change them where prudent or necessary. An effective policy is a living document, signed and supported by the company s principals and reviewed and modified on a regular basis by a committee representative of the entire organization and its interests.

When an organization has a security policy in place, it can begin to apply the document and its rules to their particular environment. Organizations with truly comprehensive security policies find that what they have created is a roadmap that helps them implement the correct security appliances, mechanisms, and controls that satisfy their particular security needs. The organization will also quickly begin to find the weaknesses in their security posture through the process of identifying important resources and associated policies and tying that information to current inadequate security controls. This documentation is sure to change over time as the computing and physical environments change, which should be expected and accepted as normal security policy maintenance.

Compliance Versus Enforcement

Any security policy—no matter how comprehensive—is only valuable to an organization if compliance with the policy is mandatory and enforceable. The policy or specific portions of the policy document must be clearly explained to the necessary individuals on a need-to-know basis and in some cases acknowledged by signature.

Any action contrary to the policy should have associated disciplinary actions that are non-negotiable, because the desired end result of the document is to provide a secure and consistent computing environment. Although employees are not typically held accountable by laws regarding certain security of information such as personal health information (PHI) and financial information of individuals and organizations, laws such as Sarbanes-Oxley (SOX), California s SB1386, and HIPAA have stipulated both high financial penalties and possible jail time for executive-level personnel found in violation of the various laws. Throughout the remaining portion of this book, you will learn how CSA can help you secure data and protect resources, maintain access to available resources with assurance of data integrity, and enforce your organization s written and accepted security policies.

NOTE

Two great places to locate security policy information are http://www.sans.org and the ISO 17799 document.


Summary

This chapter examined a number of different threats to a typical networked computing environment, and discussed the history of automated threats and the alarming future these threats hold for many individuals and organizations. This chapter asked a repeated question: Is there any reliable, general, and automated way to defend against these threats that takes the behavior of the system and its attacker into account? The remainder of this book focuses on the installation, configuration, and monitoring of the Cisco Security Agent, which provides the solution to these and other security issues facing computing environments today.


Chapter 2. Introducing the Cisco Security Agent

This chapter covers the following topics:

  • Intrusion prevention and intrusion detection technologies

  • The life cycle of an attack

  • CSA capabilities

  • CSA components overview

  • CSA communication

  • CSA's role with SAFE

A common problem security professionals face today is the inability to enforce the written security policies they have meticulously created. The Cisco Security Agent (CSA) provides the solution to that problem. CSA is a distributed security policy enforcement mechanism for today s large networks as well as a day-zero Intrusion Prevention System.

NOTE

Any virus, worm, or malicious code that can impact a system is considered to be day zero if no available patch or signature is available to protect against the code s negative nature.

The CSA product accomplishes this task by enforcing very specific policies on end sys-tems. Mechanisms within the CSA product inspect various operating system operations and resources such as local files, registry operations and entries, COM object access, and inbound and outbound network connections.

When the original CSA developers set out to create a solution for securing endpoints, they wanted to create a new prevention-based system that would rely on a proactive behavioral method rather than try to improve old signature-based Intrusion Detection Systems that rely on more traditional reactive technology. In the past, securing end systems meant employing operating system policies, deploying antivirus solutions, utilizing personal firewalls, and hoping that your user base would adhere to the written acceptable use policies when using enterprise computing resources. Hope should never be part of your strategy when providing secure computing environments.

Although you should continue to develop successful security awareness programs and acceptable use policies, you do not need to trust those policies as your sole method for protecting end systems, nor should it take a small army of security personnel to maintain, monitor, and manage multiple endpoint security products. CSA enables you to enforce your security policies based on explicit rule definitions while reserving "hope" for other parts of your organization. This chapter provides an overview of the concepts and technologies integral to CSA, including the following:

  • The difference between intrusion prevention and intrusion detection

  • The life cycle of an attack

  • CSA capabilities

  • CSA architecture components

  • CSA component communication

  • CSA s role within the Cisco SAFE architecture


Intrusion Prevention and Intrusion Detection Technologies

CSA is a Host Intrusion Prevention System (HIPS). The older technology, which previously attempted to prevent intrusions on network endpoints, is known as a Host Intrusion Detection System (HIDS). This discussion starts by exploring the basics of each type of system.

HIDSs evolved out of Network Intrusion Detection Systems (NIDSs). A NIDS is a security technology deployed on network infrastructures that detects and alerts based on passively identifying active attacks. NIDS is an invaluable technology credited with saving enterprises from having to endure drastic outages due to active hacking attempts or distributed denial-of-service (DDoS) attacks.

The major issue associated with running an effective NIDS is to ensure that this technology is continuously updated with the latest signature definitions such that all currently known attacks are identified and the appropriate alerts are sent. This technology is only as effective as its latest update and the ability to limit the number of false positive alerts being sent.

Combine the large number of false positives with the large number of possible real positive events logged in an ever-growing database, and many security teams find themselves buried in log data they cannot interpret in a timely fashion. Therefore, a more active endpoint technology such as HIDS can complement the NIDS in an enterprise environment to ensure real-time security as well as comprehensive forensics within the logs. HIDSs also function by utilizing signatures to identify and prevent attacks, although they perform this action to secure individual end systems based on their local signature base of known attacks.

A Host Intrusion Prevention System (HIPS) differs significantly in its approach to securing hosts. It actively monitors the behavior of applications, locally executing code and local network connections on the end system to determine whether the actions should be allowed. An obvious benefit to a behavior-based system is that it does not require signature updates to prove successful. To better understand how a behavior-based system such as CSA can be effective in preventing both known and unknown attacks from compromising end systems, it is important to understand what you, as a security expert, are trying to protect.


The Life Cycle of an Attack

Viruses and worms have been around for many years and over time have taken advantage of numerous vulnerabilities in both operating system and application code. Initially, new worms and viruses would show up every few weeks. Over time, this became every few days. Today, new viruses, worms, and variants of existing ones appear every few hours.

Today s programming languages have made it increasingly easy to make minor modifications to existing virus code so that the variant is at least as destructive as the original. Most importantly, the code is modified such that existing virus definitions or signatures no longer match. Because the signature no longer matches the malicious code, the security mechanism utilizing the signature definition is not an effective defense without an update that includes the new signature to match the altered pattern within the malicious code. To take this concept one step further, virus developers today write destructive code that is distributed across the Internet bundled with a developer s kit of sorts, so any individual with malicious intent and the capability to run a command-line executable (complete with built-in help files) can create his own undefined variant in just a few seconds. Armed with this knowledge, you may ask yourself, "How do I efficiently and effectively defend against constantly mutating code in time to protect my environment?"

To address this concern, CSA differs from older technologies. CSA does not care what the virus or worm looks like or how the binary 1s and 0s line themselves up to create a damaging payload. CSA is more focused on the behavior of an application and defining whether the behavior is "good" or "bad" to decide whether the action attempting to occur should be allowed or denied. CSA s internal mechanisms and implementation of the centrally defined rule set decide what is considered good and bad behavior. An example of a behavioral decision could be that a command shell such as cmd.exe is a normal "good" behavior that is allowed on an agent-protected system as long as the command shell is started by a user and not by a process launched by downloaded content.

Looking back over the history of malicious code, a pattern begins to form: All malicious code performs the same root actions. Not all viruses follow the same steps in exactly the same order, but they do attempt to use the following processes to be defined as successful penetrations:

  • Probe— Locate other systems via any method such as ping, traceroute, e-mail, port scans, and so on.

  • Penetrate— Gain access to the previously located or randomly selected systems through mechanisms such as e-mail attachments, downloaded content from web pages, buffer overflows, or even back doors such as the Windows hidden shares (ADMIN$, C$, and so on).

  • Persist— Methods by which the virus/worm will continue to be present on the infected system after deletion or reboot such as insertion into registry Run keys, initialization files, or service installation.

  • Propagate— Move from system to system using transports such as e-mail, Trojan horse-infected files, and other vulnerable network services.

  • Paralyze— Destroy files or entire file systems using various corruption, deletion, or formatting procedures. Other possibilities include simply crashing the system continuously so that it is unusable or tying up CPU cycles to make the system unresponsive to user-desired functions.

You can see that because all viruses and worms behave the same, it can be a more successful strategy to monitor and analyze the behavior of an attack rather than attempting to match it to a signature, which may not yet exist. CSA identifies the code as malicious by its inappropriate interaction with the host system and therefore can prevent previously unknown day-zero attacks.


CSA Capabilities

Because CSA resides on the endpoint and observes all system interaction, it can be very effective in securing the endpoint, controlling how the endpoint interacts with surrounding systems, and controlling how users can interact with the local system. Upon installation, CSA begins monitoring local system resources and maintains state tables of what is happening on the system so that the locally enforced security policy is not violated. The agent monitors file and application access and usage, network transactions, registry access, operating system kernel usage, COM object access, and other system components to ensure the strict enforcement of the defined security policy.

Because of its intimate knowledge of what is happening in real time on the local host, the CSA can control what requested actions are allowed or denied. This occurs whether the actions are user requested or malicious code attempting to auto-execute. When the system detects a request that should not be allowed according to the local security policy, it stops the action from occurring and sends an alert regarding the inappropriate behavior.

Residing on the endpoint and closely monitoring the system for any behavior that is inconsistent with the locally enforced security policy, CSA can fill many security roles in a single agent beyond just preventing known and unknown (or day-zero) attacks, including the following:

  • Globally automated correlation and reaction

  • Distributed firewall

  • Application control

  • File and directory protection

  • Network admission control

  • Application deployment and behavior investigation

This section describes each of these roles in detail.

Globally Automated Correlation and Reaction

With security agents throughout your architecture reporting to a single management console, you can leverage the information consolidated in this centralized repository. The CSA Management Console (MC) can correlate events such as e-mail worm propagation events and virus scanner log events to dynamically create new rules. These new rules are distributed to all systems in the architecture that may or may not have seen the correlated event. These dynamically created rules can then provide a first-level defense against the malicious code by preventing the malicious file from executing or the correlated IP address from communicating with any agent-protected system.

Distributed Firewall

CSA actively watches inbound and outbound connections to and from the local host. The agent can control how the network connection is utilized based on the current local security policy that you defined. You can apply a great number of networking controls. The agent can control which applications on the local system can act as a server to remote clients. If the agent is acting as a server, you can decide whether the application should service connections from all remote systems or just specific remote systems and on specific TCP ports. The security agent can also control which local applications can act as a network client on your network. This control proves very useful, especially when trying to limit which applications are allowed on workstations within your security policy parameters. For example, perhaps you want to require users wanting to use Telnet to use only telnet.exe located in a specific folder on the endpoint and prohibit the Telnet protocol (TCP/23) using any other application. By controlling which processes are allowed network access, you can help stop worms from propagating across your network. CSA can also constantly monitor the IP network stack for other inconsistencies, such as invalid protocol headers, SYN floods, port scans, and other malicious packets through the use of an optionally installed network shim.

Another addition in CSA 4.5 is the ability for the enterprise security administrator to distribute some of the personal firewall control to the end users. You can enable end users to control which applications are allowed network access through appropriately answering query messages spawned by the centrally defined network access rules. The user can also place the local agent personal firewall in a learning mode to build the list of allowed network applications. The personal firewall rules do not override any centrally defined policies but rather further lock down the system and limit the number of future query messages a user may receive regarding network usage.

Application Control

Many current corporate security policies list specifically named acceptable applications. Unfortunately, in most cases, the enforcement mechanisms are nothing more than signed documents, and the local administrative team typically has very little control over what users actually do use from an application standpoint. CSA can help solve that problem.

Application control rules enable you to enforce portions of your security policy by explicitly stating which applications can run on end systems. It can also be more specific in that you can name certain applications that can normally be invoked but in specific instances will not be allowed to execute. An example of this is to normally allow a local command shell, such as cmd.exe or command.com, to be launched; however, when downloaded content attempts to initiate a local shell, the application control rule should prevent this.

Another type of application control comes in the form of multiple rules and policies. Cisco provides preconfigured policies that help you control applications such as instant messengers and peer-to-peer music- and file-sharing utilities. These policies help granularly control the specified applications and their usage and require multiple rules to accomplish the task.

File and Directory Protection

CSA provides a way to protect specified directories and files from being deleted, modified, or created. The local agent monitors file usage so that your protected entries are not adversely affected. The protected files and directories can be on the local hard drive, CD, floppy, removable media (such as zip and USB), or even on network shares.

With version 4.5, you can also allow users to create a local list of files and directories that should not be accessible over any network connection. This functionality enables users to protect their own information outside of what may already be protected via global enterprise file and directory control policies. Just as with the locally administered personal firewall, any access rules set by the local user do not override the centrally defined policies, but instead further lock down the system.

Network Admission Control

CSA plays an important role in the Cisco Self-Defending Network Initiative (SDNI). The first portion of SDNI to become commercially available is Network Admission Control (NAC). Within NAC, there is a requirement that end systems run a component known as the Cisco Trust Agent (CTA). CTA, which is built in to version 4.5 of the Cisco Security Agent, provides the network a mechanism by which you can control access at Layer 2 or Layer 3 based on information CTA conveys. In simple terms, the network must learn about the security posture of the endpoint before it is granted access. The information reported as part of this posture assessment process could be regarding the version of the current virus definition file and other posture-related information.

CSA Analysis

Agent analysis is an exciting addition, new in version 4.5, that enables CSA to analyze the endpoint, determine which applications are installed, and report what a specific application is doing when it executes. The ability to inspect your endpoints to provide detailed information on which applications are locally installed is called application deployment investigation. Within this feature, you can also see applications that run and how often they run. Another crucial component of this particular analysis feature is the ability to see which applications are using network resources. This functionality provides detailed reporting of processes running as client or servers on end systems so that the administrative team can create a global report of network applications. These reports enable you to understand exactly which applications are on your network so that you can block or remove the ones that violate the current written security policy or create security agent policies for currently unprotected applications. It is very important that you understand what is installed and executing on your systems when attempting to protect them. After all, it is not necessarily what you know you have installed that is your biggest concern, but rather what you do not know is installed that poses the real security threat to your organization.

Application behavior investigation is another analysis function that has been added in version 4.5. This feature should prove extremely useful for any organization. After you have located the unprotected or unknown application on a host, you can create a behavior analysis job for that application and deploy the job to the CSA on the endpoint that the application resides. The agent will compile information on the associated application, such as file, COM, and network usage. After all the information has been compiled, you can view it on the CSA MC and, if desired, create a policy to protect the observed behavior of the application that could then be deployed to all other necessary agents.


CSA Components Overview

CSA uses a distributed architecture consisting of two major components:

  • Management Console (MC)— The MC performs many important tasks such as agent configuration, policy configuration, and centralized reporting.

  • Agents— Agents, which enforce local security policies, reside on hosts throughout the network.

The next sections provide an overview of both components.

Management Console

The CSA MC runs on top of the Microsoft Windows 2000 Server operating system using either a Microsoft Database Engine (MSDE) by default, which is included in the product installation, or Microsoft SQL 2000 when you need to scale beyond 500 agents. The CSA MC is where all management functions are performed. As part of the CiscoWorks VPN Management Solutions (VMS) network management family of products, the CSA MC has the same look and feel as the other management tools from Cisco, and its configuration interface is accessible via a web browser over a secure encrypted Secure Sockets Layer (SSL) connection. Figure 2-1 provides a typical CSA MC screen you will see upon successfully logging in to the CSA MC application with your web browser.

Figure 2-1. Cisco Security Agent Management Console

[View full size image]

The CSA MC application is where you perform all configuration tasks and tuning of necessary modules, rules, and policies to secure agents. You can also modify host group assignments and attach necessary security policies to groups from this interface. Another major function provided by the MC is the Event Viewer and Reporting tool by which necessary data is presented to the security group such that necessary action can be taken based on event notification.

Agent

CSA is a software application that installs on end systems. The following are host operating systems supported by the Cisco Security Agent:

  • Microsoft Windows NT

  • Microsoft Windows 2000

  • Microsoft Windows 2003

  • Microsoft Windows XP

  • Solaris 8

  • Linux RedHat Enterprise v3.0

The agent monitors the local system for policy violations and protects local resources and data from being compromised. Whenever an attempted policy violation is detected, a message is sent to the MC for centralized reporting purposes. At predetermined time intervals (polling time), the agents report back to the MC server to see whether any policy changes have been made to what is currently running on the local agent. Figure 2-2 shows a view of the CSA user interface that you can access from any agent-protected system in your environment.

Figure 2-2. CSA Local User Interface

[View full size image]


CSA Communication

Security agents are deployed on workstations and servers throughout your infrastructure, and your MC is located on a secured segment of your management network. Because these systems reside in different parts of your network, you should understand what communication needs to take place between the agents and MC. The next sections look at what communication takes place and the secure methods used.

Necessary Protocols and Ports

There are two communication streams to look at within the security agent architecture:

  • The management connection from the security administrator s PC to the MC

  • The communication path between the MC and the agents

The management connection from the security administrator s PC to the MC uses a web browser as the remote application to build an encrypted SSL tunnel on TCP ports 1741 and 1742. The typical installation of CiscoWorks VMS (where the CSA MC resides) uses a locally generated server-side certificate for the SSL connection; however, you can import a certificate for use on the server if you require an authenticated certificate using your current Public Key Infrastructure (PKI).

The communication path between the MC and the agents also uses SSL as the communication protocol on its standard TCP port 443 as well as TCP/5401. The MC also transmits larger transactions using HTTP (TCP/80). These large transactions include agent install kits and policy updates. Transmitting this information over HTTP allows organizations to benefit from distributed caching technologies that may have been deployed to allow for lower bandwidth utilization on slower WAN links. These files and communication are signed with the CSA MC certificate to prove its authenticity such that no one can intercept the communication and alter the contents without the endpoint knowing the transaction had been tampered with. Communication streams between the CSA MC and remote agents are used for a few purposes such as policy updates, agent polling, and alert message communication.

Pull Model

The major communication model CSA uses when checking for updates is that of a pull model. This at first seems contrary to what is expected. Many people have initially commented that they believe the communication should be a push rather than a pull because a configuration change on the MC requires an agent to initiate the conversation at the normal poll interval. This could mean that an agent would not get the necessary update in a timely fashion. This belief is a common misconception and is related to what many people have used for many years to protect their networks: signature-based technologies.

Remember, signature-based technologies are only as good as their signature level; therefore, signature-based products must have the ability to be updated as fast as possible when a new signature file is released. Behavior-based technologies do not have this limitation. Because CSA uses behavior-based rules to prevent day-zero attacks, you almost never need to force an update to the remote policy. Policy updates typically only need to take place in conjunction with rolling out a new application to an agent-protected system or as part of dynamic updates resulting from globally correlated network activities.

NOTE

The polling interval defaults to 10 minutes, but you can set it between 10 and 86,400 seconds (24 hours).

Push/Hint Capability

Even though the pull model has proven to be successful during previous versions of the CSA, with version 4.5 you can now send a hint message to remote agents suggesting they check in early because an update is waiting. The previous section identified some reasons the agent might need to receive an update. In most cases, the agent poll time is sufficient because the updates can be planned in advance as part of the project planning involving the additional new application to be installed on the end system.

Remote policy updates also may be required when a dynamic variable is updated as the result of correlated events such as the @DYNAMIC list of globally quarantined files or IP addresses. When this list is updated, it is beneficial to let the agents know they should poll early (especially if you have set the poll interval to a very long timeframe). The method used to make this happen in version 4.5 is signed UDP hint messages. Signed UDP hint messages are UDP packets that carry the CSA MC certificate as the signature to prove authenticity. This message operationally instructs the remote agent to poll earlier than the next poll time to retrieve the necessary update. Although only functionally a hint to the remote client, you can consider this feature to be as timely as a push model.

NOTE

Because the hint message is UDP based, it is nonreliable and you will not know whether the message reached the endpoint.


CSA's Role Within SAFE

Cisco has created a security blueprint called SAFE that can be applied to any-size network when attempting to design and secure network infrastructures. CSA is a fundamental part of the SAFE architecture. As any security professional will tell you, lacking effective endpoint security measures is a sure way to create an ineffective security strategy. For more information regarding CSA implementation across the SAFE architecture, consult the architecture documents located on the Cisco website at http://www.cisco.com/go/safe.


Summary

This chapter covered the overall CSA software components: agents and the CSA MC. These components communicate using various connections at the necessary times utilizing encrypted SSL communication streams. You also learned the behavior-based characteristics of the CSA product and how this differs from the older signature-based technologies. CSA provides an all-inclusive multifunctional product with a single management interface. Part 2 examines the configuration components on the MC in more detail.


Part II: Understanding the CSA Building Blocks

Chapter 3 Understanding CSA Groups and Hosts

Chapter 4 Understanding CSA Policies, Modules, and Rules

Chapter 5 Understanding Application Classes and Variables


Chapter 3. Understanding CSA Groups and Hosts

This chapter covers the following topics:

  • The relationship between groups and hosts

  • Understanding CSA groups

  • Understanding CSA hosts

The Cisco Security Agent (CSA) architecture is composed of many components that you must understand when attempting to efficiently and effectively deploy the product in an enterprise environment. Deploying the agent in the most efficient way possible translates to several hours per month saved in the future as a result of lowering the administrative over-head. As in any project, careful planning pays off. You should treat the deployment of CSA no differently than any other large-scale technical project. This chapter examines the first two logical components of CSA: groups and hosts.


The Relationship Between Groups and Hosts

In very simple high-level terminology, a host is the machine you are attempting to protect that is running CSA software. Groups are logical collections of the hosts you have deployed based on similarities the particular hosts share with one another.


Understanding CSA Groups

The CSA product uses groups as a mechanism to simplify management. Groups enable you to place policy controls and set agent configuration parameters to a number of agents without the need to granularly apply the settings. Groups also allow for a consistent configuration to be deployed across the environment. Hosts are required to participate in at least one group from which they will inherit various settings and policy controls. The hosts are not limited to participating in a single group, however. Hosts can belong to several groups at the same time, with the various settings and policies attached to the respective groups being merged into a host-specific policy on the endpoint. You should be familiar with a few types of groups and several ways to use groups, which are discussed in this section. You learn more about hosts later in the section "Understanding CSA Hosts"

Introducing the Group Types

Before you can begin creating groups for your specific deployment, collect information about your internal security requirements and the systems that need to be protected by security agents. After you have gathered information such as operating systems, application information, and system user interaction requirements, you are ready to begin grouping agents together. Three types of groups are available for use in the CSA architecture:

  • Mandatory groups

  • Predefined groups

  • Custom groups

CAUTION

Hosts can belong to more than one group, and so they can inherit multiple policies; be aware, however, that the combined rule set will follow the rule precedence when deciding which rules override other conflicting rules when the combined rule set is put into effect on the host. Rule precedence is covered in detail in Chapter 4, "Understanding CSA Policies, Modules, and Rules."

Mandatory Groups

The mandatory groups are Windows, Solaris, and Linux. After a host enrolls with the management console upon its first successful poll, it is placed into one of these groups based on the agent install kit type. At this point, the host belongs to one of the three top-level mandatory groups and cannot be removed. Mandatory groups are the highest level of grouping within CSA and enable the security administrator to apply rules to these groups such that other more specific group policies cannot override them.

The rules and policies assigned to the mandatory groups become mandatory rules, which you will learn about in Chapter 4. An example to illustrate this concept is the need to ensure all Windows hosts protected by CSA cannot have the remote control service disabled by other attached policies inherited from nonmandatory groups. When you have a policy attached to the mandatory group that ensures the agents always have the remote control mechanism allowed, the help desk can continue to service your install base without fear of a new, more-restrictive policy blocking their access.

Remember, after a machine has registered as Windows, Solaris, or Linux, it cannot be changed without first uninstalling the current agent software and then installing a new agent of a different type. Very rarely will this is necessary, but it is worth noting.

Predefined Groups

The second type of group is known as a predefined group. In the CSA product, Cisco has predefined groups for common deployment scenarios and has already defined some baseline policies to protect these groups. Organizations can use these groups to speed product deployment. Although the predefined groups and policies are useful in initially understanding and testing/piloting the product, most customers find they need to create their own groups that better mirror their security pilot, geography, and business requirements. The groups you create to specifically suit your environment are known as custom groups and are covered in the next section. Figure 3-1 shows the predefined groups on the CSA MC server. You learn more about this type of group later in the section "Exploring Predefined Groups."

Figure 3-1. Predefined Groups

[View full size image]

One last point to make about the group list shown in Figure 3-1 is that when a group has hosts as members, there will be an entry to the right of the Group Description field. In this example, the VMS CiscoWorks Systems group at the bottom of the screen lists "1 host," which is a clickable link to the list of hosts participating in this particular group. In summary, groups allow the CSA architecture to scale.

Custom Groups

Custom groups are groups that you manually create to suit your own deployment needs. You might want to create a custom group for many reasons, but the major reason is to lower the administrative overhead of managing the product while still maintaining a highly effective security policy. Custom groups enable you to create and maintain policies that will affect large numbers of similar hosts so that you do not have to manage hundreds or thousands of hosts individually. You may create groups to have a consistent policy. If you only manage a single policy and attach it to a group, there is less chance that any single machine s policy will differ from other machines in the network.

You need to decide how best to use custom groups in your network so that they best fit your security policy enforcement goals. Some ways to group machines include the following:

  • Function or application

  • Business or department related

  • Physical or geographic location

  • Criticality and importance to the business

Another reason to use custom groups is for manageability and reporting. By assigning certain hosts to specific groups, you can sort events specifically related to that group which may relate to a specific geographic location, department, or subnet. You may also want to place a group in Test Mode to test new policies without affecting your entire production environment.

Viewing Groups

The Groups configuration window is an option under the Systems tab of the CSA MC tool. To view all of the groups configured on the CSA MC (mandatory, predefined, and your custom-created groups), choose Systems > Group as shown in Figure 3-2.

Figure 3-2. Choosing Groups from the Navigation Bar

[View full size image]

When you are at the Groups window, you can view the list of currently available groups by operating system. You can also remove groups by checking the check box directly in front of the group you want to remove and then clicking the Delete button at the bottom of the browser window.

Two other options at the bottom of the page enable you to create new custom groups: New and Clone. Clicking the New button enables you to create a new custom group. You can use the Clone button after choosing another group via its associated check box. The clone process inherits the other group s configuration, so you can create a new similar group with modified settings without affecting the original group s configuration. This can prove very useful for testing slightly changed policies on a controlled pilot group without affecting the mass of other hosts running the currently deployed policy attached to the original group.

The last button to discuss at the bottom of the Groups screen is the Compare button. To use the Compare button, choose two groups you want to compare by checking the associated check boxes and then click Compare. The CSA MC then presents you with a comparison view of the two groups, including such items as attached policies, polling interval, architecture, and description, as shown in Figure 3-3.

Figure 3-3. Comparing Groups

[View full size image]

TIP

The Compare option for groups is only able to compare two groups to each other. You need to perform successive comparisons if you want to compare more than two groups to each other.

When comparing two groups, you can choose any policy attached to the group by checking the check box to detach or attach the policy to the group. Detaching a policy removes it from the group and attaching enables you to add it back to the group s active policy.

Creating a Custom Group

To create your first test group, first click New at the bottom of the Groups web page. A pop-up window then asks, "What is the target architecture?" The answer to this question depends on the purpose of your group; for illustration purposes, however, choose Windows as the target architecture. The Group Configuration page displays next. Before you finish configuring this group, notice the following points shown in Figure 3-4:

  • The group name is originally Untitled_1— This group name changes after you have renamed the group, but at this point the group has already been created. If you want to remove this newly created group, click the Delete button at the bottom of the page.

  • One rule change is pending— To finalize all configuration changes and implement them into the CSA running active configuration deployed to agents, click the Generate rules link at the bottom of the page.

Figure 3-4. Creating a Custom Group Named TestGroup1

[View full size image]

TIP

After changing any configurable settings on any CSA MC web page, you must click the Save button at the bottom of the page to commit the changes. These changes are not activated in the production agents until you generate rules, as described later in this chapter, and save the changes; otherwise, the changes are lost.

From the Group Configuration screen, you can now edit the group and all group settings. First, name this group TestGroup1. Then edit a brief description and a detailed description for this group. The Description and Detailed fields prove extremely useful when used appropriately. Place a simple description in the Description field; in the Detailed field, add information regarding who to contact about the policy and any important notes that may help troubleshooting in the future.

Below the Description field, the Target Architecture field reminds you that this is a Windows policy. The polling interval for devices in this group is set to 10 minutes. You can change the polling interval to a lower or higher number if devices in this group require checking in more or less often for configuration updates. Another option is to check the Send Polling Hint box, which turns on the UDP hint message capability new to CSA 4.5. UDP hint messages are signed UDP messages that the MC can send to the last known IP address of the agent to alert the agent of an impending configuration change or other similar request. This feature can prove useful when setting the polling interval high but still wanting to have some control over a speedy policy update when a change is necessary.

The next section of the Group Creation dialog is Rule Overrides. The various options are available upon clicking the plus sign (+) next to Rule Overrides. As shown in Figure 3-5, the rule-override options are as follows:

  • Test Mode— Applying Test Mode to a group causes the agents in that group to only monitor what actions would have been taken based on the local running policy without actually enforcing the preventive actions. These monitored events are reported back to the MC as Test Mode events. Test Mode is commonly used when testing policies in an active production environment or when testing policies in nonproduction during the early phases of the CSA implementation. This mode enables the implementation team to watch the policy on end systems for possible conflicts with the system and its applications that could have impacted system usability if the agent had been in Protect Mode. Protect or Enforcement Mode is the state an agent is in when the policy is actively enforcing the actions on the end system. You learn more about Test Mode later in the section "Using Test Mode."

  • Verbose Logging Mode— Verbose Logging Mode causes the hosts in the group to log all recurrences of events rather than just a single event in cases where multiple occurrences of the same event are suppressed.

  • Log Deny Actions— This option causes the agents in the group to log all deny actions regardless of whether the individual rules state that logging should take place.

  • Filter User Info from Events— This option prevents some personal user information from showing up in the CSA MC log so that you can be aware of what is happening in the network without overstepping your bounds as "Big Brother." This feature is valuable when you have privacy policy limitations.

Figure 3-5. Definable Group Settings

[View full size image]

After defining the appropriate parameters for the previous options, click Save to make the changes permanent.

In addition to enabling you to define parameters for group settings, the Groups screen also provides a quick links section at the top of the page. This section contains three options:

  • Modify Host Membership— Links to a page that displays which hosts belong to this group and enables you to add currently nonparticipating hosts to this group as members.

  • Modify Policy Associations— Brings you to a page where you can select which policies should be attached to this group and thereby distributed to the group s members. You learn more about policies in Chapter 4.

  • View Related Events— Links you to a filtered view of the event log, which only displays events generated by members of this group.

The final task in creating or modifying a group is to click Generate rules at the bottom of the Configuration page. Clicking this button takes you to a listing of the changes that need to be committed and an option to Generate, as shown in Figure 3-6. Also notice that some options have a clickable [Details] link, which you can click to view what that particular change entails. (See Figure 3-7.) You must click Generate for the CSA MC to modify the rule associations and agent kits so that they will be in effect. Figure 3-8 shows the rule-generation operation completed.

Figure 3-6. Sample Generate Rule Programs Screen

[View full size image]

Figure 3-7. Sample Entry Details Pop-Up Window

Figure 3-8. Generating Rules

[View full size image]

After policies are attached to this group, the associated rules display at the bottom of the Groups page.

Exploring Predefined Groups

The product installation includes many predefined groups. These groups are included to simplify a basic installation of the CSA product but may not be applicable to all environments. As a best practice, explore the predefined groups to see which you could use in your specific deployment to simplify the implementation and configuration process. So that you can better understand what a predefined group can be used for, this section looks at a few of them in detail and explores their attached policies.

The Desktops—All Types Group

The Desktops-All Types group is by far one of the most used predefined groups shipped with the CSA MC. You can use this group for all of your generic hosts. It is a great place to configure policies that should be inherent on all desktops in your organization. This section looks at the generic functionality of the Desktop-All Types group as assigned by the pre-attached policies. You can change these policies and rules as needed for your own successful deployment or, alternatively, you could create your own groups for hosts that better match your deployment plan and architecture.

Initially exploring the top-level group settings, you notice a generic description for the group has been prepopulated and the 10-minute polling time is the default. The Polling Hint Message is enabled, allowing all hosts in this group to receive a hint message when a policy update is required. Another item to note is that the attached policies and the combined rules from these policies are listed, as shown in Figure 3-9. You did not see this earlier in the "Creating a Custom Group" section because when you created your custom group called TestGroup1, you had not associated any policies with that particular group at creation time.

Figure 3-9. Attached Policies and Combined Rules

[View full size image]

To get a better understanding of what this group s policies control on the hosts, you can expand the associated policies by clicking the plus sign (+) in front of the policies listed; doing so reveals all associated modules. (See Figure 3-10.)

Figure 3-10. Expanded Policies Reveal Associated Modules

[View full size image]

You can see in Figure 3-10 that the Default Desktops group includes several policies, which in turn include several modules. In the Combined Policy Rules block, you see every rule associated with these policies. You can navigate via the clickable links directly to each attached policy, module, and rule; however, the CSA quick links section located at the top of most CSA MC Configuration pages gives you a few other valuable viewing options. To get an easy-to-read explanation of the attached combined policy, click the Explain Rules quick link.

The Explain Rules page enables you to view in as simple terms as possible what all the rules in your combined policy mean, as shown in Figure 3-11. There are sections to this easy-to-read explanation, so you can navigate directly to the portion you want to view without having to search aimlessly.

Figure 3-11. Explain Rules Page

[View full size image]

To add even further detail to this page while maintaining the ability to understand the policy in place, the sections are each broken down by state so that you can understand what rules will be in effect based on information such as who is logged in and whether the CSA MC is reachable.

Without going into great detail regarding the Desktop-All Types group, Explain Rules shows you that various types of rules are contained in the attached policy affecting the following:

  • How the local agent can be used

  • How the machine interacts with the network as both a client and server

  • How the local file system is used by various applications

  • What should be audited, such as logon and logoff of the machine

Other Predefined Groups

Several other predefined groups are included with the CSA MC installation and are listed on the Groups page. The groups listed on this page are sorted by operating system architecture. These groups are not necessarily included as a guide of how you should or should not implement groups in your organization but rather as basic examples and a possible launching pad to quicker deployment. Every organization should look deep into their own security policy for reasons to implement different sorts of groups, whether it is for grouping specific types of application servers, geographical locations, or purely for report and Event Monitor filtering purposes. Here is an abbreviated list of predefined groups:

  • Servers—All Types

  • Desktops—All Types

  • Desktops—Remote

  • Servers—IIS Web Servers

  • Systems—Test Mode

Remember, the preceding list is just a sample of the predefined groups included during the installation process. Refer to your Groups page to see what definitions are included with the particular version of the CSA MC you installed; these predefined groups and policies will continue to be developed and mature over time. Chapter 14, "CSA MC Administration and Maintenance," describes group best practices in more detail.

Viewing and Changing Group Membership

When working with groups, you may occasionally need to change which hosts are part of that group. This change might be related to a physical relocation of the host or possibly a change in the application composition of the host. To easily edit which hosts are associated with the specific group, click the Modify Host Membership quick link from that Groups Configuration page. In Figure 3-12, you can see an example of the Modify Host Membership page associated with the TestGroup1 group. It is very easy to add or remove hosts from this group by highlighting the host or hosts and clicking Add or Remove.

Figure 3-12. Example Host Membership Modification Page

[View full size image]

You also have the option to Bulk Transfer all members of another group to this group via either a Copy or Move option at the bottom of the page. Using a bulk transfer move function enables you to empty the current group and relocate the users to a new or preexisting group; however, using a bulk transfer copy adds the members of the current group to an additional group without removing the hosts from the original group. In this situation, these hosts participate in more than one group and, therefore, the host settings and rule base are a derivative of the combined group information in accordance with rule precedence, as you learn about in Chapter 4.

As with any change in the CSA MC, you must click Generate rules to commit the changes to the active configuration to be delivered and enforced on the agents. The agents are completely unaware of the changes until the rule generation is completed and the host successfully polls the CSA MC server for updates. Until both of the preceding events take place, the remote agents are completely unaware of any changes made centrally and continue to enforce the currently deployed policy.

Viewing Group-Associated Events

When working with an existing group and troubleshooting rules, it proves very useful to view which events have been triggered by members of that group. An easy way to view these particular events is from the Groups page under the top-level Systems menu option. From this page, you can choose Group Associated Events from the quick links navigation option. This opens a new window that displays all group-related events in the CSA MC database, as shown in Figure 3-13. From this page, you can scan for particular types of events that you may be troubleshooting and then dig deeper into their cause to see whether it was a legitimate action or a rule in need of revision. The event log is covered in detail in Chapter 8, "Monitoring CSA Events."

Figure 3-13. Group-Specific Events in the Event Log

[View full size image]


Understanding CSA Hosts

In the CSA architecture, hosts are the machines you want to protect. The agent software is installed on host systems. Those endpoints are, from that point on, referred to as hosts within the CSA MC. Hosts are initially assigned group and policy information upon installation of the agent kit. An agent kit is the agent installation executable, which Chapter 6, "Understanding CSA Components and Installation," discusses in detail. After the agent has been installed on the host, it attempts to connect to the CSA MC to register and pull the latest policies tied to the group to which it was assigned.

Viewing Host Configuration

To see the list of hosts that have registered with the CSA MC, choose Systems > Hosts. From this page, you can filter the list of hosts via two easy-to-use drop-down menus. The menu on the upper left is a selection method that enables you to filter by operating system, as follows:

  • All

  • Windows

  • Linux

  • Solaris

The menu on the upper right is a selection tool that enables you to filter by the following criteria:

  • Active— Only lists hosts that actively polled during the last update poll interval

  • Protected— Only lists hosts that have policies attached to their assigned groups

  • Latest Software— Only lists hosts that are running the latest available software and are not in need of an agent software upgrade

  • Test Mode— Lists hosts that are currently running in Test Mode are listed as ON

  • Last Poll— Sort hosts by the time stamp of their last poll

The Hosts window shown in Figure 3-14 gives you some basic top-level information about the host, such as the host name and a description that includes operating system and service pack, processor information, and amount of memory installed. You can also delete the host from this screen. Deleting a host frees up a license on the CSA MC for another machine to register; this proves useful when you decommission old hardware and re-issue new hardware.

Figure 3-14. Viewing the Host List

[View full size image]

When a host is a member of a particular group, it inherits the behavior of that group, which could relate to items such as the following:

  • Configuration polling intervals

  • Security policy rules

  • Test Mode operation

The next sections describe polling intervals and Test Mode operation in more detail. Chapter 4 thoroughly explains security policy rules.

Polling Intervals

Understanding polling intervals is important when attempting to best deploy and scale your CSA architecture. The remote CSA agents only request policy updates from the CSA MC server after the designated polling interval for that agent has expired. The default polling interval is 10 minutes. You can increase this time up to a maximum of 24 hours. If your environment has very secure and controlling policies and you have set many of the rules to log events, or you have a very large number of agents reporting to a single CSA MC, you might want to increase the polling interval to decrease the load placed on the MC. The polling interval is one way to control how often network traffic between the MC and remote agents needs to take place. Even though the typical traffic between the agent and MC is relatively low bandwidth, if you have a large number of hosts attempting to communicate over low-bandwidth WANs, you might want to increase the period between polls.

The amount of polling traffic communicating with the CSA MC limits the number of agents the CSA MC can successfully manage because of the overhead required to process the requests. Although this overhead is low and the CSA MC architecture can scale to service up to 100,000 hosts, the polling interval should be addressed beginning in the pilot.

NOTE

When a host belongs to more than one group, that host inherits the shortest polling interval assigned any of the groups of which it is a member.

Using Test Mode

Test Mode is an extremely important CSA topic. Test Mode is an invaluable feature often used when initially deploying the CSA product, when modifying policies down the road, or even during troubleshooting an agent. Test Mode is a state the agent can enter where it no longer is taking preventive measures. When in Test Mode, agents inspect all interaction as defined in the combined rule set running on the agent system and log all information with regard to how the agent would have reacted as any policy match occurs; however, the agent does not enforce the action specified in the matching rule and therefore does not prevent an application from functioning or an attack from succeeding.

When you initially roll out CSA, it is beneficial to implement the product in Test Mode so that you can see how the policy will affect day-to-day business without negatively impacting it. After you have fine-tuned the policies, you can take the agent out of Test Mode and all policies will be placed in full effect (that is, Protect Mode) after the next successful agent poll. Remember, when in Test Mode, the policies are actively inspecting transactions but are not enforcing the rule action, such as denying access to system resources. In Chapter 4, you learn another way to use Test Mode to test specific policies rather than entire groups.

Working with Hosts

Clicking the link on the host list takes you to the configuration detail page for that particular host. (See Figure 3-15.) This page gives you great detail regarding the particular host selected. You are presented with the host name and description, as you also saw on the Hosts page. You also have a Contact Information section, which can be expanded to show the associated username, e-mail, phone number, and location if the user has entered the information into the remote agent user interface (UI).

Figure 3-15. Host Detail Page

[View full size image]

Below the Contact Information, you see a section that can be expanded as in Figure 3-16 to reveal detailed host status. This information is broken out into three sections:

  • Host Identification— Under Host Identification, you see the following detailed breakout:

    • Product Information— CSA agent version currently reported.

    • Last Known IP Address (and History)— The last IP address from which the agent polled. This historical account of previously reported IP addresses, including start and finish times for which the IP addressed were in use, is available in a pop-up window by clicking the History link.

    • Host ID— The ID associated to the host at registration time for necessary linkage within the CSA MC database.

    • UID— ID associated with the agent kit used for installation.

    • Registration Time— Initial date and time of registration.

    • Operating System— The reported OS on the host.

    • Cisco Trust Agent Installed— Whether the Cisco Trust Agent is installed and, if installed, the associated posture state currently assigned to this agent. This feature is part of the Cisco Self-Defending Network Initiative and more specifically Network Admission Control (NAC).

  • Host Status— From here, you obtain information regarding the current operational status of the agent, such as the following:

    • Events Issued in the Past 24 Hours— Clickable link and number of events from this particular host within the past 24-hour period.

    • Software Version— Whether the agent software version is current.

    • Policy Version— Whether the agent is running the latest, current policy.

    • Time Since Last Poll— Time since the last successful poll.

    • Time Since Last Application Deployment Data Upload— If an application deployment job has been run for this agent, the time since the last upload will be listed.

    • Detailed Status and Diagnostics Link— This option enables you to get current information about the endpoint, including IP address and current or out-of-date policy, by requesting the agent to poll immediately with this information. You can also clear remote cached entries on the remote host directly from this screen and reset the agent back to default installation parameters from the Diagnostics window without physically visiting the device.

  • Host Settings— The Host Settings portion of the Status section gives you insight into some configurable on/off parameters for the host agent. Many of these options are only configurable within the groups that the host is a member of, but from here you get a good view of how the host is set to behave based on conflicting policies that may be present within multiple groups. Here is a list of what is reported under Host Settings:

    • Polling Interval— The polling interval for this host.

    • Send Poll Hint— Whether UDP hint messages are enabled for this host.

    • Test Mode— Shows whether the agent is in Test Mode.

    • Verbose Logging Mode— Whether the agent is suppressing repeated messages within the allotted timeframe.

    • Log Deny Actions— Denotes whether the host is set to log all deny actions or just those set to log per rule definition.

    • Filter User Info from Events— Whether the host is filtering user information for privacy reasons when reporting to the event log.

    • Application Deployment Investigation Enabled— Shows whether the agent is actively running an application deployment investigation.

Figure 3-16. Hosts Status Detail Information

[View full size image]

The Host Detail screen also shows a nesting of which groups the host is a member, the policies assigned to the groups, and the modules within the policies (see Figure 3-17).

Figure 3-17. Group and Policy Inheritance Nesting Example

[View full size image]

Just below the nested hierarchy appears a list of all rules running on the host as combined from all associated groups, policies, and modules. This list is divided into two major sections: enforce rules and detect rules. Enforce rules typically deny, terminate, or allow actions to occur; whereas, detect rules monitor and log actions. Chapter 4 covers the types of rules in greater detail.

A useful feature when working with the combined rule set deployed to an agent is the ability to sort the rules listed at the bottom of the Hosts page in the Combined Policy Rules section. The default displays All Rules; however, by clicking All, you can filter the displayed rules. You can select the specific rule type to view, system state conditions, or user state conditions. (See Figure 3-18.)

Figure 3-18. Filtering Combined Policy Rules

[View full size image]

Changing a Host's Group Membership

Earlier in the section "Viewing and Changing Group Membership" you learned how to add and remove a host from a particular group you are viewing. You can also change a host s group membership from the host detail window shown in Figure 3-19. When viewing the host configuration, you can click Modify Group Memberships from the quick links menu. This screen is very similar to the options earlier, but now you have lists of groups to which the host belongs and those of which the host is not yet a member. Just as before, choose the groups you want to join or unjoin and click Add or Remove. This function is similar to what you accomplished from the group option, except that you are now working with a specific host s membership and not a specific group s members. The outcome of either transaction results in a host belonging to new group(s) or being removed from an existing group and, therefore, running the newly combined policy and control mechanisms inherited from its newly defined membership.

Figure 3-19. Assigning Group Membership

[View full size image]

Viewing Host-Associated Events

When troubleshooting a particular host, it is advantageous to filter the event log so that you are only viewing events issued from that particular host. An easy way to accomplish this is to click either the View Related Events quick link or choose Host Status > View Events Issued in the Past 24 Hours. The latter option only displays 24 hours worth of events, whereas the former option displays all events in the database from the host. Both options can prove valuable based on when the issue you are troubleshooting took place.

Figure 3-20. Host-Associated Events Filter

[View full size image]


Summary

After completing this chapter, you understand how groups and hosts are related and how they are used individually. You discovered the many parameters reported and configured in the CSA MC regarding both groups and hosts and how you can tune or use each parameter to assist in scalability or troubleshooting. Because hosts inherit group configuration parameters, most of the configuration is done at a group level and is rarely changed at the host level unless circumstances require a special-case configuration be implemented. Groups are a powerful component in the CSA hierarchy and will continue to be explored throughout this book when relevantly linked to the topic at hand. The next few chapters delve even deeper into the CSA architecture to uncover the inner workings of such logical components as policies, modules, and rules, as well as other groupings such as variables and application classes.


Chapter 4. Understanding CSA Policies, Modules, and Rules

This chapter covers the following topics:

  • The relationship between policies, modules, and rule

  • Establishing acceptable use documents and security policies

  • CSA rule

  • CSA rule modules

  • CSA policies

The Cisco Security Agent (CSA) product has various capabilities that allow it to solve the many security issues facing today s enterprise networks. The following are just some of the issues security practitioners attempt to answer today:

  • How can I prevent known attacks from impacting my network?

  • How can I prevent day-zero attacks from causing loss of my resource confidentiality, integrity, and availability?

  • How can I prevent certain applications, such as peer-to-peer file-sharing systems, from negatively impacting my environment?

  • How can I prevent unauthorized network connections both inbound and outbound on my computing resources?

  • How can I prevent file access and modification?

  • How can I prevent Trojan horses and spyware such as keystroke loggers from compromising my systems?

  • How can I enforce the application of my written security policy?

All of these issues and many more can be solved through the proper application of CSA policies, modules, and rules, as discussed throughout this chapter.


The Relationship Between Policies, Modules, and Rules

Policies, modules, and rules within CSA are the mechanisms that enforce your written security policy. At the lowest level of this three-component hierarchy, rules are the individual components that enforce specific system interaction. After several associated rules are created, they are typically combined into a rule module. Rule modules are collections of rules grouped together to serve a specific purpose. These rule modules are then grouped with other rule modules to form a policy.

For example, you may build a policy to protect a specific folder and files on remote systems from being modified or deleted. This policy might include three rule modules, each associated with rules protecting the resources but specific to three different operating systems. This means that you have Solaris file protection rules grouped into a Solaris file protection module that rolls up into the overall global file protection policy. The other rule modules in this policy are also specific to the operating system that their included rules protect. Finally, after the policy has been created, you can apply it to the groups as necessary and thereby distribute it to the groups included host systems throughout your architecture.


Establishing Acceptable Use Documents and Security Policies

Unfortunately, in today s environments, many organizations rely solely on user ability to make the correct decision when using a computing resource. These decisions may relate to what software to install, what e-mail to open, or when to report "strange" system behavior to the computer support staff.

Acceptable use documents are a mechanism thought to protect intellectual property and computing resources. The documents typically state which resources can be used and how they should be used. In most cases, these documents are related to the computer issued to the individual, intellectual property, e-mail systems, and Internet usage. Acceptable use documents are commonly the result of a human resources or legal requirement and are not an enforcement mechanism for employing policy. These documents suggest what sort of behavior or misuse can result in employee discipline but accomplish very little toward guaranteeing a secure environment. This is not to say that you should not utilize acceptable use documents to satisfy legal requirements; however, understand the difference between legal requirements and notification versus enforcement.

Acceptable use documents are much like traffic laws that specify how fast you are allowed to travel on certain roads. You are only penalized when you are "caught" breaking the law, but it is very common for people to break (or bend) this law. The only way to guarantee the law is upheld is through the active enforcement of the law, such as speed traps using various detection mechanisms. CSA policies are an active enforcement mechanism that controls exactly which resources your systems can interact with and how they are allowed to interact.

Security policy documents are other documents regularly used in enterprise networks. These documents should list in detail the computing resources within the environment and precisely how the services offered may be used. Security documents typically cover the entire security landscape of an organization, including the types of access granted to users, application versions allowed, connections granted to and from portions of the network, and procedures and processes relating to modification of the document and its policies. The security policy documentation is the most important document to have on hand when laying out the CSA policy, module, and rule requirements. Because CSA is the practical enforcement mechanism of the written security policy, you must map the written document to specific rules of enforcement. The remainder of the chapter covers how to map written policy to enforced policy through various CSA mechanisms.


CSA Rules

Rules are the smallest enforcement component in relation to the enforcement hierarchy. There are several rule types available that enable you to limit, monitor, and control interaction on agent-protected systems. Rules can deny or allow interaction with the local agent user interface, allow or prevent network access, and control file usage. To better understand rule definition, you first need to grasp several concepts shared across the many rule types, such as user and system states. The next sections cover those shared concepts.

Understanding State Sets

State sets are a new concept introduced in the CSA 4.5 release. This feature enables you to define rules that can be distributed to the remote agents as part of normal polling that will remain inactive until the state set matching criteria is satisfied. There are two types of state sets:

  • User state

  • System state

The application of either (or both) types of sets enables you to define policies that become enabled based on the user logged in to the local system and the location of the computer at that moment in time.

User State Sets

User state sets provide a mechanism to enforce varying policies based on the user logged in to the system. You can enforce rule modules based on the username and group information cached upon logging in to the system. This is an excellent way to provide the common user a specific set of system control and network access while logged on and maintaining the ability to grant greater access to administrative or technical support personnel. For example, you might have policies in place that prevent the local user from stopping the Security Agent Windows Service unless the user logged in to the system is in the Administrators group. Although this condition-based method of applying rules can prove extremely useful, you should apply this method only when absolutely necessary because it increases the size of the policy transmitted to and from all protected systems and increases the processing required on the endpoint to verify the state condition.

NOTE

In previous versions of the CSA product, to accomplish a rule change on a remote system, you need to centrally change the host s policy and force a poll for the new rule to propagate, allowing the temporary access required for troubleshooting. With user state sets in version 4.5, it is now much easier to perform support tasks without a several-step well-timed process.

User state sets are configured centrally on the CSA Management Console (MC) and applied to rules as needed. To configure and view various user state sets, choose Configuration > User State Sets. Several predefined user state sets are included with the CSA installation that might already suit your requirements, as shown in Figure 4-1.

Figure 4-1. Predefined User State Sets

[View full size image]

NOTE

When defining user state sets, you can use security identifiers (SIDs) for Windows groups to match groups regardless of how they are spelled in different languages.

The following list describes a few of the predefined user state sets:

  • Administrators— This set shows users in the Administrators group defined using the SID S-1-5-32-544 rather than the group name (for accuracy when using multiple languages, from an operating system perspective).

  • Anonymous Login (Null Session)— This set contains null sessions by corresponding SID.

  • Dialup— This set shows all users who have logged in to the system via a dialup connection.

  • Root— This set lists UNIX root users.

  • Service— This set shows entities that have logged on as a service by SID.

Many other predefined user state sets such as Backup Operators, Everyone, Guest, and nonroot may also prove helpful in your environment.

To define a new user state set, click New at the bottom of the listing page. This opens the Configuration window. Defining the user state set requires some simple configuration, as follows:

  • Name and Description— Name and describe the set as appropriate.

  • Configuration— You need to set a few configurable parameters to ensure a unique state is defined:

    • Users Matching— Enter the usernames that are part of this set; otherwise, by default, all users are entered. You can use the But Not field to exclude certain users from the set by username; otherwise, by default, none are excluded.

    • Groups Matching— Enter the group name or names that will match this set definition; otherwise, the default is all. You can use the But Not field to exclude certain groups listed here from the set definition; otherwise, by default, none are excluded.

  • References Link— If any rules use this set, you can directly access the specific rules by clicking this link.

  • Save and Delete— Use the Save or Delete buttons to commit or delete any changes to this set whether old or new.

As an example configuration of a user state set, Figure 4-2 illustrates the configuration necessary to create a set that will match users who are part of the Windows Contractor group. This configuration is useful for an organization that provides contracted staff members user accounts and use of corporate resources but wants to limit access based on security agent policy.

Figure 4-2. Defining a Contractor User State Set

[View full size image]

NOTE

The use of wildcards (*) is allowed in the User fields but not in the Group fields.

System State Sets

System state sets provide a mechanism to enforce varying levels of policy at the rule module level according to the current system state. System state parameters include information such as the following:

  • Network Admission Control (NAC) posture

  • System security level

  • IP address or subnet

  • DNS suffix

  • Whether the system is currently booting

  • Whether an installation of software is currently underway

  • Whether the CSA MC server is reachable

  • Whether a rootkit currently is detected

  • Whether a virus has been detected

You can set these various factors singly or in combination to provide granular system state definitions. It is most common to set the required matching of at least two parameters to limit the ability of the end system to "spoof" a parameter such as the IP address to manipulate the local rule base.

Several system state sets are predefined on the CSA MC server, as shown in Figure 4-3. To access these system state sets or create a new one, choose Configuration > Rule Modules > System State Sets to open the listing page.

Figure 4-3. Predefined System State Sets

[View full size image]

Some of the more useful predefined system state sets are as follows:

  • Cisco Trust Agent Infected Posture— This set only uses the Trust Agent Posture parameter as matching criteria. If the NAC posture returned to the CTA is infected, you can apply specific rule modules to the agent.

  • Management Center Reachable— This state set matches when the CSA MC server is reachable from the agent system. This typically only happens when the agent is connected directly to the corporate network through a LAN or remote-access connection.

  • Security Level Low— This set matches when the slider bar on the remote agent UI is set to Low.

  • System Booting— When the system is booting, you can specify interaction allowed.

  • Virus Detected— If a virus has been detected by the local supported antivirus product, you can apply a more restrictive rule module.

The predefined system state sets are very simple, but extremely useful. To create your own customized system state set, some configuration is necessary. To create a new set, click New at the bottom of the listing page, and then configure the following set parameters:

  • Name and Description— Enter a name and description that will be useful to all administrators.

  • Network Admission Control— Use the Cisco Trust Agent Posture option within this parameter to choose the posture you want to match. The posture token is returned to the CTA and then in turn to the CSA as part of the NAC process. Options here are Don t Care, Healthy, Checkup, Quarantine, Infected, Unknown, or Other. Don t Care matches any or no token. To choose multiple postures, use Ctrl-mouse click.

  • System Security— Use the Security Level option within this parameter to match the slider bar security level chosen on the remote agent in the GUI. Note that the default setting on the agent system is Medium. To choose multiple criteria, use Ctrl-mouse click. The slider bar functionality provided to agent-protected systems is user selectable and therefore typically changes as a result of end-user interaction and modification rather than a location-based parameter.

  • System Location— The configuration options here relate to the IP address-based location detected by the agent relating the local system connectivity:

    • Network Address Range— Enter literal values or apply network address sets (variable) to match the current IP address of the system.

    • DNS Suffix Matching— Specify a DNS suffix the system may use at any given time, such as CSA.com versus serviceprovider.net. Use the But Not field to enter DNS suffixes that should be excluded from this set.

  • Additional State Conditions— Click Add State to add additional parameters that should be matched as part of the system state. All of the following parameters have the options Don t Care, Yes, and No:

    • System Booting— This setting matches if the local system is undergoing the boot process or is not booting depending on the criteria chosen.

    • Installation Process Detected— You can use the system state set to apply a more- or less-restrictive policy during an installation on the local system.

    • Management Center Reachable— If the CSA MC server is reachable by the agent, you can apply a different set of rules than if it is not reachable. This is an excellent parameter to match in concert with other parameters to determine whether the user is located on a corporate network, VPN connection, or possibly off-site.

    • Rootkit Detected— If the system detects a rootkit, you can apply different rules to the agent.

    • Virus Detected— If the local supported antivirus package has reported a virus on the system, you might want to provide a more strict policy until the virus has been cleaned and is no longer detected as present on the system.

  • References— If this system state set has been used, the references are listed.

  • Save and Delete— These buttons either commit the changes or delete the system state set.

To illustrate system state set creation, the following steps build a state condition that matches a system that is connected to the network via a Cisco VPN 3030 concentrator. Follow the steps to complete the task and view Figure 4-4 for the completed state:

Step 1. | Enter the name VPN Connected and add an appropriate description.
Step 2. | Do not change NAC or System Security parameters because they do not impact this state set.
Step 3. | Enter 10.99.99.0-10.99.99.255 as the network address range. This is the range of IP addresses served by the DHCP server only to VPN clients.
Step 4. | Enter csa.com as the DNS suffix for matching and leave the But Not field set to None.
Step 5. | Click Add State.
Step 6. | In the drop-down box, choose Management Center Reachable and Yes as the criteria.
Step 7. | Click Save and verify the configuration.

Figure 4-4. Sample System State Set Creation

[View full size image]

You have just created a system state set that should only match your VPN users. You have guaranteed this by requiring the IP address range must be from the VPN pool, the DNS name must be the same as assigned by the VPN DHCP pool, and the CSA MC must be reachable. The CSA MC reachable criteria means you are somehow connected to the net-work, and because of the IP address specified, you can guarantee that you are connected via VPN because the CSA MC return traffic is working. If the IP address is manually changed but the system is elsewhere, routing issues will make the CSA MC unreachable. The system state could now be applied to a rule module that may grant or restrict certain access because of your location in the network.

NOTE

Many of the parameters used in system state sets can be spoofed, but the combination of certain criteria can help validate the overall system state and ensure the system state is accurate.

State Set Management

State set management is performed via the listing pages. On the listing page for either system or user state sets, the following management buttons display at the bottom of the screen:

  • New— Create a new state set.

  • Delete— Check the appropriate check boxes before the items in the list to delete one or more state sets simultaneously.

  • Clone— To make a copy of a state set for modification, check the check box of the item you want to clone and click the Clone button.

  • Compare— To compare multiple state sets to one another, check the appropriate check boxes and click the Compare button. You can only choose two items to compare at a time. The comparison is returned in the browser, as shown in Figure 4-5, with differences highlighted in red.

    Figure 4-5. Comparing Two System State Sets

    [View full size image]

Understanding Rule Actions

When defining various types of rules, you need to provide the type of action the rule will enforce if the defined rule matches the requested interaction.

Deny actions include the following:

  • High Priority Terminate Process— Denies the action or resource request and attempts to terminate the process making the request. Termination of certain system processes could make the operating system unstable. To attempt to prevent an unstable system condition, CSA tries to specifically identify a particular thread and terminate it rather than the entire process when the process to be terminated is a process that would cause a system reboot or other abnormal and undesirable behavior.

  • Terminate Process— Performs the same action as high priority terminate process but with a lower priority. Rule precedence is covered later in this chapter in the section "Rule Precedence and Manipulation."

  • High Priority Deny— Denies the resource requested and does not terminate the process requesting the resource.

  • Deny— Performs the same action as high priority deny with a lower precedence in rule ordering.

Allow actions include the following:

  • Allow— Choose this option to allow access to the requested resource.

  • Default Action (Allow)— The CSA differs from many security products because it allows all interaction on a system by default and only prevents actions that are specifically defined. Choose this option if you needed to allow an action that may be denied in a conflicting rule set that gets merged on a protected host system. Remember, CSA typically denies or limits interaction for a specified policy while allowing all other undefined interaction.

Query actions include the following:

  • Query User Default Terminate— Asks the user whether the resource request is appropriate with a default action of terminate. If the user does not respond within 5 minutes or if the user cannot see the agent user interface (UI), the default action is taken.

  • Query User Default Deny— Asks the user whether the resource request is appropriate with a default action of deny. If the user does not respond within 5 minutes or if the user cannot see the agent UI, the default action is taken.

  • Query User Default Allow— Asks the user whether the resource request is appropriate with a default action of allow, as defined earlier. If the user does not respond within 5 minutes or if the user cannot see the agent UI, the default action is taken.

NOTE

Query rules are not allowed for Solaris users because they cannot interact with the local agent as on Windows and Linux systems. For Solaris users, the default action is always immediately taken.

Other actions include the following:

  • Monitor— Enables you to match a resource request and log an event based on its occurrence without the need to define the request as a deny, allow, or terminate.

  • Add or Remove to/from Application Class— Based on the resource request, you can add the process making the request to a dynamic application class or remove it from an application class if that is appropriate.

NOTE

When rules that are combined on a host conflict with one another, the resulting rule that is applied is determined by the precedence assigned to the action chosen in the rules. This precedence ordering process is covered in the section "Rule Precedence and Manipulation" later in this chapter.

Figure 4-6 shows an example of an action selection drop-down box.

Figure 4-6. Action Selection Drop-Down Box

[View full size image]

Understanding Query Options

Query rules can be an effective way to provide security controls while also allowing the user to make the ultimate decision on whether the requested resource should be allowed. In some environments where the user is considered "untrusted," you are not required to use query options but could opt to only use explicit allow, deny, or terminate actions within your policies.

NOTE

Query settings are covered in detail in Chapter 5, "Understanding Application Classes and Variables," and are only covered at a high level in this chapter.

When the query action is chosen for a rule, an additional Query Settings drop-down box appears. From this drop-down, you choose the query setting that should occur as a result of the resource request. This list is ordered according to the default action defined for the query setting created. For an illustration of the query action selection and query setting Configuration page, see Figure 4-7 and Figure 4-8, respectively.

Figure 4-7. Query Action Selection for a Rule

[View full size image]

Figure 4-8. Query Setting Configuration Page

[View full size image]

It is also very important to understand that the default action associated with a particular query is a very powerful and necessary setting. The default action is the action that will take place automatically on systems that cannot see the agent UI per policy definition and on Solaris systems that do not have an interactive agent UI option. In addition to being the default action, it tends to serve as a hint to the user as the option the security team prefers the user consider. This can be a much more powerful suggestion than some people think.

NOTE

An interesting way to use query rules is to use this feature without presenting the user an option other than the default. You can present the user an informational message upon resource request but only provide terminate or deny action(s) as selectable buttons.

Rule Precedence and Manipulation

As you combine rules into rule modules, conflicting rules in the combined set may occur. It is imperative that you understand how the CSA system dictates which rule will take effect based on precedence. The following actions are in order of precedence with the entries at the top taking precedence over lower actions:

  1. High priority terminate process

  2. High priority deny

  3. Allow

  4. Query user (terminate)

  5. Query user (deny)

  6. Query user (allow)

  7. Terminate process

  8. Deny

  9. Default action allow

  10. Add process to application class

  11. Remove process from application class

  12. Monitor

NOTE

Monitor rules are always processed along with other rules that may be enforcement in nature, regardless of precedence.

The combined rule set is ordered by the preceding action order for application on the host. For items that use the same action type, if logging is set, that rule takes precedence over rules that do not have logging set.

You can manually manipulate this order through the use of a few configuration options. On many of the rules that you can configure, you have seen the option Take Precedence over Other Rules of the Same Action Type. This option, when chosen for a rule, places that rule at the top of the rule application list when being ordered against rules of the same action type.

NOTE

When CSA combines rules into an active agent policy, the order of rule evaluation is action type, rule precedence check box, and finally logging enabled or disabled. The agent therefore resolves conflicts first by action precedence, next by the rule precedence override check box, and finally by whether logging is enabled if all other rule configuration matches.

Query rules also have a precedence or prioritized order of evaluation when applied in a combined policy on the host. The order is manipulated by the options available to the query rules. The order of precedence for query rules is as follows:

  • Challenge option chosen

  • Don t ask again chosen

  • Log

Other Common Rule Configuration Options

A few configurable parameters are common across many of the rules that you can define in CSA policies. The options are for the most part generic and for informational purposes. These options are logging, descriptions, and the Enabled check box.

Logging is an option available from rule configuration pages. The configuration is as simple as either checking or unchecking the associated Log check box. Checking the Log check box ensures that an event is logged to the CSA MC event log and the local csalog.txt file. By default, all actions are set to log other than the allow action.

Another field common to various rules is the Description field. This field and the Detailed Description field should be used to assist other administrators during the troubleshooting process.

A final shared configuration option is the Enabled check box. If this is checked, the rule is active and enforced, whereas rules that have this option unchecked are not enforced. This is an easy way to disable a rule without deleting it from the rule set immediately.

CSA Rule Types

You can use several rule types when building policies for agent-protected systems. These rules control access to resources and can use all of the previously defined shared configuration options such as state sets, logging, query settings, and various actions. This section describes the various rule types available to you.

NOTE

For the next several sections describing the various rule types available, the operating systems that can use the rule type are printed in brackets next to the name of the rule type. The operating systems supported are denoted using a W for Windows systems and a U for UNIX (Solaris and Linux) systems.

Agent Service Control [W and U]

You can use the agent service control rule to control or monitor a local administrator s ability to stop the agent service on the protected system, prevent the user from stopping agent controls by setting the slider bar in the CSA UI to the off position, as well as monitor any attempt to modify agent configuration, executable, or data files. This rule is extremely important because any attempt to uninstall the agent requires the ability to stop the agent service. Preventing service stoppage also prevents uninstallation.

NOTE

Agent self-protection is not a configurable option and is always functioning when the agent is running. Agent self-protection prevents an agent from being modified, which could result in a compromised or Trojan horse and cause weakened security policy along with the possibility of modified log files and other undesirable outcomes.

The agent service control rule configuration parameters are as follows, as shown in Figure 4-9:

  • Description and Detailed Description— Describe the rule to provide enough necessary information to aid in troubleshooting.

  • Enabled— Check the box to activate the rule.

  • Take the Following Action— Choose the appropriate action from the drop-down box.

    The options available are as follows:

    • High Priority Terminate Process

    • High Priority Deny

    • Allow

    • Query User (Deny, Allow, or Terminate)

    • Terminate Process

    • Deny

    • Add or Remove Process to/from Application Class

    • Monitor

    By default, Query User is chosen.

  • Log— Enable event log messages for this rule.

  • Take Precedence over Other Rules— Choosing this option ensures this rule has a higher precedence when ordered against other rules in the policy, including conflicting rules.

  • Applications in the Following Class— Choose the application class that identifies the process or application attempting to stop or modify the agent. By default, All Applications is the chosen class.

  • But Not in the Following Class— Choose any application class you want to exclude matching for this rule. The default is None.

  • Attempt to Stop the Agent Service— Check this check box to apply this rule to any attempt to stop the running service on the system that matches the preceding criteria.

  • Attempt to Modify Local Agent Configuration— Check this check box to apply this rule to any attempt to modify agent configuration, data, and program files. Although you cannot disable the ability to modify the agent files while the agent is running, you can monitor or tag the offensive process with this rule.

  • Save and Delete buttons— Commit or delete the changes to this rule.

Figure 4-9. Agent Service Control Rule

[View full size image]

Agent UI Control [W and U]

The agent UI control rule controls the user s ability to interact with the local security agent UI. The rule enables users to see the UI in the system tray as well as granularly control how much interaction is granted to the end user. Within this rule, you can provide user interaction capability such as the following:

  • Enable users to edit the local contact information associated with the agent

  • Enable users to modify agent security settings

  • Enable users to control the personal firewall and file protection mechanisms

NOTE

If this rule is not active on an agent, no user interaction is available because the default agent setting does not provide local interaction.

Figure 4-10 shows the agent UI control rule screen, which includes the following configuration parameters:

  • Allow User to Reset Agent UI Default Settings— Check this box to allow the local user to reset all user-changed settings and permanently cached entries to the factory default.

  • Allow User Interaction— Check this box to provide the visible tray icon and ability to receive pop-up messages and query messages. The user can also open the security agent UI to view the status of the agent, as well as view and clear query responses. This option also enables the user to choose from the following additional granular UI controls:

    • Allow User Access to Agent Configuration and Contact Information— Enables the user to perform a fast poll and enter contact information for this agent system.

    • Allow User to Modify Agent Security Settings— Provides the user the slider bar so that the user can possibly modify the local agent security level from off through high.

  • Allow User to Modify Agent Personal Firewall Settings— Enables the user to use the personal firewall and file protection controls. These controls are additive to the global policies defined and cannot override global policy, but rather further secure the system.

Figure 4-10. Agent UI Control Rule

[View full size image]

NOTE

The lists of parameters in this chapter focus on those features that are new or unintuitive. To reduce redundant explanations, parameters that appear in multiple rule screens do not appear in each list.

If the user has multiple agent UI control rules applied, a visible UI overrides an invisible UI. Also, any other check box in this rule type, if checked, overrides an unchecked check box from another conflicting rule.

Application Control [W and U]

The application control rule is used to control which applications can run on host systems. If you are attempting to prevent an application or process from executing on a host, use this type of rule. You can also use this rule to prevent a running application from starting other undesired processes. For example, you might want to enable the user to use a command shell such as cmd.exe but never want any other application to attempt to launch a shell (because this is typically a trademark of a virus, worm, or poor programming).

The application control rule configuration parameters include the following:

  • Take the Following Action— Choose the appropriate action from the drop-down box. The options available are as follows:

    • High Priority Terminate Process

    • High Priority Deny

    • Allow

    • Query User (Deny, Allow, or Terminate)

    • Terminate Process

    • Deny

    • Add/Remove Current/New Process to/from Application Class

    • Monitor

    By default, Allow is chosen.

  • Applications in the Following Class— Choose the application class that identifies the process or application attempting to execute on the system or attempting to start other processes. By default, All Applications is the chosen class.

  • But Not in the Following Class— Choose any application class you want to exclude matching for this rule. The default is None.

  • Attempting to Run Applications in the Following Application Class— Choose the application class that identifies the process attempting to be started by the previously identified process or application. By default, this is set to All Applications.

  • But Not in the Following Class— Choose any application class you want to exclude as a started process. The default is None.

Figure 4-11 shows an application control rule configured to prevent any application from attempting to spawn a command shell. You could very easily also create a rule of this type to prevent undesired applications from executing on corporate resources. You would first create an application class and file set combination that defines the list of undesired applications by filename or dynamic link library (DLL). You would then apply those building blocks to the application control rule as applications that should not run. Building blocks such as application classes and variables are covered in detail in their respective chapters throughout this book.

Figure 4-11. Configuring an Application Control Rule

[View full size image]

Clipboard Access Control [W]

The clipboard access control rule proves useful in combination with other rules when you are trying to protect data from theft. If users can open a file, they can typically perform a copy function and move the chosen data from the file to the Windows clipboard. After that data is in the clipboard, users could copy the information to another file (or possibly e-mail to circumvent file control mechanisms). The clipboard access control rule only allows data moved within a defined application to be copied to authorized locations, while other applications can continue to use the clipboard function unimpeded. As an added feature, after this rule has been activated for a specific application, the Windows Print screen capability is also disabled. You cannot, however, prevent the user from using a digital camera or camera phone (hence the need for a physical security policy).

Figure 4-12 shows the clipboard access control rule screen, which includes the following configuration parameters:

  • Do Not Allow Other Applications to Read Clipboard Content Written by the Following Application Class— Assign an application class to this rule type to specify the applications that should be allowed to share the clipboard data while other applications not defined by the class should have no access to the data. The default is All Applications.

  • But Not in the Following Class— Choose any application class you want to provide clipboard access to the protected data. The default is None.

Figure 4-12. Clipboard Access Control Rule

[View full size image]

COM Component Access Control [W]

The COM component access control rule is a mechanism that enables you to define which COM objects can be accessed by specific applications. COM objects allow for seamless interaction between processes on Windows systems but can be compromised just as seamlessly. As a result, you may want to control COM object access.

Figure 4-13 shows the COM component access control rule screen, which includes the following configuration parameters:

  • Take the Following Action— Choose the appropriate action from the drop-down box. The options available are as follows:

    • High Priority Terminate Process

    • High Priority Deny

    • Allow

    • Query User (Deny, Allow, or Terminate)

    • Terminate Process

    • Deny

    • Add/Remove Process to/from Application Class

    • Monitor

    By default, Allow is chosen.

  • Applications in the Following Class— Choose the application class that identifies the process or application attempting to access the COM object(s) to be identified. By default, All Applications is the chosen class.

  • But Not in the Following Class— Choose any application class you want to exclude matching for this rule. The default is None.

  • Attempting to Access a COM Component in the Following Component Set— Choose the COM component set that identifies the COM object(s) you want to limit. By default, this is set to None. A COM component set is a variable that identifies the necessary components. You could also use literal terminology to refer to the COM object if desired.

Figure 4-13. COM Component Access Control Rule

[View full size image]

Connection Rate Limit [W and U]

The connection rate limit rule controls the number of connections that can be opened both inbound and outbound on a system. This rule assists in preventing DoS attacks on the locally protected system by limiting the number of inbound connections received by the host from all hosts or on a per-host basis. You can also limit the number of outbound connections the machine can create to another host, which prevents the spread of DoS attacks. The enforced rate limits can also pertain to specific applications creating or terminating the connections or to all applications on the system.

Figure 4-14 shows the connection rate limit rule screen, which includes the following configuration parameters:

  • Take the Following Action— Choose the appropriate action from the drop-down box. The options available are as follows:

    • High Priority Terminate Process

    • High Priority Deny

    • Allow

    • Terminate Process

    • Deny

    • Add/Remove Process to/from Application Class

    • Monitor

    By default, Allow is chosen.

  • Applications in the Following class— Choose the application class that identifies the process or application that should be rate limited. By default, All Applications is the chosen class.

  • But Not in the Following Class— Choose any application class you want to exclude matching for this rule. The default is None.

  • Attempting to Act As A— Choose Client, Server, or Client-or-Server from the drop-down list to state whether the rate limit rule being created will limit inbound connections, outbound connections, or both.

  • Communicating With— Choose All or Specific Hosts from the drop-down box, indicating whether the rate limit should be an overall rate limit or applied on a per-host basis.

  • Over Limit ofnumberNetwork Connections— Enter the number of network connections pertaining to the configured rate limit. By default, the number is 100 per host.

  • InnumberMinutes— Enter the time interval to monitor the connection defined. By default, this is 5 minutes.

Figure 4-14. Connection Rate Limit Rule

[View full size image]

NOTE

You should not typically choose Terminate Process as an action for this type of rule when setting the rule for inbound connections because a DoS attempt or high threshold of normal traffic will shut down the process answering the connections. You may, however, want to choose Terminate Process when writing the rule to prevent outbound DoS attempts.

Data Access Control [W and U]

You should apply the data access control rule to web server systems. This type of rule monitors inbound web traffic and more specifically the Uniform Resource Identifier (URI) portion of the web requests. When watching URI traffic, the rule is specifically looking for malformed requests that may adversely impact the web server. The majority of known malformed requests are listed in the data set provided in the CSA MC installation, but you can create your own sets to catch new or specialized attacks.

This rule requires that the local system have the CSA data filter installed for the rule to be enforced. On Windows platforms, IIS and Apache installations are detected at agent installation time and the data filter is automatically loaded. If it is not loaded, you need to manually install the data filter by using the local csa_datafilter installation file. The data filter may also need to be manually installed if the web server was not loaded in the default directory. On UNIX platforms, the data filter always requires a manual installation.

NOTE

The URI in a web request contains the URL and the more detailed GET requests and parameters.

Figure 4-15 shows the data access control rule screen, which includes the following configuration parameters:

  • Take the Following Action— Choose the appropriate action from the drop-down box. The options available are as follows:

    • High Priority Terminate Process

    • High Priority Deny

    • Allow

    • Query (Deny, Allow, or Terminate)

    • Terminate Process

    • Deny

    • Add/Remove Process to/from Application Class

    • Monitor

    By default, Allow is chosen.

  • Applications in the Following Class— Choose the application class that identifies the process or application that should be monitored for inbound URI traffic. By default, All Applications is the chosen class; however, only Apache, IIS, and iPlanet are supported.

  • But Not in the Following Class— Choose any application class you want to exclude matching for this rule. The default is None.

  • Attempt to Access These Data Sets— Choose the data set variable containing the URI patterns you want to detect or enter literal values.

Figure 4-15. Data Access Control Rule with IIS Data Set Definition

[View full size image]

File Access Control [W and U]

The file access control rule provides a mechanism to control which processes can read or write files or directories. These rules can lock down access of certain files and directories that need to be protected or ensure that certain types of applications can only read specific file types. When this rule applies to UNIX systems, understand that applying this rule to a symbolic link only protects the link and not the target file. You must specify that file as well to protect it.

Figure 4-16 shows the file access control rule screen, which includes the following configuration parameters:

  • Take the Following Action— Choose the appropriate action from the drop-down box. The options available are as follows:

    • High Priority Terminate Process

    • High Priority Deny

    • Allow

    • Query (Deny, Allow, or Terminate)

    • Terminate Process

    • Deny

    • Add/Remove Process to/from Application Class

    • Monitor

    By default, Allow is chosen.

  • Applications in the Following class— Choose the application class that identifies the process or application that this rule will impact.

  • But Not in the Following Class— Choose any application class you want to exclude matching for this rule. The default is None.

  • Attempt the Following Operations— Choose a combination of Read File, Write File, and Write Directory (create/delete/rename).

  • On Any of These Files— Enter literal file or directory entries (with wildcards if necessary). You can also use file set variables that include the necessary values. You can also use network share locations if necessary. Another mechanism provided by the CSA architecture is the use of special variables such as @dynamic, @local, @system, @removable, and @floppy.

Figure 4-16. File Access Control Rule

[View full size image]

File Version Control [W]

The file version control rule enables the security team to enforce which versions of an application are allowed or denied to execute on a system. This rule proves useful when you want your user base to run an application but there is a specific version of the application that includes a known vulnerability or bug. You can write a rule to prevent that specific version of the program from running on a CSA-protected system while allowing other versions or only a specific version of the application to run.

Figure 4-17 shows the file version control rule screen, including the following configuration parameters:

  • Take The Following Action— Choose the appropriate action from the drop-down box. The options available are as follows:

    • High Priority Terminate Process

    • High Priority Deny

    • Allow

    • Query (Deny, Allow, or Terminate)

    • Terminate Process

    • Deny

    • Add/Remove Process to/from Application Class

    • Monitor

    By default, Allow is chosen.

  • An Execution of the Following File— Enter the filename without path information. This can be an EXE, DLL, or OCX file without wildcards.

  • With Version Within These Version Ranges— Enter the version ranges you want to allow or prevent from running on the system. You can enter a specific version, such as 4.5.23, or a range, such as 4.5.23-4.7.60. You can attempt to get the version information by right-clicking the file and selecting properties or checking with the manufacturer. You can see an example of a file version for Internet Explorer in Figure 4-18.

    Figure 4-18. Locating the File Version of iexplore.exe

Figure 4-17. File Version Control Rule

[View full size image]

Kernel Protection [W]

The kernel protection rule prevents unauthorized access to the operating system by not allowing drivers to dynamically load after system startup unless an exception for that specific driver has been made.

Figure 4-19 shows the kernel protection rule screen, which includes the following configuration parameters:

  • Take the Following Action— Choose the appropriate action from the drop-down box. The options available are as follows:

    • High Priority Deny

    • Allow

    • Deny

    • Add Process to Application Class

    • Monitor

    By default, Allow is chosen.

  • Modules Load After System Startup— Checking the check box enforces a rule that takes the associated action if a module loads after system startup.

  • Included Modules— Insert the file set to match, or enter the literal value. By default, the value is None, which disallows drivers from loading after system startup unless specifically mentioned here when the action is set to Deny.

  • Modules Modify Kernel Functionality— This rule monitors attempts to modify system files but does not prevent the attempts. You could use a dynamic application class with this rule to create a restrictive policy as a result.

  • Included Module Hashes— Use only the wizard to edit the entries in this field as part of a triggered event. This field is not intended to be manually edited.

  • Included Code Patterns— Use only the wizard to edit the entries in this field as part of a triggered event. This field is not intended to be manually edited.

Figure 4-19. Kernel Protection Rule

[View full size image]

NOTE

Windows updates and certain patches may trigger the kernel protection rule. If you allow the patch to install, you might need to write an exception to the particular installation to ensure a successful patch process. As always, testing and tuning in a test environment is the best approach before a production implementation.

Network Access Control [W and U]

You can use the network access control rule to control network access to and from specific applications as well as reporting applications attempting to listen on ports prior to receiving an active inbound connection. This rule allows granularity down to the protocol and port level as well as IP address ranges associated with the connectivity.

Figure 4-20 shows the network access control rule screen, which includes the following configuration parameters:

  • Take the Following Action— Choose the appropriate action from the drop-down box. If you use Query for this type of rule, the server automatically uses the default query action to enable a successful connection if necessary, but the user is still prompted. For further requests, the cached query response is automatically used in place of the default action.

  • Log check box— Enable event log messages for this rule. For this particular rule type, even when Log is checked, broadcast traffic on UDP ports will not trigger an event.

  • Applications in the Following Class— Choose the application class that identifies the process or application that should be allowed or denied network access. By default, All Applications is the chosen class.

  • But Not in the Following Class— Choose any application class you want to exclude matching for this rule. The default is None.

  • Attempting to Act As A— Choose the Client, Server, Client-or-Server, or Listener. If you choose Listener, this rule detects applications that are listening on a port prior to detecting inbound communication. This is a great way to detect a Trojan horse that was loaded prior to the agent installation.

  • For Network Service— Specify the network service by literal protocol/port such as TCP/25 or network service set.

  • Communicating with Host Addresses— Choose the appropriate network address set or literal IP address or range for the remote IP address involved in the conversation. By default, the address is 0.0.0.0-255.255.255.255.

  • Using These Local Addresses— Choose the appropriate network address set or literal IP address related to the local IP address for the conversation. By default the address is 0.0.0.0-255.255.255.255.

Figure 4-20. Network Access Control Rule

[View full size image]

Network Shield [W and U]

The network shield rule requires the use of the network shim, which you can install on the system during installation of the CSA software. This rule provides various IP protocol stack-hardening mechanisms that can granularly be enabled and disabled during rule configuration.

Figure 4-21 shows the network shield rule screen, which includes the following configuration parameters:

  • Take the Following Action— Choose the appropriate action from the drop-down box. The options available are as follows:

    • High Priority Deny

    • Allow

    • Deny

    • Add Process to Application Class

    • Monitor

    By default, Allow is chosen.

  • IP Security Checks:

    • Invalid IP Header— Perform a consistency check on the IP header, the length of the header, and the number of bytes in the header. Drop invalid packets.

    • Invalid IP Address— Choose this option to prevent known invalid IP addresses or usage. Source multicast addresses and destination multicast addresses over TCP connections are examples of invalid IP addresses.

    • Source Routed Packets— Match packets that are source routed.

    • Trace Route— Match traceroute packets.

  • Transport Security Checks:

    • Invalid TCP/UDP/ICMP Header— Similar to the IP header checks, including flags and flag combinations.

    • TCP SYN Flood— Detect SYN flood attempts. This option does not function for UNIX systems because they already have SYN flood detection mechanisms.

    • TCP Blind Session Spoofing Attempts— Make session numbers unpredictable. This option does not function for UNIX systems because they already have unpredictable session numbers.

    • TCP/UDP Port Scans— Prevent the system from responding to port scan attempts and prevent sending connection error messages. This option also triggers a global event correlation on the CSA MC if several systems correlate a port scan attempt over a set period of time.

    • ICMP Ping Message— Prevent ICMP scanning attempts.

    • ICMP Configuration Message— Prevent ICMP configuration from occurring.

    • ICMP Information Message— Prevent responding to ICMP information messages.

    • ICMP Covert Channel— Cause the system to drop unsolicited echo response packets that could carry traffic as a backdoor channel to the system through firewalls and other filtering devices.

    • Malicious Packet— Block packets that are known malicious packet types even if they are legally permissible by RFC (Request For Comment) IP standards.

  • System Startup Security Checks:

    • Unrestricted Network Connectivity During Boot— Prevent attacks to services prior to the agent starting on Windows systems only.

  • Communicating with Host Address— Enter the literal host or subnet address or use a network address set to identify the hosts to which this rule applies. You can use this field in combination with an allow rule to allow known scanners on your network to continue to probe the systems without creating unnecessary log data.

  • Using These Local Addresses— Set the local address that this rule pertains to, such as @local, or a specific address or set variable.

Figure 4-21. Network Shield Rule Configuration

[View full size image]

NT Event Log [W]

The NT event log rule provides a mechanism for correlating NT event log messages in the CSA MC event log. You can report wide ranges of events or specific events for correlation. If you decide to use this rule to send antivirus information to the event log, you can correlate the events on the CSA MC.

Figure 4-22 shows the NT event log rule screen, which includes the following configuration parameters:

  • Event Log Type— Choose a combination of system, application, and security logs you want to monitor.

  • Event Source— Enter the application or component name that is the source of the event in the log. The default is All, but could be a source, such as NtServicePack, which will pertain to events regarding the installation of a service pack on a system and may be very valuable information. Other event sources include DNS, DHCP, and antivirus packages. Figure 4-23 displays an example from a production NT Event Viewer system log.

    Figure 4-23. NT Event Viewer Entry

    [View full size image]

  • Severity— Choose all severity levels that are appropriate: Information, Warning, Error, Audit Success, or Audit Failure.

  • Event Code— Set this to a specific event code to identify a log event to monitor and report. By default, this is set to All Events.

Figure 4-22. NT Event Log Rule

[View full size image]

NOTE

You can locate event codes by searching the Microsoft website or validating the information in production event logs.

Registry Access Control [W]

The registry access control rule is a control mechanism that can disallow or allow applications writing to the registry or specific keys and hives.

Figure 4-24 shows the registry access control rule screen, which includes the following configuration parameters:

  • Take the Following Action— Choose the appropriate action from the drop-down box. The options available are as follows:

    • High Priority Terminate Process

    • High Priority Deny

    • Allow

    • Query User (Deny, Allow, or Terminate)

    • Terminate Process

    • Deny

    • Add/Remove Current/New Process to/from Application Class

    • Monitor

    By default, Allow is chosen.

  • Applications in the Following Class— Choose the application class that identifies the process or application attempting to write to the registry. By default All Applications is the chosen class.

  • Attempt to Write Any of These Registry Entries— Choose the registry set or enter the literal registry value that you want to identify for this rule. By default, this is set to None.

Figure 4-24. Registry Access Control Rule

[View full size image]

Service Restart [W]

With the service restart rule, CSA can automatically restart Windows services that stop or are not responding to requests.

Figure 4-25 shows the service restart rule screen, which includes the following configuration parameters:

  • Restart the Following Service— Enter the service name here as listed in the services control panel or by issuing the net start command.

  • When Not Responding to Service Control Manager— Choose this option to cause CSA to attempt to restart the service if the service is not responding for any reason, including failure.

  • When Not Responding to Network Requests for Service— Test the service for connectivity via the following several protocols: CTA EAP, Cisco VPN service protocols, DHCP/BOOTP, DNS, e-mail, ephemeral port ranges, FTP client data channel, FTP control channel, FTP server data channel, HTTP, IKE, instant messenger protocols, IRC user, Kerberos, LDAP, Location Service, Microsoft-DS, MMCC, MS SQL Server, NameServer, NetBIOS, NetBIOS Datagram Service, NetBIOS Datagram Service Protocol, NetBIOS Name Service, NetBIOS Name Service Protocol, NetBIOS Session Service, NNTP, Real Audio, Real Audio Server data channel, Rexec, Rlogin, SMB and NMB, SNMP, SOCKS, SSH, TCP, TCP ephemeral server ports, Telnet, TFTP, TFTP data channel, time protocols, UDP, or UDP ephemeral server ports. The network shim must be installed for this to work.

Figure 4-25. Service Restart Rule

[View full size image]

Figure 4-25 shows a service restart rule along with a typical Windows net start command executed in a command shell. This list of services that result from the Windows command serve to illustrate the exact naming of a service that must be used when configuring a service restart rule. From the figure, you can see the DNS Server service name matches exactly as it is listed by Windows and will therefore be successfully implemented in the CSA policy.

Sniffer and Protocol Detection [W]

The sniffer and protocol detection rule logs events when non-IP protocols and packet sniffers are detected on the agent-protected system. Sniffers loaded on systems can steal proprietary traffic traversing the network, which may include intellectual data, e-mails, and username/password combinations. It is important that any system running as a sniffing entity be detected immediately to prevent loss of confidentiality and integrity. Non-IP protocols should also be treated with care because they could be used as backdoor transport mechanisms that circumvent various protective mechanisms such as network access control rules, network firewalls, and IDS/IPS appliances.

Figure 4-26 shows the sniffer and protocol detection rule screen, which includes the following configuration parameters:

  • Enabled— Uncheck the box to deactivate the rule from any active running policy without permanently removing the rule from the system. You use this option when testing and tuning policy so that you can selectively turn off a rule without the need to re-create it later, which would be the case if you instead deleted the rule.

  • Exclude the Following Standard Protocols— Choose the predetermined common non-IP protocols from the list using the Shift-mouse click or Ctrl-mouse click functionality for multiple selections. The list includes TCP/IP Protocol, AppleTalk Protocol, DLC Protocol, NDIS Proxy, NetBEUI Protocol, NWLink IPX/SPX Compatible Transport, QoS Packet Scheduler, Remote Access NDIS TAPI, Remote Access NDIS WAN, and Remote Access PPPOE.

  • Exclude the Following Non-Standard Protocols— Enter nonstandard protocols and packet sniffers here, such as PacketDriver. The default entry is None.

Figure 4-26. Sniffer and Protocol Detection Rule

[View full size image]

System API [W]

The system API rule enables you to prevent Trojan horse behavior and malicious code attempting to execute on the endpoint. Prior to CSA version 4.5, this functionality was nonconfigurable. This rule will most likely require you to create exceptions during the tuning process. Items that would require tuning include poorly written applications and software distribution mechanisms.

Figure 4-27 shows the system API rule screen, which includes the following configuration parameters:

  • Take the Following Action— Choose the appropriate action from the drop-down box. The options available are as follows:

    • High Priority Terminate Process

    • High Priority Deny

    • Allow

    • Query User (Deny, Allow, or Terminate)

    • Terminate Process

    • Deny

    • Add/Remove Current/New Process to/from Application Class

    • Monitor

    By default, Allow is chosen.

  • Applications in the Following Class— Choose the application class that identifies the process or application attempting to perform the chosen actions. By default All Applications is the chosen class.

  • But Not in the Following Class— Choose any application class you want to exclude matching for this rule. The default is None.

  • System Information Checks:

    • Access Local Configuration Information— Detect code executing on a protected system that is attempting to read from the registry.

    • Access Local Password Information— Choose to detect processes that attempt to read and steal local passwords.

  • System Monitoring Checks:

    • Monitor Media Devices— Use this function to prevent devices connected to the system from grabbing local media streams. You also can use the Included Patterns input field to allow certain media devices to function without triggering the rule. To allow a specific media device to function appropriately, you specifically name the device and use an allow action. This rule can prevent Trojan horses from listening on a local microphone or from receiving pictures from a webcam. The excluded devices should use device\port as the entry method such as webco\camera.

    • Trap Keystrokes— Detect devices that hook the keyboard. Processes that hook the keyboard are attempting to capture keystrokes as they are entered by the user. This is a typical behavior exhibited by Trojan horses. You may need to write rules of this type that allow (or exclude) certain processes from triggering this detection method because certain applications may need to legitimately trap keystrokes.

  • System Modification Checks:

    • Access Physical Memory— Prevent processes from directly accessing physical memory. Typically, applications should execute using virtual memory restrictions.

    • Download and Invoke ActiveX Controls— Detect applications that attempt to load and execute ActiveX controls. The application would most commonly be a web browser, but could also be malicious code.

    • Inject Code into Other Applications— Detect code that has been marked as "downloaded" when it attempts to inject code into space owned and used by another application.

    • Write Memory Owned by Other Applications— Detect an application that attempts to use or tamper with memory space being used by another application. Also, detect Trojans that can be hidden in another application as it attempts to access resources.

  • Atypical System Behavior Checks:

    • Access System Functions from Code Executing in Data or Stack Space— Prevent buffer-overflow attacks. You also have the option to enter, manually or via the wizard, excluded patterns that should not trigger this rule, because some types of applications may perform using this method either intentionally or unintentionally (poor programming).

    • Handle Exceptions— Detect applications that are running exception-handling routines. This is not a normal behavior for applications and should be noted.

    • Invoke Unusual System Calls— Enable a trigger when an application attempts to use a system call that is rarely or never used in today s programs. These calls can have vulnerabilities associated with them that may be known or unknown, and you should prevent them because any attempt to use an uncommon system call is suspicious at best. You can use the Pattern Inclusion field (along with an allow rule) to allow certain applications that require these calls to continue to function.

Figure 4-27. System API Rule

[View full size image]

Buffer Overflow [U]

The buffer overflow rule is a UNIX-specific rule that has some similar functionality to that provided by the Windows-only system API rule. The buffer overflow rule assists in detecting and preventing buffer overflows from resulting in escalating privileges of the user attempting the buffer overflow. A buffer overflow is most dangerous when it occurs in a program that has higher privileges than a user. The user could cause a buffer overflow to occur and when escaping the failed program gain the access capabilities previously granted to the application itself.

Figure 4-28 shows the buffer overflow rule screen, which includes the following configuration parameters:

  • Take the Following Action— Choose the appropriate action from the drop-down box. The options available are as follows:

    • High Priority Terminate Process

    • Allow

    • Query User (Allow or Terminate)

    • Terminate Process

    • Monitor

    By default, Allow is chosen.

  • Attempt the Following Operations— Choose from the following options:

    • Attempted Buffer Overflow Detection— Attempt to detect buffer overflows in UNIX executables typically as a result of attempted stack buffer overflows in LIBC routines.

    • Execute a System Call in an Unsafe Context— Stop certain system calls that grant additional privileges or start additional processes from attempting to do so if they are coming from an application in a corrupted or invalid context.

    • Process Terminated by Operating System Due to Executing Code in Stack Space— Force the use of the noexec_user_stack system variable with all executing processes. You can only monitor the interaction of this function and cannot use Deny.

    • Process Terminated Due to Signal or Internal Error— Enable this feature to monitor when a process ends because of signal or internal errors and report to the event log.

    • Use of an Unsafe Format in PRINTF Call— Prevent the %n format qualifier for printf() calls because it could be used to gain access to program flow information.

Figure 4-28. Buffer Overflow Rule

[View full size image]

Network Interface Control [U]

The network interface control rule is a UNIX-specific rule that prevents a system from being able to place an interface in Promiscuous Mode. When a network interface is in Promiscuous Mode, it can act as a sniffer, which can be used to steal packets, including proprietary data and name and password information.

Figure 4-29 shows the network interface control rule screen, which includes the following configuration parameters:

  • Take the Following Action— Choose the appropriate action from the drop-down box. The options available are as follows:

    • High Priority Terminate Process

    • High Priority Deny

    • Allow

    • Query User (Deny, Allow, or Terminate)

    • Terminate Process

    • Deny

    • Add/Remove Current/New Process to/from Application Class

    • Monitor

    By default, Allow is chosen.

  • Applications in the Following Class— Choose the application class that identifies the process or application attempting to place the NIC in Promiscuous Mode. By default All Applications is the chosen class.

  • But Not in the Following Class— Choose any application class you want to exclude matching for this rule. The default is None.

  • Attempt to Open a Stream Connection to the NIC Driver— Prevent stream connections to the NIC. You might need to write an allow rule to allow certain applications on your network to continue to function using stream connections.

  • Attempt to Put the NIC into Promiscuous Mode— Detect and prevent placing the NIC in Promiscuous Mode.

Figure 4-29. Network Interface Control Rule

[View full size image]

NOTE

Depending on the action you choose for the network interface control rule, checking one of the two check box actions at the bottom of the Configuration page will automatically choose the other because of the dependent nature of the two functions.

Resource Access Control [U]

The resource access control rule is a UNIX-specific rule that you can use to prevent symbolic link attacks from occurring on the system. This prevents links that are suspicious in how they are used as defined in the configuration parameters that follow.

Figure 4-30 shows the resource access control rule screen, which includes the following configuration parameters:

  • Symbolic Link Protection— Check this box to enable the CSA to prevent common symbolic link attacks. A savvy user might attempt to create a symbolic link to a file that does not yet exist and use it to gain higher permissions or the ability to change the file it is linked to. Symbolic Link Protection prevents a link from functioning if

    • The parent directory is a temporary directory, such as /tmp.

    • The link s owner is not the same as the parent directory.

    • The link s owner is different from the UID of the process.

Figure 4-30. Resource Access Control Rule

[View full size image]

Rootkit/Kernel Protection [U]

The rootkit/kernel protection rule is a UNIX-specific rule that prevents unauthorized drivers from loading after boot time unless specifically allowed to dynamically load. This is similar to the Windows-only kernel protection rule.

Figure 4-31 shows the rootkit/kernel protection rule screen, which includes the following configuration parameters:

  • Take the Following Action— Choose the appropriate action from the drop-down box. The options available are as follows:

    • High Priority Terminate Process

    • High Priority Deny

    • Allow

    • Query User (Deny, Allow, or Terminate)

    • Terminate Process

    • Deny

    • Add/Remove Current/New Process to/from Application Class

    • Monitor

    By default, Allow is chosen.

  • Applications in Any of the Following Class— Choose the application class that identifies the process or application attempting to dynamically load drivers. By default All Applications is the chosen class.

  • But Not in the Following Class— Choose any application class you want to exclude matching for this rule. The default is None.

  • Attempt to Load the Following Modules— When used in an allow rule of this type, use this file to exclude specific drivers that are allowed to load. The default entry here is None.

Figure 4-31. Rootkit/Kernel Protection Rule

[View full size image]

Syslog Control [U]

The syslog control rule is a UNIX-specific rule that can assist in the correlation of syslog events into the central CSA MC event log database. This is quite similar to the Windows-specific rule that took events from the NT event log and placed them in the CSA MC database.

The syslog control rule configuration parameters are as follows:

  • Take the Following Action— Choose the appropriate action from the drop-down box. The options available are as follows:

    • High Priority Terminate Process

    • High Priority Deny

    • Allow

    • Query User (Deny, Allow, or Terminate)

    • Terminate Process

    • Deny

    • Add/Remove Current/New Process to/from Application Class

    • Monitor

    By default, Allow is chosen.

  • Event Source— Enter the syslog event source code information here that you want to match or exclude as per the rule definition. By default, All is chosen.

  • Facility— Using the multiselection tool, choose the appropriate facilities from the list of options: auth, cron, daemon, kern, local0 through local7, lpr, mail, news, resv9 through resv14, syslog, user, or uucp.

    Figure 4-32. Syslog Control Rule

    [View full size image]

  • Priority— Choose all the priority levels that should match: Debug, Information, Notice, Warning, Error, or Alert and Above.

  • Message Pattern— Enter a literal string that should be in the message for it to trigger the rule. The default is All, but you can edit it to a specific value. An example is a literal such as packet dropped.


CSA Rule Modules

Rule modules group rules or sets of rules that serve a similar purpose. After you group the rules, you can apply the rule module where necessary to specific policies. The CSA product includes several rule modules that serve functional purposes, but you can also create additional rule modules that apply to your specific environment and user base.

The CSA architecture provides two types of rules for application: enforcement and detection. Enforcement rules either allow or deny actions from occurring. Detection rules monitor rules that do not enforce compliance or rules that tag processes to application classes and do not take enforcement actions themselves.

Working with Rule Modules

The CSA MC separates rule modules into two groups: UNIX and Windows. To access the predefined rule module list, which is also the page where you would begin to create your own new modules, choose Configuration > Rule Modules [UNIX] or Rule Modules [Windows]. Figure 4-33 shows the Windows Rule Modules screen.

Figure 4-33. Windows Rule Module Screen

[View full size image]

From this page, you can perform the following actions, which are discussed in the next few sections:

  • Open and view a rule module— Click the rule module name.

  • View the rules in a specific rule module— Choose the link on the number of rules listed next to the rule module name.

  • Sort the view— Display a specific operating system rule module using the drop-down box in the upper-left corner of the screen.

  • Create a new rule module— Click the New button.

  • Delete rule module(s)— Choose the appropriate check box(es) and click Delete.

  • Clone a rule module— Check the check box next to the rule module you want to clone and click the Clone button. This is handy when creating a similar rule module for a different operating system. The rules in the original module are also cloned, so you can edit the newly cloned module and rules without fear of impacting the original rule module.

  • Compare two rule modules— Check the two check boxes of the modules you want to compare, and then click the Compare button to view the similarities and differences.

Comparing Rule Modules

On occasion, you might want to compare two rule modules to find the similarities or differences between them. After choosing the two rule modules you want to compare and clicking the Compare button, a comparison page displays, as shown in Figure 4-34. This page presents a great deal of information, including all configuration parameters associated with the rule modules and all rules (including rule details) for the rule modules. The differences between the two modules display in red to help aid in picking out the differences. Similar rules are placed side by side, and rules with no similar counterpart are left blank on the opposite side of the comparison page.

Figure 4-34. Rule Module Comparison Page

[View full size image]

Also, notice that check boxes appear near the "uncommon" rules on the comparison screen. You can check the box next to the rule you want to copy and then click the Copy button at the bottom of the screen to copy the rule to the other module, a different module, or a new module. You can also click the Delete button to remove a rule from a policy from this view.

Creating a Rule Module

More often than not, you will need to create your own rule modules to serve a purpose that is not accommodated by the built-in modules. To create a new rule module and view the settings available at the rule module level, perform the following steps, which correspond to Figure 4-35:

Step 1. | Click the New button on the Rule Modules page.
Step 2. | Enter the name and description for the rule module.
Step 3. | Choose the operating systems that can use the module. The options here are located in the drop-down box and include the operating systems available for selection, which could be granular or wide in approach.
Step 4. | Choose whether the rule module should be placed in Test Mode. In CSA version 4.5, you can now place the individual rule modules in Test Mode while leaving all other mechanisms on the agent in an Enforcement Mode. This is a great way to test out new application controls without impacting the already baselined usability of the other agent-protective mechanisms.
Step 5. | Choose the state conditions that should apply to this rule module. You can have rule modules that only apply based on user and system states.
Step 6. | Click Save or Delete as appropriate for the task at hand.

Figure 4-35. Viewing and Creating a Rule Module

[View full size image]

At the top of the specific rule module page, you see the following quick links options:

  • Modify Policy Associations— Displays the policy that the rule module is attached on the right side of the screen and the available policies on the left side of the screen, as shown in Figure 4-36.

    Figure 4-36. Modifying the Attached Policy Information

    [View full size image]

  • Modify Rules— Displays the rules attached to the policy in the prioritized order and are separated by enforcement and detection rules. You can add rules to the module by clicking the Add Rule link and choosing the rule you want to create. You can also check the check box adjacent to a rule you want to enable, disable, or delete (corresponding to the buttons on the bottom of the page) from the rule module. In addition, you can use the Copy feature on the page to copy a rule or rules to another policy easily and quickly. (See Figure 4-37.)

    Figure 4-37. Modifying the Rules in the Rule Module

    [View full size image]

  • Explain Rules— Displays a verbose readable version of the rule module and associated rules. The rules are divided into sections so that you can quickly locate the type of information you are attempting to find. (See Figure 4-38.)

    Figure 4-38. Explain Rules

    [View full size image]

  • View Change History— Displays a filtered view of the audit trail, which represents all the changes made to this rule module. (See Figure 4-39.)

    Figure 4-39. Viewing the Rule Module Change History

    [View full size image]

  • Consistency Check— Displays whether the rule module contains any operating system rule-specific conflicts. In version 4.5, a consistency checking feature will verify that the rule module for a specific operating system is not attempting to use any rules or variables that do not apply to that operating system, such as Windows directory paths versus UNIX directory paths. (See Figure 4-40.)

    Figure 4-40. Performing the Consistency Check

    [View full size image]

Using CSA Predefined Rule Modules

Several rule modules that come installed with the CSA MC server can aid in the deployment and testing of the product. Some of the rule modules included are as follows:

  • E-Mail Protection

  • Apache Web Server

  • Cisco VPN Client

  • CiscoWorks Base Security

  • CiscoWorks CSA MC SQL Server

  • SendMail

  • Samba

  • Data Theft Prevention

  • DHCP Server

  • DNS Server

  • Microsoft Office

This is only a sample of the rule modules included with the product. To view the included rule modules on your installation, choose Configuration > Rule Modules [UNIX] or Rule Modules [Windows] > All.

Figure 4-41 shows the predefined rule modules.

Figure 4-41. Predefined Rule Modules

[View full size image]

NOTE

This book does not attempt to explain the predefined rule modules and policies shown in Figure 4-41. These policies change over time, and the best method available for those wanting to better understand those modules is to investigate the locally installed modules and policies personally.

To view the rule modules and better understand their function, click the name and then choose Modify Rules or Explain Rules from the quick links menu.


CSA Policies

Policies are combinations of rule modules that serve a specific purpose. You might, for example, create a policy to control network access allowed by workstations in your environment. This policy could include multiple rule modules designed for specific operating systems and functional controls. When you combine the rule modules into a policy, you can apply the policy to groups and deploy them to active agent systems. Policies follow the same precedence rules described earlier in the section "Rule Precedence and Manipulation" because the rules from various modules are combined into a single policy. It is important that you review the precedence rules and understand how policy is combined and the resulting rule sets are implemented on the endpoints.

To view or configure a policy on the CSA MC, choose Configuration > Policies. As shown in Figure 4-42, the same options are available for managing policies on the CSA MC that are available for the rule modules. You are allowed to create, delete, clone, or compare policies. This page lists the configured policies on the system, including the predefined policies shipped with the product. As you saw earlier in the Rule Module page in Figure 4-33, the Policies page includes links and information related to policy name, number of modules included, and description.

Figure 4-42. Predefined Policies

[View full size image]

Understanding Policy Settings

To view a policy and the settings available at the policy level, choose the policy you want to view from the listing page by clicking its name. As shown in Figure 4-43, the configuration options on the specific policy page are as follows:

  • Name and Description— Click View or Edit to enter or modify the policy name and description.

  • Target Architectures— Verify the target operating systems that are chosen for this policy and modify as necessary. The number of modules and combined rules are listed next to the target operating system.

  • Attached Rule Modules— View the attached rule modules for accuracy. You can click the rule module name to directly link to that module for viewing.

  • Combined Policy Rules— View the combined policy rules for this policy as they are listed in order of precedence after the merger of the attached rule modules. You can filter this view by clicking the View All Rules link above the rule list. You are allowed to filter the view based on rule type, enabled rules, and state conditions.

Figure 4-43. Viewing a Policy

[View full size image]

You also have quick links available at the top of the specific policy page, including the following:

  • Modify Group Associations— Displays the groups to which the policy is attached on the right side of the screen and the available groups on the left side of the screen.

  • Modify Rule Module Associations— Displays the rule modules attached to the policy per operating system, and enables you to add additional rule modules to this policy.

  • Explain Rules— Displays a verbose readable version of the combined rule modules and associated rules. The rules are divided into sections so that you can quickly locate the type or information you are attempting to find.

  • View Change History— Displays a filtered view of the audit log, which represents all of the changes made to this policy.

Using CSA Predefined Policies

Several policies that come installed with the CSA MC server can aid in the deployment and testing of the product. A few of the policies included are as follows:

  • Base Operating System Protection

  • Cisco Trust Agent

  • Default Security

  • Installation Applications

NOTE

The Installation Applications policy makes use of dynamic application classes to identify an installation. It offers a temporarily lowered security policy during installation of the product. If the installation s completion is not detected automatically, you can resume the higher security level on the agent from within the UI by clicking the Resume button on the System Security page.

  • Microsoft Office

  • Network Personal Firewall

  • Virus Scanner

  • Web Server

This is only a sample of the policies included with the product.

NOTE

This book does not attempt to explain the predefined policies. These policies change over time with incremental server patches and version upgrades to the product. The best method available for those wanting to better understand those modules is to investigate the locally installed policies personally.

Policy Relationship to Groups and Agents

Now that you understand how rules are combined into rule modules to create functional groupings, and rule modules are combined into policies to create cross-platform or functional policies, it is important to understand how this is applied to an agent system. Policies are applied to groups to serve as the implemented policy for all hosts in that group. Groups can contain more than one policy to further dictate the type of controls on the endpoint. Agents are then associated with a group or groups and inherit the assigned policies. All of the rules that are combined as a result of the merged information follow the rules of precedence for rule ordering on the agent system. To view the ultimate enforced policy for an endpoint or group designation, choose that item within the CSA MC and view the rule set assigned, which will be a combination of all assigned policy.

Mandatory Groups and Combined Rule Precedence

Another factor to consider that affects the precedence of rules in relation to an endpoint enforcement mechanism is mandatory group assignment. All agents are assigned to one of the mandatory groups:

  • All Windows

  • All Linux

  • All Solaris

Any policy assigned directly to these groups is considered mandatory and has immediate precedence over all other rules. This is an excellent way to ensure services or controls are enforced across the entire architecture regardless of other policy assigned. For example, you could create a policy that contains a deny IRC rule to prevent IRC traffic on all systems of that particular operating system throughout the entire deployment regardless of any other conflicting rule.


Summary

The concepts covered in this chapter are some of the most important to understand concerning CSA functionality. You must have a thorough understanding of all precedence-related topics, including manipulation and mandatory settings. The predefined policies and rule modules offer a great way to learn, deploy, and test the product in your environment; however, it is more likely that you will begin to create your own personalized variations to customize the rules necessary to match your enforced policy with the written policy maintained by your own organization.


Chapter 5. Understanding Application Classes and Variables

This chapter covers the following topics

  • Using application classes

  • Introducing variables

The Cisco Security Agent (CSA) is designed to be a highly effective endpoint security product. Besides being highly effective, CSA is also extremely tunable and efficient. Application classes and variables are two ways that you can streamline CSA configuration. By using these mechanisms, you can cut down on the number of specific rules you need to explicitly define. Using variables available within the CSA architecture enables you to group applications, networks, services, and other items discussed throughout this chapter into named sets that become reusable objects. You can reuse these objects throughout the various rules you create. In fact, these two mechanisms not only make your configuration more efficient, they also enable you to use globally defined parameters, which limits the possibility of making an error when defining rules.


Using Application Classes

Application classes are very important components in the CSA Management Console (MC) management architecture. Application classes are groups of applications (executables) that are common in function. This section reviews how CSA rules work so that you may better understand how application classes are applied and how they relate to rules.

When you define a CSA rule, most likely you are creating it so that you can deny or allow an action that might attempt to take place. You also define how and where that rule should be applied. In some cases, you might want a particular rule to apply to every process running on the endpoint. An example of this is a rule that denies an endpoint the ability to use the Telnet (TCP/23) protocol no matter what application is attempting this specific network connectivity. However, when creating the rule, you might more granularly decide to allow Telnet from the endpoint, but only from a specific set of capable applications. To take that a step further, you might also want to monitor the application and subprocesses started by that specific application. Application classes enter the equation at this point. By defining an application class, which includes the specifically allowed Telnet clients (or executables), you can then apply the rule to only those applications and subprocesses.

Do not worry if you do not fully grasp the concept of using application classes just yet. It is a very important concept, and the upcoming sections illustrate application class usage by example.

Purpose of CSA MC Built-In Application Classes

The CSA MC includes some built-in application classes to get you started. These application classes initially serve two purposes:

  • Functional— The built-in application classes are fully functional and in most cases are being used by many of the predefined rules and policies that come preconfigured on the CSA MC.

  • Tutorial— Although the main purpose of the built-in application classes is for you to deploy efficient, fully functional predefined policies quickly, they can also serve as a tutorial for those who want to create their own application classes.

To acquaint you with application classes, this section first looks at some of the built-in classes to discover the basic settings and configuration. To see a list of built-in application classes, you need to get to the Application Classes Configuration screen by choosing Configuration > Applications > Application Classes [Windows]. (See Figure 5-1.)

Figure 5-1. Application Classes Menu Selection Location

[View full size image]

NOTE

This book uses Windows for the majority of examples to simplify the learning process.

Configuring Application Classes

The Application Classes Configuration screen lists the currently defined application classes, which you can sort to show all, Windows-specific, or UNIX-specific application classes by changing the selection in the drop-down selection box in the upper-left corner of the screen.

You can perform other tasks from this screen, too, such as create a new application class, delete an application class, clone an application class to create a similar application class, or just compare two application classes by clicking the respective buttons at the lower-left corner of the web page. Figure 5-2 shows the drop-down selection field and the action buttons.

Figure 5-2. Application Classes Overview Page

[View full size image]

To view the configuration of an already created application class, use the scroll bar until you locate the application class you want to view or edit, and then click the name of the application class.

For example, choose the Command Shell application class to view a basic configuration. Figure 5-3 shows the Configuration page of the Command Shell application class.

Figure 5-3. Example Application Class Configuration: Part 1

[View full size image]

You have only a few tunable parameters and clickable links available when configuring an application class. The following list describes this specific application class page from the top to the bottom of the Configuration page:

  • View Change History— Click this link to view the changes made to this application class. The changes are tracked as part of the local audit process.

  • Name— Enter a name that is recognizable and descriptive to ease the configuration of rules.

  • Description and Detailed Description— Type a brief description of the purpose for the application class in the Description field and enter a much more descriptive analysis of the purpose for this object in the Detailed window.

  • Operating System— Change the drop-down choice to be more specific to the particular Windows operating system, such as NT, 2000, XP, or 2003. (Because this example is for a Windows environment, the Target defaults to All Windows.)

  • Display Only in Show All Mode— If your application class list is getting unmanageably long, you can use this check box along with the Admin Preferences page that is discussed in Chapter 14, "CSA MC Administration and Maintenance," to hide this application class from the Selection window, which narrows the options when you are choosing classes.

  • Add Process to Application Class— Define which processes are part of the application class. You have two options:

    • When Created from One of the Following Executables— Enter the information regarding what specific executables you want to include in the grouping. You also can check Insert File Set to include an already grouped listing from a file set variable.

    • When Dynamically Defined by Policy Rules— Check this option to create a dynamic application class that will be created by application behavior rather than executable name or file set definition.

    Tip

    Occasionally, you might want to group applications or processes by their exhibited behavior such as specific file, registry, or network access rather than by explicit process name. Grouping like this proves especially helpful when attempting to control behavior of any application that matches your application class behavior definition without the upfront knowledge of every application that could behave in such a way.

  • Remove Process from Application Class— Click the check box and specify a time in seconds if you want the monitored process to be removed from the application class after a predetermined amount of time. You rarely have a reason to select this option. You might have a process that needs temporary access to protected system resources for a certain time period. You could use this option to temporarily give the application extra access, without permitting the process to continue with the excessive rights over too long a timeframe. A process with excess access to a system might be eventually compromised and could provide other processes proxy access to normally protected resources.

  • This Application Class Includes— Applications commonly spawn subprocesses to complete tasks. Because these subprocesses could be the application you want to deny, you can dynamically include those processes in the application class while they are active. You have three possible choices under this heading:

    • Only This Process— Check this option if you want the application class to include only this process and never dynamically add subprocesses to the application class.

    • This Process and All of Its Descendents— Check this option to dynamically include spawned subprocesses. A rogue malicious process commonly launches other processes that might attempt certain undesirable actions. Checking this option ensures that the root process and anything spawned by it are also added to the application class and controlled with the same rules.

    • Only Descendents of This Process— Check this option to include only subprocesses and never the listed root application process itself. Most commonly, you use this selection in an exception rule such that you apply a rule to the subprocesses and not the main application.

  • Show Reference List— Click this link to show the rules that are using this application class. This option proves very helpful when attempting to troubleshoot an application class, because the links provided are clickable and bring you directly to the rule Configuration page you select without the need to search for the rule on the Rules page.

You can see from the predefined Command Shell application class example configuration that this class is Windows specific and enables you to apply rules to the processes related to your specifically named command shells. This particular application class is used in several predefined modules and several rules that are listed by number and are clickable links. (You can display this information by clicking Show Reference List, as mentioned earlier.)

Now that you know the specific rules and modules that this example relates to, take a look at an example of how to apply it. In this example, Rule 121, as shown in Figure 5-4, is a rule within the Required Windows System module that uses the Command Shell application class. You can translate Rule 121 to read as follows: Allow and do not log when desktop interface applications attempt to run applications in the Command Shell application class. You can see that the goal of the rule is to allow desktop applications to launch command shells on your protected endpoints.

Figure 5-4. Rule 121 Using the Example Application Class

[View full size image]

Built-In Application Classes

You can use built-in application classes when defining rules, but you cannot edit them in the application class Configuration page. These application classes are also predefined on the CSA MC at installation time, but differ in that they are not configurable but can still be used in your rules. They serve very special purposes and use underlying code to provide classification rather than the CSA MC variables other application classes use. Built-in application classes display differently from other application classes in that they are surrounded by brackets (for example, <All Applications>), as shown in Figure 5-5.

Figure 5-5. Built-In Application Classes

[View full size image]

NOTE

There are two types of built-in application classes: editable and noneditable. Editable built-in application classes are identified by the asterisk in the name after the opening bracket, whereas noneditable built-in application classes are in brackets but do not include the asterisk in the name.

Configurable built-in application classes are also surrounded by brackets, but include a leading asterisk in the name (for example, <*Suspected Virus Applications>). You can configure these built-in application classes, but you can use them only with a rule that dictates what causes processes to become classified as one of these particular application types. You can edit the classes with asterisks (*); however, you should do so only if absolutely necessary. Built-in application classes that do not have the asterisk in front of their name have a special purpose; therefore, you cannot edit them.

NOTE

You can find a complete list of the built-in application classes and their descriptions in the CSA MC online Help documents via the Help link at the upper-right corner of all CSA MC web pages.

Here is a list of some of the built-in application classes:

  • First Time Application Execute— Includes executables the first time they are run on a system since the installation of the CSA

  • Network Applications— Includes any process that connects as a client or server accessing the network.

  • Processes Created by Network Applications— Includes any process started by a network application

  • Processes Monitoring the Keyboard— Includes all processes that monitor keystrokes

The following list includes a few of the built-in configurable application classes:

  • Installation Applications— Includes processes that are installing software on the protected agent machine

  • Processes Copying Untrusted Content— Includes processes that copy executables that should not be trusted and have arrived on the system as downloaded content

  • Processes Executing Untrusted Content— Includes every downloaded executable or running process that interprets downloaded content

Introducing Static and Dynamic Application Classes

Application classes are extremely important to CSA success and past performance. Within application classes, you can explicitly identify certain processes by name; such processes are called static application classes. You can also create an application class whose members dynamically change over time as certain processes exhibit specific behaviors. The next few sections examine these two application class types.

Creating a Static Application Class

Static application classes relate to applications you know are running in your environment that you want to control through CSA rules. You can create an application class by following these steps:

Step 1.
Choose Configuration > Applications > Application Classes [Windows] from the navigation bar.

Step 2.
Click New at the bottom of the page.

Step 3.
Create a name. The example shown in Figure 5-6 uses Test Telnet Application Class. The name should always be fairly descriptive to make future configuration and management tasks easier.

Figure 5-6. Static Application Class

[View full size image]

Step 4.
Create a brief description. This example includes the following brief explanation of the use for this class: App class to control our known enterprise Telnet apps.

Step 5.
Check Detailed if you want to include a more complete description or other notes.

Step 6.
Choose the target operating system. The main operating system is already shown as Windows because you created this from the Windows page, but you might want to specify the more specific Windows version, such as NT, XP, 2000, or 2003, to which this class will relate. Leave this as All Windows for this example.

Step 7.
Add your specific known Telnet applications to the list under Add Process to Application Class When Created by One of the Following Executables. You will need to add your enterprise applications, which for this example are **\telnet.exe and **\telnet32.exe.

Step 8.
To ensure you are watching subprocesses that the preceding two executables may spawn as well as the main process, check This Process and All of Its Descendents.

Step 9.
Finally, click Save to accept the changes to the newly created application class.

By following these steps, you create a new application class that includes the main process and any subprocesses resulting from executing either telnet.exe or telnet32.exe on a protected Windows system. Now that you have defined this application class, you can apply rules to control the behavior of the included processes.

Configuring Dynamic Application Classes

Dynamic application classes differ from static application classes. Whereas static classes refer to the name of the associated executable or process you want to group, dynamic application classes are grouped based on the behavior of applications and processes. This grouping enables you to benefit from the efficiencies gained through application classes without the need to know exactly which applications are running in your enterprise.

In the example static application class created in the previous section, notice one major issue: You needed to know the exact name of the application you wanted to control via CSA rules. This requirement is fine if you can guarantee that telnet.exe and telnet32.exe are the only two applications on your enterprise workstations that use the Telnet protocol, but having this level of control is unlikely. Other examples of applications that you might want to group via protocol rather than name include the following:

  • E-mail (POP, IMAP, and SMTP protocols)

  • Web servers (HTTP and HTTPS protocols)

  • TFTP servers (TFTP protocol)

Applications that behave "well" from a protocol standpoint are easily mapped to dynamic application classes, but other applications, such as instant messengers and peer-to-peer file-sharing applications, might try several communication protocols to get a connection and might be best grouped via static application classes.

You can also add a process to a dynamic application class via the outcome of a rule that queries a user for a response. By choosing Terminate when a process attempts an action denied by another rule, you can add that new process to an application class that could further control the questionable process.

Consider the Telnet example previously used to demonstrate how static application classes work, but this time use a dynamic application class. Follow these steps to create a dynamic application class:

Step 1.
Choose Configuration > Applications > Application Classes [Windows] from the navigation bar.

Step 2.
Click New at the bottom of the page.

Step 3.
Create a name. The example shown in Figure 5-7 uses Test Telnet Dynamic Application Class.

Figure 5-7. Dynamic Application Class

[View full size image]

Step 4.
Create a brief description. This example includes the following brief explanation of the use for this class: Dynamic app class to control Telnet apps.

Step 5.
Check Detailed if you want to include a more complete description or other notes.

Step 6.
Choose the target operating system. The main operating system is already shown as Windows because you created this from the Windows page, but you might want to specify a more specific Windows version, such as NT, XP, 2000, or 2003, to which this class will relate. For this example, leave this as All Windows.

Step 7.
In the Add Process to Application Class section, check When Dynamically Defined by Policy Rules. By using policy rules to dynamically create the grouping, you do not need to explicitly define the applications you want to control by name.

Step 8.
To ensure you are watching subprocesses as well as the main process, check This Process and All of Its Descendents.

Step 9.
Click Save to accept the changes to the newly created application class.

Creating the dynamic application class itself is only half of the required configuration for it to be useful. To make the dynamic application class useful to you, you need to identify the processes that should be grouped by this class. To do this, you must create an application builder rule that identifies the processes and adds them to the dynamic application class based on the process behavior. Follow the next steps to create the application builder rule:

Step 1.
Choose Configuration > Rule Modules > Rule Modules [Windows].

Step 2.
Either create a new module or select an existing module.

Step 3.
Choose Modify Rules from the top of the specific module page you either selected or created.

Step 4.
Click Add Rule > Network Access Control (see Figure 5-8).

Figure 5-8. Network Access Control Rule Selection

[View full size image]

Step 5.
Create a description. This example uses the following description: App builder rule for Telnet. You can also include a detailed description if necessary.

Step 6.
Under Take the Following Action, choose Add Process to Application Class, as shown in Figure 5-9.

Figure 5-9. Application Builder Rule

[View full size image]

Step 7.
A new drop-down selection box appears to the right. From this new drop-down, choose the previously defined dynamic application class, which was named Test Telnet Dynamic App Class. This process associates this application builder rule with your application class.

Step 8.
Specify enforcement action(s)—Terminate, Deny, or Allow to make the process part of the application class based on the specific user response.

Step 9.
Under Applications in the Following Class, leave <All Applications>, which allows any application on the protected endpoint to trigger this rule. You can limit this if desired.

Step 10.
Because you are trying to control Telnet client applications with this particular application class, choose Client from the pull-down list.

Step 11.
In the Network Services box, configure the protocol and port information that you will use to classify your applications as Telnet clients. Type TCP/23 to denote Telnet traffic.

Note

Alternatively, you can select $TELNET as the network service, which is a predefined variable. You learn more about variables later in this chapter in the "Introducing Variables" section.

Step 12.
The next options relate to the IP addressing of the local host and the remote destination of our communication. For this example, leave 0.0.0.0-255.255.255.255, which applies this application class and rules to all local and remote networks. If you want to apply this application class and the subsequent rules only to Telnet traffic to specific destinations or networks, you can modify these settings.

Step 13.
Finally, to complete the creation of the application builder rule, click Save to make the changes permanent.

You have now completed the creation of an application builder rule that identifies any Telnet (TCP/23) traffic from a protected machine and places the client application (or process/subprocess) into an application class. This dynamic application class will be a list of Telnet client processes that you can now monitor or control with other rules applied to the same clients. You can see that the few extra steps it takes to define these objects and rules gives you greater control over your network endpoints without the need for an exhaustive enterprise application audit and the naming of very specific applications.

To complete this example, the next steps configure a rule that uses the dynamic application class to deny Telnet applications from running on the endpoints. To create this rule, add another application control rule to the same module as you used for the application builder rule, and then follow the remaining steps, which are shown in Figure 5-10:

Step 1. | Add a description and a detailed description if desired.
Step 2. | Under Take the Following Action, choose Terminate Process.
Step 3. | In the Applications in Any of the Following Selected Classes menu, choose the example dynamic group called Test Telnet Dynamic App Class.
Step 4. | As the final step to this entire process, click Save to commit the changes to this new rule.

Figure 5-10. Applying the Dynamic Application Class

[View full size image]

You have now completed many steps. Without knowing the exact name of the Telnetcapable clients on your network or the location where they reside in the file structure, you are now certain that if any Telnet client runs and attempts to communicate over TCP port 23, you will terminate that application and send an event to the CSA MC for possible further examination.

Managing Application Classes

If you think you have too many application classes listed in the various application class selection boxes used throughout CSA MC configuration pages for rules, application deployment investigation, and application behavior investigation, you can limit the selection that is viewable on those screens. You control which ones show up by choosing Configuration > Applications > Application Class Management. From the Application Class Management window, you can enable or disable application classes for various portions of the CSA MC. Figure 5-11 shows an example of this screen.

Figure 5-11. Application Class Management

[View full size image]

Controlling Shell Scripts

You should control shell scripts on UNIX systems because their execution and compromise could affect the security of your UNIX system. When attempting to use application classes to control shell scripts on UNIX machines, you need to understand a few things.

To succeed, the scripts must satisfy two requirements:

  • The script must begin with an interpreter string, such as #!/bin/bash. (#! should be read as she-bang.)

  • The script must be executed directly from the command line.

Other methods for launching a script can circumvent your attempt at adding a script to the dynamic application class. It is very important that you use solid UNIX endpoint security to disallow many of these alternative methods to ensure your application classes succeed in achieving your goals.

System Processes

Any application class you create will never include system processes. To include these processes in a rule along with the application class you created, you must include the built-in classes <System Processes> or <All Applications> along with your application class, which would include the nonsystem processes you want to match.


Introducing Variables

Variables provide the CSA MC administrator a way of grouping items together to ease configuration. These variables, typically referred to as lists or sets, provide reusable objects that you can apply to many rules and alerts. You can group several objects together into variables. Once defined, you can edit these objects very easily at any point. Any rule or policy that makes use of the variable inherits the changes without you having to change every individual rule or policy directly.

Available variable types are as follows:

  • Network address sets

  • Network services sets

  • Data sets

  • File sets

  • Dynamic file sets

  • Query settings

  • COM component sets

  • Registry sets

The next sections explore each variable type, the sorts of objects they include, and how they are used. The sections also include configuration examples for each type. To configure variables, you must choose Configuration > Variables and then the appropriate variable you want to configure. (See Figure 5-12.)

Figure 5-12. Navigation Bar Variable Selection

[View full size image]

Network Address Sets

Network address sets are groups of specific IP addresses or IP networks. You can apply these groups to network access control rules, as discussed in Chapter 4. Creating a network address set enables you to group devices, such as engineering workstations, by network range or specific IP addresses. You then can use the set during rule creation instead of repeatedly typing out the addresses or ranges per each similar rule. From that point onward, you can change the addresses in the set (variable definition) if the IP addresses change, which means you do not have to edit every rule that makes use of that set.

NOTE

IPv6 is not supported on UNIX agents, but a rule using @local or 0.0.0.0-255.255.255.255 will be applied to IPv6 communication.

The next steps and Figure 5-13 show you how to configure a network address set for a fictitious engineering department:

Step 1. | Choose Configuration > Variables > Network Address Sets.
Step 2. | Click New.
Step 3. | Name the new network address set. Always use descriptive names. This example uses Engineering Workstations.
Step 4. | Enter a description. This example uses The Engineering Group s PCs.
Step 5. | Add the network addresses you want to group. You can only enter one IP address or one network range per line. To show the flexibility allowed, this example uses the following in the set: 150.1.1.51, 182.20.5.1-128, 190.5.1.1-4.255.
Step 6. | Click Save to commit the changes to the new set.

Figure 5-13. Network Address Set Configuration

[View full size image]

NOTE

Some special variables that you can use are dynamic in nature and vary from host to host and over time as the environment changes. The @local variable is a special notation that you can use to denote all local addresses on the agent. The @dynamic variable is another special notation that you can use to refer to untrusted hosts that have been quarantined by a rule using <Process Communicating with Untrusted Hosts>. The @dynamic list is automatically updated when that rule is triggered.

You have now created a network address set that you can use throughout your rules without fear of having many rules with incorrect addressing or other inconsistencies. All of the addresses in the group are maintained in a single set that you can easily edit in the future.

To complete the example, attempt to use the network address set in a network access control rule, which will deny attempts to access web servers residing in the Engineering group networks. Return to a module and create a new rule by choosing Add Rule > Network Access Control. Then follow these steps and refer to Figure 5-14:

Step 1. | Add a description.
Step 2. | Choose the desired action and whether to log the occurrence.
Step 3. | Choose Attempt to Act as a Client > for Network Services $HTTP [V4.5]. (You learn about network services sets in the next section.)
Step 4. | Under Communicating with Host Addresses, choose Insert Network Address Sets > $Engineering Workstations.
Step 5. | Remove 0.0.0.0-255.255.255.255 from the Communicating with Host Address section. This was the default and should not be there for the purpose of this example rule.
Step 6. | Finally, click Save.

Figure 5-14. Application of a Network Address Set

[View full size image]

The CSA MC includes several predefined network address sets, such as All IP Addresses, Authorized Port Scanners, External IP Addresses, and Internal IP Addresses. You can use these to ease deployment, but you might need to tune them to your specific enterprise IP deployment.

Network Services Sets

Network services sets are groups of specific IP services that you can apply to network access control rules. Creating a network services set enables you to define protocol-specific connection information such as initial ports and subsequent inbound or outbound connections the protocol may use. After defining the variable, you can refer to the set as the variable name (variable names always start with $) so that you do not have to list the ports separately in every rule. Instead of defining a new network services set, this section looks at the $HTTP set, which is a predefined set used in the preceding example:

Step 1.
Choose Configuration > Variables > Network Services. A list of the predefined network service variables appears, as shown in Figure 5-15.

Figure 5-15. Network Services Variable List

[View full size image]

Step 2.
Choose HTTP.

Step 3.
View the configuration and note that the $HTTP set includes both TCP/80 and TCP/443 for the HTTP and HTTPS protocols respectively, as shown in Figure 5-16. If you regularly use ports other than those for web servers in your architecture, you can either create another network services set or add your ports to the $HTTP set.

Figure 5-16. The $HTTP Network Services Variable

[View full size image]

Some protocols use dynamically assigned source or destination port numbers as part of additional sessions. Some of these applications are related but not limited to file and video transfer on networks. To deal with temporary ports that need to be opened as a result of one of these connections, you can use ephemeral ports in your protocol definition of CSA rules. To use ephemeral ports, use either TCP/ephemeral or UDP/ephemeral, depending on your specific needs. (See Figure 5-17.)

Figure 5-17. Ephemeral Ports in a Network Services Set

[View full size image]

NOTE

Because some protocols create additional connections or sessions as part of the protocol specification, you should specify these additional connections in other network services sets and apply them to rules as needed.

You can use the network services variables anywhere you would use specific ports, such as in network access control rules. The use of these variables is not mandatory but will greatly ease your administration.

Data Sets

Data sets are variables that you can use as data access control rules. These sets are sets of strings that you can group together. Their only purpose is to be matched against the Uniform Resource Identifier (URI) in HTTP requests. You can use several data sets that come preconfigured in the CSA MC to match sets of meta characters. Meta characters are known classes of attacks and web server-specific exploits. Follow these steps to configure a sample data set:

Step 1.
Choose Configuration > Variables > Data Sets. A list of the predefined data sets displays, as shown in Figure 5-18.

Figure 5-18. Predefined Data Set Listing

[View full size image]

Step 2.
Choose Common Windows File Exploits from the list.

Notice that the screen shown in Figure 5-19 does not differ much from the other variable configuration screens. This time, however, you are defining strings for this set to match. For the set selected in this example, the following strings are listed: *root.exe*, *cmd.exe*, *autoexec.bat*, *win.ini*, *boot.ini*, *config.sys*, *\system32\LogFiles\*, *\repair\*, *\system32\*sam*, and *nobody.cgi*. These are all files and directories that are regularly targeted by many remote URI-based exploits.

Figure 5-19. Common Windows File Exploits Data Set

[View full size image]

Step 3.
To see how this data set or others like it can be applied, click Show Reference List at the bottom of the page.

Step 4.
Choose the number of the rule listed to go directly to the configuration page for that rule.

You can see that the data access control rule displayed in Figure 5-20 will deny Apache and IIS applications (per the application classes selected) the ability to access the data set defined by $Common Windows File Exploits. This data set enabled us to create a single rule to prevent many negative occurrences through the use of a reconfigurable variable.

Figure 5-20. Application of a Data Set to a Rule

[View full size image]

File Sets

File sets are groupings of files and directories that you can link as a variable for a special purpose. You can apply file sets to file access control rules, which can control directory and file access permissions. Follow these steps to configure a sample file set:

Step 1.
Choose Configuration > Variables > File Sets [Windows]. A list of the predefined file sets for Windows displays, as shown in Figure 5-21.

Figure 5-21. Predefined File Set Listing

[View full size image]

Step 2.
Choose Command Shells from the list of file sets. Once again, this is very similar to what you would expect from any other variable; however, the data expected this time is related to directory paths and filenames. Notice that you do not need to specify the directory in this particular case, but you do specify the command shells you want to match. (See Figure 5-22.)

Figure 5-22. Command Shells File Set

[View full size image]

Step 3.
To see how the Command Shells file set can be applied, choose Show Reference List and then choose a numbered rule from this list, which will take you to the rule configuration page for that rule. The rule displayed in Figure 5-23 is Rule 12 from the installation file access control rule, described as follows: e-mail applications, user-invoked applications, and command shells. This rule is a high-priority deny for e-mail applications that attempt to read or write files that match any part of the Command Shells file set as well as another specific file set.

Figure 5-23. Application of a File Set to a Rule

[View full size image]

You can easily see the power of file sets as applied to file access control rules. You can create and use groups of file and directory strings, which can be extremely granular through the use of include and exclude matching patterns, that you then link to rules and application classes for very specific permissions.

When configuring UNIX file sets, you have an additional configuration option: content matching. By clicking Insert Content, you can select file types to match, which would be any of the following:

  • Executable objects (binary executable files)

  • Interpreter files (all files starting with she-bang; that is, #!)

  • Java class files

Dynamically Quarantined Files and IP Addresses

Dynamically quarantined files and IP addresses are not natively configurable, but are manageable. This list, which is referred to as @dynamic, is dynamically populated when triggered rules exceed thresholds defined on the Global Event Correlation page shown in Figure 5-24. From this page, you can edit the thresholds and link to both the @dynamic list of current files and IP addresses.

Figure 5-24. Globally Correlated Events

[View full size image]

When you click the link to view the current @dynamic list for files or IP addresses, you can then add to, remove from, or refresh the list. You will find this a very helpful place to visit when a new virus or worm has penetrated your network through an unprotected machine or has attempted to execute but was blocked.

NOTE

You can use @dynamic in a file set to refer to all files that have been quarantined by the CSA MC.

Query Settings

Query settings is, a list of queries that users may be prompted with when asked about a particular action occurring on their machine. You can rephrase these queries as you deem appropriate for your environment and user base. It is extremely important that users under-stand what action they are taking when queried. Without a clear and precise message, a user might not select the desired response and, therefore, place the computing resource at risk. For example, this section looks at the query message For File Access - Downloaded Script Accessing Local System Resources, as shown in Figure 5-25. For this particular issue, the message shown to the user is "The Downloaded Script @appname is trying to access local system resources. This is potentially dangerous." This message is very straightforward and simple. Messages presented to the end user should never be vague or too wordy.

Figure 5-25. An Example Query Message Configuration

[View full size image]

To display specific information about what is occurring, you can use a feature called query tokens. Query tokens, such as @appname, are variables that contain information about processes and the local user or machine and can be used in the wording when laying out the text that displays to the user. The tokens and their descriptions are available in the CSA documentation, but some examples are @appname, @filename, and @localaddr.

To see how to apply a message to a rule, choose Show Reference List, and then choose a rule number to view. From the rule chosen, as shown in Figure 5-26, you can sees that when a rule has an action of query user, another drop-down box appears to the right asking you to select the appropriate query message to display.

Figure 5-26. Application of a Specific Query Message

[View full size image]

When configuring a query message, you can choose which options the user should have available as well as the default action to take place if the user does not choose an action in the allotted timeframe. The three options are as follows:

  • Allow (Yes)— Allows the application to access the resource

  • Deny (No)— Denies the application access to the resource

  • Terminate— Denies the application access to the resource and attempts to terminate the associated process

Other options that you can configure when creating query messages include the following:

  • More Languages— Provides a query message in another language for localization based on end-user language.

  • Don t Ask Again— Allows users to say that this action is either normal or abnormal at the time they are queried and to say remember my response instead of prompting me again. This type of caching lasts approximately one hour.

  • Query Challenges— Ensures that a user is answering the query and not a malicious process. When Query Challenge is chosen, the query message displays a graphically produced string of characters that the user must manually enter into a text box for verification. If the user correctly enters the same string as seen in the graphic of the query response, the action is accepted by the local agent.

COM Component Sets

COM components sets are groups of COM program IDs and COM class IDs, which are typically referred to as PROGIDs and CLSIDs, respectively. When these are grouped into a COM component set, you can apply this new grouping to COM component access control rules to control access to COM objects matching this list. Like all the other sets discussed thus far, this type of set can also use wildcard pattern matching to create a more broad set of COM objects with fewer actual string definitions.

To show the typical configuration of a COM component set, first look at the appropriate configuration page in the CSA MC. To get to the correct page, choose Configuration > Variables > COM Component Sets. This page provides a listing of all COM component sets currently available, as shown in Figure 5-27.

Figure 5-27. COM Component Sets Page

[View full size image]

Now that you have a list, choose the MS Office Objects set. Again, you see that this variable type is really no different in configuration from the other objects. At this point, you know that the only real difference between any of the variable types is related to the strings used for matching on that particular object and within what type of rule the particular set can be used. In this particular set, you can see the IDs you are matching listed one per line. Also note the wildcard pattern matching (*) used instead of listing every object possible. Figure 5-28 shows more detail.

Figure 5-28. Example COM Component Set Configuration Page

[View full size image]

To see how a COM object is used in a COM object access control rule, once again choose Show Reference List and link directly to a specific rule that is making use of this set. In Figure 5-29, you can see that this particular rule allows Microsoft Office applications (defined in an application class) to access the COM objects listed matched by the COM component set.

Figure 5-29. Example COM Component Access Control Rule

[View full size image]

NOTE

Note that COM objects are a Microsoft-only feature. UNIX does not use COM objects.

To assist in locating the COM object names that you will need to control access, every installation of CSA software includes a COM Object Extraction utility that enables you to view the COM objects available on the system in the Cisco\CSAgent\bin directory. The executable to run on the system is extract_com.exe. In Figure 5-30, you see what it looks like when you run the COM Object Extraction utility from a command line. The file created by the utility, which you can open in a text editor such as Notepad, shows you the output provided. Specifically, this portion of the text file shows both PROGIDs and CLSIDs. The PROGIDs are at the top of the screen, and the CLSIDs are at the bottom.

Figure 5-30. COM Extraction Utility in Action

[View full size image]

NOTE

PROGIDs are typically listed as Excel.Application, whereas CLSIDs are listed in braces as uppercase hex values, such as {0000002F-0000-0000-C000-000000000046}.

Registry Sets

Registry sets are groups of explicit or wildcard strings that match registry keys and hives. Many programs, including viruses and worms, place keys throughout the registry, which provide them with configuration information at the next execute time. Also if certain keys are placed in the correct location, the application auto-executes at system boot.

Because the registry is a Microsoft-only concept, this set is available only to Windows agents. Be very careful when creating custom registry sets. If you inadvertently enter the wrong information to filter registry access, you could cause many issues with the function of the workstation or server. For this reason, always initially deploy registry access control rules in Test Mode.

CAUTION

Personally, I cannot think of a good reason not to deploy any new rule in Test Mode other than "I am under attack and my network is going up in flames," but maybe you have one. In any case, use the registry with caution.

When matching a registry key(s), you must first understand the syntax allowed and the rules necessary:

  • Use of wildcards— Although you may use wildcards throughout the strings created to match keys, at least one of the entries in a string must not be a wildcard.

  • Hive names— Here is a list of the acceptable hive names:

    • HKLM = HKEY_LOCAL_MACHINE

    • HKCR = HKEY_CLASSES_ROOT

    • HKCC = HKEY_CURRENT_CONFIG

    • HKU = HKEY_USERS (HKU\* is all users)

In Figure 5-31, you can see an example registry set configuration. Here you can that this example is going to match using wildcards **\SOFTWARE\Microsoft\Windows\CurrentVersion\Run*\*. This string will match any of the Run or RunOnce keys in the registry. When applied to a registry rule, you can deny the ability of applications to write to these keys. This would prevent many malware applications from installing themselves to auto-execute at boot.

Figure 5-31. Registry Set Configuration Example

[View full size image]


Summary

In this chapter, you have learned about two major components in the CSA architecture: application classes and variables. Both application classes and variables (or sets) are very important to understand when your CSA deployment begins to scale. With this newfound ability to group various types of objects, you can now have a deployment in which all rules are consistent and efficient.

With the majority of the CSA MC building blocks behind you, you can now continue toward its actual use, tuning, and advanced concepts. As Glinda, the Good Witch of the North in the Wizard of Oz reminds us, "It is always best to start at the beginning." So let us do just that. In the next chapter, you will discover the security agent protective software itself, along with its local installation and usage.


Part III: CSA Agent Installation and Local Agent Use

Chapter 6 Understanding CSA Components and Installation

Chapter 7 Using the CSA User Interface


Chapter 6. Understanding CSA Components and Installation

This chapter covers the following topics:

  • General CSA Agent components overview

  • CSA installation requirements

  • Agent kits

The Cisco Security Agent (CSA) is a complex architecture that can enforce enterprise security policies by granularly controlling endpoint behavior. Although technical and security expertise is required to configure, control, and monitor the deployment, it takes very little remote user knowledge of such topics to successfully use the product. In most cases, users have very little interaction with the product and typically are completely unaware of the protection the product is providing their system. Occasionally, the local CSA prompts the user for a response regarding an action that might be normal or malicious or even displays temporary balloon messages to the user about actions that are taking place. In general, however, you should keep the interaction between the user and CSA at a minimum, and generally the user will continue unaffected by the dangers lurking on the network.

Other than the installation of the product, which can be scripted through various methods, the user may never need to interact with the product if that is the desired outcome. Through the application of effective tuning mechanisms, discussed in Chapter 12, "Creating and Tuning Policy," you can get the implemented policy to a point where protective mechanisms are enforced and yet users have no interaction with the product at all. Security administrators use the CSA MC to configure all parameter assignments of the agent and its personalized policies. Optionally, as a new feature in version 4.5, the administrator can allow end users to view and use an advanced user interface (UI) that allows the user on the endpoint to control some of the policy enforced on the local workstation, such as personal firewall rules. If that is not desired, you do not need to deploy this interactive capability to all users in the architecture, or any at all.

In this chapter, you continue to gain an understanding of the CSA architecture through an exploration of the agent software components, protocol communication, and installation.


General CSA Agent Components Overview

You have access to several "under-the-hood" components that are built in to CSA. To fully understand how CSA works, it is best to get at least a high-level understanding of a few of the key components and their interaction on the local agent system.

When rules are changed, edited, added, or removed on the CSA MC that pertain to the particular rules and policies running on your agent, you need to update your local policies with the necessary changes. To do this, your local security agent software communicates with the CSA MC via HTTPS (443) to retrieve the new information. If you recall from an earlier discussion in Chapter 2, "Introducing the Cisco Security Agent," the CSA architecture uses a pull model whereby the agent requests information regarding possible policy changes at a set interval, which by default is 10 minutes. CSA version 4.5 includes a signed UDP hint message that can "nudge" the remote agents into polling earlier than the predetermined time so that they will receive the update ahead of schedule. This feature is very convenient, especially in environments where you have changed the default polling interval to a higher time value and you need the ability to push (that is, request a pull) a change quicker than the typical poll cycle.

The agent policy manager is the agent component that receives the policies from the CSA MC server and forwards them to another agent component known as the rule/event correlation engine. This engine reviews the old and new rules and replaces or updates whatever is necessary to form the new local rule set.

Another component in the CSA is known as interceptors. Interceptors proxy actions that are attempted and verify how to proceed against the rules in the rule/event correlation engine. Some of the interceptors are as follows:

  • Network Traffic interceptor— Use for SYN flood and port scan protection.

  • Network Applications interceptor— Limit or allow individual applications to access the network via specific protocols and networks addressing parameters.

  • File interceptor— Limit an application s ability to read and write to specific files and directories.

A final noteworthy component is the local event manager. The local event manager locally stores events that are generated by the rules that have been triggered and set to log. Once stored and cached locally, the events that are to be logged are sent to the CSA MC for administrative review and global event correlation capabilities. If the CSA MC is not available, the agent stores the events and transmits the next time the agent can communicate with the CSA MC server with the appropriate time stamps attached.

All of the previously mentioned agent components also reside in the UNIX agents, although they are implemented through different programming methods available to those operating system architectures.


CSA Installation Requirements

In each of the operating systems in which CSA may be installed, you must satisfy minimum hardware and software requirements to ensure the deployment is supported by Cisco Technical Assistance Center (TAC). This section describes the software and hardware requirements and the communication requirements.

Software and Hardware Requirements

CSA has specific minimum requirements to load on an endpoint-protected server or workstation. Because the CSA is a software product, it only runs on appropriate operating systems. In version 4.5, the agent is supported on some Solaris, Linux, and Windows flavors. Future versions might provide you with an expanded operating system support base, but for version 4.5, follow the operating system requirements described in this section or refer to the latest CSA documentation for the most current guidelines, which are available at Cisco.com.

The hardware requirements for Windows, Solaris, and Linux agents differ slightly. Verify the requirements for your system before attempting installation and architecture implementation.

NOTE

CSA uses approximately 20-30 MB of disk space on all platforms.

Table 6-1 shows the Windows agent minimum requirements.

Table 6-1. Windows Agent Requirements

System Component

Requirement

Processor

Intel Pentium 200 MHz or higher.

Note: Uni/dual/quad processors are all supported.

Operating systems

Windows 2003.

Windows XP (Professional English 128 bit) with Service Pack 0, 1, or 2.

Windows 2000 (Professional, Server, or Advanced Server) with Service Pack 0, 1, 2, or 3 or higher.

Windows NT (Workstation, Server, or Enterprise Server) with Service Pack 5 or higher.

Note: Citrix MetaFrame and Citrix XP are supported. Terminal Services are supported on XP and Windows 2000. Terminal Services is not supported on Windows NT.

Memory

128 MB minimum.

Hard drive space

15 MB or higher.

Network

Ethernet or dialup.

Note: Maximum of 64 IP addresses supported on a single system.

Table 6-2 lists the Solaris agent minimum requirements.

Table 6-2. Solaris Agent Requirements

System Component

Requirement

Processor

UltraSPARC 400 MHz or higher.

Note: Uni/dual/quad processors are all supported.

Operating systems

Solaris 8, 64-bit 7/01 edition or higher.

Note: Solaris minimum core installation is not sufficient. You must also install the SUNWlibCx library.

Memory

256 MB minimum.

Hard drive space

15 MB or higher.

Network

Ethernet.

Note: Maximum of 64 IP addresses supported on a single system.

Table 6-3 shows the Linux agent minimum requirements.

Table 6-3. Linux Agent Requirements

System Component

Requirement

Processor

500 MHz or higher x86 processor.

Note: Uni/dual/quad processors are all supported.

Operating systems

RedHat Enterprise Linux 3.0 ES, AS, or WS.

Memory

256 MB minimum.

Hard drive space

15 MB or higher.

Network

Ethernet.

Note: Maximum of 64 IP addresses supported on a single system.

Additional Installation Requirements

For the CSA to become fully functional, you must address a few other points. Beyond the requirement to be loaded on a supported hardware and software platform, the agent must also support the necessary communication to be sure the agent remains current from a policy standpoint. The agent must also be able to resolve the IP address of the CSA MC server by its fully qualified domain name (FQDN) within Domain Name System (DNS).

CSA MC Server and Database

The CSA MC server contains the rules and policies that are required for agent enforcement. The MC is also where configuration changes and updates are maintained and is the focal point for the agents when they need to update their local policy enforcement rules. In addition, the MC serves as the destination for agent event messages that are transmitted and thus provides a centralized aggregation point for global event correlation and agent troubleshooting.

The default installation of the CSA MC includes the installation of Microsoft Data Engine (MSDE) database. This database is sufficient for smaller installations of 500 agents or fewer. The MSDE database has a database size limitation of 2 GB, which is not sufficient in larger deployments. When the enterprise agent deployment total increases to a number greater than 500 agents, it is recommended that you migrate the MSDE database to MS SQL.

In version 4.5, you can keep the MS SQL database local to the CSA MC server itself or you can use an externally loaded MS SQL server installation. It is important in either case that this database and server be secured from both a network and physical standpoint. You might decide to use an external MS SQL database in your enterprise for a number of reasons, as follows:

  • Off-box SQL allows for cold standby CSA MC servers in case of a server failure.

  • Fewer enterprise SQL deployments to maintain (regular maintenance and patching) because the SQL database can reside in your current enterprise SQL system.

  • The ability to leverage highly effective SQL hardware, including server architectures and disaster recovery mechanisms such as storage-area networks (SANs).

Communication Security

For policy and rule changes created on the CSA MC to take effect on the CSA, the CSA must have the ability to contact and communicate with the CSA MC over the network. This communication path can take any transport necessary between the agent and MC machines as long as there is end-to-end IP reachability for the duration of the connection.

For the agent to request the update or transmit event log messages, the agent attempts to resolve the MC IP address using DNS or any other local resolution means available such as the local hosts file. It is important that this information be correct to facilitate both a successful connection and to verify the certificate used in the Secure Sockets Layer (SSL) communication.

SSL over the standard TCP port 443 is the protocol used for all MC-to-agent interaction. SSL ensures an authenticated and encrypted communication of the updates and event transmissions. Within an enterprise, name resolution is not typically an issue; however, if you have systems that will roam around disparate networks, you need to be certain that the machine resolves the correct address and that the CSA MC server is reachable from those locations.

NOTE

The CSA policy information is local upon installation and does not need to be in contact with the CSA MC for the policy to remain active. CSA MC contact is required for policy and software updates and for transmission of the locally stored events for global interrogation and correlation.


Agent Kits

Agents are initially installed on endpoints via an executable install file. You can download and install this file directly from the CSA MC itself from an SSL-protected web page. Other methods of installation include locally executing the EXE file manually or via many other scripted and automated installation procedures such as an enterprise software installation system.

Creating an Agent Kit

Before you can install an agent kit on a workstation, you must accomplish a few tasks. First you must create the appropriate initial modules, policies, and rules that the agent will use. Then you must define the group and attach policies to it. Then you must create the agent kit and define a few installation kit parameters. This section describes these tasks and explains the options along the way.

Step 1.
Choose System > Agent Kits from the navigation bar. This brings you to a view of all the currently available kits. (There are pre-installed agent kits available.) See Figure 6-1.

Figure 6-1. Available Agent Installation Kits

[View full size image]

Step 2.
Click New.

Step 3.
When prompted with the What Is Your Target Architecture? pop-up window, choose the appropriate platform. In this example, choose Windows.

Step 4.
Create a name and description that is appropriate to this agent kit, as shown in Figure 6-2.

Figure 6-2. Agent Kit Creation

[View full size image]

Step 5.
Choose the appropriate groups that will be associated with this installation kit. You may choose more that one group if necessary.

Step 6.
Choose whether this should be a quiet install. Both the quiet and nonquiet installs need to be executed on the local machine either manually or via a scripted or automated method; however, when you choose Quiet Install, the user is not prompted during the installation for options such as installing the network shim or rebooting after installation.

Step 7.
(Optional) If you choose Quiet Install, you can then select to install the network shim or reboot automatically after the installation completes.

Step 8.
(Optional) Choose whether you want to install the Cisco Trust Agent (CTA), which is part of the Cisco Self-Defending Network Initiative. CTA can query the CSA for information about the local workstation, such as installed hotfixes and service patches as well as some state information about the CSA itself. If you do opt to load CTA, you can include information regarding its initialization as well as CTA certificate information that is used to secure the CTA Extensible Authentication Protocol (EAP) session to the Cisco Secure Access Control Server (ACS). Finally, under CTA, you can opt to state whether the CTA should be uninstalled if the CSA is ever uninstalled.

Step 9.
After you have configured the kit to your liking, click Make Kit.

Upon completion of your agent kit creation, a confirmation screen displays summarizing the selections you made during the creation process. (See Figure 6-3.) You are also reminded that the kit is not ready for deployment until after the next rule generation has been performed. You can perform a generation at this time if you are ready to proceed.

Figure 6-3. Agent Kit Confirmation Screen

[View full size image]

To Shim or Not to Shim?

With regard to the CSA operation and ability to protect a host, the network shim provides the following capabilities:

  • Port scan detection

  • SYN flood protection

  • Malformed packet protection

Now, you may say, "I want all of that. Why would I not load the network shim with every agent kit?" Good question! The reason is that other network shims might already be loaded on the workstation. These other network shims typically take the form of VPN or personal firewall software. Quite often, these shims can conflict and cause problems with endpoint operation. The solution is to either not load the CSA network shim or remove the other software that is in conflict.

NOTE

The Cisco Secure VPN Client does not conflict with the CSA network shim.

Disabling the network shim does not stop network access control rules from running; it only stops the network hardening features from being active, such as SYN flood protection and port scan detection. As a best practice, it is advisable to continue to use the network shim on Internet-facing servers or systems that might be targeted by such attacks as listed previously. Servers do not tend to use the type of software that conflicts with the network shim provided by the CSA, and you would therefore have few conflicts to resolve in this case. Desktop and laptop systems regularly use applications that could conflict, and you should cautiously test the shim on these systems to prevent unnecessary outages. Because desktop systems are not often targeted for denial-of-service (DoS) attacks, these preventive and alerting mechanisms in the shim can often be better served by well-placed network IDS sensors.

Installing Agent Kits

Agent kits, once created, still need to be installed on the remote systems you are attempting to protect. The installation package created varies according to the intended operating system architecture onto which it will be loaded. The installation procedures vary between the Windows, Linux, and Solaris implementations of the product. The next few sections cover the installation processes and procedures necessary to successfully load the agent on these systems.

Installing a Windows Agent Kit

After you have created the Windows agent kits, they are ready for installation. First look at how the remote endpoints can install the software directly from an SSL-protected web page on the CSA MC. Perform the following tasks on the endpoint:

Step 1.
Open a web browser and go to the following URL:

https://ciscoworks_system_name/csamc45/kits

The web page that displays, as seen in Figure 6-4, provides a listing of all agent kits on this CSA MC server.

Figure 6-4. Available Agent Kits Page

[View full size image]

To view this URL and register with this particular CSA MC server, you must be allowed to do so as defined in the Registration Control settings on the CSA MC, as shown in Figure 6-5. To access this page, choose Systems > Registration Control.

Figure 6-5. Registration Control Page

[View full size image]

Step 2.
From the Cisco Security Agent Kits page, choose the kit you want to install by clicking the link. You must have local administrator rights to install the kit.

Step 3.
You are prompted to save the installation file. Click Save and find a location that is appropriate for the file.

Step 4.
Close your browser and double-click the executable file you downloaded. The EXE is a self-extracting file.

If the agent is performing a quiet install, no interaction occurs with the user, and all installation occurs without any input required from the user. If the agent is performing a nonquiet install, proceed with the following steps to complete the installation.

Before the installation can continue, the agent installation kit verifies the user has local administrator rights; otherwise, a pop-up notification displays.

Step 5.
After clicking Next to proceed with the installation, read the license agreement, as shown in Figure 6-6. You are required to accept the license agreement to continue.

Figure 6-6. Installation License Agreement

[View full size image]

Step 6.
Choose the installation path, as shown in Figure 6-7. The default installation directory is Program Files\Cisco Systems. The folder selected here becomes the location in which a CSAgent folder is created. All agent executables and other supporting files are placed in a directory hierarchy within the newly created CSAgent folder in the directory you select.

Figure 6-7. Installation Directory Path

[View full size image]

Step 7.
After you select the path, choose whether to install the network shim, as shown in Figure 6-8.

Figure 6-8. Choose Whether to Shim

[View full size image]

Upon completing Step 7, a summary screen displays before final installation continues, as shown in Figure 6-9. After you verify that the summary information regarding the installation to be performed is correct, the actual agent installation begins, as shown in Figure 6-10.

Figure 6-9. Pre-Installation Summary Screen

[View full size image]

Figure 6-10. Installation Begins

[View full size image]

After completing the installation, the system presents you with a reboot request. A reboot is not required for most agent functionality to become active; however, for a more detailed look at the functions available after a successful reboot, see the "Immediately Rebooting the System After Installation" section later in this chapter. Figure 6-11 shows a sample reboot request.

Figure 6-11. Reboot Request

[View full size image]

As an alternative to sending the user to the URL that includes every possible agent kit, you can go back to the Cisco Security Agent Kits page and choose the specific kit you want the user to install. When this page opens, you will see a specific link that you can send to the user via e-mail or another method. This link is to the direct download for that kit and enables the user to install that specific agent kit when clicked. You are also given the Copy to Clipboard option, which places the specific link in your Windows clipboard so that you can craft an e-mail and then just paste the link into the message from your clipboard.

Installing a Solaris Agent Kit

The installation of a Solaris agent kit is a command-line process that requires the installer to be a super user on the system. To install a Solaris agent kit, retrieve the agent installation kit as per the Windows agent kit retrieval process described earlier or manually copy the kit from the CSA MC. Continue the installation process by unpacking the archive and installing the package to the default directory, which is /opt/CSCOcsa, using the following two commands on the Solaris system:

  • tar xf CSA-Server_4.5.0.15-setup.tar

  • pkgadd -a CSCOcsa/reloc/cfg/admin -d

To complete the Solaris installation process, verify the package to install is the intended package as per the system response that displays as a result of your command entry above and acknowledge that you want to continue the installation. Press q when the installation completes. Finally, reboot the system by typing shutdown -y i6 g0.

Installing a Linux Agent Kit

The installation of a Linux agent kit is a command-line process. To begin the process, you must first obtain the Linux agent kit file from the CSA MC. After retrieving the installation kit, you unpack the compressed agent kit using the following command entered at a command prompt:

tar xvf CSAagent-4.5-51.i386.tar

You should now change directories to the CSCOcsa directory that was created during the unpacking process. This directory is the location from which you install the Red Hat Packet Manager (RPM). When in the correct directory, type the following to install the Linux RPM: ./install_rpm.

NOTE

Because of the access required to various system and file resources, you must be a root user to install the Linux agent.

As an alternative to using the command-line installation procedure, you can use the graphical interface of Red Hat to download, extract, and install the CSA. (See Figure 6-12.)

Figure 6-12. Linux Agent Installation

[View full size image]

Immediately Rebooting the System After Installation

Most CSA protective mechanisms take effect immediately after installation, even before a reboot. CSA is not fully functional, however, until a reboot has occurred. Here is a list of functionality that does not take effect until after a reboot:

  • Network shield rules— Network shield rules are not applied until after a reboot. Network shield rules provide protective mechanisms that relate to the network shim.

  • Buffer-overflow protection— Buffer-overflow protection is only enforced for processes that start after the installation is complete. The agent does not monitor any processes that were already running; however, it does monitor any new processes that are spawned by the already running process. For Linux/Solaris agents, buffer overflow protection is only in effect for new processes.

  • Data access control rules— These rules are not applied to Uniform Resource Identifiers (URIs) until the web server is restarted. This pertains to Windows, Solaris, and Linux agents.

  • COM component access control rules— COM rules, which are discussed in Chapter 4, "Understanding CSA Policies, Modules, and Rules," are not functional until the system restarts.

  • Network access control rules (Solaris/Linux restriction only)— On Solaris and Linux, these rules only apply to new socket connections.

  • File access control rules (Solaris/Linux restriction only)— Only newly opened files have these rules enforced.

Scripted Installation

As an alternative to the manual installation processes described previously for each operating system, you can install the CSA agent automatically via a script when the user logs in to the network. The CSA agent self-extracting EXE is located in %Program Files%\CSCOpx\CSAMC45\bin\webserver\htdocs\deploy_kits on the CSA MC server. You can move this file to an appropriate location and use it in scripts or other automated installation mechanisms. For a script to install the executable successfully, be sure to create the kit as a quiet install and with the appropriate options, such as network shim and automatic reboot.

Installing Software Updates

As with any software product, various software updates will become available for the CSA product over time. You should install these updates to add new functionality or provide fixes to CSA components. When you receive a new update to the CSA product, read the release and installation notes provided with the software update. When you are familiar with the reason for the update and the procedures necessary to complete the update, proceed with updating the CSA MC application. This update will also update the agent software that is available to the agents in the form of future agent kits or updates to currently deployed agent installations. To see a listing of the available software updates on the CSA MC, as shown in Figure 6-13, choose Systems > Software Updates from the navigation bar.

Figure 6-13. Available Software Updates Page

[View full size image]

You can obtain the information regarding each update by following the link in the Name column. Figure 6-14 shows an example of the information that displays.

Figure 6-14. Specific Available Update Information

[View full size image]

Currently, two different types of scheduled updates are available to CSA: automatic and manual. With automatic updates, an agent polls as expected, and as part of the transaction it receives and installs the updated software silently. Figure 6-15 shows a typical screen that displays in a CSA MC regarding scheduled software updates that have been configured for deployment.

Figure 6-15. Scheduled Updates Screen

[View full size image]

With a manual update, the installation is not silent. The user is prompted to either install the update immediately or postpone the update for up to 10 days.

NOTE

Regarding Solaris updates, because there is no GUI for the Solaris client, you need to manually check for updates using the csactl client interface.

To configure a new update with parameters specific to your environment, follow these steps and refer to Figure 6-16:

Step 1. | Choose Systems > Software Updates > Schedule Software Updates > New.
Step 2. | Provide a name and description for the update.
Step 3. | Choose the architecture the update will be targeting.
Step 4. | Choose the group or groups that will be required to install the update.
Step 5. | Choose a timeframe in which the updates will be available. By default, this is set to the entire day. If you edit this timeframe, the update will only be available during that window and no users can update outside of that timeframe even if they select Postpone at an earlier time and are now attempting to install via the button on the local GUI.
Step 6. | The last configurable option is choosing whether to make the update automatic. If you make the update automatic, users do not have the option to postpone the installation.

Figure 6-16 . Update Configuration Screen

[View full size image]

NOTE

If the update requires a reboot, a reboot occurs 2 minutes after installation completes and cannot be stopped. This is true for both automatic and manual updates.

NOTE

If users decide to postpone the update, they can wait to be prompted again to install or they can click the Update Available button that appears on the first page of the CSA agent GUI.

Uninstalling an Agent Kit

If you want to script an uninstallation of a security agent, you can use a pre-installed Cisco-provided BAT file to aid in the process. On Windows systems, the script is csa_uninstall.bat and is located in the system32 directory. If you want to script the uninstall as a quiet uninstall, you should add a parameter to the BAT file. For an automated scripted quiet uninstallation, execute csa_uninstall.bat 3 in the agent s local system32 directory. You might need to disable any rules that relate to service control prior to attempting to uninstall the agent. A query rule could easily foil your attempt to script an uninstallation of the agent.

The process to uninstall an agent running on Solaris is also very simple. From the Solaris server, enter pkgrm CSCOcsa. This process can be stopped by agent control rules that might be active. Disable any of these preventive rules before attempting uninstallation.

Uninstalling the agent in Linux is also a command-line feature. Before you can proceed, you must make sure you have the correct version number and then type the following from a command line:

rpm -qf /opt/CSCOcsa/bin/csamanagerd CSAagent-4.5-56

When that completes, type the following:

rpm -ev CSAagent-4.5-56.i386

As always, if any rules would prevent agent installation, you must disable those first before proceeding.


Summary

The CSA agent kit creation and installation process is fairly straightforward, or at least it can be. For larger organizations, you might find that the installation process can be automated quite effectively using scripts and other mechanisms. It is very important that you fully understand the types of machines you will be installing the agent on with regard to hardware and software specifications as well as other possible software that might conflict with the installation process. As always, a pilot, documentation of the scripts and processes, and user training of the new product are recommended for making the installation of your newest security tool a success.

In the next chapter, you continue to explore CSA. The next chapter covers the local GUI itself, its options, and its interaction with the user. You will also discover some local agent files that prove useful when troubleshooting a local policy interaction with the system as well as the agent interaction with the remote CSA MC server.


Chapter 7. Using the CSA User Interface

This chapter includes the following topics:

  • Windows agent interface

  • Linux agent interface

  • Solaris agent interface

The Cisco Security Agent (CSA) product includes a GUI that can be presented to local users on their protected workstations. This interface provides local users information about the local agent actions and enables them to control the personal firewall, view local log files, and much more. This agent GUI is flexible enough such that you can hide it from the end user if desired.

The CSA user GUI can prove very useful in providing information to the user about successful policy enforcement. You might find it is more desirable that users have limited or possibly no interaction with the CSA, however, which is very common. Only users who you consider trustworthy should have the ability to view the interface on the local machine.

Rules configured within the CSA MC enable you to provide or hide the user GUI. Because GUI availability is controlled via a rule, you can use user and system state sets as described in Chapter 4, "Understanding CSA Policies, Modules, and Rules," to decide exactly when the GUI is available and to whom. This capability is how you can enable a technician logged in to the protected system as local administrator to see and use the GUI while the everyday user of the system cannot.

This chapter takes a close look at the information the GUI provides and examines the possible uses the end user may desire or require. These and other agent options are discussed for Windows, Linux, and Solaris systems.


Windows Agent Interface

When the CSA is installed on a Windows operating system, you need to be familiar with a few visual GUI components such as the tray icon, the system tray options menu, and the user GUI. Other topics discussed in this section regarding the agent software are audible notifications, the Windows Programs menu, local directories and tools, user interaction, and stopping the agent service.

Windows Agent Tray Icon

The CSA tray icon is represented by a red flag that resides in the system tray (lower-right corner of the Windows taskbar). This icon remains motionless until an agent rule is triggered, in which case it begins to wave. As a local alerting mechanism, the agent flag waves to get the attention of the local user.

Another local alerting mechanism enabled by default is the balloon message feature. Balloon messages are messages that pop up just above the system tray when an agent policy rule is locally triggered. Although these visual alerts might prove useful for some users, others might find them distracting; therefore, you can hide them from the user. You can also hide them for other reasons, such as an administrative policy that forbids user interaction with local security mechanisms.

NOTE

You cannot disable pop-up messages on an agent using central policy because this notification mechanism is a local configuration option only. Another way to disable pop-up messages on the client is to add the following registry key to the agent machine:

HKEY_CURRENT_USER\Software\Okena\Cisco Security Agent\

key="BalloonPopupsDisabled"=dword:00000001

Windows System Tray Options Menu

The system tray options menu is accessible by right-clicking the system tray flag icon, as shown in Figure 7-1. When it opens, the following shortcut and configuration options display:

  • Open Agent Panel— Selecting this launches the local user agent control panel GUI.

  • Disable Balloon Messages— Selecting this option prevents balloon messages from popping up when a rule is triggered. This option is replaced with the Enable Balloon Messages option once selected.

  • Security— This option has four possible selections available: Off, Low, Medium, and High. Off suspends the agent rules until the user comes back to select any of the other security levels. Low, Medium, and High provide varying levels of security completely controlled and configured as per the CSA MC rule definitions for these levels. These are the same levels you can manually adjust from within the agent GUI System Security screen discussed later in this chapter.

  • About— This option opens a new window with the agent build number. This window proves useful when attempting to locate the exact version of the agent running on a local system.

  • Exit— This option closes the CSA taskbar icon. To re-enable the icon, choose Start > Programs > Cisco Security Agent.

Figure 7-1. Agent System Tray Options Menu

[View full size image]

NOTE

Closing the icon on the taskbar does not suspend security, but only makes the icon disappear.

The CSA User GUI

The CSA GUI, also called the Agent Control Panel, might have different options available depending on the policy definition for the local agent. Double-clicking the red flag icon in the system tray opens the control panel for viewing and manipulating the agent.

The Agent Control Panel is divided into the following three sections:

  • The navigation panel, which is on the left side of the window

  • The main portion to the right of the navigation panel, where configurable options and displayed settings are shown

  • The security level, which is listed in the lower-right corner of the window

The following sections describe the navigation panel options so that you can discover what a fully capable local agent GUI screen can provide.

Windows Agent—Status

When you open the agent GUI, the top-level status screen displays, as shown in Figure 7-2. This screen provides basic information regarding agent health. The following information displays:

  • Host Name— The fully qualified domain name of the local host.

  • Management Center— The fully qualified domain name of the CSA MC, because it must be reachable via DNS resolution.

  • Registration Date— The date and time the agent initially registered with the CSA MC and began using one of the licenses on the MC.

  • Last Poll Time— The date and time of the last poll. This could have been a scheduled or a manual poll.

  • Last Download Time— The date and time of the last policy and configuration download.

  • Software Update— Whether a software update is pending for this agent.

  • Network Admission Control (NAC) Posture Results— The posture token received as part of the Cisco NAC posture assessment.

  • Poll for New Configuration— Click this button to initiate a manual poll.

Figure 7-2. Status Screen

[View full size image]

NOTE

If the agent is a member of multiple groups, the shortest polling interval is used.

The Status screen provides three suboptions:

  • Messages

  • User Query Results

  • Contact Information

The next sections describe these suboptions in greater detail.

Windows Agent—Status > Messages

The Messages suboption enables the local user to view the list of denied system actions that have occurred as of the last reboot. This information proves useful when troubleshooting the local agent, particularly when the CSA MC is unreachable.

As shown in Figure 7-3, you can also open the local security log file by clicking the View Log button. This log provides more detailed information about what has occurred on the local agent as a result of the implemented policy. The Purge Log button enables you to clear the local log file, but not the entries in the Messages window.

Figure 7-3. Available Agent Installation Kits

[View full size image]

Windows Agent—Status > User Query Responses

The User Query Responses suboption maintains the list of cached responses from the local agent. A response is cached locally if a rule is triggered that had the Don t Ask Again check box enabled and the user chose Yes, No, or Terminate when prompted along with checking that check box. By checking Don't Ask Again, the user can cut down on the amount of interaction required with the agent such that the agent can auto-respond by using the cached information.

Responses can be cached for set time intervals, such as an hour in duration, or permanently remembered. Permanently remembered responses remain cached even through reboots, whereas the timed cached entries do not remain through a reboot.

To clear a permanent response from the User Query Responses window, as shown in Figure 7-4, click the Clear button after choosing the permanent responses you want to clear. You can also clear all temporarily cached responses by just clicking the Clear button without specifically choosing any responses. You can also clear all cached entries for a specific agent in the architecture from the Diagnostics window available from the Host Settings page in the CSA MC if that is required.

Figure 7-4. User Query Responses Screen

[View full size image]

NOTE

Cached entries are for the current user only. Systems that are used by more than one person might ask the same query to each person until cached for all users.

Windows Agent—Status > Contact Information

The Contact Information suboption is a simple form, as shown in Figure 7-5. This form enables the local user to enter information such as name, telephone number, e-mail address, and location. This information is transmitted to the CSA MC to aid in troubleshooting.

Figure 7-5. Agent Contact Information Screen

[View full size image]

Windows Agent—System Security

The System Security screen shown in Figure 7-6 is an interactive screen that enables the user to control how some local rules are enforced. Users on protected systems can use this particular screen to temporarily weaken the desired endpoint security. This screen need not be provided to all users or might possibly only be provided dependent on user or system state, such as to administrators and users who are out of the office.

Figure 7-6. System Security Screen

[View full size image]

At the top of the System Security screen is the Security Level slide bar. Users can set the bar to four possible levels: Off, Low, Medium, and High. These levels correspond to system state levels, as defined in the CSA MC, that affect whether a rule is enforced at that moment in time. Security levels do not necessarily turn off rules, but could change the rule to a query rather than implicit deny.

The security levels of Low, Medium, and High affect the agent according to the administratively defined security policies and states on the CSA MC. These levels do not correspond to generic security assignments but personalized enterprise policy-level definitions. The Off security level always disables the security agent.

NOTE

It might prove beneficial to provide the slider bar to a user who is currently out of the office so that the user can temporarily lower the security level to install needed software. Users in the office should always have local support staff available to install software and therefore should not need to lower the security level themselves.

In the next portion of the screen, you see the Network Lock check box. The network lock, if enabled, prevents all new inbound and outbound network attempts other than those that were already in progress prior to enabling the lock. When enforced, the network lock prevents new network connections regardless of whether another rule permits the network connectivity attempted. You can manually enable the network lock by checking the box, or it can be enabled automatically by setting the timer associated with the Network Lock check box. After a certain number of minutes of network inactivity, the lock is automatically enabled. To disable the network lock, you must uncheck the check box or reboot the system.

The final button on this screen is the Resume button. As discussed in Chapter 4, the agent can detect installation programs and can temporarily lower the security of the system to specifically allow the particular installation to occur without the agent interfering. In some cases, such as the installation abnormally terminating, the agent cannot see the installation completion, and the lowered security setting associated with the install executable is not removed. To manually remove the lowered security policy and let the agent know that the installation has completed, you can click the Resume button to alert the agent.

Windows Agent—System Security > Untrusted Applications

The Untrusted Applications screen displayed in Figure 7-7 provides a list of applications that were downloaded to the system that the user chose not to trust as downloaded content. If you choose to later trust this application, you can come to this screen in the Agent Control Panel GUI and delete the application from the untrusted list.

Figure 7-7. Untrusted Applications Screen

[View full size image]

Local Firewall Settings

By providing the Local Firewall Settings screen to a user, you enable the user to use the agent as a personal firewall. Without this screen, which is shown in Figure 7-8, all network access control rules are still in place. This screen enables you to locally define which applications have permissions on your system and which permissions are allowed. Firewall permissions are allowed for applications when the user answers a query message as to whether they should be permitted.

Figure 7-8. Local Firewall Settings Screen

[View full size image]

NOTE

The local firewall settings do not override centrally defined policies. For applications to have permissions, both the central and local policies must permit them.

After the personal firewall has been enabled, users can place the personal firewall in Learning Mode. In Learning Mode, the CSA watches the interactive system to build the local permissions database. Four types of permissions can be assigned to any application:

  • E-mail network permissions

  • HTTP network permissions

  • Network client permissions

  • Network server permissions

Within each type of permission assigned, the application can be either permitted or denied that permission. The icon representing each action appears next to the application in the list.

After an application has been assigned a local permission, you cannot directly change it, but rather must delete it from the list and answer the next associated query appropriately as it is re-added to the list.

NOTE

Local firewall settings are ignored if the agent is in Test Mode.

The File Protection screen shown in Figure 7-9 enables the local user to protect local files and directories from being accessed over the network. This protection is very similar to what can be provided by centralized policies within the CSA MC. In certain cases, the local user might be aware of local files that are not being protected by centrally defined file access control policies. When you add a file or directory to this list, any network attempt to access this asset results in a query so that you may only provide access when it is necessary to do so.

Figure 7-9. File Protection Screen

[View full size image]

To protect directories and files, you must use the correct syntax. If you name the specific path and file, such as c:\directory1\directory2\filename.txt, that file is protected. To protect all files in a directory and all subdirectories, use the ** wildcard (for example, c:\directory1\** to protect all files in directory1 and all subdirectories). To protect just the named directory files but not the subdirectory files, use the * wildcard (for example, c:\directory1\directory2\*).

To protect a specific filename no matter where it resides, just name that file outright (for example, filename.txt) .

CSA Audible Notifications

CSA can provide a sound notification if certain actions take place. To configure the sounds associated with these events, you must make the necessary changes in the Sounds and Audio Devices Control Panel window, as shown in Figure 7-10. By default, no audible notifications are preset, and these settings are not globally available via the CSA MC. The following is the complete list of events that can be tied to audible notifications:

  • Agent window opens

  • Dynamic configuration update

  • Flag flapping

  • New configuration download

  • Query pop-up appears

  • Query pop-up closes

  • Query timeout warning

Figure 7-10. Audible Notifications Configuration

Windows Programs Menu

Upon installation, CSA places some links into the Programs list on the Start menu. From here, you have the following options:

  • Cisco Security Agent— You can select this to restart the taskbar GUI (red flag) if you have previously exited.

  • Perform Diagnostics— You can select Perform Diagnostics to cause the agent to gather useful diagnostic information and bundle it into a csa-diagnostics.zip file, which will be placed in the Cisco Systems\CSAgent\log directory. The following useful information is bundled in this file:

    • Agent.bundle— This text file includes agent version, registration ID, CSA MC name and IP, HTTP/HTTPS ports, and so on.

    • Agent.rul— This is the rule file (not plain text readable).

    • Agent.state— This is like Agent.bundle plus SID, UID, and some other Status screen and contact information.

    • Agent.var— This file contains some local CSA variables and query information.

    • Arp.txt— This file contains local ARP table entries.

    • CSAgent-Install.txt— This is the installation log file.

    • Csalog.txt— This file includes information about what has happened on the system regarding agent operation.

    • Driver_install.txt— This log file contains information about the installation of the system drivers. This will only include time stamps and information of the related events that occurred during original agent installation.

    • Env_vars.txt— This includes the local environment variables.

    • Ipconfig.txt— This file contains a text capture of a locally executed ipconfig from the local agent.

    • Nbtstat.txt— This file contains a text capture of a locally executed nbtstat from the local agent.

    • Netstat.txt— This file contains a text capture of a locally executed netstat from the local agent.

    • RTR files— This contains all policy interaction that occurs on the local system regardless of whether the agent sends an event to the CSA MC. These files prove very useful when troubleshooting local policy interaction. To read the RTR file contents, you must use the RTRFORMAT.exe program located in the local bin directory to create an ASCII-readable output from the original binary file. These files are going to prove most useful when identifying rules that prevent actions that are required for successful application and system usage that are specifically set on the CSA MC not to log events. Although the prevented action does not display in the centrally correlated event log on the CSA MC, the action displays in the RTR files.

      Note

      To write RTR file content in a readable format to a TXT file, you need to retrieve the RTR file you want to view to the system on which you will view the files. Then, to create the TXT file, enter the following command:

      Rtrformat.exe rtrfilename > textfile.txt

      You can now open the text file in your favorite editor for viewing.

    • Routes.txt— This file contains a text capture of a locally executed route print command that displays the IP routing table of this system.

    • RuleEngine.state— This diagnostic file is not plain text readable.

    • Sslca— This is the SSL certificate file.

    • Sysvars.cf— This contains CSA-specific control variables that TAC may have you edit during certain troubleshooting procedures.

  • Reset the Agent— You can set the local agent settings back to factory default, except for firewall and file protection settings. For firewall and file protection settings, resetting the agent does not clear the entries, but disables them (because a default agent would not normally be enabled).

  • Uninstall the Agent— You can uninstall the agent using this menu option. To uninstall the agent, you must have the ability to stop the agent service, but this ability might not be available to all users based on the centrally defined policy.

CSA Local Directories and Tools

The CSA default installation directory is C:\Program Files\Cisco Systems\CSAgent. There are a number of directories here, but most notable are the log and bin directories. The log directory includes many local log files, which can prove very useful in troubleshooting a specific agent. Remember, you can get most of the log information as well as other great information about the current system by running the Agent Diagnostic tool.

The other directory that a technician may use is the bin directory. The bin directory contains the necessary agent EXE and DLL files and some other tools you might need to use from time to time. An example of a tool in this directory is getcom.exe. This particular tool checks for all COM objects on the system and places them in an ASCII text file for you to peruse when creating COM rules in the CSA MC.

CSA User Interaction

If you permit the user to interact with the local security agent GUI, the user should under-stand how to answer the common queries that will pop up when rules are triggered. When a query rule is triggered, the user is presented with some options regarding the question at hand, such as whether downloaded content should be allowed to execute. The user could be given the following options:

  • Terminate— Denies access to the resource and attempts to stop the process

  • Deny— Denies access to the resource

  • Allow— Allows access to the resource

Along with the preceding options, the user may be given the ability to check the Don t Ask Again check box, which would locally cache the response for future queries. After selecting the option that is deemed appropriate, the user may be prompted with a query challenge response. A query challenge response is an additional pop-up box that the user receives that asks the user to type a multiletter response exactly as it is presented to them in the onscreen image, as shown in Figure 7-11. This is an option made available to CSA MC administrators who are concerned that an automated client-side application might attempt to choose an undesirable option in place of the default action that would result if the user were not at the machine at the time of the query.

Figure 7-11. Query Challenge Response

[View full size image]

Stopping a CSA Agent

There are three ways to stop CSA from protecting the local system:

  • Disable agent from systems tray— Right-clicking the red flag icon and selecting Suspend Security halts all agent protections until it is re-enabled.

  • Sliding bar security setting to Off— Within the Agent Control Panel GUI, sliding the bar to Off disables agent protective mechanisms until the bar is moved back to any of the other three settings (Low, Medium, High).

  • Stopping the agent service— If a user has the ability to stop the agent service either via the Windows Control Panel > Administrative Tools > Services menu or via the command line using net stop cisco security agent, the user could stop the agent from protecting the system until the agent service is restarted.

It is important that the appropriate policies be in place such that the agent cannot be stopped inappropriately, which would result in an unprotected system. It is also important to remember that in certain cases stopping the agent might be a valid action, such as when a local technician is troubleshooting a problem on the system. System and user states are a great way to control when and how the agent protective rules are implemented.


Linux Agent Interface

The CSA for Linux is supported on Red Hat 3.0 Enterprise only. It is supported for all three versions of the product: WS, ES, and AS. The Linux agent is nearly identical to the Windows agent from a user interface perspective, as shown in Figure 7-12.

Figure 7-12. Linux Agent User Interface

[View full size image]

The agent also runs in the tray at the lower-right corner of the screen just as the Windows agent and can be accessed by double-clicking the flag icon. All the configuration and informational options available to the Windows agent are also available to Linux users, such as the personal firewall and local file protection options. The only minor difference when configuring the Linux agent is that the file directory structure used for local file protection is, obviously, Linux oriented.


Solaris Agent Interface

The CSA for Solaris does not have a GUI as is available on the other operating systems. There is, however, a utility called csactl on the Solaris systems installed by CSA that provides some of the same functionality. This section describes the csactl utility and how to stop the Solaris agent.

csactl Utility

The csactl utility is located at /opt/CSCOcsa/bin/csactl.

NOTE

The csactl utility is available only to root.

The csactl utility is a command-line utility, and no graphical component is associated with it. To perform the various tasks available, the user appends the appropriate argument to the end of the csactl command line (for example, /opt/CSCOcsa/bin/csactl poll to force a manual poll of the agent). The following is a list of supported command-line arguments:

  • poll— Forces a manual poll. The response lets the local user know whether the poll succeeded and whether a software update is available for download.

  • resetlog— Allows all log messages rather than the default holdback.

  • status— Responds with the status of the agent and whether a software update is available.

  • swupdate— Updates the agent software to the current available level.

  • infotext— Sends custom informational events to the MC.

  • warningtext— Sends custom warning events to the MC.

  • alerttext— Sends custom alert events to the MC.

  • about— Shows the agent software version.

Stopping the Solaris Agent

To stop the Solaris agent, you must use a command-line procedure because there is no Solaris agent GUI. To stop the agent, type /etc/init.d/ciscosec stop. To restart the agent in Solaris, type /etc/init.d/ciscosec start.


Summary

The CSA GUI can provide great information to the end user or field technician. It can also provide some end-user control of the agent and policy enforcement, such as the ability to disable the agent, answer query rules, and control local personal firewall settings. It is important that the security administrators configuring CSA MC policies fully understand what functionality they can distribute to the user. As with any security mechanism, the policy is only as strong as its enforcement and, therefore, the remote CSAs should be carefully tuned and controlled.


Part IV: Monitoring and Reporting

Chapter 8 Monitoring CSA Events

Chapter 9 Using CSA MC Reports


Chapter 8. Monitoring CSA Events

This chapter covers the following topics:

  • Status summary

  • Event log

  • Event Monitor

  • Event log management

  • Event sets

  • Alerts

As the Cisco Security Agent (CSA) hosts deployed throughout your enterprise architecture begin to protect systems from malicious code, worms, viruses, unauthorized user interaction, and other various policy violations, the CSA Management Console (MC) begins to receive events regarding the various issues. These events are correlated in a central repository on the CSA MC known as the event log. These events provide the security operations team with great insight into their environment. From here, they can see what is currently or has already impacted their environment and tighten current policies or create new policies to allow or disallow specific actions. It is extremely important for the CSA administrator to understand how to use and interpret the event log to efficiently and effectively deploy policies to remote agents as well as react appropriately to malicious events. In many cases, however, this information is used purely for reporting because the malicious actions are noted in the event log as prevented and no further action is required.

The CSA MC offers you several ways to view and sort events in the database. Options for viewing events include summarized views most often used in NOCs or SOCs (network/security operation centers), live event views, and historical views. All of these methods provide for sorting and filtering such that the only data presented at any given time is what is required.

To view events, either historically or live, you start with the Events section of the CSA MC. Events is located on the top navigation bar. Placing your cursor over Events or clicking Events presents a drop-down menu for navigation, as shown in Figure 8-1. The Events menu options are as follows:

  • Status Summary— High-level overview and summarized information

  • Event Log— A filterable complete event log

  • Event Monitor— Recent events refreshed regularly for a near-real-time view

  • Event Log Management— Create tasks to manage the database

  • Event Sets— Sets of predetermined information used when viewing, reporting, or notification of events in the database

  • Alerts— Configuration of alerts based on received events

Figure 8-1. Top-Level Events Menu

[View full size image]

Throughout this chapter, you will explore the various ways to view and use the Events menu to ensure a successful CSA architecture.


Status Summary

The Status Summary screen is a very common view used when you want to get a quick high-level assessment of the health of your agent architecture. As shown in Figure 8-2, the Status Summary page presents a great amount of information, which is viewable in a single compact screen. This page is divided into three sections:

  • Network Status

  • Event Counts per Day

  • Refresh

Figure 8-2. Status Summary Screen

[View full size image]

NOTE

Events are only added to the event log if the rule that triggered on the remote host was set to log. There could be far more actions occurring on the remote agents than seen at the CSA MC if many of the events have logging disabled.

Network Status

The Network Status section is minimized, by default, to display only a few of the important rows. By clicking the plus sign (+), you can expand the section to list several other rows. All numbers are clickable links to either events or hosts that are filtered to show only the information pertaining to the description. The full list of information displayed on this screen is as follows:

  • Events Recorded in the Past 24 Hours— This option displays the number of events that have occurred in the past 24 hours. This is not the number of events in the last •24-hour clock period but the past 24 hours since the page was refreshed or auto-refreshed.

  • Active Hosts with Current Configuration— This option displays the number of hosts running a current policy that has reported into the CSA MC within the last polling interval set for the host. The number is a link to the filtered hosts list view containing only these hosts.

  • Active Hosts Running an Old Configuration— This option displays the number of hosts with an old policy that need an update. These hosts have reported into the CSA MC within the last polling interval set for the host.

  • Active Hosts Running Old Software— These hosts are hosts that have polled in within the last poll interval but are running old agent software. These agents have software updates configured for them but have either not yet been notified of the update or have not installed the update. The number is a link to the filtered hosts list view containing only these hosts.

  • Active Hosts with Software Updates Pending— These agents have polled within the last polling interval and have been informed of the software update but have not installed the update yet. The number is a link to the filtered hosts list view containing only these hosts.

  • Unprotected Hosts— This is the number of hosts that are either not a member of any groups or are in groups without attached policies.

  • Hosts Running in Test Mode— This is the number of hosts currently running in Test Mode, which are not actively protected by all policies assigned to the host.

  • Hosts with Unsupported Platform— This is the number of hosts running on operating systems not officially supported by CSA.

  • Hosts Without Cisco Trust Agent Installed— This is the number of hosts within your deployment that are running the CSA but are not running the Cisco Trust Agent (CTA). The CTA is a component of the Cisco Self-Defending Network Initiative that allows for posture assessment of the local machine before the network admits the device for connectivity.

  • Hosts Not Actively Polling (Status Unknown)— This is the number of hosts that have not polled within the stated polling interval for the hosts.

  • Hosts Without Application Deployment Investigation Data Upload— This is the number of hosts that have run application data investigation but have not yet sent the information to the CSA MC.

  • Groups with No Policies Attached— This is the number of groups that have not been assigned policies. When you click the icon to the right of the number, the list of groups displays in a pop-up menu without redirecting you to a new filter view, as shown in Figure 8-3. The groups displayed in this window are clickable.

    Figure 8-3. Groups with No Policies Attached Pop-Over

    [View full size image]

Event Counts per Day

The Event Counts per Day portion of the Status Summary screen shows you a graphical representation of the number and type of events your architecture has had over the past few days. With this view, you can see whether your daily event count is spiking and in need of further investigation. You can also see within this representation the relationship between the event severities.

The first piece you need to understand when interpreting graphical data is the legend. The legend is to the right of the daily bars in the bar chart. The four colors used are mapped to event severity as follows:

  • Error and Above— The events grouped together in this category are Error, Alert, Critical, and Emergency. These events are more impacting than the lower severities and are colored red to stand out.

  • Warning— Warning events are colored orange.

  • Notice— Notice severity events are colored yellow.

  • Informational— Informational events are colored green.

When interpreting the graphical view, you also need to understand the axis labels. The x-axis across the bottom of the graphic represents days. Each bar represents a 24-hour period starting and ending at midnight on the date listed below the bar. The month is also listed just below the days. These dates are clickable links that take you to a filtered view of the event log containing only those particular days events. The y-axis has only one number listed at the top of the axis. This number is the maximum number of events received on any of the displayed days. The number is listed here to give you an understanding of the scale related to the bar charts. If the y-axis is labeled at 15,000 events and you have 2 days represented where 1 of the days is half the size of the other day, you might want to look at the events much closer to understand why you had 7,500 more events on that day. However, if the number listed as the scale is 30, you might not be as worried because the difference between the 2 days is only 15 events.

NOTE

Placing your cursor over the date below the bar chart without clicking causes a small text message to pop up displaying the number of events on that particular day, which might not easily be discernable from the chart itself.

The final piece of the graphic to understand is the information related to the bars themselves. The entire bar for a given day displays the number of events logged over that particular 24-hour period in relation to the other days displayed and the day displayed with the most events logged. Within a particular bar, the types of events are colored as per the legend and stacked to form the bar with the lower-severity events at the bottom and the higher-severity events at the top of the bar. This view enables you to get quick security health-check information about the deployment. Another great feature of this graphical view is that the bars themselves are also clickable links that redirect you to a filtered view of only the events from that day matching that particular severity group. This function can make your administration of the product more efficient by saving you the time it would normally take to create the filter necessary to view this information. For example, Figure 8-4 shows a filtered view of a single day in the event log as would display after clicking the link associated with the date below any particular bar in the summary window.

Figure 8-4. Single Day Filtered View of the Event Log

[View full size image]

Refresh

The Refresh portion of the Status Summary screen is located at the bottom of the page. From here, you can set the automatic refresh rate of the Status Summary screen. By default, it is set to refresh the information every minute. You can view the countdown to when the next refresh will occur, refresh immediately by clicking the Refresh link, or change the refresh interval to 30 seconds, 1 minute, or 5 minutes. The auto-refresh of this screen makes the data available close to real-time values, and therefore this has become a popular screen displayed around the clock in many NOCs and SOCs.


Event Log

The event log provides historical views of logged events from the most current to the oldest. These views can prove useful when attempting to understand what is impacting your user environment as well as when tuning and enforcing policy. By default, the event log shows all events recorded that have not been purged. Just as with the near real-time view provided by the Event Monitor, you can filter the event log to provide a concise view of the information you want to see. Figure 8-5 shows a sample Event Log screen.

Figure 8-5. The Event Log Viewer

[View full size image]

NOTE

The event log database access is also available to third-party applications via database access using an ODBC DSN of CSCODSN. Detailed database schema and view information is located in the CSA documentation. Only qualified individuals should attempt communication with the CSA SQL database because any incorrect statements or actions could cause database loss or corruption.

Filtering the Event Log

You can set the event log filter to display only the events you want to see. The current filter parameters display at the top of the Event Log screen. At the top of the filter parameters, an indicator describes which events, by event number, you are currently viewing. Adjacent to this is the Change Filter option. The following list describes the current filter parameters:

  • Filter by Event Set— This option is the same as described previously in the "Event Monitor" section. Event sets are described later in this chapter.

  • Define Filter— This section provides customizable filtering parameters. The majority of the parameters available to filter this view, which is shown in Figure 8-6, are described as follows and are illustrated in Figure 8-7:

    • Start Date and End Date— You can format specific start date as hh:mm:ss with AM/PM as options. If you do not specify AM/PM, then hh should be in the 24-hour format. Both minutes and seconds are optional, with only hours required.

      You can format specific start date with month and day information as mm/dd/yy (day and year are optional) or as monthname dd, yy (day and year optional).

      Alternatively, you can use relative time, which uses the following keywords: ago, today, now, last, yesterday, day, week, month, year, hour, minute, or second.

      Example 1:

      Start Date = 22 hours ago

      End Date = 13 minutes ago

      Example 2:

      Start Date = yesterday

      End Date = 3 minutes 5 seconds ago

      Example 3:

      Start Date = 10/05/2000 22:04:00

      End Date = now

    • Minimum Severity— This value is a drop-down box populated with the selection options related to the seven severity possibilities, sorted from lowest to highest:

      Information

      Notice

      Warning

      Error

      Alert

      Critical

      Emergency

      For this option, choose the lowest severity you want to view. By default, this is set to Information.

    • Maximum Severity— As with the Minimum Severity option, this drop-down box lists seven possible severity options. Choose the maximum severity setting you want to view. By default, this is set to Emergency.

    • Host— This option enables you to filter events based on a host or group of hosts you choose. By default, this is set to All. To specify a host or group, click Change. A pop-up window then presents you with two options: Select the Following Host drop-down box and Select All Hosts in the Following Group drop-down box.

      These lists are prepopulated with hosts and groups the CSA MC knows about, including the mandatory groups of All Windows, All Linux, and All Solaris. A displayed host or group is a clickable link to the settings page for that entity.

    Figure 8-6. Filtered Event Log View

    [View full size image]

    Figure 8-7. The Event Log Filter

  • Rule Module— This is a drop-down box selection tool prepopulated with all CSA rule modules. By default, this is set to All.

  • Rule ID— This is a text field that you can populate with the specific rule ID for the events you want to see. By default, this is blank.

    • Events per Page— Defaults to 50, with no defined maximum.

    • Filter Text— Include or exclude events that contain the text specified.

    • Filter Out Duplicates— You have the option to filter any duplicate events and only show the original and not the recurring messages for the same event.

    • View button— View the event log after applying the filter.

NOTE

When you apply the filter using relative times, the displayed filter parameters at the top of the Event Log view translate that information to specific dates and times relative to the date and time on the CSA MC server.

Interpreting and Using the Event Log

The events held within the event log and presented by either the Event Log Viewer or the Event Monitor must be interpreted in order for the information to prove useful to you.

Figure 8-8 shows a sample event log with several events. This section discusses the information presented in a single event.

Figure 8-8. Events as Displayed in an Event Log

[View full size image]

Events in the database are separated by alternating colors to help you better understand where one event ends and another begins. From left to right, each single event is separated into columns, as follows:

  • #— This is a number associated with each event in order relating only to events in the current filtered view. The events with higher numbers occurred more recently than those with lower numbers.

  • Date— This shows the date and time the event occurred on the agent machine. When events occur on the agent-protected machine that cannot be transmitted to the MC because of reachability issues, the events are stored and transmitted with the correct time stamp when reachability is again possible.

  • Host— This is the host that reported the event. The host is a clickable link directly to the host configuration page.

  • Severity— This indicates the severity level of the logged event.

  • Event— This contains the specific event information, which you learn more about in the next section.

Understanding Event Field Information

The Event field in the various log views contains a great deal of information, including links to policy-tuning options. If the particular event occurred in Test Mode, it will be prepended by TESTMODE and can be filtered using the include/exclude text-filtering option. The event itself is then explained in simple terms with necessary variables such as IP address, port number, and filename information included. Below each event are clickable options that become available depending on the type of rule that triggered the event. The options are as follows, which you learn about in the next sections:

  • Details

  • Rule Number

  • Wizard

  • Find Similar

Details

When you choose the Detail option, you see a new window with very detailed information about the specific event, as shown in Figure 8-9. The field options differ slightly per rule type you view. A few of the common fields and descriptions are as follows:

  • Description— Describes the specific policy rule

  • Module— Specifies the rule module that includes the rule

  • Event Text— Provides the information displayed in the Event field

  • Event Time— Shows the date and time the event occurred

  • Code— Lists the code associated with the triggered rule, which would be useable by TAC in a troubleshooting situation

  • PInt— Indicates the rule number that triggered the event

  • PString— Shows the variable used in the Event field relating to what triggered the event

  • Time— Shows the number of seconds since the agent machine booted

  • Type— Indicates the type of event such as FILE, APICALL, and TDI

Figure 8-9. Event Details View

[View full size image]

The detailed view displays several other fields. These fields become available depending on the type of rule that triggered the event. For example, for file events, you see fields relating to the file accessed and operation performed or attempted, whereas network operations include information regarding the IP addresses and ports involved. This information will be a great help for Cisco Technical Assistance Center (TAC) support staff when assisting you with troubleshooting rule behavior.

Rule Number

The Rule Number option is a clickable link in the Event field. This option directs you to the specific rule that triggered this event so that you can view and possibly configure it appropriately.

Event Wizard

The Event Wizard is an invaluable option when tuning deployed rules. This option launches a pop-up window titled Event Management Wizard, as shown in Figure 8-10. This wizard assists in creating exception rules to override specific rules, exception rules that prevent logging of specific events, or behavior analysis jobs that can provide detail about the process that triggered the event. All in detail in Chapter 12, "Creating and Tuning Policy."

Figure 8-10. Event Management Wizard Pop-Up Window

Find Similar

The Find Similar option is a quick way to isolate a type of specific event to view. When this option is clicked, a pop-up window appears with some simple filtering options, as shown in Figure 8-11:

  • Same Host— Check this box to find events from the same host.

  • Same Policy Rule— Check this box to find events triggered by the same policy rule

  • Same Severity Level— Check this box to find events of the same severity •level.

  • Same Type— Check this box to find events of the same type rule.

  • Same Time Frame— Check this box and set the time entry to find the matching events within a specific timeframe both before and after the selected event.

Figure 8-11. Find Similar Pop-Up Window Options

    Previous Section < Day Day Up > Next Section


Event Monitor

The-"/> Event Monitor is another near real-time view of the events reported by agents. This screen, which is shown in Figure 8-12, also automatically refreshes just as the Status Summary page. You can edit the refresh interval by changing the value from the drop-down box toward the top of the page. The refresh interval options are 15 seconds (default), 1 minute, and 5 minutes. The countdown to the next refresh displays directly above this •drop-down box as an indication of when the refresh will take place.

Figure 8-12. Event Monitor Near Real-Time Data

[View full size image]

By default, the Event Monitor displays all events. You can customize this view to display only the events you want as they occur. To see how the current view is filtered, you can examine the filtering values displayed at the top of the screen in the Monitoring Filter section. The filter variables displayed are as follows:

  • Displaying— You see the number of events displayed. By default, the Event Monitor displays the last 50 events.

  • Severity— You see the type of events displayed by severity of the events received. By default, it displays all events (Informational through Emergency).

  • Host— You can display only events related to specific hosts. By default, this is set to All Hosts.

  • Rule Module— You can display events related to a specific rule module. By default, this is set to All Modules.

  • Filter Out Duplicates— You can filter duplicate events from the Event Monitor to "clean up" the view. By default, this is set to No.

NOTE

Reported duplicate events are not logged for an hour after the first recorded event. Events are also suppressed if they are logging continuously, but a suppression event is logged to denote this. Verbose logging at the group level overrides both of these suppression mechanisms.

You can edit the Event Monitor view by defining a filter for the view. Click Change next to Monitoring Filter at the top of the page to display the Filter Events pop-up window shown in Figure 8-13.

Figure 8-13. Filter Events Options

The Filter Events window enables you at the highest level to select two major options: Filter by Event Set and Define Filter. You learn about event sets later in the "Event Sets" section of this chapter. At this point, you need to learn about the Define Filter option to better understand the filtering methods allowed.

Within the Define Filter section, you have many configurable options. You do not need to set all parameters specifically, because anything that is not changed keeps the default filter settings. The configurable options when defining a filter are as follows:

  • Minimum Severity— This value is a drop-down box populated with the selection options related to the seven severity possibilities sorted from lowest to highest:

    • Information

    • Notice

    • Warning

    • Error

    • Alert

    • Critical

    • Emergency

    For this option, select the lowest severity you want to view. By default, this is set to Information.

  • Maximum Severity— As with the Minimum Severity option, this drop-down box lists seven possible severity options. Select the maximum severity setting you want to view. By default, this is set to Emergency.

  • Host— This option enables you to filter events based on a host or a group of hosts you select. By default, this is set to All. To specify a host or group, click Change. A pop-up window then presents you with two options:

    • Select the Following Host drop-down box

    • Select All Hosts in the Following Group drop-down box

    These lists are prepopulated with hosts and groups the CSA MC knows about including the mandatory groups of All Windows, All Linux, and All Solaris. A displayed host or group is a clickable link to the settings page for that entity. See Figure 8-14 for the Filter Events by Host pop-up window.

    Figure 8-14. Filter Events by Host Window

  • Rule Module— This is a drop-down box selection tool prepopulated with all CSA rule modules. By default, this is set to All.

  • Rule ID— This is a text field that you can populate with the specific rule ID for the events you want to see. By default, this is blank.

  • Display Last— This text field enables you to set the number of events you want to view on the Event Monitor screen. By default, the value is set to 50 events, with a possible maximum of 100 events. The Event Monitor only displays the most current events. To view more events, including historical events, use the event log as an alternative to the Event Monitor.

  • Filter Text— This is a combination of a text field and an option button selection. The option button enables you to choose Include or Exclude keywords. The text field enables you to filter the view according to a specific combination of characters, phrases, or words. The combined effect of the text field and option button enables you to specify all events where the text either appears or specifically does not appear.

  • Filter Out Duplicates— This is an option button selection of either Yes or No, which enables you to clean up the view you are presented with by showing only unique events if desired. The default selection is No.

  • Monitor button— This button applies the filter to the Event Monitor view.

The example in Figure 8-15 shows a filter on the Event Monitor set up to display only the last three events with a severity between Alert and Emergency pertaining to the CSAMC45•.csa.com host. Therefore, the Event Monitor only displays the events as they are reported to the MC from the agents that match the specific filter.

Figure 8-15. Filtered Event Monitor View

[View full size image]

NOTE

Remember that as an alternative to the filter you can manually define, you can also select an event set to filter the Event Monitor view. Event sets can be much more granular and might provide the desired view. Event sets are saved and can be reused very easily every time you require that specific filtered view.


Event Log Management

Event log management is performed from the Events menu. You can access two types of log management actions: event insertion tasks and auto-pruning tasks. The next sections describe both tasks.

Event Insertion Tasks

Event insertion tasks are how the CSA MC database controls how events are placed in the database and how events are purged when events at certain severity reach specified thresholds. You can select and configure the global event insertion task to fit your environment. By clicking the Event Insertion Task link, you are presented with the screen shown in Figure 8-16.

Figure 8-16. Global Event Insertion Tasks Tuning Page

[View full size image]

The top of this page displays information from the current event log database. This information includes the number of events, a graphical representation of the types of event by severity, and links to filtered views of those event types.

The bottom half of the screen provides the tunable parameters for the global task insertion rules. The text boxes provide thresholds that relate to the different severity levels. Basically, if the number of events housed in the database exceed certain levels, new events of specified severities received by the CSA MC are not recorded. Insertion tasks guarantee that if a spike of events occurs, the most important events are given priority to the database.

Auto-Pruning Tasks

Whereas the global insertion parameters control whether new events are logged in the database, auto-pruning tasks control how the database removes old events to make room for the new tasks. To configure an auto-pruning task, click New from the Event Log Management screen. The configuration screen that appears has very few options that require configuration, as shown in Figure 8-17. The new task requires a name and description just as the other configurable options within the CSA MC. You also have a check box to state whether the task is enabled or disabled currently.

Figure 8-17. Auto-Pruning Configuration

[View full size image]

Finally, you have the options related to which events should be removed. The two options here are Delete Events variable Day(s) Old and Matching the Following Event Set. These two parameters enable you to state how old the event must be before being purged, and enable you to apply an event set scope to which events should be purged. Just below the configuration options, you see a statement regarding whether this task has been run and when it has been run. Auto-pruning tasks are not scheduled manually but are run by the CSA MC typically at a time when the MC is least busy.


Event Sets

You use event sets when filtering and purging logs, creating reports, and configuring alerts. These event sets contain specific information that allow for granular control over various reporting and logging functions. CSA MC includes a number of predefined event sets, as shown in Figure 8-18. You can also create event sets to your own specifications.

Figure 8-18. Predefined Event Sets

[View full size image]

To better understand an event set, examine the Events from Mission Critical Systems predefined set. To see the configuration of this event set, click the name of the set. After it has opened, you will notice the top two fields are the Name and Description fields, as shown in Figure 8-19. Below that information, the rest of the settings appear under the Event Specifications section. The first part of the Event Specifications section specifies the type of events that should be limited in scope. You can select to include all event types or specific event types from the multiple-selection box. Some types of events include rule triggers, Test Mode triggers, agent/MC software issues, @dynamic events, as well as behavior information and others.

Figure 8-19. Events from Mission Critical Systems Event Set

[View full size image]

NOTE

To choose more than one option in any of the variable selection fields during event set configuration, press and hold the Ctrl key while clicking the options you want to choose.

The next part of the Event Specifications section enables you to specify the event severity levels that should be included in the set.

Following the severity options is a portion regarding host information. Host information relates to either all hosts or specific groups. The next options relate to policy rules. Policy rules can be limited by specific rule modules or all rules. Finally, you can control the scope applied by the event set by setting timestamp parameters.

The bottom of the Event Sets page provides the following buttons:

  • Save— Save the edited or created event set

  • View— Filter the event log by this event set and display it

  • Purge Events— Remove all events in the event log that match the event set scope

  • Delete— Remove the event set from the Event Set list


Alerts

Alerts are configurable via the Events menu, with options of how, where, and why alerts should be sent. By default, events are logged in the event log; support staff notification occurs only if they examine the CSA MC screens. To take a more proactive approach to managing security-impacting events, configure alerts for notification.

To configure an alert from the Alerts page, click the New button. As with all other configurable items, you need to configure a name and a description for the alert. After the Name and Description fields, you see the following configuration information, as shown in Figure 8-20:

  • Send Alerts for the Following Event Sets— Specify the event set match that will trigger alerts. You must configure an event set to identify which specific events will cause alerts to be sent.

    Note

    Event set time options are not used when applied to alerts. Alerts such as pager and e-mail notification are sent in real time as events are received from agents and placed in the CSA MC event log, and historical timeframes are not applied.

  • Alert Method— You must configure one of the following methods of alert delivery:

    • Email— The Alert is sent via e-mail. Configurable parameters for this type of alert include recipient(s) address(es), sender address, mail server name/IP, and subject line.

    • Pager— The alert is sent to a pager. Configurable parameters include telephone number, PIN, modem init string, modem dial string, characters per block, port, and baud rate. This alert type requires the CSA MC to have a Hayes-compatible modem installed locally.

    • SNMP— The alert is delivered as an SNMP trap. Configurable parameters include community name and SNMP management station IP address.

    • Log— The alert is written to a log file. The only configurable parameter for this alerting mechanism is the log file location, including path and name. The log file created contains several fields that are explained in detail within the CSA Help files and documentation.

      Note

      The log file created as part of the alerting mechanism will only reach 1 MB in size before the file is closed and prepended with a timestamp. Another file is then opened in its place with the same filename as before.

    • Custom— The alert is handed to a custom program as a parameter to the executable. The parameter passed is the log file created to send to the program. This file is temporary and only exists until it is passed to the application. The program name and path are the only configurable options.

      Note

      The custom program must be located in the CSCOpx directory or subdirectory for it to work according to CSA MC policies, and the execution of the custom application cannot require any user input.

    • Named Pipe— The alert is handed to a third-party application via a named pipe. The application must be local because the prepended named pipe information is \\ .\pipe\, where the period denotes the local machine. The only configurable parameter is the rest of the named pipe location or the name of the local system.

Figure 8-20. Alert Configuration Screen

[View full size image]

Alerts can be sent via one or more mechanisms by checking the appropriate check boxes at configuration time. Another option you have for controlling the sending of alerts is the Purge Pending Events button. This button enables you to purge the list of alerts queued for sending that have not yet been sent. You might want to purge alerts if you are already working an issue that spurned many alerts. You would not need to receive any more alerts relating to the event triggers in this particular case, and all further alerts queued up for delivery could be removed.


Summary

Understanding, interpreting, and using the event log database efficiently directly affects how successful your CSA deployment will be. For day-to-day post-installation monitoring of CSA, refer to the various views available below Events on the main navigation menu to find the information required. Another important topic covered in this chapter is alerting, which speeds in the remediation of security events affecting your architecture by alerting via other management tools and informing the necessary individuals as soon as possible. In the coming chapters, you begin to use the information within the database to assist in tuning the product for an effective, unintrusive, and highly secure deployment.


Chapter 9. Using CSA MC Reports

This chapter covers the following topics:

  • Audit trail reporting

  • Event reporting

  • Group detail reporting

  • Host detail reporting

  • Policy detail reporting

  • Report viewing

  • Creating a sample report

Chapter 8, "Monitoring CSA Events," covered using the event log to provide the insight needed to manage your CSA deployment. The historical and near real-time views into the event database provide much of what you need when responding to security issues, alerting necessary parties, tuning the initial deployment, and developing future policy based on historical endpoint usage information. To most efficiently use the reporting feature of the CSA MC, it is necessary to understand how to efficiently use event sets, because they are the major configuration component of the event detail reports. For more information on event sets, revisit Chapter 8. This chapter examines another way to get information from the CSA database regarding stored events and configuration information. These capabilities are within the section of the CSA MC known as Reports.

CSA can provide reports regarding MC auditing information, events within the database, group and host configuration information, and policy information. You can access these reports through the Reports menu available from the main toolbar in the CSA MC, as shown in Figure 9-1. The default installation of the CSA MC includes some predefined reports, but can also create customized reports that suit your needs.

Figure 9-1. Accessing the Reports Menu

[View full size image]


Audit Trail Reporting

As with any security enforcement tool, it is very important to have an auditing mechanism available to monitor usage. In some cases, having auditing capabilities is not a nicety but rather an absolute requirement that assists with legal compliance. Auditing also assists with understanding what policy changes have been made and which administrator made the changes.

The CSA MC can use role-based access control (RBAC). RBAC enables you to give multiple users unique user IDs to access, configure, and monitor the MC with varying levels of rights. You learn about setting up users in the Network (VPN)/Security Management Solution (VMS) environment in Chapter 14, "CSA MC Administration and Maintenance," but for now assume the users are already created and focus on the auditing capabilities of the CSA MC.

To view basic auditing information, choose Reports > Audit Trail to display a screen listing all audited events, as shown in Figure 9-2. By default, this page displays audit events from the most current to the oldest. You can change the order to show the oldest events first by clicking Earliest just above the audit event listing. As with the other event database views, you can apply a filter to the audit information to customize the information presented onscreen. The current filter parameters display at the upper-left corner of the report page. The generic view always displays all events.

Figure 9-2. CSA MC Audit Trail Report

[View full size image]

The information presented as part of the Audit Trail report is formatted much like the event log. Audit log rows are separated by alternating color bands to simplify viewing. Each row is formatted the same, with information in each row separated by columns of specific audit event information. The audit event columns are as follows:

  • #— This column shows the number of the event in the current filtered or unfiltered view. The higher the number, the more recent the event in comparison to the other events.

  • Change— This is the change that took place. Every audited action taken by an administrator is known as a change. The entity that was configured as part of this audit event is clickable, and choosing the item within this report causes the specific configuration page to appear.

  • Type— This column denotes what type of change took place. Changes are grouped together in major categories such as Event Set, Generate Rules, Agent Kits, Group, Alert, Rule Module, and so on. The Type field is a clickable link that presents the specific top-level item page. For example, click Event Set in this column to see the Event Set Configuration top-level page.

  • Date— This is the specific date and time of the audited event.

  • Administrator— This column lists the administrator user ID who made the change associated with this audit event.

To apply a filter to the audit trail view, click the Change Filter link at the top of the page. When you attempt to change the filter, a pop-up box displays, as shown in Figure 9-3. You can change the following filtering information:

  • Start Date and End Date— Format this information as you would when defining filters for the event log and Event Monitor, which you learned about in Chapter 8. You can use the following formats and wording:

    • Specific start date formatted as hh:mm:ss with AM/PM as options. If you do not specify AM/PM, then hh should be in the 24-hour format. Both minutes and seconds are optional, with only hours required.

    • Specific start date formatted with month and day information as mm/dd/yy (day and year are optional) or as monthname dd, yy (day and year optional).

    • Relative time using keywords ago, today, now, last, yesterday, day, week, month, year, hour, minute, or second.

    • Example 1:

      Start Date = 22 hours ago

      End Date = 13 minutes ago

    • Example 2:

      Start Date = yesterday

      End Date = 3 minutes 5 seconds ago

    • Example 3:

      Start Date = 10/05/2000 22:04:00

      End Date = now

  • Administrator— Choose a specific administrator account from the drop-down menu to filter the view to include actions taken by that specific individual only. By default, this is set to All.

    Note

    Auditing is only as accurate as your password enforcement. If a login ID is used by more than one person or can be compromised, the audit trail will remain intact but you cannot guarantee who was logged in to the system with that ID at any given time.

  • Change Type— Choose the specific change type from the drop-drown list menu that you want to view in this audit report.

  • Changes per Page— Set the number of audit events you want to display per page. By default, this is set to 50 per page.

Figure 9-3. Audit Trail Filter Parameters

[View full size image]


Event Reporting

Event reporting is a great way to create documents for your organization. You can present technicians providing remediation services a report identifying the systems that require maintenance. You can also create specific documents for management personnel who want to see detailed security policy enforcement reports. The CSA MC reporting mechanism is very flexible in its approach, and every organization will find uses for this feature.

The Reports menu enables you to obtain event reports by severity and event reports by group. The next sections describe both events.

Events by Severity Reports

When you choose Reports > Events by Severity any reports that you have already defined appear in the screen presented, as in Figure 9-4. To create a new report of this type, click the New button at the bottom of the page.

Figure 9-4. Available Report Listing

[View full size image]

Creating this report, as shown in Figure 9-5, is very simple with only a few parameters to set, as follows:

  • Name— Name the report.

  • Description— Provide a description for the report you are creating to help others understand the report details.

  • Event Filter— Choose the event set from the drop-down menu that you want to use to create the report. This is the most important piece of information selected when creating a report. The event set parameters are how you define which events are consolidated as part of this report.

  • Sort by— Choose the order in which you want the information shown. Options to sort by are as follows:

    • Time

    • Host

    • Event Code

    In addition, check the check box to sort the information in ascending order versus the default of descending order.

  • Viewer Type— Choose how the report should be presented. The two options are HTML Frame or ActiveX. HTML Frame presents the report in a standard HTML window. ActiveX reports use a Crystal Report viewer browser plug-in. ActiveX reports can easily be printed and saved for forwarding as a standalone file via e-mail or other methods.

Figure 9-5. Configuring a Report

[View full size image]

After choosing the parameters, you can use the buttons at the bottom of the configuration page to either save the report, view the report, or delete the report.

The HTML Frame view of a report, as seen in Figure 9-6, uses standard HTML frames for displaying the report requested. This view is very similar to the ActiveX display, but does not enable you to export and share the document as a standalone file. To navigate to specific sections of the report, use the links in the left frame. You can also use the navigation tools in the top frame to skip to a specific page or view page by page and search the document for specific text. Click the lightning bolt icon when you need to refresh the displayed report with current information.

Figure 9-6. Sample HTML Frame Report

[View full size image]

The report shown in Figure 9-7 uses the Crystal Report ActiveX viewer. To navigate this view, you can either use the scroll bar on the right side of the report or click the links in the left window that enable you to maneuver to the specific portion of the report needed. As with the HTML Frame view, you can skip through the report page by page or enter the specific page number you want to view. You can also search this report by clicking the binocular icon and entering the text you want to find. Access the icons at the top of the page for other options not available in the HTML Frame view. To print the report, for example, click the printer icon and follow the typical printing instructions for your printer. Save or export the report to view later or share with others by clicking the envelope icon. After making your selection, you can export to one of the following formats:

  • Crystal Report

  • Crystal Report 7.0

  • Rich Text Format (RTF)

  • Word document

  • Excel 5.0 document

Figure 9-7. Sample ActiveX Report

[View full size image]

The lightning bolt icon enables you to refresh the report with current data in the CSA MC event database.

Events by Group Reports

Reporting events by group is similar to reporting events by severity. The only difference is how the report is sorted. If you recall, groups provide a unique way to associate hosts. You can create a group from specific application servers, specific host types, or even geographic location. Figure 9-8 shows how a report differs based just on the sorting options on the left side of the screen.

Figure 9-8. Reporting Events by Group

[View full size image]


Group Detail Reporting

You access Group Detail reports through the Reports menu. The report configuration for this type of report is very similar in its configuration other than the report configuration parameter specific to this report, which is the group or groups to be displayed. Figure 9-9 shows a sample configuration for a report of this style.

Figure 9-9. Group Detail Report Configuration

[View full size image]

Group Detail reports contain information regarding the configuration of that particular group or groups. This information includes architecture, polling interval, and other group configuration information. The report also includes the listing of hosts included in the group, the policies attached to the group, and the full list and details of the rules attached to the group. After configuring the Group Detail report desired, click the View Report button located at the bottom of the configuration page to see the report, as shown in Figure 9-10.

Figure 9-10. Sample Group Detail Report

[View full size image]


Host Detail Reporting

You can access Host Detail reports through the Reports menu. Figure 9-11 shows a sample configuration for a report of this style. As with Group Detail reports, the Host Detail report includes configurable parameters for name, description, groups, and viewer type.

Figure 9-11. Host Detail Report Configuration

[View full size image]

Host Detail reports, as shown in Figure 9-12, contain information regarding the configuration of hosts. To view this type of report, you first configure the report as described earlier, and upon completing the configuration, click the View Report button at the bottom of the configuration page. The detailed information in this type of report is as described in Chapter 3, "Understanding CSA Groups and Hosts," and includes the following:

  • Host description

  • Operating system

  • Product information

  • Host UID

  • Group membership

  • Applied rule modules

  • Registration information

  • Polling detail

  • IP address

Figure 9-12. Host Detail Report

[View full size image]


Policy Detail Reporting

You can access Policy Detail reports from the Reports menu. Figure 9-13 shows a sample configuration for a Policy Detail report. The configuration mechanism for this report is very similar to host and group detail reporting, except for the policy-specific information required. The policy-specific configuration option is a multiselection listing populated with policies that are configured in the CSA MC. You can choose a single policy or multiple policies if desired.

Figure 9-13. Policy Detail Report Configuration

[View full size image]

Policy Detail reports, as shown in Figure 9-14, contain information regarding the configuration of policies. This information includes the following:

  • Policy version and description

  • Target architecture

  • Number of associated rules

  • All associated specific rule details

Figure 9-14. Policy Detail Report

[View full size image]


Report Viewing

You can set many of the reports configured on the CSA MC to display via two viewing options: HTML Frame or ActiveX. The HTML Frame view uses a standard HTML frames perspective and HTML links to browse specific portions of the reports. ActiveX uses a Crystal Report browser plug-in that can provide a more robust and shareable reporting front end. As you learn about and view various reports throughout this chapter, you will see various sample reports in both viewing mechanisms.


Creating a Sample Report

Now that you have learned the report types available within the CSA MC, in this section you create a sample report to tie the pieces together. The Events by Severity report created provides you information regarding only Test Mode events, with a severity of Alert through Critical. You can sort this report further by host and display it in ActiveX. To create this report, you need to first create the event set that will limit the scope of events that the report will use. Figure 9-15 displays the sample event set created to limit the scope.

Figure 9-15. Event Set Configuration for Sample Report

[View full size image]

After creating the event set, you can proceed to report configuration. After navigating to the Event by Severity report section and clicking New, you can configure the report name and description, the event set, and the viewer to use. Figure 9-16 shows the report configuration.

Figure 9-16. Sample Report Configuration

[View full size image]

Figure 9-17. The Completed Sample Report

[View full size image]

After saving the report configuration, click View Report to open the report in the ActiveX viewer. When the report opens in the ActiveX Crystal Report viewer, you can view or save the report as necessary.


Summary

Reports provide a necessary component to the CSA product through document creation. You can use these reports as configuration documentation, audit logs, and hard-copy event reporting. When you understand event logs and reports, the ongoing support of the implemented CSA architecture is greatly eased.


Part V: Analyzing CSA

Chapter 10 Application Deployment Investigation

Chapter 11 Application Behavior Analysis


Chapter 10. Application Deployment Investigation

This chapter covers the following topics:

  • Using application deployment investigation

  • Using application deployment reports

Throughout this book, you have learned about the various components in the Cisco Security Agent (CSA) architecture that enable you to protect endpoints and granularly control applications on those systems. Although this product provides you with a great advantage and is an excellent tool to have in your bag of tricks, it is not always the applications and processes you "know" about that cause your most debilitating issues.

In addition to protecting and controlling your systems that use a standard set of applications based on a corporate desktop image, you also need to understand what else is installed and running on the systems. End users might manually load applications without technical support knowledge, for example. Software that has arrived via unauthorized installations, such as adware and spyware, might also be on the system without your knowledge. Regard-less of how the software or process ended up on the system, you should be aware of it and be ready to protect or reject its use. This chapter explains how CSA provides system software interrogation and reporting through a mechanism called application deployment investigation, which includes the actual investigation process as well as the reporting feature.

Under the Analysis menu shown in Figure 10-1, you have two main options related to application deployment:

  • Application Deployment Investigation

  • Application Deployment Reports

Figure 10-1. Analysis Configuration Menu

[View full size image]

Application deployment investigation is where this chapter begins because it contains the screens necessary to perform the collection of application data. When the investigation job is complete, we conclude the chapter with the reporting feature, which enables administrators to use what they learned from the investigation process.

NOTE

Application deployment investigation is only supported for agents running on Windows systems.


Using Application Deployment Investigation

Application Deployment Investigation is a new feature available as of CSA version 4.5. Understanding this feature enables administrators of the CSA product to better understand the applications installed and running on the systems they are attempting to protect. Remember, the ultimate goal of CSA is to maximize system and end-user efficiency by preventing outages and unauthorized application use while protecting corporate assets and information.

The two components used during application deployment investigation are the CSA Management Console (MC) and CSA agent. Both of these components are inherent in the base installation of the CSA products and require no further licensing for this feature to function. The CSA MC is where you configure investigation parameters and view reports regarding the collected data. The CSA agent performs application investigation on the local host and reports back the findings to the CSA MC for correlation and further analysis.

On the Application Deployment Investigation menu, you have the following four options:

  • Group Settings— To perform an investigation, you must configure the groups that will participate in the analysis.

  • Product Associations— After completing the investigation, you must associate applications to the actual processes for the reporting to work correctly.

  • Unknown Applications— When you locate a process that is not associated with an application, it will be located here.

  • Data Management— To control the amount and type of data associated with investigations warehoused on the CSA MC, you must configure data-retention parameters.

The next sections describe each option in more detail.

Group Settings

Choosing the Group Settings menu option brings you to a screen that lists currently configured group sets configured for application deployment investigation, as shown in Figure 10-2.

Figure 10-2. Application Investigation Group Settings List

[View full size image]

To configure an application deployment investigation, follow these steps, which correspond to Figure 10-3:

Step 1.
From the Group Settings page, click New.

Step 2.
Enter a name specific to this application deployment investigation •job.

Step 3.
Enter a description that provides insight into the details of this job.

Step 4.
Check the check box next to Enable Application Deployment Investigation.

Step 5.
Choose one of the following:

  • Product Data Collection— This option reports only the installed applications and no further information.

  • Product and Network Data Collection— This option provides the installed application information as well as information about applications that interact with the network.

  • Product and Verbose Network Data Collection— The Verbose option adds specific IP address-related data to the reported information.

Step 6.
Choose the upload interval for this job. The default (and minimum) timeframe is 24 hours. This is the time interval during which the agent collects information related to the preceding three options.

Step 7.
Choose the group or groups on which you want to perform application deployment investigation.

Step 8.
Click Save.

Step 9.
Click Generate Rules.

Figure 10-3. Application Deployment Investigation Configuration

[View full size image]

NOTE

Application deployment investigation does not prevent agent protective mechanisms during the reporting process. All protective rules in an agent local policy continue to run as centrally defined.

It is important to understand the preceding settings when deploying application deployment investigation to agents within the architecture. The three collection options impact the amount of data stored and transmitted. Product data collection is the least-intensive method of data collection and only reports installed products. Product and network data collection requires more storage capacity because it also reports applications that connect to the network as clients and servers. Product and verbose network data collection is the most intensive approach to data collection because it also collects and reports IP address information with regard to the network interaction. You should only use the verbose method when you require IP address information, because it dramatically increases the storage requirements.

NOTE

When an application deployment investigation process is working on an agent, you can see two files in the local agent \CSAgent\log directory with names starting with trackdb and the date of the analysis. The two files will have .dir and .pag extensions.

After you have completed all the steps, you can begin to collect data on the agent endpoints. The agents begin collecting data only after they have been instructed via their normal polling communication. To verify the group selected is running an application deployment investigation job or has reported information back to the CSA MC, view the group configuration page. (See Figure 10-4.) The group configuration page has a section that states whether the investigation is enabled. If so, you can click the Reports link to get a pop-up page that displays available reports. Also, clicking the Yes link redirects your browser to the application deployment investigation configuration page that impacts this specific group.

Figure 10-4. Application Investigation Group Indication

[View full size image]

You can also view information regarding the job from a specific host page, as in Figure 10-5. From the host-specific page, you can link to the reports available and view the date and time the host transmitted information as a result of the job. You can also click the Detailed Status and Diagnostic link within the Status pane to view information about the agent, as seen in Figure 10-6. The information you will receive from this link includes the last poll time current IP address, Cisco Trust Agent (CTA) posture, and the current Remote Security slider bar state.

Figure 10-5. Application Investigation Host Indication

[View full size image]

Figure 10-6. Host Detailed Status and Diagnostic Screen

[View full size image]

The Reset Cisco Security Agent button in the Host Diagnostics window enables you to reset the agent to factory default settings. This button has the same effect as the local agent option to reset the agent to factory defaults but enables you to perform this action from anywhere in the world. This process includes clearing locally defined firewall policies, file protection policies, and cached responses to query messages.

Product Associations

After you have received a data upload from the remote agents as a result of a configured application deployment investigation, you can choose the Product Associations option. This screen lists the applications installed on the agent systems along with a description and whether the application is configured, as shown in Figure 10-7. The CSA MC server needs to understand which processes or executables are part of which application as reported by the agents so that certain reports will provide the desired information.

Figure 10-7. Sample Product Associations Screen

[View full size image]

From the Product Associations screen, you have a few options, as follows:

  • Map to Application Class— You can define application classes that will help identify which processes belong to that application. Only use this method if you have already created the application class that applies to this application.

  • Ignore— You can configure the CSA MC to ignore and stop reporting the listed application.

  • View Ignored— You can show the list of previously ignored applications to reinstate an application to the Product Association list.

  • Select the Application Name— By clicking the application name, you bring up the configuration screen, where you can select the appropriate application class or configure a new one.

After an application has been mapped appropriately, it displays as configured with a check in the Configured column as opposed to an exclamation point, which denotes an unconfigured application.

To configure an application mapping, follow these steps:

Step 1.
Choose the application you want to configure by clicking its name. This example configures Jgsoft s EditPad 5 Demo.

Step 2.
Enter a description.

Step 3.
Choose the application class that defines this product or, for this example, create a new application class by clicking New. You can also view the application class configuration by double-clicking the application class name.

Step 4.
In the Application Class window that opens, name the new application class, provide a description, and enter the application class executables as literals or choose the file set variable that defines the application executables from the list. This example defines the literal executables, as shown in Figure 10-8.

Figure 10-8. Configuring the Application Class for Mapping

[View full size image]

Note

You can find a more detailed explanation of application class and variable configuration in Chapter 5, "Understanding Application Classes and Variables."

Step 5.
After returning to the Product Association configuration screen, verify that the new application class is selected.

Step 6.
Click Save. Figure 10-9 shows the completed configuration.

Figure 10-9. Completed Product Association Configuration

[View full size image]

You have now configured a simple product mapping within the CSA MC. To verify successful configuration, return to the Product Associations screen and make sure the check box has appeared next to the application you were configuring, as in Figure 10-10. Now that you know how to configure product associations, you can move on to the unknown applications.

Figure 10-10. Successfully Configured Application Mapping

[View full size image]

Unknown Applications

The products that had displayed within the Product Associations list were applications that were listed in the Add/Remove Programs list in the control panel of the remote systems. The other applications that you need to understand when protecting the systems are unknown applications. Unknown applications are applications that were witnessed running on the remote systems that are not associated with any product on the CSA MC. To view the list of unknown applications, choose Application Deployment Investigation > Unknown Applications to display a screen similar to Figure 10-11.

Figure 10-11. Unknown Application List

[View full size image]

From this screen, you have a few options:

  • Map to Product— You can map this process to a known product as listed in the Product Associations list.

  • Ignore— You can remove this process from the list.

  • View Ignored— You can view the previously ignored items and reinstate those that you deem necessary.

To map a product, check the check box in front of the application you want to map and click Map to Product. The example maps winvnc4.exe. After you click the Map to Product button, a small pop-up screen displays with configuration options, as shown in Figure 10-12. You can create a new application class that includes this file by entering a name for the application class, or you can select an existing application class that includes the unknown application. After you select or create the appropriate application class, you need to select the correct product from the drop-down selection. These are products that are currently unconfigured in the Product Associations screen. Click the OK button to continue after you have correctly selected the options. At this point, the process is removed from the list of unknown applications and the application displays as Configured on the Product Associations screen.

Figure 10-12. Process-to-Product Mapping

[View full size image]

Data Management

Collecting application deployment investigation data can consume a great deal of disk space. To control the amount of information collected, you can configure a data management plan. Figure 10-13 displays the data management configuration screen. From this screen, you have the following options:

  • No Data Management— This option prevents any collected data from being purged.

  • Scheduled Data Management— This option configures a data-retention policy.

    • Delete Application Deployment Investigation Data— Select from the following options:

      EverynumberDays— This option states how often data management should occur.

      Process Data Older ThannumberDays— This is the number of days process information is retained.

      Network Data Older ThannumberDays— This is the number of days network information is retained.

      Antivirus Data Older ThannumberDays— This is the number of days antivirus information is retained.

      Related to Hosts in the Following Groups— You can specify the groups you want to purge related information. Only Windows groups are displayed because only Windows hosts can run application deployment investigation jobs.

      Deletion Time— This indicates the time of day the purge should occur.

    • Archive Before Purging— This check box enables you to archive the information to a directory before purging the data. You fill in the following information:

      Archive Directory— This is the directory the archive data should be placed within.

      Use Archive Data in Reports— Checking this check box allows the CSA MC to use the offline archive records in any reports viewed.

Figure 10-13. Data Management Configuration

[View full size image]


Using Application Deployment Reports

After you have collected application deployment investigation data regarding installed known and unknown applications, you will want to view various reports to aid in the remediation of any product- and policy-related issues. The reports regarding application deployment investigation are located under Analysis > Application Deployment Reports. It is important to note that the reports are located here and not under the Reports menu option. Several reports are available, including the following:

  • Antivirus Installations

  • Installed Products

  • Network Data Flows

  • Network Server Applications

  • Product Usage

  • Unprotected Hosts

  • Unprotected Products

The next sections describe each report in more detail.

Antivirus Installations Report

The Antivirus Installations report displays the currently configured antivirus applications. You can also create, delete, or clone Antivirus Installations reports if desired. When config-uring an Antivirus Installations report, you have the following configuration options, as shown in Figure 10-14:

  • Name and Description— Name and describe the report.

  • Verbose Report— Check this check box to enable greater detail, such as per-host information for reported data rather than simple summary information for the group.

  • Groups and Hosts Matching— Choose the groups and hosts the report should include or exclude. Only hosts that have uploaded data display for selection.

  • Time Frame— Choose the timeframe you want information reported from or check the All Times option.

  • Sort By— Choose Host or Product for the first and second sort criteria.

  • Viewer Type— Choose either ActiveX or HTML Frames as with all of the other CSA MC reports.

Figure 10-14. Antivirus Installations Report Configuration

[View full size image]

Finally, after configuring this, you can save the report and view the report. Information returned by this report includes the antivirus product installed, the version, the AV engine, the signature version, and the timeframe associated with the information.

NOTE

Only McAfee and Norton antivirus information displays in the report.

Installed Products Report

An Installed Product report can include products that are either installed or not installed for a group or host. You can also create, delete, or clone Installed Product reports if desired. When configuring an Installed Products report, you have the following configuration options, as shown in Figure 10-15:

  • Name and Description— Name and describe the report.

  • Verbose Report— Check this check box to enable greater detail, such as per-host information for reported data rather than simple summary information for the group.

  • With or Without Dropdown— Choose With to report on installed products, or choose Without to report on products that are not installed.

  • Products— Choose the product or products you want to report. These are products listed in the Product Associations list.

  • Groups and Hosts Matching— Choose the groups and hosts the report should include or exclude. Only hosts that have uploaded data display for selection.

  • Sort By— Choose Host or Product for the first and second sort criteria.

  • Viewer Type— Select either ActiveX or HTML Frames.

Figure 10-15. Installed Products Report Configuration

[View full size image]

NOTE

Windows hotfixes display in the Add/Remove Software Configuration Panel on Windows systems and will therefore be reported in addition to your typical applications. This setup enables you to create reports that list which systems have hotfixes installed.

Finally, after configuring this, you can save the report and view it. The Installed Products report is valuable in understanding where discovered applications are deployed and whether they are wanted or unwanted. This report also offers a simple way to see where required applications are not yet installed. Figure 10-16 shows a sample report that includes the list of installed applications on agent-protected systems, per host.

Figure 10-16. Sample Installed Products Report

[View full size image]

Network Data Flows Report

A Network Data Flows report can show applications that communicate on the network and specify the ports and peers used during the conversations. You can also create, delete, or clone Network Data Flows reports if desired. When configuring a Network Data Flows report, you have the following configuration options, as shown in Figure 10-17:

  • Name and Description— Name and describe the report.

  • Verbose Report— Check this check box to enable greater detail such as hosts, ports, peer and protocol information for reported data rather than simple summary information.

  • Local Applications Matching— Choose the application or applications used in the report.

  • Local Groups and Hosts Matching— Choose the groups and hosts the report should include or exclude. Only hosts that have uploaded data display for selection.

  • Peer Network Address Sets Matching— Limit the peer IP addresses to only report on matching connections.

  • Peer Groups and Hosts Matching— Choose the peer groups and hosts the report should include or exclude. Only hosts that have uploaded data display for selection.

  • Network Services— Choose the network service to report (for example, DNS, DHCP, Telnet).

  • Number of Distinct Peer Hosts— Choose either Less Than or More Than a number of hosts required for a match to be reported.

  • Time Frame— Choose the timeframe you want information reported from or check the All Times option.

  • Sort By— Choose Host, Application, or Peer Address for the first and second sort criteria.

  • Viewer Type— Choose ActiveX or HTML Frames.

Figure 10-17. Network Data Flows Report Configuration

[View full size image]

Finally, after configuring this, you can save the report and view it. There are a great number of reasons to run a report on this information. For example, you might want to run the Network Data Flows report on a network service to determine proper use within a specific group.

Network Server Applications Report

A Network Server Applications report includes network server applications that terminate connections from remote systems. You can also create, delete, or clone Network Server Applications reports if desired. When configuring a Network Server Applications report, you have the following configuration options, as shown in Figure 10-18:

  • Name and Description— Name and describe the report.

  • Applications— Choose the server application or applications used in the report.

  • Groups and Hosts Matching— Choose the groups and hosts the report should include or exclude. Only hosts that have uploaded data appear for selection.

  • Number of Server Accepts— Enter the number of connections the report will match on. This value will either be less than or more than the number specified by setting the appropriate options.

  • Time Frame— Choose the timeframe you want information reported from or check the All Times option.

  • Sort By— Choose Host, Application, or Port for the first and second sort criteria.

  • Viewer Type— Choose ActiveX or HTML Frames.

Figure 10-18. Network Server Applications Report Configuration

[View full size image]

After configuring this, you can save and view the report. The Network Server Applications report is most commonly used to locate server (listening) applications are installed on systems but are not often used. This helps you locate software that could be exploited or possible back doors within the network.

Product Usage Report

A Product Usage report includes applications that are installed and whether they are used. When configuring a Product Usage report, you have the following configuration options, as shown in Figure 10-19 and Figure 10-20:

  • Name and Description— Name and describe the report.

  • Verbose— Check Verbose if you want to see where the application is used or not used listed by host rather a simple summary report.

  • Used or Unused— Choose the appropriate option from the drop-down box based on the type of report you want produced.

  • Products— Choose the applications for the report from the list provided.

  • Groups and Hosts Matching— Choose the groups and hosts the report should include or exclude. Only hosts that have uploaded data display for selection.

  • Time Frame— Choose the timeframe you want information reported from or check the All Times option.

  • Sort By— Choose Host or Product for the first and second sort criteria.

  • Viewer Type— Choose ActiveX or HTML Frames.

Figure 10-19. Product Usage Report Configuration

[View full size image]

Figure 10-20. Product Usage Report

[View full size image]

After configuring this, you can save the report and view it. Product Usage reports, as displayed in Figure 10-20, prove useful in determining whether the end systems use the reported application. You might wonder whether that application you cannot identify is being used or lying dormant, for example.

Unprotected Hosts Report

An Unprotected Hosts report provides information regarding IP addresses that were used while collecting network flow information but were not assigned to any CSA agents. This report provides a list of internal IP addresses that might be in need of a CSA installation or might indicate an unknown rogue host. When configuring an Unprotected Hosts report, you have the following configuration options, as shown in Figure 10-21:

  • Name and Description— Name and describe the report.

  • Network Address Sets— Limit the view of the report to a subset of network addresses, subnets, or all addresses by specifying that information in a network address set.

  • Network Services— Limit the scope of the report to display only the unprotected hosts using specific network services (ports) as defined by network service sets.

  • Time Frame— Choose the timeframe you want information reported from or check the All Times option.

  • Sort By— Choose Host, Unprotected Address, Operation, or Protocol for the first and second sort criteria.

  • Viewer Type— Choose ActiveX or HTML Frames.

Figure 10-21. Unprotected Hosts Report Configuration

[View full size image]

After configuring this, you can save the report and view it. You might find the Unprotected Hosts report useful when trying to locate remote systems that are connecting to your protected systems. Unrelated hosts here are hosts that have IP addresses that cannot be correlated to systems running CSA software. By limiting the service range within the report, you can focus on the unprotected systems that speak with your agents through Internet Relay Chat (IRC) or Secure Shell (SSH) if desired. Figure 10-22 shows a sample Unprotected Hosts report.

Figure 10-22. Unprotected Hosts Report

[View full size image]

Unprotected Products Report

An Unprotected Products report provides information about applications found during the investigation process that are not protected by the specified policy. When configuring an Unprotected Products report, you have the following configuration options, as shown in Figure 10-23:

  • Name and Description— Name and describe the report.

  • Products— Choose the applications you want to report.

  • Policies— Choose the policy from the list that should be run on the host to protect the specified application.

  • Groups and Hosts Matching— Choose the groups and hosts the report should include or exclude. Only hosts that have uploaded data display for selection.

  • Time Frame— Choose the timeframe you want information reported from or check the All Times option.

  • Sort By— Choose Host and Product for the first and second sort criteria.

  • Viewer Type— Choose ActiveX or HTML Frames.

Figure 10-23. Unprotected Products Report Configuration

[View full size image]

After configuring this, you can save and view the report. The Unprotected Products report enables you to quickly see where a known application may be installed and running but the local agent does not have the appropriate protective policies enforced. For example, you might see that a popular FTP server application is run throughout your environment and know that you have developed security policies to prevent its misuse; however, after running the report, you can determine where the server application is running unprotected.


Summary

The new application deployment investigation capabilities inherent in the CSA 4.5 release are a welcomed addition to the product. Although it is important to protect the endpoints and control known application behavior when desired, it is extremely important to see what is actually installed that might be outside the standard desktop image. These unknown applications can cause a lot of damage.

After you discover the applications through application deployment investigation, it is advantageous to be able to report on how they are used and with whom they communicate from a network perspective through application deployment reports. The next chapter delves into the Application Behavior Analysis feature, which enables you to further understand what the known and unknown applications are doing on your endpoints as they interact with the local system and network peers.


Chapter 11. Application Behavior Analysis

This chapter covers the following topics:

  • Understanding application behavior investigation components

  • Configuring application behavior investigation

  • Using application behavior investigation on the remote agent

  • Analyzing log data

  • Viewing behavior reports

  • Exporting the behavior analysis report data

  • Analyzing UNIX application behavior

  • Creating behavior analysis rule modules

When attempting to write policies to control and secure your application environment, you must have a detailed understanding of those applications and their usage. The information required includes the following:

  • What applications are deployed

  • Where the applications are deployed

  • How the user should interact with the application

  • How the applications should interact with the system

  • How the system should interact with the application

This detailed knowledge helps you to develop a truly secure yet functional application policy. Application Behavior Analysis is a new feature included in Cisco Security Agent (CSA) version 4.5 that greatly assists in providing you the information required about various applications. This knowledge is gained through investigative processes running on agent-protected systems. In addition to the reports provided as a result of the analysis process, the CSA Management Console (MC) can also create a policy, which is restrictive in nature, to speed the deployment of the control mechanisms necessary. In this chapter, you learn about the implementation and usage of the Application Behavior Analysis feature.


Understanding Application Behavior Investigation Components

For application behavior investigation to be successful, a few of the CSA mechanisms must perform various actions. The CSA MC provides the first and last steps in the process, and the remotely deployed agent performs the steps in the middle.

The CSA MC starts the application behavior analysis process when the administrator configures an analysis job on the central console. The job configuration process requires information about which application or process you want to investigate along with other necessary configuration parameters, which you learn about in the next few sections. When the job is completely configured, it can be deployed to the remote agent through the normal agent polling process.

After the remote agent that is the target of the analysis job successfully polls into the CSA MC, it pulls its investigation orders local and begins analyzing the locally running application. The investigation occurs over a centrally defined interval, and the logged information is stored locally until the analysis is complete. Upon completion, the data can be transmitted back to the CSA MC for completion of the analysis process.

Upon receiving the investigative data from the remote agent, the CSA MC compiles the information into readable reports for further human analysis. These reports contain a wealth of information regarding the application and its interaction with the system and network. As an added step, the CSA MC can create a policy available for import into the policy database if you have a license installed for this feature. This policy will be an enforcement mechanism for the "normal" behavior demonstrated during the analysis process on the remote agent system.


Configuring Application Behavior Investigation

The application behavior investigation process begins with configuration tasks on the central CSA MC system. This portion of the process defines the application or process you want to watch. This application may be a known application you are now developing policies to control or an unknown process discovered through application deployment investigation (which you learned about in Chapter 10, "Application Deployment Investigation"), antivirus reporting, or other means. Regardless of how the process was discovered, as a security practitioner, it is imperative that you fully understand in detail the applications that interact with your systems and resources.

When configuring a behavior analysis job, you access the appropriate configuration pages on the CSA MC and enter the necessary parameters.The following steps configure a sample application behavior investigation to demonstrate the configuration tasks:

Step 1.
Open the behavior analysis job listing by choosing Analysis > Application Behavior Investigation > Windows Behavior Analyses. Figure 11-1 shows a sample job listing.

Figure 11-1. Application Behavior Analysis Job Listing

[View full size image]

Note

You can perform application behavior investigation on both Windows and UNIX systems, unlike application deployment investigation, which you can perform only on Windows systems. To configure an analysis job for the appropriate operating system, access the corresponding configuration page on the CSA MC.

Step 2.
Click the New button at the bottom of the listing page to open the behavior analysis configuration page.

Step 3.
Enter the name and description for the analysis, as shown in Figure 11-2. This information displays on the reports regarding the investigation after the analysis is complete. The information also displays in the listing page and aids in differentiating the various jobs and reports after several have been completed.

Figure 11-2. Application Behavior Analysis Configuration

[View full size image]

Step 4.
Observe and verify that the entries in the Target Operating System and Behavior Analysis Status fields for this job are correct. You cannot edit these fields, but the information must be correct to have a successful analysis. The behavior analysis status will change over the life cycle of the behavior analysis job.

Step 5.
Optionally, check the Verbose Logging Mode check box. Verbose logging reports every time a resource is accessed rather than suppressing the repeated events. Verbose logging can prove helpful in determining not only what resources were accessed during the investigative process but also how often they were accessed.

Step 6.
Choose or create an application class that identifies the application or process you want to investigate. As a best practice, only analyze the behavior of a single process at a time to identify specifically related resource access. For this example, create an application class that specifically watches Microsoft Word (msword.exe). The Show All link displays all the application classes defined in the CSA MC, and the New link opens an additional window that enables you to create a new application class.

Step 7.
Choose the host from the drop-down list; by doing so, you identify the host that should run the analysis job.

Step 8.
Disable or enable policy rule enforcement. When the remote agent begins the analysis process, it may continue to enforce local policy that might prevent the application from accessing required resources. If you want to disable policy enforcement mechanisms from preventing any access this application might require, check the Disable Policy Rule Enforcement check box.

Caution

Disabling local policy enforcement can be dangerous when the application or process you are analyzing is of unknown origin. You should disable only the policy enforcement mechanism when you are absolutely sure there will be no negative impact as a result of the lower security level. You might decide to disable policy enforcement only when the host is located in a controlled and closely monitored quarantine segment of the network.

Step 9.
Choose the start and end times for the behavior analysis job. Remember that the job will only begin to collect data on the remote system after the agent receives the job as a result of polling. If the agent receives the job after the analysis end time that was set, the job will not run on the agent.

Step 10.
As an alternative to the time settings for analysis completion, you can set end parameters based on the size of the log file created or the number of times the application is executed.

Note

If you set more than one termination parameter, such as time, log file size, and application invocations, the first parameter to hit its termination limit causes the analysis job to terminate.

Step 11.
Click the Save button to complete the configuration process.

Step 12.
The final step required before the agent will receive the job from the CSA MC is a successful rule generation.

Before you move on to the agent portion of the behavior investigation process, you need to understand a few points regarding the CSA MC configuration parameters. During the initial configuration, the time settings are drop-down boxes with limited options such as Now, 1 hour, and 24 hours. After saving the job, those options change to text fields relating to the previously selected drop-down options translated into real-time parameters, such as 11/26/2004 14:33. You can edit these fields further to have more specific start and end time parameters with either literal exact timing or relative times, such as tomorrow.

Another important concept regarding investigation timing is which parameters you should use to determine the end time. It is not always a best practice to use the time fields as the determining factor for when a job should complete. If the system is not online or may not poll during the interval specified, the job may not run. Also, it is expected that the application in question will be run through a full and complete usability test to identify all resources required by the application. If the application being analyzed is both a web browser and FTP client, but the only portion of the application used during the time interval is the FTP client, you will not be able to report back the necessary system interaction required to use and safeguard the web browser.

The time parameter may best be used as the terminating factor when the application is a server-based component guaranteed to be available during the test. The number of invocations and log file (256 MB is both the default and maximum size) options are better used for client-type applications. When using multiple types of terminating factors, remember that the first one to hit the limit terminates the job, so set the options accordingly.

NOTE

You can run only one behavior analysis job on a system at a time. You can run multiple jobs across your computing environment simultaneously, however.

Another way to stop the investigation process is to force its termination prior to hitting one of the predefined termination limits after the job has been deployed. To do this, enter the behavior analysis job by clicking its name on the list. When you are in the job view, you can see a new button on the bottom of the page labeled Stop Logging, as shown in Figure 11-3. Click this button to send a termination notice to the agent requesting the job to end and requesting the logged data that resulted from the investigation process.

Figure 11-3. Early Termination of a Behavior Analysis

[View full size image]


Using Application Behavior Investigation on the Remote Agent

The application behavior investigation process on the remote agent is a nonintrusive mechanism. The agent continues to function normally while all normal agent interaction occurs. The only difference is that while an investigation is running on the selected agent, all interaction regarding the application being monitored is logged for further reporting and investigation at the central management console after the job is concluded.

The sample investigative process for this scenario watched winword.exe. During the time the job was running on the selected agent system, the application was fully tested by an individual and has all the desired functions, including reading and writing files to specific directories.(See Figure 11-4.) Such features as printing, importing, network access, and so on were available.

Figure 11-4. Normal Agent Interaction

[View full size image]

Also, recall that during the configuration of the analysis job, you had to make a decision about whether to have the policies on the endpoint enforced during the analysis, which would possibly prevent the processes from certain system interaction during the investigation. If you choose to leave restrictive policies enabled that may have affected the usability of this application, you might not have received a complete view of the resources required by the application because any resource access that was prevented would not have shown up in the analysis report. This fact does not necessarily dictate that you should always disable policies during investigation, however, because it is common to run investigations on applications that are not yet trusted and could negatively impact the security of your network.

The application behavior investigation process creates several associated files on the local agent system, as shown in Figure 11-5. These files are located in the \CSAgent\log\ directory and are named according to the CSA MC analysis job name with various file extensions.

Figure 11-5. Local Files Created During the Investigation

[View full size image]

Other than the files created on the local agent and a few entries in the \CSAgent\log\csalog.txt file, there is no real indication that an investigation is occurring on the endpoint. A few event log entries included on the CSA MC provide insight into the investigation. These entries are as follows, as shown in Figure 11-6:

  • Logging for analysisnamehas started— This entry in the event log denotes that the agent has received the analysis request and is about to begin collecting data.

  • Logging for analysisnamehas ended— This entry in the event log indicates the agent has completed the investigative process.

  • Log files for analysisnamewere sent to the analysis workstation— This event is entered into the event log when the remote agent has completed the analysis and the files have been transmitted to the CSA MC.

  • Logging ended without collecting data for analysis jobname— This is an indication that the investigation was unsuccessful and typically means the application was not executed during the timeslot available. You may need to verify time synchronization, application class definition, and availability of the remote agent in addition to other factors.

Figure 11-6. Associated Event Log Entries

[View full size image]


Analyzing Log Data

Now that the behavior investigation log files have been sent to the analysis workstation (that is, the CSA MC), you can continue the process of investigating the target application. The continuation of your investigation procedure takes place on the CSA MC. When the job in the list displays a status of Log Data Available for Analysis, you can select the job by clicking its name, as shown in Figure 11-7.

Figure 11-7. Behavior Investigation Job Status Listing

[View full size image]

After you have selected the job and entered the configuration page, notice that a new button has appeared at the bottom of the page: the Start Analysis button. Clicking this button generates the associated report (see Figure 11-8), which is discussed in the next section, and creates the associated policy if you have a license for the Rule Generation module. The Import button appears at the bottom of the page. You learn more about the Import button in the section "Creating Behavior Analysis Rule Modules" later in this chapter.

Figure 11-8. Start Analysis Button Appearance

[View full size image]


Viewing Behavior Reports

After the analysis portion of the task list has been completed, you may now view the associated report on the CSA MC. The report is available by choosing Analysis > Application Behavior Reports > Windows Behavior Reports. The information listed next to the report name is the description of the analysis that was entered during configuration, the name of the host that was analyzed, and the operating system of the host. Figure 11-9 shows a sample report list.

Figure 11-9. Sample Behavior Analysis Report List

[View full size image]

To view the report, click the name of the report. Doing so opens the report in the main browser window. The report has five sections:

  • File Events

  • Registry Events

  • COM Events

  • Network Events

  • Summary Events

To view the various sections of the report, click the title of the section in the left navigation pane.

File Events

The File Events section is divided into three sections:

  • Directory Summary

  • Individual File Summary

  • All Events

To open the corresponding section and view detailed information, click that link in the navigation pane. You might notice that the number of directories accessed by the application is far higher than you expected. Much of this is related to the file-saving process in Microsoft Word, which uses file browsing to locate the appropriate folder.

Directory Summary

The Directory Summary portion of the File Events section provides the following information, as shown in Figure 11-10:

  • Directory name

  • Number of files in the directory

  • The file extension of the file accessed in the directory

  • The operation performed (read or write)

Figure 11-10. Directory Summary Section

[View full size image]

NOTE

If network file shares were used by the application during the analysis, they will be at the top of the directory listing because they begin with the backward slash special characters (\\), as in \\fileserver\share\directory\filename.txt.

Individual File Summary

The Individual File Summary portion of the File Events section provides the following information, as shown in Figure 11-11:

  • Directory name

  • Number of events related to this specific action

  • The filename that was accessed

  • The operation performed (read or write)

Figure 11-11. Individual File Summary Section

[View full size image]

This view is limited to 100 entries per page with the option to view the next or a specific page of data.

NOTE

The filenames listed in this report also list directories, which display in all capital letters to show what READ and WRITE operations occurred to those directories.

All Events

The All Events portion of the File Events section provides the following information, as shown in Figure 11-12:

  • Time at which the action took place

  • Directory of the affected file

  • Filename

  • File extension

  • The operation performed (read or write)

  • Process ID (PID, the process that performed the action on the file)

  • Process name

Figure 11-12. All Events File Section

[View full size image]

This view is limited to 100 entries per page with the option to view the next or a specific page of data.

You can also filter this data by a text string within the Directory, File Name, or Process Name fields. In addition, you can sort the presented data by time, operation, file extension, or directory. The various sort and filter methods provide you with a simple and intuitive way to get to the specific data you need to view quickly and easily. Figure 11-13 shows a sample filtered view of the data collected.

Figure 11-13. Filtered All Events View

[View full size image]

Registry Events

The Registry Events section is divided into two sections:

  • Key Summary

  • All Events

To open the corresponding section and view detailed information, click that link in the navigation pane.

Key Summary

The information provided by the Key Summary portion of the Registry Events section includes the number of events affecting the registry key and the key name that was affected, as shown in Figure 11-14. Editing the Windows registry can seriously impact the usability of a system, so closely monitor this information.

Figure 11-14. Key Summary Section

[View full size image]

All Events

The All Events portion of the Registry Events section provides the following information:

  • Time of the access

  • Key name impacted

  • Value of the accessed key

  • PID (ID of the process that accessed the registry key)

  • Process name

You can filter this data by a text value in the Key Name, Value Name, or Process Name fields, as shown in Figure 11-15. You also can sort by process, key name, or time to easily view the necessary registry access without the need for an exhaustive search.

Figure 11-15. All Events Registry Section

[View full size image]

COM Events

The COM Events section is divided into two sections:

  • Object Summary

  • All Events

To open the corresponding section and view detailed information, click that link in the navigation pane.

Object Summary

The Object Summary portion of the COM Events section provides information about the number of events affecting the COM object and the object name that was affected. Figure 11-16 shows a sample view of the Object Summary section.

Figure 11-16. Object Summary Section

[View full size image]

All Events

The All Events portion of the COM Events section provides the following information:

  • Time of the access

  • COM object name impacted

  • PID (process ID)

  • Process name

You can filter this data by a text value in the Object Name or Process Name fields, as shown in Figure 11-17. You can sort also by process, object name, or time.

Figure 11-17. All Events COM Object Section

[View full size image]

Network Events

The Network Events section is divided into two sections:

  • Destination Port Summary

  • All Events

To open the corresponding section and view detailed information, click that link in the navigation pane.

Destination Port Summary

The Destination Port Summary portion of the Network Events section provides the following information:

  • Number of events related to this type of network access

  • Role (A client connection displays as CONNECT, whereas a server connection or termination of a connection displays as ACCEPT.)

  • Protocol (TCP or UDP)

  • Destination port used

Figure 11-18 shows a sample view of the Destination Port Summary section.

Figure 11-18. Destination Port Summary Section

[View full size image]

All Events

The All Events portion of the Network Events section provides the following information:

  • Time of the access

  • Role (CLIENT=CONNECT/SERVER=ACCEPT)

  • Protocol (TCP or UDP)

  • Source address

  • Source port

  • Destination address

  • Destination port

  • PID (process ID)

  • Process name

You can filter this data by a text value in the Source Address, Destination Address, or Process Name fields. You also can sort by process, protocol, role, destination port, or time. In Figure 11-19, you can see that as part of the test of the Microsoft Word application, the transmitted file to and from a network file share uses the common Windows ports of UDP/137-138.

Figure 11-19. All Events Network Section

[View full size image]

Summary Reports

The Summary Reports section is divided into two sections:

  • Behavior Summary

  • Behavior Summary by Process

To open the corresponding section and view detailed information, click that link in the navigation pane.

Behavior Summary

The information provided by the Behavior Summary portion of the Summary Reports section is an overall summarized view of the various events logged during the investigation and the corresponding number of events associated. As shown in Figure 11-20, the sections summarized are as follows:

  • COM (All Events)

  • File (All Events)

  • File (Read Operations)

  • File (Write Operations)

  • File (Writes of Executables)

  • Network (All Events)

  • Network (Acting as Client)

  • Network (Acting as Server)

  • Registry (All Events)

Figure 11-20. Behavior Summary Section

[View full size image]

Behavior Summary by Process

The Behavior Summary by Process portion of the Summary Reports section provides the following information:

  • PID (process ID)

  • Process name

  • Event type

  • Associated number of events

Figure 11-21 shows a sample view of the Behavior Summary by Process section.

Figure 11-21. Behavior Summary by Process Section

[View full size image]


Exporting the Behavior Analysis Report Data

The behavior investigation provides a great deal of useful information to the security team and offers helpful filtering and sorting capabilities; however, the reports provided by the CSA MC interface might not provide the data in a view you require. If you want to export the report to another application, just open the page of data you want to export and click the Export This Report link located just below the last section in the left navigation pane. Clicking this link bundles the report for retrieval to your system via the onscreen link provided, as displayed in Figure 11-22.

Figure 11-22. Downloading Exported Report Data

[View full size image]

To download the CSV (comma-separated values) report to your local system, right-click the link provided and save the data to an appropriate location. From here, you can easily import the data into a number of applications such as a database or spreadsheet. Figure 11-23 demonstrates what an imported CSV file looks like in Microsoft Excel, and Figure 11-24 shows a sample graph you can create from the data.

Figure 11-23. Imported Data in Excel

[View full size image]

Figure 11-24. Graph Created from the Imported Data

[View full size image]


Analyzing UNIX Application Behavior

Now that you have a better understanding of application behavior investigation on Windows systems, you need to understand the differences you will witness when performing an analysis on a UNIX-based system. When configuring the behavior investigation job, the only difference is that the target operating system defaults to UNIX, as shown in Figure 11-25. The rest of the steps are identical to that of the Windows behavior investigation process.

Figure 11-25. UNIX Behavior Analysis Configuration

[View full size image]

The piece of the complete process that changes the most is the UNIX Behavior Analysis report associated with the job. The UNIX Behavior Analysis report has only three sections:

  • File Events

  • Network Events

  • Summary Reports

The other sections that were available in the Windows report are not available because they are Windows-specific configuration information. Both registry and COM object are concepts only available to Microsoft Windows operating systems. As you can see in Figure 11-26, the report mechanism is the same as for Windows reports, and you still have the same data export option available.

Figure 11-26. UNIX Behavior Analysis Report

[View full size image]


Creating Behavior Analysis Rule Modules

In addition to producing a report as a result of application behavior analysis, the CSA MC server can create a rule module from the reported information. This feature is separately licensed and is not available in the base product. If you have a valid license installed, you will notice a new button at the bottom of the Behavior Analysis Configuration page upon completion of the analysis process: the Import button. (See Figure 11-27.) In addition, you see that all completed analysis jobs in the list display with a status of Policy Ready for Importing, as shown in Figure 11-28.

Figure 11-27. Locating the Import Button

[View full size image]

Figure 11-28. Policy Ready for Importing Status

[View full size image]

NOTE

The rule module creation feature was named Profiler in previous versions the CSA product.

Importing the Behavior Policy

To import the policy, click the Import button on the configuration page. Once selected, the policy components are imported to the local CSA MC system through the process displayed in Figure 11-29. The import does not only contain a set of rules but also a comprehensive collection of rule modules, various sets, query settings, and groups. The resulting imported rule module displays after the import process completes, as do all imported variables; but at this point, they have not yet been applied to any systems within the architecture. In addition, you must go through a generate rules process to commit all the changes imported into the system.

Figure 11-29. Importing the Rule Module and Variables

[View full size image]

NOTE

Notice that the behavior analysis job has a status of Policy Imported after the import has taken place.

Understanding Imported Rule Module Methodology

The rule module that is created as a result of behavior investigation is not automatically deployed to CSA agents. The approach taken with rule modules created by the investigation process follows a different methodology than the other CSA enforcement processes. A typical CSA policy allows all interaction to occur and only prevents what the policy specifically states. In other words, typical CSA policy "allows all" while "preventing specific" actions.

The methodology used by the rule creation process uses the exact opposite process by allowing only the interaction observed by the investigation processes and preventing all other interaction. Because of the extremely strict policies created by this process, the policies are not applied and need to be thoroughly reviewed by qualified personnel.

Reviewing and Tuning the Imported Rule Module and Components

The easiest way to review items that were imported is to perform a search on all items. In the text field for the search, enter the name of the analysis job as the criteria, and then click the Find button. The created rule module and its associated variables will display for review. (See Figure 11-30.)

Figure 11-30. Searching for the Imported Items

[View full size image]

NOTE

The rule module created will be named the same as the analysis job, with the word Analysis prepended and the words Rule Module appended.

You can link directly from the search screen to the rule module and from there directly to the included rules. The rules that belong to the module are a combination of access control rules limiting the interaction the application has with the system and the interaction the system has with the application and its data.

As another precaution in the implementation of this new policy, some of the rules created are disabled by default to prevent unnecessary restrictive lockdown of specific system resources. You must understand that the rules created for this discussion were deemed appropriate only as part of the analysis of the specific application alone in a controlled environment. Other applications on the endpoint may require some access to the same resources, whether it is registry keys, COM objects, files, or network services. To verify the rule module created during the earlier illustration using Microsoft Word, refer to the rules created, as shown in Figure 11-31.

Figure 11-31. Created Rule Module

[View full size image]

NOTE

The rules contained in Figure 11-31, although based on an actual investigation of the Word application, are not to be misconstrued as a correct rule set for this application. An exhaustive application testing procedure was not followed during this investigation process, and the rule module created is only displayed as a sample of what is to be expected.

The rule module displayed is ordered with allow actions preceding deny actions. The allow actions are the actions observed to occur during the investigation that were determined to be appropriate. The deny actions are those actions that should not occur, because they are determined abnormal interactions. You also can see the several rules that are currently disabled.

NOTE

Throughout the various rules, the application that was monitored is identified in the same manner it was identified in the investigation process. It is identified using the same application class that was created early on in the application behavior investigation process. It is therefore imperative that this application class be as accurate as possible.

Figure 11-32 shows the file access control rule 650. This rule allows applications matched by the Word application class to read a list of several files and directories. An interesting point to understand here is that the rule creation process tends to open up access fairly wide considering the restrictiveness of its charter. To better understand this last statement, review the list of files the application is allowed to read. You see many "blanket" statements within the file set and literals listed in this rule. An example is the literal entry for \\*\Shared\*.ini, which is a loose representation of what was actually viewed occurring. Although only specific INI files were accessed, you are allowed read access to all of them in this example.

Figure 11-32. Understanding the Created Rules (650)

[View full size image]

You might want to further restrict this rule based on the information in the Behavior Analysis reports for various resources. Regardless of the approach you decide to take, it is important you understand the types of rules that will be created, the nature of the rules, and the absolute need to verify the rules created before implementation.

You will need to tune many of the rules, if not all of the created rules, to ensure you end up with the policy desired. Not just file access control rules require tuning but also network access control rules and others.

TIP

Always review the rules created to further refine them as necessary. You should also, as with any other new rule module, deploy this module to a pilot group in Test Mode.

As a final note regarding the policies that you create as part of the licensed Rule Module Creation feature, you typically should combine these imported rule modules with other rule modules to round out an endpoint policy. In many cases, you must include application programming interface (API) rules, agent interaction, and agent UI rules as part of a deployed policy, which will not be part of the dynamically created and imported rules.


Summary

The Application Behavior Investigation feature in the CSA 4.5 release is by itself a compelling reason to implement the architecture. Many applications within every network are either unknown or untrusted in origin. The Application Behavior Investigation feature of CSA enables you to better understand the application in great detail and either permit or deny specific interaction observed. It is also common to attempt to control known deployed standard applications. Current applications are not always as easy to control as once thought, and a full investigation of system interaction can provide the results requested. Whereas one portion of the security administrator's job is to allow and prevent actions based on policy, it is also very important to understand and control application use or misuse in an effort to protect valuable proprietary intellectual data. The Application Behavior Investigation feature provides just that mechanism.


Part VI: Creating Policy, Implementing CSA, and Maintaining the CSA MC

Chapter 12 Creating and Tuning Policy

Chapter 13 Developing a CSA Project Implementation Plan

Chapter 14 CSA MC Administration and Maintenance


Day Day Up

Chapter 12. Creating and Tuning Policy

This chapter covers the following topics:

  • Creating policy

  • Tuning policy

Now that you understand the various building blocks within the Cisco Security Agent Management Console (CSA MC) architecture, you can begin to develop your strategy for the application of the product. Before any organization enters a lab test, pilot, or implementation of this or any product, you need a well-defined scope of work and success criteria. You can use the CSA product to granularly control your endpoints, and you might need a great deal of time to develop and adjust those policies. Although granularly controlling your endpoints might be your ultimate goal, you need to develop an implementation plan that provides a phased approach in rolling out the product features such that the most protective mechanisms, such as worm prevention, can be realized sooner than later.

The process of testing and adjusting policies is called tuning. Tuning policies and rules is a requirement at the beginning of the implementation because the various rules you implement will either create events that you no longer want to see in the log, or could attempt to prevent required system interaction. Throughout this chapter, you learn about the mechanisms available when creating and tuning CSA policies.


Creating Policy

Policy means different thing to different people. To security practitioners and auditors, the word policy typically refers to a document that outlines how an organization plans to secure both physical and informational assets. This document is a living document that is ever changing as the business evolves, acquisitions occur, applications are deployed, and systems are installed.

Policy can also refer to the implemented rule sets of a product that is meant to enforce those rules. You will often hear of the rule set implemented by a firewall as the firewall policy. The CSA also implements a policy in the same manner as the firewall. The local CSA agent software monitors system usage and prevents actions requested by the user or system that violate the defined policy. For a review of CSA policy, see Chapter 4, "Understanding CSA Policies, Modules, and Rules."

How Policy Relates to CSA

When speaking of CSA, policy is the centrally defined grouping of rules that identify how systems can be used. This policy is derived from the enterprise security policy document that specifically states how systems are allowed to interact. The security agent policy is a direct mapping of written policy to CSA-defined rules that accomplish the preventive or accepted nature of the written policy statements. The items mapped from the written policy into the CSA enforcement policies relate to approved application lists, approved use of products and systems, and allowed network interaction.

In most environments, written policy cannot be enforced at the endpoint completely, and the enforcement mechanism attempted is simple trust of the user base. It has been proven over and over that whether or not you trust your users to take the correct actions regarding corporate resources, even a single deviation can severely impact the confidentiality, integrity, and availability of your most important data. CSA provides many of the functions necessary to comply with the internally written security policy as well as the externally enforced written policies such as HIPAA.

The First Steps in Policy Creation

To successfully define policy for an organization, you must understand how the company functions daily. You must have detailed knowledge of the information flow among the various entities, partners, and customers. You must also be concerned with locating the company assets from an electronic information perspective. This information must be protected both at rest, when it is stored, and in transit, whether it is being moved or used via remote application.

The three most important concepts relating to security policy creation are as follows:

  • Confidentiality— Confidentiality is the concept of keeping data and information private and controlled so that only those who should have access can have access. This involves securing storage, transit, and use of this information.

  • Integrity— Integrity is the concept of maintaining confidence in information and ensuring that it has not been manipulated in an unauthorized way.

  • Availability— Availability is the concept of making certain that data and data access mechanisms are ready to be used when and where necessary, which requires the access methods and paths to be available.

The CSA and its policies enable you to maintain confidentiality, integrity, and availability. The various rules that are part of the deployed policy can guarantee that applications are used only as designed or allowed, ensure network connectivity and network services are available when necessary to whom and what should require them, and provide a mechanism to prevent unauthorized modification of data. To ensure that the rules created for the CSA deployment are accurate, you must have an approved security policy document on hand at the time of policy creation.

Creating New Policies Versus Using Predefined CSA Policies

The CSA MC includes a number of policies that you can use as a starting point for your own policy development or as the policies installed natively in your architecture. These policies range in their use from base security policies for protecting various operating systems to specifically developed policies that protect and control various types of applications. In most cases, the predefined policies serve as a staring point from which you can fine-tune and further develop them to suit your business needs.

Figure 12-1. Predefined CSA Policies

[View full size image]

Brief Review of Policy Component Hierarchy

The CSA hierarchy is important to understand when attempting to efficiently create or modify policies for deployment. The components are rules, rule modules, policies, groups, and hosts. Rules are targeted enforcement mechanisms. This component controls specific interaction on a system. Rules can control whether a file can be accessed by a process, or possibly whether an application can use a certain TCP port for outbound access to the network.

Rule modules are groupings or rules that collectively satisfy a common security enforcement goal. A rule module may group rules that protect a specific operating system from abnormal behavior, or possibly group rules that control how a specific application is allowed to function. Rule modules may also be composed of rules that will be enforced based only on system and user state profiles.

Policies are collections of rule modules. You might have various rule modules that serve many purposes in implementing the enforcement of your written policy. Gathering these rule modules into policies enables you to group rule modules that serve a common pur-pose to be collectively paired with one another and therefore applied to systems as a whole. Policies are applied to groups. Groups take the various policies applied to them and formulate a combined policy from all of the derivative components.

The hosts in the architecture are placed into groups. The hosts inherit the rules within the various assigned group policies and apply them as required on the endpoint, as shown in Figure 12-2. In addition, a host can participate in multiple groups, including the mandatory groups, and combine rules and settings from those groups as well.

Figure 12-2. Combined Hierarchy of a Host

[View full size image]

Where to Apply Policies

Polices are best deployed in a manner that will be efficient within your architecture. This means reusing the building blocks rather than recreating new components. Another way to gain efficiency is to group necessary components together that will apply cross platform and to use the mandatory CSA groups effectively. A couple of ways to efficiently deploy and create new policies are to use mandatory groups and the cloning feature.

Using Mandatory Groups

As you learned in Chapter 3, "Understanding CSA Groups and Hosts," with mandatory groups you can implement the pieces of your written security policy that are global in nature. It is important to understand that any policy applied to the mandatory group also becomes mandatory to all members of that group. As part of a combined policy for a host, any rules applied through a mandatory group will be at the top of the list of the rule set when the rule priority is calculated. These rules cannot be overridden by any other less or more restrictive rules. They are what they are, and they are absolutely enforced.

You want to write or use specific rules in your deployment. You should maintain these specific rules regardless of another policy. You might want, for example, to guarantee that no system under CSA agent control can ever use the Telnet protocol on port 23, because it is unencrypted. You could write a network access control list rule to prevent any application from creating a client-side connection to that port and apply it to the mandatory groups. This rule ensures that even another policy that specifically allows an application to use this sort of connectivity is not allowed and that your written policy is maintained. You can also use the various mandatory groups to implement global rules specific to worm prevention and other selectable system application programming interface (API) rule features.

Cloning CSA Components

Sometimes it is best to start with a framework instead of attempting to build a rule module from the ground up. Therefore, CSA provides a cloning feature. Cloning is a method to select an object within the hierarchy and re-create an exact copy with a new name. You can then edit the new object without impacting the integrity or application of the existing object. Cloning can prove useful when creating a similar policy to one that has already been built.

To clone a rule module, follow these steps:

Step 1.
Open the rule module listing from the Configuration menu.

Step 2.
Check the check box associated with the rule module you want to clone.

Step 3.
Click the Clone button at the bottom of the page.

Step 4.
When asked "Are you sure you want to clone this item?" click OK. The newly cloned copy displays at the top of the list.

As shown in Figure 12-3, the name of the object is the same as the cloned object except the words Copy of are prepended. The cloned module will also temporarily be designated with <new> immediately trailing the name.

Figure 12-3. A Newly Cloned Rule Module

[View full size image]

Step 5.
Click the name of the rule module now to rename and modify it appropriately.

You can easily clone certain modules or other objects for testing or for a new purpose. Cloning can save a great deal of time, especially if the objects cloned are complex with a great number of included rules and objects.

NOTE

Cloning only clones the object selected and links that new object to the same included objects as followed by the hierarchy. Cloning one object does not create clones of all additional included objects.

Creating a Simple CSA Policy

To illustrate the work flow required and hierarchy used, this section shows how to create a very basic policy. This section does not cover every step necessary in detail, but it does mention all steps required. To create a test policy, follow these steps:

Step 1.
Create a rule module to provide a location for grouping the rules, as shown in Figure 12-4.

Figure 12-4. Step 1: Create and Configure the Rule Module

[View full size image]

a. Choose Configuration > Rule Modules [Windows] to open the rule module list.

b. Click New. Optionally, you can clone a similar module.

c. Provide the necessary configuration parameters for a rule module, such as name, description, and operating system. You could select Test Mode here as well because it is a best practice to test new rules before activating them in a production environment to verify that no critical systems are adversely impacted.

d. Save the rule module and its changed parameters.

Step 2.
Add the necessary rules to this rule module, as shown in Figure 12-5.

Figure 12-5. Step 2: Add and Configure the Rules

[View full size image]

a. Choose Modify Rules from the Rule Module Configuration page. You are presented with an empty rule set. If you had cloned another rule module, you would see several rules here.

b. To add the first rule, choose Add Rule > File Access Control. (You are selecting this rule type only as an example.)

c. Configure the rule parameters as necessary for the rule you are adding.

d. Repeat as necessary to solidify the rule module.

Note

To easily add your next rule to the same rule module, use the navigation bar across the top of the rule configuration page to maneuver back to the Rules section. This navigation option is located just below the main navigation bar and just above the rule configuration window.

Step 3.
View the rule set included in the rule module to verify its accuracy, as shown in Figure 12-6.

Figure 12-6. Step 3: Verify Rule Set Accuracy

[View full size image]

a. You can accomplish this task in several ways, but the easiest way to view the rules and their actions is to return to the Rule Module Configuration page and click the Explain Rules quick link.

b. Verify that the rules configured appear accurate.

Step 4.
Create a new policy and assign the rule module to it or assign this rule module to a current policy, as shown in Figure 12-7.

  • To add the policy to an existing policy, click the Modify Policy Association quick link on the Rule Module Configuration page to assign it to a known policy.

  • To create a new policy, follow these steps:

    1. Choose Configuration > Policies.

    2. Click the New button at the bottom of the page.

    3. Enter the necessary configuration for this policy, such as name, description, and target architecture.

    4. Save the changes.

    5. Click the Modify Rule Module Associations quick link.

    6. Move the appropriate rule modules from the unattached side of the screen to the attached side of the screen by choosing the modules and clicking the Add or Remove button.

Figure 12-7. Step 4: Attach the Rule Module to a Policy

[View full size image]

Step 5.
Attach this new policy to a group or groups as necessary for deployment to the users, as shown in Figure 12-8.

Figure 12-8. Step 5: Attach the Policy to a Group

[View full size image]

a. Return to the Policy Configuration page and click Modify Group Associations from the quick links menu.

b. Choose the appropriate groups and move them to the right side of the screen by clicking the Add button.

Step 6.
As an optional step, you might need to move hosts into this group for the policy to be pushed to that particular host. Otherwise, view the host or group to verify the policy, rule module, and rules are being displayed as attached, as shown in Figure 12-9.

Figure 12-9. Step 6: Verification of Attached Hierarchy

[View full size image]

Step 7.
As the final step in this configuration process, you must click Generate Rules to propagate the changes to all necessary hosts in the architecture. (See Figure 12-10.)

Figure 12-10. Step 7: Propagate Changes Through Generate Rules

[View full size image]

Investigating Predefined Policies

Earlier, you learned that you can use the predefined policies as a starting point in developing your own purpose-driven policy. To better understand what you should expect when building your own policy, you should investigate some of the predefined CSA policies and their composition. This section briefly looks at three native policies to establish your own foundation:

  • Base Operating System Protection—Windows

  • Microsoft Office

  • Instant Messenger

Base Operating System Protection—Windows Policy

The Base Operating System Protection Windows policy provides various basic protective mechanisms for any supported Windows platform. As shown in Figure 12-11, this policy includes 6 combined rule modules (2 specific to Windows XP) with more than 40 total rules.

Figure 12-11. Base Operating System Protection—Windows

[View full size image]

Click Explain Rules on the quick links menu to see a screen containing the verbose description of the rules that are combined. The rule modules include various types of rules ranging from agent service control to application control rules and system API rules. You can also use several rules pertaining to file access control to protect the Windows operating system and the local command shell and registry files. This is a very deep policy with many control mechanisms that will serve as an excellent learning tool for a new security administrator.

Microsoft Office Policy

The Microsoft Office policy is application specific and only serves to protect the system from Microsoft Office issues that might arise and to protect the Microsoft Office components from the system. This particular policy only includes a single rule module to accomplish this task. Ten rules are included in the rule module, and consist of the following types, as shown in Figure 12-12:

  • COM component access control

  • File access control

  • Network access control

  • Registry access control

Figure 12-12. Microsoft Office Policy

[View full size image]

Instant Messenger Policy

The Instant Messenger policy is an application-specific policy geared toward limiting instant messenger applications from being compromised. This policy also only requires a single rule module and just seven rules to accomplish its focused task, as displayed in Figure 12-13. The rules are a combination of network and file access control rules, which use variables where possible. Clicking Explain Rules enables you to view the locations and uses of the variables throughout the configuration. One of the variables used is instant messenger executables. This file set includes msmsgs.exe (Microsoft Messenger), aim.exe (AOL Instant Messenger), and ypager.exe (Yahoo! Instant Messenger). You can easily edit this file set to include other instant messenger applications discovered in your network so that they too benefit from the same protective policy.

Figure 12-13. Instant Messenger Policy

[View full size image]


Tuning Policy

After you have developed or are in the process of developing policy to be deployed within your architecture, you will undoubtedly need to tune various rules to function securely without impacting your production applications and work flow. Any product that controls the endpoint interaction from "bad" behavior will have a tuning process and timeframe associated with it. There are many reasons why you must tune policy rules to your environment, including the following:

  • Custom applications contain inappropriate behaviors— It is not uncommon to discover applications within your environment that might cause buffer overflows throughout their operation. However, inhibiting buffer overflows might prevent such applications from functioning. Although the desired course of action should be to reprogram the software to function in a more appropriate, secure, and stable manner, your implementation timeline or internal programming resources might require you to move forward with a rule set that allows this normally undesirable action for these specific applications. With tuning, you can accomplish this granular exception.

  • Restrictive rules might prevent required interaction— While writing policies for deployment in your environment, you might discover that certain restrictive rules, such as file access control or network access control rules, prevent required applications or systems from functioning or having the availability required.

  • Location of previously unknown applications— It is common to discover applications installed across your systems that were not previously tested or allowed by your applications standards team. Although many of these applications are undesired and should be blocked, you might find some applications that are now required by certain departments and are part of everyday business use. These applications require tuning to function because they were most likely not tested during the lab and pilot portions of the roll out.

  • A new application is installed— As your environment evolves, new applications or upgrades to current applications will occur. These changes might require tuning deployed policy to allow appropriate functionality. This process should most likely occur as a step within your written application testing guidelines document and should never impact a production system.

All of the preceding occurrences will happen within most environments. Tuning is the process by which you can make exceptions to these and other behaviors that you want to prevent. Tuning also provides a mechanism to slightly modify rules so that they do not log the event but continue to prevent or control the interaction as initially desired. The next sections explain the tuning process and tools you can use to assist in the tuning process to efficiently complete this task.

NOTE

Just as you are required to tune your network Intrusion Detection System (IDS) and Intrusion Protection System (IPS) appliances, you must tune your CSA agents to eliminate the reporting or blocking of false positives.

Review of Key Features Impacting the Tuning Process

You need to be familiar with several CSA MC features and concepts when tuning agent systems. Many of these features have been covered already throughout this book, including the following:

  • Verbose versus standard logging— When configuring rules, you almost always have the ability to set the log parameter for that specific rule. The log setting determines whether the matching action triggers an event to be added to the central CSA MC event log database. If the log parameter is set, events are sent to the CSA MC as they occur, but repeated events are grouped and sent only once per hour to eliminate flooding the event log. Verbose logging set at the group level causes all events to be sent to the event log, which can prove useful, particularly when combined with Test Mode, to assist in tuning policy as events occur rather than waiting for repeated actions to be sent to the central console.

  • Event sets— Event sets provide a mechanism to filter the event log or Event Monitor so that only the desired events display to the administrator tuning the policy. Event sets can be very granular, enabling you to view only the specific rule- or host-related events and isolate a specific issue.

  • Test Mode— Test Mode is the mechanism that removes the enforcement nature of rules to allow logging information of what would have been prevented without actually preventing actions. New agent deployments or new rule module deployments are typically performed initially in Test Mode. Test Mode enables you to watch and tune policy without impacting the usability of your customer applications and interaction, which enables you to observe both normal and abnormal behavior in a typical work setting instead of attempting to script interaction that might not be quite as accurate.

  • Reports— The various reports provided by the CSA MC can aid in the collection of data that will be necessary in tuning policy. You can also run reports to provide an offline paper copy of events that are occurring so that the workload required in tuning can be divided among the available resources as necessary.

  • Agent polling and UDP hint messages— Agents must request updates to receive newly tuned policy. This request occurs at regularly scheduled intervals called the polling interval. This parameter determines how often a system checks back in with the CSA MC for new policy or software updates. When tuning policy, you will make changes to rules that need to be redeployed to perform further testing. These rules will not be deployed unless the system manually requests a fast poll or the next polling interval occurs. You might need to shorten the poll interval for systems you are tuning to get desired policy on the endpoint in a timely manner. An additional feature added in CSA 4.5 is the concept of UDP hint messages. This feature can alert a system that a new policy update is ready and that the system should pull the update immediately. This feature greatly improves your ability to tune policy in an efficient manner.

    Note

    The polling interval is an important timeframe to understand because it can impact your management console if inappropriately timed. Too many systems polling at a time can cause CSA MC performance degradation. Also, you cannot generate rules if the number of agents polling per second is greater than 100. You are warned of this limitation when the number of agents polling per second is between 15 and 100.

  • Analysis— Analysis is a new feature in CSA 4.5 that enables you to learn which applications are installed and which processes run on remote agent-protected systems. This feature enables you to interrogate specific processes to determine the nature of their interaction on the remote system. When tuning an application, it might prove beneficial to perform an analysis to see which systems have the application installed as well as what a specific application is attempting to do on the end system (which might be something required or possibly undesired).

Actively Tuning by Example

You can tune policy in an environment using many methods and screens on the CSA MC. To illustrate some of the methods, this section covers a few of the common events that require tuning. Covering tuning for every type of event you might encounter in a deployment environment is impossible, so it is more important to understand the steps and required processes that you can apply to tuning any type of rule. The next sections examine some of the methods available and the processes you can use.

Limiting the Event Log View

Before tuning the policies in your environment, you must understand what you want to tune in order of priority. You might decide to tune a specific system that is running a unique policy, or you might decide to focus on tuning global events that impact many systems.

To limit your view of events so that you can focus on that "needle in the haystack," you should use local temporary filters (Change Filter and Find Similar) available on the event screens and event sets. To filter the view from the event screens using either method, click the Change Filter link and apply the appropriate parameters. In Figure 12-14, you can see a configuration to filter events coming only from a specific host.

Figure 12-14. Filtering Event View to Narrow Your Scope

[View full size image]

Tuning from Event Log Entries

Below most event log entries, a few links enable you to tune the rule that caused the event. The Details link provides some information regarding the event that might assist in your decision to tune the event or accept it as a positive signature-based event. This detailed information enables you to see what policy, module, and rule caused the event, as well as to see granular parameters. The information included on the Detail Information screen that pops up as a result of clicking the link will vary based on the type of rule that triggered the event. The Rule # link displays the rule number that triggered the event and provides a clickable link that takes you directly to that rule. You can directly edit this rule from this view, but doing so could adversely affect the rest of your protected systems. It is important to understand that editing a global rule directly will impact any system running that rule.

CAUTION

Be cautious when editing rules directly. Editing rules directly will impact any other system using an edited rule in its combined rule set. So unless you are 100 percent sure that this action should be globally edited, be very careful.

Instead of editing the rule directly, it might be wiser to clone the rule or rule module and edit the cloned rules rather than the rules that may be applied elsewhere.

To view which groups are using a specific rule, you can use the CSA MC search feature to search on the specific rule ID and then select groups from the reference list, as shown in Figure 12-15. The most common way to tune an event is to use the wizard feature in the event screens.

Figure 12-15. Groups Impacted by a Rule

[View full size image]

Introducing the Event Management Wizard

You can tune many events within the event log by using the Event Management Wizard. The wizard enables you to do the following:

  • Tune the action of a rule that triggered an event

  • Create an exception rule that allows the action to be granularly tied to a specific action or group subset

  • Create an exception rule that prevents further logging of this rule

  • Perform a behavior analysis of the process that triggered the rule to further interrogate the interaction

NOTE

The wizard can only be used by events that were triggered by application control, buffer overflow, COM access control, file access control, network access control, registry access control, rootkit/kernel protection, and system API control rules.

Using the Event Management Wizard

To open the wizard and use the features associated with it, click the Wizard link from the event that you want to tune. You then follow the prompts as follows:

Step 1.
Read the available wizard options and choose as appropriate from the following. Alternatively, you can click Cancel if you do not want to take any of the listed actions, which are shown in Figure 12-16:

  • I know this is safe and I want to create and exception rule that will allow the action that triggered this event.

  • I do not want to see further similar events and I want to create an exception rule that will stop logging similar events.

  • I do not understand this event and I want to perform a behavior analysis that will target the process that triggered this event.

Figure 12-16. The Event Management Wizard

Step 2.
After you have chosen the appropriate option, click Next in the lower-right corner of the screen.

Step 3.
If you choose the option to create an exception rule to allow the action, you proceed in the following order through the wizard:

a. A screen displays that checks the rule for any state conditions that might be applied. If state conditions are tied to this rule, specify the appropriate condition.

b. You are presented with the rule type and explanation, as seen in the Explain Rules view. You can also see information regarding the rule that was triggered. In Figure 12-17, you can see that you are tuning a registry access control rule and are therefore presented with the registry key that was accessed, the process that accessed the key, and the type of access attempted. When you understand the information displayed, click Next.

Figure 12-17. Event Management Wizard Step 3 Detail

c. You are now prompted to decide where you want to apply the exception rule you are creating. Your options are to create a new exception rule module that will be applied to certain groups, or add it to the specific module in which the original rule resides. The groups automatically selected by the wizard are related to the groups that the host that triggered the event belongs to. You can change these manually from this screen to include or exclude specific groups if the automatically selected list is not accurate as to what you are attempting to accomplish. Also, you should create a new exception rule rather than the alternative option, which could impact many more systems that might not require tuning.

d. After choosing how to apply the change, you are shown the application class that will be created, which includes the process that caused the event. You can also choose already created application classes to include in the rule. To facilitate efficiencies associated with other rules that might require a reference to this process, an application class is created for this process instead of using a literal.

e. A summary displays explaining the actions about to be taken in conjunction with the completion of this wizard process. After reviewing the summary, click Next to continue.

f. As the final step in the wizard, the components are created and you are presented with the resulting rule. You might need to modify the rule to obtain a more general application. By default, specific parameters are used that you might find overly restrictive.

Note

The wizard creates restrictive rules that you might want to generalize upon completion. For example, a network access control rule might be created after the wizard completes, but it will be defined with the specific source and destination IP addresses that triggered the event. Although you might want this, you might need to change those addresses to a more open network setting, such as 0.0.0.0-255.255.255.255, if the goal is to allow a protocol to function to all destinations rather than just to the specific destination that triggered the rule.

Step 4.
If you choose the option to create an exception rule that will stop logging the event, you proceed in the following order through the wizard:

a. The state condition information for the rule displays. Click Next to continue.

b. You are then shown the type, number, and explanation. Click Next to continue.

c. You are again presented with the option to add the Do Not Log rule to the rule module that is tied to certain groups or to edit the original module that contains the logging rule. Click Next to continue.

d. A summary displays explaining the actions that will be taken upon completion of the wizard. Click Next to continue.

e. Finally, you are presented with the rule created that will prevent logging for this rule. Click Next to continue.

Note

To guarantee that the Do Not Log rule overrides the action-based rule that still needs to be maintained, the wizard creates the resulting rule with the Takes Precedence Over Similar Action rules set to maintain proper rule ordering.

Step 5.
If you choose the Behavior Analysis option, the rule is checked to see whether any state conditions are applied so that you can focus your exception rule on an appropriate state. Click Next to continue through the wizard.

a. As with any behavior analysis, choose whether to enable or disable policy enforcement mechanisms during the analysis, as shown in Figure 12-18.

Figure 12-18. Wizard-Initiated Behavior Analysis

b. Verify the process name that will be investigated as part of the analysis as well as the application class that will be used or created to identify the application to the analysis mechanisms on the agent system.

c. You are given the option to enable verbose logging of the analysis job. This option is not event log related, but only specific to the information reported in the analysis itself. Specify when the job should end by choosing either After 15 Minutes, After 1 Hour, or After 24 Hours, as shown in Figure 12-19.

Figure 12-19. Tuning Analysis Parameters in the Wizard

Note

Remember that the analysis job will not start on the target system until the job is received as part of the normal polling process. If the system does not poll prior to the scheduled termination of the analysis job, it will not run.

d. You can now view the detailed summary of the analysis job you created. After doing so, click Finish to finalize its configuration.

e. To conclude this specific branch of the wizard process, you can view the configuration of the analysis job and edit it as necessary.

Step 6.
As the ultimate final step in most CSA MC processes, you must generate rules to deploy the configuration changes made in the database to the agent systems.

You can see how the wizard eases the tuning process by assisting in the creation of various rules and analysis jobs. Note that different rules have slightly different wizard options and components created as part of the process with regard to the event and rule types involved.

Choosing Between the Event Log and Event Monitor

Tuning will most likely be done in conjunction with viewing events in the event log or Event Monitor. The only difference between the two viewing options is that the Event Monitor provides an automatic refresh of the view at a set interval that you can customize by using the appropriate drop-down box. There is no right or wrong screen to use. You might have a personal preference as to which you like to use, and you should always use whatever is more comfortable for you to accomplish the tuning task at hand. As a general rule, most people prefer to use the event log to search for the next item to tune without being interrupted by a refreshing screen, and then once located and after tuning has begun, they switch to the Event Monitor to evaluate progress of the tuning. You can see whether any events are rolling into the database in near real time by using the Event Monitor after tuning a rule.

Troubleshooting Tuning

Occasionally, you might have an issue that you are attempting to troubleshoot that is not appearing in the event log. To force events to appear in the event log, even if the specific rule is not set to log, choose Log Deny Actions from the Rule Overrides section of the Group Configuration page. This option ensures that you receive all deny events (any of which could be preventing proper system interaction).

NOTE

Interestingly enough, the Log Deny Actions override only logs deny actions and not terminate process actions.

DMP and RTR Files

DMP and RTR files are memory dump and request trace files, respectively. These files are located in the agent log directory. Cisco Technical Assistance Center (TAC) can interpret both of these files to assist in the troubleshooting of agent interaction and policy issues you might have. You might see events in an event log that say a process has been dumped. The event log identifies the specific location of the DMP file so that you can retrieve it for support staff to investigate.


Summary

Creating and tuning policy for the CSA are processes that you must master and fully understand to ensure a successful installation. Creating a valid policy upfront and testing within controlled test and pilot phases can guarantee success. Upon initiation of the policy, you will most certainly be required to tune the policy and rules to fit your operating systems, applications, and other business needs. This tuning process continues through the life of the product as your deployment evolves to include controlling new applications and processes.

Although the majority of the tuning required is performed during the initial phases of the product installation, this task will also occur over the life of the product in limited fashion. The skills used during the tuning process, such as working intimately with the event viewing screens and building event sets, will also benefit administrators as they investigate attempted security-related occurrences prevented and monitored by the CSA systems. In the next chapter, you follow an installation of the CSA architecture from start to finish by creating and following a case study of a fictitious environment that you will install, tune, and monitor.


Chapter 13. Developing a CSA Project Implementation Plan

This chapter covers the following topics:

  • Planning for success

  • The project plan

  • Outlining the project phases

The Cisco Security Agent (CSA) product contains many components that enable you to granularly control your infrastructure. The application of these control mechanisms along with the deployment and tuning of the product might seem overwhelming to a security administrator who does not completely understand how to best use the product. As an analogy, consider the various workers used to construct a home. Although individual craftsmen must understand their part of the construction, whether it be a plumber s pipes or a roofer s shingles, the foreman and contractor are the individuals who must guarantee the completeness of the end product as well as the ability of the final product to stand the test of time without burdening the owner.

The security administrators tasked with the development, deployment, and continued management of a CSA investment must think of themselves much like the contractor using all the various tools at his disposal to build a safe, secure, and manageable deployment. The majority of this book has focused on the granular components and their associated configuration details. This chapter examines how these tools come together to create a CSA project implementation plan to secure your environment, provide useful reports, and continue to function within manageable limits.


Planning for Success

The major technology-based mistakes organizations continue to make on a daily basis are typically the result of poor planning. It is for that reason that you must ensure you have a detailed step-by-step process outlined before you install a single piece of software. Each step should include the task that is to be performed, the individuals performing the task, and the success criteria that accompany the task.

Providing well-defined success criteria is a step often forgotten. Success criteria are simple checklist items that must be satisfied before you are allowed to move on to the next step. Without defining the success criteria for a specific step, you often move on to another step too early, which can prove troublesome later on in the workflow. Alternatively, you might find that without defining success criteria, you end up running into scope creep, whereby you continually add items at this step in the process and can never seem to move on to the next appropriate step. You must develop the scope document, which includes success criteria, during the initial steps of the project, and all involved parties must agree to it.

NOTE

The Cisco CSA Best Practices document is a good start for basic best practices. You can find it at http://www.cisco.com/en/US/products/sw/secursw/ps5057/products_white_paper0900aecd801163cd.shtml or by searching for "Cisco Security Agent Deployment Best Practices Guide" from the Cisco.com home page.


The Project Plan

Many organizations are searching for solutions to their endpoint-related security issues. After they compile the data regarding the multitude of issues they need to solve, they typically find that they need to purchase several products, ranging from personal firewalls to other system and application control mechanisms. Unfortunately, the use of several products requires separate management systems, support contracts, and licensing, as well as continued maintenance, which can burden the current security staff.

Generally, the CSA and its many security control mechanisms can be applied across the computing architecture to solve the majority of the endpoint-based security issues facing an organization while wrapping the entire solution within a single license, endpoint agent, management system, and support contract. For obvious reasons, many organizations have selected the CSA as the product to solve their organization security issues.


Outlining the Project Phases

Having made the decision to move forward with the CSA product, the security team needs to agree on the high-level phases the project will follow. The organization should already have a standard methodology for this process, including the following:

  • Training

  • Planning

  • Testing

  • Pilot

  • Implementation

  • Continued evolution phases

Each of these major phases has several steps included that will vary from environment to environment. Also, in smaller deployments, you might find that you can combine phases effectively and safely without impacting the success of the project. Throughout this chapter, you see the breakdown of each major phase and its application.

NOTE

You should consider discussing the role a Cisco Partner could play in your deployment, whether partial or complete, and what the partner can bring to the guaranteed success of the implementation based on their expertise and prior installation best practices. Remember, there are always best practices, but your organization might not currently follow them. To find a Cisco Partner, go to http://www.cisco.com/en/US/partners/index.html.

The Training Phase

To begin the project, selected individuals should be trained to fully understand the product, its capabilities, its implementation, and its ongoing maintenance.

NOTE

Cisco training partners offer a Host Intrusion Prevention System (HIPS) class in various locations around the world. To attend one of these classes, consult your preferred Cisco training partner for schedules and availability.

The Planning Phase

After completing the training, the security team should enter the planning phase, which is crucial to the success of the deployment. In the planning phase, you outline all the detailed steps that you will use throughout the project as well as the success criteria for the project and who should perform each task.

Many organizations use software applications to define and track the project as well as the associated timelines, which are typically displayed on Gantt charts. It is important to understand that these steps and success criteria will flesh out as you proceed through the process as the means by which you define success criteria for each task become more evident. Although it is true that the criteria and tasks may change, you must be certain that any changes in the definition of a task occur prior to that task beginning so that you can control the task and limit its effect on surrounding tasks within the workflow. From a very high-level view, you should define the major tasks involved in each phase and the major success criteria for completion of each phase. Until these criteria are reached, you should not proceed to the next step.

The Testing Phase

The testing phase assists in several ways to ensure the organization completes a successful deployment. In the testing phase, you install the CSA MC server and other key representative systems in a mock environment detached from the production network. Within this test environment, you can do the following:

  • Train other employees on the CSA product

  • Test your understanding of the CSA architecture and its components

  • Gain a basic understanding of the impact of the CSA on your critical systems, host, and business workflow

The following step-by-step list outlines tasks within the typical testing phase:

Step 1. | Gather information.
Step 2. | Decide on the test bed size and components.
Step 3. | Install the test environment.
Step 4. | Install the test CSA management architecture.
Step 5. | Create and configure the test CSA hierarchy.
Step 6. | Configure CSA administrative and maintenance settings.
Step 7. | Create the base test policy.
Step 8. | Deploy the test policy.
Step 9. | Tune the policy.
Step 10. | Add advanced policies.
Step 11. | Continue to tune policy.
Step 12. | Place the policy in Enforcement Mode.
Step 13. | Create alerts.
Step 14. | Export, report, and document the test phase.
Step 15. | Train staff and users.
Step 16. | Verify success criteria.

These phases can vary from deployment to deployment based on the size and scope of the deployment, including the type of policies and enforcement controls that are implemented. Another factor that can affect the phases, which you learn more about in subsequent sections, is the level of involvement of the Cisco Partner that may have been selected to assist.

NOTE

The phases outlined in this chapter do not always include step-by-step instructions to complete the task, but rather just sample success criteria. To create detailed steps, review the respective sections of this book as well as other resources, including your training materials, to compile the information for your specific deployment.

Gather Information

As one of the most important tasks within each and every phase, gathering all appropriate and correct information enables you to develop suitable task-success criteria. You need to gather information that is not entirely technical in nature from many parts of your organization. Here is a sample list of information required:

  • Why are you deploying the product?— It is imperative that you determine very early in the project what the ultimate goal is in implementing the product in your environment. You might decide your organization only wants to prevent worm and virus behavior, or you might want to include personal firewall rules, system and user state rules, application control, and so on. Making this determination now does not limit what you can enable later on in the product, but it will help control the project and maintain implementation timelines.

  • What applications are in use in your organization?— Compiling a list of authorized applications will assist in the policy creation process as well as team understanding of the baselines that will be created. Tuning the product is much easier when you know what should be seen running on the systems so that other processes can be flagged as suspect and investigated. If your environment seems to have too many authorized or acceptable applications to fully document, focus on the critical business applications in this step.

  • Is point-to-point file sharing allowed?— Establish whether your users are allowed to share files directly or over the Internet. This information should be outlined in your written security policy.

  • Can everyone access the Internet and e-mail?— Although many mechanisms can be deployed on the egress of your network to control Internet access and usage, placing strict policy on the endpoints themselves can prevent Internet use from protected systems even when they are not connected to your corporate network.

  • Who is allowed to install applications?— In many environments, users are not permitted to install applications. Unfortunately, the attempted enforcement mechanism is usually in the form of a signed acceptable use policy. Using the CSA control mechanisms to prevent unauthorized installations can prevent unintended applications from compromising your entire computing infrastructure.

  • Are any other software agents deployed?— Within any corporate environment, there are often agents deployed that can interrogate the system hardware, perform installation of applications, provide VPN access, act as a personal firewall, or provide virus protection. Many of these locally installed agents could be seen as suspect by the CSA product because of their deep interrogation of the system. You should be aware of any similar product prior to installation so that you can make appropriate decisions regarding installation of the CSA network shim and creation of the necessary exception policies.

  • Are any multimedia applications in use?— Multimedia applications that access the network often use complex protocols and streams to exchange information between entities. Note these dynamic connections because you might need to create exceptions.

  • How do you patch systems and install updates or software?— Centralized software updates and installation over the network often trigger various CSA protective mechanisms because downloading and installing remote software is a trait of worm and Trojan horse behavior. You need to understand the installation techniques and connections used during software installation to create policies that allow the installations to continue to occur within defined security parameters.

  • What networking control mechanisms are in place?— The CSA MC and agents must communicate over the network to provide policy updates and log events as they occur. The successful communication might require the networking and firewall teams to enable the translations, routing, and ports necessary.

  • How large should the test bed be?— You must determine which systems, applications, and user environments need to be re-created in the test bed.

Many important pieces of information must be gathered to set appropriate tasks. Many of the answers to the preceding questions should be information that is well defined in your written security policy, and so you can glean much information from there.

Determine Test Bed Size and Components

You must determine which systems, applications, and user environments need to be re-created in the test bed. Systems in the test bed should be of the same hardware type and operating system/patch level that is true to production. This task is not limited to the application servers and user workstations that should be replicated, but also applies to networking components. You should acquire basic switching, routing, and firewall systems representative of your production environment to ensure communication rules and flows are adequately tested. This environment will not only be used for initial tests, but can also be used for training new administrators and the untrained staff members. Another use for this environment is the ongoing testing of new policy and rule modules as they are developed as well as testing new applications against current policy enforcement rules.

NOTE

Every IT organization should already have solid change control and quality assurance mechanisms in place. The test bed you create should be used in the testing phases associated with any future change that might be impacted by policy rules and enforcement. The CSA product, because of its nature, needs to be incorporated into these practices.

Install the Test CSA Management Architecture

After installing your test environment, you can begin installing the CSA MC system. This step and several others in this section could be completed in parallel because they do not initially impact each other. The later steps need to be completed in a specific order to ensure success. The first item to complete for this task is the installation of the CiscoWorks VPN/Security Management System (VMS) server application on hardware that meets, or preferably exceeds, the minimum requirements. You need to verify the installation is successful. You also need to understand the configuration parameters associated with this application. At this point, the only component within the application suite you need to install is CiscoWorks Common Services. After successfully installing the VMS product, you can install the CSA MC.

Installing the CSA MC requires the team to decide on the type of installation. In version 4.5, you have the option to install all components on a single server or you can break out portions of the installation to other servers. The components required are as follows:

  • The CSA MC configuration front end

  • The CSA MC database

  • The CSA MC logging server

You should choose the appropriate installation type for your desired level of high availability as well as the number of agents you must service. In addition, if you are implementing more than 500 agents, you need to purchase and install Microsoft SQL server as the database because the included Microsoft Database Engine (MSDE) database cannot grow beyond 2 GB. After installing the CSA MC components, you must ensure the servers are reachable via Domain Name Server (DNS) resolution so that the necessary communication and Secure Sockets Layer (SSL) certificates can function.

Create and Configure the Test CSA Hierarchy

After installing the necessary products, you can begin to configure the CSA MC building blocks and customize the CSA MC to suit your needs. During this task, you might decide to archive unnecessary built-in components that clutter your view to simplify your further configuration. Some administrators export every component before configuring a single CSA component. Doing so allows them to revert or re-import the objects if they are ever changed or manipulated accidentally or in a way that would warrant bringing something back to the default. After exporting the components, you can remove/delete the ones you will not be using within your deployment. When the base components are viewable to your liking, you can continue by creating variables that might prove useful to your organization, such as groups, file sets, network sets, and user and system state sets. You do not need to configure all or any of these components at this point because you can create them as your policy evolves.

NOTE

It is important that you understand what component you are removing and the impact it might have. Upon installation of the CSA MC, the local VMS server has a security agent installed to protect the system. Removing any of the attached policy and subcomponents could cause problems to arise.

When configuring the hierarchy of the CSA MC architecture, you must determine the types of systems you will have within your deployment and the granularity of the policy control mechanisms as it relates to the hierarchy. Many novice administrators initially begin creating several groups that correspond to several occupational- or security-related functions. It is, however, typically a better strategy to start with very few groups and only add groups where absolutely necessary.

When creating groups for users (not servers at this point), the initial question to ask is "What operating systems are deployed that will be protected by the CSA agents?" These operating system determinations will be grouped into Windows, Solaris, and Linux. The next question to ask is "What security practices are common to all systems in my architecture and what security practices are common per operating system?" Both of these questions help you decide how to best use the built-in mandatory groups.

The CSA mandatory groups should include all security controls that are required across the architecture and per operating system group. Examples of these rules include "Individuals may only use an approved web browser when using the Internet within acceptable use guidelines" or "No system may run TFTP, web, or FTP servers without prior approval." Rules such as this are considered global and should not pertain to a specific subset of users, but rather to all users. The mandatory groups could also include system application programming interface (API) protective rules that limit worm and Trojan behavior, root values for system polling, and so on.

After aligning the mandatory groups with security practices, you can create the next level of group hierarchy. This level should include very few groups and will relate to the type of user interaction necessary on the endpoints. The policy applied at this level will include agent control rules and will determine how much interaction, if any, the user can have with the agent. Interaction includes viewing the agent, configuring local firewall policy, and receiving query messages. Many deployments simplify this level of hierarchy into just two groups: a group that can install software and one that cannot. You must be able to answer query messages to install software; therefore, that group would have access to the GUI. The other group might not have the ability to view the GUI, therefore, are unable to respond to query messages.

After determining the installation groups, you can decide whether any other policies will apply only to certain groups of users. You might decide that you do need specific additional groups. Or you might determine that you can deploy the same policies to a smaller number of groups and that application-specific rules deployed to agents that do not have those applications installed will not have any adverse impact. If so, you can overlay the policies on the users utilizing a smaller number of groups. An example of this is to implement a web server control policy on every system even though some systems might not have one installed. This implementation protects the systems that do have web servers, while not weakening security of the systems that are not running them because of the granular nature of the rules contained in the policy. Such an implementation also ensures that if a web server is installed at a later date, no compromise in security level will occur. Your rule set size per agent will increase slightly due to this additional rule overhead, but the number of these rules will most likely be minimal in relation to the other necessary controls.

NOTE

Creating too many groups can prove problematic as your deployment grows. Every time you need to generate rules, the number of groups and complexity of your hierarchy will determine the amount of time necessary to re-create the appropriate rule sets for the agents.

After determining the other necessary groups for policy implementation, you should decide how to use additional functional groups. It is a best practice to include other groups to temporarily or permanently control other aspects of the CSA system. Examples of functional groups are listed here:

  • Test Mode group— Creating a group with no policy attached but with an adjusted polling interval and Test Mode checked can prove advantageous. Sometimes, you need to place a host policy completely into Test Mode, which you cannot do at the policy level. You most likely will not want to place all hosts in that group into Test Mode to perform a system test, so creating a Test Mode group enables you to place that user into Test Mode by adding the host to the group in addition to the original group(s). When a host is in multiple groups, any group that contains the Test Mode selection will place that agent into Test Mode.

  • Application Deployment Investigation group— You can use this group as an additional group much like the Test Mode group to use the Application Deployment Investigation feature temporarily on certain hosts without placing an entire large group into this mode.

  • Short Polling group— You can create groups that have a short (or alternate) polling cycle to use as an additive group when troubleshooting systems.

  • Software Update group— When you are implementing CSA software updates, the systems that are assigned the update process are determined by group. To test or deploy in smaller-size batches, you can move systems in and out of this group to receive the updates in a controlled manner.

  • Geographic groups— You can create an additive group determined by geography, building, floor, subnet, and so on to provide a mechanism used when reporting and correlating data or applying alert mechanisms. You might have systems grouped by functional use but want to track a security event by location, which might help locate the source. Running a report to or filtering the events by floor might assist in troubleshooting an isolated breach.

    Your organization might have several buildings with many types of users spread throughout these buildings. Although certain groups can be developed for policy implementation and are aligned more specifically with the users role, creating a group that bundles all users by building or location regardless of role will allow alerts from these systems to be forwarded to the appropriate staff personnel responsible for the building s technical needs.

  • Groups specific to alerts and filters— You might decide to create functional groups to allow day-two support of the product to mirror your current support and alerting mechanisms. These groups will only bundle certain systems together for alerting the appropriate technical support staff and for similar group reports.

In addition to users, you must create groups for the CSA-protected servers. These groups are typically based on applications running on the server. Desktop systems can be bundled more generically because these systems use a wide array of applications, whereas servers are much more specific regarding how they should function. Servers are typically used in very specific ways, and the resulting policies for servers are therefore typically much more restrictive, which forces you to use a new group per application.

Application servers typically serve a very granular purpose and function predictably every day. Therefore, you can use more controlling policies and selective group assignments than you would with your workstations, which tend to be mush less predictable in function day after day. After creating your hierarchy to the best of your ability, you can continue on to the next task of creating the administrative and maintenance settings for the CSA MC.

Configure CSA MC Administrative and Maintenance Settings

Before progressing too far into the deployment, you should set up the maintenance and administrative parameters on the server. This task includes creating the administrative users and rights required to view and manipulate the database as well as configuring the CSA MC backup policy from the Maintenance option on the menu bar. It is important that you have a method to restore the database in case an outage occurs. Also, be sure to test the multiserver installation for high availability with a hot and cold CSA MC server at this point to verify interaction.

Create the Base Test Policy

Now that you have created some basic hierarchy to determine how you will apply your policy and have configured the CSA MC server maintenance parameters, you can begin to develop policies specific to your environment. You might decide to reuse some of the built-in policies and rule modules, edit the base policies to fit your environment, or create new policies better suited to your architecture and business model. Regardless of the option selected, you need to have your written security policy on hand because the policies you create on the CSA MC will be the direct implementation of that document. If you choose to use or modify any of the predefined policies, it is a best practice to clone the component and edit the newly created object. If the original object clutters your view at this point, you could export and remove it from the system.

The initial policy you create should include agent control rules and any of the global policies included in the mandatory groups. You will most likely also configure the worm and Trojan horse protection rules and any system-wide firewall policies that need to be in place. Do not attempt to implement too many rules at any one time as you begin, because every rule you create might require some basic tuning. You should also configure any additional sets; they are required to accomplish your task of mapping to written policy. Additional sets could include items such as user and system state sets.

NOTE

When implementing user state sets, it is considered a best practice to use groups rather than users in the definitions. Changing a user assigned to the policy requires rule generation each time, but moving a user in and out of a Windows group does not require a state definition change on the CSA MS and therefore does not require generating rules or pushing additional changed policies.

Deploy the Test Policy

After creating a set of rules and developing some basic policies you can implement what you have created on your test systems. You should always do this in Test Mode with verbose logging so that you can work out the conflicts early in your process rather than later in production. At this point, you must determine whether to deploy the network shim and how you will deploy the agents into your environment.

You do not need the network shim to implement network access control rules. The network shim can provide protection for your system against port scans and various malicious packets. Although this might sound like protection every system should have, you need to understand the implications of installing a shim on a system.

The shim can conflict with other software that also uses shims, such as VPN clients, personal firewalls, and other system agents. If you decide to use an unattended or scripted installation method, you must decide when building the agent kit whether to add this ability, because the user will not be prompted. If you attempt to install the shim in your agent kit, and a conflict arises at install time, the install will fail or other issues could occur, including system lockup. For this reason, always test the shim against your known application suite. The applications that tend to conflict most often with the network shim are workstation related, and for that reason you might decide to use the shim only on servers, because they are most likely the target of port scan, malicious packet, and denial-of-service (DoS) attacks. The workstations are better protected and port scans better detected by using a defense-in-depth approach to security design and implementing network Intrusion Detection System (IDS) sensors in your organization.

NOTE

An argument is often made for using the shim on all Internet-facing (or hostile-net-facing) systems to protect against the shim-prevented attacks and report detected port scans. One point to consider in this argument is that if your mobile user is in fact mobile when port scanned, you will most likely not receive the message that it has occurred until that user reconnects to the network anyway. In addition, even if the mobile system is scanned while in a remote portion of the world and you do receive the message, what are you going to do about it? In most cases, the answer is nothing, because of the location and inability to provide remote network security controls on the untrusted network.

Deploying the agent also requires you to consider the methods available to your organization beyond just agent kit configuration. You need to use your current software distribution system, login scripts, or other delivery methods to get the agent installed. You should also consider rebooting the systems at installation completion and the impact that could have on the users and the system security.

Tune the Test Policy and Add Advanced Policies

After installing the base policy you created on select test systems, you can begin to receive messages from the systems regarding possible conflicts the rules are causing. You should test the system rigorously by running applications through their normal interactive sessions. You might also decide to abnormally use systems to test the policys preventive measures, including virus and worm protection.

NOTE

Before testing your systems against worms and viruses, be sure that your systems and test network cannot impact the production environment. You should physically disconnect all production-connected cables at this time.

When tuning the policy, you will want to use Test Mode, the event log, diagnostic information, and log files on the agent systems. In addition, you will become familiar with the Event Management Wizard when tuning and the Application Behavior Analysis tool provided with the CSA product. This task is an important portion of the CSA implementation process, and you should thoroughly understand policy evolution and ensure it is a controlled event.

When you believe the current policy is tuned within acceptable parameters, which include system query messages and events triggered, step back to policy creation and create the next portion of your policy, whether it is specific to a group, application, or network control. After creating additional advanced policies and rules, redeploy and then tune again. This process should continue to loop until you have met your predetermined success criteria. In other words, rinse and repeat until clean.

Place the Policy in Enforcement Mode

Upon successfully completing the policy creation and tuning cycle, you should then remove the hosts from the Test Mode group, which will place the agents into Enforcement Mode using the developed policy. You must retest the systems using interactive methods to guarantee the policy was tuned appropriately. You might have had rules in your policy that were set to not log events that were not displayed during Test Mode. In Enforcement Mode, their implications will show up, and you can search for the issues in the event log and local agent log files.

Create Alerts

Now that you have tuned your policy within acceptable usage limits, you will want to set up alerting mechanisms to notify the correct people when specific events occur. This process requires your decisions as to how to configure various event sets that will trigger the many alert possibilities. Throughout the tuning phase and upon completion, you will gain a great understanding of the alerts you expect to see and which ones should trigger notification.

Export, Report, and Document

You can now begin to export the developed objects and policies for backup. You will want to securely store these objects to ensure you have an offline copy available for disaster recovery. You might also choose to run reports regarding the policies and groups used to provide additional hardcopy documentation that might be necessary as a reference later in the product s installed life cycle. You should also alter any procedural documentation that might be impacted by the security agent. Change control mechanisms should be altered to include any agent-affected mechanisms as well as to ensure that future changes in the computing environment consider the agent impact.

Train Staff and Users

You should now be able to train the monitoring staff regarding the use of the NOC/SOC (network operations center/security operations center) screens, such as the Event Summary. The monitoring staff members must understand the various alerts and diagnostic screens available to them prior to the pilot phase, during which they will be required to interact more closely with the product. Any other staff who will support the pilot phase of the project should also be included in necessary training to ensure success of the project, including IT management, workstation and server support, and the help desk.

You should also begin to train the user base at this point. Most specifically, train the users who will participate in the pilot phase. The users should feel comfortable with any interaction required and understand the messages they might view. In addition, users should understand the features of the product and the contact information of their support team in case any issues or questions arise.

Verify Success Criteria

Upon completion of all tasks in the test phase, verify that you have successfully completed all objectives and are prepared to begin the next phase of the project. Verification should be done internally by the team and possibly by a third-party group (this could be an internal corporate resource) that can audit the results before proceeding to the next phase.

The Pilot Phase

The pilot phase includes many of the same tasks completed in the test phase of the project, with a few major differences in the circumstances and environment. The pilot phase of the project is functioning in the production network with real data, systems, and business flow occurring. Any negative impact can cause production business to stop. You must keep in mind that even pilot implementations should be regarded and treated as production because they can affect business.

Another major difference in the pilot phase is that the systems are being used by real users, not by knowledgeable IT staff members. Systems and applications are not always used as designed, and you will most likely find users interacting in ways different from what you witnessed in the test phase. You are also sure to find new and previously untested applications residing on the pilot system, whether approved or not by the IT staff. These applications include necessary business applications as well as Trojan horses, worms, and viruses. You can, however, use your new familiarity with the product and lessons learned in the test phase to quickly remedy and tune the systems appropriately.

Any negative results in the pilot phase could potentially sabotage the project, and so tuning should be meticulously managed. User perception regarding the success of the pilot is what will allow the pilot to continue to the next phases. The following is a step-by-step list of tasks within the typical pilot phase and a brief description of any changes that occur in this phase (in contrast to what occurred within the same task as seen in the test phase):

Step 1. | Gather information— You will have a different list of information from what originally was gathered. This list should have been altered throughout the test phase as erroneous information was detected and additional necessary information was located.
Step 2. | Finalize the pilot size and included systems— Include a wide sample of disparate systems to ensure applications and user saturation across the pilot. Do not just use IT employee systems. You must use real systems used by real employees to ensure you run into all of the issues you will witness in the complete deployment.
Step 3. | Implement network changes— If during the test phase it was determined that you needed to make any changes to the network, including firewall rules, access control lists, routing, or DNS entries, you should make those changes at this time within your change control window.
Step 4. | Install the CSA management architecture— You will want to install the CSA MC on the permanent production hardware that will be used for the rest of the project through completion.
Step 5. | Create and configure the CSA hierarchy— You should import all the documented policies, rule modules, rules, and other components to the production system. You might need to slightly edit some of the variables to better align with the production computing environment because it differs from the test environment. You should also install the valid permanent license you have purchased for the pilot users.
Step 6. | Configure CSA administrative and maintenance settings— Just as before, configure the necessary maintenance settings to ensure the system is adequately protected from failure and that your team is able restore the system.
Step 7. | Deploy the policy— Deploy the pilot policy in Test Mode. You will also be tuning your installation process in this task.
Step 8. | Tune the policy— Using the various policy-tuning methods, continue to fine tune the policy implemented. Use the Application Behavior Investigation and Application Deployment Investigation features at this point to better understand what is really installed in your environment. As you further develop policy, you will continue to tune until satisfied with the outcome.
Step 9. | Implement alerts— Prior to placing the agents in Enforcement Mode, configure alerts to ensure you can provide timely remediation to any events that might warrant remediation.
Step 10. | Place the policy in Enforcement Mode— Begin to remove systems from Test Mode to enforce policy. This should be performed in a very controlled manner initially to ensure success. Once again, remember that any negative results could impact the perceived success of the implementation as well as corporate acceptance of the product. Even something as simple as a user receiving too many pop-up windows, as defined by the user, regardless of the technical success of the project, could make the implementation appear as a failure.
Step 11. | Export, report, and document— Completely document the outcome of the pilot and modify any documentation that will impact the production-wide rollout. You will also export the finalized policies as a backup.
Step 12. | Train additional staff and users— You should now continue to train the remaining staff and employees who will participate in the completion of the project. This training should include any alterations that might be necessary through the evolution of the project and lessons learned.
Step 13. | Verify pilot success criteria— Verify all success criteria have been met.
Step 14. | Plan for the implementation phase— Using the previously documented planning steps, your team should prepare for the additional rollout of the product, which might include developing additional policies in the test environment.

The Implementation Phase

The implementation phase is similar to the steps followed for the pilot phase. You use the same CSA MC server and the policies fine tuned during the pilot phase. The implementation phase is just an expansion of the pilot to include all remaining systems. Following are the remaining tasks necessary to complete the project:

Step 1. | Gather information— Gather any information about systems, applications, or networks not included in the pilot.
Step 2. | Create and configure additional CSA hierarchy— If any additional groups are needed, create them at this time.
Step 3. | Deploy the policy— Deploy the final project policy in Test Mode. You also fine tune your installation process in this task.
Step 4. | Tune the policy— Just as the previous similar tuning tasks, tune appropriately using all tuning aids available.
Step 5. | Implement alerts— Continue to fine tune alerts.
Step 6. | Place the policy in Enforcement Mode— Enforce the policy in a controlled manner and monitor closely.
Step 7. | Export, report, and document— Completely document the outcome of the implementation and modify any documentation that will impact further implementations. You also export the finalized policies as a backup.
Step 8. | Verify project success— Verify all success criteria have been met.

Continued Evolution of the CSA Deployment

After the production environment is saturated with CSAs, you can begin to decide how to add additional controls to the product deployment through additional policies. You should implement these controls using the very same processes, phases, and tasks discussed throughout this chapter. You should also always implement the changes within change control guidelines, which should now include procedures and steps for the CSA product.


Summary

A successful project almost always relies heavily on the initial planning phases. It also relies on the direction of the project manager to ensure success criteria are adequately defined and met while remaining true to the implementation plan. It is very easy to be drawn in by other features and controls that are not part of the initial rollout; this is called scope creep. When deploying a robustly full-featured product such as the CSA, you must remain true to the original plan and place any additional desired functionality requests that may arise throughout the project on a list of future enhancements to the deployment. If you continue to implement a methodical deployment by properly trained individuals and partners, you can ensure a successful implementation and a highly secured computing environment.


Chapter 14. CSA MC Administration and Maintenance

This chapter covers the following topics:

  • CSA licensing

  • CSA MC registration control

  • CSA MC component sharing

  • CSA MC role-based access control

  • Other CSA MC administrative features

  • CSA MC backup and restore procedures

The Cisco Security Agent (CSA) architecture is not unlike any other enterprise application in that you need a basic understanding of how to administer it and perform maintenance. The CSA Management Console (MC) uses a SQL database that you can back up and restore. It is imperative that the CSA MC server remains healthy and well tuned.

The CSA MC application contains several features that you can use to ease administration of a CSA deployment. There are also features related to controlling CSA agent registration, licensing, component sharing via import/export, and secure role-based access control. Finally, there are a group of features aimed at easing day-to-day administration, such as global and local help files, search tools, and remembered administrative preference settings. This chapter provides most of the necessary maintenance and administrative information required to have a successful CSA deployment.


CSA Licensing

The CSA MC product is licensed such that only an authorized number of server and workstation agents can register and be managed by the CSA MC server. These licenses are purchased in blocks of varying size and are added incrementally to the CSA MC to enable support for the additional agents. As agents are installed with the agent kit executable installer, the first task of that remote agent is to register with the CSA MC. When the agent attempts registration, the CSA MC checks to determine whether a license is available for that agent and, if so, allows registration and decrements the available licenses by one.

To view the licensing information on the CSA MC server, choose Maintenance > License Information. The License Information screen, shown in Figure 14-1, displays the license status for your currently running MC server. You can expand each section of the license to view specific license data on desktop agents, server agents, the MC server itself, and analysis engines. By expanding any of these sections, you can display the Product Authorization Key (PAK) code, license file ID, expiration date (demo license), and the number of agents licensed.

Figure 14-1. CSA MC Licensing Screen

[View full size image]

The totals display below the licenses in a section titled License Usage Counts. This section enables you to view not only the number of possible agents that can register but also the number of agents that have registered.

The bottom section on the License Information page is Update License Information. In this section, you can add more licenses to the CSA MC deployment as it grows beyond the current capacity. To add a new license, just click Browse and locate the license file provided by Cisco. When the filename and path have populated the text box, click the Upload button. This license will be added and additional agents will be allowed to register.

NOTE

The CSA MC server also requires a license to function, called the VMS server license (CiscoWorks VPN/Security Management Server). This license is not the same as the license required to register CSA agents and will be installed during the CiscoWorks VMS installation process.


CSA MC Registration Control

The CSA MC can control agent registration beyond just license availability. This function is called registration control. To configure this function, choose Systems > Registration Control. The method that registration control uses to limit licensing is based on the source IP address information from the client. When a client attempts to register, its communication with the CSA MC is over TCP/IP, which allows the CSA MC server to view the IP address of the remote system and limit access to the registration process. The administrator configures the registration filter, as displayed in Figure 14-2, using IP address ranges to denote what subnet an agent must reside in for registration to complete successfully. For an agent to even attempt to register with the CSA MC, the agent kit used for installation must be built on that CSA MC server and will include the fully qualified domain name of the MC and the MC certificate. The name must be resolved through any valid resolution method such as Domain Name System (DNS), Windows Internet Name Service (WINS), or host file to get the host connected with the correct CSA MC server.

Figure 14-2. CSA MC Registration Control by IP Address

[View full size image]

NOTE

By default, the CSA MC registration control filter is 0.0.0.0-255.255.255.255, which will not prevent any agent registration request.


CSA MC Component Sharing

Every enterprise environment is different; thus, some enterprise deployments require more than one CSA MC server. In version 4.5, the CSA MC can handle up to 100,000 agents, but sometimes security policy, security administration, and geographic separation play a role in deploying an efficient architecture.

The CSA MC enables you to import and export CSA components between management servers. Items that can be imported and exported include all configuration settings applicable to that component. Components that can be migrated include the following:

  • Groups

  • Policies

  • Rule modules

  • Event sets

  • File sets

  • Network service sets

  • Registry sets

  • COM sets

  • Data sets

  • Network address sets

  • User state sets

  • System state sets

  • Query settings

  • Application classes

  • Reports

The Import/Export feature enables you to maintain consistent policy and configuration across multiple CSA MC servers. This ability speeds deployment and limits configuration error.

Exporting CSA MC Objects

To perform an export task, choose Maintenance > Export. Click New to create a new export job. A list of exportable objects displays, as in Figure 14-3. Before completing the exportation task, you must name the export job, provide a description, and choose all the objects you want to export by checking the associated check boxes. This export will also include referenced objects, such as various sets that may be included in other objects. After setting all parameters associated with the export, click the Export button at the bottom of the page. When prompted about whether you want to export, click Yes. The job proceeds as you watch the progress in the window. When the export finishes, you can click the Here link at the bottom of the processing page to download the file locally.

Figure 14-3. Sample Exportable Objects

[View full size image]

NOTE

When naming an export job, do not include spaces, because this will also be the filename of the export. The file will be named NameProvided.export and will reside in the \csamc45\export directory.

The file exported is formatted as XML and can be opened for viewing, as shown in Figure 14-4. The options within the XML file differ per object type and should never be manually edited, because any error could produce instabilities in your enterprise production CSA MC server when imported.

Figure 14-4. Sample Export Job in XML

[View full size image]

After completing the file export, you can manually move the file from the CSA MC server file location or return to the Export menu where the export job you created is now listed. By clicking this job, you are prompted to save or open the file locally via remote download. Figure 14-5 shows a sample exported file screen.

Figure 14-5. Sample Exported Job Listing

[View full size image]

Importing CSA MC Objects

To perform an import task, choose Maintenance > Import. Click New to create a new import job. You must locate the locally accessible file on your system by clicking the Browse button. After locating the correct previously exported file, provide a name and description for this import. This particular screen should appear as in Figure 14-6. After entering all parameters, click Import.

Figure 14-6. Sample Import Page

[View full size image]

Upon clicking the Import button, you can watch the progress of the import. When the import finishes, you will see Successfully Imported File filename displayed in bold letters at the bottom of the progress page. The import is not yet complete, however. You still need to click Generate Rules to commit the changes. Figure 14-7 shows a successfully imported file.

Figure 14-7. Successful Import of a File

[View full size image]

You can also use the Import History page available as an option on the Import/Export menu to import configuration data. This page displays a historical account of everything that has been imported to this CSA MC server. You can consider this log an audit of imported data.


CSA MC Role-Based Access Control

The CSA MC server automatically employs role-based access control (RBAC) through the VMS user management policy. Every user who wants to use the CSA MC component must first log in to the VMS server with a username and password. Users are granted certain rights to the CSA MC through inheritance from the VMS user database. The CSA MC server has additional administrator controls beyond the basic inherited VMS rights, which you learn about in the next sections.

Inherited VMS Administrative Rights

Rights inherited by the CSA MC from VMS are directly related to the VMS administrative rights. To configure a new VMS administrator user ID, you need to open the Server Configuration drawer in the VMS application. From there, choose Setup > Security. You should see several options related to authentication and user configuration, as follows:

  • Select Login Module— This option enables you to select how users who log in to the VMS application are authenticated. Modules include the following:

    • Local CiscoWorks User Database

    • Local NT System

    • MS Active Directory

    • Netscape Directory

    • IBM SecureWay Directory

    • KerberosLogin

    • RADIUS

    • TACACS+

    The default is to use the local CiscoWorks user database.

  • Permissions Report— This link provides a matrix illustrating the rights each type of VMS user has per application.

  • Who Is Logged On— This link provides a view of all VMS users and whether they are currently online or offline. This also displays the roles the user has assigned and, if online, the IP address and date/time of authentication. You can also broadcast a message to all online users if necessary.

  • Modify My Profile— This enables users to edit their account on the VMS server.

  • Add Users— This is where you would create a new user account to access the VMS server and, in turn, the CSA MC. Figure 14-8 shows an example.

    Figure 14-8. Add CiscoWorks VMS User Page

    [View full size image]

  • Modify/Delete Users— After a user has been created, you can change the assigned roles and other parameters from this page.

To effectively add a user with the correct inherited rights, you must understand how the various roles map into CSA MC administrative roles. Here are the CSA MC administrative roles:

  • Configure— This type is inherited from network or system administrator VMS roles and has full read and write access to the CSA MC database.

  • Deploy— This type is inherited from the network operator VMS role. This CSA MC administrator has full read and partial write access to the CSA MC database. They can manage groups, manage hosts, create new agent kits, schedule software updates for agents, attach policies to groups, and monitor CSA events.

  • Monitor— If the user is not part of either of the above roles but has a valid VMS login account, the user can only view the database but not make changes. These users can also create event sets for use in reports and alerts, which they can also create without impacting agent configuration or software.

CSA MC Administrative Control

Beyond the administrative rights mapping provided by the CiscoWorks VMS server, the CSA MC can further control the access an administrator has to certain objects.

NOTE

You must have configure rights on the CSA MC to edit the Admin Access Control parameters.

To configure restricted access to an administrator account, follow these steps and refer to Figure 14-9:

Step 1. | Choose Maintenance > Admin Preferences the CSA MC application.
Step 2. | Choose Admin Access Control to enter the configuration page.
Step 3. | Choose the administrators you want to limit from the multiple-selection box at the top of the configuration page.
Step 4. | Assign the groups you want them to have rights to view.
Step 5. | Click Save.

Figure 14-9. CSA MC Admin Access Control Configuration

[View full size image]

NOTE

You can only limit administrators with monitor rights to a limited view by group. You cannot limit any of the other administrative types to only configure portions of the database. When an administrator has write access, the administrator has write access to the entire CSA MC database.

Administrative Preferences

While you are still in the Admin Preferences page, it is a perfect time to see what administrative efficiencies can be gained by setting preferences. CSA MC administrators can simplify their view throughout the MC by setting preferences that will follow their management session. If you are running the enterprise-wide deployment of CSA in your network but have only Linux systems, you would not want to see all Solaris- and Windows-configurable options. The way you limit your view is through administrative preferences.

NOTE

The administrative user ID you are logged in as always displays in the lower-right corner of every CSA MC screen.

You can access the following four predefined preferences:

  • Basic

  • Basic UNIX

  • Basic Windows

  • Advanced

This section looks more closely at the Basic Windows administrative preference to better understand what this configurable item provides you. Choose Basic Windows to see a page similar to Figure 14-10. The following options are available:

  • Name— Provide a name for the object

  • Description— Insert a descriptive comment

  • Configuration— Select the appropriate parameters, as follows:

    • Operating System— Select All, Windows, or UNIX to limit your view to only these items.

    • Remember Last Page Visited— This option brings you directly to where you left off when you next return to the CSA MC.

    • Always Use Show All Mode— This option overrides the hidden items that you configured as Display Only in Show All Mode.

    • Always Show Expanded Configuration Views— This option displays any configuration item typically retracted behind a plus sign (+) as fully expanded.

Figure 14-10. Admin Preferences Configuration Page

[View full size image]


Other CSA MC Administrative Features

The Search and Help menus also can speed the use of and efficiency of a CSA MC administrator. These two options prove valuable when attempting to locate timely configuration and usage information.

CSA MC Search Menu

The CSA MC Search menu has several options to limit the scope of the search within the CSA MC configuration database. The Search option is on the main navigation bar across the top of every CSA MC screen. You can search all items or limit the search to any of the following:

  • Hosts

  • Groups

  • Policies

  • Rule modules

  • Rules

  • Variables (sets)

  • Application classes

The next sections provide examples of each option.

Hosts

The hosts search criteria includes several scope-limiting criteria as well as the Find text box at the top of the page, which is where you enter the text you want to locate. Examples of definable criteria for hosts searches include the following:

  • Active hosts

  • Hosts with software updates pending

  • Hosts that have not polled over a specific timeframe

  • Test Mode

  • Within a group

  • Hosts with a specific IP address

You can also show references, search the description fields, and search all other fields. Figure 14-11 displays the Host Search Criteria page.

Figure 14-11. Host Search Criteria Page

[View full size image]

When a search is complete, the results display at the bottom of the search criteria page so that you can view your results and then alter your search if necessary from a single page. Figure 14-12 shows a sample results list. The searched text displays in red even if it is only a partial match. The references are located in the Reference List column of the search results and are expandable by selecting the reference listed.

Figure 14-12. Sample Results Page with Expanded Reference

[View full size image]

Groups

The groups search criteria includes a few scope-limiting criteria as well as the Find text box at the top of the page. Examples of definable criteria for groups searches include the following:

  • All groups

  • Groups with no policies attached

  • Groups with at least one policy attached

You can also show references, search the description fields, and search all other fields. Figure 14-13 displays the Group Search Criteria page.

Figure 14-13. Group Search Criteria and Sample Listing

[View full size image]

Policies

The policies search criteria includes several scope-limiting criteria as well as the Find text box at the top of the page. Examples of definable criteria for policies searches include the following:

  • Attached to no groups

  • Attached to at least one group

  • Attached to a specific group

You can also show references, search the description fields, and search all other fields. Figure 14-14 displays the Policy Search Criteria page.

Figure 14-14. Policy Search Criteria and Sample Results

[View full size image]

NOTE

The Replace link available from the Policy, Variable, and Application Class Search Criteria pages enables you to replace a reference with another reference as part of the search process. This is a sort of "Find and Replace" feature.

Rule Modules

The rule modules search criteria includes several scope-limiting criteria as well as the Find text box at the top of the page. Examples of definable criteria for rule modules searches include the following:

  • Contains a specific rule

  • Attached to specific policy

  • Attached to no policies

You can also show references, search the description fields, and search all other fields. Figure 14-15 displays the Rule Module Search Criteria page.

Figure 14-15. Rule Module Search Criteria and Sample Results

[View full size image]

Rules

The rules search criteria includes several scope-limiting criteria as well as the Find text box at the top of the page. Examples of definable criteria for rules searches include the following:

  • Having a specific rule ID

  • Enabled

  • Disabled

  • Triggered

  • Specific types of rules

You can also show references, search the description fields, and search all other fields. Figure 14-16 displays the Rule Search Criteria page.

Figure 14-16. Rule Search Criteria and Sample Results

[View full size image]

Variables

The variables search criteria includes several scope-limiting criteria as well as the Find text box at the top of the page. Examples of definable criteria for variable searches include the following:

  • All variables

  • Variables that are not used or used

You can also show references, search the description fields, and search all other fields. Figure 14-17 displays the Variable Search Criteria page.

Figure 14-17. Variable Search Criteria and Sample Results

[View full size image]

Application Classes

The application classes search criteria includes several scope-limiting criteria as well as the Find text box at the top of the page. Examples of definable criteria for application classes searches include either all application Classes or application classes that are either used or unused.

You can also show references, search the description fields, and search all other fields. Figure 14-18 displays the Application Class Search Criteria page.

Figure 14-18. Application Class Search Criteria and Sample Results

[View full size image]

All Inclusive

The final search type available is to search all objects. The only search criteria for this search type is the Find text box itself. You can also show references, search the description fields, and search all other fields. Figure 14-19 displays the All Inclusive Search Criteria page.

Figure 14-19. All Inclusive Search Criteria and Sample Results

[View full size image]

CSA MC Help Menu

The CSA MC comes with a built-in searchable Help menu. This online documentation is very thorough and should be the first place you look for assistance when attempting to understand any of the CSA objects and MC usage. You can access the Help menu in two basic ways. The first possible way to access the Help menu is from any CSA MC web page by choosing the Help menu option on the navigation bar. You have three options available from this menu:

  • Online Help— Provides searchable help documentation, as shown in Figure 14-20

    Figure 14-20. Online Help Menu

    [View full size image]

  • Technical Support— Links to the Cisco support website (http://www.cisco.com/tac)

  • About— Provides a pop-up window with the CSA MC version information

You can also access the CSA Help menu via two other links available from any CSA MC page. Using these links will provide the same Help menu; however, these links bring you directly to the specific portion of the menu relating to section of the CSA MC you were configuring. You can locate the two context-specific Help links as follows:

  • The Help option in the upper-right corner of the screen

  • The Help option available by right-clicking any CSA MC web page to reveal a small menu

Figure 14-21 provides examples of both options.

Figure 14-21. Contextual Help Menu Links

[View full size image]


CSA MC Backup and Restore Procedures

You should back up your CSA MC configuration database regularly as part of your scheduled maintenance plan. Having backups will ensure you can keep your architecture running even when affected by CSA MC server hardware failure.

CSA MC Database Backup

You can configure a one-time backup or regular backups of the CSA MC database to protect your configuration information and speed recovery efforts. To access the Backup menu, choose Maintenance > Backup Configuration.

NOTE

The directory specified for backups of the CSA MC configuration database must already exist before successful submission. The storage point in the network must be secure and stable and should not be the C: drive, if possible.

When configuring a backup of the CSA MC configuration database, you are presented the following options, as shown in Figure 14-22:

  • No Backup— This is the default option.

  • Low Frequency Backup— Choose from the following options:

    • Full— Every Sunday at midnight

    • Differential— Every midnight, except Sundays

    • Transaction Log— Every 24 hours, at noon

  • Medium Frequency Backup— Choose from the following options:

    • Full— Every Sunday at midnight

    • Differential— Every midnight, except Sundays

    • Transaction Log— Every 8 hours

  • High Frequency Backup— Choose from the following options:

    • Full— Every Sunday at midnight

    • Differential— Every midnight, except Sundays

    • Transaction Log— Every 4 Hours

  • Backups Directory— Choose the directory for the backup files.

Figure 14-22. Configuring a CSA MC Backup and Backup History

[View full size image]

You should ensure you store this backup in a safe place for both security and availability purposes. If you ever need to restore the CSA MC server from this backup, which includes license information, databases, and transaction logs, you will use the Restore utility described in the following section.

CSA MC Database Restoration

The Configuration Restoring Console is stored in the CSCOpx\CSAMC45\bin directory and is named Restore Configuration. Double-click this file to open the Configuration Restoring Console, as shown in Figure 14-23. To perform a restore operation, all you need to provide is the backup directory location. After completing a restoration, review the log file, as shown in Figure 14-24, and verify the procedure succeeded. After log verification, it is recommended that you restart the CSA MC server.

Figure 14-23. Restoring a Backup with the Configuration Restoring Console

[View full size image]

Figure 14-24. Restoration Log

[View full size image]


Summary

The CSA MC server has many built-in tools that you should use to gain efficiencies and guarantee configuration restoration after an outage. These tools provide mechanisms for locating objects within the database and assistance when using the various configuration pages. In addition to these tools, the CSA MC provides built-in processes for both backing up and restoring the CSA database. It is imperative the CSA MC administrator not only understand these tools but also implement them as regular best practices in a CSA deployment.


Part VII: Appendixes

Appendix A VMS and CSA MC 4.5 Installation

Appendix B Security Monitor Integration

Appendix C CSA MIB


Appendix A. VMS and CSA MC 4.5 Installation

A major component in the Cisco Security Agent (CSA) architecture is the CSA Management Console (MC). This component is where all policy configuration tasks take place and where the events and database can be stored. Previous versions of the CSA MC required all pieces of the MC to be installed on the same server, but in CSA 4.5 the MC components can be separated onto either two or three servers if necessary to provide greater scalability and redundancy.


VMS v2.3 Components

This appendix does not focus too heavily on CiscoWorks VPN/Security Management Solution (VMS) 2.3 as a product other than how it relates to the CSA MC. VMS is the management server framework that the CSA MC plugs in to. VMS provides access control via management user rights and centralized management capabilities to many Cisco security products, such as the Intrusion Detection System (IDS) sensors, CSA agents, and PIX Firewalls. It also has a central logging component known as the Security Monitor for correlating disparate security events within the enterprise. For CSA MC, the required VMS 2.3 component needed is the CiscoWorks Common Services.

You can access the various components of VMS by directing your Java-enabled web browser to http://vmsservername:1741 for the login screen. (You will automatically be redirected to use SSL and port 1742.) Figure A-1 shows the CiscoWorks server login screen. After logging in to the server, you can access the various drawers on the left navigation pane to monitor or configure various tasks, such as the login method and user rights.

Figure A-1. CiscoWorks Server Login Screen

[View full size image]

The drawer that includes the CSA MC component is the VPN/Security Management Solution drawer. Choosing this opens up the VMS component. From here, you can view the installed MCs or select administration tasks. (See Figure A-2.)

Figure A-2. VMS Drawer and Available MCs

[View full size image]

Next, open the appropriate MC, in this case CSA MC (Security Agents V4.5). Choosing this MC opens the application in another web browser window, as shown in Figure A-3. When in the CSA MC, you can begin your configuration tasks as explained throughout this book.

Figure A-3. CSA MC V4.5

[View full size image]

VMS 2.3 Hardware and Software Requirements

As with any software application, you must be certain that you have a stable, precertified hardware and software platform upon which to install. Table A-1 provides the specifications for both the required operating system and hardware platform.

Table A-1. VMS 2.3 Requirements

System Component

Requirement

Hardware

IBM PC-compatible computer

Color monitor with 16-bit video card

Processor

1-GHz or faster Pentium

Operating systems

Windows 2000 (Server or Advanced Server) with Service Pack 4

(Terminal Services is not supported on the CSA MC Server.)

File system

NTFS

Memory

1 GB minimum

Virtual memory

2 GB minimum

Hard drive space

9 GB minimum

Database

MSDE SP 3 or MS SQL 2000

Paging

Hayes-compatible modem

NOTE

MSDE will scale to approximately 500 agents because of the 2-GB database limit, whereas MS SQL loaded on the same server will support up to 10,000 agents.

Using an off-box SQL deployment in a multiserver installation of the CSA MC architecture can scale the system to 100,000 agents in version 4.5.


Installation

This section walks through only the tasks necessary to install VMS 2.3 and CSA MC 4.5 using the Microsoft Database Engine (MSDE) database in a single-server installation. For additional information regarding using MS SQL and multiserver CSA MC deployments, refer to the CSA MC installation guide for details. If you are upgrading from a previous version of CSA, it is advisable to also refer to the appropriate installation documentation provided with the product. When you are certain that your server hardware and software platform meets the minimum requirements, you may proceed with the following steps:

Step 1.
Insert the VMS2.3 installation CD into the drive and wait for the splash screen to appear. Then click Install, as shown in Figure A-4.

Figure A-4. VMS Installation Splash Screen

[View full size image]

Step 2.
Click Next to continue.

Step 3.
Read the license agreement and click Yes if you agree to the terms. (See Figure A-5.)

Figure A-5. VMS Installation License Agreement

[View full size image]

Step 4.
Read the installation recommendations and documentation information, and then click Next.

Note

It is recommended that you install the Security Monitor on a separate server than the MC components for scalability.

Step 5.
Designate the appropriate installation directory or leave the default of C:\Program Files\CSCOpx, as shown in Figure A-6.

Figure A-6. Installation Directory

[View full size image]

Step 6.
Choose the components you want to install, as shown in Figure A-7. Common Services and the Security Monitor are the only applications other than the CSA MC that should be installed on this server. You should not attempt to install other applications on this server because of possible software conflicts and the highly restrictive nature of the local CSA that will be installed as part of the CSA MC installation process.

Figure A-7. Select Components to Install

[View full size image]

Step 7.
View the required drive space and memory for the options you have selected.

Step 8.
Provide a password for the default VMS admin user. The password must be at least five characters long. After completing the installation, you can create additional administrative and viewer accounts locally or point the VMS server to an external server for authentication, such as RADIUS, LDAP, or NDS servers.

Step 9.
Click Yes for the installation to create the CASUSER account, which it will use to run system processes without the need for root privileges.

Step 10.
Provide a password for the VMS application server database.

Step 11.
View the summary prior to installation to verify the installation settings. You can click Show Details to view all settings, including the passwords you entered during the pre-installation interrogation process. Figure A-8 shows the details screen.

Figure A-8. Verify Installation Settings with Details

[View full size image]

Step 12.
Click Next to commence the installation, as shown in Figure A-9.

Figure A-9. Installation of Common Services Begins

[View full size image]

Step 13.
Restart the installation process, this time selecting the CSA MC as the only component to install. Then click Next, as shown in Figure A-10.

Figure A-10. Begin Installation of CSA MC 4.5

[View full size image]

Step 14.
If you are running IIS, you will be prompted to exit out of the installation and stop the World Wide Web Publishing Service before proceeding.

Step 15.
Choose whether the SQL database will be local or on another server. For this example, the installation is a local MSDE installation, as shown in Figure A-11.

Figure A-11. Choose Database Location

[View full size image]

Step 16.
The installation now informs you that it needs to proceed with the MSDE installation prior to installing the CSA MC. After the MSDE component has been installed, you must reboot the server and restart the installation of the CSA MC.

Step 17.
Choose the destination of the MSDE database on the local server, as shown in Figure A-12. The default is C:\Program Files\Microsoft SQL Server.

Figure A-12. Choose MSDE Installation Location

[View full size image]

Step 18.
Upon installation completion, reboot the server and begin the CSA MC installation again.

Step 19.
You are now prompted for the CSA MC license file. Choose the appropriate file from your hard drive and continue.

Step 20.
Click Install to begin the installation process. The CSA MC V4.5 installation begins by copying the files, as shown in Figure A-13. Figure A-14 shows the start of the configuration process.

Figure A-13. CSA MC V4.5 Begins with Copying Files

[View full size image]

Figure A-14. Product Configuration Commences

[View full size image]

Step 21.
When installation completes, a restart is required and you are informed that the system will reboot in 2 minutes.

Step 22.
After reboot, you can start CiscoWorks from the Windows Programs menu on the server to verify a successful installation, as shown in Figure A-15.

Figure A-15. Verify Installation of All Components

[View full size image]


Summary

The installation of a generic single-server deployment of the CSA MC server is fairly straightforward, with relatively few caveats and a few reboots along the way. Obviously, as you increase the complexity of the installation by using MS SQL server rather than the MSDE database and separate various CSA MC components onto multiple servers for scalability and redundancy, the number of steps increases. For more information regarding the more complex implementation architectures, refer to the associated installation documentation for the appropriate procedure.


Appendix B. Security Monitor Integration

The CiscoWorks VPN/Security Management Solution (VMS) package consists of several components. The majority of the components, known as management centers (MC), are used for configuring and updating specific types of devices. The CSA MC is used to manage a Cisco Security Agent (CSA) deployment, the Firewall MC is for managing the Cisco PIX Firewall family, and the IDS MC is used to manage Cisco IDS sensors.

You can install another component as part of a VMS server deployment that all the Cisco security components can use. This package is the Monitoring Center for Security, also known as the Security Monitor.

The Monitoring Center for Security is a software package that is capable of receiving alert/events from various Cisco security devices, including network Intrusion Detection/Protection Systems (IDS/IPS), Host IPSs, and syslogs from PIX Firewalls. Receiving the alerts in a single monitoring application allows for centralized viewing of correlated events. This package can then send notification of an issue or provide reporting capabilities on the aggregate data. Because it is a component of the VMS package and is licensed as part of the VMS software, it can also use the inherent role-based access control capabilities that the suite of utilities implements. Therefore, administrative users can have varying levels of control over the monitoring package based on their user rights granted by the overall VMS system itself.

You will find the Security Monitor to be a useful package when attempting to correlate events across your network. This appendix does not cover the Security Monitor in detail because the goal is only to help you understand what the Security Monitor is capable of providing a CSA deployment and what is necessary to get the two components to communicate.


Adding the CSA MC to the Security Monitor

The Security Monitor does not receive events from all CSA agents. The CSA MC continues to receive, log, and act upon all events received from CSA agents and then communicates the information to the Security Monitor. The event data is sent between the two components using SSL as the communication protocol to ensure secure encrypted communication of events.


Configuring the Security Monitor

The CSA MC CiscoWorks component does not require any explicit configuration to communicate with the Security Monitor. All configuration is performed within the Security Monitor itself. To configure the Security Monitor to communicate with the CSA MC, open the Security Monitor from the VMS drawer on the server, as shown in Figure B-1.

Figure B-1. Security Monitor Application Location Drawer

[View full size image]

When the Security Monitor application opens, follow these steps, which correspond to Figure B-2:

Step 1.
Click Devices > Add.

Step 2.
Choose Cisco SA MC > Next.

Step 3.
Enter the information required into the Add Device page, as follows:

  • IP Address— Enter the address of the CSA MC.

  • NAT Address— If the CSA MC is behind a NAT device, add the appropriate NAT address. Otherwise, leave this field empty; it is not required.

  • Device Name— Enter the name that will appear in the device list.

  • Description— Enter a description for the CSA MC. A description assists other administrators in understanding special information regarding this device.

  • Certificate Common Name— Enter the name from the CSA MC SSL certificate.

  • Web Server Port— Enter the web server port that should be used for communication. By default, this is set to TCP/443, which is SSL.

  • Username— Enter a valid CSA MC administrator name. For auditing purposes, make this name unique so that no other administrator uses this account.

  • Password— Enter and verify the password for the CSA MC administrator account.

  • Minimum Event Level— From the drop-down list, choose the minimum event level you want to add to the Security Monitor database.

Step 4.
Click Finish to complete the device configuration.

Figure B-2. Security Monitor Device Configuration Page

[View full size image]

After the sensor has been added, you should see the device listed either alone or with your other monitored devices, as in Figure B-3.

Figure B-3. CSA MC in the Device List

[View full size image]


Verifying Connectivity

After adding the CSA MC device, verify that the Security Monitor is successfully talking to the CSA MC. To do this, you must follow a few simple steps:

Step 1. | Click the Monitor tab in the Security Monitor.
Step 2. | Click the Connections option.

You should see your CSA MC server in the device list with a connection status of Connected TLS. This state proves a successful connection to the CSA MC has been made. Figure B-4 shows a sample view of a connected CSA MC server. After you have a connected CSA MC server, you will begin to receive events in the Security Monitor application.

Figure B-4. Successfully Connected CSA MC Server

[View full size image]


Viewing Events in the Security Monitor

It is fairly easy to view and work with events in the Security Monitor. To view events as they enter the database, you must first open the Security Monitor Event Viewer. You can open the Event Viewer by clicking the Events option from the Monitor tab. This presents a screen as in Figure B-5. On this screen, you configure the Event Viewer for this session.

Figure B-5. Event Viewer Configuration Page

[View full size image]

The Launch Event Viewer screen enables you to set some behavioral parameters. By default, the viewer is set to display all IDS alarms. You can change this setting for this session to display only CSA alarms if you want to focus your view on only your CSA MC server(s).

When you have the viewing parameters set for this session, click Launch Event Viewer. You are now presented the Event Viewer screen, similar to what you see in Figure B-6. Discussing the Security Monitor in detail is beyond the scope of this book. For more information on using the Security Monitor, refer to the VMS server help documentation or Cisco.com.

Figure B-6. Sample Event Viewer Screen

[View full size image]


Summary

The CSA MC can integrate with several third-party applications to provide a well-rounded security view of your network for your security and monitoring staff. The Cisco Security Monitor is just one those applications that the CSA MC can integrate. Although the CSA MC itself is the most efficient way to monitor a CSA deployment, the Security Monitor capability to correlate your entire Host Intrusion Detection System (HIDS) and Network Intrusion Detection System (NIDS) deployment can prove a very valuable asset. Whether you choose to implement the Cisco Security Monitor, a third-party aggregation and reporting tool, or just the CSA MC itself, it is at the very least worth taking some time to understand what benefits a correlation tool can provide.


Appendix C. CSA MIB

The Cisco Security Agent Management Console (CSA MC) can integrate with third-party SNMP applications by sending traps to the SNMP server. This appendix provides the SNMPv2 MIB used when you want to integrate. You can find the Management Information Base (MIB) in the \CSCOpx\CSAMC45\doc\CSAMC-SNMPv2.mib document.


CSA MC MIB Definitions

CSAMC-SNMPv2-MIB DEFINITIONS ::= BEGIN

IMPORTS

    enterprises, Counter

             FROM RFC1155-SMI

    OBJECT-TYPE

             FROM RFC-1212

    TRAP-TYPE

             FROM RFC-1215;

--

-- Assigned by IANA

--

ciscoSecurityAgent    OBJECT IDENTIFIER ::= { enterprises 8590 }

--

-- Cisco Security Agent subtrees

--

csaModules OBJECT IDENTIFIER ::= { ciscoSecurityAgent 1 }

csaObjects OBJECT IDENTIFIER ::= { ciscoSecurityAgent 2 }

csaTraps   OBJECT IDENTIFIER ::= { ciscoSecurityAgent 3 }

--

-- Managed objects follow

--

-- Contents:

--     csaNotifyMessage      Alert generated by Cisco Security Agent

--

eventID OBJECT-TYPE

        SYNTAX  INTEGER

        ACCESS  not-accessible

        STATUS  mandatory

        DESCRIPTION "An integer uniquely identifying the event."

        ::= {csaObjects 1}

ruleID OBJECT-TYPE

       SYNTAX  INTEGER

       ACCESS  not-accessible

       STATUS  optional

       DESCRIPTION "An integer uniquely identifying the rule that caused the event."

       ::= {csaObjects 2}

hostName OBJECT-TYPE

       SYNTAX  OCTET STRING

       ACCESS  not-accessible

       STATUS  optional

       DESCRIPTION "Name of the host that generated the event."

       ::= {csaObjects 3}

eventTime OBJECT-TYPE

        SYNTAX  OCTET STRING

        ACCESS  not-accessible

        STATUS  mandatory

        DESCRIPTION "The time at which the event occurred."

        ::= {csaObjects 4}

severityCode OBJECT-TYPE

        SYNTAX  INTEGER

        ACCESS  not-accessible

        STATUS  optional

        DESCRIPTION "An integer indicating event severity, from Information (1) to

          Emergency (7)."

        ::= {csaObjects 5}

eventCode OBJECT-TYPE

        SYNTAX  INTEGER

        ACCESS  not-accessible

        STATUS  mandatory

        DESCRIPTION "An integer uniquely identifying event type."

        ::= {csaObjects 6}

processName OBJECT-TYPE

        SYNTAX  OCTET STRING

        ACCESS  not-accessible

        STATUS  optional

        DESCRIPTION "When applicable, the process that triggered the event."

        ::= {csaObjects 7}

fileName OBJECT-TYPE

        SYNTAX  OCTET STRING

        ACCESS  not-accessible

        STATUS  optional

        DESCRIPTION "When applicable, the name of the relevant file from

          a file event."

        ::= {csaObjects 8}

sourceIPAddress OBJECT-TYPE

        SYNTAX  IpAddress

        ACCESS  not-accessible

        STATUS  optional

        DESCRIPTION "When applicable, the source IP address of a network event."

        ::= {csaObjects 9}

destinationIPAddress OBJECT-TYPE

        SYNTAX  IpAddress

        ACCESS  not-accessible

        STATUS  optional

        DESCRIPTION "When applicable, the destination IP address of a network event."

        ::= {csaObjects 10}

eventText OBJECT-TYPE

    SYNTAX       OCTET STRING

    ACCESS       not-accessible

    STATUS       mandatory

    DESCRIPTION  "The complete formatted text of the event."

    ::= { csaObjects 11 }

hostID OBJECT-TYPE

        SYNTAX  INTEGER

        ACCESS not-accessible

        STATUS optional

        DESCRIPTION "An integer uniquely identifying the host that generated the

          event."

        ::= { csaObjects 12 }

currentHostIPAddress OBJECT-TYPE

               SYNTAX  IpAddress

               ACCESS not-accessible

               STATUS optional

               DESCRIPTION "The most recently recorded IP address of the host that

                 generated the event."

        ::= { csaObjects 13 }

hostOSType OBJECT-TYPE

        SYNTAX  OCTET STRING

        ACCESS  not-accessible

        STATUS  optional

        DESCRIPTION "The OS type of the host that generated the event, W for Windows,

          U for Unix"

        ::= { csaObjects 14 }

sourcePort OBJECT-TYPE

        SYNTAX  INTEGER

        ACCESS not-accessible

        STATUS optional

        DESCRIPTION "When applicable, the port used by the source of a network event."

        ::= { csaObjects 15 }

destinationPort OBJECT-TYPE

        SYNTAX  INTEGER

        ACCESS not-accessible

        STATUS optional

        DESCRIPTION "When applicable, the port used by the destination of a network

          event."

        ::= { csaObjects 16 }

eventType OBJECT-TYPE

        SYNTAX  OCTET STRING

        ACCESS  not-accessible

        STATUS  optional

        DESCRIPTION "A string representing the type of the rule that caused the event."

        ::= { csaObjects 17 }

ruleDescription OBJECT-TYPE

        SYNTAX  OCTET STRING

        ACCESS  not-accessible

        STATUS  optional

        DESCRIPTION "The user-specified string description of the rule that caused

          the event."

        ::= { csaObjects 18 }

policyID OBJECT-TYPE

        SYNTAX  INTEGER

        ACCESS not-accessible

        STATUS optional

        DESCRIPTION "An integer uniquely identifying the policy which contains the

          rule that caused the event."

        ::= { csaObjects 19 }

policyName OBJECT-TYPE

        SYNTAX  OCTET STRING

        ACCESS  not-accessible

        STATUS  optional

        DESCRIPTION "The string name of the policy which contains the rule that

          caused the event."

        ::= { csaObjects 20 }

buttonCode OBJECT-TYPE

        SYNTAX  INTEGER

        ACCESS not-accessible

        STATUS optional

        DESCRIPTION "When applicable, the bottom 16 bits represent the query button

          that the user pressed."

        ::= { csaObjects 21 }

userName OBJECT-TYPE

        SYNTAX  OCTET STRING

        ACCESS  not-accessible

        STATUS  optional

        DESCRIPTION "The name of the logged-in user at the time of the event."

        ::= { csaObjects 22 }

--

-- Traps follow

--

-- Contents:

--     csaNotifyTrap         Trap containing a single csaNotifyMessage

--

csaNotifyTrap TRAP-TYPE

    ENTERPRISE   csaTraps

    VARIABLES    {         eventID, ruleID, hostName, eventTime,

                              severityCode, eventCode, processName, fileName,

                              sourceIPAddress, destinationIPAddress2, eventText,

                              hostID, currentHostIPAddress, hostOSType,

                              sourcePort, destinationPort,

                              eventType, ruleDescription, policyID, policyName,

                              buttonCode, userName }

    DESCRIPTION  "An alert generated by a Cisco Security Manager."

    ::= 1

END


Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W]

Previous Section < Day Day Up >


index_SYMBOL

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W]

@dynamic variable
@local variable

Previous Section < Day Day Up >


index_A

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W]

access control rules
data sets 2nd
network address sets
network services sets 2nd
ActiveX Frame 2nd 3rd
administrative parameters
agent components
interceptors
rule/event correlation engine
Agent Control Panel 2nd 3rd 4th 5th
Status 2nd
Contact Information
Messages
User Query Responses 2nd
System Security 2nd
Untrusted Applications
agent executable files
agent interfaces
Linux 2nd
Solaris
csactl utility 2nd
stopping
Windows
Agent Control Panel 2nd 3rd 4th 5th
audible notifications 2nd
directories 2nd
firewalls 2nd
GUI 2nd 3rd 4th 5th
Programs menu 2nd 3rd
stopping 2nd
system tray options 2nd
tools 2nd
tray icon 2nd
user interfaction 2nd
agent kits
creating 2nd
installing 2nd
Windows
network shim 2nd
agent policy manager
alert events
alerts 2nd
configuring
creating 2nd
custom programs
event sets
geographic groups
analysis
Event Management Wizard
anomaly detection 2nd
application builder rules
application classes
dynamic
shell scripts
Application Deployment Investigation groups
application fingerprinting
attacks
blended threats 2nd
bundled exploits
delivery mechanisms 2nd
persistence 2nd
propagation mechanisms 2nd
scanning mechanisms
DoS attacks
viruses 2nd
worms 2nd
Audit Trail reports
audit trails 2nd
filtering 2nd 3rd
auditing 2nd
changes
filtering 2nd
filtering audits
auto-pruning tasks 2nd

Previous Section < Day Day Up >


index_B

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W]

backdoor attack vectors 2nd
balloon messages
Base Operating System Protection _ Windows policy 2nd
behavior-based attack detection 2nd
Best Practices document
bin directories
blended threats
destructive behavior 2nd
propagation mechanisms 2nd
bulk transfers (groups)
bundled exploits

Previous Section < Day Day Up >


index_C

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W]

candy shell security 2nd
challenge responses
changes (auditing)
Cisco ACS (Access Control Server)
Cisco Partners
Cisco Self-Defending Network Initiative
Cisco Trust Agent [See CTA]
CiscoWorks Common Services
CiscoWorks VPN/Security Management System [See VMS server]
cloning
components
rule modules
communication security 2nd
critical events
Crystal Report viewer
csactl utility 2nd
CTA ()
custom groups
custom programs

Previous Section < Day Day Up >


index_D

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W]

data
availability
confidentiality
integrity
data sets 2nd
databases
event log
MSDE 2nd
DCOM
denial-of-service attacks [See attacks;DoS attacks]
detect rules
detecting attacks
application fingerprinting
automation
behavior-based attacks 2nd
log file scraping
signature-based attacks
directories
bin
log
protecting
Distributed Component Object Model [See DCOM]
DNS (Domain Name Server)
Domain Name Server [See DNS]
downloads
untrusted
dump files
DMP files
dynamic application classes
configuring 2nd 3rd

Previous Section < Day Day Up >


index_E

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W]

edge security mechanisms
editing
cloning (versus)
emergency events
enforce rules
Enforcement Mode
agents
enhancements
error events
event insertion tasks 2nd
event log 2nd 3rd
alerts
axis labels
database
Event field 2nd
details 2nd
Event Wizard 2nd
find similar 2nd
rule numbers
Event Log Viewer
filtering 2nd 3rd
filtering view 2nd
interpreting 2nd
managing
auto-pruning tasks 2nd
event insert tasks 2nd
using 2nd
Event Log Viewer
event logs
Event Management Wizard 2nd 3rd 4th 5th 6th
Event Monitor (versus) 2nd
fine-tuning policies 2nd
troubleshooting 2nd
Event Management Wizard 2nd
using 2nd 3rd 4th
Event menu
Summary Status screen
Refresh section
event messages
Event Monitor 2nd
event logs (versus) 2nd
filtering 2nd 3rd 4th
using event sets
Event Monitoring
filtering
event sets 2nd 3rd
Event Montior
hosts
policy rules
predefined
Event Wizard 2nd
exception rules
events
alerts 2nd 3rd
configuring
auto-pruning tasks 2nd
axis labels
critical
emergency
errors
event counts per day 2nd 3rd
event insertion tasks 2nd
event log
database
Event Log Viewer
managing 2nd 3rd 4th 5th
Event Monitor
filtering 2nd 3rd 4th
Event Monitor filtering
event sets 2nd 3rd
predefined
Event Wizard 2nd
Events menu
filtering
Filter Events window
informational
notice
reporting 2nd
by group reports 2nd
by severity 2nd 3rd 4th
suppression events
Test Mode
warning
Events menu
alerts
Status Summary screen 2nd
Status Summary Screen
Event Counts per Day section
Network Status section 2nd
exception rules 2nd 3rd 4th
exploits
bundled exploits
persistence 2nd
Extensible Authentication Protocol
EAP

Previous Section < Day Day Up >


index_F

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W]

false positives
file servers
files
hosts file
protecting
RTR files
Filter events window
filtering
audit trails 2nd
audits
event log 2nd 3rd
Event Monitor 2nd
Event Montitor
event sets
Filter Events window
using event sets
filters
host-associated events
user information
fingerprinting (application)
firewalls
Linux
floppy disks
viruses
functional groups

Previous Section < Day Day Up >


index_G

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W]

geographic groups
Group Detail reports 2nd
groups
Application Deployment Investigation groups
assigning group membership
changing group membership 2nd 3rd
comparing groups
creating custom groups
CSA
exploring predefined groups
other groups
functional groups
geographic groups
Group Detail reports 2nd
group types
custom
Host Detail reports 2nd
implementation plan
mandatory groups 2nd 3rd
policies
Policy Detail reports 2nd
reporting events 2nd
servers
Short Polling groups
Software Update groups
Test Mode groups
user state sets
Verbose Logging Mode
viewing group membership
viewing group-associated events
GUIs (graphical user interfaces) [See agent interfaces]

Previous Section < Day Day Up >


index_H

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W]

hackers
e-mail
hierarchy
CSA components
hint messages 2nd
Host Detail reports 2nd
hosts
Application Deployment Investigation groups
changing group membership
CSA 2nd 3rd 4th 5th 6th
event sets
Host Detail reports 2nd
inheritance
Test Mode groups
updates
using Test Mode
working with
HTML Frame 2nd 3rd
Hypertext Transfer Protocol
HTTP
Hypertext Transfer Protocol Secure
HTTPS

Previous Section < Day Day Up >


index_I

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W]

IDS (Intrusion Detection System) sensors
implementation 2nd
project phases 2nd
continuing evolution
implementation phase
pilot phase 2nd
planning
testing 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th 16th 17th 18th 19th 20th 21st 22nd 23rd 24th 25th 26th
training
implementation phase 2nd
implementation plan
CiscoWorks Common Services
future enhancements
groups
network shim
project phases
implementation phase
pilot phase
planning
testing 2nd 3rd
project plan
users
informational events
inheritance (groups)
insider attacks 2nd
installation
MSDE database 2nd
Instant Messenger policy 2nd
interaction [See user interaction]
interfaces
Linux 2nd
Solaris
csactl utility 2nd
stopping
Windows agent
Agent Control Panel 2nd 3rd 4th 5th
audible notifications 2nd
directories 2nd
firewalls 2nd
GUI 2nd 3rd 4th 5th
Programs menu 2nd 3rd
stopping 2nd
system tray options 2nd
tools 2nd
tray icon 2nd
user interaction 2nd
Internet
viruses
Internet Protocol
IP
Intrusion Detection Sensors/Systems [See security;IDSs]

Previous Section < Day Day Up >


index_L

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W]

LANs
viruses
Learning Mode
Linus
mandatory groups
Linux
agent components
agent interface 2nd
local event manager
local-area networks [See LANs]
locks
log directories
log file scraping
logging
Event field 2nd
details 2nd
Event Wizard 2nd
rule numbers
event log
filtering 2nd 3rd
interpreting 2nd
using 2nd
event sets
local event manager
Log Deny Actions option
purging logs
verbose logging
logs
security logs

Previous Section < Day Day Up >


index_M

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W]

maintenance parameters
mandatory groups 2nd 3rd 4th 5th
mandatory rules
MC ()
MSDE database
updating rules
viewing events
Microsoft Office policy 2nd
Microsoft Windows [See Windows]
MSDE (Microsoft Data Engine) database
MSDE database

Previous Section < Day Day Up >


index_N

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W]

network address sets 2nd 3rd
network attacks [See attacks]
network locks
network services sets 2nd
network shim
implementation plan
network shims 2nd 3rd
conflicts
nonquiet install
Windows
nonquiet installs
notice events

Previous Section < Day Day Up >


index_O

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W]

ODBC DSN
OLE_LINK1

Previous Section < Day Day Up >


index_P

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W]

Partners (Cisco)
payloads
damaging payloads
permissions
persistence 2nd
blended threats 2nd
pilot phase 2nd 3rd
planning
planning phase 2nd
success criteria
policies
agent policy manager
availability
confidentiality
fine-tuning
DMP/RTR files
integrity
Policy Detail reports 2nd
predefined policies
test beds
testing
tuning
tuning
updating
Policy Detail reports 2nd
policy documents
policy rules
polling intervals (hosts) 2nd
pop-up messages
port scans
ports
ephemeral ports
precedence (rules)
predefined event sets
predefined groups
project implementation [See implementation]

Previous Section < Day Day Up >


index_Q

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W]

quiet install
Windows
quiet installs

Previous Section < Day Day Up >


index_R

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W]

RBAC (role-based access control)
reactive detection
Red Hat
refresh rates 2nd
registry
pop-up messages
Remote Procedure Call [See RPC]
reports
ActiveX Frame 2nd
Reports
ActiveX Frame
reports
Audit Trail reports
audit trails 2nd
filtering 2nd 3rd
configuring
creating 2nd
event sets
events 2nd
by group reports 2nd
by severity 2nd 3rd 4th
Group Detail reports 2nd
Host Detail reports 2nd
HTML Frame 2nd 3rd
Policy Detail reports 2nd
Reports menu
sorting options
viewing
Reports menu
Event by Severity option
Group Details reports
Host Detail reports
Policy Detail reports
request traces files [See RTR files]
role-based access control [See RBAC]
RPC
RTR (request trace) files
RTR files
rule modules
test beds
rule sets
rule/event correlation engine
rules
access control
data sets 2nd
network address sets 2nd
network services sets 2nd
conflicts
detect rules
Event Monitor
Event Wizard
exception rules 2nd
locks
precedence
rule modules
cloning
test beds
rule sets
rule/event correlation engine
user interfaces
Run key
RunOnce key

Previous Section < Day Day Up >


index_S

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W]

scope creep
Secure Shell [See worms;SSH]
Secure Sockets Layer [See SSL]
security
communication security 2nd
IDSs
point security 2nd
security policies 2nd 3rd
compliance vs. enforcement 2nd
security levels
security policies
compliance vs. enforcement
servers
using groups
workstations (versus
sets
Short Polling groups
signature-based attack detection
signatures
Slammer worm 2nd
sneakernet 2nd
software
updating
Software Update groups
Solaris
agent components
agent interface
csactl utility 2nd
stopping
arguments 2nd
mandatory groups
spyware 2nd
SQL server
SSL ()
state sets
user
static application classes
creating 2nd
status summary 2nd
event counts per day 2nd 3rd
network 2nd
refresh 2nd
success criteria 2nd
planning phase
summaries
event counts per day 2nd 3rd
refresh 2nd
status 2nd
network 2nd
system tray options 2nd

Previous Section < Day Day Up >


index_T

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W]

tasks
auto-pruning 2nd
event insertion 2nd
test beds
Test Mode 2nd
events
logging
verbose logging
Test Mode groups
testing phase 2nd
adding advanced policies 2nd
creating alerts 2nd
creating base test policy 2nd
creating/configuring administrative/maintenance settings 2nd
creating/configuring test hierarchy 2nd 3rd
deploying test policy 2nd
determining test bed size and components 2nd
exporting/reporting/documenting
gathering information 2nd
installing management architecture
installing test management architecture
placing policy in Enforcement Mode 2nd
training staff/users 2nd
tuning test policy 2nd
verifying success
timeframes
rules
training 2nd
training phase
Transmission Control Protocol
TCP
tray icon 2nd
troubleshooting
event logs 2nd
isolated breaches
using Short Polling groups

Previous Section < Day Day Up >


index_U

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W]

UDP
blended threats
UDP ()
ephemeral ports
UNIX
shell scripts
controlling 2nd
updates 2nd
hosts
policies
software
Software Update groups
User Datagram Protocol [See UDP]
user interaction
user state sets
users
implementation plan

Previous Section < Day Day Up >


index_V

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W]

verbose logging 2nd
viruses
e-mail
encryption
floppy disks 2nd
global implications
payload
testing system protection 2nd
WANS
zip files
VMS server 2nd

Previous Section < Day Day Up >


index_W

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W]

warning events
websites
Cisco.com 2nd
wide-area networks [See viruses;WANs]
wildcards
directories
files
Windows
Agent Control Panel
Contact Information
Messages
Status 2nd
System Security 2nd
Untrusted Applications
User Query Responses 2nd
agent interface
Agent Control Panel 2nd 3rd 4th 5th
audible notifications 2nd
directories 2nd
firewalls 2nd
GUI 2nd 3rd 4th 5th
Programs menu 2nd 3rd
stopping 2nd
system tray options 2nd
tools 2nd
tray icon 2nd
user interaction 2nd
agent kits
installing 2nd 3rd
auto-start mechanisms
directories
default installation
mandatory groups
workstations
defense in depth
servers (versus)
worms
e-mail
encryption
global implications 2nd
history 2nd 3rd 4th 5th
Morris worm
payloads
persistence
single environment
SSH

Previous Section < Day Day Up >