Front cover Building a Network Access Control Solution with IBM Tivoli and Cisco Systems Covering Cisco Network Admission Control Framework and Appliance Automated remediation of noncompliant workstations Advanced security compliance notification Axel Buecker Richard Abdullah Markus Belkin Mike Dougherty Wlodzimierz Dymaczewski Vahid Mehr Frank Yeh ibm.
International Technical Support Organization Building a Network Access Control Solution with IBM Tivoli and Cisco Systems January 2007 SG24-6678-01
Note: Before using this information and the product it supports, read the information in “Notices” on page vii. Second Edition (January 2007) This edition applies to Tivoli Security Compliance Manager V5.1, Tivoli Configuration Manager V4.2.3, and Cisco Secure ACS V4.0. © Copyright International Business Machines Corporation 2005, 2007. All rights reserved. Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.
Contents Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix The team that wrote this redbook. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x Become a published author . . . . . .
3.1.1 Network Admission Control. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 3.1.2 Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 3.1.3 Remediation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 3.2 Physical components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 3.2.1 Network client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2.1 Posture collectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 6.2.2 Policy collector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 6.2.3 Installation of posture collectors . . . . . . . . . . . . . . . . . . . . . . . . . . . 155 6.2.4 Customization of compliance policies . . . . . . . . . . . . . . . . . . . . . . . 161 6.2.5 Assigning the policy to the clients . . . . . . . . . . . . . . . . . . . . . . . . . . 186 6.
Fault isolation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 448 Security Compliance Manager server and client . . . . . . . . . . . . . . . . . . . . . . 450 Communication port usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 451 Tools and tricks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 451 Cisco NAC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Notices This information was developed for products and services offered in the U.S.A. IBM may not offer the products, services, or features discussed in this document in other countries. Consult your local IBM representative for information about the products and services currently available in your area. Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM product, program, or service may be used.
Trademarks The following terms are trademarks of the International Business Machines Corporation in the United States, other countries, or both: Redbooks (logo) developerWorks® ibm.com® Access360® AIX® ™ DB2 Universal Database™ DB2® IBM® NetView® PartnerWorld® Redbooks™ Tivoli® WebSphere® The following terms are trademarks of other companies: Cisco, Cisco Systems, Cisco IOS, PIX, and Catalyst are trademarks of Cisco Systems, Inc. in the United States, other countries, or both.
Preface In February of 2004, IBM® announced that it would be joining Cisco’s Network Admission Control (NAC) program. In December of 2004, IBM released its first offering for the Cisco NAC program in the form of the IBM Tivoli® compliance and remediation solution. In June of 2005 the first edition of this IBM Redbook was published.
The team that wrote this redbook This redbook was produced by a team of specialists from around the world working for the International Technical Support Organization, Austin Center. The project was executed at the Cisco Headquarter in San Jose. Figure 1 Top left to right: Frank, Axel, Vahid, and Mike Bottom left to right: Vlodek, Markus, and Rich Axel Buecker is a Certified Consulting Software IT Specialist at the International Technical Support Organization, Austin Center.
Richard Abdullah is a Consulting Engineer with Cisco Systems Strategic Alliances. Prior to joining Cisco Systems in 2001, he worked in technical capacities within various service providers. He has spent 19 years in the IT industry focusing on networking and most recently on network security solutions. He holds a BSEE degree from the University of Michigan, Dearborn. Markus Belkin is a Network Architect with IBM Australia.
Thanks to the following people for their contributions to this project: Cheryl Gera, Erica Wazewski, Lorinda Schwarz, Julie Czubik International Technical Support Organization, Poughkeepsie Center Wing Leung, Alex Rodriguez IBM US Tadeusz Treit, Bogusz Piotrowski, Anna Iskra IBM Poland Cindra Ford, Zary Stahl, Nick Chong, Prem Ananthakrishnan, Brendan O'Connell, Irene Sandler, Raju Srirajavatchavai, Alok Agrawal, Marcia Hanson Cisco Systems Inc.
Find out more about the residency program, browse the residency index, and apply online at: ibm.com/redbooks/residencies.html Comments welcome Your comments are important to us! We want our Redbooks™ to be as helpful as possible. Send us your comments about this or other Redbooks in one of the following ways: Use the online Contact us review redbook form found at: ibm.com/redbooks Send your comments in an e-mail to: redbook@us.ibm.
xiv Building a Network Access Control Solution with IBM Tivoli and Cisco Systems
Summary of changes This section describes the technical changes made in this edition of the book and in previous editions. This edition may also include minor corrections and editorial changes that are not identified. Summary of Changes for SG24-6678-01 for Building a Network Access Control Solution with IBM Tivoli and Cisco Systems as created or updated on January 16, 2007.
xvi Building a Network Access Control Solution with IBM Tivoli and Cisco Systems
Part 1 Part 1 Architecture and design In this part we discuss the overall business context of the IBM Integrated Security Solution for Cisco Networks. We then describe how to technically architect the overall solution into an existing environment, and introduce the logical and physical components on both the IBM Tivoli and Cisco side. © Copyright IBM Corp. 2005, 2007. All rights reserved.
2 Building a Network Access Control Solution with IBM Tivoli and Cisco Systems
1 Chapter 1. Business context Information Technology (IT) security is a vital component of business success and is very important in e-business security and security for on demand services. As the Internet increasingly becomes an effective means to conduct business, the challenge of protecting IT infrastructures from intruders and malicious attacks increases as well. When an IT resource (server, workstation, printer, and so on) is connected to a network, it becomes a target for a persistent hacker.
Personal computer workstations are used in the office, at home, or at a remote client location. Telecommuters must use mobile PC workstations to meet customer expectations and provide quicker response to queries, quotes, and information. In this book, we introduce a new concept: a comprehensive integrated security solution jointly developed by IBM and Cisco Systems, trusted leaders in this arena for many years who have established enviable synergy in the industry.
concept that can protect all networks in this era. This IBM and Cisco integration, depicted in an overview in Figure 1-1, is a true enabler for the on demand self-defending and security compliance strategy.
It has become mandatory for businesses to comply with regulatory guidelines such as the Gramm-Leach-Bliley Act (GLBA; also known as the Financial Services Modernization Act), Sarbanes-Oxley Act (SOX), and Health Insurance Portability and Accountability Act (HIPAA). More guidelines may emerge over time. The Gramm-Leach-Bliley Act has provisions to protect consumer information held by financial institutions.
Note: Customers are responsible for ensuring their own compliance with various laws such as the Graham-Leach-Bliley Act, the Sarbanes-Oxley Act, and the Health Insurance Portability and Accountability Act. It is the customer’s sole responsibility to obtain the advice of competent legal counsel regarding the identification and interpretation of any relevant laws that may affect the customer’s business and any actions the customer may need to take to comply with such laws.
Standard reports that can be generated from the IBM Integrated Security Solution for Cisco Networks can be valuable to corporate auditors. These can be used as artifacts, thereby reducing the effort in checking individual users. Automated processes can also provide consistency in checking a particular policy that may be required at certain circumstances.
Enable an automated remediation process that eases the process of regaining compliancy for all authorized users on the corporate network. Provide partners and visitors access to the Internet but not the corporate intranet. 1.6 Achievable benefits for being compliant How do organizations benefit from compliance with corporate security policies? Corporate security policies and controls are established to enforce consistent rules that centrally secure access to IT resources across the organization.
Figure 1-2 depicts the relevant tasks in a life-cycle overview for endpoint protection. All of the topics discussed in this chapter are represented at some point in this life cycle.
those mentioned in 1.2, “Why we need this” on page 5, mandate every organization to comply with regulatory acts. Keys to greater productivity include identifying authorized users and providing them easier access to network and system resources while keeping them compliant. The IBM Integrated Security Solution for Cisco Networks delivers corporate compliance at a reduced cost.
12 Building a Network Access Control Solution with IBM Tivoli and Cisco Systems
2 Chapter 2. Architecting the solution In this chapter we discuss the solution architecture of the IBM Integrated Security Solution for Cisco Networks with its compliance-based Network Admission Control system. We provide an overview of the key modules and their relationship, and describe an approach for introducing this additional security layer into the enterprise IT environment. © Copyright IBM Corp. 2005, 2007. All rights reserved.
2.1 Solution architectures, design, and methodologies Our objective for this chapter is not to discuss any general approach for architecting a security solution; however, we follow the IBM Method for Architecting Secure Solutions (MASS), which is closely aligned with the Common Criteria objectives. IBM MASS uses a systematic approach for defining, modeling, and documenting security functions within a structured design process in order to facilitate greater trust in the operation of resulting IT solutions.
In general, the IBM Integrated Security Solution for Cisco Networks consists of three subsystems or logical components, as shown in Figure 2-1 on page 14: Network Admission Control (NAC) subsystem based on Cisco technology Compliance subsystem based on IBM Tivoli Security Compliance Manager (SCM) Remediation subsystem based on IBM Tivoli Configuration Manager Figure 2-2 depicts all involved subsystems and components in a physical network representation.
devices seeking to access network computing resources, thereby limiting damage from viruses and worms. Using NAC, organizations can provide network access to endpoint devices such as PCs, PDAs, and servers that are verified to be fully compliant with an established security policy. NAC can also identify noncompliant devices and deny them access, place them in a quarantined area, or give them only restricted access to computing resources.
Note: With the availability of Cisco’s Network Admission Control Appliance (NAC Appliance) offering, the Network Admission Control subsystem can be delivered by NAC Framework or NAC Appliance. While the interfaces between these two offerings vary, the Tivoli Security Compliance Manager and Tivoli Configuration Manager subsystems are designed to work with either version of Cisco’s NAC offerings.
Port details and communication flows between Security Compliance Manager server and client can be found in “Security Compliance Manager server and client” on page 450. Details of the activities performed by server and client include: Security Compliance Manager server – Provides an interface for defining complex policies that specify conditions that should exist on a client.
Tivoli Configuration Manager IBM Tivoli Configuration Manager automates the manual provisioning and deployment process. Tivoli Configuration Manager provides an automated software and patch distribution solution that can also run pre-built scripts on a client, essentially enabling the Tivoli Configuration Manager solution to install any conceivable software product on a client as well as change a client’s local settings and state.
tables that contain data gathered by the collectors. In a generic Security Compliance Manager deployment, the compliance queries are evaluated on the server, but with NAC-enabled clients using new posture collectors they can also be evaluated on the client. A compliance query is written to return a list of policy violations.
If the client is not Security Compliance Manager policy–enabled, it is denied access to the corporate network and may be allowed only restricted access to the Internet or may be denied access to all networks. When a client is quarantined, the user is given a choice to either remediate manually using the provided instructions or to use an automated remediation process by clicking a button on the pop-up window (if the Tivoli Configuration Manager infrastructure exists).
access, this is an acceptable solution. Users are authenticated and placed into a default network based on their identity. It is not until the user attempted access across a NAC-enabled router that the integrity check was performed. With Layer 2 NAC, identity enforcement via 802.1x delivers access control by checking authorization of the user to connect to the network.
The IEEE 802.1x standard addresses the need to authenticate the user or client trying to connect to the particular network. Point-to-Point Protocol (PPP) can be used in a basic dial-up scenario, but it limits the authentication process to checking only user and password matching. The Extensible Authentication Protocol (EAP) was designed to provide transport for other authentication methods.
In the Cisco NAC solution, the EAP header is extended with posture data and the admission process is based on policies governing the network admission decision. Those policies consider all of the attributes provided by the posture agent (Cisco Trust Agent) to determine the client’s health and security compliance status. In the generic 802.1x, the identity credential is used for authentication. In the Cisco NAC solution, the posture credential of the client device is used for authentication. IEEE 802.
This requirement can be fulfilled by providing each user with a unique identity and verifying it even before the posture condition of a client is checked. This process was standarized with the IEEE 802.1x protocol, and IBM provides the solution to facilitate it. IBM Tivoli Identity Manager delivers a flexible provisioning engine to create and manage user accounts on the Secure Access Control Server. For more information, contact your IBM representative.
2.2 Definition of a Network Admission Control project Objectives of a Network Admission Control solution must be carefully planned because the result of having a large number of workstations quarantined may be more disruptive to the business than a particular virus attack.
Figure 2-5 illustrates a possible NAC deployment scenario. Branch Office AAA Server (ACS) SCM Server EAP/UDP 1 4 Branch Router Edge Router RADIUS (posture) Campus FW 5 EAP 802.1x (wireless) Internet EAP/UDP 3 2 Dial-in NAS RA IPsec VPN 6 EAP 802.
2.3 Design process The MASS methodology that we follow in this book includes the following steps of the design process: 1. 2. 3. 4. Model business process. Establish security design objectives. Select and enumerate subsystems. Document conceptual security architecture. We now walk through these steps. 2.3.
2. Check control settings and compare to security policy. The audit team periodically checks the systems to be sure their settings are in compliance with the policy. The audit team creates a report listing all controlled systems and the violated controls. Periodically the list also has to contain the complete security control settings and the systems that are controlled. 3. Document health check and deviations.
The security compliance process for desktops and mobile clients can be simplified to look like this: 1. Apply security policy. The first step in setting up a health check process is to make sure the required security control settings of the enterprise security policy are audited. 2. Check control settings and compare to security policy. With the NAC in place the health check audit is automated and takes place every time the client connects to the network.
reason a policy cannot be complied with due to a particular business need, the situation has to be accepted as a security risk for a well-defined period of time and signed off by the project sponsor. A policy that is created but is not enforced is no better than no security policy at all. This situation can expose the organization and put its credibility at stake. We discuss more details of the full policy life cycle in the following sections.
This means that for each desired change in the configuration settings, there must be an appropriate configuration change process in place to perform the changes on the afflicted systems. For example, if there is a security policy stating that each workstation must have antivirus software installed, there has to be a corresponding software installation process to distribute it to clients consistent with this policy.
2.3.4 Network design discussion In this section we discuss the following network design factors for the IBM Integrated Security Solution for Cisco Networks: Network segmentation via VLANs and downloadable IP ACLs Performance Adding new components that may not have been required previously The IBM Integrated Security Solution for Cisco Networks introduces new zoning terminology for intranet networks: Default network These are the network segments or virtual LANs (VLANs) to which clients are connected.
In the reference architecture described later in this book, there are several untrusted networks that are the default networks to which users are assigned based on their identity-based authentication. When clients are in a healthy state, they should be placed in the default network based on the user’s identity. Quarantine access We use this term to refer to the necessary network resources that a quarantined client needs to access.
revalidation process takes place too often, this pop-up window may become annoying and significantly lower the user’s productivity. The recommended value is 14400 seconds (4 hours) or more. The router or the network access device (NAD) periodically queries the client for the current policy compliance status changes. This activity introduces additional network traffic, which becomes larger as the defined time intervals shorten.
particular security compliance concept is aimed at validating client access to the corporate network, so it is mandatory that the system is available at all times. As mentioned in Chapter 1, “Business context” on page 3, this concept can be deployed in stages, first targeting the most vulnerable user group (such as WLAN users) or a branch office, which may have a security exposure, and then being deployed across the whole enterprise.
Part 2, “Customer environment” on page 75, details a comprehensive deployment scenario. 2.6 Conclusion In this chapter, we discussed the architecture and design principles for the IBM Integrated Security Solution using Cisco Networks. The overall architecture encompasses several components from IBM and Cisco, with integrated systems that complement each other by providing the first industry compliance-based Network Admission Control system with automated remediation capabilities.
38 Building a Network Access Control Solution with IBM Tivoli and Cisco Systems
3 Chapter 3. Component structure This chapter introduces the logical and physical components of the IBM Integrated Security Solution for Cisco Networks. The final section of this chapter talks about the logical data flow among the various components to better understand dependencies and component placement within the network. © Copyright IBM Corp. 2005, 2007. All rights reserved.
3.1 Logical components The IBM Integrated Security Solution for Cisco Networks detects the state of network clients and compares it with a set of centrally defined and managed policies to establish client postures. It then dynamically reconfigures the network based on detected client postures and changes the state of devices to be in compliance with defined policies. This solution is an integration of products from IBM and Cisco.
The logical components are: Network Admission Control Compliance Remediation The following sections provide function and architecture details for each component. 3.1.1 Network Admission Control Network Admission Control (NAC) is the Cisco component of the solution that provides enforcement by restricting traffic based on the client's posture. Cisco NAC can be implemented via NAC Framework or NAC Appliance.
for network devices and other services. The various components that constitute the ACS and a brief description of their functions are discussed here. The ACS architecture consists of seven services bundled within ACS. Figure 3-2 shows the internal ACS components and their functions.
Note: For more information about the ACS architecture and administration refer to the ACS user guide and ACS administration guides at the Cisco Web site: http://www.cisco.com/en/US/products/sw/secursw/ps2086/tsd_products_support_s eries_home.html Policy enforcement device Clients access enterprise resources via the network which makes it an effective point to validate system posture prior to allowing access to such resources.
Figure 3-3 shows the Cisco Trust Agent architecture, followed by a brief explanation of the components that make up the Cisco Trust Agent. Client Application (EXT-Service) Application supplied Posture Credential Providers EXT-Service Posture-Plug-in Logging Service Posture Plug-in EAP Methods Cisco Trust Agent Service NAD Device Figure 3-3 Cisco Trust Agent architecture Cisco Trust Agent service Responds to network requests for client system posture information.
EAP methods Provide a mechanism to authenticate the application or device requesting the host credentials, and encrypts or decrypts that information.
Clean Access Policy Updates These are regular updates of pre-packaged policies/rules that can be used to check the up-to-date status of operating systems, antivirus (AV), antispyware (AS), and other client software. 3.1.
Figure 3-4 depicts Security Compliance Manager’s high-level component architecture, followed by a brief explanation.
Compliance evaluation Consisting of Security Compliance Manager snapshots and policies, these components centrally verify security compliance. Note: You can find more details about these components in the IBM Redbook Deployment Guide Series: IBM Tivoli Security Compliance Manager, SG24-6450. Compliance client The client consists of modules that run on the endpoint to collect compliance information and report it to the Security Compliance Manager server.
The compliance client component (Figure 3-5) consists of the following modules: Policy collector Posture collector Posture cache Posture plug-in Default remediation handler SCM Client Collector Posture Cache Posture Collector Posture Collector Policy Collector Posture Plug-in Remediation Handler Figure 3-5 Compliance client logical component Posture collector A collector is a Java language-based software module, packaged as a Java Archive (JAR) file, that collects specific information fro
In the IBM Integrated Security Solution for Cisco Networks, the collector is called a posture collector. A posture collector consists of posture data collection and posture status determination. The posture data collection part of a posture collector is the same as in a regular Security Compliance Manager collector, but the posture status determination part of a posture collector is an extension to the standard model.
Posture cache This component provides the caching area where posture collectors store the results of posture determination in a temporary file. The policy collector refers to the information captured in the posture cache for determining the violation count. Posture plug-in Posture plug-ins are the means by which the Cisco Trust Agent requests and receives security posture information from NAC-compliant applications installed on the system.
and any client components that would normally be installed on a Tivoli Configuration Manager client are embedded within the Security Compliance Manager Compliance policy. For the IBM Integrated Security Solution for Cisco Networks, the Tivoli Configuration Manager Software Distribution Server and Web Gateway components are used.
Cisco Trust Agent The Cisco Trust Agent is Cisco client software that is required to pass posture credentials and validation results between the Cisco NAC solution and the IBM Security Compliance Manager client. Security Compliance Manager client The Security Compliance Manager client is a software component that is physically installed on the network client.
3.2.2 Network access infrastructure All users connect to enterprise resources via network access devices. The topology varies depending on the size of the organization, but most networks can be classified into LAN (local area network), WAN (wide area network), or remote access. The LAN enables connectivity to users within a location. A WAN provides connectivity to remote or branch office users who need connectivity to resources that are centrally deployed.
be deployed to the clients. The server is also used for administration and for providing reports about client compliance to deployed policies. Tivoli Configuration Manager servers There are two Tivoli Configuration Manager servers used for remediation. Tivoli Configuration Manager Software Distribution Server is used to create remediation objects and publish them to the Tivoli Configuration Manager Web Gateway Server, where they are made available to clients requesting remediation. 3.
The flow consists of these process groups, depicted in Figure 3-6: 1. 2. 3. 4. Policy creation and deployment Posture collection Posture validation and policy enforcement Remediation AAA Policy Server (ACS) SCM Server 1.d 3.f 1.a 1.b 3.e Rem.URL Rem.Object TCM Web Gateway 3.d ACL 3.g 1.c 1.e NAD 4.b Policy Posture Token Policy.Version Violation.Count Rem.URL Pop-up Message 2.a Posture cache Policy Collector 3.b Network TCM Server Posture Collector Rem. Attributes 4.
remediation object should also be provided. Details of the policy creation and deployment process are discussed here: Remediation object creation and publishing (1a) A remediation object that can remediate violations must be provided. The naming and creation of these objects is dependent on the corresponding Security Compliance Manager posture collectors and certain naming conventions.
Cisco Secure ACS policy creation (1d) An ACS policy consists of rules that must match required posture criteria. Depending on the matched criteria, a token is assigned to the network client that requires validation. The token results in the network client being dynamically assigned to a group. Based on the Network Access Profiles configured on the ACS, the group has an access policy (for example, an ACL or a RAC) associated with it.
Posture validation and policy enforcement (flow 3) This section contains details about how a client in a live environment connects to the network and how its posture is validated by the ACS. After validation the client is provided access based on client posture. Client network access (3a) The network client initiates IP traffic that crosses a NAC-enabled route point or connects to a switch running 802.1X.
– Quarantine – Infected – Unknown Posture notification (3f) After the ACS has determined the posture token it performs these actions: a. Cisco Secure ACS sends the system posture token to the network client. b. The Cisco Secure ACS sends the network client an action to be taken that is the result of the client being assigned to a group complying to a particular policy level.
Remediation (flow 4) Two cases should be considered for the remediation process: one where the organization has a Tivoli Configuration Manager server with an automatic remediation implementation, and the other where the organization will use manual methods for remediation using a Web server or alternative methods.
3.3.1 Secure communication The components are designed to provide a high level of security between the various elements in the solution. We provide a description of how the various components securely communicate, and Figure 3-7 shows an overview of the secure communications.
NAC communication During communication of the Cisco Trust Agent client with the Cisco Secure ACS, a secure PEAP session is established with the network client and requests the network client security posture credentials. Cisco Trust Agent uses certificates to establish a PEAP session with the ACS.
Figure 3-8 shows the security zones and their classifications. Organizations could have different topologies and have their own architecture and naming of zones depending on their security policy. Organizations may set up specialized restricted zones for production systems Which would have Application & Database systems Some organizations may set up special networks to separate various management components from production systems.
corporate network through what are considered external networks, such as the DMZ and intranet zones. Details of resources that are generally deployed in the various security zones, the possible access methods by which network clients access these enterprise resources, and the zones from which clients would access are discussed here and depicted in Figure 3-9.
Remote offices and branch offices can use the Internet as a primary method of access or for backup if the primary access method fails. Organizations can provide partners access over the Internet and exchange data over VPN. Controlled zone - external network-facing DMZ One controlled, semi-trusted network zone is called the DMZ. It provides a buffer zone between the Internet and internal networks.
3.4.2 Policy enforcement points The IBM Integrated Security Solution for Cisco Networks employs the Cisco NAC solution to restrict access to users depending on the compliance level of the client. The NAC solution requires network access devices (NAD) to be deployed at various network points to enforce the policy. Some of the widely used network topologies and possible policy enforcement points are discussed here. Branch office compliance Most medium and large networks have regional and branch offices.
Advantages of this kind of deployment are: Policy enforcement load distribution across the various routers Protection against virus infection between branch offices if the network has a mesh topology Factors that must be considered for branch egress enforcement are: Branch routers must support NAC Some additional administrative effort required during deployment Campus internal enforcement In this deployment option, the office policy compliance is enforced on all switches to which the users connect.
Branch Office Compliance (Campus Ingress Enforcement) Corporate Headquarters Data Center AAA AAA AAA Internet AAA Server Posture Enforcement Points Router Site-to-Site VPN Users VPN Figure 3-11 Campus ingress enforcement Chapter 3.
Small Office Home Office compliance Policy enforcement can be used to protect corporate networks from noncompliant and potentially infected small office and home office (SOHO) users, as shown in Figure 3-12. This will also be the practical deployment option for clients who are using Port Address Translation to access corporate resources.
Extranet compliance Organizations could have WAN connections to share information with partners. This would require partner systems connecting to the parent organization to comply with the policies laid down by the parent organization. The policy enforcement device can be deployed appropriately to ensure that these partner systems comply to the parent organization’s policies (Figure 3-13).
Lab compliance Organizations prefer having lab networks to test systems before deployment of new solutions or equipment. Traffic from this zone to the primary network is restricted so that operations in the lab setup do not disrupt the production systems and networks. A policy enforcement at the connection between the production systems and lab setup can ensure that only systems that comply to the enterprise policy are allowed into the production network from a lab subnet.
Data Center protection The Data Center is the site where organizations host business-critical systems that require maximum protection. Compliance can be checked for client systems before they are provided connections to the resources at the Data Center (Figure 3-15). Data Center Protection AA AA AA AAA Corporate Networks Data Center Lab Networks AAA AAA Server Posture Enforcement Points Router Switch Access Point Figure 3-15 Data Center protection Chapter 3.
Remote access protection Remote access users use dial-up or VPN to connect to corporate resources. To enforce these users to comply to the corporate policies, a policy enforcement device may be deployed at the remote access entry points (Figure 3-16).
Part 2 Part 2 Customer environment Part 2 discusses how the IBM Integrated Security Solution for Cisco Networks might be used in customer situations. We use a well-know customer scenario, the Armando Banking Brothers Corp. In our last encounter in the IBM Redbook Deployment Guide Series: IBM Tivoli Security Compliance Manager, SG24-6450, they successfully deployed the Tivoli Security Compliance Manager solution for their distributed server environment.
76 Building a Network Access Control Solution with IBM Tivoli and Cisco Systems
4 Chapter 4. Armando Banking Brothers Corporation This chapter provides an introduction to the overall structure of the Armando Banking Brothers Corporation (ABBC). This introduction includes a description of ABBC’s business profile, their current IT architecture, and their medium-term business vision and objectives. Note: All names and references for company, personnel, and other business institutions used in this chapter are fictional; any match with real entities is coincidental. © Copyright IBM Corp.
4.1 Company profile Armando Brothers Banking Corporation (ABBC) is a fictional financial institution that traces its roots back to the early days of industrialization. During a time of radical change and growing financing needs, the Armando brothers founded a bank situated in the pioneer town of Waterloo — now known as Austin, Texas. In the early years, ABBC helped many entrepreneurial pioneers finance their business ventures.
4.2 Current IT architecture This section provides background information about the existing Armando Banking Brothers Company IT architecture, including the network infrastructure, security infrastructure, and the middleware/application infrastructure. 4.2.1 Network infrastructure Next we describe the logical network components that make up the ABBC network (Figure 4-1). ABBC has developed the network and application security infrastructure in line with the IBM MASS security model.
Uncontrolled zone - Internet The Internet has become a pivotal component in the banking industry with its immense flexibility and business opportunities. But it has also become one of the preferred methods for spreading viruses and malicious code as well as providing easy access to many unprotected or weakly secured enterprise resources. Balancing the requirements and threats, ABBC has provided clients, employees, and partners with controlled access to its resources.
Figure 4-2 is representative of the ITSO Lab Environment used for L2Dot1x NAC deployment. VLAN-11 Healthy Sales VLAN in the Core network. This VLAN hosts those users that have been authenticated by IEEE 802.1x as members of the Sales Group and have been posture validated as Healthy. VLAN-12 Healthy Engineering VLAN in the Core network. This VLAN hosts those users that have been authenticated by IEEE 802.1x as members of the Engineering Group and have been posture validated as HealthyII.
his credentials, the Cisco Secure ACS checks its local user database and assigns the user to the respective group. The user is then mapped to the Healthy or Quarantine VLAN of that group, depending on the state of posture compliance provided by the CTA on the user’s machine. All access to the network is based on access control lists (ACLs) bound to the Layer 3 Switched Virtual Interfaces (SVIs) on the switch, which in this example is also the access switch.
Figure 4-3 on page 84 is representative of the ITSO Lab environment used for NAC Appliance deployment. VLAN 20 This is the Access VLAN for a Healthy user. All DHCP addresses are provided from VLAN 20, regardless of whether a user is compliant or noncompliant. VLAN 120 This is the authentication VLAN. If a user is classified as noncompliant by the CAM, that user’s switchport has its VLAN membership changed from VLAN 20 to VLAN 120.
Figure 4-3 Armando Banking Brothers network environment for NAC Appliance When a user connects to the network controlled by NAC Appliance, the CAM is advised of a linkup notification sent by the user’s switch. The CAM checks its certified user list. If the MAC address is already present on the CAM as a certified user, and the credentials supplied at login are authenticated by the CAM, the user will be granted access to the network on their Access VLAN, which in this case is VLAN 20.
4.2.3 Application security infrastructure General management and the IT department are aware of the need for a solid basis to implement their future goals. The current environment with multiple systems is complex; the introduction of IBM Tivoli Access Manager for e-business in a previous project deployment provided a centralized, solid, and easy-to-manage security architecture to help control access to ABBC’s Web-based assets and protect them from attacks.
The diagram in Figure 4-4 provides a high-level graphical overview of the existing ABBC security infrastructure. We see that ABBC is using the IBM Tivoli Access Manager best-practice deployment methodology by incorporating dual multiple firewalls to secure the core network from external and internal users.
cluster of IBM HTTP servers and WebSphere® Application Servers providing Internet banking and other services to external users. Similarly, the internal application server block represents multiple servers providing application support for internal users. 4.3 Corporate business vision and objectives The Armando Banking Brothers Corporation (ABBC) has already made a significant investment toward securing their network infrastructure.
In the practice of IT security, it is possible to design an extremely secure, hardened system. However, this apex of maximum security will likely incur a cost of reduced system usability. Likewise it is possible to create a very user friendly, highly accessible network, but at a cost of reduced security. The IT Security Administrator must strive to strike a balance between these extremes. The introduction of a Network Admission Control system is a new technology for most, if not all, companies today.
Action Notes Reference Configure Security Compliance Manager posture policy. Ample thought time must always be provided for determining proper policy for the business. In a true deployment, the proper forethought, establishment of process, and policy are major keys to success. 6.2, “Configuration of the compliance policies” on page 152 Install compliance client software. This includes both the IBM client components and the Cisco Trust Agent software. 6.3.1, “Cisco Trust Agent” on page 190, and 6.3.
Action Notes Reference Installing the Clean Access Agent Highlights the steps for installing the Clean Access Agent 7.2.1, “Installing CCA Agent” on page 304 Configuring a CCA OOB VG server Highlights all the steps to configure the CAM and CAS for a Out-Of-Band Virtual Gateway server deployment 7.2.
Action Notes Reference Define or create HTML pages for assistance with remediation process. Maps the posture policy to meaningful information to inform the user why they have been marked noncompliant, as well as what steps they have to take to remediate. 8.3, “Creating remediation instructions for the users” on page 397 Configure remediation workflows. Links the Security Compliance Manager policy to the remediation actions. 8.4, “Building the remediation workflows” on page 417 4.
92 Building a Network Access Control Solution with IBM Tivoli and Cisco Systems
5 Chapter 5. Solution design In this chapter we describe the business objectives that drive the functional requirements of the technical solution. As a best practice, it is typical in a production environment to deploy a new technology, such as compliance-based Network Admission Control, in phases, aiming first at the selected test locations or user groups and then extending the project to the whole network.
implementation of part two is described in Chapter 7, “Network enforcement subsystem implementation” on page 213. Part 3, “Appendixes” on page 439, builds on this infrastructure and adds automatic remediation functionality. The detailed technical implementation of Part 3, “Appendixes” on page 439, is described in Chapter 8, “Remediation subsystem implementation” on page 355.
5.1 Business requirements As described in Chapter 4, “Armando Banking Brothers Corporation” on page 77, Armando Banking Brothers Corporation (ABBC) is well vested in the IBM Tivoli Identity, Access, and Compliance management solutions. With the emergence of the Network Admission Control program, as sponsored by Cisco Systems, it is ABBC’s direction to introduce a Network Admission Control program based on workstation posture-compliance status information.
5.2 Functional requirements In this section, the business requirements are further examined in order to extract the functional requirements. In subsequent sections of this book, the functional requirements are further distilled down to the implementation details. 5.2.1 Security compliance requirements As we further examine our security compliance-related business requirements, we find that the following pain points are the requirement drivers.
5.2.3 Remediation requirements Examining the operational maintenance related requirements we found that the following pain points are the requirement drivers: Desktop security requirements became so complex that most of the non-technical end users cannot track the policy changes on their own. Increasing numbers of mobile users are outside of the scope of the desktop policy enforcement realized with Active Directory®.
allows us to warn users if any noncompliance is found and explain the current desktop security policy requirement. This helps to keep users aware of the current security policy requirements and allow reporting on the compliance status of all of the workstations in the environment. The second functional requirement is to restrict network access for noncompliant workstations. This limits or prevents the interruption of network operations caused by worms and other hostile software.
ABBC will institute posture-based network admission. Systems deemed in noncompliance will be quarantined and allowed to access only the remediation network. Figure 5-1 shows a conceptualized view of the functional requirements.
4. The Security Compliance Manager client is armed with a remediation handler. The remediation handler provides a method of displaying the compliance posture data to the end user.
recommend that a process be in place for the normal notification and distribution of required workstation updates and corporate policies; for all but the most extreme cases, the life cycle management process includes a grace period. The deployment of the NAC, along with the IBM Integrated Solution for Cisco Networks, enables ABBC to enforce policy by blocking the network access of noncompliant systems after the expiration of this grace period.
integrated solution include the Security Compliance Manager client/server componentry and the Tivoli Configuration Manager remediation client/server code. In this section we see how these components map to the implementation architecture.
with the Web Gateway component to allow for automated remediation at the workstation level without need of having Tivoli Framework endpoint installed. Again referencing Figure 5-3 on page 102, note that the total solution is comprised of three major subsystems: the compliance subsystem, the Network Admission Control subsystem, and the remediation subsystem. The implementation of these subsystems is described in the following three chapters.
Establishing the policy collector parameters At this point, we have to establish the posture policy version because this has a direct bearing on how the network access control permissions will be set. Figure 5-4 shows a logical view of the Tivoli Security Compliance Manager client components.
Although the policy collector appears to be at a peer level with the posture collectors in Figure 5-5, it is actually a hierarchical relationship, as shown in Figure 5-4 on page 104. Figure 5-5 Security Compliance Manager policy collector - edit collector parameters The Tivoli Security Compliance Manager policy collector parameters are set exactly the same way the posture policies are set. Refer to Chapter 6, “Compliance subsystem implementation” on page 125, for a detailed description of the procedure.
There are several parameters of interest: The POLICY_VERSION parameter (Figure 5-6) establishes the version level of the policy. This field is simply a string value. The company version control process is strictly a manual one. During the network admission check, this version information is used to ensure that the client has an acceptable version of the compliance policy. (More on this in the next section.
For ABBC we set the parameter to 60 seconds. Effectively this forces the posture status to refresh itself at every challenge. Figure 5-8 shows the conceptual control flow for this parameter.
The HANDLER_ATTRIBUTES parameter (Figure 5-9) establishes the URL where the remediation handler will send the remediation request, as well as more attributes for the remediation handler. This field has to have a form of = string, as presented below: remediation.
The REMEDIATOR_JAR parameter (Figure 5-10 on page 108) tells the class loader where the JAR file is located for the remediation Java class specified in the REMEDIATION_CLASS attribute. This field is a simple string and should have the value of: collectors/com.ibm.scm.nac.tcmremed.client.TCMRemed.jar Figure 5-11 Setting the remediation handler JAR classpath The value of the POLICY_VERSION parameter must then be handed over to the networking team.
focus on how our posture policy, as established by the Tivoli Security Compliance Manager, interrelates with the Cisco Secure Access Control Server and how its associated polices form an interlocked security solution (Figure 5-12).
In the posture validation policies, we check that a client has the correct minimum supported version of CTA installed and is running the correct version of the Security Compliance Manager policy (Figure 5-13). Figure 5-13 Posture validation policies For detailed information about the creation and configuration of the Cisco Secure Access Control Server reference see 7.1.1, “Configuring the Cisco Secure ACS for NAC L2 802.1x” on page 214. This section discusses the way the policy is evaluated.
those users that are in breach of these requirements, and how to remediate them back to a compliant state. Terms that are used include: Network Access Profile A Network Access Profile is a means to classify access requests according to AAA clients' IP addresses, membership in a network device group, protocol types, or other specific RADIUS attribute values sent by the network device through which the user connects.
Quarantine System Posture Token for a policy violation, he will be mapped to the Quarantine_Engineering_RAC (VLAN14). This allows for scalability and granularity. Figure 5-14 Shared RADIUS Authorization Components In our scenario, we list the Cisco Trust Agent (Cisco:PA) and the Security Compliance Manager agent (IBM Corporation:SCM) as our posture validation policies. Thus in all, three pieces of information are used to make the access decision: IEEE 802.
The Cisco Secure ACS evaluates each of the authorization rules in order from top to bottom. The first match assigns the client the listed posture token. If no match is found, the default rule assigns the listed token. Assigning the System Posture Token Cisco Secure ACS supports the following System Posture Token types: Healthy The endpoint device complies with the currently required credentials so you do not have to restrict this device.
SVIs. Each Shared RADIUS Authorization Component had a corresponding ACL defined on the NAD. The example below shows the configuration used for the Healthy Engineering VLAN and the Quarantine Sales VLAN. access-list access-list access-list access-list access-list ! access-list access-list access-list access-list access-list access-list access-list access-list access-list access-list access-list access-list access-list ! 120 120 120 120 120 remark **Healthy Engineering VLAN ACLs** deny ip any 192.168.13.
See 8.4, “Building the remediation workflows” on page 417, for information about the creation of the workflows for the IBM Integrated Security Solution for Cisco Networks. Remediation handler HTML pages The remediation process does not link back to a central policy as do the security compliance posture and the Access Control Server posture token and access control list. The compliance client provides a way to display HTML-based information to the user.
Compliance subsystem The compliance subsystem has two major components: The IBM Security Compliance Manager server The IBM Security Compliance Manager client IBM Security Compliance Manager server The required IBM Security Compliance Manager server software is Version 5.1.1 (at the time we are writing this book this version is also known as Version 5.1.0 Fix Pack 30). The Security Compliance Manager server runs on a variety of supported platforms, which Table 5-1 lists.
The system used by ABBC for the Security Compliance Manager server is: Windows 2003 Server Enterprise Edition with SP1 installed Pentium® IV @ 3.0Ghz CPU 512 MB of system memory 3 GB of free disk space IBM Tivoli Security Compliance Manager client The required IBM Security Compliance Manager client software is Version 5.1.1 (also known as 5.1.0 Fix Pack 30). This version contains the DLLs required to enable the Cisco integration.
Operating system requirements for ACS V4.
NAC-enabled network device The following Layer 2 and Layer 3 network devices are supported for a Network Admission Control implementation. Layer 2 devices Table 5-2 shows the supported Layer 2 devices. Table 5-2 Layer 2 devices NAC features NAC Layer 2 IEEE 802.1x authentication and validation NAC Layer 2 IP validation 7600 X X 6500 X X 4500 X X 3750 Metro - - 3750 X X 3560 X X 3550 (12.2S) X X 3550 (12.
Cisco 2600XM Series Router Cisco 2691 Multiservice Platform Cisco 2800 Series Router Cisco 3640 Multiservice Platform Cisco 3660-ENT Series Router Cisco 3725 and 3745 Multiservice Access Routers Cisco 3800 Series Router Cisco 7200 Series Router For the most up-to-date information refer to: http://www.cisco.com/application/pdf/en/us/guest/netsol/ns617/c649/cdccont_0900 aecd8040bc84.pdf Cisco Trust Agent The Cisco Trust Agent 2.0 with the IEEE 802.
Remediation subsystem The remediation subsystem has three components: IBM Tivoli Configuration Manager server Software Package Web Server Remediation handler IBM Tivoli Configuration Manager server The Tivoli Configuration Manager supports a wide range of architecture types as well as a range of installation topologies (one-node, two-node, and three-node). The resulting multitude of combinations is well beyond the scope of this book.
EAR file. This application must be installed on the same WebSphere Application Server as the Web Gateway component. Remediation handler In the current release of the solution, the remediation handler is delivered in the form of the Security Compliance Manger collector JAR file and is automatically downloaded to the client workstation together with the compliance policy. See 8.1, “Automated remediation enablement” on page 357, for more detailed configuration information. 5.
124 Building a Network Access Control Solution with IBM Tivoli and Cisco Systems
6 Chapter 6. Compliance subsystem implementation This chapter describes the IBM Tivoli Security Compliance Manager part of the Network Admission Control (NAC) solution, where the main concern is the establishment of security policy.
6.1 Tivoli Security Compliance Manager setup Tivoli Security Compliance Manager server is an important component of the solution providing the policy management service to the client workstations. In the section below we describe the process of installing the Tivoli Security Compliance Manager server. To perform the installation the following media are needed: DB2 Universal Database 8.2 Tivoli Security Compliance Manager Server 5.1.1 Note: The Tivoli Security Compliance Manager Server 5.1.
2. After a little while you are presented with the Welcome window, as shown in Figure 6-1. Click the Install Product selection on the left. Figure 6-1 DB2 installation welcome window Chapter 6.
3. The DB2 version selection is presented similar to the one shown in Figure 6-2. Depending on the media installation you use there may be more than one option presented. Select DB2 UDB Enterprise Server Edition and click Next.
4. Next the welcome window is displayed, as presented in Figure 6-3. Click Next. Figure 6-3 Setup wizard welcome window Chapter 6.
5. On the next dialog you are presented with the standard license agreement (Figure 6-4). Accept the license and click Next.
6. In the Installation type selection window (Figure 6-5) leave all of the default values (which is Typical installation) and click Next. Figure 6-5 Installation type selection window Chapter 6.
7. On the next dialog, shown in Figure 6-6, you are presented with the installation action selection, where there are two options: Install the product Which is selected by default Save your settings Which will save your selections to a response file, which can then be used for silent installations If you plan to perform multiple installations you may mark the second check box. Otherwise, click Next.
8. In the next window, shown in Figure 6-7, you must select the installation destination folder. Make sure that there is enough space on the selected drive and click Next. Figure 6-7 Installation folder selection window Chapter 6.
9. In the next dialog, shown in Figure 6-8, you must provide user information. We strongly recommend leaving the default user name db2admin. In the next two fields provide the password for this user. Make sure that you have written this down, as you will need this password several times during the installation of the other components. Then click Next.
10.In the next dialog, depicted in Figure 6-9, you are presented with the administration contact configuration options, where you may specify names of the users who should be notified by the database if something goes wrong. If you leave the defaults and click Next you will be presented with the additional warning that Notification SMTP server information has not been specified, which you can ignore by clicking OK. Figure 6-9 Administration contact list dialog Chapter 6.
11.In the next window, shown in Figure 6-10, you can modify the DB2 instance configuration options. You can explore the protocols settings and change the startup options. The default instance name on Windows is DB2, the communication protocol used is TCP/IP, and the database instance is instructed to start automatically when you boot the system. We recommend that you leave the defaults and click Next.
12.As we do not need to use any DB2 tools on the next dialog, shown in Figure 6-11, click Next. Figure 6-11 DB2 Tools selection dialog Chapter 6.
13.In the next window, presented in Figure 6-12, you can provide the contact information for a user to receive the database health notifications. Select the option to Defer this task until after installation is complete and click Next.
14.In the next window, shown in Figure 6-13, you are given a last chance to review your selected options. If everything is as you want, click Install. Figure 6-13 Installation options summary Chapter 6.
15.The installation may take a few minutes depending on the configuration of your server. When it is complete you are presented with the final window, shown in Figure 6-14. When you click Finish there may be additional dialogs called First steps, which you may safely close by clicking Exit First Steps in the bottom left corner. Figure 6-14 Installation completion window This completes the installation of the DB2 database. You may proceed with installing the next components for the solution. 6.1.
2. The usual language selection box is presented, as shown on Figure 6-15. Accept English and click Next. Figure 6-15 Language selection dialog 3. Click Next on the Tivoli Security Compliance Manager Welcome window, which is presented next. There will be a license agreement window displayed, as shown in Figure 6-16. Accept the license and click Next. Figure 6-16 License agreement window Chapter 6.
4. In the next window, shown in Figure 6-17, specify the destination directory for the Tivoli Security Compliance Manager installation. Accept the default, which is C:\Program Files\IBM\SCM, and click Next. Figure 6-17 Destination directory selection dialog 5. In the next window you may select what you want to have installed.
Tivoli Security Compliance Manager server installation. This is a recommended option in large scale deployments. For this installation we must have all three components installed, so select the second option Server, as presented on Figure 6-18, and click Next. Figure 6-18 Setup type selection window Chapter 6.
6. You are presented the e-mail Server configuration dialog, as shown in Figure 6-19. The Tivoli Security Compliance Manager server uses e-mails to notify the administrators of the violations found, as well as for distributing the reports. Specify the SMTP server name as well as the account the Tivoli Security Compliance Manager server will use to send the outgoing communication. If you do not have the SMTP server name available put any name there. You can easily change these values later in the server.
7. In the next window, shown on Figure 6-20, the installation wizard asks for the communication ports the server uses to communicate with the clients. We strongly recommend leaving the defaults. Click Next. Figure 6-20 Server Communication Configuration window Chapter 6.
8. The Server Security Configuration window is displayed, as shown in Figure 6-21. In the System name certificate field you must provide the system name that will be used to generate the self-signed certificate for the Tivoli Security Compliance Manager server. In the next four fields provide the passwords (and password confirmations) to access the keystore files generated during the installation. Then click Next.
9. In the next window, presented in Figure 6-22, select the location for your database. If you installed DB2 as described in 6.1.1, “Installation of DB2 database server” on page 126, select The database is on the local system option and click Next. Figure 6-22 Database Location selection window Chapter 6.
10.In the next dialog, provide the database configuration information, as shown in Figure 6-23. Enter the username and password for the DB2 administrator you have provided in step 9 on page 134. Leave the other fields with the default values and click Next.
11.In the next dialog, shown in Figure 6-24, you are asked whether the database should be created during this installation. Make sure that the check box is marked and click Next. Figure 6-24 Database creation choice window Chapter 6.
12.The next dialog allows you to specify an administrator user ID and password for Tivoli Security Compliance Manager server, as shown in Figure 6-25. Use the name admin and enter a password of your choice. This user Id is created in the Tivoli Security Compliance Manager database and does not need to be a system account. Click Next to continue.
13.Finally you are presented with the installation selection summary, as shown in Figure 6-26. Click Next to start the actual installation. Figure 6-26 Installation options summary window Chapter 6.
14.The installation itself is very fast, but the database creation process may take a while. You may see the black command line window popping up listing the DB2 command execution results. Do not close this window. When the installation process is finished the last window is displayed, as shown in Figure 6-27. Click Finish to close the installation wizard. Figure 6-27 Installation result window This concludes the Tivoli Security Compliance Manager server installation.
The user password settings on the client workstation have to be following the policy, which means that the password must be at least eight characters in length and it must be renewed at least every 90 days. The appropriate operating system service pack level must be installed, which is Service Pack 4 for Windows 2000 and Service Pack 2 for Windows XP. Appropriate hotfixes must be applied. As an example we use the KB896423 and KB893756 hotfixes. The personal firewall must be running.
The status of a posture element can be one of the following: PASS The data collection was successful, and the security posture of the selected item matches the required value. FAIL The data collection was successful, but the detected value indicates that the client is noncompliant and remediation must be performed. ERROR The data collection failed or an internal error occurred.
remediation subsystem, such as a Tivoli Configuration Manager. After the remediation has been performed, the remediation subsystem communicates to the policy collector to obtain updated status and, if necessary, perform additional remediation. 6.2.3 Installation of posture collectors The compliance policies are defined on the Tivoli Security Compliance Manager server and are sets of rules verifying whether the data collected on the client meets the security policy criteria.
3. When the GUI pops up, as shown on Figure 6-28, log in with the credentials you specified during the installation, as described in step 12 on page 150 in the Installation of Tivoli Security Compliance Manager server procedure. Figure 6-28 Tivoli Security Compliance Manager GUI login 4. If it is the first time you start the Administration Console you may be prompted to accept the new server identity, as shown on Figure 6-29. Just click Accept Forever.
5. You are presented with the default Message of the day window, which by default contains only the information about the Tivoli Security Compliance Manager version. Click OK. On the main Administrative Console window, as shown on Figure 6-30, switch to the Policies tab. Figure 6-30 Tivoli Security Compliance Manager Administration Console 6. When you select menu Action → Import Policy, as shown in Figure 6-31, the file selection dialog is presented. Figure 6-31 Import policy action menu Chapter 6.
7. Navigate to the sample_polices directory created in step 1 and select the TCMCLI.pol file, as shown in Figure 6-32. Click Import. Figure 6-32 Import file selection dialog 8. In the next dialog, presented in Figure 6-33, you can change the default policy name. We recommend that you leave the default name unless you have this policy already imported and click Next.
9. In the next step the import wizard performs a validation of the signatures of the collectors included with the policy. When it is completed, as shown in Figure 6-34, click Next. Figure 6-34 Collectors signature validation Chapter 6.
10.Now the actual policy installation is performed. Depending on the collectors you have already installed in your environment you may be asked if the existing collectors should be overwritten with the new ones included with the policy. If you are just following this book, there will be no warnings and you will be presented with the Policy Installation Summary, as shown in Figure 6-35. Click Finish to close the Import policy wizard.
11.After the wizard is closed you will see the imported policy in the Administrative Console, as shown in Figure 6-36. Figure 6-36 Compliance Policy view To import the additional two sample policies named IISSCN_TCM_v2.00_winXP.pol and IISSCN_TCM_v2.00_win2000.pol, repeat steps 6 to 10, selecting the correct files accordingly. 6.2.
must be evaluated on each client workstation. This is the reason why the appropriate values must be supplied as parameters for the NAC collectors rather then in the SQL query in the compliance object definition. 1. To start the customization open the Tivoli Security Compliance Manager Administration Console and log in as admin. Then move to the Policies tab and select the IISSCN_TCM_v2.00_winXP policy, as shown in Figure 6-37.
2. In the right pane click the Collectors tab and select the Symantec Antivirus collector, as shown on Figure 6-38. Figure 6-38 Collectors configuration view 3. The collector responsible for the Symantec Antivirus policy check is named nac.win.any.nav.PostureNavV2, and it is capable of checking three conditions regulated by the parameters specified on the Parameters dialog, shown in Figure 6-39. To open this window right-click the collector name and click Edit collector parameters from the pop-up menu.
The different conditions are: – Version of the Symantec Antivirus Software – Last scan date – Age of the latest virus definition file There are nine parameters regulating the behavior of the collector, as described in Table 6-1. Table 6-1 Parameter information for nac.win.any.nav.PostureNavV2 collector 164 Parameter name Parameter type Description PASS_VERSION Operational A list of acceptable Symantec/Norton Antivirus product versions. This list may consist of one or more entries.
Parameter name Parameter type Description WARN_DEFS_OLDER_THAN Operational A time stamp in the format YYYY-MM-DD HH:MM:SS that the installed virus definitions must be more recent than to avoid generating a warning. DEFS_WF Workflow Name of the workflow used for remediation if the installed virus definitions need to be updated. To adjust the parameters to your need modify the operational parameters, selecting the appropriate tabs. To add additional values to the parameter click the plus (+) sign.
There are six parameters regulating the behavior of the collector, which are described in Table 6-2. Table 6-2 Parameter information for nac.win.any.netaccounts.PostureNetAccountsV2 Parameter name Parameter type Description WARN_MIN_LEN_UNDER Operational An integer value used to indicate the minimum allowable password length to avoid a warning. FAIL_MIN_LEN_UNDER Operational An integer value used to indicate the minimum allowable password length to avoid a failure.
When you are done editing click Save. 5. The next policy we customize is the one that checks for the appropriate operating system service pack level installed on the client workstation. Back at the list of the collectors right-click the Windows Service Pack collector. Then click Edit collector parameters, as shown in Figure 6-41. Figure 6-41 Editing collector parameters Chapter 6.
6. The parameters for the collector nac.win.any.oslevel.PostureOSLevelV2 are displayed, as shown in Figure 6-42. Figure 6-42 Parameters for Windows Service Pack collector As you can see, this is a generic collector for all Windows versions. Since the policy we are editing is applied to Windows XP workstations, we only need to edit the two relevant parameters: – WARN_WINDOWS_XP – PASS_WINDOWS_XP. The full list of parameters is described in Table 6-3. Table 6-3 Parameter information for nac.win.any.oslevel.
Parameter name Parameter type Description WARN_WINDOWS_2000 Operational List of service packs that generate warnings for the Microsoft Windows 2000 operating system PASS_WINDOWS_2003 Operational List of accepted service packs for the Microsoft Windows 2003 operating system WARN_WINDOWS_2003 Operational List of service packs that generate warnings for the Microsoft Windows 2003 operating system PASS_WINDOWS_XP Operational List of accepted service packs for the Microsoft Windows XP operating sys
Back at the list of the collectors right-click the Windows Hotfixes collector. Then click Edit collector parameters. The parameters for collector nac.win.any.hotfix.PostureHotfixV2 are displayed as shown in Figure 6-43. Figure 6-43 Parameters for Windows Hotfixes collector This collector checks for the missing critical hofixes. The parameters are described in Table 6-4. Table 6-4 Parameter information for nac.win.any.hotfix.
8. The next policy we configure checks whether the personal firewall is installed and running. Since we are using the generic posture collectors, this policy was implemented as two separate policies, one for checking the registry if the firewall is installed and the second to check the services if it is running. As an example we have chosen to check for the ZoneLabs firewall, but you can easily adjust these policies for any other personal firewall.
Parameter name Parameter type Description NO_KEY_RULE Operational Used to determine the status of the registry key existence check if the registry key specified in KEY is not found. No more than one parameter value should be provided. If more than one parameter value is provided, only the first parameter value will be used. The parameter value provided should be one of the following: PASS, WARN, or FAIL. If the parameter value is set to either WARN or FAIL, then the KEY_WF workflow is used.
Parameter name Parameter type Description VALUE_DATA_RULES Operational If the registry key specified in the KEY parameter and the registry value specified in the VALUE parameter both exist, then the contents of this parameter are used to determine the status of the registry value data check. The VALUE_DATA_RULES parameter should contain zero or more parameter values that make up the rules. Rules will be explained in more detail in a later section.
Rules Rules are used to evaluate the detected registry value and determine the status of the registry value data element. All rules conform to simple rule grammar, and are composed of the following: A rule operator A rule value A rule result A rule that logically evaluates to true is called a matching rule. A rule that evaluates to false, or cannot be evaluated, is called a failing rule.
There are some limitations on numeric context evaluations. The collector initially receives all values from the underlying utilities as strings. For example, even though the registry type might be REG_DWORD and the value is set to 0x00000630, the collector will receive this value as the string 1584. Numeric checks are only run if both the value in the registry and the value in the rule can be converted to a 32-bit integer.
VALUE equal to InstallDirectory. NO_KEY_RULE equal to FAIL. NO_VALUE_RULE equal to FAIL. Since you do not care about the actual value, but only of its existence, the VALUE_DATA_RULES must be set to: *;PASS If any of the three checks fail you want to have the same remediation workflow kicked off, so specify the same value for all three workflow parameters, for example, TCRZLSoftwareInstalled.
When you are done with editing the parameters for the nac.win.any.regkey.PostureRegKeyV2 collector click Save. 1. The second part of the firewall policy is meant to check whether the firewall service is running. This policy is checked using the generic nac.win.service.PostureServiceV2 collector. To open the parameter edition dialog shown in Figure 6-45, right-click the ZoneAlarm Firewall Active collector in the policy collector view and click Edit collector parameters from the pop-up menu.
Parameter name Parameter type Description REQ_RUNNING Operational A Boolean parameter used to indicate that the services listed in the REQ_SERVICE parameter must be running. A true value (1) indicates that the service must be running. A false value (0) indicates that the service must not be running. All other values are ignored. SERVICE_RUNNING_WF Workflow The workflow used if the REQ_RUNNING check fails.
– SERVICE_RUNNING_WF equal to TCRZLSoftwareRunning – REQ_DISABLED not set – SERVICE_DISABLED_WF not set When you are done editing click Save. 2. According to our security policy outlined in “Security compliance criteria” on page 100 we must add one more policy checking for the status of the Messenger service, which must be disabled. This service is installed by default on any Windows XP workstation, and our corporate security policy requires this service to be disabled.
The new dialog is presented, as shown in Figure 6-47. Select the destination policy for the copy process of the compliance query. Select IISSCN_TCM_v2.00_winXP, which is also the source for this compliance query, and click OK.
There cannot be two compliance queries with the same name in one policy, so the copy of the compliance query is automatically renamed. It received an added _0 suffix. We must rename our new compliance query. Right-click the new ZoneAlarm Firewall Active_0 compliance query and select Rename compliance query, as shown in Figure 6-48. Figure 6-48 Renaming compliance query Chapter 6.
In the following dialog modify the name value to Messenger Service Disabled and click OK. Then, in the right pane, modify the description of the compliance query, as shown on Figure 6-49, and click the Save button on the right.
Next select the Compliance SQL tab on the right pane and modify the violation message generated by the compliance check, as shown in Figure 6-50. There is no need to change the SQL compliance query itself, as it does not refer to any values other than the number of violations, which is generic for all services. When done with the editing click Save. Figure 6-50 Violation message modification Next we modify the collector parameters for the Messenger Service Disabled compliance query.
collector as well. Right-click the ZoneAlarm Firewall Active name under Messenger Service Disabled and click Stop sharing collector item from the pop-up menu, as shown in Figure 6-51. Figure 6-51 Disabling collector sharing A small dialog window is displayed asking you for the new name of the collector instance. Enter Messenger Service Disabled, as shown in Figure 6-52, and click OK.
Now we must change the parameters for the new collector instance. Right-click the Messenger Service Disabled collector instance and click Edit collector parameters from the pop-up menu. The parameters were described in Table 6-7 on page 177. Provide the following parameter values: – – – – – SERVICE_REQ equal to Messenger REQ_RUNNING not set SERVICE_RUNNING_WF not set REQ_DISABLED equal to 1 SERVICE_DISABLED_WF equal to TCRMessengerDisabled When you are done editing click Save. 3.
You are presented with a warning that the changes will affect all of the clients that have this policy assigned, as shown in Figure 6-54. Figure 6-54 Save policy collectors warning Click Yes to have your changes saved. If you have different groups of clients in your environment with different operating systems or different requirements you may need to add more policies, repeating the steps described above for each policy and setting the correct values as appropriate. 6.2.
The steps are: 1. When logged into the Tivoli Security Compliance Manager Administration Console with administrative privileges select the Clients tab and click the Actions → Group → Create Group menu item, as shown in Figure 6-55. Figure 6-55 Create group action selection 2. On the Create group dialog, which is displayed in Figure 6-56, enter the name you want for your group (for example, NAC Windows XP) and click OK. Figure 6-56 Create group dialog Chapter 6.
3. Assign the policy to this new group. Select the group in the navigation tree in the left pane and click Actions →Policy → Add policy, as shown in Figure 6-57. Figure 6-57 Add policy menu selection 4. The Select a policy window is displayed, as shown in Figure 6-58. Select the IISSCN_TCM_v2.00_winXP policy (the one we changed in 6.2, “Configuration of the compliance policies” on page 152) and click OK.
5. An informational dialog is displayed, as shown in Figure 6-59, showing the successful completion. To close it click OK. Figure 6-59 Operation complete dialog 6. Repeat steps 3 to 5 to select the TCMCLI policy this time. When you have your group selected in the left pane and you click the Policies tab in the right pane you should see a window similar to the one presented in Figure 6-60.
book we cover only the installation of the client on Windows. For other platforms and more detailed system prerequisites see Tivoli Security Compliance Manager: Installation Guide: Client Component, GC32-1593. A prerequisite for the Security Compliance Manager client to work within the IBM Integrated Security Solution for Cisco Networks is the already deployed Cisco Trust Agent. This is why we first cover the installation of this component. 6.3.
Note: The following section is an excerpt from the Administrator Guide for Cisco Trust Agent 2.0, which is available at (requires CCO login): http://www.cisco.com/en/US/partner/products/ps5923/products_maintenance_ guide_book09186a008059a40e.html For Cisco Secure ACS to establish a secure PEAP session with Cisco Trust Agent, you must install the root certificate for the Cisco Secure ACS certificate on the network client.
Installation of Cisco Trust Agent on Windows The Cisco Trust Agent installation uses the Microsoft Windows Installer (MSI) and requires administrator privileges. 1. Start the installation process by double-clicking the setup file or typing the command: ctasetup-supplicant-win-2.0.0.30.exe 2. After starting the setup file, the welcome window opens (Figure 6-62). Click Next.
3. The license agreement is presented, as shown in Figure 6-63. Select I accept the license agreement and click Next. Figure 6-63 License agreement for Cisco Trust Agent Chapter 6.
4. Accept the defaults (Figure 6-64) and click Next.
5. Accept the default depicted in Figure 6-65 and click Next. Figure 6-65 Cisco Trust Agent installation type Chapter 6.
6. Click Next (Figure 6-66).
7. If the certificate file was copied into the Certs directory, the window in Figure 6-67 is presented during the installation. Click OK. Remember, this step is optional and will only be presented if you have copied the certificate file to the Certs directory. Figure 6-67 Confirmation of the certificate import Chapter 6.
8. Click Finish to close the installation, as shown in Figure 6-68. Figure 6-68 Successful completion of Cisco Trust Agent installation 9. If you have not created a Certs directory before the installation as described in “Prerequisites” on page 190 or you were not presented with the window shown in Figure 6-67 on page 197 during the installation, install the certificates manually using the ctaCert.exe utility.
If the certificate has been successfully imported, the window shown in Figure 6-69 is displayed. Figure 6-69 Successful certificate import Tip: The ctaCert.exe utility seems to have a problem with long path names. If you have received an error message, ensure that the path to the certificate file is correct, and if the path (including the file name) is very long, move the file to a different location and try again.
The Security Compliance Manager client installation requires the following media: Security Compliance Manager 5.1.0.30 client base installation image. Installation of the Security Compliance Manager client The procedure of the client installation is very similar to the server installation. Both are using the same type of Java installer, however, since this version of the client is running a different version of JVM™ and the installation files were separated.
2. The Security Compliance Manager welcome screen appears momentarily (Figure 6-71). Figure 6-71 The welcome window Chapter 6.
3. The Client Installation Utility window appears, as depicted in Figure 6-72. After carefully reading all of the required information, click Next.
4. The license agreement window is displayed (Figure 6-73). Select I accept the terms in the license agreement and click Next. Figure 6-73 License agreement for IBM Tivoli Security Compliance Manager Chapter 6.
5. Accept the default destination folder, shown in Figure 6-74, and click Next.
6. Accept the default client installation (Figure 6-75) and click Next. Figure 6-75 Setup type window Chapter 6.
7. In the IBM Security Solution for Cisco Networks window (Figure 6-76), ensure that the box Select the checkbox to install IBM Integrated Security Solution for Cisco Networks is checked, then click Next Figure 6-76 The IBM Integrated Security Solution for Cisco Networks window 8. In the client communication mode window, select the port on which the client listens for requests. The default port is 1950.
Figure 6-77 Client connection window Chapter 6.
9. The server communication configuration window, shown in Figure 6-78, is used to provide the client with the location information of the server. In the Server host name field insert the fully qualified name of the Security Compliance Manager server (or IP address). The default value for the Server connection port field is 1951. Unless you have selected a different port number during the server installation, accept the default.
10.If you selected the DHCP option in the previous step, you will see the client DHCP configuration dialogue, as in Figure 6-79. In the DHCP client alias field, provide the alias name for the client. This name will be shown on the Security Compliance Manager server during client registration, and the client will be referenced by this name in the Security Compliance Manager GUI. If this field is left blank, the name that will appear in the Security Compliance Manager GUI will be the client’s computer name.
11.Finally, the installation summary window is displayed (Figure 6-80). Click Next.
12.The Security Compliance Manager client is successfully installed. Click Finish to close the window shown in Figure 6-81 to complete this step of the process. Figure 6-81 Successful completion window Chapter 6.
13.If you want to verify that the Security Compliance Manager posture plug-in was registered successfully with the Cisco Trust Agent, check the C:\Program Files\Common Files\PostureAgent\Plugins directory. The ibmnac6.dll and ibmnac6.inf files should be there (Figure 6-82). Figure 6-82 Security Compliance Manager posture plug-in files 6.4 Conclusion This concludes the installation and configuration of the basic compliance subsystem.
7 Chapter 7. Network enforcement subsystem implementation This chapter contains detailed descriptions for the installation and configuration of the following network enforcement subsystem components: Configuring NAC Framework components – Configuring the Cisco Secure ACS for NAC L2 802.
7.1 Configuring NAC Framework components This section focuses on the deployment of NAC Framework. NAC Framework can be deployed as NAC L3 IP, NAC L2 IP, or NAC L2 802.1x. Configure the Cisco Secure ACS for NAC L2 802.1x. Configure the Cisco Secure ACS for L2/L3 IP NAC. Deploy the network infrastructure (authenticator). Configure a Cisco 3750 switch with Cisco IOS software as a Network Access Device. 7.1.1 Configuring the Cisco Secure ACS for NAC L2 802.
Installing Cisco Secure ACS To install Cisco Secure ACS Version 4.0 software on a machine running a supported operating system, run the setup.exe program provided with the Cisco Secure ACS installation software. When you install Cisco Secure ACS, the setup program uninstalls any previous version of Cisco Secure ACS before it installs the new version. If you have a previous version, you are given the option to save and reuse your existing configuration.
Configuring the administrative interface to Cisco Secure ACS By default, not all features and options of the Cisco Secure ACS administrator interface are enabled. The advanced features required by the IBM Integrated Security Solution for Cisco Networks are not used in common Cisco Secure ACS deployments. For our solution some of these features must be activated. They are used by Cisco Secure ACS to communicate enforcement actions to the NAD.
Note: Group-level downloadable ACLs are not yet supported for L2Dot1x. They are only supported for NAC L2/L3 IP. It is Cisco’s stated intention that future releases of IOS for switches will support downloadable ACLs for NAC L2 802.1x. Access restriction for NAC L2 802.1x should be configured as an access-list bound to the SVI on the L3 device closest to the end user. In the example used for this book, the access lists were bound to the SVIs defined on the 3750 switch.
Allowing administrator access via HTTP (optional) If you want to configure ACS from a remote client using the Web interface, you must configure at least one administrator user name and password: 1. Click Administration Control on the Cisco Secure ACS main menu. This opens the window shown in Figure 7-4. Click Add Administrator.
2. Fill in the user name and password fields, and click Grant All to give all configuration rights to the administrator. If desired, an administrator’s privileges can be limited to individual groups and components in order to have separate administrators for different parts of the network and network policies. Click Submit to complete the process.
Note: We highly recommend that you use a production PKI and certificates signed by the production certificate authority (CA) or a registration authority (RA) for the most scalable NAC deployments. You will need to use an existing PKI (internal or outsourced) to securely identify the ACS infrastructure to endpoint devices (for example, CTA). For information about obtaining and installing a certificate from a certificate authority refer to (requires CCO login): http://www.cisco.
To use a self-signed certificate, perform the following steps: 1. Click Generate Self-Signed Certificate in the Cisco Secure ACS Certificate Setup window (Figure 7-6). Figure 7-6 Generating self-signed certificate 2. Fill in the blanks with the appropriate information according to your own installation. Be sure to enable Install generated certificate. In the example used here: – – – – – Certificate subject: cn=iisscn_demo Certificate file: c:\certs\iisscn_demo.cer Private key file: c:\certs\iisscn_demo.
4. Restart the Cisco Secure ACS (Figure 7-7).
5. After completing the certificate setup process and installation, verify that the certificate has been installed by clicking Install ACS Certificate from the ACS Certificate Setup screen (Figure 7-8). Figure 7-8 Self-signed certificate installation verification 6.
To import Security Compliance Manager attributes, perform the following steps: 1. Copy the Security Compliance Manager attributes definition file to a directory accessible to the Cisco Secure ACS. Example 7-1 shows the content of the Security Compliance Manager attribute definition file for information purposes. We strongly urge you not to modify this file.
filename is the name of the file in which you want CSUtil.exe to write all attribute definitions. Example 7-2 shows the execution of this command. Example 7-2 Import Security Compliance Manager attribute C:\Program Files\CiscoSecure ACS v4.0\Utils>CSUtil -addavp c:\Temp\avplist.
filename is the file that the attributes will be written to. The Security Compliance Manager attributes should be viewable in this file. Tip: The result of csutil.exe -dumpavp contains these two attributes, which are added automatically when csutil.exe -addavp is executed: IBM Corporation:SCM:Application-Posture-Token IBM Corporation:SCM:System-Posture-Token Configuring logging Logging configuration is crucial for monitoring, reporting, and troubleshooting a NAC implementation. To set up logging: 1.
that you wish to include in the log file. Scroll down and change the file management settings if desired. We recommend that you include the following fields in Logged Attribute: – – – – – Network Access Profile Name Shared RAC Application Posture Token System Posture Token Reason These should be moved toward the top of the list of installed attributes for easy access. This makes writing policy rules and troubleshooting much easier.
6. Click the Log to CSV Failed Attempts report under Enable Logging. Repeat step 4 on page 226, selecting the items you wish to log. A selection is shown in Figure 7-11. Figure 7-11 Failed attempts logging 7. Click System Configuration again on the Cisco Secure ACS main menu, and click Service Control.
8. In the window in under Services Log File Configuration (Figure 7-12) change Level of Detail to Full, and increase the file size from 2048 Kb as necessary. Click Restart to apply the new configuration. Figure 7-12 Log file management Configuring a network device group in Cisco Secure ACS To make Cisco Secure ACS interact with a Network Access Device (router, switch, VPN concentrator, and so on), you must configure Cisco Secure ACS to use the proper NAD information.
It is possible to group the NADs into Network Device Groups (NDGs) for location or service-based filtering. To do this, the use of NDGs must first be enabled: 1. Click Interface Configuration from the main menu (Figure 7-13).
2. Select Advanced Options (Figure 7-13 on page 230). Ensure that Network Device Groups is checked (Figure 7-14). Figure 7-14 Network Device Group check box Chapter 7.
3. Select Network Configuration in the main menu. The screen in Figure 7-15 is shown. Figure 7-15 Network Configuration Note: Figure 7-15 changes depending on your interface configuration. If you are using Network Device Groups (NDGs), after you click Network Configuration in the main menu, only the Network Device Groups table and Proxy Distribution Table information appear. If you are not using NDGs, the AAA Clients table and the AAA Servers table appear in place of the Network Device Groups table. 4.
6. From the Network Configuration screen, select the hyperlink under Network Device Groups. If you did not assign a name in step 5, you will see Not Assigned as the name (Figure 7-15 on page 232). By clicking this link, you will see the AAA Clients (Figure 7-16). Figure 7-16 AAA clients Chapter 7.
7. Click Add Entry under AAA Clients to add any AAA clients to this particular NDG. You can configure all NADs as a single AAA client by using IP address wild cards (*.*.*.*). In Figure 7-17 we have done this and used the RADIUS key cisco123. Note that authentication is done using RADIUS (IOS/PIX6.0). There are other options available, depending on what is being defined as a NAD. Click Submit and then Apply. Figure 7-17 AAA client setup Note: The use of wild cards (*.*.*.
8. You should now see the newly defined AAA clients (Figure 7-18). Figure 7-18 AAA Clients Chapter 7.
Configuring RADIUS attributes The RADIUS attributes required for NAC must be globally enabled on the Cisco Secure ACS. 1. Select Interface Configuration from the main menu (Figure 7-13 on page 230), then select RADIUS (IETF) (Figure 7-19). Figure 7-19 Global IETF RADIUS attributes For L2Dot1x NAC, you must select the following: – – – – – [027] Session-Timeout [029] Termination-Action [064] Tunnel-type [065] Tunnel-Medium-Type [081] Tunnel-Private-Group-ID After selecting just these items, click Submit.
2. From the Interface Configuration menu, select RADIUS (Cisco IOS/PIX 6.0) (Figure 7-20). Figure 7-20 Cisco IOS/PIX 6.0 RADIUS attributes For L2Dot1x NAC, you must select [026/009/001] cisco-av-pair. 3. After selecting this item, click Submit. Configuring groups The group setup and configuration portion of the Cisco Secure ACS requires careful thought and planning. In the NAC L2 802.1x scenario we are using here, we have two locally defined groups, sales and engineering.
Active Directory, for example. To configure groups and vendor-specific attributes, complete these steps: 1. Click Group Setup on the Cisco Secure ACS Main Menu. 2. Choose any unused groups, and rename each group as applicable. In the example here, we have renamed Group 2 as Sales and Group 3 as Engineering. Figure 7-21 Group Setup Note: Only the group names need to be defined.
Configuring users Now that the groups have been defined, we can create our users and then add them to their relevant group. 1. From the main menu select User Setup, as shown in Figure 7-22. Figure 7-22 User setup 2. In the User field, type the name of the user to be added, then click Add/Edit. Chapter 7.
3. You will be prompted for the user’s real name and description under Supplementary User Info, followed by user setup details, as shown in Figure 7-23. The password authentication, in this example, is set to ACS Internal Database, the password has been entered and confirmed, and the user has been assigned to a default group. The list of groups available will be a direct result of those you configured in Figure 7-21 on page 238.
Global authentication setup The Cisco Secure ACS supports many types of protocols for securely transferring credentials from the host to the Cisco Secure ACS for authentication and authorization. Note: We highly recommend that you enable all protocols globally. You will have the opportunity to limit the actual protocol options later when you create the Network Access Profiles for NAC. If they are not enabled here, they will not be enabled in the Network Access Profiles. 1.
4. Click EAP-FAST Configuration from the Global Authentication Setup (Figure 7-24 on page 241). Figure 7-25 EAP-FAST Configuration screen 5. The EAP-FAST configuration, as shown in Figure 7-25, requires you to enter a lot of fields. Table 7-1 lists all fields and their respective values.
EAP-FAST configuration Condition Require client certificate for provisioning Checked Allow Machine Authentication Checked Machine PAC TTL One week Allow Stateless Session Resume Checked Authorization PAC TTL One hour Allow inner methods EAP-GTC Checked EAP-MSCHAPv2 Checked EAP-TLS Checked Select one or more of the following EAP-TLS comparison methods: Certificate SAN comparison Checked Certificate CN comparison Checked Certificate Binary comparison Checked EAP-TLS Session timeout (mi
Configuring posture validation To do this: 1. Select Posture Validation from the Main Menu (Figure 7-26).
2. Select Internal Posture Validation. The screen show in Figure 7-27 will be displayed. 3. Click Add Policy (Figure 7-27). Figure 7-27 Posture Validation Policies Chapter 7.
4. In this example, we have entered the name of the first policy as CTA with the description Cisco Trust Agent. Then click Submit (Figure 7-28).
5. Click Add Rule (Figure 7-29). Figure 7-29 Posture Validation for CTA Chapter 7.
6. Click Add Condition Set (Figure 7-30).
7. From the Attribute drop-down list (Figure 7-31), select Cisco:PA:PA-Version. The operator value should be set to >= and the value set to 2.0.0.0. This simply means that we are setting up a check for the Cisco Trust Agent to be present on the endpoint, and that it must be running version 2.0.0.0 or later. Click Enter when this is done, and then Submit. Figure 7-31 Adding a condition set Chapter 7.
8. Figure 7-32 shows that if this condition is satisfied, that an Application Posture Token (APT) of Healthy is returned. Clicking Submit here takes us to Figure 7-33 on page 251.
9. Next we need to modify the default action, which is the action to be taken if the condition we just created is not met. You will notice that there is a default condition, which we will modify for this purpose. Click Default under Condition (Figure 7-33). Figure 7-33 CTA rule defined Chapter 7.
10.The posture token remains Cisco:PA, however the posture token value should be changed to Quarantine, as shown in Figure 7-34. In the notification string, add the line: http://tcmweb/SoftwarePackageServerWeb/SPServlet Figure 7-34 Quarantine condition applied as default action Note: http://tcmweb/SoftwarePackageServerWeb/SPServlet is the location of the software remediation package. The URL can be changed depending on where the remediation software packages are stored.
11.Click Submit and you will find yourself back in the dialog shown in Figure 7-35. Figure 7-35 Completed posture validation for CTA 12.Click Done. Chapter 7.
13.Click Apply and Restart, as shown in Figure 7-36. Figure 7-36 CTA posture validation policy 14.Next we must repeat the process to create a posture check for the IBM:SCM.
15.Click Add Policy (Figure 7-37). Figure 7-37 Repeating the process for Security Compliance Manager Chapter 7.
16.In this example, we use TSCM in the Name field and IBM Security Compliance in the Description field, as shown in Figure 7-38.
17.After entering the name and description, click Submit and you will see the dialog shown in Figure 7-39. Figure 7-39 IBM TSCM policy creation Chapter 7.
18.Click Add Rule to get to the screen shown in Figure 7-40. Figure 7-40 Condition set creation for TSCM 19.Click Add Condition Set. From the Attribute drop-down menu, select IBMCorporation:SCM:PolicyVersion. From the Operator menu select Contains, and for the Value enter the value of the security policy being used on the Security Compliance Manager server. In this example, the policy version is IISSCN_EBU_v2.20_winXP. Click Enter. Note: This is to enforce the version of the TSCM policy being used.
20.From the Attribute drop-down menu, select IBMCorporation:SCM:PolicyViolation. From the Operator menu select =, and for the Value enter 0. Then click Enter (Figure 7-41). Figure 7-41 TSCM policy components 21.Click Submit. Chapter 7.
22.Make sure that the posture token is set to IBMCorporation:SCM, and the value should be set to Healthy (Figure 7-42). Figure 7-42 Completed posture validation check for Security Compliance Manager 23.Click Submit. 24.Next we must modify the default condition. Click Default, as shown in Figure 7-39 on page 257.
25.The posture token should be set to IBMCorporation:SCM (Figure 7-43) and the value should be set to Quarantine. The notification string should be the same as we discussed in step 10 on page 252 of this section: http://tcmweb/SoftwarePackageServerWeb/SPServlet Figure 7-43 Security Compliance Manager Default condition modification 26.Click Submit. Chapter 7.
27.Click Done (Figure 7-44).
28.Click Apply and Restart (Figure 7-45). Figure 7-45 Completed posture validation rules Chapter 7.
Configuring RADIUS Authorization Components In this section we configure RADIUS Authorization Components (RAs), a new concept introduced with Cisco Secure ACS 4.0. Note: We deleted all of the default RACs and started with a blank screen. It was cleaner to work with and take you through the steps of creating a RAC from scratch, as opposed to cloning an existing example. 1. Click Shared Profile Components from the main menu. This brings you to the dialog shown in Figure 7-46.
Note: In the scenario detailed in this book, we have two groups defined: sales and engineering. When creating the RACs, we define a Healthy Sales RAC, a Quarantine Sales RAC, a Healthy Engineering RAC, and a Quarantine engineering RAC. We also define a Default Quarantine RAC to address the situation where a condition may not be defined or there is no matched condition. When a user authenticates via IEEE 802.1x, the posture is checked and a RAC is applied.
6. Click Add next to Cisco IOS/PIX6.0, which brings you to Figure 7-47. Figure 7-47 IOS RAC attribute 7. In the value field, enter status-query-timeout=30. 8. Click Submit. 9. Repeat this procedure, clicking Add next to Cisco IOS/PIX 6.0 and add the values as per Table 7-2 on page 265 for the Cisco IOS/PIX 6.0 requirements.
10.Repeat the same procedure for the IETF attributes, first selecting the relevant field from the drop-down menu, then clicking Add (Figure 7-48). Use the values in Table 7-2 on page 265. Figure 7-48 IETF drop-down menu Chapter 7.
11.When completed, your Healthy Sales RAC should look like Figure 7-49. Figure 7-49 Healthy Sales RAC 12.Click Submit. 13.Repeat steps 3 through to 12 for each of the RACs to be configured. Using our example, there are the Healthy Engineering RAC, the Quarantine Sales RAC, the Quarantine Engineering RAC, and the Default Quarantine RAC to be configured. The values for each can be found in the following tables. Table 7-3 Healthy Engineering RAC attributes 268 Vendor Attribute Value Cisco IOS/PIX 6.
Vendor Attribute Value IETF Tunnel-Private-Group-ID (81) [T1] 12 Table 7-4 Quarantine Sales RAC attributes Vendor Attribute Value Cisco IOS/PIX 6.0 cisco-av-pair (1) status-query-timeout=30 Cisco IOS/PIX 6.
Vendor Attribute Value IETF Termination-Action (29) RADIUS-Request(1) IETF Tunnel-Type (64) [T1] VLAN (13) IETF Tunnel-Medium-Type (65) [T1] 802 (6) IETF Tunnel-Private-Group-ID (81) [T1] 15 Note: The dot1x reauthentication timer is controlled by the value assigned to the IETF Session-Timeout (27) attribute. If set to 60, for example, the CTA pop-up screen will appear on the client workstation every 60 seconds. There will be some fine tuning required to find an appropriate value here.
Configuring Network Access Profiles We have now configured all of the individual components to be in a position to bring them together and create the Network Access Profiles, which determine what to check and what action to take based on the results of those checks. Again, we have deleted all of the pre-configured sample configs to create our own from scratch. 1. Select Network Access Profiles from the main menu, which brings you to the dialog in Figure 7-50. Figure 7-50 Network Access Profiles 2.
4. The newly created NAP is shown (Figure 7-51) with the three policies that comprise the NAP — authentication, posture validation, and authorization. Each of these will have to be configured in turn, after clicking Apply and Restart. Figure 7-51 Newly created NAP Note: Be careful in the selection of Deny access when no profile matches or Grant access using global authentication when no profile matches. In our example, we use Grant access....
5. Click Authentication. Click the tab Populate from Global and ensure that Posture Validation - Required is set. Selected Databases should contain ACS Internal Database (Figure 7-52). Figure 7-52 Authentication configuration for RAC 6. Click Submit. This will take you back to the screen in Figure 7-51 on page 272, where you will need to click Apply and Restart. 7. Click Posture Validation from the screen in Figure 7-51 on page 272. Chapter 7.
8. From the screen shown in Figure 7-53, click Add Rule. Figure 7-53 Posture validation rule creation 9. Add a name in the Name field. In our example we used NAC_IISSCN_Posture_Profile.
10.Under Condition → Required Credential Types, there is a list of available credentials. Select IBMCorporation:SCM, then click the arrow ( →) to move this to the column for selected credentials, as shown in Figure 7-54. Repeat this process for Cisco:PA (Figure 7-53 on page 274). Figure 7-54 Partial configuration of posture validation Chapter 7.
11.Scrolling down the page to Action → Selected Internal Posture Validation Policies, CTA and TSCM should already be present. The only action required here is to check them both under Select (Figure 7-55). Figure 7-55 Selecting CTA and TSCM policies 12.(Optional) Under System Posture Token Configuration, add the following syntax in the Healthy PA message: 
PAGE 295
An example of the CTA Healthy pop-up is shown in Figure 7-56. Figure 7-56 Example of CTA Healthy pop-up 13.(Optional) Under System Posture Token Configuration, add the following syntax in the Quarantine PA message (this process is depicted in Figure 7-58 on page 278): 
