CISSP GLOSSARY · SECURITY OPERATIONS
Sandboxing
Running untrusted code in an isolated environment so its behaviour can be observed and contained without risk to production; the basis of malware detonation and browser isolation.
Sandboxing executes untrusted code in an isolated environment where it can be observed without endangering production systems. The sandbox (a virtual machine, container, or restricted process) grants the code limited access to files, memory, and the network, and records everything it tries to do. Common uses include malware detonation, where a suspicious attachment is run and watched before delivery, browser isolation, and the app-level sandboxes that confine mobile applications to their own data.
The caveat that decides questions is evasion. Modern malware checks whether it is being watched: it looks for virtualisation artefacts, sleeps until the analysis window times out, or stays benign until it detects human activity such as mouse movement. A clean sandbox verdict therefore means “no malicious behaviour observed”, not “safe”. Sandboxing is a detection and containment control for code you must run; it does not remove whatever underlying vulnerability the code might exploit.
Exam relevance: if a scenario mentions detonating a suspicious file, observing the behaviour of unknown code, or isolating a browser session, the answer is sandboxing. Contrast it with a honeypot, which is a decoy that draws the attacker in, whereas a sandbox confines something you already hold. Verdicts from sandbox detonations commonly feed an IDS ruleset or a SIEM for correlation with the rest of the estate.