GreyNOC Detector Engine v0.9.1: Building a Predictive, Defender-First Detection Platform

Security teams are overwhelmed by signals.

Every day brings another wave of CVEs, exploit chatter, public proof-of-concept activity, ransomware movement, vendor advisories, threat intelligence feeds, detection rules, suspicious network behavior, and alerts that may or may not matter. The modern defender is no longer suffering from a lack of information. The problem is the opposite. There is too much information, too little context, and not enough time to decide what deserves action first.

That is the problem GreyNOC Detector Engine is being built to solve.

With the v0.9.1 release, GreyNOC Detector Engine takes a major step forward from a defensive aggregation tool into a predictive, OSINT-driven, defender-first detection platform. The goal is not to build another generic rule generator. The goal is to build an engine that helps defenders understand what matters, why it matters, how likely it is to become active, whether their environment may be exposed, and whether the available detections are actually trustworthy.

The direction is simple: GreyNOC does not just generate detections. GreyNOC helps prove which detections are worth trusting.

That difference matters. In security operations, a detection that has not been tested, validated, tuned, or tied to real evidence is only a draft idea. It might be useful, but it might also be noisy, too broad, too vague, or impossible to deploy with the telemetry a team actually has. GreyNOC is being designed around the belief that defenders need more than rules. They need evidence, confidence, explainability, prioritization, and actionability.

The v0.9.1 release establishes that foundation. It brings together predictive forecasting, OSINT enrichment, local defensive sensing, ICS-aware classification, safety hardening, export workflows, analyst feedback, and detection quality. Together, these features move the engine toward a larger mission: helping SOC teams turn messy public and local signals into trusted, validated detection intelligence.

At the center of this release is the predictive engine. Each threat can now receive an explainable forecast that includes probability, time horizon, confidence, p50 and p90 day estimates, and named drivers. Instead of only asking what happened, the engine begins asking what is likely to matter next. That is a critical shift. Defense is a race against time. The sooner a SOC can identify which vulnerability, campaign, IOC, exposure, or detection gap is becoming important, the better chance it has to act before impact.

Predictive security should not be treated as magic. Forecasts are not guarantees. They are prioritization aids. They help analysts decide where to look first, what deserves deeper review, and which threats may be moving from background noise into operational relevance. GreyNOC’s approach is built around explainability, meaning a forecast should not only produce a number. It should also explain the drivers behind that number. If a threat’s probability rises because of EPSS movement, CISA KEV presence, ransomware leak-site activity, public IOC reputation, vendor emergency language, related detection-rule activity, or observed local exposure, the analyst should be able to see that clearly.

That level of explanation is essential. A black-box prediction is not useful to a defender who has to justify action. A transparent forecast, backed by source context and named drivers, becomes something a SOC can reason about.

The OSINT layer behind v0.9.1 is also much stronger. The engine now works with public CVE data, CISA KEV, FIRST.org EPSS, abuse.ch ThreatFox, URLhaus, ransomware leak-site metadata, vendor PSIRTs, security research blogs, AI-security research, GitHub metadata, and carefully controlled defensive rule repositories. Each of these sources answers a different question. CVE data describes the vulnerability. KEV tells us whether exploitation is known. EPSS gives an external exploit-probability prior. ThreatFox and URLhaus add IOC reputation. Ransomware metadata provides campaign context. Vendor advisories add urgency and remediation signals. Research blogs add TTPs and narrative. GitHub metadata and defensive rule repositories show what the broader security community is already watching or trying to detect.

The point is not to blindly trust public feeds. Public data is noisy, incomplete, and sometimes wrong. The point is to collect those signals, preserve their source context, score them transparently, and help defenders make better decisions. GreyNOC treats public source content as untrusted input. That is the correct model. The engine should ingest, normalize, correlate, and explain; it should not blindly accept or execute anything it sees.

Safety is one of the most important parts of this release. Because the engine touches public data, GitHub metadata, defensive rule repositories, local network observations, and honeypot-style signals, the engine itself has an attack surface. v0.9.1 includes a dedicated security review that documents this surface and the mitigations applied. That includes protections around hostile public feeds, unsafe HTTP redirects, oversized responses, malicious repository content, unsafe honeypot defaults, fixture path traversal, raw string interpolation in generated detections, and subprocess environment inheritance.

Those controls matter because a defender tool should never become a new risk to the defender. GreyNOC is built around clear defensive boundaries. It does not generate exploit code. It does not generate malware. It does not generate credential theft logic. It does not generate persistence logic, unauthorized scanning behavior, weaponized payloads, or bypass instructions. GitHub search remains metadata-only. Defensive git repository ingestion is opt-in, allowlisted, shallow, sandboxed, and content-only. Honeypot behavior defaults to loopback. ICS awareness is classification-focused and detection-only. Public content is treated as hostile until proven otherwise.

That safety posture is especially important as the engine expands into local sensing and ICS-aware visibility.

v0.9.1 introduces local defensive sensing through what we call the Spacestation sensor. It reads the OS connection table and identifies patterns such as port scans, slow scans, SYN flood indicators, port knocks, ICS probes, and darknet touches. This gives the engine a way to connect external intelligence with local observations. If the outside world is shouting about a campaign and the local network is showing related scanning or probing behavior, that combination becomes more important than either signal alone.

The release also adds ICS device classification based on passive indicators such as MAC OUI and protocol port fingerprints. This includes protocols like Modbus, S7, DNP3, EtherNet/IP, BACnet, OPC UA, IEC 60870-5-104, Profinet, FINS, MELSEC, and CODESYS. The important point is that the engine does not speak ICS protocols. It does not interact with industrial devices. It classifies and observes defensively. That boundary should remain clear in every future release, because ICS environments demand caution. Passive awareness can help defenders. Active behavior can create risk. GreyNOC should stay firmly on the passive, detection-only side unless a future deployment explicitly and safely defines otherwise.

Another major direction in this release is detection trust. One of the most important ideas in the GreyNOC roadmap is the Detection Quality Passport. Detection generation by itself is not enough. A generated rule might be helpful, but it might also be noisy, incomplete, or dangerous to rely on. A SOC does not need endless draft rules. It needs detections that have been tested, validated, tuned, and explained.

The Detection Quality Passport is designed to give each detection a trust grade. It evaluates validation status, passed evidence, reviewer presence, telemetry source, positive sample size, precision-ready test results, true positives, and false positives. In other words, it asks whether the detection has earned trust. A Platinum detection should mean something. A Gold detection should mean something. An Unproven detection should remain in draft or research mode.

This is where GreyNOC can become meaningfully different from ordinary rule-generation tools. Most tools can produce detection logic. Fewer tools can tell you whether the detection is trustworthy, what evidence supports it, what telemetry it requires, what false positives were observed, who reviewed it, and whether it is ready for operational export.

GreyNOC is moving toward a model where detections pass through a lifecycle. A detection may begin as a draft generated from threat context. It can then be tested against positive and negative fixtures. It can be reviewed by an analyst. It can receive validation evidence. It can be assigned a Quality Passport. Only then should it move toward trusted export or operational deployment. That lifecycle is a much better model than treating every generated rule as equally useful.

GreyNOC Signal DNA is another important concept in the release direction. Signal DNA gives threats a stable fingerprint and signal-strength profile based on source references, CVE context, KEV context, detection opportunities, AI relevance, affected products, ATT&CK or TTP terms, and SOC action density. Over time, this can evolve into campaign memory.

Campaign memory is powerful because SOC teams often see related activity in fragments. A CVE appears in one feed. A vendor advisory appears somewhere else. A suspicious repository appears later. A ransomware leak-site post references a victim in the same sector. A local sensor observes probing against a related protocol. Separately, those signals may look small. Together, they may form a pattern. Signal DNA gives GreyNOC a way to identify, compare, and cluster those patterns over time.

Eventually, this can help answer questions like: Have we seen this pattern before? Is this threat similar to a previous campaign? Are the same products, TTPs, actors, or infrastructure signals showing up again? Are forecast scores rising across related threats? Do we have validated detection coverage for this family of activity? What changed since the last time this signal appeared?

That is when the engine becomes more than a database. It becomes memory for the defender.

v0.9.1 also introduces analyst feedback and forecast accuracy tracking. This matters because a predictive engine must be honest about its own performance. If the engine predicts that a threat is likely to become active and nothing happens, that should be measured. If the engine underestimates a threat that later becomes important, that should be measured too. Forecasting without calibration is just guessing with confidence. Forecasting with Brier scores, calibration buckets, horizon tracking, and analyst feedback becomes a system that can improve.

This is another area where GreyNOC can stand out. A lot of tools score threats. Fewer tools measure whether their scoring was right. A mature version of GreyNOC should be able to tell defenders when it was overconfident, when it was underconfident, which drivers helped, which drivers hurt, and how the model changed after feedback. That kind of transparency builds trust.

The release also adds STIX 2.1 and ATT&CK Navigator exporters, which is important because SOC teams do not need another isolated tool. They need intelligence and detections that can move into the systems they already use: threat intelligence platforms, SIEMs, detection repositories, case management systems, reporting workflows, and executive summaries. GreyNOC should not become a silo. It should become a trust layer that feeds the defender ecosystem.

The long-term export vision should be a trusted detection package. That package should include the detection logic, required telemetry, validation evidence, Quality Passport, Signal DNA, forecast context, ATT&CK mapping, deployment notes, tuning guidance, and recommended SOC action. That is the difference between a rule and a detection product.

Looking at v0.9.1 as a whole, the release is impressive, but it also introduces a lot of scope. Predictive scoring, OSINT enrichment, ICS classification, local sensing, honeypot behavior, defensive git ingestion, feedback tuning, accuracy tracking, counterfactuals, STIX export, ATT&CK export, migrations, and doctor checks are a lot for one release. That does not mean the direction is wrong. It means the next phase should be stabilization.

The strongest recommendation for the next release is to make v0.9.2 a stabilization release. Do not add another huge batch of features immediately. Focus on hardening, documentation consistency, end-to-end testing, usability, and release confidence. Verify every CLI command in the README and changelog. Add an end-to-end fixture workflow test. Update the README roadmap so it reflects the reality of v0.9.1. Add API-key authentication for non-loopback deployments. Add a release workflow for tags. Add a Docker smoke test. Add prediction calibration documentation. These improvements will make the project feel more mature and safer to adopt.

API security should be one of the first items addressed. The current security model treats unauthenticated API access as acceptable because the server binds to 127.0.0.1 by default and production use should sit behind a reverse proxy. That is reasonable for local-first development, but before enterprise or hosted deployment, built-in authentication should return. A simple optional API-key model would be enough for the next step. If GREYNOC_API_KEY is set, mutating routes should require an x-greynoc-api-key header. If the API binds to a non-loopback address, authentication should be required unless an explicit unsafe override is set. That would preserve local ease-of-use while giving operators a safer path for internal deployments.

The project should also add a safe deployment modes document. v0.9.1 has enough capability that users need clear operating modes. There should be an offline lab mode, local SOC workstation mode, internal server mode, sensor mode, honeypot mode, and ICS-aware passive inventory mode. Each mode should explain what it enables, what it never does, recommended bind address, required environment variables, safe defaults, and risks. This would reduce confusion and make the safety posture easier to understand.

The predictive engine should also use careful language. Forecasts are valuable, but they should not be oversold. GreyNOC should clearly state that forecasts are explainable prioritization aids, not guarantees. They should help rank review effort, not serve as the sole authority for action. That kind of honesty will make the engine more credible, not less.

Calibration history should become a first-class feature. The release already includes forecast accuracy tracking. The next step is to make that visible and useful. The engine should show forecast accuracy by horizon, by source type, by CVE/KEV status, by campaign, and by driver. It should identify overconfident drivers and underweighted drivers. It should show whether the model is improving over time. This could become a major differentiator because many products produce risk scores, but few products show whether those scores were historically reliable.

The doctor command is another strong feature that should be expanded. A strict mode would be valuable. doctor --strict should fail if the API is bound to a non-loopback address without authentication, if the honeypot external bind is enabled, if live fetching is enabled without host allowlists, if git clone sources are enabled without per-source allowlists, if migrations are pending, if forecast weights are not normalized, or if unsafe sensor settings are detected. This would give operators confidence before deployment.

Another important recommendation is to connect the new predictive layer with the earlier detection trust model. v0.9.1 is heavily predictive, OSINT, and network focused. That is good. But the earlier concepts of Detection Quality Passport, evidence-gated promotion, trusted export bundles, and Signal DNA should remain central. The next major product concept should combine these into what could be called a Threat Forecast Passport.

A Threat Forecast Passport would bring together the threat forecast, Signal DNA, detection coverage, Quality Passport summaries, local asset exposure, missing telemetry, and recommended actions. It would answer the questions SOC teams actually care about: How likely is this threat to matter? Why? Have we seen related signals before? Are we exposed? Do we have detections? Are those detections validated? What telemetry is missing? What should we do next?

That would make GreyNOC feel very different from ordinary SIEM rule generators. It would forecast risk, explain why, show detection coverage, prove detection quality, and recommend action.

Coverage-gap analysis should also become a priority. For each high-risk forecasted threat, the engine should answer: Do we have detections? Are they draft or validated? Which telemetry is required? Which telemetry do we not have? Which backend can receive the rule? What action closes the gap fastest? This turns prediction into operational value. It is not enough to say that something is risky. The engine should tell the defender how prepared they are and what to improve.

The release should also continue strengthening policy guardrails for sensor and honeypot features. A sensor_policy configuration file would be useful. It could include settings such as whether network discovery is allowed, whether external honeypot binding is allowed, whether ICS classification is enabled, maximum payload preview bytes, and whether payload redaction is required. Then doctor could verify that policy. This would make deployment safer and easier to audit.

For v1.0, the goal should not be “more features.” The goal should be a trusted predictive detection lifecycle. That means stable migrations, release automation, API authentication, strict doctor mode, safe deployment documentation, forecast calibration reports, coverage-gap analysis, Detection Quality Passport integration, validated export packs with trust metadata, and a clear Postgres roadmap or early Postgres backend.

The minimum v1.0 promise should be that GreyNOC can ingest external and local signals, enrich them, forecast risk, explain the drivers, identify detection coverage, test detections, validate detections with evidence, export trusted detection packages, and measure its own forecasting accuracy over time.

That is a strong product position.

The best next build is the Threat Forecast Passport. It should combine the new predictive engine with Signal DNA and detection quality. A single object should show the threat ID, forecast probability, horizon, confidence, named drivers, Signal DNA fingerprint, signal strength, detection coverage, validated detection count, draft detection count, best detection grade, missing telemetry, asset exposure, and recommended SOC actions.

That is the kind of feature that feels exclusive. It is not just another API endpoint. It is a defender workflow compressed into one trusted artifact.

In short, v0.9.1 is a major milestone. It moves GreyNOC Detector Engine from a promising defensive engine into a real predictive detection platform. The release has strong OSINT coverage, strong safety thinking, strong predictive ambition, and a clear path toward trusted detection intelligence. The next step is not to expand wildly. The next step is to stabilize, connect the strongest ideas, and make the trust model impossible to miss.

The future direction should be clear: GreyNOC should become the engine that tells defenders what matters next, why it matters, whether they are covered, and which detections are actually worth trusting.