2 cissp ® Official Study Guide Eighth Edition

Trusted Recovery
When an unprepared system crashes and subsequently recovers, two opportunities to 
compromise its security controls may arise. Many systems unload security controls as part 
of their shutdown procedures. 
Trusted recovery
ensures that all security controls remain 
intact in the event of a crash. During a trusted recovery, the system ensures that there are 
no opportunities for access to occur when security controls are disabled. Even the recovery 
phase runs with all controls intact.
For example, suppose a system crashes while a database transaction is being written to 
disk for a database classified as top secret. An unprotected system might allow an unau-
thorized user to access that temporary data before it gets written to disk. A system that 
supports trusted recovery ensures that no data confidentiality violations occur, even during 
the crash. This process requires careful planning and detailed procedures for handling sys-
tem failures. Although automated recovery procedures may make up a portion of the entire 
recovery, manual intervention may still be required. Obviously, if such manual action is 
needed, appropriate identification and authentication for personnel performing recovery is 
likewise essential.
Input and Parameter Checking
One of the most notorious security violations is a 
buffer overflow
. This violation occurs 
when programmers fail to validate input data sufficiently, particularly when they do not 
impose a limit on the amount of data their software will accept as input. Because such 
data is usually stored in an input buffer, when the normal maximum size of the buffer is 

---

Common Architecture Flaws and Security Issues 
387
exceeded, the extra data is called overflow. Thus, the type of attack that results when some-
one attempts to supply malicious instructions or code as part of program input is called 
a buffer overflow. Unfortunately, in many systems such overflow data is often executed 
directly by the system under attack at a high level of privilege or at whatever level of privi-
lege attaches to the process accepting such input. For nearly all types of operating systems, 
including Windows, Unix, Linux, and others, buffer overflows expose some of the most 
glaring and profound opportunities for compromise and attack of any kind of known secu-
rity vulnerability.
The party responsible for a buffer overflow vulnerability is always the programmer 
whose code allowed nonsanitized or unsanitized input. Due diligence from programmers 
can eradicate buffer overflows completely, but only if programmers check all input and 
parameters before storing them in any data structure (and limit how much data can be 
proffered as input). Proper data validation is the only way to do away with buffer over-
flows. Otherwise, discovery of buffer overflows leads to a familiar pattern of critical secu-
rity updates that must be applied to affected systems to close the point of attack.