A vulnerability researcher discovered that Salesforce and ServiceNow portals remained exposed for 17 months before detection. During that time, attackers exploited a Metabase zero-day to access customer data through these misconfigured instances. No one noticed until external researchers flagged it.
This isn't a failure of technology. It's a failure of process.
Timeline
Although exact dates aren't provided, the exposure lasted 17 months. Here's what that timeline reveals:
- Month 0: Portals were misconfigured or left insecure.
- Months 1-16: No automated alerts triggered; no manual audits caught the exposure.
- Month 17: External researchers discovered and reported the vulnerability.
- Post-discovery: Organizations scrambled to assess data access and notify affected customers.
The Metabase zero-day exploitation occurred during this exposure window, turning a configuration problem into an active data breach.
Which Controls Failed
1. Asset Inventory and Classification
These portals were deployed without being documented in the organization's asset inventory. You can't monitor what you don't know exists. NIST CSF v2.0 function "Identify" requires maintaining accurate inventories of information systems. These portals should have been tagged as external-facing assets handling customer data, the highest risk category.
2. Continuous Monitoring
No automated scanning caught the misconfiguration for 17 months. Your vulnerability scanners should run weekly at minimum against all external assets. These weren't just missed once, they were missed 68 times if you're scanning weekly, 17 times if monthly.
ISO/IEC 27001 Control 8.8 (Management of technical vulnerabilities) requires organizations to obtain timely information about technical vulnerabilities and evaluate exposure. Seventeen months isn't timely.
3. Configuration Management
The portals were misconfigured from deployment or drifted into an insecure state. Either scenario indicates missing configuration baselines and drift detection. PCI DSS v4.0.1 Requirement 2.2.1 demands that configuration standards be defined and implemented for all system components. These portals violated that baseline, and no one caught it.
4. Patch Management
The Metabase zero-day represents a separate failure, but it compounded the portal exposure. When the vulnerability became public, affected organizations had no process to identify which systems ran Metabase or to prioritize patching based on exposure risk.
PCI DSS v4.0.1 Requirement 6.3.1 requires security vulnerabilities to be identified and addressed within defined timeframes based on risk. Zero-days demand immediate response, hours, not days.
5. Access Logging and Review
For 17 months, someone should have been reviewing access logs for these portals. Unusual patterns, unauthorized access attempts, or data exfiltration indicators should trigger alerts. SOC 2 Type II Common Criteria CC7.2 requires monitoring of the system and analysis of system activity.
No alerts fired. No one reviewed the logs manually. The monitoring gap was total.
What the Standards Require
Let's map these failures to specific requirements you're already supposed to meet:
NIST 800-53 Rev 5 SI-4 (System Monitoring): Organizations must monitor information systems to detect attacks and indicators of potential attacks. The control explicitly calls for automated tools and real-time analysis. These portals had neither.
ISO/IEC 27001 Control 8.16 (Monitoring activities): Networks, systems, and applications must be monitored for anomalous behavior. The 17-month gap violates this completely.
PCI DSS v4.0.1 Requirement 10.4.1: Audit logs must be reviewed at least once daily. If these portals processed payment data (likely, given Salesforce and ServiceNow use cases), daily log review would have caught unauthorized access within 24 hours, not 17 months.
NIST CSF v2.0 DE.CM-1 (Detect Continuous Monitoring): Networks and network services are monitored to find potentially adverse events. This is a core detection function, it's not optional.
Lessons and Action Items
Here's what you need to do this quarter:
1. Audit Your External Attack Surface
Run an external discovery scan this week. Use tools like Shodan, Censys, or your cloud provider's asset inventory to find everything exposed to the internet. Compare that list to your CMDB. Any discrepancy is a control failure.
Action: Schedule quarterly external discovery scans. Assign an owner to reconcile findings with your asset inventory within 48 hours.
2. Implement Automated Configuration Monitoring
Deploy configuration drift detection on all external-facing assets. Tools like AWS Config, Azure Policy, or open-source options like OpenSCAP can alert you when configurations deviate from your baseline.
Action: Define configuration baselines for your top 10 external assets this month. Enable automated drift alerts next month.
3. Fix Your Vulnerability Management SLA
If you're scanning monthly, you're missing too much. Move to weekly scans for external assets, daily for critical systems. Your SLA for critical vulnerabilities should be measured in hours, not days.
Action: Update your vulnerability management policy. Set a 24-hour remediation window for critical external vulnerabilities, 7 days for high-severity issues.
4. Enable Real-Time Alerting on External Assets
Your SIEM should have rules for unusual access patterns on external portals: login failures, new user registrations, data export operations, API calls from unexpected geolocations. If you don't have these rules, you're blind.
Action: Create detection rules for your top 5 external applications. Test them by simulating suspicious activity. Tune thresholds until false positives drop below 5 per day.
5. Conduct Tabletop Exercises for Zero-Day Response
When the next zero-day drops, you need to identify affected systems within one hour and begin remediation within four hours. That requires automation and a rehearsed playbook.
Action: Document your zero-day response process. Include asset queries, communication templates, and rollback procedures. Run a tabletop exercise next quarter.
Seventeen months is inexcusable. Your board will ask why you didn't catch it. "We scan quarterly" won't satisfy them. Start closing these gaps now, before external researchers find your exposed portals.
