Security

Almost One for All

If your security controls seem out of control, these steps can help you apply the new NIST guidance to find a way forward.

With the release last year of security control guidance that applies to nearly all federal systems, government organizations for the first time have an overarching approach to evaluating, setting and managing security controls.

The National Institute of Standards and Technology released the catalog of recommended security controls, five years in the making, in August 2009. NIST Special Publication 800-53, “Recommended Security Controls for Federal Information Systems and Organizations,” applies to all federal systems except those designated as “national security systems.”

The agencies and organizations covered by the recommendations in SP 800-53 are numerous and varied, ranging in size from very large to very small and have national and international reach. They include both civilian and military entities as well as the multitude of contracting organizations acting on behalf of them. With 18 distinct control families and 200 controls in the catalog, security professionals may find the task of interpreting, selecting, tailoring and implementing controls overwhelming.

The publication itself is full of tips and pointers and allows for organization-defined security control parameters for tailoring some controls for practical application in a multitude of operational environments. For federal security practitioners, familiarity with this publication has grown over its development cycle as they have reviewed and commented on previous versions.

This article is not intended to review detailed aspects of the security control guidance but to provide common-sense tips for implementing its recommendations. The following five steps can assist a security manager in developing a methodical approach to selecting and implementing security controls, while maximizing resources (personnel, time and dollars). These tips are applicable in any environment — large or small, civilian or military.

Before You Begin: Line Up the Experts

Do not begin implementing SP 800-53 without getting all subject-matter experts, technical experts and business owners on board. Identify individuals in your organization who have authority over information systems and security as well as specific areas identified in the 18 security control families.

These individuals should understand security concepts, laws and regulations, and systems and software development principles. Use of the NIST recommendations requires knowledge of both FIPS 199 and 200 and other supporting and related documents. Normally, the chief information security officer or the designated senior IT security official would meet these requirements.

In terms of authority over systems, the CIO would be the designated official. These experts act as critical in-agency resources for advising project and program owners about implementation of SP 800-53.

It is equally important to assign management leads for the 18 identified control areas. This team has the responsibility of coordinating application of the recommended security controls with system managers throughout the organization who are charged with evaluating and implementing the security controls for systems within their domain of responsibility.

If you lack internal experts, then give serious consideration to acquiring outside experts to complement your agency team.

1 | Step one

Inventory all systems.

Without knowing the systems for which the organization is responsible, it is not possible to apply a risk management framework appropriately or assess risk across the enterprise. Moreover, it is impossible to fully leverage common controls. A systems inventory requires the coordination of the CIO, CISO and system owners through formal vehicles such as capital planning and investment and IT governance.

2 | Step two

Categorize all systems.

Successful use of SP 800-53 requires taking the preliminary step of categorizing systems and assessing their impact according to FIPS 199 and 200. This assessment should be done from an enterprisewide perspective and coordinated through the assigned team for completeness and consistency.

The selection of a baseline set of controls is directly related to whether a system’s impact is assessed as low, moderate or high. It is also helpful to distinguish within the system inventory those systems that are legacy systems as opposed to new systems being developed because the strategy used in achieving a given baseline could vary based on a system’s status.

3 | Step three

Attack the low-hanging fruit of common controls.

Once you have categorized the systems, the next step is to select baseline controls. The first thing an organization should do to eliminate unnecessary work later on is to identify common controls. Common controls are developed and approved at the enterprise level; they usually apply across a multitude of systems.

Some typical areas where this is frequently done are personnel security, physical and environmental protection, contingency planning, configuration management and program management. More examples can be found in SP 800-53, but each organization needs to make its own determination based on its internal processes and system use.

By identifying common controls early in the process, the information can be made available to all system managers as they implement security controls.

This is also the time when organizations should determine if any control areas not previously addressed as common controls should be addressed as such going forward. This can drastically streamline the security control evaluation and implementation process.

Be aware that some control families include hybrids: Some controls can be implemented at the enterprise level, but others must be system-specific. Training tends to fall into this category, for instance. It is quite common to have enterprise awareness and training programs in place, but they may not address end-user training on security requirements for specific application systems. System-specific training would be based on unique characteristics of a given system, so it would not be appropriate to broadly disseminate it across the entire system inventory.

The same scenario might apply to incident response. Often, an agencywide capability covers network systems, but some lower-level requirements for discrete cross-transactional relationships will likely need to be captured, evaluated and addressed for discrete systems.

The team assigned to lead this effort should assist in determining how to best approach each family of security controls for optimal implementation (common versus system-specific versus hybrid).

4 | Step four

Conduct a gap analysis.

It’s time to address other system-specific baseline controls.

Start by analyzing existing systems and their associated security requirements, incorporating applicable common controls into the baseline and mapping the remaining controls to the selected baseline (low, moderate or high). As you do this, identify controls that are incomplete, in conflict or missing.

This mapping provides a useful tool for decision-making when selecting the target set of controls. Compensating controls are controls that achieve the intent of a given baseline control but do so by implementing a different measure. The organization must document compensating controls, including the rationale on how they provide the required level of protection.

For systems in development, incorporate the selected set of baseline controls into security requirements submitted within the analysis and requirements development phase of the system development lifecycle (SDLC). The final set of security controls implemented for a system needs to be documented in the system security plan.

5 | Step five

Establish mechanisms for security re-evaluations and updates.

Simply stated, the process of identifying and implementing security controls using SP 800-53 has to become an integral part of an organization’s SDLC processes, especially the configuration management and change control components.

If a well-developed and managed SDLC process exists, once you apply and document the security control baselines, the organization will be in a good position to make future modifications without starting from scratch.

Made to Fit

NIST developed the set of controls contained in SP 800-53 with flexibility and tailoring in mind. It carefully vetted the approach with federal, public- and private-sector officials. For the most part, the government has achieved its objective of providing a framework for security control selection.

Going forward, NIST’s ability to adjust the guidance needs to be based on actual use and feedback. A basic premise is that a control is a candidate for downgrading if that action is consistent with FIPS 199 and 200, is supported by a risk assessment and does not adversely affect the level of protection for security-relevant information within a system.

Ultimately, organizations still must do the work of determining system impact, providing organization-specific parameters and establishing a risk management program to achieve the intended result.

The absence of some specificity is what makes SP 800-53 flexible enough to be useful to a wide variety of organizations. Only its use over an extended period of time in a wide range of operating environments will show if the document strikes the right balance.

Members of the bureau include federal IT security experts from government and industry. For a full list of bureau members, go to www.isc2.org/ewb-usgov.

Almost Everyone

Before the release of the security controls guidance, the National Institute of Standards and Technology participated in a Joint Task Force Transformation Initiative Interagency Working Group to begin development of a unified information security framework for all federal information systems, including national security systems. Currently, the controls may only be applied to such systems with the approval of federal officials having authority over those systems. Thus, the creation of a truly single, unified framework has begun, but more remains to be done.

Think Through Priority Rankings for Controls Within Families

The final release of the National Institute of Standards and Technology’s Special Publication 800-53 specifies a sequence priority for individual controls within a control family.

Although theoretically useful in deciding implementation sequence, the priority code adds little to the exercise in practicality. It is assigned without real information on a number of other variables internal to an organization that can affect how development proceeds. Final prioritization is best handled within an organization’s system development lifecycle process, where essential information regarding the operational environment, technology used, budget, acquisition and other dependencies are known.

For example, in the access control family, a session lock control is assigned a Priority 3 rating, below other controls such as separation of duties and least privilege. In fact, with the sophisticated software used today to implement access control functions, implementation of session lock is almost trivial and would seldom need to be deferred in lieu of other controls.

On the other hand, implementation of separation of duties and least privilege controls can be complex for organizations with tens of thousands of users operating across many job functions. It is useful to note the priority sequence offered in the publication, but it is important for a security manager to tailor implementation of the selected security controls based on actual information available in his or her organization.