As defined in The Language of Compliance, organizational standards are used to define the uniform use of specific measurable technologies, parameters, or procedures when such uniform use will benefit the organization. A standard can be: 1) an object or measure of comparison that defines or represents the magnitude of a unit; 2) a characterization that establishes allowable tolerances or constraints for categories of items; 3) a degree or level of required excellence or attainment. Standards are definitional in nature and established either to further understanding and interaction, or to acknowledge observed (or desired norms) of exhibited characteristics or behavior. Thus, standards may function to specify minimum performance levels or describe best practice. Standards can be put in place to support a policy or a process, or as a response to an operational need. Like policies, standards must include a description of the manner in which noncompliance will be detected. While ITIL states that standards are mandated, there is no legal precedence that they are.

Let’s delve further into this by defining what an organizational standard seeks to achieve and why we have organizational standards. An organizational standard falls in between a policy and a procedure and supports both. Where policy is the 10,000 foot leader’s view of the direction the organization should head, the procedure is the 10 foot view of how to specifically get there, and the standard is part of the “there” we’re trying to reach.[1]

Consider driving and maintaining a car. Many people learn how to drive basically any type of car and what the rules of the road are by taking driver’s education classes. These are like the policies for how to drive a car. There is also a driver’s manual for each make and model of a car that documents how to operate that model of the car, which is like the car’s procedures. Each make and model of a car also comes with a maintenance manual that documents the proper amount of pressure for the tires on the car, the grade of oil to use in the car, and so on. This maintenance manual is like a like a set of standards. The standards indicate what needs to be done (tires inflated to 28 PSI), but not necessarily how to do it (hand pump, electric pump, gas station compressor, etc.).

These concepts parallel information security policies, procedures and standards. Procedures can, and do (and should), vary from one department and office location to the next. Some differences in procedures may be required by local conditions or regulations - for example fire codes in different cities may require different evacuation procedures. Other variations may be based on differences in technology - for example, the procedure for setting up a Cisco router will not be the same for the procedure for setting up a SonicWALL router (although security policies implemented by such procedures may be the same in both cases). With that said, in order to maintain commonality of products the organization might create a purchasing standard for routers to ensure that they are compatible with routers that are already deployed, or interchangeable if need be. In simple terms the why is focused on normalization.

Typically within a corporate environment, a standard provides the specific technical requirements for implementing corresponding policies. For example, a corporate policy may require that strong encryption be used when sending confidential information within or attached to e-mail messages. The corresponding standard might name the specific encryption solution and algorithm that must be used to satisfy the policy.

Generally, standards only need to be communicated to the personnel charged with implementing them, not to all corporate personnel. Another difference between standards and policies is that well-written policies will rarely change, but standards will change in response to changing technical environments, which may happen comparatively often.

The generally accepted use of the word standard implies that it is a universally agreed upon set of rules for interoperability. Fat chance, that. In reality, you should look upon standardization as a process for establishing various kinds of efficiencies, implementations, and syntaxes within a set of approved possibilities. Think of organizational standards as formalizations, unifications, or homogenizations of products, implementations, and procedures. Therefore, let’s define the what of standard setting as the continuous development, implementation, and adjusting of products, designs, implementations, syntaxes, and procedures to achieve and maintain required levels of compliance while maintaining compatibility, interchangeability, and commonality within the organization. The “standard” itself is the output of this process.

A closer definition of the why can be found in the words “compliance, compatibility, interchangeability, and commonality.” We need to focus on that word compliance for a second before we move on, because it is important to the methodology your organization will use when creating standards. Standards within most organizations either arise organically as de facto standards (meaning that they develop over time as personnel gravitate toward them and are followed for the convenience of the organization), or they are foisted upon the organization as de jure standards (meaning that they are externally created and must be followed in order to meet regulatory or contractual compliance).

Why and how de facto standards are developed

Let’s say that a typical organization has three departments; sales, production, and billing. The policy for the organization is that all departments will back up their computers every day. The sales department consists of a bunch of people with notebooks. Therefore, the sales department develops a procedure to back up over the Internet to an ASP-based backup provider so that the sales folks can run backups from whatever hotel room or internet cafe they happen to be working from at the moment. The billing department, on the other hand, has a series of desktops with a procedure to back them up to tape on a daily basis. Because production consists of devices that have a short backup window, their procedure is to back up to disk and then run that backup to tape at a later time. These three procedures are neither common nor interchangeable as each uses different hardware and software. There is no clear backup standard.

The first step is achieving compatibility. By selecting a software product that could run Internet, disk, and tape based backups, the organization could normalize three different applications to a single instance.

The next step would be examining interchangeability. Interchangeability here would be looked at more of as a process than a product. Because the sales group is mobile, they would not be able to interchange their backup locations with disks or tape - they are stuck with Internet-based backups. However, both production and billing could back up initially to a local disk-based backup location because the disk-based solution is equivalent in both performance and durability. Therefore, the organization could achieve interchangeability with a single exception (sales). Note that the exception is a compatibility-based exception. This means that the sales department’s traveling is not compatible with being backed up locally. Using the Internet-based backup method is a compensating solution to the exception.

For both billing and production, the question now comes down to commonality. Can the backup product be selected and procedures written in such a way for each group’s backups to be operated and maintained by personnel from either department without any additional training? If so, the organization can achieve commonality at least for these two groups.

Notice what we are doing in this story. We are attacking the problem of creating a standard from the ground up. We are taking the policy (from on high) and then examining each procedure (from the bottom) to see which procedure could be brought to a higher level of normalization in order to work better across the entire organization. That’s because de facto standards are created to make your life easier - you are following your own internal rules and methods that have evolved organically to solve specific problems.

Some de facto standards are so widely accepted and used that they eventually become required, or de jure, standards. For example, Hewlett-Packard created the interface bus (HP-IB) but it quickly became so popular and widely used within the computer industry, that the Institute of Electrical and Electronics Engineers (IEEE) committee adopted it and renamed it the General Purpose Interface Bus (GPIB) as defined within their IEEE-488, thus turning it into a de jure standard.

De facto standards seek normalization and homogenization. No so with de jure standards.

Why and how de jure standards are developed

De jure standards are foisted upon organizations by external rule makers. We write organizational standards because our organizations have to follow public rules (such as PCI-DSS that applies to everyone accepting credit card information, or HIPAA that applies to all who need to protect patient health information), as well as specific external rules (contracts and Service Level Agreements with clients or suppliers), and even internal rules (organizational policies).

Many of these rules define specific controls that must be followed. The job of the rule maker seems to be to say “do this” or “do that.” But rule makers aren’t always blind to reality. There’s often the clause that says “we anticipate exceptions, just tell us why and where.” Therefore the why of de jure standards is compliance.

The how of de jure standards is attempting to marry a set of externally written controls with existing conditions by creating rules for commonality and determining when exceptions to the standard are acceptable (and the degree of deviation that at is acceptable). The first step in the process is to establish commonality between any competing compliance authority requirements. Once a common framework has been created, exceptions should be based, in order, upon compatibility and then interchangeability.

Compliance and commonality or harmonization

The first question when looking at whether to apply a de jure standard as written is to define the area of commonality, also known as harmonization. Most of us are under multiple external regulations. A typical large university, for example, must follow the Health Insurance Portability and Accountability Act (HIPAA) in connection with its medical program, the Gramm-Leach-Bliley Act (GLBA) in connection with student loan programs, PCI-DSS regulations in connection with it’s acceptance of credit card payments for tuition and fees, and a great many other acts and regulations. HIPAA calls for the protection of patient records. GLBA calls for the protection of non-public personal information. PCI-DSS calls for the protection of credit cardholder data. What is common among all three of these is that the regulation deals with people’s information. Therefore, instead of having three separate standards (one for a person’s medical information, one for personal information, and one for credit card information), why not create a standard that defines how to protect confidential information in general? The standard could have a section defining what constitutes fields to be kept confidential, records to be kept confidential, reports to be kept confidential, and media to be kept confidential.

By focusing on the commonality of the compliance requirements, anything outside of the scope of commonality can be considered an exception. As another example, HIPAA, GLBA and PCI-DSS each require awareness and training.

The HIPAA requirement is found within §164.306 as follows:

(5)(i) Standard: Security awareness and training. Implement a security awareness and training program for all members

The GLBA requirement is found within §314.4 as follows:

(b) Identify reasonably foreseeable internal and external risks to the security, confidentiality, and integrity of customer information that could result in the unauthorized disclosure, misuse, alteration, destruction or other compromise of such information, and assess the sufficiency of any safeguards in place to control these risks. At a minimum, such a risk assessment should include consideration of risks in each relevant area of your operations, including:

(1) Employee training and management;

The PCI-DSS requirement is found within Requirement 12 as follows:

12.6 Implement a formal security awareness program to make all employees aware of the importance of cardholder data security.

12.6.1 Educate employees upon hire and at least annually (for example, by letters, posters, memos, meetings, and promotions)

12.6.2 Require employees to acknowledge in writing that they have read and understood the company’s security policy and procedures.

Okay, so if we are from the University we see we need to provide information security and training to our employees, and a policy stating this provision would need to meet the general requirements of HIPAA, GLBA, and PCI-DSS for this type of education. The standard for delivering the education will need to be documented to support this policy. When harmonizing standards, check for all commonalities between your authority documents (in our example, HIPAA, GLBA, and PCI-DSS) as well as the differences, as we’ve done in the table below.

Control	HIPAA	GLBA	PCI-DSS
All members of the organization will be trained on information security awareness.	§164.306(5)(i)		12.6
The new hire process will require training			12.6.1
Training will take place annually			12.6.1
All employees will acknowledge in writing that they have read and understood the organizational policies and procedures			12.6.2
The effectiveness of information security awareness training will be measured for future risk management audits		§314.4(b)

The three authority documents harmonized

This, then, becomes your harmonized standard for what must be included within a training program to meet your compliance requirements. And if you are noticing, yes, this is the entire foundation upon which the Unified Compliance Framework has been built. You can find unified control standards in abundance at our unifiedcompliance.com website.

De jure standards don’t always play nicely with de facto standards - enter operational standards

Recall that de facto standards evolve over time out of a combination of necessity, convenience, and inertia - the “this is the way we’ve always done it” syndrome. De jure standards may or may not be met by the de facto standards of the organization. In order to implement an effective compliance program, you must operationalize the de jure standards and reconcile them with the de facto standards. Only then can you determine if the de facto standard can remain, must be changed, or must be completely discarded in favor of a new operational standard.

Many organizations get confused when trying to create their own operational standards to meet compliance with the externally mandated de jure standards.  A common mistake is to try and take the de jure standard verbatim and make it an operational standard.  Sometimes this can work, but more often than not, it will create some problems for you.

The typical lack of specificity within the de jure standards often do not harmonize well with organizational de facto standards.  For example, consider the HIPAA standard from § 164.312 Technical safeguards:

“A covered entity must, in accordance with § 164.306:

(a)(1) Standard: Access control.

Implement technical policies and procedures for electronic information systems that maintain electronic protected health information to allow access only to those persons or software programs that have been granted access rights as specified in § 164.308(a)(4).”

Do you see any problem with trying to use this exact statement as your organizational standard? Would your IT folks know what this statement means to them? Would this type of standard lead to consistent implementation of access controls within your organization, or would it open the door to inconsistent use of technology and inconsistent access control implementations? If you tried to include the referenced text from § 164.308(a)(4) you would end up including all the following:

“(4)(i) Standard: Information access management.

Implement policies and procedures for authorizing access to electronic protected health information that are consistent with the applicable requirements of subpart E of this part.

(ii) Implementation specifications:

(A) Isolating health care clearinghouse functions

(Required). If a health care clearinghouse is part of a larger organization, the clearinghouse must implement policies and procedures that protect the electronic protected health information of the clearinghouse from unauthorized access by the larger organization.

(B) Access authorization (Addressable)

Implement policies and procedures for granting access to electronic protected health information, for example, through access to a workstation, transaction, program, process, or other mechanism.

(C) Access establishment and modification

(Addressable). Implement policies and procedures that, based upon the entity’s access authorization policies, establish, document, review, and modify a user’s right of access to a workstation, transaction, program, or process.”

Huh?  Did this help?  More likely all this verbiage just muddied the waters. And, since it references yet another part of the regulatory text, there are still more passages from this regulation that would need to be included if we continued to follow this logic.  We have seen organizations actually try to do this, though, and they ended up with the following:

   The plunked in de jure standard covers more topics than applies to the organization, confusing those who must follow them. For example, if the organization is not a clearinghouse, those reading this standard will wonder how they are supposed to comply with the “required” clearinghouse statement.

   Documenting a statement as “addressable” usually gets incorrectly interpreted as meaning “optional.” If the people who must follow the standard think an action is optional, nine times out of ten they will choose not to follow it.

   De jure standards typically read more like policies, not standards. There are no specific solutions provided in de jure standards (such as this one from HIPAA), leading to multiple solutions being implemented throughout an organization that all do basically the same thing.  This not only wastes your organization’s money, it leads to a maintenance and compatibility nightmare - it completely undermines our goal of commonality.

   The writing style does not match the other standards within the organization, making them seem strangely out of place to the readers who must follow them.

   Your organization’s standards can not be harmonized for multiple de jure standards if you take the statements verbatim from each of the regulations.  You thus leave it to the individual readers to attempt to interpret and harmonize these standards in a way that they believe makes sense for their own jobs without knowing the impact of their interpretations on other parts of the business. As discussed in the previous section, this harmonization is important for making organizational standards as succinct and understandable as possible while complying with multiple regulatory requirements.

When using de jure standards as the basis of your organization’s operational standards, boil them down to the concepts that apply to your organization and then write them consistently with the way your other standards are written, sticking with the language with which your readers are familiar.

An example to use for this HIPAA standard for an organization that is a covered entity but not a clearinghouse might look like the following:

Access to confidential information must be given only to 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.

Notice - we set two parameters for the policy (need to know, need to access). Operational standards define common parameters for policies and procedures.

Compliance and compatibility

Let’s consider the common control statement inferred by many public regulations that mandates organizational firewalls must be set up as a default “deny all” access policy. If an organization were to deny all traffic from entering their network, there would be no reason to have the network - web traffic, e-mail traffic, and other business related traffic would be stopped by the firewall. This type of extreme compliance, implemented to meet the letter of the law, would be incompatible with doing business.[2] Therefore, the organization must create a process to ensure that both compatibility and compliance are balanced. They have to define and document compatibility exceptions.

In the case of our firewall scenario, the compatibility exceptions are based upon the addresses, ports, and protocols needed to carry traffic between the organization’s computers, its clients, and suppliers (or even the general public).

A simple exceptions table could list all of the open ports, what runs on those ports, the reason for the port to be open, where the traffic should be routed, and which group the exception came from.

Port/Address	What	Why	Where	Group
80	HTTP	Web traffic	DMZ web	Sales
25/110	SMTP/POP	Mail sending	DMZ e-mail	All
1596	EDI	Supply Ordering	Production Server	Production
ALL Internal Addresses	Use of private IP range	NAT will be used	All non-DMZ devices	All

Again, the standard here is addressing parameters (in this case ports) that should be normalized unless an exception is made.

Another way to look at compliance and compatibility is technical compatibility. Walking through the Center for Internet Security’s various systems hardening guidelines (which are now mandated by PCI-DSS), we determined that many of the hardening guidelines simply aren’t compatible across all operating systems (and neither does the Center for Internet Security claim them to be). What follows is a small segment of system configuration standards and which operating systems they apply to.

	Windows NT	Windows 2003 Server	VSE-ESA	Unisys	Sun Solaris	Novell Netware	Linux	HP-UX	AIX
Install patches	X	X	X	X	X	X	X	X	X
Install Service Packs	X	X
Convert to Trusted System								X	X
Install Login warning banner			X	X	X	X	X	X	X
Login parameters	X	X			X	X	X	X	X
Single-user login mode							X
Convert File System	X	X
Remove un-needed software							X

When it comes to technical compatibility, any system which is simply not capable of meeting the standard either must be wholly eliminated from the organization’s use, or must automatically be excepted from the standard.

In addition, rules for deciding upon general compatibility exceptions, and the exception request, review, and approval process can (and should) be documented.

Compliance and interchangeability

Another reason for exceptions to a de jure compliance rule is based upon interchangeability, or what is being called compensating controls. For the most part, organizations that are unable to follow external rules due to technical or business limitations can employ compensating controls as long as they have undertaken a risk analysis and can show documented decisions to do so, and as long as the compensating controls are interchangeable with the controls the rule calls for. By interchangeable here, we mean that the compensating controls put into place by the organization are equivalent in performance and durability, or provide greater protection than those stated by the rule maker.

When creating the rules for analyzing a compensating control’s interchangeability with a control published by the rule in question, the compensating control in question must:

1.    meet the intent and rigor of the external requirement;

2.    mitigate the threat with similar force; and

3.    be commensurate with the additional risk imposed by not adhering to the external requirement as stated.

As an example, let’s take another widely defined rule - that of “separation of duties.” Many regulations call for the complete separation of duties between positions such as the database administrator and the security patch manager. This means that there should be two physical people, one to administrate the database and another to ensure its continued security. But what about offices with a single administrator? Other than hiring someone with a split-personality (which carries a whole different set of security risks!), the small office might not have the salary budget for two people. That’s when a compensating control can be decided upon. Here’s a model for documenting interchangeability.

Original	Interchangeability parameter
Intent: separate security change-related tasks from normal admin tasks by assigning them to different people	Submit all changes for approval from home office before making them, and then allow the home office to review changes once they’ve been made. Each server should have individual accounts for security and DBA and DBA should only log on as security admin when performing changes.
Threat mitigation: Threat is that DBA will have access to security measures	By forcing DBA to log in using a separate security admin account when making changes, and tracking all access, the home office can ensure that DBA isn’t making unapproved changes or continually logging in as security vs. DBA. By reviewing changes, home office ensures only approved changes are made.
Commensurate equality: Ensure that DBA actions and entitlements do not cross with Security actions, and that there is change oversight	By enforcing a strict change management approval and review process, entitlements will be managed appropriately and commensurately. By establishing a strict logging and log review process, actions will be managed appropriately and commensurately.

Types of standards parameters

Now that you know what a standard is, you need to think about the acceptable parameter values to use within standards. Organizations should not write standards if the standards cannot be measured or evaluated in some objective way. Think about it. How would you ever know if the standards were effective, reasonable or needed to be changed without being able to measure or evaluate them? How could you ensure security was applied consistently throughout the organization without establishing acceptable parameters? Security controls containing organization-defined parameters give organizations the flexibility to define specific values and characteristics of controls to support organizational requirements or objectives consistently.

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 document and use an identified custodian at all times to transport information systems backup media outside corporate facilities. No other individual is authorized to take backup media outside facilities.

The identified custodian in this example is the named path parameter who must be the only individual to transport backup media.

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

http://sharepoint.netfrontiers.com/compliance/Sharedocuments/TheUCFBookto4/

\\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 measurable, 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.

Keep the characteristics of organizational standards in mind

Standards and their defined parameter values have a huge impact on how the information risk within your organization is mitigated, and they must be constructed in a thoughtful manner with your own organization’s unique environment and compliance requirements in mind.  So as you create your own organizational standards, keep the pointers we’ve discussed in mind.  From a mile high view they include:

1.    An organization’s de facto standards point the way for operational standards that provide the specific technical requirements for implementing corresponding policies.

2.    De facto standards seek normalization and homogenization throughout the organization.

3.    You will usually not be able to use de jure standards verbatim as your organization’s operational standards; more often than not the typical lack of specificity within de jure standards will not work as operational standards.

4.    You must create a process to ensure that both compatibility and compliance are balanced, defining and documenting compatibility exceptions for the standards.

5.    Compensating controls for exceptions need to meet the intent of the standards as written, and also equally mitigate the threat and any additional risk created by not having the stated control.

6.    Standards must specify measurable parameter values.

Parameter categories

Again, here are the list of parameter categories.

Category	Policy descriptions	Configuration descriptions
Informational	Descriptions for such requirements as roles and classifications	Banner text or policy statements that should be included as warnings
Variable preference	Specified options for how to establish security based upon the circumstances or the choice of the responsible individual	String (think password here) length, addresses, ports, protocols, which fields should be reported or in a log, etc.
Capacity	Values for security related information related to storage and size
Boolean	Settings that have only two possible values, such as “yes” or “no;” “on” or “off;” or “connect” or “disconnect”	For enabling or disabling services, accounts, applications, etc.
Retention	Time periods for which certain types of security-related information or resources are retained
Named access	Types of access and related security controls that must be implemented	The users and groups that should be enabled or disabled
Data list	List of values that must be implemented	These are lists of parameters or other items not otherwise covered
Named path	Roles, positions or individuals authorized to perform specified activities	These are the directory and share names that are included or excluded from access
Permissions	What specified roles, positions or individuals can or cannot do	This covers access rights to named paths and applications for users or groups
Patches	Values associated with each type of security-related systems and applications patches that must be used when security and software patching occur