Threat Intelligence — Digital Brand Protection
The governance layer of brand protection. This is where the organization declares what needs to be watched and where — seven independent fronts, each with its own registered sources — and it is that registry that steers the collection carried out by the detection modules.
Overview
The seven fronts are Domain Intelligence, Network Intelligence, Phishing Monitor, Brand Monitor, Fake Apps, Social Network and Fraud Intelligence. They can be licensed together or separately, and they share the same model: each record is a source or a surveillance target, with a name, URL, type, sector, owner, description and — when the source requires authentication — the access credentials.
Splitting them into seven is not cosmetic. It exists because the fronts have different owners inside the customer’s organization — whoever handles fake apps in the stores is rarely whoever handles IP ranges — and because licensing is per front, which lets a customer start with one and grow.
How It Works Underneath
Source credentials are never stored in the clear. The URL, e-mail, password and description of every record are written to encrypted fields. The source password is the most sensitive piece of data in the module: it is what grants access to a closed forum, a marketplace panel or a surveillance account. It is written encrypted and read encrypted.
Fail-closed multi-tenant scoping. The seven fronts use sequential primary keys, which is an open invitation to enumeration by URL. Every read by identifier goes through the same organization filter, including on the detail, edit and delete screens — not just on the listing. If the user’s organization cannot be resolved, the query returns empty, never everything. The filter also excludes already-deleted records, so that an old identifier cannot resurrect a record through the URL.
Deletion is reversible and audited. Deleting marks the record as removed; it disappears from the interface but remains in the database for auditing. Four signals are emitted and consumed by the audit trail: creation, activation or deactivation, soft delete and hard delete — the last one being rare, and designed to be noticed.
Counts in a single query. Each front’s landing screen shows total, active, inactive and created-in-the-last-seven-days in one aggregation, rather than four sequential counts.
The Brand Asset Dictionary
Attached to this module is a registry of everything the organization wants to protect: 41 categories across ten groups.
| Group | Example categories |
|---|---|
| Identity and Brand | keywords, brand names, registered terms, product names, whitelist |
| Digital Infrastructure | domains, subdomains, URLs, IPs, network ranges, ASNs |
| Mobile | package names, store IDs, iOS bundle IDs |
| Financial | BINs, card patterns, account patterns, payment gateways |
| People (VIPs) | executives, employees, board members, job titles |
| Contact | e-mail addresses, e-mail domains, phone numbers, forms |
| Social Networks | handles, URLs, IDs, YouTube channels, LinkedIn company IDs |
| Documents | MD5 and SHA256 hashes, document titles, SSL certificates |
| Legal | CNPJ and equivalent company IDs, registration numbers, licenses |
| Geolocation | addresses, offices, regions |
Each category has its own per-organization limit, set in the contract. It is this dictionary that feeds the terms used by monitors and the scope of perimeters — instead of every module keeping its own list of “what is ours”, there is a single list.
The same registry also holds the organization’s takedown quota: monthly total, how it is counted, limited carryover of unused balance, priority and the option of automatic approval.
Use Cases
- Centralize, in one place, everything the organization considers its own: brands, domains, executives, BINs, app packages
- Register the surveillance sources for each front without scattering credentials across spreadsheets
- Separate responsibility by front, with a named sector and owner on every record
- Prove, at audit time, who created, activated, deactivated or removed each surveillance front, and when
What the Module Does Not Do
This module is registry and governance, not a detection engine. Specifically:
- It does not enrich indicators automatically. WHOIS, DNS, SSL, ASN and abuse contacts are gathered during the takedown workflow, in Legal & Takedown.
- It does not assign a 0-100 risk score. Exposure scoring belongs to the EASM module, and there it is a sum of open findings.
- It does not correlate automatically across the seven fronts.
- It does not query MISP, OpenCTI, VirusTotal or Google Safe Browsing from inside this module. MISP synchronization is its own module (MISP Sync); reputation lookups live among the Threat Monitoring sources.
- PDF export per front is not implemented yet and returns a notice, not a file.
- It keeps no TLD inventory and does not crawl domain registries on its own — typosquatting is detected in EASM.
Integrations
- Field-level encryption at rest and the platform audit trail (OODA Audit)
- OODA Threat Monitoring (consumes the asset dictionary), OODA EASM (perimeters) and Legal & Takedown (quota and case initiation)
SLA & Guarantees
Source credentials encrypted at rest · fail-closed scoping per organization · deletion reversible and audited