Terminology

A brief overview of AIR terminology

Acquisition Profile

A collection of evidence types, application artifacts, network captures, and custom content items grouped into reusable sets known as Acquisition Profiles. While several profiles are provided out-of-the-box, users can also create and customize their own, adding them to the Acquisition Profile Library, accessible via the Main Menu.

AIR Console

The AIR Console is a web-based management interface that enables users to efficiently manage assets, assign tasks, and oversee the entire investigation lifecycle. From evidence acquisition to in-depth analysis, report generation, and case management, all activities are streamlined through the Investigation Hub. Users can also personalize their experience by switching between light and dark modes via the main menu, enhancing usability and visual comfort.

Asset and Asset Status

In AIR, an asset is defined as any entity, whether a device or system, physical or virtual, that operates on a supported operating system such as Windows, macOS, Linux, Chrome, IBM AIX, and ESXi. Assets are the foundational elements on which AIR performs various actions, including evidence collection and task execution, crucial for responding to and hunting cyber threats. Examples of assets include computers, servers, hosts, cloud accounts, and disk images.

In AIR, an Asset can be in one of 3 states:

1. Managed: The asset's responder has been successfully deployed to the device and is ready to collect tasking assignments from the console.

2. Unmanaged: An asset is categorized as Unmanaged under two specific conditions:

   • Discovery without Deployment: The asset is identified through Active Directory or Cloud Account scans, but does not have the AIR responder installed.

   • Unreachable with No Data: The asset has been disconnected from the AIR console for over 30 days (Unreachable), and no forensic data from that asset is stored in the AIR console.

3. Off-Network: An asset is classified as Off-Network under two specific scenarios:

   • Data Supplied: The asset has previously provided data through methods such as an Off-Network Acquisition or a Hunt/Triage task.

   • Unreachable with Stored Data: The asset holds forensic data within the console but is currently inaccessible for further data collection or task assignments.

   For both scenarios, investigation of the existing data is possible, and additional data can be manually imported as required.

The Assets Summary window on the home page can also report the asset as:

1. Unreachable: The asset's responder is currently unreachable. If an Asset's Responder fails to connect to the AIR console for over 30 days, its status changes to "unreachable." Until then, its status will be managed as online or offline.

2. Update Required: The responder on the asset requires an update to function correctly.

3. Update Advised: The responder is still functional, but for full functionality, an update is recommended.

4. Isolated: The asset is currently isolated from the network, except for communication with the AIR console.

Asset Management - Using Persistent Saved Filters

Persistent Saved Filters enable users to create and store custom asset filters, making it easier to locate and manage assets without having to reapply filter conditions in each session.

A Case

In AIR, a Case — can often be thought of simply as an 'investigation' — as it is where all related activity and evidence are grouped together. By collecting acquisitions, DRONE findings, timelines, interACT sessions and hunt results within a single case, AIR automatically builds a unified view of all of that activity in the Investigation Hub. This case-based approach gives investigators a clear, consolidated picture of their entire investigation in one place — the single pane of glass.

Evidence Item

In Binalyze AIR, evidence refers to any data collected from an asset during acquisition or triage that supports forensic investigation and incident response. This may include system metadata, logs, configuration information, user-activity traces, or other information useful in reconstructing events.

AIR organizes all collectible data into evidence items, each of which belongs to one of the defined evidence categories in the acquisition profile. An evidence item represents a specific data source with a clear description of what it contains and why it is relevant for investigation.

The current evidence categories are:

1. System - Core operating system information, including system configuration, environment details, and fundamental OS state.

2. Memory - Volatile memory sources such as RAM snapshots, memory sections, and other data that reflect live system state at the time of acquisition.

3. Network - Network-related evidence including connections, configurations, interface details, and network activity indicators.

4. Event Logs - Structured logs generated by the operating system that record authentication events, system changes, service activity, and other audit information.

5. Disk & File System - File system metadata, mount points, directory information, file activity indicators, and other disk-level sources that reflect how data is organized and accessed.

6. Applications - Evidence produced by installed or active applications, including logs, caches, configuration files, usage traces, and other application-specific data sources.

7. Custom Content - Items defined directly by the user based on file paths or directories of interest. This allows investigators to collect additional files or folders that fall outside the standard evidence set.

8. osquery - Items collected by executing osquery queries on the asset. These provide structured, table-driven insights into system and application state using the osquery framework.

Evidence Repository

A remote location for saving evidence collected as a result of an AIR tasking. These include:

1. SMB

2. SFTP

3. FTPS

4. Amazon S3

5. Azure Blob

6. Network Shares

To create a New Repository, go to Settings in the Main Menu and select Evidence Repositories from the secondary Menu. From the window 'New Repository' complete the mandatory fields and select the type of repository you wish to add.

Read more details about Evidence Repositories here.

Organizations

In AIR, an organization is a structural entity that allows for the separation of assets, users, and cases within a multi-tenant environment. The multi-tenancy capability of AIR enables a single console to manage multiple organizations, each with its own isolated environment. Here's how it works:

1. Asset Management: An asset (e.g., a device or endpoint) can belong to only one organization, ensuring clear boundaries between different organizational environments. However, within that organization, the same asset can be assigned to multiple cases.

2. Case Management: Cases could perhaps also be called 'investigations' or 'incidents', and they are also aligned to a specific organization. Access to cases can be restricted based on user privileges within that organization.

3. Global and Organization-Specific Settings: Certain settings, such as policies and evidence repositories, can be configured globally across all organizations or individually for each organization. This flexibility allows administrators to enforce global standards while still providing the ability to customize configurations at the organizational level when required.

4. Policies and Evidence Repositories: Policies can be applied either globally or on an organization-by-organization basis. For example, evidence repositories, which store collected data, can be aligned to all organizations (global) or set up uniquely for each organization, allowing for localized data control.

This multi-tenant architecture in AIR enables organizations to operate independently within the same platform, benefiting from both shared resources and isolated environments, depending on their specific needs.

Real-Time User Online Status Indicators

Terminology: Real-Time User Online Status Indicators

User real-time status is shown throughout the AIR via colored dots—green for online, gray for offline—helping teams coordinate more effectively across the platform.

This live collaboration capability extends to the Investigation Hub where investigators can see real-time user presence, track comment updates, and observe evidence flag changes as they happen. These live updates allow multiple investigators to work simultaneously on the same evidence without needing to refresh the view. Every action—whether adding notes, updating findings, or adjusting flags—appears instantly for all connected users, creating a fully synchronized collaborative workspace within the Investigation Hub.

Terminology: Real time user presence in the Investigation Hub

In the Investigation Hub screenshot above, you can see that three users are currently active in this case. Their profile icons indicate not only who is present, but also where each person is working in real time. In this example, one user is viewing the Findings page, another is focused on the System Info evidence, and a third is examining the Amcache File evidence. This provides instant visibility into team activity and helps avoid duplication of effort during collaborative investigations.

Responder

The AIR responder is a compact, cross-platform, zero-dependency, and zero-configuration package that functions as a virtual incident responder, delivering Level 3–4 SOC expertise directly to your assets.

Unlike 'agents' that constantly monitor systems and consume significant resources, AIR responders only activate to perform precise, user-defined DFIR tasks on demand. This approach enables the deployment of thousands of virtual responders across your IT ecosystem, ready to execute proactive and reactive incident response activities, such as evidence collection, threat hunting, and forensic-level analysis, as needed.

Binalyze's approach prioritizes efficient security enhancement, marrying minimal asset impact with maximum readiness and incident response capability. Read more here: Responder Deployment

Task

Operations are assigned to the assets by the AIR console, either manually or automatically via a trigger. A task can be assigned to multiple assets, and this is managed through 'task assignments.' Each individual assignment, known as a 'task assignment,' creates a one-to-one correspondence between the task assigned by the console and the specific asset on which the task assignment is executed, ensuring precise management and tracking across all assigned tasks.

Tasks could be either:

1. Manual: Assigned manually by users,

2. Scheduled: Created by users to start at a future date. Scheduled tasks can be either one-time or recurring (daily, weekly, or monthly).

3. Triggered: Assigned to the assets as a response to a trigger request, which is sent by a SIEM/SOAR/EDR solution.

Triggers (Webhooks)

Triggers are the primary extensibility mechanism for AIR to receive alerts from other security suites, such as SIEM, SOAR, and EDRs.

A trigger is the combination of a parser, an acquisition profile, and a destination for saving the collected evidence (either local or remote).

AIR takes this to the next level by allowing the trigger to further automate the post-acquisition analysis by leveraging DRONE and MITRE&CK scanners. In effect, the alert from your security tools can launch AIR into the collection of relevant forensic data, facilitate the analysis of that data, and deliver any DFIR findings into the Intelligence Hub with no analyst intervention required.

Hunt/Triage

Hunt/Triage in AIR refers to searching for indicators of compromise—such as file hashes, processes, or malicious domains—across assets at scale. AIR provides built-in YARA, Sigma, and osquery capabilities, enabling analysts to detect anomalies in live systems, memory, and logs. Users can write their own rules or import large rule sets for rapid deployment, all of which are centrally stored and managed in the AIR Libraries to ensure consistency and collaboration across investigations.