Database Auditing: What to Audit and Why

    By: Frank Pound on Dec 23, 2016

    Database Auditing: What to Audit and Why

    By Frank Pound  ◾  Michelle Malcher, Editor

    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 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.

    Figure 1: Six Steps of RMF

    Figure 1: Six Steps of RMF

    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.

    Security Control and Identifiers Security Controls and Identifiers - 2

     

     

     

     

     

     

     

     

     

     


     System Security Control Rating


    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:

    NIST Standard for Access Control - P1

    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.

    NIST Standard for Access Control - P2

    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.

    NIST Standard for Access Control - P3

    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.

    NIST Standard for Access Control - P0

    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.

    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 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:

    Special Publication 800-53 Security and Privacy Controls for Federal Information Systems and Organizations (revision 4).

    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.

     

    Figure 1: Six Steps of RMF

    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.

     

    Security Controls and Identifiers  

    ID        FAMILY

    AC       Access Control

    AT       Awareness and Training

    AU       Audit and Accountability

    CA       Security Assessment and Authorization

    CM      Configuration Management

    CP       Contingency Planning

    IA         Identification and Authentication

    IR        Incident Response

    MA       Maintenance

    MP       Media Protection

    PE       Physical and Environmental Protection

    PL        Planning

    PS       Personnel Security

    RA       Risk Assessment

    SA       System and Services Acquisition

    SC       System and Communications Protection

    SI         System and Information Integrity

    PM       Program Management 

     

    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:

     

    CNTL NO.           CONTROL NAME            PRIORITY            INITIAL CONTROL
    BASELINES                     

    AC-1      Access Control Policy and Procedures       P1          AC-1      AC-1      AC-1

    AC-2      Account Management      P1          AC-2      AC-2 (1) (2) (3) (4)            AC-2 (1) (2) (3) (4) (5) (11) (12) (13)

    AC-3      Access Enforcement        P1          AC-3      AC-3      AC-3

    AC-4      Information Flow Enforcement      P1          Not Selected       AC-4      AC-4

    AC-5      Separation of Duties        P1          Not Selected       AC-5      AC-5

    AC-6      Least Privilege   P1          Not Selected       AC-6 (1) (2) (5) (9) (10)    AC-6 (1) (2) (3) (5) (9) (10)

    AC-8      System Use Notification  P1          AC-8      AC-8      AC-8

    AC-17    Remote Access  P1          AC-17    AC-17 (1) (2) (3) (4)          AC-17 (1) (2) (3) (4)

    AC-18    Wireless Access P1          AC-18    AC-18 (1)             AC-18 (1) (4) (5)

    AC-19    Access Control for Mobile Devices              P1          AC-19    AC-19 (5)             AC-19 (5)

    AC-20    Use of External Information Systems          P1          AC-20    AC-20 (1) (2)       AC-20 (1) (2) 

     

    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.

     

    CNTL NO.           CONTROL NAME            PRIORITY            INITIAL CONTROL
    BASELINES                     

    AC-7      Unsuccessful Logon Attempts       P2          AC-7      AC-7      AC-7

    AC-12    Session Termination        P2          Not Selected       AC-12    AC-12

    AC-21    Information Sharing         P2          Not Selected       AC-21    AC-21 

     

     

    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.

     

    CNTL NO.           CONTROL NAME            PRIORITY            INITIAL CONTROL
    BASELINES                     

    AC-10    Concurrent Session Control          P3          Not Selected       Not Selected       AC-10

    AC-11    Session Lock      P3          Not Selected       AC-11 (1)             AC-11 (1)

    AC-14    Permitted Actions without Identification or Authentication    P3          AC-14    AC-14    AC-14

    AC-22    Publicly Accessible Content          P3          AC-22    AC-22    AC-22 

     

     

    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.

     

    CNTL NO.           CONTROL NAME            PRIORITY            INITIAL CONTROL
    BASELINES                     

    AC-9      Previous Logon (Access) Notification       &n

    Released: December 23, 2016, 3:08 pm | Updated: January 9, 2017, 2:32 pm
    Keywords: Feature | audit | database | Frank Pound


    Copyright © 2017 Communication Center. All Rights Reserved
    All material, files, logos and trademarks within this site are properties of their respective organizations.
    Terms of Service - Privacy Policy - Contact

    Independent Oracle Users Group
    330 N. Wabash Ave., Suite 2000, Chicago, IL 60611
    phone: 312-245-1579 | email: ioug@ioug.org

    IOUG Logo

    Copyright © 1993-2017 by the Independent Oracle Users Group
    Terms of Use | Privacy Policy