Attachment 0009 - Standard Operating Procedures.pdf

UNCLASSIFIED / FOR OFFICIAL USE ONLY

PEO EIS Cybersecurity SCR SOP i

Standard Operating Procedure

For the

Program Executive Office Enterprise Information Systems (PEO EIS) Cybersecurity Office

Software Code Review Process

(PEO EIS Cybersecurity Office SCR SOP)

Version 2

1 July 2019

Prepared by:

PEO EIS Cybersecurity 9350 Hall Road

Fort Belvoir, VA 22060 ii

Table of Contents

1. Introduction

1.1 SCR Overview and Relation to Assessment & Authorization Process

1.2 Background

1.3 Scope

1.3.1 COTS Software Exemption

1.4 Points of Contact (POC)

2. SCR Roles and Responsibilities

2.1 Software Code Review (SCR) Project Team Representative

2.2 PM SCR Representative

2.3 Static Code Analyzer Subject Matter Expert (SME)

2.4 PM Information Assurance Manager (IAM I-III depending on the PM designation on orders)

2.5 PM SCR Application Technical Representative

2.6 Developer SCR Application Technical Representative

2.7 Information System Security Officer (ISSO)

2.8 Authorizing Official (AO)

2.9 Summary of Responsibilities

3. Static Code Analyzer Fortify (Micro Focus)

3.1 Metrics from Micro Focus Fortify Static Code Analyzer

3.2 SCR Reporting Requirements for MDA

3.3 Required Metrics for PEO EIS Applications

4. PEO EIS Cybersecurity Office SCR Process

4.1 Step 1. SCR Kick-Off Meeting

4.2 Step 2. Source Code & SCR Artifacts Delivered

4.3 Step 3. Baseline SCA Scans Performed

4.4 Step 4. Audit and Triage of SCA Scans

4.4.1 How SCA Issues Are Classified

4.4.1.1 Classifying SCA Issues

4.5 Step 5. Scan Reports Delivered

4.5.1 Developer Report

4.6 Step 6. Assessment & Authorization (A&A) Documents Updated

4.6.1 Special Interest Issues

4.7 Step 7. Code Remediated

4.8 Step 7.A SCA Tools Installed Locally

4.8.1 Licensing Requirements and Agreement

4.8.2 Install and Training for Fortify

4.9 Step 8. New Code or Scan Reports Submitted

4.10 Step 9. Application SCR Status Submitted to AO or MDA

4.11 SCR Process for Classified Applications

5. SCR Contracting Requirements

6. Conclusion Appendix A – PEO EIS Policy Memorandum, Software Code Reviews ......... I Appendix B – References ........................................................................ III Appendix C – NDAA, Section 933 ............................................................. IV Appendix D – Sample SCR POA&M Entry................................................... V Appendix E – Source Code Delivery Requirements ................................... VI Appendix F – Application Registration ..................................................... IX Appendix G – Threat Model (STRIDE) ...................................................... XI Appendix H – SCR Developer Workbook Report ...................................... XII Appendix I – SCR Summary Report STIG ............................................... XVI iii

Appendix J – Licensing Agreement ......................................................... XX Appendix K –Fortify Training Types and Hardware Requirements .......... XXI Appendix L – Fortify Sourceanalyzer Software Requirements ............... XXII Appendix M – Mailing Classified Media ................................................ XXIV Appendix N – SCR Contract Boilerplate Language ................................. XXV Appendix O – Acronym List ................................................................. XXVI iv

List of Tables Table 1: Points of Contact Table 2: Software Release Points Requiring SCR Input to MDA Table 3: SCA Metric Requirements Table 4: Updated Source Code or Report Delivery Requirements

List of Figures Figure 1: Primary SCR Roles and Responsibilities Figure 2: The Software Code Review (SCR) Process Figure 3: Classified Application SCR Process Figure 4 (Replace with new Policy) ............................................................... I Figure 5 (Replace with new policy) ............................................................... I Figure 6: Sample SCR Summary Report ..................................................... XIV Figure 7: Sample Application Detail Sheet .............................................. XVIII

This document and all referenced documents can be found on the PEO EIS SharePoint portal:

https://peoeis.kc.army.mil/sites/cyber/SitePages/Cybersecurity.aspx

For the Software Code Review specific information, you will need to select the Software Code Review image on the link shown above.

https://web-mech02.mail.mil/owa/redir.aspx?C=0K29crC0oMu1yrdnnvK76sUm4Ylxuq_ueBSwuiW_ZlJcmf9RI97WCA..&URL=https%3a%2f%2fpeoeis.kc.army.mil%2fsites%2fcyber%2fSitePages%2fCybersecurity.aspx

1. Introduction This Standard Operating Procedure (SOP) defines the specifics of the Program Executive Office (PEO) Enterprise Information Systems (EIS) Software Code Review (SCR) process. The overall objective is to ensure software deployed by PEO EIS and its constituent Project Managers (PM), Project Directors (PD), Product Managers (PdM), and Product Leads (PL) meets or exceeds requirements for software quality and software assurance outlined within this document as authorized by PEO EIS Policy Memorandum, Software Code Reviews (Appendix A) and other statutory requirements referenced in section 1.2. The SCR process will be implemented with the use of automated static software code analysis tools to measure, remediate and improve Software Code Assurance (SCA) metrics.

1.1 SCR Overview and Relation to Assessment & Authorization Process This SOP provides the PEO EIS Software Code Review team with a standardized, but adaptable, process that is in line with PEO EIS, Department of the Army (DA), Department of Defense (DoD) and federal policies. The SCR process is a sub-element within the PEO EIS Assessment & Authorization (A&A) process. The A&A process is designed to certify that a system (i.e., General Support System [GSS] and a Major Application [MA]) meets documented security requirements and will continue to maintain the authorized security posture throughout the System Life Cycle (SLC).

This SOP describes the critical roles and responsibilities of Program staff, Contractor support staff, and key PEO EIS Cybersecurity Office personnel. This SOP identifies the steps involved in the SCR process, how those steps interact with the steps in the overarching A&A process and provides sample documents to assist in the SCR process.

1.2 Background

DoD Directive 8500.01 requires that all Information Assurance (IA) and IA-enabled Information Technology (IT) products incorporated into DoD information systems shall be configured in accordance with the DoD approved security configuration guidelines. Under the authority of DoD Directive 8500.1 the Defense Information Systems Agency (DISA) released the DISA Application Security and Development Security Technical Implementation Guide (DISA AS&D STIG). This STIG version is for immediate use as DoD-approved security configuration guideline. The DISA AS&D STIG is a series of application security requirements that apply to "all DoD developed, architected, and administered applications and systems connected to DoD networks."

The National Defense Authorization Act (NDAA) Section 933 specifically references requirements for automated static source code analysis for vulnerabilities and the adoption and promotion of software development best practices. Please refer to Appendix C for more information on the NDAA requirements referenced here. PEO EIS CYBER has determined that automated static source code analysis for security vulnerabilities and adherence to software development best practices and standards is currently a capability gap in the overall A&A process. PEO EIS Policy Memorandum Software Code Reviews was enacted to address this capability gap and, further, to ensure that the software delivered to PEO EIS and its constituent organizations has sufficient quality and security.

1.3 Scope

This document applies to all PEO EIS PM/PD/PdM/PL organizations (all four further referenced as “PM” or “PMs”), System Owners (SO), System Integrators (SI), and Software Developers tasked with the development or maintenance of software source code for an Information System (IS) that is registered in the Army Portfolio Management Solution (APMS) Army Information Technology Repository (AITR) and/or the Enterprise Mission Assurance Support Service (eMASS).

1.3.1 COTS Software Exemption

The SCR process does not apply to Commercial off the Shelf (COTS) software.

Examples include Microsoft Windows and Office products or Motorola communications software. However, any custom, customized, or modified code, including third-party software will be subject to the SCR process. Any PM that believes their application should not be subject to the SCR process because of the COTS exemption should contact the Program Information System Security Manager (P-ISSM) in the PEO EIS Cybersecurity Office. The final determination of whether any source code is considered COTS, and therefore subject to the SCR process, will be made solely by the PEO EIS Program Information System Security Manager (P-ISSM) and the SCR Project Lead.

1.4 Points of Contact (POC)

PEO EIS is responsible for the acquisition, integration, delivery, and support of interoperable enterprise information systems enabling seamless operations for the fleet, joint, and coalition war fighter. Army Regulation (AR) 25-2 specifies IA positions required to maintain the information assurance of DA information systems.

In accordance with (IAW) AR 25-2, and to clarify the responsible individuals for specified roles within this SOP, Table 1 lists the PEO EIS Cybersecurity Office and PEO EIS POCs related to the SCR process. POCs may vary depending on the specific Information System (IS).

Table 1: Points of Contact

Role Name Phone Email AO (PEO)1 Brendan Burke (703) 806-4200 brendan.p.burke.civ@mail.mil Cybersecurity Directorate (PEO) Manish D. Patel (703) 806-4219 manish.d.patel.civ@mail.mil

AODR

(PEO EIS Cybersecurity ) Manish D. Patel (703) 806-4219 manish.d.patel.civ@mail.mil

Security Operations Lead (PEO EIS Cybersecurity ) John C. Lammé (703) 806-0220 john.c.lamme.civ@mail.mil

SCR Project Team Lead Marwan Mina (703) 806-4189 marwan.m.mina.ctr@mail.mil SCR Project Team Robert Urquhart (703) 806-3627 robert.e.urquhart.ctr@mail.mil Program ISSM (PEO EIS Cybersecurity )2

Each system has their own

2. SCR Roles and Responsibilities Many positions within PEO EIS have significant roles that contribute to the Software Code Assurance (SCA) of a PEO EIS system as well as the associated application software code base throughout its Software Development Life Cycle (SDLC). The SCR process requires specific roles with significant input, oversight, and decision-making authority on the analysis, remediation and documentation of SCR issues. The SCR process integrates these roles throughout the SDLC and within the overarching A&A process. The SCR roles are:

• Software Code Review (SCR) Project Team Representative

• PM SCR Representative

• Static Code Analyzer Subject Matter Expert (SME)

• Information System Security Manager (ISSM)

• Information System Security Officer (ISSO)

• PM SCR Application Technical Representative

• Developer Application Technical Representative

• PEO EIS Cybersecurity ISSM (Program ISSM)

• Authorizing Official (AO)

Note: A single person may serve in more than one of the roles above. For example, the PM may choose to have the ISSM serve as the PM SCR Representative as well.

2.1 Software Code Review (SCR) Project Team Representative

The Software Code Review (SCR) Project Team Representative will be the individual responsible for coordinating all steps of the SCR process, implementing the requirements of this SOP, tracking and documenting all SCR-related activities for a given IS or application. This role will normally be filled by the SCR Project Lead, but may also be filled by another member of the SCR Project Team.

2.2 PM SCR Representative

The PM SCR Representative will be the individual responsible for serving as the primary POC for all SCR-related activities within the PM Office (PMO). This person will coordinate meetings and communications between the SCR Project team, the SI, and contractor software developers. This person will also report on SCR status to the PM and provide assistance to the SCR Project Team Representative as necessary.

2.3 Static Code Analyzer Subject Matter Expert (SME)

The SCA SME will be responsible for all software source code scanning, analysis and remediation recommendations in pursuit of SCA requirements for an application or IS. They will provide all SCA input to PM and developer reports produced and track all SCA metrics for individual applications, PMs, and across the PEO EIS portfolio.

This person will also provide all technical support and training in the use of SCA software tools.

Note: The Micro Focus Fortify Static Code Analyzer™ is the current static source code analysis tool being utilized by the SCR Project Team in pursuit of SCA goals.

2.4 PM Information Assurance Manager (IAM I-III depending on the PM designation on orders)

The IAM (DoDD 8140.01 and 8570.01-M which refer to the ISSM as an IAM level x) is appointed by the PM and is responsible for the security of the information system during the course of its operations. The ISSM ensures that the system is https://marketplace.microfocus.com/fortify?tab=categories implemented, maintained, and operated in a secure manner. In addition, the ISSM is the main POC with the RMF and SCR staff for negotiating A&A issues and to make recommendations to the command for additional protection mechanisms necessary prior to operation of an incoming IS. Therefore, the ISSM reviews all SCR scan reports, remediation actions and IA documentation (System Plan of Action & Milestones [POA&M] and SCR Application Detail Sheet) to ensure accuracy and completeness, and that they meet minimal risk acceptance standards.

Note: This individual is the same as the assigned ISSM in the overarching A&A process and SOP.

2.5 PM SCR Application Technical Representative

The PM SCR Application Technical Representative will be the individual from the PMO responsible for providing the SCR Project Team with technical information on the application architecture, security requirements, source code design and other technical information about a given application or IS needed by the SCR Project Team to properly scan and analyze the source code.

2.6 Developer SCR Application Technical Representative

The Developer SCR Application Technical Representative will be the individual from the SI or other contractor software developer responsible for the development and maintenance of a specific application or IS within the SCR process. This person will provide technical guidance on the source code being reviewed, coordinate meetings between the SCR Project Team and developers for detailed code audit and triage activities. This person will also be responsible for coordinating implementation and documentation of all remediation of the source code as determined necessary by the SCR process to meet requirements of the overarching PEO EIS Cybersecurity A&A process.

2.7 Information System Security Officer (ISSO)

The ISSO is the individual, assigned to a PM by the ISSM (PEO EIS Cybersecurity Office), responsible for coordinating and assisting RMF activities among other IA related actions. The ISSO will be responsible for reviewing the required SCR artifacts submitted to the AO or Milestone Decision Authority (MDA) as part of the SCR process and working with the SCR Project Team to brief the ISSM, AO or MDA as necessary, on any SCR issues related to the A&A process or software releases.

2.8 Authorizing Official (AO)

The AO is a senior government executive with the authority and responsibility to weigh the operational need of the system against the risk associated with its established security posture, as well as the risk it would impose on the Department of Defense Information Networks (DoDIN) and other systems. The AO must determine whether or not to personally accept the risk of its operations on behalf of the Army. The AO may grant an Authorization to Operate (ATO) or an Interim Authority to Test (IATT), or decide that the system weaknesses are of too great a risk and are unacceptable; therefore, refusing to allow the system to operate until findings are mitigated further. These decisions should be supported by the information contained in the authorization package including the current SCR status to include SCA metrics, open issues associated with each and remediation actions documented in the System POA&M and SCR Application Detail Sheet.

The primary A&A process roles and responsibilities are illustrated in Figure 1.

Figure 1: Primary SCR Roles and Responsibilities

2.9 Summary of Responsibilities

All senior management and/or program officials are in some way responsible for the quality and security of an IS or application’s source code. Therefore, they must be notified when a general support system or major application is operating without acceptable levels of SCA. Application or IS source code operating without meeting the SCA source code requirements outlined in this SOP will risk not being granted necessary authorization under RMF by the AO or release approval by the MDA and could potentially have adverse impact on PEO EIS primary missions.

Note: Some applications listed in eMASS do not have the DPEO as their AO or the PEO as their MDA. Those applications are still subject to the SCR process, but the AO and MDA for those applications may weigh the outputs of the SCR process differently than the PEO or DPEO. Regardless, all SCR metrics will be reported to the PEO, DPEO and CYBER at all relevant milestones in the A&A process.

3. Static Code Analyzer Fortify (Micro Focus) PEO EIS has acquired a static source code analysis tool to be used for the SCR to achieve the measurable, documented levels of software assurance that the MDA, AO, and Cybersecurity Office has set as acceptable thresholds in the A&A process. The Micro Focus Fortify Static Code Analyzer™ will be used to measure all the PEO EIS applications. The vulnerabilities of concern are categorized as either CAT I or CAT II.

3.1 Metrics from Micro Focus Fortify Static Code Analyzer

CAT I - Vulnerabilities that allow an attacker immediate access into a machine, allow super user access, or bypass a firewall.

CAT II - Vulnerabilities that provide information that have a high potential of giving access to an intruder.

Figure 2: Risk = Impact * Likelihood

The Static Code Analyzer tool will also assign a rating of Critical, High, Medium or Low to a vulnerability based on a compilation of software industry security best practices and the technology being used in the application.

3.2 SCR Reporting Requirements for MDA

In addition to the SCR Reporting requirements outlined for the AO within the A&A process, PMs will also be required to report on SCR status to the MDA for all Major and Minor software releases or updates. This applies only to those PMs and applications that have the PEO serve as the MDA. Table 2 shows the definitions https://marketplace.microfocus.com/fortify?tab=categories and version types that will require SCR input to the MDA. See section 4.10.2 of this SOP for more information on this reporting requirement.

Table 2: Software Release Points Requiring SCR Input to MDA

Type of Releases

MAJOR

(Full Release)

MINOR

(Point Release)

Definition

A significant change in the architecture or operation of the service

New COTS SW, HW, or O/S changes, but the fundamental architecture remains the same Version

Numbering 6.x 7.x 6.1 6.2

Approval Format

PEO Briefing / PEO Signed

Memo

PEO Package Review / PEO Signed Memo

3.3 Required Metrics for PEO EIS Applications

PEO EIS and CYBER have developed the following metric requirements for all applications seeking an ATO/IATT within the A&A process or release approval from the PEO when the PEO is serving as the MDA. Any application seeking an ATO/IATT that does not meet these required metric thresholds will document their current status, remediation plan and milestones in the System POA&M. All Major and Minor SW Releases going to the PEO for release approval must meet these requirements as those releases are considered new development. See section 4.6 of this SOP and Appendix D of this SOP for POA&M guidance as it relates to SCR findings.

Applications that are currently in production or have been previously authorized in the A&A process will have less stringent requirements, while new software development will be expected to utilize the SCR tools and process from inception and will therefore be held to stricter SCA requirements. Table 4 summarizes the SCA requirements for different types of applications.

Note: The specific requirements for any given application will be handled on an individual basis and will be communicated between the ISSM, SCR Project Team and the PM SCR Representative. Several factors such as Confidentiality, Integrity and Availability (CIA), how long the application has been in production, how long until projected End-of-Life (EOL) for the application, projected resourcing required to remediate findings and the mission of the application may cause the SCA requirements to be decreased or increased. All individualized requirements will be determined by the ISSM and will be communicated to the AO and PM as necessary.

Table 3: SCA Metric Requirements

NOTES

(1)“High Fix Priority”, “Critical” and “Exploitable” are all classifications for issues and will be documented in the SCR Application Detail Sheet. See section

4.4.1.2 of this SOP for information on how SCA issues are classified.

(2)CAT II Density percentage is calculated as (Total Open CAT II issues/Lines of Code [LOC]). See Section 4.4.1.2 of this SOP for information on how issues are classified as CAT I or II. LOC is determined by the Micro Focus Fortify software and is based on executable lines of code.

(3)The determination of what applications will be considered in this category is at the sole discretion of the ISSM and the AO

(4)Special Interest issues are at the discretion of the ISSM and the SCR Project Team. These will generally be focused on, but not limited to, Cross-Site Scripting (XSS) and SQL Injection vulnerabilities for all public-facing web applications.

http://en.wikipedia.org/wiki/Cross-site_scripting http://en.wikipedia.org/wiki/SQL_Injection

4. PEO EIS Cybersecurity Office SCR Process

The overall objective of the SCR process, as part of the overarching RMF process, is to ensure PEO EIS deploys applications with software that meets or exceeds SCA goals in an efficient framework that eliminates unforeseen delays in the application’s accreditation and/or release.

Most steps of the SCR process are tied directly or indirectly to one of the RMF process steps. The steps of the SCR Process are illustrated in Figure 3 below.

Note: The following steps are for Unclassified applications in eMASS. Refer to section 4.11 of this SOP for the special considerations that must be taken into account for Classified applications undergoing a code review.

Figure 2: The Software Code Review (SCR) Process

4.1 Step 1. SCR Kick-Off Meeting

The SCR Kick-Off Meeting can be held in person or via teleconference. The following personnel should be in attendance or identified as an outcome of the meeting:

• SCR Project Team Rep

• PM SCR Rep

• ISSM

• PM SCR Application Technical Rep

• Developer SCR Application Technical Rep

• ISSO (optional)

• SCR SME (SCA) (optional)

The purpose of the meeting is to provide an initial overview of the SCR goals and requirements from the perspective of the PEO EIS Cybersecurity Office, review the history and current status of the specific application in question and outline the rest of the steps of the process. The SCR Project Team will provide a list of required documentation needed to begin the SCR process and will document POC information for personnel filling the SCR roles outlined in section 2 of this SOP.

Actions:

• Application Registration (Appendix F)

• Review Application history and current mission

• Discuss SCR goals and requirements for remediation

• Plan for baseline source code delivery

4.2 Step 2. Source Code & SCR Artifacts Delivered

This step will normally occur shortly after the kick-off meeting. The completion of this step will allow the SCR team to begin scanning the application source code, analyzing results and producing preliminary reports.

Deliverables:

• Application source code with all required files (Appendix E)

• Application architecture (should include all Trust Boundaries)

• Application security requirements (Security Design Review docs)

• Application privacy requirements (Privacy Impact Analysis)

• Threat Model (STRIDE) documentation (Appendix G)

Once the code and other artifacts have been delivered the SCR SMEs will review and contact the SCR Application Tech. Rep. (PM or Dev.) or ISSM if anything else is required before performing the initial scans.

Note: For every Application within eMASS the deliverables outlined above were collected initially as part of SACO Tasker #2735 (via TMT) during the initial SCR deployment. This information will be updated or affirmed during Step 2.

4.3 Step 3. Baseline SCA Scans Performed

Once the SCR team has received the application source code and other required artifacts they will be able to perform the initial baseline scans using the SCA tools.

The reports generated by the SCA scanning tool will be unaudited and will need further input and/or validation from the development team before they can be used to remediate the source code.

Actions:

• Upload application source code into Cybersecurity SCR Code

Repository

• Configure Fortify scans based on Application Survey and other artifacts

• Run scans

• Perform initial scan analysis and classification http://msdn.microsoft.com/en-us/library/ee823878%28v=cs.20%29.aspx

4.4 Step 4. Audit and Triage of SCA Scans

The SCR SMEs for SCA will conduct the audit and triage of the source code scan reports in conjunction with the Developer SCR Application Technical Lead and any other personnel from the development team as necessary.

Actions:

• SCA SMEs meet with Dev. SCR Application Tech. Rep. and other developers, as necessary, to explain and review unaudited findings

• Final baseline classifications for all SCA issues determined

• Application baseline metrics for SCA recorded by SCR Project Team as benchmarks for future code remediation

4.4.1 How SCA Issues Are Categorized

The findings or “issues” that are reported by Fortify Static Analysis scans are classified in some important ways that determine the severity of the issue, potential impact, and the density of a given issue within the source code. The following two sections will explain how issues that are found in Fortify scans will be classified by the SCR Project Team.

4.4.1.1 Classifying SCA Issues

The primary designation that a Fortify issue or “vulnerability” will have is CAT I or CAT II. These are determined by the Fortify mapping of the DISA AS&D STIG.

The SCA SME and the Fortify tool will assign all issues a “Risk Mitigation Status” category as well. The possible statuses are:

Exploitable – This issue has the potential to be exploited by a known type of threat or attacker.

Suspicious – This issue may have the potential to be exploited by a known type of threat or attacker, but the SCA SME is unable to determine this without further information from the developer. This status will only exist before the final audit and triage classifications are determined.

Exploitable / Risk Accepted – This issue has been determined to be exploitable, but the impact of the issue is minimal or the effort required (in schedule or cost) to fix the issue outweighs the improved security posture from remediation. The development team and the SCR PM App. Tech. Rep.

can propose this status during the audit and triage process, but this status can only be assigned by the SCA SME or SCR Project Team.

Note: The ISSM and SCR Project Lead will have final say in the classification of all issues.

False Finding – This issue has been determined to not be a legitimate issue and will not be counted as an actionable issue for remediation. False findings will also be excluded from calculations involving issue density.

Note: All Exploitable / Risk Accepted and False Finding issues must have a documented rationale within the “Mitigation Comments” section of the SCR Application Detail Sheet. See section 4.5.2 for more information.

A Risk Level (High, Med, Low) will also be assigned to each issue by the SCA SME. This is based on the potential impact of the vulnerability being exploited and the likelihood of it occurring.

4.5 Step 5. Scan Reports Delivered

Once the SCR Project Team has completed the Static Code Analysis scan of the source code, they will audit and triage the vulnerabilities identified and generate a SCR Summary STIG report and submit it to the ISSO and ISSM of the Program. For a sample SCR Summary STIG report, refer to Appendix I – SCR Summary Report STIG . The details of what is contained in the STIG report is explained in the following section.

4.5.1 Developer Report

In addition to the SCR Summary STIG report, there will be an additional detailed report for developers generated by the Fortify tool “out of the box.” This report contain much more detail about each of the issues including coding language specific recommendations for remediation and greater detail on the best practice or security rule being violated. These reports are designed specifically for developers and will be provided to the development team at the same time the SCR Summary STIG Report is submitted to the ISSO and ISSM. For a sample SCR Developer Workbook report, refer to Appendix H – SCR Developer Workbook Report. The details of what is contained in the Developer Workbook report is explained in the following section

4.6 Step 6. Assessment & Authorization (A&A) Documents Updated All Applications that do not meet the metric guidelines for SCA outlined in section 3.3 of this SOP are required to document the need to remediate their code further within their System Plan of Action & Milestones (POA&M). The majority of open SCR issues will be entered as single line within the POA&M. The guidelines for how to enter SCR findings on the System POA&M are below. A sample POA&M entry for SCR findings is in Appendix D.

4.6.1 Special Interest Issues

There are two types of Micro Focus Fortify issues that are considered to be of special interest to CYBER. These are Cross-Site Scripting (XSS) and SQL Injection vulnerabilities on publically facing website applications. These issues will be identified in the SCR the Application Detail Sheet and the SCR AO Report.

These two vulnerabilities have been deemed to be of a criticality that requires special attention from Cyber, the PM and the developer. These issues should always be the first in the priority of issues to be fixed regardless of any other categorization of an issue. Further, at the discretion of the ISSM and ISSO, these issues may be addressed separately on the POA&M if necessary. This will be handled on a case-by-case basis and if deemed necessary the ISSO and the SCR Project Team will assist the ISSM in creating the POA&M entry.

4.7 Step 7. Code Remediated

Once the development team has received the SCR reports and updated their A&A documentation they can begin the code remediation. The fixes should address any Special Interest issues first and should then be worked based on the “Fix Priority”.

The schedule for releasing fixes into the production baseline via service pack, software patch or other method should be considered when breaking down the work http://en.wikipedia.org/wiki/SQL_Injection required into smaller segments. The SCR Project Team is available for support on SCA issues during this stage if the development team has questions or needs further insight into possible methods for addressing various findings.

Note: All source code changes must be put through the same test and evaluation protocols used in the normal development of the application. It will not be acceptable for a development team to lose functionality or “break” the current application and use the fixes required by the SCR process as the reason for the loss in current availability or functionality of the system.

4.8 Step 7.A SCA Tools Installed Locally

The Micro Focus Fortify Static Analysis tools are both designed for use early and iteratively in the SDLC. With that in mind, each PM and development team will have the option of having the tools installed within their local development environment in order to audit their software as early as possible within the SDLC. This will be done sometime after the baseline scans and analysis have been done by the SCR Project Team within the Cyber environment. Installing these code auditing tools at the development site will allow the developer to identify and eliminate new issues on code that is still under development or was otherwise not captured during the baseline scan without relying on the availability of the SCR Project Team. This will prevent the PM and developer from waiting on future analysis by the SCR Project Team and, over time, will lead to higher quality and more secure code being developed early in the lifecycle.

Note: Due to the large number of applications normally in a queue for analysis by the SCR Project Team the PEO EIS Cyber strongly encourages each PM utilizing the SCA tools locally within their SDLC. This is especially true for any PM and/or development team that utilizes agile development methods.

4.8.1 Licensing Requirements and Agreement

PEO EIS Cyber has purchased a limited amount of licenses for Micro Focus Fortify Static Code Analyzer to be used by the PMs and their developers for code auditing within their SDLC. These licenses will be provided, at the discretion of Cyber and the ISSM, to the PMs for code audit use strictly on software developed for PEO EIS and its constituent programs. Any use of Fortify software, by the PM or developer, outside of this scope can result in penalties or fees. PEO EIS Cyber reserves the right, at any time, to remove the licenses and software from the PM, SI or developer if they are needed elsewhere due to mission priority or due to unlicensed usage of the software.

Each PM and SI, that chooses to have the tools installed within their SDLC, is required to sign the agreement in Appendix J acknowledging the purpose and scope of the licenses and software that may be provided by PEO EIS Cyber. This agreement will be kept on file by the SCR Project Team. If a PM, SI or contractor is interested in purchasing additional licenses for Micro Focus Fortify or the Micro Focus Fortify Developer Plug-In they should contact the SCR Project Lead so that the Cyber office can negotiate on their behalf to acquire these resources.

http://en.wikipedia.org/wiki/Agile_software_development

4.8.2 Install and Training for Fortify

If the PM chooses to have Fortify tools installed locally then the SCR Project Team will coordinate a timeframe to complete the install and training required to use the tools properly. It is recommended that each tool be handled separately as far as coordinating the install and training. The SCR Project Team will work with the ISSM, PM SCR Application Tech. Rep., Dev. SCR Application Tech. Rep and other development team members to coordinate a time and location to conduct the install and training.

Training takes an average of two days for each tool, but the specific needs vary greatly depending on the type of training required for various roles in the development or oversight process as well as the mix of technology being used in the application. Refer to Appendix K for details on the types of training for Fortify as well as the hardware requirements for local installation of the tools and for training.

4.9 Step 8. New Code or Scan Reports Submitted

The PM will provide updated source code to the SCR Project Team periodically depending on approaching IA or SW release milestones. Alternatively, if PMs have chosen to install the Static Analysis tool into their SDLC they may simply provide the output reports from those tools. The SCR Project Team will audit/review the configurations of the Static Analysis tool to ensure they are in sync with the baseline scans and overall PEO EIS configurations. Table 4 below details the requirements for delivery of updated source code or output reports from the SCA tools for various milestones within the SCR process.

Note: The timelines below all assume that that the application baseline scan and analysis have already been completed. This may not be the case in the early stages of the SCR project rollout or for applications new to the SCR process. In those instances the baseline scan and analysis will also serve as the milestone reporting requirement.

Table 4: Updated Source Code or Report Delivery Requirements

Update Delivery Process

Updated Source Code

Delivered

Updated SCA/SCQ Tool

Reports Delivered

Milestones

Minor Software Release 4 Months Prior to "Go Live" 1 Month Prior to

"Go Live"

Major Software Release 6 Months Prior to "Go Live" 1 Month Prior to

"Go Live"

1-3 Years from ATO Decision

Once Annually as part of PM FISMA visit

Once Annually as part of PM FISMA visit

< 1 Year from ATO Decision

12 months and 6 months from

ATO

Once Quarterly

4.10 Step 9. Application SCR Status Submitted to AO or MDA

There are two milestones that require the SCR Project Team to provide standard reports on a PM and application’s current SCR status to PEO EIS leadership. For applications seeking an ATO or IATT through the normal A&A process the AO SCR Report will be created. For applications with a pending “Major” or “Minor” Software Release the SCR Status will be reporting the Milestone Decision Authority (MDA) using the PEO EIS Fielding Decision Brief.

4.11 SCR Process for Classified Applications

The requirements and artifacts for the SCR Process are the same as the unclassified process, but there may be some additional precautions needed in order to process and share the information involved. The application’s ISSM, with assistance from the ISSO and the ISSM, will need to make a determination about the classification level of the source code itself as well as the appropriate classification level of any the reports generated by the SCA tools. This information can be found in the application’s Security Classification Guide (SCG). Figure 3 below outlines the classified application SCR Process and its unique actions.

Note: Any uncertainty about the classification level of the application source code or reports generated about that source code should be brought up to the SCR Project Team, the ISSM and the ISSO before any information is shared.

Figure 3: Classified Application SCR Process

NOTES

(1)See Appendix M for instructions to mail classified media if you are not local to the PEO EIS HQ.

(2)For Classified Applications at least one POC from the PM must have a registered SIPRNet email account in order to receive classified SCR documents.

5. SCR Contracting Requirements

PEO EIS Policy Memorandum, PEO EIS Software Code Reviews (SCR), Section 4(f) states:

PMs must include the use of Static Analysis tools in any and all future contracts involving software development. These contracts must incorporate the use of these tools within the software development process and/or project schedule.

Appendix P contains boilerplate Performance Work Statement (PWS) language that can be used directly or modified as the PM feels necessary to address this requirement. PMs are encouraged to incentivize the SCA goals outlined in this SOP and to share any innovative or differing contracting language with the PEO EIS Cyber.

Any questions about structuring contracting language to meet this requirement should be directed to the PEO EIS Procurement Assistance Division (PAD) under the Operations and Theater Support Directorate (OTSD). See Table 1 for POC information.

6. Conclusion

PEO EIS is positioning itself as a leader within the DoD with this SCR Policy and SOP.

The goals within will position PEO EIS ahead of the curve of federal law for software development and will ensure we are fielding the highest quality (and lowest cost) software possible while documenting the best possible security posture possible for our software. It will take time and effort to integrate the requirements of the SCR process into current PM missions and SDLCs, but the long-term benefits of this effort are undeniable. This SOP will continue to be updated and modified as the mission needs are further understood and refined. It is no longer good enough for PMs to simply trust that the applications they are developing adhere to the known best practices of Software Code Quality or the specific Software Code Assurance requirements of the DISA AS&D STIG. The process laid out in this SOP will give the Cybersecurity Office and, more importantly, the PMs the ability to ensure that PEO EIS develops the best possible software applications with documented software code assurance and software code quality levels.

I

Appendix A – PEO EIS Policy Memorandum, Software Code Reviews (To be replaced with the new signed copy)

Figure 4 (Replace with new Policy)

Figure 5 (Replace with new policy)

II

III

Appendix B – References

1. PEO EIS Policy Memorandum, PEO EIS Software Code Reviews (SCR)

2. DISA Application Security and Development (AS&D) Security Technical Implementation Guide (STIG), most current version.

3. The Program Protection Plan outline and guidance on Software Assurance, July 2010.

4. The FY11 National Defense Authorization Act Section 932 on Software Assurance, 7 January 2011.

5. The FY13 National Defense Authorization Act Section 933 on Software Assurance, 3 January 2013.

6. PEO EIS Cybersecurity Office Plan of Action and Milestone Standard Operating Procedure, 8 November 2011.

7. PEO EIS Policy #12-12 Security Classification Guide (SCG), 5 January 2012

8. DoD Directive 8500.1, Cybersecurity, 14 March 2014.

9. DoDI 8510.01, DoD Risk Management Frameword (RMF), 28 July 2017.

10. Army Regulation Number 25-2, Army Cybersecurity, 4 April 2019.

11. PEO EIS Policy Memorandum 13-08, PEO EIS Cybersecurity Program, 10 December 2012.

IV

Appendix C – NDAA, Section 933

SEC. 933. IMPROVEMENTS IN ASSURANCE OF COMPUTER SOFTWARE

PROCURED BY THE DEPARTMENT OF DEFENSE.

(a) BASELINE SOFTWARE ASSURANCE POLICY.—The Under Secretary of Defense for Acquisition, Technology, and Logistics, in coordination with the Chief Information Officer of the Department of Defense, shall develop and implement a baseline software assurance policy for the entire lifecycle of covered systems. Such policy shall be included as part of the strategy for trusted defense systems of the Department of Defense.

(b) POLICY ELEMENTS.—The baseline software assurance policy under subsection (a) shall—

(1) Require use of appropriate automated vulnerability analysis tools in computer software code during the entire lifecycle of a covered system, including during development, operational testing, operations and sustainment phases, and retirement;

(2) Require covered systems to identify and prioritize security vulnerabilities and, based on risk, determine appropriate remediation strategies for such security vulnerabilities;

(3) Ensure such remediation strategies are translated into contract requirements and evaluated during source selection;

H. R. 4310—254

(4) Promote best practices and standards to achieve software security, assurance, and quality; and

(5) Support competition and allow flexibility and compatibility with current or emerging software methodologies.

(c) VERIFICATION OF EFFECTIVE IMPLEMENTATION.—The Under Secretary of Defense for Acquisition, Technology, and Logistics, in coordination with the Chief Information Officer of the Department of Defense, shall—

(1) Collect data on implementation of the policy developed under subsection (a) and measure the effectiveness of such policy, including the particular elements required under subsection (b); and

(2) Identify and promote best practices, tools, and standards for developing and validating assured software for the Department of Defense.

(d) BRIEFING ON ADDITIONAL MEANS OF IMPROVING SOFTWARE ASSURANCE.—Not later than one year after the date of the enactment of this Act, the Under Secretary for Acquisition, Technology, and Logistics shall, in coordination with the Chief Information Officer of the Department of Defense, provide to the congressional defense committees a briefing on the following:

(1) A research and development strategy to advance capabilities in software assurance and vulnerability detection.

(2) The state-of-the-art of software assurance analysis and test.

(3) How the Department might hold contractors liable for software defects or vulnerabilities.

(e) DEFINITIONS.—In this section:

(1) COVERED SYSTEM.—The term ‘‘covered system’’ means any Department of Defense critical information, business, or weapons system that is—

(A) a major system, as that term is defined in section 2302(5) of title 10, United States Code;

(B) a national security system, as that term is defined in section 3542(b)(2) of title 44, United States Code;

or

(C) a Department of Defense information system categorized as Mission Assurance Category I in Department of Defense Directive 8500.01E that is funded by the Department of Defense.

(2) SOFTWARE ASSURANCE – The term “software assurance” means the level of confidence that software functions as intended and is free of vulnerabilities, either intentionally or unintentionally designed or inserted as part of the software, throughout the life cycle.

V

Appendix D – Sample SCR POA&M Entry

Note: The Excel version of this document can be found at the Software Code Review Page of the PEO EIS SharePoint Site for download.

https://peoeis.kc.army.mil/sites/G6/SitePages/softwarereview.aspx

VI

Appendix E – Source Code Delivery Requirements

Transmission and Mailing of Classified and Unclassified Media:

The PEO EIS programs and all personnel must comply with local security policies and procedures for the transmitting classified or unclassified data.

Please provide:

• All production source code

• 3rd party SW

• Libraries application is dependent on

• DLLs

• For SAP applications the SCA SME will provide the SCR Dev. App. Tech. Rep. with an ABAP extractor program to access the ABAP code, schemas, and database information necessary to perform the scans with Fortify

• Depending on the application technology portfolio (coding language, DB architecture, etc.) there may be some further specific code delivery requirements. The SCR SMEs for SCA can provide further guidance as needed.

Classified Transfer Methods

• DVD

Unclassified Transfer Methods

• AMRDEC S.A.F.E. site is strongly preferred. The email address to give access to in AMRDEC is the SCR distribution email: USARMY Ft Belvoir PEO EIS List PEO-SCR (usarmy.belvoir.peo-eis.list.peo-scr@mail.mil).

• DVD

https://safe.apps.mil/ mailto:usarmy.belvoir.peo-eis.list.peo-scr@mail.mil

VII

Flow-chart for the Software Code Review process:

VIII

IX

Appendix F – Application Registration Go to Sharepoint site: Register Application and click on the Register Your Application green button at the top right-hand side. Once you do you will see the following screens:

X

Note: You will need to fill out all mandatory fields (which contain an asterisk *)

XI

Appendix G – Threat Model (STRIDE)

Microsoft Threat Model page https://www.microsoft.com/en-us/securityengineering/sdl/threatmodeling

XII

Appendix H – SCR Developer Workbook Report

XIII

XIV

Figure 6: Sample SCR Summary Report

1. Fortify Engine Version – This is the version of the Fortify source analyzer.

2. Summary of Critical Issues – This table shows a breakdown of the number of unique Critical vulnerability issues. The Fortify Priority Order groups issues as Critical based on the source analyzer’s combined values of impact and likelihood that the identified security vulnerability will occur. A Critical rating means that a particular vulnerability has a high likelihood of being exploited, and once exploited, the impact is high.

3. Summary of High Issues – This table shows a breakdown of the number of unique High vulnerability issues. The Fortify Priority Order groups issues as High based on the source analyzer’s combined values of impact and likelihood that the identified security vulnerability will occur. A High rating means that a particular vulnerability has a low likelihood of being exploited, but once exploited, the impact is high.

4. Category – A comprehensive list of all categories of issues found. This report also gives a high-level summary of the number of issues in each category.

5. Number of Critical Vulnerabilities - This part of the report lists the number of Critical vulnerabilities found in each category. The first number of the two

XV

number value is the number of vulnerabilities that have been analyzed or assessed with either: Not an Issue, Reliability Issue, Bad Practice, Suspicious, or Exploitable. The second number is the total number of vulnerabilities found for that particular category.

6. Number of High Vulnerabilities – This part of the report lists the number of

High vulnerabilities found in each category. The first number of the two number value is the number of vulnerabilities that have been analyzed or assessed with either: Not an Issue, Reliability Issue, Bad Practice, Suspicious, or Exploitable.

The second number is the total number of vulnerabilities found for that particular category.

7. Evaluating Issues – This section identifies the group of issues that was detected by the dataflow analyzer. It includes an explanation of the conditions in which this type of issue occurs. This includes a discussion of the vulnerability, the constructs typically associated with it, how an attacker can exploit it, and the potential consequences of an attack.

8. Source Code Location – This shows the module or package within the source code where the issue can be found. Filtering the issues by this column will allow the PM and development team to see where, within the source code, that issues may be persistent.