8. Securing and Assessing STIG Manager Deployments
Warning
You must secure and assess your deployments in compliance with your individual or organizational security requirements. The discussions below are educational. Encouragement to do things a particular way does not constitute advice that overrides your specific requirements.
The STIG Manager application can be orchestrated several ways, each with unique security requirements and goals. We know many deployments must comply with the Application Security and Development STIG - commonly known as the ASD. Therefore we have organized this section around ASD requirements, to provide guidance for those tasked with securing and assessing STIG-compliant STIG Manager deployments.
Note
The ASD assesses many application components, and application governance, using a single checklist of 286 checks (as of V5R1). Unfortunately, the current ASD provides limited guidance if you’re using modern security technologies such as Single Sign On, OpenID Connect, OAuth2 authorization, and containerization. If you are required to complete an ASD assessment, we encourage focusing on the spirit of the checklist until it is updated or re-imagined.
8.1. Securing Your Deployment
These are some common security topics to review when designing a secure STIG Manager application deployment.
8.1.1. Container Security
We strongly encourage STIG Manager deployments to be containerized. Containerization has built-in security advantages such as immutability, image signing, transparency, modularity, small attack surface, secure updates, and environment parity. The content of container images and their runtime behavior require security evaluations, as in traditional deployments, but provide the advantage of image layer inheritance.
Note
If you are subject to ASD-compliance you are likely subject to other DoD requirements. We encourage an in-depth familiarity with the Container Image Creation and Deployment Guide from DISA. The STIG Manager Project adheres to DISA image creation guidance when defining and building container images, and we encourage STIG Manager deployments to follow the container deployment guidance.
8.1.1.1. Image Choices
Many deployments might directly orchestrate one of our images published on Docker Hub. For most ASD-compliant deployments, you may want to deploy one of our images offered on Iron Bank. Our Iron Bank images are built from the Iron Bank Nodejs-slim images, hardened images with reduced surface area that are based on the Iron Bank Alpine Linux Image. To use Iron Bank Images, you will need an account at https://ironbank.dso.mil/.
Some deployments might prefer a custom container image of STIG Manager created by modifying the Dockerfile from our repo or basing their custom image on one of our published images. In these cases, we strongly encourage use of the relevant Iron Bank base images.
If you need to understand how a container image was built, we encourage familiarity with the docker history command.
8.1.1.2. Vulnerability Scanning
We encourage all deployments to perform vulnerability scanning of our published container images and source code. The Project makes use of automated tools such as GitHub Dependabot, Docker Scout, and Iron Bank scan reports to respond to any vulnerability issues. Iron Bank makes their scan result artifacts available on the STIG Manager page on Iron Bank.
Organizations should consider deploying their own container registry with embedded image scanning. Choices include the open-source Harbor registry with built-in Clair testing, and cloud-based offerings from Amazon, Azure and Google.
8.1.1.3. Validating Image Signatures
The Project signs each image we publish to Docker Hub using Docker Content Trust (DCT). Images on Iron Bank are automatically signed by that platform.
Note
For secure DCT image verification, you should understand trust-pinning. The default “Trust On First Use” (TOFU) behavior of the docker CE client may not be appropriate for your security requirements. Our root.json file will be helpful if you wish to pin trust on our signing key.
8.1.2. Data Flow
Several ASD checks refer to SOAP, WS-Security and SAML, early protocols for implementing and securing online APIs. None of the checks refer to REST or OIDC/OAuth2, modern alternatives that are commonly used in cloud-ready software such as STIG Manager. The checks that address SOAP, etc. state that if you aren’t using those technologies, the assessment is ‘not applicable’.
Note
The discussion below assumes the reader has prerequisite knowledge of REST principles, OAuth2 flows as defined in RFC 6749 and the Open ID Connect Core 1.0 specification
8.1.2.1. REST and OpenAPI Specification (OAS)
The STIG Manager API and Web Client exchange data across a REST architecture that enforces the STIG Manager OAS definition.
Access to individual endpoints is controlled by the OAuth2 scope claims listed in each endpoint’s security.oauth property in the OAS. Oauth2 is discussed further below.
8.1.2.2. Discretionary Access Control (DAC) and Role Based Access Control (RBAC)
The API grants or denies access to STIG Manager data objects (Collections, Assets, Asset/STIG maps, and Reviews) based on the the OAuth2 username claim (or configured equivalent). The username value indexes into the internal STIG Manager DAC system which includes per-Collection RBAC lists (i.e, Collection Grants and Restricted User Access Lists).
Correct implementation of the STIG Manager data flow, especially the DAC and RBAC logic, is verified by an automated workflow that is performed when any change to the codebase is proposed (a Pull Request or PR). Over 2000 assertions are evaluated using tests you can review here. These tests are run against every commit to the release branch to evaluate all features of the API and actively try to cross defined access boundaries to test our DAC and RBAC implementations.
8.1.2.3. OpenID Connect (OIDC) and OAuth2
The claims described in the sections above are contained in OAuth2 JWT formatted access_tokens issued by an OIDC Provider to remote clients, such as the Project’s Web Client and the STIG Manager Watcher bot.
The Web Client on startup redirects users to the OIDC Provider to authenticate and obtain an access token that defines the scope of API access the user grants that client. For most ASD-compliant deployments, the connection to the OIDC Provider’s authorization_endpoint will use MTLS and CAC PKI.
Note
Communication between the API and clients include the access_token and should occur using TLS but do not require Mutual TLS (MTLS).
The Web Client is a single-page application (SPA) that executes entirely in the browser. Browsers are low- to zero-trust environments where OAuth2 access tokens should have short lifetimes to mitigate the risk of token diversion. Just what is considered ‘short’ is for you (or your organization) to decide, but 15 minutes or even less is not uncommon.
The Web Client will not engage in an OIDC implicit flow. The OIDC Provider must provide tokens using the OIDC Authorization Code Flow with Proof Key for Code Exchange (PKCE). To work with bots such as STIG Manager Watcher, the OIDC Provider should also support the client_credentials flow with Signed JWT authentication.
If your OIDC Provider issues refresh tokens (encouraged for a better user experience), those tokens usually have longer lifetimes than the access_token but should be rotated and limited to a single use. Policies vary greatly, but refresh token lifetime is sometimes correlated to the SSO session lifetime. Attempts to reuse a refresh_token should be logged by the OIDC Provider and generate alerts.
8.1.3. User Sessions
Note
The discussion below assumes the reader has knowledge of their specific OIDC Provider and any user federation or identity brokering features it is configured to use.
Several ASD checks address the management of user login sessions. It is important to understand how your OIDC Provider controls user sessions, performs user management, and audits its activities.
8.1.4. Database
Note
The discussion below assumes the reader has prerequisite knowledge of MySQL and how to perform PKI user authentication (if required), secure data storage, and secure data backups.
Several ASD checks address the management of data storage. It is important to understand how to configure MySQL in accordance with local security requirements, such as the Oracle MySQL 8.0 STIG. Ideally, your organization will provision MySQL instances from a hardened cloud subscription that requires a smaller set of customer-responsible security settings.
8.1.5. Logging and Analysis
Many ASD checks specify requirements for how application log entries should collected, aggregated, managed, audited, and analysed. The STIG Manager application role in this is simple: it outputs all its log entries to STDOUT. These log entries must be captured and retained in accordance with your log retention policy. The developers of the STIG Manager API component have made efforts to ensure that the logs the application emits conform to requirements specified in the ASD where appropriate. However, there are several other components of a successful deployment that will produce logs that may also require management by your logging solution, such as the OIDC Provider, Database, and Container Platform.
8.1.6. Transport Layer Security
The ASD specifies the use of TLS-secured connections to the application. STIG Manager supports native TLS connections that can be configured using environment variables (see Environment Variables beginning with STIGMAN_API_TLS_*).
A reverse proxy is still required to meet ASD requirements for mTLS authentication with DoD Common Access Cards (CAC) or client certificate authentication. The reverse proxy should be configured to handle TLS client certificate authentication and forward appropriate headers to the application. See Deploy with Reverse Proxy for detailed configuration guidance.
8.1.7. Security Updates, Advisories, and Policies
The ASD requires application deployment representatives to be aware of application updates, advisories, processes, and policies. The project’s Security Policy and Security Advisories can be found on the Security page of our GitHub site. We encourage you to acquaint yourself with our published Security Policy, subscribe for notifications of new releases, and report any vulnerabilities you may find on your own in a responsible way.
8.2. Assessing Your Deployment
The documentation and artifacts provided here are intended to help teams that are deploying STIG Manager in an environment that is subject to the Application Security and Development STIG. Below, you can find a summary and STIG information, including a .ckl, relevant to this effort.
Where applicable, we have self-evaluated portions of the ASD as if we were developer members of a deployed application’s team. For most deployments, though, we are NOT part of your team and therefore the checks covering development practices might be properly evaluated as not applicable. Even in this case, however, we hope our self-evaluation provides useful insight into how the Project integrates security into our practice.
8.2.1. API and Web Client
About a third of the checks in the ASD assess application components provided by this Project - the API and Web Client. These checks assess both their behavior and how they are developed. All other checks are dependent on specific deployment configurations, but we have provided some guidance where we can.
Warning
You must evaluate your deployment independently in accordance with your individual security requirements. Our self-evaluation CANNOT and DOES NOT represent a valid assessment of your deployment!
It is always possible to configure your deployment into an insecure state. The provided assessments may not apply to the way you have configured your deployment! They are to be used only as a guide or as reference for your own assessments. In general, we have followed this convention when providing assessments:
Reviews are marked Not a Finding if they are considered by the STIGMan team to be compliant with the ASD by nature of the design and practices executed by the developers.
Reviews are marked Not Applicable only if the project design meets conditions provided in rule guidance. It is always possible that your deployment configuration makes that particular STIG check “applicable.”
Reviews marked Informational or Not Reviewed may have useful details to be used as reference for assessments but cannot be satisfied by the project application alone.
The results displayed in the table below are also available as a .ckl file in our GitHub repo, suitable for importing into STIG Manager.
Vuln |
Title |
result |
Detail |
|---|---|---|---|
V-222387 |
The application must provide a capability to limit the number of logon sessions per user. |
Informational |
The User Session layer, including concurrent session handling, is implemented by an external OpenID Connect (OIDC) Provider that issues OAuth2 tokens. |
V-222388 |
The application must clear temporary storage and cookies when the session is terminated. |
Not a Finding |
The Web Client does not persist storage of any user information, including OAuth2 tokens. |
V-222389 |
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. |
Informational |
The User Session layer, including idle session handling, is implemented by an external OpenID Connect (OIDC) Provider that issues OAuth2 tokens. |
V-222390 |
The application must automatically terminate the admin user session and log off admin users after a 10 minute idle time period is exceeded. |
Informational |
The User Session layer, including idle session handling, is implemented by an external OpenID Connect (OIDC) Provider that issues OAuth2 tokens. |
V-222391 |
Applications requiring user access authentication must provide a logoff capability for user initiated communication session. |
Not a Finding |
The Web Client requests logoff service from the OIDC Provider after user interaction with a DOM element whose innerText = ‘Logout’ |
V-222392 |
The application must display an explicit logoff message to users indicating the reliable termination of authenticated communications sessions. |
Not a Finding |
The SPA does not display an explicit ‘logged out’ screen, it immediately redirects to the login screen of the configured OIDC Provider. Addressed by Issue #485 |
V-222393 |
The application must associate organization-defined types of security attributes having organization-defined security attribute values with information in storage. |
Not a Finding |
The API scaffolds each new database instance with the classification specified by the environment variable STIGMAN_CLASSIFICATION. This value is stored in the ‘configuration’ table and represents the default classification for all data that is stored by the database instance, served by the API, and received by the Web Client. |
V-222394 |
The application must associate organization-defined types of security attributes having organization-defined security attribute values with information in process. |
Not a Finding |
Individual objects do not contain data markings. An API endpoint returns the data marking for all data served by the API. The Web Client displays a banner that represents the data marking for all data received by the Client. Processing the data does not alter this banner in any circumstances. |
V-222395 |
The application must associate organization-defined types of security attributes having organization-defined security attribute values with information in transmission. |
Not a Finding |
Individual objects do not contain data markings. An API endpoint returns the data marking for all data served by the API. The Web Client displays a banner that represents the data marking for all data received by the Client. Data transmission does not alter this banner in any circumstances. |
V-222396 |
The application must implement DoD-approved encryption to protect the confidentiality of remote access sessions. |
Informational |
The documentation recommends deployments locate the application behind a TLS reverse proxy. |
V-222397 |
The application must implement cryptographic mechanisms to protect the integrity of remote access sessions. |
Informational |
The documentation recommends deployments locate the application behind a TLS reverse proxy. |
V-222398 |
Applications with SOAP messages requiring integrity must include the following message elements:-Message ID-Service Request-Timestamp-SAML Assertion (optionally included in messages) and all elements of the message must be digitally signed. |
Not Applicable |
The SPA does not utilize SOAP messages. |
V-222399 |
Messages protected with WS_Security must use time stamps with creation and expiration times. |
Not Applicable |
The SPA does not utilize WS-Security tokens. |
V-222400 |
Validity periods must be verified on all application messages using WS-Security or SAML assertions. |
Not Applicable |
The SPA does not utilize WSS or SAML assertions. |
V-222401 |
The application must ensure each unique asserting party provides unique assertion ID references for each SAML assertion. |
Not Applicable |
The SPA does not utilize SAML assertions. |
V-222402 |
The application must ensure encrypted assertions, or equivalent confidentiality protections are used when assertion data is passed through an intermediary, and confidentiality of the assertion data is required when passing through the intermediary. |
Not Applicable |
The SPA does not utilize WS-Security tokens |
V-222403 |
The application must use the NotOnOrAfter condition when using the SubjectConfirmation element in a SAML assertion. |
Not Applicable |
The SPA does not utilize SAML assertions. |
V-222404 |
The application must use both the NotBefore and NotOnOrAfter elements or OneTimeUse element when using the Conditions element in a SAML assertion. |
Not Applicable |
The SPA does not utilize SAML assertions. |
V-222405 |
The application must ensure if a OneTimeUse element is used in an assertion, there is only one of the same used in the Conditions element portion of an assertion. |
Not Applicable |
The SPA does not utilize SAML assertions. |
V-222406 |
The application must ensure messages are encrypted when the SessionIndex is tied to privacy data. |
Not Applicable |
The SPA does not utilize SAML assertions. |
V-222407 |
The application must provide automated mechanisms for supporting account management functions. |
Informational |
Account Management services are provided by an external (OIDC) OpenID Connect Provider. |
V-222408 |
Shared/group account credentials must be terminated when members leave the group. |
Informational |
Account Management services are provided by an external (OIDC) OpenID Connect Provider. |
V-222409 |
The application must automatically remove or disable temporary user accounts 72 hours after account creation. |
Informational |
Account Management services are provided by an external (OIDC) OpenID Connect Provider. |
V-222410 |
The application must have a process, feature or function that prevents removal or disabling of emergency accounts. |
Informational |
Account Management services are provided by an external (OIDC) OpenID Connect Provider. |
V-222411 |
The application must automatically disable accounts after a 35 day period of account inactivity. |
Informational |
Account Management services are provided by an external (OIDC) OpenID Connect Provider. |
V-222412 |
Unnecessary application accounts must be disabled, or deleted. |
Informational |
Account Management services are provided by an external (OIDC) OpenID Connect Provider. |
V-222413 |
The application must automatically audit account creation. |
Informational |
Account Management services are provided by an external (OIDC) OpenID Connect Provider. |
V-222414 |
The application must automatically audit account modification. |
Informational |
Account Management services are provided by an external (OIDC) OpenID Connect Provider. |
V-222415 |
The application must automatically audit account disabling actions. |
Informational |
Account Management services are provided by an external (OIDC) OpenID Connect Provider. |
V-222416 |
The application must automatically audit account removal actions. |
Informational |
Account Management services are provided by an external (OIDC) OpenID Connect Provider. |
V-222417 |
The application must notify System Administrators and Information System Security Officers when accounts are created. |
Informational |
Account Management services are provided by an external (OIDC) OpenID Connect Provider. |
V-222418 |
The application must notify System Administrators and Information System Security Officers when accounts are modified. |
Informational |
Account Management services are provided by an external (OIDC) OpenID Connect Provider. |
V-222419 |
The application must notify System Administrators and Information System Security Officers of account disabling actions. |
Informational |
Account Management services are provided by an external (OIDC) OpenID Connect Provider. |
V-222420 |
The application must notify System Administrators and Information System Security Officers of account removal actions. |
Informational |
Account Management services are provided by an external (OIDC) OpenID Connect Provider. |
V-222421 |
The application must automatically audit account enabling actions. |
Informational |
Account Management services are provided by an external (OIDC) OpenID Connect Provider. |
V-222422 |
The application must notify System Administrators and Information System Security Officers of account enabling actions. |
Informational |
Account Management services are provided by an external (OIDC) OpenID Connect Provider. |
V-222423 |
Application data protection requirements must be identified and documented. |
Not a Finding |
The project provides documentation describing its data structures and protection methods, including RBAC and other access controls. These concepts are also expressed and enforced by its use of an appropriate OAS definition. All app data is persisted in a deployment-provided database that must be configured in accordance with organization requirements. |
V-222424 |
The application must utilize organization-defined data mining detection techniques for organization-defined data storage objects to adequately detect data mining attempts. |
Informational |
Data mining detection and prevention are to be implemented at the Log Analysis layer, Ingress controller, or elsewhere. No data mining protection requirements apply to application itself. |
V-222425 |
The application must enforce approved authorizations for logical access to information and system resources in accordance with applicable access control policies. |
Not a Finding |
The API ensures proper access to application resources in accordance with Role-Based Access Control (RBAC) and Discretionary Access Control (DAC) mechanisms at the application and Collection levels. No direct database access is provided by the application. See documentation. |
V-222426 |
The application must enforce organization-defined discretionary access control policies over defined subjects and objects. |
Not a Finding |
The API ensures proper access to application resources in accordance with Role-Based Access Control (RBAC) and Discretionary Access Control (DAC) mechanisms at the application and Collection levels. No direct database access is provided by the application. See documentation. |
V-222427 |
The application must enforce approved authorizations for controlling the flow of information within the system based on organization-defined information flow control policies. |
Informational |
The application does not provide data flow control capabilities, the requirement is not applicable. |
V-222428 |
The application must enforce approved authorizations for controlling the flow of information between interconnected systems based on organization-defined information flow control policies. |
Informational |
The application does not provide data flow control capabilities, the requirement is not applicable. |
V-222429 |
The application must prevent non-privileged users from executing privileged functions to include disabling, circumventing, or altering implemented security safeguards/countermeasures. |
Not a Finding |
The Project publishes container images configured to execute the API as the unprivileged user, ‘node’ whose userId is not 0. |
V-222430 |
The application must execute without excessive account permissions. |
Not a Finding |
The project supplied container images are configured to run by the limited, unprivileged user, ‘node’. |
V-222431 |
The application must audit the execution of privileged functions. |
Not a Finding |
The API emits audit records for privileged functions that document the specific endpoint invoked, the date and time, and all path and query parameters. |
V-222432 |
The application must enforce the limit of three consecutive invalid logon attempts by a user during a 15 minute time period. |
Informational |
User Account services are provided by a external OIDC Provider. |
V-222433 |
The application administrator must follow an approved process to unlock locked user accounts. |
Informational |
User Account services are provided by a external OIDC Provider. |
V-222434 |
The application must display the Standard Mandatory DoD Notice and Consent Banner before granting access to the application. |
Informational |
The Standard Mandatory DoD Notice and Consent Banner can be displayed by the external OIDC Provider. |
V-222435 |
The application must retain the Standard Mandatory DoD Notice and Consent Banner on the screen until users acknowledge the usage conditions and take explicit actions to log on for further access. |
Informational |
Standard Mandatory DoD Notice and Consent Banner services are provided by a external OIDC Provider. |
V-222436 |
The publicly accessible application must display the Standard Mandatory DoD Notice and Consent Banner before granting access to the application. |
Informational |
Standard Mandatory DoD Notice and Consent Banner services are provided by a external OIDC Provider. |
V-222437 |
The application must display the time and date of the users last successful logon. |
Informational |
User Session services are provided by a external OIDC Provider. |
V-222438 |
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. |
Informational |
STIG Manager does not have any non-repudiation requirements as part of its design. |
V-222439 |
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. |
Informational |
STIG Manager does not offer log aggregation services. This is expected to be implemented by specific deployments at the Log Analysis level. |
V-222441 |
The application must provide audit record generation capability for the creation of session IDs. |
Informational |
The web app delegates these duties to an OIDC Provider. The OpenID Connect (OIDC) Provider creates, manages and logs user session data. |
V-222442 |
The application must provide audit record generation capability for the destruction of session IDs. |
Informational |
The web app delegates these duties to an OIDC Provider. The OpenID Connect (OIDC) Provider creates, manages and logs user session data. |
V-222443 |
The application must provide audit record generation capability for the renewal of session IDs. |
Informational |
The web app delegates these duties to an OIDC Provider. The OpenID Connect (OIDC) Provider creates, manages and logs user session data. |
V-222444 |
The application must not write sensitive data into the application logs. |
Not a Finding |
The API does not emit audit records with sensitive data, including session Ids (not used), encryption keys, or passwords (not used). |
V-222445 |
The application must provide audit record generation capability for session timeouts. |
Informational |
The web app delegates these duties to an OIDC Provider. The OpenID Connect (OIDC) Provider creates, manages and logs user session data. |
V-222446 |
The application must record a time stamp indicating when the event occurred. |
Not a Finding |
The API emits audit records that are time stamped. |
V-222447 |
The application must provide audit record generation capability for HTTP headers including User-Agent, Referer, GET, and POST. |
Not a Finding |
Addressed by Issue #179, allowing different log levels and configuration to affect headers included in audit record. |
V-222448 |
The application must provide audit record generation capability for connecting system IP addresses. |
Not a Finding |
When logging endpoint requests, the API emits audit records that include the original source IP address. |
V-222449 |
The application must record the username or user ID of the user associated with the event. |
Not a Finding |
When logging endpoint requests, the API emits audit records that include the OAuth2 token claim configured as representing the requesting entity’s username. |
V-222450 |
The application must generate audit records when successful/unsuccessful attempts to grant privileges occur. |
Not a Finding |
Addressed by Issue #179, must include POST content and JSON reply in audit record. |
V-222451 |
The application must generate audit records when successful/unsuccessful attempts to access security objects occur. |
Not a Finding |
When logging endpoint requests, the API emits audit records for successful and unsuccessful attempts to access security objects (i.e., Collections, Assets, Reviews). |
V-222452 |
The application must generate audit records when successful/unsuccessful attempts to access security levels occur. |
Not a Finding |
When logging endpoint requests, the API emits audit records for successful and unsuccessful attempts to access security levels (i.e., Collection Grants). |
V-222453 |
The application must generate audit records when successful/unsuccessful attempts to access categories of information (e.g., classification levels) occur. |
Not a Finding |
When logging endpoint requests, the API emits audit records for successful and unsuccessful attempts to access all categories of information. |
V-222454 |
The application must generate audit records when successful/unsuccessful attempts to modify privileges occur. |
Not a Finding |
Addressed by Issue #179, must include POST content and JSON reply in audit record. |
V-222455 |
The application must generate audit records when successful/unsuccessful attempts to modify security objects occur. |
Not a Finding |
When logging endpoint requests, the API emits audit records for successful and unsuccessful attempts to modify security objects (i.e, Collections, Assets, Reviews and Users). |
V-222456 |
The application must generate audit records when successful/unsuccessful attempts to modify security levels occur. |
Not a Finding |
When logging endpoint requests, the API emits audit records for successful and unsuccessful attempts to modify security levels (i.e, Collection Grants). |
V-222457 |
The application must generate audit records when successful/unsuccessful attempts to modify categories of information (e.g., classification levels) occur. |
Not a Finding |
When logging endpoint requests, the API emits audit records for successful and unsuccessful attempts to modify categories of information (i.e, Collection Grants, Restricted User Access). |
V-222458 |
The application must generate audit records when successful/unsuccessful attempts to delete privileges occur. |
Not a Finding |
Addressed by Issue #179, must include POST content and JSON reply in audit record. |
V-222459 |
The application must generate audit records when successful/unsuccessful attempts to delete security levels occur. |
Not a Finding |
When logging endpoint requests, the API emits audit records for successful and unsuccessful attempts to delete security levels (i.e, Collection Grants, Restricted User Access). |
V-222460 |
The application must generate audit records when successful/unsuccessful attempts to delete application database security objects occur. |
Not a Finding |
The API does not implement functionality that manipulates database security objects, including deletions. |
V-222461 |
The application must generate audit records when successful/unsuccessful attempts to delete categories of information (e.g., classification levels) occur. |
Not a Finding |
When logging endpoint requests, the API emits audit records for successful and unsuccessful attempts to delete categories of information (i.e, Collection Grants, Restricted User Access). |
V-222462 |
The application must generate audit records when successful/unsuccessful logon attempts occur. |
Informational |
The web app delegates these duties to an OIDC Provider. The OpenID Connect (OIDC) Provider creates, manages and logs user session data. |
V-222463 |
The application must generate audit records for privileged activities or other system-level access. |
Informational |
By design, privileged access does not include the ability to modify the application or its configuration. It only provide users with the functionality or the ability to manage their own user specific preferences or otherwise tailor the application to suit individual user needs based upon choices or selections built into the application. |
V-222464 |
The application must generate audit records showing starting and ending time for user access to the system. |
Informational |
The web app delegates these duties to an OIDC Provider. The OpenID Connect (OIDC) Provider creates, manages and logs user session data. |
V-222465 |
The application must generate audit records when successful/unsuccessful accesses to objects occur. |
Not a Finding |
When logging endpoint requests, the API emits audit records for successful and unsuccessful attempts to access to application objects (i.e, Collections, Assets, Reviews, Users). |
V-222466 |
The application must generate audit records for all direct access to the information system. |
Informational |
The application does not provide direct access to the underlying information system. |
V-222467 |
The application must generate audit records for all account creations, modifications, disabling, and termination events. |
Informational |
The web app delegates these duties to an OIDC Provider. The OpenID Connect (OIDC) Provider creates, manages and logs user session data. |
V-222468 |
The application must initiate session auditing upon startup. |
Not a Finding |
The API emits audit records immediately upon the start of its bootstrapping process. Your local definition of ‘application startup’ may include other components (i.e, OIDC Provider, database, reverse proxies, log servers, etc.) whose compliance with this check must be individually evaluated. |
V-222469 |
The application must log application shutdown events. |
Not a Finding |
The API emits audit records after receiving the SIGINT or SIGTERM signal that initiates a shutdown. Addressed by Issue #484 Your local definition of ‘application shutdown’ may include other components (i.e, OIDC Provider, database, reverse proxies, log servers, etc.) whose compliance with this check must be individually evaluated. |
V-222470 |
The application must log destination IP addresses. |
Not a Finding |
The API emits audit records containing the destination IP when retrieving token signing keys from the OIDC Provider or when optionally downloading STIG compilations during the initial database bootstrap. |
V-222471 |
The application must log user actions involving access to data. |
Not a Finding |
When logging endpoint requests, the API emits audit records for user actions involving access to data (i.e, Collections, Assets, Reviews, Users). |
V-222472 |
The application must log user actions involving changes to data. |
Not a Finding |
When logging endpoint requests, the API emits audit records for user actions involving changes to data (i.e, Collections, Assets, Reviews, Users). |
V-222473 |
The application must produce audit records containing information to establish when (date and time) the events occurred. |
Not a Finding |
The API emits audit records that are time stamped. |
V-222474 |
The application must produce audit records containing enough information to establish which component, feature or function of the application triggered the audit event. |
Not a Finding |
The API emits audit records that include a component property. |
V-222475 |
When using centralized logging; the application must include a unique identifier in order to distinguish itself from other application logs. |
Not a Finding |
The API emits audit records that include an instance property. |
V-222476 |
The application must produce audit records that contain information to establish the outcome of the events. |
Not a Finding |
When logging endpoint requests, the API emits audit records that contain the response status code. |
V-222477 |
The application must generate audit records containing information that establishes the identity of any individual or process associated with the event. |
Not a Finding |
When logging endpoint requests, the API emits audit records that include the OAuth2 token claim configured as representing the requesting entity’s username. |
V-222478 |
The application must generate audit records containing the full-text recording of privileged commands or the individual identities of group account users. |
Not a Finding |
When logging endpoint requests, if the request includes parameter ‘elevate’ == true, the API emits audit records that include the JSON POST content and the JSON reply Addressed by Issue #179 |
V-222479 |
The application must implement transaction recovery logs when transaction based. |
Informational |
Implemented by the Data Storage layer |
V-222480 |
The application must provide centralized management and configuration of the content to be captured in audit records generated by all application components. |
Informational |
Application log entries are written to the container’s STDOUT, to be captured by the deployment’s preferred and compliant logging solution. |
V-222481 |
The application must off-load audit records onto a different system or media than the system being audited. |
Informational |
Application log entries are written to the container’s STDOUT, to be captured by the deployment’s preferred and compliant logging solution. |
V-222482 |
The application must be configured to write application logs to a centralized log repository. |
Informational |
Application log entries are written to the container’s STDOUT, to be captured by the deployment’s preferred and compliant logging solution. |
V-222483 |
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. |
Informational |
Application log entries are written to the container’s STDOUT, to be captured by the deployment’s preferred and compliant logging solution. |
V-222484 |
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. |
Informational |
Application log entries are written to the container’s STDOUT, to be captured by the deployment’s preferred and compliant logging solution. |
V-222485 |
The application must alert the ISSO and SA (at a minimum) in the event of an audit processing failure. |
Informational |
Application log entries are written to the container’s STDOUT, to be captured by the deployment’s preferred and compliant logging solution. |
V-222486 |
The application must shut down by default upon audit failure (unless availability is an overriding concern). |
Informational |
Application log entries are written to the container’s STDOUT, to be captured by the deployment’s preferred and compliant logging solution. Application must be stopped by the Container Platform layer (e.g., k8s). |
V-222487 |
The application must provide the capability to centrally review and analyze audit records from multiple components within the system. |
Informational |
Application log entries are written to the container’s STDOUT, to be captured by the deployment’s preferred and compliant logging solution. |
V-222488 |
The application must provide the capability to filter audit records for events of interest based upon organization-defined criteria. |
Informational |
Application log entries are written to the container’s STDOUT, to be captured by the deployment’s preferred and compliant logging solution. |
V-222489 |
The application must provide an audit reduction capability that supports on-demand reporting requirements. |
Informational |
Application log entries are written to the container’s STDOUT, to be captured by the deployment’s preferred and compliant logging solution. |
V-222490 |
The application must provide an audit reduction capability that supports on-demand audit review and analysis. |
Informational |
Application log entries are written to the container’s STDOUT, to be captured by the deployment’s preferred and compliant logging solution. |
V-222491 |
The application must provide an audit reduction capability that supports after-the-fact investigations of security incidents. |
Informational |
Application log entries are written to the container’s STDOUT, to be captured by the deployment’s preferred and compliant logging solution. |
V-222492 |
The application must provide a report generation capability that supports on-demand audit review and analysis. |
Informational |
Application log entries are written to the container’s STDOUT, to be captured by the deployment’s preferred and compliant logging solution. |
V-222493 |
The application must provide a report generation capability that supports on-demand reporting requirements. |
Informational |
Application log entries are written to the container’s STDOUT, to be captured by the deployment’s preferred and compliant logging solution. |
V-222494 |
The application must provide a report generation capability that supports after-the-fact investigations of security incidents. |
Informational |
Application log entries are written to the container’s STDOUT, to be captured by the deployment’s preferred and compliant logging solution. |
V-222495 |
The application must provide an audit reduction capability that does not alter original content or time ordering of audit records. |
Informational |
Application log entries are written to the container’s STDOUT, to be captured by the deployment’s preferred and compliant logging solution. |
V-222496 |
The application must provide a report generation capability that does not alter original content or time ordering of audit records. |
Informational |
Application log entries are written to the container’s STDOUT, to be captured by the deployment’s preferred and compliant logging solution. |
V-222497 |
The applications must use internal system clocks to generate time stamps for audit records. |
Not a Finding |
The API emits audit records with a time stamp generated from the system clock. |
V-222498 |
The application must record time stamps for audit records that can be mapped to Coordinated Universal Time (UTC) or Greenwich Mean Time (GMT). |
Not a Finding |
The API emits audit records with the time stamp represented as an ISO-8601 string, including time zone. |
V-222499 |
The application must record time stamps for audit records that meet a granularity of one second for a minimum degree of precision. |
Not a Finding |
The API emits audit records with millisecond time stamp precision. |
V-222500 |
The application must protect audit information from any type of unauthorized read access. |
Informational |
Application log entries are written to the container’s STDOUT, to be captured by the deployment’s preferred and compliant logging solution. |
V-222501 |
The application must protect audit information from unauthorized modification. |
Informational |
Application log entries are written to the container’s STDOUT, to be captured by the deployment’s preferred and compliant logging solution. |
V-222502 |
The application must protect audit information from unauthorized deletion. |
Informational |
Application log entries are written to the container’s STDOUT, to be captured by the deployment’s preferred and compliant logging solution. |
V-222503 |
The application must protect audit tools from unauthorized access. |
Informational |
Application log entries are written to the container’s STDOUT, to be captured by the deployment’s preferred and compliant logging solution. |
V-222504 |
The application must protect audit tools from unauthorized modification. |
Informational |
Application log entries are written to the container’s STDOUT, to be captured by the deployment’s preferred and compliant logging solution. |
V-222505 |
The application must protect audit tools from unauthorized deletion. |
Informational |
Application log entries are written to the container’s STDOUT, to be captured by the deployment’s preferred and compliant logging solution. |
V-222506 |
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. |
Informational |
Application log entries are written to the container’s STDOUT, to be captured by the deployment’s preferred and compliant logging solution. |
V-222507 |
The application must use cryptographic mechanisms to protect the integrity of audit information. |
Informational |
Application log entries are written to the container’s STDOUT, to be captured by the deployment’s preferred and compliant logging solution. |
V-222508 |
Application audit tools must be cryptographically hashed. |
Informational |
Application log entries are written to the container’s STDOUT, to be captured by the deployment’s preferred and compliant logging solution. The project does not provide a separate tool in the form of a file which provides an ability to view and manipulate application log data, query data, or generate reports |
V-222509 |
The integrity of the audit tools must be validated by checking the files for changes in the cryptographic hash value. |
Informational |
Application log entries are written to the container’s STDOUT, to be captured by the deployment’s preferred and compliant logging solution. The project does not provide a separate tool in the form of a file which provides an ability to view and manipulate application log data, query data or generate reports. |
V-222510 |
The application must prohibit user installation of software without explicit privileged status. |
Informational |
The project does not provide the ability to install software components, modules, plugins, or extensions, |
V-222511 |
The application must enforce access restrictions associated with changes to application configuration. |
Informational |
The application cannot configure itself, and does not offer any configuration mechanisms that are affected by users or config files. |
V-222512 |
The application must audit who makes configuration changes to the application. |
Informational |
The application cannot configure itself, and does not offer any configuration mechanisms that are affected by users or config files. The project should be deployed with a Application Services layer (Container Platform such as k8s) that audits configuration changes to the application. |
V-222513 |
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. |
Informational |
The application is offered as containerized API/Web Client builds that are signed using Docker Content Trust. |
V-222514 |
The applications must limit privileges to change the software resident within software libraries. |
Not a Finding |
The API is designed to be stateless and runnable in a read-only container. |
V-222515 |
An application vulnerability assessment must be conducted. |
Informational |
Deployments must be scanned according to individual or organizational policies. Developers scan the codebase regularly in a test environment, but this is only one component of a functioning production deployment. |
V-222516 |
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. |
Informational |
Organization-defined policies regarding software program usage and restrictions, and/or rules authorizing the terms and conditions of software program usage are determined locally and not by the project. |
V-222517 |
The application must employ a deny-all, permit-by-exception (whitelist) policy to allow the execution of authorized software programs. |
Not Applicable |
The application is not a configuration management or similar type of application designed to manage system processes and configurations, this requirement is not applicable. |
V-222518 |
The application must be configured to disable non-essential capabilities. |
Not a Finding |
The application runs only essential services needed for operation. Container images are based on either the Alpine Linux distribution or the Iron Bank Universal Base Image (UBI). |
V-222519 |
The application must be configured to use only functions, ports, and protocols permitted to it in the PPSM CAL. |
Informational |
PPS features are implemented by the Container Platform service. |
V-222520 |
The application must require users to reauthenticate when organization-defined circumstances or situations require reauthentication. |
Informational |
Authentication services are provided by an external (OIDC) OpenID Connect Provider. Reauthentication policies are locally defined and implemented. |
V-222521 |
The application must require devices to reauthenticate when organization-defined circumstances or situations requiring reauthentication. |
Informational |
Authentication services are provided by an external (OIDC) OpenID Connect Provider. Reauthentication policies are locally defined and implemented. |
V-222522 |
The application must uniquely identify and authenticate organizational users (or processes acting on behalf of organizational users). |
Informational |
Authentication services are provided by an external (OIDC) OpenID Connect Provider. |
V-222523 |
The application must use multifactor (Alt. Token) authentication for network access to privileged accounts. |
Informational |
Authentication services are provided by an external (OIDC) OpenID Connect Provider. |
V-222524 |
The application must accept Personal Identity Verification (PIV) credentials. |
Informational |
Authentication services are provided by an external (OIDC) OpenID Connect Provider. |
V-222525 |
The application must electronically verify Personal Identity Verification (PIV) credentials. |
Informational |
Authentication services are provided by an external (OIDC) OpenID Connect Provider. Reauthentication policies are locally defined and implemented. |
V-222526 |
The application must use multifactor (e.g., CAC, Alt. Token) authentication for network access to non-privileged accounts. |
Informational |
Authentication services are provided by an external (OIDC) OpenID Connect Provider. |
V-222527 |
The application must use multifactor (Alt. Token) authentication for local access to privileged accounts. |
Informational |
Authentication services are provided by an external (OIDC) OpenID Connect Provider. |
V-222528 |
The application must use multifactor (e.g., CAC, Alt. Token) authentication for local access to non-privileged accounts. |
Informational |
Authentication services are provided by an external (OIDC) OpenID Connect Provider. |
V-222529 |
The application must ensure users are authenticated with an individual authenticator prior to using a group authenticator. |
Not Applicable |
The project does not use group or shared accounts. |
V-222530 |
The application must implement replay-resistant authentication mechanisms for network access to privileged accounts. |
Informational |
Replay-resistant authentication mechanisms are implemented by the OIDC Provider. |
V-222531 |
The application must implement replay-resistant authentication mechanisms for network access to non-privileged accounts. |
Informational |
Replay-resistant authentication mechanisms are implemented by the OIDC Provider. |
V-222532 |
The application must utilize mutual authentication when endpoint device non-repudiation protections are required by DoD policy or by the data owner. |
Informational |
Mutual authentication mechanisms are implemented by the OIDC Provider. |
V-222533 |
The application must authenticate all network connected endpoint devices before establishing any connection. |
Not a Finding |
All API endpoint access requires a valid OAuth2 token issued by the application OIDC Provider. |
V-222534 |
Service-Oriented Applications handling non-releasable data must authenticate endpoint devices via mutual SSL/TLS. |
Informational |
Authentication services are provided by an external (OIDC) OpenID Connect Provider. Devices should perform mutual authentication with the OIDC Provider via the ‘client credentials’ flow with Signed JWT or equivalent PKI technologies. |
V-222535 |
The application must disable device identifiers after 35 days of inactivity unless a cryptographic certificate is used for authentication. |
Informational |
Authentication services are provided by an external (OIDC) OpenID Connect Provider. Devices should perform mutual authentication with the OIDC Provider via the ‘client credentials’ flow with Signed JWT or equivalent PKI technologies. |
V-222536 |
The application must enforce a minimum 15-character password length. |
Informational |
Authentication services are provided by an external (OIDC) OpenID Connect Provider. |
V-222537 |
The application must enforce password complexity by requiring that at least one upper-case character be used. |
Informational |
Authentication services are provided by an external (OIDC) OpenID Connect Provider. |
V-222538 |
The application must enforce password complexity by requiring that at least one lower-case character be used. |
Informational |
Authentication services are provided by an external (OIDC) OpenID Connect Provider. |
V-222539 |
The application must enforce password complexity by requiring that at least one numeric character be used. |
Informational |
Authentication services are provided by an external (OIDC) OpenID Connect Provider. |
V-222540 |
The application must enforce password complexity by requiring that at least one special character be used. |
Informational |
Authentication services are provided by an external (OIDC) OpenID Connect Provider. |
V-222541 |
The application must require the change of at least 8 of the total number of characters when passwords are changed. |
Informational |
Authentication services are provided by an external (OIDC) OpenID Connect Provider. |
V-222542 |
The application must only store cryptographic representations of passwords. |
Informational |
Authentication services are provided by an external (OIDC) OpenID Connect Provider. |
V-222543 |
The application must transmit only cryptographically-protected passwords. |
Informational |
Authentication services are provided by an external (OIDC) OpenID Connect Provider. |
V-222544 |
The application must enforce 24 hours/1 day as the minimum password lifetime. |
Informational |
Authentication services are provided by an external (OIDC) OpenID Connect Provider. |
V-222545 |
The application must enforce a 60-day maximum password lifetime restriction. |
Informational |
Authentication services are provided by an external (OIDC) OpenID Connect Provider. |
V-222546 |
The application must prohibit password reuse for a minimum of five generations. |
Informational |
Authentication services are provided by an external (OIDC) OpenID Connect Provider. |
V-222547 |
The application must allow the use of a temporary password for system logons with an immediate change to a permanent password. |
Informational |
Authentication services are provided by an external (OIDC) OpenID Connect Provider. |
V-222548 |
The application password must not be changeable by users other than the administrator or the user with which the password is associated. |
Informational |
Authentication services are provided by an external (OIDC) OpenID Connect Provider. |
V-222549 |
The application must terminate existing user sessions upon account deletion. |
Informational |
Authentication services are provided by an external (OIDC) OpenID Connect Provider. Low-latency session termination should be configured on the OIDC Provider. |
V-222550 |
The application, when utilizing PKI-based authentication, must validate certificates by constructing a certification path (which includes status information) to an accepted trust anchor. |
Informational |
Authentication services are provided by an external (OIDC) OpenID Connect Provider. |
V-222551 |
The application, when using PKI-based authentication, must enforce authorized access to the corresponding private key. |
Informational |
Authentication services are provided by an external (OIDC) OpenID Connect Provider. |
V-222552 |
The application must map the authenticated identity to the individual user or group account for PKI-based authentication. |
Informational |
Authentication services are provided by an external (OIDC) OpenID Connect Provider. |
V-222553 |
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. |
Informational |
Authentication services are provided by an external (OIDC) OpenID Connect Provider. |
V-222554 |
The application must not display passwords/PINs as clear text. |
Informational |
Authentication services are provided by an external (OIDC) OpenID Connect Provider. |
V-222555 |
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. |
Informational |
Authentication services are provided by an external (OIDC) OpenID Connect Provider. |
V-222556 |
The application must uniquely identify and authenticate non-organizational users (or processes acting on behalf of non-organizational users). |
Informational |
Authentication services are provided by an external (OIDC) OpenID Connect Provider. |
V-222557 |
The application must accept Personal Identity Verification (PIV) credentials from other federal agencies. |
Informational |
Authentication services are provided by an external (OIDC) OpenID Connect Provider. |
V-222558 |
The application must electronically verify Personal Identity Verification (PIV) credentials from other federal agencies. |
Informational |
Authentication services are provided by an external (OIDC) OpenID Connect Provider. |
V-222559 |
The application must accept FICAM-approved third-party credentials. |
Informational |
Authentication services are provided by an external (OIDC) OpenID Connect Provider. |
V-222560 |
The application must conform to FICAM-issued profiles. |
Not a Finding |
The project conforms to OpenID Connect, a FICAM issued profile. |
V-222561 |
Applications used for non-local maintenance sessions must audit non-local maintenance and diagnostic sessions for organization-defined auditable events. |
Not Applicable |
The project does not provide non-local maintenance and diagnostic capability. |
V-222562 |
Applications used for non-local maintenance sessions must implement cryptographic mechanisms to protect the integrity of non-local maintenance and diagnostic communications. |
Not Applicable |
The project does not provide non-local maintenance and diagnostic capability. |
V-222563 |
Applications used for non-local maintenance sessions must implement cryptographic mechanisms to protect the confidentiality of non-local maintenance and diagnostic communications. |
Not Applicable |
The project does not provide non-local maintenance and diagnostic capability. |
V-222564 |
Applications used for non-local maintenance sessions must verify remote disconnection at the termination of non-local maintenance and diagnostic sessions. |
Not Applicable |
The project does not provide non-local maintenance and diagnostic capability. |
V-222565 |
The application must employ strong authenticators in the establishment of non-local maintenance and diagnostic sessions. |
Not Applicable |
The project does not provide non-local maintenance and diagnostic capability. |
V-222566 |
The application must terminate all sessions and network connections when non-local maintenance is completed. |
Not Applicable |
The project does not provide non-local maintenance and diagnostic capability. |
V-222567 |
The application must not be vulnerable to race conditions. |
Not a Finding |
Code review by SonarCloud tests reveal no race conditions. |
V-222568 |
The application must terminate all network connections associated with a communications session at the end of the session. |
Not a Finding |
The application relies on the underlying OS to control the network connection aspect of the application which is perfectly acceptable. |
V-222569 |
The application must implement NSA-approved cryptography to protect classified information in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, and standards. |
Informational |
The project expects other layers to provide appropriate data protection via compliant cryptography. It supports interactions with the Data Storage layer via TLS. The project containers are read-only, stateless builds. |
V-222570 |
The application must utilize FIPS-validated cryptographic modules when signing application components. |
Not a Finding |
Container images are signed via Docker Content Trust, which uses SHA256 digests. |
V-222571 |
The application must utilize FIPS-validated cryptographic modules when generating cryptographic hashes. |
Not a Finding |
Container images are signed via Docker Content Trust, which uses SHA256 digests. |
V-222572 |
The application must utilize FIPS-validated cryptographic modules when protecting unclassified information that requires cryptographic protection. |
Informational |
Conformant data protection techniques should be implemented by the Data Storage service, and/or by Ingress configuration of the Container Platform. |
V-222573 |
Applications making SAML assertions must use FIPS-approved random numbers in the generation of SessionIndex in the SAML element AuthnStatement. |
Not Applicable |
The project does not use SAML assertions. |
V-222574 |
The application user interface must be either physically or logically separated from data storage and management interfaces. |
Not a Finding |
Web application is logically separated from data storage layer. Authorization for privileged access determined by the OIDC Provider, also logically separated. Web application offers no application configuration functionality in the application itself. |
V-222575 |
The application must set the HTTPOnly flag on session cookies. |
Informational |
The web application does not set session cookies. OIDC Provider must be configured appropriately. |
V-222576 |
The application must set the secure flag on session cookies. |
Informational |
The web application does not set session cookies. OIDC Provider must be configured appropriately. |
V-222577 |
The application must not expose session IDs. |
Informational |
The web application does not set session cookies. OIDC Provider must be configured appropriately. |
V-222578 |
The application must destroy the session ID value and/or cookie on logoff or browser close. |
Informational |
The web application does not set session cookies. OIDC Provider must be configured appropriately. |
V-222579 |
Applications must use system-generated session identifiers that protect against session fixation. |
Informational |
The web application does not set session cookies. OIDC Provider must be configured appropriately. |
V-222580 |
Applications must validate session identifiers. |
Informational |
The web application does not set session cookies. OIDC Provider must be configured appropriately. |
V-222581 |
Applications must not use URL embedded session IDs. |
Informational |
The web application does not set session cookies. OIDC Provider must be configured appropriately. |
V-222582 |
The application must not re-use or recycle session IDs. |
Informational |
The web application does not set session cookies. OIDC Provider must be configured appropriately. |
V-222583 |
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. |
Informational |
The web application expects OAuth2 tokens to be signed by the OIDC Provider using FIP-140-2 validated algorithms . |
V-222584 |
The application must only allow the use of DoD-approved certificate authorities for verification of the establishment of protected sessions. |
Informational |
The project expects DoD-approved CAs to be referenced by the OIDC Provider. |
V-222585 |
The application must fail to a secure state if system initialization fails, shutdown fails, or aborts fail. |
Informational |
The project expects fail-safe procedures to be implemented by the Container Platform (i.e, k8s). The web application is provided as a stateless container that caches no data and will not respond with data to requests when components are inoperable or inaccessible. |
V-222586 |
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. |
Informational |
The project expects fail-safe procedures to be implemented by the Container Platform (i.e, k8s). The web application is provided as a stateless container that caches no data and will not respond with data to requests when components are inoperable or inaccessible. |
V-222587 |
The application must protect the confidentiality and integrity of stored information when required by DoD policy or the information owner. |
Informational |
The project expects conformant data storage procedures to be implemented by the Data Storage layer. |
V-222588 |
The application must implement approved cryptographic mechanisms to prevent unauthorized modification of organization-defined information at rest on organization-defined information system components. |
Informational |
The project expects conformant data storage procedures to be implemented by the Data Storage layer. |
V-222589 |
The application must use appropriate cryptography in order to protect stored DoD information when required by the information owner or DoD policy. |
Informational |
The project expects conformant data storage procedures to be implemented by the Data Storage layer. |
V-222590 |
The application must isolate security functions from non-security functions. |
Not a Finding |
The project RBAC is described in the documentation. |
V-222591 |
The application must maintain a separate execution domain for each executing process. |
Not a Finding |
The project should be deployed as an immutable, stateless container that runs in a single, isolated execution domain. |
V-222592 |
Applications must prevent unauthorized and unintended information transfer via shared system resources. |
Not a Finding |
The project should be deployed as an immutable, stateless container that is isolated from other host processes (i.e, k8s) |
V-222593 |
XML-based applications must mitigate DoS attacks by using XML filters, parser options, or gateways. |
Not a Finding |
The project uses the library ‘fast-xml-parser’ a maintained library whose development pipeline tests itself against XML based attacks. |
V-222594 |
The application must restrict the ability to launch Denial of Service (DoS) attacks against itself or other information systems. |
Informational |
The project expects to be deployed in a Container Platform that resists DoS attacks. |
V-222595 |
The web service design must include redundancy mechanisms when used with high-availability systems. |
Informational |
The project expects to be deployed in a Container Platform that provides high-availability services. |
V-222596 |
The application must protect the confidentiality and integrity of transmitted information. |
Informational |
The project expects to be deployed in a Container Platform that protects the confidentiality and integrity of transmitted information. |
V-222597 |
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). |
Informational |
The project expects to be deployed in a Container Platform that protects the confidentiality and integrity of transmitted information. |
V-222598 |
The application must maintain the confidentiality and integrity of information during preparation for transmission. |
Informational |
The project expects to be deployed in a Container Platform that protects the confidentiality and integrity of transmitted information. |
V-222599 |
The application must maintain the confidentiality and integrity of information during reception. |
Informational |
The project expects to be deployed in a Container Platform that protects the confidentiality and integrity of transmitted information. |
V-222600 |
The application must not disclose unnecessary information to users. |
Not a Finding |
Error messages addressed by Issue #483 |
V-222601 |
The application must not store sensitive information in hidden fields. |
Not a Finding |
No sensitive authentication or session data is stored in hidden fields. SonarCloud scans, including OWASP tests, are run regularly to identify vulnerabilities. Manual testing also performed. See project Security Advisories page on GitHub for any known vulnerabilities. |
V-222602 |
The application must protect from Cross-Site Scripting (XSS) vulnerabilities. |
Not a Finding |
SonarCloud scans, including OWASP tests, are run regularly to identify vulnerabilities. Manual testing also performed. See project Security Advisories page on GitHub for any known vulnerabilities. |
V-222603 |
The application must protect from Cross-Site Request Forgery (CSRF) vulnerabilities. |
Not a Finding |
SonarCloud scans, including OWASP tests, are run regularly to identify vulnerabilities. Manual testing also performed. See project Security Advisories page on GitHub for any known vulnerabilities. |
V-222604 |
The application must protect from command injection. |
Not a Finding |
SonarCloud scans, including OWASP tests, are run regularly to identify vulnerabilities. Manual testing also performed. See project Security Advisories page on GitHub for any known vulnerabilities. |
V-222605 |
The application must protect from canonical representation vulnerabilities. |
Not a Finding |
SonarCloud scans, including OWASP tests, are run regularly to identify vulnerabilities. Manual testing also performed. See project Security Advisories page on GitHub for any known vulnerabilities. |
V-222606 |
The application must validate all input. |
Not a Finding |
API input is validated against the OAS definition. SonarCloud scans, including OWASP tests, are run regularly to identify vulnerabilities. Manual testing also performed. See project Security Advisories page on GitHub for any known vulnerabilities. |
V-222607 |
The application must not be vulnerable to SQL Injection. |
Not a Finding |
All SQL queries that process user input are parameterized. SonarCloud scans, including OWASP tests, are run regularly to identify vulnerabilities. Manual testing also performed. See project Security Advisories page on GitHub for any known vulnerabilities. |
V-222608 |
The application must not be vulnerable to XML-oriented attacks. |
Not a Finding |
SonarCloud scans are run regularly to identify XML vulnerabilities. SonarCloud scans, including OWASP tests, are run regularly to identify vulnerabilities. Manual testing also performed. See project Security Advisories page on GitHub for any known vulnerabilities. |
V-222609 |
The application must not be subject to input handling vulnerabilities. |
Not a Finding |
All user input is validated on both the client and the server. SonarCloud scans, including OWASP tests, are run regularly to identify vulnerabilities. Manual testing also performed. See project Security Advisories page on GitHub for any known vulnerabilities. |
V-222610 |
The application must generate error messages that provide information necessary for corrective actions without revealing information that could be exploited by adversaries. |
Not a Finding |
Error messages addressed by Issue #483 |
V-222611 |
The application must reveal error messages only to the ISSO, ISSM, or SA. |
Not a Finding |
Error messages addressed by Issue #483 |
V-222612 |
The application must not be vulnerable to overflow attacks. |
Not a Finding |
SonarCloud scans, including OWASP tests, are run regularly to identify vulnerabilities. Manual testing also performed. See project Security Advisories page on GitHub for any known vulnerabilities. |
V-222613 |
The application must remove organization-defined software components after updated versions have been installed. |
Not a Finding |
Dependabot services provided by GitHub to identify vulnerable software components. SonarCloud scans, including OWASP tests, are run regularly to identify vulnerabilities. Manual testing also performed. See project Security Advisories page on GitHub for any known vulnerabilities. |
V-222614 |
Security-relevant software updates and patches must be kept up to date. |
Not a Finding |
Dependabot services provided by GitHub to identify vulnerable software components. SonarCloud scans, including OWASP tests, are run regularly to identify vulnerabilities. Manual testing also performed. See project Security Advisories page on GitHub for any known vulnerabilities. |
V-222615 |
The application performing organization-defined security functions must verify correct operation of security functions. |
Not Applicable |
The application is not designed or intended to perform security function testing. |
V-222616 |
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. |
Not Applicable |
The application is not designed or intended to perform security function testing. |
V-222617 |
The application must notify the ISSO and ISSM of failed security verification tests. |
Not Applicable |
The application is not designed or intended to perform security function testing. |
V-222618 |
Unsigned Category 1A mobile code must not be used in the application in accordance with DoD policy. |
Not Applicable |
No Category 1A present in the application. The SPA mobile code executes within the client browser. |
V-222619 |
The ISSO must 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. |
Informational |
Account management services are provided by the external OpenID Connect (OIDC) Provider. |
V-222620 |
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 DoD DMZ. |
Informational |
Determined by deployment configuration. |
V-222621 |
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. |
Informational |
Application log entries are written to the container’s STDOUT, to be captured by the deployment’s preferred and compliant logging solution. |
V-222622 |
The ISSO must review audit trails periodically based on system documentation recommendations or immediately upon system security events. |
Informational |
Dependent on organizational compliance. Application log entries are written to the container’s STDOUT, to be captured by the deployment’s preferred and compliant logging solution. |
V-222623 |
The ISSO must report all suspected violations of IA policies in accordance with DoD information system IA procedures. |
Informational |
Dependent on organizational compliance. |
V-222624 |
The ISSO must ensure active vulnerability testing is performed. |
Informational |
Dependent on organizational compliance. |
V-222625 |
Execution flow diagrams and design documents must be created to show how deadlock and recursion issues in web services are being mitigated. |
Not a Finding |
By design, the application web service is not subject to deadlocking as it does not call the client. |
V-222626 |
The designer must ensure the application does not store configuration and control files in the same directory as user data. |
Not a Finding |
Application is provided as a stateless container. |
V-222627 |
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. |
Informational |
Dependent on organizational compliance. Deployment and security guidance available in project documentation. |
V-222628 |
New IP addresses, data services, and associated ports used by the application must be submitted to the appropriate approving authority for the organization, which in turn will be submitted through the DoD Ports, Protocols, and Services Management (DoD PPSM) |
Informational |
Dependent on organizational compliance. |
V-222629 |
The application must be registered with the DoD Ports and Protocols Database. |
Informational |
Dependent on organizational compliance. |
V-222630 |
The Configuration Management (CM) repository must be properly patched and STIG compliant. |
Informational |
Configuration management dependent on organizational compliance and processes. Application code hosted on GitHub according to Code.mil guidance. |
V-222631 |
Access privileges to the Configuration Management (CM) repository must be reviewed every three months. |
Informational |
Configuration management dependent on organizational compliance and processes. Application code hosted on GitHub according to Code.mil guidance. Codebase access restricted to repository administrators, which are publicly listed on the project’s GitHub site. |
V-222632 |
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. |
Informational |
Configuration management dependent on organizational compliance and processes. All project artifacts are publicly available on the GitHub site, in accordance with Code.mil guidance. |
V-222633 |
A Configuration Control Board (CCB) that meets at least every release cycle, for managing the Configuration Management (CM) process must be established. |
Informational |
Configuration management dependent on organizational compliance and processes. All project artifacts are publicly available on the GitHub site, in accordance with Code.mil guidance. |
V-222634 |
The application services and interfaces must be compatible with and ready for IPv6 networks. |
Informational |
Dependent on specific deployment. Web application is a Node.js application that includes support for IPv6. |
V-222635 |
The application must not be hosted on a general purpose machine if the application is designated as critical or high availability by the ISSO. |
Informational |
Dependent on organizational compliance. |
V-222636 |
A disaster recovery/continuity plan must exist in accordance with DoD policy based on the applications availability requirements. |
Informational |
Dependent on organizational compliance. |
V-222637 |
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. |
Informational |
Dependent on organizational compliance. |
V-222638 |
Data backup must be performed at required intervals in accordance with DoD policy. |
Informational |
Dependent on organizational compliance. |
V-222639 |
Back-up copies of the application software or source code must be stored in a fire-rated container or stored separately (offsite). |
Not a Finding |
Application codebase is stored in a GitHub repository (offsite). |
V-222640 |
Procedures must be in place to assure the appropriate physical and technical protection of the backup and restoration of the application. |
Informational |
Dependent on organizational compliance. |
V-222641 |
The application must use encryption to implement key exchange and authenticate endpoints prior to establishing a communication channel for key exchange. |
Informational |
The project expects other layers to provide appropriate data protection via compliant cryptography. |
V-222642 |
The application must not contain embedded authentication data. |
Not a Finding |
No passwords, certificates, or sensitive data are included in the source code. |
V-222643 |
The application must have the capability to mark sensitive/classified output when required. |
Not a Finding |
The application interface indicates its configured classification, and all exports are marked with the configured classification. |
V-222644 |
Prior to each release of the application, updates to system, or applying patches; tests plans and procedures must be created and executed. |
Not a Finding |
Github workflows test functionality and access controls before release. |
V-222645 |
Application files must be cryptographically hashed prior to deploying to DoD operational networks. |
Not a Finding |
The application is offered as containerized API/Web Client builds that are signed using Docker Content Trust. |
V-222646 |
At least one tester must be designated to test for security flaws in addition to functional testing. |
Not a Finding |
Automated feature and access control tests are run against every commit to the release branch. SonarCloud scans, including OWASP tests, are run regularly to identify vulnerabilities. Manual testing also performed. See project Security Policy for more information. |
V-222647 |
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. |
Informational |
Dependent on organizational compliance. |
V-222648 |
An application code review must be performed on the application. |
Informational |
SonarCloud scans, including OWASP tests and code reviews, are run regularly to identify vulnerabilities. Manual testing also performed. See project Security Policy for more information. Application source code is publicly available, and may be scanned at any time by any organization. |
V-222649 |
Code coverage statistics must be maintained for each release of the application. |
Informational |
Code coverage assessed for development using Node.js c8 and newman tests. Reports available upon request. |
V-222650 |
Flaws found during a code review must be tracked in a defect tracking system. |
Informational |
All known code defects are tracked as Issues on the project’s GitHub site, or developer’s SonarCloud management page. |
V-222651 |
The changes to the application must be assessed for IA and accreditation impact prior to implementation. |
Informational |
Dependent on organizational compliance. |
V-222652 |
Security flaws must be fixed or addressed in the project plan. |
Informational |
SonarCloud scans, including OWASP tests, are run regularly to identify vulnerabilities. Manual testing also performed. See project Security Policy page on GitHub for more info. |
V-222653 |
The application development team must follow a set of coding standards. |
Informational |
SonarCloud scans, including OWASP tests, and tests for coding standards, are run regularly to identify vulnerabilities. Manual testing also performed. See project Security Policy page on GitHub for more info. |
V-222654 |
The designer must create and update the Design Document for each release of the application. |
Informational |
Requires organizational compliance, project documentation, and project Security Policy. |
V-222655 |
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. |
Informational |
Requires organizational compliance, project documentation, and project Security Policy. |
V-222656 |
The application must not be subject to error handling vulnerabilities. |
Not a Finding |
Automated feature and access control tests are run against every commit to the release branch. SonarCloud scans, including OWASP tests, are run regularly to identify vulnerabilities. Manual testing also performed. See project Security Policy for more information. |
V-222657 |
The application development team must provide an application incident response plan. |
Not a Finding |
See project documentation and Security Policy. |
V-222658 |
All products must be supported by the vendor or the development team. |
Not a Finding |
Application is currently being actively maintained and supported. |
V-222659 |
The application must be decommissioned when maintenance or support is no longer available. |
Not a Finding |
Application is currently being actively maintained and supported. |
V-222660 |
Procedures must be in place to notify users when an application is decommissioned. |
Informational |
Dependent on organizational compliance. |
V-222661 |
Unnecessary built-in application accounts must be disabled. |
Not a Finding |
Application has no built-in user accounts. |
V-222662 |
Default passwords must be changed. |
Not a Finding |
Application has no default passwords. |
V-222663 |
An Application Configuration Guide must be created and included with the application. |
Not a Finding |
Project Documentation is provided. |
V-222664 |
If the application contains classified data, a Security Classification Guide must exist containing data elements and their classification. |
Informational |
Dependent on organizational compliance. |
V-222665 |
The designer must ensure uncategorized or emerging mobile code is not used in applications. |
Not a Finding |
Application uses only Category 3 mobile code. (Javascript that runs client side in a web browser) |
V-222666 |
Production database exports must have database administration credentials and sensitive data removed before releasing the export. |
Informational |
Dependent on organizational compliance. |
V-222667 |
Protections against DoS attacks must be implemented. |
Informational |
Threat model dependent on organizational requirements. The project expects to be deployed in a Container Platform that resists DoS attacks. DoS mitigations expected to be implemented at Container Platform Ingress layer or otherwise fulfilled by specific deployment configurations. |
V-222668 |
The system must alert an administrator when low resource conditions are encountered. |
Informational |
The project expects to be deployed in a Container Platform that monitors resource conditions. |
V-222669 |
At least one application administrator must be registered to receive update notifications, or security alerts, when automated alerts are available. |
Informational |
Dependent on organization compliance. Update notifications are available by subscription on GitHub project page. |
V-222670 |
The application must provide notifications or alerts when product update and security related patches are available. |
Not a Finding |
Update notifications are available by subscription on GitHub project page. |
V-222671 |
Connections between the DoD enclave and the Internet or other public or commercial wide area networks must require a DMZ. |
Informational |
Dependent on organizational compliance. |
V-222672 |
The application must generate audit records when concurrent logons from different workstations occur. |
Not a Finding |
When logging endpoint requests, the API emits audit records that include the original source IP address. |
V-222673 |
The Program Manager must verify all levels of program management, designers, developers, and testers receive annual security training pertaining to their job function. |
Not a Finding |
The current developers are subject to annual security training requirements. |