SC-6: Resource Availability

Quick-reference card

What this control requires

SC-06 requires you to protect the availability of system resources by enforcing priority-based allocation, quotas, or equivalent controls that prevent any single process or user from monopolizing CPU, memory, disk I/O, or network bandwidth. Without these guardrails, a single runaway process or malicious workload can starve every other application sharing the same host.

In practice, this control means defining which resources matter most to your organization, then configuring the operating system, hypervisor, or orchestration platform to enforce hard limits. You need to decide which processes receive priority scheduling, which users or services are subject to quotas, and what happens when a threshold is exceeded. The goal isn’t just fair sharing; it’s ensuring that mission-critical workloads continue running even when something unexpected consumes disproportionate capacity.

The requirement, part of the System and Communications Protection family, also extends beyond individual hosts. In environments with shared infrastructure, such as multi-tenant cloud deployments or clustered application servers, resource allocation controls are what separate predictable performance from cascading failures. Organizations that skip this step often discover the gap only after an outage, when forensic analysis reveals that a non-essential background task consumed resources that should have been reserved for production systems.

Why it matters

Most organizations don’t discover that they lack resource allocation controls until a performance incident forces the question. The absence of quotas and priority scheduling creates a system where any sufficiently resource-intensive process can crowd out legitimate workloads without triggering a single alert. This gap is a precondition for a wide range of availability attacks, and it’s one that attackers actively exploit.

Cryptomining resource exhaustion with macOS resource fork hiding

Without resource allocation controls and process quotas, a single application, user session, or malicious process can consume disproportionate system resources and degrade or deny service to other processes sharing the same host. In a common pattern, cryptomining malware installed on a compromised workstation or server runs as a background process that consumes significant CPU capacity. Because no quota exists, the operating system doesn’t throttle the miner, and mission-critical application processes compete directly for the same resources. The initial symptom is performance degradation that teams often attribute to hardware aging, application bugs, or network congestion before identifying the malicious process.

The T1564.009 (Resource Forking) technique compounds this risk in macOS environments specifically. Attackers use the extended attributes (resource fork) of a file to conceal a malicious executable that runs when the file is accessed, consuming resources in a process that doesn’t appear in standard process listings. Without resource quotas and priority controls, these hidden processes run unthrottled and undetected.

More broadly, SC-06 addresses the precondition for many availability attacks. A system with no resource boundaries is one where any sufficiently resource-intensive process can crowd out legitimate workloads without triggering any threshold-based detection.

What attackers exploit

Attackers target the absence of resource controls through several common vectors:

• Cryptomining malware that silently consumes CPU and memory on compromised hosts, degrading performance for legitimate workloads over weeks or months before detection
• Resource fork concealment (T1564.009) on macOS, where attackers hide executables in file extended attributes to evade standard process monitoring
• Fork bombs and process multiplication attacks that exhaust process table entries and memory, causing denial of service without network-level indicators
• Runaway queries or API calls from compromised application accounts that consume database or service resources without triggering rate limits
• Lateral movement tools that generate sustained I/O or network load during data exfiltration, competing with production traffic for bandwidth

How to implement

The most common failure mode for SC-06 isn’t the absence of resource controls; it’s configuring them once during initial deployment and never revisiting them as workloads change. Resource allocation that matched your environment 18 months ago may now throttle critical services or leave too much headroom for non-essential processes.

For your organization

Start by inventorying the resources that matter most to your operations. CPU, memory, disk I/O, and network bandwidth are the primary categories, but you should also consider process table limits, file descriptor counts, and connection pool sizes for database-backed applications.

Once you’ve identified critical resources, map them to your workload tiers. Mission-critical production services should receive guaranteed minimum allocations, while batch processing, reporting, and development workloads should be subject to hard caps. On Linux systems, cgroups (control groups) provide the mechanism for enforcing CPU shares, memory limits, and I/O bandwidth per process group. On Windows, Job Objects and Windows System Resource Manager serve a similar function. Container orchestration platforms like Kubernetes offer resource requests and limits at the pod level, which translate directly to SC-06 compliance when configured correctly.

Define what happens when a quota is exceeded. The control doesn’t prescribe a specific response, but you need a documented policy. Options include throttling the process to its allocated share, generating an alert for operations staff, or terminating the process if it exceeds a hard limit. Whichever approach you choose, test it under load before relying on it in production.

Monitoring is the enforcement mechanism that makes quotas meaningful. Configure your monitoring platform to alert on sustained resource consumption above defined thresholds, and include process-level attribution so you can identify which workload is consuming resources. The UpGuard Breach Risk platform can help identify externally visible indicators of resource exhaustion, such as degraded response times or intermittent availability, across your attack surface.

Review and update your resource allocations at least quarterly, or whenever you deploy a significant new workload. Document each allocation decision, including the rationale and the approving authority, to satisfy audit requirements.

For your vendors

When evaluating vendors against SC-06, the key question is whether they’ve moved beyond default operating system configurations to implement intentional resource allocation controls. Request documentation of their resource allocation policy, including how they define resource tiers, enforce quotas, and respond to threshold violations.

Ask vendors to provide evidence of cgroup configurations, container resource limits, or equivalent controls on their production systems. If a vendor operates in a multi-tenant environment, ask how they isolate your workload from other tenants’ resource consumption. A vendor that can’t articulate their tenant isolation strategy likely hasn’t implemented one.

Review their monitoring configuration for resource utilization. Vendors should demonstrate that they track CPU, memory, disk I/O, and network bandwidth at the process or container level, not just the host level. Host-level averages can mask individual processes that are consuming disproportionate resources.

Request incident response records related to resource exhaustion events. How the vendor handled past availability incidents reveals whether their resource controls are effective in practice. The UpGuard Vendor Risk platform streamlines this assessment by centralizing vendor evidence collection and tracking control implementation across your third-party ecosystem.

Red flags to watch for include vendors who can’t distinguish between host-level and process-level resource monitoring, vendors with no documented quota policy, and vendors who rely solely on reactive scaling (adding capacity after exhaustion) rather than proactive allocation controls.

Evidence examples

Cross-framework mapping

No cross-framework mappings are currently configured for SC-06. Organizations seeking related guidance may find ISO 27001 control 8.6 (Capacity Management) relevant, as it addresses capacity monitoring and resource planning from an information security management perspective. The broader System and Communications Protection family contains additional controls that complement SC-06’s resource allocation requirements.

Related controls

• SC-05 — Denial-of-service Protection: SC-05 addresses detection and mitigation of denial-of-service attacks at the network and application layer, while SC-06 provides the underlying resource boundaries that prevent any single process from achieving the same effect internally.

Frequently asked questions

What is NIST SP 800-53 SC-06?

SC-06 is the NIST SP 800-53 control that requires organizations to protect system resource availability by enforcing priority allocation, quotas, or equivalent controls across CPU, memory, disk I/O, and network bandwidth. The control ensures that no single process, user, or application can monopolize shared resources and degrade service for other workloads. It applies at the system level and covers both the mechanisms for allocating resources and the policies that define how those allocations are enforced.

What happens if SC-06 is not implemented?

Without SC-06 controls in place, any resource-intensive process, whether malicious or accidental, can consume disproportionate system resources and deny service to mission-critical applications. Cryptomining malware, fork bombs, and runaway queries all exploit the absence of process quotas and priority scheduling to degrade system performance. The resulting outages often appear as hardware failures or application bugs, delaying identification of the root cause and extending the impact window.

How do you audit SC-06?

Auditing SC-06 starts with reviewing the organization’s resource allocation policy to confirm that it defines specific resource categories, priority tiers, and quota thresholds for each workload classification. Auditors then verify that the documented controls are implemented by examining system configuration artifacts, such as cgroup settings, container resource limits, or hypervisor resource pools. Process-level monitoring records should demonstrate that the organization tracks resource consumption at a granularity sufficient to detect individual processes exceeding their allocated share. Review audit logs for evidence of quota enforcement actions, including throttled or terminated processes, to confirm that the controls operate as documented.

How does SC-06 relate to denial-of-service protection?

SC-06 and SC-05 (Denial-of-service Protection) address different layers of the same availability problem. SC-05 focuses on detecting and mitigating denial-of-service attacks that arrive through network traffic or application-layer exploitation. SC-06 provides the internal resource boundaries that prevent a single process from achieving denial-of-service effects on the same host, whether the cause is malicious software, a misconfigured application, or an insider threat. Implementing both controls together creates defense in depth for system availability.