2 cissp ® Official Study Guide Eighth Edition

Covert Timing Channel
A covert timing channel conveys information by altering the per-
formance of a system component or modifying a resource’s timing in a predictable manner. 
Using a covert timing channel is generally a method to secretly transfer data and is very dif-
ficult to detect.
Covert Storage Channel
A covert storage channel conveys information by writing data to 
a common storage area where another process can read it. When assessing the security of 
software, be diligent for any process that writes to any area of memory that another pro-
cess can read.
Both types of covert channels rely on the use of communication techniques to exchange 
information with otherwise unauthorized subjects. Because the covert channel is outside 
the normal data transfer environment, detecting it can be difficult. The best defense is to 
implement auditing and analyze log files for any covert channel activity.
Attacks Based on Design or Coding Flaws
and Security Issues
Certain attacks may result from poor design techniques, questionable implementation 
practices and procedures, or poor or inadequate testing. Some attacks may result from 
deliberate design decisions when special points of entry built into code to circumvent access 
controls, login, or other security checks often added to code while under development are 
not removed when that code is put into production. For what we hope are obvious reasons, 
such points of egress are properly called back doors because they avoid security measures 
by design (they’re covered later in this chapter in “Maintenance Hooks and Privileged 
Programs”). Extensive testing and code review are required to uncover such covert means 

---

386
Chapter 9 
■
Security Vulnerabilities, Threats, and Countermeasures
of access, which are easy to remove during final phases of development but can be incred-
ibly difficult to detect during the testing and maintenance phases.
Although functionality testing is commonplace for commercial code and applica-
tions, separate testing for security issues has been gaining attention and credibility only 
in the past few years, courtesy of widely publicized virus and worm attacks, SQL injec-
tion attacks, cross-site scripting attacks, and occasional defacements of or disruptions to 
widely used public sites online. You might benefit from viewing the OWASP Top 10 Web 
Application Security Risks report at 
https://www.owasp.org/images/7/72/OWASP_Top_10-
2017_%28en%29.pdf.pdf
.
In the sections that follow, we cover common sources of attack or vulnerabilities of secu-
rity architectures that can be attributed to failures in design, implementation, prerelease 
code cleanup, or out-and-out coding mistakes. Although they’re avoidable, finding and fix-
ing such flaws requires rigorous security-conscious design from the beginning of a develop-
ment project and extra time and effort spent in testing and analysis. This helps to explain 
the often lamentable state of software security, but it does not excuse it!
Humans will never write completely secure (flawless) code. Source code analysis tools 
implemented throughout the appdev cycle will minimize the number of flaws in the pro-
duction release, and the flaws identified prior to production release will cost much less to 
mitigate. The concepts of code review and testing are covered in Chapter 15, “Security 
Assessment and Testing.”