DEV Community: ALSOPS

How I Built a Linux Threat Detection Engine That Explains Why It Fired

ALSOPS — Fri, 14 Aug 2026 19:07:01 +0000

Security alerts are easy to generate.
Useful security alerts are much harder.
After dealing with enough alerts that turned out to be false positives, I started asking a different question:
What if a threat detection system didn't just tell you what happened, but explained why it thinks it matters?
That's what led me to build the detection engine behind Watch Cortex.
This isn't a post about building another SIEM. It's about the detection and reasoning layer: how it correlates Linux security events, builds context, evaluates competing hypotheses, matches attack sequences, and produces an investigation you can actually understand.
The Problem: An Alert Isn't an Investigation
A traditional rule might look something like:
if failed_ssh_logins > 5:
alert("possible brute force")
The problem is that the rule doesn't know what happened afterward.
Five failed SSH logins followed by nothing might be automated internet noise.
Five failed logins followed by a successful login, a privilege escalation, a new process, and a configuration change are a very different situation.
Those two events shouldn't produce the same response.
So instead of treating every event independently, I designed Cortex around context and event sequences.
The Architecture: Five Context Trees + A Reasoner
The detection pipeline has two major stages.
Stage 1: Build Context Trees
For each Linux server, Cortex builds five independent context trees.
The database queries run concurrently using Promise.all, with a warm-cache target of under 60 ms for the context-building stage.
The five trees are:

Health Tree Tracks deviations from a server's normal behavior. Instead of saying: CPU > 80% = suspicious Cortex builds a seven-day baseline for each server and uses statistical deviation instead. That matters because 80% CPU can be completely normal for one server and highly unusual for another. For new servers without enough historical data, the system can fall back to peer-group behavior.
Network Tree Tracks things such as: New connections Unusual ports Port scanning behavior Potential lateral movement Suspicious outbound connections Beacon-like communication patterns
Process Tree Tracks: Running processes Parent/child relationships Process ancestry File activity Suspicious executables YARA matches The process ancestry is particularly useful. A process isn't necessarily suspicious because of its name. How it got there can be much more interesting.
Threat Tree Correlates: IOC matches CVE exposure MITRE ATT&CK techniques Known malicious indicators Other threat intelligence signals
Authentication Tree Tracks: Failed logins Successful logins Sudo activity New accounts Privilege changes Credential-related behavior Each signal receives a weight and severity score. There's also an important distinction between new behavior and persistent behavior. If a server has continuously shown the same condition for more than 24 hours, Cortex marks that signal as chronic and reduces its impact. A server that has always been running at 90% CPU isn't necessarily experiencing a new security event. Stage 2: The Reasoner Evaluates Competing Hypotheses Once the five context trees are built, the reasoner evaluates possible explanations. Some of the hypotheses include: brute_force_campaign active_intrusion apt_intrusion malware_execution lateral_movement_attempt data_exfiltration ransomware resource_abuse reconnaissance supply_chain_compromise Instead of asking: "Did rule X fire?" the system asks: "Given all of the evidence available right now, which explanation best fits what we're seeing?" Each hypothesis evaluates the five context axes independently on a 0–100 scale. The weighting is hypothesis-specific. For example, a brute-force hypothesis puts more emphasis on authentication activity, while an APT-style hypothesis may put more emphasis on process behavior and its relationship with network activity. Just as importantly, the system tracks evidence against a hypothesis. If there's no internet exposure, no recent authentication activity, and no plausible entry point, that should reduce confidence in certain intrusion hypotheses even if other anomalies exist. That's an important difference between simply adding more alerts and actually correlating evidence. Detecting Attack Chains Instead of Isolated Events The hypothesis engine isn't the only detection layer. There's also a TTP sequence matcher that looks for multi-step attack patterns. Each pattern contains ordered signal steps and time constraints. For example: SSH Brute Force → Process Anomaly → Configuration Change Step 1: brute_force or auth_fail minimum: 5 events

Step 2:
suspicious_process
within: 2 hours
source correlation: Step 1

Step 3:
fim_change
within: 2 hours

Result:
increase confidence in active intrusion
The important part isn't that any individual event is necessarily malicious.
It's that the sequence makes the events more meaningful together.
Another example is cryptocurrency-mining persistence:
Step 1:
known miner indicator or mining-pool connection

Step 2:
cron modification or systemd unit creation
within: 4 hours

Result:
increase confidence in resource abuse
And a reverse-shell pattern:
Step 1:
process spawns shell

Step 2:
shell establishes outbound connection

Result:
increase confidence in command execution
When a TTP chain matches, it can increase the confidence of the relevant hypothesis and, depending on the policy, contribute to an automated response.
Possible responses include:
Temporarily blocking an IP
Isolating a network interface
Terminating a suspicious process
Collecting forensic information
The important design principle is that detection and response are separate decisions. A detection can increase confidence without automatically taking destructive action.
The Feature That Made the System Actually Useful: Explainability
This is probably the part I'm most proud of.
Every investigation plan contains the reasoning behind the decision.
Instead of:
Threat detected — confidence: 87%
you can see:
Which hypothesis won
Why it won
Supporting evidence
Against-evidence
Relevant processes and PIDs
File paths
IOC values
Matched TTP chains
Confidence adjustments
The final confidence score
For example, the system can explain that confidence was affected by:
False-positive dampening
If a server has repeatedly generated false-positive plans for the same behavior, the system can reduce the confidence of similar future detections.
Temporal escalation
If the same threat class appeared recently and wasn't dismissed or cancelled, confidence can increase.
Persistence matters.
Fleet correlation
If multiple servers in the same organization exhibit the same threat class at approximately the same time, Cortex can flag the behavior as potentially campaign-wide.
This makes the output much more useful than a generic severity number.
You can actually inspect why the system believes something is happening.
What I Got Wrong
The first version had several problems.

Chronic Signals Created Alert Fatigue Early versions would repeatedly rediscover the same condition. A misconfigured process could appear in every detection sweep and continuously generate another "suspicious process" investigation. The solution was to distinguish persistent conditions from newly emerging behavior. Signals that remain continuously present for more than 24 hours receive a chronic penalty. The goal isn't to hide the condition. It's to stop treating yesterday's condition as today's new incident.
Hardcoded Thresholds Don't Generalize My first attempt was basically: CPU > 80% = anomaly That didn't work. A database server running at 80% CPU may be completely normal. A lightly loaded web server suddenly reaching 80% at 3 AM could be much more interesting. Switching to per-server baselines and statistical deviation made the health signals considerably more useful.
I Wanted Real-Time Reasoning Cortex currently separates event detection from the heavier reasoning sweep. The agent can react to events as they're ingested, while the contextual reasoning layer runs on a 15-minute cycle. I initially wanted to make the reasoning cycle much faster. But the context-building stage queries five different areas of server state for every server. On a larger fleet, running that continuously becomes expensive very quickly. So I ended up with a hybrid approach: Fast event detection + periodic deeper reasoning. It's not perfectly real-time, but it gives me a better tradeoff between detection depth and infrastructure cost. Why I Built It This Way The goal wasn't to create another tool that generates more alerts. The goal was to reduce the distance between: Event → Context → Hypothesis → Evidence → Decision That's also why I don't want the system to be a black box. If Cortex says something looks like an active intrusion, I want an operator to be able to open the investigation and ask: "Why?" And get an answer based on the actual evidence collected from the server. Try the Detection Engine The system is currently available through Watch Cortex. You can try the interactive demo without creating an account: https://watch.alsopss.com/demo The demo shows the investigation workflow, reasoning chain, confidence scoring, and TTP matching. There's also a 14-day trial for the full platform. If you're building Linux security tooling, detection pipelines, SIEMs, EDRs, or homelab security systems, I'd genuinely like to hear how you approach the same problem. What signals do you find most useful for distinguishing a real intrusion from normal Linux noise? I'd especially like to hear from people running their own homelabs or small server fleets.

I Built an Autonomous AI Security Brain for Linux Servers (It Actually Responds, Not Just Alerts)

ALSOPS — Sun, 21 Jun 2026 13:22:08 +0000

I got tired of security tools that wake me up at 3am with alerts but leave all the real work to me.

So I built Cortex — the autonomous decision engine that powers Watch.

The Problem Most Linux Security Tools Share

Most tools (Falco, Wazuh, OSSEC, etc.) are great at detecting things, but terrible at deciding what to do about them. You end up with alert fatigue and manual investigation every single time.

I wanted something different.

Introducing Cortex: Context → Reason → Plan → Actuate

Cortex is the AI-powered security brain inside Watch. It runs on every server and works like this:

Context — Automatically builds a rich snapshot of the system (processes with ancestry, network connections, file integrity, SSH activity, DNS queries, etc.)
Reason — The on-device AI analyzes everything and answers:
- What is the most likely threat?
- How confident are we?
- How urgent is this?
Plan — If action is needed, it creates a clear, safe response plan (ban IP, kill process, revert file changes, etc.). It also deduplicates plans so you don’t get spammed with the same alert 50 times.
Actuate — It can act autonomously (in Autopilot or Sovereign mode) or queue the plan for your one-click approval.

All of this happens on-device, in milliseconds, even if the backend is unreachable.

Real Example from the Live Demo

When a brute-force attack hits, you can literally watch Cortex:

Gather context
Reason: “High confidence SSH brute force + suspicious process”
Plan: Ban the IP via nftables + kill the malicious process
Actuate: Execute (or wait for approval)

You see the full reasoning chain in plain English.

Try the Public Demo Right Now (No Account Needed)

Why I Built This

I run a small independent software company (AL'S-OPS LLC) and got frustrated with the existing tools. Either they were:

Too noisy (constant alerts)
Too heavy (ate all my RAM)
Too cloud-dependent
Or completely passive

Cortex was designed to fix all four problems.

Current Status & Roadmap

Works great on bare metal and VMs (Ubuntu, Debian, RHEL, etc.)
Docker support is live
Kubernetes support is rolling out now
Extremely lightweight agent (<8MB)

Try It Yourself

One-line install:


bash
curl -fsSL https://watch.alsopss.com/install.sh | sudo bash

Building the Future of Automation: The Al's-Ops LLC Story

ALSOPS — Sat, 20 Jun 2026 20:06:50 +0000

Hey Dev.to community! 👋
I wanted to take a moment to introduce myself and share the journey behind the company I founded. My name is Aiden McElroy, and I am the CEO and Founder of Al's-Ops LLC.
If you love DevOps, automation, and building scalable infrastructure, you're in the right place.
The Vision Behind Al's-Ops
Every developer knows the pain of repetitive tasks, fragile deployment pipelines, and the dreaded "well, it worked on my machine" excuse. I started Al's-Ops LLC with a clear mission: to streamline operations, eliminate friction, and help teams deploy with absolute confidence.
We focus on creating robust operational frameworks and automation strategies that allow developers to focus on what they do best—writing great code—while we handle the heavy lifting of the infrastructure.
What We Are Obsessed With:
Infrastructure as Code (IaC): Making environments reproducible, scalable, and secure.
CI/CD Pipeline Optimization: Cutting down build times and removing deployment bottlenecks.
Smart Monitoring & Observability: Finding and fixing bugs before your users even notice them.
Leadership in Tech: The Founder's Journey
Stepping into the role of CEO and Founder has been an incredible masterclass in both tech and business. Balancing the technical roadmap with strategic growth isn't always easy, but seeing the direct impact our solutions have on development teams makes every late-night coding session completely worth it.
My goal for Al's-Ops LLC isn't just to build another tech company; it’s to foster a culture of efficiency, continuous learning, and open-source collaboration.
Let’s Connect!
We are always looking to connect with brilliant developers, system architects, and tech enthusiasts.
What are the biggest DevOps or automation bottlenecks your team faces today?
What tools are you currently utilizing in your stack?
Drop a comment below, let’s chat tech, and feel free to follow along as we continue to scale Al's-Ops LLC! 🚀
Follow me here on Dev.to or connect with me to stay updated on our latest projects and technical insights!

How I got a threat-classification AI running on-agent in under 8ms — no GPU, no cloud

ALSOPS — Mon, 15 Jun 2026 18:16:36 +0000

When I tell people that Watch Cortex classifies threats in under 8ms on-agent — no cloud call, no GPU, no round-trip — the first question is usually: how?

The second question is: why bother? Just send it to the cloud.

Let me answer the second one first, because it explains all the engineering decisions that follow.

Why on-agent matters

The cloud-call model for security agents has a fundamental problem: it fails when you need it most.

Network incidents, backend outages, high-latency connections — all of these happen. And they correlate with attacks. An attacker who can disrupt your monitoring before escalating isn't a theoretical threat; it's a documented technique (T1562.001 in MITRE ATT&CK).

If your security agent phones home and gets no answer, you're flying blind during an attack. That's not a tradeoff I'm willing to make.

Beyond reliability: latency. A cloud round-trip is 50-200ms under good conditions. That's an eternity in an SSH brute-force sequence. Cortex needs to classify and respond before the attacker's next attempt lands — sub-second total, which means the classification step has to be under 10ms.

So: on-agent, <8ms, no GPU. Those were the constraints. Here's how I built to them.

What "classification" actually means here

First, let's be precise about what Cortex is doing. It's not doing NLP. It's not running a large model. It's doing behavioral event classification — looking at structured telemetry events and deciding: is this a threat, and if so, what kind?

Input: a stream of structured events — process forks, network connections, file writes, auth attempts — with context (parent process, timestamp, user, path, connection direction).

Output: a threat classification with confidence score, threat category, and recommended response action.

That framing changes the problem significantly. I'm not asking "what does this log line mean in English?" I'm asking "does this pattern of events match known attack behavior?"

The model architecture

Cortex uses a gradient-boosted decision tree ensemble (XGBoost, specifically) for the primary classifier, with a lightweight neural layer for anomaly scoring on top.

Why GBT instead of a neural network?

Inference speed. A well-tuned XGBoost model with ~200 trees classifies a feature vector in under 1ms on a modern CPU. Neural networks at equivalent accuracy are 10-50x slower for structured tabular data.
No GPU required. GBT inference is pure CPU arithmetic — matrix multiplications over narrow feature vectors. An EC2 t3.micro can run it comfortably alongside the monitoring agent without noticeable CPU impact.
Explainability. SHAP values let me tell the operator exactly which features drove the classification. That's how Cortex generates plain-language investigation summaries — not LLM-generated prose, but template-filled explanations grounded in feature importance scores.
Small model size. The serialized Cortex model is ~1.2MB. It ships with the agent binary, pre-synced. No cold-start, no download-on-first-use.

The anomaly layer is a small autoencoder (3 layers, ~15K parameters) that learns each server's baseline behavior over the first 72 hours. It flags events that deviate from that baseline even when they don't match known attack patterns. This is what catches novel techniques that the GBT hasn't been trained on.

Feature engineering: where the real work is

The model is the easy part. Feature engineering is where I spent 80% of the time.

Raw events are useless to a classifier. What matters is the context around an event — the temporal patterns, the process ancestry, the prior history of the entities involved.

Cortex computes ~140 features per event. A few illustrative examples:

Process ancestry features:

Depth of the process tree from init
Whether the parent is a known-good daemon vs. a user shell
Number of unique children spawned by this parent in the last 60 seconds
Whether this process name has been seen under this parent before (binary: novel lineage)

Network features:

Is the destination IP in a known-bad range (Tor exit nodes, bulletproof hosting ASNs)?
Is this the first time this process has made a network connection?
Is the destination port non-standard for this process's typical behavior?
Is the connection outbound from a process that typically doesn't make outbound connections?

Temporal features:

Auth failure rate per source IP in a rolling 60-second window
Time since last successful auth from this IP
Number of distinct usernames targeted by this source IP
Whether this event is occurring during an unusual time window for this server

File integrity features:

Was the file path modified by a process in the authorized-writer set?
Is the path in a high-sensitivity directory (authorized_keys, sudoers, cron.d)?
How recently was this file last modified?

The key insight: most of these features require stateful context, not just the current event. The agent maintains an in-memory state store — process tables, connection history, auth attempt logs, file write history — that the feature extractor queries in microseconds. This is why the agent runs as a persistent daemon rather than a per-event script.

The 8ms breakdown

Here's where the time actually goes:

Step	Time
Event receipt from kernel (eBPF probe)	~0.1ms
State store lookup + feature extraction	~1.5ms
GBT inference (XGBoost, 200 trees)	~0.8ms
Anomaly score (autoencoder)	~1.2ms
Threat category resolution + confidence calibration	~0.3ms
Response decision + action dispatch	~0.5ms
SHAP explanation generation	~3.5ms
Total	~8ms

SHAP generation is surprisingly expensive — it's the largest chunk. In a future version I may cache SHAP values for common event types and only run full SHAP on novel patterns. But 8ms total is fast enough that I haven't prioritized it.

The eBPF kernel probes are the other interesting piece. Cortex uses a small eBPF program (compiled with libbpf) attached to kprobes for execve, connect, openat, and a handful of others. The probe captures the raw event and writes it to a ring buffer; the userspace agent reads the ring buffer in a tight loop. This gives sub-millisecond event delivery from kernel to userspace — much faster than reading audit logs from /var/log/audit/.

Training data: the unglamorous part

A model is only as good as its training data, and training data for Linux attack behavior is genuinely hard to get.

I ended up with four sources:

Public datasets. DARPA VAST, CERT Insider Threat, CIC-IDS2017/2018. These are academic datasets with labeled attack traffic. Useful for broad coverage, but they're old and the attack patterns don't match modern techniques.
Honeypots. I run a small fleet of intentionally vulnerable Linux VMs (minimal hardening, weak SSH passwords) exposed to the public internet. They get attacked constantly. I log everything and use it as labeled attack data after manual review.
Red team exercises. I've run controlled red team scenarios against test VMs — mimicking common MITRE ATT&CK techniques — and captured the resulting telemetry as positive training examples.
Production negatives. Telemetry from normal server operation — cron jobs, package installs, legitimate SSH sessions, monitoring agents — gives me the negative class (normal behavior). This is the largest portion of the training set by volume.

The hardest problem: class imbalance. In production, attacks are rare events. A naive classifier learns to just say "not attack" and achieves 99.9% accuracy, which is useless. Cortex uses SMOTE oversampling on the minority class during training, plus a heavily tuned decision threshold that optimizes for false-negative minimization rather than accuracy. I'd rather have a false positive (unnecessary alert) than a false negative (missed attack).

Fleet immune memory: how threat signatures propagate

When Cortex detects and confirms a novel threat pattern on one agent, it extracts a compact threat signature: a vector of the most discriminative features that characterized the attack.

This signature is broadcast to all other agents in the fleet over an encrypted WebSocket connection to the backend, which fans it out immediately. Each receiving agent adds the signature to its local threat library.

The signature is not the full model — it's a set of rules derived from feature importance: "if source IP is in this /24, and auth failure rate exceeds X/min, and targeted usernames include 'admin' or 'root', classify as brute force with 0.95 confidence."

These derived rules are fast to evaluate — microseconds, not milliseconds — and supplement the GBT classifier for known-active attack campaigns.

When a human operator corrects a Cortex decision (false positive or false negative), the correction is also broadcast fleet-wide. The correction adjusts the confidence calibration for that threat category and, if it's a false positive on a specific process/path combination, adds it to a server-specific allowlist that propagates to similar servers in the fleet (matched by OS version and installed packages).

What I got wrong the first time

A few things I had to unlearn:

I started with a larger model. My first attempt used a 1,000-tree ensemble with deeper trees and more features. It was more accurate on benchmarks. It was also 40ms inference time, which broke the latency requirement. Ruthlessly pruning to 200 shallower trees while maintaining accuracy was a week of work.

I underestimated feature extraction time. I assumed feature extraction was trivial. It's not — especially the temporal features that require querying rolling windows over the state store. Most of my latency wins came from optimizing the state store (switched from SQLite to a hand-rolled ring-buffer structure in memory) rather than the model itself.

I tried to make the model explain itself in prose. My first attempt at investigation summaries used a small language model to generate natural-language explanations from the feature values. It added 50ms and the explanations were worse than what I ended up with: structured templates filled in by SHAP feature importance. "High-frequency SSH auth failures from new IP (3,800 attempts / 4 min)" is more useful than a paragraph.

Where it goes from here

A few things on the roadmap:

Per-server model fine-tuning. Right now Cortex ships one global model and adapts at inference time using the anomaly layer. Long-term, I want to fine-tune the GBT on each server's specific behavior profile after a 30-day baseline period.
eBPF program hot-reload. Currently, updating the kernel probes requires an agent restart. I'm working on a mechanism to push updated eBPF programs without dropping the ring buffer or interrupting monitoring.
Threat intelligence federation. Beyond fleet immune memory, I'm looking at integrating with external threat intel feeds (VirusTotal, AbuseIPDB, Shodan) to supplement the classifier's context for external IPs and file hashes.

If you're building something in this space — autonomous security agents, on-device ML inference, eBPF-based monitoring — I'm happy to trade notes. Drop a comment or reach out directly.

Watch Cortex — 14-day free trial, no credit card.

Built by AL'S-OPS LLC. Feedback and security disclosures: security@alsopss.com.

I built an AI that autonomously bans attackers on Linux — no human in the loop

ALSOPS — Sun, 07 Jun 2026 06:47:09 +0000

Last year I got paged at 2am because someone was brute-forcing SSH on one of my servers. I woke up, fumbled for my phone, opened the dashboard, confirmed it was real, and banned the IP. By the time I did that — maybe 4 minutes — they'd tried 3,800 passwords.

They didn't get in. But that's not the point.

The point is: why did that require a human?

The pattern was unambiguous. High-frequency auth failures from a single IP, no prior connection history, no valid user account targeted. An intern could have made that call. So why was I woken up at 2am to rubber-stamp a decision that was already obvious?

That question is why I built Watch Cortex.

The actual problem with Linux security tooling

Most Linux security tools are good at one thing: generating alerts.

Wazuh fires alerts. Datadog fires alerts. Falco fires alerts. Auditd fires alerts. If you're lucky, your SIEM correlates those alerts into a bigger alert that you also have to manually act on.

The human is always in the loop. And the human is always the bottleneck.

This creates a well-documented failure mode: alert fatigue. You get so many alerts that you stop trusting them. You start dismissing things. And then you miss the one that mattered.

I wanted to build something different. Not "detect and alert." Detect, reason, and respond — in the time it takes the attacker to try their next password.

How Watch Cortex works

The architecture is built around three components:

1. The Watch agent

A single binary (~8MB) that deploys as a systemd service. Install:

curl -fsSL https://watch.alsopss.com/install-agent.sh | sudo bash -s -- --token YOUR_TOKEN

Done in under 60 seconds. The agent connects outbound over WSS on port 443 — no inbound firewall changes, no open ports.

It monitors:

Process creation and termination with full ancestry trees
Network connections and DNS queries
File integrity changes (configs, SSH authorized_keys, crontabs)
SSH authentication events
Systemd unit additions
User/group mutations

2. Cortex AI — the on-agent reasoning engine

This is the part I'm most proud of. Cortex runs locally on the agent — no cloud call, no round-trip latency, no "cloud service is unreachable" failure mode.

It classifies threats in under 8 milliseconds.

Cortex doesn't just match signatures. It correlates signals across process trees, network activity, and file writes to identify behavioral patterns:

Brute force followed by a successful login from a new IP → escalate
Process that opens a network socket and writes to /tmp → suspicious regardless of name
SSH key added to authorized_keys by a process that isn't the user's shell → respond immediately
Cron job added by a process with no history → flag

Every alert comes with a plain-language investigation summary explaining what triggered, what it correlates to, and what action was taken or recommended. Not RULE_5023_TRIGGERED. An actual explanation.

3. Cortex Hive — fleet immune memory

When Watch catches something on one server, it broadcasts that threat signature to every other agent in your fleet immediately.

One server gets hit with a new cryptominer variant → every other server learns to recognize and block it before it arrives. The fleet develops collective immunity.

When you correct a Cortex decision — "that was actually legitimate, don't block that next time" — that correction propagates fleet-wide automatically. The whole fleet gets smarter from one operator's feedback.

The four automation modes

I don't want to force everyone into full autonomous mode on day one. So Watch has a mode ladder:

Mode	What it does
Watch	AI observes and alerts. Every action requires your approval.
Assist	Non-destructive actions (logging, enrichment) run auto. Destructive actions (IP ban, process kill) surface as one-click suggestions.
Autopilot	High-confidence threats acted on immediately. Low-confidence threats queue for your override.
Sovereign	AI acts on everything confirmed. You override rather than approve — system never waits.

Most people start on Assist. They see the one-click suggestions coming in, they confirm a few, they realize Cortex is right 95%+ of the time, and they bump to Autopilot. Some teams — especially infrastructure-heavy ones with no 24/7 security staff — run full Sovereign.

The key insight is: humans should be the override path, not the approval path.

What happens during a real attack sequence

Here's a realistic SSH brute-force → persistence scenario and how Watch handles it in Autopilot mode:

T+0s: Attacker begins SSH brute force from 185.220.101.x

T+0.3s: Watch agent detects high-frequency auth failures

T+0.8s: Cortex classifies: brute force, high confidence

T+1.1s: iptables rule added — IP banned

T+1.2s: Threat broadcast to all fleet agents via Cortex Hive

T+1.5s: Alert + investigation summary sent to dashboard

T+0s: Attacker tries again from a different IP in same /24 subnet

T+0.3s: Cortex correlates new IP to same campaign (same user targets, same timing pattern)

T+0.8s: Subnet banned preemptively

T+0s: Attacker somehow gets in (compromised credential, different vector)

T+2s: New process spawned by sshd with unusual ancestry

T+3s: Process opens outbound connection to known C2 range

T+3.2s: Cortex classifies: reverse shell / lateral movement, high confidence

T+3.5s: Process killed by PID

T+3.6s: File integrity check initiated on affected paths

T+4s: Operator notified with full chain-of-events summary

Total time from first detection to lateral movement blocked: 4 seconds.

Time I need to be awake: 0.

Why I didn't just use Wazuh

Wazuh is genuinely good. It's open-source, extensible, and has a massive rule set. I used it for two years.

But Wazuh is a SIEM. It collects events, matches rules, and fires alerts. That's it. Everything after the alert is on you.

Watch is an autonomous response platform. The detection is table stakes. The response — especially the AI-reasoned, fleet-aware, offline-capable response — is the thing.

The other thing: Wazuh alert noise. Out of the box, you'll tune it for weeks before it's quiet enough to trust. Cortex learns your specific server's baseline. It's not "process X is always suspicious" — it's "process X is suspicious on this server because it's never done this before."

Offline operation

This is a requirement I'm firm about. An agent that stops working when the backend is unreachable isn't actually protecting you — it's just making you feel protected.

Cortex AI, threat signatures, contingency plans, and response policies are all pre-synced to each agent. When the backend is unreachable, detection and response continue at full capability. Actions taken offline are logged locally with cryptographic timestamps and synced when connectivity returns.

If someone is actively attacking your server during a network incident, the last thing you need is your security agent phoning home and getting no answer.

The compliance angle

Most teams I talk to are running on vibes for Linux compliance. "We have auditd enabled" doesn't get you through a SOC 2 audit. Watch automates the parts that actually matter:

CIS Benchmark Level 1 & 2 — continuous posture monitoring
SOC 2 Type II — automated control mapping + evidence collection
PCI-DSS v4 — cardholder data environment monitoring
HIPAA — access events and audit controls
ISO 27001, NIST 800-207 Zero Trust, GDPR

Business plan generates on-demand compliance reports. Enterprise/Empire run a continuous compliance forge — gaps are identified and closed automatically without you pulling a report and manually remediating.

Try it

14-day free trial, no credit card, under 60 seconds to install:

watch.alsopss.com

Developer plan is $39/month for 5 servers. Business is $149/month for 25 servers with Autopilot mode, fleet immune memory, and compliance automation.

If you're running Linux in production with limited security headcount — or you've been paged at 2am one too many times to rubber-stamp an obvious brute-force — it's worth a look.

Happy to answer questions in the comments. I've been building this for two years and I can talk about the architecture all day.

Built by AL'S-OPS LLC. Feedback, issues, and security disclosures: security@alsopss.com.

From Idea to Product: How We Build Modern Web Applications

ALSOPS — Fri, 13 Mar 2026 00:12:43 +0000

Building a modern web application today is very different from even a few years ago. Users expect fast performance, seamless design, AI-powered features, and products that work flawlessly across devices.

At Al’s-Ops LLC, we spend a lot of time thinking about how to build digital products that not only function well but also create meaningful user experiences.

In this article, I want to share some of the principles and development practices we follow when building web applications, from early-stage concepts to production platforms.

⸻

Start With the Problem, Not the Technology

One of the biggest mistakes we see in product development is starting with technology instead of the user problem.

Before writing a single line of code, we ask questions like:
• What real problem does this solve?
• Who is the user?
• How often will they use this product?
• What would make them return?

This approach helps avoid over-engineering and ensures the product is actually valuable.

For example, when building SwiftChef, our recipe discovery and meal planning platform, the focus wasn’t simply on storing recipes. The real challenge was helping users quickly find meals they want to cook and plan their week efficiently.

That focus shaped everything that followed in the product.

⸻

Build an MVP That Can Scale

Many founders hear the phrase “build an MVP” but misunderstand what it actually means.

A good MVP should be:
• Minimal in features
• High quality in execution
• Designed with future scaling in mind

The goal isn’t to launch something temporary. It’s to launch something small but strong.

When designing architectures for new platforms, we typically aim for:
• Modular backend systems
• Clean API design
• Component-based frontend frameworks
• Cloud-native infrastructure

This allows products to grow without requiring a full rewrite later.

⸻

User Experience Is a Competitive Advantage

The difference between successful apps and forgotten apps often comes down to UX.

Great software should feel:
• Fast
• Intuitive
• Effortless

This means developers need to think beyond functionality and consider:
• Load performance
• Visual hierarchy
• Interaction feedback
• Mobile responsiveness

Even small improvements in usability can dramatically increase user retention.

⸻

AI Is Changing Product Development

Artificial intelligence is quickly becoming a core feature in many digital products.

We’re seeing AI used for:
• Personalization
• Smart recommendations
• Natural language search
• Automated workflows

The key is integrating AI in ways that actually improve the user experience, rather than adding it just because it’s trendy.

For consumer platforms like SwiftChef, AI-driven discovery and intelligent filtering can dramatically improve how users find content.

For SaaS tools, AI can automate tasks that previously required manual effort.

⸻

Speed Matters in Modern Development

Startups and early-stage products need to move fast.

This means focusing on development processes that prioritize:
• Rapid iteration
• Continuous deployment
• Feedback loops with real users

Shipping quickly doesn’t mean sacrificing quality. It means building systems that allow you to improve the product continuously.

⸻

Collaboration Is Key to Great Products

Great software rarely comes from one person working alone.

The best products come from collaboration between:
• Developers
• Designers
• Product thinkers
• Founders
• Users

At Al’s-Ops LLC, we work closely with teams to transform ideas into scalable digital products across areas like:
• Web applications
• E-commerce platforms
• AI-powered tools
• Gaming-related services

⸻

Final Thoughts

The web is evolving faster than ever. New technologies appear constantly, but the fundamentals of building great products remain the same:
• Solve real problems
• Focus on the user experience
• Build systems that scale
• Iterate quickly

If you’re building a new digital product or experimenting with a startup idea, these principles can help you move from concept to production more effectively.

⸻

About the Author

Al’s-Ops LLC is a software development company building innovative web applications and digital products across gaming, e-commerce, web development, and artificial intelligence.

Our flagship product, SwiftChef, is a premium recipe discovery and meal planning platform used by home cooks every day.

🌐 https://alsopss.com
📧 b2b@alsopss.com

metaForge: A Multi-Language Build & Automation Compiler

ALSOPS — Mon, 08 Dec 2025 17:07:22 +0000

I’m excited to share metaForge, a multi-language MFG compiler that makes building, running, and managing code files across languages easy.
MetaForge parses .mfg files containing groups, blocks, arguments, and raw commands, expands variables, writes code files, and executes commands automatically. It’s designed for developers who want a flexible, multi-language build system.
📌 Key Features
Parse .mfg files into:
Groups: collections of blocks with variables
Blocks: named code files with optional run commands
Args blocks: conditional blocks triggered by CLI arguments
Raw variables & commands: global scope
Variable Expansion: $var:name, $arg, $block:name, $group:name
Automatic File Creation & Execution
Verbose Logging (-v or --verbose)
⚙️ Supported Languages
C++ (default, compiled, fastest)
JavaScript (Node.js based, easy to modify)
Python (widely accessible)
🚀 Quick Start
Create a .mfg file:
group js {
var greeting = "Hello World!"

block hello.js {
    code {
        console.log("$var:greeting");
    }
    run "node $block:hello.js"
}

}

run "rm -rf $group:js"
Run metaForge:
metaForge example.mfg
MetaForge will create hello.js with expanded variables, run it, and clean up automatically.
Example CLI:
metaForge build.mfg build # Builds and runs everything
metaForge build.mfg clean # Removes generated files
📖 Documentation
Full guides, syntax reference, and advanced examples: metaforge.alsopss.com/docs
🛠 Installation

Build C++ version (default)

make build

Build JS or Python versions

make build LANG=js
make build LANG=py

Install

sudo make install LANG=cpp
Custom installation paths and packaging are supported via PREFIX and DESTDIR.
🤝 Contributing
Contributions are welcome! Submit Pull Requests or open Discussions on GitHub: https://github.com/ALSOPSS/metaForge