I
Igboanugo David Ugochukwu
Guest
A round two engineering report on brute force detection, a deployment that works, a GPU module that does not yet exist, and the experiment that would settle whether decentralized compute earns a place in this pipeline.
Most security teams do not lack events. They lack the story that connects them. A failed login at 02:14, a success at 02:19 from the same address, and a read of a sensitive resource at 02:21 are three log lines in three systems. Together they may be one account takeover. Apart, each looks like noise.
That is the problem SentinelIQ targets, and it is still a live one. Verizon's 2026 Data Breach Investigations Report, drawing on more than 22,000 confirmed breaches, found vulnerability exploitation overtaking credential abuse as the top initial access vector, at 31 percent. The headline is real, but Push Security points out that the report's taxonomy splits identity attacks across phishing, credential abuse and pretexting, and that identity related access comes to roughly the same share as exploitation once combined. More telling for anyone building detection: credential abuse still appears in 39 percent of all breaches across the full attack chain. Stolen credentials may no longer be the front door in every case, but they remain the connective tissue of the breach. Detecting how they get used is still worth building.
Brute force against an account is catalogued as technique T1110 in MITRE ATT&CK. It is the technique SentinelIQ models first. I built it in public, and for this second article I did something uncomfortable: I reread my own code line by line, as a skeptical reviewer would, and wrote down what it does.
SentinelIQ is a Python 3.12 and FastAPI service, packaged with Docker, with a browser dashboard. The README describes the flow as events entering an API layer, then a UEBA risk engine, a correlation engine, MITRE ATT&CK mapping, an attack graph builder, a response engine and a dashboard. The repository is MIT licensed and has a live Swagger interface on Nosana at the deployment URL.
I want to be precise about the word "AI" here. I audited four modules in depth: the UEBA engine, the correlation engine, the threat intelligence check and the GPU anomaly module. In those files, nothing is trained, and no model is loaded. The logic is rule based, which is a fair starting point for a transparent system, as long as it is labelled correctly.
The README documents this input:
In
I traced that arithmetic by hand from the source. These are derived values, not recorded API output:
The score is not capped, and nothing decays it.
Here is the finding that matters.
The README's sample risk of 65 does not appear anywhere in the UEBA arithmetic above, so it likely came from another module, most plausibly
Two more observations. The technique label T1110 is attached to every outcome, including
None of this is shameful. It is what a first prototype looks like. It becomes a problem only if the documentation claims more than the code does, and I would rather find that myself than have a reviewer find it.
It establishes that the pipeline runs end to end and that its thresholds behave deterministically. It does not establish detection quality. A rule that fires on a hardcoded address list is a demonstration of control flow, not evidence of recall against real attackers. A risk score is a prioritisation signal. A correlation label is a hypothesis. Neither is confirmation of compromise, and the string
The repository contains a
So the accurate statement is this: SentinelIQ currently contains no GPU workload. There is no model, no CUDA call and no tensor operation in that module. A random multiplier also makes the score non reproducible, which is a defect in its own right for a security tool, because the same event can score differently on two runs.
This shapes the Nosana story, and I prefer to tell it straight. My deployment demonstrates that a containerised FastAPI service can be built, shipped and exposed on Nosana's network using the free credits I received. That is a hosting result. It is not evidence of GPU inference, and it is not evidence that decentralized compute improved speed or cost. I have not measured either, so I make neither claim.
That is also why the question is interesting. A rule engine like this one is CPU work. It would be wasteful to put it on a GPU, and any honest architecture would say so. Decentralized GPU capacity becomes relevant only when there is a workload that needs it, such as embedding model inference or anomaly detection over large synthetic event histories. Deciding whether that workload exists in this pipeline is the real engineering question.
With limited credits, I cannot explore broadly. I can run one disciplined experiment.
If a small model on CPU turns out faster and cheaper, that is a valid and useful finding for Nosana's developer relations team, because it tells them which workloads do not belong on the network.
I have used my free Nosana credits and cannot buy more. I treat that as a design input. It is the reason the plan above is one experiment with a baseline rather than a scatter of demos. A small budget forces a precise question, and a precise question is what produces a result other engineers can trust.
It is a transparent, runnable prototype of a security analysis pipeline, with an honest gap between its ambition and its current logic, and a concrete, measurable path across that gap. The hackathon gave me a reason to look closely. The audit gave me the plan.
If you maintain detection engineering tools, or work on workload placement at Nosana, I would value your critique of the evaluation design. Break the assumptions. That is how this gets better.
The problem is context, not collection
Most security teams do not lack events. They lack the story that connects them. A failed login at 02:14, a success at 02:19 from the same address, and a read of a sensitive resource at 02:21 are three log lines in three systems. Together they may be one account takeover. Apart, each looks like noise.
That is the problem SentinelIQ targets, and it is still a live one. Verizon's 2026 Data Breach Investigations Report, drawing on more than 22,000 confirmed breaches, found vulnerability exploitation overtaking credential abuse as the top initial access vector, at 31 percent. The headline is real, but Push Security points out that the report's taxonomy splits identity attacks across phishing, credential abuse and pretexting, and that identity related access comes to roughly the same share as exploitation once combined. More telling for anyone building detection: credential abuse still appears in 39 percent of all breaches across the full attack chain. Stolen credentials may no longer be the front door in every case, but they remain the connective tissue of the breach. Detecting how they get used is still worth building.
Brute force against an account is catalogued as technique T1110 in MITRE ATT&CK. It is the technique SentinelIQ models first. I built it in public, and for this second article I did something uncomfortable: I reread my own code line by line, as a skeptical reviewer would, and wrote down what it does.
What SentinelIQ is, as of the code I audited
SentinelIQ is a Python 3.12 and FastAPI service, packaged with Docker, with a browser dashboard. The README describes the flow as events entering an API layer, then a UEBA risk engine, a correlation engine, MITRE ATT&CK mapping, an attack graph builder, a response engine and a dashboard. The repository is MIT licensed and has a live Swagger interface on Nosana at the deployment URL.
I want to be precise about the word "AI" here. I audited four modules in depth: the UEBA engine, the correlation engine, the threat intelligence check and the GPU anomaly module. In those files, nothing is trained, and no model is loaded. The logic is rule based, which is a fair starting point for a transparent system, as long as it is labelled correctly.
| Component | File | What it actually does today |
|---|---|---|
| Behavior analytics | ueba_engine.py | Counts failed logins per user in memory and computes a linear risk score |
| Correlation | correlation_engine.py | Applies two thresholds to risk plus a threat intelligence flag |
| Threat intelligence | threat_intel.py | Checks an IP against a hardcoded list of two addresses |
| GPU anomaly scorer | gpu_anomaly_engine.py | Simulated. Builds a three number vector and applies a random multiplier |
| ATT&CK mapping | correlation_engine.py | Static T1110 label attached to every outcome |
One event, traced through the code
The README documents this input:
Code:
{
"user_id": "admin",
"event_type": "LOGIN_FAILURE",
"ip_address": "8.8.8.8"
}In
ueba_engine.py, each user has an entry in an in memory dictionary holding a failed login counter and a suspicion counter. Every LOGIN_FAILURE adds one to the counter. From the third failure onward, the suspicion counter rises by two with each failure. The risk score is failed_logins * 20 + suspicious * 25.I traced that arithmetic by hand from the source. These are derived values, not recorded API output:
| Failure number | Risk score |
|---|---|
| 1 | 20 |
| 2 | 40 |
| 3 | 110 |
| 4 | 180 |
The score is not capped, and nothing decays it.
correlation_engine.py then combines that score with a threat intelligence flag. If the IP is flagged and risk is at least 60, the result is CONFIRMED_ATTACK (T1110 Brute Force). If the IP is flagged and risk is at least 30, it is SUSPICIOUS_ACTIVITY. Everything else is NORMAL.Here is the finding that matters.
threat_intel.py flags exactly two addresses: 10.0.0.99 and 185.220.101.1. Under this code, the README's 8.8.8.8 example returns NORMAL, even after four failures and a risk of 180. Submit the same events from 185.220.101.1 and the third failure produces CONFIRMED_ATTACK.| Source IP | Failures | Risk | Correlation result |
|---|---|---|---|
| 8.8.8.8 | 4 | 180 | NORMAL |
| 185.220.101.1 | 2 | 40 | SUSPICIOUS_ACTIVITY |
| 185.220.101.1 | 3 | 110 | CONFIRMED_ATTACK |
The README's sample risk of 65 does not appear anywhere in the UEBA arithmetic above, so it likely came from another module, most plausibly
ai_risk_engine.py, which I have not yet verified.Two more observations. The technique label T1110 is attached to every outcome, including
NORMAL, so the mapping is static rather than inferred. And the per user state lives in a process level dictionary, so it vanishes on restart and would diverge across multiple workers.None of this is shameful. It is what a first prototype looks like. It becomes a problem only if the documentation claims more than the code does, and I would rather find that myself than have a reviewer find it.
What this output does and does not establish
It establishes that the pipeline runs end to end and that its thresholds behave deterministically. It does not establish detection quality. A rule that fires on a hardcoded address list is a demonstration of control flow, not evidence of recall against real attackers. A risk score is a prioritisation signal. A correlation label is a hypothesis. Neither is confirmation of compromise, and the string
CONFIRMED_ATTACK in the current code is a stronger word than the logic earns. Renaming it is on my list.The GPU question, answered honestly
The repository contains a
gpu directory and a file called gpu_anomaly_engine.py. Its header calls it a simulated GPU based anomaly scorer. It builds a three number "embedding" from the length of the user name, a sum of IP octets modulo 50 and the length of the event type. It then takes the vector's magnitude and multiplies it by a random number between 0.8 and 1.3. The code comments say a real model, such as sentence transformers, ONNX or CUDA, should replace it later.So the accurate statement is this: SentinelIQ currently contains no GPU workload. There is no model, no CUDA call and no tensor operation in that module. A random multiplier also makes the score non reproducible, which is a defect in its own right for a security tool, because the same event can score differently on two runs.
This shapes the Nosana story, and I prefer to tell it straight. My deployment demonstrates that a containerised FastAPI service can be built, shipped and exposed on Nosana's network using the free credits I received. That is a hosting result. It is not evidence of GPU inference, and it is not evidence that decentralized compute improved speed or cost. I have not measured either, so I make neither claim.
That is also why the question is interesting. A rule engine like this one is CPU work. It would be wasteful to put it on a GPU, and any honest architecture would say so. Decentralized GPU capacity becomes relevant only when there is a workload that needs it, such as embedding model inference or anomaly detection over large synthetic event histories. Deciding whether that workload exists in this pipeline is the real engineering question.
The experiment worth running
With limited credits, I cannot explore broadly. I can run one disciplined experiment.
| Step | Action | Evidence produced |
|---|---|---|
| 1 | Replace the random multiplier with a small, fixed embedding model exported to ONNX. Run on CPU first and seed everything. | Deterministic scores for identical input |
| 2 | Build a labelled synthetic dataset of benign sequences (including legitimate users who mistype passwords) and scripted brute force sequences, with ground truth stored beside each. | Published dataset and generator script |
| 3 | Measure the CPU baseline: precision, recall, false positive rate, p50 and p95 latency per event, throughput per second. Document hardware and versions. | Baseline metrics table |
| 4 | Run the identical workload on a Nosana GPU node and record the same metrics plus cost per thousand events. | Side by side comparison |
| 5 | State whether decentralized compute helped, whichever way the numbers fall. | Written conclusion |
If a small model on CPU turns out faster and cheaper, that is a valid and useful finding for Nosana's developer relations team, because it tells them which workloads do not belong on the network.
Next milestones, with completion criteria
| Priority | Milestone | Done when |
|---|---|---|
| 1 | Reconcile the documentation with the code | A stranger can run the documented request and get the documented response |
| 2 | Add tests. The README lists a tests directory, but the repository listing I inspected does not contain one | Tests cover the brute force path, the benign mistyped password path and the threat intelligence boundary, and pass in CI |
| 3 | Persist and bound state | A restart does not erase history, and scores stay on a fixed scale with decay |
| 4 | Run the CPU versus Nosana GPU experiment | The metrics table is published with the dataset and scripts |
Constraints, stated plainly
I have used my free Nosana credits and cannot buy more. I treat that as a design input. It is the reason the plan above is one experiment with a baseline rather than a scatter of demos. A small budget forces a precise question, and a precise question is what produces a result other engineers can trust.
Where this leaves SentinelIQ
It is a transparent, runnable prototype of a security analysis pipeline, with an honest gap between its ambition and its current logic, and a concrete, measurable path across that gap. The hackathon gave me a reason to look closely. The audit gave me the plan.
If you maintain detection engineering tools, or work on workload placement at Nosana, I would value your critique of the evaluation design. Break the assumptions. That is how this gets better.
Links
- Repository: https://github.com/Drechi3/SentinelIQ
- Live API documentation: https://4u8pgm9fagp9ah4al48agqdvwoxypvsvn9rutoeccsvn.node.k8s.prd.nos.ci/docs
- Nosana: https://nosana.io/
- MITRE ATT&CK T1110: https://attack.mitre.org/techniques/T1110/
- Verizon 2026 DBIR analysis by Push Security: https://pushsecurity.com/blog/verizon-dbir-2026-review
- DBIR takeaways on credential abuse by SpyCloud: https://spycloud.com/blog/top-takeaways-from-the-2026-verizon-data-breach-investigations-report/