Information Security Management Handbook, Sixth Edition (2012)
DOMAIN 3: INFORMATION SECURITY AND RISK MANAGEMENT
Security Management Planning
Chapter 10. Security Requirements Analysis
Sean M. Price
Requirements are the basis for system design. The successful planning, initiation, development, and maintenance of an information technology (IT) system hinge on solid requirements specifications. These system life-cycle activities are negatively impacted when requirements are not adequately analyzed. Inadequately defined requirements lead to poor planning. System development activity may proceed in a direction contrary to user wishes or mission requirements when the planning is weak or the requirements are poorly defined. Appropriate maintenance is difficult to achieve when the timing and activities are not clearly identified and communicated. Proceeding down a path without regard to what is required is an invitation to failure. Likewise, security management also fails to deliver when a security requirements analysis is lacking.
A security requirements analysis typically occurs during the initiation phase of a system. High-level security requirements translate readily into understandable activities, such as account management, auditing, and installation and updating of antivirus software. Requirements are quickly translated into equally high-level actions affecting people, processes, and technology. The security requirements, pushed early in the life of a system, quickly become dated.
The rapid advancement of technology, threats, and vulnerabilities complicates system and security management. New technology can introduce weaknesses not previously considered. Mutating threats reveal new attack vectors, inducing migraines for those responsible for system security. The never-ending avalanche of software flaws continuously degrades the existing controls. Authorities of all stripes promulgate new policies in an attempt to address these complicated advancements. Thus, a periodic security requirements analysis is needed to keep up with these changes.
A security requirements analysis is an activity commonly practiced but seldom specified in detail by the security community. The need for gathering and analyzing security requirements is obvious. Without security requirements, there is little authority to dictate countermeasures or evaluate their effectiveness. Ad hoc (and poorly documented) methods of evaluating security requirements impede efficiency and repeatability. An effective security requirements analysis, therefore, implies the need for a repeatable methodology.
This chapter introduces a security requirements analysis methodology (SRAM). The goal of this methodology is to assist the security professional with identifying, analyzing, associating, and integrating security requirements into the security management process. Each aspect of this goal helps the security professional to
Identify: relevant security requirements
Analyze: security requirements under consideration
Associate: security requirements with the targeted system
Integrate: applicable security requirements into the system’s life cycle and documentation
The attributes in this methodology are joined in a circle, much like other techniques for continuous monitoring or improvement. The methodology is started by identifying the security requirements applicable to the organization and system. Once collected, these requirements are broken down into smaller chunks of information. This provides a means to compare existing requirements, ensuring that nominal differences are considered. Interpretations of a security requirement component are performed to ensure consistent meanings. Next, the compilation of decomposed requirements is compared with the target system. An evaluation is conducted to determine if a deficiency in the requirements list exists. This list of requirement components is trimmed according to the system architecture and management guidance. In the final step, life-cycle documentation is updated to comply with the tailored list of security requirements.
Definitions
To begin with, it is worth taking a few moments to express some definitions that might not be universally accepted. For the purpose of this chapter, the definitions included here are meant as a guide for understanding as opposed to rigid interpretations.
“Implement only those security controls that are necessary.” This is a common security management mantra that is as logical as it is deceptively difficult to comply with. It is often associated with the concept of risk management.
Risk management: A process to evaluate the impact of a threat exploiting a weakness. It does not imply a means to conduct risky operations.
Security goals are the collective objectives of confidentiality, integrity, and availability pertaining to the system and the information processed, stored, and transmitted within it.
Confidentiality: Enables resource access only to those authorized.
Integrity: Protects against improper resource modification or destruction.
Availability: Ensures timely and reliable access to resources.
Security goals are often expressed in a policy.
Policy: A compulsory collection of rules formally promulgated and authorized by an authority or a ruling body
Examples of policies include laws, regulations, and standards (established to implement policy). Governments, industry regulators, and organizations themselves establish policies. This forms the basis for security requirements.
Security requirement: A compulsory discrete rule supporting the desired security goals
By definition, a security requirement must be followed. If it is optional, then it is not really a requirement. A valid security requirement should in some way dictate an action, behavior, process, or system attribute supporting one or more of the security goals. For example, file level encryption supports confidentiality.
Well-defined security requirements support the overall security goals of confidentiality, integrity, and availability. Requirements must in some way support the protection of information and the system within the overall security goals.
Following these definitions, we can proceed with a common basis into the SRAM.
Identify Phase
The goal of this initial phase is to gather all policies that may potentially apply to the system. It is important to remember that security requirements are system-specific. An organization might have two systems with different operational and functional requirements. This might dictate different requirements for each system. In the beginning, no candidate policy should be ignored until it has been properly evaluated for its applicability.
Anyone who has used a search engine on the Internet understands that the amount of information available online is staggering. Sifting through mountains of data to find the security requirements needed can seem like a monumental task. As with all projects, it is important to limit the scope of the work. At this early stage, the security professional should establish boundaries to narrow the search to quickly sort out the needed information. The boundaries are defined by the parameters and attributes of the system in question. Some high-level attributes to consider include:
System role
User types
Industry focus
Data types
Locality
Use a high-level viewpoint to focus on key elements that will guide the security requirements search. Investigate these aspects to discover the key elements. Ask the following questions to establish the initial boundaries of the requirements search:
What is the role of the system? A system might have a primary function, such as accounting. Most systems are a collection of smaller systems performing many functions within an organization. Someone must decide where to draw the line for system boundaries. Knowing the purpose of the system helps focus the search for the relevant security requirements.
Who uses the system? A system will often have at least a few employees who are responsible for maintenance. Internet-facing systems could have various classes of users to consider. The general public is one type of users who are very different than a buying customer. Likewise, systems designed to support collaboration between third parties may have different requirements from those hosting government users. Organizational departments with particular functions such as research and development may have different requirements than those that involve the privacy or health-related information of employees or customers.
What is the industry focus of the users? This question considers the role and users of the system. Some industries may have explicit regulations that others do not. For instance, systems designed to support the healthcare industry will have specific requirements. By contrast, a Web-hosting system that has health industry customers among others probably would not need to support healthcare industry requirements. But, if an aspect of the Web hosting is focused on the healthcare industry, then the additional requirements might be needed. Look to the business mission of the system and types of users supported to help answer this question.
What types of data are processed, stored, and transmitted by the system? Systems often contain a great variety of data types. Common data types include financial, legal, customer, and publicly available information. Some types of information are more regulated than others. For instance, privacy information is often controlled by a multitude of regulations. By contrast, there may be no regulations at all for an organization’s proprietary information. What makes this more interesting is that an organization would likely value proprietary above privacy information. Local policy might dictate rigid requirements to protect information affecting the future of the company. Managers often recognize the importance of protecting information sensitive to corporate survival. However, the organization is still compelled by higher authorities to protect other types of information in their custody. Knowing the types of information processed, stored, and transmitted by the system is essential to identifying the needed security requirements.
Where are the physical and logical locations of the system and its users? A system may reside in one country and service customers in another. In some instances, a multinational corporation may have an internal system spanning multiple countries. In both cases, the physical and logical locations of the system and its users may require very different standards to be in place. For example, privacy laws in the European Union are typically more rigid than those in the United States. A system in the United States recently extended to the European Union would incur new security requirements. This type of situation is further complicated when a security practitioner must consider foreign laws and regulations levied in a language not understood.
With answers to the prior questions in hand, the security requirement scope should now be manageable. The type of information to be searched to discover the security requirements has already been alluded to. Laws, regulations, industry standards, and organizational policies are the primary sources of security requirements. These types of requirement sources are often compulsory. That is to say, they must be followed.
Aside from the Internet, there are other resources available to help identify security requirements. Finding security requirements can be as easy as asking a question. The following are a few groups who can get you going in the right direction:
Organization management: Various business units in an organization are often focused primarily on regulations affecting what they do. Functional managers with a significant influence or stake in the system are a starting point to discover requirements.
Informal leaders: These are the go-to people who always seem to have an answer or can at least point you in the right direction. Many people shy away from management roles, but possess voluminous knowledge on a topic. They are often an excellent source of information that is sometimes overlooked by managers focused on other priorities.
Legal department: Organizational lawyers are on guard to keep their employer out of legal trouble. They are one of the best placed to identify applicable laws and regulations or at least point you to sources to find what you need. While their focus is the law, do not rely on them exclusively. Although lawyers are quite knowledgeable, they do not know it all. It is probable that they are unaware of the technical security requirements that might exist. Furthermore, a lawyer lacking an in-depth understanding of technology would have difficulty translating or interpreting a law into a technical security requirement.
Professional associations: Industry groups and trade associations often provide their members with areas to post and answer questions. Periodic meetings of these groups offer another forum to discuss issues with people in the same business arena. A security professional does not need to have access to every type of professional group. It is quite likely that at least a few people within the organization already have access to associations in your industry. Talk with those coworkers and ask them to seek feedback from their peers. Better yet, attend some meetings with the coworker and ask questions yourself.
Industry partners: Organizations sharing data has a mutual interest in protecting it. The IT managers and security professionals from partnering organizations may have identified requirements not immediately apparent or previously considered. An open dialog with a business partner is also a good way to learn of the pitfalls that they might have encountered with a particular requirement.
Regulatory agencies: The statement, “Hello, we are from the government and are here to help,” is not something that many people want to hear. However, most people in government positions are actually human, have families, and can be compassionate. While some managers cringe at the thought of contacting a regulatory agency, it is not something to be feared. Government agencies are a legitimate source and are often quite helpful. Just asking a government agency for information does not imply guilt, incompetence, or wrongdoing (at least in most democracies). Many government workers are quite professional and are happy to answer your questions. After all, their job is to serve the people. Your tax dollars are likely paying their salary. Doesn’t it make sense to leverage that money to help you achieve your own work objectives?
External sources of requirements arising from laws and regulations are the most obvious sources. However, the number of security requirements that the organization creates for itself may be surprising. Within an organization, there are a variety of sources that can be used to obtain security requirements. The security professional should consider:
Organizational policy: Organizational management is just as likely as government bodies to establish its own laws driving security requirements. High-level policies are sometimes created to mimic other laws and requirements. This is an efficient approach to guide the organization into compliance with government laws and regulations. While organizational policy might only paraphrase higher laws, in some instances, additional security requirements will emerge.
Mission statements: Ordinarily, a mission statement is not considered policy. It is a way for management to convey an overall strategy guiding the workforce. In this regard, it might feel awkward to consider a mission statement as a security requirement source. However, organization and business unit mission statements can hint at desired security requirements. This can reveal an underlying concern that business activities should support security goals.
Business objectives: Short- and medium-term activities of an organization sometimes include security attributes. For instance, an organization wanting to expand into E-commerce will incur security requirements. Although not specified, the use of Secure Sockets Layer (SSL) and the protection of the associated certificate are needed. Digital transactions involving credit cards may also necessitate compliance with the Payment Card Industry (PCI) data security standard.
Contractual obligations: Contractual agreements with customers, business partners, and suppliers sometimes require compliance with particular security requirements. An organization hosting a system for the U.S. federal government will need to comply with the Federal Information Security Management Act (FISMA). Retail business partners may require acknowledgement of compliance with PCI standards or that national privacy standards are met. Managers associated with the contracts should be able to elaborate on particular requirements agreed to by the organization.
User needs: Systems exist for users because they are the primary group driving the requirements. In some cases, users might need remote access to the system. The dramatic proliferation of mobile devices pushes system boundaries into higher-risk scenarios. Savvy users and system managers recognizing the risk will establish security requirements in conjunction with functional requirements. However, this does not always occur. Often, functional requirements are specified without regard to security. This is still not a problem, because a functional requirement often has an associated security requirement buried somewhere in the policy. Understanding what users want and need helps the security professional identify previously unconsidered security requirements.
Risk acceptance: A system with a known flaw represents an operational risk. In some cases, the risk is considered small enough to be inconsequential. At other times, a risk might be concerning, but addressing the threat or vulnerability might be too costly or infeasible. In either case, managers accept the risk and continue operations. The management’s decision to continue operations despite the risk may represent a type of operational policy for the system. The management could reason that a particular threshold is acceptable for continued operations. A boundary or threshold on a security requirement might imply an additional security requirement for the system. Ongoing acceptance of a particular risk can therefore create new security requirements.
Another place to obtain security requirements is from the system itself. A review of the system’s documentation and its architecture can also reveal security requirements. Sometimes, the system’s documentation does not fully imply the need for security. Security controls built into a system might also allude to forgotten security requirements. After reviewing the documentation and the system, ask yourself and others:
Why was the system built this way?
Why is a particular security control required?
What is the purpose of a given security configuration?
These questions might lead to written policies, point to risk-based decisions, or reveal techniques used to counteract specific threats. In any case, if it is built into the system and is needed, it is implied that it is required.
Many of the aforementioned sources are derived from external authorities and organizational people, processes, and policies. There is one final source that ought to be considered: You, the security professional. Aside from a chief security officer, most security professionals do not possess the power to promulgate policy as they see fit. However, those with education and experience should not discount their own worth and that of their peers. It is worth considering:
Publications: Peer-reviewed literature from journals and conferences often provide innovative solutions to ongoing problems. Some security books also suggest ways to handle vexing security issues. It is not unusual for research solutions and recommendations to emerge years ahead of policy makers. The guidance provided by these sources is valuable and should not be discounted.
Best practices: Each year, numerous external groups form to address the ongoing problems in the realms of cyber security and information security. These groups combine talented people from a variety of industries to solve vexing problems. For example, the Center for Internet Security developed security configuration benchmarks for a wide variety of technologies. The Open Web Application Security Project, as another example, promotes secure design for Web-based technologies. The work by these groups and others provides great value to the security community and society at large. Their recommendations ought to be considered along with traditional security requirements.
Experience: Your history as a security professional and the advice of your peers are not without value. Over time, security professionals see patterns of what does and does not work in technology, society, as well as our current organization. Seek out the advice of peers in new situations. Share with others things that you have learned. By no means will experience alone be counted directly as a security requirement. However, the advice we give can affect decision makers and the outcome of policy.
Many security requirements can be discovered by simply networking with other professionals. Talking to internal and external professionals at all levels enables a wider dynamic viewpoint. Networking with others expands the discovery possibilities and is more efficient than relying on a Web-based search engine alone. Life does not occur in a vacuum and neither should the search for security requirements.
Analyze Phase
The quest to identify security requirements can result in a multitude of sources. Undoubtedly, sources emerge from diverse authorities. Many policies express similar requirements in very different phrases. But, do they really say the same things? Do policy statements express the same requirements? The purpose of the analyze phase of the SRAM is to break down policies into their smallest components and capture the explicit security requirement of each policy.
Written policies are a collection of sentences expressing the authority’s security objectives. We refer to each sentence in a policy as a policy statement. A single sentence can express one or more security objectives. A policy statement with a single objective is itself a basic security requirement. Policy statements with multiple objectives must be broken down until each objective is expressed as a unique security requirement. The process of breaking down a policy into security requirements is called policy statement decomposition.
Security requirements obtained from policy statement decomposition still require further analysis. Comparisons must be made between similar security requirements to infer any uniqueness. One way to facilitate this is to compile the results into a security requirements traceability matrix (SRTM). This provides a security professional with a means to track, manage, analyze, and interpret the relevant security requirements.
Repetition of security requirements from divergent sources and authorities will definitely occur. It is neither efficient nor relevant to list the same security requirement multiple times in the SRTM. The final step in the analyze phase is to combine similar requirements through interpretation. Contextual differences between individual security requirements may imply different things. Some degree of reasoning is needed to interpret the similarities and differences between security requirements. The ultimate goal is to eliminate redundancy in the SRTM through the use of analysis guided by security professional reasoning.
Decomposition
Policy statements can be simple or complex. Simple policy statements contain a single objective and require little or no interpretation. By contrast, a complex policy statement may have multiple objectives or require extensive interpretation. Vague statements can be challenging to interpret when multiple valid interpretations are possible. Consider the following security requirement obtained from the National Institute of Standards and Technology (NIST) Special Publication 800-53, Recommended Security Controls for Federal Information Systems and Organizations, Revision 3. For our purposes, we shall disregard the supplemental guidance and control enhancements specified in NIST 800-53.
AU-8 time stamps: The information system uses internal system clocks to generate time stamps for audit records.
This policy statement contains only one security objective. Although some might argue the interpretation of internal clocks, the statement requires little or no interpretation. Now consider the following NIST 800-53 policy statement:
AU-3 content of audit records: The information system produces audit records that contain sufficient information to, at a minimum, establish what type of event occurred, when (date and time) the event occurred, where the event occurred, the source of the event, the outcome (success or failure) of the event, and the identity of any user/subject associated with the event.
This is an example of a complex policy statement. It contains multiple security objectives. Some might feel that alternate degrees of interpretation are possible within the individual objectives. For instance, the “where” an event occurred might refer to the location of the log, the location of the subject associated with the event, or both. Most, however, would generally agree that “where” refers to the location of the subject. Breaking down this policy statement into the individual security requirements provides the following:
1. The information system produces audit records that contain sufficient information to establish:
a. What type of event occurred
b. When (date and time) the event occurred
c. Where the event occurred
d. The source of the event
e. The outcome (success or failure) of the event
f. The identity of any user/subject associated with the event
This single policy statement generated six individual security requirements identified by 1.a through 1.f. Decomposing down to this level enables granular identification of the security requirements for a system. This is especially helpful when manual verification of the security requirement implementations is needed. More importantly, to the SRAM, decomposition to this level facilitates direct comparison between similar security requirements.
SRTM
An SRTM is a tool used to help facilitate the comparison and analysis between security requirements. An SRTM is nothing more than columns and rows used to organize the security requirement details. A spreadsheet is ideal for this task. Keep in mind that the overall goal in this phase is to list a security requirement only once in the SRTM. To accomplish this, consider a spreadsheet with the following types of defined columns:
Group: A collection of similar or related security requirements
Identifier: A unique label for the security requirement
Name: A short name representing the policy statement or requirement
Description: An individual security objective from a decomposed policy statement
Source: The abbreviated name of the source document where the policy statement was obtained
Related: Additional sources stipulating the same requirement
Group
Select group names that collect security requirements areas into focused management areas. Ideally, a single organizational unit would be responsible for all the requirements in the group. Arguably, some of the suggested groups that follow could be combined. However, what matters is that the requirements are identified once and are grouped according to how those requirements might be managed. Where practical, it is best to have one organizational unit responsible for similar requirements. This helps to reduce conflict and confusion about who is responsible for which requirements. There will be overlap. For instance, those responsible for managing network devices (network security) will still be required to implement account management (access control) security requirements. The suggested groups are
Access control: This group covers most aspects of account use and management as well as access enforcement. Policies covering granular concepts, such as separation of duties, least privilege, roles, rights, and permissions, are candidate members for this group.
Audit and accountability: Policy statements on the types of auditing are included in this group.
Configuration management: Requirements in this collection are critical to system integrity. Policies addressing hardware and software inventories as well as required security settings are common examples. Configuration management guidance typically requires documented processes for approving, developing, testing, deploying, and validating changes to a system.
Contingency planning: This group encompasses a wide range of requirements related to threats against system availability. Policies related to disaster recovery, business continuity planning, and business resumption planning are closely related topics that could be included in this collection.
Identification and authentication: Requirements covering the creation and management of account names, authenticators, and tokens are placed in this group. Security requirements specifying account-naming conventions, password complexity, and authenticator protection against disclosure are common examples.
Incident response: Some organizations have a core team that responds to instances of malware, data breaches, and denial-of-service attacks. Collecting incident response types of requirements into a single group is advisable.
Intrusion detection: Operational monitoring for intrusions implies network security. Response to a detected intrusion implies incident response. It is reasonable to view intrusion detection as a balance between network security requirements and those for incident response. An intrusion detection function is handled as a subelement function of the network security group in some organizations. For this reason, it is reasonable to gather intrusion detection security requirements into their own group.
Network security: This group is used to identify the security requirements related to telecommunication and networking equipment. Security requirements focused on Layer 3 and below of the Open Systems Interconnection model are candidates for this group.
Operations security: Security guidelines for everyday system management can be placed in this group. System availability is usually the focus of those assigned to an operations group. In this regard, requirements for failover, shadowing, redundancy, backup, and recover are prime candidates for inclusion.
Personnel security: Policies specifying the controls and requirements of personnel using the system are included in this group. Security requirements involving human resources functions, such as background checks, duty rotation, terminations, and transfers, are examples of personnel security items to include.
Physical security: The collective requirements for barriers, deterrents, and detective physical controls make up this group. In some cases, a system is subject to rules that specify in great detail the makeup of the physical components required to protect a system. For example, some physical security requirements delineate facility perimeter controls, intrusion detection, fire detection/suppression, and even construction requirements for sensitive processing areas. This group should also include the requirements for environmental factors, such as facility power, lighting, temperature, and humidity controls.
System security: Explicit guidance for system hosts and devices are included in this group. For example, specifications for host-based controls, such as encryption, antivirus, and security configurations, are candidates for inclusion.
Security management: An organization might be required to implement a security program overseeing all aspects of security management. These types of requirements might specify the appointment of a chief security officer, Information system security officers, or internal system auditors. In many cases, these broad requirements will intersect with or have management authority over groups with related security requirements.
Security awareness and training: Security requirements specifying the training needs for managers, users, developers, and administrators are contained in this group. In large organizations, training is sometimes handled by a dedicated personnel office. In smaller organizations, these requirements are handled by those with security management responsibilities. In either case, collecting the requirements into the same group enables efficient management of awareness and training programs.
Identifier
The security requirement in each row should be unique. The label assigned to each requirement should be unique as well. Ideally, the label should contain some meaningful information to help identify its relevant group. One way to do this is to construct the identifier to contain an abbreviation of the group name. For instance, a requirement in the Audit and Accountability group could be to use “AA” as the group abbreviation. Consider again the auditing security requirement previously mentioned:
The information system produces audit records that contain sufficient information to establish:
a. What type of event occurred
b. When (date and time) the event occurred
c. Where the event occurred
d. The source of the event
e. The outcome (success or failure) of the event
f. The identity of any user/subject associated with the event
Suppose this is the twelfth security requirement in the audit and accountability (AA) group of the SRTM. Each requirement would then be uniquely identified as:
AA-12.a
– The information system produces audit records that contain sufficient information to establish what type of event occurred.
AA-12.b
– The information system produces audit records that contain sufficient information to establish when (date and time) the event occurred.
AA-12.c
– The information system produces audit records that contain sufficient information to establish where the event occurred.
AA-12.d
– The information system produces audit records that contain sufficient information to establish the source of the event.
AA-12.e
– The information system produces audit records that contain sufficient information to establish the outcome (success or failure) of the event.
AA-12.f
– The information system produces audit records that contain sufficient information to establish the identity of any user/subject associated with the event.
Name
The short name is an abbreviated phrase representing the policy statement or requirement. Again, this should also be unique to aid in understanding the relevance. The prior list of security requirements could have names assigned as follows:
AA-12.a
– Event type
AA-12.b
– Event date and time
AA-12.c
– Event location
AA-12.d
– Event source
AA-12.e
– Event outcome
AA-12.f
– Event subject
Description
This field contains the actual language of the requirement. Remember, this is the individual security objective from a decomposed policy statement.
Source
Use an abbreviated name in this field of the source document containing the policy statement. Be mindful that obscure abbreviations may need to be identified elsewhere. Include revision numbers, versions, or dates of the policy to distinguish between published versions.
Related
Security requirements that are related but not listed elsewhere are included in this field. The related requirement must be equivalent or a subset of the source with which it is associated. This will be discussed in detail next.
Table 10.1 shows how the audit requirement would look in the SRTM.
Requirements Consolidation
A fully populated SRTM will undoubtedly contain redundant statements or objectives. At first, it may seem appropriate to simply eliminate one objective in favor of another. This has the first disadvantage of not appropriately acknowledging the valid requirements. It has the second disadvantage of potentially being inexact. On close examination, similar security objectives often have subtle differences. These differences may imply unique requirements. The goal then is to consolidate the requirements that are identical and distinguish those that are unique.
The various security policies obtained likely make similar statements. Whenever possible, we combine policy statements together by making one the source and the other “Related” in the SRTM. A careful review is needed to determine if similarly worded statements actual imply the same meaning. Consider the following three policy statements recorded in a hypothetical SRTM in Table 10.2.
SS-1 requires scanning of e-mail attachments only before they are opened. This statement has some glaring weaknesses that should be questioned. For instance, if the attachment is not opened, must scanning be conducted? Likewise, is scanning required at all for the e-mail body itself? Given the threats regarding phishing, spyware, spam, and active content embedded in e-mail messages, scanning the e-mail message body is imperative.
Table 10.1 Example Breakdown of Audit Requirement
SS-2 addresses some of the shortcomings of SS-1. At first glance, it may appear that the attributes of SS-1 are completely addressed by SS-2. Suppose SS-2 is decomposed into its two principle components represented as SS-2.a and SS-2.b, as seen in Table 10.3.
In this case, SS-1 is not related to SS-2.a, but has a commonality with SS-2.b. Neither SS-2.a nor SS-2.b indicate when scanning must be conducted. SS-1 does contain an additional element not found in SS-2.b. In this regard, it would be proper to subordinate SS-2.b to SS-1. These two requirements would be rewritten as shown in Table 10.4.
Table 10.2 Hypothetical SRTM
Table 10.3 Hypothetical SRTM—Decomposing
The identifier for P2 is returned back to SS-2 because it cannot be further decomposed. P2 is noted as related to P1 because part of its original statement can be contained within the P1 statement.
SS-3 stipulates two requirements:
All incoming e-mail must be scanned for all threats.
All outgoing e-mail must be scanned for all threats.
Clearly, the policy folks got it right, coming and going. However, we are presented with two issues. First, does e-mail, in this requirement, also constitute attachments? Second, what exactly are “all threats”? This is where some degree of professional judgment must be used to interpret policy.
It is not unusual when someone refers to e-mail to also mean attachments. By contrast, when someone refers explicitly to an e-mail attachment, they generally are not referring to the e-mail message body. In this case, it is not unreasonable to interpret the term “e-mail,” in the case of SS-3, to also imply attachments. After all, the most damaging malicious code commonly arrives in e-mail as an executable attachment or as an exploit for a vulnerability related to the type of file sent.
Table 10.4 Hypothetical SRTM—Combining P2 with P1
Do we really know “all threats” related to e-mail? Arguably, we have not seen every conceivable abuse that could be sent via e-mail. But, we know that malware (includes spyware), phishing, and spam are ongoing problems associated with e-mail. Our interpretation, therefore, is that “scanned for all threats” implies that a tool looks for known types of threats, such as malware, phishing, and spam. We bracket these interpretations within the decomposed P3 description to provide clarity and show that they are not part of the original statement. We also change the name fields in Table 10.5 to better represent the decomposed statements.
Table 10.5 Hypothetical SRTM—Interpreting P3
Table 10.6 Hypothetical SRTM—Consolidated Requirements
Moving along, we now compare SS-1 and SS-2 to the decomposed elements of SS-3. Requirement SS-1 is related to SS-3.a because both require antivirus scanning before an attachment is opened. SS-3.a contains additional attributes, such as handling nonmalware threats, which are not part of SS-1. In this case, SS-1 can clearly be subordinated to (i.e., contained within) SS-3.a.
SS-2 is still a little troublesome because it does not tell us at what point an e-mail must be scanned. It only says that it must be accomplished. Once again, we could reasonably assume that scanning must be conducted, at a minimum, when the e-mail is received. Fortunately, it is irrelevant in this case. It makes no difference what SS-2 requires because SS-3.a and SS-3.b got it covered, coming and going. And, because SS-3.a and SS-3.b have additional attributes, SS-2 can be subordinated to both. Finally, SS-3.a becomes SS-1.a and SS-3.b is identified as SS-1.b.
The original security requirements are now shown decomposed and combined in Table 10.6.
Associate Phase
In the analysis phase, candidate policies with broad applicability are reduced to their security objectives, resulting in a multitude of security requirements. The many candidate security requirements populating the SRTM have some degree of relevance to the system according to the attributes used with the initial selection process. Aspects of a given policy are likely to be applicable, but perhaps not the whole source. However, is the SRTM complete? Were all needed requirements captured? The gap between the known requirements and those that are not known must be closed.
The purpose of the associate phase is to determine what security requirements are needed for a given system. This is accomplished from two points of view. The first perspective evaluates the known requirements. The second viewpoint seeks what is missing. Each perspective can be considered by asking the following questions:
Which security requirements in the SRTM are applicable or not to the system?
Which requirements are suitable?
What security requirements are missing from the SRTM?
What are the requirement gaps?
Security Requirement Suitability
Organizations are compelled to follow policies. Any given policy will express multiple security requirements. Some of the requirements will simply not apply. For example, a policy may express a number of rules for wireless nodes along with other basic network security guidelines. If, however, the system does not implement wireless technology, then these requirements would not apply. Furthermore, if another policy forbids the use of wireless technology, then these particular security requirements would not be suitable. The determination of a requirement’s suitability is affected by aspects of the system and other security requirements. Decisions to include or exclude a security requirement should be documented.
It may seem easier to simply remove or hide a particular security requirement from the SRTM. Why even bother with documenting the decision? It is important to remember that rapid changes in systems are a way of life. This often has the undesirable effect of shifting requirements too. Tracking the reason for including or excluding a requirement supports continuity of management decisions. The question “Why did we include/exclude this requirement?” is bound to come up when prior decision makers have moved on. An easy way to support the tracking of decisions is to append the following columns in the SRTM:
Target purpose: Tracks the interpreted scope of the requirement with respect to the system.
Requirement validity: Determines the applicability of the requirement to the system.
Validation justification: Identifies other information shaping the determination.
Comment: Records clarifying statements for future reference.
Target Purpose
A suitable security requirement has a corresponding purpose with the system. This means that the security requirement has an intersecting purpose with the system. This column records an interpretation of how the requirement most significantly impacts the system. In other words, the purpose of the requirement is deemed to primarily affect the system from a particular perspective. These perspectives pertaining to the system can be broadly categorized as
Intended operations: Security requirements that are focused on people and processes using and managing the system. These include user types and anticipated use of the system. A requirement from this perspective may impart guidance regarding various types of system users. Or it might provide guidance on the proper use or management of the system.
Target data: Not all data is created equal. Some types of data can have very explicit, if not unique, security requirements. This perspective is reserved for the security requirements that are directed at a class of sensitive data. Data related to an individual’s privacy, legal, financial, or health are example classes of sensitive data commonly addressed by unique security requirements. In some cases, a particular type of data is prohibited. Requirements of this type are also good candidates for this category.
Functional capability: The physical and logical attributes of a system are some of the best ways to implement security requirements. System architecture, such as physical location, connectivity, and technology, can be used to directly enforce policy. A security requirement addressing a particular technology is a prime candidate for this category. However, technology-specific security requirements are the exception as opposed to the rule. More typically, security requirements specify concepts enforceable by a wide range of technologies. For example, password lengths are a functional capability supported by many technologies. Policies expressing minimum requirements are quite common. Security requirements that are enforceable by system design and technology implemented are best placed in this category.
Requirement Validity
As previously mentioned, not every requirement from a given policy applies to all systems. The decision and reason to include or exclude a requirement should be documented. Recording the reason conveys, to some extent, the thought process used to arrive at the decision. Most importantly, recording this type of information illustrates a degree of due diligence with respect to the security requirements. Within this column, the applicability of a requirement objective is identified as one of the following:
Applicable: The security requirement applies to the system. Aspects of the requirement apply to the operational, data, or functional attributes of the system.
Unsuitable: The requirement objective does not address a planned or implemented functional attribute of the system. For example, E-commerce security requirements would not apply to a system not processing financial transactions and without a public-facing interface (e.g., E-commerce Web server).
Prohibited: Attributes of the requirement are not allowed. Suppose a security requirement discusses appropriate uses of peer-to-peer (P2P) technology. However, P2P may be prohibited in the target system. In this case, any P2P security requirements would be marked as prohibited.
Irrelevant: The requirement objective is not pertinent to the system. This choice primarily applies to data types. For instance, a security requirement discussing health-related information probably would not apply to a system supporting E-commerce.
Validation Justification
A security requirement applies when it touches on an aspect of the operations, data, or functionality of the system. A requirement would not apply when it contracts other guidance or fact. Pointing to the relevant guidance is needed to support the requirement validity. Supporting evidence is needed to affirm that the decision to include or exclude a security requirement was done properly. Evidence to support the decision is best obtained from:
Existing policy: It is not rare for security requirements to contradict each other. For example, one requirement might call for passwords with a minimum length of six characters while another requires eight. Generally, one policy trumps the other or the more rigid requirement becomes the standard.
Design documentation: Most validation justifications for a requirement validity that is applicable would point to this justification. System documentation should contain enough information to allude to the intended operations, data types, and functional capabilities of the system. Likewise, the security requirements, unsuitable or irrelevant, would also rely on design documentation for justification.
Security documentation: Specialized documents, such as security plans, configuration guidance, and other standards, are reliable sources. These sources are particularly useful when they describe implemented security controls directly related to the security requirement.
Management decision: Risk acceptance and the authority to operate statements are prime examples of management decisions conveying what is and is not allowed. Sometimes, managers express decisions in memorandums and other less than formal communications. Regardless of the medium, communications representing a management directive are a valid means of justifying requirement validity.
It is important to note that evidence supporting validation justification constitutes something in writing. That something becomes an artifact supporting the due diligence decision to include or exclude a candidate security requirement. The artifact of the evidence should be clearly identified. In this column, record the path to the artifact document supporting the justification of the requirement validity.
Comment
Sometimes, a few words of wisdom can clarify a murky situation. Use a comments column to record information that may help others better understand the decisions made or find pertinent documents. Avoid recording anything that does not clarify and contribute to understanding the decisions made.
Security Requirement Gaps
Policies are broadly applicable, but this does not imply that they provide comprehensive coverage. In some cases, a policy may not go far enough to require adequate security. The security objectives stated are weak. This occurs when those crafting the policy seek to make it broadly applicable. Sometimes, the intent is to set a low threshold in the hope that the system owners will build on it. A nonexplicit policy can create unintentional weaknesses in a system. In other cases, policies simply do not address critical security needs. The policy is often far behind the rapid advancements of technology and threats. System owners may not have considered the need for additional requirements. This has the potential effect of introducing weaknesses in the system as well.
Weak Security Objectives
Vague security requirements are a common occurrence. It is important to consider how a security requirement might be enforced by a system or put into practice. Begin by comparing the requirement to the system design and the security architecture of the system. Typically, a security requirement can be implemented any number of ways. For instance, our audit requirements given in Table 10.1 are a good example of this situation. Clearly, auditing must be implemented, but how and where? Places where auditing can be implemented include:
Applications
Workstations
File servers
Systems services
Databases
E-mail servers
Web servers
Network devices
Where should auditing be implemented? Should it be in all these locations or only at selected ones? To some extent, the decision becomes a judgment call. Recall that AA-12.f from Table 10.1 states:
The information system produces audit records that contain sufficient information to establish the identity of any user/subject associated with the event.
This could be loosely interpreted as, “Turn on auditing wherever it’s needed to identify an attacker” or it might also be implying, “Turn on auditing in at least one place to identify who is doing what.” The problem here is that we have the what of auditing but not the where. This vagueness hinders interpretation and may result in a poor implementation decision.
The common ailment of weak security objectives is a lack of specificity about the breadth or the depth of an implementation. Think of breadth, of how wide a requirement applies. How many different types of things or like items should implement the requirement? Insufficient breadth quickly translates into insufficient coverage. By contrast, depth refers to how many layers into an item the requirement should be implemented. Undetected or unmitigated compromises become possible when depth is missing. Inadequate depth implies a lack of defense-in-depth.
Missing Security Requirements
It is unlikely that policy makers will keep up with the advancing technology and the evolving threats. This is immediately apparent to the security practitioner who is asked to evaluate a new technology implemented in a system. It becomes even more painfully apparent when the technology becomes a new attack vector. However, missing security requirements need not arise from something new. The need for new security requirements can be found over time through common system and security management activities. Some of the activities providing the best likelihood of identifying missing security requirements include:
System changes: A change itself may call out for a new security requirement. In some cases, investigating a change reveals another system weakness occurring due to a lack of security requirements.
Security assessments: Skilled security assessors sometimes discover a unique attack vector to compromise a system under test. Trivial attack vectors are the most serious and require mitigating controls. Explaining the importance of mitigating the weakness to system managers is sometimes challenging. This alone cries out for explicit security requirements needed to close the gap.
Risk assessments: New threats should be addressed in a system’s periodic risk assessment. The assessment should seek to determine if existing requirements adequately address new threats. Risk assessment results should call for new security requirements or security controls when threat mitigation is deemed insufficient.
Mission/system objectives: Changes to organizational and system objectives may introduce weaknesses insufficiently addressed by policy. Innovative uses of technology to meet mission objectives can place systems in locations not previously considered. Explicit requirements for protecting the system in a new environment might not exist. Similarly, integrating a system with new technology to meet expanding objectives is another challenge. Integrated technology can make a new weakness apparent. However, a policy identifying the appropriate controls for this instance may not have been conceived as of yet.
Security gaps are serious and should be addressed as quickly as possible. Whether the gap arises from weak statements or missing requirements, proactive measures are needed. Those necessary measures are handled in the next phase of the SRAM.
Integrate Phase
Security requirements that are identified, analyzed, and associated with the systems are ready for integration. The first step is to ensure that proactive measures are undertaken for the identified gaps. Next, the formal integration of policy needs and requirement gaps is merged with the system security policy. Lastly, the system security plan is updated to reflect the security requirement changes.
Proactive Measures
Security requirement gaps should be addressed as quickly as possible. There are a number of avenues that a security professional can take to proactively close a gap. Some of the common methods used include:
Policy changes: Work with local management to create a policy or standard stipulating the new requirement. This could mean an amendment to an existing policy or the creation of something new. In some cases, it could also mean removing defunct requirements from an existing policy.
Design alterations: Coordinate the change of the system design or security architecture. Removing software or hardware is sometimes an easy fix to a problem. In other situations, applying existing security controls in a manner compliant with an existing policy to assuage the problem is another approach.
Risk management: In some organizations, risk assessments are the primary tool used to push for changes affecting the security gaps. Formal risk management has the advantage of documenting threats leveraging a policy gap and the potential impact. The potential magnitude of harm may be sufficient to warrant immediate changes to the system as well as the policy.
Management decisions: A memorandum from top management can be enough to require a change to be made. While this might not carry the finesse of a full risk assessment, it can help expedite changes to accommodate a critical gap.
System Security Policy
The identify phase of the SRAM suggested business objectives, user needs, and risk acceptance, as well as education and experience, as possible security requirement sources. Ordinarily, these policy needs would not be referred to directly as security requirements. Legitimate security requirements come from an authority. This is to say, it should be specified in writing by organizational management or some governmental body. A policy need might be considered a gap when serious. However, disagreements over severity and interpretation may dissuade management to take immediate action. In any event, policy needs should be given appropriate authority through policy. Since these needs are particular to a given system, they should be included in the system security policy.
A system security policy is specific to a particular system. This type of documentation is an underused tool essential to the SRAM. It should contain the necessary requirements not identified in other policies or security requirements. Requirements in the system security policy serve to bridge the gap between the system and the applicable security objectives from other policies. It can also be used as the source to record policy interpretations. This makes it an ideal reference for the validation justification as well.
System Security Plan
The final step in the SRAM is to update the associated system security plan. Changes to the security requirements affect the security controls designated through the system security plan. A comparison of the security requirements versus the planned and implemented controls is needed to ensure that the gaps between the policy and the security architecture are identified and accommodated when needed.
SRAM Cycle
The intent of the SRAM is to support continuous monitoring of the system. This cycle should be periodically repeated as necessary. There are a number of events that should trigger a run through the cycle. Some of these event triggers include:
Known policy changes: Updates to any policy in the SRTM is a good time to review all associated policies.
Risk assessments: Changes to risk posture or new threats may reveal security requirement gaps.
Security assessments: System weaknesses or trivial attack vectors are another source of potential security requirement gaps.
System changes: Adding or removing system components could change the security requirement validity.
Defined period: Minimally, the SRAM should be associated with a key anniversary date, such as a system accreditation or authorization cycle. In some cases, a mandatory annual review may be more appropriate.
Summary
A security requirements analysis is an important function in security management. Improper identification of requirements can at best make a system an easy target for auditors and at worse enable an exploitable weakness. Rapid advances in technology and threats quickly date many policies. Using a defined SRAM is one way to implement continuous monitoring to counteract the rapid changes. The SRAM consists of phases that Identify, Analyze, Associate, and Integrate life-cycle security requirements. The identified security requirements must be analyzed for inclusion in the SRTM. Suitable security requirements contained in the SRTM are those associated with the system. Lastly, integrating applicable security requirements and mitigating identified gaps into a system security policy and system security plan are essential to security management.