By Frank Pound | Edited by Michelle Malcher

In the first article in this series (How to Comply with Audit and Make Your Life Easier), I outlined how to set up a set of management control processes using an existing Information Technology (IT) policy, if one exists.

In this article, I lay out a set of steps that help clearly articulate what should be audited and why (Steps 1 and 2) using national and international security standards as the basis of the rationale.

The basis of many current IT security policies is balancing and setting standards for the protection of Confidentiality, Integrity, and Availability (CIA) of systems. This article deals specifically with database systems, but the steps described can be used for many other types of systems.

National Institute of Standards and Technology (NIST)

A U.S. Information Technology lab (ITL) is dedicated to promoting innovation and industrial competitiveness, which produces a standard to help organizations increase security. They are mandated to develop information security standards and guidelines according to the Federal Information Security Management Act (FISMA), Public Law (P.L.) 107-347.

NIST publishes two documents to aid organizations in the task of setting IT security policies:

1. Special Publication 800-53 Security and Privacy Controls for Federal Information Systems and Organizations (revision 4).
2. Special Publication 800-53A Assessing Security and Privacy Controls in Federal Information Systems and Organizations: Building Effective Assessment Plans (revision 4).

Special Publication 800-53A is a companion guideline to Special Publication 800-53. Each publication provides guidance for implementing specific steps in the Risk Management Framework (RMF) (800-37: Guide for Applying the Risk Management Framework to Federal Information Systems). The outlined framework describes six steps as illustrated in Figure 1.

The RMF apply to each special publication as follows:

• Special Publication 800-53 = RMF Step 2: SELECT the security and privacy control (i.e., determining what controls are needed to manage risks to organizational operations and assets, individuals, other organizations, and the Nation).
• Special Publication 800-53A = RMF Step 4: Assess the control.
• Special Publication 800-53A = RMF Step 6: Monitor the control; and provides guidance on the security assessment and privacy assessment processes.

This guidance includes how to build effective assessment plans and how to analyze and manage assessment results.

FIPS 200 and SP 800-53

The Federal Information Processing Standards (FIPS) 200 is the second of two U.S. Federal standards, which defines a security catalog for categorization of controls. Categorizing the data assets of your organization is the first step in understanding what controls are required to secure your data.

The goal of this set of documents is to help organizations perform their due diligence related to management controls.

The guidance and subsequent management controls are not meant to be static, but rather to be assessed and reevaluated at regular intervals to ensure they are constantly relevant, accurate and valid.

The security controls identified by NIST are divided into 18 groups/families.

When selecting controls, the organization is responsible to “determine the most cost-effective, appropriate set of security controls, which if implemented and determined to be effective, would mitigate risk while complying with security requirements defined.”

NIST provides baseline controls to ease the processes of selecting controls and groupings.

I strongly recommend reading the NIST documentation to increase your knowledge and skills in selecting, and implementing appropriate controls for your organizations systems.

Before starting a critical pre-requisite is to understand the criticality and sensitivity (statement of sensitivity: SOW) of the data contained in each system.

Baselines are based on the following assumptions:

• Information systems are located in physical facilities
• User data/information in organizational information systems is relatively persistent
• Information systems are multi-user (either serially or concurrently) in operation
• Some user data/information in organizational information systems is not shareable with other users who have authorized access to the same systems
• Information systems exist in networked environments
• Information systems are general purpose in nature
• Organizations have the necessary structure, resources and infrastructure to implement the controls.

If the assumptions do not apply to the system for which the control is created, then adjust accordingly. This may mean the implementation of compensating control(s) to compensate for the difference.

As with most control frameworks and architectural decisions, a record of decision is highly recommended and may already be mandated by your organization.

Some controls may be specifically related to one another in an understood flow/sequence. If so, then each relationship should be recorded in a matrix where the ordering of the controls is identified. NIST suggests the use of P0, P1, P2, P3, … Pn. Where P0 indicates no relationship, P1 indicates the first or top priority control followed in ascending order by P2, P3, etc.

Identify Controls Relevant to the Information Systems

After reviewing and becoming comfortable with how security controls are ranked and rated, the next step is to review the set of recommended controls and identify those, which are most relevant to your information (e.g., database) systems.

For brevity, we will review those controls recommended by the NIST standard for Access Control.

In the first round, I recommend focusing on the P1 ranked controls, which are as follows:

Typically, all controls require documentation, which is recorded in the first control for each family. In this case it is AC-1: Access Control Policy and Procedures. This is not strictly a control, but is a pre-requisite for the creation and auditing of the controls.

Traditionally, controls AC-2, AC-3, AC-4, AC-5, AC-6, and AC-8 fall under the prevue of database administration. Controls number AC-17, AC-18, AC-19 and AC-20 are traditionally the responsibility of the network and security teams to monitor and control on behalf of many organizations. The controls should be confirmed in writing by the responsible team and kept as proof the database administration team has validated the controls exist and understand where the procedural documentation exists for reference purposes.

Associate All Dependent Sub-Controls

Once the P1 controls have been identified, it is time to identify the P2, P3 and P0 controls to ensure all the controls are included in your security plan.

Of the three P2 controls, I envision the controls as being monitored in the following manner:

• AC-7: One report grouped by user and count for the monitoring period.
• AC-7: One report grouped by user by day to understand risk of the unsuccessful logon attempts.
• AC-12: One report listing the configuration of each granted profile listing CONNECT_TIME, and IDLE_TIME.
• AC-12: One report listing the “LOGOFF BY CLEANUP” sessions, which could have been terminated by reaching/exceeding the CONNECT_TIME or IDLE_TIME profiles limits.
• AC-21: One report listing logons recorded where the account used does not match the OS User Account. However, this will only work if the network/OS account name is the same as the DB account.

Of the four P3 controls, I envision the controls as being monitored in the following manner:

• AC-10: One report listing the configuration of each granted profile listing session limit for SESSIONS_PER_USER and
• CPU_PER_SESSION.
• AC-11: One report listing session locking occurrences.
• AC-14: This would typically be identified by reviewing Oracle Security Alerts, which identify vulnerabilities on a periodic basis. This should be a collaborative effort between the DBA and Security monitoring team. This requires manual documentation of review.
• AC-22: One report listing any non-standard grants to the PUBLIC group.

Of the five P0 controls, I believe that each of these require documentation and education of the database administration team, developers and the security teams, agreeing on how these will be mitigated.

Using the examples provided for the Access Control family, the same process needs to be performed for all of the remaining families listed in the Security and Control Identifiers table.

In the first article in this series (How to Comply with Audit and Make Your Life Easier), I outlined how to set up a set of management control processes using an existing Information Technology (IT) policy, if one exists.

In this article, I lay out a set of steps that help clearly articulate what should be audited and why (Steps 1 and 2) using national and international security standards as the basis of the rationale.

The basis of many current IT security policies is balancing and setting standards for the protection of Confidentiality, Integrity, and Availability (CIA) of systems. This article deals specifically with database systems, but the steps described can be used for many other types of systems.