The table below lists currently supported capture sources, on which OS they are supported, and which capture method is used by default. See Constraints of Legacy OS regarding Windows XP, Vista and Windows Server 2003.

How do I retrieve the data from Tachyon client devices?

Live and aggregated TAR data is available in inventory tables.

/* Sum the number of connections made per process today */
SELECT  SUM(ConnectionCount) AS Connections
,     ProcessName
FROM   $TCP_Daily
WHERE   TS = DATETRUNC(STRFTIME("%s", "now"), "day")
GROUP BY ProcessName;

Note the below example uses LIKE because the inventory tables are not created with COLLATE NOCASE, and need to be queried in a case-sensitive fashion. If ProcessName = "chrome.exe" is used then it will not match "Chrome.exe" or "chrome.EXE".

SELECT * FROM $Process_Live WHERE ProcessName LIKE "chrome.exe"

How is the data managed?

The Tachyon client automatically aggregates and grooms data in each inventory table, according to aggregation intervals and data retention settings which are configurable in the 1E Client configuration file.

• Default aggregation cycle interval is every 60 seconds, therefore it may take up to a minute before an event appears in an aggregated table
• Default retention for live tables is 5000 entries provided at least 3 aggregation cycles have occurred (older entries are deleted to make room for new entries)
• Default retention for hourly tables is a rolling 24 hours.
• Default retention for daily tables is a rolling 31 days.
• Default retention for monthly tables is a rolling 12 months.

Each aggregated table is built from the live table, and does not have a dependency on other aggregated tables. For example, Monthly is fed by Live, not fed by Daily. This allows retention settings to be configured independently for each table.

Data is stored in a local, compressed and encrypted persistent store, which persists during a Tachyon client upgrade, uninstall and re-installation, unless specifically deleted.

If the Tachyon client is unable to write to storage (out of disk space or other file-system problems), it will fail but continue monitoring in the hope this situation will improve later.

Tachyon Activity Record schema

The following table shows the fields which exist only in the Live and Aggregated (Hourly, Daily, Monthly) tables.

Timestamps

The timestamp column (TS) in each table is stored in Unix Epoch format. Defined as the number of seconds that have elapsed since 00:00:00 Coordinated Universal Time (UTC), Thursday, 1 January 1970

To convert to a readable text format use the EPOCHTOJSON function. See also datetime handling.

SELECT Fqdn, EPOCHTOJSON(TS) AS TS_ FROM $DNS_Hourly WHERE Fqdn LIKE "%facebook%";

Timestamps are truncated in the aggregated tables.

• Hourly - time is truncated to each hour - so an event that occurred at 2017-01-27 18:03:54 would be included in the summary for 2017-01-27 18:00:00
• Daily - time is truncated to midnight on each day - so an event that occurred at 2017-01-27 18:03:54 would be included in the summary for 2017-01-27 00:00:00
• Monthly - time is truncated to midnight on the first day of each month - so an event that occurred at 2017-01-27 18:03:54 would be included in the summary for 2017-01-01 00:00:00

ARP cache entries

The following table shows which OS and polling methods are available for ARP cache entries. 

The following table shows fields available in the $ARP_ tables. 

The Tachyon client polls the operating system ARP cache periodically. Since the lifetime of an entry in the ARP cache can be variable, if an entry in the ARP cache is encountered which is already present in the Tachyon client's database, the Tachyon client will increment the CacheCount field on the table for that row, and update the timestamp (TS) field to the current time. To that end, the CacheCount field can be used to determine how frequently a particular entry was observed in the operating system's cache.

Device performance

The following table shows which OS and polling methods are available for Device Performance. 

The following table shows fields available in the $DNS_ tables. 

When using polling, the local DNS cache is queried for all unique FQDNs. This includes an initial scan of cache entries created before the Tachyon client starts, which are stored with the same timestamp. New entries that appear in the cache are deemed to correspond to new resolutions and stored with the timestamp of when the polling occurred.

DNS resolutions

The following table shows which OS and polling methods are available for DNS resolutions. 

The following table shows fields available in the $DNS_ tables. 

When using polling, the local DNS cache is queried for all unique FQDNs. This includes an initial scan of cache entries created before the Tachyon client starts, which are stored with the same timestamp. New entries that appear in the cache are deemed to correspond to new resolutions and stored with the timestamp of when the polling occurred.

When using ETW, the Tachyon client attempts to capture DNS queries at the point that they are made. The query is captured, not the result of that query. That is, the Tachyon client will capture a request to resolve an FQDN which may ultimately not be resolvable. The DNS cache is not scanned.

Operating System performance

The following table shows which OS and polling methods are available for Operating System performance. 

The following table shows fields available in the $OperatingSystemPerformance_ tables.

Process executions

The following table shows which OS and polling methods are available for Process executions. 

The following table shows fields available in the $Process_ tables. 

On Windows, the 1E Client service runs as LOCAL SYSTEM, therefore details of almost every process will be available to the Tachyon client features; however some processes may not be accessible because of permissions.

The Tachyon client captures process starts; it does not track how long the process has been running, or how much CPU-time (or user/kernel/active time) the process has used.

Each time the Tachyon client starts it does an initial scan of processes before it starts capturing, and will use that time to record when these processes started.

The UserName field is derived from the session in which the process was executed, and doesn't necessarily reflect the user in whose context the process was executed.

Process stabilizations

The following table shows which OS and polling methods are available for Process stabilizations. 

The following table shows fields available in the $ProcessStabilization_ tables. 

On Windows, the 1E Client service runs as LOCAL SYSTEM, therefore details of almost every process will be available; however some processes may not be accessible because of permissions. The Tachyon client captures only information that can be accessed by LOCAL SYSTEM - as such it does not check the UI responsiveness of a process.

By default, process stabilization monitoring is not active. To enable, the process names must be specified in the 1E Client configuration file as follows:

• Add Module.Inventory.ProcessStabilization.MonitoredProcesses=<string> to the 1E Client configuration file.
• This is a list of comma separated values, and the case is not significant. For example, winword.exe and WINWORD.EXE are treated the same.
• The list of monitored processes does not currently have a limit, however adding a large list of processes to monitor can cause performance degradation and the process stabilization time will become less accurate.

A process' resource usage is tracked, and it will be considered stable once it's resource utilisation has stopped fluctuating. The margin in which a process is considered stable can be modified in the 1E Client configuration file. Changing from default is not recommended.

• This margin is controlled by the fuzziness configuration setting.
• Add Module.Inventory.ProcessStabilization.Fuzziness=<integer> to the 1E Client configuration file. It cannot be lower than 1, and cannot exceed 66. The default is 5.

A process that exits before it is considered stable is not be recorded. Currently, such processes are discarded. A warning is logged when this occurs.

The accuracy of process monitoring decreases if more processes need to be monitored concurrently. For example, accuracy will decrease if many processes are started at the same time. Warnings are logged when this occurs.

The accuracy of the process monitoring decreases if the system is under considerable load, for example high disk or CPU stress.

Aggregation is grouped by the UserName and ExecutableName fields. Unlike process executions, process stabilization values for UserName and ExecutableName are lower case.

Process usage

The following table shows which OS and polling methods are available for Process usage. 

The following table shows fields available in the $ProcessUsage_Daily table.

The Tachyon client captures executable usage; this is from the moment the executable is turned into a process, hence the process usage. The Process Usage data presented is grouped by executable binary, and parallel runs are accumulated in the ExecutionCount, but not in the Duration, where coverage time period is desired instead.

Sensitive processes

The following table shows which OS and polling methods are available for Sensitive Processes. 

The following table shows fields available in the $SensitiveProcess_ tables. 

Software installations

The following table shows which OS and polling methods are available for Software installations.

The following table shows fields available in the $Software_ tables. 

Each time the Tachyon client starts it does an initial scan of install software before it starts capturing. Since the Tachyon client has no way of knowing when this install/uninstall happened, it will mark the event as having occurred "now".

On Windows, software installations are read from the registry key HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall and HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall

Per-user installations are not yet supported.

Linux does not distinguish between O/S packages (even the kernel) and application packages; they are all software.

Software performance

TCP outbound connections

The following table shows which OS and polling methods are available for TCP outbound connections.

The following table shows fields available in the $TCP_ tables. 

The Tachyon client captures TCP connections, not UDP connections - as UDP is inherently connectionless (each packet sent is effectively a new connection).

Each time the Tachyon client starts it does an initial scan of connections before it starts capturing. A limitation of the Windows API is means that all established TCP connections, whether inbound or outbound, are captured; there is no way to distinguish between the two. This means that it is possible for the Tachyon client to double-capture a connection if that connection was established before the Tachyon client stops monitoring, and still exists when the Tachyon client starts monitoring again, for example between Tachyon client restarts. Unlike other capture sources, there is no persistent storage setting to prevent double-counting.

The Tachyon client captures initial "connect" requests, not just successful connection establishment. This means that an attempt to perform a connection will be captured, even if that connection does not complete, for example, because of a timeout, or the server-side does not permit the connection.

User usage

The following table shows which OS and polling methods are available for User usage.

The following table shows fields available in the $UserUsage_Daily table. 

The Tachyon client captures user sessions (usage); this is from the moment the user instigates a login/logout, hence User Usage. The usage data presented is grouped by SID and Username, and parallel login durations are really the coverage of the time period, not the total time for all the individual sessions.