The OSINT Framework: Turning Public Data Into Defensible Intelligence

Most security teams already do OSINT. Few of them do it as a framework.

Someone gets a suspicious domain in a phishing report, pastes it into a whois lookup, checks VirusTotal, maybe runs a quick search on the sender's name, and moves on. That is reconnaissance, and it has value, but it is not intelligence. It is not repeatable, it is not documented, and six months later nobody can reconstruct how the conclusion was reached.

An OSINT framework is what closes that gap. This post covers what the term actually means, the process model that holds it together, the collection domains you need coverage across, and how open-source intelligence gets operationalized inside a SOC rather than living in a browser tab.

Two things people mean by "OSINT framework"

The phrase gets used two ways, and conflating them is the first mistake teams make.

The directory. OSINTFramework.com and similar resources (Bellingcat's Online Investigation Toolkit, the various annual OSINT landscape maps) are categorized link trees. They are useful for discovery: you need a username enumerator, you open the tree, you find five. What they are not is a methodology. A directory tells you what exists. It does not tell you what to collect, in what order, or how to judge whether what you found is true.

The process. This is the framework that matters. It is the discipline that governs how your organization defines an intelligence requirement, collects against it, validates it, analyzes it, and delivers it to someone who will act on it. Tools are interchangeable. Process is not.

Tool churn makes this point for itself. Free tools go paid, platforms close their APIs, projects get acquired and folded into enterprise suites. Anyone who built their capability around a specific tool has had to rebuild it more than once. Teams who built around a process just swapped a component.

The process layer: an intelligence cycle that fits OSINT

The classic intelligence cycle adapts cleanly to open sources. Five phases, and the ones teams skip are always the first and the last.

Direction. Every collection effort starts with a stated requirement, written down. "Find everything about Acme Corp" is not a requirement. "Identify externally exposed Acme assets that authenticate against our shared SSO tenant" is. A good requirement names the decision it supports, the consumer of the answer, and the deadline. If you cannot name who acts on the output, do not start collecting.
Collection. Gathering against the requirement, across the domains covered in the next section. The discipline here is scope: collect what the requirement asks for, log where each item came from, and stop. Unbounded collection is how investigations blow a week and produce nothing.
Processing. Raw collection is messy. Normalize it, deduplicate it, translate it, extract entities, and get it into a structure your analysts can work with. This is the phase most teams underinvest in, and it is where automation pays back the fastest.
Analysis. Turning data into a judgment. This means applying structured techniques (analysis of competing hypotheses, key assumptions checks), assigning confidence levels, and being explicit about what you do not know. An OSINT product without a stated confidence level is an opinion with citations.
Dissemination and feedback. Get it to the consumer in the format they can use, then find out whether it helped. Feedback loops back into direction. A cycle that never closes is a straight line.

The collection layer: five domains

Coverage matters more than tool count. Each domain answers a different question, and a gap in one domain is a gap in the picture.

Infrastructure and attack surface. What does the target look like from outside? Passive DNS, certificate transparency logs, subdomain enumeration, ASN and netblock mapping, exposed service discovery. Amass, theHarvester, Shodan, Censys, crt.sh. For defensive work this is your own external footprint, and running it against yourself on a schedule is one of the highest-value recurring OSINT tasks there is.
Identity and persona. Usernames, email addresses, account correlation across platforms. Sherlock, Maigret, WhatsMyName, Blackbird, Hunter.io. Defensively, this maps your organization's public human attack surface, which is to say your phishing target list.
Breach and credential exposure. Have I Been Pwned, DeHashed, IntelX, stealer log aggregators. This domain has grown into its own discipline, particularly infostealer log monitoring, which surfaces live session cookies and corporate credentials that predate any breach disclosure.
Corporate and public record. Registrations, filings, ownership structures, court records, procurement data, sanctions and PEP lists. SEC EDGAR, OpenCorporates, national company registries. Slower and less glamorous than infrastructure work, and frequently the thing that turns three disconnected findings into one attributed entity.
Geospatial and media. Image and video verification, reverse image search, EXIF analysis, satellite and street-level imagery, chronolocation. Increasingly supported by AI-assisted geolocation tooling, which has moved this from specialist work to something a trained generalist can do.

Cutting across all five: content authenticity. Synthetic media and AI-generated personas have made source verification a first-class collection problem rather than an afterthought. Assume any single artifact could be fabricated. Corroborate across independent sources before it enters a product.

Analyst OPSEC is part of the framework

Collection leaves traces. If your OPSEC is weak, your investigation becomes a notification to the target that they are under investigation.

Baseline practices:

Research infrastructure separated from corporate infrastructure. A dedicated VM or cloud workstation, not the laptop with your SSO session on it.
Attribution management. Egress that does not resolve to your employer's netblock.
Managed research personas where platform access requires an account, created and aged deliberately, never linked to a real identity or a corporate email.
Passive first. Certificate transparency and passive DNS do not touch the target. Direct scanning and probing do, and require authorization.
Browser isolation and separate profiles. Cross-contamination between a research persona and a personal session is the most common failure mode.

Document your OPSEC posture the same way you document collection. If an investigation ends up supporting a legal action, how you collected will be examined as closely as what you collected.

Legal and ethical guardrails

"Publicly available" and "lawfully collectible" are not the same category, and the gap between them is where organizations get hurt.

Three lines worth writing into policy:

Scope to entities, not individuals. Investigating an organization's exposed infrastructure is routine security hygiene. Compiling a dossier on a private individual is a different activity with different legal exposure, and it needs explicit authorization and a documented purpose.
Passive means passive. Reading public records is collection. Logging into a system, probing a service, or accessing data behind an authentication boundary is not OSINT regardless of how weak the boundary was.
Data protection applies. Personal data collected from public sources is still personal data under GDPR and comparable regimes. You need a lawful basis, a retention limit, and a deletion process. Regulatory attention on AI-assisted investigation is increasing, and where AI sits in your workflow you should expect to explain and evidence how it reached its output.

Write these into an OSINT policy, get it reviewed by counsel, and make analyst training a prerequisite for access. The framework is not just technical.

Making OSINT operational

OSINT that stays in an analyst's notes is a hobby. The value shows up when it feeds systems that act.

Enrichment. Wire OSINT sources into your SIEM enrichment pipeline so that when a detection fires on an external IP or domain, the analyst gets registration age, hosting provider, certificate history, and reputation context in the alert rather than in a separate tab. Ten seconds of automated enrichment routinely saves ten minutes of manual triage.
Detection content. OSINT findings become detections. A newly registered lookalike domain becomes a proxy log detection. A credential set found in a stealer log becomes a watchlist and a targeted authentication anomaly rule. Exposed assets discovered in your own footprint become monitoring scope.
Automated collection. Recurring requirements belong in a SOAR playbook, not in a human's calendar. Daily certificate transparency monitoring for lookalike domains, weekly external footprint diff, continuous breach monitoring for corporate domains. Human analysts should be doing analysis, not running the same three commands every morning.
Risk scoring. In a risk-based alerting model, OSINT context is a legitimate risk contributor. An authentication from an IP with adverse open-source context is not the same event as one from a clean residential address, and your scoring should reflect that.

The failure modes

Five patterns worth naming, because they recur:

Collection without requirement. Analysts collect because a tool produces output, not because someone needs an answer.
Tool worship. Buying a platform and calling it a capability. The platform will change. The process is what you own.
Single-source conclusions. One breach database hit, one social account match, and a name goes into a report. Corroborate or caveat.
No confidence language. Products that state findings flatly, with no distinction between what is confirmed and what is assessed.
No feedback loop. Nobody asks whether the last twenty products changed a single decision. Some of them did not, and those requirements should be retired.

Where to start

If you are standing this up from zero, sequence it like this.

First 30 days. Write three intelligence requirements tied to real decisions your organization makes. Run your external footprint against yourself and document the result. Stand up isolated research infrastructure.
Next 30. Draft the OSINT policy and get it reviewed. Build a reporting template with mandatory confidence language and source citation. Train analysts on at least one structured analytic technique.
Next 30. Automate the recurring collection. Wire two OSINT enrichment sources into your SIEM. Run the feedback review on everything produced so far and cut what nobody used.

Ninety days gets you from ad hoc lookups to a capability. The tooling will keep changing underneath it. The framework is what stays.

SecTower helps security teams build intelligence capability that survives tool churn, from requirement definition through SIEM integration and detection engineering. Get in touch to talk through your OSINT program.