IBM Tivoli and Cisco User Manual

Front cover

Building a Network
Access Control Solution

with IBM Tivoli and Cisco Systems

Covering Cisco Network Admission
Control Framework and Appliance

Automated remediation of
noncompliant workstations

Advanced security
compliance notification

ibm.com/redbooks

Axel Buecker

Richard Abdullah

Markus Belkin

Mike Dougherty

Wlodzimierz Dymaczewski

Vahid Mehr

Frank Yeh

International Technical Support Organization

Building a Network Access Control Solution with
IBM Tivoli and Cisco Systems

January 2007

SG24-6678-01

Note: Before using this information and the product it supports, read the information in
“Notices” on page vii.

Second Edition (January 2007)

This edition applies to Tivoli Security Compliance Manager V5.1, Tivoli Configuration Manager
V4.2.3, and Cisco Secure ACS V4.0.

© Copyright International Business Machines Corporation 2005, 2007. All rights reserved.

Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP
Schedule Contract with IBM Corp.

Contents

Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii

Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii

Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix

The team that wrote this redbook. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x

Become a published author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii

Comments welcome. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii

Summary of changes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv

January 2007, Second Edition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv

Part 1. Architecture and design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

Chapter 1. Business context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.1 The security compliance and remediation concept . . . . . . . . . . . . . . . . . . . 4

1.2 Why we need this . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.3 Does this concept help our mobile users . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.4 Corporate security policy defined . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.5 Business driver for corporate security compliance . . . . . . . . . . . . . . . . . . . 8

1.6 Achievable benefits for being compliant . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.7 Conclusion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Chapter 2. Architecting the solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.1 Solution architectures, design, and methodologies . . . . . . . . . . . . . . . . . . 14

2.1.1 Architecture overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.1.2 Architectural terminology. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.2 Definition of a Network Admission Control project . . . . . . . . . . . . . . . . . . 26

2.2.1 Phased rollout approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2.3 Design process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

2.3.1 Security compliance management business process . . . . . . . . . . . . 28

2.3.2 Security policy life cycle management . . . . . . . . . . . . . . . . . . . . . . . 30

2.3.3 Solution objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

2.3.4 Network design discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

2.4 Implementation flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

2.5 Scalability and high availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

2.6 Conclusion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Chapter 3. Component structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

3.1 Logical components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

© Copyright IBM Corp. 2005, 2007. All rights reserved. iii

3.1.1 Network Admission Control. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

3.1.2 Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

3.1.3 Remediation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

3.2 Physical components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

3.2.1 Network client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

3.2.2 Network access infrastructure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

3.2.3 IBM Integrated Security Solution for Cisco Networks servers. . . . . . 54

3.3 Solution data and communication flow . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

3.3.1 Secure communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

3.4 Component placement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

3.4.1 Security zones. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

3.4.2 Policy enforcement points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

3.5 Conclusion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

Part 2. Customer environment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

Chapter 4. Armando Banking Brothers Corporation . . . . . . . . . . . . . . . . . 77

4.1 Company profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

4.2 Current IT architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

4.2.1 Network infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

4.2.2 IBM Integrated Security Solution for Cisco Networks lab . . . . . . . . . 80

4.2.3 Application security infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

4.2.4 Middleware and application infrastructure. . . . . . . . . . . . . . . . . . . . . 86

4.3 Corporate business vision and objectives . . . . . . . . . . . . . . . . . . . . . . . . . 87

4.3.1 Project layout and implementation phases . . . . . . . . . . . . . . . . . . . . 87

4.4 Conclusion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

Chapter 5. Solution design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

5.1 Business requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

5.2 Functional requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

5.2.1 Security compliance requirements . . . . . . . . . . . . . . . . . . . . . . . . . . 96

5.2.2 Network access control requirements . . . . . . . . . . . . . . . . . . . . . . . . 96

5.2.3 Remediation requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

5.2.4 Solution functional requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

5.3 Implementation architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

5.3.1 Logical components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

5.3.2 Physical components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

5.4 Conclusion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

Chapter 6. Compliance subsystem implementation . . . . . . . . . . . . . . . . 125

6.1 Tivoli Security Compliance Manager setup . . . . . . . . . . . . . . . . . . . . . . . 126

6.1.1 Installation of DB2 database server . . . . . . . . . . . . . . . . . . . . . . . . 126

6.1.2 Installation of Tivoli Security Compliance Manager server . . . . . . . 140

6.2 Configuration of the compliance policies. . . . . . . . . . . . . . . . . . . . . . . . . 152

iv Building a Network Access Control Solution with IBM Tivoli and Cisco Systems

6.2.1 Posture collectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153

6.2.2 Policy collector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154

6.2.3 Installation of posture collectors . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

6.2.4 Customization of compliance policies . . . . . . . . . . . . . . . . . . . . . . . 161

6.2.5 Assigning the policy to the clients . . . . . . . . . . . . . . . . . . . . . . . . . . 186

6.3 Deploying the client software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189

6.3.1 Cisco Trust Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190

6.3.2 IBM Tivoli Security Compliance Manager client . . . . . . . . . . . . . . . 199

6.4 Conclusion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212

Chapter 7. Network enforcement subsystem implementation . . . . . . . . 213

7.1 Configuring NAC Framework components . . . . . . . . . . . . . . . . . . . . . . . 214

7.1.1 Configuring the Cisco Secure ACS for NAC L2 802.1x . . . . . . . . . 214

7.1.2 Configuring the Cisco Secure ACS for NAC L2/L3 IP. . . . . . . . . . . 283

7.1.3 Deployment of the network infrastructure . . . . . . . . . . . . . . . . . . . . 291

7.2 Configuring NAC Appliance components . . . . . . . . . . . . . . . . . . . . . . . . 303

7.2.1 Installing CCA Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304

7.2.2 Configuring a CCA OOB VG server . . . . . . . . . . . . . . . . . . . . . . . . 306

7.2.3 Deployment of the network infrastructure . . . . . . . . . . . . . . . . . . . . 352

7.3 Conclusion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354

Chapter 8. Remediation subsystem implementation. . . . . . . . . . . . . . . . 355

8.1 Automated remediation enablement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357

8.2 Remediation server software setup. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358

8.2.1 Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358

8.2.2 Tivoli Configuration Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359

8.2.3 Configuration of the remediation server . . . . . . . . . . . . . . . . . . . . . 385

8.2.4 Installation of the Software Package Utilities . . . . . . . . . . . . . . . . . 394

8.3 Creating remediation instructions for the users . . . . . . . . . . . . . . . . . . . . 397

8.3.1 Locating HTML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398

8.3.2 Variables and variable tags. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402

8.3.3 Debug attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406

8.3.4 Creating HTML pages for ABBC policy. . . . . . . . . . . . . . . . . . . . . . 409

8.4 Building the remediation workflows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417

8.4.1 Modification of the remediation packages . . . . . . . . . . . . . . . . . . . . 436

8.5 Conclusion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437

Part 3. Appendixes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 439

Appendix A. Hints and tips. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 441

Deployment overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 442

Top-level sequence of events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444

Security Compliance Manager and NAC compliance subsystem . . . . . . . . . 446

Cisco NAC sequence of events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447

Contents v

Fault isolation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 448

Security Compliance Manager server and client . . . . . . . . . . . . . . . . . . . . . . 450

Communication port usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 451

Tools and tricks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 451

Cisco NAC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 451

Tools and tricks for the client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453

NAC Appliance details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455

NAC Appliance integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 457

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 470

Appendix B. Network Admission Control . . . . . . . . . . . . . . . . . . . . . . . . . 471

Executive summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472

The benefit of NAC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472

Dramatically improve network security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473

NAC implementation options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474

The NAC Appliance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475

NAC Framework solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476

Investment protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476

Planning, designing, and deploying an effective NAC solution . . . . . . . . . . . 477

The next steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 478

NAC technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 478

NAC Appliance components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 478

NAC Framework components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 479

Appendix C. Additional material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 481

Locating the Web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 481

Using the Web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 482

How to use the Web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 482

Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483

IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483

Other publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483

Online resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484

How to get IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484

Help from IBM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 487

vi Building a Network Access Control Solution with IBM Tivoli and Cisco Systems

Notices

This information was developed for products and services offered in the U.S.A.

IBM may not offer the products, services, or features discussed in this document in other countries. Consult
your local IBM representative for information about the products and services currently available in your
area. Any reference to an IBM product, program, or service is not intended to state or imply that only that
IBM product, program, or service may be used. Any functionally equivalent product, program, or service that
does not infringe any IBM intellectual property right may be used instead. However, it is the user's
responsibility to evaluate and verify the operation of any non-IBM product, program, or service.

IBM may have patents or pending patent applications covering subject matter described in this document.
The furnishing of this document does not give you any license to these patents. You can send license
inquiries, in writing, to:

IBM Director of Licensing, IBM Corporation, North Castle Drive Armonk, NY 10504-1785 U.S.A.

The following paragraph does not apply to the United Kingdom or any other country where such provisions
are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES

THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT,
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer
of express or implied warranties in certain transactions, therefore, this statement may not apply to you.

This information could include technical inaccuracies or typographical errors. Changes are periodically made
to the information herein; these changes will be incorporated in new editions of the publication. IBM may
make improvements and/or changes in the product(s) and/or the program(s) described in this publication at
any time without notice.

Any references in this information to non-IBM Web sites are provided for convenience only and do not in any
manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the
materials for this IBM product and use of those Web sites is at your own risk.

IBM may use or distribute any of the information you supply in any way it believes appropriate without
incurring any obligation to you.

Information concerning non-IBM products was obtained from the suppliers of those products, their published
announcements or other publicly available sources. IBM has not tested those products and cannot confirm
the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on
the capabilities of non-IBM products should be addressed to the suppliers of those products.

This information contains examples of data and reports used in daily business operations. To illustrate them
as completely as possible, the examples include the names of individuals, companies, brands, and products.
All of these names are fictitious and any similarity to the names and addresses used by an actual business
enterprise is entirely coincidental.

COPYRIGHT LICENSE:
This information contains sample application programs in source language, which illustrates programming
techniques on various operating platforms. You may copy, modify, and distribute these sample programs in
any form without payment to IBM, for the purposes of developing, using, marketing or distributing application
programs conforming to the application programming interface for the operating platform for which the
sample programs are written. These examples have not been thoroughly tested under all conditions. IBM,
therefore, cannot guarantee or imply reliability, serviceability, or function of these programs. You may copy,
modify, and distribute these sample programs in any form without payment to IBM for the purposes of
developing, using, marketing, or distributing application programs conforming to IBM's application
programming interfaces.

© Copyright IBM Corp. 2005, 2007. All rights reserved. vii

Trademarks

The following terms are trademarks of the International Business Machines Corporation in the United States,
other countries, or both:

Redbooks (logo) ™
developerWorks®
ibm.com®
Access360®
AIX®

The following terms are trademarks of other companies:

Cisco, Cisco Systems, Cisco IOS, PIX, and Catalyst are trademarks of Cisco Systems, Inc. in the United
States, other countries, or both.

Java, JVM, J2EE, Solaris, Sun, and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in
the United States, other countries, or both.

Active Directory, Expression, Internet Explorer, Microsoft, Visual Basic, Windows NT, Windows Server,
Windows, and the Windows logo are trademarks of Microsoft Corporation in the United States, other
countries, or both.

Pentium, Intel logo, Intel Inside logo, and Intel Centrino logo are trademarks or registered trademarks of Intel
Corporation or its subsidiaries in the United States, other countries, or both.

UNIX is a registered trademark of The Open Group in the United States and other countries.

Linux is a trademark of Linus Torvalds in the United States, other countries, or both.

Other company, product, and service names may be trademarks or service marks of others.

DB2 Universal Database™
DB2®
IBM®
NetView®
PartnerWorld®

Redbooks™
Tivoli®
WebSphere®

viii Building a Network Access Control Solution with IBM Tivoli and Cisco Systems

Preface

In February of 2004, IBM® announced that it would be joining Cisco’s Network

Admission Control

offering for the Cisco NAC program in the form of the IBM Tivoli® compliance and
remediation solution. In June of 2005 the first edition of this IBM Redbook was
published.

A number of subsequent updates from Cisco have changed the dynamics of the
Network Access Control market, and have led to significant changes by IBM to
our compliance and remediation solution. Foremost amongst these new
developments are the release of Cisco’s Phase 2 Network Admission Control
architecture, the addition of the NAC Appliance to Cisco’s offerings, and the
addition of Tivoli Configuration Manager as a remediation component of the
overall solution.

While this second edition addresses these changes, the fundamental concept
and business value of the solution remain relatively constant and are preserved
with minimal changes from the first edition. In contrast, the technical and
implementation details have significantly changed and are of great interest to
those who have read the first edition.

It is important to realize what is the compliance and remediation solution. It is not
a one-size-fits-all product that will work out-of-the-box for customers. It is an
integrated solution comprised of three products that are very powerful in their
own right. As such, there is no individual product manual that can properly
capture all of the techniques and practices that must be developed in order to
properly deploy this solution.

(NAC) program. In December of 2004, IBM released its first

A typical product manual is analogous to an automobile owner’s manuals in that
it tells you a wealth of information about your product but it does not tell you how
to apply your product in practice, just as an automobile owner’s manual does not
teach you how to drive or how to navigate. This redbook serves as a high-level
guide for designing and deploying the solution in various business scenarios. It
teaches you how to

Note that the IBM Integrated Security Solution for Cisco Networks, referenced
numerous times in this book, is a portfolio of solutions that also includes Tivoli’s
identity management solution for Cisco network access. This book does not
address the identity-based solution, so any references to the IBM Integrated
Security Solution for Cisco Networks in this book actually refers to the
compliance and remediation parts of the solution.

© Copyright IBM Corp. 2005, 2007. All rights reserved. ix

drive and navigate the compliance and remediation solution.

The team that wrote this redbook

This redbook was produced by a team of specialists from around the world
working for the International Technical Support Organization, Austin Center. The
project was executed at the Cisco Headquarter in San Jose.

Figure 1 Top left to right: Frank, Axel, Vahid, and Mike
Bottom left to right: Vlodek, Markus, and Rich

Axel Buecker is a Certified Consulting Software IT Specialist at the International
Technical Support Organization, Austin Center. He writes extensively and
teaches IBM classes worldwide in Software Security Architecture and Network
Computing Technologies. He holds a degree in Computer Science from the
University of Bremen, Germany. He has 20 years of experience in a variety of
areas related to Workstation and Systems Management, Network Computing,
and e-business Solutions. Before joining the ITSO in March 2000, Axel worked
for IBM in Germany as a Senior IT Specialist in Software Security Architecture.

x Building a Network Access Control Solution with IBM Tivoli and Cisco Systems

Richard Abdullah is a Consulting Engineer with Cisco Systems Strategic

Alliances. Prior to joining Cisco Systems in 2001, he worked in technical
capacities within various service providers. He has spent 19 years in the IT
industry focusing on networking and most recently on network security solutions.
He holds a BSEE degree from the University of Michigan, Dearborn.

Markus Belkin is a Network Architect with IBM Australia. He has worked in the
IT Industry for 10 years and works predominately with Cisco technologies. He
specializes in routing and switching, security and optical technologies. He has an
MCP, MCSE, CCNA, CCDA, CCNP, and CCDP and is currently working towards
his Routing and Switching CCIE.

Mike Dougherty is a Consulting Engineer at Cisco Systems, Inc. in San Jose,
California. He has worked in the industry for 16 years supporting Cisco
networking equipment ranging from routers and switches to security and unified
communication solutions. He obtained his CCIE in Routing and Switching in
1996 and is currently working on his CCIE in Security. Mike is a technical
consultant working in Strategic Alliances under the business development
umbrella at Cisco Systems, Inc.

Wlodzimierz Dymaczewski is an IBM Certified Senior IT Specialist with IBM
Software Group in Poland. Before joining the Tivoli Technical Sales team in 2002
he worked for four years in IBM Global Services where he was a technical leader
for several Tivoli deployment projects. He has almost 13 years of experience in
systems management, recently specializing in security. He holds a degree in
Computer Science from the Poznan Technical University, Poland. Vlodek is a
Certified Deployment Professional for Security Compliance Manager 5.1 and
Risk Manager 4.1 as well as for some Tivoli automation products (TEC,
NetView®, and Monitoring).

Vahid Mehr is a Consulting Engineer with Cisco Systems Strategic Alliances
working on joined architectural solutions with IBM. In his more than 13 years of
experience with Cisco he has been in various customer consulting and alliance
development roles. Prior to this, he was a Software Engineer working on Object
Oriented programming. He has a BSEE from the University of Colorado and
resides in San Ramon, California.

Frank Yeh is a member of the IBM Corporate Security Strategy Team who works
in Costa Mesa, California. He has more than 25 years of computing experience
in a variety of functions including Operations, Support, MIS, Development, Sales,
and Business Development. Prior to joining IBM, Frank served as the Strategic
Architect for Access360®, a pioneer in the Identity Management space that was
acquired by IBM in October 2002. He holds a degree in Economics from the
University of California, Los Angeles.

Preface xi

Thanks to the following people for their contributions to this project:

Cheryl Gera, Erica Wazewski, Lorinda Schwarz, Julie Czubik
International Technical Support Organization, Poughkeepsie Center

Wing Leung, Alex Rodriguez
IBM US

Tadeusz Treit, Bogusz Piotrowski, Anna Iskra
IBM Poland

Cindra Ford, Zary Stahl, Nick Chong, Prem Ananthakrishnan, Brendan
O'Connell, Irene Sandler, Raju Srirajavatchavai, Alok Agrawal, Marcia Hanson
Cisco Systems Inc.

Thanks to following people for working on the first edition of this book:
Wlodzimierz Dymaczewski
Jeffery Paul
John Giammanco
Harish Rajagopal
Hideki Katagiri

Additional support: Tom Ballard, Sam Yang, Mike Garrison, Max Rodriguez, Don
Cronin, Michael Steiner, Jeanette Fetzer, Sean Brain, Sean McDonald
IBM US

Phil Billin
IBM UK

Richard Abdullah, Mike Steinkoenig, Denise Helfrich, Laura Kuiper, Cindra Ford,
Vahid Mehr
Cisco Systems, Inc.

Become a published author

Join us for a two- to six-week residency program! Help write an IBM Redbook
dealing with specific products or solutions, while getting hands-on experience
with leading-edge technologies. You’ll team with IBM technical professionals,
IBM Business Partners, and/or customers.

Your efforts will help increase product acceptance and customer satisfaction. As
a bonus, you’ll develop a network of contacts in IBM development labs, and
increase your productivity and marketability.

xii Building a Network Access Control Solution with IBM Tivoli and Cisco Systems

Find out more about the residency program, browse the residency index, and
apply online at:

ibm.com/redbooks/residencies.html

Comments welcome

Your comments are important to us!

We want our Redbooks™ to be as helpful as possible. Send us your comments
about this or other Redbooks in one of the following ways:

򐂰 Use the online Contact us review redbook form found at:

ibm.com/redbooks

򐂰 Send your comments in an e-mail to:

[e-mail]

򐂰 Mail your comments to:

IBM Corporation, International Technical Support Organization

Dept. HYTD Mail Station P099

2455 South Road

Poughkeepsie, NY 12601-5400

Preface xiii

xiv Building a Network Access Control Solution with IBM Tivoli and Cisco Systems

Summary of changes

This section describes the technical changes made in this edition of the book and
in previous editions. This edition may also include minor corrections and editorial
changes that are not identified.

Summary of Changes
for SG24-6678-01
for Building a Network Access Control Solution with IBM Tivoli and Cisco
Systems
as created or updated on January 16, 2007.

January 2007, Second Edition

This revision reflects the addition, deletion, or modification of new and changed
information described below.

New information

򐂰 The Cisco Network Admission Control Appliance has been added to the

network access control solution.
򐂰 The IBM Tivoli Configuration Manager has been added to the remediation

solution. It replaces the IBM Tivoli Provisioning Manager product.

Changed information

򐂰 A new release of IBM Tivoli Security Compliance Manager is being used

within the security compliance solution.

© Copyright IBM Corp. 2005, 2007. All rights reserved. xv

xvi Building a Network Access Control Solution with IBM Tivoli and Cisco Systems

Part 1

Part 1 Architecture

and design

In this part we discuss the overall business context of the IBM Integrated Security
Solution for Cisco Networks. We then describe how to technically architect the
overall solution into an existing environment, and introduce the logical and
physical components on both the IBM Tivoli and Cisco side.

© Copyright IBM Corp. 2005, 2007. All rights reserved. 1

2 Building a Network Access Control Solution with IBM Tivoli and Cisco Systems

Chapter 1. Business context

Information Technology (IT) security is a vital component of business success
and is very important in e-business security and security for on demand services.
As the Internet increasingly becomes an effective means to conduct business,
the challenge of protecting IT infrastructures from intruders and malicious attacks
increases as well. When an IT resource (server, workstation, printer, and so on)
is connected to a network, it becomes a target for a persistent hacker. Corporate
networks are constantly under attack by intruders seeking access for their
personal gain. In a world where everyone relies on the Internet, it is not difficult
for an intruder to find the tools on the Web to assist in breaking into an enterprise
network. To overcome this immense threat faced by many organizations, a
corporation must identify every user accessing its network and allow access only
to authorized users who are identified and meet

1

corporate compliance criteria.

Every time an intruder successfully breaks into a corporate network or infects
computers with a virus or malicious code, it can cause damage that may result in

substantial financial loss (loss of revenue) to the businesses involved.

Enterprises must defend their IT infrastructure continuously and keep
themselves protected from intruders. One infected server or workstation can
potentially bring the whole corporate network to its knees if it does not comply
with corporate security policies.

© Copyright IBM Corp. 2005, 2007. All rights reserved. 3

Personal computer workstations are used in the office, at home, or at a remote
client location. Telecommuters must use mobile PC workstations to meet
customer expectations and provide quicker response to queries, quotes, and
information.

In this book, we introduce a new concept: a

solution

arena for many years who have established enviable synergy in the industry. This
solution is based on the IBM Enterprise Class Autonomic Computing Model and
the Cisco Self-Defending Network. This new concept provides an integrated
security model that can help an organization protect its reputation by enabling its
network to self-defend. This also enables corporations to proactively secure IT
infrastructure and protect from loss of productivity, loss of revenue, and the
constant battle of escalation due to noncompliance. Every time an auditor finds
an IT resource that is noncompliant, it costs the enterprise a lot of money to fix
(reactive measure) and to regain compliance, which leads to loss of productivity.
Security auditors can even shut down a mission-critical server or deny access to
users if found to be vulnerable due to noncompliance.

The solution discussed in this book addresses corporations’ security concerns by
validating users against a centrally predefined policy before granting them
access to the network. It also provides a path for an automated remediation
process to fix noncompliant workstations quickly (improved productivity).

This solution can be deployed in stages by first targeting the most vulnerable
user community, such as wireless local area network (WLAN) users or a branch
office that is less secure, and then expanding the deployment enterprise-wide.
This concept resolves the human-intensive process that is involved in fixing
infected workstations that do not have antivirus software or the latest antivirus
signature and so on. This concept further helps customers to act proactively in
defending their network by denying access to unauthorized users.

jointly developed by IBM and Cisco Systems, trusted leaders in this

comprehensive integrated security

1.1 The security compliance and remediation concept

IBM and Cisco are working together on this new concept that offers a solution to
companies to defend their network. This solution is called the

Security Solution for Cisco Networks

Manager (SCM) and Cisco Network Admission Control (NAC) integration in this
solution can assist you in safeguarding your IT resources and enables security
compliancy to users. The IBM Integrated Security Solution for Cisco Networks is
a first of its kind in the industry that provides a full cycle self-defending and
automated remediation mechanism to corporate networks. Both Security
Compliance Manager and NAC are independent solutions. Combined, they
complement each other and can provide the best

4 Building a Network Access Control Solution with IBM Tivoli and Cisco Systems

. The IBM Tivoli Security Compliance

self-defending and compliance

IBM Integrated

concept that can protect all networks in this era. This IBM and Cisco integration,

depicted in an overview in Figure 1-1, is a true enabler for the on demand
self-defending and security compliance strategy.

Identity & Access Management

Identifies and manages user profiles

Device characteristics as part of the access decision

Endpoint

Protected client
Trusted identity

Figure 1-1 IBM and Cisco integration strategy

IBM Security Compliance Manager and Cisco Network Admission Control can
help the corporate protect networks by identifying every client and denying
access to the ones who are not identified. Further integrating Security
Compliance Manager and NAC with the IBM Tivoli Identity Management suite
can help corporations keep authorized users compliant with corporate security
through central management of user profiles and policy enforcement.

1.2 Why we need this

Computer virus outbreaks create a dreadful situation for corporate CIOs, who
must regard proactive protection against viruses as constant. The IBM Integrated
Security Solution for Cisco Networks solution provides in-depth defense by
ensuring that authorized users are kept compliant with corporate security policies
and denying access to users who are noncompliant. With the integration of Tivoli
Configuration Manager, the solution can provide a path to an

remediation

again, which can result in

process to help noncompliant users get their workstations compliant

Cisco Self-Defending Network

Identifies, prevents and adapts to threats

Limits damage from viruses and worms

Delivers new system-level threat defense

and identity management capabilities

Compliance & Remediation

Infection identification, containment, and remediation

Policy enforcement

improved productivity.

Endpoint

Protected

servers

automated

Chapter 1. Business context 5

It has become mandatory for businesses to comply with regulatory guidelines
such as the

Services Modernization Act
Portability and Accountability Act

time.

The Gramm-Leach-Bliley Act has provisions to protect consumer information
held by financial institutions. This act provides the authority for federal agencies
to enforce and administer the

Any company with stock that is publicly traded in the United States must comply
with the Sarbanes-Oxley Act, regardless of whether the company’s headquarters
is located in the U.S. This compliancy requirement was enacted to protect
individual investors, and corporations are required by law to provide truthful
financial statements. All public financial statements released by corporations are
subjected to intense scrutiny by regulatory authorities. Hence these legislations
mandate every corporation to maintain the integrity of its own data and provide
the same level of protection to the data it cares for.

Note: More information about the Gramm-Leach-Bliley Act (GLBA) can be
found at:

http://banking.senate.gov/conf/

More information about the Sarbanes-Oxley Act (SOX) can be found at:

http://www.sarbanes-oxley.com

Gramm-Leach-Bliley Act (GLBA; also known as the Financial

), Sarbanes-Oxley Act (SOX), and Health Insurance

(HIPAA). More guidelines may emerge over

Financial Privacy Rule and the Safeguards Rule.

More information about the Health Insurance Portability and Accountability Act
(HIPAA) can be found at:

http://www.cms.hhs.gov/hipaa

These laws are applicable for organizations in the United States of America.
Similar regulations may be enforced by government regulators of other
countries. Customers should consult their relevant government regulatory
bodies to learn more about the applicable laws in their respective countries.

6 Building a Network Access Control Solution with IBM Tivoli and Cisco Systems

Note: Customers are responsible for ensuring their own compliance with

various laws such as the Graham-Leach-Bliley Act, the Sarbanes-Oxley Act,
and the Health Insurance Portability and Accountability Act. It is the
customer’s sole responsibility to obtain the advice of competent legal counsel
regarding the identification and interpretation of any relevant laws that may
affect the customer’s business and any actions the customer may need to take
to comply with such laws. IBM does not provide legal, accounting, or auditing
advice, or represent or warrant that its products or services ensure that the
customer is in compliance with any law.

The IBM Integrated Security Solution for Cisco Networks checks every client’s
workstation when it attempts to connect to the corporate local area network
(LAN) using predefined policies. For example, it can examine whether the
workstation has the latest antivirus signature installed, whether a desktop firewall
is running, whether the password length is correct, and so on. When a
noncompliant client is detected, the IBM Integrated Security Solution for Cisco
Networks quarantines the client by denying access to the corporate LAN and
directing that workstation to either automatically download the latest antivirus
signature or provide information why the workstation is noncompliant. This
provides an opportunity for the user to either manually download the required
updates from the remediation LAN or choose a path to automatically remediate
using IBM Tivoli Configuration Manager.

1.3 Does this concept help our mobile users

The IBM Integrated Security Solution for Cisco Networks by default denies
access to the corporate LAN for all noncompliant users and keeps them at bay.
Enforcing this policy requires every telecommuter’s computer to be compliant
before it is granted access to the corporate LAN.

Corporations must allow external partners and contractors to have access to
limited IT resources as well. Most businesses are looking for ways to remotely
connect to their corporate LAN using a secure virtual private network (VPN)
connection from outside their office premises. The IBM Integrated Security
Solution for Cisco Networks can be configured to allow only partners to connect
to the Internet by using a policy that provides appropriate access to the partners’
workstations that do not have particular client software installed on their
computers. This can be considered a winning situation for both parties involved,
as it provides a network access method without additional infrastructure and yet
assures protection from non-authorized users.

Chapter 1. Business context 7

Standard reports that can be generated from the IBM Integrated Security
Solution for Cisco Networks can be valuable to corporate auditors. These can be
used as artifacts, thereby reducing the effort in checking individual users.
Automated processes can also provide consistency in checking a particular
policy that may be required at certain circumstances. For example, when a new
vulnerability is being publicized a policy can be created and deployed quickly to
direct users to update their workstation and regain compliancy by downloading
and installing a fix using the appropriate remediation process.

1.4 Corporate security policy defined

A corporate security policy should protect the company’s valuable assets and
meet legal obligations. Intellectual properties must not be shared without explicit
written authorization. As we do business with customers, we are required by law
to maintain the confidentiality of the information, privacy of the individual, and so
on. Companies must adhere to government regulations that ensure that
businesses are run legally and ethically without jeopardizing the integrity of the
enterprise. This is fundamental to maintain a trusted relationship between
organizations and customers. Many businesses have outsourced their IT
management to third-party companies; now it is the responsibility of that
company to maintain the data confidentiality and integrity.

Most large corporations have employee guidelines that define how to protect
company assets and conduct business with customers. Each employee is solely
responsible for their actions and has to perform business within the given
framework or guidelines set by the company.

To maintain trust between organizations, security is everyone’s concern without
any exception. Every employee must be empowered to challenge untrusted
entities, such as unauthorized access to information. Hackers use all abilities and
means to access protected data. Physical security alone does not protect data,
as information is available in many shapes and forms. It is of utmost importance
for every employee of an organization to be conscious of corporate security
policies and to adhere to them without exception.

1.5 Business driver for corporate security compliance

Corporations are required to enforce compliance to their policies to maintain a
secure network and allow access only to authorized users, employees, and
external partners. Best practices include:

򐂰 Protect the corporate network from malicious attackers.
򐂰 Keep authorized users compliant with corporate security policy.

8 Building a Network Access Control Solution with IBM Tivoli and Cisco Systems

򐂰 Enable an automated remediation process that eases the process of

regaining compliancy for all authorized users on the corporate network.
򐂰 Provide partners and visitors access to the Internet but not the corporate

intranet.

1.6 Achievable benefits for being compliant

How do organizations benefit from compliance with corporate security policies?

Corporate security policies and controls are established to enforce consistent
rules that centrally secure access to IT resources across the organization. This
also provides consistency in compliance with general business rules. Enforcing
and maintaining strong passwords, for example, can make it more difficult for
malicious users to access protected data.

Corporate auditors check for consistency in compliancy to corporate policies and
look for deviations by individual users. Auditors are always looking for artifacts to
prove that users are compliant. These can be used when the enterprise is being
legally challenged by government regulators.

The following list spells out some tangible benefits to the organization:

򐂰 Increased accuracy of security compliance reporting
򐂰 Reduced effort and costs in data collection and report generation
򐂰 Timeliness of report generation and artifacts as required during security

audits
򐂰 A consistent approach to security compliance reporting across geographically

dispersed organizations

Chapter 1. Business context 9

Figure 1-2 depicts the relevant tasks in a life-cycle overview for endpoint
protection. All of the topics discussed in this chapter are represented at some
point in this life cycle.

Policy Development and Assurance

Asset protection, privacy and reputation protection,

and regulatory compliance

Privacy:
Secure Connectivity & Data

Confidential delivery of
applications, voice,
data, and transactions

Protection:

Threat Defense

Minimize and manage
both known and
unknown threats

devices in accordance

Secure Systems & Networks

Leverage core networking,

software, and systems
capabilities to address

Control:

Trust & Identity

Manage users and

with security policy

Infrastructure:

security issues

Secure Monitoring and Management

Realize security policy through

integrated network, device, and security management

Figure 1-2 Integrated endpoint protection

When an organization is responsible for maintaining and protecting customer
data, it must create measures to ensure policy compliance by all involved
systems on an automated and regular basis. Failure to meet this objective has
resulted in significant exposure and many lawsuits have been lost. It is better to
seem security-paranoid than to be ignorant.

More information about security compliance can be found in the IBM Redbook
Deployment Guide Series: IBM Tivoli Security Compliance Manager,
SG24-6450.

1.7 Conclusion

Organizations are constantly looking to maintain compliance status with their
corporate security policy for both inter-company and intra-company interactions.
Production losses and inefficiencies, and therefore substantial financial losses,
have resulted from noncompliance. Laws and government regulations such as

10 Building a Network Access Control Solution with IBM Tivoli and Cisco Systems

those mentioned in 1.2, “Why we need this” on page 5, mandate every
organization to comply with regulatory acts. Keys to greater productivity include
identifying authorized users and providing them easier access to network and
system resources while keeping them compliant.

The IBM Integrated Security Solution for Cisco Networks delivers corporate
compliance at a reduced cost. The IBM Integrated Security Solution for Cisco
Networks enables organizations to identify users, monitor their compliance, offer
them an easy and centralized remediation capability in case of noncompliance,
and easily route them into appropriate network zones based on their credentials.

IBM and Cisco have recognized inter-company and intra-company security
compliance problems. This approach enables corporations to implement a

simplified, compliance-based full life-cycle Network Admission Control and
remediation solution

of user administration. It also enables the corporate auditors and administrators
to have powerful controls in place for partners and contractors.

It is of utmost importance for every employee in an organization to be conscious
of and in adherence with corporate security policies to provide end-to-end
security across the gamut of IT services. Organizations must provide security
education to all employees and continuously update on a regular basis; every
employee from the CEO on down must comply. Security is the responsibility of

that can result in greater productivity, consistency, and ease

every employee, not just the holder of the security job title.

In the next chapter we introduce the architecture and design methodologies for
the IBM Integrated Security Solution using Cisco Networks.

Chapter 1. Business context 11

12 Building a Network Access Control Solution with IBM Tivoli and Cisco Systems

Chapter 2. Architecting the solution

In this chapter we discuss the solution architecture of the IBM Integrated Security
Solution for Cisco Networks with its compliance-based Network Admission
Control system. We provide an overview of the key modules and their
relationship, and describe an approach for introducing this additional security
layer into the enterprise IT environment.

2

© Copyright IBM Corp. 2005, 2007. All rights reserved. 13

2.1 Solution architectures, design, and methodologies

Our objective for this chapter is not to discuss any general approach for
architecting a security solution; however, we follow the IBM Method for
Architecting Secure Solutions (MASS), which is closely aligned with the Common
Criteria objectives. IBM MASS uses a systematic approach for defining,
modeling, and documenting security functions within a structured design process
in order to facilitate greater trust in the operation of resulting IT solutions. More
information about MASS may be found in the IBM Redbook Enterprise Security
Architecture Using IBM Tivoli Security Solutions, SG24-6014.

2.1.1 Architecture overview

The IBM Integrated Security Solution for Cisco Networks involves several
products and components from IBM and Cisco Systems. In this section, we
present an overview of the solution and define some of the terms used in
subsequent sections and chapters.

Network

Admission

Control

Posture

Validation

Server

Policy

Enforcement

Device

Admission Control

Client

Compliance

Compliance

Server

Compliance Client

(Posture plug-in)

Remediation

Remediation

Server

Remediation

Client

Figure 2-1 IBM Integrated Security Solution for Cisco Network components overview

14 Building a Network Access Control Solution with IBM Tivoli and Cisco Systems

In general, the IBM Integrated Security Solution for Cisco Networks consists of
three subsystems or logical components, as shown in Figure 2-1 on page 14:

򐂰 Network Admission Control (NAC) subsystem based on Cisco technology
򐂰 Compliance subsystem based on IBM Tivoli Security Compliance Manager

򐂰 Remediation subsystem based on IBM Tivoli Configuration Manager

Figure 2-2 depicts all involved subsystems and components in a physical
network representation. It shows the involved stationary and portable clients, the
different network segregations, the server components, and the required
networking equipment.

Mobile Users

(SCM)

Data Center Network

Corporate

ACS

Resources

TCM Server

Web Server

AAA

Internet

SCM Policy Enabled Clients

NAC Enabled Devices

Branch Office

Router

Remote Access Server

Figure 2-2 IBM and Cisco architecture overview

Network Admission Control

Network Admission Control (NAC) is a Cisco-sponsored industry initiative that

uses the network infrastructure to enforce security policy compliance on all

WAN

SCM Server

VPN Wireless Access Point

Remediation VLAN

Corporate VLAN

Quarantine VLAN

Chapter 2. Architecting the solution 15

devices seeking to access network computing resources, thereby limiting
damage from viruses and worms.

Using NAC, organizations can provide network access to endpoint devices such
as PCs, PDAs, and servers that are verified to be fully compliant with an
established security policy. NAC can also identify noncompliant devices and
deny them access, place them in a quarantined area, or give them only restricted
access to computing resources.

NAC is part of the
network intelligence in order to enable the network to automatically identify,
prevent, and adapt to security threats.

Network Admission Control offers the following benefits:

򐂰

Comprehensive span of control – All of the access methods that hosts use to

connect to the network are covered, including campus switching, wireless

access, router WAN links, IP Security (IPSec) remote access, and dialup.

򐂰

Extension of existing technologies and standards – NAC extends the use of

existing communications protocols and security technologies, such as

Extensible Authentication Protocol (EAP), 802.1x, and RADIUS services.

򐂰

Extension of existing network and security software investments – NAC

combines existing investments in network infrastructure and security

technology to provide a secure admission-control solution.

Network Admission Control is a strategic program in which Cisco shares
technology features with approved program participants. Participants design and
sell third-party client and server applications that incorporate these features that
are compatible with the Network Admission Control (NAC) infrastructure.

Network Admission Control can operate at Layer 3 or Layer 2. In Cisco terms,

Cisco Self-Defending Network, an initiative to increase

Layer 3 NAC uses EAP transported on UDP packets and is called EAPoverUDP,

or EOU. In
transported on 802.1x frames and is called EAPoverLAN or EAPOL.

Layer 2 NAC the Extensible Authentication Protocol (EAP) is

16 Building a Network Access Control Solution with IBM Tivoli and Cisco Systems

Note: With the availability of Cisco’s Network Admission Control Appliance

(NAC Appliance) offering, the Network Admission Control subsystem can be
delivered by NAC Framework or NAC Appliance. While the interfaces between
these two offerings vary, the Tivoli Security Compliance Manager and Tivoli
Configuration Manager subsystems are designed to work with either version
of Cisco’s NAC offerings. A minor difference exists in the interface between
Tivoli Security Compliance Manager and the selected Network Admission
Control offering, but all of the policies and remediation objects built for Tivoli
Security Compliance Manager and Tivoli Configuration Manager can be used
interchangeably with either Cisco offering.

Customers have to choose between a NAC Framework and NAC Appliance
implementation because applications that are compatible with a NAC
Framework do not work with an NAC Appliance, as the interfaces are currently
dissimilar. It is Cisco’s stated intention to make NAC Framework and NAC
Appliance solutions compatible, but at the current time, this is not the case.

In most cases, customers who run homogenous Cisco networks and have
long-range NAC plans will be able to start with NAC Framework and deploy in
phases. For customers with heterogeneous networks containing non-Cisco
equipment or customers who wish to start with a smaller entry price and
deployment footprint while still retaining the option to migrate to a full NAC
Framework solution, NAC Appliance is the better choice.

For the purposes of this book, the majority of the content is targeted at NAC
Framework solutions.

Security Compliance Manager

IBM Tivoli Security Compliance Manager performs the functions of managing
security compliance policies and monitoring compliance of clients to these
policies. It plays a vital role in deploying predefined policies and providing a
repository for reporting that can help corporate auditors. The Security
Compliance Manager server has a built-in reporting engine that can be used to
produce standard reports as required by security officers. It can also utilize
external report generators such as IBM DB2® Alphablox or Crystal Reports for
ad hoc reporting.

The relationship between the Security Compliance Manager server and client is
more accurately described as an agent/manager model than a client/server
architecture. The Security Compliance Manager client acts as an agent collecting
data from the client subsystem on a predefined schedule or at the request of the
Security Compliance Manager server and sends the requested data back to the
server. The Security Compliance Manager server acts as a manager issuing
requests to clients and receiving data collections from the client.

Chapter 2. Architecting the solution 17

Port details and communication flows between Security Compliance Manager
server and client can be found in “Security Compliance Manager server and
client” on page 450.

Details of the activities performed by server and client include:
򐂰 Security Compliance Manager server

– Provides an interface for defining complex policies that specify conditions

that should exist on a client.

– Manages

collect what kind of data using the data collection components.

– Determines

interpret the data using the compliance management components.

– Stores the security compliance data received from the clients in a central

database and provides the available data to users through the
administration console and administration commands.

– Provides security violation details as a basis for the compliance report

components.

򐂰 Security Compliance Manager client

– Collects information about its environment required to assess compliance

with the security policy at a predefined schedule. Using different

when the security compliance data is collected and which clients

what security compliance data is collected, and how to

collectors, this data is sent back to the Security Compliance Manager

server. With new
Manager Fix Pack 2, the data is stored locally in a posture cache.

– If enabled for NAC, the client performs a local compliance assessment

using the security policy based on the data from the posture cache. It then
provides the posture assessment data to the Cisco Trust Agent via posture
plug-in for further processing.

– Receives the network admission decision from either the Cisco Secure

Access Control Server (ACS) via Cisco Trust Agent (in case of using the
NAC Framework solution) or the Clean Access Server (CAS) via the Clean
Access Agent (in case of using the NAC Appliance solution) and presents
current status information using a GUI. It displays the compliance status
and posture data, and enables re-initiating the compliance scanning
process.

posture collectors introduced with Security Compliance

– On user request, it can initiate an automated remediation process.

More information about Tivoli Security Compliance Manager can be found in the
IBM Redbook Deployment Guide Series: IBM Tivoli Security Compliance
Manager, SG24-6450.

18 Building a Network Access Control Solution with IBM Tivoli and Cisco Systems

Tivoli Configuration Manager

IBM Tivoli Configuration Manager automates the manual provisioning and
deployment process.

Tivoli Configuration Manager provides an automated software and patch
distribution solution that can also run pre-built scripts on a client, essentially
enabling the Tivoli Configuration Manager solution to install any conceivable
software product on a client as well as change a client’s local settings and state.

This functionality is used to provide the noncompliant workstation with the correct
software and settings using reusable remediation objects.

These remediation objects can be triggered automatically after a client has been
tagged noncompliant by the Security Compliance Manager client policy
evaluation process. This can help an individual client regain its compliance status
and access to the production network without manual interaction and within an
acceptable time frame.

A Tivoli Configuration Manager administrator must pre-define all of the objects
necessary to remediate a noncompliant condition on a client. More information
about Tivoli Configuration Manager can be found in the Deployment Guide
Series: IBM Tivoli Configuration Manager, SG24-6454.

More details of each subsystem and its logical components can be found in
Chapter 3, “Component structure” on page 39.

2.1.2 Architectural terminology

In this section we provide a brief introduction of the terms related to the solution
described in this book, as illustrated in Figure 2-1 on page 14.

Security policy

A security policy, as implemented in Security Compliance Manager, is a
collection of compliance objects or queries. A security policy defines what data
has to be collected on the client (collectors and parameters) and the default
schedule for gathering this data. Security policies can be applied to one or more
client groups. The security policy uses a version attribute, which is required for
the IBM Integrated Security Solution for Cisco Networks. Read more about these
attributes in “Establishing the policy collector parameters” on page 104.

Compliance query

A compliance query, or compliance object, is a single check defined to verify one
particular aspect of the enterprise security policy. Security Compliance Manager
compliance objects are SQL queries extracting data from one or more collector

Chapter 2. Architecting the solution 19

tables that contain data gathered by the collectors. In a generic Security
Compliance Manager deployment, the compliance queries are evaluated on the
server, but with NAC-enabled clients using new posture collectors they can also
be evaluated on the client. A compliance query is written to return a list of policy
violations.

The results of the compliance queries associated with a particular policy can be
used on the Security Compliance Manager server to provide a current picture, or

snapshot, of the level of compliance for all clients in a client group. The results of

the compliance queries evaluated locally on the client are passed as a posture
status. They define the client’s compliance status.

Compliance User Interface

When a client is found to be out of compliance, the Tivoli Security Compliance
Manager Client opens a window that notifies the user of the violation and
provides a means to invoke the remediation process. This user interface includes
a functional Web browser that supports customized HTML content that can assist
the user in remediating. In addition, if an automated remediation handler is
installed, a button to start automated remediation is presented to the user.

Remediation handler

A remediation handler performs the functions of communicating with the
remediation server to download remediation content, installing downloaded
content and providing respective notification to the user.

Network Admission Control process

The following are the conceptual steps of the Network Admission Control
process. Figure 2-3 on page 21 displays the result of what happens to compliant,
noncompliant, and clientless devices.

򐂰 A user tries to connect (remotely or locally) to the corporate network.
򐂰 A Network Access Device (NAD) challenges the client for compliance posture

information.
򐂰 The Security Compliance Manager policy-enabled

the NAC system.
򐂰 The NAC system

rules.
򐂰 The NAC system either admits the client to the network if it complies with all

of the policies or quarantines the client, allowing access only to a remediation

network if the client is not complying with the policies.

20 Building a Network Access Control Solution with IBM Tivoli and Cisco Systems

validates the client’s health (posture) based on predefined

client communicates with

򐂰 If the client is not Security Compliance Manager policy–enabled, it is

access to the corporate network and may be allowed only

the Internet or may be

denied access to all networks.

򐂰 When a client is quarantined, the user is given a choice to either

manually using the provided instructions or to use an

restricted access to

remediate

automated remediation

process by clicking a button on the pop-up window (if the Tivoli Configuration

Manager infrastructure exists).

denied

Untrusted LAN

Healthy

Trusted LAN

Compliant

Remediation LAN

Quarantined

Non-compliant

Remediation

Corporate

Resources

TCM

Server

Denied

Clientless

Figure 2-3 Basic overview of NAC functionality

In general, any admission control solution can base the admission decision on a
number of factors. Authentication decisions are identity-based and the admission
decisions are based on who is attempting access. Posture decisions are
integrity-based and depend on the integrity of the device being used for access.

Posture-based NAC is designed to protect the network from threats introduced by

noncompliant workstations. Workstation-related information is presented to the
authorization server. It describes the current state of the hardware, operating
system, and installed applications (for example, the list of patches installed,
version of installed antivirus or personal firewall software, version of virus
definition file, the date of the last full scan). With Layer 3 NAC, it is not
straightforward to tie the identity-based and posture-based admission decisions
together. Since they operate in two different time frames with regard to network

Chapter 2. Architecting the solution 21

access, this is an acceptable solution. Users are authenticated and placed into a
default network based on their identity. It is not until the user attempted access
across a NAC-enabled router that the integrity check was performed.

With Layer 2 NAC, identity enforcement via 802.1x delivers access control by
checking authorization of the user to connect to the network. The identity can be
verified based on different means, such as user name/password or PKI public
certificates, but more importantly, it allows both identity and posture to be
validated before network access is granted. This allows users to be assigned into
specific networks based on their identity and assigned groups with
posture-based checking, providing an additional way to control a user’s traffic.

SCM
Policy

Laptop computer

SCM
Policy

Desktop Client

VPN

Concentrator

Wireless

Access Point

NAC-

enabled

router

Cisco

Secure

ACS

Server

A A A

SCM
Policy

Intranet

Server

SCM
Policy

Intranet

Server

SCM
Policy

PC Workstation

SCM policy enabled Layer 2 NAC Layer 3 NAC SCM policy enabled

Workgroup Switch

SCM
Policy
Server

IBM SCM Server

Figure 2-4 Layer 3 and Layer 2 NAC overview

Cisco NAC and IEEE 802.1x

An interesting terminology question to ask is: How does this solution relate to the

IEEE 802.1x protocol?

these two solutions can complement each other.

IEEE 802.1x is an identity-based network authentication protocol used at Layer 2
level to allow or disallow a specific user to connect to the network based on user
or machine credentials.

22 Building a Network Access Control Solution with IBM Tivoli and Cisco Systems

In this section we explain the basic difference and how

The IEEE 802.1x standard addresses the need to authenticate the user or client
trying to connect to the particular network. Point-to-Point Protocol (PPP) can be
used in a basic dial-up scenario, but it limits the authentication process to
checking only user and password matching. The Extensible Authentication
Protocol (EAP) was designed to provide transport for other authentication
methods. EAP extends PPP as a framework for several different authentication
methods, such as challenge-response tokens and PKI certificates.

IEEE 802.1X introduces three terms:
Supplicant The user or device that wants to be authenticated and

connect to the network.

Authenticator The device responsible for mediation between client

and authentication server. Typically this is a RAS
server for EAP-over-PPP, or a wireless access point or
switch for EAP-over-LAN.

Authentication server The server performing authentication, typically a

RADIUS server.

IEEE 802.1x was introduced to enable users to use EAP in a consistent way, with
either dial-up or LAN connection. It defines the way an EAP message is
packaged in an Ethernet frame so there is no need for PPP-over-LAN overhead.

On the other hand, Cisco NAC is a posture-based Network Admission Control
solution that enables control of who connects to the network and whether the
client workstation is

healthy and complies with all required security policies.

The Cisco Layer 3 NAC solution implements proprietary extensions to EAP and
uses User Datagram Protocol (UDP) as the transport for EAP (EAP-over-UDP, or
EOU). In Cisco’s Layer 2 NAC offerings, EAP is transported over 802.1x.

Using Cisco terminology

The Cisco Trust Agent performs the role of the supplicant. It provides the
authenticator, which is a NAC-enabled Cisco device, with the client’s posture
statement. The communication is performed using the EAP-over-UDP or
EAP-over-802.1X protocol. On the network device, the EAP header is
repackaged into RADIUS and sent to the Cisco Secure ACS server (performing
the role of an authentication server).

The main difference between IEEE 802.1x and the Cisco implementation lies in
the authentication process:

򐂰 With generic IEEE 802.1x, the EAP header carries only identity information,

and authentication is performed using credentials provided by the supplicant.

Chapter 2. Architecting the solution 23

򐂰 In the Cisco NAC solution, the EAP header is extended with posture data and

the admission process is based on policies governing the network admission

decision. Those policies consider all of the attributes provided by the posture

agent (Cisco Trust Agent) to determine the client’s health and security

compliance status.

򐂰 In the generic 802.1x, the identity credential is used for authentication.
򐂰 In the Cisco NAC solution, the posture credential of the client device is used

for authentication.

IEEE 802.1x and NAC can be combined easily to provide a stepped-up level of
security in corporate networks. The selected authentication and network
admission protocols will determine which client software or supplicants are
loaded on the client.

Note: In this section we used the term authentication to discuss the
differences and similarities between IEEE 802.1x and the Cisco NAC process.

Regarding 802.1x, we can accurately speak of authentication because we are
considering individuals providing credentials to gain access to protected
resources. In the Cisco NAC process we examine a posture status of a client
machine in order to grant general network access — a process not usually
considered an authentication.

Posture agent

The posture agent is a software agent residing on the client capable of
communicating with the NAC-enabled network device before the client is granted
network access. It aggregates security posture information from the
NAC-compliant applications running on the network client and sends it to the
posture verification server. In the present solution, the role of the posture agent is
performed by Cisco Trust Agent. Third-party applications including the IBM Tivoli
Security Compliance Manager client register with the posture agent using a
plug-in. More information can be found in 3.2.1, “Network client” on page 52.

Network identity provisioning

With the posture-based Network Admission Control, the client requires a set of
software components to be able to connect to the network. It is feasible to assign
different security policies to the different groups of clients and check for
compliance with complex rules concerning all of the clients’ attributes. However,
all clients running the same version of an operating system, for example, typically
are unified in terms of which security policy applies for these clients. Looking at
the generic design, the NAC solution makes no differentiation between who the
clients belong to or who is actually trying to connect to the network.

24 Building a Network Access Control Solution with IBM Tivoli and Cisco Systems

This requirement can be fulfilled by providing each user with a unique identity
and verifying it even before the posture condition of a client is checked. This
process was standarized with the IEEE 802.1x protocol, and IBM provides the
solution to facilitate it. IBM Tivoli Identity Manager delivers a flexible provisioning
engine to create and manage user accounts on the Secure Access Control
Server. For more information, contact your IBM representative.

Remediation process

The remediation process, either HTML-assisted or automated, is an integral part
of the IBM Integrated Security Solution for Cisco Networks. The role of this
process is to provide the noncompliant client with a means to become compliant
again and thus providing access to the network.

The remediation process is facilitated by the following components:
򐂰 Remediation handler

The

remediation handler initiates the remediation process. It receives the list

of noncompliant settings from the compliance client, then asks the

remediation server to provide the new software or the correct settings as

required by the security policy. In the presented solution, each compliance

check performed by the compliance agent is associated with a related

remediation object that is capable of correcting the client posture if it is not

compliant.
򐂰 Remediation server

The

remediation server provides the approved compliant settings templates

for the clients. It listens to the clients’ requests and responds to them. The

response may include a number of elements, for example:

– Installing the software package on the client
– Starting or stopping a service on the client
– Changing software settings on the client

򐂰 Remediation object

The

remediation object includes the required software and scripts required for

the client to become compliant again. For example, the object for recovering

from an outdated virus definition file would include the new virus definition file

and would automatically install it.

Depending on the conditions and security policy requirements, objects can be

more or less complex.

Chapter 2. Architecting the solution 25

2.2 Definition of a Network Admission Control project

Objectives of a Network Admission Control solution must be carefully planned
because the result of having a large number of workstations quarantined may be
more disruptive to the business than a particular virus attack.

Planning the Network Admission Control is an organizational challenge for most
enterprises as it requires close cooperation among different groups of people in
different roles, typically not closely related:

򐂰 Security officers responsible for the formal audit and compliance process
򐂰 Network administrators responsible for configuration of network devices
򐂰 Administrators responsible for everyday PC configuration and maintenance

It is essential to follow these steps in the implementation of the IBM Tivoli
Security Compliance Manager and Cisco Network Admission Control:

򐂰 Creation of the policies to meet the business requirements and needs
򐂰 Building the policies on the compliance server
򐂰 Deploying the clients with the required software and initial policy
򐂰 Defining and implementing the remediation process
򐂰 Preparing the network infrastructure
򐂰 Turning on the security compliance enforcement

2.2.1 Phased rollout approach

Enforced Network Admission Control solutions are new to the industry and are
not yet widely adopted so the phased approach to rollout is highly recommended.

In the first phase the most vulnerable network segments should be selected.
These networks can be selected based on network topology knowledge or on the
statistics from threat monitoring software.

NAC planning and deployment may be combined with the process of deploying
wireless networks, along with IEEE 802.1x authentication.

26 Building a Network Access Control Solution with IBM Tivoli and Cisco Systems

Figure 2-5 illustrates a possible NAC deployment scenario.

Branch Office

AAA Server (ACS)

EAP/UDP

1

Branch

Router

Internet

EAP/UDP

Mobile
Users

4

4

Campus FW Edge Router

2

3

Dial-in

NAS

EAP 802.1x (wired)

RA IPsec

VPN

6

RADIUS

(posture)

SCM

Server

5

EAP 802.1x

(wireless)

Corporate

Network

Figure 2-5 NAC deployment scenario

Typical candidates for NAC protection are networks (both wireless and wired)
used by the mobile users to connect to the intranet while visiting the office [1], as
well as the dial-up and VPN networks used to connect remotely [2,3]. (Especially
in a dial-up and VPN environment, NAC enables posture control of the users
(clients) connecting to the intranet where the other methods of enforcing
compliance are limited.) In the next step, all branch office networks [4] can be
protected with NAC. Finally, the solution can be extended to cover all wireless
networks [5] and the stationary networks in the main campus [6].

A second factor strongly influencing project scope is the availability of automated
remediation. As the number of quarantined clients increases, the number of help
desk calls grows, raising the total cost of ownership (TCO) for the solution.

Chapter 2. Architecting the solution 27

2.3 Design process

The MASS methodology that we follow in this book includes the following steps of
the design process:

1. Model business process.

2. Establish security design objectives.

3. Select and enumerate subsystems.

4. Document conceptual security architecture.

We now walk through these steps.

2.3.1 Security compliance management business process

Figure 2-6 illustrates the security compliance management business process,
which is described in detail in the redbook Deployment Guide Series: IBM Tivoli
Security Compliance Manager, SG24-6450.

System

System

administration

System

administration

administration

5. Correct
settings

Servers

4. Report
deviations

7.Request
exceptions

Security Audit Team

3. Document health
check and deviations

9. Document accepted
deviations

2. Check control
settings and compare to
Security Policy

6. Report compliance status

8. Ask for risk accaptance

Management

Security

Policy

1. Apply security
policy

Authority

Figure 2-6 Generic security compliance management business process

The security compliance management business process consists of these
general steps:

1. Apply security policy.
The first step in setting up a health check process is to make sure that the

required security control settings of the enterprise security policy are audited.

28 Building a Network Access Control Solution with IBM Tivoli and Cisco Systems

2. Check control settings and compare to security policy.
The audit team periodically checks the systems to be sure their settings are in

compliance with the policy. The audit team creates a report listing all
controlled systems and the violated controls. Periodically the list also has to
contain the complete security control settings and the systems that are
controlled.

3. Document health check and deviations.
The audit team archives the health check results documenting that the health

check was performed according to the security policy.

4. Address deviations.
The audit team has to inform the system owners and administrators about the

health check process findings. Usually a list of deviations is handed over that
specifies a target date for correcting the discrepancies.

5. Correct settings.
The system administrators usually test the corrective actions in a test

environment, verify that the system functions are not affected, and deploy the
changes to the production environment.

6. Report compliance status.
The audit team creates security compliance status reports for management

and external audit purposes on a regular basis.

7. Request compliance exceptions.
System administrators who come across security settings that affect the

functionality of a system might request compliance exceptions. They ask the
audit team whether the violation of a security control can be tolerated for a
certain amount of time.

8. Ask for risk acceptance.
When asked for compliance exceptions, the audit team will negotiate a risk

acceptance with the management team. Usually, the risk acceptance is
temporary until there is a secure solution for the IT system.

This process was designed for managing server compliance, where a typical
environment includes a variety of different configurations, platforms, and
applications. In a server environment, the number of application-specific
deviations can be large and the change management process is required to
correct any noncompliance.

On the other hand, in the typical workstation environment, all clients tend to be
unified in terms of security settings, and the remediation process can be
automated to enable faster accommodation to respond to security threats and
avoid network infection.

Chapter 2. Architecting the solution 29

The security compliance process for desktops and mobile clients can be
simplified to look like this:

1. Apply security policy.
The first step in setting up a health check process is to make sure the

required security control settings of the enterprise security policy are audited.

2. Check control settings and compare to security policy.
With the NAC in place the health check audit is automated and takes place

every time the client connects to the network. This approach is very efficient
in terms of protecting the network. However, additional security means may
be required to protect the clients themselves (and information that they may
contain) when they are operating outside the corporate network.

3. Address deviations.
The system owner has to be informed about the findings of the health check

process. Usually a list of deviations is presented to the user in a pop-up
window and the noncompliant workstation is refused access to the corporate
intranet.

4. Correct settings.
As the configuration of the client tends to be unified and is regulated by a

separate policy, there is no need to test the changes on every client. All
requested changes should be applied as soon as possible either through the
manual process according to designated instructions or in an automated way.

5. Report compliance status.
The audit team creates security compliance status reports for management

and external audit purposes on a regular basis. These reports document the
number of noncompliances found, the progress of the new policy deployment,
and so on.

2.3.2 Security policy life cycle management

In any organization, Information Technology resources are very important assets
that are critical to business success and must be protected from unauthorized
users without sacrificing integrity, availability, and confidentiality. Organizations
must keep their IT security policies current and assess compliance regularly.
Conducting regular security-education sessions for employees is a good idea.

The most important aspects of a security policy are identifying a threat,
assessing the risk associated with it, providing means to protect critical data, and
maintaining integrity and confidentiality without any compromise. Security policy
creation is an ongoing process; all policies require constant review and
amendment as necessary to suit the organization’s business model. If for some

30 Building a Network Access Control Solution with IBM Tivoli and Cisco Systems

reason a policy cannot be complied with due to a particular business need, the
situation has to be accepted as a security risk for a well-defined period of time
and signed off by the project sponsor.

A policy that is created but is not enforced is no better than no security policy at
all. This situation can expose the organization and put its credibility at stake.

We discuss more details of the full policy life cycle in the following sections.
Figure 2-7 depicts the single steps in the security policy life cycle management
process.

Security Policy Creation

Figure 2-7 Security policy life cycle diagram

Security Policy

Implementation in the

environment

Grace Period

Creation

Chapter 1, “Business context” on page 3, discussed business reasons for having
security policies in place. At this point we want to mention only that for the
automated audit most of the policies have be operationalized. For example, the
policy statement (such as “Each workstation connected to the corporate network
should have all of the latest recommended security patches applied”) must be
translated into a detailed list of all patches and hotfixes required for each
operating system type.

This process is described in detail in the IBM Redbook Deployment Guide
Series: IBM Tivoli Security Compliance Manager, SG24-6450.

Implementation

Establishing and implementing the policy in the environment typically are two
separate processes involving different business units. IBM Tivoli Security
Compliance Manager is an audit tool for automated verification of compliance. As
part of the security audit process, it is not designed to perform any changes to
the configuration of audited systems.

Security Policy

Enforcement

Security Policy

Review and update

Chapter 2. Architecting the solution 31

This means that for each desired change in the configuration settings, there must
be an appropriate configuration change process in place to perform the changes
on the afflicted systems. For example, if there is a security policy stating that
each workstation must have antivirus software installed, there has to be a
corresponding software installation process to distribute it to clients consistent
with this policy.

Depending on the size of the environment, this can be achieved in a number of
ways: fully automated, manually, or in some way in between. Depending on the
type of policy, a different grace period for the implementation may be granted.

Enforcement

Before introducing the IBM Integrated Security Solution for Cisco Networks to the
corporate environment, the only way to enforce the security policy as a client
connected to the network was to perform a periodic audit of the configurations on
individual user PC workstations. This was very ineffective and costly, the process
was resource-intensive, and the results were not satisfactory. With the
introduction of the IBM Integrated Security Solution for Cisco Networks, any
noncompliant clients trying to connect to the network can be denied access to
corporate resources or quarantined (that is, they are allowed to connect to only
one designated network for remediation) until the workstation regains a
compliant state according to the policies.

Review and update

As the IT environment and business requirements may change frequently, the
security policy should be reviewed periodically and updated to reflect current
security threats and business goals.

Updating the policy requires special attention because a
value checked by the posture validation server in the IBM Integrated Security
Solution for Cisco Networks. It is an important architectural decision whether
clients with an outdated policy version should be admitted access to the
compliance server to be updated or if first they should be updated using a
remediation process and then, only if compliant, allowed to further access the
network. This second approach is more secure, but it requires the automated
remediation process to be operational.

policy version is the first

2.3.3 Solution objectives

Several business drivers for the IBM Integrated Security Solution for Cisco
Networks were described in 1.2, “Why we need this” on page 5. Each particular
implementation may require all drivers to be in place or just a subset, so the
selected objectives should be documented. The solution objectives will
eventually drive most of the architectural decisions in the design process.

32 Building a Network Access Control Solution with IBM Tivoli and Cisco Systems

2.3.4 Network design discussion

In this section we discuss the following network design factors for the IBM
Integrated Security Solution for Cisco Networks:

򐂰 Network segmentation via VLANs and downloadable IP ACLs
򐂰 Performance
򐂰 Adding new components that may not have been required previously

The IBM Integrated Security Solution for Cisco Networks introduces new zoning
terminology for intranet networks:

Default network These are the network segments or virtual LANs

(VLANs) to which clients are connected. Each client will
be placed in a default network when they have been
successfully admitted to the network.

Quarantine access This defines the resources that quarantined clients can

access. These resources may be placed anywhere
within the network but must be reachable by hosts that
are in quarantine. Typical resources that are available
while in quarantine are the remediation server, the
compliance server, and public internet. In general,
access to trusted networks is not allowed while in
quarantine except in cases where the remediation or
compliance servers are deployed within trusted
networks.

Trusted network These are the parts of the network where the corporate

resources are placed — domain servers, application and
database servers, print servers, and so on. These
network segments typically are not NAC-enabled as
separate business processes govern the security
compliance and configuration changes for servers.
These segments are also not considered to be the
serious source of threats to the rest of the network.

Default network

With Layer 3 NAC only networks connected to NAC-enabled routers can be
isolated from other parts of the network. If existing network equipment has to be
reused it may limit the number of possible untrusted network segments.

It is also important to realize that it is possible for a noncompliant client to
connect to (and possibly harm) other clients connected to the same network
segment. This limitation is addressed by Layer 2 NAC that can operate at
network protocol layer 2 on switches, wireless access points (WAP), and virtual
private network (VPN) concentrators.

Chapter 2. Architecting the solution 33

In the reference architecture described later in this book, there are several
untrusted networks that are the default networks to which users are assigned
based on their identity-based authentication. When clients are in a healthy state,
they should be placed in the default network based on the user’s identity.

Quarantine access

We use this term to refer to the necessary network resources that a quarantined
client needs to access. Network access is governed by the content of an

control list

connected, and this ACL may include several particular IP addresses required for
remediation.

Depending on the solution design, remediation resources may include:

򐂰 Remediation server
򐂰 Compliance server
򐂰 Software distribution depot
򐂰 Internet access proxy

(ACL) applied to the router or switch port to which the client is

access

Trusted network

In a real world scenario this term is used for static, internal network segments
where no clients are physically connected. In this book, we consider as trusted
any network segment that is excluded from the NAC. Of course, other security
means such as firewalls may still apply, but this outside the scope of this book.

Performance controls

Network admission control introduces the two timing parameters used to control
solution behavior:

Revalidation period Defines how often the whole NAC procedure will be

repeated for clients that are already connected.

Status query period Defines how often the posture agent is asked by the

NAC router for changes in the posture. This second
type of polling enables us to initiate a revalidation
process if the client posture changes significantly (for
example, if the user stops or disables an essential
service required in the policy).

Depending on those settings the policy enforcement may be more or less rigid,
but they also influence the end-user experience and network performance.

The revalidation process enables the client to pick up changes in a security policy
version if no other distribution way is defined. However, as a result of the NAC
process, a user connecting to the network is presented a pop-up window with the
current status (Healthy, Quarantined, Checkup, Infected, or Unknown). If the

34 Building a Network Access Control Solution with IBM Tivoli and Cisco Systems

revalidation process takes place too often, this pop-up window may become
annoying and significantly lower the user’s productivity. The recommended value
is 14400 seconds (4 hours) or more.

The router or the
the current policy compliance status changes. This activity introduces additional
network traffic, which becomes larger as the defined time intervals shorten.
However, frequent polling enables quick disconnection from a client that
becomes noncompliant from the network. Depending on the network architecture
(number of clients connected to one NAD, network bandwidth, current network
load, and so on) the status query period should not be shorter than 30 seconds.

network access device (NAD) periodically queries the client for

2.4 Implementation flow

IBM best practice in implementation of this concept in an enterprise-wide
deployment has been identified by the following project phases that would assist
in a smooth transition to the new environment:

򐂰 Initiation
򐂰 Definition
򐂰 Design
򐂰 Build
򐂰 Maintenance

In the

initiation phase, high-level project requirements are gathered and verified

to be included in the Statement of Work (SoW) document.

During the
detail, and as a result several of the documents are created, including

Definition Report

definition phase, those requirements are refined and documented in

(PDR), functional specification, and existing system analysis.

Project

In the

design phase, the detailed design of the solution is created, typically in the

form of architecture and design documents covering macro and micro design
studies. Then the solution is actually implemented in the

The final stage is
environment or business requirements change. This typically is a cyclic process
as described in 2.3.2, “Security policy life cycle management” on page 30.

maintaining and updating the solution as the surrounding

2.5 Scalability and high availability

Any architecture must be easily scalable and available at all times for secure and
reliable business transactions and the future growth of the business. This

Chapter 2. Architecting the solution 35

build phase.

particular security compliance concept is aimed at validating client access to the
corporate network, so it is mandatory that the system is available at all times.

As mentioned in Chapter 1, “Business context” on page 3, this concept can be
deployed in stages, first targeting the most vulnerable user group (such as WLAN
users) or a branch office, which may have a security exposure, and then being
deployed across the whole enterprise. This concept is flexible, can be
implemented with minimum required equipment, and can be scaled up to
become a high-available solution as business demands.

If an existing infrastructure has all of the required components for Cisco Network
Admission Control already in place, only a Tivoli Security Compliance Manager
server and clients are to be deployed. This both protects the investment and
provides an avenue to obtain additional benefits from the existing infrastructure.
Similarly, if a Tivoli Security Compliance Manager server has already been
deployed for server compliance control, it will be easier to use the existing
Security Compliance Manager server and extend this concept to desktop
workstations.

It is recommended that when this concept is deployed enterprise-wide, adequate
redundancies for individual components are put in place. For example, a NAC­enabled Cisco router (Network Access Device) utilizes a secondary router that is
configured in a redundant pair using
Cisco Secure Access Control Servers are configured as a redundant pair in
Active-Active or Active-Standby mode. These different devices and applications
are explained in more detail in 3.1, “Logical components” on page 40.

Hot Standby Routing Protocol (HSRP), and

If an organization has already deployed a Cisco Secure ACS v3.3 server for
TACACS+ use, the same server can be utilized for the IBM Integrated Security
Solution for Cisco Networks concept, thus safeguarding the existing investment.
The size of your infrastructure load may become an issue for your Cisco Secure
ACS. The Server will require an upgrade to Release 4.0 or later to support
Layer 2 NAC.

Based on initial deployments, a single Security Compliance Manager
Server V5.1 is capable of handling approximately 10,000 concurrent desktop
clients. For the IBM Integrated Security Solution for Cisco Networks, the Security
Compliance Manager server is not mission critical. It is required only for policy
deployment and reporting.

For the manual remediation process, an existing infrastructure may be utilized
(such as a download or update server that may be Web-based) for fixes and
patches. Tivoli Provisioning Manager can be used to assist in the automation of
the remediation process, taking advantage of its workflow capability.

36 Building a Network Access Control Solution with IBM Tivoli and Cisco Systems

Part 2, “Customer environment” on page 75, details a comprehensive
deployment scenario.

2.6 Conclusion

In this chapter, we discussed the architecture and design principles for the IBM
Integrated Security Solution using Cisco Networks. The overall architecture
encompasses several components from IBM and Cisco, with integrated systems
that complement each other by providing the first industry compliance-based
Network Admission Control system with automated remediation capabilities.

The focus of this chapter was to introduce a description of functionality provided
by the IBM Integrated Security Solution for Cisco Networks and how the IBM
Tivoli products and Cisco NAC are integrated. We also discussed the high-level
architecture and building blocks for the overall solution.

Designing the IBM Integrated Security Solution for Cisco Networks is a
multi-phase process involving at least three groups of IT personnel. It is
important to understand that this concept may have substantial influence on
users’ experience and productivity, especially during the project rollout.

In the next chapter we provide the detailed description of the logical and physical
components of the IBM Integrated Security Solution for Cisco Networks.

Chapter 2. Architecting the solution 37

38 Building a Network Access Control Solution with IBM Tivoli and Cisco Systems

Chapter 3. Component structure

This chapter introduces the logical and physical components of the IBM
Integrated Security Solution for Cisco Networks. The final section of this chapter
talks about the logical data flow among the various components to better
understand dependencies and component placement within the network.

3

© Copyright IBM Corp. 2005, 2007. All rights reserved. 39

3.1 Logical components

The IBM Integrated Security Solution for Cisco Networks detects the state of
network clients and compares it with a set of centrally defined and managed
policies to establish client postures. It then dynamically reconfigures the network
based on detected client postures and changes the state of devices to be in
compliance with defined policies. This solution is an integration of products from
IBM and Cisco. The IBM products focus on the aspects of compliance and
remediation, and the Cisco products provide the Network Admission Control
(NAC) and policy validation components.

This new integrated solution includes a set of policies and workflows that address
certain well-known conditions such as operating system levels, hotfixes, and
security and policy settings. These policies and workflows can be configured to
address new instances of these conditions. The IBM Integrated Security Solution
for Cisco Networks is an extensible offering that provides the ability to create new
policies to detect various combinations of device postures and workflows that
can remediate various states on these devices. This can provide you with the
flexibility to define polices that are unique to your environment.

The solution integrates three major independent logical components or
subsystems with add-on components specifically developed for the IBM
Integrated Security Solution for Cisco Networks, depicted in Figure 3-1.

Client

Components

Network

Admission

Control

Posture

Validation

Server

Policy

Enforcement

Device

Admission Control

Client

Compliance

Compliance

Server

Compliance Client

(Posture plug-in)

Figure 3-1 Solution logical block diagram

40 Building a Network Access Control Solution with IBM Tivoli and Cisco Systems

Remediation

Remediation

Server

Remediation

Client

The logical components are:

򐂰 Network Admission Control
򐂰 Compliance
򐂰 Remediation

The following sections provide function and architecture details for each
component.

3.1.1 Network Admission Control

Network Admission Control (NAC) is the Cisco component of the solution that
provides enforcement by restricting traffic based on the client's posture. Cisco
NAC can be implemented via NAC Framework or NAC Appliance. NAC
Framework provides NAC functionality within the infrastructure, posturing at the
network access device, where as NAC Appliance provides posturing on an
appliance. Both NAC Framework and NAC Appliance can be integrated
simultaneously into the network. An overview introducing the concepts of NAC
Framework and NAC Appliance can be found in Appendix B, “Network Admission
Control” on page 471.

Network Admission Control Framework

The Network Admission Control Framework consists of the following
subcomponents:

򐂰 Posture validation server
򐂰 Policy enforcement device
򐂰 Admission control client

Posture validation server

The posture validation server validates the client posture against network access
policy. In our solution the Cisco Secure Access Control Server (ACS) acts as the
posture validation server. The Cisco Secure ACS performs these functions:

򐂰 It enables administrators to create polices that are used as validation criteria

for clients trying to access the network.

򐂰 It validates the security posture credentials received from a client machine.

The validation process compares the client’s current posture with a
predefined desired posture.

򐂰 It forwards the appropriate network access policy for the client to a network

access device, such as a switch, router, VPN concentrator, Adaptive Security
Appliance or access point, to restrict traffic flow based on the client’s posture.

The Cisco Secure ACS is an
server that provides a centralized authentication and policy deployment platform

authentication, authorization, accounting (AAA)

Chapter 3. Component structure 41

for network devices and other services. The various components that constitute
the ACS and a brief description of their functions are discussed here.

The ACS architecture consists of seven services bundled within ACS. Figure 3-2
shows the internal ACS components and their functions.

Function

Administration

Authentication

External DB

sync

Logging

TACACS

communication

RADIUS

communication

Monitoring

Figure 3-2 ACS architecture

Service

CSAdmin

CSAuth

CSDBSync

CSlog

CSTacacs

CSRadius

CSMon

Here are brief explanations for the ACS services:

CSAdmin Provides an HTML interface for administration of ACS
CSAuth Provides authentication services
CSDBSync Provides synchronization of the internal ACS user database

with third-party external RDBMS applications

CSlog Provides logging services both for accounting and system

activity

CSTacacs Provides communication between TACACS+ AAA clients and

the CSAuth service

CSRadius Provides communication between RADIUS AAA clients and

the CSAuth service

CSMon Provides monitoring, recording, and notification of ACS

performance and includes automatic response to some
scenarios

42 Building a Network Access Control Solution with IBM Tivoli and Cisco Systems

Note: For more information about the ACS architecture and administration

refer to the ACS user guide and ACS administration guides at the Cisco Web
site:

http://www.cisco.com/en/US/products/sw/secursw/ps2086/tsd_products_support_s
eries_home.html

Policy enforcement device

Clients access enterprise resources via the network which makes it an effective
point to validate system posture prior to allowing access to such resources. In the
NAC solution, policy enforcement is accomplished using a network access
device that has the NAC feature set enabled in Cisco IOS (Internetworking
Operating System). The network access device also acts as a client to ACS
which provides it with direction on how to handle connected devices.The
functions of policy enforcement devices are:

򐂰 The NAD demands endpoint posture

client through a client software component. This information is relayed to ACS
for an admission decision.

򐂰 Based on appropriate network access policy provided by ACS, the NAD

permits, denies, or restricts the network access of the network client.

򐂰 The NAD also checks for a change in posture of the client by polling the client

at specified intervals.

credentials from the network-attached

Admission control client

The Cisco Trust Agent is a specialized application that runs on network clients. It
collects security posture information from the NAC-compliant applications that
are installed on network clients and reports the posture information to a posture
validation server, which is the Cisco Secure ACS. For the IBM Integrated Security
Solution for Cisco Networks, the posture information is provided by the Tivoli
Security Compliance Manager client. Based on the reported security posture, the
network client is either permitted, denied, or allowed restricted access to the
network.

Chapter 3. Component structure 43

Figure 3-3 shows the Cisco Trust Agent architecture, followed by a brief
explanation of the components that make up the Cisco Trust Agent.

Client Application

(EXT-Service)

EXT-Service

Posture-Plug-in

Application supplied

Posture Credential

Providers

Logging

Service

EAP

Methods

Cisco Trust Agent

Service

NAD

Device

Posture

Plug-in

Figure 3-3 Cisco Trust Agent architecture

Cisco Trust Agent service Responds to network requests for client system

posture information.

Logging service

Logs event information received from Cisco Trust
Agent components and from NAC-compliant
applications into log files.

Posture plug-in Provides the capability to collect information such as

operating system type and version.

EXT-Posture plug-in Represents an external or third-party posture

plug-in. This is a communication path provided by
Cisco Trust Agent software to enable system
integrators to pass posture information to the Cisco
Trust Agent. For IBM Integrated Security Solution for
Cisco Networks, an IBM-developed posture plug-in
communicates with Cisco Trust Agent and provides
posture credentials.

44 Building a Network Access Control Solution with IBM Tivoli and Cisco Systems

EAP methods Provide a mechanism to authenticate the application

or device requesting the host credentials, and
encrypts or decrypts that information.

Network Admission Control Appliance

The Network Admission Control Appliance consists of the following
subcomponents:

򐂰 Clean Access Manager (CAM)
򐂰 Clean Access Server (CAS)
򐂰 Clean Access Agent (CAA)
򐂰 Clean Access Policy Updates

Clean Access Manager (CAM)

The Clean Access Manager is the administration server and database that
centralizes configuration and monitoring of all Clean Access Servers, users, and
policies in a Cisco NAC Appliance deployment. The Web admin console for the
Clean Access Manager is a secure, browser-based management interface. For
out-of-band (OOB) deployment, the Web admin console provides the Switch
Management module to add and control switches in the Clean Access Manager's
domain and configure switch ports.

Clean Access Server (CAS)

The Clean Access Server is the gateway between an untrusted and a trusted
network. The CAS enforces the policies you have defined in the CAM Web admin
console, including network access privileges, authentication requirements,
bandwidth restrictions, and NAC Appliance system requirements. It can be
deployed
traffic only during authentication/posture assessment). It can also be deployed in
Layer-2 mode (users are L2-adjacent to CAS) or Layer-3 (users are multiple L3
hops away from the CAS) mode.

in-band (always inline with user traffic) or out-of-band (inline with user

Clean Access Agent (CAA)

When enabled for your Cisco NAC Appliance deployment, the Clean Access
Agent can ensure that computers accessing your network meet the system
requirements you specify. The Clean Access Agent is a free, read-only,
easy-to-use, small-footprint program that resides on user machines. When a user
attempts to access the network, the Clean Access Agent checks the client
system for the software you require, and helps users acquire any missing
updates or software.

Agent users who fail the system checks can be assigned to the
This role gives users limited network access to the resources needed to comply
with the Clean Access Agent requirements. Once a client system meets the
requirements, it is considered

clean and allowed network access.

Chapter 3. Component structure 45

temporary role.

Clean Access Policy Updates

These are regular updates of pre-packaged policies/rules that can be used to
check the up-to-date status of operating systems, antivirus (AV), antispyware
(AS), and other client software.

3.1.2 Compliance

Tivoli Security Compliance Manager, a a client/server-based policy compliance
solution, supports the definition of policies that specify conditions that should
exist on a client, detects the state of these conditions and stores the collected
current state information on the server. Security Compliance Manager collectors
are written to evaluate system data and state information. Collectors can be
written to evaluate virtually any system parameter.

Compliance server

The server is the central component of a Security Compliance Manager
infrastructure. The server’s responsibilities include:

򐂰 Creating and deploying new policies
򐂰 Determining what security compliance data is collected and how to interpret

the data using the compliance management components

򐂰 Managing security compliance data collection frequency and grouping of

policies for different types of user groups

򐂰 Storing the security compliance data received from the clients and providing

the available data to users through the administration console and
administration commands

򐂰 Providing security violation details as a basis for the compliance report

components

46 Building a Network Access Control Solution with IBM Tivoli and Cisco Systems

Figure 3-4 depicts Security Compliance Manager’s high-level component
architecture, followed by a brief explanation.

Compliance Report

Components

Operational

SCM

Database

SCM

Collector

Firewall

SCM

Report

SCM

Snapshots

Compliance Evaluation

Components

SCM

Policies

Router

SCM

Admin GUI

Administration

Components

SCM

Admin CLI

Windows Registry

Configuration

File

SCM

Report

SCM Client

SCM

SCM

SCM

Collector

Collector

Collector

Executable

SCM

SCM

Server

Server

Data Collection

Components

SCM Proxy

SCM Client

SCM

Collector

Figure 3-4 IBM Tivoli Security Compliance Manager logical component architecture

Figure 3-4 shows:
Administration components Consist of a graphical user interface and a

command line interface (CLI). Used to manage
the Security Compliance Manager components.

Data collection component Build a framework for collecting security-relevant

configuration data from connected systems such
as operating systems, middleware components,
applications, firewalls, routers, and so on.

Compliance reporting Deliver different kinds of configurable reports for

audit purposes and correcting deviations.

Chapter 3. Component structure 47

Compliance evaluation Consisting of Security Compliance Manager

snapshots and policies, these components
centrally verify security compliance.

Note: You can find more details about these components in the IBM Redbook
Deployment Guide Series: IBM Tivoli Security Compliance Manager,
SG24-6450.

Compliance client

The client consists of modules that run on the endpoint to collect compliance
information and report it to the Security Compliance Manager server. In the IBM
Integrated Security Solution for Cisco Networks, the Security Compliance
Manager client introduces a new posture plug-in that communicates with the
Cisco Trust Agent required by Cisco to report posture data during the NAC
process.

The Security Compliance Manager client is Java™-based software that runs on
systems to be monitored for security compliance. By default, the client runs as a
daemon with root authority on UNIX® systems, or as a service running under the
local system account on Microsoft® Windows® systems. The client provides the
runtime environment for collectors deployed to the system and handles
communication with the server.

48 Building a Network Access Control Solution with IBM Tivoli and Cisco Systems

The compliance client component (Figure 3-5) consists of the following modules:

򐂰 Policy collector
򐂰 Posture collector
򐂰 Posture cache
򐂰 Posture plug-in
򐂰 Default remediation handler

SCM Client

Collector

Posture Cache

Policy Collector

Posture

Plug-in

Figure 3-5 Compliance client logical component

Posture

Collector

Posture

Collector

Remediation

Handler

Posture collector

A collector is a Java language-based software module, packaged as a Java
Archive (JAR) file, that collects specific information from a client system. The
collector may use different methods for collecting data depending on the
compliance data to be gathered. Here are some examples:

򐂰 Reading the content of one or more files on the client system
򐂰 Running an operating system command or utility and examining the output
򐂰 Running an executable program packaged as part of the collector JAR file

and examining the output

򐂰 Reading information from the registry on Windows systems

In a scenario where an organization is using a Security Compliance Manager
solution independently, collectors are called

collectors

compliance information and

. In this scenario, an Security Compliance Manager collector collects

only reports it to the Security Compliance Manager

Security Compliance Manager

server.

Chapter 3. Component structure 49

In the IBM Integrated Security Solution for Cisco Networks, the collector is called
a

posture collector. A posture collector consists of posture data collection and

posture status determination. The posture data collection part of a posture
collector is the same as in a regular Security Compliance Manager collector, but
the posture status determination part of a posture collector is an extension to the
standard model. A posture collector determines the client posture status by
checking or comparing a
posture data value, which is part of the collector, is inserted into the collector by
editing collector parameters while creating a collector on the Security
Compliance Manager server.

If required posture data values are null in the parameters, the posture
determination part is not executed. Each posture collector stores into the posture
cache:

򐂰 Collected posture data
򐂰 Posture status, which is from the set {PASS, FAIL, WARN, ERROR}
򐂰 Optional posture messages
򐂰 Zero or more remediation actions

The posture collector also contains appropriate information to be used in order to
remediate any compliance violations.

A posture collector can be called by the Security Compliance Manager server or
by the policy collector on the client, or it can be scheduled.

collected value with a required value. The required

Note: Organizations having Security Compliance Manager deployed can use
Security Compliance Manager collectors and posture collectors at the same
time, but only posture collectors can trigger posture violations and hence
trigger NAC enforcement. To enforce a compliance policy before a client
connects to the enterprise network, posture collectors have to be deployed
using the IBM Integrated Security Solution for Cisco Networks.

Policy collector

After a posture collector collects all required information from the client system,
the policy collector counts the number of posture collector results that show
noncompliance; this result forms the
policy collector’s version information together form the
policy collector also receives back the client’s posture that is evaluated by the
posture validation server (ACS). Depending on the client’s posture status, the
policy collector calls the default
noncompliant items on the client system to the end user.

50 Building a Network Access Control Solution with IBM Tivoli and Cisco Systems

violation count. The violation count and the

posture credentials. The

remediation handler to present information about

Posture cache

This component provides the caching area where posture collectors store the
results of posture determination in a temporary file. The policy collector refers to
the information captured in the posture cache for determining the violation count.

Posture plug-in

Posture plug-ins are the means by which the Cisco Trust Agent requests and
receives security posture information from NAC-compliant applications installed
on the system.

Default remediation handler

The default remediation handler provides a graphical interface for displaying the
compliance posture data and a method for reinitiating the compliance scanning
process. The default remediation handler supports the passing of noncompliance
data and remediation request data to the remediation client.

3.1.3 Remediation

The compliance component identifies and reports policy violations. To make the
client productive again, these violations must be mapped to corresponding
corrective actions that are provided through a remediation subsystem. This
remediation subsystem provides a set of software and configuration
management capabilities that an enterprise can leverage to centrally manage
and automate the remediation process for noncompliant endpoints.

The remediation subsystem consists of a remediation server and the remediation
client.

Remediation server

IBM Tivoli Configuration Manager can automate the manual tasks of installing
software and updating configurations on endpoints. It enables an enterprise to
centrally manage and automate software and configuration for endpoints.

For our solution, Tivoli Configuration Manager helps automate the remediation of
noncompliant endpoints by installing required software updates or correcting
configuration issues. Its remediation capabilities include software levels, typically
operating system levels and fix packs, patch levels, virus and firewall updates,
last virus scans history, password strength and history, and policy level.

Outside the IBM Integrated Security Solution for Cisco Networks environment,
Tivoli Configuration Manager uses the
levels on clients, manage remediation content in self-installing objects, and
perform a number of other functions. In the IBM Integrated Security Solution for
Cisco Networks, requests for the required corrections are initiated by the client,

Tivoli Framework to monitor software

Chapter 3. Component structure 51

and any client components that would normally be installed on a Tivoli
Configuration Manager client are embedded within the Security Compliance
Manager Compliance policy.

For the IBM Integrated Security Solution for Cisco Networks, the Tivoli
Configuration Manager Software Distribution Server and Web Gateway
components are used. The Software Distribution server is extended with
administrative utilities that support the creation of remediation objects that are
designed to be invoked and installed based on requests from the compliance
client. These utilities also publish the remediation objects to the Web Gateway.
The Web Gateway is extended with a
accept the remediation requests from the client and provide the appropriate
remediation objects in response to these requests.

Remediation Servlet that is designed to

Remediation handler component

The remediation handler is a specific component for the IBM Integrated Security
Solution for Cisco Networks that handles the interface between the Security
Compliance Manager client for NAC and the Tivoli Configuration Manager server.
These components are shown in Figure 3-6 on page 56 and explained in the next
sections. This component is not actually installed on the client. Instead, it is
embedded into compliance policies as a special collector and is downloaded to
the clients as part of the compliance policy.

3.2 Physical components

The discussion so far has been focused on the various logical components that
make up the IBM Integrated Security Solution for Cisco Networks. In this section
we map the logical components into physical components that make up the IBM
Integrated Security Solution for Cisco Networks. The physical components of the
solution can be categorized into three types: client components, network
components, and server components. All three components work together to
effectively deploy polices that an enterprise would like to implement.

3.2.1 Network client

A network client is the end device that must comply with the policy. The client in
the current context of the solution can be a PC or mobile computer running
Windows 2000, Windows XP, or Windows NT®, and Red Hat Linux® Enterprise
Linux 3.x and 4.0. The network client must have the following software
components installed:

򐂰 Cisco Trust Agent client software
򐂰 Security Compliance Manager client

52 Building a Network Access Control Solution with IBM Tivoli and Cisco Systems

Cisco Trust Agent

The Cisco Trust Agent is Cisco client software that is required to pass posture
credentials and validation results between the Cisco NAC solution and the IBM
Security Compliance Manager client.

Security Compliance Manager client

The Security Compliance Manager client is a software component that is
physically installed on the network client. It is responsible for communicating with
the Security Compliance Manager Server to keep the client’s policy up-to-date
and to send collected compliance data to the server where it is stored in a
database.

Security Compliance Manager policy

A Security Compliance Manager policy containing all of the collectors that will be
run on the client is downloaded to clients and is the essential unit that performs
most of the work on the client. Policies contain many collectors, each of which is
responsible for collecting an explicit set of data.

Special
for various data and remediation information to be provided to the remediation
handler when collected values do not match required values.

A special
summarizes the collector data to provide version information (for example,
software version of Security Compliance Manager client) and the number of
policy violations to the Cisco Trust Agent client software. Communication
between the Cisco Trust Agent client and Security Compliance Manager client is
implemented using a plug-in developed by IBM.

posture collectors contain parameters that describe the required values

policy collector gathers data from the various collectors and

Tip: A personal firewall and Host IDS running on the client systems are
recommended for controlling traffic and alerting of intrusions on the client. The
Cisco Security Agent provides endpoint server and desktop protection against
new and emerging threats due to malicious network activity. The Cisco
Security Agent identifies and prevents malicious behavior resulting in the
elimination of known and unknown, or “Day Zero,” network threats. The Cisco
Security Agent provides for the aggregation and extension of multiple endpoint
security functions by providing intrusion prevention and distributed firewall
capabilities in addition to malicious mobile code protection, system integrity
assurance, and audit log consolidation. Read more about this product at:

http://www.cisco.com/go/csa

Chapter 3. Component structure 53

3.2.2 Network access infrastructure

All users connect to enterprise resources via network access devices. The
topology varies depending on the size of the organization, but most networks can
be classified into LAN (local area network), WAN (wide area network), or remote
access. The LAN enables connectivity to users within a location. A WAN provides
connectivity to remote or branch office users who need connectivity to resources
that are centrally deployed. Remote access users access the enterprise
resources using dial-up or the Internet to connect. Virtual private network (VPN)
technology is generally deployed for remote access secure connectivity. VPN
connectivity is also used by remote and branch offices to provide a low-cost
secure access method. Enterprise users may use any of these methods to
access the enterprise resources.

Network access device

In the IBM Integrated Security Solution for Cisco Networks, the network enforces
the policy, so the network access device (NAD) becomes an integral part of the
solution. In our solution, Cisco switches, routers, VPN Concentrators, Adaptive
Security Appliances, and access points can be used as policy enforcement
devices.

Note: Refer to the Cisco Web site for the latest list of supported hardware and
corresponding software for the NAC solution at:

http://www.cisco.com/go/nac

3.2.3 IBM Integrated Security Solution for Cisco Networks servers

The servers are a set of centrally administered devices that enable creation,
deployment, and management of policies. They also provide a platform for
centralized validation and reporting.

Cisco Secure Access Control Server

The Cisco Secure Access Control Server (ACS) is a Cisco AAA server or an ACS
appliance that provides posture validation to the client. Posture credentials of the
client are then validated and network access is provided to clients depending on
the policy and their posture status. The ACS delivers network policy information
such as ACL and RADIUS parameters to the NAD that enforces the policy.

Security Compliance Manager server

The Security Compliance Manager server is an IBM-developed solution for the
complex problem of deploying and checking enterprise polices. The server
provides a platform for the creation of various client compliance policies that can

54 Building a Network Access Control Solution with IBM Tivoli and Cisco Systems

be deployed to the clients. The server is also used for administration and for
providing reports about client compliance to deployed policies.

Tivoli Configuration Manager servers

There are two Tivoli Configuration Manager servers used for remediation. Tivoli
Configuration Manager Software Distribution Server is used to create
remediation objects and publish them to the Tivoli Configuration Manager Web
Gateway Server, where they are made available to clients requesting
remediation.

3.3 Solution data and communication flow

Until now we have discussed the various components of our solution. This
section explains the communication and data flow and how the various
components integrate when the solution is being deployed.

Note: This section describes the NAC Framework solution. A similar
description of the NAC Appliance solution is in Appendix A, “Hints and tips” on
page 441.

Chapter 3. Component structure 55

The flow consists of these process groups, depicted in Figure 3-6:

1. Policy creation and deployment

2. Posture collection

3. Posture validation and policy enforcement

4. Remediation

Posture

Network

3.a

Token

Rem.URL

AAA Policy

Server

(ACS)

Rem.URL

3.f

Pop-up

Message

Network

Client

ACL

3.g

3.b

Cisco Trust

Agent

1.d

3.e

3.d

NAD

Policy.Version

Violation.Count

3.c

1.e

Policy

Posture

cache

Policy Collector

Policy.Version

Policy.Version

Violation.Count

Posture

Plug-in

1.b

2.b

SCM

Server

1.c

2.a

Rem.URL

Posture

Collector

Rem.

Attributes

Posture

Collector

Rem.

Attributes

Rem.

Attributes

4.a

TCM

Server

1.a

Rem.Object

TCM Web Gateway

4.b

4.c

Remediation

Handler

Network

4.d

Figure 3-6 Solution data and communication flow

The naming convention in the diagram has four flows based on the process.

Policy creation and deployment (flow 1)

The first step in the data flow is the creation and deployment of a policy. If a Tivoli
Configuration Manager server is used for remediation, a corresponding

56 Building a Network Access Control Solution with IBM Tivoli and Cisco Systems

remediation object should also be provided. Details of the policy creation and
deployment process are discussed here:

򐂰 Remediation object creation and publishing (1a)

A

remediation object that can remediate violations must be provided. The

naming and creation of these objects is dependent on the corresponding
Security Compliance Manager posture collectors and certain naming
conventions. For example, posture collectors that check for hotfixes will have
a different name mapping than those that check for local system settings, and
the remediation objects that will be created for these collectors must take this
name mapping into account. Details on naming conventions and the creation
and publishing of remediation objects are provided in 8.2.4, “Installation of the
Software Package Utilities” on page 394.

򐂰 Compliance policy creation (1b)

A

compliance policy must be created or updated on the Security Compliance

Manager server. The policy may include:

–

Posture collectors of appropriate types to detect violations

– The collectors’ parameters, which must be configured with the values that

will be checked against when making compliance decisions

– Information specific to the remediation object that will remediate violations

when detected as noted in step 1a

– Other attributes that are used to support automated remediation

Each policy must include a
parameters updated for Policy_Version. The new value must be noted for
entry in the ACS policy.

Be aware that only a single policy containing the policy collector can be
deployed to a client. You can define multiple Security Compliance Manager
policies, each with a policy collector instance, but you should never assign
more than one of these policies to a group (and thus a client).

򐂰 Policy deployment (1c)

Security Compliance Manager provides a means to deploy the policy file to
the client, which requires that the client has direct access to the Security
Compliance Manager server. Whenever a client is in communication with the
server, the appropriate policy updates are automatically downloaded to the
client. Our reference architecture provides for the Security Compliance
Manager client to be in contact with the Security Compliance Manager Server
regardless of whether it is being quarantined, which will allow quarantined
clients to download required policy updates using the standard Security
Compliance Manager method.

policy collector, which must have its collector

Chapter 3. Component structure 57

򐂰 Cisco Secure ACS policy creation (1d)

An ACS policy consists of rules that must match required posture criteria.
Depending on the matched criteria, a token is assigned to the network client
that requires validation. The token results in the network client being
dynamically assigned to a group. Based on the
configured on the ACS, the group has an access policy (for example, an ACL
or a RAC) associated with it. Thus depending on the client’s posture, the ACS
assigns an access policy to the client that is enforced by the NAD.

Network Access Profiles

An example of such
the Security Compliance Manager Policy_Version noted in step 1b, and the
violation count to a predetermined value defined by the enterprise policy. This
criteria must be deployed as a policy on the ACS. The ACS policy also has a
feature to provide an action parameter with each rule. Whenever a new
Security Compliance Manager policy is deployed, the ACS Server’s policy
must be updated with the new Policy_Version as noted at the Security
Compliance Manager server in 1b.

򐂰 NAD configuration deployment (1e)

The NAD should be a NAC-compliant hardware device with specific software
that supports NAC. It has to be deployed at the appropriate network points.
The NAD must be deployed with a NAC-related configuration.

posture criteria in our solution is to match the OS type,

Posture collection process (flow 2)

After the policy has been deployed in the various subsystems, the next step is to
collect the posture compliance from the clients. This is the posture collection
process:

򐂰 Posture collection (2a)

The policy that has been deployed to the clients in process 1c includes
posture collectors that are responsible for determining the client’s posture.
The posture collector determines the client’s posture status by comparing the
required posture data value with collected posture data.This data is stored in
the posture cache.

򐂰 Violation count (2b)

The policy collector determines the number of violations. The number of
violations and the policy collector version, which form the posture credentials,
are passed on to the Cisco Trust Agent when it queries the Security
Compliance Manager client. The policy collector passes the posture
credentials to the Cisco Trust Agent using a posture plug-in.

58 Building a Network Access Control Solution with IBM Tivoli and Cisco Systems

Posture validation and policy enforcement (flow 3)

This section contains details about how a client in a live environment connects to
the network and how its posture is validated by the ACS. After validation the
client is provided access based on client posture.

򐂰 Client network access (3a)

The network client initiates IP traffic that crosses a NAC-enabled route point
or connects to a switch running 802.1X. The NAD initiates an EAP session,
forwarding the EAP identity of the NAC-client computer to Cisco Secure ACS.
The ACS initiates a PEAP (Protected Extensible Authentication Protocol)
session with the NAC-client computer, so that all NAC communications are
encrypted and trusted.

򐂰 Posture query (3b)

If various conditions are met, the NAD initiates posture validation. The NAD
applies a default access policy to the client network traffic and initiates an
EAP session with the client. The NAD queries the client for posture
credentials.

򐂰 Posture status reply (Cisco Trust Agent - NAD) (3c)

The Cisco Trust Agent, running on the network client, receives the security
posture credential request and in turn requests security posture credentials
from the NAC-compliant applications (in this case, Security Compliance
Manager client). The security posture credentials are requested and received
through posture plug-ins provided by IBM. When the Cisco Trust Agent
queries for posture credentials, the Security Compliance Manager client
component responds with the posture credentials that were collected in 2b.
The Cisco Trust Agent sends this information to the NAD.

򐂰 Posture status reply (NAD - ACS) (3d)

The NAD transfers the posture credentials to the Cisco Secure ACS using
EAP over RADIUS (EAPoRADIUS).

򐂰 Posture evaluation (3e)

Cisco Secure ACS evaluates the security posture credentials using rules in
the local database. The result of the evaluation is an

. If applications are used other than Security Compliance Manager,

token

there could be multiple application posture tokens.
Cisco Secure ACS consolidates the application posture tokens into an overall

application posture

system posture token. The system posture token is typically the worst-case

scenario for all application posture tokens. The system posture token can
have one of the following values:

–Healthy
– Checkup

Chapter 3. Component structure 59

– Quarantine
– Infected
– Unknown

򐂰 Posture notification (3f)

After the ACS has determined the posture token it performs these actions:
a. Cisco Secure ACS sends the system posture token to the network client.
b. The Cisco Secure ACS sends the network client an action to be taken that

is the result of the client being assigned to a group complying to a
particular policy level. If a customer uses the IBM Integrated Security
Solution for Cisco Networks with Configuration Manager integration and
the client happens to get a token “quarantine,” the results parameter will be
the

remediation URL pointing to the Configuration Manager server.

c. Cisco Secure ACS sends the NAD device the RADIUS attributes as

configured in the mapped user group, including ACLs or RACs as per
network access policy and attribute-value pairs. The optional user
notification can be used to display meaningful messages to the client that
correspond to the posture token assigned to the network client. The
access policy depends on the policy defined by the organization’s network
policy.

d. When the Cisco Secure ACS sends the system posture token to the

NAC-client computer, the ACS ends the PEAP session with the client.

e. Cisco Secure ACS logs the results of the posture validation request.

򐂰 Network policy enforcement (3g)

The NAD device enforces network access as dictated by Cisco Secure ACS
in its RADIUS response. By configuring group mapping, you define
authorizations and, therefore, network access control, based on the system
posture token determined as a result of posture evaluation.

To fully control what resources users have access to under all conditions, a
mapping of default user groups, posture tokens, and access restrictions is
specified in ACS. In general, each user will be assigned to a default user
group based on his authentication. Each user group is mapped to several
posture tokens, and each combination of user group to posture token can be
assigned either a RADIUS Access Control set or a downloadable IP ACL
filter.

60 Building a Network Access Control Solution with IBM Tivoli and Cisco Systems

Remediation (flow 4)

Two cases should be considered for the remediation process: one where the
organization has a Tivoli Configuration Manager server with an automatic
remediation implementation, and the other where the organization will use
manual methods for remediation using a Web server or alternative methods.
Manual remediation could be provided with a Web server where a user can
download the required software to meet the software compliance requirements
and manually comply to configuration requirements.

In the case of automatic remediation, these processes result in remediation:
򐂰 Remediation request (4a)

The token received in step 3e determines the posture of the client. If the client
receives a
(for example, a corrective action). The remediation is initiated by the user of
the network client machine by clicking a remediation button from the Security
Compliance Manager client pop-up window. The
a

remediation URL and a remediation request containing the name of the

remediation object for remediating policy objects to the
on the network client.

򐂰 Remediation execution (4b)

The
Manager Web Gateway server requesting remediation. An appropriate object
is downloaded and executed and the client is remediated.

򐂰 Network access (4c)

quarantine posture this requires being provided with remediation,

policy collector then passes

remediation handler

remediation handler on the network client contacts the Configuration

The NAD continuously polls the client for change in posture status. If the
network client has been remediated, it has to go through the process steps 2a
through 3g again. After the network client is remediated of all violations, it
receives a
changed in the NAD device. At this point the client is compliant to the
enterprise policy and is provided access to the enterprise network.

healthy token from the ACS and the access control policy is

Chapter 3. Component structure 61

3.3.1 Secure communication

The components are designed to provide a high level of security between the
various elements in the solution. We provide a description of how the various
components securely communicate, and Figure 3-7 shows an overview of the
secure communications.

Server

Certificate

CA Server

Server

Certificate

Server

Certificate

EAPoRADIUS

Enforcement

Device (NAD)

EAPoUDP/
EAPonLAN

Cisco Trust Agent

AAA Policy

Server (ACS)

Root

Certificate

Policy

PEAP

Client

Client

Compliance

Server (SCM)

SSL

SCM

Client

Figure 3-7 Secure communication between components

Remediation

Server (TCM)

SSL

Remediation

Handler

62 Building a Network Access Control Solution with IBM Tivoli and Cisco Systems

NAC communication

During communication of the Cisco Trust Agent client with the Cisco Secure
ACS, a secure PEAP session is established with the network client and requests
the network client security posture credentials.

Cisco Trust Agent uses certificates to establish a PEAP session with the ACS.

Security Compliance Manager communication

The Security Compliance Manager client communication with the Security
Compliance Manager server is based on the server’s self-signed SSL certificate
and IP address or host name. Any other communication requests are denied.
This assures that only the authorized Security Compliance Manager server can
communicate with the particular client. The server presents its SSL certificate
during the first communication with the client (first contact trust). This certificate
is used to verify the server’s unique identity and to encrypt all traffic within the
Tivoli Security Compliance Manager environment.

Remediation communication

The communication between the remediation client and Tivoli Configuration
Manager Web Gateway is based on HTTP, which means that if desired, an
HTTPS session can be used to ensure confidentiality of the communications.

3.4 Component placement

Network security is an important consideration for most organizations. New
systems and components that are deployed into the enterprise periodically due
to business needs or security requirements must be deployed and should be
consistent with existing security polices and architecture. This leads us into the
discussion about where the various pieces of the IBM Integrated Security
Solution for Cisco Networks can fit into in an enterprise network.

3.4.1 Security zones

As per IBM MASS (Method for Architecting Secure Solutions), networks can be
divided into five major security zones.

򐂰 Uncontrolled zone/Internet, external networks
򐂰 Controlled zone/demilitarized zone (DMZ)
򐂰 Controlled zone/intranet
򐂰 Restricted zone/production network
򐂰 Restricted zone/management network

Chapter 3. Component structure 63

Figure 3-8 shows the security zones and their classifications. Organizations
could have different topologies and have their own architecture and naming of
zones depending on their security policy.

Untrusted

External network

like Internet

Uncontrolled

Zone

Internet

Business Partner

Connections

VPN termination

Controlled

Zone

Trusted Internal

DMZ Intranet

Network

Controlled

Zone

Organizations may

set up specialized
restricted zones for
production systems

Which would have

Application &

Database systems

Restricted

Zone

Production

Network

Some organizations

may set up special

networks to

separate various

management

components from

production systems.

Restricted

Zone

Management

Network

Less Secure More Secure

Figure 3-8 Security zones

For more about the MASS architecture methodology, refer to the IBM Redbook
Enterprise Security Architecture Using IBM Tivoli Security Solutions,
SG24-6014.

Enterprise security has to meet many stringent requirements, one of them being
compliance. Maintaining and enforcing client compliance can be a tedious
process that consumes time and resources because:

򐂰 The number of clients can be large.
򐂰 Clients are physically dispersed and use different access methods to access

enterprise resources.

򐂰 Not all clients accessing the network are owned by the enterprise (for

example, partners and contractors).

The IBM Integrated Security Solution for Cisco Networks addresses network
clients’ compliance to policies that are centrally defined by the enterprise. The
solution can enforce client compliance and help remediate compliance violations.
Hence it is important to understand network clients, their access methods, and
how this solution can effectively meet the end result of client compliance.

Network client machines represent the users of corporate resources. Clients
access these resources using various access methods such as LAN, wireless,
WAN, and Internet access. Clients using these access methods mostly enter the

64 Building a Network Access Control Solution with IBM Tivoli and Cisco Systems

Branch

Office

Internet

corporate network through what are considered

external networks, such as the

DMZ and intranet zones.

Details of resources that are generally deployed in the various security zones,
the possible access methods by which network clients access these enterprise
resources, and the zones from which clients would access are discussed here
and depicted in Figure 3-9. This discussion can help customers visualize the
practical deployment scenarios of the IBM Integrated Security Solution for Cisco
Networks in their organization.

LAN

Dial up

Client

Branch

Office

WAN

DMZ –2

VPN & R-access

Core

Production

Network

Production

Serve rs

Compli ance

& Remediation

SCMTPM

DMZ –1

Serve r

VPN

Client

Part ner

WAN

DMZ –3

Ext network

DMZ

External Network

Figure 3-9 Client access to enterprise with zone details

Uncontrolled zone - Internet, external networks

The Internet has become a major business driver for many organizations, but it
can be considered completely
the following means:

򐂰 Remote users can use the Internet as an access method and connect to

enterprise resources using VPN technology from across the globe.

uncontrolled. Client machines use the Internet for

LAN

Intranet

ACS

LAB

NMS

Management

Network

Chapter 3. Component structure 65

򐂰 Remote offices and branch offices can use the Internet as a primary method

of access or for backup if the primary access method fails.

򐂰 Organizations can provide partners access over the Internet and exchange

data over VPN.

Controlled zone - external network-facing DMZ

One controlled, semi-trusted network zone is called the DMZ. It provides a buffer
zone between the Internet and internal networks. This zone can realize the
following benefits:

򐂰 DMZ can terminate partner traffic or any other WAN traffic before it enters any

restricted production zone.

򐂰 This zone terminates all dial-up users and VPN traffic.
򐂰 The Tivoli Configuration Manager Web Gateway is typically located in the

DMZ.

Controlled zone - intranet

The intranet is the other controlled zone. Local client users on the LAN
infrastructure and remote office users, using WAN-technologies to connect to
various enterprise resources, are participants of this zone.

Restricted zone - production network

One or more network zones may be designated as restricted zones in systems to
which access must be strictly controlled. These systems can be production
servers and are typically application servers, database servers, and other
servers that support business-critical functions. Direct access to these systems
from uncontrolled networks should not be permitted. The Security Compliance
Manager server, Security Compliance Manager proxy, and, optionally, the
Configuration Manager Software Distribution server may be placed in the
production network.

Restricted zone - management network

This zone contains network and enterprise management systems. The ACS can
typically be part of the management zone.

Other networks

The network examples that we use do not necessarily include all possible
scenarios. There are organizations that extensively segment functions into
various subnetworks. However, in general, the principles discussed here may be
translated easily into appropriate architectures for such environments.

66 Building a Network Access Control Solution with IBM Tivoli and Cisco Systems

3.4.2 Policy enforcement points

The IBM Integrated Security Solution for Cisco Networks employs the Cisco NAC
solution to restrict access to users depending on the compliance level of the
client. The NAC solution requires network access devices (NAD) to be deployed
at various network points to enforce the policy. Some of the widely used network
topologies and possible policy enforcement points are discussed here.

Branch office compliance

Most medium and large networks have regional and branch offices. Routers are
usually deployed at both ends (for example, at the headquarters and the branch
office). Hence there are two locations at which policy enforcement can be
achieved at the branch router or at the headquarter router. In addition, if the
branch office has a NAC-capable switch, the NAC policy enforcement can be
implemented on the switch.

Branch egress enforcement

Regional and branch offices can have the policy enforcement point deployed at
their location before they connect to the central data center at the branch routers
itself (Figure 3-10).

Branch Office Compliance

(Branch egress Enforcement)

Remote Office

Remote

Offices

Remote

Offices

Regional

Offices

AAA

AAA

Remote

Offices

Figure 3-10 Branch egress enforcement

Private

WAN

Internet

Server

AAA

Posture Enforcement

Router

AAA

Points

AAA

AAA

Chapter 3. Component structure 67

Corporate

Headquarters

Data Center

Advantages of this kind of deployment are:

򐂰 Policy enforcement load distribution across the various routers
򐂰 Protection against virus infection between branch offices if the network has a

mesh topology

Factors that must be considered for branch egress enforcement are:

򐂰 Branch routers must support NAC
򐂰 Some additional administrative effort required during deployment

Campus internal enforcement

In this deployment option, the office policy compliance is enforced on all switches
to which the users connect. Two modes of posture checking users exist within
switches: 802.1x and EAP/UDP.

802.1x involves passing posture and, if desired, user authentication information
in an EAP-based 802.1x frame. The response from ACS is a VLAN name or
number associated with the posture state of the user, which would be healthy or
quarantine.

EAP/UDP passes only posture information in an UDP datagram. ACS responds
with a port-based ACL (PACL) that provides enforcement of users’ healthy or
quarantine state.

Note: At the time of this writing PACLs are not supported in an 802.1x NAC
Framework on all Cisco devices. However, it is Cisco’s stated intention to
make this functionality available on all devices in the near future. Due to
considerations that will affect the client software required on each endpoint,
this book uses a reference architecture in which 802.1X is used for both
authentication and admission control. This architecture delivers a valid
network deployment even without PACLs and will be able to constrain traffic in
a more granular fashion once PACLs are available.

The NAC Framework can work in IP Communications environments. For 802.1x
environments, Cisco IP Phones must be used. For EAP/UDP environments, both
Cisco and Non-Cisco IP Phones may be used.

68 Building a Network Access Control Solution with IBM Tivoli and Cisco Systems

Branch Office Compliance

(Campus Ingress Enforcement)

Corporate

Headquarters

Data Center

AAA

AAA

Internet

Server

AAA

Posture Enforcement

AAA

Points

Figure 3-11 Campus ingress enforcement

Site-to-Site

VPN Users

Router

VPN

Chapter 3. Component structure 69

Small Office Home Office compliance

Policy enforcement can be used to protect corporate networks from
noncompliant and potentially infected small office and home office (SOHO)
users, as shown in Figure 3-12. This will also be the practical deployment option
for clients who are using Port Address Translation to access corporate resources.

SOHO Compliance

(PAT access protection)

Corporate

Headquarters

Data Center

AAA

AAA

AAA

Server

Internet

AAA

Posture Enforcement

Points

Figure 3-12 SOHO compliance

Site-to-Site

VPN Users

Router

VPN

70 Building a Network Access Control Solution with IBM Tivoli and Cisco Systems

Extranet compliance

Organizations could have WAN connections to share information with partners.
This would require partner systems connecting to the parent organization to
comply with the policies laid down by the parent organization. The policy
enforcement device can be deployed appropriately to ensure that these partner
systems comply to the parent organization’s policies (Figure 3-13).

Extranet

Compliance

Partners

Partner

WAN

Figure 3-13 Extranet compliance

Corporate

Headquarters

Data Center

AAA

AAA

AAA

Server

AAA

Posture Enforcement

Router

Points

Chapter 3. Component structure 71

Lab compliance

Organizations prefer having lab networks to test systems before deployment of
new solutions or equipment. Traffic from this zone to the primary network is
restricted so that operations in the lab setup do not disrupt the production
systems and networks. A policy enforcement at the connection between the
production systems and lab setup can ensure that only systems that comply to
the enterprise policy are allowed into the production network from a lab subnet.
Figure 3-14 shows a lab policy enforcement scenario.

LAB Compliance

AAA

AAA

AAA

Lab

Networks

Figure 3-14 Lab compliance

Production

Network

Server

AAA

Posture Enf orcement

Router

Switch

Access Point

AAA

Points

72 Building a Network Access Control Solution with IBM Tivoli and Cisco Systems

Data Center protection

The Data Center is the site where organizations host business-critical systems
that require maximum protection. Compliance can be checked for client systems
before they are provided connections to the resources at the Data Center
(Figure 3-15).

Data Center Protection

AAA

AAA

AAA

Corporate

Networks

Figure 3-15 Data Center protection

Data

Center

Lab

Networks

Server

AAA

Posture Enforcement

Router

Switch

Access Point

AAA

Points

Chapter 3. Component structure 73

Remote access protection

Remote access users use dial-up or VPN to connect to corporate resources. To
enforce these users to comply to the corporate policies, a policy enforcement
device may be deployed at the remote access entry points (Figure 3-16).

Remote Access Protection

Figure 3-16 Remote access protection

The policy enforcement points can vary, depending on which section of the
enterprise the organization would like to enforce compliance. The physical
locations of posture enforcement points depend on the organization’s network
and security architecture.

3.5 Conclusion

The IBM Integrated Security Solution for Cisco Networks is an integration of
products from IBM and Cisco. New components have been added to each of the
individual product sets so they can work in unison. The components in this
chapter have been described with integration being the prime objective. Some of
the components can perform other functions not mentioned here. This chapter
has dealt with the various logical and physical components that make up the IBM
Integrated Security Solution for Cisco Networks. A logical data flow has been
provided to show how the various components communicate and deliver the
desired result of policy compliance validation and remediation.

AAA

AAA

AAA

Internet

Corporate

Network

Legacy VPN

Concentrators

Mobile

Users

Posture Enforcement

Points

Router

VPN

Concentrator

74 Building a Network Access Control Solution with IBM Tivoli and Cisco Systems

Part 2 Customer

environment

Part 2

Part 2 discusses how the IBM Integrated Security Solution for Cisco Networks
might be used in customer situations.

We use a well-know customer scenario, the Armando Banking Brothers Corp. In
our last encounter in the IBM Redbook Deployment Guide Series: IBM Tivoli
Security Compliance Manager, SG24-6450, they successfully deployed the Tivoli
Security Compliance Manager solution for their distributed server environment.

This time they are extending the use of Security Compliance Manager and, with
solutions from Cisco and IBM Tivoli, they want to implement compliance-based
physical network access control.

© Copyright IBM Corp. 2005, 2007. All rights reserved. 75

76 Building a Network Access Control Solution with IBM Tivoli and Cisco Systems

4

Chapter 4. Armando Banking Brothers

Corporation

This chapter provides an introduction to the overall structure of the Armando
Banking Brothers Corporation (ABBC). This introduction includes a description of
ABBC’s business profile, their current IT architecture, and their medium-term
business vision and objectives.

Note: All names and references for company, personnel, and other business
institutions used in this chapter are fictional; any match with real entities is
coincidental.

© Copyright IBM Corp. 2005, 2007. All rights reserved. 77

4.1 Company profile

Armando Brothers Banking Corporation (ABBC) is a fictional financial institution
that traces its roots back to the early days of industrialization. During a time of
radical change and growing financing needs, the Armando brothers founded a
bank situated in the pioneer town of Waterloo — now known as Austin, Texas. In
the early years, ABBC helped many entrepreneurial pioneers finance their
business ventures. In part due to their history of progressive management, as
well as their diligent awareness of emerging technologies, ABBC developed an
ability to rapidly expand and open branches throughout the state, the nation, and
ultimately the world. As the 20th century drew to a close, ABBC was an early
adopter of electronic banking technologies; they were among the first banks
offering their customers online account access. Today ABBC is one of the
dominant players in the highly competitive realm of worldwide finance.

ABBC is keenly aware that providing increased electronic access for its
customers requires ever-increasing security measures to protect its electronic
assets. Currently ABBC is leveraging the existing IBM product solutions of the
IBM Tivoli Identity Manager and the IBM Tivoli Access Manager to manage and
enforce its authentication and authorization policies. Like many companies,
ABBC has found that traditional hacker attempts to gain unauthorized access are
only part of the security threat factor. In today’s environment network, worms,
trojans, and viruses pose an equally tangible threat. ABBC is aware that more
than 90% of security attacks exploit known security flaws for which a patch is
available or a preventive measure is known. ABBC is further challenged by
compliance legislation such as the Gramm-Leach-Bliley Act (GLBA) and the
Sarbanes-Oxley Act (SOX), as are many companies. To assist with both threat
mitigation and management of business policy compliance issues, ABBC has
adopted the IBM Security Compliance Manager product.

The inclusion of the IBM Security Compliance Manager product enables ABBC
to reap a quick return on investment by automating and centralizing security
compliance monitoring. Previously ABBC limited the use of the IBM Security
Compliance Manager product to their servers. In the current project, ABBC will
extend the use of the IBM Security Compliance Manger product to its
workstations. Following workstation client deployment, they will embark on the
next logical step: integrating their existing IBM Security Compliance Manager
infrastructure with the Cisco-sponsored Network Admission Control program.

ABBC decided also to enhance the scope of the project by employing Tivoli
Configuration Manager software currently used by the operations department to
provide the users with help in keeping their workstation compliant with the
corporate security policy.

78 Building a Network Access Control Solution with IBM Tivoli and Cisco Systems

4.2 Current IT architecture

This section provides background information about the existing Armando
Banking Brothers Company IT architecture, including the network infrastructure,
security infrastructure, and the middleware/application infrastructure.

4.2.1 Network infrastructure

Next we describe the logical network components that make up the ABBC
network (Figure 4-1). ABBC has developed the network and application security
infrastructure in line with the IBM MASS security model. The network has the
following major security zones:

򐂰 Uncontrolled zone/Internet, external networks
򐂰 Controlled zone/demilitarized zone (DMZ)
򐂰 Controlled/intranet
򐂰 Restricted/production network
򐂰 Restricted/management network

LAN

Dialup
Client

Branch

Office

Internet

VPN

Client

Partner

WAN

External Network

VPN & R-access

DMZ –3

Ext network

DMZ –2

DMZ

DMZ –1

Server

Figure 4-1 ABBC current network diagram

Virtual Private

network

Wireless

Access point

Core

LAN

Intranet

Branch

Office

WAN

LAB

Firewall

Router

Production

Network

Production

Servers

NMS

Management

Network

Intrusion detection

SCMTCM

Compliance

& Remediation

ACS

System

Chapter 4. Armando Banking Brothers Corporation 79

Uncontrolled zone - Internet

The Internet has become a pivotal component in the banking industry with its
immense flexibility and business opportunities. But it has also become one of the
preferred methods for spreading viruses and malicious code as well as providing
easy access to many unprotected or weakly secured enterprise resources.
Balancing the requirements and threats, ABBC has provided clients, employees,
and partners with controlled access to its resources. Firewalls and intrusion
detection and prevention systems have been deployed to provide adequate
network perimeter security.

Controlled zone - DMZ

ABBC hosts Web access control servers and mail gateways in the DMZ. It is also
a termination point for VPN users before they connect to the primary network.

Controlled intranet

Local employees connected through the LAN are part of this zone. ABBC is
investing in wireless networks and VOIP technology for their users’ improved
access capability and flexibility. The corporate WAN also terminates in this zone.
ABBC has a lab network where testing is done before any system is deployed in
a production environment. The IBM Integrated Security Solution for Cisco
Networks has been tested by ABBC. The test simulation is discussed briefly in

4.2.2, “IBM Integrated Security Solution for Cisco Networks lab” on page 80.

Production network

The server resources for the enterprise are deployed in the production network.
With the IBM Integrated Security Solution for Cisco Networks, ABBC has
deployed the compliance and remediation servers in this section of the network.
The network management zone is a separate protected subnet. The segments of
the production network are also given additional protection.

4.2.2 IBM Integrated Security Solution for Cisco Networks lab

Network Admission Control uses the network infrastructure to enforce security
policy compliance on all devices seeking to access the network. NAC can be
delivered in two ways: NAC Framework and NAC Appliance.

NAC Framework

NAC Framework is an architecture-based approach that provides comprehensive
control by assessing all endpoints across all access methods, including LAN,
wireless connectivity, remote access, and WAN. It can be deployed as NAC L2 IP,
NAC L2 802.1x, or NAC L3 IP. It utilizes Cisco routers, switches, VPN
Concentrators, and Adaptive Security Appliances. Cisco Secure ACS is an
integral component of NAC Framework.

80 Building a Network Access Control Solution with IBM Tivoli and Cisco Systems

Figure 4-2 is representative of the ITSO Lab Environment used for L2Dot1x NAC
deployment.

VLAN-11 Healthy Sales VLAN in the Core network. This VLAN hosts those

users that have been authenticated by IEEE 802.1x as members
of the Sales Group and have been posture validated as Healthy.

VLAN-12 Healthy Engineering VLAN in the Core network. This VLAN hosts

those users that have been authenticated by IEEE 802.1x as
members of the Engineering Group and have been posture
validated as HealthyII.

VLAN-13 Quarantine Sales VLAN in the Core network. This VLAN hosts

those users that have been authenticated by IEEE 802.1x as
members of the Sales Group, but are not compliant.

VLAN-14 Quarantine Engineering VLAN in the Core network. This VLAN

hosts those users hat have been authenticated by IEEE 802.1x
as members of the Engineering Group, but are not compliant.

VLAN-9 This VLAN hosts the Cisco Secure ACS and the Tivoli Security

Compliance Manager.

VLAN-104 This VLAN hosts the Tivoli Configuration Manager.

Figure 4-2 Armando Banking Brothers network environment for NAC Framework

From a Network Admission Control perspective, the user is prompted for his
IEEE 802.1x credentials when he connects to the access switch. Upon supplying

Chapter 4. Armando Banking Brothers Corporation 81

his credentials, the Cisco Secure ACS checks its local user database and
assigns the user to the respective group. The user is then mapped to the Healthy
or Quarantine VLAN of that group, depending on the state of posture compliance
provided by the CTA on the user’s machine. All access to the network is based on
access control lists (ACLs) bound to the Layer 3 Switched Virtual Interfaces
(SVIs) on the switch, which in this example is also the access switch.

NAC Appliance

NAC Appliance is based on the Cisco Clean Access products. It comprises a
Clean Access Manager (CAM), a Clean Access Server (CAS), and a Clean
Access Agent (CAA). It is not based on an architecture approach, and can
provide NAC functionality on non-Cisco based networks. NAC Appliance can be
deployed in a variety of ways. In this example, it has been deployed as a

out-of-band

gateway.

virtual

82 Building a Network Access Control Solution with IBM Tivoli and Cisco Systems