Chapter 4. Security Requirements


You will know that your tent is secure; you will take stock of your property and find nothing missing.

 Job 5:24 (NIV)
Table of Contents
4.1. Common Criteria Introduction
4.2. Security Environment and Objectives
4.3. Security Functionality Requirements
4.4. Security Assurance Measure Requirements

Before you can determine if a program is secure, you need to determine exactly what its security requirements are. Obviously, your specific requirements depend on the kind of system and data you manage.

For example, any person or company doing business in the state of California is responsible for notifying California residents when an unauthorized person acquires unencrypted computer data if that data includes first name, last name, and at least one of the following: Social Security Number, driver’s license number, account number, debit or credit card information. (Senate bill 1386 aka Civil Code 1798.82, effective July 1, 2003).

Thankfully, there’s an international standard for identifying and defining security requirements that is useful for many such circumstances: the Common Criteria [CC 1999], standardized as ISO/IEC 15408:1999. The CC is the culmination of decades of work to identify information technology security requirements. There are other schemes for defining security requirements and evaluating products to see if products meet the requirements, such as NIST FIPS-140 for cryptographic equipment, but these other schemes are generally focused on a specialized area and won’t be considered further here.

This chapter briefly describes the Common Criteria (CC) and how to use its concepts to help you informally identify security requirements and talk with others about security requirements using standard terminology. The language of the CC is more precise, but it’s also more formal and harder to understand; hopefully the text in this section will help you “get the jist”.

Note that, in some circumstances, software cannot be used unless it has undergone a CC evaluation by an accredited laboratory. This includes certain kinds of uses in the U.S. Department of Defense (as specified by NSTISSP Number 11, which requires that before some products can be used they must be evaluated or enter evaluation), and in the future such a requirement may also include some kinds of uses for software in the U.S. federal government. This section doesn’t provide enough information if you plan to actually go through a CC evaluation by an accredited laboratory. If you plan to go through a formal evaluation, you need to read the real CC, examine various websites to really understand the basics of the CC, and eventually contract a lab accredited to do a CC evaluation.