HP ProCurve Access Control Client Security Solutions

Download

ProCurve Solutions

Access Control Security Design Guide 2.1

www.procurve.com

ProCurve Access Control Security

Design Guide

April 2008

2.1.XX

This document contains proprietary information, which is protected by copyright. No part of this document may be photocopied, re produced, or translated into another language without the prior written consent of Hewlett-Packard.

Applicable ProCurve Products

Network Access Controller 800 (J9065A)

ProCurve Manager Plus (J9056A)

Identity Driven Manager (J9012A)

IPsec VPN Base Modules (J9026A, J8471A)

Secure Router 7102dl (J8752A)

Secure Router 7203dl (J8753A)

Switch 5406zl (J8697A)

Switch 5406zl-48G (J8699A)

Switch 5412zl (J8698A)

Switch 5412zl-96G (J8700A)

Switch 5304xl (J4850A)

Switch 5304xl-32G (J8166A)

Switch 5308xl (J4819A)

Switch 5308xl-48G (J8167A)

Switch 5348xl (J4849A)

Switch 5372xl (J4848B)

Switch 8212zl (J8715A)

Wireless Edge Services xl Module (J9001A)

Redundant Wireless Services xl Module (J9003A)

Wireless Edge Services zl Module (J9051A)

Redundant Wireless Services zl Module (J9052A)

AP 530 (J8986A)

AP 420 na/ww (J8130B, J8131B)

RP 210 (J9004A)

RP 220 (J9005A)

RP 230 (J9006A)

Trademark Credits

ActiveX, Microsoft, Windows, Windows NT, and Windows XP are U.S. registered trademarks of Microsoft Corporation.

Apple, Mac OS, and QuickTime are registered trademarks of Apple, Inc.

CRYPTOCard is a registered trademark of Cryptocard Corporation.

eDirectory, NetWare, Novell, and SUSE are registered trademarks of Novell, Inc.

Juniper Networks is a registered trademark of Juniper Networks, Inc.

Linux is a registered trademark of Linus Torvalds.

OpenLDAP is a registered trademark of the OpenLDAP Foundation.

Red Hat is a registered trademark of Red Hat, Inc.

Solaris is a registered trademark of Sun Microsystems, Inc.

Steel-Belted Radius is a registered trademark of Funk Software, Inc.

Disclaimer

HEWLETT-PACKARD COMPANY MAKES NO WARRANTY OF ANY KIND WITH REGARD TO THIS MATERIAL, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. Hewlett-Packard shall not be liable for errors contained herein or for incidental or consequential damages in connection with the furnishing, performance, or use of this material.

The only warranties for HP products and services are set forth in the express warranty statements accompanying such products and services. Nothing herein should be construed as constituting an additional warranty. HP shall not be liable for technical or editorial errors or omissions contained herein.

Hewlett-Packard assumes no responsibility for the use or reliability of its software on equipment that is not furnished by Hewlett-Packard.

War rant y

See the Customer Support/Warranty booklet included with the related products.

A copy of the specific warranty terms applicable to your Hewlett-Packard products and replacement parts can be obtained from your HP Sales and Service Office or authorized dealer.

Open Source Software Acknowledgment Statement

This software incorporates open source components that are governed by the GNU General Public License (GPL), version 2. In accordance with this license, ProCurve Networking will make available a complete, machinereadable copy of the source code components covered by the GNU GPL upon receipt of a written request. Send a request to:

Hewlett-Packard Company, L.P. Wireless Edge Services xl Module Program GNU GPL Source Code Attn: ProCurve Networking Support MS: 5550 Roseville, CA 95747 USA

Hewlett-Packard Company 8000 Foothills Boulevard Roseville, California 95747 http://www.procurve.com/

1 Access Control Concepts

Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1

Introduction to Access Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-3

Network Access Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-4

Network Access Control Technologies . . . . . . . . . . . . . . . . . . . . . . . . . . 1-6

AAA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-6

Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-7

Authorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-8

Accounting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-10

Network Access Control Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 1-11

Endpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-11

Policy Enforcement Point (PEP) . . . . . . . . . . . . . . . . . . . . . . . . . . 1-11

Policy Decision Point (PDP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-12

Policy Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-14

Network Access Control Process . . . . . . . . . . . . . . . . . . . . . . . . . 1-15

Authentication-Based Network Access Control Methods . . . . . . . . . 1-16

MAC-Auth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-16

Web-Auth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-19

802.1X . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-21

Authentication Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-23

Authentication Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-23

PAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-24

CHAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-24

MS-CHAPv2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-25

EAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-25

RADIUS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-28

Wireless Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-30

802.11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-30

Static Wired Equivalent Privacy (WEP) . . . . . . . . . . . . . . . . . . . . 1-31

Dynamic WEP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-31

WPA/WPA2 and 802.11i . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-32

Access Control Rights—Dynamic Settings . . . . . . . . . . . . . . . . . . . . . 1-33

VLANs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-33

ACLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-35

Endpoint Integrity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-36

Endpoint Integrity Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-36

Pre-connect and Post-connect Testing . . . . . . . . . . . . . . . . . . . . . 1-37

Testing Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-38

Endpoint Requirements for Integrity Checking . . . . . . . . . . . . . . 1-40

Endpoint Integrity Posture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-42

Quarantine Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-42

ProCurve NAC 800 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-45

NAC 800 as an Endpoint Integrity Only Solution . . . . . . . . . . . . . . . . 1-45

802.1X Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-46

DHCP Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-48

Inline Deployment Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-51

NAC 800 as a RADIUS-Only Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 1-52

NAC 800 as Both a RADIUS Server and an Endpoint

Integrity Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-53

ProCurve IDM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-58

2 Customer Needs Assessment

Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3

Types of Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-5

Employees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-5

Temporary Employees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-6

Guests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-6

Network Skills . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-7

Recording Information about Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-8

Types of Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-9

Wired Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-9

Wireless Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-9

Remote Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-10

Recording the Types of Connections Available to Users . . . . . . . . . . 2-10

Access Control Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-11

Determine Risk Tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-15

Regulations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-16

Regulatory Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-18

Quantify Your Company’s Risk Tolerance . . . . . . . . . . . . . . . . . . . . . . 2-18

Vulnerability to Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-19

Attack Vectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-19

External Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-19

Internal Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-19

Types of Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-20

Malware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-21

Viruses and Worms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-22

Evaluate the Existing Network Environment . . . . . . . . . . . . . . . . . . 2-25

Size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-25

Edge Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-25

Endpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-28

Workstations and Laptops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-28

Other Endpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-30

RADIUS Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-31

Directory Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-31

Remote Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-32

Subnets and VLANs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-32

Routing Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-32

DCHP Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-32

Network Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-33

iii

Determine Your Endpoint Integrity Requirements . . . . . . . . . . . . . 2-34

Browser Security Policy—Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-34

Select Security Settings for Your Company . . . . . . . . . . . . . . . . . 2-36

Operating System—Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-37

Security Settings—OS X . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-37

Security Settings—Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-37

Software—Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-38

The Human Factor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-39

Control over Network Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-39

IT Department Workload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-40

Users’ Cooperation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-40

3 Designing Access Controls

Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1

Comprehensive Security Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-5

The Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-6

The Process of Designing Access Control Security . . . . . . . . . . . . . . . 3-8

Example Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-8

Choose the Access Control Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-13

Network Access Zones: Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-15

Wired Zone Security Concerns . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-16

Wireless Zone Security Concerns . . . . . . . . . . . . . . . . . . . . . . . . . 3-17

Vulnerability and Risk Tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-21

Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-22

User Type and Sophistication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-22

Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-23

Administrative Workload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-24

Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-24

Endpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-25

Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-26

Administrative Control over Endpoints . . . . . . . . . . . . . . . . . . . . . . . . 3-27

Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-28

Network Infrastructure Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-29

Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-30

Network Infrastructure Devices as 802.1X Supplicants . . . . . . . 3-31

Bringing All of the Factors Together . . . . . . . . . . . . . . . . . . . . . . . . . . 3-32

Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-34

Make Decisions about Remote Access (VPN) . . . . . . . . . . . . . . . . . . . 3-36

Decide Whether to Grant Remote Access . . . . . . . . . . . . . . . . . . . . . . 3-37

Select VPN Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-38

Vulnerability and Risk Assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-40

Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-41

User Type and Sophistication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-42

Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-43

Administrative Workload and IT Budget . . . . . . . . . . . . . . . . . . . . . . . 3-44

Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-44

Endpoint Capabilities and Administrative Control

over Endpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-45

Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-46

Existing Network Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-47

Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-47

Bringing All Factors Together . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-48

Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-49

Choose the Endpoint Integrity Deployment Method . . . . . . . . . . . . 3-51

Access Control Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-51

802.1X . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-51

Web-Auth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-51

MAC-Auth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-52

Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-53

Vulnerability to Risks and Risk Tolerance . . . . . . . . . . . . . . . . . . . . . . 3-53

Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-55

Existing Network Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-55

Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-56

Connection Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-56

Bringing the Factors Together . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-57

Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-57

Choose Endpoint Integrity Testing Methods . . . . . . . . . . . . . . . . . . . 3-59

Requirements for Testing Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-60

NAC EI Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-60

Advantages and Disadvantages of NAC Agent Testing . . . . . . . . 3-62

ActiveX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-62

Requirements for ActiveX Testing . . . . . . . . . . . . . . . . . . . . . . . . . 3-62

Advantages and Disadvantages of ActiveX Testing . . . . . . . . . . . 3-63

Agentless . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-63

Requirements for Agentless Testing . . . . . . . . . . . . . . . . . . . . . . . 3-64

Advantages and Disadvantages of Agentless Testing . . . . . . . . . 3-64

Deciding Which Testing Methods to Enable . . . . . . . . . . . . . . . . . . . . 3-64

Transparent Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-65

Testing with User Interaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-67

Factors to Consider for Testing Methods . . . . . . . . . . . . . . . . . . . . . . 3-69

Administrative Control over Endpoints . . . . . . . . . . . . . . . . . . . . 3-69

Post-Connect Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-71

User Sophistication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-72

Administrative Workload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-74

Network Overhead . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-75

Bringing All of the Factors Together . . . . . . . . . . . . . . . . . . . . . . . 3-76

Choose RADIUS Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-78

RADIUS Servers in a Network Without Endpoint Integrity . . . . . . . . 3-79

Choose Which Devices Will Play the Role of PDP . . . . . . . . . . . . 3-79

Choose an Access Control Architecture . . . . . . . . . . . . . . . . . . . . 3-84

Determine the Number of RADIUS Servers . . . . . . . . . . . . . . . . . 3-89

Choose Your RADIUS Servers and Finalize the Plan . . . . . . . . . 3-90

RADIUS Servers in a Network With Endpoint Integrity (802.1X

Quarantining) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-93

IAS as the RADIUS Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-93

NAC 800 as the RADIUS Server . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-94

Add ProCurve IDM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-98

IDM Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-98

Determine If You Need IDM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-98

Design Parameters for a Network with IDM . . . . . . . . . . . . . . . . . . . . 3-99

Add Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-100

Create Access Policy Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-100

Select an EAP Method for 802.1X . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-101

Finalize Security Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-106

User Groups and Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-106

Access Group Policies with IDM . . . . . . . . . . . . . . . . . . . . . . . . . 3-107

Access Policies without IDM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-117

Create the NAC Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-120

Design NAC Policy Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-120

Design NAC Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-121

Lay Out the Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-129

Core Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-129

Access Zones for Endpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-131

Public Wired Zone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-131

Public Wireless Zone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-134

Private Wired Zone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-140

Private Wireless Zone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-142

Remote Zone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-143

Combining Access Control Zone Designs . . . . . . . . . . . . . . . . . . . . . 3-146

Adjacent Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-146

Overlapping Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-146

Designing Adjacent and Overlapping Zones . . . . . . . . . . . . . . . . 3-147

Integrating all Parts of the Network Design . . . . . . . . . . . . . . . . . . 3-148

Adding Access Control to an Existing Network . . . . . . . . . . . . . . . . 3-148

Migrating from One Solution to Another . . . . . . . . . . . . . . . . . . . . . . 3-149

4 Other Resources

Services and Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1

ProCurve Elite Partners . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1

ProCurve Network Access Controller 800 Implementation Start-up

Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1

Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-2

A Appendix A: Glossary

Index

vii

Addendum to the ProCurve Access Control Security Design Guide

Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-1

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-3

ProCurve Access Control Solution 2.1 . . . . . . . . . . . . . . . . . . . . . . . . . A-4

Enhancements to the ProCurve Access Control Solution 2.1 . . . . . . A-5

ProCurve NAC 1.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-6

SMB Signing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-6

Deep Check Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-6

Post-Connect NAC Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-7

Integration with Microsoft SMS . . . . . . . . . . . . . . . . . . . . . . . . . . . A-7

Support for RDAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-7

DHCP Plug-in Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-8

Identity Driven Manager 2.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-9

Microsoft NAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-11

NAP Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-11

NAP Client Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-14

NAP Enforcement Clients (ECs) . . . . . . . . . . . . . . . . . . . . . . . . . A-14

System Health Agents (SHAs) . . . . . . . . . . . . . . . . . . . . . . . . . . . A-14

NAP Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-14

NAP Server Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-15

NAP Enforcement Point . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-16

NPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-16

Health Requirement Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-17

Network Access Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-17

IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-17

DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-20

VPN Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-21

802.1X Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-21

Remediation and Health Requirement Servers . . . . . . . . . . . . . A-23

viii

Updating the Access Control Design Process . . . . . . . . . . . . . . . . . . A-24

Choose the Endpoint Integrity Solution . . . . . . . . . . . . . . . . . . . . . . . A-25

Existing Network Environment . . . . . . . . . . . . . . . . . . . . . . . . . . A-25

Vulnerability to Risks and Risk Tolerance . . . . . . . . . . . . . . . . . A-26

Management Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A-27

Interoperability Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . A-28

Bringing the Factors Together . . . . . . . . . . . . . . . . . . . . . . . . . . . A-29

Choose the Endpoint Integrity Deployment Method . . . . . . . . . . . . A-30

Access Control Concepts

Introduction to Access Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2

Network Access Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-3

Network Access Control Technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-5

AAA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-5

Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-6

Authorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-7

Accounting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-9

Network Access Control Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 1-10

Endpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-10

Policy Enforcement Point (PEP) . . . . . . . . . . . . . . . . . . . . . . . . . . 1-10

Policy Decision Point (PDP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-11

Policy Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-13

Network Access Control Process . . . . . . . . . . . . . . . . . . . . . . . . . 1-14

Authentication-Based Network Access Control Methods . . . . . . . . . 1-15

MAC-Auth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-15

Web-Auth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-18

802.1X . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-20

Authentication Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-22

Authentication Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-22

PAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-23

CHAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-23

MS-CHAPv2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-24

EAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-24

RADIUS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-27

1-1

Access Control Concepts

Contents

Wireless Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-29

802.11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-29

Static Wired Equivalent Privacy (WEP) . . . . . . . . . . . . . . . . . . . . 1-30

Dynamic WEP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-30

WPA/WPA2 and 802.11i . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-31

Access Control Rights—Dynamic Settings . . . . . . . . . . . . . . . . . . . . . 1-32

VLANs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-32

ACLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-34

Endpoint Integrity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-35

Endpoint Integrity Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-35

Pre-connect and Post-connect Testing . . . . . . . . . . . . . . . . . . . . . 1-36

Testing Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-37

Endpoint Requirements for Integrity Checking . . . . . . . . . . . . . . 1-39

Endpoint Integrity Posture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-41

Quarantine Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-41

ProCurve NAC 800 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-44

NAC 800 as an Endpoint Integrity Only Solution . . . . . . . . . . . . . . . . 1-44

802.1X Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-45

DHCP Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-47

Inline Deployment Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-50

NAC 800 as a RADIUS-Only Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 1-51

NAC 800 as Both a RADIUS Server and an Endpoint

Integrity Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-52

1-2

ProCurve IDM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-57

Access Control Concepts

Introduction to Access Control

Over the last several decades, network connectivity has evolved into a necessary component of nearly every business activity. Users rely on the network for:

■ Data—the information stored in the computing environment

■ Applications—the means of manipulating that data

It is a rare user who accesses only the data and applications stored on an isolated computer system. Instead, a user connects to a network, which allows his or her endpoint—the device used to connect to the network—to access data and applications stored on many systems.

Resources stored and delivered over a network are valuable; they might include medical records, payroll information, customers’ financial records, corporate strategy, and military operation plans. And because the resources are valuable, some people may attempt to hijack them for their own purposes.

To protect resources from misuse (whether malicious or not), you must enforce access controls. Many users associate the words access control with a username and password, submitted to gain access to a particular piece of data or application. However, an access control is any mechanism for dictating which users and devices can access particular resources.

You can control users’ access to resources in three ways:

■ Data access control (enforced on particular data storage devices)

■ Application access control (enforced on particular services)

■ Network access control (enforced at the network edge, where users

connect)

Access control is most effective at protecting resources when the three types work together. But because the network is the means of distributing all data and applications to users, network access control is particularly important as a comprehensive solution. Network access control provides the following functions:

■ Blocks access from unauthorized users at each network entry

point—Securing individual resources is not enough. Even when an attacker cannot reach core resources, he or she can discover much about your network and potentially implement attacks simply by connecting to it. A solution for blocking and controlling users at the edge, before they connect to the network, adds another layer of security to that implemented on individual devices.

1-3

Access Control Concepts

Introduction to Access Control

■ Eliminates frustrations created by piecemeal solutions—A well-

This solution design guide focuses on network access control as the first front in securing your organization’s resources.

Network Access Control

Network access control is the process of controlling who has access to which network resources under what conditions (the time, location, and means of access).

An access control security policy addresses these questions:

■ Who should access the network?

■ What data, services, and other resources on the network should these

■ What conditions should alter the level of access granted to a

designed, centrally administered network access control solution minimizes the number of passwords that users must enter throughout the day. Ideally, the solution begins to control the user’s access as soon as he or she connects to the network and continues to do so without further user interaction.

users access?

particular user?

1-4

It is easy to think of network access control in terms of the first question only and to answer that question in a simplistic fashion: “I want to allow the good guys in and keep the bad guys out.” But, of course, users do not split neatly into “good guys” and “bad guys,” and attacks do not always originate from the outside.

You can more usefully think of access control as granting many different types of users—employees, both temporary and permanent; guests; and customers—the level of access that is appropriate to their needs.

For example, it is appropriate for doctors and nurses in a hospital to access patient records; they need those records to do their jobs. Receptionists at the front desk, on the other hand, do not require such access, so the network should not give it to them. However, the receptionists should, quite appropriately, have access to other network resources (such as appointment databases and scheduling software). And the only resource appropriate for patients and visitors might be the Internet and the hospital’s public Web site.

Access Control Concepts

Introduction to Access Control

The third question raises another important issue: factors beyond a user’s identity can affect the appropriate level of access. For example, a daytime manufacturing worker might require network access during normal working hours from computers near his assembly station, but not at night or from computers in the marketing department.

The means by which the user connects to the network can also be relevant. For example, wireless connections are sometimes more vulnerable to eavesdropping than wired, so a user that is normally allowed to access sensitive data might be prohibited from viewing that same data over a wireless connection. And because a t rusted, well-intentioned user can introduce m alware from within the network by connecting with an improperly secured endpoint, a complete access control solution should examine the integrity of the user’s device in addition to the user’s identity.

Chapter 3: “Designing Access Controls” will discuss these considerations in more depth, guiding you through formulating your own security policy. The remainder of this chapter focuses on the concepts and technologies that underlie network access control.

1-5

Access Control Concepts

Network Access Control Technologies

This solution design guide focuses on two general types of access control:

■ Authentication, authorization, and accounting (AAA)—controls

(and tracks) which users access which resources on the network

■ Endpoint integrity—controls which endpoints are allowed on the net-

work based on their compliance with policies for endpoint security settings

AAA provides the traditional framework for controlling access to the network, whereas endpoint integrity adds the ability to protect the network from potentially compromised endpoints.

The remainder of this chapter covers the protocols and technologies that underlie AAA and endpoint integrity solutions. If you already have a solid understanding of these concepts, you can proceed immediately to Chapter 2: “Customer Needs Assessment.” But remember: designing an access control solution is much less frustrating when you know what choices are available and what those choices entail.

1-6

AAA

Developed by the Internet Engineering Task Force (IETF), AAA dictates how network devices provide:

■ Authentication—determining if users are who they claim to be

■ Authorization—deciding which data and applications users can access

and applying controls to enforce those decisions

■ Accounting—tracking which resources users actually access

AAA allows you to centralize these functions and standardize policies throughout a network. A AAA server makes decisions that edge devices—in AAA, called network access servers (NASs)—enforce.

The NASs and AAA servers communicate using a AAA protocol, of which the two most common are:

■ Remote Access Dial-In User Service (RADIUS)

■ Terminal Access Controller Access Control System Plus (TACACS+)

This guide focuses on RADIUS because it is compatible with most other access control mechanisms.

Network Access Control Technologies

Access Control Concepts

Authentication

Authentication is the process by which a device determines the identity of a user connecting to a network or attempting to access a resource.

Authentication Factors. A human can identify another human in many different ways: by a name, a face, an ID badge, or knowledge of a certain piece of information. And a human can rely on his or her judgment to inform the identification. In the networking world, authentication boils down to a user submitting certain information that an authentication server uniquely associates with that user.

However, the information submitted can take several forms, or factors:

■ Something the user knows—The user submits a password, which the

authentication server has already associated with the user’s name (also submitted during authentication). Assuming that no one else knows the password, the server equates a correct password with an authentic user.

Although relatively easy to deploy, this factor is also the least secure. Users may write down their passwords where anyone can find them; they may tell them to friends and family members; they may select easily guessed passwords. In addition, passwords that are not changed often enough can be cracked, and passwords submitted or stored in an insecure manner can be hijacked.

Still, steps have been taken to address these issues. Databases often store passwords in non-reversibly encrypted form; users may be required to choose non-dictionary passwords and to change passwords frequently. In addition, most authentication protocols require users to submit passwords in encrypted form. You need to consider these issues when you select an authentication protocol because, implemented correctly, passwords are still often a good choice for credentials. (For more information, see “Authentication Protocols” on page 1-23.)

■ Something the user has—The user owns a physical object, such as a

token card or smart card, that identifies him or her, usually by storing credentials that cannot be compromised without destroying the device.

The stored credentials often take the form of a private key/digital certificate. The private key “signs” data to prove that the user, who is identified in the associated digital certificate, is the source of the data.

Instead of being installed on a smart card, the private key/digital certificate can be stored directly on a user’s endpoint. In this case, owning the endpoint (with installed certificate) is what proves the user’s identity.

1-7

Access Control Concepts

Network Access Control Technologies

Unfortunately, although forging these physical devices is difficult, the devices can be lost or stolen. A user might also allow someone else to access his or her endpoint—in fact, this might be a common practice in your organization. Once an unauthorized user possesses the necessary device, he or she can access the network easily.

■ Something the user is—The previous two factors associate individuals

with more or less arbitrary credentials. An increasingly important authentication factor, biometrics attempts to equate users and their credentials, which are physical characteristics, including voice, face geometry, fingerprints, hand geometry, handwriting dynamics, iris pattern, and retinal pattern.

In theory at least, a person’s physical characteristics are unique—and so unalterable and irreproducible. However, to live up to theory, biometrics require sophisticated, and often expensive, equipment. Privacy concerns also cause biometrics to be, while the most secure factor, also the least commonly used.

Each of these factors provides greater security when combined with another for two-factor authentication. For example, a smartcard or certificate installed on an endpoint becomes secure when combined with a password. Even if an unauthorized user seizes control of the device, he or she cannot use it without the correct password.

1-8

Authentication Protocols. An authentication protocol defines the procedure for submitting credentials to the authenticating device (typically, a network server).

RADIUS authentication comes in three forms, each of which uses a protocol developed for point-to-point connections:

■ Password Authentication Protocol (PAP)

■ Challenge Handshake Authentication Protocol (CHAP)

■ Extensible Authentication Protocol (EAP)

You’ll learn more about these protocols and their role in network access control in “Authentication Protocols” on page 1-23.

Authorization

Authorization builds on authentication. Authorization determines which network resources an authenticated user is granted rights to access.

Network Access Control Technologies

Access Control Concepts

Note You can also configure the network to authorize unauthenticated users for

certain—typically, very limited—rights.

In addition to considering whether a user has authenticated successfully, a AAA server assigns rights based on user identity and time and location of access. In other words, authorization is the mechanism that customizes a network for different types of users, providing each user with appropriate network access, rather than blanket “all or none” access.

Therefore, authorization is a particularly important component of a network access control solution. The authorization aspect of network access control also removes some of the burden from data and application access control. For example, you could set up “all or none” access to the network and then control access to application servers separately on each server. But a better solution often adds centralized network access control policies that grant users rights to appropriate services when they first access the network, preventing unauthorized traffic from ever reaching servers.

Authorization rights that are set up on AAA server are often called dynamic or user-based settings because they are assigned to individual users automatically when they connect to the network.

Rights determine:

■ Which resources and services the user can and cannot access—Typically,

you enforce these rights with Virtual LAN (VLAN) assignments and access control lists (ACLs).

Note ProCurve Identity Driven Manager (IDM) will help you set up your polices

more efficiently, as described in “ProCurve IDM” on page 1-58).

As much as possible, you place resources necessary for a particular group of users in the same VLAN. ACLs, applied to routers or to edge devices, permit only the appropriate user groups access to the VLAN in question. For example, if the server with your payroll database were placed on VLAN 7, you would restrict access to this VLAN: you would allow only users in the Accounting group—thereby preventing unauthorized employees from browsing the company payroll.

You can also use rights (specifically, dynamic ACLs) to control which types of services and applications users can access. TCP and UDP, two Transport Layer protocols, assign various applications to specific ports. For example, Web traffic uses TCP port 80 whereas File Transfer Protocol (FTP) traffic uses TCP port 21. To limit a set of users such as guests to browsing Web sites, simply restrict their traffic to TCP port 80.

1-9

Access Control Concepts

Network Access Control Technologies

■ Other settings for the connection such as rate limits and quality of service

(QoS) settings

These settings affect how a user accesses network resources, rather than which resources a user accesses. For example, you can limit a user to 10 Mbps of bandwidth, or you can assign guest users’ traffic low priority.

Accounting

Accounting, the third AAA function, collects information from NASs about users and their activities.

At a minimum, accounting logs users’ authentication requests, creating a record of who has logged in to the network (initial request) and logged out (final request). Just as important for network security, NASs log rejected authentication requests, clueing you in to potential attempts to infiltrate the network.

Accounting reports include information about access requests such as:

■ Username

■ Date and time

■ Transaction type

■ NAS ID

■ User location (for example, the NAS port ID)

■ Amount of data exchanged (reports on ongoing or terminated

connections)

1-10

Although tracking users as they log in and out of the network is important, it is equally important to monitor what they actually do on the network. Many NASs also send periodic reports on connected users, which update the accounting server on the resources that the user has accessed during that period.

A security analyst (usually aided by a security solution) can analyze accounting logs to:

■ Establish a baseline for normal network activity, which can be used for

resource planning and for comparison with future network activity

■ Check for suspicious activity (for example, significant deviations from the

normal activity baseline or multiple rejected access requests)

■ Trigger preemptive action to address suspicious behavior (for example,

shutting down the source port generating rejected requests)

■ Create reports that demonstrate compliance with regulations such as the

Sarbanes-Oxley Act

Network Access Control Technologies

Access Control Concepts

Accounting also enables billing; the accounting logs are forwarded to a billing server, and users are charged for the bandwidth and resources they have consumed.

Network Access Control Architecture

Before turning to methods for implementing a network access control solution, let’s consider the roles network devices play. There are many access control technologies; fortunately, the same basic architecture is used for all of them.

Based on definitions in the Internet Engineering Task Force (IETF) standard for policy-based management, this architecture comprises four logical elements:

■ Endpoint

■ Policy enforcement point (PEP)

■ Policy decision point (PDP)

■ Policy repository

(See Request for Comments [RFC] 3084 and 3198 at http://http://tools.ietf.org/ html/.)

Endpoint

The endpoint is the entity attempting to gain access to the network. Usually a computer (workstation or laptop) or personal digital assistant (PDA), the endpoint can also be a printer, scanner, or any device with a network interface card (NIC).

Note Endpoints are sometimes called stations or clients. This guide will always use

the term endpoint to avoid confusion.

Policy Enforcement Point (PEP)

Acting as the gatekeeper to the network, the PEP enforces access control on the endpoint, typically at the endpoint’s point of access. Thus, the PEP is often a switch or wireless Access Point (AP) at the edge of the network. It can also be a device such as the Wireless Edge Services Module, which controls several coordinated (or lightweight) APs, which ProCurve refers to as radio ports (RPs). In this case, the module is the logical point of access because the RPs encapsulate and forward all traffic to it.

1-11

Access Control Concepts

Network Access Control Technologies

NASs, which you learned about earlier in the AAA section, are also PEPs. The term NAS is typically used when discussing RADIUS. For consistency, however, this chapter will use the term PEP when discussing RADIUS.

The PEP has two roles:

■ Access request generator—Forces endpoints to provide basic informa-

tion about themselves (credentials) before accessing network resources. The PEP uses this information to compose an access request on the endpoint’s behalf.

■ Access decision enforcer—Enforces access decisions by opening or

blocking a port, assigning an endpoint to a particular VLAN, or applying other dynamic settings.

Because the PEP is responsible for initiating and enforcing the access control method, evaluating the PEP’s capabilities is often one of the first steps you should take when designing a network access control solution. This design guide focuses on the many capabilities offered by ProCurve Networking PEPs, which include both wired switches and wireless APs, as well as the Wireless Edge Services Module.

Policy Decision Point (PDP)

Simply put, the PDP makes access decisions. It has three roles:

■ Translator—Converts security policies into device-specific instructions

that PEPs can understand. The most basic instru ction is whether to enable or disable a port, but these instructions can include settings such as the VLAN for the port.

■ Resolver—Settles policy conflicts that arise as a result of divergent

request needs such as requests for a port to be assigned simultaneously to two VLANs.

■ Information aggregator—Collects information from PEPs for manage-

ment and monitoring purposes.

The typical PDP is an authentication server, which might be a software application installed on a computer, a stand-alone appliance, or even a server built into a PEP such as the Wireless Edge Services Module. An endpoint integrity solution, or network access controller, is also a PDP.

The PDPs discussed in this guide are:

■ RADIUS servers

■ Network access controllers

1-12

Network Access Control Technologies

Access Control Concepts

Identity-based management in the form of ProCurve IDM augments the standard PDP translator role. You will learn more about IDM in “ProCurve IDM” on page 1-58. For now, simply know that IDM helps the PDP factor user group, location, time, system, and—with the help of a network access controller—endpoint integrity into its decisions. Based on these inputs, IDM can provide policy instructions to the PEP in the form of various dynamic settings.

The section below gives some examples of RADIUS servers. You will learn about network access controllers in “Endpoint Integrity” on page 1-36.

Examples of RADIUS Servers. ProCurve solutions have been verified with several RADIUS servers:

■ Microsoft IAS (Windows Server 2000/2003)—Microsoft’s version of

a RADIUS server, Internet Authentication Server (IAS), is bundled with Windows 2000 Server and Windows Server 2003. In most cases it makes sense for an organization that runs a Windows domain to use IAS as the RADIUS platform. For organizations that rely heavily on Active Directory, the tight integration between IAS and Active Directory facilitates deployment and administration. Note, however, that the tight linkage between IAS and Active Directory can be a drawback, especially when using MACAuth, an access control method described later in this chapter.

■ Juniper Steel-Belted Radius—Steel-Belted Radius server provides

additional functions and flexibility beyond that provided by IAS. LDAP support allows the server to communicate with Active Directory content. But because the RADIUS server is not as closely integrated into Active Directory, it can use other credential stores instead, such as UNIX Network Information Services (NIS), token-based servers (RSA, CRYPTOCard), SQL database, or even another RADIUS server. In addition, SteelBelted Radius is not limited to running on Windows platforms: it can also run on NetWare or Solaris, or as a hardware appliance.

■ ProCurve NAC 800—The NAC 800 can act as your network’s RADIUS

server. It supports RADIUS as a stand-alone access control solution, or it can integrate its RADIUS capabilities with endpoint integrity checking.

■ Built-in server on a PEP—ProCurve Networking offers several wireless

devices that feature their own internal RADIUS server. Since authentication (particularly 802.1X) is key to security in the wireless world, these built-in servers are ideal for small-to-medium businesses that want to add wireless networking without compromising security.

The following ProCurve edge devices feature built-in RADIUS servers:

• Wireless Edge Services Module (xl and zl)

•AP 530

1-13

Access Control Concepts

Network Access Control Technologies

Policy Repository

The policy repository stores policies that the PDP draws on to make decisions. Stored policies include access criteria for users such as username and password, valid MAC address, IP address, location, and time of day. Usually network policies are stored as sub-elements within a directory that contains other policy-related information such as user credentials (username/password combinations) and device or network information. A PDP might also store some of these policies itself and refer to a directory server for user credentials.

For a PDP to perform its AAA functions, it needs access to the policy repository. The policy database may be either local (on the same system as the PDP server) or remote (on a different system on the network).

Local Policy Repository. A local policy database can be as simple as a flat file under control of the PDP server, or it can be a more complex local database such as a SQL database or a UNIX password file.

Remote Policy Repository. Remote policy databases are generally superior to local databases because they tend to scale better and offer a central control point for management. They do, however, require additional upfront effort to deploy. That objection may be academic if your organization already has a distributed policy infrastructure in place.

1-14

The most common form of a distributed policy database is a directory service. A server that implements directory services identifies all network resources, such as users, servers, peripheral devices, and the policies for dealing with them. In a Microsoft Windows domain, the user and policy database is Active Directory. Other directory services include Novell eDirectory and OpenLDAP.

A PDP such as a RADIUS server can use a directory service in conjunction with a local policy repository. For example, the RADIUS server might query the directory service to check user credentials. After authenticating the user, the RADIUS server must decide for which rights that user is authorized under the current conditions. It checks policies that, while they might originate from the remote repository, might be stored locally instead.

Network Access Control Technologies

Access Control Concepts

Network Access Control Process

Figure 1-1 shows the typical components of the network access control architecture.

Figure 1-1. Network Access Control Architecture

You will learn more about how the four components interact in discussions of specific network access control technologies. For now, you should simply be familiar with the vocabulary and the most basic process:

1. An endpoint attempts to gain access to the network.

2. The PEP requests and receives the user’s credentials from a utility on the endpoint.

3. With the credentials, the PEP composes an access request, which it forwards to the PDP.

4. The PDP seeks information about the user from the policy repository. On the basis of this information, it decides whether or not to authenticate the user.

With IDM, the PDP can factor additional criteria (such as location, time, and user group) into the decision.

1-15

Access Control Concepts

Network Access Control Technologies

5. If it authenticates the user, the PDP draws on additional policy information from the repository to authorize the user for particular resources. It then generates device-specific configuration instructions (such as the VLAN for the port) for the PEP.

6. The PEP configures its ports according to the instructions from the PDP. The user’s endpoint receives the appropriate level of access.

Authentication-Based Network Access Control Methods

This section describes the three most common methods for enforcing network access control at the edge. Built on the architecture described in the previous section, these methods hinge an endpoint’s level of network access on a PDP’s decisions. These decisions are, in turn, based primarily on the validity of credentials submitted by the user but perhaps on other policies as well.

The three methods are:

■ MAC authentication (MAC-Auth)—allows access based on the end-

point’s MAC address

■ Web authentication (Web-Auth)—allows access based on credentials

submitted in a Web page

■ 802.1X—allows access based on credentials exchanged via Extensible

Authentication Protocol (EAP)

1-16

802.1X is the most secure option. However, for reasons explained in the rest

of this guide, another method might meet your requirements. You can also implement different methods in different areas of your network or begin by enforcing a less secure method and eventually migrate to 802.1X. Chapter 3: “Designing Access Controls” will give you more guidelines for your design.

MAC-Auth

MAC-Auth identifies an endpoint by its MAC address, a unique 48-bit hardware address assigned to the network interface card (NIC) by the manufacturer at production. MAC-Auth identifies hardware, not users—one reason that this method is sometimes downplayed in contemporary security solutions.

MAC-Auth does not require any special capabilities on the endpoint nor any user interaction. The PEP is entirely responsible for generating authentication requests. The PDP makes an access control decision based on the endpoint’s MAC address, and the PEP enforces the decision by allowing or blocking traffic from the address accordingly.

Network Access Control Technologies

Access Control Concepts

In theory, a MAC address is unique and unalterable and therefore a good choice for identifying whether the endpoint should be allowed access. In practice, however, an attacker can spoof a MAC address relatively easily.

If you are using IAS, you might encounter another problem. MAC addresses do not conform to the rules for a typical user account. You must create an entirely new set of pseudo-user accounts, which can be tedious and might introduce security vulnerablities.

Despite its flaws, MAC-Auth remains the only choice for devices that have neither user interfaces nor support for 802.1X.

Note A device without a user interface may still support 802.1X. For example, many

Voice-over-IP (VoIP) phones support EAP-Subscriber Identity Module (SIM) and include smart cards automatically configured with authentication credentials. In addition, some Hewlett-Packard (HP) printers support 802.1X.

Process. An endpoint follows this process to connect to a network that enforces MAC-Auth:

1. The endpoint connects to a PEP and begins generating traffic, typically Dynamic Host Configuration Protocol (DHCP) requests.

2. The PEP observes that the traffic’s source MAC address is unauthenticated, so it drops the traffic.

3. The PEP generates an access request specifying the source MAC address as the username, and, as the password, either the same MAC address or a password configured on the PEP. The request also contains other information, such as the port, time, and so forth. The PEP forwards the request to an authentication server.

4. The authentication server, acting as the PDP, verifies the MAC address against its own or a centrally managed data store. The authentication server may also retrieve policy information, such as rules for the times that the MAC address is allowed on the network or rules that specify authorization instructions (for example, a VLAN assignment).

5. The authentication server returns an accept or deny response to the PEP that is based on the results of step 4.

6. The PEP reconfigures itself dynamically to forward or block all traffic from the MAC address depending on the access decision. If the accept response included authorization instructions, the PEP configures itself to enforce them—for example, assigning the endpoint’s port to the specified VLAN.

1-17

Access Control Concepts

Network Access Control Technologies

1-18

Figure 1-2. The MAC-Auth Process

Local MAC-Auth. ProCurve Networking’s Adaptive Edge Architecture (AEA) emphasizes control from the center—centralized policies enforced by edge devices. Centralizing policies saves IT staff time and ensures users a consistent network experience. However, an organization with a very small network might impose network access controls set up entirely on the edge device.

With local MAC-Auth, the PEP also acts as the PDP. It stores a local list of valid MAC addresses (a white list) or prohibited addresses (a black list) and controls access to its ports accordingly.

Network Access Control Technologies

Access Control Concepts

Web-A uth

Like MAC-Auth, Web-Auth enables end-users to authenticate and connect to the network without special utilities or configurations on their endpoints. The endpoints require a Web browser only. However, unlike MAC-Auth, a user must participate in the authentication process, entering credentials—a username and password—in a Web page.

The network access control decision is based on the validity of the username and password. The PEP enforces the decision by binding these credentials to the source MAC address; it then allows or blocks traffic from this address based on the success of the request that is generated from these credentials.

Process. The exact process by which an end-user authenticates and connects to the network depends on the Web-Auth implementation on the PEP.

In general, these steps occur:

1. The user’s endpoint connects to a PEP. The PEP might allow the endpoint to transmit certain background traffic such as DHCP and Domain Name System (DNS) requests, or the PEP might assign the endpoint a DHCP address itself.

2. The user opens a Web browser, and the PEP redirects the browser to the Web-Auth login page, which might be stored on the PEP or on a private Web server.

3. The user enters and submits credentials (username and password) as instructed on this login page.

4. The PEP receives the user’s credentials and records the MAC address of the endpoint that sent them. The PEP generates an access request containing the user’s credentials as well as other information about the access attempt and forwards the request to the authentication server.

5. The authentication server, or PDP, verifies the username and password against its own or a centrally managed data store. The authentication server may also retrieve policy information, such as rules for the times the user is allowed on the network or rules specifying authorization instructions (for example, a VLAN assignment).

6. The authentication server returns an accept or deny response to the PEP, based on the results of step 5.

1-19

Access Control Concepts

Network Access Control Technologies

7. The PEP reconfigures itself dynamically to forward or block all traffic from the MAC address associated with the request, depending on the access decision.

If the accept response included authorization instructions, the PEP configures itself to enforce them—for example, assigning the user’s port to the specified VLAN.

Some Web-Auth implementations allow rejected (or not-yet-authenticated) users to access an “Allow list” of Web sites.

1-20

Figure 1-3. The Web-Auth Process

Network Access Control Technologies

Access Control Concepts

802.1X

The industry-standard Institute of Electrical and Electronics Engineers (IEEE) 802.1X protocol provides the most secure form of network access control. Its standardized framework enables vendor-neutral implementations.

802.1X binds the state of a user’s port (open or closed) to the user’s authenti-

cation state—ensuring that users are properly identified and controlled as soon as they connect to a network.

Process. An endpoint follows this process to connect to a network that enforces 802.1X authentication:

1. The endpoint, which is running an 802.1X supplicant, establishes a DataLink Layer connection to the PEP:

• An Ethernet cable is plugged into a switch and the link opens.

• A wireless endpoint associates with a wireless AP.

Note The 802.1X supplicant is usually running on an endpoint, as described in these

steps. However, network infrastructure devices can also have supplicants, enabling them to authenticate to the network. For example, you might impose

802.1X authentication on all switch ports, even those to which APs connect.

You would then configure the 802.1X supplicants on legitimate APs so that they could authenticate to the network and be granted access. Rogue APs, on the other hand, would be denied access.

2. The PEP shuts down the connection to all traffic except EAP authentication messages. It sends an EAP challenge to the endpoint’s 802.1X supplicant.

3. An 802.1X supplicant returns an EAP message that typically contains its username. The PEP proxies the supplicant’s response to the authentication server and the server’s reply back to the supplicant, thereby creating a logical connection between the supplicant and the authentication server.

4. Within this logical data tunnel, the supplicant and the authentication server exchange authentication information. The exact process, as well as the type of credentials exchanged and the security of the tunnel, depends on the EAP method, which you will learn about later.

5. The authentication server verifies the user’s credentials against its own or a centrally managed data store. The authentication server may also retrieve policy information, such as rules for the times the user is allowed on the network or rules specifying authorization instructions (for example, a VLAN assignment).

1-21

Access Control Concepts

Network Access Control Technologies

6. The authentication server returns an accept or deny response to the PEP, based on the results of step 5.

7. The PEP keeps the port shut or opens the port to all traffic depending on the access decision.

If the accept response included authorization instructions, the PEP configures itself to enforce them—for example, assigning the user’s port to the specified VLAN.

You can optionally configure some PEPs to open the port to rejected users but assign those users to a VLAN with limited access to the network (the unauthorized VLAN).

1-22

Figure 1-4. The 802.1X Process

Network Access Control Technologies

Access Control Concepts

Authentication Requirements

Access control methods may impose some requirements on the endpoints:

■ MAC-Auth—None

■ Web- Auth—Web browser interface and user interaction

■ 802.1X—802.1X supplicant

The following Windows OS versions include a native 802.1X supplicant:

•Windows Vista

•Windows XP

• Windows 2000 SP4

Mac OS 10.3 also provides native support for 802.1X. The OpenX project has developed the Xsupplicant for Linux systems.

An 802.1X supplicant can also be installed on an endpoint as software from a third-party vendor. In addition, many vendors of wireless NICs include a wireless client with an 802.1X supplicant as part of the product. You must also consider which EAP methods the endpoint’s 802.1X supplicant supports.

Typically, 802.1X requires some form of user interaction; however, some smartphones and printers are 802.1X capable. These devices include supplicants that automatically submit credentials such as a SIM or digital certificate.

Authentication Protocols

Users and authentication servers communicate through authentication protocols, which dictate the process of submitting credentials. You’ve already learned a little about authentication protocols as they play a role in the three access control authentication methods.

You should understand these protocols in more detail:

■ Password Authentication Protocol (PAP)

■ Challenge Handshake Authentication Protocol (CHAP)

■ Microsoft CHAP (MS-CHAP) version 2

■ EAP

■ RADIUS

1-23

Access Control Concepts

Network Access Control Technologies

PAP

PAP is a simple protocol: the endpoint sends an authenticate request that includes the username and password in plaintext. The authentication server compares the password to the one stored for the user, and if the passwords match, the server grants the user access (as long as other policies allow the user access at that time and location).

PAP opens several security vulnerabilities—the most crucial one that the password is sent in plaintext and can be intercepted. In addition, PAP does not provide mutual authentication. Because the authentication server does not prove its identity to the supplicant, an attacker can pose as a legitimate server and steal the user’s credentials.

PAP is rarely used in contemporary networks. However, a PEP submitting a MAC-Auth or Web-Auth request on behalf of an endpoint might use RADIUSPAP, a slightly more secure protocol. (See “RADIUS” on page 1-28.)

CHAP

Although, like PAP, CHAP relies on usernames and passwords, CHAP provides greater security because the password is not sent in plaintext. Instead, the endpoint submits a one-way hash of the password and a challenge value randomly selected by the authentication server.

1-24

To prevent hackers from simply capturing and re-sending the hash of a user’s password (called a playback or replay attack), different challenges include different values. To recalculate the hash of the password with various challenge values, the authentication server must be able to extract the password. Therefore, the database must store the password in plaintext or reversible encrypted form. This requirement excludes CHAP from networks using certain types of authentication servers or directories.

Another disadvantage of CHAP is that it does not provide mutual authentication. In addition, while the one-way hash protects the password from casual eavesdroppers, it is susceptible to dictionary attacks and password-cracking software.

Again, while CHAP is rarely used in contemporary network, PEPs might use RADIUS-CHAP to submit MAC-Auth or Web-Auth requests.

Network Access Control Technologies

Access Control Concepts

MS-CHAPv2

The most common version of CHAP used in contemporary networks is MSCHAPv2. MS-CHAPv2 builds on the basic CHAP process, but adds several capabilities. First, MS-CHAPv2 provides mutual authentication, which protects users and their credentials from hackers that pose as legitimate servers.

MS-CHAPv2 also enables more sophisticated controls over the authentication process. For example, the authentication server can limit the number of times an endpoint can attempt to authenticate. It can also force users to periodically change their passwords and explain to users why their authentication failed.

EAP

EAP establishes a standardized framework for authentication protocols. The first EAP request and response packets initiate the authentication process. Subsequent packets are EAP method packets, which essentially encapsulate other authentication protocols. (When selecting an EAP type, you must ensure that both the RADIUS server and the 802.1X supplicant that runs on the endpoint support that EAP type. For more information about supplicants, see “Authentication Requirements” on page 1-23.

Note You will probably use EAP in an Ethernet network; this particular brand of

EAP is more precisely called EAP over LAN (EAPOL). However, this design guide follows common usage and refers simply to EAP.

Because EAP can encapsulate any authentication protocol as an EAP method, it provides flexibility. New methods can be developed to meet new needs; all methods fit within the standard framework, so you can choose the ones that meet your security requirements.

EAP methods range from relatively insecure to very secure and from simple to complex to deploy. You should familiarize yourself with the most common EAP methods, all of which are non-proprietary, so that you can make informed choices for your network.

Note Although EAP can encapsulate any authentication protocol, only the proto-

cols that pass Internet Assigned Numbers Authority (IANA) screening are designated as registered EAP methods and assigned a standard EAP number. As of early 2007, IANA recognized more than 40 EAP registered authentication protocols. Many of these are vendor-specific protocols that implement proprietary authentication schemes.

1-25

Access Control Concepts

Network Access Control Technologies

EAP-Message Digest 5 (MD5). EAP-MD5 is a base-level authentication protocol similar to CHAP; for credentials, an endpoint submits a one-way hash of a random challenges and its password.

This method has the advantage of simplicity, which makes implementation and configuration straightforward. But, like CHAP, it is vulnerable to:

■ Automated cracking tools and dictionary attacks

■ Attackers that pose as the authentication server and steal credentials

Thus, EAP-MD5 affords only a low level of protection and is not regarded as suitable for wireless networks. Another reason this method is unsuitable for wireless networks is that it does not provide material necessary for generating encryption keys and securing the connection.

Lightweight EAP (LEAP). A Cisco proprietary EAP method, LEAP authenticates users by means of passwords; it also provides keying material, which is important for wireless networks. However, although LEAP provides mutual authentication, it is vulnerable to man-in-the-middle attacks and is not recommended.

EAP-TLS (Transport Level Security). EAP-TLS is highly secure because it uses public key infrastructure (PKI) digital certificates for authentication credentials. It also provides mutual authentication: both the supplicant and the server must possess valid certificates.

1-26

EAP-TLS is impervious to the attacks that affect EAP-MD5 but can be difficult to implement. Managing significant numbers of certificates requires specialized software and human expertise, which makes EAP-TLS substantially more expensive than password-based methods.

EAP-Tunneled TLS (TTLS). Created by Funk Software as an extension to EAP-TLS, EAP-TTLS removes the obstacle of certificate management.

Like EAP-TLS, EAP-TTLS enforces mutual authentication. But with EAPTTLS, only authentication servers, not supplicants, authenticate with digital certificates, reducing the number of necessary certificates perhaps a thousandfold. For this reason, EAP-TTLS is significantly easier to deploy than EAP-TLS.

Although supplicants authenticate with usernames and passwords, EAP-TTLS preserves much of the security of EAP-TLS by establishing a two-step procedure for tunneling those credentials.

Network Access Control Technologies

Access Control Concepts

In the first step—the initial TLS handshake—the server authenticates to the supplicant. The two devices use the public key in the server certificate to exchange cipher keys and create a symmetric encryption tunnel. In the second step—the secondary handshake—the supplicant submits credentials over the secure tunnel using a secondary authentication protocol.

The secondary protocol can be another EAP method, but is typically a form of the RADIUS CHAP/PAP protocols (see “RADIUS” on page 1-28). You can use a relatively insecure—but easy to implement—secondary protocol because the tunnel secures the messages.

The encryption tunnel is maintained only for the duration of the secondary handshake; once the handshake is complete, the tunnel is destroyed.

Protected EAP (PEAP). PEAP is Microsoft’s extension of EAP-TLS and is very similar to EAP-TTLS. Like EAP-TTLS, PEAP uses a two-step authentication architecture, in which the supplicant and server create a symmetric tunnel over which the supplicant then sends its credentials.

Unlike EAP-TTLS, EAP-PEAP does not support the RADIUS CHAP/PAP protocols; it generally supports MS-CHAPv2 instead. The level of security, however, is approximately the same.

EAP-Subscriber Identity Module (SIM). A SIM is a smart card installed on a mobile device, which stores the device’s unique International Mobile Subscriber Identity (IMSI) and authentication key (Ki). The SIM uses the IMSI and Ki to authenticate, in a secure manner, to an authentication server, authentication server, which has access to a database of legitimate IMSIs and the corresponding Kis. The SIM might also negotiate encryption keys with the authentication server to secure future transmissions.

EAP-SIM is primarily used as a secure authentication method for headless devices such as wireless phones.

EAP-Generic Token Card (GTC). While EAP-GTC is similar in design to EAP-MD5, this method was originally designed to work with token cards, devices that store one-time passwords (OTPs), which are less susceptible to cracking than traditional, static passwords. However, EAP-GTC can be used with a traditional password, in which case it is vulnerable to many of the attacks to which EAP-MD5 is also prey. In contemporary networks, EAP-GTC is most often used as the inner protocol for EAP-TTLS or PEAP.

1-27

Access Control Concepts

Network Access Control Technologies

RADIUS

As mentioned earlier, RADIUS is an industry-standard protocol for providing AAA services. However, this section describes the RADIUS protocol in its most limited sense, as the standard for communications between PEPs (devices such as switches and APs that offer users network access) and RADIUS servers (the authentication and possibly accounting server).

RADIUS Messages. A PEP sends two types of messages:

■ Access request—The PEP requests authentication and authorization for

a user attempting to connect to the network.

■ Accounting request—The PEP transmits accounting information to the

RADIUS server. For example, the PEP sends an accounting message when it connects a user to the network. This message both acknowledges the message sent by the RADIUS server that allowed the user to connect and also provides more information about the connection.

The RADIUS server sends four types of messages:

■ Access challenge—The server responds to access requests, necessary

when it requires more information from the user, needs to resolve incomplete or conflicting user information, or wants the user to retry authentication.

■ Access accept messages—The server responds to access requests,

informing the PEP that the user is authenticated, and optionally specifying additional authorization instructions such as the user’s VLAN assignment.

■ Access reject messages—The server responds to access requests,

informing the PEP that the user failed authentication.

■ Accounting responses—The server acknowledges accounting requests.

1-28

As a UDP protocol, RADIUS is stateless and connectionless. That is, servers and PEPs can send each other messages without first setting up the conversation. By default, PEPs send access requests on UDP port 1812 and accounting messages on UDP port 1813, and RADIUS servers listen on these ports. However, you can configure some devices to send and listen on private ports.

RADIUS Attribute-Value Pairs (AVPs). RADIUS messages consist of a header and zero or more AVPs, which contain various types of information. For example, AVPs in access-request messages specify users’ credentials and other information about where, when, and how the user is accessing the network. AVPs in access-accept messages, on the other hand, often communicate authorization instructions.

Network Access Control Technologies

Access Control Concepts

An AVP includes:

■ A name, which specifies the type of attribute—for example, “Username”

or “Tunnel-Private-Group-ID”

■ A value, which is the specific value for that attribute for this supplicant at

this time—for example, “Bob,” the name of the user who is attempting to connect, or “10,” the ID of Bob’s dynamic VLAN

The RADIUS protocol defines approximately 50 attributes, including:

■ Username

■ Password

■ Type of service request

■ NAS ID

■ NAS port ID

■ NAS IP address

■ Tunnel attributes for dynamic VLAN assignment:

• Tunnel-Medium-Type (value is 802 or “6”)

• Tunnel-Type (value is VLAN)

• Tunnel-Private-Group-ID (value is set to the VLAN assignment)

RADIUS also allows vendors to define their own AVPs, which are called vendor-specific attributes (VSAs).

Often you can implement network access control without VSAs. However, if you want to enforce dynamic ACLs, you must configure the proper VSAs. For example, standard AVPs suffice for assigning a guest user to a VLAN; on the other hand, you might need VSAs to limit the guest user rights to Internet via TCP port 80.

The AVPs for authorization instructions are stored in a policy repository, which, as you learned, might be on the RADIUS server itself or on a directory service. For example, eDirectory can include RADIUS extensions which define AVPs for directory objects. Other services, such as Active Directory, do not provide these extensions. You must set up the AVPs on the RADIUS server itself. Because such configuration can be complicated, ProCurve Networking recommends that you use IDM. (See “ProCurve IDM” on page 1-58.)

RADIUS and Other Authentication Protocols. Originally, RADIUS was designed to work with PAP and CHAP, and the protocol defines attributes specifically for PAP and CHAP passwords.

1-29

Access Control Concepts

Network Access Control Technologies

RADIUS-PAP and RADIUS-CHAP, while not very secure, are more secure than simple PAP and CHAP. For example, a PEP and a RADIUS server have a shared secret, which authenticates their messages to each other. The PEP also encrypts PAP passwords with this secret, lending a limited degree of security to PAP.

In addition to PAP and CHAP, the RADIUS protocol works with EAP. The EAP AVP contains an entire EAP packet, allowing a PEP to shuttle EAP messages between the supplicant and the RADIUS server within RADIUS packets.

802.1X relies on RADIUS and EAP.

Wireless Authentication

Authentication protocols and access control methods are more or less standardized; they function similarly whether implemented on an Ethernet port, a PPP connection, or a wireless (802.11) association. This does not mean, however, that the connection type is irrelevant to the design. Characteristics of a wireless network—particularly its open, shared medium—create vulnerabilities that you must factor into your design. This section equips you with the necessary knowledge about wireless technologies and protocols.

802.11

IEEE 802.11 is the Physical and Data-Link Layer standard for wireless connections. While most specifications in this standard are irrelevant to access control, you should understand how an 802.11 endpoint connects to a wireless AP.

1. The endpoint sends an 802.11 authentication request. (This request is sometimes referred to as the association request.)

2. The AP sends an 802.11 authentication success response.

Note The AP always allows 802.11 authentication to succeed because it should

enforce open authentication. When 802.11 was first adopted, it defined another option: shared-key authentication, which required wireless users to enter the correct password (actually, an encryption key). However, this authentication method included several major flaws and has since been denigrated.

3. The endpoint sends an 802.11 association request.

1-30

Network Access Control Technologies

4. The AP sends an 802.11 association response, and—if the response is “success”—the association comes up.

The AP usually sends an association success response.

However, if the AP implements MAC-Auth, it first extracts the MAC address from the association request and forwards it in an access request to a RADIUS server. The AP then sends a success or failure response depending on whether the RADIUS server accepts or rejects the request.

5. An active association is much like a connected Ethernet port. Unless a specific access control mechanism is enforced, the endpoint can send and receive any data.

The 802.11i amendment to the standard requires just such a mechanism: 802.1X.

In addition, encryption keys, while not part of a formal authentication scheme, can act as de facto access controls. In fact, these keys are commonly called passwords.

Access Control Concepts

Static Wired Equivalent Privacy (WEP)

WEP was designed to deliver the privacy of a wired connection to the shared wireless medium. It both protects users’ data and offers a measure of access control.

To protect data from eavesdroppers, the AP and wireless endpoints encrypt all traffic with the same shared key.

If a user specifies the wrong encryption key on his or her endpoint, the AP discovers the problem when it decrypts the traffic. It drops the traffic silently, effectively cutting off the user’s access.

Unfortunately, the WEP design includes several flaws, and widely available software can exploit these flaws to crack the shared key. Cracking the key requires at most about a million frames, which a hacker can collect over several hours in a reasonably busy network (particularly since all users share the same key).

Dynamic WEP

If you so desire, you can implement 802.1X for access control in a wireless network using WEP encryption. This option is called dynamic WEP because the RADIUS server not only handles authentication but also provides each endpoint with its own unique WEP key.

1-31

Access Control Concepts

Network Access Control Technologies

In terms of access control, dynamic WEP is quite secure. Dynamic WEP also provides better data protection: because each station has its own key, a hacker finds it much more difficult to collect enough keys to crack one.

Wi-Fi Protected Access (WPA)/WPA2, however, provides an even higher measure of security.

WPA/WPA2 and 802.11i

802.11i was developed to amend the flaws of WEP; however, it was not fully

adopted until 2004, several years after WEP was cracked. WPA, a Wi-Fi standard, emerged in the interim.

WPA meets the first part of the 802.11i standard, the specifications for the Temporal Key Identity Protocol (TKIP), which provides data privacy, and Michael, which provides data integrity. WPA2 meets the full standard, which calls for even more secure encryption via Counter Mode with CBC-MAC Protocol (CCMP) w ith Advanced Encryption Standard (A ES). These protocols provide privacy and integrity for data transmitted in the wireless network. A full discussion of the protocols is not pertinent to this design guide; it is sufficient to know that WPA/WPA2 is not susceptible to key-cracking tools.

In addition to providing encryption, WPA/WPA2 requires users to authenticate before joining the wireless network. This function is, of course, the most crucial to your access control design.

Under normal (sometimes called Enterprise) operation, WPA/WPA2 uses

802.1X authentication to control which users can connect. In this mode, WPA/

WPA2 affords all of the benefits that are associated with 802.1X on Ethernet connections:

■ Secure, per-user authentication

■ Choice of EAP method that meets your network’s security policy

■ Per-user rights received as dynamic settings from the authentication

server

If, for whatever reason, you do not want to implement 802.1X, you can still take advantage of WPA/WPA2’s highly secure encryption. The WPA/WPA2 Preshared Key (PSK) option allows users to enter a shared key (password) to authenticate to a wireless network that implements TKIP or CCMP/AES encryption. You can then add another authentication method (MAC-Auth or Web-Auth) or simply assume that the shared key provided sufficient access control for your purposes.

1-32

Network Access Control Technologies

Access Control Concepts

Access Control Rights—Dynamic Settings

The overview of “Authorization” on page 1-8 gave a few examples of how rights are assigned and enforced. Let’s now look in more detail at ways to control users’ access after they connect.

Keep in mind that you can set up these access controls in one of two ways:

■ Manually

■ Dynamically as a part of the AAA architecture—This guide will focus on

this option.

VLANs

VLANs divide users and other network devices into separate Layer 2 broadcast domains, each isolated and relatively secure from the others; they are a fundamental way to group and control users. Traffic cannot cross a VLAN (subnet) boundary unless forwarded by a router, which can filter the traffic appropriately with ACLs.

Traditionally, users are assigned to VLANs statically. That is, each user has a single port at which he or she is expected to remain, and the user’s port is actually assigned to the VLAN. If the user accesses the network through a different port, he or she might be in a different VLAN. And in a wireless network, all users that access the WLAN find themselves in the same VLAN.

The traditional model is no longer adequate for many networks because users access the network through many different ports. For example, although employees often connect to the network from the port at their desk, they might also connect from conference rooms or even a remote location. In addition, an AP, in the revolving-door wireless world, funnels a constantly shifting group of users to a single switch port.

Your access control design and your VLAN design interconnect because the network access control solution helps ports configure themselves for VLANs dynamically. When a user is authorized to connect to the network, he or she is also authorized for the correct VLAN, as determined by the authentication server and enforced by the PEP.

Here is another advantage of dynamic VLANs: you can create rules to assign users to different VLANs under various conditions. For example, you might create one VLAN for users accessing the network during work hours and a different VLAN for after-hours access.

1-33

Access Control Concepts

Network Access Control Technologies

A network typically includes VLANs such as these:

■ Management VLAN—This type of VLAN includes the IP addresses on

infrastructure devices through which you manage and configure those devices. It may also include the endpoints which network administrators use to access the infrastructures devices. On ProCurve devices, you can enable a Secure Management VLAN, which does not allow traffic to be routed in or out of it.

■ Default VLAN—This VLAN includes all devices connected to ports not

specifically assigned to another VLAN. If you implement network access control on all ports, you do not need to worry as much about securing the default VLAN. A method such as 802.1X prevents rogue users from connecting to unprotected ports.

Note Sometimes the management VLAN is also the default VLAN; you should

give the management VLAN a new ID to protect access to your network devices.

■ Unauthorized VLAN—In a network that implements port access con-

trol, the unauthorized VLAN fulfills some of the roles of a default VLAN. It is the VLAN into which users that fail authentication are placed, and is therefore sometimes called the guest VLAN. The unauthorized VLAN might allow access to the Internet or a limited list of private resources.

■ User VLANs—These VLANs include end-user devices. Best practices

dictate that you group end-users together according to resources and rights that they require. For example, a network administrator at a hospital might place all nurses and doctors in VLAN 16, subnet 10.1.16.0/22. The administrator can then create ACLs to allow traffic from that subnet to a database of patient information.

■ Server VLANs—These VLANs include servers and databases. Again, it is

easier to set up access controls when resources necessary to a particular group are placed in the same VLAN. For example, the hospital network administrator could group all databases that store patient information in VLAN 6 and allow communication between VLAN 6 and VLAN 16. Of course some servers, such as DHCP and DNS servers, might handle requests from several VLANs.

1-34

Of these types of VLANs, often only the user and perhaps management VLANs are set up dynamically. In a large or complicated network, you should strongly consider a solution such as IDM, which helps you quickly configure dynamic VLAN settings on all of your RADIUS servers. (See “ProCurve IDM” on page 1-58.)

Network Access Control Technologies

Access Control Concepts

Note In “Endpoint Integrity” on page 1-36, you will learn about solutions that test

endpoints for compliance with security policies. A network that enforces endpoint integrity might include additional VLANs:

■ Tes t VL A Ns —The VLANs in which endpoints are placed after they

connect to the network but before they are tested by the network access controller. A test VLAN can the same as the quarantine VLAN (described below) or its own VLAN. In either case, the VLAN should be rather restrictive.

■ Quarantine VLANs—The VLANs for endpoints that fail to comply with

the network’s security poli cies. A quarantine VLAN typically allows access only to resources necessary for bringing endpoints into compliance.

■ Infected VLANs—The VLANs for endpoints on which the NAC 800

detects viruses, trojans, or other malware. While you can place infected and quarantined endpoints in the same VLAN, you may want to separate them. Then infected endpoints do not spread malware to the not-yetinfected, but insecure quarantined endpoints.

These VLANs would be assigned to endpoints dynamically as part of the policies sent out the RADIUS server (which, if you are using the ProCurve NAC 800 could be the network access controller itself). Note, however, that some network access controllers use different methods to quarantine endpoints—methods that do not rely on VLAN assignments at all.

ACLs

A VLAN assignment ensures that a user receives an IP address in the correct subnet. ACLs control communications between subnets so that users in a particular VLAN receive access to the correct resources.

An ACL is a series of rules, or access control entries (ACEs) to which a network device compares every packet that arrives. Although ACLs can operate either at Layer 2 or Layer 3/4, this design guide focuses on Layer 3/4 ACLs. An ACE in such an ACL controls traffic according to a variety of fields in the IP header:

■ Protocol (TCP, UDP, Internet Group Management Protocol [IGMP], and

so forth)

■ IP source address

■ Source port

■ IP destination address

■ Destination port (for example, UDP 67 to allow DHCP traffic or 80 to allow

Web traffic)

1-35

Access Control Concepts

Network Access Control Technologies

If a packet’s IP header matches the ACE, the device treats the packet as indicated in the ACE, forwarding it (“allow”) or dropping it (“deny”).

In effect, the ACL controls which devices can access which other devices using which applications. For example, you want to allow devices in VLAN 100 to access a private Web server. In an “allow” ACE, you enter TCP for the protocol, specify the Web server’s IP address as the IP destination address, and 80 (HTTP) for the destination TCP port. Then you apply the ACL to the VLAN.

You can apply ACLs manually to VLANs and ports. But, as with VLAN assignments, network access control enables dynamic ACLs, which can authorize users for network resources at quite a granular level.

Due to the complexity involved in configuring dynamic ACLs on a RADIUS server, it is recommended that you use a solution such as IDM.

Endpoint Integrity

Endpoint integrity adds another component to an access control solution: users can only connect to your network using equipment that meets your standards for security.

Implementing endpoint integrity can be rather complex, encompassing concepts and processes that might be new to you. Although the industry is beginning to standardize on some concepts and , this process is ongoing. To the extent possible, this section describes the industry-wide concepts and terminology. It then provides specific examples based on the ProCurve NAC

800.

Endpoint Integrity Policies

An endpoint integrity policy dictates the criteria that an endpoint must meet to connect to the network. You can think of this policy as the section of your organization’s security policy that applies to end-user equipment.

The endpoint integrity policy consists of a precise series of tests which the network access controller runs on endpoints that attempt access. Each test searches for a specific setting and has a specific allowed result.

For example, the endpoint integrity policy might test the security settings for the Internet zone used by the endpoint’s Internet Explorer (IE). The policy enforces the security setting, such as Medium, for that zone; unless the endpoint’s setting is at or above Medium, the endpoint fails the test.

1-36

Network Access Control Technologies

Access Control Concepts

The policy also specifies the action taken when an endpoint fails the test. Most network access controllers generally quarantine the endpoint (see “Quarantine Methods” on page 1-42). Sometimes, however, network access controllers simply send an email message to notify the network administrator.

Different network access controllers support different tests. The ProCurve NAC 800 tests endpoints in ways such as these:

■ Security Settings

These tests examine an endpoint’s security settings, checking, for example:

• Enabled services

• Networks to which the endpoint connects

• Security settings for macros

• Local security settings, which determine how users are allowed to

access the endpoint

• Personal firewall status

■ Software

These tests check software that is installed on an endpoint. Some tests look for required software such as personal firewalls and anti-virus software. Other tests look for prohibited software such as file-sharing software. Another test scans for viruses and other malware.

■ Operating System

All OSs have vulnerabilities that hackers can exploit. The OS manufacturers distribute updates to close these vulnerabilities. Some tests examine a Windows endpoint’s OS to verify that all required hotfixes and patches are installed.

■ Browser Security Policy

These tests verify that an endpoint’s Web browser enforces the proper level of security for various zones (for example, on IES, Internet sites, local sites, trusted sites, and untrusted sites).

Pre-connect and Post-connect Testing

A network access controller may test endpoints at various points in the connection:

■ Pre-connect testing—This testing takes place before the endpoint con-

nects at all. It makes initial access to the network contingent on compliance with the endpoint integrity policy.

1-37

Access Control Concepts

Network Access Control Technologies

■ Post-connect testing—This testing takes place at set intervals through-

out the connection, ensuring endpoints continue to comply. Post-connect testing is a key component for complete endpoint integrity enforcement. Without it, end-users quickly learn that they can, for example, raise browser security settings, connect to the network, and immediately lower the settings again.

Testing Methods

To test an endpoint, a network access controller must collect information about the endpoint that the endpoint does not generally advertise about itself.

The mechanism that allows an endpoint to respond to tests is called an agent; the agent must be installed on the endpoint prior to testing. Agents fall into two general categories:

■ Permanent agents, which once installed remain on the endpoint perma-

nently

■ Transient agents, which install on the endpoint temporarily at the initia-

tion of each test

Instead of relying on an agent designed specifically for the endpoint integrity solution, a network access controller can leverage an application that is already installed on most endpoints. This option is called an agentless solution.

1-38

Permanent Agents. Perhaps the most straightforward approach for deploying agents is to manually install on each endpoint the agent specific to your network access controller. Some solutions, including the ProCurve NAC 800, also allow users to download and install the agent the first time the NAC attempts to test their endpoint.

Permanent agent-based solutions have several benefits:

■ Minimal impact on users—Once the agent is installed, testing occurs in

the background. As long as the endpoint meets the criteria for connecting, users might not even notice the testing.

■ Control—Permanent agents can sometimes automatically correct con-

figuration problems and open ports that need to be opened for testing.

■ Reduced bandwidth consumption—Installed permanently, the agent is

not downloaded through the network every time an endpoint is tested.

Network Access Control Technologies

Access Control Concepts

However, there are some drawbacks to using software-based agents:

■ Deployment—Installing the agent on each endpoint consumes time and

IT resources. Even if the user downloads the agent manually, that installation requires the one-time user interaction.

■ Memory consumed on endpoints—The agent remains on the endpoint

permanently, which does take memory. However, most agents are relatively small files.

Transient Agents. Manually installing the agent permanently on every endpoint is not always feasible, particularly for companies that must accommodate guests that bring their own devices.

Some solutions offer a modified agent-based solution that relies on a transient agent. This agent is installed on endpoints only for the duration of the compliance scan, which usually occurs when the endpoint first connects. The endpoint downloads the transient agent, an executable program often delivered through ActiveX. The agent then begins working with the network access controller to complete the compliance scan. When the scan is finished and the endpoint is declared compliant or non-compliant, the agent is erased from the endpoint. For this reason, transient agents are sometimes called “disposable” agents.

Transient agent-based solutions have several benefits:

■ Ease of deployment—Time and resources are saved because the solu-

tion itself manages the installation of the transient agent.

■ Control—Like a permanent agent, a transient agent is designed to work

with your network compliance solution, so it may be able to help the endpoint fix problems as specified by that solution.

But transient agent-based solutions are not without drawbacks:

■ Time to connect—Installing permanent agents on every endpoint may

be time consuming, but it is a one-time process for each individual endpoint. With transient agents, users must always wait for the agent to download before they can connect to the network. If your network enforces post-connect testing, the transient agent must download again every time the NAC tests the endpoint.

■ Imperfect deployment—Some endpoints still might fail to receive the

agent either because the user refuses the download or because the endpoint’s security policies prohibit downloading executable files.

1-39

Access Control Concepts

Network Access Control Technologies

Agentless. Agentless solutions use applications that are already available on the endpoint, such as Windows Management Interface (WMI), Simple Network Management Protocol (SNMP), or Microsoft Remote Procedure Call (RPC), to provide the agent functions.

Note The ProCurve NAC 800’s agentless option relies on RPC, which provides a

flexible framework for a variety of communications between remote devices, including endpoint integrity checks.

Agentless solutions have several benefits:

■ Ease of deployment—Time and resources are saved because agentless

solutions do not require users to install software on their endpoint. And you do not have to train users to set up their endpoints for testing: in most cases, the native applications that provide agent functions are already active.

■ Minimal impact on users and endpoints—In many cases, agentless

testing can proceed from beginning to end without any user interaction. In addition, the endpoint neither has to store a permanent agent nor download a transient agent.

You might, however, encounter issues with:

■ Unsupported endpoints—The endpoint must have the proper applica-

tion for the agentless solution to function.

■ Requirements on the application—The application enlisted to fulfill

the role of the endpoint integrity agent was not designed specifically for that purpose. To use the application, the network access controller must follow its rules. For example, RPC requires the network access controller to submit administrator credentials to the endpoint. For this reason, this agentless solution functions best on endpoints that are managed members of a Windows domain (all have the same credentials).

1-40

Combined Solutions. Some network access controllers offer multiple testing methods to accommodate various needs. The ProCurve NAC 800, in fact, provides all three.

Endpoint Requirements for Integrity Checking

The endpoint requirements for integrity checking depend almost entirely on the testing method implemented by the network access controller.

In general, the endpoint requires the following for each method:

■ Permanent-agent based—installation of an agent designed for the net-

work access controller

Network Access Control Technologies

Access Control Concepts

Note The NAC 800 allows endpoints to automatically download the NAC EI agent

the first time that they are tested—combining the ease of deployment of the a transient agent with the advantages of a permanent agent. However, the automatic download requires ActiveX.

■ Transient-agent based—Web browser with ActiveX and JavaScript

allowed in the security settings

Web browsers implement security in slightly different ways. Most Web browsers allow you to set up different settings for different Web sites. For example, the Web browser might generally prohibit ActiveX but allow it for the network access controller. The ProCurve Access Control Solutions Implementation Guide shows you how to set up various Web browsers.

■ Agentless—application such as:

•WMI

These Microsoft Windows OSs support WMI: – Windows 2000 –Windows ME – Windows Server 2003 –Windows XP

• SNMP agent

•RPC

All Windows OSs (Windows 95 and later) support RPC. The network access controller must know administrator credentials for the endpoint to successfully make use of RPC.

In addition, the endpoint’s security settings most not interfere with testing. In practice, this usually means that you must open ports in personal firewalls or other firewalls that stand between the endpoint and the network access controller. Often, however, agents will automatically open the correct ports without user interaction.

For example, the NAC 800 agent uses TCP and UDP ports 1500, and the agent automatically opens these ports on all personal firewalls (except a nonWindows firewall on an XP endpoint). However, you must open these ports on a router firewall manually.

1-41

Access Control Concepts

Network Access Control Technologies

Endpoint Integrity Posture

As a network access controller tests an endpoint, it assigns it a posture, depending on the results of the test:

■ Unknown—Not yet tested

■ Healthy—Passed all tests

■ Check-up—Failed at least one test but allowed temporary access

■ Quarantine—Failed at least one test (and a temporary access period, if

allowed, has expired)

■ Infected—Infected with malware such as a virus, worm, or spyware

The network access controller uses the posture to determine the action it takes (based on your particular configuration).

Quarantine Methods

Testing the endpoint determines whether or not it complies with your policies, but ascertaining compliance is only half the solution. The other half is taking action against non-compliant endpoints. Network access controllers typically quarantine non-compliant endpoints, isolating them from the main portion of the network.

1-42

While quarantined, endpoints have either no access to network resources or limited access. Resources made available to quarantined endpoints are often called remediation services because they help the endpoint become compliant. For example, quarantined endpoints might be allowed to contact a Web site for downloading patches.

Network access controllers quarantine endpoints in several different ways—not surprising because endpoints connect in different ways to networks with different architectures and capabilities. The three standard quarantine methods are:

■ 802.1X

■ DHCP

■ Inline

802.1X. As you should recall from earlier in this chapter, 802.1X is a standard

method for enforcing access control in Ethernet and wireless networks. It provides a framework for hinging the status of the endpoint’s access port (open or closed) to the end-user’s authentication status.

Network Access Control Technologies

Access Control Concepts

The network access controller enters the 802.1X framework as either an authentication server or a supplement to the authentication server. It inserts checking an endpoint’s integrity into the process of making access decisions.

For example, the network access controller detects and tests all endpoints when they first connect to the network. It then report the endpoints’ integrity posture to network RADIUS servers, which are configured with policies that take these postures into account. If necessary, the RADIUS server alters a user’s assignment and places him or her in a quarantine VLAN.

The ProCurve NAC 800 includes its own built-in RADIUS server, so it can provide both components of the solution.

DHCP. The DHCP quarantine method is designed primarily for networks with equipment that is not 802.1X capable. Any endpoint is allowed to connect to the network. However, the network access controller prevents non-compliant endpoints from receiving a valid IP address. Instead, these endpoints receive an address in the quarantine subnet, which has access only to remediation services.

With the DHCP deployment method, part of a network access controller’s role is acting as another PEP, quarantining non-compliant endpoints. Typically, you must position the network access controller correctly—between the DHCP server and the rest of the network.

Note An end-user who has the technical savvy to give his or her station a valid IP

address can circumvent DHCP quarantining. This is one reason that 802.1X is the recommended option for high security.

Inline. With inline quarantining, perhaps the most straightforward of the three options, a network access controller physically separates endpoints from network resources.

This option has the advantage of ease of setup as well as relatively high security. Because the network access controller literally stands between the endpoint and network resources, it can tightly control which endpoint traffic passes through it.

However, deploying a network access controller between every Ethernet workstation and its switch port is not a realistic option. And the further the network access controller is from the endpoint, the more resources the endpoint can access before it is tested. Inline quarantining is most viable when many endpoints connect to your network through a single point of access.

1-43

Access Control Concepts

Network Access Control Technologies

Examples include:

■ A VPN—Remote users access the private network through the Internet.

Each remote user sets up a secure tunnel with the network’s VPN gateway device. Checking the integrity of the remote endpoints is particularly important, because they are otherwise beyond your control.

■ A WAN—A WAN is a network that connects several sites over private

connections such as T1 or E1 cable or Asymmetric Digital Subscriber Line (ADSL) lines: for example, branch offices that connect to a company headquarters. For whatever reason, you might want to test the integrity of endpoints at a remote office before they connect to the segment of the WAN under your control.

■ A wireless network—A device such as the ProCurve Wireless Edge

Services Module controls many RPs and may provide thousands of wireless users with their access point to the network. Especially when the wireless users connect with their own equipment, the network should test their integrity.

The Wireless Edge Services Module and ProCurve APs support 802.1X authentication, and, for a wireless network that already uses 802.1X to authenticate users, you should choose the 802.1X quarantine option. However, some networks use an alternative such as WPA-PSK. In this case, inline quarantining provides a higher security option than DHCP.

Note that the NAC 800 is acting as a bridge so all traffic from the module or APs must be forwarded into the rest of the network in the same VLAN. If you require multiple VLANs and cannot use 802.1X, you should use the DHCP method rather than the inline method.

Note With the inline deployment method, the network access controller acts as PEP

as well as PDP. It physically stands between endpoints and network resources and enforces its decisions about which resources an endpoint can access.

1-44

Access Control Concepts

ProCurve NAC 800

You should now have a solid grounding in access control concepts, both those relating to authentication and those relating to endpoint integrity. Let’s turn to ProCurve’s network access controller, the NAC 800—a versatile solution that can provide both types of access control:

■ Endpoint integrity alone

■ RADIUS authentication alone

■ Endpoint integrity and RADIUS authentication integrated together

Depending on the services that you require, you can choose one of three deployment methods for your NAC 800; these deployment methods correspond to the three standard quarantine methods described in “Quarantine Methods” on page 1-42.

The following sections describe the variety of services provided by the NAC 800; they also walk you, step-by-step, through the processes by which the NAC 800 provides these services.

Note A particular NAC 800 provides different services based on its server type. You

will learn more about selecting the appropriate server types later. For now, these brief descriptions will help you follow the discussion below:

■ MS—A management server (MS) stores NAC policies and manages

enforcement clusters, which consist of multiple enforcement servers (ESs).

■ ES—An ES tests endpoints’ integrity and enforces access control

decisions.

■ CS—A CS acts as a stand-alone device, performing all MS and ES roles.

NAC 800 as an Endpoint Integrity Only Solution

The NAC 800 can make policy decisions based on endpoint integrity alone. It tests endpoints for compliance with security policies called NAC policies and decides whether to grant the endpoints network access or quarantine them.

1-45

Access Control Concepts

ProCurve NAC 800

A NAC policy consists of a list of tests. The NAC 800 provides a wide array of customizable tests, and Chapter 2: “Customer Needs Assessment” gives you some guidelines in choosing tests that meet your needs. The NAC policy also dictates whether an endpoint that fails a particular test should be quarantined immediately, quarantined after a grace period, or not quarantined at all. The NAC policy repository depends on the deployment:

■ The NAC policy is stored on the NAC 800 that runs the tests if that NAC

800 is a stand-alone device (a CS).

■ If the NAC 800 is part of a cluster, an MS acts as the repository for policies.

The ESs run the tests.

As an endpoint-integrity-only solution, the NAC 800 supports all three deployment methods. Let’s look at how those methods work in more detail.

802.1X Deployment

In an endpoint-integrity-only 802.1X deployment, the NAC 800 tests endpoints for compliance with the system’s NAC policies, but a different RADIUS server authenticates the users.

This RADIUS server must be an IAS server, which is configured to contact the NAC 800 after authenticating a user and request the integrity posture for the user’s endpoint. The IAS server then assigns the user to a test or a quarantine VLAN, if necessary.

1-46

Process for 802.1X Quarantining (Endpoint Integrity Only). The NAC 800 imposes this process to control an endpoint’s network access:

1. The endpoint establishes a Data-Link Layer connection to the PEP:

• An Ethernet cable is plugged into a switch, and the link opens.

• A wireless endpoint associates with a wireless AP.

2. The PEP shuts down the connection to all traffic except EAP authentication messages. It sends an EAP challenge to the endpoint’s

802.1X supplicant.

3. The endpoint returns an EAP message that typically contains its username. The PEP proxies this response to IAS and IAS’s reply back to the endpoint.

4. The endpoint and IAS exchange authentication information (proxied by the PEP) as dictated by the EAP method.

5. IAS verifies the user’s credentials (typically against Active Directory).

Access Control Concepts

ProCurve NAC 800

6. If the credentials are correct, IAS contacts the NAC 800 and requests the endpoint’s integrity posture. (You can learn how to configure the IAS server to do so in the ProCurve Access Control Implementation Guide.)

7. Initially, the posture is Unknown. IAS calls the SAIASConnector (a file installed on the IAS server). The connector should contain a policy that associates the Unknown posture with a test VLAN. IAS sends this VLAN assignment to the PEP.

8. Detecting the endpoint that has been placed on the test VLAN, the NAC 800 begins to check its compliance with NAC policies.

The NAC 800 needs to receive mirrored DHCP traffic on its port 2 to detect the endpoint.

Note In a cluster of ESs, any ES can test the endpoint; they share information

with each other.

9. When the testing is completed, the endpoint has gained a new posture. The NAC 800 sends a message to the PEP to force the user to reauthenticate.

10. Steps 2 to 7 repeat. Now, however, the user is assigned to a new VLAN based on its new posture:

• If the endpoint has the Healthy posture (complies with your policies)

or the Check-up posture (granted temporary access), the user receives his or her normal dynamic VLAN assignment.

• If, on the other hand, the endpoint has the Quarantine or Infected

posture, the user is placed in the quarantine or infected VLAN.

Network access in the quarantine and infected VLANs is limited, typically to remediation services, in one or several of these ways: – The endpoint is assigned (via dynamic settings) a rate limit and

list of accessible resources.

– The NAC 800 acts as the endpoint’s DNS server and redirects the

user’s Web browser away from all sites (except a limited list of accessible services).

– Network infrastructure devices might impose static ACLs on the

quarantine VLAN.

1-47

Access Control Concepts

ProCurve NAC 800

DHCP Deployment

With this deployment method, the NAC 800 intercepts and responds to endpoints’ DHCP requests, assigning them IP addresses on a quarantine subnet. It then tests endpoints for compliance with NAC policies. Healthy endpoints are allowed to receive DHCP addresses from the network DHCP server and are granted complete network access. Non-compliant endpoints, on the other hand, remain in the quarantine subnet.

In a cluster of NAC 800s, the devices might share roles between them. For example, one or two NAC 800 ESs act as PEPs, intercepting DHCP requests, while multiple NAC 800 ESs test the endpoints and decide whether they should be quarantined. All the ESs are controlled by an MS, which acts as the repository for NAC policies.

Process for DHCP Quarantining. The NAC 800 enforces this process to control a endpoint’s network access:

1. The endpoint connects to a switch port or associates to an AP. The PEP does not enforce an access control method on the port, so the Data-Link Layer connection activates.

2. The endpoint sends a DHCP message, requesting a valid IP address for itself, the IP address of its default gateway and DNS server, and all the other configurations necessary for full connectivity.

3. Network infrastructure devices forward the DHCP request to the DHCP server.

Note Exactly how the devices forward the request depends on the network

infrastructure.

In a network with a single VLAN, the devices flood the request as a broadcast. In a network with multiple VLANs, network infrastructure devices usually implement DHCP relay, routing DHCP requests to a helper address (the address of a DHCP server on another subnet). When you add a NAC 800 deployed with the DHCP method, you must configure two helper addresses: the network DHCP server’s and the NAC 800’s. The devices initially send DHCP requests to the first helper address, the network DHCP server’s.

4. The NAC 800, which is installed between the DHCP server and the server’s switch, intercepts the request. It decides how to handle the request based on the endpoint’s integrity posture.

1-48

Access Control Concepts

ProCurve NAC 800

Note By default the NAC 800 intercepts all DHCP requests. In a network that

uses DHCP relay, however, you can configure the NAC 800 to respond to only those requests with source IP addresses in the quarantine and nonquarantine subnets. (The source IP address originates from the DHCP relay device; the endpoint, of course, does not yet have one).

5. Initially, an endpoint has the Unknown posture. The NAC 800 sends a DHCP reply that has a configuration for the quarantine subnet.

Note The actual process differs slightly depending on whether your network

implements DHCP relay. The NAC 800 immediately replies to a broadcast DHCP request. On the other hand, it simply drops a relayed request destined to the network DHCP server. The DHCP relay device then sends a DHCP request to the NAC 800’s IP address (which is configured as a secondary helper address). The NAC 800 replies to that request.

6. The NAC 800 (or one of the NAC 800s in a cluster) tests the endpoint, and the endpoint gains a new posture.

7. If the endpoint has proven to be Healthy (or granted the Check-up posture):

a. The NAC 800 forces it to release the address in the quarantine subnet.

b. The endpoint again sends a DHCP request.

c. The NAC 800 intercepts the request, but because the endpoint has the

Healthy or Check-up posture, the NAC 800 forwards the request to the network DHCP server.

d. The DHCP server replies, sending the endpoint an IP address in one

of the network’s normal user VLANs.

8. If the endpoint is assigned the Quarantine or Infected posture, the NAC 800 continues to respond to its DHCP requests with an IP address in the quarantine subnet.

Establishing the Quarantine Subnet. Some network access controllers quarantine endpoints completely: they assign endpoints IP addresses in a subnet that does not exist in the private network. For example, a network uses the 10.1.0.0/16 range, and the quarantine subnet is 192.168.1.0/24. Should a quarantined user attempt to reach a resource on the network, network devices see the invalid IP address and drop the traffic. The problem with this approach is that users cannot reach any resources—including those that help them become compliant.

1-49

Access Control Concepts

ProCurve NAC 800

Because remediation is a key component of an endpoint integrity solution, the NAC 800 does not follow this strategy. Instead, it places quarantined endpoints in a subnet that exists in the private network, albeit in carefully controlled way.

You can establish the quarantine subnet in one of these ways:

■ The NAC 800 assigns to quarantined endpoints IP addresses that are valid

but unused in the production network. The quarantined “subnet” is not truly a subnet, but rather an unused subset of an existing subnet.

For example, the network includes three Class C user subnets, each with 100 users:

• 10.1.2.0/24

• 10.1.3.0/24

• 10.1.4.0/24

The DHCP server assigns users addresses in the 25 to 125 range—for example, 10.1.2.25 to 10.1.2.125. The second half of each subnet (10.1.X.128/25) is available for quarantined endpoints:

• Quarantine “subnet” = 10.1.2.128/25

• Quarantine “subnet” = 10.1.3.128/25

• Quarantine “subnet” = 10.1.4.128/25

Of course, the scopes on the network DHCP server must exclude these addresses so that a healthy endpoint is not inadvertently assigned an address in the quarantined subset.

■ The network administrator multinets the quarantine subnet on an existing

VLAN. Each VLAN requires its own quarantine subnet.

For example, the network includes two Class C subnets, each with 250 users:

• 192.168.8.0/24

• 192.168.12.0/24

A quarantine subnet isolates non-compliant endpoints from each existing subnet:

• Quarantine subnet = 192.168.9.0/24

• Quarantine subnet = 192.168.13.0/24

The network administrator sets up multinetting on infrastructure devices to accommodate the quarantine subnets. For example, a routing switch could have this configuration:

•VLAN 2

IP address = 192.168.8.1/24 IP address = 192.168.9.1/24

1-50

Access Control Concepts

ProCurve NAC 800

•VLAN 3

IP address = 192.168.12.1/24 IP address = 192.168.13.1/24

Restricting Access in the Quarantine Subnet. The NAC 800 uses one of these methods to enforce the quarantine:

■ It does not assign quarantined endpoints a default gateway in their DHCP

configuration, and it sends them subnet masks of 255.255.255.255. In effect, each quarantined endpoint is isolated within a subnet that consists of itself alone. To allow access to remediation services, the NAC 800 sends the endpoints static routes to itself. It then acts as DNS server, as well as proxy Web server to the allowed sites.

■ Network infrastructure devices enforce static ACLs that drop all traffic

from quarantined addresses except that to remediation services.

Note If you select the static ACL option, you must ensure that the infrastructure

devices are capable of filtering traffic correctly. For example, if you multinetted quarantine subnets on VLANs, the device should be able to apply ACLs to multinetted traffic. If you have assigned quarantined endpoints IP addresses on existing subnets, the infrastructure devices must be able to filter non-routed traffic. For example, the Switch 3500yl/5400zl/ 6200yl Series supports VLAN ACLs, which filter all IP traffic regardless of whether it is switched or routed.

Inline Deployment Method

As with other deployment methods, the NAC 800 tests endpoints for compliance with NAC policies and decides to grant or deny network access accordingly.

An inline NAC 800 also enforces its decisions. It imposes a firewall between endpoints on either side of its Ethernet port 1, which connects to the private network, and port 2, which connects to endpoints to be tested. Endpoints on the port 2 side cannot access any resources on the port 1 side—until the NAC 800 has checked them and ensured they comply with NAC policies. Therefore, typically, the NAC 800 is deployed at a “choke point” such as a VPN gateway, where all valuable resources are located beyond the NAC 800’s port 1.

1-51

Access Control Concepts

ProCurve NAC 800

Note A cluster of ESs can connect to the choke point and test endpoints using the

policies stored on the MS. Because the multiple NAC 800s may create a loop in the topology, remember to set up Spanning Tree Protocol (STP) or Rapid STP (RSTP) on the devices to which they connect.

Process for Inline Quarantining. A NAC 800 follows this process to control an endpoint’s access to the network:

1. The endpoint connects to the network. It may do so in a variety of ways—for example, establishing a VPN tunnel with a gateway device.

Authentication—if it occurs at all—takes place within this step. For example, a user must authenticate to connect to the VPN gateway. A wireless user might enter a preshared key to connect to an AP. However, the authentication is unrelated to the NAC 800.

2. The endpoint’s traffic reaches the NAC 800, which stands between the endpoint and the rest of the network.

3. If it has not already done so, the NAC 800 tests the endpoint.

4. The NAC 800 decides whether to bridge the traffic to the rest of the network or drop it, basing its decision on the endpoint’s posture:

• Healthy or Check-up = Bridge the traffic

• Unknown, Quarantine, or Infected = Drop the traffic (unless destined

to an allowed remediation service)

1-52

NAC 800 as a RADIUS-Only Solution

With its FreeRADIUS server, the NAC 800 can function as a traditional RADIUS server. Querying an Active Directory, eDirectory, or OpenLDAP server, the NAC 800 verifies users’ credentials. If you use IDM, the NAC 800 can also factor more complex policies into its access control decisions, sending the appropriate dynamic settings to PEPs. (See “ProCurve IDM” on page 1-58.)

The ProCurve NAC 800 supports a variety of authentication protocols including:

■ PAP

■ CHAP

Access Control Concepts

ProCurve NAC 800

■ EAP

• PEAP with MS-CHAPv2

•TLS

• TTLS with MD5

•GTC

•LEAP

The NAC 800’s FreeRADIUS server can also log users’ activity and function as an accounting server.

To configure the NAC 800 to provide RADIUS services, you choose the 802.1X deployment and quarantining method. You then prevent the NAC 800 from testing endpoint integrity.

NAC 800 as Both a RADIUS Server and an Endpoint Integrity Solution

The NAC 800, with its built-in FreeRADIUS server, offers services on both network access control fronts. To provide both RADIUS and endpoint integrity services, the NAC 800 must be deployed with the 802.1X method.

The NAC 800 then acts as a PDP that includes these factors in its decisions:

■ User’s authentication status as determined by its built-in FreeRADIUS

server

As described in the section above, the NAC 800 can draw on several remote policy repositories to authenticate the user.

Note You can use IDM to manage a NAC 800’s local database as an alternative

to having the NAC 800 query a remote policy repository such as a directory.

■ Endpoint integrity posture

If the user authenticates successfully, the NAC 800 decides whether his or her endpoint should receive normal network access or quarantined access. This decision is based on the endpoint’s compliance with NAC policies. After the NAC 800 tests the endpoint, it makes another access decision and assigns the user to the appropriate VLAN.

You can configure the policies for VLAN assignment on the NAC 800 manually. However, IDM offers a quick and efficient way to create the policies. (See “ProCurve IDM” on page 1-58.)

1-53

Access Control Concepts

ProCurve NAC 800

Process for 802.1X Quarantining. The NAC 800 imposes this process to control a user’s (and his or her endpoint’s) network access:

1. The endpoint establishes a Data-Link Layer connection to the PEP:

• An Ethernet cable is plugged into a switch, and the link opens.

• A wireless endpoint associates with a wireless AP.

2. The PEP shuts down the connection to all traffic except EAP authentication messages. It sends an EAP challenge to the endpoint’s

802.1X supplicant.

3. The endpoint returns an EAP message that typically contains its username. The PEP proxies this response to the NAC 800 and the NAC 800’s reply back to the endpoint.

4. The endpoint and the NAC 800 exchange authentication information (proxied by the PEP) as dictated by the EAP method.

5. The NAC 800 verifies the user’s credentials whether against a directory, its own database, or a proxy RADIUS server.

6. If the credentials are correct, the NAC 800 checks other policies to determine the correct authorization rights for the user. One important criterion in the policies is the user’s endpoint integrity posture. In a network with IDM, however, other factors can come into play.

1-54

7. Initially, the endpoint integrity posture is Unknown. The NAC 800, which has been configured to associate the Unknown posture with a test VLAN, sends this VLAN assignment to the PEP.

Access Control Concepts

ProCurve NAC 800

Figure 1-5. The User Authenticates and Is Placed in the Test VLAN

8. Detecting the endpoint that has been placed on the test VLAN, the NAC 800 begins to check its compliance with NAC policies.

The NAC 800 needs to receive mirrored DHCP traffic on its port 2 to detect the endpoint.

Note In a cluster of ESs, any ES can test the endpoint; they share information

with each other.

9. When the testing is completed, the endpoint has gained a new posture. The NAC 800 sends a message to the PEP to force the user to reauthenticate.

1-55

Access Control Concepts

ProCurve NAC 800

1-56

Figure 1-6. The NAC 800 Tests the User and Forces the User to Re-authenticate

10. Steps 2 to 7 repeat. Now, however, the user is assigned to a new VLAN based on its new posture:

• If the endpoint has the Healthy posture (complies with your policies)

or the Check-up posture (granted temporary access), the user receives an assignment for a normal user VLAN.

You can use IDM to customize network access for different users groups, times, and locations.

Access Control Concepts

ProCurve NAC 800

• If, on the other hand, the endpoint has the Quarantine or Infected

posture, the user is placed in the quarantine or infected VLAN.

a rate limit and list of accessible resources.

– The NAC 800 acts as the endpoint’s DNS server and redirects the

user’s Web browser away from all sites (except a limited list of accessible services).

– Network infrastructure devices might impose static ACLs on the

quarantine VLAN.

Figure 1-7. The User Re-authenticates and Is Placed in the Appropriate VLAN

1-57

Access Control Concepts

ProCurve IDM

ProCurve IDM manages RADIUS servers, including NAC 800s.

IDM is a centralized, easy-to-use solution for assigning network rights to users. It offers fine-grained network access control that is based on user identity—and other configurable criteria—rather than on network equipment alone.

The IDM server runs as a plug-in to the ProCurve Manager Plus (PCM+) network management software and provides configuration and event logging services to the IDM agent. An easy-to-use interface enables straightforward management of access policy groups.

Each access policy group consists of a list of users and rules that control the users’ access. You can manually import lists of users from a directory, or IDM can synchronize with AD and automatically import complete domain groups as access policy groups.

Access policy rules match a group’s users to profiles—VLAN assignments, QoS parameters, bandwidth restrictions, and ACL settings—based on these criteria:

■ Time of access

■ Location of access

■ WLAN

■ System

■ Endpoint integrity posture—if you are using NAC 800s

1-58

These rules become policy instructions, which the IDM agent residing in the RADIUS server and examining authentication requests, feeds to the RADIUS server. Although configured on the IDM server, the policy instructions are pushed to the IDM agent that resides on the RADIUS server, making them permanently available to the RADIUS server.

Access Control Concepts

ProCurve IDM

Note The IDM server and the PCM+ server can run on the same hardware as the

RADIUS server and the IDM agent. For example, you could install PCM+/IDM, IAS, and the IDM agent on the same Windows Server 2003.

However, IDM often controls multiple RADIUS servers running on other devices. Those RADIUS servers also require the IDM agent. You must install the IDM agent on a third-party RADIUS server, but the NAC 800 automatically includes the agent.

In short, IDM allows you to set up a network access policy at the center of your network and apply it dynamically at the edges. For example:

■ You can allow contract workers access to the network only from their

desks within normal working hours on weekdays; but you can allow your full-time employees access at any time and from anywhere on your network.

■ You can allow guests network access only from lobbies or conference

rooms, and you can restrict them to Internet connections with limited bandwidth. Employees, on the other hand, have access to all their normal network resources at full speed even from those same lobbies and conference rooms.

■ You can limit access to sensitive network resources (such as accounting

and personnel servers or patient information databases) to employees from the appropriate departments while denying access to employees from other departments. For example, a security policy could dictate that a certain user has access to Accounting Department resources. The RADIUS server sends the PEP instructions specifying the correct ACLs to apply to the user’s port.

■ You can alter the resources that users can access depending on the WLAN

through which they connect. For example, your organization might offer two wireless networks: one, intended for employees, that enforces WPA2 security and one, intended for guests, that enforces Web-Auth and no encryption. As long as employees connect to the proper WLAN, they receive all their normal rights. However, if they happen to connect to the guest WLAN, they cannot access sensitive data (which must always be encrypted).

■ You can assign users with non-compliant endpoints to a quarantine VLAN,

which allows the users to download patches but do nothing else, while users with compliant endpoints are placed in their normal user VLAN. You can assign endpoints infected with malware to another VLAN, and endpoints waiting to be tested to a fourth VLAN still.

The figure below shows the difference between the standard RADIUS process and the process with IDM.

1-59

Access Control Concepts

ProCurve IDM

1-60

Figure 1-8. RADIUS Process with IDM

Customer Needs Assessment

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3

Types of Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-5

Employees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-5

Temporary Employees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-6

Guests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-6

Network Skills . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-7

Recording Information about Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-8

Types of Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-9

Wired Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-9

Wireless Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-9

Remote Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-10

Recording the Types of Connections Available to Users . . . . . . . . . . 2-10

Access Control Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-11

Determine Risk Tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-15

Regulations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-16

Regulatory Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-18

Quantify Your Company’s Risk Tolerance . . . . . . . . . . . . . . . . . . . . . . 2-18

Vulnerability to Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-19

Attack Vectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-19

External Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-19

Internal Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-19

Types of Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-20

Malware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-21

Viruses and Worms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-22

2-1

Customer Needs Assessment

Contents

Evaluate the Existing Network Environment . . . . . . . . . . . . . . . . . . . . . . . 2-25