| AC-02 f |
Ensure an account management process is implemented, verifying only authorized users can gain access to the application, and individual accounts designated as inactive, suspended, or terminated are promptly removed. |
Establish an account management process. |
Heimdall Server provides a user management page where application administrators can deprovision user accounts based on organizational policy. |
|
9/9/2024 |
V-222619 |
| AC-02 (01) |
The application must provide automated mechanisms for supporting account management functions. |
Use automated processes and mechanisms for account management functions. |
Achieved by integrating your organization's existing external account and authentication mechanisms for user access. Local accounts should only be used for administration and troubleshooting. Local accounts must be managed using manual procedures per organizational requirements. |
|
9/9/2024 |
V-222407 |
| AC-02 (02) |
The application must automatically remove or disable temporary user accounts 72 hours after account creation. |
Configure temporary accounts to be automatically removed or disabled after 72 hours after account creation. |
Achieved by integrating your organization's existing external account and authentication mechanisms for user access. Local accounts should only be used for administration and troubleshooting. Local accounts must be managed using manual procedures per organizational requirements. |
|
9/9/2024 |
V-222409 |
| AC-02 (03) (d) |
The application must automatically disable accounts after a 35 day period of account inactivity. |
Design and configure the application to expire user accounts after 35 days of inactivity. |
Achieved by integrating your organization's existing external account and authentication mechanisms for user access. Local accounts should only be used for administration and troubleshooting. Local accounts must be managed using manual procedures per organizational requirements. |
|
9/9/2024 |
V-222411 |
| AC-02 (03) (d) |
Unnecessary application accounts must be disabled, or deleted. |
Design the application so unessential user accounts are not created during installation. Disable or delete all unnecessary application user accounts. |
Application installation scripts/steps create only those accounts necessary for normal operation. |
|
9/9/2024 |
V-222412 |
| AC-02 (04) |
The application must automatically audit account creation. |
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. |
Achieved by integrating your organization's existing external account and authentication mechanisms for user access. Local accounts should only be used for administration and troubleshooting. |
|
9/9/2024 |
V-222413 |
| AC-02 (04) |
The application must automatically audit account modification. |
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. |
Achieved by integrating your organization's existing external account and authentication mechanisms for user access. Local accounts should only be used for administration and troubleshooting. |
|
9/9/2024 |
V-222414 |
| AC-02 (04) |
The application must automatically audit account disabling actions. |
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. |
Achieved by integrating your organization's existing external account and authentication mechanisms for user access. Local accounts should only be used for administration and troubleshooting. |
|
9/9/2024 |
V-222415 |
| AC-02 (04) |
The application must automatically audit account removal actions. |
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. |
Achieved by integrating your organization's existing external account and authentication mechanisms for user access. Local accounts should only be used for administration and troubleshooting. |
|
9/9/2024 |
V-222416 |
| AC-02 (04) |
The application must notify System Administrators and Information System Security Officers when accounts are created. |
Configure the application to notify the system administrator and the ISSO when application accounts are created. |
Achieved by integrating your organization's existing external account and authentication mechanisms for user access. Local accounts should only be used for administration and troubleshooting. |
|
9/9/2024 |
V-222417 |
| AC-02 (04) |
The application must notify System Administrators and Information System Security Officers when accounts are modified. |
Configure the application to notify the system administrator and the ISSO when application accounts are modified. |
Achieved by integrating your organization's existing external account and authentication mechanisms for user access. Local accounts should only be used for administration and troubleshooting. |
|
9/9/2024 |
V-222418 |
| AC-02 (04) |
The application must notify System Administrators and Information System Security Officers of account disabling actions. |
Configure the application to notify the system administrator and the ISSO when application accounts are disabled. |
Achieved by integrating your organization's existing external account and authentication mechanisms for user access. Local accounts should only be used for administration and troubleshooting. |
|
9/9/2024 |
V-222419 |
| AC-02 (04) |
The application must notify System Administrators and Information System Security Officers of account removal actions. |
Configure the application to notify the system administrator and the ISSO when application accounts are removed. |
Achieved by integrating your organization's existing external account and authentication mechanisms for user access. Local accounts should only be used for administration and troubleshooting. |
|
9/9/2024 |
V-222420 |
| AC-02 (04) |
The application must automatically audit account enabling actions. |
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. |
Achieved by integrating your organization's existing external account and authentication mechanisms for user access. Local accounts should only be used for administration and troubleshooting. |
|
9/9/2024 |
V-222421 |
| AC-02 (04) |
The application must notify System Administrators and Information System Security Officers of account enabling actions. |
Configure the application to notify the system administrator and the ISSO when application accounts are enabled. |
Achieved by integrating your organization's existing external account and authentication mechanisms for user access. Local accounts should only be used for administration and troubleshooting. |
|
9/9/2024 |
V-222422 |
| AC-02 (10) |
Shared/group account credentials must be terminated when members leave the group. |
Create a procedure for deleting either member accounts or the entire group account when members leave the group. |
Achieved by integrating your organization's existing external account and authentication mechanisms for user access. Local accounts should only be used for administration and troubleshooting. |
|
9/9/2024 |
V-222408 |
| AC-03 |
The application must enforce approved authorizations for logical access to information and system resources in accordance with applicable access control policies. |
Design or configure the application to enforce access to application resources. |
Heimdall Server enforces role-based access control for user, administrator, and other application roles. |
|
9/9/2024 |
V-222425 |
| AC-03 (04) |
The application must enforce organization-defined discretionary access control policies over defined subjects and objects. |
Design and configure the application to enforce discretionary access control policies. |
Heimdall Server enforces role-based access control for user, administrator, and other application roles. |
|
9/9/2024 |
V-222426 |
| AC-04 |
The application must enforce approved authorizations for controlling the flow of information within the system based on organization-defined information flow control policies. |
Configure the application to enforce data flow control in accordance with data flow control policies. |
Heimdall Server enforces role-based access control on its API. |
|
9/9/2024 |
V-222427 |
| AC-04 |
The application must enforce approved authorizations for controlling the flow of information between interconnected systems based on organization-defined information flow control policies. |
Configure the application to enforce data flow control in accordance with data flow control policies. |
Heimdall Server enforces role-based access control on its API. |
|
9/9/2024 |
V-222428 |
| AC-06 (04) |
Application web servers must be on a separate network segment from the application and database servers if it is a tiered application operating in the organization DMZ. |
Separate web server from other application tiers and place it on a separate network segment apart from the application and database servers in accordance with organization DMZ data access controls requirements. |
Heimdall Server can be deployed with application logic on a separate server/network from the database server/network. |
|
9/9/2024 |
V-222620 |
| AC-06 (08) |
The application must execute without excessive account permissions. |
Configure the application accounts with minimalist privileges. Do not allow the application to operate with admin credentials. |
The user deploying Heimdall Server can choose both the account under which the application logic runs under, as well as the account used to access the backend database. Neither account needs to be nor should have full access rights to the OS or Database, respectively. |
|
9/9/2024 |
V-222430 |
| AC-06 (09) |
The application must audit the execution of privileged functions. |
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. |
Heimdall Server audits actions of all users including users with administrative role. |
|
9/9/2024 |
V-222431 |
| AC-06 (10) |
The application must prevent non-privileged users from executing privileged functions to include disabling, circumventing, or altering implemented security safeguards/countermeasures. |
Modify the application to limit access and prevent the disabling or circumvention of security safeguards. |
Heimdall Server enforces role-based access control for user, administrator, and other application roles. |
|
9/9/2024 |
V-222429 |
| AC-07 a |
The application must enforce the limit of three consecutive invalid logon attempts by a user during a 15 minute time period. |
Configure the application to enforce an account lock after 3 failed logon attempts occurring within a 15-minute window. |
Achieved by integrating your organization's existing external account and authentication mechanisms for user access. Local accounts should only be used for administration and troubleshooting. |
|
9/9/2024 |
V-222432 |
| AC-07 b |
The application administrator must follow an approved process to unlock locked user accounts. |
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. |
Achieved by integrating your organization's existing external account and authentication mechanisms for user access. Local accounts should only be used for administration and troubleshooting. |
|
9/9/2024 |
V-222433 |
| AC-08 a |
The application must display an approved organization banner before granting access to the application. |
Configure the application to present the approved organization banner prior to granting access to the application. |
Heimdall Server provides a 'CLASSIFICATION_BANNER_TEXT' environment variable to configure an organization's banner. |
|
9/9/2024 |
V-222434 |
| AC-08 b |
The application must retain the approved organization banner on the screen until users acknowledge the usage conditions and take explicit actions to log on for further access. |
Configure the application to retain the approved organization banner until the user accepts the usage conditions prior to granting access to the application. |
Heimdall Server provides a 'CLASSIFICATION_BANNER_TEXT' environment variable to configure an organization's banner. |
|
9/9/2024 |
V-222435 |
| AC-08 c 1;AC-08 c 2;AC-08 c 3 |
The publicly accessible application must display an approved organization banner before granting access to the application. |
Configure the application to present the approved organization banner prior to granting access to the application. |
Heimdall Server provides a 'CLASSIFICATION_BANNER_TEXT' environment variable to configure an organization's banner. |
|
9/9/2024 |
V-222436 |
| AC-09 |
The application must display the time and date of the users last successful logon. |
Design and configure the application to display the date and time when the user was last successfully granted access to the application. |
Achieved by integrating your organization's existing external account and authentication mechanisms for user access. Local accounts should only be used for administration and troubleshooting. |
|
9/9/2024 |
V-222437 |
| AC-10 |
The application must provide a capability to limit the number of logon sessions per user. |
Design and configure the application to specify the number of logon sessions that are allowed per user. |
Heimdall Environment Variable 'ONE_SESSION_PER_USER' should be set to TRUE to limit one session per user. |
|
9/9/2024 |
V-222387 |
| AC-12 |
The application must clear temporary storage and cookies when the session is terminated. |
Design and configure the application to clear sensitive data from cookies and local storage when the user logs out of the application. |
Heimdall Server only stores one sensitive piece of data in the Local Storage, the JWT. When the user clicks 'Log Off' the JWT is cleared from local storage. |
|
9/9/2024 |
V-222388 |
| AC-12 |
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. |
Design and configure the application to terminate the non-privileged users session after 15 minutes of inactivity. |
Heimdall Environment Variable 'JWT_EXPIRE_TIME' should be set to 15m to limit non-privileged user sessions. |
|
9/9/2024 |
V-222389 |
| AC-12 |
The application must automatically terminate the admin user session and log off admin users after a 10 minute idle time period is exceeded. |
Design and configure the application to terminate the admin users session after 10 minutes of inactivity. |
Administrator JWT expire after 10 minutes. Administrators must reauthenticate every 10 minutes. |
|
9/9/2024 |
V-222390 |
| AC-12 (01) |
Applications requiring user access authentication must provide a logoff capability for user initiated communication session. |
Design and configure the application to provide all users with the capability to manually terminate their application session. |
Heimdall provides a Log Out button in the web page for clients that will invalidate their current JWT |
|
9/9/2024 |
V-222391 |
| AC-12 (02) |
The application must display an explicit logoff message to users indicating the reliable termination of authenticated communications sessions. |
Design and configure the application to provide an explicit logoff message to users indicating a successful logoff has occurred upon user session termination. |
Heimdall provides a 'You have successfully logged off' message |
|
9/9/2024 |
V-222392 |
| AC-16 a |
The application must associate organization-defined types of security attributes having organization-defined security attribute values with information in storage. |
Design and configure the application to assign data marking and ensure the marking is retained when the data is stored. |
The data format that Heimdall is designed to display does not include classification markings |
|
9/9/2024 |
V-222393 |
| AC-16 a |
The application must associate organization-defined types of security attributes having organization-defined security attribute values with information in process. |
Design and configure the application to retain the data marking when processing data. |
The data format that Heimdall is designed to display does not include classification markings. |
|
9/9/2024 |
V-222394 |
| AC-16 a |
The application must associate organization-defined types of security attributes having organization-defined security attribute values with information in transmission. |
Design and configure the application to retain the data marking when transmitting data. |
The data format that Heimdall is designed to display does not include classification markings |
|
9/9/2024 |
V-222395 |
| AC-17 (02) |
The application must implement organization-approved encryption to protect the confidentiality of remote access sessions. |
Design and configure applications to use TLS encryption to protect the confidentiality of remote access sessions. |
For docker deployments an nginx reverse proxy is provided to implement TLS. For user-hosted deployments, users can provide their own reverse proxy to implement TLS. |
|
9/9/2024 |
V-222396 |
| AC-17 (02) |
The application must implement cryptographic mechanisms to protect the integrity of remote access sessions. |
Design and configure applications to use TLS encryption to protect the integrity of remote access sessions. |
For docker deployments an nginx reverse proxy is provided to implement TLS. For user-hosted deployments, users can provide their own reverse proxy to implement TLS. |
|
9/9/2024 |
V-222397 |
| AC-23 |
Application data protection requirements must be identified and documented. |
Identify and document the application data elements and the data protection requirements. |
The primary data elements of interest in Heimdall Server are known as 'Results'. Results are stored in a database and protected by database RBAC and application-level ABAC that mediates access and operations to 'Results' data |
|
9/9/2024 |
V-222423 |
| AC-23 |
The application must utilize organization-defined data mining detection techniques for organization-defined data storage objects to adequately detect data mining attempts. |
Utilize and implement data mining protections when requirements specify it. |
Achieved by employing the organization's data loss prevention tools to monitor for data mining activities. |
|
9/9/2024 |
V-222424 |
| AT-03 (03) |
The Program Manager must verify all levels of program management, designers, developers, and testers receive annual security training pertaining to their job function. |
Provide application development/operational related security specific annual training for managers, designers, developers, and testers. |
All training requirements are established and tracked by the organization. |
|
9/9/2024 |
V-222673 |
| AU-03 a |
The application must log application shutdown events. |
Configure the application or application server to record application shutdown events in the event logs. |
Heimdall Server logs application shutdown events. |
|
9/9/2024 |
V-222469 |
| AU-03 a |
The application must log destination IP addresses. |
Configure the application to record the destination IP address of the remote system. |
Heimdall Server logs all connections by user and location (IP). |
|
9/9/2024 |
V-222470 |
| AU-03 a |
The application must log user actions involving access to data. |
Identify the specific data elements requiring protection and audit access to the data. |
Heimdall Server implements parameter logging that helps identify what specific actions a user is making, including what results a user would have access to and how those results are modified. |
|
9/9/2024 |
V-222471 |
| AU-03 a |
The application must log user actions involving changes to data. |
Configure the application to log all changes to application data. |
Heimdall application auditing goes to 'standard out'. The Heimdall postgreSQL database also records transactions, and can be enhanced by the organization using the optional pgaudit module. The organization can choose how to locally store and copy this data to the organization's centralized logging system to retain, protect, search, report and review user and application account activities. |
|
9/9/2024 |
V-222472 |
| AU-03 b |
The application must produce audit records containing information to establish when (date and time) the events occurred. |
Configure the application or application server to include the date and the time of the event in the audit logs. |
Heimdall Server logs date/time for application activities. |
|
9/9/2024 |
V-222473 |
| AU-03 c |
The application must produce audit records containing enough information to establish which component, feature or function of the application triggered the audit event. |
Configure the application to log which component, feature or functionality of the application triggered the event. |
All of the URI paths logged from user requests map to an application module in Heimdall. |
|
9/9/2024 |
V-222474 |
| AU-03 d |
When using centralized logging; the application must include a unique identifier in order to distinguish itself from other application logs. |
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. |
Heimdall application auditing goes to 'standard out'. The Heimdall postgreSQL database also records transactions, and can be enhanced by the organization using the optional pgaudit module. The organization can choose how to locally store and copy this data to the organization's centralized logging system to retain, protect, search, report and review user and application account activities. |
|
9/9/2024 |
V-222475 |
| AU-03 e |
The application must produce audit records that contain information to establish the outcome of the events. |
Configure the application to include the outcome of application functions or events. |
Heimdall Server logs failures. For example: an unauthorized or malformed request. |
|
9/9/2024 |
V-222476 |
| AU-03 f |
The application must generate audit records containing information that establishes the identity of any individual or process associated with the event. |
Configure the application to log the identity of the user and/or the process associated with the event. |
Unique User IDs are logged with each action. |
|
9/9/2024 |
V-222477 |
| AU-03 (01) |
The application must generate audit records containing the full-text recording of privileged commands or the individual identities of group account users. |
Configure the application to log the full text recording of privileged commands or the individual identities of group users. |
Heimdall Server logs details for application activities. |
|
9/9/2024 |
V-222478 |
| AU-03 (01) |
The application must implement transaction recovery logs when transaction based. |
Configure the application database to utilize transactional logging. |
Heimdall application auditing goes to 'standard out'. The Heimdall postgreSQL database also records transactions, and can be enhanced by the organization using the optional pgaudit module. The organization can choose how to locally store and copy this data to the organization's centralized logging system to retain, protect, search, report and review user and application account activities. |
|
9/9/2024 |
V-222479 |
| AU-03 (02) |
The application must provide centralized management and configuration of the content to be captured in audit records generated by all application components. |
Configure the application to utilize a centralized log management system that provides the capability to configure the content of audit records. |
Heimdall application auditing goes to 'standard out'. The Heimdall postgreSQL database also records transactions, and can be enhanced by the organization using the optional pgaudit module. The organization can choose how to locally store and copy this data to the organization's centralized logging system to retain, protect, search, report and review user and application account activities. |
|
9/9/2024 |
V-222480 |
| AU-04 (01) |
The application must off-load audit records onto a different system or media than the system being audited. |
Configure the application to off-load audit records onto a different system as per approved schedule. |
Heimdall application auditing goes to 'standard out'. The Heimdall postgreSQL database also records transactions, and can be enhanced by the organization using the optional pgaudit module. The organization can choose how to locally store and copy this data to the organization's centralized logging system to retain, protect, search, report and review user and application account activities. |
|
9/9/2024 |
V-222481 |
| AU-04 (01) |
The application must be configured to write application logs to a centralized log repository. |
Configure the application to utilize a centralized log repository and ensure the logs are off-loaded from the application system as quickly as possible. |
Heimdall application auditing goes to 'standard out'. The Heimdall postgreSQL database also records transactions, and can be enhanced by the organization using the optional pgaudit module. The organization can choose how to locally store and copy this data to the organization's centralized logging system to retain, protect, search, report and review user and application account activities. |
|
9/9/2024 |
V-222482 |
| AU-05 a |
The application must alert the ISSO and SA (at a minimum) in the event of an audit processing failure. |
Configure the application to send an alarm in the event the audit system has failed or is failing. |
Heimdall application auditing goes to 'standard out'. The Heimdall postgreSQL database also records transactions, and can be enhanced by the organization using the optional pgaudit module. The organization can choose how to locally store and copy this data to the organization's centralized logging system to retain, protect, search, report and review user and application account activities. |
|
9/9/2024 |
V-222485 |
| AU-05 b |
The application must shut down by default upon audit failure (unless availability is an overriding concern). |
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. |
Heimdall application auditing goes to 'standard out'. The Heimdall postgreSQL database also records transactions, and can be enhanced by the organization using the optional pgaudit module. The organization can choose how to locally store and copy this data to the organization's centralized logging system to retain, protect, search, report and review user and application account activities. |
|
9/9/2024 |
V-222486 |
| AU-05 (01) |
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. |
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. |
Heimdall application auditing goes to 'standard out'. The Heimdall postgreSQL database also records transactions, and can be enhanced by the organization using the optional pgaudit module. The organization can choose how to locally store and copy this data to the organization's centralized logging system to retain, protect, search, report and review user and application account activities. |
|
9/9/2024 |
V-222483 |
| AU-05 (02) |
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. |
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. |
Heimdall application auditing goes to 'standard out'. The Heimdall postgreSQL database also records transactions, and can be enhanced by the organization using the optional pgaudit module. The organization can choose how to locally store and copy this data to the organization's centralized logging system to retain, protect, search, report and review user and application account activities. |
|
9/9/2024 |
V-222484 |
| AU-06 b |
The ISSO must report all suspected violations of security policies in accordance with organization procedures. |
Create and maintain a policy to report security violations. |
Achieved by leveraging or adapting your organization's policies for reporting security violations. |
|
9/9/2024 |
V-222623 |
| AU-06 (04) |
The application must provide the capability to centrally review and analyze audit records from multiple components within the system. |
Configure the application so all of the applications logs are available for review from one centralized location. |
Heimdall application auditing goes to 'standard out'. The Heimdall postgreSQL database also records transactions, and can be enhanced by the organization using the optional pgaudit module. The organization can choose how to locally store and copy this data to the organization's centralized logging system to retain, protect, search, report and review user and application account activities. |
|
9/9/2024 |
V-222487 |
| AU-06 (10) |
The ISSO must review audit trails periodically based on system documentation recommendations or immediately upon system security events. |
Establish a scheduled process for reviewing logs. Maintain a log or records of dates and times audit logs are reviewed. |
Heimdall application auditing goes to 'standard out'. The Heimdall postgreSQL database also records transactions, and can be enhanced by the organization using the optional pgaudit module. The organization can choose how to locally store and copy this data to the organization's centralized logging system to retain, protect, search, report and review user and application account activities. |
|
9/9/2024 |
V-222622 |
| AU-07 a |
The application must provide an audit reduction capability that supports on-demand audit review and analysis. |
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. |
Heimdall application auditing goes to 'standard out'. The Heimdall postgreSQL database also records transactions, and can be enhanced by the organization using the optional pgaudit module. The organization can choose how to locally store and copy this data to the organization's centralized logging system to retain, protect, search, report and review user and application account activities. |
|
9/9/2024 |
V-222490 |
| AU-07 a |
The application must provide an audit reduction capability that supports on-demand reporting requirements. |
Configure the application to generate soft copy, hard copy and/or screen-based reports based on the selected filtered event data. |
Heimdall application auditing goes to 'standard out'. The Heimdall postgreSQL database also records transactions, and can be enhanced by the organization using the optional pgaudit module. The organization can choose how to locally store and copy this data to the organization's centralized logging system to retain, protect, search, report and review user and application account activities. |
|
9/9/2024 |
V-222489 |
| AU-07 a |
The application must provide an audit reduction capability that supports after-the-fact investigations of security incidents. |
Configure the application to provide an audit reduction capability that supports forensic investigations. |
Heimdall application auditing goes to 'standard out'. The Heimdall postgreSQL database also records transactions, and can be enhanced by the organization using the optional pgaudit module. The organization can choose how to locally store and copy this data to the organization's centralized logging system to retain, protect, search, report and review user and application account activities. |
|
9/9/2024 |
V-222491 |
| AU-07 a |
The application must provide a report generation capability that supports on-demand audit review and analysis. |
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. |
Heimdall application auditing goes to 'standard out'. The Heimdall postgreSQL database also records transactions, and can be enhanced by the organization using the optional pgaudit module. The organization can choose how to locally store and copy this data to the organization's centralized logging system to retain, protect, search, report and review user and application account activities. |
|
9/9/2024 |
V-222492 |
| AU-07 a |
The application must provide a report generation capability that supports on-demand reporting requirements. |
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. |
Heimdall application auditing goes to 'standard out'. The Heimdall postgreSQL database also records transactions, and can be enhanced by the organization using the optional pgaudit module. The organization can choose how to locally store and copy this data to the organization's centralized logging system to retain, protect, search, report and review user and application account activities. |
|
9/9/2024 |
V-222493 |
| AU-07 a |
The application must provide a report generation capability that supports after-the-fact investigations of security incidents. |
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. |
Heimdall application auditing goes to 'standard out'. The Heimdall postgreSQL database also records transactions, and can be enhanced by the organization using the optional pgaudit module. The organization can choose how to locally store and copy this data to the organization's centralized logging system to retain, protect, search, report and review user and application account activities. |
|
9/9/2024 |
V-222494 |
| AU-07 b |
The application must provide an audit reduction capability that does not alter original content or time ordering of audit records. |
Configure the application to not alter original log content or time ordering of audit records. |
Heimdall application auditing goes to 'standard out'. The Heimdall postgreSQL database also records transactions, and can be enhanced by the organization using the optional pgaudit module. The organization can choose how to locally store and copy this data to the organization's centralized logging system to retain, protect, search, report and review user and application account activities. |
|
9/9/2024 |
V-222495 |
| AU-07 b |
The application must provide a report generation capability that does not alter original content or time ordering of audit records. |
Configure and design the application to not modify source logs when filtering events. |
Heimdall application auditing goes to 'standard out'. The Heimdall postgreSQL database also records transactions, and can be enhanced by the organization using the optional pgaudit module. The organization can choose how to locally store and copy this data to the organization's centralized logging system to retain, protect, search, report and review user and application account activities. |
|
9/9/2024 |
V-222496 |
| AU-07 (01) |
The application must provide the capability to filter audit records for events of interest based upon organization-defined criteria. |
Configure the application filters to search event logs based on defined criteria. |
Heimdall application auditing goes to 'standard out'. The Heimdall postgreSQL database also records transactions, and can be enhanced by the organization using the optional pgaudit module. The organization can choose how to locally store and copy this data to the organization's centralized logging system to retain, protect, search, report and review user and application account activities. |
|
9/9/2024 |
V-222488 |
| AU-08 a |
The applications must use internal system clocks to generate time stamps for audit records. |
Configure the application to use the hosting systems internal clock for audit record generation. |
This requirement is inherited from underlying operating system time functions. |
|
9/9/2024 |
V-222497 |
| AU-08 b |
The application must record time stamps for audit records that meet a granularity of one second for a minimum degree of precision. |
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. |
This requirement is inherited from underlying operating system time functions. |
|
9/9/2024 |
V-222499 |
| AU-08 b |
The application must record time stamps for audit records that can be mapped to Coordinated Universal Time (UTC) or Greenwich Mean Time (GMT). |
Configure the application to use the underlying system clock that maps to relevant UTC or GMT timezone. |
This requirement is inherited from underlying operating system time functions. |
|
9/9/2024 |
V-222498 |
| AU-09 |
The application must protect audit tools from unauthorized modification. |
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. |
Heimdall application auditing goes to 'standard out'. The Heimdall postgreSQL database also records transactions, and can be enhanced by the organization using the optional pgaudit module. The organization can choose how to locally store and copy this data to the organization's centralized logging system to retain, protect, search, report and review user and application account activities. |
|
9/9/2024 |
V-222504 |
| AU-09 |
The application must protect audit tools from unauthorized deletion. |
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. |
Heimdall application auditing goes to 'standard out'. The Heimdall postgreSQL database also records transactions, and can be enhanced by the organization using the optional pgaudit module. The organization can choose how to locally store and copy this data to the organization's centralized logging system to retain, protect, search, report and review user and application account activities. |
|
9/9/2024 |
V-222505 |
| AU-09 a |
The application must protect audit information from any type of unauthorized read access. |
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. |
Heimdall application auditing goes to 'standard out'. The Heimdall postgreSQL database also records transactions, and can be enhanced by the organization using the optional pgaudit module. The organization can choose how to locally store and copy this data to the organization's centralized logging system to retain, protect, search, report and review user and application account activities. |
|
9/9/2024 |
V-222500 |
| AU-09 a |
The application must protect audit information from unauthorized modification. |
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. |
Heimdall application auditing goes to 'standard out'. The Heimdall postgreSQL database also records transactions, and can be enhanced by the organization using the optional pgaudit module. The organization can choose how to locally store and copy this data to the organization's centralized logging system to retain, protect, search, report and review user and application account activities. |
|
9/9/2024 |
V-222501 |
| AU-09 a |
The application must protect audit information from unauthorized deletion. |
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. |
Heimdall application auditing goes to 'standard out'. The Heimdall postgreSQL database also records transactions, and can be enhanced by the organization using the optional pgaudit module. The organization can choose how to locally store and copy this data to the organization's centralized logging system to retain, protect, search, report and review user and application account activities. |
|
9/9/2024 |
V-222502 |
| AU-09 a |
The application must protect audit tools from unauthorized access. |
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. |
Heimdall application auditing goes to 'standard out'. The Heimdall postgreSQL database also records transactions, and can be enhanced by the organization using the optional pgaudit module. The organization can choose how to locally store and copy this data to the organization's centralized logging system to retain, protect, search, report and review user and application account activities. |
|
9/9/2024 |
V-222503 |
| AU-09 (02) |
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. |
Configure application backup settings to backup application audit logs every 7 days. |
Heimdall application auditing goes to 'standard out'. The Heimdall postgreSQL database also records transactions, and can be enhanced by the organization using the optional pgaudit module. The organization can choose how to locally store and copy this data to the organization's centralized logging system to retain, protect, search, report and review user and application account activities. |
|
9/9/2024 |
V-222506 |
| AU-09 (03) |
The application must use cryptographic mechanisms to protect the integrity of audit information. |
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. |
Heimdall application auditing goes to 'standard out'. The Heimdall postgreSQL database also records transactions, and can be enhanced by the organization using the optional pgaudit module. The organization can choose how to locally store and copy this data to the organization's centralized logging system to retain, protect, search, report and review user and application account activities. |
|
9/9/2024 |
V-222507 |
| AU-09 (03) |
Application audit tools must be cryptographically hashed. |
Cryptographically hash the audit tool files used by the application. Store and protect the generated hash values for future reference. |
Heimdall application auditing goes to 'standard out'. The Heimdall postgreSQL database also records transactions, and can be enhanced by the organization using the optional pgaudit module. The organization can choose how to locally store and copy this data to the organization's centralized logging system to retain, protect, search, report and review user and application account activities. |
|
9/9/2024 |
V-222508 |
| AU-09 (03) |
The integrity of the audit tools must be validated by checking the files for changes in the cryptographic hash value. |
Establish a process to periodically check the audit tool cryptographic hashes to ensure the audit tools have not been tampered with. |
Heimdall application auditing goes to 'standard out'. The Heimdall postgreSQL database also records transactions, and can be enhanced by the organization using the optional pgaudit module. The organization can choose how to locally store and copy this data to the organization's centralized logging system to retain, protect, search, report and review user and application account activities. |
|
9/9/2024 |
V-222509 |
| AU-10 |
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. |
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. |
Heimdall application auditing goes to 'standard out'. The Heimdall postgreSQL database also records transactions, and can be enhanced by the organization using the optional pgaudit module. The organization can choose how to locally store and copy this data to the organization's centralized logging system to retain, protect, search, report and review user and application account activities. |
|
9/9/2024 |
V-222438 |
| AU-11 |
The ISSO must ensure application audit trails are retained for at least 1 year for applications without SAMI data, and 5 years for applications including SAMI data. |
Retain application audit log files for one year and five years for sources and methods intelligence data. |
Heimdall application auditing goes to 'standard out'. The Heimdall postgreSQL database also records transactions, and can be enhanced by the organization using the optional pgaudit module. The organization can choose how to locally store and copy this data to the organization's centralized logging system to retain, protect, search, report and review user and application account activities. |
|
9/9/2024 |
V-222621 |
| AU-12 a |
The application must provide audit record generation capability for the creation of session IDs. |
Enable session ID creation event auditing. |
Heimdall Server backend logic records session token creation. |
|
9/9/2024 |
V-222441 |
| AU-12 a |
The application must provide audit record generation capability for the destruction of session IDs. |
Enable session ID destruction event auditing. |
Heimdall Server backend logic records session token destruction/change. |
|
9/9/2024 |
V-222442 |
| AU-12 a |
The application must provide audit record generation capability for the renewal of session IDs. |
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. |
Heimdall Server backend logic records session token creation. |
|
9/9/2024 |
V-222443 |
| AU-12 a |
The application must not write sensitive data into the application logs. |
Design or reconfigure the application to not write sensitive data to the logs. |
Heimdall has a logging interceptor with a configurable list of keywords (regular expressions) that are checked before writing the logs. If a keyword matches, then [REDACTED] is printed on the log instead |
|
9/9/2024 |
V-222444 |
| AU-12 a |
The application must provide audit record generation capability for session timeouts. |
Configure the application to record session timeout events in the logs. |
Heimdall Server backend logic records session token renewal including due to session timeouts. |
|
9/9/2024 |
V-222445 |
| AU-12 a |
The application must record a time stamp indicating when the event occurred. |
Configure the application to record the time the event occurred when recording the event. |
Heimdall Server records a time stamp indicating when the event occurred. |
|
9/9/2024 |
V-222446 |
| AU-12 a |
The application must provide audit record generation capability for HTTP headers including User-Agent, Referer, GET, and POST. |
Configure the web application and/or the web server to log HTTP headers. |
Heimdall Server backend logic records HTTP header information. |
|
9/9/2024 |
V-222447 |
| AU-12 a |
The application must provide audit record generation capability for connecting system IP addresses. |
Configure the application or application server to log all connecting IP address information |
Heimdall logs IP addresses from all requests. If 'x-forwarded-for' or 'x-real-ip' HTTP headers are set, the IP from the value of that header is logged instead. |
|
9/9/2024 |
V-222448 |
| AU-12 a |
The application must record the username or user ID of the user associated with the event. |
Configure the application to record the user ID of the user responsible for the log event entry. |
Heimdall logs the user ID for all requests. |
|
9/9/2024 |
V-222449 |
| AU-12 c |
The application must generate audit records when successful/unsuccessful attempts to grant privileges occur. |
Configure the application to audit successful and unsuccessful attempts to grant privileges. |
Heimdall Server audits actions of all users including users with administrative role. |
|
9/9/2024 |
V-222450 |
| AU-12 c |
The application must generate audit records when successful/unsuccessful attempts to access security objects occur. |
Configure the application to create an audit record for both successful and unsuccessful attempts to access security objects. |
Heimdall Server audits actions of all users including users with administrative role. |
|
9/9/2024 |
V-222451 |
| AU-12 c |
The application must generate audit records when successful/unsuccessful attempts to access security levels occur. |
Configure the application to create an audit record for both successful and unsuccessful attempts to access security levels. |
Heimdall Server audits actions of all users including users with administrative role. |
|
9/9/2024 |
V-222452 |
| AU-12 c |
The application must generate audit records when successful/unsuccessful attempts to access categories of information (e.g., classification levels) occur. |
Configure the application to create an audit record for both successful and unsuccessful attempts to access protected categories of information. |
Heimdall logs access by logging the HTTP command and URI of the resource that a user requests. |
|
9/9/2024 |
V-222453 |
| AU-12 c |
The application must generate audit records when successful/unsuccessful attempts to modify privileges occur. |
Configure the application to audit successful and unsuccessful attempts to modify privileges. |
Heimdall Server audits actions of all users including users with administrative role. |
|
9/9/2024 |
V-222454 |
| AU-12 c |
The application must generate audit records when successful/unsuccessful attempts to modify security objects occur. |
Configure the application to create an audit record for both successful and unsuccessful attempts to modify security objects. |
Heimdall Server audits actions of all users including users with administrative role. |
|
9/9/2024 |
V-222455 |
| AU-12 c |
The application must generate audit records when successful/unsuccessful attempts to modify security levels occur. |
Configure the application to create an audit record for both successful and unsuccessful attempts to modify security levels. |
Heimdall Server audits actions of all users including users with administrative role. |
|
9/9/2024 |
V-222456 |
| AU-12 c |
The application must generate audit records when successful/unsuccessful attempts to modify categories of information (e.g., classification levels) occur. |
Configure the application to create an audit record for both successful and unsuccessful attempts to modify protected categories of information. |
Heimdall logs modification by logging the HTTP command and URI of the resource that a user requests. |
|
9/9/2024 |
V-222457 |
| AU-12 c |
The application must generate audit records when successful/unsuccessful attempts to delete privileges occur. |
Configure the application to audit successful and unsuccessful attempts to delete privileges. |
Heimdall Server audits actions of all users including users with administrative role. |
|
9/9/2024 |
V-222458 |
| AU-12 c |
The application must generate audit records when successful/unsuccessful attempts to delete security levels occur. |
Configure the application to create an audit record for both successful and unsuccessful attempts to delete security levels. |
Heimdall Server audits actions of all users including users with administrative role. |
|
9/9/2024 |
V-222459 |
| AU-12 c |
The application must generate audit records when successful/unsuccessful attempts to delete application database security objects occur. |
Configure the application to create an audit record for both successful and unsuccessful attempts to delete database security objects. |
Heimdall Server audits actions of all users including users with administrative role. |
|
9/9/2024 |
V-222460 |
| AU-12 c |
The application must generate audit records when successful/unsuccessful attempts to delete categories of information (e.g., classification levels) occur. |
Configure the application to create an audit record for both successful and unsuccessful attempts to delete protected categories of information. |
Heimdall Server logs deletion by logging the HTTP command and URI of the resource that a user requests. |
|
9/9/2024 |
V-222461 |
| AU-12 c |
The application must generate audit records when successful/unsuccessful logon attempts occur. |
Configure the application or application server to write a log entry when successful and unsuccessful logon events occur. |
Heimdall Server enforces this requirement. |
|
9/9/2024 |
V-222462 |
| AU-12 c |
The application must generate audit records for privileged activities or other system-level access. |
Configure the application to write a log entry when privileged activities or other system-level events occur. |
Heimdall logs all requests for any user, including the admin user. |
|
9/9/2024 |
V-222463 |
| AU-12 c |
The application must generate audit records showing starting and ending time for user access to the system. |
Configure the application or application server to record the start and end time of user session activity. |
User authentications that issue a JWT are logged. User log-out that invalidate the issued JWT are also logged. |
|
9/9/2024 |
V-222464 |
| AU-12 c |
The application must generate audit records when successful/unsuccessful accesses to objects occur. |
Configure the application to log successful and unsuccessful access to application objects. |
All of the URI paths logged from user requests map to an application module in Heimdall. |
|
9/9/2024 |
V-222465 |
| AU-12 c |
The application must generate audit records for all direct access to the underlying hosting operating system. |
Configure the application to log all direct access to the underlying hosting operating system. |
Heimdall does not provide direct access to the underlying operating system, hence this auditing requirement is not applicable. |
|
9/9/2024 |
V-222466 |
| AU-12 c |
The application must generate audit records for all account creations, modifications, disabling, and termination events. |
Configure the application to log user account creation, modification, disabling, and termination events. |
This is implemented for local accounts. For integrated external authentication mechanisms, account management is an external process separate from Heimdall. |
|
9/9/2024 |
V-222467 |
| AU-12 c |
The application must generate audit records when concurrent logons from different workstations occur. |
Configure the application to log concurrent logons from different workstations. |
Heimdall Server logs all connections by user and location. |
|
9/9/2024 |
V-222672 |
| AU-12 (01) |
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. |
Configure the application to correlate time stamps when aggregating audit records. |
Heimdall application auditing goes to 'standard out'. The Heimdall postgreSQL database also records transactions, and can be enhanced by the organization using the optional pgaudit module. The organization can choose how to locally store and copy this data to the organization's centralized logging system to retain, protect, search, report and review user and application account activities. |
|
9/9/2024 |
V-222439 |
| AU-14 (01) |
The application must initiate session auditing upon startup. |
Configure the application to begin logging application events as soon as the application starts up. |
System Start-Up logging is provided as an inheritable control via SLA with the Source Code Push. The application also initiate logging upon startup and logs to standard out. |
|
9/9/2024 |
V-222468 |
| CA-02 (02) |
The ISSO must ensure active vulnerability testing is performed. |
Perform active vulnerability and fuzz testing of the application. Verify the vulnerability scanning tool is configured to test all application components and functionality. Address discovered vulnerabilities. |
The Heimdall Server GitHub repository undergoes continuous automated dependency, static, and secrets scanning. https://github.com/mitre/heimdall2/security |
|
9/9/2024 |
V-222624 |
| CM-04 (02) |
Execution flow diagrams and design documents must be created to show how deadlock and recursion issues in web services are being mitigated. |
Develop web services to account for deadlock issues. |
For docker deployments an nginx reverse proxy is provided to implement TLS. For user-hosted deployments, users can provide their own reverse proxy to implement TLS. |
|
9/9/2024 |
V-222625 |
| CM-05 |
The designer must ensure the application does not store configuration and control files in the same directory as user data. |
Separate the application user data into a different directory than the application code and user file permissions to restrict user access to application configuration settings. |
User data is stored only within the database, separate from application logic stored in operating system folders. |
|
9/9/2024 |
V-222626 |
| CM-05 (01) |
The application must audit who makes configuration changes to the application. |
Configure the application to create log entries that can be used to identify the user accounts that make application configuration changes. |
There are no Heimdall Server components for the purposes of initiating changes, including upgrades and modifications. The only way to modify the configuration is through the CI/CD pipeline outside of Heimdall Server. |
|
9/9/2024 |
V-222512 |
| CM-05 (01) (a) |
The application must enforce access restrictions associated with changes to application configuration. |
Configure the application to limit access to configuration settings to only authorized users. |
There are no Heimdall Server components for the purposes of initiating changes, including upgrades and modifications. The only way to modify the configuration is through the CI/CD pipeline outside of Heimdall Server. |
|
9/9/2024 |
V-222511 |
| CM-05 (03) |
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. |
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. |
There are no Heimdall Server components for the purposes of initiating changes, including upgrades and modifications. The only way to modify the configuration is through the CI/CD pipeline outside of Heimdall Server. |
|
9/9/2024 |
V-222513 |
| CM-05 (06) |
The applications must limit privileges to change the software resident within software libraries. |
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. |
Heimdall Server does not provide user roles access to change software components of the application. |
|
9/9/2024 |
V-222514 |
| CM-06 a |
The ISSO must ensure if a DoD STIG or NSA guide is not available, a third-party product will be configured by following available guidance. |
Configure the application according to the product STIG or when a STIG is not available, utilize: - commercially accepted practices, - independent testing results, or - vendor literature and lock down guides. |
The Heimdall Server GitHub repository undergoes continuous automated dependency, static, and secrets scanning. https://github.com/mitre/heimdall2/security Additionally, the application is following applicable Application Security and Development STIG requirements and vendor best practices. |
|
9/9/2024 |
V-222627 |
| CM-06 b |
The application must have a process, feature or function that prevents removal or disabling of emergency accounts. |
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. |
Achieved by integrating your organization's existing external account and authentication mechanisms for user access. Local accounts should only be used for administration and troubleshooting. Local accounts must be managed using manual procedures per organizational requirements. |
|
9/9/2024 |
V-222410 |
| CM-06 b |
An application vulnerability assessment must be conducted. |
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. |
The Heimdall Server GitHub repository undergoes continuous automated dependency, static, and secrets scanning. https://github.com/mitre/heimdall2/security |
|
9/9/2024 |
V-222515 |
| CM-07 a |
The application must be configured to disable non-essential capabilities. |
Disable extraneous application functionality that is not required in order to fulfill the application's mission. |
Heimdall is configured with minimum components required for functionality, including disabling of Oauth routes and functionality when not configured for use. |
|
9/9/2024 |
V-222518 |
| CM-07 b |
The application must be configured to use only functions, ports, and protocols permitted to it in the organization. |
Configure the application to utilize application ports approved by the organization. |
Heimdall Server uses only those services, ports and protocols required for secure functionality. |
|
9/9/2024 |
V-222519 |
| CM-07 (02) |
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. |
Restrict application execution in accordance with the policy, terms, and conditions specified. |
Heimdall Server uses only those services, ports and protocols required for secure functionality. |
|
9/9/2024 |
V-222516 |
| CM-07 (03) |
New IP addresses, data services, and associated ports used by the application must be submitted to the appropriate approving authority for the organization. |
Verify the accreditation documentation lists all interfaces and the ports, protocols, and services used. Verify that all ports, protocols, and services are used in accordance with organizational policy. |
Heimdall Server uses only those services, ports and protocols required for secure functionality. |
|
9/9/2024 |
V-222628 |
| CM-07 (03) |
The application's ports and protocols must be registered with the organization's approval process. |
Register the application ports and protocols with the organization's approval process. |
Heimdall Server uses only those services, ports and protocols required for secure functionality. |
|
9/9/2024 |
V-222629 |
| CM-07 (05) (b) |
The application must employ a deny-all, permit-by-exception (whitelist) policy to allow the execution of authorized software programs. |
Configure the application to utilize a deny-all, permit-by-exception policy when allowing the execution of authorized software. |
Heimdall Server uses only those services, ports and protocols required for secure functionality. |
|
9/9/2024 |
V-222517 |
| CM-09 b |
Access privileges to the Configuration Management (CM) repository must be reviewed every three months. |
Review access privileges to the CM repository at least every three months. |
Access controls to the Heimdall Server master GitHub repository are maintained. Access controls to forks or clones of this repository are the responsibility of the organization maintaining the copy. |
|
9/9/2024 |
V-222631 |
| CM-09 b |
A Configuration Control Board (CCB) that meets at least every release cycle, for managing the Configuration Management (CM) process must be established. |
Setup and maintain a Configuration Control Board. |
The CCB of the Heimdall Server master GitHub repository is established. The CCB of forks or clones of this repository are the responsibility of the organization maintaining the copy. |
|
9/9/2024 |
V-222633 |
| CM-09 b |
The Configuration Management (CM) repository must be properly patched and STIG compliant. |
Patch the CM system when new security patches are made available and apply the relevant STIGs. |
The Heimdall Server GitHub repository undergoes continuous automated dependency, static, and secrets scanning, and each release is patched accordingly. The application is following this Application Security & Development STIG and using vendor best practices. At- and post-deployment, it is the responsibility of the organization to update it to the latest release of Heimdall code, as well as apply patches to the underlying operating system and database. |
|
9/9/2024 |
V-222630 |
| CM-09 b |
A Software Configuration Management (SCM) plan describing the configuration control and change management process of application objects developed by the organization and the roles and responsibilities of the organization must be created and maintained. |
Create and update a SCM plan describing the configuration control and change management process of application objects developed by the organization and the roles and responsibilities of the organization. Configure CMR to comply. |
The SCM of the Heimdall Server master GitHub repository is maintained. The SCM of forks or clones of this repository are the responsibility of the organization maintaining the copy. |
|
9/9/2024 |
V-222632 |
| CM-11 (02) |
The application must prohibit user installation of software without explicit privileged status. |
Configure the application to prohibit user installation of software without explicit permission. |
Heimdall Server does not provide the ability to install software components, modules, plugins, or extensions, hence this requirement is not applicable. |
|
9/9/2024 |
V-222510 |
| CP-02 a 1 |
A disaster recovery/continuity plan must exist in accordance with organization policy based on the applications availability requirements. |
Create and maintain the disaster recovery/continuity plan. |
Inherited as it is the responsibility of the deploying organization/user to ensure compliance with this requirement. |
|
9/9/2024 |
V-222636 |
| CP-02 a 2 |
Recovery procedures and technical system features must exist so recovery is performed in a secure and verifiable manner. The ISSO will document circumstances inhibiting a trusted recovery. |
Create and maintain a disaster recovery plan. |
Inherited as it is the responsibility of the deploying organization/user to ensure compliance with this requirement. |
|
9/9/2024 |
V-222637 |
| CP-02 (08) |
The application must not be hosted on a general purpose machine if the application is designated as critical or high availability by the ISSO. |
Deploy mission critical applications on servers that are not shared by other less critical applications. |
Inherited as it is the responsibility of the deploying organization/user to ensure compliance with this requirement. |
|
9/9/2024 |
V-222635 |
| CP-09 (b) |
Data backup must be performed at required intervals in accordance with organization policy. |
Develop and implement backup procedures based on risk level of the system and in accordance with organization policy. |
Inherited as it is the responsibility of the deploying organization/user to ensure compliance with this requirement. |
|
9/9/2024 |
V-222638 |
| CP-09 (d) |
Back-up copies of the application software or source code must be stored in a fire-rated container or stored separately (offsite). |
Store a back-up copy of the application software and source code in a fire-rated container or store it separately (offsite) from their respective environments. |
Inherited as it is the responsibility of the deploying organization/user to ensure compliance with this requirement. |
|
9/9/2024 |
V-222639 |
| CP-09 (d) |
Procedures must be in place to assure the appropriate physical and technical protection of the backup and restoration of the application. |
Develop and implement procedures to insure that backup and restoration assets are properly protected and stored in an area/location where it is unlikely they would be affected by an event that would affect the primary assets. |
Inherited as it is the responsibility of the deploying organization/user to ensure compliance with this requirement. |
|
9/9/2024 |
V-222640 |
| IA-02 |
The application must uniquely identify and authenticate organizational users (or processes acting on behalf of organizational users). |
Configure the application to uniquely identify and authenticate users and user processes. |
Each user has a unique ID that is present in all requests and is logged with all requests |
|
9/9/2024 |
V-222522 |
| IA-02 (01) |
The application must use multifactor (Alt. Token) authentication for network access to privileged accounts. |
Configure the application to use an Alt. Token when providing network access to privileged application accounts. |
Heimdall can support any CAC-based or Alt. Token-based authentication method via an appropriate Passportjs approach: https://www.passportjs.org |
|
9/9/2024 |
V-222523 |
| IA-02 (02) |
The application must use multifactor (e.g., CAC, Alt. Token) authentication for network access to non-privileged accounts. |
Configure the application to require CAC or Alt. Token authentication for non-privileged network access to non-privileged accounts. |
Heimdall can support any CAC-based or Alt. Token-based authentication method via an appropriate Passportjs approach: https://www.passportjs.org |
|
9/9/2024 |
V-222526 |
| IA-02 (03) |
The application must use multifactor (Alt. Token) authentication for local access to privileged accounts. |
Configure the application to only use Alt. Tokens when locally accessing privileged application accounts. |
Heimdall can support any CAC-based or Alt. Token-based authentication method via an appropriate Passportjs approach: https://www.passportjs.org |
|
9/9/2024 |
V-222527 |
| IA-02 (04) |
The application must use multifactor (e.g., CAC, Alt. Token) authentication for local access to non-privileged accounts. |
Configure the application to require CAC or Alt. Token authentication for non-privileged network access. |
Heimdall can support any CAC-based or Alt. Token-based authentication method via an appropriate Passportjs approach: https://www.passportjs.org |
|
9/9/2024 |
V-222528 |
| IA-02 (05) |
The application must ensure users are authenticated with an individual authenticator prior to using a group authenticator. |
Design and configure the application to individually authenticate group account members prior to allowing access. |
Heimdall Server does allow for the creation of API keys to allow a remote server/service/device to upload data into Heimdall designated for review by specific teams of individuals with Heimdall. This is not intended to be used by individuals. |
|
9/9/2024 |
V-222529 |
| IA-02 (08) |
The application must implement replay-resistant authentication mechanisms for network access to privileged accounts. |
Design and configure the application to utilize replay-resistant mechanisms when authenticating privileged accounts. |
Heimdall Server uses JWT Session approach to resist replay authentication. |
|
9/9/2024 |
V-222530 |
| IA-02 (09) |
The application must implement replay-resistant authentication mechanisms for network access to non-privileged accounts. |
Design and configure the application to utilize replay-resistant mechanisms when authenticating non-privileged accounts. |
Heimdall Server uses JWT Session approach to resist replay authentication. |
|
9/9/2024 |
V-222531 |
| IA-02 (12) |
The application must accept Personal Identity Verification (PIV) credentials. |
Configure the application to require CAC authentication. |
Heimdall can support any CAC-based authentication method via an appropriate Passportjs approach: https://www.passportjs.org |
|
9/9/2024 |
V-222524 |
| IA-02 (12) |
The application must electronically verify Personal Identity Verification (PIV) credentials. |
Configure the application to require CAC authentication. |
Heimdall can support any CAC-based authentication method via an appropriate Passportjs approach: https://www.passportjs.org |
|
9/9/2024 |
V-222525 |
| IA-03 |
The application must utilize mutual authentication when endpoint device non-repudiation protections are required by organization policy or by the data owner. |
Configure the application to utilize mutual authentication when specified by data protection requirements. |
Creation of 'Group' API keys are permitted to allow a server/service/device to upload data to Heimdall Server for visibility to a certain group in Heimdall. Handling, provisioning, rotation, deletion and other management of such keys are the responsibility of the organizational procedures. |
|
9/9/2024 |
V-222532 |
| IA-03 |
The application must authenticate all network connected endpoint devices before establishing any connection. |
Configure the application to authenticate all network connected endpoint devices/service consumers before establishing connections. |
When 'Group' API keys are employed, the source server/service/device is not yet required to authenticate itself to the Heimdall Server at this time |
|
9/9/2024 |
V-222533 |
| IA-03 (01) |
Service-Oriented Applications handling non-releasable data must authenticate endpoint devices via mutual SSL/TLS. |
Configure the application to utilize mutual authentication when the application is processing non-releasable data. |
When 'Group' API keys are employed, the source server/service/device is not yet required to authenticate itself to the Heimdall Server at this time |
|
9/9/2024 |
V-222534 |
| IA-04 e |
The application must disable device identifiers after 35 days of inactivity unless a cryptographic certificate is used for authentication. |
Configure the application to disable device accounts after 35 days of inactivity or to utilize DoD PKI certificates that provide an expiration date. |
The application is not designed to authenticate devices. |
|
9/9/2024 |
V-222535 |
| IA-05 h |
The application password must not be changeable by users other than the administrator or the user with which the password is associated. |
Ensure users are only allowed to change their own passwords. |
This is implemented for local accounts. For integrated external authentication mechanisms, password management is an external process separate from Heimdall. |
|
9/9/2024 |
V-222548 |
| IA-05 (01) (a) |
The application must enforce password complexity by requiring that at least one upper-case character be used. |
Configure the application to require at least one upper-case character in the password. |
Heimdall Server supports this requirement for local accounts. When using an external authentication method, it is the responsibility of the organization to maintain this requirement. |
|
9/9/2024 |
V-222537 |
| IA-05 (01) (a) |
The application must enforce password complexity by requiring that at least one lower-case character be used. |
Configure the application to require at least one lower-case character in the password. |
Heimdall Server supports this requirement for local accounts. When using an external authentication method, it is the responsibility of the organization to maintain this requirement. |
|
9/9/2024 |
V-222538 |
| IA-05 (01) (a) |
The application must enforce password complexity by requiring that at least one numeric character be used. |
Configure the application to require at least one numeric character in the password. |
Heimdall Server supports this requirement for local accounts. When using an external authentication method, it is the responsibility of the organization to maintain this requirement. |
|
9/9/2024 |
V-222539 |
| IA-05 (01) (a) |
The application must enforce a minimum 15-character password length. |
Configure the application to require 15 characters in the password. |
Heimdall Server supports this requirement for local accounts. When using an external authentication method, it is the responsibility of the organization to maintain this requirement. |
|
9/9/2024 |
V-222536 |
| IA-05 (01) (a) |
The application must enforce password complexity by requiring that at least one special character be used. |
Configure the application to require at least one special character in the password. |
Heimdall Server supports this requirement for local accounts. When using an external authentication method, it is the responsibility of the organization to maintain this requirement. |
|
9/9/2024 |
V-222540 |
| IA-05 (01) (b) |
The application must require the change of at least 8 of the total number of characters when passwords are changed. |
Configure the application to require the change of at least 8 characters in the password when passwords are changed. |
Heimdall Server supports this requirement for local accounts. When using an external authentication method, it is the responsibility of the organization to maintain this requirement. |
|
9/9/2024 |
V-222541 |
| IA-05 (01) (c) |
The application must only store cryptographic representations of passwords. |
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. |
Heimdall Server supports this requirement for local accounts. When using an external authentication method, it is the responsibility of the organization to maintain this requirement. |
|
9/9/2024 |
V-222542 |
| IA-05 (01) (c) |
The application must transmit only cryptographically-protected passwords. |
Configure the application to encrypt passwords when they are being transmitted. |
Heimdall Server supports this requirement for local accounts. When using an external authentication method, it is the responsibility of the organization to maintain this requirement. |
|
9/9/2024 |
V-222543 |
| IA-05 (01) (d) |
The application must enforce 24 hours/1 day as the minimum password lifetime. |
Configure the application to have a minimum password lifetime of 24 hours. |
Heimdall Server supports this requirement for local accounts. When using an external authentication method, it is the responsibility of the organization to maintain this requirement. |
|
9/9/2024 |
V-222544 |
| IA-05 (01) (d) |
The application must enforce a 60-day maximum password lifetime restriction. |
Configure the application to have a maximum password lifetime of 60 days. |
Heimdall Server supports this requirement for local accounts. When using an external authentication method, it is the responsibility of the organization to maintain this requirement. |
|
9/9/2024 |
V-222545 |
| IA-05 (01) (e) |
The application must prohibit password reuse for a minimum of five generations. |
Configure the application to prohibit password reuse for up to 5 passwords. |
Heimdall Server supports this requirement for local accounts. When using an external authentication method, it is the responsibility of the organization to maintain this requirement. |
|
9/9/2024 |
V-222546 |
| IA-05 (01) (f) |
The application must allow the use of a temporary password for system logons with an immediate change to a permanent password. |
Configure the application to specify when a password is temporary and change the temporary password on the first use. |
Heimdall Server supports this requirement for local accounts. When using an external authentication method, it is the responsibility of the organization to maintain this requirement. |
|
9/9/2024 |
V-222547 |
| IA-05 (02) (a) (01) |
The application, when using PKI-based authentication, must enforce authorized access to the corresponding private key. |
Configure the application or relevant access control mechanism to enforce authorized access to the application private key(s). |
Heimdall can support any CAC-based authentication method via an appropriate Passportjs approach: https://www.passportjs.org |
|
9/9/2024 |
V-222551 |
| IA-05 (02) (a) (02) |
The application must map the authenticated identity to the individual user or group account for PKI-based authentication. |
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. |
Heimdall can support any CAC-based authentication method via an appropriate Passportjs approach: https://www.passportjs.org |
|
9/9/2024 |
V-222552 |
| IA-05 (02) (b) (01) |
The application, when utilizing PKI-based authentication, must validate certificates by constructing a certification path (which includes status information) to an accepted trust anchor. |
Design the application to construct a certification path to an accepted trust anchor when using PKI-based authentication. |
Heimdall can support any CAC-based authentication method via an appropriate Passportjs approach: https://www.passportjs.org |
|
9/9/2024 |
V-222550 |
| IA-05 (02) (d) |
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. |
Implement a Certificate Revocation List (CRL) import process and configure the application to check the CRL if OCSP is not available. |
Heimdall can support any CAC-based authentication method via an appropriate Passportjs approach: https://www.passportjs.org |
|
9/9/2024 |
V-222553 |
| IA-05 (06) |
The application must use encryption to implement key exchange and authenticate endpoints prior to establishing a communication channel for key exchange. |
Use encryption for key exchange. |
Heimdall Server does not use key exchange, hence this requirement is not applicable. |
|
9/9/2024 |
V-222641 |
| IA-05 (07) |
The application must not contain embedded authentication data. |
Remove embedded authentication data stored in code, configuration files, scripts, HTML file, or any ASCII files. |
No passwords or sensitive data are included in documentation or source code. The server administrator is reminded to secure environment variables and initial passwords designated or assigned upon initial deployment. |
|
9/9/2024 |
V-222642 |
| IA-05 (13) |
The application must terminate existing user sessions upon account deletion. |
Configure the application to terminate existing sessions of users whose accounts are deleted. |
At this time, a deleted user's active session does not immediately automatically terminate. |
Yes |
9/9/2024 |
V-222549 |
| IA-06 |
The application must not display passwords/PINs as clear text. |
Configure the application to obfuscate passwords and PINs when they are being entered so they cannot be read. Design the application so obfuscated passwords cannot be copied and then pasted as clear text. |
Heimdall Server does not display passwords/PINS as clear text. |
|
9/9/2024 |
V-222554 |
| IA-07 |
The application must use mechanisms meeting the requirements of applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance for authentication to a cryptographic module. |
Use FIPS-approved cryptographic modules. |
Heimdall Server does not provide authenticated access to a cryptographic module. The requirement is not applicable. |
|
9/9/2024 |
V-222555 |
| IA-08 |
The application must uniquely identify and authenticate non-organizational users (or processes acting on behalf of non-organizational users). |
Configure the application to identify and authenticate all non-organizational users. |
Heimdall can support any PIV-based, CAC-based or Alt. Token-based authentication method via an appropriate Passportjs approach: https://www.passportjs.org |
|
9/9/2024 |
V-222556 |
| IA-08 (01) |
The application must accept Personal Identity Verification (PIV) credentials from other federal agencies. |
Configure the application to accept PIV credentials when utilizing authentication provided by Federal (Non-DoD) agencies. |
Heimdall can support any PIV-based, CAC-based or Alt. Token-based authentication method via an appropriate Passportjs approach: https://www.passportjs.org |
|
9/9/2024 |
V-222557 |
| IA-08 (01) |
The application must electronically verify Personal Identity Verification (PIV) credentials from other federal agencies. |
Configure the application to verify the PIV credentials presented when utilizing authentication provided by Federal (Non-DoD) agencies. |
Heimdall can support any PIV-based, CAC-based or Alt. Token-based authentication method via an appropriate Passportjs approach: https://www.passportjs.org |
|
9/9/2024 |
V-222558 |
| IA-08 (02) |
The application must accept FICAM-approved third-party credentials. |
Configure applications intended to be accessible to non-federal government agencies to use FICAM-approved third-party credentials. |
Heimdall can support any PIV-based, CAC-based or Alt. Token-based authentication method via an appropriate Passportjs approach: https://www.passportjs.org |
|
9/9/2024 |
V-222559 |
| IA-08 (04) |
The application must conform to FICAM-issued profiles. |
Configure the application to conform to FICAM-issued technical profiles when providing services that rely on external (Federal Government) identity providers. |
Heimdall can support any PIV-based, CAC-based or Alt. Token-based authentication method via an appropriate Passportjs approach: https://www.passportjs.org |
|
9/9/2024 |
V-222560 |
| IA-11 |
The application must require users to reauthenticate when organization-defined circumstances or situations require reauthentication. |
Configure the application to require reauthentication before user privilege is escalated and user roles are changed. |
Heimdall Server requires separate accounts for user vs administrator roles. |
|
9/9/2024 |
V-222520 |
| IA-11 |
The application must require devices to reauthenticate when organization-defined circumstances or situations requiring reauthentication. |
Configure the application to require reauthentication periodically. |
Heimdall Server is does not provide for device authentication, hence this requirement is not applicable. |
|
9/9/2024 |
V-222521 |
| MA-04 c |
The application must employ strong authenticators in the establishment of non-local maintenance and diagnostic sessions. |
Configure the application to use strong authentication when accessing the application for maintenance purposes. |
Heimdall Server does not provide any non-local maintenance and diagnostic capability, this requirement is not applicable. |
|
9/9/2024 |
V-222565 |
| MA-04 e |
The application must terminate all sessions and network connections when non-local maintenance is completed. |
Configure the application to expire idle user sessions after 10 minutes of inactivity for admin users and after 15 minutes of inactivity for regular users. |
Heimdall Server does not provide any non-local maintenance and diagnostic capability, this requirement is not applicable. |
|
9/9/2024 |
V-222566 |
| MA-04 (01) (a) |
Applications used for non-local maintenance sessions must audit non-local maintenance and diagnostic sessions for organization-defined auditable events. |
Configure the application to log when application maintenance functionality is executed remotely. |
Heimdall Server does not provide any non-local maintenance and diagnostic capability, this requirement is not applicable. |
|
9/9/2024 |
V-222561 |
| MA-04 (06) |
Applications used for non-local maintenance sessions must implement cryptographic mechanisms to protect the integrity of non-local maintenance and diagnostic communications. |
Configure the application to encrypt remote application maintenance sessions. |
Heimdall Server does not provide any non-local maintenance and diagnostic capability, this requirement is not applicable. |
|
9/9/2024 |
V-222562 |
| MA-04 (06) |
Applications used for non-local maintenance sessions must implement cryptographic mechanisms to protect the confidentiality of non-local maintenance and diagnostic communications. |
Configure the application to encrypt remote application maintenance sessions. |
Heimdall Server does not provide any non-local maintenance and diagnostic capability, this requirement is not applicable. |
|
9/9/2024 |
V-222563 |
| MA-04 (07) |
Applications used for non-local maintenance sessions must verify remote disconnection at the termination of non-local maintenance and diagnostic sessions. |
Configure the application to verify termination of remote maintenance sessions. |
Heimdall Server does not provide any non-local maintenance and diagnostic capability, this requirement is not applicable. |
|
9/9/2024 |
V-222564 |
| MP-03 a |
The application must have the capability to mark sensitive/classified output when required. |
Enable the application to adequately mark sensitive/classified output. |
System classification banner is configurable based on the sensitivity of the network Heimdall Server is deployed on. |
|
9/9/2024 |
V-222643 |
| PM-14 a 2 |
Prior to each release of the application, updates to system, or applying patches; tests plans and procedures must be created and executed. |
Execute tests plans prior to release or patch update. |
Automated unit, functional, and integration testing occurs before and after each release. See .GitHub/workflow folder within the source code for related job definitions |
|
9/9/2024 |
V-222644 |
| SA-04 (05) (a) |
Default passwords must be changed. |
Configure the application to use strong authenticators instead of passwords when possible. Otherwise, change default passwords to a DoD-approved strength password and follow all guidance for passwords. |
Heimdall Server does not implement default passwords |
|
9/9/2024 |
V-222662 |
| SA-04 (05) (a) |
Unnecessary built-in application accounts must be disabled. |
Disable unnecessary built-in userids, use other strong authentication when possible and use strong passwords if accounts are necessary for application operation. |
There is only one administrator account built-in and it is necessary. The password for the built-in administrator account is randomized upon initial startup and is required to be changed at first login. |
|
9/9/2024 |
V-222661 |
| SA-05 a 1 |
If the application contains classified data, a Security Classification Guide must exist containing data elements and their classification. |
Create and maintain a security classification guide. |
This requirement is the responsibility of the organization deploying instances of Heimdall Server. |
|
9/9/2024 |
V-222664 |
| SA-05 a 1 |
An Application Configuration Guide must be created and included with the application. |
Create the application configuration guide in accordance with configuration examples provided in the vulnerability discussion and check. Verify the application configuration guide is distributed along with the application. |
Documentation for configuration and deployment is provided at the primary GitHub repository for Heimdall Server. |
|
9/9/2024 |
V-222663 |
| SA-10 (01) |
Application files must be cryptographically hashed prior to deploying to organization operational networks. |
Developers/release managers create cryptographic hash values of application files and/or application packages prior to transitioning the application from test to a production environment. They protect cryptographic hash information so it cannot be altered and make a read copy of the hash information available to application Admins so they can validate application packages and files after they download the files. Application Admins validate cryptographic hashes prior to deploying the application to production. |
Organization is responsible for cryptographically hashing application files prior to deploying on organization networks. |
|
9/9/2024 |
V-222645 |
| SA-11 b |
The changes to the application must be assessed for IA and accreditation impact prior to implementation. |
Review IA impact to the system prior to implementing changes. |
The Heimdall Server GitHub repository undergoes continuous automated dependency, static, and secrets scanning, and each release is secured/patched accordingly. Unit tests are performed via GitHub Actions at every commit, including to validate security functionality. Manual code review is also accomplished via peer review, as well as paired programming throughout code development. |
|
9/9/2024 |
V-222651 |
| SA-11 e |
The application must not be vulnerable to race conditions. |
Be aware of potential timing issues related to application programming calls when designing and building the application. Validate that variable values do not change while a switch event is occurring. |
The Heimdall Server GitHub repository undergoes continuous automated dependency, static, and secrets scanning. https://github.com/mitre/heimdall2/security |
|
9/9/2024 |
V-222567 |
| SA-11 e |
Security flaws must be fixed or addressed in the project plan. |
Address security flaws within a project plan to ensure they are tracked and addressed by management. |
Users are encouraged to submit security issues to the application developers [email protected] as well as submit issues on GitHub |
|
9/9/2024 |
V-222652 |
| SA-11 (02) |
At least one tester must be designated to test for security flaws in addition to functional testing. |
Designate personnel to conduct security testing on the applications. |
Automated unit, functional, and integration testing occurs before and after each release. |
|
9/9/2024 |
V-222646 |
| SA-11 (02) |
Test procedures must be created and at least annually executed to ensure system initialization, shutdown, and aborts are configured to verify the system remains in a secure state. |
Create test procedures to test the security state of the application and exercise test procedures annually. |
The Heimdall Server GitHub repository undergoes continuous automated dependency, static, and secrets scanning, and each release is secured/patched accordingly. Unit tests are performed via GitHub Actions at every commit, including to validate security functionality. Manual code review is also accomplished via peer review, as well as paired programming throughout code development. |
|
9/9/2024 |
V-222647 |
| SA-11 (04) |
An application code review must be performed on the application. |
Conduct and document code reviews on the application during development and identify and remediate all known and potential security vulnerabilities prior to releasing the application. |
The Heimdall Server GitHub repository undergoes continuous automated dependency, static, and secrets scanning, and each release is secured/patched accordingly. Unit tests are performed via GitHub Actions at every commit, including to validate security functionality. Manual code review is also accomplished via peer review, as well as paired programming throughout code development. |
|
9/9/2024 |
V-222648 |
| SA-11 (04) |
Code coverage statistics must be maintained for each release of the application. |
Track application testing and maintain statistics that show how much of the application function was tested. |
The Heimdall Server GitHub repository undergoes continuous automated dependency, static, and secrets scanning, and each release is secured/patched accordingly. Unit tests are performed via GitHub Actions at every commit, including to validate security functionality. Manual code review is also accomplished via peer review, as well as paired programming throughout code development. |
|
9/9/2024 |
V-222649 |
| SA-11 (08) |
Flaws found during a code review must be tracked in a defect tracking system. |
Track software defects in a defect tracking system. |
All issues found during code review of primary Heimdall repository are logged as issues in GitHub. The Heimdall Server GitHub repository undergoes continuous automated dependency, static, and secrets scanning, and each release is secured/patched accordingly. Unit tests are performed via GitHub Actions at every commit, including to validate security functionality. Manual code review is also accomplished via peer review, as well as paired programming throughout code development. |
|
9/9/2024 |
V-222650 |
| SA-15 a |
The application development team must follow a set of coding standards. |
Create and maintain a coding standard process and documentation for developers to follow. Include programming best practices based on the languages being used for application development. Include items that should be standardized across the team that that deal with how developers write their application code. |
The Heimdall Server GitHub repository undergoes continuous automated dependency, static, and secrets scanning, and each release is secured/patched accordingly. Unit tests are performed via GitHub Actions at every commit, including to validate security functionality. Manual code review is also accomplished via peer review, as well as paired programming throughout code development. |
|
9/9/2024 |
V-222653 |
| SA-15 (04) |
Threat models must be documented and reviewed for each application release and updated as required by design and functionality changes or when new threats are discovered. |
Establish and maintain threat models and review for each application release and when new threats are discovered. Identify potential mitigations to identified threats. Verify mitigations are implemented to threats based on their risk analysis. |
Threat model documentation and implementation of mitigations is the responsibility of the deploying organization. |
|
9/9/2024 |
V-222655 |
| SA-15 (05) |
The application must not be subject to error handling vulnerabilities. |
Ensure proper return code and exception handling is implemented throughout the application. |
Heimdall Server has automated testing, code reviews, and vulnerability testing to ensure proper return code and exception handling is implemented. |
|
9/9/2024 |
V-222656 |
| SA-15 (10) |
The application development team must provide an application incident response plan. |
The development team creates an application incident response plan documenting and establishing a process that at a minimum: - Tracks reported vulnerabilities and bugs - Confirms reported vulnerabilities and bugs - Tracks remediation effort - Notifies application users of available updates that address the reported issues. |
All issues found during code review of primary Heimdall repository are logged as issues in GitHub. The Heimdall Server GitHub repository undergoes continuous automated dependency, static, and secrets scanning, and each release is secured/patched accordingly. Unit tests are performed via GitHub Actions at every commit, including to validate security functionality. Manual code review is also accomplished via peer review, as well as paired programming throughout code development. |
|
9/9/2024 |
V-222657 |
| SA-22 a |
All products must be supported by the vendor or the development team. |
Remove or decommission all unsupported software products in the application. |
Heimdall Server is supported by the development team at the primary GitHub repository. |
|
9/9/2024 |
V-222658 |
| SA-22 a |
The application must be decommissioned when maintenance or support is no longer available. |
Ensure there is maintenance for the application. |
Heimdall Server is supported by the development team at the primary GitHub repository. |
|
9/9/2024 |
V-222659 |
| SA-22 b |
Procedures must be in place to notify users when an application is decommissioned. |
Create and establish procedures to notify users when an application is decommissioned. |
Heimdall Server maintains a list of supported versions on GitHub |
|
9/9/2024 |
V-222660 |
| SC-02 |
The application user interface must be either physically or logically separated from data storage and management interfaces. |
Configure the application so user interface to the application and management interface to the application is separated. |
Application administrative functions are only available within the graphical interface to application users assigned the admin role. Direct database administration is only available to separate accounts for administrators acting via the operating system level. |
|
9/9/2024 |
V-222574 |
| SC-03 |
The application must isolate security functions from non-security functions. |
Implement controls within the application that limits access to security configuration functionality and isolates regular application function from security-oriented function. |
The application utilizes application based access control with policies enforced by the application's authorization service and policies written by application developers. These policies mediate access to every API endpoint and thus any change, request, or destruction of data. |
|
9/9/2024 |
V-222590 |
| SC-04 |
Applications must prevent unauthorized and unintended information transfer via shared system resources. |
 Configure or design the application to utilize a security control that will implement a boundary that will prevent unauthorized and unintended information transfer via shared system resources. |
Heimdall Server does not share information resources via file sharing protocol, nor does it include configuration settings that provide access to data files on the hard drive. |
|
9/9/2024 |
V-222592 |
| SC-05 |
Protections against DoS attacks must be implemented. |
Implement mitigations from the threat model for DOS attacks. |
Threat model documentation and implementation of mitigations is the responsibility of the deploying organization. |
|
9/9/2024 |
V-222667 |
| SC-05 (01) |
The application must restrict the ability to launch Denial of Service (DoS) attacks against itself or other information systems. |
Design and deploy the application to utilize controls that will prevent the application from being affected by DoS attacks or being used to attack other systems. This includes but is not limited to utilizing throttling techniques for application traffic such as QoS or implementing logic controls within the application code itself that prevents application use that results in network or system capabilities being exceeded. |
DoS protection is dependent on the user-configuration of network protections within their organization. |
|
9/9/2024 |
V-222594 |
| SC-05 (02) |
The web service design must include redundancy mechanisms when used with high-availability systems. |
Build the application to address issues that are found in a redundant environment and utilize redundancy mechanisms to provide high availability. |
As a basic node application and database behind a reverse proxy, Heimdall Server can be deployed for highly available configurations depending on an organizations own preferences. |
|
9/9/2024 |
V-222595 |
| SC-07 (13) |
Connections between the organization enclave and the Internet or other public or commercial wide area networks must require a DMZ. |
Setup a DMZ between organization and public networks. |
DMZ configuration is the responsibility of the deploying organization. |
|
9/9/2024 |
V-222671 |
| SC-08 |
The application must protect the confidentiality and integrity of transmitted information. |
Configure all of the application systems to require TLS encryption in accordance with data protection requirements. |
For docker deployments an nginx reverse proxy is provided to implement TLS. For user-hosted deployments, users can provide their own reverse proxy to implement TLS. |
|
9/9/2024 |
V-222596 |
| SC-08 (01) |
The application must implement cryptographic mechanisms to prevent unauthorized disclosure of information and/or detect changes to information during transmission unless otherwise protected by alternative physical safeguards, such as, at a minimum, a Protected Distribution System (PDS). |
Configure the application to use cryptographic protections to prevent unauthorized disclosure of application data based upon the application architecture. |
For docker deployments an nginx reverse proxy is provided to implement TLS. For user-hosted deployments, users can provide their own reverse proxy to implement TLS. |
|
9/9/2024 |
V-222597 |
| SC-08 (02) |
The application must maintain the confidentiality and integrity of information during preparation for transmission. |
Configure all of the application systems to require TLS encryption. |
For docker deployments an nginx reverse proxy is provided to implement TLS. For user-hosted deployments, users can provide their own reverse proxy to implement TLS. |
|
9/9/2024 |
V-222598 |
| SC-08 (02) |
The application must not disclose unnecessary information to users. |
Configure the application to not display technical details about the application architecture on error events. |
The error handler for users is set to only pass along relevant information. |
|
9/9/2024 |
V-222600 |
| SC-08 (02) |
The application must not store sensitive information in hidden fields. |
Design and configure the application to not store sensitive information in hidden fields. |
Sensitive information is not stored in hidden fields. |
|
9/9/2024 |
V-222601 |
| SC-08 (02) |
The application must maintain the confidentiality and integrity of information during reception. |
Configure all of the application systems to require TLS encryption. |
For docker deployments an nginx reverse proxy is provided to implement TLS. For user-hosted deployments, users can provide their own reverse proxy to implement TLS. |
|
9/9/2024 |
V-222599 |
| SC-10 |
The application must terminate all network connections associated with a communications session at the end of the session. |
Configure or design the application to terminate application network sessions at the end of the session. |
HTTP-based - there are no open connections to and from other systems as part of their design and function. |
|
9/9/2024 |
V-222568 |
| SC-13 b |
The application must utilize FIPS-validated cryptographic modules when signing application components. |
Utilize FIPS-validated algorithms when signing application components. |
At this time, it is unclear if all packages created via Github Actions at the primary Heimdall Server repository are signed using FIPS 140-2 validated cryptographic modules. Addressing under https://github.com/mitre/heimdall2/pull/4850 |
Yes |
9/9/2024 |
V-222570 |
| SC-13 b |
The application must utilize FIPS-validated cryptographic modules when generating cryptographic hashes. |
Configure the application to use a FIPS-validated hashing algorithm when creating a cryptographic hash. |
Heimdall Server uses bcryptjs for encryption/hashing, which at this time is NOT a validated FIPS 140-2 library. Addressing under https://github.com/mitre/heimdall2/pull/4850 |
Yes |
9/9/2024 |
V-222571 |
| SC-13 b |
The application must utilize FIPS-validated cryptographic modules when protecting unclassified information that requires cryptographic protection. |
Configure the application to use a FIPS-validated cryptographic module. |
Heimdall Server uses bcryptjs for encryption/hashing, which at this time is NOT a validated FIPS 140-2 library. Addressing under https://github.com/mitre/heimdall2/pull/4850 |
Yes |
9/9/2024 |
V-222572 |
| SC-13 b |
The application must implement organization-approved cryptography to protect sensitive organization information. |
Configure application to encrypt stored sensitive mission information |
Heimdall Server can be configured to encrypt stored classified results data by implementing the correct modules/settings on PostgreSQL and hosting operating system. |
|
9/9/2024 |
V-254803 |
| SC-18 (01) |
Unsigned Category 1A mobile code must not be used in the application. |
Configure the application so Category 1A mobile code is signed. |
Heimdall Server does not use mobile code. |
|
9/9/2024 |
V-222618 |
| SC-18 (02) |
The designer must ensure uncategorized or emerging mobile code is not used in applications. |
Remove uncategorized or emerging mobile code from the application or obtain a waiver and risk acceptance to operate. |
Heimdall does not contain any uncategorized mobile code. |
|
9/9/2024 |
V-222665 |
| SC-23 |
The application must set the HTTPOnly flag on session cookies. |
Configure the application to set the HTTPOnly flag on session cookies. |
Heimdall Server cannot set the HTTP_ONLY flag on the JWT, which is stored in a cookie. This particular cookie must be read by the frontend application JavaScript to perform API requests. For docker deployments an nginx reverse proxy is provided to implement HTTP_ONLY flag. For user-hosted deployments, users can provide their own reverse proxy to implement HTTP_ONLY flag. |
|
9/9/2024 |
V-222575 |
| SC-23 |
The application must set the secure flag on session cookies. |
Configure the application to ensure the secure flag is set on session cookies. |
Heimdall Server supports the secure flag set on session cookies. |
|
9/9/2024 |
V-222576 |
| SC-23 |
The application must not expose session IDs. |
Configure the application to protect session IDs from interception or from manipulation. |
Heimdall Server protects session IDs from interception or from manipulation. |
|
9/9/2024 |
V-222577 |
| SC-23 (01) |
The application must destroy the session ID value and/or cookie on logoff or browser close. |
Configure the application to destroy session ID cookies once the application session has terminated. |
Once a User clicks 'Log Off' the JWT is destroyed |
|
9/9/2024 |
V-222578 |
| SC-23 (03) |
The application must use the Federal Information Processing Standard (FIPS) 140-2-validated cryptographic modules and random number generator if the application implements encryption, key exchange, digital signature, and hash functionality. |
Configure the application to use FIPS 140-2-validated cryptographic modules when the application implements encryption, key exchange, digital signatures, random number generators, and hash functionality. |
Heimdall Server uses bcryptjs for encryption/hashing, which at this time is NOT a validated FIPS 140-2 library. Addressing under https://github.com/mitre/heimdall2/pull/4850 |
Yes |
9/9/2024 |
V-222583 |
| SC-23 (03) |
Applications must use system-generated session identifiers that protect against session fixation. |
Design the application to generate new session IDs with unique values when authenticating user sessions. |
JWT tokens are generated for users with a secure random secret generated on a per-user basis. |
|
9/9/2024 |
V-222579 |
| SC-23 (03) |
Applications must validate session identifiers. |
Configure the application to configure user session identifiers. |
Heimdall Server uses the JavaScript framework Passport to manage JWT. JWTs are cryptographically signed with a Server secret that is validated on every request to the API. |
|
9/9/2024 |
V-222580 |
| SC-23 (03) |
Applications must not use URL embedded session IDs. |
Configure the application to transmit session ID information via cookies. |
Heimdall Server uses the JavaScript framework Passport to manage JWT. JWTs are generated by Passport by cryptographically signing a token object containing the User's: email, role, database primary key, and if they are required to change their password |
|
9/9/2024 |
V-222581 |
| SC-23 (03) |
The application must not re-use or recycle session IDs. |
Design the application to not re-use session IDs. |
Heimdall Server uses the JavaScript Passport Framework to manage JWT. Since JWT do not have a unique ID associated with them this is not applicable. |
|
9/9/2024 |
V-222582 |
| SC-23 (05) |
The application must only allow the use of organization-approved certificate authorities for verification of the establishment of protected sessions. |
Configure the application to utilize organization-approved PKI established CAs when verifying organization-signed certificates. |
Users are able to supply their own certificates and this process is covered in the Heimdall documentation |
|
9/9/2024 |
V-222584 |
| SC-24 |
The application must fail to a secure state if system initialization fails, shutdown fails, or aborts fail. |
Fix any vulnerability found when the application is an insecure state (initialization, shutdown and aborts). |
The Heimdall Server application logic and backend PostgreSQL database operate independently. Each has its own method to fail into a secure state if initialization, shutdown, or abort fails. |
|
9/9/2024 |
V-222585 |
| SC-24 |
In the event of a system failure, applications must preserve any information necessary to determine cause of failure and any information necessary to return to operations with least disruption to mission processes. |
Create operational configuration documentation that identifies information needed for the application to return back into service or specify no such data is required, and retain data required to determine root cause of application failures. |
The application will log any errors that lead to a crash. |
|
9/9/2024 |
V-222586 |
| SC-28 |
The application must protect the confidentiality and integrity of stored information when required organization policy or the information owner. |
Identify data elements that require protection. Document the data types and specify protection requirements and methods used. |
The application utilizes application based access control with policies enforced by the application's authorization service and policies written by application developers. These policies mediate access to every API endpoint and thus any change, request, or destruction of data. |
|
9/9/2024 |
V-222587 |
| SC-28 (01) |
The application must implement approved cryptographic mechanisms to prevent unauthorized modification of organization-defined information at rest on organization-defined information system components. |
Identify data elements that require protection. Document the data types and specify encryption requirements. Encrypt data according to DoD policy or data owner requirements. |
The organization can meet this requirement by configuring underlying OS and PostgreSQL STIG encryption. |
|
9/9/2024 |
V-222588 |
| SC-28 (01) |
The application must use appropriate cryptography in order to protect stored organization information when required by the information owner or organization policy. |
Identify data elements that require protection. Document the data types and specify encryption requirements. Encrypt organization data using organization-approved encryption solutions. |
The organization can meet this requirement by configuring underlying OS and PostgreSQL STIG encryption. |
|
9/9/2024 |
V-222589 |
| SC-28 (02) |
Production database exports must have database administration credentials and sensitive data removed before releasing the export. |
Remove sensitive data from production database exports. |
The organization deploying/using Heimdall Server is responsible for restricting data exports from its production database to include removing sensitive organization data. |
|
9/9/2024 |
V-222666 |
| SC-39 |
The application must maintain a separate execution domain for each executing process. |
Design and configure applications to maintain a separate execution domain for each executing process. |
Docker method: Heimdall Server can be deployed with three docker containers to isolate system components: nginx server, the web application server, and the database. User-hosted method: Heimdall Server can be configured with each component placed in a separate host/network. |
|
9/9/2024 |
V-222591 |
| SI-02 c |
Security-relevant software updates and patches must be kept up to date. |
Check for application updates at least weekly and apply patches immediately or in accordance with POA&Ms, IAVMs, CTOs, DTMs or other authoritative patching guidelines or sources. |
The Heimdall Server GitHub repository undergoes continuous automated dependency, static, and secrets scanning, and each release is patched accordingly. The application is following this Application Security & Development STIG and using vendor best practices. At- and post-deployment, it is the responsibility of the organization to update it to the latest release of Heimdall code, as well as apply patches to the underlying operating system and database. |
|
9/9/2024 |
V-222614 |
| SI-02 (06) |
The application must remove organization-defined software components after updated versions have been installed. |
Configure or design the application to remove old components when updating. |
The Heimdall Server GitHub repository undergoes continuous automated dependency, static, and secrets scanning, and each release is patched accordingly. The application is following this Application Security & Development STIG and using vendor best practices. At- and post-deployment, it is the responsibility of the organization to update it to the latest release of Heimdall code, as well as apply patches to the underlying operating system and database. |
|
9/9/2024 |
V-222613 |
| SI-04 (12) |
The system must alert an administrator when low resource conditions are encountered. |
Implement mechanisms to alert system administrators about a low resource condition. |
Management of low resource conditions are the responsibility of the deploying organization. |
|
9/9/2024 |
V-222668 |
| SI-05 a |
At least one application administrator must be registered to receive update notifications, or security alerts, when automated alerts are available. |
Register administrators to receive update notifications so they can patch and update applications and application components. |
The Heimdall Server GitHub repository undergoes continuous automated dependency, static, and secrets scanning, and each release is patched accordingly. The application is following this Application Security & Development STIG and using vendor best practices. At- and post-deployment, it is the responsibility of the organization to update it to the latest release of Heimdall code, as well as apply patches to the underlying operating system and database. Personnel responsible for receipt/review of patch notifications and GitHub releases are assigned by the organization deploying their Heimdall instance. |
|
9/9/2024 |
V-222669 |
| SI-05 b |
The application must provide notifications or alerts when product update and security related patches are available. |
Provide a distribution mechanism for obtaining updates to the application. Include a description of the issue, a summary of risk as well as potential mitigations and how to obtain the update. |
The Heimdall Server GitHub repository undergoes continuous automated dependency, static, and secrets scanning, and each release is patched accordingly. The application is following this Application Security & Development STIG and using vendor best practices. At- and post-deployment, it is the responsibility of the organization to update it to the latest release of Heimdall code, as well as apply patches to the underlying operating system and database. |
|
9/9/2024 |
V-222670 |
| SI-06 a |
The application performing organization-defined security functions must verify correct operation of security functions. |
Design the application to verify the correct operation of security functions. |
The Heimdall Server GitHub repository undergoes continuous automated dependency, static, and secrets scanning, and each release is patched accordingly. Unit tests are performed via GitHub Actions at every commit, including to validate security functionality. |
|
9/9/2024 |
V-222615 |
| SI-06 b |
The application must perform verification of the correct operation of security functions: upon system startup and/or restart; upon command by a user with privileged access; and/or every 30 days. |
Design the application to verify the correct operation of security functions on command and on application startup and restart. |
The Heimdall Server GitHub repository undergoes continuous automated dependency, static, and secrets scanning, and each release is patched accordingly. Unit tests are performed via GitHub Actions at every commit, including to validate security functionality. |
|
9/9/2024 |
V-222616 |
| SI-06 c |
The application must notify the ISSO and ISSM of failed security verification tests. |
Configure the application to send notices to the ISSO and ISSM indicating the application failed a verification test. |
The Heimdall Server GitHub repository undergoes continuous automated dependency, static, and secrets scanning, and each release is patched accordingly. Unit tests are performed via GitHub Actions at every commit, including to validate security functionality. ISSOs and ISSMs can sign up for alerts from these automated tests. |
|
9/9/2024 |
V-222617 |
| SI-10 |
The application must protect from Cross-Site Scripting (XSS) vulnerabilities. |
Verify user input is validated and encode or escape user input to prevent embedded script code from executing. Develop your application using a web template system or a web application development framework that provides auto escaping features rather than building your own escape logic. |
The Heimdall Server GitHub repository undergoes continuous automated dependency, static, and secrets scanning, and each release is secured/patched accordingly. Unit tests are performed via GitHub Actions at every commit, including to validate security functionality. |
|
9/9/2024 |
V-222602 |
| SI-10 |
The application must protect from Cross-Site Request Forgery (CSRF) vulnerabilities. |
Configure the application to use unpredictable challenge tokens and check the HTTP referrer to ensure the request was issued from the site itself. Implement mitigating controls as required such as using web reputation services. |
The Heimdall Server GitHub repository undergoes continuous automated dependency, static, and secrets scanning, and each release is secured/patched accordingly. Unit tests are performed via GitHub Actions at every commit, including to validate security functionality. |
|
9/9/2024 |
V-222603 |
| SI-10 |
The application must protect from command injection. |
Modify the application so as to escape/sanitize special character input or configure the system to protect against command injection attacks based on application architecture. |
The Heimdall Server GitHub repository undergoes continuous automated dependency, static, and secrets scanning, and each release is secured/patched accordingly. Unit tests are performed via GitHub Actions at every commit, including to validate security functionality. |
|
9/9/2024 |
V-222604 |
| SI-10 |
The application must protect from canonical representation vulnerabilities. |
A suitable canonical form should be chosen and all user input canonicalized into that form before any authorization decisions are performed. Security checks should be carried out after decoding is completed. Moreover, it is recommended to check that the encoding method chosen is a valid canonical encoding for the symbol it represents. |
The Heimdall Server GitHub repository undergoes continuous automated dependency, static, and secrets scanning, and each release is secured/patched accordingly. Unit tests are performed via GitHub Actions at every commit, including to validate security functionality. |
|
9/9/2024 |
V-222605 |
| SI-10 |
The application must validate all input. |
Design and configure the application to validate input prior to executing commands. |
The Heimdall Server GitHub repository undergoes continuous automated dependency, static, and secrets scanning, and each release is secured/patched accordingly. Unit tests are performed via GitHub Actions at every commit, including to validate security functionality. |
|
9/9/2024 |
V-222606 |
| SI-10 |
The application must not be vulnerable to SQL Injection. |
Modify the application and remove SQL injection vulnerabilities. |
The Heimdall Server GitHub repository undergoes continuous automated dependency, static, and secrets scanning, and each release is secured/patched accordingly. Unit tests are performed via GitHub Actions at every commit, including to validate security functionality. |
|
9/9/2024 |
V-222607 |
| SI-10 |
The application must not be vulnerable to XML-oriented attacks. |
Design the application to utilize components that are not vulnerable to XML attacks. Patch the application components when vulnerabilities are discovered. |
The Heimdall Server GitHub repository undergoes continuous automated dependency, static, and secrets scanning, and each release is secured/patched accordingly. Unit tests are performed via GitHub Actions at every commit, including to validate security functionality. |
|
9/9/2024 |
V-222608 |
| SI-10 (03) |
The application must not be subject to input handling vulnerabilities. |
Follow best practice when accepting user input and verify that all input is validated before the application processes the input. Remediate identified vulnerabilities and obtain documented risk acceptance for those issues that cannot be remediated immediately. |
The Heimdall Server GitHub repository undergoes continuous automated dependency, static, and secrets scanning, and each release is secured/patched accordingly. Unit tests are performed via GitHub Actions at every commit, including to validate security functionality. |
|
9/9/2024 |
V-222609 |
| SI-11 a |
The application must generate error messages that provide information necessary for corrective actions without revealing information that could be exploited by adversaries. |
Configure the server to not send error messages containing system information or sensitive data to users. Use generic error messages. |
Heimdall returns generic error messages, such as 401, to users without revealing sensitive information. |
|
9/9/2024 |
V-222610 |
| SI-11 b |
The application must reveal error messages only to the ISSO, ISSM, or SA. |
Configure the server to only send error messages containing system information or sensitive data to privileged users. Use generic error messages for non-privileged users. |
Heimdall returns generic error messages, such as 401, to users without revealing sensitive information. |
|
9/9/2024 |
V-222611 |
| SI-16 |
The application must not be vulnerable to overflow attacks. |
Design the application to use a language or compiler that performs automatic bounds checking. Use an abstraction library to abstract away risky APIs. Use compiler-based canary mechanisms such as StackGuard, ProPolice, and the Microsoft Visual Studio/GS flag. Use OS-level preventative functionality and control user input validation. Patch applications when overflows are identified in vendor products. |
The Heimdall Server GitHub repository undergoes continuous automated dependency, static, and secrets scanning, and each release is secured/patched accordingly. Unit tests are performed via GitHub Actions at every commit, including to validate security functionality. |
|
9/9/2024 |
V-222612 |