attempts by the client to access a protected resource will also trigger a PostureQuery from the network. This StatusQuery cycle is typically configured to a low value so that any changes that occur on the client after it has been admitted to the network will be detected quickly.

In a typical scenario, the network initiates the process by sending a PostureQuery to the client. The client responds with its current posture attributes, which are then compared against configured rules on the ACS Server. Based on this comparison, the client will be evaluated as either Healthy or Quarantined:

￿In the simpler case, the client is evaluated as healthy and a notification of heathy evaluation is sent to the client. Note that this notification is not the PostureNotification that would be sent to the client if the posture was evaluated as quarantined.

The healthy notification is processed completely by the Cisco Trust Agent on the client and the Tivoli Compliance and Remediation client never sees it. After this notification is sent, the network enters the StatusQuery polling cycle, basically asking the client whether anything has changed each time the cycle repeats. If something changes on the client, it will be reflected as a status change and the network will then reset both polling cycles and issue a PostureQuery to the client, starting the whole process over to evaluate the new state on the client.

￿If the initial PostureQuery ends with the client being evaluated as quarantined, this status is sent to the client as a PostureNotification, which is accompanied by a URL that the client uses to request remediation. The client responds by acknowledging the PostureNotification, signaling the network to enter the StatusQuery polling cycle. The network continues to poll for state changes on the client using the StatusChangeQuery request. Now the client is free to request automated remediation or to prompt the user to manually remediate whatever violations have been detected.

The system stays in this state until remediation actions are complete, at which time the Security Compliance Manager Client will automatically rescan all collectors, or until the user presses the Rescan button on the remediation handler. Either of these events cause a rescan of all collectors, and if anything has been remediated on the client, the state changes. The next time the network polls, it realizes that the status has changed and re-initiates the process by issuing a PostureQuery to the client.

Fault isolation

Now that the overall sequence of events is understood, it should be straightforward to isolate any fault to one of the subsystems or interfaces and

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

Page 466
Image 466
IBM Tivoli and Cisco manual Fault isolation