Building an Intel AMT Agent Monitor (Part 1)

This article explores the security benefits of Intel® Active Management Technology (Intel® AMT), specifically the System Defense feature, network security policies and heuristic filters to finally build an Agent monitor (or "Agent Presence"). This article is written by Javier Andres Caceres Alvis. Javier works as a Software Engineer for Aranda Software (ISV enabling for Intel AMT).


Intel AMT has two closely related features: System Defense and Agent Presence. Below is a brief description of what they are and how to use them:

• System Defense (previously known as "circuit breaker"): is in short the capacity of a machine to block the traffic of packets through a network security policy. A network security policy is the way to group filters and a filter is a test made to the incoming or outgoing traffic from one machine to verify if it meets certain conditions (for example, a common condition is to review the packages’ IP).

There are pre-loaded filters and the possibility of creating new ones. Heuristic filters are types of filter that can block the outgoing traffic from one machine to prevent it from infecting / attacking other machines on the network. This traffic blocking is done through the inspection of outgoing packets in order to find unusual operating conditions. Find more on this topic here (/en-us/articles/download-the-latest-intel-amt-software-development-kit-sdk).

• Agent Presence: This feature allows an independent vendor’s software agent (like: a firewall, an anti viruses, an asset tracker) to report to Intel AMT that: 1) it is started, 2) it is running 3) it is shutdown. This very important because a user or an exceptional condition may terminate or stop a software agent unexpectedly.

The way Agent Presence and policies interact with an agent monitor is through state transitions. For example: when the monitor reports that an agent changes from "Running" to "Expired" state, it is possible to automatically activate/disable a policy to allow / block all inbound / outbound traffic.

Building an agent monitor

Agent monitors are built in two pieces: one in the AMT machine (local) and one in the monitoring console (remote). The remote piece is for agent monitor management functions: like creation, selection, and deletion. The local piece is for agent monitor registration (previously created in the remote interface) and reporting (of its currently state through “heartbeat” signals). The way in which both parts communicate is via a shared GUID.

Using the Intel Manageability DTK:

In the Manageability DTK, there is an application called “Intel AMT Outpost” which one simulates to be an agent monitor and it attracted my attention because it lets making a relation between the heartbeat signals and any application’s execution.

You can start by taking the DTK’s source code as a basis to write a C# solution made of a monitor console and an agent. Both the console and the agent consume Intel AMT machine’s web services (EOI, not WS-Man). Agent monitors are also known as watchdogs. The results of this exercise are two sample applications: a remote one (Figure 1) for watchdog creation, deletion and selection and a local one (Figure 2) for watchdog registration and reporting.

Figure 1. Agent monitor console.

Both applications share a GUID to uniquely identify each other. The application’s source code is available. Some agent monitor’s parameters (like heartbeats) are static. Note that this is a sample, so it does not meet best design practices.

Figure 2. Agent monitor.

During the development of this sample I learnt two things: 1) it’s necessary to increment the heartbeat sequence and 2) the relation between a heartbeat signal and an application’s execution shown in “Intel AMT Outpost” is merely descriptive; I mean, it is an agent monitor‘s task to perform any action to verify the application’s execution and it is not an built-in AMT function.

During the testing stage I found that it is not necessary to create a “watchdog” before performing a registration or a reporting action. General recommendations: 1) Use “localhost” instead of IP in Windows Vista machines, 2) Don’t use the remote interfaces from AMT host, 3) If you get a "Failed to parse the request" exception while calling any web service method it’s probably that you need to change the WSDL files’ version (in my case, I first added a web service reference to SDK WSDL files and then I needed to change them) and 4) be careful with the heartbeat sequence increments because your unsigned int variable (that holds this value) can become huge.

For more complete information about compiler optimizations, see our Optimization Notice.