Attachment_8_FMF_App_Security_Control_Selection_Worksheet.xlsx

Instructions

FMF App Security Controls

Risk Management Framework (RMF) Security Control Selection Worksheet

DoD has defined the software components as any software components when the vendor provides digitally signed products. The organization conducting the inspection/assessment obtains and examines the documented process for preventing the installation of software onto any software components when the vendor provides digitally signed products without verification that software has been digitally signed using a certificate and approved by the organization.

The organization conducting the inspection/assessment reviews software on a sampling of the defined components to ensure that only software digitally signed by a defined CA is installed.

DoD has defined the security configuration checklists as DoD security configuration or implementation guidance (e.g. STIGs, NSA configuration guides, CTOs, DTMs etc.).

The organization conducting the inspection/assessment obtains and examines the documented process to ensure the organization being inspected/assessed implements DoD security configuration or implementation guidance (e.g. STIGs, NSA configuration guides, CTOs, DTMs etc.).

The organization conducting the inspection/assessment tests a sampling of information system components to ensure they comply with the required settings.

• Time of check, time of use: the time in which a given resource is checked, and the time that resource is used.

• Thread based: two threads of execution use a resource simultaneously, resource may be invalid when used.

Switch based: variable switches values while switch statement is in progress. Developers must be cognizant of programming sequence and use sanity checks to validate data prior to acting upon it. A code review or a static code analysis is the method used to identify race conditions.

SI-10 CCI-001310 The information system checks the validity of organization-defined inputs. The organization being inspected/assessed configures the information system to check the validity of all inputs except those identified specifically by the organization.

For information system components that have applicable STIGs or SRGs, the organization being inspected/assessed must comply with the STIG/SRG guidance that pertains to CCI 1310.

DoD has defined the information inputs as all inputs except those identified specifically by the organization. The organization conducting the inspection/assessment examines the information system to ensure the organization being inspected/assessed configures the information system to check the validity of all inputs except those identified specifically by the organization.

For information system components that have applicable STIGs or SRGs, the organization conducting the inspection/assessment evaluates the components to ensure that the organization being inspected/assessed has configured the information system in compliance with the applicable STIGs and SRGs pertaining to CCI 1310.

For information system components that have applicable STIGs or SRGs, the organization being inspected/assessed must comply with the STIG/SRG guidance that pertains to CCI 1310.

DoD has defined the information inputs as all inputs except those identified specifically by the organization. The organization conducting the inspection/assessment examines the information system to ensure the organization being inspected/assessed configures the information system to check the validity of all inputs except those identified specifically by the organization.

For information system components that have applicable STIGs or SRGs, the organization conducting the inspection/assessment evaluates the components to ensure that the organization being inspected/assessed has configured the information system in compliance with the applicable STIGs and SRGs pertaining to CCI 1310.

The organization being inspected/assessed configures the information system to behave in the documented manner when invalid inputs are received.

For information system components that have applicable STIGs or SRGs, the organization being inspected/assessed must comply with the STIG/SRG guidance that pertains to CCI 2754. The organization conducting the inspection/assessment obtains and examines the documented behavior to ensure the organization being inspected/assessed documents proper behavior that reflects organizational and system objectives for when invalid inputs are received.

The organization conducting the inspection/assessment examines the information system to ensure the organization being inspected/assessed configures the information system to behave in the documented manner when invalid inputs are received.

For information system components that have applicable STIGs or SRGs, the organization conducting the inspection/assessment evaluates the components to ensure that the organization being inspected/assessed has configured the information system in compliance with the applicable STIGs and SRGs pertaining to CCI 2754. APSC-DV-002560 Discussion: A common application vulnerability is unpredictable behavior due to improper input validation. This requirement guards against adverse or unintended system behavior caused by invalid inputs, where information system responses to the invalid input may be disruptive or cause the system to fail into an unsafe state. Data received from the user should always be suspected as being malicious and always validated prior to using it as input to the application. Some examples of input methods:

• Forms Data

• URL parameters

• Hidden Fields

• Cookies

• HTTP Headers or anything in the HTTP request

• Client data entry fields Items to validate:

• Out of range values/Boundary

• Data length

• Validate types of characters allowed

• Whitelist validation for known good data input while denying all other input

SI-16 CCI-002824 The information system implements organization-defined security safeguards to protect its memory from unauthorized code execution. The organization being inspected/assessed configures the information system to implement security safeguards defined in SI-16, CCI 2823 to protect its memory from unauthorized code execution.

For information system components that have applicable STIGs or SRGs, the organization being inspected/assessed must comply with the STIG/SRG guidance that pertains to CCI 2824. The organization conducting the inspection/assessment examines the information system to ensure the organization being inspected/assessed configures the information system to implement security safeguards defined in SI-16, CCI 2823 to protect its memory from unauthorized code execution.

Vulnerability scans are not the same as penetration testing.

DoD has defined the frequency as annually. The organization conducting the inspection/assessment obtains and examines the test and exercise plan documented in the security assessment plan as well as the results of one or more of the latest security assessments to ensure the organization being inspected/assessed is conducting the assessments required in their security assessment plan annually.

• Description of the configuration control and change management process

• Types of objects developed

• Roles and responsibilities of the organization The SCM plan should also contain the following:

• Defined responsibilities

• Actions to be performed

• Tools used in the process

• Techniques and methodologies

• Initial set of baselined software components The SCM plan should identify all objects that are under configuration management control. The SCM plan should identify third-party tools and respective version numbers. The SCM plan should identify mechanisms for controlled access of individuals simultaneously updating the same application component. The SCM plan assures only authorized changes by authorized persons are allowed. The SCM plan should identify mechanisms to control access and audit changes between different versions of objects subject to configuration control. The SCM plan should have procedures for label versions of application components and application builds under configuration management control. The configuration management repository (CMR) should track change requests from beginning to end. The configuration management repository (CMR) should authorize change requests to the application. The configuration management repository (CMR) should contain security classification labels for code and documentation in the repository. Classification labels are not applicable to unclassified systems. The configuration management repository (CMR) should monitor all objects under CMR control for auditing.

The organization being inspected/assessed requires the developer to enable integrity verification of software and firmware that may include:

1. Stipulating and monitoring logical delivery of products and services, requiring downloading from approved, verification-enhanced sites;

2. Encrypting elements (software, software patches, etc.) and supply chain process data in transit (motion) and at rest throughout delivery;

3. Requiring suppliers to provide their elements “secure by default”, so that additional configuration is required to make the element insecure;

4. Implementing software designs using programming languages and tools that reduce the likelihood of weaknesses;

5. Implementing cryptographic hash verification; and

6. Establishing performance and sub-element baseline for the system and system elements to help detect unauthorized tampering/modification during repairs/refurbishing.

• format string exploits

• memory leaks

• buffer overflows

• race conditions

• sql injection

• dead/unused/commented code

• input validation exploits The code review is conducted during the application development phase, this allows discovered security issues to be corrected prior to release. Code reviews performed after the development phase must eventually go back to development for correction so conducting the code review during development is the logical and preferred action. Automated code review tools are to be used whenever reviewing application source code. These tools are often incorporated into Integrated Development Environments (IDE) so code reviews can be conducted during all stages of the development life cycle. Periodically reviewing code during the development phase makes transition to a production environment easier as flaws are continually identified and addressed during the development phase rather than en masse at the end of the development effort. Code review processes and the tools used to conduct the code review analysis will vary depending upon application architecture and the development languages utilized. In addition to automated testing, manual code reviews may also be used to validate or augment automated code review results. Larger projects will have a large code base and will require the use of automated code review tools in order to achieve complete code review coverage. A manual code review may consist of a peer review wherein other programmers on the team manually examine source code and automated code review results for known flaws that introduce security bugs into the application. As with any testing, there is no single best approach and the tests must be tailored to the application architecture. Use of automated tools along with manual review of code and testing results is considered a best practice when conducting code reviews. This method is the most likely way to ensure the maximum number of errors are caught and addressed prior to implementing the application in a production environment.

• Indent style conventions

• Naming conventions

• Line length conventions

• Comment conventions

• Programming best practices

• Programming style conventions Coding standards allow developers to quickly adapt to code which has been developed by various members of a development team. Coding standards are useful in the code review process as well as in situations where a team member leaves and duties must then be assigned to another team member. Code conforming to a standard format is easier to read, especially if someone other than the original developer is examining the code. In addition, formatted code can be debugged and corrected faster than unformatted code. Introducing coding standards can help increase the consistency, reliability, and security of the application by ensuring common programming structures and tasks are handled by similar methods, as well as, reducing the occurrence of common logic errors.

SA-15 CCI-003233 The organization requires the developer of the information system, system component, or information system service to follow a documented development process. The organization being inspected/assessed requires within contracts/agreements that the developer of the information system, system component, or information system service to follow a documented development process. The organization conducting the inspection/assessment obtains and examines the contracts/agreements to ensure the organization being inspected/assessed requires that the developer of the information system, system component, or information system service to follow a documented development process. APSC-DV-003220 Discussion: This requirement is meant to apply to developers or organizations that are doing application development work. The application design document or configuration guide includes configuration settings, recommendations and best practices that pertain to the secure deployment of the application. It also contains the detailed functional architecture as well as any changes to the application architecture corresponding to a new version release and must be documented to ensure all risks are assessed and mitigated to the maximum extent practical.

Failure to do so may result in unexposed risk, and failure to mitigate the risk leading to failure or compromise of the system.

SA-15 (4) CCI-003256 The organization requires that developers perform threat modeling for the information system at organization-defined breadth/depth. The organization being inspected/assessed requires within contracts/agreements that the developers perform threat modeling for the information system at the breadth/depth defined in SA-15 (4), CCI 3258. The organization conducting the inspection/assessment obtains and examines the contracts/agreements to ensure the organization being inspected/assessed requires that the developers perform threat modeling for the information system at the breadth/depth defined in SA-15 (4), CCI 3258. APSC-DV-003230 Discussion: Threat modeling is an approach for analyzing the security of an application. It is a structured approach that enables you to identify, quantify, and address the security risks associated with an application. Threat modeling is not an approach to reviewing code, but it does complement the security code review process. Threat modeling can optimize application security by identifying objectives and vulnerabilities, and then defining countermeasures to prevent, or mitigate the effects of, threats to the system. The lack of threat modeling will potentially leave unidentified threats for attackers to utilize to gain access to the application. To execute a threat model you should do the following:

• Decompose the Application. The first step in the threat modeling process is gaining an understanding of the application and how it interacts with external entities. This includes identifying languages used by the application. It also includes identifying network connections and the means utilized to access the application.

• Determine and rank threats. Use a threat categorization methodology to understand the different threat categories. The goal of the threat categorization is to help identify threats both from the attacker perspective and the defensive perspective.

• Determine countermeasures and mitigation. A lack of protection against a threat might indicate a vulnerability whose risk exposure could be mitigated with the implementation of a countermeasure.

1. Identifies and documents physical security controls that require training.

2. Identifies personnel defined in AT-3 (2), CCI 2051

3. Ensures designated personnel receive this training annually

4. Maintains and monitors records of personnel who have received this training.

DoD has defined the frequency as annual. The organization conducting the inspection/assessment obtains and examines:

1. Documentation of physical security controls that require training.

2. Documented list of personnel defined in AT-3 (2), CCI 2051

3. Ensures identified personnel have received training annually.

DoD has defined the frequency as annual. APSC-DV-003400 Discussion: Many…