The Unified Compliance Framework's underlying belief is that all authority documents are expressed as lists of controls, and that controls can be abstracted in order to gain a better sense of their intent.

To control is an activity conducted to bring into check (to manage or to verify), or to constrain (to restrict or confine) something. In order to abstract a control, each control can be broken down into two parts,

• the action and demonstrable outcome being called for (the basis of the control) as well as

• the parameters associated with the action

Here are two examples with the control action bolded, the demonstrable outcome in italics, and the parameters in brackets:

The risk assessment process is conducted in two steps. The first step defines the boundary of the environment, determines the scope of the assessment and selects the appropriate methodology to use. In step two the risk analysis is conducted. The risk analysis can be broken down into asset identification, threat and vulnerability identification, likelihood assessment, and risk measure... The [Reference and Further Reading Sections of this document provide some information on LAN threats and vulnerabilities] to use when conducting the risk analysis.

Establish a process to identify newly discovered security vulnerabilities, for example, [subscribe to alert services freely available on the Internet].

As you can see, the action, or methodology which forms the basis of the control in both of the above examples is to identify vulnerabilities, wither through a simple process or through a risk analysis. Whether the action is to follow a strict manual process or to run an automated tool, or follow some risk framework, the effect is the same - maintain an active and up-to-date vulnerability list - which forms the basis for the demonstrable result. The parameters for the first example are elucidated from an additional guide. For the second example, the parameters are found by subscribing to alert services. In either case, the actual control is the act of identifying vulnerabilities with the demonstrable result be a list of security vulnerabilities. It is only the parameters that differ.

Content decisions

The authority documents that we work with are anything but cleanly written. Some authority document references are well formed and others are not. Laws, as one judge put it, are meant to be "prescriptively ambiguous." On the other hand, standards are often over-engineered with multiple references to the same control (turn off FTP for example) written into the standard at various places because the control is aimed at different targets (such as the mail server, the database server, etc.). Fundamental to our content decisions is the understanding that there is no underlying or naturally "correct" pattern to follow when interpreting the threading in of authority document references into a unified compliance framework.

With this in mind, we have developed certain Rules of Thumb for our content decisions. We use these to determine (and then check) how to interpret the authority documents we need as well as how to thread those documents into the UCF's framework. We will present each of our rules in the order in which they must be examined and implemented when reading and commenting on each authority document's rules.

Rule 1: A control is a single activity that produces a demonstrable outcome

In its simplest terms, to control is an activity conducted to bring into check (to manage or to verify), or to constrain (to restrict or confine) something, the results of which brings forth a demonstrable outcome. Therefore, any authority document reference that is not actionable or that does not create a demonstrable outcome is excluded from being listed as a citation.

Example of non-actionable reference

The Payment Card Industry's Data Security Standard (PCI-DSS) states in § 1.1 that the organization must create a firewall configuration standard that includes multiple parameters. However, the demonstrable portion of the standard isn't listed in § 1.1, but rather in the sub-sections that follow (§ 1.1.1 through 1.1.9). Therefore, because this paragraph isn't demonstrable, it is omitted from the UCF in favor of the subsection controls.

Example of an actionable and demonstrable reference (i.e., a control)

§ 1.1.2 of the PCI-DSS states that the organization should ensure its network diagrams are up-to-date. This is a single action (maintain up-to-date diagrams) that is demonstrable (define up-to-date and ensure the diagrams meet the criteria).

Rule 2: An authority document reference must be decomposed into discrete actions with discrete demonstrable outcomes

Because each control is a single action that creates a single demonstrable event, any reference found within an authority document that contains multiple actions (resulting in multiple demonstrable events) must be decomposed into a series of discrete citations to match the discrete controls.

Example

Visa's Payment Application Best Practices, § 10.1 states that the merchant's firewall needs to be configured properly; ensure that it is never disabled; and if a modem is attached, to only allow the modem connections to be enabled during a manual period of time to allow custom downloads.

C1: Configure firewalls, routers, and networking equipment to follow organizational compliance mandates in order to protect confidential information and systems.

C2: If a modem is installed, disable automatic dial-in access to the computer.

Rule 3: Multiple authority document references must be combined into a single UCF control reference if the control effect is the same even though the methodologies are different

Many times authority document authors will write instances of controls that use different mechanisms or have different targets, but achieve the same effect.

Example

§ 11.4 of PCI-DSS states that the organization should use network intrusion detection systems, host-based intrusion detection systems, and intrusion prevention systems to monitor all network traffic and alert personnel to suspected compromises. The effect of the control isn't to monitor for its own sake; it is to allow the staff to take action based upon the alert found during monitoring. Farther down, in § 12.9.5, PCI-DSS calls for the organization to implement an incident response plan that includes alerts from intrusion detection, intrusion prevention, and file integrity monitoring systems. Again, the control effect isn't to have monitoring happening for monitoring's sake, but to allow the organization to take action (incident response) based upon the alert. Therefore, the UCF control would be written as such and would include a cross reference to both the § 11.4 and the §12.9.5 references:

C: Maintain intrusion detection and incident monitoring and response capabilities.

Rule 4: Multiple authority document references (within the same document) must be combined into a single UCF control citation if the control effect is the same even though the targets are different

Many times, authority document authors will write a control in a very general or even abstracted (non-targeted) way, only to repeat themselves within the same document with the same control that is very targeted, as explained in the example below. In other authority documents, such as configuration documents, they will often state controls such as "turn off FTP" multiple times, each for a different target (the mail server, the web server, the database server). If the control's effect is the same while the target is different, it is listed as a single reference within the UCF.

Example

§ 8.2 of the PCI-DSS states that the organization must employ some type of access authentication methodology. The effect is to authenticate uniquely identified users in general. Then in § 8.5.16, it calls for the organization to authenticate access to any database holding cardholder data. The target is now very specific - while the effect (authenticate uniquely identified users) is the same. Therefore, the UCF control would be written as such and would include a cross reference to both the § 8.2 and the §8.5.16 references:

C: Authenticate access to any device or system holding or providing access to sensitive data.

Rule 5: Combine and harmonize the control effect of multiple authority document references when the effect is the same but the parameters are different

As we've stated, the Unified Compliance Framework abstracts a control into two parts, the actionable demonstrable outcome (the control) and its parameters (the choices in methodology or policy). Many times, especially with the case of password controls, the authority documents will state that the organization must set a password (the control) to a certain length and character type (both of which are parameters). In order to harmonize this control, the UCF would restate it as "set strong password controls" because the effect is to set strong access control measures no matter which parameter variables might be used. We then annotate the original language of each authority document reference within the Control's reference area.

Another instance is when the variables are at odds with each other. Many times configuration controls will state to turn on a service in one authority document while stating to turn off the same service in another authority document. The variable is "on/off", with the actual control being to assign the parameter according to organizational needs and risk analysis. One more instance of this is when the variables are slightly at odds with each other, such as the example below.

Example

§ 113(g)(1) of FACTA states that no one shall print more than the last five digits of the Payment Application Number (PAN), nor may they print the expiration date. § 3.3 of the PCI-DSS states the organization must mask the PAN when displayed (the first six and last four digits are the maximum number of digits to be displayed). The point of unifying this control isn't to argue about the number of digits to display. It is to render whatever data is displayed useless for cardholder information theft. Therefore, the unified control could be written as such:

C: Mask or remove from displaying (or printing) the key elements of cardholder data in a manner that renders the displayed (or printed) data useless for cardholder or identity theft.

To ensure that the UCF team doesn't get into the business of interpreting which of the parameters is more or less correct, our policy is to annotate each authority document's parameter guidance within the in-depth control reference.

Rule 6: Separate single authority document references into separate UCF controls when the demonstrable outcome of each control is different based upon multiple parameters within the same reference

Wow, that one was a mouthful. What it means is that there will be cases where an authority document author has treated parameters as controls. More often than not, this occurs when the author creates what we call a "run on" reference, such as the example below.

Example

In NIST 800-68, § 6.1, the organization is to create individual password policies for maximum password age, minimum password age, password length, password complexity, the enforcing of password history, maintaining the password file in encrypted format, setting the account lockout threshold, setting the account lockout duration, and resetting the lockout counter. Most of those parameters are actually a demonstrable control in and of themselves. Within the UCF, each one garners its own control statement.

C1: Require a minimum password length suited to the organization's needs.

C2: Set retry limit for account lockout according to organizational standards.

C3: Enable password history.

Etc.

Rule 7: Treat the control as a metric definition if the control meets the minimum requirements for a metric

We know that controls produce demonstrable outcomes. When the demonstrable outcome is a method of measurement and reporting, the control should be treated as a metric (i.e., a system of related measures that facilitates the quantification of some particular characteristic, such as a goal or activity).

In order for a control to be represented as a metric, the control must have the following characteristics:

1. The control statement must state that the control's demonstrable outcome is to create a report of some type.

2. A measurement formula must exist that correlates with the report in the control.

3. The sources of the measured information must be explained.

Example

Control	Metric formula	Source of measurement
Report on the percentage of key IT assets for which an assurance strategy has been implemented	# of key IT assets for which an assurance strategy has been implemented / # IT assets	The assets in your CMDB as the base / # of assets that have assigned configuration standards and controlling procedures

Minimum requirements for a control to be a metric

Rule 8: Reference the correct metric if the control calls for a report that is based upon an existing metric, but the control is not a metric in and of itself

There are many controls that call for documentation or reports, but don't go far enough to actually be metrics (e.g., they don't include the three metric must-haves listed above). In that case, not only should the control be documented, but the control should then be cross-referenced with the appropriate metric for that control.

Example

One of the UCF Controls states "the IS leadership will work with the organization in order to analyze and document business direction, objectives, and functions when properly aligning IS strategies with organizational strategies. [UCF ID 00598]" The metric associated with this control is as follows; "Report on the percentage of critical information assets and information-dependent functions. [UCF Control ID 02040]" These two are linked because that referenced metric is designed to report on the number of critical information assets and information dependent functions divided by the number of information assets and functions. In other words, how many IT systems directly support the business's direction.

Rule 9: Reference additional audit documentation if the control specifically calls out for examination, testing, or interview techniques

Within the UCF, we normally harmonize a standard control title, control statement, and audit question for each and every control we track. However, some authority documents are either outright audit guides or they are written as quasi-audit guides. Because some authority documents have additional information regarding audit activities, we have chosen to track this guidance as separate from general guidance. There are three additional (and optional) fields of information for specific audit guidance:

1. Examine guidance is used when the auditor is being asked to inspect, analyze, or scrutinize the demonstrable outcome of a control.

2. Test guidance is used when the auditor is being asked to either actively try a control's process or observe the active process in order to judge the demonstrable outcome.

3. Interview guidance is used when the auditor is being asked to speak with or take a survey of individual or key personnel when examining the demonstrable outcome of the control.

Example

The following is a control within the UCF: "The organization will maintain a standard and appropriate procedures to implement password standards and procedures. [UCF ID 01702]" In addition to this control, the PCI Audit Guide 1.1, § 8.5.2 and 8.5.3 provides the following audit guidance:

Examine the password procedures to ensure a user's identity is verified before the password is reset and that a user must change his/her password after initially logging on to the system.

Observe security personnel receiving user requests to reset their password by phone, email, web, or another form of non-face-to-face method and ensure they verify identities prior to resetting passwords. Observe security personnel issuing first-time passwords and ensure each one is unique.

Interviews should be conducted with security personnel to ensure they verify identities prior to resetting passwords. Interview users to ensure they change their password after the initial use.

Control parameters

Throughout our process of research, we have boiled it down to ten categories of parameters. Let's look at each category in more detail and consider some examples. As you read through these notice how, in each category, you would be able to evaluate or measure whether or not the standard has compliance based upon the stated parameter.

1. Informational parameters

Informational parameters describe such things as roles, responsibilities, actions or characteristics. For example, a security program roles and responsibilities standard would describe the responsibilities for each formally identified role. For example, such a standard could look like:

The Director of Information Security is an employee that is assigned the leadership role for the organization's security program. The responsibilities include:

• Managing implementation of the organization's security program,

• Creating and maintaining the information security policies and standards,

• Managing the selection and implementation of security tools, and

• Managing the security staff and providing direction to security representatives.

The four bullets provide the descriptions for the Director of Information Security's specific job responsibilities.

When documenting system configuration informational parameters, you are usually describing the information that would be a part of a sign-on or warning banner. Or the information parameter could contain what should be included in the privacy policy or license agreement presented to a user prior to allowing access to an application.

A sign-in banner will be created for all systems that hold company confidential information and the banner will be displayed during the login process.

2. Variable preference parameters

Variable preference parameters provide those individuals with security implementation responsibilities a choice of specific options for how to establish security based upon the circumstances. For example, such a standard could look like:

The organization's information systems contingency plan must be tested at least annually and as soon as possible following major changes to systems and applications.

The variables are annually and as soon as possible following major changes.

When documenting system configuration standards, the variable preferences normally define string lengths, addresses, ports, protocols, which fields should be reported in a log, etc.

The password length for all devices will be 8 characters in length, with a mix of upper and lower case characters.

3. Capacity parameters

Capacity parameters define values for security related information related to storage and size. For example, such a standard could look like:

The organization's information systems must be configured to provide a warning when allocated storage volume reaches 90% of the maximum audit record storage capacity.

The specified capacity in this example is 90% of the maximum audit record storage capacity.

4. Boolean parameters

Defining settings that have only two possible values, such as "yes/no;" "on/off;" or "connect/disconnect." For example, such a standard could look like:

The information systems must terminate a network connection at the end of a session.

In this example, either an active session has a network connection or a terminated session has no connection.

5. Retention parameters

Retention parameters specify the time periods for which certain types of information is retained. For example, such a standard could look like:

The organization's information systems must be configured to automatically disable inactive accounts after three months of inactivity.

This retention period for keeping active accounts in this example is three months of inactivity, after which the account is disabled.

6. Named access parameters

Named access parameters list the types of access and related security controls that must be implemented for certain information assets or resources. For example, such a standard could look like:

The information systems must limit each defined user to one concurrent session.

The requirement for one concurrent session is the named access parameter in this example.

When writing this type of parameter into a configuration standard, the parameter normally defines specific users and groups that should be enabled or disabled.

The Remote Administrator account must only be enabled if the Remote Administration application and other settings have been enabled.

7. Data list parameters

Data list parameters provide a list of values that must be implemented. For example, such a standard could look like:

All the organization's information systems must generate audit records for the following events:

• Login time

• Login user ID

• Login date

• And so on...

In this example, each of the bulleted items represents each of the data list parameters.

8. Named path parameters

Named path parameters indicate what roles, positions or individuals are authorized to perform specified information security related activities. For example, such a standard could look like:

The organization must limit shared directories that can be accessed anonymously.

Those shared directories mentioned in this example is the named path parameter that must be limited to anonymous access.

Named path parameters for configuration standards are very explicit and are either defined as URLs or Windows file paths.

http://netfrontiers.com/compliance/Shared%20Documents/The%20UCF%20Book/3%20to%204/

\\sharepoint\compliance\Shared Documents\The UCF Book\3 to 4\

9. Permissions parameters

Permissions parameters define what specified roles, positions or individuals can or cannot do. For example, such a standard could look like:

The organization must develop and keep current a list of personnel with authorized access to the facility where the information system resides (except for those areas within the facility officially designated as publicly accessible) and must issue appropriate authorization credentials. The Information Security Officer must review and, if applicable, approve the access list and authorization credentials at least annually.

In this example the requirement to keep current a list of personnel with authorized access is the permissions parameter.

10. Patches parameters

Patches parameters define the values associated with each type of security-related systems and applications patches that must be used when security and software patching occur. For example, such a standard could look like:

Before systems and applications patches are put into production, all security controls must be tested to determine what impact they have on system security, functionality, and usability, and to take appropriate steps to address any issues identified.

The requirement that all security controls must be tested is the patches parameter in this example.

When describing patches within a configuration standard, you'll usually want to specifically list the oldest patch level that you'll allow.

All Windows XP systems must have Service Pack 2 installed.

Some parameters belong to multiple categories

Don't get frustrated if you have a standards parameter that seems as though belongs in more than one category - some of them will! Consider the example we used earlier in this chapter,

Access to confidential information must be made to only those groups and individuals who:

• Have a documented need to access the information to perform their job responsibilities, and

• Have been authorized to access the information in accordance with the organization's change control procedures.

Both of the above standards parameters can be considered as both a named access parameter setting (because of the requirement to have a documented need to access) and a permissions parameter setting (because of the requirement to have been authorized).

Using standards parameter categories is not bureaucratic busy-work meant to bog you down with trying to figure out where a specific category goes. Established parameter values help you ensure your standards are demonstrable, realistic, and will be implemented throughout your organization in the most consistent manner possible.

Sometimes more restrictive values are needed

All areas throughout the organization need to follow the established minimum and maximum values for organization-defined standard parameters with one notable exception: if applicable laws, Executive Orders, or regulations require more restrictive values, or when risk assessments indicate more restrictive values are necessary in order to adequately mitigate risk for certain situations.

Consider the example discussed earlier to disable user accounts after three months of inactivity. If you created an administrative user account for an outside regulator to use while performing a compliance audit you may wisely decide to disable that regulator's user account immediately upon the conclusion of the audit instead of waiting until the account has not been used for three months.