- Home
- Armadillo platform
Armadillo, as a system
What goes into Armadillo, what it does with it, and what it produces. Every section here is condensed from the Armadillo Technical Due Diligence dossier.
Architecture
Sources feed one engine; the engine correlates, validates and decides; outcomes surface in one console. Select any stage.
Armadillo data flow
Select any stage for detail
One engine, no seams
Sources feed a single engine that correlates, validates and decides. Select a stage to see what it does.
One platform. Multiple security planes.
Every plane reads from and writes to the same data model, so context never crosses an integration seam.
Management plane
Security overview, hosts and health, bundles and rules, reports in PDF and CSV, notifications, users, host enrollment
Response plane
Response actions, cases, archive, agent event audit trail
Prevention plane
IPS block, drop and reject, manual and automatic IP blocks, containment through response actions
Detection plane
Deterministic rules, IDS detection path, alerts, SIEM ingestion and real time correlation
Intelligence plane
Continuous threat intelligence, vulnerability intelligence, correlation context
Visibility plane
Endpoint and host, processes, file integrity, software inventory, ports, sessions, network traffic, monitoring
From threat intelligence to enforcement
Fresh threat knowledge, or a sufficiently detailed attack description, becomes a validated deterministic rule that is deployed and enforced at the customer. No vendor release cycle, no manual rule writing.
-
01Collect
InputNew advisories, exploits, threat reports and indicators from public and private sources
ProcessCollect and ingest threat information into the intelligence pipeline
OutputStructured threat candidates
-
02Filter
InputRaw intelligence, duplicates, weak or irrelevant data
ProcessFilter, normalize, deduplicate and keep what is useful
OutputClean, structured intelligence
-
03Interpret
InputFiltered intelligence plus learned rule knowledge
ProcessAI interprets threat behavior and indicators and decides the detection logic required
OutputCandidate deterministic logic
-
04Generate
InputThreat representation, exploit behavior, indicators
ProcessGenerate a new rule, not merely select an existing one
OutputNew candidate rule
-
05Validate
InputGenerated rule
ProcessCheck syntax, logic and expected detection behavior; refine if needed
OutputValidated or reworked rule
-
06Test
InputValidated rule plus test scenarios
ProcessSafety and quality checks and debugging before customer deployment
OutputApproved rule; bad candidates rejected
-
07Bundle
InputApproved rule
ProcessAdd to the active rule bundle and content version, keeping it auditable
OutputNew bundle version
-
08Deploy
InputBundle plus enrolled agents and engines
ProcessPush the protection update automatically to active customer environments
OutputUpdated rule base, no manual rule writing
-
09Detect
InputLive traffic and events
ProcessEvaluate live input against the updated deterministic logic
OutputDetection and alert on match
-
10Enforce
InputConfirmed malicious event plus IPS or response policy
ProcessBlock or prevent, correlate in SIEM, trigger the response path
OutputThreat stopped, alert, case and audit record
AI assisted Interpret and generate Deterministic and automated Everything else
Pipeline stages in detail
| Stage | Input | Process | Output |
|---|---|---|---|
| 1. Collect | New advisories, exploits, threat reports and indicators from public and private sources | Collect and ingest threat information into the intelligence pipeline | Structured threat candidates |
| 2. Filter | Raw intelligence, duplicates, weak or irrelevant data | Filter, normalize, deduplicate and keep what is useful | Clean, structured intelligence |
| 3. Interpret | Filtered intelligence plus learned rule knowledge | AI interprets threat behavior and indicators and decides the detection logic required | Candidate deterministic logic |
| 4. Generate | Threat representation, exploit behavior, indicators | Generate a new rule, not merely select an existing one | New candidate rule |
| 5. Validate | Generated rule | Check syntax, logic and expected detection behavior; refine if needed | Validated or reworked rule |
| 6. Test | Validated rule plus test scenarios | Safety and quality checks and debugging before customer deployment | Approved rule; bad candidates rejected |
| 7. Bundle | Approved rule | Add to the active rule bundle and content version, keeping it auditable | New bundle version |
| 8. Deploy | Bundle plus enrolled agents and engines | Push the protection update automatically to active customer environments | Updated rule base, no manual rule writing |
| 9. Detect | Live traffic and events | Evaluate live input against the updated deterministic logic | Detection and alert on match |
| 10. Enforce | Confirmed malicious event plus IPS or response policy | Block or prevent, correlate in SIEM, trigger the response path | Threat stopped, alert, case and audit record |
The deterministic detection engine
AI assists where interpretation is needed. What reaches enforcement is explicit, validated and tested logic, not an opaque model decision.
Inputs
- Threat intelligence
- Existing detection knowledge
- Security context
AI assisted
- Interpretation
- Candidate detection logic
Deterministic
- Validation
- Testing
- Refinement
Outputs
- Validated rules
- Protection bundle
- Endpoint and network deployment
- IDS and IPS enforcement
Nothing crosses the validation gate until it passes validation and testing. Hover or focus a stage for detail.
AI interprets. Deterministic logic enforces.
Interpretation is flexible by design. Enforcement is not: once a candidate passes the gate it becomes structured, versioned logic with an identifier, and every match it makes can be traced back to it.
- Threat observed
- Candidate rule
- Syntax validation
- Logic validation
- Testing
- Safety checks
- Bundle
- Deploy
- Enforce
- Audit
Filtered intelligence describes new behavior and indicators.
Time to protection, measured end to end
≤5seconds
Maximum observed end to end time to protection across the completed reported Armadillo test set.
- Start Fresh threat intelligence or attack description received.
- End Protection active at the customer side.
- Scope The completed, reported Armadillo test set documented in the technical due diligence dossier.
- Reading This is the maximum observed value in that set. It does not predict the result for every threat or environment.
- Intelligence received
- Interpretation
- Rule generation
- Validation and testing
- Deployment
- Enforcement
Replay of a documented benchmark. Stage positions show order, not individual durations.
Where zero day protection comes from
In a conventional stack protection is a vendor deliverable. In Armadillo the rule is derived from the intelligence itself.
Conventional signature model Protection waits on an external release cycle
- StartDisclosure
- Stage 1Vendor research
- Stage 2Signature authoring
- Stage 3Vendor testing
- Stage 4Update release
- Stage 5Your change window
- EndProtected
Armadillo workflow Maximum observed end to end: 5 seconds, completed reported test set
- StartDisclosure
- Stage 1Filtered and interpreted
- Stage 2Rule generated
- Stage 3Validated and tested
- Stage 4Deployed automatically
- EndProtected
Amber stages are time your environment spends exposed. The conventional row shows where protection comes from, not measured durations.
What goes in, what Armadillo does, what comes out
Endpoint, network, session, port, event and vulnerability telemetry in one engine. Views below use synthetic example data.
- Input
- Agent identity, host state and health, engine and bundle version, CPU, disk and network metrics, installed software, processes, file changes
- Process
- Collect, normalize, track host state, analyze processes, files and software, correlate with detections and vulnerability context
- Output
- Host inventory and health, process events, file integrity events, software inventory, exposure findings, endpoint alerts, response targets
Process lineage, host app-04
- systemd PID 1
- sshd PID 812
- bash PID 4410
- python3 PID 4471Suspicious
- bash PID 4410
- nginx PID 1204
- sshd PID 812
File integrity event
- Path
- /etc/ssh/sshd_config
- Change
- modify
- Before
- 9f2c…a41e
- After
- 07bd…e913
- Severity
- High
- Input
- Flows, source and destination, protocol, volume, packet and flow metadata, internal and external communications
- Process
- Inspect traffic, identify protocols, match IDS and IPS rules, correlate, classify risk, optionally prevent
- Output
- Flow records, detections, alerts, blocked traffic and addresses, protocol breakdown, investigation context
Benign flows pass. A flow matching an active rule stops at the boundary when IPS is enabled.
- Input
- SSH, RDP, FTP and other inbound and outbound sessions with initiator, receiver, service, port, start, end and duration; Open, closed and newly opened ports, internet exposed ports, suspicious services, connection attempts, remote address
- Process
- Reconstruct sessions, classify direction and service, evaluate suspicion, correlate with host and network events; Baseline ports, detect state changes, classify exposure, apply suspicious port logic, correlate
- Output
- Session log with status and confidence, linked alerts and cases; Open, exposed and suspicious counters, port event log, exposure findings, possible alert or block
| Service | Direction | Initiator | Confidence |
|---|---|---|---|
| SSH 22 | Inbound | 10.0.4.21 | High |
| RDP 3389 | Inbound | 198.51.100.7 | Review |
| FTP 21 | Outbound | 10.0.2.9 | Medium |
Port events, last 24 hours
- 8080 newly opened Internet exposed
- 5432 baseline Internal only
- 3389 connection attempts Suspicious
- Input
- Agent events, alerts, rule IDs, severity, status, timestamps, source, destination, host, protocol
- Process
- SIEM ingestion, normalization, real time correlation, deduplication and grouping, severity and status workflow, case logic
- Output
- Alert queue, correlated incidents, cases, archive, dashboards, reports, notifications
- HighPort 3389 newly exposed on ws-117
- HighRDP session from external address
- CriticalSuspicious process spawned by session
Correlated into one case with three linked alerts
- Input
- Installed package and version data plus advisory and CVE data
- Process
- Match packages to advisories, correlate hosts and packages, classify severity, aggregate exposure
- Output
- Exposures by severity, affected packages and hosts, prioritization context
- Inventoryopenssl 3.0.2 on 3 hosts
- Mappingpackage and version resolved
- AdvisoryADV-EXAMPLE-07 matched
- Exposure3 hosts affected
- PriorityCritical
From detection to action
Armadillo does not stop at the alert. Prevention runs automatically where policy allows. Deeper actions are analyst initiated, authorized and audited. Select an action to follow its command path.
Automatic under policy
- Block, drop or rejectWhen the IPS policy is enabled, confirmed malicious traffic is prevented and logged
- Automatic IP blockingWhen auto blocking is enabled, detections queue a firewall block at the agent
- Protection updatesNew rule bundles are deployed to active environments automatically
Analyst initiated
Command lifecycle
Kill process python3, PID 4471 on app-04 synthetic example
- Authorization
- Dispatch
- Agent check in
- Execution
- Status returned
- Audit
Every module, input to output
Grouped by security plane.
Visibility
| Module | What it does | What it produces |
|---|---|---|
| Hosts | Tracks enrollment and health; classifies healthy, degraded or offline | Host inventory, health, agent actions |
| Processes | Process snapshot and history; evaluates suspicious indicators | Process events and investigation evidence |
| File integrity | Compares watched file state; classifies create, modify, delete, rename, permission and ownership changes | Change stream with path, severity, before and after hashes |
| Software inventory | Full snapshot, then deltas; tracks additions, removals and versions | Per host package inventory and history |
| Traffic | Aggregates and classifies flows; protocol analysis; top flows | Flow volume, protocol breakdown, top flows |
| Sessions | Builds session records; inbound or outbound; status and confidence | Active, resolved and high confidence sessions |
| Ports | Maintains a baseline; detects changes; marks exposure and suspicious services | Open, exposed, suspicious, opened and closed in 24 hours |
| Monitoring | Time series of CPU, disk and network per host and fleet | Monitoring charts and averages |
Intelligence
| Module | What it does | What it produces |
|---|---|---|
| Continuous intelligence | Ingests threat knowledge; feeds the AI and rule pipeline | Updated detection content without a separate release cycle |
| Vulnerability exposures | Server side package to advisory correlation; severity by host and package | Exposure counts, affected hosts and packages |
Detection
| Module | What it does | What it produces |
|---|---|---|
| Deterministic detection engine | AI generates deterministic logic; validates, refines and tests before release | Validated detection rules |
| IDS detection path | Rule evaluation, detection decision, severity, SIEM correlation | Alert with rule ID, source, destination, protocol, host |
| Alerts | Correlation and classification; severity and status workflow | Alert queue; archive, investigate, acknowledge |
Prevention
| Module | What it does | What it produces |
|---|---|---|
| IPS prevention path | Enforcement decision; block, drop, reject or firewall action | Threat prevented, block and audit event |
| IP blocks | Policy check, queued firewall block, enforcement, expiry and failure handling | Active, enforced, failed and expired blocks |
| Rules and bundles | Rule lifecycle and bundle management; distribution to agents | Active bundle state at enrolled hosts |
Response
| Module | What it does | What it produces |
|---|---|---|
| Response actions | Authorization, dispatch, agent execution, result and audit capture | Kill process, diagnostics, restart or disable service, quarantine file, isolate host |
| Cases | Groups related activity into an investigation workflow | Ownership, status, history, resolution trail |
| Agent events | Audits control plane actions and execution state | Applied, failed and pending actions with timestamps |
| Archive | Preserves records after triage; restore to active workflow | Searchable archive and audit evidence |
Management
| Module | What it does | What it produces |
|---|---|---|
| Security overview | Summarizes platform wide operational and security state | Central posture dashboard |
| Reports | Queries retained data and formats report sections | PDF and CSV security reports |
| Notifications | Routes alerts to configured destinations | Security alert emails |
| Health | Agent, service and engine health checks | Posture status and warnings |
| Users and account security | Access control and account management | Authorized platform access |
| Host enrollment | Install, register, associate to workspace, begin telemetry | Enrolled host in inventory |
Ten end to end processing flows
How each kind of event moves through Armadillo.
A. Normal traffic
- Capture
- extract protocol
- flow and session
- evaluate IDS rules
- correlate
- decide
OutputBenign traffic passes; telemetry stored; no prevention action
B. Known malicious traffic
- Rule match
- classify severity
- alert
- enforce block or drop when IPS is enabled
- log
- correlate into a case
OutputAlert with rule ID, prevention, audit trail, case update
C. New threat intelligence
- Collect
- filter
- AI generation of a new deterministic rule
- validate
- test
- deploy to the rule base
OutputNew bundle distributed; matching traffic detected and, with IPS enabled, prevented
D. Vulnerable software
- Package to advisory correlation
- severity
- host and package aggregation
OutputExposure view with affected hosts and packages
E. Sensitive file change
- Compare state and hash
- classify the change
- assign severity
- correlate with process
- user and host
OutputFile integrity event with before and after hashes
F. Suspicious process
- Evaluate against rules and context
- flag
- correlate with host
- network and file activity
OutputProcess evidence; analyst can kill the process, quarantine a file, isolate the host or collect diagnostics
G. Remote access session
- Reconstruct the session
- classify direction and service
- correlate with confidence
OutputSession record, possible alert or case
H. Port exposure change
- Update baseline
- classify exposure and service
- correlate
- alert when risk logic matches
OutputPort event, exposure status, optional block
I. Analyst response
- Authorization
- queue command
- agent check in
- execute
- return status
- audit
OutputApplied, failed or pending action
J. Reporting
- Query
- aggregate
- format
- export
OutputPDF or CSV report for audit and management
Telemetry Armadillo captures
- Host and agent
- Agent name, hostname, status, engine version, bundle version, last seen, health state
- Alert
- Detection title, rule ID, source IP, destination IP, protocol, severity, status, host, detected time, action
- Traffic flow
- Protocol, source, destination, bytes, flow count, time window, protocol totals
- Session
- Principal, initiator, receiver, service and port, protocol, start, end, duration, status, confidence, direction
- Port event
- Time, host, event type (baseline, opened, closed, attempt), protocol, port, service, confidence, risk, remote IP
- Block event
- Time, source IP, state, manual or automatic, detection, severity, port, duration, expiry, reason
- Process
- Name, PID, user, lineage, last observed, state, suspicious flag, host
- File integrity
- Time, severity, change type, path, user or UID, size, before and after hash, host
- Software inventory
- Host, snapshot type, OS and kernel context, package, version, source, timestamp
- Vulnerability exposure
- Advisory count, severity, affected host and package, mapping, last evaluated
- Response event
- Time, agent, kind, type, target, status, actor, resolved time, reason or incident reference
- Monitoring
- CPU, disk, network in, network out, host and fleet averages over time
Security analysis that stays in country
Armadillo is designed for deployment models where telemetry, logs and traffic are analyzed on site or on in country infrastructure, with rules that remain visible and auditable.
The deployment model is agreed with each customer. It supports data residency requirements; it does not by itself establish compliance with a specific regulation.
What each team gets
- SOC analyst
- Prioritized alerts, correlated events, cases, process, file, network and session evidence, response actions, archive
- Security administrator
- Host health, agents, IPS policy, rules and bundles, blocks, notifications, account security, audit trail
- Network and infrastructure
- Traffic flows, protocol usage, open and exposed ports, connection attempts, sessions, blocked addresses, resource monitoring
- Vulnerability and risk
- Software inventory, advisory correlation, affected hosts and packages, severity distribution
- Management
- Security reports, incident and response audit trail, local processing posture, operational metrics
Built to keep the queue to real findings
Because Armadillo derives detections from defined threat conditions, every alert traces back to a condition an analyst can read. The design goal is a queue that reflects actual threat activity, with far less noise than probabilistic scoring produces.
One console, every module
Overview, hosts, alerts, traffic, sessions, ports, blocks, cases, processes, file integrity, software, vulnerabilities, reports, rules and bundles.
| Severity | Detection | Rule ID | Action |
|---|---|---|---|
| Critical | Exploit attempt, web service | AR-EXAMPLE-0142 | Blocked |
| High | Lateral movement pattern | AR-EXAMPLE-0088 | Case opened |
| Medium | Unexpected outbound volume | AR-EXAMPLE-0031 | Investigating |
| Service | Direction | Initiator | Confidence |
|---|---|---|---|
| SSH 22 | Inbound | 10.0.4.21 | High |
| RDP 3389 | Inbound | 198.51.100.7 | Review |
| FTP 21 | Outbound | 10.0.2.9 | Medium |
Port events, last 24 hours
- 8080 newly opened Internet exposed
- 5432 baseline Internal only
- 3389 connection attempts Suspicious
| Change | Path | Host | Severity |
|---|---|---|---|
| modify | /etc/ssh/sshd_config | app-04 | High |
| permission | /usr/local/bin/backup | db-02 | Medium |
| create | /tmp/.cache/x | web-01 | High |
- Inventoryopenssl 3.0.2 on 3 hosts
- Mappingpackage and version resolved
- AdvisoryADV-EXAMPLE-07 matched
- Exposure3 hosts affected
- PriorityCritical
For security architects
Armadillo Technical Due Diligence
The technical dossier behind this page, for evaluators who need the system model rather than the summary.
- Input, process, output modelSystem level and module by module
- Telemetry fieldsEvery data element Armadillo captures
- Processing flowsTen end to end flows, from normal traffic to reporting
- Rule automation pipelineTen stages from collection to enforcement
- Time to protectionBenchmark definition and result
See Armadillo against your environment
A technical session with our engineers covering your stack, your threat model and how Armadillo would be deployed.