A multi-tenant B2B SaaS platform serving approximately 4,000 enterprise customers engaged BlackNeuron for a DDoS resilience validation following an extortion-driven incident affecting a peer SaaS provider. The platform's customer agreements included availability SLAs with material credit obligations for missed targets; sustained DDoS pressure threatening SLA compliance would create both operational and contractual cost. The validation needed to confirm resilience across three distinct architectural surfaces: the customer-facing web application, the public API used by customer-side integrations, and the multi-tenant data plane where customer isolation is enforced.
The validation employed BlackNeuron's simultaneous multi-vector approach, in which L3, L4, and L7 adversarial traffic is generated concurrently against the same infrastructure with the attack engine adjusting vectors adaptively. The methodology was selected because SaaS adversarial profiles increasingly target the architectural assumption of customer isolation — attacks directed at one tenant's traffic that affect adjacent tenants represent a defensive failure even when no specific tenant's traffic is fully unavailable. Sequential single-vector testing does not exercise the cross-tenant resilience properties that define the platform's customer-isolation guarantee.
The threat profile
B2B SaaS DDoS pressure has specific operational characteristics distinct from consumer-facing services. Adversary motivation includes ransomware-precursor pressure (forcing a customer or the SaaS provider to negotiate), competitive harassment (a competitor sponsoring DDoS-for-hire campaigns against a vendor), and disgruntled-departed-employee retaliation. Attack patterns frequently target specific customers' tenant infrastructure rather than the SaaS provider broadly — the SaaS provider's challenge is to absorb the attack while preserving adjacent tenants' service.
The public API is a particular concern. SaaS APIs are accessed by customer-side automation, integration partners, and embedded clients in customer products. Aggressive rate limiting against adversarial API traffic creates collateral damage on legitimate customer integrations that may operate at varying request volumes across customers. The defensive boundary needs to identify adversarial patterns at granularity finer than per-customer rate limits — distinguishing a customer's burst of legitimate integration traffic from a tenant-targeted attack.
A third concern: multi-tenant data-plane architecture means certain operations are shared across tenants (database connection pools, cache infrastructure, asynchronous job queues). Adversarial pressure that exhausts a shared resource affects every tenant. The defensive properties of tenant isolation depend on resource-management architectures that the customer-facing presentation does not surface.
Engagement structure
The validation was structured over seven weeks. Three testing windows progressively escalated attack profile sophistication, with each combining adversarial pressure against simulated tenant infrastructure with legitimate-tenant traffic across other tenants in the multi-tenant data plane. The legitimate-traffic simulation included realistic patterns: customer-side automation cycles, integration-partner request patterns, and embedded-client behaviors across multiple tenants concurrent with the adversarial pressure against the target tenant.
The adaptive testing engine adjusted attack vectors based on defensive engagement: when per-tenant rate limits engaged on API traffic, the engine shifted to lower-rate-per-tenant patterns combined with cross-tenant enumeration; when application-layer rate limits caught flood patterns, the engine pivoted to slow-attack family vectors against connection-state resources. The pattern shifts replicated the conditions of an actual targeted-tenant attack campaign rather than the artificially clean conditions of single-vector testing.
Attack vectors exercised
L3 volumetric against the platform's public IP space at peak 40 Gbps multi-source. CDN-based anycast absorbed the volumetric component. Origin-side metrics showed no anomalous patterns. Validation confirmed the edge tier's contribution.
L7 HTTP flood against the customer-portal login endpoint at sustained 3,500 RPS distributed across 9,000 source IPs, with the target identified as a specific high-value customer's tenant domain. The platform's per-tenant rate limit (200 RPM per IP per tenant) engaged correctly for the target tenant. The simultaneous legitimate-tenant traffic simulation revealed the cross-tenant impact: shared application-server resources — specifically the connection pool to the shared authentication database — were proportionally consumed by the attack volume, increasing authentication latency for legitimate users of other tenants by approximately 35% during peak attack volume.
API endpoint pressure against the platform's public API at sustained 6,000 RPS targeting a specific tenant's API surface. The per-tenant API rate limit (500 RPS per tenant for the highest-tier plan) engaged correctly. The finding emerged at the integration layer: legitimate integration partners for OTHER tenants were affected by the shared API gateway's per-second processing capacity, with elevated latency observed across all tenants' API consumers during the attack window.
Application-logic abuse against the platform's bulk-export endpoint. The endpoint generated CSV exports of customer data on demand, with each export consuming significant CPU and producing files in shared object storage. Sustained 200 RPS of export requests against the target tenant exhausted the shared export-worker pool within eight minutes. Adjacent tenants attempting legitimate exports during the attack window experienced extended queue waits — observable as customer-facing latency on a feature used by every tenant.
Slow-attack family against the platform's load balancer with 4,000 Slowloris connections. The load balancer's connection-pool capacity was approached but not exhausted within the testing window. Configured connection-pool capacity was adequate; the architectural reserve was confirmed.
Credential-stuffing patterns against the customer-portal authentication endpoint with distributed attempts across many tenant accounts. The platform's per-account lockout policy engaged correctly. The cross-tenant impact emerged at the shared authentication-event-logging infrastructure, where the volume of failed-authentication events from the attack consumed the log-ingestion budget allocated to authentication telemetry — temporarily reducing observability for security event detection across all tenants.
Findings
Six findings, prioritized by customer-SLA impact and platform-architectural significance:
-
Shared-resource cross-tenant impact. Per-tenant rate limits engaged correctly, but adversarial pressure on one tenant proportionally consumed shared application-server resources, affecting adjacent tenants' performance. The architecture's tenant-isolation guarantee held for service availability but degraded for service quality during sustained adversarial pressure.
-
API gateway throughput as shared constraint. Per-tenant API rate limits did not protect against shared API-gateway capacity exhaustion. The binding constraint was upstream of per-tenant enforcement.
-
Bulk-export worker pool exhaustion. The shared export-worker pool was a single point of cross-tenant impact. A single adversarial actor could disproportionately consume the resource.
-
Authentication telemetry log-ingestion budget. Shared log-ingestion budget for security events was exhausted under attack-volume failed-auth events, reducing observability for security event detection during the conditions in which observability matters most.
-
Tenant-isolation observability gap. The platform's existing observability stack did not provide per-tenant resource consumption visibility at the granularity required to surface cross-tenant impact patterns. The cross-tenant findings were observed via the validation engagement's instrumentation, not via the platform's existing visibility.
-
SLA reporting under partial-degradation conditions. Side finding: the platform's automated SLA reporting calculated availability at the tenant level but did not characterize service-quality degradation. Customers experiencing 35% authentication latency increase during the attack window would not have shown SLA violations even though service quality was materially degraded.
Remediation
Per-tenant resource budgets were extended beyond rate limits to include shared-resource consumption ceilings (connection-pool usage per tenant, export-worker capacity per tenant, log-ingestion budget per tenant). The API gateway was reconfigured with per-tenant processing-capacity reservation in addition to rate-limit enforcement. The bulk-export worker pool was redesigned with per-tenant scheduling priority and explicit per-tenant queue capacity. Authentication telemetry log-ingestion was given dedicated capacity allocation independent of tenant-specific budgets. Per-tenant observability instrumentation was added across the shared resource tiers. SLA reporting was expanded to include service-quality metrics alongside availability metrics.
Outcome
The platform absorbed the simulated 40 Gbps multi-vector attack against a target tenant without customer-visible availability impact and without observable cross-tenant degradation that would have triggered SLA credit obligations. The validation produced documented evidence of tenant-isolation properties under adversarial conditions, supporting both customer-relationship discussions and customer-procurement-process security documentation. The platform's tenant-isolation guarantee now extends beyond service availability to include service quality at the granularity that customer experience requires.
The instructive part
Multi-tenant SaaS DDoS resilience surfaces a defensive property that single-tenant architectures do not face: cross-tenant impact under tenant-targeted adversarial pressure. Per-tenant rate limits protect the targeted tenant but do not, by themselves, prevent cross-tenant resource consumption. Adjacent tenants experience service-quality degradation indistinguishable from a service incident from their perspective, even when the platform's metrics report nominal availability. The defensive boundary required for multi-tenant SaaS is more demanding than per-tenant rate limiting — it requires shared-resource budget enforcement at granularity that surfaces and constrains cross-tenant impact patterns. The discipline of validation must exercise the conditions under which cross-tenant impact would emerge in production, not the conditions of single-tenant attack profiles that the architecture's documented guarantees would handle cleanly.