CONTINUOUS DARK WEB & CREDENTIAL MONITORING
This is a standing monitoring/watch subscription on organizational and individual credentials, data exposures, and adversarial activity across dark-web forums, marketplace activity, and public credential-breach aggregators: it defines the watch criteria/tripwires, the collection and reporting cadence, the escalation routes, and the service levels under which we keep the client current over the term. It does NOT cover the one-off baseline credential audit that seeds the watch list (the Credentials & Access Inventory), nor any staffed operational security operations center (GSOC/watch-floor staffing → the staffed retained-service archetype). Prescriptive throughout: this is what we watch, how often, and what we do when a tripwire fires - not an analytic estimate of adversarial capability.
Document Control
| Field | Value |
|---|---|
| Service name | [ ] |
| DID | OSINT-060 |
| Organization / credential scope | [ ] |
| Client / sponsor | [ ] |
| Classification & handling | [e.g., classification + caveats + dissemination control] |
| Version | [ ] |
| Author / service owner | [ ] |
| Effective date | [ ] |
| Term / period of performance | [e.g., start–end, auto-renew terms] |
| Seeding product (baseline) | [e.g., reference to the baseline credential audit that establishes the watch list] |
Scope, Authorities & Limitations
State the authorized scope (which organizational/personal credentials, which lawful source lanes, which dark-web/public aggregator coverage zones), the engagement authority/consent basis, and what is explicitly out of scope; reproduce the verbatim caveats below; name the sibling products this service routes to.
This is a monitoring/operational service, not an investigation, a guarantee of detection, or legal advice. Collection is limited to lawful, authorized sources within the agreed scope; no unlawful access, intrusion, pretexting, or surveillance of non-consenting third parties is performed. Alerting is best-effort within the stated SLA and does not warrant prevention of any event.
| Boundary | Statement |
|---|---|
| In scope | [ ] |
| Out of scope | [ ] |
| Authority / consent basis | [ ] |
| Routes to (seeding product) | [e.g., Credentials & Access Inventory] |
| Routes to (incident response) | [e.g., response/remediation service or staffed incident-response sibling] |
1. Scope & Watch Criteria / Tripwires
Enumerate every watch item; per the load-bearing rule each row MUST bind a tripwire (the observable threshold that fires it), implicitly a cadence (§2), and an escalation route (§4). Risk-score each watch item with the L×I key reproduced in §4. No row may omit a tripwire or an escalation route.
| # | Watch item | Observable indicator | Tripwire threshold | Likelihood (1–5) | Impact (1–5) | L×I (1–25) | Severity tier | Escalation route (→ §4) |
|---|---|---|---|---|---|---|---|---|
| [ ] | [e.g., organizational credential exposure] | [e.g., domain/email credential, SSO account, API key] | [e.g., appearance in breach aggregator or dark-web marketplace] | [ ] | [ ] | [ ] | [ ] | [ ] |
| [ ] | [e.g., executive/key-personnel credential breach] | [e.g., named individual login, payment account, or privilege account] | [e.g., sale or leak on dark-web forum] | [ ] | [ ] | [ ] | [ ] | [ ] |
| [ ] | [e.g., third-party vendor credential exposure] | [e.g., contractor/supplier/partner account tie to organization] | [e.g., credential appearance in compromise dataset] | [ ] | [ ] | [ ] | [ ] | [ ] |
| [ ] | [e.g., adversarial activity / targeting intelligence] | [e.g., discussion of organization by name in threat forum] | [e.g., reconnaissance query, targeting discussion, or threat listing] | [ ] | [ ] | [ ] | [ ] | [ ] |
| [ ] | [e.g., data breach / corporate information exposure] | [e.g., proprietary data, source code, customer PII, financial records] | [e.g., posted offer or dump on dark-web marketplace] | [ ] | [ ] | [ ] | [ ] | [ ] |
2. Collection Cadence & Sources
Specify each lawful collection lane keyed to the watch items above, its method, its collection cadence, the expected source grade (Admiralty, see Annex A), and the owning collector. Free/browser-first lanes before escalation-tier platforms; no live tool names here - describe the lane.
| Source / lane | Watch item(s) served | Collection method | Cadence | Expected source grade (Admiralty) | Owner |
|---|---|---|---|---|---|
| [e.g., public credential-breach aggregator] | [ ] | [e.g., automated querying of public password/credential databases, email alerting] | [e.g., real-time / daily verification sweep] | [e.g., B–C / 2–3] | [ ] |
| [e.g., dark-web forum monitoring] | [ ] | [e.g., forum account access + automated keyword monitoring + human review] | [e.g., daily to weekly keyword sweep + human review on detection] | [e.g., C–D / 3–4] | [ ] |
| [e.g., dark-web marketplace monitoring] | [ ] | [e.g., automated listing monitoring + manual search by org indicator] | [e.g., continuous automated sweep + human verification on match] | [e.g., C–D / 2–3] | [ ] |
| [e.g., pastebin/public dump aggregators] | [ ] | [e.g., automated ingestion of public paste/dump feeds, keyword matching] | [e.g., real-time / hourly verification] | [e.g., B–C / 2–3] | [ ] |
| [e.g., social media / public-web credential recon] | [ ] | [e.g., open-source search engine, archive, and social-media public-profile scanning] | [e.g., weekly or monthly sweep per executive/credential set] | [e.g., A–B / 1–2] | [ ] |
3. Reporting Cadence & Product Format
Define each recurring product the service emits, what triggers it (scheduled cadence or tripwire-driven), its format, recipient, and delivery channel. Distinguish the routine cadence product from the on-tripwire alert product.
| Product | Trigger / cadence | Format | Recipient | Channel |
|---|---|---|---|---|
| [e.g., credential exposure alert] | [e.g., on tripwire fire per §1 row(s)] | [e.g., structured alert: credential type, source, confidence, remediation directive, DID link] | [ ] | [e.g., encrypted email / secure channel] |
| [e.g., weekly summary] | [e.g., every [ ] at [ ] time] | [e.g., summary of watch-item activity, exposures, false positives, recommendations] | [ ] | [e.g., encrypted email / secure channel] |
| [e.g., monthly service-health and recommendation report] | [e.g., first [ ] of month] | [e.g., monitoring coverage status, SLA compliance, credential-hygiene recommendations, darknet activity summary] | [ ] | [e.g., encrypted email / secure portal] |
4. Escalation & Notification Triggers
Map severity tiers to trigger conditions, the party notified, the notification method, and the acknowledgement target. Each tier must correspond to severity bands derived from the L×I key below; every §1 watch item routes to a tier here.
Risk scoring key (reproduce verbatim): Likelihood (1–5) × Impact (1–5) = 1–25; 1–5 Low · 6–10 Moderate · 11–15 Elevated · 16–20 High · 21–25 Critical.
| Severity tier | L×I band | Trigger condition | Notify | Method | Acknowledgement target |
|---|---|---|---|---|---|
| [e.g., Critical] | [e.g., 21–25] | [e.g., C-suite or privileged account exposed; active targeting/threat intel; large data dump] | [ ] | [e.g., phone call + encrypted email + secure slack] | [e.g., 15-minute acknowledgement] |
| [e.g., High] | [e.g., 16–20] | [e.g., executive account breach; breach dataset containing significant PII; active forum discussion] | [ ] | [e.g., encrypted email + phone within 1 hour] | [e.g., 1-hour acknowledgement] |
| [e.g., Elevated] | [e.g., 11–15] | [e.g., non-executive staff account breach; third-party vendor credential exposure; reconnaissance activity] | [ ] | [e.g., encrypted email + follow-up call within 4 hours] | [e.g., 4-hour acknowledgement] |
| [e.g., Moderate/Low] | [e.g., 1–10] | [e.g., low-confidence possible match; historical breach re-surfacing; minor vendor account] | [ ] | [e.g., email summary in next batch report] | [e.g., next scheduled report cycle] |
5. Service Levels (SLA)
Bind measurable service-level commitments to the cadence (§2/§3) and escalation timing (§4): detection/refresh timeliness, alert-delivery time per tier, product-delivery punctuality, availability, and the remedy when a target is missed. Every target must be measurable and have a measurement method.
| Metric | Target | Measurement method | Reported | Remedy / credit on miss |
|---|---|---|---|---|
| [e.g., credential detection latency] | [ ] | [e.g., time from appearance in source to alert fired, measured per source lane] | [e.g., monthly SLA report] | [ ] |
| [e.g., alert-delivery time by tier] | [e.g., Critical ≤15 min / High ≤1 hr / Elevated ≤4 hr] | [e.g., timestamp of alert sent vs. tripwire timestamp] | [e.g., monthly SLA report + exception log] | [ ] |
| [e.g., routine product punctuality] | [ ] | [e.g., on-time delivery of weekly summary and monthly report] | [e.g., monthly SLA report] | [ ] |
| [e.g., monitoring availability / coverage]] | [e.g., ≥98% collection-lane uptime per month] | [e.g., lane status logs and outage tracking] | [e.g., monthly SLA report] | [ ] |
| [e.g., false-positive / quality bound] | [e.g., ≤5% false-positive rate per 100 alerts] | [e.g., monthly manual audit of top sources and trends] | [e.g., monthly SLA report + improvement plan] | [ ] |
6. Review & Renewal
State the cadence of formal service review, the change-control process for adding/removing watch items or adjusting cadence, and the renewal, re-scoping, and termination terms.
| Item | Specification |
|---|---|
| Service-review cadence | [ ] |
| Watch-list change-control | [e.g., process to add/retire a §1 watch item; 5-business-day notice for credential/credential-set addition] |
| Cadence / scope adjustment process | [ ] |
| Renewal terms | [ ] |
| Termination / offboarding terms | [ ] |
Annex A - Source & Watch-List Register (graded)
Register every standing source and watch item with its current Admiralty grade. Reproduce the scales verbatim; grade each sourced datum as a two-character code (e.g., B2).
NATO Admiralty source reliability (A–F): A Completely reliable · B Usually reliable · C Fairly reliable · D Not usually reliable · E Unreliable · F Reliability cannot be judged. NATO Admiralty information credibility (1–6): 1 Confirmed by other sources · 2 Probably true · 3 Possibly true · 4 Doubtful · 5 Improbable · 6 Truth cannot be judged.
| Source / watch item | Lane (→ §2) | Reliability (A–F) | Credibility (1–6) | Grade | Last verified | Notes |
|---|---|---|---|---|---|---|
| [e.g., Have I Been Pwned (public aggregator)] | [e.g., public credential-breach aggregator] | [e.g., A] | [e.g., 1] | [e.g., A1] | [ ] | [e.g., verified legitimate breach feed, high coverage] |
| [e.g., organizational email domain in marketplace listing] | [e.g., dark-web marketplace monitoring] | [e.g., C] | [e.g., 3] | [e.g., C3] | [ ] | [e.g., unconfirmed seller reputation] |
| [ ] | [ ] | [ ] | [ ] | [ ] | [ ] | [ ] |
Annex B - Onboarding / Offboarding & Data-Handling Checklist
Capture the standing-up and tearing-down steps and the data-handling regime over the term: authorization capture, baseline ingest, collection standup, retention/destruction, and offboarding.
| Step | Phase | Owner | Status |
|---|---|---|---|
| [e.g., capture authority/consent + scope sign-off] | [e.g., onboarding] | [ ] | [ ] |
| [e.g., ingest seeding baseline (credential audit)] | [e.g., onboarding] | [ ] | [ ] |
| [e.g., stand up collection lanes + credential watch triggers] | [e.g., onboarding] | [ ] | [ ] |
| [e.g., configure alerting channels + escalation matrix]] | [e.g., onboarding] | [ ] | [ ] |
| [e.g., data retention / destruction schedule (credential data, alerts)]] | [e.g., steady-state] | [ ] | [ ] |
| [e.g., offboarding + data return/purge]] | [e.g., offboarding] | [ ] | [ ] |
END OF SERVICE PLAYBOOK
Model wiring
Generated from cell frontmatter at publish time.
- Inputs: OSINT-058