STIG ID - BACF1042: Perform Audit Analysis

Audit trail, monitoring, analysis, and reporting provides automated, continuous online monitoring and audit trail creation capability to alert personnel of any unusual or inappropriate activity. Failure to perform audit log analysis can allow unusual or inappropriate activity to continue without review and actions taken.
ACF2
provides report generators and sample JCL to create various reports for audit trail purposes. Any attempted violation detected appears on a report. In addition, standard reports display updates to any of the three control databases (logonid, rule, or Infostorage). Thus, additions, changes, or deletions of any user or rule control information is visible to a person reviewing these reports. Records produced from these three databases and SMF records provide information presented in the various reports.
Your organization must ensure that a security log management policy is documented that implements a process to review and analyze information system audit records every seven days. Additionally, we strongly recommend a robust, continuous monitoring strategy and process for your mainframe to include active monitoring, real-time alerting of critical security and system changes, and weekly reviews of those items identified within this STIG article.
This STIG article provides recommended areas of review to include in your organization's security log management policy.
Identify Audit Finding
Review the following data to determine if you should consider remediation.
Follow these steps:
  1. Determine if your organization has a mainframe continuous monitoring strategy and program. The program must include a mainframe security log management policy and processes.
  2. Determine if the mainframe security log management policy and processes require review and analysis of information system security and audit and event records every seven days.
  3. Determine that the process maintains security event records for the minimal organizational required period. Recommendation is to store the security event records separate from all SMF records, allowing decentralized security administrators the capability to generate their own scoped security event reporting, utilize the standard
    ACF2
    security reports as needed, and not have to reprocess all SMF recorded event records or granting access to all SMF records generated on the system.
  4. Review the policy to determine if the following are included as possible areas for review:
    • A user attempting to read, update, delete, scratch, or alter a critical data set such as:
      • Security database files and security setup (parmib)
      • System parmlib such as SYS1.PARMLIB.
      • A user generating violations while attempting to update (or greater level), operating system data sets because they do not have permissions. Example Names can include: SYS1*, SYS2*, SYS3*, SYS4*, SYS*. Be sure to document your organizational standard data set names within your mainframe continuous monitoring strategy documentation.
      • A user generating violations while attempting to update (or greater level), APF libraries.
      • Violations against other organizationally-determined, critical data set names.
    • A user generating violations while attempting DASD Volume Level access.
    • Violations of JESSPOOL resources against domain level operations batch processing, system programmer submitted jobs, security related batch jobs, and system level started tasks.
    • Violations generated against critical system level resources FACILITY/IBMFAC and OPERCMDS.
    • A review of users' excessive password violations within a given day during the prior week. Excessive is determined by your organization and documented within your Mainframe System Security Plan.
    • Security changes performed at the infrastucture level during the prior week.
    • USS Security changes performed during the prior week.
    • Privileged USS commands executed including CHOWN, extattr +a and other privileged USS commands during the prior week.
    • Security violations within USS against critical USS resources during the prior week.
    • Monitor, at the discretion of your organization, any additional critical system level resources deemed necessary above and beyond the above specified.
  5. If a security log management policy does not exists which documents and implements a process to review and analyze information system security audit and event records every seven days,
    your organization has an audit finding
    . See Remediate Audit Finding.
  6. If a security log management policy exists which documents and implements a process to review and analyze information system audit records every seven days,
    your organization does not have an audit finding
    .
Remediate Audit Finding
The Information System Security Officer (ISSO) is responsible for ensuring a security log management policy is documented and implemented every seven days.
If your organization does not have a security log management policy documented, one must be created. This process must contain an audit trail of reviews. See the NIST Special Publication 800-92, Guide to Computer Security Log Management and step 2 under Identify Audit Finding, as guidelines for establishing the policy.
Control Correlation Identifier (CCI)
A Control Correlation Identifier (CCI) list provides a standard identifier and description for each of the singular, actionable statements that comprise a control or best practice. The following CCIs are related to this STIG.  For more information, see the National Institute of Standards and Technology website.
CCIs
: CCI-000148
CCI
:
CCI-000148
Published Date
:
2009-05-22
Definition
:
The organization reviews and analyzes information system audit records on an organization-defined frequency for indications of organization-defined inappropriate activity.
Type
:
policy
References
:
NIST: NIST SP 800-53 (v3): AU-6 a
NIST: NIST SP 800-53 Revision 4 (v4): AC-6 a
NIST: NIST SP 800-53A (v1): AU-6.1 (ii)