Building a Collection Plan for Credential-Stuffing Intelligence
You lead CTI for an online retailer with 4 million customer accounts. Credential stuffing is the top business risk: last quarter 12,000 account-takeover attempts succeeded. The CISO approves one new paid source for a 12-month pilot, maximum $60,000. Current sources are free AlienVault OTX, a $15,000/year commercial IOC feed, and the internal SIEM. Vendor A offers dark-web credential-dump monitoring with 48-hour latency and fuzzy matching; its sample data includes cleartext passwords and customer PII. Vendor B offers brand and domain monitoring with API access and a 24-hour SLA, but no credential data. Legal says you cannot ingest unsanctioned PII, GDPR applies, and the team has three analysts. You also want paste-site mentions without scraping, and the SOC wants indicators in the SIEM within 15 minutes.
1. Define collection requirements and prioritize the two vendors against them.
Read the worked answer
Translate business risk into collection requirements: R1 credential dumps mentioning company domains or brands; R2 paste-site posts containing customer email domains; R3 brand and domain impersonation used for phishing; R4 account-takeover infrastructure such as proxy and phishing kits. Score each vendor on requirement coverage, latency, legal risk, and integration effort. Vendor A directly addresses R1, the top risk, but carries PII and GDPR exposure and 48-hour latency. Vendor B addresses R3 but not credential stuffing. If only one can be funded, negotiate Vendor A with data minimization: domain-only or hashed matches, no cleartext passwords, a data processing agreement, retention limits, and access controls. Add Vendor B only if budget or scope allows. Document the collection plan with source, requirement, priority, frequency, and owner.
2. How would you apply source reliability ratings and legal review before ingestion?
Read the worked answer
Use the Admiralty code: rate source reliability A-F and information credibility 1-6. Vendor A might be B2 for the existence of a dump but C3 for attribution; OTX is often C3; internal SIEM is A1 for observed events. Reliability rating is not a substitute for legal review. Before ingestion, require a lawful basis, data minimization, retention schedule, access control, and a segregated store for any PII. Do not place unsanctioned cleartext credentials into the SIEM. Hash or tokenize identifiers where possible. Paste-site collection should use an approved API or feed, not scraping, and should respect terms of service and privacy law.
3. What collection methods and deconfliction would you specify?
Read the worked answer
Specify API pulls from the vendor, STIX/TAXII if supported, DNS and authentication logs, and SIEM matching against hashed or domain-level identifiers. Assign source IDs and provenance tags to every indicator. Deduplicate by indicator and track sightings. Define a 15-minute SLA through an automated pipeline and test it with a sample. Document the legal approval and data flow. Deconflict with the fraud team so both teams do not open duplicate investigations. Report metrics: time from dump publication to detection, match rate, false positives, and legal exceptions.