SC-31 Covert Channel Analysis asks you to do two things. Analyze the system's communications to identify aspects that could be avenues for covert channels, and estimate the maximum bandwidth of those channels.
NIST SP 800-53 binds US federal systems, and reaches contractors and cloud providers through contract terms such as FedRAMP. For everyone else it is a reference catalog you borrow from.
The guidance says developers are best placed to find potential areas. It calls the analysis meaningful where unauthorized information flows across security domains are possible, such as systems holding export controlled information that connect to external networks, and for multilevel secure, multiple security level and cross domain systems. Three enhancements extend it. SC-31.1 tests channels for exploitability, SC-31.2 covers maximum bandwidth, and SC-31.3 measures bandwidth in operational environments.
What it means in practice
Most commercial software does not need a formal covert channel study. If you handle data that must not cross a boundary, such as a shared multi tenant platform, a cross domain solution or export controlled technical data, then you should ask where information could leak through shared resources or timing, for example shared caches, disk usage, response times or resource quotas.
If you decide the system is in scope, the analysis has a recognizable shape. List every path through which two components or two security domains can influence each other: shared memory, shared storage, network timing, resource contention, and error messages. For each path, ask whether a sender could encode information that a receiver can decode, then estimate how many bits per second that could carry.
The guidance says developers are in the best position to do this, so the people who built the design should be in the room. A security reviewer without design knowledge will miss paths. A developer without security training will not think to look. Pair them.
The bandwidth estimate does not need to be exact to be useful. A rough figure, with the assumptions written down, lets you decide whether a channel matters. A channel that leaks one bit per hour is a different problem from one that leaks megabytes.
For multi tenant software, the practical version of this question is whether one customer can learn anything about another through shared infrastructure. Cache timing, noisy neighbors and shared rate limits all belong in that discussion. Keep the notes short, dated and signed off.
Evidence to collect
- The scope decision: why the system is or is not in scope.
- The analysis report listing candidate channels.
- Bandwidth estimates and the method used.
- Test results from any exploitability testing.
- Design changes made to close or limit channels.
Common gaps
No scope decision at all, so an auditor cannot tell whether the control was considered. Analysis done once at design and never revisited after architecture changes. Estimates without a method.
How to implement it
Write a one page scoping note. If the system is out of scope, say why and who approved. If it is in scope, run the analysis during design, record candidate channels, estimate bandwidth, and mitigate the ones that matter. Revisit when tenancy or network boundaries change.
Quick check
Do all systems need a covert channel analysis?
No. The guidance ties it to systems with potential unauthorized flows across security domains. Document your scoping decision either way.
