Policy decomposition involves the mapping of high-level policy statements into lower-level policies, a process that can be repeated until the policies are implementable. Policy is a term that can have several meanings, depending upon the context of its use. The National Institute of Standards and Technology (NIST) categorizes computer security policies into three types: program policies, issue-specific policies, and system-specific policies. Program policies are those that are used as a foundation for the organization’s information security program. Issue-specific policies are used to address specific issues of concern, such as personally identifiable information (PII) or data retention. System-specific policies are technical directives aimed at driving a specific technical outcome, such as firewall rules.

Regardless of the source or type, policies need to be decomposed into security requirements so that they can be enforced. Besides policy-based requirements, other sources of security requirements include regulations and government directives. If software is going to meet all of these drivers, then the issues need to be decomposed into requirements. When examining security requirements, there are a limited set of defined options.

Confidentiality, Integrity, and Availability Requirements

At the core of software is data, and one of the key policy elements that needs to be defined for the software development team is required levels of data protection. Defining the required specific level of protection in terms of confidentiality, integrity, and availability is a key security requirement. Per Federal Information Processing Standard (FIPS) 199 and 44 U.S.C., Sec. 3542, the terms confidentiality, integrity, and availability are defined as follows:

CONFIDENTIALITY
“Preserving authorized restrictions on information access and disclosure, including means for protecting personal privacy and proprietary information…”

A loss of confidentiality is the unauthorized disclosure of information.

INTEGRITY
“Guarding against improper information modification or destruction, and includes ensuring information non-repudiation and authenticity…”

A loss of integrity is the unauthorized modification or destruction of information.

AVAILABILITY
“Ensuring timely and reliable access to and use of information…”

A loss of availability is the disruption of access to or use of information or an information system.

Confidentiality

Issues involving protecting data from unauthorized disclosure can be decomposed to confidentiality requirements. The policy will define confidentiality requirements in terms of who can exchange what information between what endpoints. The key elements to determine are who the authorized users are and for what specific data elements or types. It can then be assumed that any other users would be unauthorized. Based on this set of information, the following items can be enumerated:

•   Who is authorized to see what specific data elements

•   What mechanism should be employed to enforce confidentiality

•   What are the business requirements with respect to data collection, transfer, storage, and use with respect to confidentiality

Integrity

Issues involving protecting data from unauthorized alteration can be decomposed to integrity requirements. The policy will define integrity requirements in terms of who can alter which information elements between what endpoints. The key elements to determine are who is authorized to alter which specific data streams. It can then be assumed that any other users’ alterations would be unauthorized. Based on this set of information, the following items can be enumerated:

•   Who is authorized to alter which specific data elements

•   What mechanism should be employed to detect errors and enforce integrity

•   What are the business requirements with respect to data collection, transfer, storage, and use with respect to integrity

Because integrity can be expressed in the form of data errors, consideration should be given to requirements that can be used as a basis for monitoring error conditions.

Availability

Availability is concerned with two issues: ensuring systems are available for authorized users when they require those systems and denying access to unauthorized users at all other times. Policy elements associated with determining access can be translated into the availability requirements. Common availability issues include denying illegitimate access to systems as well as preventing availability attacks such as denial of service.

Authentication, Authorization, and Auditing Requirements

To accomplish the tasks associated with confidentiality, integrity, and availability, one must first establish identity and then determine the level of authorized activity. This leads us to the issue of identification and authentication, followed by authorization. This is another important set of policy determinations that needs to be defined at the beginning of the development process. To ensure that the system is operating as desired, an audit function is needed.

Identification and Authentication

Determining a user’s identity requires an authentication process. Typically, a user enters some token to demonstrate to the system that they are who they purport to be. This requires a previous identification step, where the original record of the user is created. The identification step requires the following issues to be determined by requirements:

•   Mechanism to be used for identity

•   Management of identities, including reaffirmations

The mechanism to be used for identity sets the means to be used to authenticate users when services are requested. Identity is a step usually only taken once—when a user is established in the authentication system and a shared secret is created. This shared secret is what will be used to confirm identity during authentication events.

Authentication is, therefore, a validation that the user is presenting the known shared secret. This requires the establishment of a specific authentication method and a means of protecting the shared secret from disclosure. Other issues of authentication that need to be resolved include

•   Method of authentication management

•   Strength of authentication method

An authentication system may be as simple as a plain-text password system. An example of this would be basic authentication of a web-based system, where credentials are passed in the clear. For some uses, where no real security requirements exist, this provides sufficient control. Basic authentication provides no protection for credentials being passed between systems, so in reality, there is no security provided by this authentication method. For systems where more demanding security is needed, a more complicated system such as the Kerberos system may be employed with its encrypted secrets.

In all cases, authentication systems depend on some unique bit of information known only to the party being authenticated and the authentication system, a shared secret established during the identification phase. To protect this shared secret, in most cases, it is represented by a token such as a salted hash. This enables manipulation without risk of disclosure.

The concept of tokenization can also be extended to other shared secrets, such as biometrics. A biometric can be converted to a specific representative code, which can then be treated like any other secret. Another form of tokenization is in the use of a security token or smart card system.

In the end, the requirement for authentication depends upon the level of security needed, the scale of users, and management of users, coupled with the specific uses of the authentication. For a given system, multiple methods may be used; for example, high-value customers may use two-factor authentication, whereas visitors may have only a simple single factor. System administrators may require stronger authentication based on their higher access levels. The specifics for all of these individual circumstances can be decomposed from policy-driven requirements.

Authorization

Once a user is positively identified by the authentication system, an authorization determination still needs to be made. The best method of decomposing authorization follows a subject-object-activity model. A subject is a user that has been authenticated. An object is the item that a user wishes to perform an action on—it can be a file, a system, a database entry, a webpage, basically any resource whatsoever. The activity is the desired action that the subject wishes to invoke with the object. For file systems, this can be read, write, execute, delete, and so on. With database entries, there are basically the same options.

At this point, the loop back to the requirements associated with confidentiality, integrity, and availability (CIA) is complete. The instantiation of the CIA requirements is performed by the authorization system. Whether a simple access control mechanism or a more sophisticated granular control such as a database access lattice, the concept is the same. The authorization system implements the control of access.

Access Control Mechanisms

Access control systems exist to implement access control models. Different access control models are used based on the scale and scope of the elements of the subject-object-activity relationship.

Mandatory Access Control

In MAC, a subject’s access to an object is a predetermined property that is defined by the rules associated with the system. This system, generally used only in environments where different levels of security classifications exist, is much more restrictive in terms of what a user is allowed to do. Referring to the Orange Book, we can find a definition for mandatory access control: “A means of restricting access to objects based on the sensitivity (as represented by a label) of the information contained in the objects and the formal authorization (i.e., clearance) of subjects to access information of such sensitivity.”

In the case of MAC, the owner or subject can’t determine whether access is to be granted to another subject; it is the job of the operating system to decide. In MAC, the security mechanism controls access to all objects, and individual subjects cannot change that access. The key here is the label attached to every subject and object. The label identifies the level of classification for that object and the level that the subject is entitled to. Think of military security classifications such as Secret and Top Secret. A file that has been identified as Top Secret (has a label indicating that it is Top Secret) may be viewed only by individuals with a Top Secret clearance.

It is up to the access control mechanism to ensure that an individual with only a Secret clearance never gains access to a file labeled as Top Secret. Similarly, a user cleared for Top Secret access will not be allowed by the access control mechanism to change the classification of a file labeled as Top Secret to Secret or to send that Top Secret file to a user cleared only for Secret information.

The complexity of such a mechanism can be further understood when you consider today’s windowing environment. The access control mechanism will not allow a user to copy a portion of a Top Secret document and paste it into a window containing a document with only a Secret label. It is this separation of differing levels of classified information that results in this sort of mechanism being referred to as multilevel security. A final comment should be made: Just because a subject has the appropriate level of clearance to view a document, this does not mean that they will be allowed to do so. The concept of “need to know,” which is a DAC concept, also exists in MAC mechanisms.

Discretionary Access Control

Both discretionary access control and mandatory access control are terms originally used by the military to describe two different approaches to controlling what access an individual has on a system. In systems that employ discretionary access controls, the owner of an object can decide which other subjects may have access to the object and what specific access they may have. One common method to accomplish this is via the permission bits used in UNIX-based systems. The owner of a file can specify what permissions (read/write/execute) members in the same group may have and also what permissions all others may have. Access control lists are another common mechanism used to implement discretionary access control.

Role-Based Access Control

Access control lists can be cumbersome and can take time to administer properly. Another access control mechanism that has been attracting increased attention is role-based access control (RBAC). In this scheme, instead of each user being assigned specific access permissions for the objects associated with the computer system or network, that user is assigned a set of roles that he or she may perform. The roles are, in turn, assigned the access permissions necessary to perform the tasks associated with the role. Users will thus be granted permissions to objects in terms of the specific duties they must perform—not of a security classification associated with individual objects.

Rule-Based Access Control

The first thing that you might notice is the ambiguity that is introduced with this access control method also using the acronym RBAC. Rule-based access control (RBAC) again uses objects such as access control lists (ACLs) to help determine whether or not access should be granted. However, in this case, a series of rules is contained in the ACL and the determination of whether to grant access is made based on these rules. An example of such a rule is one that states that no employee may have access to the payroll file after hours or on weekends. As with MAC, users are not allowed to change the access rules, and administrators are relied on to enforce this. Rule-based access control can actually be used in addition to or as a method of implementing other access control methods. For example, MAC methods can utilize a rule-based approach for implementation.

Attribute-Based Access Control

There are times when access control decisions are best made based on attributes associated with the object and the subject. Attribute-based access control (ABAC) is a form of access control where decisions are coded based on rules associated with specific elements of the data or objects and the subjects requesting access. For instance, on a medical record, access may be limited to doctors and nurses that are assigned to care for a patient. In the case of doctors, this can be by assignment; doctors are assigned to cases. In the case of nurses and other medical staff, it can be based on staffing or specific orders. Radiology staff would be able to access records when patients are assigned specific tests or treatments. This assignment of access is based on specific attributes in the patient medical data, not just at a higher level such as patient.

Auditing

The information system security policy decomposition for auditing activities should consider both risk-based and organizational characteristics. The risk-based issues can be examined as cases of three forms of audit-related risk (also known as residual risk):

•   Inherent risk

•   Detection risk

•   Control risk

Inherent risks are those associated with the process and its inherent error rate, assuming no internal controls exist to handle the potential errors. Detection risk is the risk that an audit will not detect an issue that can result in material error. Control risk is the risk that controls will not detect or prevent material errors in a timely fashion.

Organizational characteristics that can drive auditing include items such as organizational history, the business environment, and supervisory issues. When decomposing policies, the following organizational security elements should be explored for auditing:

•   Roles and responsibilities

•   Separation of duties

•   Training and qualifications

•   Change management

•   Control management

Internal and External Requirements

All applicable internal and external requirements need to be documented and communicated to the team so that they can be decomposed into security requirements. An understanding of the internal and external security requirements is important for the team to craft solutions that include these requirements in the design phase. Learning about them later during coding results in workarounds or even assumptions that can lead to gaps in coverage and security issues that are hard to patch later.

Internal

Internal security requirements include all of the items used by the system to protect its own data and communications. Some typical internal requirements could include

•   Protect audit logs

•   Manage data loss prevention elements

•   Monitor internal system traffic

•   Monitor internal controls

Prime examples of past issues with internal requirements include such issues as failing to protect configuration files on server applications. Hackers then are able to change the configuration, and ultimately the application usage, not by hacking the application code itself, but by reconfiguring it because the config files were left vulnerable. Logging of sensitive data over open, plaintext communication channels has given up user credentials during software errors and crash reports.

External

Security policies should ensure compliance with all external obligations. The sources of these obligations include statutory and regulatory regulations, as well as contractual obligations. These requirements need to be decomposed into security requirements that can be operationalized. Some typical external requirements could include

•   Manage external connections with security controls

•   Manage external connections and authentication

•   Employ content filtering and proxies to protect against web-based threats

Chapter Review

In this chapter, we examined the decomposition of policies and other sources of requirements into operational security requirements. These operational security requirements are typically grouped into those that impact confidentiality, integrity, and availability. Other requirements map to identity and authentication, authorization, and auditing activities.

Quick Tips

•   Confidentiality requirements relate to the protection of data from unauthorized disclosure.

•   Integrity requirements relate to the protection of data from unauthorized alteration.

•   Availability requirements relate to the protection from disruption of authorized access.

•   Authentication requirements relate to the identification of a user.

•   Authorization requirements relate to controlling the subject-object-activity model.

•   Auditing requirements are used to ensure controls are operational and effective.

Questions

To further help you prepare for the CSSLP exam, and to provide you with a feel for your level of preparedness, answer the following questions and then check your answers against the list of correct answers found at the end of the chapter.

1.   When policies decompose into audit risk requirements, the following are the three types of audit-related risks:

A.   Requirements risk, development risk, testing risk

B.   Tangible risk, intangible risk, residual risk

C.   Inherent risk, control risk, detection risk

D.   Confidentiality risk, integrity risk, availability risk

2.   To what set of requirements can issues involving protecting data from unauthorized disclosure be decomposed to?

A.   Authorization

B.   Authentication

C.   Integrity

D.   Confidentiality

3.   Issues related to denying illegitimate access into systems map to what kind of security requirements?

A.   Authorization

B.   Availability

C.   Integrity

D.   Confidentiality

4.   The process by which a user enters some token to demonstrate to the system that they are the user they purport to be is:

A.   Identification

B.   Authorization

C.   Authentication

D.   Auditing

5.   Restricting access to objects based on the identity of a subject or the groups to which they belong is an example of which of the following?

A.   Discretionary access control

B.   Mandatory access control

C.   Rule-based access control

D.   Authentication

6.   What was described in the chapter as being essential in order to implement discretionary access control?

A.   Object owner–defined security access

B.   Certificates

C.   Labels

D.   Security classifications

7.   The CIA of security includes:

A.   Confidentiality, integrity, authentication

B.   Certificates, integrity, availability

C.   Confidentiality, inspection, authentication

D.   Confidentiality, integrity, availability

8.   A security policy that is associated with securing PII is an example of what type of computer security policy?

A.   System-specific policy

B.   Program policy

C.   Organizational policy

D.   Issue-specific policy

9.   When an audit fails to find a specific risk during an examination of a system, this is an example of what type of risk?

A.   Detection risk

B.   Audit risk

C.   Inherent risk

D.   Control risk

10.   Which access control technique discussed relies on a set of rules to determine whether access to an object will be granted or not?

A.   Role-based access control

B.   Object and rule instantiation access control

C.   Rule-based access control

D.   Discretionary access control

11.   When both parties authenticate each other, this is defined as:

A.   Mandatory access control

B.   Dual authentication

C.   Separation of duties

D.   Mutual authentication

12.   The ability of a subject to interact with an object describes:

A.   Authentication

B.   Activity

C.   Confidentiality

D.   Mutual authentication

13.   Which of the following is not an example of something that can be used as a shared secret?

A.   Something you know

B.   Something you have

C.   Something you are

D.   Something you want

14.   An example of a policy element that is related to integrity is:

A.   Record error detection and correction

B.   Ensure systems are available for authorized users

C.   Who is authorized to see what specific data elements

D.   Control risk

15.   Ensuring that the software security requirements address the legal and regulatory policy issues is an example of:

A.   System-based security policy

B.   Risk mitigation

C.   Internal requirements

D.   External requirements

Answers

1.   C. The risk-based issues can be examined as cases of three forms of audit-related risk: inherent risk, detection risk, and control risk.

2.   D. Issues involving protecting data from unauthorized disclosure can be decomposed to confidentiality requirements.

3.   B. Common availability issues include denying illegitimate access to systems as well as preventing availability attacks such as denial of service.

4.   C. Authentication is a process by which a user enters some token to demonstrate to the system that they are the user they purport to be.

5.   A. In systems that employ discretionary access controls, the owner of an object can decide which other subjects may have access to the object and what specific access they may have.

6.   A. Object owners define access control in discretionary access control systems.

7.   D. Don’t forget, even though authentication was described at great length in this chapter, the A in the CIA of security represents availability, which refers to both the hardware and data being accessible when the user wants them.

8.   D. Issue-specific policies are used to address specific issues of concern, such as PII or data retention.

9.   A. Detection risk is the risk that an audit will not detect an issue that can result in material error.

10.   C. This is the description of rule-based access control.

11.   D. Mutual authentication is when both parties authenticate each other at the same time.

12.   B. A subject performs an activity on an object.

13.   D. The primary items used as shared secrets are something you have, something you know, and something you are (biometrics).

14.   A. The detection and correction of errors can be a part of integrity controls.

15.   D. Legal and regulatory issues are external requirements.