- 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
This chapter is from the book
This chapter is from the book
This chapter is from the book
Principle 5: Computer Security Depends on Two Types of Requirements: Functional and Assurance
Functional requirements describe what a system should do. Assurance requirements describe how functional requirements should be implemented and tested. Both sets of requirements are needed to answer the following questions:
- Does the system do the right things (behave as promised)?
- Does the system do the right things in the right way?
These are the same questions that others in noncomputer industries face with verification and validation. Verification is the process of confirming that one or more predetermined requirements or specifications are met. Validation then determines the correctness or quality of the mechanisms used to meet the needs. In other words, you can develop software that addresses a need, but it might contain flaws that could compromise data when placed in the hands of a malicious user.
Consider car safety testing as an example. Verification testing for seat belt functions might include conducting stress tests on the fabric, testing the locking mechanisms, and making certain the belt will fit the intended application, thus completing the functional tests. Validation, or assurance testing, might then include crashing the car with crash-test dummies inside to “prove” that the seat belt is indeed safe when used under normal conditions and that it can survive under harsh conditions.
With software, you need both verification and validation answers to gain confidence in products before launching them into a wild, hostile environment such as the Internet. Most of today’s commercial off-the-shelf (COTS) software and systems stop at the first step, verification, without bothering to test for obvious security vulnerabilities in the final product. Developers of software generally lack the wherewithal and motivation needed to try to break their own software. More often, developers test that the software meets the specifications in each function that is present but usually do not try to find ways to circumvent the software and make it fail. You learn more about security testing of software in Chapter 5.