- Introduction
- Principle 1: There Is No Such Thing As Absolute Security
- Principle 2: The Three Security Goals Are Confidentiality, Integrity, and Availability
- Principle 3: Defense in Depth as Strategy
- Principle 4: When Left on Their Own, People Tend to Make the Worst Security Decisions
- Principle 5: Computer Security Depends on Two Types of Requirements: Functional and Assurance
- Principle 6: Security Through Obscurity Is Not an Answer
- Principle 7: Security = Risk Management
- Principle 8: The Three Types of Security Controls Are Preventative, Detective, and Responsive
- Principle 9: Complexity Is the Enemy of Security
- Principle 10: Fear, Uncertainty, and Doubt Do Not Work in Selling Security
- Principle 11: People, Process, and Technology Are All Needed to Adequately Secure a System or Facility
- Principle 12: Open Disclosure of Vulnerabilities Is Good for Security!
- Summary
- Test Your Skills
Principle 6: Security Through Obscurity Is Not an Answer
Many people in the information security industry believe that if malicious attackers don’t know how software is secured, security is better. Although this might seem logical, it’s actually untrue. Security through obscurity means that hiding the details of the security mechanisms is sufficient to secure the system alone. An example of security through obscurity might involve closely guarding the written specifications for security functions and preventing all but the most trusted people from seeing it. Obscuring security leads to a false sense of security, which is often more dangerous than not addressing security at all.
If the security of a system is maintained by keeping the implementation of the system a secret, the entire system collapses when the first person discovers how the security mechanism works—and someone is always determined to discover these secrets. The better bet is to make sure no one mechanism is responsible for the security of the entire system. Again, this is defense in depth in everything related to protecting data and resources.
In Chapter 11, “Cryptography,” you’ll see how this principle applies and why it makes no sense to keep an algorithm for cryptography secret when the security of the system should rely on the cryptographic keys used to protect data or authenticate a user. You can also see this in action with the open-source movement: Anyone can gain access to program (source) code, analyze it for security problems, and then share with the community improvements that eliminate vulnerabilities and/or improve the overall security through simplification (see Principle 9).