Attach006-FMS-ACES RFI - Requirements Master List_Ch1 Change Log.xlsx

Sheet1

- confirm or reject this is a valid requirement from a DoD perspective (in other words, are these still the standard or have they been superseded)

- tell us if this standard/requirement covered in one of the DoDD, DoDI, listed below; and if so, which one(s)

- tell us if requiring CAC log on and the use of Phishing Resistant MFA meet and/or exceed the standards specified here? Y Valid, but it is met with CAC authentication. This is a reference to CCA requirements and was written in 1996. We can keep it to save face or rewrite it so it just references more current policies. At this point, I think we leave it as is so it does not look like we had to change every cyber requirement we wrote in the RFI.

This assessment comes from reviewing the CCA checklist and response that Christine sent yesterday 41 Foundational Cyber The system shall provide the ability the use of a Demilitarized Zone (DMZ) in the system design is required for any remote access as well as any access to the Internet through systems that are isolated from all other DoD information systems through physical means. This requirement seems to be a subset of Requirements 44 and 51 below. In reviewing the DoD Cyber Exchange (Public) site (https://public.cyber.mil/stigs/downloads/) there are 552 active STIGS.

- From a requirements perspective, should we just require the system be compliant with all DoD Applicable STIGS or should we call them all out the important ones like this one?

-There are some CAC enabled STIGS (they are FOUO), only people with CAC enabled systems can pull them down, do systems on the NIPRNet have to comply with the FOUO STIGS?

- Is there a minimum set of STIGS that NIPRNet systems must adhere to (a subset of the 552) and if so, can you provide us with a list of the subset of STIGS?

-This may be a G6 question, but when a new system is created and it resides on the cARMY cloud, are there not many infrastructure requirements (as in STIG controls) that are automatically implemented (e.g., Cloud Security, Network, Perimeter, Wireless, Operating System)?

- Since this requirement is a subset of 44 and 51, we can probably drop this requirement (and 44) and still be covered by 51. Do you concur or do you have a different insight you can provide or different language we can apply in requirements? Y Based on my analysis, this one goes away and we write a more robust requirement 51 (and get rid of 44 as well). The Army's Cloud Strategy is to build on cArmy for Iaas and Paas systems (which is behind the DMZ) or to access securely through the cArmy for SaaS systems. If we go with custom code, it is an IaaS or PaaS solution and goes on cArmy and it is an architectural issue that must be built into the system at design time. If we go with an ERP, then the ERP itself is behind the vendor DMZ and the access via the NIPRNet and through secure connections through cArmy puts it behind a DMZ. We can cover this requirement, 44, and 51 with a single requirement that dicsusses complying with the Army's cloud strategy, ICAM, DoDI's, STIGs, NIST 800 guidance, and Information Assurance requirements that allow the system to get a provisional ATO and cATO.

My other concern is that as we move to cArmy (the cloud and/or cloud based software service providers), the term DMZ becomes more outdated as infrastructures evolve.

I think one giant (or a few less giant) robust requirements that don't tie us to physical solutions and exact specifications is preferable to the alternative. If we call out every spec required by name and miss one, is the vendor responsible to adhere to it? The answer is no. The reasonable person would assume that if we went to the trouble to call out a specific series of specifications by number, then we did our due diligence and those are the only ones they need to address. One could argue that we could call out all the specs we can find and then add an umbrella "and all other appropriate security specifications" to protect ourselves in case we missed a few, but if we are willing to do that, why don't we just do that and save a lot of fretting for everyone.

This assessment is based in part on my discussion with the cyber folks, my prior conclusions from research, and my review of a few other DA (AIE and ArmyIgnightED) requirements.

If this is not acceptable, then we can rewrite this as follows: The system shall provide the ability for users on the NIPRNet and DoD financial, logistical, analytical, and reporting interfaces to connect and communicate securely.

42 Foundational Cyber The system shall provide the ability to satisfy Connection Approval Procedures (CAP) prior to connection to the Defense Information System Network (DISN). In reviewing the DISN Connection Process Guide, there are a lot of steps to be taken.

- Most of these tasks fall to the DoD Sponsor and/or the DoD Partner.

Who is the Sponsor and who is the Partner?

- There are A&A and C&A tasks. Who performs those?

- The most current version of the DISN CPG is SEPT 2016 (Version 5.1). Is this the most current version? If not, what is and can you provide a link? Y This one is okay. It could possible be wordsmithed, but I think it is fine as written and consistent with our other requirments

43 Foundational Cyber The system shall provide the ability for products or technology whose primary purpose is to provide security services (e.g., firewalls, encryptors, intrusion detection devices) to comply with Common Criteria Certification (CCC) which produces an Evaluation Assurance Level (EAL) that represents a level of confidence in the security functions. In reviewing the CISA web page, I can find the CCC documents in the Archive section with the disclaimer that it may no longer be valid and most references and blogs I find on the CCC are dated on or before 2017. Can you please:

- Confirm CCC as written in this requirement is still valid as a stand alone compliance check?

- If so, can you please provide a link to the most current version of the CCC used by the DoD?

- If not, can you please identify which DODD, DODG, or DODI supersedes the CCC? Y This one should go away. It is too specific and really defines the cArmy secure infrastructure. I think that this requirement should be included in an umbrella requirement that references applicable STIGS, DoDIs, NIST 800 series, and can achieve an ATO.

I am not even certain it makes sense as written.

- Does the Army have an enterpise antivirus solution? If so, is it available to new systems and what is the name of the service/software?

- Does this guidance apply to contractors brought on board to develop an application and maintain it?

- If so, would it be more appropriate to reword this so it is not system centric but instead is reworded to describe the team that is provided by the vendor must meet 8570.01-M certifications? Y I really think this one can go away and get covered by an umbrella requirement that states the system will be compliant with DoDI, STIGS, NIST, … and achieve an ATO.

Unless the development team and the sustainment/support team are considered part of the system, this does not apply. This DoDD states that humans have to be certified/trained for the role they are taking.

Send Wes Link of most current version 49 Foundational Cyber The system shall be compliant with FIPS PUB 140-2 (Cryptographic). Research indicates that FIPS 140-2 was superseded by 140-3.

- Can you confirm that 140-3 is what we should be referencing?

- This document seems to describe the standards for developing cryptographic libraries and modules. Is it safe to assume that DA and DoD have an approved standard and libraries that conform to FIPS 140-3 and that this requirement should actually reference those libraries or make a statement that the system shall use DoD approved Cryptographic libraries that are compliant with FIPS 140-3?

- If there are libraries that are DoD approved and authorized for use, can you provide us the names?

- Assuming the government goes with a low code/no code solution that exists on a standard platform, is there a standard certifaction a vendor can provide to prove it is FIPS 140-3 compliant? Y I really think this one can go away and get covered by an umbrella requirement that states the system will be compliant with DoDI, STIGS, NIST, … and achieve an ATO.

Unless the development team and the sustainment/support team are considered part of th 50 Foundational Cyber The system shall be compliant with DoDI 8510.01 (RMF). This Instruction discusses the policies, procedures, framework to be implemented to support Risk management. It is not guidance or instructions on how to architect, design, or develop a system (those are covered in many other documents).

- can you confirm this is not an applicaiton design document?

- Can you confirm this is correct and that we should not be mentioning DIACAP?

- If it has been replaced, is there a DoDD, DoDG, DoDI that documents the transition and provide guidance on implementing the RMF and what the requirements are?

- Since it references "Information Assurance" and the DoD has shifted to "Cybersecurity" in its language is it safe to assume this document has been superseded by some other CSCSM? If so, can you please provide the name and link?

- If we are compliant with DoDI 8500.01 and CJCSM should be compliant and consistent with the DoDI, is it necessary to cite the CJCSM if we are compliant with the DoDI? Or is vice versa correct (if I reference the CJCSM I don't need to reference the DoDI?

- Can you confirm that DoDD 8500.01E is in fact the same thing that we are referencing as DODD 8500.1?

- Are we correct in assuming 8500.02 is the correct reference to what we have been calling DoDI 8500.2?

- If so, does this mean that DoDI 8500.02/8500.2 have been recended and this requirement is no longer valid?

- Can you confirm the version referenced above is the most current version and the name is now "Support to DoD Information Network Operations"

- Can you confirm this is the correct and most current guidance?

- Given it has been at least 15 years since these documents have been released is it safe to assume they have been superseded by some other guidance and this requirement should be dropped?

- If these documents have been superceded, is it by DoDI 8320.02? If not, which document(s) supersede them?

- Can you confirm DoDI 8330.01 is the correct references for interoperability?

- Is the DoD Cloud Computing Security Requirements Guide the DoD implementation of NIST 800-145? If so, is there a version of this document that is more current than 2017? If not, what is the DoD guidance for this document?

- Is there a DA document that supports NIST 800-145 and the DoD Guidance? If so, what is it?

- Is that interpretation correct and we could safely drop 167 or are these two different standards?

Requirement Master List Changes Change log for the following files:

Attach006-FMS-ACES RFI - Requirements Master List_v2 Attach003-FMS-ACES RFI - Requirements Feedback Template_v2