CISSP 9.20 - Common Security Architecture Flaws & Issues

This episode of the ISC2 Certified Information Systems Security Professional (CISSP) exam prep series surveys the common ways a security architecture gets undermined, continuing Domain 3 — because no architecture is ever perfectly secure, and knowing the flaw patterns is what lets you spot a subtle attack before it becomes a very public one.

Frequently Asked Questions

What is a covert channel?

A covert channel is a path used for communication that was never meant for it, so your normal controls do not guard it — the opposite of an overt channel, which is known, authorized, and monitored. A covert timing channel leaks information by subtly altering the timing or performance of a component, while a covert storage channel hides data by writing it somewhere another process can quietly read, such as unused disk space. Your best defense is thorough auditing and hunting the logs for anomalies.

What happens when design and coding flaws leave doors ajar?

You inherit weaknesses that attackers love. A maintenance hook or backdoor is a special entry point built into code during development to skip the usual security checks, which becomes a serious hole if it is not removed before release, and a program that mishandles an error can crash into an unstable state an attacker exploits to gain higher privilege. The remedy is security-conscious design from the start, code review, and testing tools run throughout development.

Which new flaws arrive with AI and machine learning?

With large language models, prompt injection tricks the model into ignoring its real instructions, and system prompt leakage makes the model spill its hidden instructions, handing an attacker the exact rules to bypass. Traditional machine learning faces input manipulation, also called an evasion attack, which feeds subtly altered input that makes the model misclassify, and data poisoning, which corrupts the training data so the model learns the wrong lessons or hides a backdoor. Treat every interaction with a model as potentially hostile.

How does a rootkit hide in plain sight?

A rootkit can replace the kernel, slip beneath it, swap out device drivers, or infiltrate application libraries, so whatever it feeds the operating system looks perfectly normal, letting it hide its own files and processes from the very tools you would use to find them. One clue is a change in the size or hash of key system files, which file-integrity monitoring can flag. Once you truly suspect a rootkit, the only trustworthy cure is to rebuild the machine from clean sources.

How do slow, tiny attacks slip past you?

Incremental attacks stay under the threshold that would raise an alarm. Data diddling makes small, quiet changes to data as it is entered or processed, usually an insider’s game that hides unless integrity checks catch it, while the salami attack whittles away tiny slices of value, like shaving fractions of a cent off countless transactions. You counter both with separation of duties, tight control over code, and monitors that watch for small, repetitive transfers.

Reference: This article is based on concepts discussed in CISSP 9.20 - Common Security Architecture Flaws & Issues.