Data Retention Policy

It can be useful to know when Asset Manager has interrogated an address using various discovery types and not received a response. When Asset Manager's Data Retention policy is disabled, this non-response gets communicated back to the Asset Manager Command Center (CC) as a “Negative Acknowledgement” (a “NACK”) that explicitly tells the Command Center that Asset Manager asked a question and didn’t get an answer.

Persistent Profiling Policy

In Asset Manager versions before 3.2.7, a ‘persistent’ profiling policy was in place. This assumed that a non-response from a device likely indicated a temporary condition that prevented it from responding (e.g., firewall, network impairment, etc.). It then assumed that the device would continue to retain the same attributes that it previously held until specifically ‘told differently’ by the device. In other words, if discovery of any scan type returns no response or a NULL response, then the previously discovered attribute data is kept and used in the profiling process.

Note that, if all scan types returned no response, then Asset Manager started a countdown timer. If the timer expired without any responses from the targeted device, the device was moved to the ‘non-responder’ category. All the most recently received scan attribute data was retained.

Non-Persistent Profiling Policy

An additional profiling policy was added at Asset Manager 3.2.7 that takes a non-persistent viewpoint regarding discovery of attributes. If a scan returns no response or a NULL response, Asset Manager assumes a change of device attributes or that a new device is now at that destination. With this policy enabled, those scans will result in ‘clearing out’ the discovered attribute data for that scan type. The device profile will then be based on the remaining scan attribute data, if any exists.

Because scan attribute data is cleared with each non-response, a fully non-responsive device ends up with no attribute data at all under this policy.

Examples of the Non-Persistent Policy in Action

NOTE: The illustration below does not account for the non-alignment of scan cycles between scan types.

Event		Transition to Linux	Switch to Linux Complete		Some Ports are Closed	Device is Removed
	Starting State	Scan 2 (HTTP Scan)	Scan 3 (CIFS Scan)	Scan 4 (HTTP Scan)	Scan 5 (Port Scan and SNMP Scan)	Scan 6 (Port Scan)	Scan 7 (HTTP Scan)	Scan 10
ICMP	Yes	Yes	Yes	Yes	Yes	Yes	None	None
HTTP	Windows 10	None	None	Linux	Linux	Linux	None	None
TCP Ports	23, 161, 162, 80, 443, 8080	23, 161, 162, 80, 443, 8080	23, 161, 162, 80, 443, 8080	23, 161, 162, 80, 443, 8080	23	None	None	None
CIFS	Windows 10	Windows 10	None	None	None	None	None	None
SNMP	Yes	Yes	Yes	Yes	None	None	None	None


Device Profile	Windows 10	Windows 10	None	Linux	Linux	Linux	None	None
Description	Profile based on CIFS as the highest confidence factor (for this example)	Retains the same profile even though HTTP did not return data - still based on CIFS as highest confidence but the CIFS scan has not completed yet.	The failure to get CIFS response along with the lack of HTTP response results in the lack of a profile for this device.	For Linux, HTTP banner is the next most highest confidence indication (since CIFS did not return an indication)	The open ports state has changed but that does not affect the profile determination. The device attributes are updated to show the new open/closed ports.	Ports are all found closed. The other scan type data is from the most recent previous scans. Transition state to non-responder has started but has not been fully diagnosed yet. AS A RESULT, some scan data will be updated (in this case TCP Ports). Scan 10 will have these updates in it.	All scan types have now iterated and found this device to be completely non-responsive.	After 3 cycles of inactivity, determine this device to be a 'Non-Responder'. Device attributes reflect the last set of attributes received for each scan type. NOTE - This state will be changed with the “Device Lifecycle View” feature.
Device Attribute (Data) Handling Rule		Clear the HTTP response because no response was received.	Clear the CIFS profiling match and response because no response was received.

Frequently Asked Questions

Q1: For example, let’s say I have two different IP and MAC addresses, but the result of device consolidation indicates them to be the same type of device. How is this differentiated between a single machine with two interfaces, and two machines each with one interface?

A1: This is the most common case. For example, thousands of Windows 10 PC’s will likely be discovered. When they are first found, they have matching profiles. The Asset Manager ‘consolidation’ process considers a number of factors (such as serial number, interface tables, etc.) to determine whether an interface (IP/MAC) or router ID is associated to a parent device. Note that the host does not have to be responsive to be recorded as a device. Asset Manager creates a device for any IP or MAC or Router ID that is found.

Q2: For another example, suppose I have one IP address with no MAC information, and 72 hours ago its profile indicated an open port 80 running Apache with “ServerTokens PROD” restricting the banner information from being presented. 24 hours ago, the port 80 was found closed. How is the device profile affected by this set of circumstances, and the multitude of other combinations that could happen?

A2: In the current default implementation, the device profile is not affected. When we receive new information about the device, we update the device attributes. The lack of a response does not affect the device profile but does affect device attributes (port 80 is now closed). However, if a port becomes open and newly discovery attributes are found via that port, it could result in a different, higher-confidence match.

Q3: Lastly, suppose a similar scenario to the second one, but this time, port 445 was found open in the 72 hour old scan, but all ports were closed in the more recent scan. What device profile would be reported?

A3: In the current default implementation,the device profile will remain the same but the port status will be reported as closed. Refer to xxx document for details regarding the proposed future implementation in this area.

Q4: I need to better understand the conditions in which device_id will change. If all other details of a host remain the same, but the IP address changes, as in the case of a DHCP assigned endpoint, is a new device_id generated each time this happens? If so, how is the churn that this creates on a large network dealt with, are old assignments expired off and reused after a given interval, etc.? In general, can you help me understand what factors go into assigning a new device_id? And what the maximum size of a device_id is?

A4: When a new MAC is discovered, a new interface (this is referred to as ‘device’ in the database tables) is created with a unique DeviceID which is a 4-byte auto-incrementing integer (1 to 2,147,483,647). As shown in the charts above, this is then assessed to determine whether it is a new stand-alone device or one interface on a multi-interface device (ie. ‘consolidated’). If it belongs to a parent device, then the DeviceID record points to the parent DeviceID. In this way, DeviceID’s don’t change.