Cyber Trackr - Free Compliance Library
Cyber Trackr
The Free Compliance Library

Application Security and Development Security Technical Implementation Guide

  • Version/Release: V5R3
  • Published: 2023-06-08
  • Released: 2023-07-26
  • Expand All:
  • Severity:
  • Sort:
Compare

Select any two versions of this STIG to compare the individual requirements

View

Select any old version/release of this STIG to view the previous requirements

This Security Technical Implementation Guide is published as a tool to improve the security of Department of Defense (DOD) information systems. The requirements are derived from the National Institute of Standards and Technology (NIST) 800-53 and related documents. Comments or proposed revisions to this document should be sent via e-mail to the following address: disa.stig_spt@mail.mil.
b
The application must provide a capability to limit the number of logon sessions per user.
AC-10 - Medium - CCI-000054 - V-222387 - SV-222387r879511_rule
RMF Control
AC-10
Severity
Medium
CCI
CCI-000054
Version
APSC-DV-000010
Vuln IDs
  • V-222387
  • V-69239
Rule IDs
  • SV-222387r879511_rule
  • SV-83861
Application management includes the ability to control the number of users and user sessions that utilize an application. Limiting the number of allowed users and sessions per user is helpful in limiting risks related to DoS attacks. This requirement may be met via the application or by utilizing information system session control provided by a web server or other underlying solution that provides specialized session management capabilities. If it has been specified that this requirement will be handled by the application, the capability to limit the maximum number of concurrent single user sessions must be designed and built into the application. This requirement addresses concurrent sessions for individual system accounts and does not address concurrent sessions by single users via multiple system accounts. The maximum number of concurrent sessions should be defined based upon mission needs and the operational environment for each system.
Checks: C-24057r493069_chk

For production environments; Review the system documentation, identify the number of application user logon sessions allowed per user, identify the methods utilized for user session management or have application administrator describe how the application implements user session management. Utilize the management interface that is used to set the user session values, or examine configuration files in order to review user session configuration settings. Ensure the number of sessions allowed per user is specified in accordance with the organizational requirements. For development environments; have the developer provide design documentation or demonstrate how the application is designed to limit the number of simultaneous user logon sessions. If the application is not configured to limit the number of logon sessions per user as defined by the organization, this is a finding.

Fix: F-24046r493070_fix

Design and configure the application to specify the number of logon sessions that are allowed per user.

b
The application must clear temporary storage and cookies when the session is terminated.
AC-12 - Medium - CCI-002361 - V-222388 - SV-222388r879673_rule
RMF Control
AC-12
Severity
Medium
CCI
CCI-002361
Version
APSC-DV-000060
Vuln IDs
  • V-222388
  • V-69241
Rule IDs
  • SV-222388r879673_rule
  • SV-83863
Persistent cookies are a primary means by which a web application will store application state and user information. Since HTTP is a stateless protocol, this persistence allows the web application developer to provide a robust and customizable user experience. However, if a web application stores user authentication information within a persistent cookie or other temporary storage mechanism, this information can be stolen and used to compromise the users account. Likewise, HTML 5 provides the developer with a client storage capability where application data larger than the 4K cookie size limit can be stored on the local client. While this can be beneficial to the developer, this is considered insecure storage and should not be used for storing sensitive session or security tokens. A cross site scripting attack can put this data at risk. Web applications must clear sensitive data from files and storage areas on the client when the session is terminated.
Checks: C-24058r493072_chk

Review application design documentation and interview application administrator to identify how the application makes use of temporary client storage and cookies. Identify cookie and web storage locations on the client. Clear all browser cookies and web cache. Log on to the application and perform several standard operations, noting if the application ever prompts the user to accept a cookie. If prompted by the browser to save the user ID and password (decline to save the user ID and password), this is a finding. Log out of the application and close the browser. Reopen the browser and examine the stored cookies. The cookies displayed should be related to the application website. The procedure to view cookies will vary according to the browser used. Some modern browsers are making use of SQLite databases to store cookie data so use of a SQLite db reader/browser may be required. Open the cookies related to the application website and search for any identification or authentication information. While authentication information can vary on a per application basis, this is most often specified as "username=x", or "password=x". If the web application prompts the user to save their password, or if a username or password value exists within a cookie or within local storage locations, even if hashed, this is a finding. The application may use means other than cookies to store user information. If the reviewer detects an alternative mechanism for storing information locally, examine the data storage to ensure no authentication or other sensitive information is present.

Fix: F-24047r493073_fix

Design and configure the application to clear sensitive data from cookies and local storage when the user logs out of the application.

b
The application must automatically terminate the non-privileged user session and log off non-privileged users after a 15 minute idle time period has elapsed.
AC-12 - Medium - CCI-002361 - V-222389 - SV-222389r879673_rule
RMF Control
AC-12
Severity
Medium
CCI
CCI-002361
Version
APSC-DV-000070
Vuln IDs
  • V-222389
  • V-69243
Rule IDs
  • SV-222389r879673_rule
  • SV-83865
Leaving a user’s application session established for an indefinite period of time increases the risk of session hijacking. Session termination terminates an individual user's logical application session after 15 minutes of application inactivity at which time the user must re-authenticate and a new session must be established if the user desires to continue work in the application.
Checks: C-24059r493075_chk

Ask the application representative to demonstrate the configuration setting where the idle time out value is defined. Alternatively, logon with a regular application user account and let the session sit idle for 15 minutes. Attempt to access the application after 15 minutes of inactivity. If the configuration setting is not set to time out user sessions after 15 minutes of inactivity, or if the regular user session used for testing does not time out after 15 minutes of inactivity, this is a finding.

Fix: F-24048r493076_fix

Design and configure the application to terminate the non-privileged users session after 15 minutes of inactivity.

b
The application must automatically terminate the admin user session and log off admin users after a 10 minute idle time period is exceeded.
AC-12 - Medium - CCI-002361 - V-222390 - SV-222390r879673_rule
RMF Control
AC-12
Severity
Medium
CCI
CCI-002361
Version
APSC-DV-000080
Vuln IDs
  • V-222390
  • V-69245
Rule IDs
  • SV-222390r879673_rule
  • SV-83867
Leaving an admin user's application session established for an indefinite period of time increases the risk of session hijacking. Session termination terminates an individual user's logical application session after 10 minutes of application inactivity at which time the user must re-authenticate and a new session must be established if the user desires to continue work in the application.
Checks: C-24060r493078_chk

Ask the application representative to demonstrate the application configuration setting where the idle time out value is defined for admin users. Alternatively, logon with an admin user account and let the session sit idle for 10 minutes. Attempt to access the application after 10 minutes of inactivity. If the configuration setting is not set to time out admin user sessions after 10 minutes of inactivity, or if the session used for testing does not time out after 10 minutes of inactivity, this is a finding.

Fix: F-24049r493079_fix

Design and configure the application to terminate the admin users session after 10 minutes of inactivity.

b
Applications requiring user access authentication must provide a logoff capability for user initiated communication session.
AC-12 - Medium - CCI-002363 - V-222391 - SV-222391r879674_rule
RMF Control
AC-12
Severity
Medium
CCI
CCI-002363
Version
APSC-DV-000090
Vuln IDs
  • V-222391
  • V-69247
Rule IDs
  • SV-222391r879674_rule
  • SV-83869
If a user cannot explicitly end an application session, the session may remain open and be exploited by an attacker. Applications providing user access must provide the ability for users to manually terminate their sessions and log off.
Checks: C-24061r493081_chk

If the application does not provide an interface for interactive user access, this is not applicable. Log on to the application with a valid user account. Examine the user interface. Identify the command or link that provides the logoff function. Activate the user logoff function. Observe user interface and attempt to interact with the application. Confirm user interaction with the application is no longer possible. If the user session is not terminated or if the logoff function does not exist, this is a finding.

Fix: F-24050r493082_fix

Design and configure the application to provide all users with the capability to manually terminate their application session.

a
The application must display an explicit logoff message to users indicating the reliable termination of authenticated communications sessions.
AC-12 - Low - CCI-002364 - V-222392 - SV-222392r879675_rule
RMF Control
AC-12
Severity
Low
CCI
CCI-002364
Version
APSC-DV-000100
Vuln IDs
  • V-222392
  • V-69249
Rule IDs
  • SV-222392r879675_rule
  • SV-83871
If a user is not explicitly notified that their application session has been terminated, they cannot be certain that their session did not remain open. Applications with a user access interface must provide an explicit logoff message to the user upon successful termination of the user session.
Checks: C-24062r493084_chk

If the application does not provide an interface for interactive user access, this is not applicable. Log on to the application with a valid user account. Examine the user interface. Identify the command or link that provides the logoff function. Activate the user logoff function. If the application does not provide an explicit logoff message indicating the user session has been terminated, this is a finding.

Fix: F-24051r493085_fix

Design and configure the application to provide an explicit logoff message to users indicating a successful logoff has occurred upon user session termination.

b
The application must associate organization-defined types of security attributes having organization-defined security attribute values with information in storage.
AC-16 - Medium - CCI-002262 - V-222393 - SV-222393r879689_rule
RMF Control
AC-16
Severity
Medium
CCI
CCI-002262
Version
APSC-DV-000110
Vuln IDs
  • V-222393
  • V-69251
Rule IDs
  • SV-222393r879689_rule
  • SV-83873
Without the association of security attributes to information, there is no basis for the application to make security related access-control decisions. Security attributes are abstractions representing the basic properties or characteristics of an entity (e.g., subjects and objects) with respect to safeguarding information. These attributes are typically associated with internal data structures (e.g., records, buffers, files) within the information system and are used to enable the implementation of access control and flow control policies, reflect special dissemination, handling or distribution instructions, or support other aspects of the information security policy. One example includes marking data as classified or FOUO. These security attributes may be assigned manually or during data processing but either way, it is imperative these assignments are maintained while the data is in storage. If the security attributes are lost when the data is stored, there is the risk of a data compromise. Classify the system hosting the application with default classification. Treat all unmarked data at the highest classification as the overall hosting system is classified. If there is no classification, mark system high.
Checks: C-24063r493087_chk

Review the application documentation and interview the application administrator. Determine if the application processes classified, FOUO, or other data that is required to be marked and identify if the application requirements specify data markings of any other types of data. If the application does not contain classified, FOUO, or other data that is required to be marked, this requirement is not applicable. Review the database or other storage mechanism and have the application administrator identify and demonstrate how the application assigns and maintains data markings while the data is in storage. Typical methods for marking data include utilizing a table or data base field that contains the marking information and associating the marking information with the data. If application data required to be marked is not marked and does not retain its marking while it is being stored, this is a finding.

Fix: F-24052r493088_fix

Design and configure the application to assign data marking and ensure the marking is retained when the data is stored.

b
The application must associate organization-defined types of security attributes having organization-defined security attribute values with information in process.
AC-16 - Medium - CCI-002263 - V-222394 - SV-222394r879690_rule
RMF Control
AC-16
Severity
Medium
CCI
CCI-002263
Version
APSC-DV-000120
Vuln IDs
  • V-222394
  • V-69253
Rule IDs
  • SV-222394r879690_rule
  • SV-83875
Without the association of security attributes to information, there is no basis for the application to make security related access-control decisions. Security attributes are abstractions representing the basic properties or characteristics of an entity (e.g., subjects and objects) with respect to safeguarding information. These attributes are typically associated with internal data structures (e.g., records, buffers, files) within the information system and are used to enable the implementation of access control and flow control policies, reflect special dissemination, handling or distribution instructions, or support other aspects of the information security policy. One example includes marking data as classified or FOUO. These security attributes may be assigned manually or during data processing but either way, it is imperative these assignments are maintained while the data is in process. If the security attributes are lost when the data is being processed, there is the risk of a data compromise.
Checks: C-24064r493090_chk

Review the application documentation and interview the application administrator. Identify if the application requirements include data marking. Also determine if the application processes classified, FOUO or other data that is required to be marked. If the application does not contain classified, FOUO or have data marking requirements, this requirement is not applicable. Access the user interface for the application and navigate through the application. Perform several application actions that will manipulate data contained within the application. For example, create a test record and assign a data marking to the data element. Save the test record, close the data entry fields and navigate to display the test record. Perform an edit action on the test data that does not edit the marking itself or perform any other form of data processing such as assigning the data to another users work queue for review or printing the data, ensure the data marking is retained throughout the data processing actions. If application data required to be marked does not retain its marking while it is being processed by the application, this is a finding.

Fix: F-24053r493091_fix

Design and configure the application to retain the data marking when processing data.

b
The application must associate organization-defined types of security attributes having organization-defined security attribute values with information in transmission.
AC-16 - Medium - CCI-002264 - V-222395 - SV-222395r879691_rule
RMF Control
AC-16
Severity
Medium
CCI
CCI-002264
Version
APSC-DV-000130
Vuln IDs
  • V-222395
  • V-69255
Rule IDs
  • SV-222395r879691_rule
  • SV-83877
Without the association of security attributes to information, there is no basis for the application to make security related access-control decisions. Security attributes are abstractions representing the basic properties or characteristics of an entity (e.g., subjects and objects) with respect to safeguarding information. These attributes are typically associated with internal data structures (e.g., records, buffers, files) within the information system and are used to enable the implementation of access control and flow control policies, reflect special dissemination, handling or distribution instructions, or support other aspects of the information security policy. One example includes marking data as classified or FOUO. These security attributes may be assigned manually or during data processing but either way, it is imperative these assignments are maintained while the data is in transmission. If the security attributes are lost when the data is being transmitted, there is the risk of a data compromise.
Checks: C-24065r493093_chk

Review the application documentation and interview the application administrator. Identify if the application requirements include data marking also determine if the application processes classified, FOUO or other data that is required to be marked. Access the user interface for the application and navigate through the application. Perform an application action that will transmit marked data that is contained within the application. If the application does not contain classified, FOUO or have data marking requirements, or if the application does not transmit data, this requirement is not applicable. E.g., create a test record and assign a data marking to the data element. Save the test record, close the data entry fields and navigate to display the test record. Initiate the application processes to transmit data. Access remote system or have person with access to remote system verify the data marking is retained after the data transmission. If application data required to be marked does not retain its marking when it is being transmitted by the application, this is a finding.

Fix: F-24054r493094_fix

Design and configure the application to retain the data marking when transmitting data.

b
The application must implement DoD-approved encryption to protect the confidentiality of remote access sessions.
AC-17 - Medium - CCI-000068 - V-222396 - SV-222396r879519_rule
RMF Control
AC-17
Severity
Medium
CCI
CCI-000068
Version
APSC-DV-000160
Vuln IDs
  • V-222396
  • V-69257
Rule IDs
  • SV-222396r879519_rule
  • SV-83879
Without confidentiality protection mechanisms, unauthorized individuals may gain access to sensitive information via a remote access session. Remote access is access to DoD nonpublic information systems by an authorized user (or an information system) communicating through an external, non-organization-controlled network. Remote access methods include, for example, dial-up, broadband, and wireless. Encryption provides a means to secure the remote connection to prevent unauthorized access to the data traversing the remote access connection thereby providing a degree of confidentiality. The encryption strength of mechanism is selected based on the security categorization of the information.
Checks: C-24066r493096_chk

Review the application documentation and interview the system administrator. Identify the application encryption capabilities and methods for implementing encryption protection. For web based applications; open the web browser and access the website URL. Use the browser and determine if the session is protected via TLS. A secure connection is usually indicated in the upper left hand corner of the URL by a padlock icon. Click on the padlock icon and examine the connection information. Determine if TLS encryption is used to secure the session. For non-web based applications, determine the TCP/IP port, protocol and method used for establishing client connections to the remote server. Review application configuration settings to ensure encryption is specified and via TLS. If the connection is not secured with TLS, this is a finding.

Fix: F-24055r493097_fix

Design and configure applications to use TLS encryption to protect the confidentiality of remote access sessions.

b
The application must implement cryptographic mechanisms to protect the integrity of remote access sessions.
AC-17 - Medium - CCI-001453 - V-222397 - SV-222397r879520_rule
RMF Control
AC-17
Severity
Medium
CCI
CCI-001453
Version
APSC-DV-000170
Vuln IDs
  • V-222397
  • V-69259
Rule IDs
  • SV-222397r879520_rule
  • SV-83881
Without integrity protection mechanisms, unauthorized individuals may gain access to sensitive information via a remote access session. Remote access is access to DoD nonpublic information systems by an authorized user (or an information system) communicating through an external, non-organization-controlled network. Remote access methods include, for example, dial-up, broadband, and wireless. Encryption provides a means to secure the remote connection to prevent unauthorized access to the data traversing the remote access connection. Without integrity protection mechanisms, unauthorized individuals may be able to insert inauthentic content into a remote session. The encryption strength of mechanism is selected based on the security categorization of the information.
Checks: C-24067r493099_chk

Review the application documentation and interview the system administrator. Identify the application encryption capabilities and methods for implementing encryption protection. For web based applications; open the web browser and access the website URL. Use the browser and determine if the session is protected via TLS. A secure connection is usually indicated in the upper left hand corner of the URL by a padlock icon. Click on the padlock icon and examine the connection information. Determine if TLS encryption is used to secure the session. For non-web based applications, determine the TCP/IP port, protocol and method used for establishing client connections to the remote server. Review application configuration settings to ensure encryption is specified and via TLS. If the connection is not secured with TLS, this is a finding.

Fix: F-24056r493100_fix

Design and configure applications to use TLS encryption to protect the integrity of remote access sessions.

b
Applications with SOAP messages requiring integrity must include the following message elements:-Message ID-Service Request-Timestamp-SAML Assertion (optionally included in messages) and all elements of the message must be digitally signed.
AC-17 - Medium - CCI-001453 - V-222398 - SV-222398r879520_rule
RMF Control
AC-17
Severity
Medium
CCI
CCI-001453
Version
APSC-DV-000180
Vuln IDs
  • V-222398
  • V-69261
Rule IDs
  • SV-222398r879520_rule
  • SV-83883
Digitally signed SOAP messages provide message integrity and authenticity of the signer of the message independent of the transport layer. Service requests may be intercepted and changed in transit and the data integrity may be at risk if the SOAP message is not digitally signed. Functional architecture aspects of the application security plan identify the application data elements that require data integrity protection.
Checks: C-24068r493102_chk

Review the application documentation, system security plan, application architecture diagrams and interview the application administrator. Review the design document for web services using SOAP messages. If the application does not utilize SOAP messages, this check is not applicable. Review the design document and SOAP messages. Verify the Message ID, Service Request, Timestamp, and SAML Assertion are included in the SOAP message. If they are included, verify they are signed with a certificate. If SOAP messages requiring integrity do not have the Message ID, Service Request, Timestamp, and SAML Assertion signed, or if any part of the message is not digitally signed, this is a finding.

Fix: F-24057r493103_fix

Design and configure the application to sign the following message elements for SOAP messages requiring integrity: - Message ID - Service Request - Timestamp - SAML Assertion - Message elements

c
Messages protected with WS_Security must use time stamps with creation and expiration times.
AC-17 - High - CCI-000068 - V-222399 - SV-222399r879519_rule
RMF Control
AC-17
Severity
High
CCI
CCI-000068
Version
APSC-DV-000190
Vuln IDs
  • V-222399
  • V-69279
Rule IDs
  • SV-222399r879519_rule
  • SV-83901
The lack of time stamps could lead to the eventual replay of the message, leaving the application susceptible to replay events which may result in an immediate loss of confidentiality.
Checks: C-24069r493105_chk

Ask the application representative for the design document. Review the design document for web services using WS-Security tokens. If the application does not utilize WS-Security tokens, this check is not applicable. Examine the contents of a SOAP message using WS Security; all messages should contain time stamps, sequence numbers, and expiration. If messages using WS Security do not contain time stamps, sequence numbers, and expiration, this is a finding.

Fix: F-24058r493106_fix

Design and configure applications using WS-Security messages to use time stamps with creation and expiration times and sequence numbers.

c
Validity periods must be verified on all application messages using WS-Security or SAML assertions.
AC-17 - High - CCI-000068 - V-222400 - SV-222400r879519_rule
RMF Control
AC-17
Severity
High
CCI
CCI-000068
Version
APSC-DV-000200
Vuln IDs
  • V-222400
  • V-69281
Rule IDs
  • SV-222400r879519_rule
  • SV-83903
When using WS-Security in SOAP messages, the application should check the validity of the time stamps with creation and expiration times. Time stamps that are not validated may lead to a replay event and provide immediate unauthorized access of the application. Unauthorized access results in an immediate loss of confidentiality.
Checks: C-24070r493108_chk

Ask the application representative for the design document. Review the design document for web services. If the application does not utilize WSS or SAML assertions, this requirement is not applicable. Review the design document and verify validity periods are checked on all messages using WS-Security or SAML assertions. If the design document does not exist, or does not indicate validity periods are checked on messages using WS-Security or SAML assertions, this is a finding.

Fix: F-24059r493109_fix

Design and configure the application to use validity periods, ensure validity periods are verified on all WS-Security token profiles and SAML Assertions.

b
The application must ensure each unique asserting party provides unique assertion ID references for each SAML assertion.
AC-17 - Medium - CCI-000068 - V-222401 - SV-222401r879519_rule
RMF Control
AC-17
Severity
Medium
CCI
CCI-000068
Version
APSC-DV-000210
Vuln IDs
  • V-222401
  • V-69283
Rule IDs
  • SV-222401r879519_rule
  • SV-83905
SAML is a standard for exchanging authentication and authorization data between security domains. SAML uses security tokens containing assertions to pass information about a principal (usually an end user) between a SAML authority, (identity provider), and a SAML consumer, (service provider). SAML assertions are usually made about a subject, (user) represented by the element. SAML assertion identifiers should be unique across a system implementation. Duplicate SAML assertion identifiers could lead to unauthorized access to a web service.
Checks: C-24071r493111_chk

Ask the application representative for the design document. Review the design document for web services using SAML assertions. If the application does not utilize SAML assertions, this check is not applicable. Review the design document and verify SAML assertion identifiers are not reused by a single asserting party. If the design document does not exist, or does not indicate SAML assertion identifiers which are unique for each asserting party, this is a finding.

Fix: F-24060r493112_fix

Design and configure each SAML assertion authority to use unique assertion identifiers.

b
The application must ensure encrypted assertions, or equivalent confidentiality protections are used when assertion data is passed through an intermediary, and confidentiality of the assertion data is required when passing through the intermediary.
AC-17 - Medium - CCI-000068 - V-222402 - SV-222402r879519_rule
RMF Control
AC-17
Severity
Medium
CCI
CCI-000068
Version
APSC-DV-000220
Vuln IDs
  • V-222402
  • V-69285
Rule IDs
  • SV-222402r879519_rule
  • SV-83907
SAML is a standard for exchanging authentication and authorization data between security domains. SAML uses security tokens containing assertions to pass information about a principal (usually an end user) between a SAML authority, (identity provider), and a SAML consumer, (service provider). SAML assertions are usually made about a subject, (user) represented by the element. The confidentially of the data in a message as the message is passed through an intermediary web service may be required to be restricted by the intermediary web service. The intermediary web service may leak or distribute the data contained in a message if not encrypted or protected.
Checks: C-24072r493114_chk

Ask the application representative for the design document. Review the design document for web services using WS-Security tokens. If the application does not utilize WS-Security tokens, this check is not applicable. Verify all WS-Security tokens are transmitted via an approved encryption method. If the design document does not exist, or does not indicate all WS-Security tokens are only transmitted via an approved encryption method, this is a finding.

Fix: F-24061r493115_fix

Encrypt assertions or use equivalent confidentiality when sensitive assertion data is passed through an intermediary.

c
The application must use the NotOnOrAfter condition when using the SubjectConfirmation element in a SAML assertion.
AC-17 - High - CCI-000068 - V-222403 - SV-222403r879519_rule
RMF Control
AC-17
Severity
High
CCI
CCI-000068
Version
APSC-DV-000230
Vuln IDs
  • V-222403
  • V-69287
Rule IDs
  • SV-222403r879519_rule
  • SV-83909
SAML is a standard for exchanging authentication and authorization data between security domains. SAML uses security tokens containing assertions to pass information about a principal (usually an end user) between a SAML authority, (identity provider), and a SAML consumer, (service provider). SAML assertions are usually made about a subject, (user) represented by the element. When a SAML assertion is used with a element, a begin and end time for the should be set to prevent reuse of the message at a later time. Not setting a specific time period for the , may grant immediate access to an attacker and result in an immediate loss of confidentiality.
Checks: C-24073r493117_chk

Ask the application representative for the design document. Review the design document for web services using SAML assertions. If the application does not utilize SAML assertions, this check is not applicable. Examine the contents of a SOAP message using the <SubjectConfirmation> element. All messages should contain the <NotOnOrAfter> element. This can be accomplished if the application allows the ability to view XML messages or via a protocol analyzer like Wireshark. If SOAP messages do not contain <NotOnOrAfter> elements, this is a finding.

Fix: F-24062r493118_fix

Design and configure the application to use the <NotOnOrAfter> condition when using the <SubjectConfirmation> element in a SAML assertion.

c
The application must use both the NotBefore and NotOnOrAfter elements or OneTimeUse element when using the Conditions element in a SAML assertion.
AC-17 - High - CCI-000068 - V-222404 - SV-222404r879519_rule
RMF Control
AC-17
Severity
High
CCI
CCI-000068
Version
APSC-DV-000240
Vuln IDs
  • V-222404
  • V-69289
Rule IDs
  • SV-222404r879519_rule
  • SV-83911
SAML is a standard for exchanging authentication and authorization data between security domains. SAML uses security tokens containing assertions to pass information about a principal (usually an end user) between a SAML authority, (identity provider), and a SAML consumer, (service provider). SAML assertions are usually made about a subject, (user) represented by the element. When a SAML assertion is used with a element, a begin and end time for the element should be set in order to specify a timeframe in which the assertion is valid. Not setting a specific time period for the element, the possibility exists of granting immediate access or elevated privileges to an attacker which results in an immediate loss of confidentiality.
Checks: C-24074r493120_chk

Ask the application representative for the design document. Review the design document for web services using SAML assertions. If the application does not utilize SAML assertions, this check is not applicable. Examine the contents of a SOAP message using the &lt;Conditions&gt; element; all messages should contain the &lt;NotBefore&gt; and &lt;NotOnOrAfter&gt; or &lt;OneTimeUse&gt; element when in a SAML Assertion. This can be accomplished using a protocol analyzer such as Wireshark. If SOAP using the &lt;Conditions&gt; element does not contain &lt;NotBefore&gt; and &lt;NotOnOrAfter&gt; or &lt;OneTimeUse&gt; elements, this is a finding.

Fix: F-24063r493121_fix

Design and configure the application to implement the use of the <NotBefore> and <NotOnOrAfter> or <OneTimeUse> when using the <Conditions> element in a SAML assertion.

b
The application must ensure if a OneTimeUse element is used in an assertion, there is only one of the same used in the Conditions element portion of an assertion.
AC-17 - Medium - CCI-000068 - V-222405 - SV-222405r879519_rule
RMF Control
AC-17
Severity
Medium
CCI
CCI-000068
Version
APSC-DV-000250
Vuln IDs
  • V-222405
  • V-69291
Rule IDs
  • SV-222405r879519_rule
  • SV-83913
Multiple elements used in a SAML assertion can lead to elevation of privileges, if the application does not process SAML assertions correctly.
Checks: C-24075r493123_chk

Ask the application representative for the design document. Review the design document for web services using SAML assertions. If the application does not utilize SAML assertions, this check is not applicable. Examine the contents of a SOAP message using the OneTimeUse element; all messages should contain only one instance of a &lt;OneTimeUse&gt; element in a SAML assertion. This can be accomplished using a protocol analyzer such as Wireshark. If SOAP message uses more than one, OneTimeUse element in a SAML assertion, this is a finding.

Fix: F-24064r493124_fix

When using OneTimeUse elements in a SAML assertion only allow one, OneTimeUse element to be used in the conditions element of a SAML assertion.

b
The application must ensure messages are encrypted when the SessionIndex is tied to privacy data.
AC-17 - Medium - CCI-000068 - V-222406 - SV-222406r879519_rule
RMF Control
AC-17
Severity
Medium
CCI
CCI-000068
Version
APSC-DV-000260
Vuln IDs
  • V-222406
  • V-69293
Rule IDs
  • SV-222406r879519_rule
  • SV-83915
When the SessionIndex is tied to privacy data (e.g., attributes containing privacy data) the message should be encrypted. If the message is not encrypted there is the possibility of compromise of privacy data.
Checks: C-24076r493126_chk

Ask the application representative for the design document. Review the design document for web services using SAML assertions. If the application does not utilize SAML assertions, this check is not applicable. Examine the contents of a SOAP message using a SessionIndex in the SAML element AuthnStatement. Verify the information which is tied to the SessionIndex. If the SessionIndex is tied to privacy information, and it is not encrypted, this is a finding.

Fix: F-24065r493127_fix

Encrypt messages when the SessionIndex is tied to privacy data.

b
The application must provide automated mechanisms for supporting account management functions.
AC-2 - Medium - CCI-000015 - V-222407 - SV-222407r879522_rule
RMF Control
AC-2
Severity
Medium
CCI
CCI-000015
Version
APSC-DV-000280
Vuln IDs
  • V-222407
  • V-69295
Rule IDs
  • SV-222407r879522_rule
  • SV-83917
Enterprise environments make application account management challenging and complex. A manual process for account management functions adds the risk of a potential oversight or other error. Manual examples include but are not limited to admin staff logging into the system or systems and manually performing step by step actions affecting user accounts that could otherwise be automated. This does not include any manual steps taken to initiate automated processes or the use of automated systems. A comprehensive application account management process that includes automation helps to ensure accounts designated as requiring attention are consistently and promptly addressed. Examples include, but are not limited to, using automation to take action on multiple accounts designated as inactive, suspended or terminated or by disabling accounts located in non-centralized account stores such as multiple servers. This requirement applies to all account types, including individual/user, shared, group, system, guest/anonymous, emergency, developer/manufacturer/vendor, temporary, and service. The application must be configured to automatically provide account management functions and these functions must immediately enforce the organization's current account policy. The automated mechanisms may reside within the application itself or may be offered by the operating system or other infrastructure providing automated account management capabilities. Automated mechanisms may be comprised of differing technologies that when placed together contain an overall automated mechanism supporting an organization's automated account management requirements. Account management functions include: assignment of group or role membership; identifying account type; specifying user access authorizations (i.e., privileges); account removal, update, or termination; and administrative alerts. The use of automated mechanisms can include, for example: using email or text messaging to automatically notify account managers when users are terminated or transferred; using the information system to monitor account usage; and using automated telephonic notification to report atypical system account usage.
Checks: C-24077r493129_chk

Review the application documentation and interview the application administrator. Identify the account management methods, processes and procedures that are used. If the application is utilizing a centralized authentication mechanism such as Active Directory or LDAP, verify all user account activity is conducted via that solution and no local user accounts that circumvent the automated solution are used. Determine if automated mechanisms are used when managing application user accounts and taking management action on application user accounts. Automated methods include but are not limited to: Taking action on accounts that have been determined to be inactive, suspended, terminated, or disabled. Automated action examples include: deleting such accounts, reactivating accounts in conjunction with a validation or verification process, or sending notifications or reminders to the account holders that their account is about to be disabled or deleted. Verify the action that is taken is automated and repeatable. If the account management process is manual in nature, this is a finding.

Fix: F-24066r493130_fix

Use automated processes and mechanisms for account management functions.

b
Shared/group account credentials must be terminated when members leave the group.
AC-2 - Medium - CCI-002142 - V-222408 - SV-222408r879694_rule
RMF Control
AC-2
Severity
Medium
CCI
CCI-002142
Version
APSC-DV-000290
Vuln IDs
  • V-222408
  • V-69297
Rule IDs
  • SV-222408r879694_rule
  • SV-83919
If shared/group account credentials are not terminated when individuals leave the group, the user that left the group can still gain access even though they are no longer authorized. A shared/group account credential is a shared form of authentication that allows multiple individuals to access the application using a single account. There may also be instances when specific user actions need to be performed on the information system without unique user identification or authentication. Examples of credentials include passwords and group membership certificates.
Checks: C-24078r493132_chk

Review the application documentation and determine if there is a requirement for shared or group accounts. If there is no official requirement for shared or group application accounts, this requirement is not applicable. Interview the application representative and identify shared/group accounts. Have the application representative provide their procedures for account management as it pertains to group users. Validate there is a procedure for deleting either member accounts or the entire group account when member leave the group. If there is no process for handling group account credentials, this is a finding.

Fix: F-24067r493133_fix

Create a procedure for deleting either member accounts or the entire group account when members leave the group.

b
The application must automatically remove or disable temporary user accounts 72 hours after account creation.
AC-2 - Medium - CCI-000016 - V-222409 - SV-222409r879523_rule
RMF Control
AC-2
Severity
Medium
CCI
CCI-000016
Version
APSC-DV-000300
Vuln IDs
  • V-222409
  • V-69299
Rule IDs
  • SV-222409r879523_rule
  • SV-83921
If temporary user accounts remain active when no longer needed or for an excessive period, these accounts may be used to gain unauthorized access. To mitigate this risk, automated termination of all temporary accounts must be set upon account creation. Temporary accounts are established as part of normal account activation procedures when there is a need for short-term accounts without the demand for immediacy in account activation. If temporary accounts are used, the application must be configured to automatically terminate these types of accounts after a DoD-defined time period of 72 hours starting from the point of account creation. To address access requirements, many application developers choose to integrate their applications with enterprise-level authentication/access mechanisms meeting or exceeding access control policy requirements. Such integration allows the application developer to off-load those access control functions and focus on core application features and functionality.
Checks: C-24079r493135_chk

If official documentation exist that disallows the use of temporary user accounts within the application, this requirement is not applicable. Examine the application documentation or interview the application representative to identify how the application users are managed. Navigate to the screen where user accounts are configured. Create a test account and determine if there is a setting to specify the user account as being temporary in nature. Determine if there is an available setting to expire the account after a period of time. If the application has no ability to specify a user account as being temporary in nature, or if the account has no ability to automatically disable or remove the account after 72 hours after account creation, this is a finding.

Fix: F-24068r493136_fix

Configure temporary accounts to be automatically removed or disabled after 72 hours after account creation.

a
The application must have a process, feature or function that prevents removal or disabling of emergency accounts.
CM-6 - Low - CCI-000366 - V-222410 - SV-222410r879887_rule
RMF Control
CM-6
Severity
Low
CCI
CCI-000366
Version
APSC-DV-000310
Vuln IDs
  • V-222410
  • V-70173
Rule IDs
  • SV-222410r879887_rule
  • SV-84795
Emergency accounts are administrator accounts which are established in response to crisis situations where the need for rapid account activation is required. Therefore, emergency account activation may bypass normal account authorization processes. If these accounts are automatically disabled, system maintenance during emergencies may not be possible, thus adversely affecting system availability. Emergency accounts are different from infrequently used accounts (i.e., local logon accounts used by system administrators when network or normal logon/access is not available). Infrequently used accounts also remain available and are not subject to automatic termination dates. However, an emergency account is normally a different account which is created for use by vendors or system maintainers. To address access requirements, many application developers choose to integrate their applications with enterprise-level authentication/access mechanisms that meet or exceed access control policy requirements. Such integration allows the application developer to off-load those access control functions and focus on core application features and functionality.
Checks: C-24080r493138_chk

Review the application documentation and interview the application administrator. Identify if emergency accounts are ever used. If emergency accounts are not used, this requirement is not applicable. If emergency accounts are used, validate a procedure, process, feature or function exists that will prevent the emergency account from being deleted or disabled during a crisis situation. Examples include but are not limited to adding a flag to the account to ensure it is not deleted during a specified emergency period or placing the account in a designated group that is monitored and controlled in accordance with the crisis. If a process, procedure, function or feature designed to prevent emergency accounts from being deleted or disabled during a crisis situation is not available, this is a finding.

Fix: F-24069r493139_fix

Identify accounts that are created in an emergency situation and ensure procedures or processes are in place to prevent disabling or deleting the account while the emergency is underway.

a
The application must automatically disable accounts after a 35 day period of account inactivity.
AC-2 - Low - CCI-000017 - V-222411 - SV-222411r879524_rule
RMF Control
AC-2
Severity
Low
CCI
CCI-000017
Version
APSC-DV-000320
Vuln IDs
  • V-222411
  • V-69301
Rule IDs
  • SV-222411r879524_rule
  • SV-83923
Attackers that are able to exploit an inactive account can potentially obtain and maintain undetected access to an application. Owners of inactive accounts will not notice if unauthorized access to their user account has been obtained. Applications need to track periods of user inactivity and disable accounts after 35 days of inactivity. Such a process greatly reduces the risk that accounts will be hijacked, leading to a data compromise. To address access requirements, many application developers choose to integrate their applications with enterprise-level authentication/access mechanisms that meet or exceed access control policy requirements. Such integration allows the application developer to off-load those access control functions and focus on core application features and functionality. This policy does not apply to either emergency accounts or infrequently used accounts. Infrequently used accounts are local logon administrator accounts used by system administrators when network or normal logon/access is not available. Emergency accounts are administrator accounts created in response to crisis situations.
Checks: C-24081r493141_chk

Examine the application documentation or interview the application representative to identify how the application users are managed. Interview the application administrator and determine if the application is configured to utilize a centralized user management system like Active Directory (AD) for user management or if the application manages user accounts within the application. If the application is configured to use an enterprise-based application user management capability that is STIG compliant, the requirement is not applicable. If the application handles the management tasks for user accounts, access the applications user management utility. Navigate to the screen where user accounts are configured to be disabled after 35 days of inactivity. Confirm this setting is active. If the application is not set to expire inactive accounts after 35 days, or if the application has no ability to expire accounts after 35 days of inactivity, this is a finding.

Fix: F-24070r493142_fix

Design and configure the application to expire user accounts after 35 days of inactivity.

b
Unnecessary application accounts must be disabled, or deleted.
AC-2 - Medium - CCI-000017 - V-222412 - SV-222412r879524_rule
RMF Control
AC-2
Severity
Medium
CCI
CCI-000017
Version
APSC-DV-000330
Vuln IDs
  • V-222412
  • V-69303
Rule IDs
  • SV-222412r879524_rule
  • SV-83925
Test or demonstration accounts are sometimes created during the application installation process. This creates a security risk as these accounts often remain after the initial installation process and can be used to gain unauthorized access to the application. Applications must be designed and configured to disable or delete any unnecessary accounts that may be created. Care must be taken to ensure valid accounts used for valid application operations are not disabled or deleted when this requirement is applied.
Checks: C-24082r493144_chk

Review the system documentation and identify any valid application accounts that are required in order for the application to operate. Accounts the application itself uses in order to function are not in scope for this requirement. Have the application administrator generate a list of all application users. This should include relevant user metadata such as phone numbers or department identifiers. Have the application administrator identify and validate all user accounts. If any accounts cannot be validated and are deemed to be unnecessary, this is a finding.

Fix: F-24071r493145_fix

Design the application so unessential user accounts are not created during installation. Disable or delete all unnecessary application user accounts.

b
The application must automatically audit account creation.
AC-2 - Medium - CCI-000018 - V-222413 - SV-222413r879525_rule
RMF Control
AC-2
Severity
Medium
CCI
CCI-000018
Version
APSC-DV-000340
Vuln IDs
  • V-222413
  • V-69305
Rule IDs
  • SV-222413r879525_rule
  • SV-83927
Once an attacker establishes initial access to a system, the attacker often attempts to create a persistent method of re-establishing access. One way to accomplish this is for the attacker to simply create a new account. Auditing of account creation is one method for mitigating this risk. A comprehensive account management process will ensure an audit trail documents the creation of application user accounts and, as required, notifies administrators and/or application owners exists. Such a process greatly reduces the risk that accounts will be surreptitiously created and provides logging that can be used for forensic purposes. To address access requirements, many application developers choose to integrate their applications with enterprise-level authentication/access/auditing mechanisms meeting or exceeding access control policy requirements. Such integration allows the application developer to off-load those access control functions and focus on core application features and functionality.
Checks: C-24083r493147_chk

Examine the application documentation to identify how the application users are managed. Interview the application administrator and determine if the application is configured to utilize a centralized user management system like Active Directory for user management or if the application manages user accounts within the application. If the application is configured to use an enterprise-based application user management capability that is STIG compliant, the requirement is not applicable. Identify the location of the audit logs and review the end of the logs. Access the user account management functionality and create a new user account. Examine the log file again and determine if the account creation event was logged. The information logged should, at a minimum, include enough detail to determine which account was created and when. If the account creation event was not logged, this is a finding.

Fix: F-24072r493148_fix

Configure the application to write a log entry when a new user account is created. At a minimum, ensure account name, date and time of the event are recorded.

b
The application must automatically audit account modification.
AC-2 - Medium - CCI-001403 - V-222414 - SV-222414r879526_rule
RMF Control
AC-2
Severity
Medium
CCI
CCI-001403
Version
APSC-DV-000350
Vuln IDs
  • V-222414
  • V-69307
Rule IDs
  • SV-222414r879526_rule
  • SV-83929
One way for an attacker to establish persistent access is for the attacker to modify or copy an existing account. Auditing of account modification is one method for mitigating this risk. A comprehensive account management process will ensure an audit trail documents the modification of application user accounts. Such a process greatly reduces the risk that accounts will be surreptitiously modified and provides logging that can be used for forensic purposes. To address account requirements and to ensure application accounts follow requirements consistently, application developers are strongly encouraged to integrate their applications with enterprise-level authentication/access/auditing mechanisms that meet or exceed access control policy requirements. Such integration allows the application developer to off-load those access control functions and focus on core application features and functionality.
Checks: C-24084r493150_chk

Examine the application documentation to identify how the application users are managed. Interview the application administrator and determine if the application is configured to utilize a centralized user management system like Active Directory for user management or if the application manages user accounts within the application. If the application is configured to use an enterprise-based application user management capability that is STIG compliant, the requirement is not applicable. Identify the location of the audit logs and review the end of the logs. Access the user account management functionality and modify a test user account. Examine the log file again and determine if the account event was logged. The information logged should, at a minimum, include enough detail to determine which account was modified and when. If the account modification event information was not logged, this is a finding.

Fix: F-24073r493151_fix

Configure the application to write a log entry when a user account is modified. At a minimum, ensure account name, date and time of the event are recorded.

b
The application must automatically audit account disabling actions.
AC-2 - Medium - CCI-001404 - V-222415 - SV-222415r879527_rule
RMF Control
AC-2
Severity
Medium
CCI
CCI-001404
Version
APSC-DV-000360
Vuln IDs
  • V-222415
  • V-69309
Rule IDs
  • SV-222415r879527_rule
  • SV-83931
When application accounts are disabled, user accessibility is affected. Accounts are utilized for identifying individual application users or for identifying the application processes themselves. In order to detect and respond to events affecting user accessibility and application processing, applications must audit account disabling actions and, as required, notify the appropriate individuals, so they can investigate the event. Such a capability greatly reduces the risk that application accessibility will be negatively affected for extended periods of time and provides logging that can be used for forensic purposes. Application developers are encouraged to integrate their applications with enterprise-level authentication/access/audit mechanisms such as Syslog, Active Directory or LDAP.
Checks: C-24085r493153_chk

Examine the application documentation to identify how the application users are managed. Interview the application administrator and determine if the application is configured to utilize a centralized user management system like Active Directory for user management or if the application manages user accounts within the application. If the application is configured to use an enterprise-based application user management capability that is STIG compliant, the requirement is not applicable. Identify the location of the audit logs and review the end of the logs. Access the user account management functionality and disable a test user account. Examine the log file again and determine if the account disable event was logged. The information logged should, at a minimum, include enough detail to determine which account was disabled and when. If the account disabling event information was not logged, this is a finding.

Fix: F-24074r493154_fix

Configure the application to write a log entry when a user account is disabled. At a minimum, ensure account name, date and time of the event are recorded.

b
The application must automatically audit account removal actions.
AC-2 - Medium - CCI-001405 - V-222416 - SV-222416r879528_rule
RMF Control
AC-2
Severity
Medium
CCI
CCI-001405
Version
APSC-DV-000370
Vuln IDs
  • V-222416
  • V-69311
Rule IDs
  • SV-222416r879528_rule
  • SV-83933
When application accounts are removed, user accessibility is affected. Accounts are utilized for identifying individual application users or for identifying the application processes themselves. In order to detect and respond to events affecting user accessibility and application processing, applications must audit account removal actions and, as required, notify the appropriate individuals, so they can investigate the event. Such a capability greatly reduces the risk that application accessibility will be negatively affected for extended periods of time and provides logging that can be used for forensic purposes. Application developers are encouraged to integrate their applications with enterprise-level authentication/access/audit mechanisms such as Syslog, Active Directory or LDAP.
Checks: C-24086r493156_chk

Examine the application documentation to identify how the application users are managed. Interview the application administrator and determine if the application is configured to utilize a centralized user management system like Active Directory for user management or if the application manages user accounts within the application. If the application is configured to use an enterprise-based application user management capability that is STIG compliant, the requirement is not applicable. Identify the location of the audit logs and review the end of the logs. Access the user account management functionality and remove a test user account. Examine the log file again and determine if the account removal event was logged. The information logged should, at a minimum, include enough detail to determine which account was disabled and when. If the account removal event information was not logged, this is a finding.

Fix: F-24075r493157_fix

Configure the application to write a log entry when a user account is removed. At a minimum, ensure account name, date and time of the event are recorded.

a
The application must notify System Administrators and Information System Security Officers when accounts are created.
AC-2 - Low - CCI-001683 - V-222417 - SV-222417r879669_rule
RMF Control
AC-2
Severity
Low
CCI
CCI-001683
Version
APSC-DV-000380
Vuln IDs
  • V-222417
  • V-69313
Rule IDs
  • SV-222417r879669_rule
  • SV-83935
Once an attacker establishes access to a system, the attacker often attempts to create a persistent method of re-establishing access. One way to accomplish this is for the attacker to simply create a new account. Notification of account creation is one method for mitigating this risk. A comprehensive account management process will ensure an audit trail which documents the creation of application user accounts and notifies administrators and Information System Security Officers (ISSO) exists. Such a process greatly reduces the risk that accounts will be surreptitiously created and provides logging that can be used for forensic purposes. To address access requirements, many application developers choose to integrate their applications with enterprise-level authentication/access/auditing mechanisms that meet or exceed access control policy requirements. Such integration allows the application developer to off-load those access control functions and focus on core application features and functionality.
Checks: C-24087r493159_chk

Review the application and system documentation. Interview the application administrator and determine if the application is configured to utilize a centralized user management system like Active Directory for user management or if the application manages user accounts within the application. If the application is configured to use an enterprise-based application user management capability that is STIG compliant, the requirement is not applicable. Ensure the application is configured to notify system administrators when new accounts are created by identifying system administrators who will be notified when new accounts are created, creating a test account and checking with system administrator to verify notification was received. If system administrators and ISSOs are not notified when accounts are created, this is a finding.

Fix: F-24076r493160_fix

Configure the application to notify the system administrator and the ISSO when application accounts are created.

a
The application must notify System Administrators and Information System Security Officers when accounts are modified.
AC-2 - Low - CCI-001684 - V-222418 - SV-222418r879670_rule
RMF Control
AC-2
Severity
Low
CCI
CCI-001684
Version
APSC-DV-000390
Vuln IDs
  • V-222418
  • V-69315
Rule IDs
  • SV-222418r879670_rule
  • SV-83937
Once an attacker establishes access to a system, the attacker often attempts to create a persistent method of re-establishing access. One way to accomplish this is for the attacker to simply create a new account. Notification of account creation is one method for mitigating this risk. A comprehensive account management process will ensure an audit trail which documents the creation of application user accounts and notifies administrators and Information System Security Officers (ISSO) exists. Such a process greatly reduces the risk that accounts will be surreptitiously created and provides logging that can be used for forensic purposes. To address access requirements, many application developers choose to integrate their applications with enterprise-level authentication/access/auditing mechanisms that meet or exceed access control policy requirements. Such integration allows the application developer to off-load those access control functions and focus on core application features and functionality.
Checks: C-24088r493162_chk

Review the application and system documentation. Interview the application administrator and determine if the application is configured to utilize a centralized user management system like Active Directory for user management or if the application manages user accounts within the application. If the application is configured to use an enterprise-based application user management capability that is STIG compliant, the requirement is not applicable. Ensure the application is configured to notify system administrators when accounts are modified by identifying system administrators who will be notified when accounts are modified. Modify a test account and check with a system administrator to verify notification was received. If system administrators and ISSOs are not notified when accounts are modified, this is a finding.

Fix: F-24077r493163_fix

Configure the application to notify the system administrator and the ISSO when application accounts are modified.

a
The application must notify System Administrators and Information System Security Officers of account disabling actions.
AC-2 - Low - CCI-001685 - V-222419 - SV-222419r879671_rule
RMF Control
AC-2
Severity
Low
CCI
CCI-001685
Version
APSC-DV-000400
Vuln IDs
  • V-222419
  • V-69317
Rule IDs
  • SV-222419r879671_rule
  • SV-83939
Once an attacker establishes access to a system, the attacker often attempts to create a persistent method of re-establishing access. One way to accomplish this is for the attacker to simply create a new account. Notification of account creation is one method for mitigating this risk. A comprehensive account management process will ensure an audit trail which documents the creation of application user accounts and notifies administrators and Information System Security Officers (ISSO) exists. Such a process greatly reduces the risk that accounts will be surreptitiously created and provides logging that can be used for forensic purposes. To address access requirements, many application developers choose to integrate their applications with enterprise-level authentication/access/auditing mechanisms that meet or exceed access control policy requirements. Such integration allows the application developer to off-load those access control functions and focus on core application features and functionality.
Checks: C-24089r493165_chk

Review the application and system documentation. Interview the application administrator and determine if the application is configured to utilize a centralized user management system like Active Directory for user management or if the application manages user accounts within the application. If the application is configured to use an enterprise-based application user management capability that is STIG compliant, the requirement is not applicable. Ensure application is configured to notify system administrators when accounts are disabled by identifying system administrators who will be notified when accounts are disabled. Disable a test account and check with a system administrator to verify notification was received. If system administrators and ISSOs are not notified when accounts are disabled, this is a finding.

Fix: F-24078r493166_fix

Configure the application to notify the system administrator and the ISSO when application accounts are disabled.

a
The application must notify System Administrators and Information System Security Officers of account removal actions.
AC-2 - Low - CCI-001686 - V-222420 - SV-222420r879672_rule
RMF Control
AC-2
Severity
Low
CCI
CCI-001686
Version
APSC-DV-000410
Vuln IDs
  • V-222420
  • V-69319
Rule IDs
  • SV-222420r879672_rule
  • SV-83941
Once an attacker establishes access to a system, the attacker often attempts to create a persistent method of re-establishing access. One way to accomplish this is for the attacker to simply create a new account. Notification of account creation is one method for mitigating this risk. A comprehensive account management process will ensure an audit trail which documents the creation of application user accounts and notifies administrators and Information System Security Officers (ISSO) exists. Such a process greatly reduces the risk that accounts will be surreptitiously created and provides logging that can be used for forensic purposes. To address access requirements, many application developers choose to integrate their applications with enterprise-level authentication/access/auditing mechanisms that meet or exceed access control policy requirements. Such integration allows the application developer to off-load those access control functions and focus on core application features and functionality.
Checks: C-24090r493168_chk

Review the application and system documentation. Interview the application administrator and determine if the application is configured to utilize a centralized user management system like Active Directory for user management or if the application manages user accounts within the application. If the application is configured to use an enterprise-based application user management capability that is STIG compliant, the requirement is not applicable. Ensure application is configured to notify system administrators when accounts are removed by identifying system administrators who will be notified when accounts are removed. Remove a test account and check with a system administrator to verify notification was received. If system administrators and ISSOs are not notified when accounts are removed, this is a finding.

Fix: F-24079r493169_fix

Configure the application to notify the system administrator and the ISSO when application accounts are removed.

b
The application must automatically audit account enabling actions.
AC-2 - Medium - CCI-002130 - V-222421 - SV-222421r918115_rule
RMF Control
AC-2
Severity
Medium
CCI
CCI-002130
Version
APSC-DV-000420
Vuln IDs
  • V-222421
  • V-69321
Rule IDs
  • SV-222421r918115_rule
  • SV-83943
When application accounts are enabled, user accessibility is affected. Accounts are utilized for identifying individual application users or for identifying the application processes themselves. In order to detect and respond to events affecting user accessibility and application processing, applications must audit account removal actions and, as required, notify the appropriate individuals, so they can investigate the event. Such a capability greatly reduces the risk that application accessibility will be negatively affected for extended periods of time and provides logging that can be used for forensic purposes. Application developers are encouraged to integrate their applications with enterprise-level authentication/access/audit mechanisms such as Syslog, Active Directory or LDAP.
Checks: C-24091r918114_chk

Examine the application documentation or interview the application representative to identify how the application users are managed. Interview the application administrator and determine if the application is configured to utilize a centralized user management system such as Active Directory for user management or if the application manages user accounts within the application. If the application is configured to use an enterprise-based application user management capability that is STIG compliant, the requirement is not applicable. Identify the location of the audit logs and review the end of the logs. Access the user account management functionality and enable a test user account. Examine the log file again and determine if the account enable event was logged. The information logged should, at a minimum, include enough detail to determine which account was enabled and when. If the account enabling event information was not logged, this is a finding.

Fix: F-24080r493172_fix

Configure the application to write a log entry when a user account is enabled. At a minimum, ensure account name, date and time of the event are recorded.

a
The application must notify System Administrators and Information System Security Officers of account enabling actions.
AC-2 - Low - CCI-002132 - V-222422 - SV-222422r879697_rule
RMF Control
AC-2
Severity
Low
CCI
CCI-002132
Version
APSC-DV-000430
Vuln IDs
  • V-222422
  • V-69323
Rule IDs
  • SV-222422r879697_rule
  • SV-83945
Once an attacker establishes access to a system, the attacker often attempts to create a persistent method of re-establishing access. One way to accomplish this is for the attacker to simply enable an existing account that has been previously disabled. Notification when account enabling actions occur is one method for mitigating this risk. A comprehensive account management process will ensure an audit trail which documents the enabling of application user accounts and notifies administrators and Information System Security Officers (ISSO) exists. Such a process greatly reduces the risk that accounts will be surreptitiously created and provides logging that can be used for forensic purposes. To address access requirements, many application developers choose to integrate their applications with enterprise-level authentication/access/auditing mechanisms that meet or exceed access control policy requirements. Such integration allows the application developer to off-load those access control functions and focus on core application features and functionality.
Checks: C-24092r493174_chk

Review the application and system documentation. Interview application administrator and determine if the application is configured to utilize a centralized user management system like Active Directory for user management or if the application manages user accounts within the application. If the application is configured to use an enterprise-based application user management capability that is STIG compliant, the requirement is not applicable. Ensure application is configured to notify system administrators when accounts are enabled by identifying system administrators who will be notified when accounts are enabled. Disable and then enable a test account and check with system administrator to verify notification was received to indicate the account was enabled. If system administrators and ISSOs are not notified when accounts are enabled, this is a finding.

Fix: F-24081r493175_fix

Configure the application to notify the system administrator and the ISSO when application accounts are enabled.

b
Application data protection requirements must be identified and documented.
AC-23 - Medium - CCI-002346 - V-222423 - SV-222423r879700_rule
RMF Control
AC-23
Severity
Medium
CCI
CCI-002346
Version
APSC-DV-000440
Vuln IDs
  • V-222423
  • V-69325
Rule IDs
  • SV-222423r879700_rule
  • SV-83947
Failure to protect organizational information from data mining may result in a compromise of information. In order to assign the appropriate data protections, application data must be identified and then protection requirements assigned. Access to sensitive data and sensitive data objects should be restricted to those authorized to access the data. Examples of sensitive data include but are not limited to; Social Security Numbers, Personally Identifiable Information, or any other data that is has been identified as being sensitive in nature by the data owner. Data storage objects include, for example, databases, database records, and database fields. Data mining prevention and detection techniques include, for example: limiting the types of responses provided to database queries; limiting the number/frequency of database queries to increase the work factor needed to determine the contents of such databases; and notifying organizational personnel when atypical database queries or accesses occur. Protection methods include but are not limited to data encryption, Role-Based Access Controls and access authentication.
Checks: C-24093r493177_chk

Ask the application representative for the documentation that identifies the application data elements, the protection requirements, and any associated steps that are being taken to protect the data. If the application data protection requirements are not documented, this is a finding.

Fix: F-24082r493178_fix

Identify and document the application data elements and the data protection requirements.

b
The application must utilize organization-defined data mining detection techniques for organization-defined data storage objects to adequately detect data mining attempts.
AC-23 - Medium - CCI-002347 - V-222424 - SV-222424r879701_rule
RMF Control
AC-23
Severity
Medium
CCI
CCI-002347
Version
APSC-DV-000450
Vuln IDs
  • V-222424
  • V-69327
Rule IDs
  • SV-222424r879701_rule
  • SV-83949
Failure to protect organizational information from data mining may result in a compromise of information. Data mining occurs when the application is programmatically probed and data is automatically extracted. While there are valid uses for data mining within data sets, the organization should be mindful that adversaries may attempt to use data mining capabilities built into the application in order to completely extract application data so it can be evaluated using methods that are not natively offered by the application. This can provide the adversary with an opportunity to utilize inference attacks or obtain additional insights that might not have been intended when the application was designed. Methods of extraction include database queries or screen scrapes using the application itself. The entity performing the data mining must have access to the application in order to extract the data. Data mining attacks will usually occur with publicly releasable data access but can also occur when access is limited to authorized or authenticated inside users. Data storage objects include, for example, databases, database records, and database fields. Data mining prevention and detection techniques include, for example: limiting the types of responses provided to database queries; limiting the number/frequency of database queries to increase the work factor needed to determine the contents of such databases; and notifying organizational personnel when atypical database queries or accesses occur.
Checks: C-24094r493180_chk

Review the security plan, application and system documentation and interview the application administrator to identify data mining protections that are required of the application. If there are no data mining protections required, this requirement is not applicable. Review the application authentication requirements and permissions. Review documented protections that have been established to protect from data mining. This can include limiting the number of queries allowed. Automated alarming on atypical query events. Limiting the number of records allowed to be returned in a query. Not allowing data dumps. If the application requirements specify protections for data mining and the application administrator is unable to identify or demonstrate that the protections are in place, this is a finding.

Fix: F-24083r493181_fix

Utilize and implement data mining protections when requirements specify it.

c
The application must enforce approved authorizations for logical access to information and system resources in accordance with applicable access control policies.
AC-3 - High - CCI-000213 - V-222425 - SV-222425r879530_rule
RMF Control
AC-3
Severity
High
CCI
CCI-000213
Version
APSC-DV-000460
Vuln IDs
  • V-222425
  • V-69329
Rule IDs
  • SV-222425r879530_rule
  • SV-83951
To mitigate the risk of unauthorized access to sensitive information by entities that have been issued certificates by DoD-approved PKIs, all DoD systems (e.g., networks, web servers, and web portals) must be properly configured to incorporate access control methods that do not rely solely on the possession of a certificate for access. Successful authentication must not automatically give an entity access to a restricted asset or security boundary. Authorization procedures and controls must be implemented to ensure each authenticated entity also has a validated and current authorization. Authorization is the process of determining whether an entity, once authenticated, is permitted to access a specific asset. Information systems use access control policies and enforcement mechanisms to implement this requirement. Access control policies include identity-based policies, role-based policies, and attribute-based policies. Access enforcement mechanisms include access control lists, access control matrices, and cryptography. These policies and mechanisms must be employed by the application to control access between users (or processes acting on behalf of users) and objects (e.g., devices, files, records, processes, programs, and domains) in the information system. This requirement is applicable to access control enforcement applications (e.g., authentication servers) and other applications that perform information and system access control functions.
Checks: C-24095r493183_chk

Review the application documentation and interview the application administrator. Review application data protection requirements. Identify application resources that require protection and authentication over and above the authentication required to access the application itself. This can be access to a URL, a folder, a file, a process or a database record that should only be available to certain individuals. Identify the access control methods utilized by the application in order to control access to the resource. Examples include Role-Based Access Control policies (RBAC). Using RBAC as an example, utilize a test account placed into a test role. Set a protection control on a resource and explicitly deny access to the role assigned to the test user account. Try to access an application resource that is not configured to allow access. Access should be denied. If the enforcement of configured access restrictions is not performed, this is a finding.

Fix: F-24084r493184_fix

Design or configure the application to enforce access to application resources.

b
The application must enforce organization-defined discretionary access control policies over defined subjects and objects.
AC-3 - Medium - CCI-002165 - V-222426 - SV-222426r879705_rule
RMF Control
AC-3
Severity
Medium
CCI
CCI-002165
Version
APSC-DV-000470
Vuln IDs
  • V-222426
  • V-69331
Rule IDs
  • SV-222426r879705_rule
  • SV-83953
Discretionary Access Control allows users to determine who is allowed to access their data. To mitigate the risk of unauthorized access to sensitive information by entities that have been issued certificates by DoD-approved PKIs, all DoD systems (e.g., networks, web servers, and web portals) must be properly configured to incorporate access control methods that do not rely solely on the possession of a certificate for access. Successful authentication must not automatically give an entity access to an asset or security boundary. Authorization procedures and controls must be implemented to ensure each authenticated entity also has a validated and current authorization. Authorization is the process of determining whether an entity, once authenticated, is permitted to access a specific asset. Information systems use access control policies and enforcement mechanisms to implement this requirement. Access control policies include identity-based policies, role-based policies, and attribute-based policies. Access enforcement mechanisms include access control lists, access control matrices, and cryptography. These policies and mechanisms must be employed by the application to control access between users (or processes acting on behalf of users) and objects (e.g., devices, files, records, processes, programs, and domains) in the information system. This requirement is applicable to access control enforcement applications (e.g., authentication servers) and other applications that perform information and system access control functions.
Checks: C-24096r493186_chk

Review the application documentation and interview the application administrator. Review application data protection requirements and application integrated access control methods. Identify if the application implements discretionary access control to application resources. Discretionary Access Controls (DAC) allows application users to determine and set permissions on application data and application objects. The result is the user is given the ability to control who has access to the data they control. If the application does not implement discretionary access controls, this requirement is not applicable. Resources can be a URL, a folder, a file, a process, a database record, or any other application asset that warrants sharing or authorization permission reassignment. Create 3 test accounts. Using test account 1 set protection control on a test user 1 controlled resource. Grant access to test user 2 and only test user 2. Authenticate as test user 3 and attempt to access the application resource where test user 1 and test user 2 are granted access. Access should be denied. If the enforcement of configured access restrictions is not performed, this is a finding.

Fix: F-24085r493187_fix

Design and configure the application to enforce discretionary access control policies.

b
The application must enforce approved authorizations for controlling the flow of information within the system based on organization-defined information flow control policies.
AC-4 - Medium - CCI-001368 - V-222427 - SV-222427r879533_rule
RMF Control
AC-4
Severity
Medium
CCI
CCI-001368
Version
APSC-DV-000480
Vuln IDs
  • V-222427
  • V-69333
Rule IDs
  • SV-222427r879533_rule
  • SV-83955
A mechanism to detect and prevent unauthorized communication flow must be configured or provided as part of the system design. If information flow is not enforced based on approved authorizations, the system may become compromised. Information flow control regulates where information is allowed to travel within a system and between interconnected systems. The flow of all system information must be monitored and controlled so it does not introduce any unacceptable risk to the systems or data. Application specific examples of enforcement occurs in systems that employ rule sets or establish configuration settings that restrict information system services, or message-filtering capability based on message content (e.g., implementing key word searches or using document characteristics). This is usually established by identifying if there are rulesets, policies or other configurations settings provided by the application which serve to control the flow of information within the system. Control of data flow is established by using labels on data and data subsets, evaluating the destination of the data within or without the system (similar security domain) and referencing a corresponding policy that is used to control the flow of data. Applications providing information flow control must be able to enforce approved authorizations for controlling the flow of information within the system in accordance with applicable policy.
Checks: C-24097r493189_chk

Review the application documentation and interview the application and system administrators. Review application features and functions to determine if the application is designed to control the flow of information within the system. Identify: - rulesets, - data labels, and - policies to determine if the application is designed to control the flow of data within the system. If the application does not provide data flow control capabilities, the requirement is not applicable. Access the system as a user with access rights that allow the creation of test data or use of existing test data. Create a test data set and label the data with a data label provided with or by the application, e.g., Personally Identifiable Information (PII) data. Review the policy to determine where in the system the PII labeled data is allowed and is not allowed to go. Using application features and functions, attempt to transmit the labeled data to an area that is prohibited by policy. Verify the flow control policy was enforced and the data was not transmitted. If the application does not enforce the approved authorizations for controlling data flow, this is a finding.

Fix: F-24086r493190_fix

Configure the application to enforce data flow control in accordance with data flow control policies.

b
The application must enforce approved authorizations for controlling the flow of information between interconnected systems based on organization-defined information flow control policies.
AC-4 - Medium - CCI-001414 - V-222428 - SV-222428r879534_rule
RMF Control
AC-4
Severity
Medium
CCI
CCI-001414
Version
APSC-DV-000490
Vuln IDs
  • V-222428
  • V-69335
Rule IDs
  • SV-222428r879534_rule
  • SV-83957
A mechanism to detect and prevent unauthorized communication flow must be configured or provided as part of the system design. If information flow is not enforced based on approved authorizations, the system may become compromised. Information flow control regulates where information is allowed to travel within a system and between interconnected systems. The flow of all system information must be monitored and controlled so it does not introduce any unacceptable risk to the systems or data. Application specific examples of enforcement occurs in systems that employ rule sets or establish configuration settings that restrict information system services, or message-filtering capability based on message content (e.g., implementing key word searches or using document characteristics). This is usually established by identifying if there are rulesets, policies or other configurations settings provided by the application which serve to control the flow of information within the system. Control of data flow is established by using labels on data and data subsets, evaluating the destination of the data within or without the system (similar security domain) and referencing a corresponding policy that is used to control the flow of data. Applications providing information flow control must be able to enforce approved authorizations for controlling the flow of information within the system in accordance with applicable policy.
Checks: C-24098r493192_chk

Review the application documentation and interview the application and system administrators. Identify application features and functions to determine if the application is designed to control the flow of information between interconnected systems. Identify: - rulesets, - data labels - policies - systems to determine if the application is designed to control the flow of data between interconnected systems. If the application does not provide data flow control capabilities, the requirement is not applicable. Access the system as a user with access rights allowing the creation of test data or use of existing test data. Create a test data set and label the data with a data label provided with or by the application (for example, a Personally Identifiable Information (PII) data label). Review the policy settings to determine where the PII labeled data is allowed and is not allowed. Using application features and functions, attempt to transmit the labeled data to an interconnected system that is prohibited by policy. Verify the flow control policy was enforced and the data was not transmitted. If the application does not enforce the approved authorizations for controlling data flow, this is a finding.

Fix: F-24087r493193_fix

Configure the application to enforce data flow control in accordance with data flow control policies.

b
The application must prevent non-privileged users from executing privileged functions to include disabling, circumventing, or altering implemented security safeguards/countermeasures.
AC-6 - Medium - CCI-002235 - V-222429 - SV-222429r879717_rule
RMF Control
AC-6
Severity
Medium
CCI
CCI-002235
Version
APSC-DV-000500
Vuln IDs
  • V-222429
  • V-69337
Rule IDs
  • SV-222429r879717_rule
  • SV-83959
Preventing non-privileged users from executing privileged functions mitigates the risk that unauthorized individuals or processes may gain unnecessary access to information or privileges. Privileged functions include, for example, establishing accounts, performing system integrity checks, or administering cryptographic key management activities. Non-privileged users are individuals that do not possess appropriate authorizations. Circumventing intrusion detection and prevention mechanisms or malicious code protection mechanisms are examples of privileged functions that require protection from non-privileged users.
Checks: C-24099r493195_chk

Identify the application user account(s) that the application uses to run. These accounts include the application processes (defined by Control Panel Services (Windows) or ps –ef (UNIX)) or for an n-tier application, the account that connects from one service (such as a web server) to another (such as a database server). Determine the OS user groups in which each account is a member. List the user rights assigned to these users and groups and evaluate whether any of them are unnecessary. If the OS rights exceed application operational requirements, this is a finding. If the application user account is a member of the Administrators group (Windows) or has a User Identification (UID) of 0 (i.e., is equivalent to root in UNIX), this is a finding. Search the file system to determine if the application user or groups have ownership or permissions to any files or directories. Review the list of files and identify any that are outside the scope of the application. If there are such files outside the scope of the application, this is a finding. Check ownership and permissions; identify permissions beyond the minimum necessary to support the application. If there are instances of unnecessary ownership or permissions, this is a finding. The finding details should note the full path of the file(s) and the associated issue (i.e., outside scope, permissions improperly granted to user X, etc.).

Fix: F-24088r493196_fix

Modify the application to limit access and prevent the disabling or circumvention of security safeguards.

c
The application must execute without excessive account permissions.
AC-6 - High - CCI-002233 - V-222430 - SV-222430r879719_rule
RMF Control
AC-6
Severity
High
CCI
CCI-002233
Version
APSC-DV-000510
Vuln IDs
  • V-222430
  • V-69339
Rule IDs
  • SV-222430r879719_rule
  • SV-83961
Applications are often designed to utilize a user account. The account represents a means to control application permissions and access to OS resources, application resources or both. When the application is designed and installed, care must be taken not to assign excessive permissions to the user account that is used by the application. An application operating with unnecessary privileges can potentially give an attacker access to the underlying operating system or if the privileges required for application execution are at a higher level than the privileges assigned to organizational users invoking such applications/programs, those users are indirectly provided with greater privileges than assigned by organizations. Applications must be designed and configured to operate with only those permissions that are required for proper operation.
Checks: C-24100r493198_chk

Review the system documentation or interview the application representative and identify if the application utilizes an account in order to operate. Determine the OS user groups in which each application account is a member. List the user rights assigned to these users and groups using relevant OS commands and evaluate whether any of them provide admin rights or if they are unnecessary or excessive. If the application connects to a database, open an admin console to the database and view the database users, their roles and group rights. Locate the application user account used to access the database and examine the accounts privileges. This includes group privileges. If the application user account has excessive OS privileges such as being in the admin group, database privileges such as being in the DBA role, has the ability to create, drop, alter the database (not application database tables), or if the application user account has other excessive or undefined system privileges, this is a finding.

Fix: F-24089r493199_fix

Configure the application accounts with minimalist privileges. Do not allow the application to operate with admin credentials.

b
The application must audit the execution of privileged functions.
AC-6 - Medium - CCI-002234 - V-222431 - SV-222431r879720_rule
RMF Control
AC-6
Severity
Medium
CCI
CCI-002234
Version
APSC-DV-000520
Vuln IDs
  • V-222431
  • V-69341
Rule IDs
  • SV-222431r879720_rule
  • SV-83963
Misuse of privileged functions, either intentionally or unintentionally by authorized users, or by unauthorized external entities that have compromised information system accounts, is a serious and ongoing concern and can have significant adverse impacts on organizations. Auditing the use of privileged functions is one way to detect such misuse, and identify the risk from insider threats and the advanced persistent threat.
Checks: C-24101r493201_chk

Log on to the application as an administrative user. Identify functionality within the application that requires utilizing the admin role. Monitor application logs while performing privileged functions within the application. Perform administrative types of tasks such as adding or modifying user accounts, modifying application configuration, or managing encryption keys. Review logs for entries that indicate the administrative actions performed were logged. Ensure the specific action taken, date and time or event is recorded. If the execution of privileged functionality is not logged, this is a finding.

Fix: F-24090r493202_fix

Configure the application to write log entries when privileged functions are executed. At a minimum, ensure the specific action taken, date and time of event are recorded.

c
The application must enforce the limit of three consecutive invalid logon attempts by a user during a 15 minute time period.
AC-7 - High - CCI-000044 - V-222432 - SV-222432r879546_rule
RMF Control
AC-7
Severity
High
CCI
CCI-000044
Version
APSC-DV-000530
Vuln IDs
  • V-222432
  • V-69343
Rule IDs
  • SV-222432r879546_rule
  • SV-83965
By limiting the number of failed logon attempts, the risk of unauthorized system access via user password guessing, otherwise known as brute forcing, is reduced. Limits are imposed by locking the account. User notification when three failed logon attempts are exceeded is an operational consideration determined by the application owner. In some instances the operational situation may dictate that no notice is to be provided to the user when their account is locked. In other situations, the user may be notified their account is now locked. This decision is left to the application owner based upon their operational scenarios.
Checks: C-24102r493204_chk

All testing must be performed within a 15-minute window. Log on to the application with a test user account. Intentionally enter an incorrect user password or pin. Repeat 2 times within 15 minutes for a total of three failed attempts. Notification of a locked account may or may not be provided. Using the correct user password or pin, attempt to logon a 4th time. If the logon is successful upon the 4th attempt the account was not locked after the third failed attempt and this is a finding.

Fix: F-24091r493205_fix

Configure the application to enforce an account lock after 3 failed logon attempts occurring within a 15-minute window.

b
The application administrator must follow an approved process to unlock locked user accounts.
AC-7 - Medium - CCI-002238 - V-222433 - SV-222433r879722_rule
RMF Control
AC-7
Severity
Medium
CCI
CCI-002238
Version
APSC-DV-000540
Vuln IDs
  • V-222433
  • V-69347
Rule IDs
  • SV-222433r879722_rule
  • SV-83969
Once a user account has been locked, it must be unlocked by an administrator. An ISSM and ISSO approved process must be created and followed to ensure the user requesting access is properly authenticated prior to access being re-established. The process must include having the user provide information only the user would know and having the administrator verify the accuracy of the information prior to unlocking the account. This means having the user provide this information when their account is created so the information can be referenced when they are locked out. The process utilized may be manual in nature, however it is recognized that password resets are a time consuming task. To minimize helpdesk resource constraints related to user lockout requests, procedures may be automated by administrators in order to unlock the account or reset the password. Authentication process examples include having the user provide personal information known only by the user and provided when the account was created and/or using Out-of-Band or side channel communication methods such as text messages to the users established cell phone number in order to provide a temporary password or token that can be used to logon once and reset the password. The OWASP site provides an acceptable password reset process that can be used as a reference. https://www.owasp.org/index.php/Forgot_Password_Cheat_Sheet. Automated procedures should follow industry standards and best practice for securely automating password reset/account unlocks and must be reviewed, tested, and then approved by the ISSM and ISSO.
Checks: C-24103r493207_chk

Interview the application administrator and identify the approved process for unlocking user accounts. The process may involve a manual or automated reset after the locked out user has identified themselves using standard user identification processes outlined in the vulnerability discussion. If the admin does not unlock the account following the approved process, and if the process does not have documented ISSO and ISSM approvals, this is a finding.

Fix: F-24092r493208_fix

Create a standard approved process for unlocking locked application accounts which includes validating user identity prior to unlocking the account. Use that process when unlocking application user accounts.

a
The application must display the Standard Mandatory DoD Notice and Consent Banner before granting access to the application.
AC-8 - Low - CCI-000048 - V-222434 - SV-222434r879547_rule
RMF Control
AC-8
Severity
Low
CCI
CCI-000048
Version
APSC-DV-000550
Vuln IDs
  • V-222434
  • V-69349
Rule IDs
  • SV-222434r879547_rule
  • SV-83971
Display of the DoD-approved use notification before granting access to the application ensures privacy and security notification verbiage used is consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance. System use notifications are required only for access via logon interfaces with human users and are not required when such human interfaces do not exist. The banner must be formatted in accordance with DTM-08-060. Use the following verbiage for applications that can accommodate banners of 1300 characters: "You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only. By using this IS (which includes any device attached to this IS), you consent to the following conditions: -The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations. -At any time, the USG may inspect and seize data stored on this IS. -Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose. -This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy. -Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details." Use the following verbiage for operating systems that have severe limitations on the number of characters that can be displayed in the banner: "I've read & consent to terms in IS user agreem't."
Checks: C-24104r493210_chk

If the application has no interactive user interface, this requirement is not applicable. Log on to the application as a user. Observe the screen and ensure the DoD-approved banner is displayed prior to obtaining access to the application. Refer to the vulnerability discussion for the approved text. If the only way to access the application is through the OS console, e.g., a fat client application installed on a GFE desktop or laptop, and that GFE is configured to display the DoD banner, an additional banner is not required at the application level. If the standard DoD-approved banner is not displayed prior to obtaining access, this is a finding.

Fix: F-24093r493211_fix

Configure the application to present the standard DoD-approved banner prior to granting access to the application.

a
The application must retain the Standard Mandatory DoD Notice and Consent Banner on the screen until users acknowledge the usage conditions and take explicit actions to log on for further access.
AC-8 - Low - CCI-000050 - V-222435 - SV-222435r879548_rule
RMF Control
AC-8
Severity
Low
CCI
CCI-000050
Version
APSC-DV-000560
Vuln IDs
  • V-222435
  • V-69351
Rule IDs
  • SV-222435r879548_rule
  • SV-83973
The banner must be acknowledged by the user prior to allowing the user access to the application. This provides assurance that the user has seen the message and accepted the conditions for access. If the consent banner is not acknowledged by the user, DoD will not be in compliance with system use notifications required by law. To establish acceptance of the application usage policy, a click-through banner at application logon is required. The application must prevent further activity until the user executes a positive action to manifest agreement by clicking on a box indicating "OK".
Checks: C-24105r493213_chk

If the application has no interactive user interface, this requirement is not applicable. If the user interface is only available via the OS console, e.g., a fat client application installed on a GFE desktop or laptop, and that GFE is configured to display the DoD banner, this requirement is not applicable. Access the application and authenticate if necessary. Verify the banner is displayed and action must be taken to accept terms of use. If the banner is not displayed or no action must be taken to accept terms of use, this is a finding.

Fix: F-24094r493214_fix

Configure the application to retain the standard DoD-approved banner until the user accepts the usage conditions prior to granting access to the application.

a
The publicly accessible application must display the Standard Mandatory DoD Notice and Consent Banner before granting access to the application.
AC-8 - Low - CCI-001384 - V-222436 - SV-222436r879549_rule
RMF Control
AC-8
Severity
Low
CCI
CCI-001384
Version
APSC-DV-000570
Vuln IDs
  • V-222436
  • V-69353
Rule IDs
  • SV-222436r879549_rule
  • SV-83975
Display of a standardized and approved use notification before granting access to the publicly accessible application ensures privacy and security notification verbiage used is consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance. System use notifications are required only for access via logon interfaces with human users and are not required when such human interfaces do not exist. The banner must be formatted in accordance with DTM-08-060. Use the following verbiage for desktops, laptops, and other devices accommodating banners of 1300 characters: "You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only. By using this IS (which includes any device attached to this IS), you consent to the following conditions: -The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations. -At any time, the USG may inspect and seize data stored on this IS. -Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose. -This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy. -Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details." Use the following verbiage for operating systems that have severe limitations on the number of characters that can be displayed in the banner: "I've read & consent to terms in IS user agreem't."
Checks: C-24106r493216_chk

This requirement only applies to publicly accessible applications. If the application is not publicly accessible, this requirement is not applicable. Access the application and observe the screen to ensure the DoD-approved banner is displayed prior to obtaining full access to the application. Refer to the vulnerability discussion for the approved banner text. If the standard DoD-approved banner is not displayed prior to obtaining access, this is a finding.

Fix: F-24095r493217_fix

Configure the application to present the standard DoD-approved banner prior to granting access to the application.

a
The application must display the time and date of the users last successful logon.
AC-9 - Low - CCI-000052 - V-222437 - SV-222437r879551_rule
RMF Control
AC-9
Severity
Low
CCI
CCI-000052
Version
APSC-DV-000580
Vuln IDs
  • V-222437
  • V-69355
Rule IDs
  • SV-222437r879551_rule
  • SV-83977
Providing a last successful logon date and time stamp notification to the user when they authenticate and access the application allows the user to determine if their application account has been used without their knowledge. Armed with that information, the user can notify the application administrator and initiate a forensics investigation to identify root cause. Without providing this information to the user, a potential compromise of user accounts could go unnoticed.
Checks: C-24107r493219_chk

Review the application documentation and interview the application administrator. If the application does not provide a user interface, this requirement is not applicable. Logon to the application as a test user and verify successful authentication by creating test data, navigating the application functionality or otherwise utilizing the application. Note the date and time access was granted. Log out of the application. Re-authenticate to the application as the same user. Validate the last logon date and time is displayed in the user interface. If the date and time the user account was last granted access to the application is not displayed in the user interface, this is a finding.

Fix: F-24096r493220_fix

Design and configure the application to display the date and time when the user was last successfully granted access to the application.

b
The application must protect against an individual (or process acting on behalf of an individual) falsely denying having performed organization-defined actions to be covered by non-repudiation.
AU-10 - Medium - CCI-000166 - V-222438 - SV-222438r879554_rule
RMF Control
AU-10
Severity
Medium
CCI
CCI-000166
Version
APSC-DV-000590
Vuln IDs
  • V-222438
  • V-69357
Rule IDs
  • SV-222438r879554_rule
  • SV-83979
Without non-repudiation, it is impossible to positively attribute an action to an individual (or process acting on behalf of an individual). Non-repudiation services can be used to determine if information originated from a particular individual, or if an individual took specific actions (e.g., sending an email, signing a contract, approving a procurement request) or received specific information. Non-repudiation protects individuals against later claims by an author of not having authored a particular document, a sender of not having transmitted a message, a receiver of not having received a message, or a signatory of not having signed a document. The application will be configured to provide non-repudiation services for an organization-defined set of commands that are used by the user (or processes action on behalf of the user). DoD PKI provides for non-repudiation through the use of digital signatures. Non-repudiation requirements will vary from one application to another and will be defined based on application functionality, data sensitivity, and mission requirements.
Checks: C-24108r493222_chk

Review the application documentation, the design requirements if available and interview the application administrator. Identify application services or application commands that are formerly required and designed to provide non-repudiation services (e.g., digital signatures). If the application documentation specifically states that non-repudiation services for application users are not defined as part of the application design, this requirement is not applicable. Email is one example of an application specifically required to provide non-repudiation services for application users within the DoD. Interview the application administrators and have them describe which aspect of the application, if any, is required to provide digital signatures. Access the application as a test user or observe the application administrator as they demonstrate the applications signature capabilities. If the application is required to provide non-repudiation services and does not, or if the non-repudiation functionality fails on demonstration, this is a finding.

Fix: F-24097r493223_fix

Configure the application to provide users with a non-repudiation function in the form of digital signatures when it is required by the organization or by the application design and architecture.

b
For applications providing audit record aggregation, the application must compile audit records from organization-defined information system components into a system-wide audit trail that is time-correlated with an organization-defined level of tolerance for the relationship between time stamps of individual records in the audit trail.
AU-12 - Medium - CCI-000174 - V-222439 - SV-222439r879557_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000174
Version
APSC-DV-000600
Vuln IDs
  • V-222439
  • V-69359
Rule IDs
  • SV-222439r879557_rule
  • SV-83981
Without the ability to collate records based on the time when the events occurred, the ability to perform forensic analysis and investigations across multiple components is significantly degraded. Audit trails are time-correlated if the time stamps in the individual audit records can be reliably related to the time stamps in other audit records to achieve a time ordering of the records within organization-defined level of tolerance. This requirement applies to applications which provide the capability to compile system-wide audit records for multiple systems or system components. However, all applications must provide the relevant log details that are used to aggregate the information.
Checks: C-36237r602277_chk

Review the application documentation and interview the application administrator. Determine if the application has the ability to compile audit records from multiple systems or system components. If the application does not provide log aggregation services, this requirement is not applicable. Identify the systems that comprise the application. Access each system comprising the application or a random sample of several application systems. Review the application logs and obtain date and time stamps for several random audit events. Record the information. Access the server providing the log aggregation. Access the application logs that have been written to the server and compare the samples obtained from the application systems to the aggregated logs. Ensure the dates and time stamps correlate with one another. If the log dates and times do not correlate when the logs are aggregated, this is a finding.

Fix: F-36204r602278_fix

Configure the application to correlate time stamps when aggregating audit records.

b
The application must provide audit record generation capability for the creation of session IDs.
AU-12 - Medium - CCI-000169 - V-222441 - SV-222441r879559_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000169
Version
APSC-DV-000620
Vuln IDs
  • V-222441
  • V-69363
Rule IDs
  • SV-222441r879559_rule
  • SV-83985
Applications create session IDs at the onset of a user session in order to manage user access to the application and differentiate between different user sessions. It is important to log the creation of these session ID creation events for forensic purposes. It is equally important to not log the session ID itself. Logging the session ID puts active sessions at risk if log data is compromised. Specific session ID information should be removed, masked, sanitized, or encrypted. A hash value of the session ID that can be mapped to the session ID is an acceptable method for assuring active session protection when logging session ID information. Alternatively, logging protections that protect the logs and defend from unauthorized access are means to assure log confidentiality and protect session integrity. Web based applications will often utilize an application server that creates, manages and logs user session IDs. It is acceptable for the application to delegate this requirement to the application server.
Checks: C-24111r493231_chk

Access the management interface for the application or configuration file and evaluate the log/audit management settings. Determine if the setting that enables session ID creation event auditing is activated. Create a new user session by logging in to the application. Review the logs to ensure the session creation event was recorded. If the application is not configured to log session ID creation events, or if no creation event was recorded, this is a finding. If a web-based application delegates session ID creation to an application server, this is not a finding. If the application generates session ID creation event logs by default, and that behavior cannot be disabled, this is not a finding.

Fix: F-24100r493232_fix

Enable session ID creation event auditing.

b
The application must provide audit record generation capability for the destruction of session IDs.
AU-12 - Medium - CCI-000169 - V-222442 - SV-222442r879559_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000169
Version
APSC-DV-000630
Vuln IDs
  • V-222442
  • V-69365
Rule IDs
  • SV-222442r879559_rule
  • SV-83987
Applications should destroy session IDs at the end of a user session in order to terminate user access to the application session and to reduce the possibility of an unauthorized attacker high jacking the session and impersonating the user. It is important to log when session IDs are destroyed for forensic purposes. Web based applications will often utilize an application server that creates, manages and logs session IDs. It is acceptable for the application to delegate this requirement to the application server.
Checks: C-24112r493234_chk

Access the management interface for the application or configuration file and evaluate the log/audit management settings. Determine if the setting that enables session ID destruction event auditing is activated. Terminate a user session within the application and review the logs to ensure the session destruction event was recorded. If the application is not configured to log session ID destruction events, or if the application has no means to enable auditing of session ID destruction events, this is a finding. If a web-based application delegates session ID destruction to an application server, this is not a finding. If the application generates audit logs by default when session IDs are destroyed, and that behavior cannot be disabled, this is not a finding.

Fix: F-24101r493235_fix

Enable session ID destruction event auditing.

b
The application must provide audit record generation capability for the renewal of session IDs.
AU-12 - Medium - CCI-000169 - V-222443 - SV-222443r879559_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000169
Version
APSC-DV-000640
Vuln IDs
  • V-222443
  • V-69367
Rule IDs
  • SV-222443r879559_rule
  • SV-83989
Application design sometimes requires the renewal of session IDs in order to continue approved user access to the application. Session renewal is done on a case by case basis under circumstances defined by the application architecture. The following are some examples of when session renewal must be done; whenever there is a change in user privilege such as transitioning from a user to an admin role or when a user changes from an anonymous user to an authenticated user or when a user's permissions have changed. For these types of critical application functionalities, the previous session ID needs to be destroyed or otherwise invalidated and a new session ID must be created. It is important to log when session IDs are renewed for forensic purposes. Web based applications will often utilize an application server that creates, manages and logs session IDs. It is acceptable for the application to delegate this requirement to the application server.
Checks: C-24113r493237_chk

Interview the system admin and review the application documentation. Identify any web pages or application functionality where a user's privileges or permissions will change. This is most likely to occur during the authentication stages. Evaluate the log/audit output by opening the log files and observing changes to the logs. Create a new user session by accessing the application. Review the logs and save the relevant session creation event recorded. Utilize the application pages that provide privilege escalation. Escalate privileges by authenticating as a privileged user. Review the logs and determine if new session information is created and being used. If a web-based application delegates session ID renewals to an application server, this is not a finding. If the application is not configured to log session ID renewal events this is a finding.

Fix: F-24102r493238_fix

Design or reconfigure the application to log session renewal events on those application events that provide changes in the users privileges or permissions to the application.

b
The application must not write sensitive data into the application logs.
AU-12 - Medium - CCI-000169 - V-222444 - SV-222444r879559_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000169
Version
APSC-DV-000650
Vuln IDs
  • V-222444
  • V-69369
Rule IDs
  • SV-222444r879559_rule
  • SV-83991
It is important to identify and exclude certain types of data that is written into the logs. If the logs are compromised and sensitive data is included in the logs, this could assist an attacker in furthering their attack or it could completely compromise the system. Examples of such data include but are not limited to; Passwords, Session IDs, Application source code, encryption keys, and sensitive data such as personal health information (PHI), Personally Identifiable Information (PII), or government identifiers (e.g., SSN).
Checks: C-24114r493240_chk

Review the application logs and identify application logging format. Using the format of the log and the requisite search data as a guide to create your search, create search strings that could successfully identify the existence of passwords, session IDs, or other sensitive information such as SSN. Utilizing the UNIX grep-based search utility include the following examples which are meant to illustrate the purpose of the requirement. Password values are usually associated with usernames so searching for "username" in the provided log file will often assist in determining if password values are included. grep -i "username" &lt; logfile.txt Search for social security numbers in the provided log file. grep -i "[0-9]{3}[-]?[0-9]{2}[-]?[0-9]{4}" &lt; logfile.txt Use regular expressions to aid in searching log files. All search syntax cannot be provided within the STIG, the reviewer must utilize their knowledge to create new search criteria based upon the log format used and the potentially sensitive data processed by the application. If the application logs sensitive data such as session IDs, application source code, encryption keys, or passwords, this is a finding.

Fix: F-24103r493241_fix

Design or reconfigure the application to not write sensitive data to the logs.

b
The application must provide audit record generation capability for session timeouts.
AU-12 - Medium - CCI-000169 - V-222445 - SV-222445r879559_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000169
Version
APSC-DV-000660
Vuln IDs
  • V-222445
  • V-69371
Rule IDs
  • SV-222445r879559_rule
  • SV-83993
When a user's session times out, it is important to be able to identify these events in the application logs. Without the capability to generate audit records, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one. Audit records can be generated from various components within the application (e.g., process, module). Certain specific application functionalities may be audited as well. The list of audited events is the set of events for which audits are to be generated. This set of events is typically a subset of the list of all events for which the system is capable of generating audit records. DoD has defined the list of events for which the application will provide an audit record generation capability as the following: (i) Successful and unsuccessful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g., classification levels); (ii) Access actions, such as successful and unsuccessful logon attempts, privileged activities or other system level access, starting and ending time for user access to the system, concurrent logons from different workstations, successful and unsuccessful accesses to objects, all program initiations, and all direct access to the information system; and (iii) All account creation, modification, disabling, and termination actions. Web-based applications will often utilize an application server that creates, manages, and logs session timeout information. It is acceptable for the application to delegate this requirement to the application server.
Checks: C-24115r493243_chk

Review the application documentation and interview the application administrator to identify log locations for application session activity. Open the log file that tracks user session activity. Access the application as a regular user and identify the user session within the log files. Identify the session timeout threshold defined by the application. Perform no action within the application in order to allow the session to timeout. Once the session timeout threshold has been exceeded, verify the session has been terminated due to the timeout event and review the logs again to ensure the session timeout event was recorded in the logs. If a web-based application delegates session timeout auditing to an application server, this is not a finding. If the session timeout event is not recorded in the logs, this is a finding.

Fix: F-24104r493244_fix

Configure the application to record session timeout events in the logs.

b
The application must record a time stamp indicating when the event occurred.
AU-12 - Medium - CCI-000169 - V-222446 - SV-222446r879559_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000169
Version
APSC-DV-000670
Vuln IDs
  • V-222446
  • V-69373
Rule IDs
  • SV-222446r879559_rule
  • SV-83995
It is important to include the time stamps for when an event occurred. Failure to include time stamps in the event logs is detrimental to forensic analysis.
Checks: C-24116r493246_chk

Review the application logs. If the time the event occurred is not included as part of the event, this is a finding.

Fix: F-24105r493247_fix

Configure the application to record the time the event occurred when recording the event.

b
The application must provide audit record generation capability for HTTP headers including User-Agent, Referer, GET, and POST.
AU-12 - Medium - CCI-000169 - V-222447 - SV-222447r879559_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000169
Version
APSC-DV-000680
Vuln IDs
  • V-222447
  • V-69375
Rule IDs
  • SV-222447r879559_rule
  • SV-83997
HTTP header information is a critical component of data that is used when evaluating forensic activity. Without the capability to generate audit records, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one. Audit records can be generated from various components within the application (e.g., process, module). Certain specific application functionalities may be audited as well. The list of audited events is the set of events for which audits are to be generated. This set of events is typically a subset of the list of all events for which the system is capable of generating audit records. DoD has defined the list of events for which the application will provide an audit record generation capability as the following: (i) Successful and unsuccessful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g., classification levels); (ii) Access actions, such as successful and unsuccessful logon attempts, privileged activities or other system level access, starting and ending time for user access to the system, concurrent logons from different workstations, successful and unsuccessful accesses to objects, all program initiations, and all direct access to the information system; and (iii) All account creation, modification, disabling, and termination actions.
Checks: C-24117r493249_chk

Review the application documentation and interview the application administrator to identify log locations for application session activity. Open the log file that tracks user session activity. Access the application as a regular user and identify the user session within the log files. Perform several actions within the application in order to generate HTTP header traffic. Review the logs to ensure the HTTP header information is recorded in the logs. Header information logged will vary based upon the application and environment. Examples of headers include but are not limited to: User-Agent: Referer: X-Forwarded-For: Date: Expires: If HTTP headers are not logged, this is a finding.

Fix: F-24106r493250_fix

Configure the web application and/or the web server to log HTTP headers.

b
The application must provide audit record generation capability for connecting system IP addresses.
AU-12 - Medium - CCI-000169 - V-222448 - SV-222448r879559_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000169
Version
APSC-DV-000690
Vuln IDs
  • V-222448
  • V-69377
Rule IDs
  • SV-222448r879559_rule
  • SV-83999
Without the capability to generate audit records, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one. Audit records can be generated from various components within the application (e.g., process, module). Certain specific application functionalities may be audited as well. The list of audited events is the set of events for which audits are to be generated. This set of events is typically a subset of the list of all events for which the system is capable of generating audit records. The IP addresses of remote systems that connect to the application are an important aspect of identifying the sources of application activity. Recording these IP addresses in the application logs provides forensic evidence and aids in investigating and identifying sources of malicious behavior related to security events.
Checks: C-24118r493252_chk

Review the application documentation and interview the application administrator to identify where audit logs are stored. Review audit logs and determine if the IP address information of systems that connect to the application is kept in the logs. If connecting IP addresses are not seen in the logs, connect to the application remotely and review the logs to determine if the connection was logged. If the IP addresses of the systems that connect to the application are not recorded in the logs, this is a finding.

Fix: F-24107r493253_fix

Configure the application or application server to log all connecting IP address information

b
The application must record the username or user ID of the user associated with the event.
AU-12 - Medium - CCI-000169 - V-222449 - SV-222449r879559_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000169
Version
APSC-DV-000700
Vuln IDs
  • V-222449
  • V-69379
Rule IDs
  • SV-222449r879559_rule
  • SV-84001
When users conduct activity within an application, that user’s identity must be recorded in the audit log. Failing to record the identity of the user responsible for the activity within the application is detrimental to forensic analysis.
Checks: C-24119r493255_chk

Review and monitor the application logs. Connect to the application and perform application activity that is allowed by the user such as accessing data or running reports. Observe if the log includes an entry to indicate the user ID of the user that conducted the activity. If the user ID is not recorded along with the event in the event log, this is a finding.

Fix: F-24108r493256_fix

Configure the application to record the user ID of the user responsible for the log event entry.

b
The application must generate audit records when successful/unsuccessful attempts to grant privileges occur.
AU-12 - Medium - CCI-000172 - V-222450 - SV-222450r879561_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
APSC-DV-000710
Vuln IDs
  • V-222450
  • V-69381
Rule IDs
  • SV-222450r879561_rule
  • SV-84003
Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). When a user is granted access or rights to application features and function not afforded to an ordinary user, they have been granted access to privilege and that action must be logged.
Checks: C-24120r493258_chk

Review the application documentation and interview the application admin to identify application management interfaces and features. Access the application management utility and create a test user account or use the account of a regular unprivileged user who is cooperating with the testing. Access and open the auditing logs. Using an account with the appropriate privileges, grant the user a privilege they previously did not have. Attempt to grant privileges in a manner that will cause a failure event such as granting privileges to a non-existent user or attempting to grant privileges with an account that doesn't have the rights to do so. Review the application logs and ensure both events were captured in the logs. The event data should include the user’s identity and the privilege that was granted and the privilege that failed to be granted. If the application does not log when successful and unsuccessful attempts to grant privilege occur, this is a finding.

Fix: F-24109r493259_fix

Configure the application to audit successful and unsuccessful attempts to grant privileges.

b
The application must generate audit records when successful/unsuccessful attempts to access security objects occur.
AU-12 - Medium - CCI-000172 - V-222451 - SV-222451r879863_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
APSC-DV-000720
Vuln IDs
  • V-222451
  • V-69383
Rule IDs
  • SV-222451r879863_rule
  • SV-84005
Security objects represent application objects that provide or require security protections or have a security role within the application. Examples include but are not limited to, files, application modules, folders, and database records. Essentially, if permissions are assigned to protect it, it can be considered a security object. Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter).
Checks: C-24121r493261_chk

Review the application documentation and interview the application administrator. Identify where the application logs are stored. Identify application functionality that provides privilege or permission settings to security objects within the application. This can be an application function that assigns privileges to an application object or data element. Authenticate to the application as a regular user. Using application functionality, attempt to access the security object within the application. Perform two attempts, one successfully and one unsuccessfully. Review the log data and ensure both the successful and unsuccessful access attempts are logged. If the application does not generate an audit record when successful and unsuccessful attempts to access security objects occur, this is a finding.

Fix: F-24110r493262_fix

Configure the application to create an audit record for both successful and unsuccessful attempts to access security objects.

b
The application must generate audit records when successful/unsuccessful attempts to access security levels occur.
AU-12 - Medium - CCI-000172 - V-222452 - SV-222452r879864_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
APSC-DV-000730
Vuln IDs
  • V-222452
  • V-69385
Rule IDs
  • SV-222452r879864_rule
  • SV-84007
A security level denotes a permissions or authorization capability within the application. This is most often associated with a user role. Attempts to access a security level can occur when a user attempts an action such as escalating their privilege from within the application itself. Attempts to access a security level can be construed as an attempt to change your user role from within the application. Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter).
Checks: C-24122r493264_chk

Review the application documentation and interview the application administrator. Identify where the application logs are stored. Identify application functionality that provides privilege escalation or access to additional security levels within the application. This can be performing a function that escalates the privileges of the user, or accessing a protected area of the application that requires additional authentication in order to access. Authenticate to the application as a regular user. Using application functionality, attempt to access a different security level or domain within the application. Perform two attempts, one successfully and one unsuccessfully. Review the log data and ensure both the successful and unsuccessful access attempts are logged. If the application does not generate an audit record when successful and unsuccessful attempts to access security levels occur, this is a finding.

Fix: F-24111r493265_fix

Configure the application to create an audit record for both successful and unsuccessful attempts to access security levels.

b
The application must generate audit records when successful/unsuccessful attempts to access categories of information (e.g., classification levels) occur.
AU-12 - Medium - CCI-000172 - V-222453 - SV-222453r879865_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
APSC-DV-000740
Vuln IDs
  • V-222453
  • V-69387
Rule IDs
  • SV-222453r879865_rule
  • SV-84009
Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one. Categories of information is information that is identified as being sensitive or requiring additional protection from regular user access. The data is accessed on a need to know basis and has been assigned a category or a classification in order to assign protections and track access. Audit records can be generated from various components within the information system (e.g., module or policy filter).
Checks: C-24123r493267_chk

Review the application documentation and interview the application administrator. Identify where the application logs are stored. Identify any data protections that are required. Identify any categories of data or classification of data. If the application requirements do not call for compartmentalized data and data protection, this requirement is not applicable. Authenticate to the application as a regular user. Using application functionality, attempt to access data that has been assigned to a protected category. Perform two access attempts, one successful and one unsuccessful. Testing this will require obtaining access to test data that has been assigned to a protected category, or having an authorized user access the data for you. Review the log data and ensure both the successful and unsuccessful access attempts are logged. If the application does not generate an audit record when successful and unsuccessful attempts to access categories of information occur, this is a finding.

Fix: F-24112r493268_fix

Configure the application to create an audit record for both successful and unsuccessful attempts to access protected categories of information.

b
The application must generate audit records when successful/unsuccessful attempts to modify privileges occur.
AU-12 - Medium - CCI-000172 - V-222454 - SV-222454r879866_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
APSC-DV-000750
Vuln IDs
  • V-222454
  • V-69389
Rule IDs
  • SV-222454r879866_rule
  • SV-84011
Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter).
Checks: C-24124r493270_chk

Review the application documentation and interview the application admin to identify application management interfaces and features. Access the application management utility and create a test user account or use the account of a regular privileged user who is cooperating with the testing. Access and open the auditing logs. Using an admin account, modify the privileges of a privileged user. Attempt to modify privileges in a manner that will cause a failure event such as attempting to modify a user’s privileges with an account that doesn't have the rights to do so. Review the application logs and ensure both events were captured in the logs. The event data should include the user’s identity and the privilege that was granted and the privilege that failed to be granted. If the application does not log when successful and unsuccessful attempts to modify privileges occur, this is a finding.

Fix: F-24113r493271_fix

Configure the application to audit successful and unsuccessful attempts to modify privileges.

b
The application must generate audit records when successful/unsuccessful attempts to modify security objects occur.
AU-12 - Medium - CCI-000172 - V-222455 - SV-222455r879867_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
APSC-DV-000760
Vuln IDs
  • V-222455
  • V-69391
Rule IDs
  • SV-222455r879867_rule
  • SV-84013
Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter).
Checks: C-24125r493273_chk

Review the application documentation and interview the application administrator. Identify where the application logs are stored. Identify application functionality that provides privilege or permission settings to security objects within the application. This can be an application function that assigns privileges to an application object or data element. Authenticate to the application as a regular user. Using application functionality, attempt to modify the security object within the application. Perform two attempts, one successfully and one unsuccessfully. Review the log data and ensure the modification events both successful and unsuccessful are logged. If the application does not generate an audit record when successful and unsuccessful attempts to modify security objects occur, this is a finding.

Fix: F-24114r493274_fix

Configure the application to create an audit record for both successful and unsuccessful attempts to modify security objects.

b
The application must generate audit records when successful/unsuccessful attempts to modify security levels occur.
AU-12 - Medium - CCI-000172 - V-222456 - SV-222456r879868_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
APSC-DV-000770
Vuln IDs
  • V-222456
  • V-69393
Rule IDs
  • SV-222456r879868_rule
  • SV-84015
A security level denotes a permissions or authorization capability within the application. This is most often associated with a user role. Attempts to modify a security level can be construed as an attempt to change the configuration of the application so as to create a new security role or modify an existing security role. Some applications may or may not provide this capability. Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter).
Checks: C-24126r493276_chk

Review the application documentation and interview the application administrator. Identify where the application logs are stored. Identify application functionality that provides privilege escalation or access to additional security levels within the application. This can be performing a function that escalates the privileges of the user, or accessing a protected area of the application that requires additional authentication in order to access. Authenticate to the application as a regular user. Using application functionality, attempt to modify the permissions of a different security level or domain within the application. Perform two attempts, one successfully and one unsuccessfully. Review the log data and ensure the modify events, both successful and unsuccessful, are logged. If the application does not generate an audit record when successful and unsuccessful attempts to modify the permissions regarding the security levels occur, this is a finding.

Fix: F-24115r493277_fix

Configure the application to create an audit record for both successful and unsuccessful attempts to modify security levels.

b
The application must generate audit records when successful/unsuccessful attempts to modify categories of information (e.g., classification levels) occur.
AU-12 - Medium - CCI-000172 - V-222457 - SV-222457r879869_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
APSC-DV-000780
Vuln IDs
  • V-222457
  • V-69395
Rule IDs
  • SV-222457r879869_rule
  • SV-84017
Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter).
Checks: C-24127r493279_chk

Review the application documentation and interview the application administrator. Identify where the application logs are stored. Identify any data protections that are required. Identify any categories of data or classification of data. If the application requirements do not call for compartmentalized data and data protection, this requirement is not applicable. Authenticate to the application as a regular user. Using application functionality, attempt to modify data that has been assigned to a protected category. Perform two modification attempts, one successful and one unsuccessful. Testing this will require obtaining access to test data that has been assigned to a protected category, or having an authorized user access the data for you. Review the log data and ensure both the successful and unsuccessful modification attempts are logged. If the application does not generate an audit record when successful and unsuccessful attempts to modify categories of information occur, this is a finding.

Fix: F-24116r493280_fix

Configure the application to create an audit record for both successful and unsuccessful attempts to modify protected categories of information.

b
The application must generate audit records when successful/unsuccessful attempts to delete privileges occur.
AU-12 - Medium - CCI-000172 - V-222458 - SV-222458r879870_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
APSC-DV-000790
Vuln IDs
  • V-222458
  • V-69397
Rule IDs
  • SV-222458r879870_rule
  • SV-84019
Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter).
Checks: C-24128r493282_chk

Review the application documentation and interview the application admin to identify application management interfaces and features. Access the application management utility and create a test user account or use the account of a regular privileged user who is cooperating with the testing. Access and open the auditing logs. Using an admin account, delete some or all of the privileges of a privileged user. Attempt to delete privileges in a manner that will cause a failure event such as attempting to delete a user’s privileges with an account that doesn't have the rights to do so. Review the application logs and ensure both events were captured in the logs. The event data should include the user’s identity and the privilege that was granted and the privilege that failed to be granted. If the application does not log when successful and unsuccessful attempts to delete privileges occur, this is a finding.

Fix: F-24117r493283_fix

Configure the application to audit successful and unsuccessful attempts to delete privileges.

b
The application must generate audit records when successful/unsuccessful attempts to delete security levels occur.
AU-12 - Medium - CCI-000172 - V-222459 - SV-222459r879871_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
APSC-DV-000800
Vuln IDs
  • V-222459
  • V-69399
Rule IDs
  • SV-222459r879871_rule
  • SV-84021
A security level denotes a permissions or authorization capability within the application. This is most often associated with a user role. Attempts to delete a security level can be construed as an attempt to change the configuration of the application so as to delete an existing security role. Some applications may or may not provide this capability. Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter).
Checks: C-24129r493285_chk

Review the application documentation and interview the application administrator. Identify where the application logs are stored. Identify application functionality that provides privilege escalation or access to additional security levels within the application. This can be performing a function that escalates the privileges of the user, or accessing a protected area of the application that requires additional authentication in order to access. Authenticate to the application as a regular user. Using application functionality, attempt to delete permissions of a different security level or domain within the application. Perform two attempts, one successfully and one unsuccessfully. Review the log data and ensure the deletion events, both successful and unsuccessful are logged. If the application does not generate an audit record when successful and unsuccessful attempts to delete permissions regarding the security levels occur, this is a finding.

Fix: F-24118r493286_fix

Configure the application to create an audit record for both successful and unsuccessful attempts to delete security levels.

b
The application must generate audit records when successful/unsuccessful attempts to delete application database security objects occur.
AU-12 - Medium - CCI-000172 - V-222460 - SV-222460r879872_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
APSC-DV-000810
Vuln IDs
  • V-222460
  • V-69401
Rule IDs
  • SV-222460r879872_rule
  • SV-84023
Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter).
Checks: C-24130r493288_chk

Review the application documentation and interview the application administrator. Identify where the application logs are stored. Identify application functionality that provides privilege or permission settings to database security objects within the application. This can be an application function that assigns privileges to an application object or data element. Authenticate to the application as a regular user. Using application functionality, attempt to delete the database security object within the application. Perform two attempts, one successfully and one unsuccessfully. Review the log data and ensure the deletion events, both successful and unsuccessful, are logged. If the application does not generate an audit record when successful and unsuccessful attempts to delete database security objects occur, this is a finding.

Fix: F-24119r493289_fix

Configure the application to create an audit record for both successful and unsuccessful attempts to delete database security objects.

b
The application must generate audit records when successful/unsuccessful attempts to delete categories of information (e.g., classification levels) occur.
AU-12 - Medium - CCI-000172 - V-222461 - SV-222461r879873_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
APSC-DV-000820
Vuln IDs
  • V-222461
  • V-69403
Rule IDs
  • SV-222461r879873_rule
  • SV-84025
Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter).
Checks: C-24131r493291_chk

Review the application documentation and interview the application administrator. Identify where the application logs are stored. Identify any data protections that are required. Identify any categories of data or classification of data. If the application requirements do not call for compartmentalized data and data protection, this requirement is not applicable. Authenticate to the application as a regular user. Using application functionality, attempt to delete data that has been assigned to a protected category. Perform two modification attempts, one successful and one unsuccessful. Testing this will require obtaining access to test data that has been assigned to a protected category, or having an authorized user access the data for you. Review the log data and ensure both the successful and unsuccessful deletion attempts are logged. If the application does not generate an audit record when successful and unsuccessful attempts to delete categories of information occur, this is a finding.

Fix: F-24120r493292_fix

Configure the application to create an audit record for both successful and unsuccessful attempts to delete protected categories of information.

b
The application must generate audit records when successful/unsuccessful logon attempts occur.
AU-12 - Medium - CCI-000172 - V-222462 - SV-222462r879874_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
APSC-DV-000830
Vuln IDs
  • V-222462
  • V-69405
Rule IDs
  • SV-222462r879874_rule
  • SV-84027
Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). Knowing when a user successfully or unsuccessfully logged on to the application is critical information that aids in forensic analysis.
Checks: C-24132r493294_chk

Review and monitor the application logs. Authenticate to the application and observe if the log includes an entry to indicate the user’s authentication was successful. Terminate the user session by logging out. Reauthenticate using invalid user credentials and observe if the log includes an entry to indicate the authentication was unsuccessful. If successful and unsuccessful logon events are not recorded in the logs, this is a finding.

Fix: F-24121r493295_fix

Configure the application or application server to write a log entry when successful and unsuccessful logon events occur.

b
The application must generate audit records for privileged activities or other system-level access.
AU-12 - Medium - CCI-000172 - V-222463 - SV-222463r879875_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
APSC-DV-000840
Vuln IDs
  • V-222463
  • V-69407
Rule IDs
  • SV-222463r879875_rule
  • SV-84029
Privileged activities include the tasks or actions taken by users in an administrative role (admin, backup operator, manager, etc.) which are used to manage or reconfigure application function. Examples include but are not limited to: Modifying application logging verbosity, starting or stopping of application services, application user account management, managing application functionality, or otherwise changing the underlying application capabilities such as adding a new application module or plugin. Privileged access does not include an application design which does not modify the application but does provide users with the functionality or the ability to manage their own user specific preferences or otherwise tailor the application to suit individual user needs based upon choices or selections built into the application.
Checks: C-24133r493297_chk

Review and monitor the application logs. Authenticate to the application as a privileged user and observe if the log includes an entry to indicate the user’s authentication was successful. Perform actions as an admin or other privileged user such as modifying the logging verbosity, or starting or stopping an application service, or terminating a test user session. If log events that correspond with the actions performed are not recorded in the logs, this is a finding.

Fix: F-24122r493298_fix

Configure the application to write a log entry when privileged activities or other system-level events occur.

b
The application must generate audit records showing starting and ending time for user access to the system.
AU-12 - Medium - CCI-000172 - V-222464 - SV-222464r879876_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
APSC-DV-000850
Vuln IDs
  • V-222464
  • V-69409
Rule IDs
  • SV-222464r879876_rule
  • SV-84031
Knowing when a user’s application session began and when it ended is critical information that aids in forensic analysis.
Checks: C-24134r493300_chk

Review and monitor the application logs. Initiate a user session and observe if the log includes a time stamp showing the start of the session. Terminate the user session and observe if the log includes a time stamp showing the end of the session. If the start and the end time of the session are not recorded in the logs, this is a finding.

Fix: F-24123r493301_fix

Configure the application or application server to record the start and end time of user session activity.

b
The application must generate audit records when successful/unsuccessful accesses to objects occur.
AU-12 - Medium - CCI-000172 - V-222465 - SV-222465r879878_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
APSC-DV-000860
Vuln IDs
  • V-222465
  • V-69411
Rule IDs
  • SV-222465r879878_rule
  • SV-84033
Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one. Application objects are system or application components that comprise the application. This includes but is not limited to; application files, folders, processes and modules. This requirement is not intended to force the use of debug logging which would be used for troubleshooting or forensic actions; rather it is intended to assure the application strikes a balance when auditing access to application objects and logs normal and potentially abnormal application activity. Audit records can be generated from various components within the information system (e.g., module or policy filter).
Checks: C-24135r493303_chk

Review the application documentation and interview the application administrator to identify log locations. Access the application logs. Review the logs and identify if the application is logging both successful and unsuccessful access to application objects such as files, folders, processes, or application modules and sub components, or systems. If the application does not log application object access, this is a finding.

Fix: F-24124r493304_fix

Configure the application to log successful and unsuccessful access to application objects.

b
The application must generate audit records for all direct access to the information system.
AU-12 - Medium - CCI-000172 - V-222466 - SV-222466r879879_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
APSC-DV-000870
Vuln IDs
  • V-222466
  • V-69413
Rule IDs
  • SV-222466r879879_rule
  • SV-84035
Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one. When an application provides direct access to underlying OS features and functions, that access must be audited. Audit records can be generated from various components within the information system (e.g., module or policy filter).
Checks: C-24136r493306_chk

Review the application documentation and interview the application administrator. Identify if the application implements a direct access feature or function that allows users to directly access the underlying OS. Direct access includes but is not limited to: executing OS commands, navigating the file system, manipulating system resources such as print queues, or reading files hosted on the OS that are not specifically shared or made available on the website. If the application does not provide direct access to the system, this requirement is not applicable. Access the application logs. Access the application as a user or test user with appropriate permissions and attempt to execute application features and functions that provide direct access to the system. Review the logs and ensure the actions executed were logged. Log information must include the user responsible for executing the action, the action executed, and the result of the action. If the application does not log all direct access to the system, this is a finding.

Fix: F-24125r493307_fix

Configure the application to log all direct access to the system.

b
The application must generate audit records for all account creations, modifications, disabling, and termination events.
AU-12 - Medium - CCI-000172 - V-222467 - SV-222467r918117_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
APSC-DV-000880
Vuln IDs
  • V-222467
  • V-69415
Rule IDs
  • SV-222467r918117_rule
  • SV-84037
When application user accounts are created, modified, disabled or terminated the event must be logged. Centralized management of user accounts allows for rapid response to user related security events and also provides ease of management. Allowing the centralized user management solution to log these events is acceptable practice; however, if the application provides a user management interface to manage these tasks, the application must also log these events. Application developers are encouraged to integrate their applications with enterprise-level authentication/access/audit mechanisms such as Syslog, Active Directory or LDAP.
Checks: C-24137r918116_chk

Examine the application documentation or interview the application representative to identify how the application users are managed. Interview the application administrator and determine if the application is configured to utilize a centralized user management system such as Active Directory for user management or if the application manages user accounts within the application. If the application is configured to use an enterprise-based application user management capability that is STIG compliant, the requirement is not applicable. Identify the location of the audit logs and review the end of the logs. Access the user account management functionality. Create an application test account and then review the log to ensure a log record that documents the event is created. Modify the test account and then review the log to ensure a log record that documents the event is created. Disable the test account and then review the log to ensure a log record that documents the event is created. Terminate/remove the test account and then review the log to ensure a log record that documents the event is created. If log events are not created that document all of these events, this is a finding. If some but not all of the aforementioned events are documented in the logs, this is a finding. Findings should document which of the events was not logged.

Fix: F-24126r493310_fix

Configure the application to log user account creation, modification, disabling, and termination events.

b
The application must initiate session auditing upon startup.
AU-14 - Medium - CCI-001464 - V-222468 - SV-222468r879562_rule
RMF Control
AU-14
Severity
Medium
CCI
CCI-001464
Version
APSC-DV-000910
Vuln IDs
  • V-222468
  • V-69419
Rule IDs
  • SV-222468r879562_rule
  • SV-84041
If the application does not begin logging upon startup, important log events could be missed.
Checks: C-24138r493312_chk

Examine the application design documentation and interview the application administrator to identify application logging behavior. If the application is writing to an existing log or log file: Open and monitor the application log. Start the application service and view the log entries. Log entries indicating the application is starting should commence as soon as the application starts. Determine if the log events correlate with the time the application was started and if event log entries include an application start up sequence of events. If the application writes events to a new log on startup: Identify location logs are written to, start the application and then identify and access the new log. Determine if the log events correlate with the time the application was started and if event log entries include an application start up sequence of events. If the application does not begin logging events upon start up, this is a finding.

Fix: F-24127r493313_fix

Configure the application to begin logging application events as soon as the application starts up.

b
The application must log application shutdown events.
AU-3 - Medium - CCI-000130 - V-222469 - SV-222469r879563_rule
RMF Control
AU-3
Severity
Medium
CCI
CCI-000130
Version
APSC-DV-000940
Vuln IDs
  • V-222469
  • V-69421
Rule IDs
  • SV-222469r879563_rule
  • SV-84043
Forensics is a large part of security incident response. Applications must provide a record of their actions so application events can be investigated post-event. Attackers may attempt to shut off the application logging capability to cover their activity while on the system. Recording the shutdown event and the time it occurred in the application or system logs helps to provide forensic evidence that aids in investigating the events.
Checks: C-36238r602280_chk

Review and monitor the application and system logs. If an application shutdown event is not recorded in the logs, either initiate a shutdown event and review the logs after reestablishing access or request backup copies of the application or system logs that indicate shutdown events are being recorded. Alternatively, check for a setting within the application that controls application logging events and determine if application shutdown logging is configured. If the application is not recording application shutdown events in either the application or system log, or if the application is not configured to record shutdown events, this is a finding.

Fix: F-24128r493316_fix

Configure the application or application server to record application shutdown events in the event logs.

b
The application must log destination IP addresses.
AU-3 - Medium - CCI-000130 - V-222470 - SV-222470r879563_rule
RMF Control
AU-3
Severity
Medium
CCI
CCI-000130
Version
APSC-DV-000950
Vuln IDs
  • V-222470
  • V-69423
Rule IDs
  • SV-222470r879563_rule
  • SV-84045
The IP addresses of the systems that the application connects to are an important aspect of identifying application network related activity. Recording the IP addresses of the system the application connects to in the application logs provides forensic evidence and aids in investigating and correlating the sources of malicious behavior related to security events. Logging this information can be particularly useful for Service-Oriented Applications where there is application to application connectivity.
Checks: C-24140r493318_chk

If the application design documentation indicates the application does not initiate connections to remote systems this requirement is not applicable. Network connections to systems used for support services such as DNS, AD, or LDAP may be stored in the system logs. These connections are applicable. Identify log source based upon application architecture, design documents and input from application admin. Review and monitor the application or system logs. Connect to the application and utilize the application functionality that initiates connections to a destination system. If the application routinely connects to remote system on a regular basis you may simply allow the application to operate in the background while the logs are observed. Observe the log activity and determine if the log includes an entry to indicate the IP address of the destination system. If the IP address of the remote system is not recorded along with the event in the event log, this is a finding.

Fix: F-24129r493319_fix

Configure the application to record the destination IP address of the remote system.

b
The application must log user actions involving access to data.
AU-3 - Medium - CCI-000130 - V-222471 - SV-222471r879563_rule
RMF Control
AU-3
Severity
Medium
CCI
CCI-000130
Version
APSC-DV-000960
Vuln IDs
  • V-222471
  • V-69425
Rule IDs
  • SV-222471r879563_rule
  • SV-84047
When users access application data, there is risk of data compromise or seepage if the account used to access is compromised or access is granted improperly. To be able to investigate which account accessed data, the account access must be logged. Without establishing when the access event occurred, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one. Associating event types with detected events in the application and audit logs provides a means of investigating an attack; recognizing resource utilization or capacity thresholds; or identifying an improperly configured application.
Checks: C-24141r493321_chk

Review and monitor the application logs. When accessing data, the logs are most likely database logs. If the application design documents include specific data elements that require protection, ensure user access to those data elements are logged. Utilize the application as a regular user and operate the application so as to access data elements contained within the application. This includes using the application user interface to browse through data elements, query/search data elements and using report generation capability if it exists. Observe and determine if the application log includes an entry to indicate the user’s access to the data was recorded. If successful access to application data elements is not recorded in the logs, this is a finding.

Fix: F-24130r493322_fix

Identify the specific data elements requiring protection and audit access to the data.

b
The application must log user actions involving changes to data.
AU-3 - Medium - CCI-000130 - V-222472 - SV-222472r879563_rule
RMF Control
AU-3
Severity
Medium
CCI
CCI-000130
Version
APSC-DV-000970
Vuln IDs
  • V-222472
  • V-69427
Rule IDs
  • SV-222472r879563_rule
  • SV-84049
When users change/modify application data, there is risk of data compromise if the account used to access is compromised or access is granted improperly. To be able to investigate which account accessed data, the account making the data changes must be logged. Without establishing when the data change event occurred, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one. Associating event types with detected events in the application and audit logs provides a means of investigating an attack; recognizing resource utilization or capacity thresholds; or identifying an improperly configured application.
Checks: C-24142r493324_chk

Review and monitor the application logs. When modifying data, the logs are most likely database logs. If the application design documents include specific data elements that require protection, ensure any changes to those specific data elements are logged. Otherwise, a random check is sufficient. If the application uses a database configured to use Transaction SQL logging this is not a finding if the application admin can demonstrate a process for reviewing the transaction log for data changes. The process must include using the transaction log and some form of query capability to identify users and the data they changed within the application and vice versa. Utilize the application as a regular user and operate the application so as to modify a data element contained within the application. Observe and determine if the application log includes an entry to indicate the users data change event was recorded. If successful changes/modifications to application data elements are not recorded in the logs, this is a finding.

Fix: F-24131r493325_fix

Configure the application to log all changes to application data.

b
The application must produce audit records containing information to establish when (date and time) the events occurred.
AU-3 - Medium - CCI-000131 - V-222473 - SV-222473r879564_rule
RMF Control
AU-3
Severity
Medium
CCI
CCI-000131
Version
APSC-DV-000980
Vuln IDs
  • V-222473
  • V-69429
Rule IDs
  • SV-222473r879564_rule
  • SV-84051
Without establishing when events occurred, it is impossible to establish, correlate, and investigate the events relating to an incident. In order to compile an accurate risk assessment, and provide forensic analysis, it is essential for security personnel to know when events occurred (date and time).
Checks: C-24143r493327_chk

Access the application logs and review the log entries for date and time. Each event written into the log must have a corresponding date and time stamp associated with it. If the audit logs do not have a corresponding date and time associated with each event, this is a finding.

Fix: F-24132r493328_fix

Configure the application or application server to include the date and the time of the event in the audit logs.

b
The application must produce audit records containing enough information to establish which component, feature or function of the application triggered the audit event.
AU-3 - Medium - CCI-000132 - V-222474 - SV-222474r879565_rule
RMF Control
AU-3
Severity
Medium
CCI
CCI-000132
Version
APSC-DV-000990
Vuln IDs
  • V-222474
  • V-69431
Rule IDs
  • SV-222474r879565_rule
  • SV-84053
It is impossible to establish, correlate, and investigate the events relating to an incident if the details regarding the source of the event it not available. In order to compile an accurate risk assessment, and provide forensic analysis, it is essential for security personnel to know where within the application the events occurred, such as which application component, application modules, filenames, and functionality. Associating information about where the event occurred within the application provides a means of quickly investigating an attack; recognizing resource utilization or capacity thresholds; or identifying an improperly configured application.
Checks: C-24144r493330_chk

Review application administration and/or design documents. Identify key aspects of application architecture objects and components, e.g., Web Server, Application server, Database server. Interview the application administrator and identify the log locations. Access the application logs and review the log entries for events that indicate the application is auditing the internal components, objects, or functions of the application. Confirm the event logs provide information as to which component, feature, or functionality of the application triggered the event. Examples of the types of events to look for are as follows: - Application and Protocol events. e.g., Application loads or unloads and Protocol use. - Data Access events. e.g., Database connections. Events could include reference to database library or executable initiating connectivity: - Middleware events. e.g., Source code initiating calls or being invoked. - Name of application modules being loaded or unloaded. - Library loads and unloads. - Application deployment activity. Events written into the log must be able to be traced back to the originating component, feature or function name, service name, application name, library name etcetera in order to establish which aspect of the application triggered the event. If the audit logs do not contain enough data in the logs to establish which component, feature or functionality of the application triggered the event, this is a finding.

Fix: F-24133r493331_fix

Configure the application to log which component, feature or functionality of the application triggered the event.

b
When using centralized logging; the application must include a unique identifier in order to distinguish itself from other application logs.
AU-3 - Medium - CCI-000133 - V-222475 - SV-222475r879566_rule
RMF Control
AU-3
Severity
Medium
CCI
CCI-000133
Version
APSC-DV-001000
Vuln IDs
  • V-222475
  • V-69433
Rule IDs
  • SV-222475r879566_rule
  • SV-84055
Without establishing the source, it is impossible to establish, correlate, and investigate the events leading up to an outage or attack. In the case of centralized logging, or other instances where log files are consolidated, there is risk that the application's log data could be co-mingled with other log data. To address this issue, the application itself must be identified as well as the application host or client name. In order to compile an accurate risk assessment, and provide forensic analysis, it is essential for security personnel to know the source of the event, particularly in the case of centralized logging. Associating information about the source of the event within the application provides a means of investigating an attack; recognizing resource utilization or capacity thresholds; or identifying an improperly configured application.
Checks: C-24145r493333_chk

If the application is logging locally and does not utilize a centralized logging solution, this requirement is not applicable. Review system documentation and identify log location. Access the application logs. Review the application logs. Ensure the application is uniquely identified either within the logs themselves or via log storage mechanisms. Ensure the hosts or client names hosting the application are also identified. Either hostname or IP address is acceptable. If the application name and the hosts or client names are not identified, this is a finding.

Fix: F-24134r493334_fix

Configure the application logs or the centralized log storage facility so the application name and the hosts hosting the application are uniquely identified in the logs.

b
The application must produce audit records that contain information to establish the outcome of the events.
AU-3 - Medium - CCI-000134 - V-222476 - SV-222476r879567_rule
RMF Control
AU-3
Severity
Medium
CCI
CCI-000134
Version
APSC-DV-001010
Vuln IDs
  • V-222476
  • V-69435
Rule IDs
  • SV-222476r879567_rule
  • SV-84057
Without information about the outcome of events, security personnel cannot make an accurate assessment as to whether an attack was successful or if changes were made to the security state of the system. Event outcomes can include indicators of event success or failure and event-specific results (e.g., the security state of the information system after the event occurred). As such, they also provide a means to measure the impact of an event and help authorized personnel to determine the appropriate response. Successful application events are expected to far outnumber errors. Therefore, success events may be implied by default and not specified in the logs if this behavior is documented.
Checks: C-24146r493336_chk

Review system and application documentation to identify application operation and function. Access the application logs and review the logs to determine if the results of application operations are logged. Successful application events are expected to far outnumber errors. Therefore, success events may be implied by default and not specified in the logs if this behavior is documented. The outcome will be a log record that displays the application event/operation that occurred followed by the result of the operation such as "ERROR", "FAILURE", "SUCCESS" or "PASS". Operation outcomes may also be indicated by numeric code where a "1" might indicate success and a "0" may indicate operation failure. If the application does not produce audit records that contain information regarding the results of application operations, this is a finding.

Fix: F-24135r493337_fix

Configure the application to include the outcome of application functions or events.

b
The application must generate audit records containing information that establishes the identity of any individual or process associated with the event.
AU-3 - Medium - CCI-001487 - V-222477 - SV-222477r879568_rule
RMF Control
AU-3
Severity
Medium
CCI
CCI-001487
Version
APSC-DV-001020
Vuln IDs
  • V-222477
  • V-69437
Rule IDs
  • SV-222477r879568_rule
  • SV-84059
Without information that establishes the identity of the subjects (i.e., users or processes acting on behalf of users) associated with the events, security personnel cannot determine responsibility for the potentially harmful event. Event identifiers (if authenticated or otherwise known) include, but are not limited to, user database tables, primary key values, user names, or process identifiers.
Checks: C-24147r493339_chk

Review system documentation and discuss application operation with application administrator. Identify application processes and application users. Identify application components, e.g., application features framework and function. Identify server components, such as web server, database server. Review application logs. Ensure the application event logs include an identifier or identifiers that will allow an investigator to determine the user or the application process responsible for the application event. If the event logs do not include the appropriate identifier or identifiers, this is a finding.

Fix: F-24136r493340_fix

Configure the application to log the identity of the user and/or the process associated with the event.

b
The application must generate audit records containing the full-text recording of privileged commands or the individual identities of group account users.
AU-3 - Medium - CCI-000135 - V-222478 - SV-222478r879569_rule
RMF Control
AU-3
Severity
Medium
CCI
CCI-000135
Version
APSC-DV-001030
Vuln IDs
  • V-222478
  • V-69439
Rule IDs
  • SV-222478r879569_rule
  • SV-84061
Reconstruction of harmful events or forensic analysis is not possible if audit records do not contain enough information. Organizations consider limiting the additional audit information to only that information explicitly needed for specific audit requirements. The additional information required is dependent on the type of information (i.e., sensitivity of the data and the environment within which it resides). At a minimum, the organization must audit either full-text recording of privileged commands or the individual identities of group users, or both. The organization must maintain audit trails in sufficient detail to reconstruct events to determine the cause and impact of compromise. In addition, the application must have the capability to include organization-defined additional, more detailed information in the audit records for audit events.
Checks: C-24148r493342_chk

Review application documentation and interview application administrator. Identify audit log locations and review audit logs. Access the system as a privileged user and execute privileged commands. Review the application logs and ensure that the logs contain all details of the actions performed. If a privileged command was typed within the application that command text must be included in the logs. Authentication information provided as part of the text must NOT be logged, just the commands. If an action was performed, such as activating a check box, that action must be logged. Review group account users, review logs to determine if the individual users of group accounts are identified in the logs. If the application does not log the full text recording of privileged commands or if the application does not identify and log the individuals associated with group accounts, this is a finding.

Fix: F-24137r493343_fix

Configure the application to log the full text recording of privileged commands or the individual identities of group users.

b
The application must implement transaction recovery logs when transaction based.
AU-3 - Medium - CCI-000135 - V-222479 - SV-222479r879569_rule
RMF Control
AU-3
Severity
Medium
CCI
CCI-000135
Version
APSC-DV-001040
Vuln IDs
  • V-222479
  • V-69441
Rule IDs
  • SV-222479r879569_rule
  • SV-84063
Without required logging and access control, security issues related to data changes will not be identified. This could lead to security compromises such as data misuse, unauthorized changes, or unauthorized access. Transaction logs contain a sequential record of all changes to the database. Using a transaction log helps with maintaining application availability and aids in speedy recovery. Transactional logging should be enabled whenever the application database offers the transactional logging capability.
Checks: C-24149r493345_chk

Review the application documentation and interview the application administrator. Have the application administrator provide configuration settings that demonstrate transaction logging is enabled. Review configuration settings for the location of transaction specific logs and verify transaction logs exist and the log records access and changes to the data. If the application is not configured to utilize transaction logging, this is a finding.

Fix: F-24138r493346_fix

Configure the application database to utilize transactional logging.

b
The application must provide centralized management and configuration of the content to be captured in audit records generated by all application components.
AU-3 - Medium - CCI-001844 - V-222480 - SV-222480r879729_rule
RMF Control
AU-3
Severity
Medium
CCI
CCI-001844
Version
APSC-DV-001050
Vuln IDs
  • V-222480
  • V-69443
Rule IDs
  • SV-222480r879729_rule
  • SV-84065
Without the ability to centrally manage the content captured in the audit records, identification, troubleshooting, and correlation of suspicious behavior would be difficult and could lead to a delayed or incomplete analysis of an ongoing attack. This requirement requires that the content captured in audit records be managed from a central location (necessitating automation). Centralized management of audit records and logs provides for efficiency in maintenance and management of records, as well as the backup and archiving of those records. Application components requiring centralized audit log management must have the capability to support centralized management. This requirement applies to centralized management applications or similar types of applications designed to manage and configure audit record capture.
Checks: C-24150r493348_chk

Review the application documentation and interview the application administrator to determine the logging architecture of the application. If the application is configured to log application event entries to a centralized, enterprise based logging solution that meets this requirement, the requirement is not applicable. Review the application components and the log management capabilities of the application. Verify the application log management interface includes the ability to centrally manage the configuration of what is captured in the logs of all application components. If the application does not provide the ability to centrally manage the content captured in the audit logs, this is a finding.

Fix: F-24139r493349_fix

Configure the application to utilize a centralized log management system that provides the capability to configure the content of audit records.

b
The application must off-load audit records onto a different system or media than the system being audited.
AU-4 - Medium - CCI-001851 - V-222481 - SV-222481r879731_rule
RMF Control
AU-4
Severity
Medium
CCI
CCI-001851
Version
APSC-DV-001070
Vuln IDs
  • V-222481
  • V-69445
Rule IDs
  • SV-222481r879731_rule
  • SV-84067
Information stored in one location is vulnerable to accidental or incidental deletion or alteration. In addition, attackers often manipulate logs to hide or obfuscate their activity. The goal is to off-load application logs to a separate server as quickly and efficiently as possible so as to mitigate these risks. A centralized logging solution offering applications an enterprise designed and managed logging capability which is the desired solution. However, when a centralized logging solution is not an option due to the operational environment or other situations where the risk has been officially recognized and accepted, off-loading is a common process utilized to address this type of scenario.
Checks: C-24151r493351_chk

Review application documentation and interview application administrator. Identify log functionality and locations of log files. Obtain risk acceptance documentation and task scheduling information. If the application is configured to utilize a centralized logging solution, this requirement is not applicable. Evaluate log management processes and determine if there are automated tasks that move the logs off of the system hosting the application. Verify automated tasks are performed on an ISSO approved schedule (hourly, daily etc.). Automation can be via scripting, log management oriented tools or other automated means. Review risk acceptance documentation for not utilizing a centralized logging solution. If the logs are not automatically moved off the system as per approved schedule, or if there is no formal risk acceptance documentation, this is a finding.

Fix: F-24140r493352_fix

Configure the application to off-load audit records onto a different system as per approved schedule.

b
The application must be configured to write application logs to a centralized log repository.
AU-4 - Medium - CCI-001851 - V-222482 - SV-222482r879886_rule
RMF Control
AU-4
Severity
Medium
CCI
CCI-001851
Version
APSC-DV-001080
Vuln IDs
  • V-222482
  • V-69447
Rule IDs
  • SV-222482r879886_rule
  • SV-84069
Information stored in one location is vulnerable to accidental or incidental deletion or alteration. In addition, attackers often manipulate logs to hide or obfuscate their activity. Off-loading is a common process in information systems with limited audit storage capacity or when trying to assure log availability and integrity. This requirement is meant to address space limitations and integrity issues that can be encountered when storing logs on the local server. The goal of the requirement being to offload application logs to a separate server as quickly and efficiently as possible so as to mitigate these risks.
Checks: C-24152r493354_chk

Review application documentation and interview application administrator. Evaluate application log management processes and determine if the system is configured to utilize a centralized log management system for the hosting and management of application audit logs. If the system is not configured to write the application logs to the centralized log management repository in an expeditious manner, this is a finding.

Fix: F-24141r493355_fix

Configure the application to utilize a centralized log repository and ensure the logs are off-loaded from the application system as quickly as possible.

b
The application must provide an immediate warning to the SA and ISSO (at a minimum) when allocated audit record storage volume reaches 75% of repository maximum audit record storage capacity.
AU-5 - Medium - CCI-001855 - V-222483 - SV-222483r879732_rule
RMF Control
AU-5
Severity
Medium
CCI
CCI-001855
Version
APSC-DV-001090
Vuln IDs
  • V-222483
  • V-69449
Rule IDs
  • SV-222483r879732_rule
  • SV-84071
If security personnel are not notified immediately upon storage volume utilization reaching 75%, they are unable to plan for storage capacity expansion. Due to variances in application usage and audit records storage usage, the SA and the ISSO may evaluate usage patterns and determine if a higher percentage of usage is warranted before an alarm is sent. The intent of the requirement is to provide a warning that will allow the SA and ISSO ample time to plan and implement an audit storage capacity expansion that will provide for the increased audit log storage requirements without forcing an emergency or otherwise negatively impacting the recording of audit events. The requirement will take into account a reasonable amount of processing time such as 1 or 2 minutes that may be required of the system in order to satisfy the requirement.
Checks: C-36239r602282_chk

Review system documentation and interview application administrator for details regarding logging configuration. If the application utilizes a centralized logging system that provides storage capacity alarming, this requirement is not applicable. Identify application alarming capability relating to storage capacity alarming for the log repository. Coordinate with the appropriate personnel regarding the generation of test alarms. Review log alarm settings and ensure audit log storage capacity alarming is enabled and set to alarm when the storage threshold exceeds 75% of disk storage capacity or the capacity value the SA and ISSO have determined will provide adequate time to plan for capacity expansion. Ensure the alarm will be sent to the ISSO and the application administrator when the utilization threshold is exceeded by changing the threshold settings to below the current disk space utilization. An alarm should be triggered at that point and forwarded to the ISSO and the SA/application admin. If the application is not configured to send an alarm when storage volume exceeds 75% of disc capacity or if the designated alarm recipients did not receive an alarm when the test was conducted, this is a finding.

Fix: F-36205r865216_fix

Configure the application to send an immediate alarm to the application admin/SA and the ISSO when the allocated log storage capacity exceeds 75% of usage or exceeds the capacity value the SA and ISSO have determined will provide adequate time to plan for capacity expansion.

b
Applications categorized as having a moderate or high impact must provide an immediate real-time alert to the SA and ISSO (at a minimum) for all audit failure events.
AU-5 - Medium - CCI-001858 - V-222484 - SV-222484r879733_rule
RMF Control
AU-5
Severity
Medium
CCI
CCI-001858
Version
APSC-DV-001100
Vuln IDs
  • V-222484
  • V-69451
Rule IDs
  • SV-222484r879733_rule
  • SV-84073
Applications that are categorized as having a high or moderate impact on the organization must provide immediate alerts when encountering failures with the application audit system. It is critical for the appropriate personnel to be aware if a system is at risk of failing to process audit logs as required. Without this notification, the security personnel may be unaware of an impending failure of the audit capability and system operation may be adversely affected. Audit processing failures include software/hardware errors, failures in the audit capturing mechanisms, and audit storage capacity being reached or exceeded. While alerts provide organizations with urgent messages containing important information regarding application audit log activity, real-time alerts provide these messages at information technology speed (i.e., the time from event detection to alert occurs in seconds or no more than 1-2 minutes). Without a real-time alert, security personnel may be unaware of an impending failure of the audit capability and system operation may be adversely affected.
Checks: C-24154r493360_chk

Review system documentation and interview application administrator for details regarding application security categorization and logging configuration. If the application utilizes a centralized logging system that provides the real-time alarms, this requirement is not applicable. Review application log alert configuration. Identify audit failure events and associated alarming configuration. If the application is categorized as having a moderate or high impact and is not configured to provide a real-time alert that indicates the audit system has failed or is failing, this is a finding.

Fix: F-24143r493361_fix

Configure the log alerts to send an alarm when the audit system is in danger of failing or has failed. Configure the log alerts to be immediately sent to the application admin/SA and ISSO.

b
The application must alert the ISSO and SA (at a minimum) in the event of an audit processing failure.
AU-5 - Medium - CCI-000139 - V-222485 - SV-222485r879570_rule
RMF Control
AU-5
Severity
Medium
CCI
CCI-000139
Version
APSC-DV-001110
Vuln IDs
  • V-222485
  • V-69453
Rule IDs
  • SV-222485r879570_rule
  • SV-84075
It is critical for the appropriate personnel to be aware if a system is at risk of failing to process audit logs as required. Without this notification, the security personnel may be unaware of an impending failure of the audit capability and system operation may be adversely affected. Audit processing failures include software/hardware errors, failures in the audit capturing mechanisms, and audit storage capacity being reached or exceeded. This requirement applies to each audit data storage repository (i.e., distinct information system component where audit records are stored), the centralized audit storage capacity of organizations (i.e., all audit data storage repositories combined), or both.
Checks: C-24155r493363_chk

Review system documentation and interview application administrator for details regarding logging configuration. If the application utilizes a centralized logging system that provides the audit processing failure alarms, this requirement is not applicable. Identify application alarming capability regarding audit processing failure events. Verify the application is configured to alarm when the auditing system fails. Example alarm events include but are not limited to: hardware failure events failures to capture audit record events audit storage errors If the application is not configured to alarm on alerts that indicate the audit system has failed or is failing, this is a finding.

Fix: F-24144r493364_fix

Configure the application to send an alarm in the event the audit system has failed or is failing.

b
The application must shut down by default upon audit failure (unless availability is an overriding concern).
AU-5 - Medium - CCI-000140 - V-222486 - SV-222486r879571_rule
RMF Control
AU-5
Severity
Medium
CCI
CCI-000140
Version
APSC-DV-001120
Vuln IDs
  • V-222486
  • V-69455
Rule IDs
  • SV-222486r879571_rule
  • SV-84077
It is critical that when the application is at risk of failing to process audit logs as required, it take action to mitigate the failure. Audit processing failures include: software/hardware errors; failures in the audit capturing mechanisms; and audit storage capacity being reached or exceeded. Responses to audit failure depend upon the nature of the failure mode. When availability is an overriding concern, other approved actions in response to an audit failure are as follows: (i) If the failure was caused by the lack of audit record storage capacity, the application must continue generating audit records if possible (automatically restarting the audit service if necessary), overwriting the oldest audit records in a first-in-first-out manner. (ii) If audit records are sent to a centralized collection server and communication with this server is lost or the server fails, the application must queue audit records locally until communication is restored or until the audit records are retrieved manually. Upon restoration of the connection to the centralized collection server, action should be taken to synchronize the local audit data with the collection server.
Checks: C-24156r493366_chk

Review system documentation and interview application administrator for details regarding logging configuration. Identify application shut down capability regarding audit processing failure events. Locate and verify application logging settings that specify the application will halt processing on detected audit failure. If ISSO approval to continue operating and not shut down the application upon an audit failure exists and is documented, validate the application is configured as follows: If logging locally and the failure is attributed to a lack of disk space: Ensure the application is configured to overwrite the oldest logs first so as to maintain the most up to date audit events in the event of an audit failure. When logging centrally: Ensure the application is configured to locally spool/queue audit events in the event an audit failure is detected with the centralized system. If the application does not shut down processing when an audit failure is detected, or if the application does not take steps needed to ensure audit events are not lost due to audit failure, this is a finding.

Fix: F-24145r493367_fix

Configure the application to cease processing if the audit system fails or configure the application to continue logging in a manner that compensates for the audit failure.

b
The application must provide the capability to centrally review and analyze audit records from multiple components within the system.
AU-6 - Medium - CCI-000154 - V-222487 - SV-222487r879572_rule
RMF Control
AU-6
Severity
Medium
CCI
CCI-000154
Version
APSC-DV-001130
Vuln IDs
  • V-222487
  • V-69457
Rule IDs
  • SV-222487r879572_rule
  • SV-84079
Successful incident response and auditing relies on timely, accurate system information and analysis in order to allow the organization to identify and respond to potential incidents in a proficient manner. If the application does not provide the ability to centrally review the application logs, forensic analysis is negatively impacted. Segregation of logging data to multiple disparate computer systems is counterproductive and makes log analysis and log event alarming difficult to implement and manage, particularly when the system or application has multiple logging components written to different locations or systems. Automated mechanisms for centralized reviews and analyses include, for example, Security Information Management products.
Checks: C-24157r493369_chk

Review system documentation and interview application administrator for details regarding application architecture and logging configuration. Identify the application components, the logs that are associated with the components and the locations of the logs. If the application utilizes a centralized logging system that provides the capability to review the log files from one central location, this requirement is not applicable. Access the application's log management utility and review the log files. Ensure all of the applications logs are reviewable from within the centralized log management function and access to other systems in order to review application logs are not required. If all of the application logs are not reviewable from a central location, this is a finding.

Fix: F-24146r493370_fix

Configure the application so all of the applications logs are available for review from one centralized location.

b
The application must provide the capability to filter audit records for events of interest based upon organization-defined criteria.
AU-7 - Medium - CCI-000158 - V-222488 - SV-222488r879574_rule
RMF Control
AU-7
Severity
Medium
CCI
CCI-000158
Version
APSC-DV-001140
Vuln IDs
  • V-222488
  • V-69459
Rule IDs
  • SV-222488r879574_rule
  • SV-84081
The ability to specify the event criteria that are of interest provides the persons reviewing the logs with the ability to quickly isolate and identify these events without having to review entries that are of little or no consequence to the investigation. Without this capability, forensic investigations are impeded. Events of interest can be identified by the content of specific audit record fields including, for example, identities of individuals, event types, event locations, event times, event dates, system resources involved, IP addresses involved, or information objects accessed. Organizations may define audit event criteria to any degree of granularity required, for example, locations selectable by general networking location (e.g., by network or subnetwork) or selectable by specific information system component. This requires applications to provide the capability to customize audit record reports based on organization-defined criteria.
Checks: C-24158r493372_chk

Review the system documentation and interview the application administrator for details regarding application architecture and logging configuration. Identify the application components and the logs associated with the components as well as the locations of the logs. If the application utilizes a centralized logging system that provides the capability to filter log events based upon the following events, this requirement is not applicable. Review the application log management utility. Ensure the application provides the ability to filter on audit events based upon the following minimum criteria: Users: e.g., specific users or groups Event types: Event dates and time: System resources involved: e.g., application components or modules. IP addresses: Information objects accessed: Event level categories: e.g., high, critical, warning, error Key words: e.g., a specific search string Additional details may be logged as needed or prescribed by operational requirements. If the application does not provide the ability to filter audit events, this is a finding.

Fix: F-24147r493373_fix

Configure the application filters to search event logs based on defined criteria.

b
The application must provide an audit reduction capability that supports on-demand reporting requirements.
AU-7 - Medium - CCI-001876 - V-222489 - SV-222489r879618_rule
RMF Control
AU-7
Severity
Medium
CCI
CCI-001876
Version
APSC-DV-001150
Vuln IDs
  • V-222489
  • V-69461
Rule IDs
  • SV-222489r879618_rule
  • SV-84083
The ability to generate on-demand reports, including after the audit data has been subjected to audit reduction, greatly facilitates the organization's ability to generate incident reports as needed to better handle larger-scale or more complex security incidents. Audit reduction is a process that manipulates collected audit information and organizes such information in a summary format that is more meaningful to analysts. The report generation capability provided by the application must support on-demand (i.e., customizable, ad-hoc, and as-needed) reports. This requirement is specific to applications with audit reduction capabilities; however, applications need to support on-demand audit review and analysis.
Checks: C-24159r493375_chk

Review the system documentation and interview the application administrator for details regarding application architecture and logging configuration. Identify the application components and the logs associated with the components. If the application utilizes a centralized logging system that provides the capability to generate reports based on filtered log events, this requirement is not applicable. Using the relevant application features for generating reports and/or searching application data, (this is usually executed directly within a logging utility or within a reports feature or function) configure a filter based on any of the security criteria provided below. Alternatively, you can use security-oriented criteria provided by the application administrator. Once the data filter has been selected, filter the audit event data so only filtered data is displayed and generate the report. The report can be any combination of screen-based, soft copy, or a printed report. Criteria: Users: e.g., specific users or groups Event types: Event dates and time: System resources involved: e.g., application components or modules. IP addresses: Information objects accessed: Event level categories: e.g., high, critical, warning, error If the application does not provide on demand reports based on the filtered audit event data, this is a finding.

Fix: F-24148r493376_fix

Configure the application to generate soft copy, hard copy and/or screen-based reports based on the selected filtered event data.

b
The application must provide an audit reduction capability that supports on-demand audit review and analysis.
AU-7 - Medium - CCI-001875 - V-222490 - SV-222490r879737_rule
RMF Control
AU-7
Severity
Medium
CCI
CCI-001875
Version
APSC-DV-001160
Vuln IDs
  • V-222490
  • V-69463
Rule IDs
  • SV-222490r879737_rule
  • SV-84085
The ability to perform on-demand audit review and analysis, including after the audit data has been subjected to audit reduction, greatly facilitates the organization's ability to generate incident reports as needed to better handle larger-scale or more complex security incidents. Audit reduction is a technique used to reduce the volume of audit records in order to facilitate a manual review. Audit reduction does not alter original audit records. The report generation capability provided by the application must support on-demand (i.e., customizable, ad-hoc, and as-needed) reports. This requirement is specific to applications with audit reduction capabilities; however, applications need to support on-demand audit review and analysis.
Checks: C-24160r493378_chk

Review the system documentation and interview the application administrator for details regarding application architecture and logging configuration. Identify the application components and the logs associated with the components. If the application utilizes a centralized logging system that provides the capability to generate reports based on filtered log events, this requirement is not applicable. Using the relevant application features for generating reports and/or searching application data, (this is usually executed directly within a logging utility or within a reports feature or function) configure a filter based on any of the security criteria provided below. Alternatively, you can use security-oriented criteria provided by the application administrator. Once the data filter has been selected, filter the audit event data so only filtered data is displayed and generate the report. The report can be any combination of screen-based, soft copy, or a printed report. Criteria: Users: e.g., specific users or groups Event types: Event dates and time: System resources involved: e.g., application components or modules. IP addresses: Information objects accessed: Event level categories: e.g., high, critical, warning, error If the application does not provide an audit reduction capability that supports on-demand reports based on the filtered audit event data, this is a finding.

Fix: F-24149r493379_fix

Configure the application to log to a centralized auditing capability that provides on-demand reports based on the filtered audit event data or design or configure the application to meet the requirement.

b
The application must provide an audit reduction capability that supports after-the-fact investigations of security incidents.
AU-7 - Medium - CCI-001877 - V-222491 - SV-222491r879738_rule
RMF Control
AU-7
Severity
Medium
CCI
CCI-001877
Version
APSC-DV-001170
Vuln IDs
  • V-222491
  • V-69465
Rule IDs
  • SV-222491r879738_rule
  • SV-84087
If the audit reduction capability does not support after-the-fact investigations, it is difficult to establish, correlate, and investigate the events leading up to an outage or attack, or identify those responses for one. This capability is also required to comply with applicable Federal laws and DoD policies. Audit reduction capability must support after-the-fact investigations of security incidents either natively or through the use of third-party tools. This requirement is specific to applications with audit reduction capabilities.
Checks: C-24161r493381_chk

Review application documentation and interview application administrator for details regarding audit reduction (log record event filtering). Access the application with user rights sufficient to read and filter audit records. Navigate the application user interface and select the application functionality that provides access and interface to audit records and audit reduction (event filtering). If the application uses a centralized logging solution that performs the audit reduction (event filtering) functions, the requirement is not applicable. Examine the log files; take note of dates and times of events such as logon events. Note: dates and times as well as the original content and any unique record identifiers. Record the identifying information as well as the dates and times and content of the audit records. Apply filters to reduce the amount of audit records displayed to just the logon events for the day. Review the records and ensure the application provides the ability to filter on audit events. If the application does not provide an audit reduction (event filtering) capability, this is a finding.

Fix: F-24150r493382_fix

Configure the application to provide an audit reduction capability that supports forensic investigations.

b
The application must provide a report generation capability that supports on-demand audit review and analysis.
AU-7 - Medium - CCI-001878 - V-222492 - SV-222492r879739_rule
RMF Control
AU-7
Severity
Medium
CCI
CCI-001878
Version
APSC-DV-001180
Vuln IDs
  • V-222492
  • V-69467
Rule IDs
  • SV-222492r879739_rule
  • SV-84089
The report generation capability must support on-demand review and analysis in order to facilitate the organization's ability to generate incident reports as needed to better handle larger-scale or more complex security incidents. Report generation must be capable of generating on-demand (i.e., customizable, ad-hoc, and as-needed) reports. On-demand reporting allows personnel to report issues more rapidly to more effectively meet reporting requirements. Collecting log data and aggregating it to present the data in a single, consolidated report achieves this objective. Audit reduction and report generation capabilities do not always reside on the same information system or within the same organizational entities conducting auditing activities. The audit reduction capability can include, for example, modern data mining techniques with advanced data filters to identify anomalous behavior in audit records. The report generation capability provided by the information system can generate customizable reports. Time ordering of audit records can be a significant issue if the granularity of the time stamp in the record is insufficient. This requirement is specific to applications with report generation capabilities; however, applications need to support on-demand audit review and analysis.
Checks: C-24162r493384_chk

Review the application documentation and interview the application administrator for details regarding audit reduction (log record event filtering). Access the application with user rights sufficient to read and filter audit records. Navigate the application user interface and select the application functionality that provides access and interface to audit records and audit reporting. If the application uses a centralized logging solution that provides immediate, customizable audit review and analysis functions, the requirement is not applicable. Create an event report. Report data can be based on date ranges, times or events, or other criteria that could be used in an investigation. Use of data from previous checks for audit reduction is encouraged. Review the report and ensure the data in the report coincides with event filters used to create the report. If the application does not provide an immediate, ad-hoc audit review and analysis capability, this is a finding.

Fix: F-24151r493385_fix

Design or configure the application to provide an immediate audit review capability or utilize a centralized utility designed for the purpose of on-demand log management and reporting.

b
The application must provide a report generation capability that supports on-demand reporting requirements.
AU-7 - Medium - CCI-001879 - V-222493 - SV-222493r879740_rule
RMF Control
AU-7
Severity
Medium
CCI
CCI-001879
Version
APSC-DV-001190
Vuln IDs
  • V-222493
  • V-69469
Rule IDs
  • SV-222493r879740_rule
  • SV-84091
The report generation capability must support on-demand reporting in order to facilitate the organization's ability to generate incident reports as needed to better handle larger-scale or more complex security incidents. The report generation capability provided by the application must be capable of generating on-demand (i.e., customizable, ad-hoc, and as-needed) reports. On-demand reporting allows personnel to report issues more rapidly to more effectively meet reporting requirements. Collecting log data and aggregating it to present the data in a single, consolidated report achieves this objective. This requirement is specific to applications with report generation capabilities; however, applications need to support on-demand reporting requirements.
Checks: C-24163r493387_chk

Review the application documentation and interview the application administrator for details regarding audit reduction (log record event filtering). Access the application with user rights sufficient to read and filter audit records. Navigate the application user interface and select the application functionality that provides access and interface to audit records and audit reduction (event filtering). If the application uses a centralized logging solution that provides immediate, customizable, ad-hoc report generation functions, the requirement is not applicable. Create an event report. Report data can be based on date ranges, times or events, or other criteria that could be used in an investigation. Use of data from previous checks for audit reduction is encouraged. Review the report and ensure the data in the report coincides with event filters used to create the report. If the application does not provide customizable, immediate, ad-hoc audit log reporting, this is a finding.

Fix: F-24152r493388_fix

Design or configure the application to provide an on-demand report generation capability or utilize a centralized utility designed for the purpose of on-demand log management and reporting.

b
The application must provide a report generation capability that supports after-the-fact investigations of security incidents.
AU-7 - Medium - CCI-001880 - V-222494 - SV-222494r879741_rule
RMF Control
AU-7
Severity
Medium
CCI
CCI-001880
Version
APSC-DV-001200
Vuln IDs
  • V-222494
  • V-69471
Rule IDs
  • SV-222494r879741_rule
  • SV-84093
If the report generation capability does not support after-the-fact investigations, it is difficult to establish, correlate, and investigate the events leading up to an outage or attack, or identify those responses for one. This capability is also required to comply with applicable Federal laws and DoD policies. The report generation capability must support after-the-fact investigations of security incidents either natively or through the use of third-party tools. This requirement is specific to applications with report generation capabilities; however, applications need to support on-demand reporting requirements.
Checks: C-24164r493390_chk

Review the application documentation and interview the application administrator for details regarding audit reduction (log record event filtering). Access the application with user rights sufficient to read and filter audit records. Navigate the application user interface and select the application functionality that provides access and interface to audit records and audit reduction (event filtering). If the application uses a centralized logging solution that performs the report generation functions, the requirement is not applicable. Create an event report. Report data can be based on date ranges, times or events, or other criteria that could be used in an investigation. Use of data from previous checks for audit reduction is encouraged. Review the report and ensure the data in the report coincides with event filters used to create the report. If the application does not have a report generation capability that supports after the fact security investigations, this is a finding.

Fix: F-24153r493391_fix

Design or configure the application to provide after-the-fact report generation capability or utilize a centralized utility designed for the purpose of log management and reporting.

b
The application must provide an audit reduction capability that does not alter original content or time ordering of audit records.
AU-7 - Medium - CCI-001881 - V-222495 - SV-222495r879742_rule
RMF Control
AU-7
Severity
Medium
CCI
CCI-001881
Version
APSC-DV-001210
Vuln IDs
  • V-222495
  • V-69473
Rule IDs
  • SV-222495r879742_rule
  • SV-84095
If the audit reduction capability alters the content or time ordering of audit records, the integrity of the audit records is compromised, and the records are no longer usable for forensic analysis. Time ordering refers to the chronological organization of records based on time stamps. The degree of time stamp precision can affect this. Audit reduction is a process that manipulates collected audit information and organizes such information in a summary format that is more meaningful to analysts. This requirement is specific to applications with audit reduction capabilities; however, applications need to support on-demand audit review and analysis.
Checks: C-24165r493393_chk

Review the application documentation and interview the application administrator for details regarding audit reduction (log record event filtering). Access the application with user rights sufficient to read and filter audit records. Navigate the application user interface and select the application functionality that provides access and interface to audit records and audit reduction (event filtering). If the application uses a centralized logging solution that performs the audit reduction (event filtering) functions, the requirement is not applicable. Examine the log files; take note of dates and times of events such as logon events. Note: dates and times as well as the original content and any unique record identifiers. Record the identifying information as well as the dates and times and content of the audit records. Apply filters to reduce the amount of audit records displayed to just the logon events for the day. Review the records and ensure nothing in the records has changed. Once validated, clear the filter and review the records again to validate nothing changed within the audit record itself. If the application of event filters modifies the original log records, this is a finding.

Fix: F-24154r493394_fix

Configure the application to not alter original log content or time ordering of audit records.

b
The application must provide a report generation capability that does not alter original content or time ordering of audit records.
AU-7 - Medium - CCI-001882 - V-222496 - SV-222496r879743_rule
RMF Control
AU-7
Severity
Medium
CCI
CCI-001882
Version
APSC-DV-001220
Vuln IDs
  • V-222496
  • V-69475
Rule IDs
  • SV-222496r879743_rule
  • SV-84097
If the audit report generation capability alters the original content or time ordering of audit records, the integrity of the audit records is compromised, and the records are no longer usable for forensic analysis. Time ordering refers to the chronological organization of records based on time stamps. The degree of time stamp precision can affect this. The report generation capability provided by the application can generate customizable reports. This requirement is specific to applications with audit reduction capabilities; however, applications need to support on-demand audit review and analysis.
Checks: C-24166r493396_chk

Review the application documentation and interview the application administrator for details regarding audit reduction (log record event filtering). Access the application with user rights sufficient to read and filter audit records. Navigate the application user interface and select the application functionality that provides access and interface to audit records and audit reduction (event filtering). If the application does not provide a report generation capability, the requirement is not applicable. Examine the log files; take note of dates and times of events such as logon events. Note: dates and times as well as the original content and any unique record identifiers. Record the identifying information as well as the dates and times and content of the audit records. Apply filters to reduce the amount of audit records displayed to just the logon events for the day. Review the records and ensure nothing in the records has changed. Once validated, clear the filter and review the records again to validate nothing changed within the audit record itself. If the application of event filters modifies the original log records, this is a finding.

Fix: F-24155r493397_fix

Configure and design the application to not modify source logs when filtering events.

b
The applications must use internal system clocks to generate time stamps for audit records.
AU-8 - Medium - CCI-000159 - V-222497 - SV-222497r879575_rule
RMF Control
AU-8
Severity
Medium
CCI
CCI-000159
Version
APSC-DV-001250
Vuln IDs
  • V-222497
  • V-69477
Rule IDs
  • SV-222497r879575_rule
  • SV-84099
Without an internal clock used as the reference for the time stored on each event to provide a trusted common reference for the time, forensic analysis would be impeded. Determining the correct time a particular event occurred on a system is critical when conducting forensic analysis and investigating system events. If the internal clock is not used, the system may not be able to provide time stamps for log messages. Additionally, externally generated time stamps may not be accurate. Applications can use the capability of an operating system or purpose-built module for this purpose.
Checks: C-24167r493399_chk

Review the system documentation and interview the application administrator for details regarding application architecture and logging configuration. Identify the application components and the logs associated with the components. Ensure the time written into the logs coincides with the OS timeclock. Access random audit records and review the most recent logs. Access the system OS hosting the application and use the related OS commands to determine the time of the system. Perform an action in the application that causes a log event to be written and review the log to ensure the system times and the application log times correlate; compensating for any time delays that may have occurred between running the OS time command and running the application action. If the application doesn't use the internal system clocks to generate time stamps for the audit event logs, this is a finding.

Fix: F-24156r493400_fix

Configure the application to use the hosting systems internal clock for audit record generation.

b
The application must record time stamps for audit records that can be mapped to Coordinated Universal Time (UTC) or Greenwich Mean Time (GMT).
AU-8 - Medium - CCI-001890 - V-222498 - SV-222498r879747_rule
RMF Control
AU-8
Severity
Medium
CCI
CCI-001890
Version
APSC-DV-001260
Vuln IDs
  • V-222498
  • V-69479
Rule IDs
  • SV-222498r879747_rule
  • SV-84101
If time stamps are not consistently applied and there is no common time reference, it is difficult to perform forensic analysis. Time stamps generated by the application include date and time. Time is commonly expressed in Coordinated Universal Time (UTC), a modern continuation of Greenwich Mean Time (GMT), or local time with an offset from UTC.
Checks: C-24168r493402_chk

Review the system documentation and interview the application administrator for details regarding application architecture and logging configuration. Identify the application components and the logs associated with the components. If the application utilizes the underlying OS system clock, and the system clock is mapped to UTC or GMT, this is not a finding. Identify where clock settings are configured within the application. Access the configuration settings and determine if the application is configured to set the time stamps for audit records according to UTC or GMT (e.g., East coast standard time is represented as GMT -5, east coast daylight savings time is represented as GMT-4). If the application is not configured to map to UTC or GMT, this is a finding.

Fix: F-24157r493403_fix

Configure the application to use the underlying system clock that maps to relevant UTC or GMT timezone.

b
The application must record time stamps for audit records that meet a granularity of one second for a minimum degree of precision.
AU-8 - Medium - CCI-001889 - V-222499 - SV-222499r879748_rule
RMF Control
AU-8
Severity
Medium
CCI
CCI-001889
Version
APSC-DV-001270
Vuln IDs
  • V-222499
  • V-69481
Rule IDs
  • SV-222499r879748_rule
  • SV-84103
Without sufficient granularity of time stamps, it is not possible to adequately determine the chronological order of records. Time stamps generated by the application include date and time. Granularity of time measurements refers to the degree of synchronization between information system clocks and reference clocks.
Checks: C-24169r493405_chk

Review the system documentation and interview the application administrator to determine where application audit logs are written and how time stamps are recorded. If the application utilizes the underlying OS for time stamping and time synchronization when writing the audit logs, this requirement is not applicable. Access and review log files over a period of at least 10 minutes; compare time stamps written in the application log to the system clock to ensure time is synchronized to within 1 second of precision. If the application audit log time stamps differ from the OS time source by more than one second, this is a finding.

Fix: F-24158r493406_fix

Configure the application to leverage the underlying operating system as the time source when recording time stamps or design the application to ensure granularity of 1 second as the minimum degree of precision.

b
The application must protect audit information from any type of unauthorized read access.
AU-9 - Medium - CCI-000162 - V-222500 - SV-222500r879576_rule
RMF Control
AU-9
Severity
Medium
CCI
CCI-000162
Version
APSC-DV-001280
Vuln IDs
  • V-222500
  • V-69483
Rule IDs
  • SV-222500r879576_rule
  • SV-84105
If audit data were to become compromised, then competent forensic analysis and discovery of the true source of potentially malicious system activity is difficult if not impossible to achieve. In addition, access to audit records provides information an attacker could potentially use to his or her advantage. To ensure the veracity of audit data, the information system and/or the application must protect audit information from any and all unauthorized access. This includes read, write, and copy access. This requirement can be achieved through multiple methods which will depend upon system architecture and design. Commonly employed methods for protecting audit information include least privilege permissions as well as restricting the location and number of log file repositories. Additionally, applications with user interfaces to audit records should not allow for the unfettered manipulation of or access to those records via the application. If the application provides access to the audit data, the application becomes accountable for ensuring audit information is protected from unauthorized access. Audit information includes all information (e.g., audit records, audit settings, and audit reports) needed to successfully audit information system activity.
Checks: C-24170r493408_chk

Review the system documentation and interview the application administrator for details regarding application architecture and logging configuration. Identify the application components and the logs associated with the components. Identify the roles and users allowed to access audit information and the circumstances in which they are allowed to read or otherwise access the data. Identify the methods used to manage audit records and audit components. Typical methods are file system-based, via an application user interface via database access or a combination thereof. For file system access: Review file system permissions to ensure the audit logs and the application audit components such as executable files and libraries are protected by adequate file permission restrictions. Permissions must be configured to limit access to only those who have been identified and whose access has been approved. If file permissions are configured to allow unapproved access, this is a finding. For application-oriented and database access: Identify the application module that provides access to audit settings and audit data. Attempt to access audit configuration features and logs by using a regular non-privileged application or database user account. If a non-privileged user account is allowed to access the audit data or the audit configuration settings, this is a finding.

Fix: F-24159r493409_fix

Configure the application to protect audit data from unauthorized access. Limit users to roles that are assigned the rights to view, edit or copy audit data, and establish permissions that control access to the audit logs and audit configuration settings.

b
The application must protect audit information from unauthorized modification.
AU-9 - Medium - CCI-000163 - V-222501 - SV-222501r879577_rule
RMF Control
AU-9
Severity
Medium
CCI
CCI-000163
Version
APSC-DV-001290
Vuln IDs
  • V-222501
  • V-69485
Rule IDs
  • SV-222501r879577_rule
  • SV-84107
If audit data were to become compromised, then forensic analysis and discovery of the true source of potentially malicious system activity is impossible to achieve. To ensure the veracity of audit data, the information system and/or the application must protect audit information from unauthorized modification. This requirement can be achieved through multiple methods, which will depend upon system architecture and design. Some commonly employed methods include ensuring log files receive the proper file system permissions, and limiting log data locations. Applications providing a user interface to audit data will leverage user permissions and roles identifying the user accessing the data and the corresponding rights that the user enjoys in order to make access decisions regarding the modification of audit data. Audit information includes all information (e.g., audit records, audit settings, and audit reports) needed to successfully audit information system activity.
Checks: C-36240r602285_chk

Review the system documentation and interview the application administrator for details regarding application architecture and logging configuration. Identify the application components and the logs associated with the components. Identify the roles and users allowed to modify audit information and the circumstances in which they are allowed to modify the data. Identify the methods used to manage audit records and audit components. Typical methods are file system-based, via an application user interface via database access or a combination thereof. For file system access: Review file system permissions to ensure the audit logs and the application audit components such as executable files and libraries are protected by adequate file permission restrictions. Permissions must be configured to limit write/modify access to only those who have been identified and whose access has been approved. If file permissions are configured to allow unapproved write/modify access, this is a finding. For application oriented and database access: Identify the application module that provides access to audit settings and audit data. Attempt to access audit configuration features and logs by using a regular non-privileged application or database user account. Once access has been established, attempt to modify an audit record and attempt to modify the audit settings. If a non-privileged user account is allowed to modify the audit data or the audit configuration settings, this is a finding.

Fix: F-36206r602286_fix

Configure the application to protect audit data from unauthorized modification and changes. Limit users to roles that are assigned the rights to edit audit data and establish permissions that control access to the audit logs and audit configuration settings.

b
The application must protect audit information from unauthorized deletion.
AU-9 - Medium - CCI-000164 - V-222502 - SV-222502r879578_rule
RMF Control
AU-9
Severity
Medium
CCI
CCI-000164
Version
APSC-DV-001300
Vuln IDs
  • V-222502
  • V-69487
Rule IDs
  • SV-222502r879578_rule
  • SV-84109
If audit data were to become compromised, then forensic analysis and discovery of the true source of potentially malicious system activity is impossible to achieve. To ensure the veracity of audit data, the information system and/or the application must protect audit information from unauthorized deletion. This requirement can be achieved through multiple methods, which will depend upon system architecture and design. Some commonly employed methods include: ensuring log files receive the proper file system permissions utilizing file system protections, restricting access, and backing up log data to ensure log data is retained. Applications providing a user interface to audit data will leverage user permissions and roles identifying the user accessing the data and the corresponding rights the user enjoys in order make access decisions regarding the deletion of audit data. Audit information includes all information (e.g., audit records, audit settings, and audit reports) needed to successfully audit information system activity. Audit information may include data from other applications or be included with the audit application itself.
Checks: C-24172r493414_chk

Review the system documentation and interview the application administrator for details regarding application architecture and logging configuration. Identify the application components and the logs associated with the components. Identify the roles and users allowed to delete audit information and the circumstances in which they are allowed to delete the data. Identify the methods used to manage audit records and audit components. Typical methods are file system-based, via an application user interface via database access or a combination thereof. For file system access: Review file system permissions to ensure the audit logs and the application audit components such as executable files and libraries are protected by adequate file permission restrictions. Permissions must be configured to limit deletions to only those who have been identified and whose rights to delete audit data and audit configurations has been approved. If file permissions are configured to allow unapproved deletions of audit settings and data, this is a finding. For application oriented and database access: Identify the application module that provides access to audit settings and audit data. Attempt to access audit configuration features and logs by using a regular non-privileged application or database user account. Once access has been established, attempt to delete a test audit record and attempt to delete a test audit settings. If a non-privileged user account is allowed to delete the audit data or the audit configuration settings, this is a finding.

Fix: F-24161r493415_fix

Configure the application to protect audit data from unauthorized deletion. Limit users to roles that are assigned the rights to delete audit data and establish permissions that control access to the audit logs and audit configuration settings.

b
The application must protect audit tools from unauthorized access.
AU-9 - Medium - CCI-001493 - V-222503 - SV-222503r879579_rule
RMF Control
AU-9
Severity
Medium
CCI
CCI-001493
Version
APSC-DV-001310
Vuln IDs
  • V-222503
  • V-69489
Rule IDs
  • SV-222503r879579_rule
  • SV-84111
Protecting audit data also includes identifying and protecting the tools used to view and manipulate log data. Therefore, protecting audit tools is necessary to prevent unauthorized operation on audit data. Applications providing tools to interface with audit data will leverage user permissions and roles identifying the user accessing the tools and the corresponding rights the user enjoys in order make access decisions regarding the access to audit tools. Audit tools include, but are not limited to, vendor-provided and open source audit tools needed to successfully view and manipulate audit information system activity and records. Audit tools include custom queries and report generators.
Checks: C-36241r602288_chk

Review the system documentation and interview the application administrator for details regarding application architecture, audit methods, and audit tools. Identify the application audit tools and their locations. If the application does not provide a distinct audit tool oriented functionality that is a separate tool with an ability to view and manipulate log data, this requirement is not applicable. Identify the methods used for implementing the audit tool functionality within the application. Typical methods are file system-based, e.g., a separate executable file that when invoked provides audit functionality, an application user interface to an audit module, or a combination thereof. For file system access: Review file system permissions to ensure the application audit components such as executable files and libraries are protected by adequate file permission restrictions. Permissions must be configured to limit access to only those who have been identified and whose access has been approved. If file permissions are configured to allow unapproved access, this is a finding. For circumstances where audit tools are accessed via application sub-modules or menus: Identify the application module that provides access to audit settings and audit data. Attempt to access audit configuration features and logs by using a regular non-privileged application or database user account. If a non-privileged user account is allowed to access the audit data or the audit configuration settings, this is a finding.

Fix: F-36207r602289_fix

Configure the application to protect audit data from unauthorized access. Limit users to roles that are assigned the rights to view, edit or copy audit data, and establish file permissions that control access to the audit tools and audit tool capabilities and configuration settings.

b
The application must protect audit tools from unauthorized modification.
AU-9 - Medium - CCI-001494 - V-222504 - SV-222504r879580_rule
RMF Control
AU-9
Severity
Medium
CCI
CCI-001494
Version
APSC-DV-001320
Vuln IDs
  • V-222504
  • V-69491
Rule IDs
  • SV-222504r879580_rule
  • SV-84113
Protecting audit data also includes identifying and protecting the tools used to view and manipulate log data. Therefore, protecting audit tools is necessary to prevent unauthorized operation on audit data. Applications providing tools to interface with audit data will leverage user permissions and roles identifying the user accessing the tools and the corresponding rights the user enjoys in order make access decisions regarding the modification of audit tools. Audit tools include, but are not limited to, vendor-provided and open source audit tools needed to successfully view and manipulate audit information system activity and records. Audit tools include custom queries and report generators.
Checks: C-36242r602291_chk

Review the system documentation and interview the application administrator for details regarding application architecture, audit methods, and provided audit tools. Identify the application audit tools and their locations. If the application does not provide a distinct audit tool oriented functionality that is a separate tool with an ability to view and manipulate log data, this requirement is not applicable. Identify the methods used for implementing an audit tool functionality that is separate from the application. Typical methods are file-oriented in nature, e.g., the application includes a separate executable file or library that when invoked allows users to view and manipulate logs. Identify the users with the rights to modify the audit tools. This capability will usually be reserved for admin staff. Review file system permissions to ensure the application audit components such as executable files and libraries are protected by adequate file permission restrictions. File permissions must be configured to limit access to only those users who have been identified and whose access has been approved. If file permissions are configured so as to allow unapproved modifications to the audit tools, this is a finding.

Fix: F-36208r602292_fix

Configure the application to protect audit tools from unauthorized modifications. Limit users to roles that are assigned the rights to edit or update audit tools and establish file permissions that control access to the audit tools and audit tool capabilities and configuration settings.

b
The application must protect audit tools from unauthorized deletion.
AU-9 - Medium - CCI-001495 - V-222505 - SV-222505r879581_rule
RMF Control
AU-9
Severity
Medium
CCI
CCI-001495
Version
APSC-DV-001330
Vuln IDs
  • V-222505
  • V-69493
Rule IDs
  • SV-222505r879581_rule
  • SV-84115
Protecting audit data also includes identifying and protecting the tools used to view and manipulate log data. Therefore, protecting audit tools is necessary to prevent unauthorized operation on audit data. Applications providing tools to interface with audit data will leverage user permissions and roles identifying the user accessing the tools and the corresponding rights the user enjoys in order make access decisions regarding the deletion of audit tools. Audit tools include, but are not limited to, vendor-provided and open source audit tools needed to successfully view and manipulate audit information system activity and records. Audit tools include custom queries and report generators.
Checks: C-36243r602294_chk

Review the system documentation and interview the application administrator for details regarding application architecture, audit methods and provided audit tools. Identify the application audit tools and their locations. If the application does not provide a distinct audit tool oriented functionality that is a separate tool with an ability to view and manipulate log data, this requirement is not applicable. Identify the methods used for implementing an audit tool functionality that is separate from the application. Typical methods are file-oriented in nature, e.g., the application includes a separate executable file or library that when invoked allows users to view and manipulate logs. Identify the users with the rights to delete the audit tools. This capability is normally reserved for admin staff. Review file system permissions to ensure the application audit components such as executable files and libraries are protected by adequate file permission restrictions. File permissions must be configured to limit access to only those users who have been identified and whose access has been approved. If file permissions are configured to allow unapproved deletions of the audit tools, this is a finding.

Fix: F-36209r602295_fix

Configure the application to protect audit tools from unauthorized deletions. Limit users to roles that are assigned the rights to edit or delete audit tools and establish file permissions that control access to the audit tools and audit tool capabilities and configuration settings.

b
The application must back up audit records at least every seven days onto a different system or system component than the system or component being audited.
AU-9 - Medium - CCI-001348 - V-222506 - SV-222506r879582_rule
RMF Control
AU-9
Severity
Medium
CCI
CCI-001348
Version
APSC-DV-001340
Vuln IDs
  • V-222506
  • V-69495
Rule IDs
  • SV-222506r879582_rule
  • SV-84117
Protection of log data includes assuring log data is not accidentally lost or deleted. Backing up audit records to a different system or onto separate media than the system being audited on an organizationally defined frequency helps to assure in the event of a catastrophic system failure, the audit records will be retained. This helps to ensure a compromise of the information system being audited does not also result in a compromise of the audit records. This requirement only applies to applications that have a native backup capability for audit records. Operating system backup requirements cover applications that do not provide native backup functions.
Checks: C-24176r493426_chk

Review the application documentation and interview the application administrator. Identify log functionality and locations of log files. If the application does not include a built-in backup capability for backing up its own audit records, this requirement is not applicable. Access the management interface for configuring application audit logs and review the backup settings. If the application backup settings are not configured to backup application audit records every 7 days, this is a finding.

Fix: F-24165r493427_fix

Configure application backup settings to backup application audit logs every 7 days.

b
The application must use cryptographic mechanisms to protect the integrity of audit information.
AU-9 - Medium - CCI-001350 - V-222507 - SV-222507r879583_rule
RMF Control
AU-9
Severity
Medium
CCI
CCI-001350
Version
APSC-DV-001350
Vuln IDs
  • V-222507
  • V-69497
Rule IDs
  • SV-222507r879583_rule
  • SV-84119
Audit records may be tampered with; if the integrity of audit data were to become compromised, then forensic analysis and discovery of the true source of potentially malicious system activity is impossible to achieve. Protection of audit records and audit data is of critical importance. Cryptographic mechanisms are the industry established standard used to protect the integrity of audit data. An example of a cryptographic mechanism is the computation and application of a cryptographic-signed hash using asymmetric cryptography. This requirement applies to applications that generate, process or manage audit records and is applied once audit processing has completed and the audit record is being stored.
Checks: C-24177r493429_chk

Review the system documentation and interview the application administrator for details regarding application architecture, audit methods, and provided audit tools. Identify the location of the application audit information. If the application is configured to utilize a centralized audit log solution that uses cryptographic methods that meet this requirement such as creating cryptographic hash values or message digests that can be used to validate integrity of audit files, the requirement is not applicable. Ask application administrator to demonstrate the cryptographic mechanisms used to protect the integrity of audit data. Verify when application logs are stored on the file system, a process that includes the creation of an integrity check of the audit file being stored is utilized. This integrity check can be the creation of a checksum, message digest or other one-way cryptographic hash of the audit file that is created. If an integrity check is not created to protect the integrity of the audit information, this is a finding.

Fix: F-24166r493430_fix

Configure the application to create an integrity check consisting of a cryptographic hash or one-way digest that can be used to establish the integrity when storing log files.

b
Application audit tools must be cryptographically hashed.
AU-9 - Medium - CCI-001496 - V-222508 - SV-222508r879668_rule
RMF Control
AU-9
Severity
Medium
CCI
CCI-001496
Version
APSC-DV-001360
Vuln IDs
  • V-222508
  • V-69499
Rule IDs
  • SV-222508r879668_rule
  • SV-84121
Protecting the integrity of the tools used for auditing purposes is a critical step to ensuring the integrity of audit data. Audit data includes all information (e.g., audit records, audit settings, and audit reports) needed to successfully audit information system activity. Audit tools include, but are not limited to, vendor provided and open source audit tools needed to successfully view and manipulate audit information system activity and records. Audit tools include custom queries and report generators. It is not uncommon for attackers to replace the audit tools or inject code into the existing tools with the purpose of providing the capability to hide or erase system activity from the audit logs. To address this risk, audit tools must be cryptographically signed/hashed and the resulting value securely stored in order to provide the capability to identify when the audit tools have been modified, manipulated or replaced. Some OSs provide a native command line tool capable of extracting or creating a hash value. Care must be taken to ensure any hashing algorithm strength used is acceptable. An example is UNIX OS variants that provide the "shasum" utility with SHA256 capabilities. Windows is not known to provide a native cryptographic tool that utilizes an acceptable hashing algorithm. The Windows fciv.exe checksum tool currently only utilizes MD5 and SHA1 which are not acceptable hashing algorithms.
Checks: C-24178r493432_chk

Review the system documentation and interview the application administrator for details regarding application architecture, audit methods, and provided audit tools. Identify the location of the application audit tools. Separate audit tools will be file-oriented in nature, e.g., the application includes a separate executable file or library that when invoked allows users to view and manipulate logs. If the application does not provide a separate tool in the form of a file which provides an ability to view and manipulate application log data, query data, or generate reports, this requirement is not applicable. If the system hosting the application has a separate file monitoring utility installed that is configured to identify changes to audit tools and alarm on changes to audit tools, this is not applicable. Ask application administrator to demonstrate the cryptographic hashing mechanisms used to create the one way hashes that can be used to validate the integrity of audit tools. For example, "shasum /path/to/file &gt; checksum.filename". Ask the application administrator to provide the list of checksum values and the associated file names of the audit tools. If a cryptographic checksum or hash value of the audit tool file is not created for future reference, this is a finding.

Fix: F-24167r493433_fix

Cryptographically hash the audit tool files used by the application. Store and protect the generated hash values for future reference.

b
The integrity of the audit tools must be validated by checking the files for changes in the cryptographic hash value.
AU-9 - Medium - CCI-001496 - V-222509 - SV-222509r879668_rule
RMF Control
AU-9
Severity
Medium
CCI
CCI-001496
Version
APSC-DV-001370
Vuln IDs
  • V-222509
  • V-69501
Rule IDs
  • SV-222509r879668_rule
  • SV-84123
Protecting the integrity of the tools used for auditing purposes is a critical step to ensuring the integrity of audit data. Audit data includes all information (e.g., audit records, audit settings, and audit reports) needed to successfully audit information system activity. Audit tools include, but are not limited to, vendor provided and open source audit tools needed to successfully view and manipulate audit information system activity and records. Audit tools include custom queries and report generators. It is not uncommon for attackers to replace the audit tools or inject code into the existing tools with the purpose of providing the capability to hide or erase system activity from the audit logs. To address this risk, audit tools must be cryptographically signed/hashed in order to provide the capability to identify when the audit tools have been modified, manipulated or replaced. An example is a checksum hash of the file or files.
Checks: C-24179r493435_chk

Review the system documentation and interview the application administrator for details regarding application architecture, audit methods, and provided audit tools. Identify the location of the application audit tools. Separate audit tools will be file-oriented in nature, e.g., the application includes a separate executable file or library that when invoked allows users to view and manipulate logs. If the application does not provide a separate tool in the form of a file which provides an ability to view and manipulate application log data, query data or generate reports, this requirement is not applicable. If the system hosting the application has a separate file monitoring utility installed that is configured to identify changes to audit tools and alarm on changes to audit tools, this is not applicable. Ask the application administrator to provide their process for periodically checking the list of checksum values against the associated file names of the audit tools to ensure none of the audit tools have been tampered with. If a cryptographic checksum or hash value of the audit tool file is not periodically checked to ensure the integrity of audit tools, this is a finding.

Fix: F-24168r493436_fix

Establish a process to periodically check the audit tool cryptographic hashes to ensure the audit tools have not been tampered with.

b
The application must prohibit user installation of software without explicit privileged status.
CM-11 - Medium - CCI-001812 - V-222510 - SV-222510r879751_rule
RMF Control
CM-11
Severity
Medium
CCI
CCI-001812
Version
APSC-DV-001390
Vuln IDs
  • V-222510
  • V-69503
Rule IDs
  • SV-222510r879751_rule
  • SV-84125
Allowing regular users to install software, without explicit privileges, creates the risk that untested or potentially malicious software will be installed on the system. Explicit privileges (escalated or administrative privileges) provide the regular user with explicit capabilities and control that exceeds the rights of a regular user. Application functionality will vary, and while users are not permitted to install unapproved applications, there may be instances where the organization allows the user to install approved software packages such as from an approved software repository. The application must enforce software installation by users based upon what types of software installations are permitted (e.g., updates and security patches to existing software) and what types of installations are prohibited (e.g., software whose pedigree with regard to being potentially malicious is unknown or suspect) by the organization. This requirement applies, for example, to applications that provide the ability to extend application functionality (e.g., plug-ins, add-ons) and software management applications.
Checks: C-24180r493438_chk

Review the application documentation and interview the application administrator to determine the capabilities of the application as it relates to software installation or product function extension. Identify any software configuration change capabilities which are allowed by design and incorporated into the user interface. An example is utilizing a known software repository of tested and approved extensions, plugins or modules which can be used by application users to extend application features or functions. If the application does not provide the ability to install software components, modules, plugins, or extensions, the requirement is not applicable. Access the application user interface as a regular user, navigate to the application screen that provides the software installation function and attempt to install software components, modules, extensions, or plugins. If the application utilizes an approved repository of approved software that has been tested and approved for all application users to install, this is not a finding. If the application allows regular users to install untested or unapproved software components, extensions, modules, or plugins without explicit authorization, this is a finding.

Fix: F-24169r493439_fix

Configure the application to prohibit user installation of software without explicit permission.

b
The application must enforce access restrictions associated with changes to application configuration.
CM-5 - Medium - CCI-001813 - V-222511 - SV-222511r879753_rule
RMF Control
CM-5
Severity
Medium
CCI
CCI-001813
Version
APSC-DV-001410
Vuln IDs
  • V-222511
  • V-69505
Rule IDs
  • SV-222511r879753_rule
  • SV-84127
Failure to provide logical access restrictions associated with changes to application configuration may have significant effects on the overall security of the system. When dealing with access restrictions pertaining to change control, it should be noted that any changes to the hardware, software, and/or firmware components of the information system and/or application can potentially have significant effects on the overall security of the system. Accordingly, only qualified and authorized individuals should be allowed to obtain access to application components for the purposes of initiating changes, including upgrades and modifications. Logical access restrictions include, for example, controls that restrict access to workflow automation, media libraries, abstract layers (e.g., changes implemented into third-party interfaces rather than directly into information systems), and change windows (e.g., changes occur only during specified times, making unauthorized changes easy to discover).
Checks: C-24181r493441_chk

Review the application documentation and configuration settings. Access the application configuration settings interface as a regular non-privileged user. Attempt to make configuration changes to the application. If configuration changes can be made by regular non-privileged users, this is a finding. Review the locations of all configuration files used by the application. Examine the file permission settings and determine who has access to the configuration files. If access permissions to configuration files are not restricted to application administrators, this is a finding.

Fix: F-24170r493442_fix

Configure the application to limit access to configuration settings to only authorized users.

b
The application must audit who makes configuration changes to the application.
CM-5 - Medium - CCI-001814 - V-222512 - SV-222512r879754_rule
RMF Control
CM-5
Severity
Medium
CCI
CCI-001814
Version
APSC-DV-001420
Vuln IDs
  • V-222512
  • V-69507
Rule IDs
  • SV-222512r879754_rule
  • SV-84129
Without auditing the enforcement of access restrictions against changes to the application configuration, it will be difficult to identify attempted attacks and an audit trail will not be available for forensic investigation for after-the-fact actions. Enforcement actions are the methods or mechanisms used to prevent unauthorized changes to configuration settings. Enforcement action methods may be as simple as denying access to a file based on the application of file permissions (access restriction). Audit items may consist of lists of actions blocked by access restrictions or changes identified after-the-fact. If application configuration is maintained by using a text editor to modify a configuration file, this function may be delegated to an operating system file monitoring/auditing capability.
Checks: C-24182r493444_chk

Review the application documentation and configuration settings. Access the application configuration settings interface as a privileged user. Make configuration changes to the application. Review the application audit logs and ensure a log entry is made identifying the privileged user account that was used to make the changes. If application configuration is maintained by using a text editor to modify a configuration file, modify the configuration file with a text editor. Review the system logs and ensure a log entry is made for the file modification that identifies the user that was used to make the changes. If the user account is not logged, or is a group account such as "root", this is a finding. If the user account used to make the changes is not logged in the audit records, this is a finding.

Fix: F-24171r493445_fix

Configure the application to create log entries that can be used to identify the user accounts that make application configuration changes.

b
The application must have the capability to prevent the installation of patches, service packs, or application components without verification the software component has been digitally signed using a certificate that is recognized and approved by the organization.
CM-5 - Medium - CCI-001749 - V-222513 - SV-222513r879584_rule
RMF Control
CM-5
Severity
Medium
CCI
CCI-001749
Version
APSC-DV-001430
Vuln IDs
  • V-222513
  • V-69509
Rule IDs
  • SV-222513r879584_rule
  • SV-84131
Changes to any software components can have significant effects on the overall security of the application. Verifying software components have been digitally signed using a certificate that is recognized and approved by the organization ensures the software has not been tampered with and that it has been provided by a trusted vendor. Accordingly, patches, service packs, or application components must be signed with a certificate recognized and approved by the organization. Verifying the authenticity of the software prior to installation validates the integrity of the patch or upgrade received from a vendor. This ensures the software has not been tampered with and that it has been provided by a trusted vendor. Self-signed certificates are disallowed by this requirement. The application should not have to verify the software again. This requirement does not mandate DoD certificates for this purpose; however, the certificate used to verify the software must be from an approved CA. If this capability is not present, the vendor must provide a cryptographic hash value that can be verified by a system administrator prior to installation.
Checks: C-36244r602297_chk

Review the application documentation and interview the application administrator to determine the process and commands used for patching the application. Access application configuration settings. Review commands and procedures used to patch the application and ensure a capability exists to prevent unsigned patches from being applied. If the application is not capable of preventing installation of patches and packages that are not signed, or if the vendor does not provide a cryptographic hash value that can be manually checked prior to installation, this is a finding.

Fix: F-36210r602298_fix

Design and configure the application to have the capability to prevent unsigned patches and packages from being installed. Provide a cryptographic hash value that can be verified by a system administrator prior to installation.

b
The applications must limit privileges to change the software resident within software libraries.
CM-5 - Medium - CCI-001499 - V-222514 - SV-222514r879586_rule
RMF Control
CM-5
Severity
Medium
CCI
CCI-001499
Version
APSC-DV-001440
Vuln IDs
  • V-222514
  • V-69511
Rule IDs
  • SV-222514r879586_rule
  • SV-84133
If the application were to allow any user to make changes to software libraries, then those changes might be implemented without undergoing the appropriate testing and approvals that are part of a robust change management process. This requirement applies to applications with software libraries that are accessible and configurable, as in the case of interpreted languages. Software libraries also include privileged programs which execute with escalated privileges. Only qualified and authorized individuals will be allowed to obtain access to information system components for purposes of initiating changes, including upgrades and modifications.
Checks: C-24184r493450_chk

Review the application documentation and interview the application administrator to identify the application architecture. Identify application folders where application libraries are stored. Review permissions of application folders and library files contained with the folders to ensure file permissions restrict access to authorized users or processes. Access application configuration settings. Examine settings for capability to update software libraries or extend application functionality via the application. Review user roles and access rights within the application to determine if access to this capability is restricted to authorized users. If file restrictions do not limit write access to library files and if the application does not restrict access to library update functionality, this is a finding.

Fix: F-24173r493451_fix

Configure the application OS file permissions to restrict access to software libraries and configure the application to restrict user access regarding software library update functionality to only authorized users or processes.

b
An application vulnerability assessment must be conducted.
CM-6 - Medium - CCI-000366 - V-222515 - SV-222515r879887_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
APSC-DV-001460
Vuln IDs
  • V-222515
  • V-69513
Rule IDs
  • SV-222515r879887_rule
  • SV-84135
An application vulnerability assessment is a test conducted in order to identify weaknesses and security vulnerabilities that may exist within an application. The testing must cover all aspects and components of the application architecture. If an application consists of a web server and a database, then both components must be tested for vulnerabilities to the fullest extent possible. Vulnerability assessment tests normally utilize a combination of specialized software called application vulnerability scanners as well as custom scripts and manual tests. In some instances, multiple tools are required in order to test all aspects of application features, functions and architecture. The vulnerability scanner is typically configured to communicate with the application through the user interface or via an applications communication port. In addition to using automated tools, manual tests conducted from the OS console such as executing custom scripts or reviewing configuration settings for known vulnerabilities may also be included as part of the test. Testers will typically utilize application user test accounts in order to test application features and functionality such as adding content, executing queries and completing transactions. The vulnerability testing software utilizes user actions and access as well as a list of known security vulnerabilities in order to detect and identify weak security controls or misconfigurations that could potentially be manipulated by the user or create a security vulnerability. The Open Web Application Security Project (OWASP) top 10 for 2013 includes the following top issues that should be tested. The site is available by pointing your browser to https://www.owasp.org. A1 Injection A2 Weak authentication and session management A3 XSS A4 Insecure Direct Object References A5 Security Misconfiguration A6 Sensitive Data Exposure A7 Missing Function Level Access Control A8 Cross Site Request Forgery A9 Using Components with Known Vulnerabilities A10 Unvalidated Redirects and Forwards The OWASP top 10 are categories of tests that can be applied to most but not necessarily all applications and are provided as an example of what to test for. Scanning tools include a multitude of tests that fall under these categories but may refer to these tests by a different name. Testing must be conducted on a periodic basis while the application is in production and subsequent to system changes to ensure any changes made to the system do not introduce new security vulnerabilities.
Checks: C-24185r493453_chk

Review the application documentation to understand application architecture. Interview the application administrator, obtain and review their application vulnerability scanning process. Request the latest scan results including scan configuration settings. Review scan configurations and ensure coverage of all application architecture has been tested. The proper scanning tool or combination of tools must be utilized in order to ensure the full range of application features and functionality is tested. For example, if the application includes a web interface and a SQL database, then ensure test results for web and SQL vulnerabilities are provided. Although web and SQL applications are included as examples and are the prevalent types of applications, this requirement is not intended to be limited to just the aforementioned application architectures. Ensure test results are provided from all testing tools employed during vulnerability testing. If high risk security vulnerabilities are identified in the scan results, request subsequent test results that indicate the issues have been fixed or mitigated. If the high risk issues identified in the report have not been fixed or mitigated to a level accepted by the ISSO and the ISSM, or if the application administrator cannot produce vulnerability security testing results that cover the range of application functionality, this is a finding.

Fix: F-24174r493454_fix

Configure the application vulnerability scanners to test all components of the application, conduct vulnerability scans on a regular basis and remediate identified issues. Retain scan results for compliance verification.

b
The application must prevent program execution in accordance with organization-defined policies regarding software program usage and restrictions, and/or rules authorizing the terms and conditions of software program usage.
CM-7 - Medium - CCI-001764 - V-222516 - SV-222516r879757_rule
RMF Control
CM-7
Severity
Medium
CCI
CCI-001764
Version
APSC-DV-001480
Vuln IDs
  • V-222516
  • V-69515
Rule IDs
  • SV-222516r879757_rule
  • SV-84137
Control of application execution is a mechanism used to prevent execution of unauthorized applications in order to follow the rules of least privilege. Some applications may provide a capability that runs counter to the mission or provides users with functionality that exceeds mission requirements. Some of the functions and services, provided by default, may not be necessary to support essential organizational operations (e.g., key missions, functions). Removal of executable programs is not always possible; therefore, establishing a method of preventing program execution is critical to maintaining a secure system baseline. Software program restrictions include restricting execution of programs in certain environments, while preventing execution in other environments; or limiting execution of certain application functionality based on organization-defined criteria (e.g., privileges, subnets, sandboxed environments, security managers, roles).
Checks: C-24186r493456_chk

Review the application documentation and interview the application administrator to determine if policies, rules, or restrictions exist regarding application usage or terms which authorize the conditions of application use. If the policy, terms, or conditions state there are no usage restrictions, this requirement is not applicable. Interview the application administrator, review policy, terms, and conditions documents to determine what the terms and conditions of application usage are. Have the application administrator demonstrate how the program execution is restricted in accordance with the policy terms and conditions. Typical methods include but are not limited to the use of Windows Group Policy, AppLocker, Software Restriction Policies, Java Security Manager, and Role-Based Access Control (RBAC). If application requirements or policy documents specify application execution restriction requirements and the execution of the application or its subcomponents are not restricted in accordance with requirements or policy, this is a finding.

Fix: F-24175r493457_fix

Restrict application execution in accordance with the policy, terms, and conditions specified.

b
The application must employ a deny-all, permit-by-exception (whitelist) policy to allow the execution of authorized software programs.
CM-7 - Medium - CCI-001774 - V-222517 - SV-222517r879759_rule
RMF Control
CM-7
Severity
Medium
CCI
CCI-001774
Version
APSC-DV-001490
Vuln IDs
  • V-222517
  • V-69517
Rule IDs
  • SV-222517r879759_rule
  • SV-84139
Utilizing a whitelist provides a configuration management method for allowing the execution of only authorized software. Using only authorized software decreases risk by limiting the number of potential vulnerabilities. The organization must identify authorized software programs and permit execution of authorized software. The process used to identify software programs that are authorized to execute on organizational information systems is commonly referred to as whitelisting. Verification of whitelisted software can occur either prior to execution or at system startup. This requirement applies to configuration management applications or similar types of applications designed to manage system processes and configurations (e.g., HBSS and software wrappers).
Checks: C-24187r493459_chk

If the application is not a configuration management or similar type of application designed to manage system processes and configurations, this requirement is not applicable. Review the application documentation and interview the application administrator to identify if application whitelisting specifying which applications or application subcomponents are allowed to execute is in use. Check for the existence of policy settings or policy files that can be configured to restrict application execution. Have the application administrator demonstrate how the program execution is restricted. Look for a deny-all, permit-by-exception policy of restriction. Some methods for restricting execution include but are not limited to the use of custom capabilities built into the application or leveraging of Windows Group Policy, AppLocker, Software Restriction Policies, Java Security Manager or Role-Based Access Controls (RBAC). If application whitelisting is not utilized or does not follow a deny-all, permit-by-exception (whitelist) policy, this is a finding.

Fix: F-24176r493460_fix

Configure the application to utilize a deny-all, permit-by-exception policy when allowing the execution of authorized software.

b
The application must be configured to disable non-essential capabilities.
CM-7 - Medium - CCI-000381 - V-222518 - SV-222518r879587_rule
RMF Control
CM-7
Severity
Medium
CCI
CCI-000381
Version
APSC-DV-001500
Vuln IDs
  • V-222518
  • V-69519
Rule IDs
  • SV-222518r879587_rule
  • SV-84141
It is detrimental for applications to provide, or install by default, functionality exceeding requirements or mission objectives. These unnecessary capabilities or services are often overlooked and therefore may remain unsecured. They increase the risk to the platform by providing additional attack vectors. Applications are capable of providing a wide variety of functions and services. Some of the functions and services, provided by default, may not be necessary to support essential organizational operations (e.g., key missions, functions). Examples of non-essential capabilities include, but are not limited to, advertising software or browser plug-ins not related to requirements or providing a wide array of functionality not required for every mission, but cannot be disabled.
Checks: C-24188r493462_chk

Review the application guidance, application requirements documentation, and interview the application administrator. Identify the application's operational requirements and what services the application is intended to provide users. Review the overall application features and functionality via the user interface. Review and identify installed application software modules via configuration settings. Using the relevant OS commands, identify services running on the system and have the application administrator identify the services related to the application. If the application is operating with extraneous capabilities that have not been defined as required in order to meet mission objectives, this is a finding.

Fix: F-24177r493463_fix

Disable application extraneous application functionality that is not required in order to fulfill the application's mission.

b
The application must be configured to use only functions, ports, and protocols permitted to it in the PPSM CAL.
CM-7 - Medium - CCI-000382 - V-222519 - SV-222519r918119_rule
RMF Control
CM-7
Severity
Medium
CCI
CCI-000382
Version
APSC-DV-001510
Vuln IDs
  • V-222519
  • V-69521
Rule IDs
  • SV-222519r918119_rule
  • SV-84143
In order to prevent unauthorized connection of devices, unauthorized transfer of information, or unauthorized tunneling (i.e., embedding of data types within data types), organizations must disable or restrict unused or unnecessary physical and logical ports/protocols on information systems. Applications are capable of providing a wide variety of functions and services. Some of the functions and services provided by default may not be necessary to support essential organizational operations. Additionally, it is sometimes convenient to provide multiple services from a single component (e.g., email and web services; however, doing so increases risk over limiting the services provided by any one component. To support the requirements and principles of least functionality, the application must support the organizational requirements providing only essential capabilities and limiting the use of ports, protocols, and/or services to only those required, authorized, and approved to conduct official business or to address authorized quality of life issues.
Checks: C-24189r918118_chk

Review the application documentation and configuration. Interview the application administrator. Identify the network ports and protocols that are utilized by the application. Using a combination of relevant OS commands and application configuration utilities, identify the TCP/IP port numbers the application is configured to utilize and is utilizing. Review the PPSM Category Assurance List (CAL) at: https://cyber.mil/ppsm/cal/ Verify the ports used by the application are approved by the PPSM CAL. If the ports are not approved by the PPSM CAL, this is a finding.

Fix: F-24178r493466_fix

Configure the application to utilize application ports approved by the PPSM CAL.

b
The application must require users to reauthenticate when organization-defined circumstances or situations require reauthentication.
IA-11 - Medium - CCI-002038 - V-222520 - SV-222520r879762_rule
RMF Control
IA-11
Severity
Medium
CCI
CCI-002038
Version
APSC-DV-001520
Vuln IDs
  • V-222520
  • V-69523
Rule IDs
  • SV-222520r879762_rule
  • SV-84145
Without reauthentication, users may access resources or perform tasks for which they do not have authorization. When applications provide the capability to change security roles or escalate the functional capability of the application, it is critical the user reauthenticate. In addition to the reauthentication requirements associated with session locks, organizations may require reauthentication of individuals and/or devices in other situations, including (but not limited to) the following circumstances: (i) When authenticators change; (ii) When roles change; (iii) When security categories of information systems change; (iv) When the execution of privileged functions occurs; (v) After a fixed period of time; or (vi) Periodically. Within the DoD, the minimum circumstances requiring reauthentication are privilege escalation and role changes.
Checks: C-24190r493468_chk

Review the application guidance and interview the application administrator. Identify the application user roles. Identify the methods and manner in which an application user is allowed to escalate their privileges or change their role. Create or utilize an account that has 2 roles within the application, both should be non-administrator. Example: User role and Report Creator role. Authenticate to the application as the user in the User role. Access the application functionality that allows the user to change their role and change from the User role to the Report Creator role. If the user is not prompted to reauthenticate before the user’s role is changed, this is a finding. Log out of the application and log back in as the User role. Access the application functionality that allows the user to escalate their privileges to an administrative user. Attempt to escalate the privileges of the user. If the user is not prompted to reauthenticate before the user is allowed to proceed with escalated privileges, this is a finding.

Fix: F-24179r493469_fix

Configure the application to require reauthentication before user privilege is escalated and user roles are changed.

b
The application must require devices to reauthenticate when organization-defined circumstances or situations requiring reauthentication.
IA-11 - Medium - CCI-002039 - V-222521 - SV-222521r879763_rule
RMF Control
IA-11
Severity
Medium
CCI
CCI-002039
Version
APSC-DV-001530
Vuln IDs
  • V-222521
  • V-69525
Rule IDs
  • SV-222521r879763_rule
  • SV-84147
Without reauthenticating devices, unidentified or unknown devices may be introduced; thereby facilitating malicious activity. In addition to the reauthentication requirements associated with session locks, organizations may require reauthentication of devices, including (but not limited to), the following other situations: (i) When authenticators change; (ii) When roles change; (iii) When security categories of information systems change; (iv) After a fixed period of time; or (v) Periodically. For distributed architectures (e.g., service-oriented architectures), the decisions regarding the validation of identification claims may be made by services separate from the services acting on those decisions. In such situations, it is necessary to provide the identification decisions (as opposed to the actual identifiers) to the services that need to act on those decisions. Gateways and SOA applications are examples of where this requirement would apply.
Checks: C-24191r493471_chk

Review the application guidance and interview the application administrator. Identify the methods and manner in which application devices such as an XML gateway, SOA application gateway, or application firewall is allowed to access the application. Most devices themselves will not change role or authenticators once they are established but will need to periodically re-authenticate. Review the configuration setting in the application where the time period is set to force the device to reauthenticate. Review local policy requirements to determine if reauthentication intervals are specified. If the device is not forced to reauthenticate periodically, this is a finding.

Fix: F-24180r493472_fix

Configure the application to require reauthentication periodically.

c
The application must uniquely identify and authenticate organizational users (or processes acting on behalf of organizational users).
IA-2 - High - CCI-000764 - V-222522 - SV-222522r879589_rule
RMF Control
IA-2
Severity
High
CCI
CCI-000764
Version
APSC-DV-001540
Vuln IDs
  • V-222522
  • V-69527
Rule IDs
  • SV-222522r879589_rule
  • SV-84149
To assure accountability and prevent unauthenticated access, organizational users must be identified and authenticated to prevent potential misuse and compromise of the system. Organizational users include organizational employees or individuals the organization deems to have equivalent status of employees (e.g., contractors). Organizational users (and any processes acting on behalf of users) must be uniquely identified and authenticated for all accesses, except the following: (i) Accesses explicitly identified and documented by the organization. Organizations document specific user actions that can be performed on the information system without identification or authentication; and (ii) Accesses that occur through authorized use of group authenticators without individual authentication. Organizations may require unique identification of individuals in group accounts (e.g., shared privilege accounts) or for detailed accountability of individual activity.
Checks: C-24192r493474_chk

Review the application documentation and interview the application administrator to determine how organizational users access the application. If the application is publicly available, providing access to publicly releasable data and the users are non-organizational users such as individuals who no longer have a CAC (e.g., retirees) or members of the public with no requirement for DoD credentials, this requirement is not applicable. The requirement still applies to DoD organizational users and admins when accessing the non-public data areas or system resources of the system. Attempt to access the application and confirm that a unique user account and password or CAC token and pin are required in order to access the application. If the application does not uniquely identify and authenticate users, this is a finding.

Fix: F-24181r493475_fix

Configure the application to uniquely identify and authenticate users and user processes.

b
The application must use multifactor (Alt. Token) authentication for network access to privileged accounts.
IA-2 - Medium - CCI-000765 - V-222523 - SV-222523r879590_rule
RMF Control
IA-2
Severity
Medium
CCI
CCI-000765
Version
APSC-DV-001550
Vuln IDs
  • V-222523
  • V-69529
Rule IDs
  • SV-222523r879590_rule
  • SV-84151
Multifactor authentication requires using two or more factors to achieve authentication and access. Factors include: (i) something a user knows (e.g., password/PIN); (ii) something a user has (e.g., cryptographic identification device, token); or (iii) something a user is (e.g., biometric). Multifactor authentication decreases the attack surface by virtue of the fact that attackers must obtain two factors, a physical token or a biometric and a PIN, in order to authenticate. It is not enough to simply steal a user's password to obtain access. A privileged account is defined as an information system account with authorizations of a privileged user. An Alt. Token is a separate CAC like token used specifically for administrative account access and serves as a separate identifier much like a separate user account. Network access is defined as access to an information system by a user (or a process acting on behalf of a user) communicating through a network (e.g., local area network, wide area network, or the Internet).
Checks: C-24193r493477_chk

Review the application documentation and interview the application administrator to identify application access methods. Ask the application administrator to present both their primary CAC and their Alt. Token. Ask the application administrator to log on to the application using application relevant network based access methods. Attempt to use both CAC and Alt. Tokens to authenticate to the application. Validate the application requests the user to input their CAC PIN and that they cannot perform administrative functions. Have user logoff and reauthenticate with their Alt. Token and that they can perform administrative functions. If the application allows administrative access to the application without requiring an Alt. Token, this is a finding.

Fix: F-24182r493478_fix

Configure the application to use an Alt. Token when providing network access to privileged application accounts.

b
The application must accept Personal Identity Verification (PIV) credentials.
IA-2 - Medium - CCI-001953 - V-222524 - SV-222524r879764_rule
RMF Control
IA-2
Severity
Medium
CCI
CCI-001953
Version
APSC-DV-001560
Vuln IDs
  • V-222524
  • V-69531
Rule IDs
  • SV-222524r879764_rule
  • SV-84153
The use of PIV credentials facilitates standardization and reduces the risk of unauthorized access. DoD has mandated the use of the CAC to support identity management and personal authentication for systems covered under HSPD 12, as well as a primary component of layered protection for national security systems.
Checks: C-24194r493480_chk

Review the application documentation and interview the application administrator to identify application access methods. If the application is not PK-enabled due to the hosted data being publicly releasable, this check is not applicable. Ask the application administrator to log on to the application. Have the application admin use their non-privileged credentials. Validate the application prompts the user to provide a certificate from the CAC. If the application allows access without requiring a CAC, this is a finding.

Fix: F-24183r493481_fix

Configure the application to require CAC authentication.

b
The application must electronically verify Personal Identity Verification (PIV) credentials.
IA-2 - Medium - CCI-001954 - V-222525 - SV-222525r879765_rule
RMF Control
IA-2
Severity
Medium
CCI
CCI-001954
Version
APSC-DV-001570
Vuln IDs
  • V-222525
  • V-69533
Rule IDs
  • SV-222525r879765_rule
  • SV-84155
The use of PIV credentials facilitates standardization and reduces the risk of unauthorized access. DoD has mandated the use of the CAC to support identity management and personal authentication for systems covered under HSPD 12, as well as a primary component of layered protection for national security systems. If the application does not verify the credentials provided, user authentication cannot be established which places the integrity and confidentiality of the application at risk.
Checks: C-24195r493483_chk

Review the application documentation and interview the application administrator to identify application access methods. If the application is not PK-enabled due to the hosted data being publicly releasable, this check is not applicable. Ask the application administrator to log on to the application. Validate the application prompts the user to provide a certificate from the CAC. Validate the application requests the user to input their CAC PIN. If the application allows access without requiring a CAC, this is a finding.

Fix: F-24184r493484_fix

Configure the application to require CAC authentication.

b
The application must use multifactor (e.g., CAC, Alt. Token) authentication for network access to non-privileged accounts.
IA-2 - Medium - CCI-000766 - V-222526 - SV-222526r879591_rule
RMF Control
IA-2
Severity
Medium
CCI
CCI-000766
Version
APSC-DV-001580
Vuln IDs
  • V-222526
  • V-69535
Rule IDs
  • SV-222526r879591_rule
  • SV-84157
To assure accountability and prevent unauthenticated access, non-privileged users must utilize multifactor authentication to prevent potential misuse and compromise of the system. Multifactor authentication uses two or more factors to achieve authentication. Factors include: (i) Something you know (e.g., password/PIN); (ii) Something you have (e.g., cryptographic identification device, CAC/SIPRNet token); or (iii) Something you are (e.g., biometric). A non-privileged account is any information system account with authorizations of a non-privileged user. Network access is any access to an application by a user (or process acting on behalf of a user) where said access is obtained through a network connection. Applications integrating with the DoD Active Directory and utilize the DoD CAC are an example of compliant multifactor authentication solutions.
Checks: C-24196r493486_chk

Review the application documentation and interview the application administrator to identify application access methods. If the application is not PK-enabled due to the hosted data being publicly releasable, this check is not applicable. Ask the application administrator to log on to the application. Have the application admin use their non-privileged credentials. Validate the application prompts the user to provide a certificate from the CAC. Validate the application requests the user to input their CAC PIN. If the application allows access without requiring a CAC or Alt. Token, this is a finding.

Fix: F-24185r493487_fix

Configure the application to require CAC or Alt. Token authentication for non-privileged network access to non-privileged accounts.

b
The application must use multifactor (Alt. Token) authentication for local access to privileged accounts.
IA-2 - Medium - CCI-000767 - V-222527 - SV-222527r879592_rule
RMF Control
IA-2
Severity
Medium
CCI
CCI-000767
Version
APSC-DV-001590
Vuln IDs
  • V-222527
  • V-69537
Rule IDs
  • SV-222527r879592_rule
  • SV-84159
Multifactor authentication requires using two or more factors to achieve authentication and access. Factors include: (i) something a user knows (e.g., password/PIN); (ii) something a user has (e.g., cryptographic identification device, token); or (iii) something a user is (e.g., biometric). Multifactor authentication decreases the attack surface by virtue of the fact that attackers must obtain two factors, a physical token or a biometric and a PIN, in order to authenticate. It is not enough to simply steal a user's password to obtain access. A privileged account is defined as an information system account with authorizations of a privileged user. An Alt. Token is a separate CAC or token used specifically for administrative account access and serves as a separate identifier much like a separate user account. Local access is defined as access to an organizational information system by a user (or process acting on behalf of a user) communicating through a direct connection without the use of a network.
Checks: C-24197r493489_chk

Review the application documentation and interview the application administrator to identify application access methods. Ask the application administrator to present both their primary CAC and their Alt. Token. Ask the application administrator to log on to the application using the local application console. Attempt to use both the CAC and Alt. Tokens to authenticate to the application. Validate the application requests the user to input their CAC PIN and that they cannot perform administrative functions. Have user logoff and reauthenticate with their Alt. Token and that they can perform administrative functions. If the application allows administrative access to the application without requiring an Alt. Token, this is a finding.

Fix: F-24186r493490_fix

Configure the application to only use Alt. Tokens when locally accessing privileged application accounts.

b
The application must use multifactor (e.g., CAC, Alt. Token) authentication for local access to non-privileged accounts.
IA-2 - Medium - CCI-000768 - V-222528 - SV-222528r879593_rule
RMF Control
IA-2
Severity
Medium
CCI
CCI-000768
Version
APSC-DV-001600
Vuln IDs
  • V-222528
  • V-69539
Rule IDs
  • SV-222528r879593_rule
  • SV-84161
To assure accountability, prevent unauthenticated access, and prevent misuse of the system, privileged users must utilize multifactor authentication for local access. Multifactor authentication is defined as: using two or more factors to achieve authentication. Factors include: (i) Something a user knows (e.g., password/PIN); (ii) Something a user has (e.g., cryptographic identification device, token); or (iii) Something a user is (e.g., biometric). A non-privileged account is defined as an information system account with authorizations of a regular or non-privileged user. Local access is defined as access to an organizational information system by a user (or process acting on behalf of a user) communicating through a direct connection without the use of a network. Applications integrating with the DoD Active Directory and utilize the DoD CAC are examples of compliant multifactor authentication solutions.
Checks: C-24198r493492_chk

Review the application documentation and interview the application administrator to identify application access methods. If the application is not PK-enabled due to the hosted data being publicly releasable, this check is not applicable. Ask the application administrator to log on to the application. Have the application admin use their non-privileged credentials. Validate the application prompts the user to provide a certificate from the CAC. Validate the application requests the user to input their CAC PIN. If the application allows access without requiring a CAC or Alt. Token, this is a finding.

Fix: F-24187r493493_fix

Configure the application to require CAC or Alt. Token authentication for non-privileged network access.

b
The application must ensure users are authenticated with an individual authenticator prior to using a group authenticator.
IA-2 - Medium - CCI-000770 - V-222529 - SV-222529r879594_rule
RMF Control
IA-2
Severity
Medium
CCI
CCI-000770
Version
APSC-DV-001610
Vuln IDs
  • V-222529
  • V-69541
Rule IDs
  • SV-222529r879594_rule
  • SV-84163
To assure individual accountability and prevent unauthorized access, application users must be individually identified and authenticated. Individual accountability mandates that each user is uniquely identified. A group authenticator is a shared account or some other form of authentication that allows multiple unique individuals to access the application using a single account. If an application allows or provides for group authenticators, it must first individually authenticate users prior to implementing group authenticator functionality. Some applications may not have the need to provide a group authenticator; this is considered a matter of application design. In those instances where the application design includes the use of a group authenticator, this requirement will apply. There may also be instances when specific user actions need to be performed on the information system without unique user identification or authentication. An example of this type of access is a web server which contains publicly releasable information.
Checks: C-24199r493495_chk

Review the application documentation, examine user accounts, group membership and interview the application administrator to identify group or shared accounts. Document the group or shared account information. If the application does not use group or shared accounts, this requirement is not applicable. Create a test account or use an existing group member account. Ensure the test account is not authenticated to the application and attempt to access the application with the group account credentials. If the application allows access without first requiring the group member to authenticate with their individual credentials, this is a finding.

Fix: F-24188r493496_fix

Design and configure the application to individually authenticate group account members prior to allowing access.

b
The application must implement replay-resistant authentication mechanisms for network access to privileged accounts.
IA-2 - Medium - CCI-001941 - V-222530 - SV-222530r879597_rule
RMF Control
IA-2
Severity
Medium
CCI
CCI-001941
Version
APSC-DV-001620
Vuln IDs
  • V-222530
  • V-69543
Rule IDs
  • SV-222530r879597_rule
  • SV-84165
A replay attack may enable an unauthorized user to gain access to the application. Authentication sessions between the authenticator and the application validating the user credentials must not be vulnerable to a replay attack. An authentication process resists replay attacks if it is impractical to achieve a successful authentication by recording and replaying a previous authentication message. A privileged account is any information system account with authorizations of a privileged user. Techniques used to address this include protocols using nonces (e.g., numbers generated for a specific one time use) or challenges (e.g., TLS, WS_Security). Additional techniques include time-synchronous or challenge-response one-time authenticators.
Checks: C-36245r602300_chk

Review application documentation and interview application administrator to identify what authentication mechanisms are used when accessing the application. If the application is hosting publicly releasable information that does not require authentication, or if the application users are not eligible for a DoD CAC as per DoD 8520, this requirement is not applicable. Review to ensure the application is utilizing TLSV1.2 or greater to protect communication and privileged user authentication traffic. Verify the application utilizes a strong authentication mechanism such as Kerberos, IPSEC, or Secure Shell (SSH). - Cryptographically sign web services packets. - Time stamps and cryptographic hashes are used with web services packets. - Use WS_Security for web services. Request the most recent vulnerability scan results and configuration settings. Verify the configuration is set to test for known replay vulnerabilities. Request code review results (if available) and review for issues that have been identified as potential replay attack vulnerabilities. Verify identified issues have been remediated. If the application is not implementing replay-resistant authentication methods applicable to the application architecture, this is a finding.

Fix: F-24189r493499_fix

Design and configure the application to utilize replay-resistant mechanisms when authenticating privileged accounts.

b
The application must implement replay-resistant authentication mechanisms for network access to non-privileged accounts.
IA-2 - Medium - CCI-001942 - V-222531 - SV-222531r879598_rule
RMF Control
IA-2
Severity
Medium
CCI
CCI-001942
Version
APSC-DV-001630
Vuln IDs
  • V-222531
  • V-69545
Rule IDs
  • SV-222531r879598_rule
  • SV-84167
A replay attack is a man-in-the-middle style attack which allows an attacker to repeat or alter a valid data transmission that may enable unauthorized access to the application. Authentication sessions between the authenticating client and the application server validating the user credentials must not be vulnerable to a replay attack. The protection methods selected to protect against a replay attack will vary according to the application architecture. An authentication process resists replay attacks if it is impractical to achieve a successful authentication by recording and replaying a previous authentication message. A non-privileged account is any operating system account with authorizations of a non-privileged user. Techniques used to address this include protocols using nonces (e.g., numbers generated for a specific one time use) or challenges (e.g., TLS, WS_Security) and PKI certificates. Additional techniques include time-synchronous or challenge-response one-time authenticators.
Checks: C-36246r602302_chk

Review the application documentation and interview the application administrator to identify what authentication mechanisms are used when accessing the application. If the application is hosting publicly releasable information that does not require authentication, or if the application users are not eligible for a DoD CAC as per DoD 8520, this requirement is not applicable. Review to ensure the application is utilizing TLSV1.2 or greater to protect communication and non-privileged user authentication traffic. Verify the application utilizes a strong authentication mechanism such as Kerberos, IPSEC, or Secure Shell (SSH). - Cryptographically sign web services packets. - Time stamps and cryptographic hashes are used with web services packets. - Use WS_Security for web services. Request the most recent vulnerability scan results and configuration settings. Verify the configuration is set to test for known replay vulnerabilities. Request code review results (if available) and review for issues that have been identified as potential replay attack vulnerabilities. Verify identified issues have been remediated. If the application is not implementing replay-resistant authentication methods applicable to the application architecture, this is a finding.

Fix: F-24190r493502_fix

Design and configure the application to utilize replay-resistant mechanisms when authenticating non-privileged accounts.

b
The application must utilize mutual authentication when endpoint device non-repudiation protections are required by DoD policy or by the data owner.
IA-3 - Medium - CCI-000778 - V-222532 - SV-222532r879599_rule
RMF Control
IA-3
Severity
Medium
CCI
CCI-000778
Version
APSC-DV-001640
Vuln IDs
  • V-222532
  • V-69547
Rule IDs
  • SV-222532r879599_rule
  • SV-84169
Without identifying devices, unidentified or unknown devices may be introduced, thereby facilitating malicious activity. With one way SSL authentication which is the typical form of SSL authentication done between a web browser client and a web server, the client requests the server certificate to validate the server's identity and establish a secure connection. When SSL mutual authentication is used, the server is configured to request the client’s certificate as well so the server can also identify the client. For distributed architectures (e.g., service-oriented architectures), the decisions regarding the validation of identification claims may be made by services separate from the services acting on those decisions. In such situations, it is necessary to provide the identification decisions (as opposed to the actual identifiers) to the services that need to act on those decisions. This requirement applies to applications that connect either locally, remotely, or through a network to an endpoint device (including but not limited to: workstations, printers, servers (outside a datacenter), VoIP Phones, VTC CODECs). Gateways and SOA applications are examples of where this requirement would apply.
Checks: C-24202r493504_chk

Review the application documentation and interview the application administrator. Determine if mutual authentication is mandated by the data owner or by mission data protection objectives and data type. Review application architecture and design documents. Identify endpoint devices that interact with the application. These can be SOA gateways, VOIP phones, or other devices that are used to connect to and exchange data with the application. If the design documentation specifies, this could potentially also include remote client workstations. In order for two way SSL/mutual authentication to work properly, the server must be configured to request client certificates. Access the applications management console. Navigate to the SSL management utility or web page that is used to configure two way mutual authentication. Verify endpoints are configured for client authentication (mutual authentication). Some application architectures such as Java configure their settings in text/xml formatted files; in that case, have the application administrator identify the configuration files used by the application. E.g., web.xml stored in WEB-INF/ sub directory of the application root folder. Open the web.xml file using a text editor. Verify the application deployment descriptor for the application and the resource requiring protection under the "login-config" element is set to CLIENT-CERT. If SSL mutual authentication is required and is not being utilized, this is a finding.

Fix: F-24191r493505_fix

Configure the application to utilize mutual authentication when specified by data protection requirements.

b
The application must authenticate all network connected endpoint devices before establishing any connection.
IA-3 - Medium - CCI-001958 - V-222533 - SV-222533r879767_rule
RMF Control
IA-3
Severity
Medium
CCI
CCI-001958
Version
APSC-DV-001650
Vuln IDs
  • V-222533
  • V-69549
Rule IDs
  • SV-222533r879767_rule
  • SV-84171
Without authenticating devices, unidentified or unknown devices may be introduced, thereby facilitating malicious activity. For distributed architectures (e.g., service-oriented architectures), the decisions regarding the validation of authentication claims may be made by services separate from the services acting on those decisions. In such situations, it is necessary to provide authentication decisions (as opposed to the actual authenticators) to the services that need to act on those decisions. This requirement applies to applications that connect either locally, remotely, or through a network to an endpoint device (including but not limited to: workstations, printers, servers (outside a datacenter), VoIP Phones, VTC CODECs). Gateways and SOA applications are examples of where this requirement would apply. End point devices are not: Client desktop workstations only offer browser-based web application access where the user authenticates at the app layer. Device authentication is a solution enabling an organization to manage devices. It is an additional layer of authentication ensuring only specific pre-authorized devices can access the system.
Checks: C-24203r493507_chk

Review the application documentation, implementation documentation and interview the application administrator. Identify if the application utilizes Web Services/Service-Oriented Architecture (SOA). Using the web services framework that has been implemented, have the application administrator identify the remote devices allowed to communicate to the service provider. If the application is designed to provide end-user, interactive application access only and does not use web services or allow connections from remote devices, this requirement is not applicable. Identify the authentication mechanism used to authenticate the remote consumers/devices. Commonly available authentication methods are Client Certificate Authentication and Basic Authentication. The Basic Authentication method provides insufficient protection for authentication sessions and is not allowed. If no authentication mechanism is used to authenticate remote service consumers/devices, or if Basic Authentication is used to authentication remote service consumers/devices, this is a finding.

Fix: F-24192r493508_fix

Configure the application to authenticate all network connected endpoint devices/service consumers before establishing connections.

b
Service-Oriented Applications handling non-releasable data must authenticate endpoint devices via mutual SSL/TLS.
IA-3 - Medium - CCI-001967 - V-222534 - SV-222534r879768_rule
RMF Control
IA-3
Severity
Medium
CCI
CCI-001967
Version
APSC-DV-001660
Vuln IDs
  • V-222534
  • V-69551
Rule IDs
  • SV-222534r879768_rule
  • SV-84173
Without identifying devices, unidentified or unknown devices may be introduced, thereby facilitating malicious activity. One way SSL/TLS authentication is the typical form of authentication done between a web browser client and a web server. The client requests the server certificate to validate the server's identity and establish a secure connection. When SSL/TLS mutual authentication is used, the server is configured to request the client’s certificate as well so the server can also identify the client. This form of authentication is normally chosen for system to system communications that leverage HTTP as the transport. It should be noted that SSL is being deprecated and replaced with TLS. For distributed architectures (e.g., service-oriented architectures), the decisions regarding the validation of identification claims may be made by services separate from the services acting on those decisions. In such situations, it is necessary to provide the identification decisions (as opposed to the actual identifiers) to the services that need to act on those decisions. This requirement applies to applications that connect either locally, remotely, or through a network to an endpoint device (including but not limited to: workstations, printers, servers (outside a datacenter), VoIP Phones, VTC CODECs). Gateways and SOA applications are examples of where this requirement would apply.
Checks: C-24204r493510_chk

Review application documentation and interview application administrator. Identify application data elements and determine if the application is handling/processing non-releasable data. Review the application architecture and design documents. Identify endpoint devices that interact with the application. These can be SOA gateways, VOIP phones, or other devices that are used to connect to and exchange data with the application. If the design documentation specifies it, this could also include remote client workstations. However, this requirement is usually reserved for system-oriented endpoints rather than client workstations. In order for two way SSL/TLS mutual authentication to work properly, the server must be configured to request client certificates. Access the applications management console and navigate to the SSL/TLS management utility or web page that is used to configure two-way mutual authentication. Verify endpoints are configured for client authentication (mutual authentication). Some application architectures configure their settings in text/xml formatted files; in that case, have the application administrator identify the configuration files used by the application (e.g., web.xml stored in WEB-INF/ sub directory of the application root folder). Open the web.xml file using a text editor and verify the application deployment descriptor for the application and the resource requiring protection under the "login-config" element is set to CLIENT-CERT. If SSL/TLS mutual authentication is required due to the application processing non-releasable data and SSL/TLS mutual authentication not being utilized, this is a finding.

Fix: F-24193r493511_fix

Configure the application to utilize mutual authentication when the application is processing non-releasable data.

b
The application must disable device identifiers after 35 days of inactivity unless a cryptographic certificate is used for authentication.
IA-4 - Medium - CCI-000795 - V-222535 - SV-222535r879600_rule
RMF Control
IA-4
Severity
Medium
CCI
CCI-000795
Version
APSC-DV-001670
Vuln IDs
  • V-222535
  • V-69553
Rule IDs
  • SV-222535r879600_rule
  • SV-84175
Device identifiers are used to identify hardware devices that interact with the application much like a user account is used to identify an application user. Examples of hardware devices include but are not limited to mobile phones, application gateways or other types of smart hardware. This requirement does not apply to individual application user accounts. This requirement is not applicable to shared information system accounts, application groups, roles (e.g., guest and anonymous accounts) that are used by the application itself in order to function. Care must be taken to not disable identifiers that are used by the application in order to function. Inactive device identifiers pose a risk to systems and applications. Attackers that are able to exploit an inactive identifier can potentially obtain and maintain undetected access to the application. Applications need to track periods of device inactivity and disable the device identifier after 35 days of inactivity. This is usually accomplished by disabling the account used by the device to access the application. Applications that utilize cryptographic certificates for device authentication may use the expiration date assigned to the certificate to meet this requirement with the understanding that the certificate is created and managed in accordance with DoD PKI policy and can be revoked by a trusted CA. To avoid having to build complex device management capabilities directly into their application, developers should leverage the underlying OS or other account management infrastructure (AD, LDAP) that is already in place within the organization and meets organizational user account management requirements. Applications are encouraged to utilize a centralized data store such as Active Directory or LDAP to offload device management requirements and ensure compliance with policy requirements.
Checks: C-24205r493513_chk

Review the application documentation and interview the application administrator. If the application is not designed to authenticate devices (such as mobile phones, gateways or other smart devices), or uses DoD PKI certificates to authenticate these devices, this requirement is NA. Access the user management interface for the application. Identify application device IDs. If the application utilizes approved certificates or a centralized authentication store (Active Directory or LDAP) as the authoritative source for application authentication, and the authentication store is configured to meet the requirement to disable device IDs after 35 days of inactivity, this is not a finding. Accounts such as guest and anonymous as well as roles and groups or other identities used to operate the application or to provide limited guest access are not applicable. Access the application user management interface and review the account settings that pertain to devices. Verify the application is configured to disable device accounts that have not been active or logged into the application for the past 35 days. If the application does not disable accounts used to authenticate devices after 35 days of inactivity, this is a finding.

Fix: F-24194r493514_fix

Configure the application to disable device accounts after 35 days of inactivity or to utilize DoD PKI certificates that provide an expiration date.

c
The application must enforce a minimum 15-character password length.
IA-5 - High - CCI-000205 - V-222536 - SV-222536r879601_rule
RMF Control
IA-5
Severity
High
CCI
CCI-000205
Version
APSC-DV-001680
Vuln IDs
  • V-222536
  • V-69555
Rule IDs
  • SV-222536r879601_rule
  • SV-84177
The shorter the password, the lower the number of possible combinations that need to be tested before the password is compromised. Use of passwords for application authentication is intended only for limited situations and should not be used as a replacement for two-factor CAC-enabled authentication. Examples of situations where a user ID and password might be used include but are not limited to: - When the application user base does not have a CAC and is not a current DoD employee, member of the military, or a DoD contractor. - When an application user has been officially designated as a Temporary Exception User; one who is temporarily unable to present a CAC for some reason (lost, damaged, not yet issued, broken card reader) and to satisfy urgent organizational needs must be temporarily permitted to use user ID/password authentication until the problem with CAC use has been remedied. and - When the application is publicly available and or hosting publicly releasable data requiring some degree of need-to-know protection. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. Password length is one factor of several that helps to determine strength and how long it takes to crack a password. The shorter the password, the lower the number of possible combinations that need to be tested before the password is compromised. Use of more characters in a password helps to exponentially increase the time and/or resources required to compromise the password.
Checks: C-24206r493516_chk

Review the application documentation and interview the application administrator to identify if the application uses passwords for user authentication. If the application does not use passwords, the requirement is not applicable. Access the application management interface and create a test user account or logon to the system with a test account and access the functionality that provides password change capabilities. When prompted to provide the password, attempt to create a password shorter than 15 characters in length. If a password shorter than 15 characters can be created, this is a finding.

Fix: F-24195r493517_fix

Configure the application to require 15 characters in the password.

b
The application must enforce password complexity by requiring that at least one upper-case character be used.
IA-5 - Medium - CCI-000192 - V-222537 - SV-222537r879603_rule
RMF Control
IA-5
Severity
Medium
CCI
CCI-000192
Version
APSC-DV-001690
Vuln IDs
  • V-222537
  • V-69557
Rule IDs
  • SV-222537r879603_rule
  • SV-84179
Use of passwords for application authentication is intended only for limited situations and should not be used as a replacement for two-factor CAC-enabled authentication. Examples of situations where a user ID and password might be used include but are not limited to: - When the application user base does not have a CAC and is not a current DoD employee, member of the military, or a DoD contractor. - When an application user has been officially designated as a Temporary Exception User; one who is temporarily unable to present a CAC for some reason (lost, damaged, not yet issued, broken card reader) and to satisfy urgent organizational needs must be temporarily permitted to use user ID/password authentication until the problem with CAC use has been remedied. and - When the application is publicly available and or hosting publicly releasable data requiring some degree of need-to-know protection. Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. Password complexity is one factor of several that determine how long it takes to crack a password. The more complex the password is, the greater the number of possible combinations that need to be tested before the password is compromised.
Checks: C-24207r493519_chk

Review the application documentation and interview the application administrator to identify if the application uses passwords for user authentication. If the application does not use passwords, the requirement is not applicable. Access the application management interface and create a test user account or logon to the system with a test account and access the functionality that provides password change capabilities. When prompted to provide the password, attempt to create a password that does not have one upper-case character. If a password without at least one upper-case character can be created, this is a finding.

Fix: F-24196r493520_fix

Configure the application to require at least one upper-case character in the password.

b
The application must enforce password complexity by requiring that at least one lower-case character be used.
IA-5 - Medium - CCI-000193 - V-222538 - SV-222538r879604_rule
RMF Control
IA-5
Severity
Medium
CCI
CCI-000193
Version
APSC-DV-001700
Vuln IDs
  • V-222538
  • V-69559
Rule IDs
  • SV-222538r879604_rule
  • SV-84181
Use of passwords for application authentication is intended only for limited situations and should not be used as a replacement for two-factor CAC-enabled authentication. Examples of situations where a user ID and password might be used include but are not limited to: - When the application user base does not have a CAC and is not a current DoD employee, member of the military, or a DoD contractor. - When an application user has been officially designated as a Temporary Exception User; one who is temporarily unable to present a CAC for some reason (lost, damaged, not yet issued, broken card reader) and to satisfy urgent organizational needs must be temporarily permitted to use user ID/password authentication until the problem with CAC use has been remedied. and - When the application is publicly available and or hosting publicly releasable data requiring some degree of need-to-know protection. Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. Password complexity is one factor of several that determine how long it takes to crack a password. The more complex the password, the greater the number of possible combinations that need to be tested before the password is compromised.
Checks: C-24208r493522_chk

Review the application documentation and interview the application administrator to identify if the application uses passwords for user authentication. If the application does not use passwords, the requirement is not applicable. Access the application management interface and create a test user account or logon to the system with a test account and access the functionality that provides password change capabilities. When prompted to provide the password, attempt to create a password that does not have one lower-case character. If a password without at least one lower-case character can be created, this is a finding.

Fix: F-24197r493523_fix

Configure the application to require at least one lower-case character in the password.

b
The application must enforce password complexity by requiring that at least one numeric character be used.
IA-5 - Medium - CCI-000194 - V-222539 - SV-222539r879605_rule
RMF Control
IA-5
Severity
Medium
CCI
CCI-000194
Version
APSC-DV-001710
Vuln IDs
  • V-222539
  • V-69561
Rule IDs
  • SV-222539r879605_rule
  • SV-84183
Use of passwords for application authentication is intended only for limited situations and should not be used as a replacement for two-factor CAC-enabled authentication. Examples of situations where a user ID and password might be used include but are not limited to: - When the application user base does not have a CAC and is not a current DoD employee, member of the military, or a DoD contractor. - When an application user has been officially designated as a Temporary Exception User; one who is temporarily unable to present a CAC for some reason (lost, damaged, not yet issued, broken card reader) and to satisfy urgent organizational needs must be temporarily permitted to use user ID/password authentication until the problem with CAC use has been remedied. and - When the application is publicly available and or hosting publicly releasable data requiring some degree of need-to-know protection. Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. Password complexity is one factor of several that determine how long it takes to crack a password. The more complex the password, the greater the number of possible combinations that need to be tested before the password is compromised.
Checks: C-24209r493525_chk

Review the application documentation and interview the application administrator to identify if the application uses passwords for user authentication. If the application does not use passwords, the requirement is not applicable. Access the application management interface and create a test user account or logon to the system with a test account and access the functionality that provides password change capabilities. When prompted to provide the password, attempt to create a password that does not have one numeric character. If a password without at least one numeric character can be created, this is a finding.

Fix: F-24198r493526_fix

Configure the application to require at least one numeric character in the password.

b
The application must enforce password complexity by requiring that at least one special character be used.
IA-5 - Medium - CCI-001619 - V-222540 - SV-222540r879606_rule
RMF Control
IA-5
Severity
Medium
CCI
CCI-001619
Version
APSC-DV-001720
Vuln IDs
  • V-222540
  • V-69563
Rule IDs
  • SV-222540r879606_rule
  • SV-84185
Use of passwords for application authentication is intended only for limited situations and should not be used as a replacement for two-factor CAC-enabled authentication. Examples of situations where a user ID and password might be used include but are not limited to: - When the application user base does not have a CAC and is not a current DoD employee, member of the military, or a DoD contractor. - When an application user has been officially designated as a Temporary Exception User; one who is temporarily unable to present a CAC for some reason (lost, damaged, not yet issued, broken card reader) and to satisfy urgent organizational needs must be temporarily permitted to use user ID/password authentication until the problem with CAC use has been remedied. and - When the application is publicly available and or hosting publicly releasable data requiring some degree of need-to-know protection. Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. Password complexity is one factor of several that determine how long it takes to crack a password. The more complex the password, the greater the number of possible combinations that need to be tested before the password is compromised.
Checks: C-24210r493528_chk

Review the application documentation and interview the application administrator to identify if the application uses passwords for user authentication. If the application does not use passwords, the requirement is not applicable. Access the application management interface and create a test user account or logon to the system with a test account and access the functionality that provides password change capabilities. When prompted to provide the password, attempt to create a password that does not have one special character. If a password without at least one special character can be created, this is a finding.

Fix: F-24199r493529_fix

Configure the application to require at least one special character in the password.

b
The application must require the change of at least 8 of the total number of characters when passwords are changed.
IA-5 - Medium - CCI-000195 - V-222541 - SV-222541r879607_rule
RMF Control
IA-5
Severity
Medium
CCI
CCI-000195
Version
APSC-DV-001730
Vuln IDs
  • V-222541
  • V-69565
Rule IDs
  • SV-222541r879607_rule
  • SV-84187
Use of passwords for application authentication is intended only for limited situations and should not be used as a replacement for two-factor CAC-enabled authentication. Examples of situations where a user ID and password might be used include but are not limited to: - When the application user base does not have a CAC and is not a current DoD employee, member of the military, or a DoD contractor. - When an application user has been officially designated as a Temporary Exception User; one who is temporarily unable to present a CAC for some reason (lost, damaged, not yet issued, broken card reader) and to satisfy urgent organizational needs must be temporarily permitted to use user ID/password authentication until the problem with CAC use has been remedied. and - When the application is publicly available and or hosting publicly releasable data requiring some degree of need-to-know protection. Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. Password complexity is one factor of several that determine how long it takes to crack a password. The more complex the password, the greater the number of possible combinations that need to be tested before the password is compromised.
Checks: C-24211r493531_chk

Review the application documentation and interview the application administrator to identify if the application uses passwords for user authentication. If the application does not use passwords, the requirement is not applicable. Access the application management interface and create a test user account or logon to the system with a test account and access the functionality that provides password change capabilities. When prompted to provide the password, attempt to change less than 8 characters of the total number of characters in the password. If less than 8 characters of the password are changed, this is a finding.

Fix: F-24200r493532_fix

Configure the application to require the change of at least 8 characters in the password when passwords are changed.

c
The application must only store cryptographic representations of passwords.
IA-5 - High - CCI-000196 - V-222542 - SV-222542r879608_rule
RMF Control
IA-5
Severity
High
CCI
CCI-000196
Version
APSC-DV-001740
Vuln IDs
  • V-222542
  • V-69567
Rule IDs
  • SV-222542r879608_rule
  • SV-84189
Use of passwords for application authentication is intended only for limited situations and should not be used as a replacement for two-factor CAC-enabled authentication. Examples of situations where a user ID and password might be used include but are not limited to: - When the application user base does not have a CAC and is not a current DoD employee, member of the military, or a DoD contractor. - When an application user has been officially designated as a Temporary Exception User; one who is temporarily unable to present a CAC for some reason (lost, damaged, not yet issued, broken card reader) and to satisfy urgent organizational needs must be temporarily permitted to use user ID/password authentication until the problem with CAC use has been remedied. and - When the application is publicly available and or hosting publicly releasable data requiring some degree of need-to-know protection. Passwords need to be protected at all times and using a strong one-way hashing encryption algorithm with a salt is the standard method for providing a means to validate a user's password without having to store the actual password. Performance and time required to access are factors that must be considered and the one way hash is the most feasible means of securing the password and providing an acceptable measure of password security. If passwords are stored in clear text, they can be plainly read and easily compromised. In many instances, verifying the user knows a password is performed using a password verifier. In its simplest form, a password verifier is a computational function that is capable of creating a hash of a password and determining if the value provided by the user matches the hash. A more secure version of verifying a user knowing a password is to store the result of an iterating hash function and a large random SALT value as follows: H0 = H(pwd, H(salt)) Hn = H(Hn-1,H(salt)) Where n is a cryptographically-strong random [*3] number. Hn is stored, along with the salt. When the application wishes to verify that the user knows a password, it simply repeats the process and compares Hn with the stored Hn. A SALT is essentially a fixed-length cryptographically-strong random value. Another method used is utilizing a keyed hash message authentication code (HMAC). HMAC calculates a message authentication code via a cryptographic hash function used in conjunction with an encryption key. The key must be protected as with any private key. Applications must only store passwords that have been cryptographically protected.
Checks: C-24212r493534_chk

Review the application documentation and interview the application administrator to identify if the application uses passwords for user authentication. If the application does not use passwords, the requirement is not applicable. Have the application administrator identify the application's password storage locations. Potential locations include the local file system where the application is stored or in an application-related database table that should not be accessible to application users. Review application files and folders using a text editor or by using a database tool that allows you to view data stored in database tables. Look for indications of stored user information and review that information. Determine if password strings are readable/discernable. Determine if the application uses the MD5 hashing algorithm to create password hashes. If the passwords are readable or there is no indication the application utilizes cryptographic hashing to protect passwords, or if the MD5 hash algorithm is used to create password hashes, this is a finding.

Fix: F-24201r493535_fix

Use strong cryptographic hash functions when creating password hash values. Utilize random salt values when creating the password hash. Ensure strong access control permissions on data files containing authentication data.

c
The application must transmit only cryptographically-protected passwords.
IA-5 - High - CCI-000197 - V-222543 - SV-222543r879609_rule
RMF Control
IA-5
Severity
High
CCI
CCI-000197
Version
APSC-DV-001750
Vuln IDs
  • V-222543
  • V-69569
Rule IDs
  • SV-222543r879609_rule
  • SV-84191
Use of passwords for application authentication is intended only for limited situations and should not be used as a replacement for two-factor CAC-enabled authentication. Examples of situations where a user ID and password might be used include but are not limited to: - When the application user base does not have a CAC and is not a current DoD employee, member of the military, or a DoD contractor. - When an application user has been officially designated as a Temporary Exception User; one who is temporarily unable to present a CAC for some reason (lost, damaged, not yet issued, broken card reader) and to satisfy urgent organizational needs must be temporarily permitted to use user ID/password authentication until the problem with CAC use has been remedied. and - When the application is publicly available and or hosting publicly releasable data requiring some degree of need-to-know protection. Passwords need to be protected at all times and encryption is the standard method for protecting passwords. If passwords are not encrypted, they can be plainly read (i.e., clear text) and easily compromised. Applications can accomplish this by making direct function calls to encryption modules or by leveraging operating system encryption capabilities.
Checks: C-24213r493537_chk

Review the application documentation and interview the application administrator to identify if the application uses passwords for user authentication. If the application does not use passwords, the requirement is not applicable. Identify when the application transmits passwords. This will most likely be when the user authenticates to the application or when the application authenticates to another resource. Access the application management interface with a test account and access the functionality that requires a password be provided. If the interface is via a web browser, verify the web browser has gone secure prior to entering any password or authentication information. This can be done by viewing the browser and observing a “lock” icon displayed somewhere in the browser as well as an https:// to indicate an SSL connection. Most browsers display this in the upper left hand corner. If the application is transmitting the password rather than the user, obtain design documentation from the application admin that provides the details on how they are protecting the password during transmission. This will usually be via a TLS/SSL tunneled connection or VPN. If the passwords are not encrypted when being transmitted, this is a finding.

Fix: F-24202r493538_fix

Configure the application to encrypt passwords when they are being transmitted.

b
The application must enforce 24 hours/1 day as the minimum password lifetime.
IA-5 - Medium - CCI-000198 - V-222544 - SV-222544r879610_rule
RMF Control
IA-5
Severity
Medium
CCI
CCI-000198
Version
APSC-DV-001760
Vuln IDs
  • V-222544
  • V-69571
Rule IDs
  • SV-222544r879610_rule
  • SV-84193
Use of passwords for application authentication is intended only for limited situations and should not be used as a replacement for two-factor CAC-enabled authentication. Examples of situations where a user ID and password might be used include but are not limited to: - When the application user base does not have a CAC and is not a current DoD employee, member of the military, or a DoD contractor. - When an application user has been officially designated as a Temporary Exception User; one who is temporarily unable to present a CAC for some reason (lost, damaged, not yet issued, broken card reader) and to satisfy urgent organizational needs must be temporarily permitted to use user ID/password authentication until the problem with CAC use has been remedied. and - When the application is publicly available and or hosting publicly releasable data requiring some degree of need-to-know protection. Enforcing a minimum password lifetime helps prevent repeated password changes to defeat the password reuse or history enforcement requirement. Restricting this setting limits the user's ability to change their password. Passwords need to be changed at specific policy-based intervals; however, if the application allows the user to immediately and continually change their password, then the password could be repeatedly changed in a short period of time to defeat the organization's policy regarding password reuse.
Checks: C-24214r493540_chk

Review the application documentation and interview the application administrator to identify if the application uses passwords for user authentication. If the application does not use passwords, the requirement is not applicable. Access the application management interface and create a test user account or logon to the system with a test account and access the functionality that provides password change capabilities. Attempt to change the password more than once. If a password can be changed more than once within 24 hours, the minimum lifetime setting is not set and this is a finding.

Fix: F-24203r493541_fix

Configure the application to have a minimum password lifetime of 24 hours.

b
The application must enforce a 60-day maximum password lifetime restriction.
IA-5 - Medium - CCI-000199 - V-222545 - SV-222545r879611_rule
RMF Control
IA-5
Severity
Medium
CCI
CCI-000199
Version
APSC-DV-001770
Vuln IDs
  • V-222545
  • V-69573
Rule IDs
  • SV-222545r879611_rule
  • SV-84195
Use of passwords for application authentication is intended only for limited situations and should not be used as a replacement for two-factor CAC-enabled authentication. Examples of situations where a user ID and password might be used include but are not limited to: - When the application user base does not have a CAC and is not a current DoD employee, member of the military, or a DoD contractor. - When an application user has been officially designated as a Temporary Exception User; one who is temporarily unable to present a CAC for some reason (lost, damaged, not yet issued, broken card reader) and to satisfy urgent organizational needs must be temporarily permitted to use user ID/password authentication until the problem with CAC use has been remedied. and - When the application is publicly available and or hosting publicly releasable data requiring some degree of need-to-know protection. Any password, no matter how complex, can eventually be cracked. Therefore, passwords need to be changed at specific intervals. One method of minimizing this risk is to use complex passwords and periodically change them. If the application does not limit the lifetime of passwords and force users to change their passwords, there is the risk that the system and/or application passwords could be compromised. This requirement does not include emergency administration accounts which are meant for access to the application in case of failure. These accounts are not required to have maximum password lifetime restrictions.
Checks: C-24215r493543_chk

Review the application documentation and interview the application administrator to identify if the application uses passwords for user authentication. If the application does not use passwords, the requirement is not applicable. Access the application management interface and view the user password settings page. Review user password settings and validate the application is configured to expire and force a password change after 60 days. If user passwords are not configured to expire after 60 days, or if the application does not have the ability to control this setting, this is a finding.

Fix: F-24204r493544_fix

Configure the application to have a maximum password lifetime of 60 days.

b
The application must prohibit password reuse for a minimum of five generations.
IA-5 - Medium - CCI-000200 - V-222546 - SV-222546r879602_rule
RMF Control
IA-5
Severity
Medium
CCI
CCI-000200
Version
APSC-DV-001780
Vuln IDs
  • V-222546
  • V-69575
Rule IDs
  • SV-222546r879602_rule
  • SV-84197
Use of passwords for application authentication is intended only for limited situations and should not be used as a replacement for two-factor CAC-enabled authentication. Examples of situations where a user ID and password might be used include but are not limited to: - When the application user base does not have a CAC and is not a current DoD employee, member of the military, or a DoD contractor. - When an application user has been officially designated as a Temporary Exception User; one who is temporarily unable to present a CAC for some reason (lost, damaged, not yet issued, broken card reader) and to satisfy urgent organizational needs must be temporarily permitted to use user ID/password authentication until the problem with CAC use has been remedied. and - When the application is publicly available and or hosting publicly releasable data requiring some degree of need-to-know protection. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. To meet password policy requirements, passwords need to be changed at specific policy-based intervals. If the information system or application allows the user to consecutively reuse their password when that password has exceeded its defined lifetime, the end result is a password that is not changed as per policy requirements.
Checks: C-24216r493546_chk

Review the application documentation and interview the application administrator to identify if the application uses passwords for user authentication. If the application does not use passwords, the requirement is not applicable. Access the application management interface and view the user password settings page. Review user password settings and validate the application is configured to prohibit password reuse for a minimum of 5 password generations. If the application does not prevent users from reusing their previous 5 passwords, or if the application does not have the ability to control this setting, this is a finding.

Fix: F-24205r493547_fix

Configure the application to prohibit password reuse for up to 5 passwords.

b
The application must allow the use of a temporary password for system logons with an immediate change to a permanent password.
IA-5 - Medium - CCI-002041 - V-222547 - SV-222547r879770_rule
RMF Control
IA-5
Severity
Medium
CCI
CCI-002041
Version
APSC-DV-001790
Vuln IDs
  • V-222547
  • V-69577
Rule IDs
  • SV-222547r879770_rule
  • SV-84199
Use of passwords for application authentication is intended only for limited situations and should not be used as a replacement for two-factor CAC-enabled authentication. Examples of situations where a user ID and password might be used include but are not limited to: - When the application user base does not have a CAC and is not a current DoD employee, member of the military, or a DoD contractor. - When an application user has been officially designated as a Temporary Exception User; one who is temporarily unable to present a CAC for some reason (lost, damaged, not yet issued, broken card reader) and to satisfy urgent organizational needs must be temporarily permitted to use user ID/password authentication until the problem with CAC use has been remedied. and - When the application is publicly available and or hosting publicly releasable data requiring some degree of need-to-know protection. Without providing this capability, an account may be created without a password. Non-repudiation cannot be guaranteed once an account is created if a user is not forced to change the temporary password upon initial logon. Temporary passwords are typically used to allow access to applications when new accounts are created or passwords are changed. It is common practice for administrators to create temporary passwords for user accounts which allow the users to log on, yet force them to change the password once they have successfully authenticated.
Checks: C-24217r493549_chk

Review the application documentation and interview the application administrator to identify if the application uses passwords for user authentication. If the application does not use passwords, the requirement is not applicable. Access the application management interface and view the user password settings page. Review user password settings and validate the application is configured to specify when a password is temporary and force a password change when the administrator either creates a new user account or changes a user’s password. If the application can not specify a password as temporary and force the user to change the temporary password upon successful authentication, this is a finding.

Fix: F-24206r493550_fix

Configure the application to specify when a password is temporary and change the temporary password on the first use.

b
The application password must not be changeable by users other than the administrator or the user with which the password is associated.
IA-5 - Medium - CCI-000184 - V-222548 - SV-222548r879887_rule
RMF Control
IA-5
Severity
Medium
CCI
CCI-000184
Version
APSC-DV-001795
Vuln IDs
  • V-222548
  • V-70145
Rule IDs
  • SV-222548r879887_rule
  • SV-84767
If the application allows user A to change user B's password, user B can be locked out of the application, and user A is provided the ability to grant themselves access to the application as user B. This violates application integrity and availability principles. Many applications provide a password reset capability that allows the user to reset their password if they forget it. Protections must be utilized when establishing a password change or reset capability to prevent user A from changing user B's password. Protection is usually accomplished by having each user provide an out of bounds (OOB) communication address such as a separate email address or SMS/text address (mobile phone) that can be used to transmit password reset/change information. This OOB information is usually provided by the user when the user account is created. The OOB information is validated as part of the user account creation process by sending an account validation request to the OOB address and having the user respond to the request. Applications must prevent users other than the administrator or the user associated with the account from changing the account password.
Checks: C-36247r602304_chk

Review the application documentation and interview application administrator. Determine if the application utilizes passwords. If the application does not utilize passwords, the requirement is NA. Identify the processes, commands or web pages the application uses to allow application users to change their own passwords. This includes but is not limited to password resets. If the application does not allow users to change or reset their passwords, the requirement is NA. Obtain two application test accounts, referred to here as User A and User B. Access the application as User A. Utilize the application password reset or change processes and determine if User A is allowed to specify or otherwise force a password change for User B. If User A is allowed to change or force a reset of User B's password, this is a finding.

Fix: F-36211r865212_fix

Use a CAC to authenticate users instead of using passwords. If application users are prohibited or prevented from obtaining a CAC due to DoD policy requirements and passwords are the only viable option, design the application to utilize a secure password change or password reset process. Utilize out of band (OOB) communication techniques to communicate password change requests to users. Ensure verification processes exist that allow users to validate the change request prior to implementing the password change. Ensure users are only allowed to change their own passwords.

b
The application must terminate existing user sessions upon account deletion.
IA-5 - Medium - CCI-002007 - V-222549 - SV-222549r879773_rule
RMF Control
IA-5
Severity
Medium
CCI
CCI-002007
Version
APSC-DV-001800
Vuln IDs
  • V-222549
  • V-70147
Rule IDs
  • SV-222549r879773_rule
  • SV-84769
The application must ensure that a user does not retain any rights that may have been granted or retain access to the application after the user's authorization or role within the application has been deleted or modified. This means once a user's role/account within the application has been modified, deleted or disabled, the changes must be enforced immediately within the application. Any privileges or access the user had prior to the change must not be retained. For example; any application sessions that the user may have already established prior to the configuration change must be terminated when the user account changes occur. Simply removing a user from a web application without terminating any existing application user sessions can introduce a scenario where the deleted user still has access to the application even though their account has been deleted from the authentication store. This can be attributed to browser caching and session management on the web server. To address this, the web application must provide a means for ensuring this type of "zombie" access does not occur. Applications must provide a user management feature or function that will terminate any existing user sessions at the same time or just before the user account is terminated from the authoritative authentication source.
Checks: C-24219r493555_chk

Review the application documentation and interview the application administrator. Identify the user management functions of the application and create a test user account. Access the application and perform application functions as the test user. Access the user management functions and delete the test account while the test user sessions are still active. Verify the test user application sessions are terminated by attempting to perform additional application functions. If the test user retains access after the test account has been deleted, this is a finding.

Fix: F-24208r493556_fix

Configure the application to terminate existing sessions of users whose accounts are deleted.

c
The application, when utilizing PKI-based authentication, must validate certificates by constructing a certification path (which includes status information) to an accepted trust anchor.
IA-5 - High - CCI-000185 - V-222550 - SV-222550r879612_rule
RMF Control
IA-5
Severity
High
CCI
CCI-000185
Version
APSC-DV-001810
Vuln IDs
  • V-222550
  • V-70149
Rule IDs
  • SV-222550r879612_rule
  • SV-84771
Without path validation, an informed trust decision by the relying party cannot be made when presented with any certificate not already explicitly trusted. A trust anchor is an authoritative entity represented via a public key and associated data. It is used in the context of public key infrastructures, X.509 digital certificates, and DNSSEC. When there is a chain of trust, usually the top entity to be trusted becomes the trust anchor; it can be, for example, a Certification Authority (CA). A certification path starts with the subject certificate and proceeds through a number of intermediate certificates up to a trusted root certificate, typically issued by a trusted CA. This requirement verifies that a certification path to an accepted trust anchor is used for certificate validation and that the path includes status information. Path validation is necessary for a relying party to make an informed trust decision when presented with any certificate not already explicitly trusted. Status information for certification paths includes certificate revocation lists or online certificate status protocol responses. Validation of the certificate status information is out of scope for this requirement.
Checks: C-24220r493558_chk

Review the application documentation, the application architecture and interview the application administrator to identify the method employed by the application for validating certificates. Review the method to determine if a certification path that includes status information is constructed when certificate validation occurs. Some applications may utilize underlying OS certificate validation and certificate path building capabilities while others may build the capability into the application itself. The certification path will include the intermediary certificate CAs along with a status of the CA server's signing certificate and will end at the trusted root anchor. If the application does not construct a certificate path to an accepted trust anchor, this is a finding.

Fix: F-24209r493559_fix

Design the application to construct a certification path to an accepted trust anchor when using PKI-based authentication.

c
The application, when using PKI-based authentication, must enforce authorized access to the corresponding private key.
IA-5 - High - CCI-000186 - V-222551 - SV-222551r879613_rule
RMF Control
IA-5
Severity
High
CCI
CCI-000186
Version
APSC-DV-001820
Vuln IDs
  • V-222551
  • V-70151
Rule IDs
  • SV-222551r879613_rule
  • SV-84773
If the private key is discovered, an attacker can use the key to authenticate as an authorized user and gain access to the network infrastructure. The cornerstone of the PKI is the private key used to encrypt or digitally sign information. If the private key is stolen, this will lead to the compromise of the authentication and non-repudiation gained through PKI because the attacker can use the private key to digitally sign documents and pretend to be the authorized user. Both the holders of a digital certificate and the issuing authority must protect the computers, storage devices, or whatever they use to keep the private keys.
Checks: C-24221r493561_chk

Review the application documentation and interview the application administrator to identify where the application's private key is stored. If the application does not perform code signing or other cryptographic tasks requiring a private key, this requirement is not applicable. Ask the administrator to demonstrate where the application private key(s) are stored. Examine access restrictions and ensure access controls are in place to restrict access to the private key(s). If the key(s) are stored on the file system, ensure adequate file permissions are set so as to only allow authorized users and processes. If the key(s) are maintained or available via an application interface, ensure the application provides access controls that limit access via the application interface to only authorized users and processes. Review access controls and attempt to use a relevant user account, group or application role that is not allowed access to the private key. Verify access to the keys is denied. If unauthorized access is granted to the private key(s), this is a finding.

Fix: F-24210r493562_fix

Configure the application or relevant access control mechanism to enforce authorized access to the application private key(s).

b
The application must map the authenticated identity to the individual user or group account for PKI-based authentication.
IA-5 - Medium - CCI-000187 - V-222552 - SV-222552r879614_rule
RMF Control
IA-5
Severity
Medium
CCI
CCI-000187
Version
APSC-DV-001830
Vuln IDs
  • V-222552
  • V-70153
Rule IDs
  • SV-222552r879614_rule
  • SV-84775
Without mapping the certificate used to authenticate to a corresponding user account, the ability to determine the identity of the individual user or group will not be available for forensic analysis. Some CAs will include identifying information like an email address within the certificate itself. When the email is assigned to an individual, this helps to identify the individual user who has been assigned the certificate. When identifying information is not available within the certificate itself, the application must provide a mapping that allows administrators to quickly determine who the owner of the certificate is. When responding to a security incident, particularly involving user access violations, time is of the essence so this information must be readily available to investigators.
Checks: C-24222r493564_chk

Review the application documentation and interview the application administrator to identify how the application maps individual user certificates or group accounts to individual users. Access the application as a regular user while reviewing the application logs to determine if the application records the individual name of the user or if the application only includes certificate information. If the application only logs certificate information which contains no discernable user data, ask the system admin what their process is for mapping the certificate information to the user. If the application does not map the certificate data to an individual user or group, or if the administrator has no automated process established for determining the identity of the user, this is a finding.

Fix: F-24211r493565_fix

Configure the application to map certificate information to individual users or group accounts or create a process for automatically determining the individual user or group based on certificate information provided in the logs.

b
The application, for PKI-based authentication, must implement a local cache of revocation data to support path discovery and validation in case of the inability to access revocation information via the network.
IA-5 - Medium - CCI-001991 - V-222553 - SV-222553r879774_rule
RMF Control
IA-5
Severity
Medium
CCI
CCI-001991
Version
APSC-DV-001840
Vuln IDs
  • V-222553
  • V-70155
Rule IDs
  • SV-222553r879774_rule
  • SV-84777
A local cache of revocation data is also known as a CRL list. This list contains a list of revoked certificates and can be periodically downloaded to ensure certificates can still be checked for revocation when network access is not available or access to the Online Certificate Status Protocol OCSP server is not available. Without configuring a local cache of revocation data, there is the potential to allow access to users who are no longer authorized (users with revoked certificates).
Checks: C-24223r493567_chk

Review the application documentation and interview the system administrator to identify how the application checks certificate revocation. If the application resides on the SIPRNET and does not have access to the root CAs this requirement is not applicable. Different application frameworks may handle this requirement for the developer or the developer may have chosen to implement their own implementation for managing and implementing the CRL. Have the administrator demonstrate the process used for obtaining and importing the CRL. CAs may publish the CRL in an LDAP directory or it may be posted to an HTTP server. Verify the application is configured to import the CRL on a regular basis. Have the administrator demonstrate the configuration setting that enables CRL checking in the event the OCSP server is not available. If the application is not configured to implement a CRL, this is a finding.

Fix: F-24212r493568_fix

Implement a Certificate Revocation List (CRL) import process and configure the application to check the CRL if OCSP is not available.

c
The application must not display passwords/PINs as clear text.
IA-6 - High - CCI-000206 - V-222554 - SV-222554r879615_rule
RMF Control
IA-6
Severity
High
CCI
CCI-000206
Version
APSC-DV-001850
Vuln IDs
  • V-222554
  • V-70157
Rule IDs
  • SV-222554r879615_rule
  • SV-84779
To prevent the compromise of authentication information such as passwords during the authentication process, the feedback from the information system must not provide any information that would allow an unauthorized user to compromise the authentication mechanism. Obfuscation of user-provided information when typed into the system is a method used in addressing this risk. For example, displaying asterisks when a user types in a password is an example of obscuring feedback of authentication information. Another method is to display authentication feedback for a very limited time, usually in fractions of a second. This occurs during password character entry where the password characters are displayed for a very small window of time and then automatically obfuscated. This allows users with just enough time to confirm their password as they type it while limiting the ability of "shoulder surfers" to covertly witness the values. A common tactic employed to circumvent password obfuscation is to copy the obfuscated password and paste it to a text file. Proper obfuscation techniques will not paste the clear text password.