Defensium Engine Architecture and Scan Controls

01 / A unified multi-engine analysis model

Defensium uses a multi-engine analysis model to examine different types of endpoint evidence through specialised capabilities. Instead of applying the same method to every file, event or indicator, the platform selects the analysis capability that best matches the investigation objective.

The architecture brings together four complementary security engines:

• DeepCore provides advanced file, content and memory analysis.
• BehaviorLens identifies suspicious behavioural relationships and activity sequences.
• IntelStream performs IOC search and fleet-wide threat scoping.
• D-Logic analyses logs and forensic evidence for security-relevant activity.

The ATF Quad Engine coordinates these capabilities through a common scan profile and result model. Analysts can run focused scans with one engine or combine several engines when an investigation requires multiple evidence perspectives.

This approach gives Defensium two important advantages:

1. Investigation depth: Each evidence type is evaluated by a capability designed for that analytical purpose.
2. Operational control: Scan scope and resource settings can be adjusted according to endpoint role, business impact and investigation urgency.

02 / Why specialised engines matter

Endpoint investigations rarely depend on one source of truth. A security team may need to determine whether:

• a suspicious file contains malicious or high-risk content;
• a script or configuration includes a suspicious behavioural sequence;
• the same indicator appears on other endpoints;
• endpoint logs contain related execution, access or persistence activity;
• the evidence is isolated or part of a wider incident.

These questions require different analytical perspectives. Defensium brings those perspectives into one operational context so the analyst can move from an isolated signal to a broader, evidence-backed investigation.

Investigation need	Defensium capability
Examine suspicious files, archives, documents or memory content	DeepCore
Identify related command, script or configuration behaviours	BehaviorLens
Search indicators across authorised endpoint groups	IntelStream
Analyse endpoint logs and forensic event evidence	D-Logic
Combine results and maintain a consistent investigation context	ATF Quad Engine

03 / DeepCore: advanced content analysis

DeepCore examines content that requires deeper inspection than a simple metadata or hash lookup. It supports investigations involving files, archives, documents and selected memory targets.

DeepCore helps analysts answer questions such as:

• Does the object contain content associated with a known or suspicious threat?
• Is relevant evidence embedded inside an archive or document?
• Does the same detection appear across multiple files or endpoint locations?
• Is suspicious content present in a selected process-memory target?
• Which object and evidence context produced the finding?

DeepCore can be used as part of routine scanning, targeted triage or a deeper incident investigation. Its workload can be controlled independently so security teams can balance analytical depth with endpoint performance.

Typical DeepCore controls

DeepCore controls allow teams to adjust analytical depth and endpoint impact without exposing the internal implementation of the engine.

Control	Purpose	Operational value
Analysis scope	Defines the files, locations, archives, documents or selected memory targets included in the scan.	Keeps deep analysis aligned with the investigation question.
Workload level	Controls the amount of DeepCore analysis performed concurrently.	Balances scan throughput with endpoint responsiveness.
Object timeout	Limits how long one complex object can remain under evaluation.	Prevents one object from delaying the wider scan.
File-type and size filters	Focuses analysis on relevant content classes and manageable object sizes.	Reduces unnecessary CPU and disk activity.
Modified-time window	Limits analysis to objects created or changed during the relevant investigation period.	Supports faster incident-focused triage.
Archive and document inspection	Includes supported embedded content when required by the scan profile.	Extends visibility beyond the outer file container.
Memory-analysis scope	Selects the process or memory targets relevant to the investigation.	Enables focused memory inspection instead of uncontrolled broad acquisition.
Finding controls	Applies early termination and per-object publication limits.	Controls repeated findings and analyst noise.

These controls can be combined in reusable profiles. A routine workstation scan can use a narrow scope and reduced workload, while an incident-response profile can increase depth for selected endpoints or objects.

04 / BehaviorLens: behavioural relationship detection

BehaviorLens identifies suspicious relationships inside scripts, commands, configuration data and other supported content. Its purpose is to detect behaviours that become meaningful when several elements appear together or in a relevant sequence.

This is useful when an individual command fragment may be legitimate on its own, but its combination with execution, download, persistence or remote-access behaviour increases risk.

BehaviorLens supports investigations involving:

• suspicious script and command sequences;
• encoded or obfuscated activity;
• remote-access and command-channel indicators;
• configuration-based persistence behaviour;
• credential or secret-handling activity;
• multi-stage behaviours distributed across related content.

Findings retain the related detection and evidence context so analysts can review the behaviour rather than receiving only a generic malicious label.

05 / IntelStream: IOC hunting and fleet scoping

IntelStream searches supported threat indicators across authorised endpoint scopes. It allows analysts to begin with a known indicator and determine whether the same or related evidence appears elsewhere in the environment.

Investigation pivots can include:

• file hashes;
• IP and network indicators;
• domains and URLs;
• email indicators;
• filenames and paths;
• case-specific IOC packages.

IntelStream helps security teams:

• scope one detection across endpoint groups;
• identify systems requiring deeper investigation;
• distinguish isolated activity from activity distributed across multiple endpoints;
• prioritise critical or recently affected systems;
• route confirmed results to evidence collection or authorised response.

Each match remains connected to its endpoint and evidence source. This allows the analyst to distinguish a confirmed file identity from an indicator found inside a file, log or historical artifact.

For detailed operating guidance, see Fleet-Wide IOC Search with IntelStream.

06 / D-Logic: log and evidence analytics

D-Logic analyses endpoint logs and forensic evidence to identify security-relevant activity. It provides the event-focused layer of the Defensium engine architecture and helps connect detections with the records required for investigation.

D-Logic can support investigations involving:

• suspicious process and command execution;
• authentication and privilege activity;
• service or Scheduled Task creation;
• script and administrative activity;
• security-control changes;
• remote access and lateral movement;
• persistence and event sequences associated with an attack.

Results preserve the relevant event source, timestamp and available context. This allows analysts to review the activity that produced the detection and correlate it with findings from other Defensium engines.

07 / How the engines support one investigation

The engines can be used independently or together, depending on the investigation profile.

Consider a suspicious object detected on a finance workstation:

1. DeepCore examines the object and its embedded content.
2. BehaviorLens evaluates related script, command or configuration behaviour.
3. IntelStream determines whether associated indicators appear on other endpoints.
4. D-Logic reviews relevant endpoint events for supporting activity.
5. ATF Quad Engine presents the findings within a consistent scan and investigation context.

The analyst receives complementary evidence covering content, behaviour, fleet scope and endpoint activity. This reduces the need to rebuild the same investigation across disconnected tools.

08 / Scan resource-control model

Deep analysis must remain proportionate to the endpoint and business environment. Defensium provides scan controls that help teams manage performance without losing sight of the investigation objective.

The resource-control model separates how much data is selected, how much work is performed concurrently, how the operating system prioritises the scan and how individual objects are bounded.

The main controls are:

Control	Purpose
CPU and workload settings	Adjust the amount of analysis performed concurrently.
Process priority	Reduce or increase competition with other endpoint workloads.
Scan scope	Limit analysis by endpoint group, path, file type, size or investigation period.
Timeout	Prevent one object from delaying the wider scan.
Early termination	Stop additional analysis on an individual object after a defined finding threshold.
Finding limits	Control excessive result volume from one object.
Scheduled scans	Run recurring or resource-intensive operations during controlled periods.

These controls can be combined in reusable scan profiles for workstations, servers, low-resource devices and incident-response scenarios.

No single setting represents the complete endpoint impact. For example, lowering process priority can improve foreground responsiveness, but it does not reduce the selected data scope. Likewise, reducing workload concurrency does not remove unnecessary disk activity if the scan target remains unnecessarily broad.

09 / CPU and workload controls

CPU management is not limited to one setting. Defensium combines scan scope, parallel workload controls, process priority, timeouts and scheduling to manage endpoint impact.

A resource-aware scan normally follows this order:

1. Select only the engines needed for the investigation.
2. Narrow the endpoint and data scope.
3. Configure the appropriate workload level.
4. Choose a process priority suited to the endpoint role.
5. Apply timeouts and per-object finding limits.
6. Schedule intensive operations outside critical business periods where appropriate.

This allows a focused investigation to remain lightweight while deeper analysis can be reserved for endpoints or objects that require it.

Control area	What it changes	When to use it
Engine selection	Removes analysis capabilities that are not required by the current question.	Focused triage and recurring scans
Endpoint scope	Limits which systems receive the operation.	Pilot groups, critical servers or affected business units
Data scope	Limits paths, file types, sizes and investigation periods.	Reducing CPU, disk activity and total duration
Workload level	Adjusts concurrent analysis activity.	Workstations, VDI and low-resource endpoints
Process priority	Changes competition with foreground applications and services.	Background and maintenance operations
Timeout	Bounds processing time for one object.	Complex, oversized or malformed content
Finding controls	Limits repeated evaluation and result volume for one object.	High-noise files and broad detection profiles
Operating window	Moves intensive work into an approved time period.	Servers and business-critical endpoint groups

CPU and workload controls should be selected as part of the scan profile rather than adjusted independently without considering scope. This keeps performance decisions repeatable across endpoint groups.

10 / Process priority

Process priority defines how scan activity competes with other workloads on the endpoint.

Priority	Behaviour	Typical use
Managed Default	Uses the priority defined by the central scan policy.	Centrally governed profiles
Auto	Applies the priority selected for the scan type.	Routine endpoint operations
Low	Reduces competition with foreground applications.	Background analysis and longer scans
Normal	Uses standard operating-system scheduling.	Short, focused triage operations
Idle	Prioritises other system activity over the scan.	Low-priority maintenance scans

Priority is used together with workload controls. Lowering priority improves coexistence with foreground activity, while workload settings determine how much analysis is performed concurrently.

11 / Early termination and finding limits

Some objects can produce a large number of similar findings. Defensium provides two controls to keep this behaviour proportionate:

• Early termination stops additional matching work on an individual object after the configured threshold is reached.
• Maximum findings per object limits how many results from that object are published for review.

These controls apply to the individual object, not the complete scan. If one file reaches its limit, Defensium continues with the remaining scan scope.

Object A: finding limit reached → result marked as limited
Object B: two findings → complete result
Object C: no finding → scan continues

This reduces repeated analysis and excessive result volume while keeping the wider operation active. Limited results remain distinguishable from fully evaluated objects so the analyst can decide whether a deeper follow-up is necessary.

Timeout and early termination address different conditions:

• Timeout is based on processing duration.
• Early termination is based on the finding threshold for one object.

12 / Scheduled scan controls

Defensium allows recurring and resource-intensive scans to be planned through centrally managed schedules.

Scheduled scan controls can include:

Setting	Purpose
Start time and recurrence	Defines when and how often the scan runs.
Timezone	Aligns the schedule with the intended location.
Scan profile	Selects the required engines, scope and resource controls.
Endpoint scope	Targets one endpoint or an authorised endpoint group.
Operating window	Limits execution to an approved time period.
Maximum duration	Prevents a scheduled operation from continuing indefinitely.
Offline endpoint handling	Defines how unavailable endpoints are handled.
Overlap handling	Defines what happens when an earlier scan is still active.
Retry policy	Controls recovery from temporary delivery or endpoint errors.

Overlapping scan behaviour

Option	Behaviour
Queue	Waits for the active scan to finish before starting the next operation.
Skip	Skips the overlapping occurrence and records the outcome.
Replace	Stops the active operation in a controlled manner and starts the newer scan.
Parallel	Allows concurrent operations under an explicitly selected resource profile.

Queue is suitable for routine resource-intensive scans because it prevents unnecessary workload competition on the endpoint. Urgent incident-response activity can use a different overlap policy when authorised.

13 / Recommended operating profiles

Reusable profiles help maintain consistent engine selection and endpoint controls.

Profile	Analysis focus	Control approach
Daily SOC	Recent behavioural and IOC evidence	Controlled workload and scheduled background execution
Log Review	Recent endpoint and application activity	Low-priority, time-bounded analysis
Deep Triage	Suspicious objects and locations	Focused scope, controlled CPU use and per-object timeout
Memory Triage	Selected process-memory targets	Investigation-driven execution with a defined workload
Emergency Hybrid	Multiple evidence perspectives for an active incident	Tight endpoint scope with explicit operator authorisation

14 / Endpoint-aware scan configuration

Endpoint role should influence how a profile is applied:

Endpoint type	Recommended approach
User workstation	Use focused scope, Low or Idle priority and controlled scheduling.
Server	Use an approved operating window and time-bounded analysis.
VDI or low-resource endpoint	Use a reduced workload and shorter scan scope.
Incident-response endpoint	Prioritise evidence completeness according to containment and business impact.

This flexibility allows security teams to use the same investigation capability across different endpoint classes without applying one fixed performance profile to every system.

15 / Result visibility

Defensium keeps scan results connected to the context needed for operational review:

• scan and endpoint identity;
• selected engine or analysis capability;
• execution status and timestamps;
• analysed and skipped object counts;
• timeout and limited-result visibility;
• findings grouped by severity and engine;
• partial, cancelled or failed state;
• related investigation and response actions.

This allows analysts to understand not only what Defensium detected, but also the scope and completion state of the scan that produced the result.

16 / Choosing the right scan controls

Operational need	Primary control	Supporting control
Reduce competition with user applications	Select Low or Idle priority.	Use a controlled workload and focused scope.
Reduce CPU-intensive analysis	Lower the workload level.	Select only the required engines and shorten the investigation period.
Reduce unnecessary disk activity	Narrow path, file type and size scope.	Use a modified-time window.
Prevent one object from delaying the scan	Apply an object timeout.	Keep the remaining scan active and mark the limited object clearly.
Control excessive findings	Use early termination.	Apply maximum findings per object.
Run routine scans outside peak periods	Use scheduled profiles and operating windows.	Apply Low priority and Queue overlap handling.
Prevent heavy scans from overlapping	Use Queue overlap handling.	Set an appropriate maximum duration.
Protect VDI or low-resource endpoints	Use a reduced workload profile.	Use short scope, scheduling and resumable operations.
Investigate an urgent incident	Use a focused hybrid profile.	Increase depth only for authorised endpoints and relevant evidence.

The best result usually comes from combining controls. Scope reduction removes unnecessary work, workload settings control concurrency, priority protects foreground activity, and scheduling places the operation in the most appropriate business window.

17 / What Defensium contributes

Defensium turns specialised analysis capabilities into one controlled endpoint-security workflow:

• Multi-engine coverage: Content, behaviour, IOC and log analysis support different investigation questions.
• Unified operations: Analysts configure and review scans through a consistent platform experience.
• Resource-aware scanning: CPU, workload, priority, timeout, scope and schedule controls reduce endpoint impact.
• Flexible depth: Teams can start with focused analysis and expand only when evidence requires it.
• Fleet-wide control: Scan profiles can be applied consistently across authorised endpoint groups.
• Evidence continuity: Results remain connected to endpoint, scan, engine and investigation context.
• Actionable follow-up: Findings can guide evidence collection, quarantine, live response and other authorised workflows.

The value of the architecture is not simply the number of engines. It is the ability to select the right analytical capability, control its operational impact and connect the result to the next investigation decision.

18 / Frequently asked questions

Is ATF a separate detection engine?

ATF Quad Engine coordinates Defensium's specialised analysis capabilities. It provides a consistent scan and result experience while DeepCore, BehaviorLens, IntelStream and D-Logic focus on their respective evidence domains.

Does process priority define an exact CPU percentage?

Process priority controls how scan activity competes with other endpoint workloads. Defensium combines priority with workload, scope, timeout and scheduling controls to manage overall scan impact.

Does early termination stop the entire scan?

No. Early termination applies to the individual object that reaches the configured finding threshold. The scan continues across the remaining scope.

What is the difference between timeout and early termination?

Timeout limits processing duration for an object. Early termination limits additional analysis after an object reaches the configured finding threshold.

Can several engines be used in one investigation?

Yes. Focused profiles can select one analysis capability, while broader investigations can combine content, behaviour, IOC and log analysis.

How are overlapping scheduled scans handled?

The scan policy can Queue, Skip, Replace or explicitly allow Parallel execution. The selected behaviour depends on endpoint capacity, scan profile and investigation urgency.

19 / Practical outcome

Defensium connects specialised analysis → resource-aware scanning → central visibility → investigation and response in one operational model.

Security teams can apply the right depth of analysis to each question, manage endpoint impact and move from findings to action without rebuilding the investigation across disconnected tools.