Intel® vPro™ Technology

Advanced Security Features of Intel® vPro™ Technology

Audit Log

Intel® vPro™ technology creates a powerful tool for the network administrator to control the network entities. However, being in possession of a powerful tool comes with risks: the risk of erroneous use of this tool, and more importantly, the risk of malicious use of this tool. Rogue insiders are becoming a real threat to worldwide governments and enterprises, as demonstrated by a recent San Francisco network lockout [8].

A legitimate insider such as a network administrator already has very powerful credentials to access sources of business-critical information in an enterprise. Unfortunately, if such administrators turn against the enterprise, they become rogue insiders, and prevention of malicious use of a privileged system is nearly impossible. However, the risk can still be mitigated, by using deterrence mechanisms, and this is where auditing capabilities comes into play. [9, 10]

The Intel® Active Management Technology (Intel® AMT) audit log (see Figure 3) is an internal log that captures the administrator’s operations in the system, and also captures unauthorized accesses to the system. When a security breach is discovered, the audit log can assist in tracking down the administrator that may have caused the breach.

Figure 3: Intel® AMT audit log
Source: Intel Corporation, 2008
click image for larger view

The auditing capability cannot prevent system administrators from misusing the system, but it will prevent them from covering their tracks. The Intel AMT auditing subsystem allows an enterprise, or the authorities, to follow the steps of the administrator responsible for misusing the system, in a manner that is provable and undeniable. Having such a mechanism in place can deter an administrator from misusing the system in the first place.

Separation of Duties
An audited system has both an administrator and an auditor role. The auditor controls the audit log policies and contents. In many cases, an enterprise will outsource their auditing services to an impartial third-party company that provides auditing services. A separation of duties is required to create a true audited system, one that cannot be tampered with by the internal enterprise administrators.

The separation of duties concept is adhered to in the credential mechanism embedded in the audit log subsystem. While the administrator might usually be omnipotent where the system is concerned, the audit log is outside of his or her purview. The administrator should not have the credentials to clear the log, modify the auditing policies, or modify the auditor’s access credentials. The auditor, in turn, should only be given enough privileges to manage the audit log. Conversely, administrative operations in the system are typically outside of the auditor’s purview. This is the concept of “two person controls.” Thus, in order to compromise a network, and escape undetected, the administrator and auditor would have to collaborate.

Audit Log Records
A record in the audit log represents an administrative operation on the system. The record contains the following information:

• Identifier of the operation being logged.
• Access control credentials (username) that were used for the operation.
• IP address of the management console that initiated the operation.
• Timestamp of the operation.
• Additional information specific to the operation, if applicable.

Posting an Event to the Log
For an enterprise to claim it maintains a security log, the sequence of records in the audit log must match what transpired in the system. This means that if the administrator initiated an operation that should be logged in the audit log according to the policy, and the log entry could not be written because the log was full (an extremely rare scenario, which as we explain later, we try to prevent from occurring at all costs), then the operation fails. When the log needs to be retrieved, the auditor can be certain that no auditable operations occurred in the system other than those written in the log.

Auditing Policy
The auditing policy defines which administrative operations should be logged in the audit log. Operations can be defined in the policy as “critical” or “noncritical,” and how operations are defined is crucial to a proper balance of security and usability within an enterprise. Critical events will always be logged; if a critical operation occurs and the log is full, the operation will fail. Noncritical operations will be logged only if the log is at least 20 percent empty. When the log is nearly full and a noncritical operation occurs, the entry will not be logged and the operation will not fail. Noncritical operations are logged as space permits. The last 20 percent of the log is reserved for critical operations only. A true, foolproof audit is therefore performed only on critical operations.

The Audit Trail
Due to the limited capacity of the Intel AMT flash, and the usability concerns described earlier, the auditor needs to clear the log periodically. Before clearing the log, the auditor requests an audit trail: this is the current contents of the log, signed by the firmware auditing service in a way that can later be verified by the auditor. The auditor can store the trail in long-term storage, such that if a breach occurs later, the old log can still be retrieved. The signature can attest to the fact that the logs have not been tampered with while in long-term storage. Figure 4 illustrates the structure of the audit log trail.

Two potential problems may arise with this approach. The first is the ability of an administrator to delete an entire signed trail from long-term storage. This issue may be addressed by adding an incremental counter to the signed trails. This allows the auditor to make sure that all signed logs are in place. In addition, the enterprise administrator should not have access to long-term storage, but a discussion of this issue is beyond the scope of this article.

Figure 4: Intel® AMT audit log trail structure
Source: Intel Corporation, 2008
click image for larger view

A second issue that may arise from this approach is the revocation of the keying material used to sign the audit trail. It is recommended that an additional signature be added to the auditing software by means of a temporal certificate being added to the trail before it is stored in long-term storage. When this certificate is replaced periodically, the logs in long-term storage should be re-signed. This adds another layer of authentication in case the keying material used to sign the audit trail is compromised or revoked.

This kind of an auditing system provides very robust protections against rogue-insider attacks.

Back to Top