ATT0010 REVISED 2.5 item f USAISEC CyberSecurity Assessment and CE Eng Manual V2.1.1.pdf

FOR OFFICIAL USE ONLY

CYBERSECURITY ASSESSMENT

AND CYBERSECURITY ENGINEERING MANUAL

DECEMBER 2019

MISSION ENGINEERING DIRECTORATE

Distribution C Distribution authorized to U.S. Government agencies and their Contractors only, for administrative or operational use, February 2019. Refer other requests for this document to Commander, U.S. Army Information Systems Engineering Command, ATTN: ELIE-ISE-ME, Fort Huachuca, AZ 85613-5300

CYBERSECURITY ASSESSMENT AND SECURITY ENGNEERING MANUAL, February 2019 ii U.S. Army Information Systems Engineering Command ●

2133 Cushing Street ● Fort Huachuca, AZ 85613-5300

DISCLAIMER

The use of trade names in this document does not constitute an official endorsement or approval of the use of such commercial hardware or software. Do not cite this document for advertisement.

CHANGES

Refer requests for all changes that affect this document to: USAISEC, ATTN: ELIE-ISE-ME, Fort Huachuca, AZ 85613-5300.

DISPOSITION INSTRUCTIONS

Destroy this document when no longer needed. Do not return it to the organization. Safeguard and destroy this document with consideration given to its classification or distribution statement requirements.

iii

DECEMBER 2019

MISSION ENGINEERING DIRECTORATE

U.S. ARMY INFORMATION SYSTEMS ENGINEERING COMMAND

Distribution C Distribution authorized to U.S. Government agencies and their contractors only, for administrative or operational use, February 2019. Refer other requests for this document to Commander, U.S. Army Information Systems Engineering Command, ATTN: ELIE-ISE-ME, Fort Huachuca, AZ 85613-5300 iv

Table 1. Approvals

Document Approval(s) Project/Organization Role Mr. Steven J. Fulbright Director - Mission Engineering Directorate

Mrs. Deborah D. Harvey Security Control Assessor - Validator

Table 2. Document Owner(s)

Document Owner(s) Project/Organization Role

Cybersecurity Assessment Subject Matter Expert

Table 3. Version Control and Change Log Version Date Author Change Description

1.0 02 Dec 2013 South, L. Initial publication date

2.0 30 Aug 2016 Hills, K. RMF revision publication date

2.1 07 Feb 2019 Harvey, D. Addition of required certifications

2.1.1. 11 Dec 2019 Schreurs, R. Updated references and links. Minor edits.

v

TABLE OF CONTENTS

Page

1.0 INTRODUCTION

2.0 HOW THIS MANUAL IS ORGANIZED

3.0 HOW TO USE THIS MANUAL

4.0 HOW THIS MANUAL IS UPDATED

5.0 MISSION

6.0 CS

6.1 CS is a Process, not a Discrete Event

7.0 TERMS AND ACRONYMS

8.0 REFERENCES

9.0 SCOPING, PROJECT INITIATION, AND FUNCTIONAL SUPPORT

AGREEMENT (FSA) DEVELOPMENT

10.0 CS SERVICES

10.1 Matrix Support

10.2 Initial Scoping

10.3 Security Assessment (SA)

10.4 Preliminary Assessment

10.5 Assessment

11.0 PROCESSES

11.1 Cybersecurity Engineering (CE) Process

11.2 Assessment Process

12.0 TRAINING and Certification

12.1 IA Training Facility (ITF)

12.2 Sustainment Training

12.3 Certification

13.0 DATA COLLECTION, ANALYSIS, AND RETENTION

13.1 Data Collection

13.2 Protecting Raw Data

13.3 Collecting and Validating Technical Data

13.4 Sampling

13.5 Data Analysis

13.6 Data Retention

14.0 TOOLS

14.1 ISEL – Pronounced “I-SELL”

14.2 ISEL WIKI

vi

Appendices

Page APPENDIX A. REFERENCES ............................................................................. A-1 APPENDIX B. SUPPORTING FILES (FILE STRUCTURE) ................................. B-1 APPENDIX C. PROCESSES ............................................................................... C-1 GLOSSARY. ACRONYMS AND ABBREVIATIONS .................................. Glossary-1

Tables Table 1. Approvals .................................................................................................. iv Table 2. Document Owner(s) .................................................................................. iv Table 3. Version Control and Change Log .............................................................. iv Table 4. Sampling Example

1.0 INTRODUCTION

This manual covers the activities performed during Cybersecurity (CS) Assessment and/or Cybersecurity Engineering (CE) missions. CS professionals assigned to the U.S.

Army Information Systems Engineering Command (USAISEC) Mission Engineering Directorate (MED) perform these missions.

This manual refers to Directorate personnel and includes: 1) all Directorate U.S.

Government (USG) civilians, 2) Government Contractors supporting MED, and 3) any other designated representatives conducting or participating in Assessment and/or Security Engineering support.

Processes and procedures are to be followed by all personnel when supporting Assessment and/or CE missions. Any deviation from the processes and procedures listed herein must be pre-approved by the Director, Group Leader (GL) or Senior Project Lead (SPL).

While no one party may participate in all processes or procedures, it is vital that the reader understand the complete methodology.

Contractors supporting MED will adhere to all identified Contract Data Requirements Lists (CDRLs), in addition to the guidance provided in this manual.

This manual does not include those aspects of CS Assessment and CE that are not directly tied to completing the mission itself, such as budgeting, funds management, personnel matters, etc.

2.0 HOW THIS MANUAL IS ORGANIZED

This manual contains 14 sections and four appendices. It will guide the reader through the governing framework that MED abides by and adheres to in the course of performing CS Assessment and CE missions.

3.0 HOW TO USE THIS MANUAL

Throughout this manual, there are footnotes and other references that will identify additional documents, checklists, forms, Worldwide Web (WWW) addresses, policies and procedures, and should be used to enhance the understanding the reader can gain from this manual to successfully complete MED’s mission.

This manual is distributed with a supporting file structure that contains other documents, templates, Standard Operating Procedures (SOPs), checklists, forms, etc. Please see Appendix B for details.

When a footnote or reference refers to a document, it will depict the structure shown on MED’s SharePoint portal. However, all documents are also contained within the Data Collection and Archive Folder Structure (DCAFS) under “References and Tools,” as well as part of the Information Assurance (IA) Security Evaluation Laptop (ISEL) Wiki.

4.0 HOW THIS MANUAL IS UPDATED

To ensure that all Directorate personnel have the most up-to-date and most efficient methods, this manual will be updated as needs arise. This manual is posted on MED’s SharePoint portal1 and distributed as part of the DCAFS2.

It is the responsibility of all Directorate personnel to ensure they are operating under the guidance of the most recent revision of this manual. Changes, additions, or modifications will be identified in the Version Control and Change Log3.

Directorate personnel can propose changes to any process or procedure (operational or technical) referenced in this manual or any other manual, process document, or guide.

To propose any change, please process those requests through the appropriate chain of command. Directorate leadership supports all input concerning operational efficiency, technical accuracy, and product improvements.

5.0 MISSION

The mission of MED is to provide the U.S. Army with a full-service CS Assessment and CE support capability to ensure that Army Information Systems (ISs), networks, and infrastructures are properly secured, assessed, and authorized to meet the Army’s sustaining base and force protection CS needs. MED is the Army’s premier CS Assessment and CE service provider.

6.0 CS

6.1 CS is a Process, not a Discrete Event

At the project development level, the CS Process has two components:

● CE Process: That sub-discipline of Systems Engineering (SE) responsible for the identification and integration of security requirements and satisfaction of those requirements, in an interdisciplinary manner throughout the life cycle of an

IS

● Assess and Authorize Process: The Validation and Verification (V&V) of CS requirements, the resultant risks identification to the system and the enterprise, and the acceptance or rejection of that risk

Both processes must address system development, system fielding, system operation, security sustainment, and End of Life (EOL) cycle security needs.

1 https://cecom.aep.army.mil/cecom/ISEC/MED 2 See Section 14.2 of this manual 3 Table 3, Page iv

FOR OFFICIAL USE ONLY

7.0 TERMS AND ACRONYMS

The title of the individual managing the systems that MED evaluates can be Program Manager (PM), System Owner, Commander, Director, etc. To aid readability, this manual will refer to this individual as the Customer.

Directorate support can consist of a site, enclave, network, system, application, or all of the above. As indicated above, the term Customer will identify whom, this manual will use the term System to identify what. See Glossary for common acronyms.

8.0 REFERENCES

CS references are listed in Appendix A.

9.0 SCOPING, PROJECT INITIATION, AND FUNCTIONAL SUPPORT AGREEMENT

(FSA) DEVELOPMENT

MED has several project initiation processes:

● Security Control Assessor (SCA)-Validator (SCA-V) efforts for the SCA-Army

(SCA-A)

● CS efforts for other organizations (e.g., Medical Command (MEDCOM))

● CE and other CS support efforts

SCA-V assessments in support of the SCA-A are initiated in and/or routed through the Army Enterprise Mission Assurance Support Service (eMASS4), which is under the control of the CS Directorate (CSD), U.S. Army Network Enterprise Technology Command (NETCOM). Because all SCA-V work is processed through eMASS and under the auspices of the SCA-A, all SCA-V work must follow a predefined business process controlled by the CSD, NETCOM. This process is conducted outside of, and in addition to, the standard Command’s guidance as outlined in the NETCOM-provided Tactics, Techniques, and Procedures (TTP) documentation, which can be found on the NETCOM RMF Knowledge Service5.

Efforts in support of other component Assessment Authorities and efforts, where MED is acting as the SCA, adhere to the process defined by the SCA of that component. The Directorate GLs or SPLs are the initial Points of Contact (POCs).

Directorate personnel or Project Leads (PLs) route all Security Engineering and other CS support requests for service from new Customers to one of the GLs or SPLs. At the direction of a GL, the SPL manages Security Engineering and other CS support requests from existing Customers.

4 https://emass-army.csd.disa.mil Email Certificate Required for Authentication 5 https://army.deps.mil/NETCOM/sites/RMF/SitePages/TTPs.aspx (10 Attachments) https://rmfks.osd.mil/rmf/Pages/default.aspx https://rmfks.osd.mil/rmf/Pages/default.aspx

MED’s process for Project Initiation and FSA development for non-SCA-V efforts adheres to the Command’s guidance. For SCA-V efforts, the FSA creation process will adhere to Command templates and standards to include a modified timeline from the timeline identified within the NETCOM TTPs.

10.0 CS SERVICES

This section identifies the services provided to MED’s Customers and the final deliverable of each service. All final deliverables (both USG and contract) must be completed in eMASS and reviewed by the designated Authorizing Official (AO). The designated AO digitally signs all final memorandums and deliverables going to an outside organization.

All draft memorandums and deliverables sent to an outside organization will be clearly marked “DRAFT.”

10.1 Matrix Support

MED provides CS support to other Command Directorates, where MED is acting as an extension of another Command Directorate. MED will usually not have an FSA, but rather the services provided by MED will be requirements-based. MED can provide any of the services listed herein or additional CS services, as required, by the project and requested by the owning Directorate.

10.2 Initial Scoping

In some cases, the full scope of a mission cannot be determined without a visit to the location where the environment exists. An Initial Assessment is performed to evaluate the system or environment, determine the scope of work, and roughly assess the security posture of the system. This is usually a short, 2- or 3-day visit where assessment of personnel, processes, documentation, facility, and technical settings occur to fully evaluate the complexity of the mission. The final level of work and costs can then be negotiated with the Customer.

Because the purpose of this type of effort is to complete scoping of the project, the Assessment Report should provide as much detail as possible about the system’s mission, architecture/data flows, scope, environment, processes, and systematic problems likely to impact authorization or the security of the system. Presumably, the Customer will accept the final FSA estimate and an Assessment Report will be provided based on the agreed-upon timeline.

10.3 Security Assessment (SA)

An SA is a focused assessment of a specific component or system. During the assessment, Directorate personnel will collect technical and non-technical data associated with the focus area. The purpose of the assessment is to identify areas that are not in compliance with regulations and/or configuration guidance in order to address the overall security posture of the focus area. Additionally, as required by the Customer, a “get-well” plan should be included as part of the recommendation. If the assessment is to verify implementation of a type of accreditation, the report should address if the system was installed In Accordance With (IAW) the authorization decision (e.g., RMF Authority To Operate (ATO)).

FOR OFFICIAL USE ONLY

The deliverable to the Customer is a Security Assessment Report (SAR) signed by the GL. The Risk Assessment section must be completed within eMASS. A SAR can be generated from eMASS after the completion of the Risk Assessment section.6

10.4 Preliminary Assessment

A Preliminary Assessment could be a full or partial assessment of the Customer’s system or environment. Directorate personnel will assess the security posture of the system using the same techniques and practices that are used in an official RMF Assessment.

The CSD will be releasing specific information regarding how to conduct a Preliminary Assessment to ensure continuity amongst all SCA-Vs; however, it is not available at the time of this manual’s release.

The deliverable to the customer is a Compliance Report Spreadsheet and a Preliminary Assessment Memorandum signed by the SPL or GL. The Preliminary Assessment Memorandum template is available on MED’s SharePoint portal7.

10.5 Assessment

An Assessment is a Test and Evaluation (T&E). These are the test events required before the system’s operational status is determined. During an assessment, Directorate personnel evaluate the system for overall Security Control compliance in support of the SCA-V. Even though the customer pays for the assessment, the Assessment Team is working for the SCA-A. The T&E is an in-depth assessment that addresses all RMF control families, including all applicable overlays for the system being evaluated. The SCA-V is charged with determining the overall security posture of the system by validating compliance with Department of Defense (DoD) Instruction (DoDI) 8510.01, DoDI 8500.01, National Institute of Standards and Technology (NIST) Special Publication (SP) 800-53, Committee on National Security Systems Instruction (CNSSI) 1253, and any other requirements for assessment. The SCA-V Team is required to follow all NETCOM SCA TTPs and Fragmentary Orders (FRAGOs). NETCOM SCA TTPs can be found on the NETCOM RMF site and FRAGOs can be found on the RMF KS8.

The deliverable to the SCA-A (NETCOM CSD) is an SCA-V Recommendation Memorandum, signed by the SCA-V. If applicable, this memorandum includes an enclosure for conflicting inherited controls. The Recommendation Memorandum is uploaded by the SCA-V to the “Artifacts” section of eMASS. Templates for the SCA-V Recommendation Memorandum and Enclosure are available on MED’s SharePoint portal9.

6 https://army.emass.apps.mil Cybersecurity Manuals & Supporting Docs \ 03_Memo_Templates \ Preliminary _Assessment _Memo

_Template (Attached) 8 https://army.deps.mil/NETCOM/sites/RMF (3 attachments) https://rmfks.osd.mil RMF Knowledge Service > Collaboration > Component Workspaces > US Army Component Workspace > US Army Component Workspace - Operations 9 Cybersecurity Manuals & Supporting Docs \03_Memo_Templates\ (2 Attachments) https://army.deps.mil/NETCOM/sites/RMF https://rmfks.osd.mil/rmf/Pages/default.aspx https://rmfks.osd.mil/rmf/collaboration/Pages/default.aspx https://rmfks.osd.mil/rmf/collaboration/Component%20Workspaces/Pages/default.aspx https://rmfks.osd.mil/rmf/collaboration/Component%20Workspaces/USArmyCW/Pages/default.aspx https://rmfks.osd.mil/rmf/collaboration/Component%20Workspaces/USArmyCW/Pages/default.aspx https://rmfks.osd.mil/rmf/collaboration/Component%20Workspaces/USArmyCW/Pages/default.aspx https://rmfks.osd.mil/rmf/collaboration/Component%20Workspaces/USArmyCW/USArmyOperations/Pages/default.aspx

The SCA-V also creates a SAR from eMASS and uploads a copy into the “Artifacts:

section of eMASS, once all controls have been processed and the Recommendation Memorandum has been signed.

11.0 PROCESSES

11.1 CE Process

CE is a sub-discipline of CS responsible for the identification and integration of security requirements and satisfaction of those requirements in an interdisciplinary manner, throughout the life cycle of an IS. This includes the technical, procedural, and documentation work that is required to prepare a system for assessment under RMF. CE is intended to ensure that systems of any size or complexity meet all applicable CS requirements and are designed, implemented, and maintained in a manner that complies with all DoD, Army, and other applicable policies. The ultimate goal is a secure, sustainable, assessed, and authorized system that protects itself from external threats, and protects the DoD Information Network (DoDIN) from any internal or external threats.

See Appendix C for more information on the CE Process.

11.2 Assessment Process

An Assessment is the comprehensive evaluation of the technical and non-technical security features of a system and other safeguards made in support of the authorization process, to establish the extent to which a particular design and implementation meets a set of specified security requirements. An Assessment primarily addresses software, hardware, firmware, and data security measures. It must also consider procedural, physical, personnel, threat, and emissions security.

The MED SCA-V is one of the Army’s CSD, NETCOM-appointed SCA-Vs under the Army’s single SCA model. As an SCA-V, MED acts as an objective third party and independent validator. MED provides a complete and detailed analysis of the level of compliance with DoD and other requirements, and the risk associated with operating the system. With this analysis from the SCA-V, the SCA-A is able to make an informed decision to determine a systems operational status. This analysis also assists the AO in determining whether or not to accept the risk associated with any findings in the analysis.

The Assessment Team must follow all guidance as published in the various TTPs (especially the SCA-V TTP) and FRAGOs approved by the NETCOM CSD. These documents are continually updated. FRAGOs can be downloaded from the RMF KS and NETCOM RMF TTPs from the NETCOM RMF site.10 See Appendix C for more information on the Assessment Process.

Approval to deviate from any documented process can be obtained through discussions with the SPL, the GL, or the SCA-V Lead.

https://army.deps.mil/NETCOM/sites/RMF https://rmfks.osd.mil/rmf/collaboration/Component%20Workspaces/USArmyCW/USArmyOperations/RM F%20Operations%20Document%20Library/TTPs https://army.deps.mil/NETCOM/sites/RMF

12.0 TRAINING AND CERTIFICATION

12.1 IA Training Facility (ITF)

MED maintains a training facility and lab environment for use by all Directorate personnel.

The ITF personnel maintain the ISEL according to Directorate processes and procedures.

The ITF maintains test environments where the tools used by MED can be tested prior to use in a Customer’s environment, and where training can occur.

12.2 Sustainment Training

MED provides sustainment training based on the training needs of Directorate personnel.

Training subject areas, schedules, and audience will be at the direction of Directorate leadership. Senior Directorate personnel may be called on to provide subject area training, as required. The Subject Matter Expert (SME) staff will oversee sustainment training, as well as provided training.

12.3 Certification

IAW DoD Directive (DoDD) 8140.01 and DoDI 8570.01-M, all cyberspace workforce personnel must become compliant with the mandated Information Technology (IT) and Security certification standards within a certain time frame.

All PLs and SPLs will be appointed as IA System Architects, and Engineers Level 2 (IASAE II), and will maintain their certification for that standard.

Any Team Leads or Team Members will be appointed as IA Technical Level 2 (IAT II) and will maintain their certification for that standard.

Any Interns that are assigned to USAISEC MED and are not part of the cyberspace workforce, for example, Pathway Interns are categorized as “General” and do not have to obtain any certification standard.

Contractors will adhere to the Personnel Requirements of the Contract Task Order’s Performance Work Statement. This will, at a minimum, be IAW DoD Directive (DoDD)

8140.01 and DoDI 8570.01-M.

13.0 DATA COLLECTION, ANALYSIS, AND RETENTION

13.1 Data Collection

MED collects data to scope the project, to understand the system being evaluated, to determine compliance with security controls, and to understand any mitigating and/or aggravating factors. The data collected can be in the form of system documentation, interview questions and answers, vulnerability scan data, notes based on observations, and evidence of compliance/non-compliance. All data collected is maintained and archived using the DCAFS, see Section 13.6 of this manual.

13.2 Protecting Raw Data

The data and documentation collected during an assessment carries the identified classification of the assessed system and MED has a responsibility to protect this information accordingly. Prior to collecting and/or storing data or documentation, ensure that the Classification Guide applicable to the system or environment is obtained and reviewed. Ensure proper protection mechanisms are in place and all applicable procedures, regulations, and/or policies are followed concerning the classification of the data collected.

13.3 Collecting and Validating Technical Data

While onsite, MED personnel will verify all Security Technical Implementation Guide (STIG) requirements. The minimum acceptable performance when evaluating STIG requirements is to validate all open findings, as well as all non-reviewed checks.

Directorate personnel must consider which STIGs apply to the system and how to validate those STIG requirements. Directorate personnel collect technical raw data as validation evidence, which is later analyzed to determine compliance and security posture. MED has various tools at its disposal to facilitate both manual and automated data collection and validation. While the tools available cover many of the technical requirements, no single tool covers all of them; therefore, Directorate personnel should ensure they use any available mechanisms to collect and validate data. Additionally, the operational environment of a device must be considered and evaluated to ensure there are no operational deficiencies that aggravate a potential vulnerability, due to technical configuration. The bottom line is the validator is responsible for ensuring all appropriate and applicable STIGS and manual checks must be performed. If the evaluation is a one-off type of equipment and there is no DoD regulation or guide, due diligence requires evaluating compliance with any vendor-published or industry standard guidelines.

Checklists must be created from each STIG using Security Content Automation Profile (SCAP) Compliance Checker (SCC) and saved as Continuous Monitoring and Risk Scoring (CMRS) Extensible Markup Language (XML) file format and uploaded into “Asset Manager” within eMASS. In addition, Assured Compliance Assessment Solution (ACAS) scan reports are created as pairs, Advanced Recording File (ARF) and Action Script Remote (ASR) format, and must be uploaded to “Asset Manager” as well.

13.4 Sampling

When collecting data from large systems, it would be virtually impossible to test every device in the time allocated for the CE or Assessment effort. Compliance with technical Security controls can be determined by sampling a number of “like” devices. Directorate personnel use a standard sampling rate to assess compliance. To qualify as “like” devices, the equipment must be of the same baseline, perform the same function, exist in the same operational environment, and be administered by the same personnel. For example, the Human Resources Department is using Dell laptops, which are administered by the Human Resources Workstation Team. These devices are “like” devices. All Exchange servers running on a Windows Server with the same baseline, administered by the Network Enterprise Center (NEC) Exchange Team are “like” machines. Use extreme caution when attempting to sample network devices. It is important they are also at the same layer in the architecture and perform the same security functions. A perimeter router is not the same as an End User Building (EUB) router, even if the Operating System (OS) and administrators are the same.

FOR OFFICIAL USE ONLY

Table 4. Sampling Example Like Systems Sample Rate Like Systems Sample Rate

1-3 Test All 4-25 Test 3 26-50 Test 5 51-90 Test 6 91-150 Test 7 151-280 Test 10 281-500 Test 11 501-1200 Test 15 1201-3200 Test 18 3201-10000 Test 22

13.5 Data Analysis

All scan data must be analyzed. Scan data may be analyzed using Vulnerator, a spreadsheet, or any other capability as long the team can show that analysis was performed. This analysis documentation must be uploaded to the “Artifacts” section of eMASS using the required nomenclature “SCA-V_[SysAcr]_[Doctype].[xyz]”(include a dash “-“ in system name if there are spaces. For example, “System-01”). This nomenclature must be used for all artifacts uploaded to eMASS by the SCA-V Team. For a complete list of approved nomenclature for artifacts, please reference the SCA-V TTP.

The Risk Assessment Workbook, found on MED’s SharePoint11 site must also be completed and uploaded to the “Artifacts” section of eMASS. The Risk Calculator must be completed and used to identify the highest watermark of likelihood and impact within the non-compliant controls for the system’s overall risk (placed in the risk matrix portion of the recommendation memorandum), as well as the values for Vulnerability Severity Value and Control Risk Value in eMASS under the “Risk Assessment Summary” tab.

All scans completed by the Assessment Team must be zipped and uploaded to the Artifacts section of eMASS. All test results for each applicable Common Communication Interface (CCI) must be completed within eMASS by the Assessor starting from the beginning of the assessment period to completion.

13.6 Data Retention

Data collected and analyzed during a mission becomes part of MED archives. The central repository is a combination of SharePoint and a Storage Area Network (SAN), in which a copy of all mission data is archived. MED does not maintain data past 3 years plus 3 months. The reasoning for MED’s retention period is that RMF ATO decisions do not exceed 3 years. MED allows for an additional 3 months beyond the 3-year ATO.

11Cybersecurity Manuals & Supporting Docs \00_Policy-Process-SOP-TTP\Risk Assessment Workbook\RAW (2 Attachments)

14.0 TOOLS

MED has many tools available for various aspects of its services. MED developed some of these tools specifically for its functions and others are Commercial-Off-The-Shelf (COTS). See the ISEL Accreditation Package for a complete listing of tools and software available. The sections below identify MED’s three primary tools.

14.1 ISEL – Pronounced “I-SELL”

The ISEL is a Road Warrior system as defined in the Road Warrior Best Business Practice (BBP)12. The ISEL image is configured from a master image maintained by the ITF.

Directorate personnel use the ISEL to scan Customer environments for configuration and vulnerabilities, and to collect and maintain all data collected during the course of an assessment; it does not connect to any other network outside the scope of the Customer’s system boundary, in which Directorate personnel have been engaged to operate.

Directorate personnel may do some administrative work using the ISEL, such as writing control notes or analyzing data. Upon return to home station, the collected data from the Customer’s system and other documents developed during the deployment are transferred from the ISEL to archive media using the DCAFS, and the ISEL is turned in to the ITF personnel for re-imaging with the most current image.

Note that if the ISEL becomes Classified during the deployment, it will be wiped securely IAW current DoD and U.S. Army policies before it may be re-imaged and re-issued. The data recovered will be handled and stored IAW Army Regulation (AR) 380-5; the relevant Security Classification Guide; and other DoD and Department of the Army (DA) guidance, as applicable. See MED’s SharePoint portal for more details on the ISEL.13

DCAFS is designed for “cradle to grave” use throughout an effort. Using the file structure from the beginning of the effort will support the organization of data efficiently and in the structure needed for the final archive. Many references or tools needed during system familiarization, the onsite effort, or post deployment analysis are readily available within the “99_References_and_Tools” folder.

DCAFS is jointly maintained by MED’s CS Assessment, CE, and Application SMEs.

Additional information on DCAFS is available on MED’s SharePoint portal14.

14.2 ISEL WIKI

The wiki is located on MED’s ISEL image, and includes all data previously stored in the “References and Tools” folder of DCAFS. This includes all information regarding use and training of various tools used by Directorate personnel during a CE effort or an Assessment.

12 Army BBP 06-EC-O-0007, Road Warrior Laptop Security 13 https://cecom.aep.army.mil/cecom/ISEC/MED/Lists/iselrllup/AllItems.aspx (attached) 14 https://cecom.aep.army.mil/cecom/ISEC/MED/Lists/dcafsrllup/AllItems.aspx (attached) https://cecom.aep.army.mil/cecom/ISEC/MED/Lists/iselrllup/AllItems.aspx

Directorate personnel are expected to access the wiki for guidelines to appropriately configure and use all tools necessary.

DCAFS is maintained by MED’s Application SME. The wiki is updated on an as-needed basis. Updates to the wiki coincide with updates to tools and applications used by MED, as well as when new training on tools becomes available.

This page intentionally left blank.

A-1

APPENDIX A. REFERENCES

A-1.0 USG REFERENCES

a. DoD, DoDD 8500.01, Cybersecurity, March 2014.

b. DoD, DoDI 8510.01, Risk Management Framework (RMF) for DoD Information Technology (IT), May 2016.

c. Headquarters, Department of the Army (HQDA), AR 25-1, Army Knowledge Management and Information Technology, December 2008.

d. HQDA, AR 25-2, Information Assurance, October 2007.

e. HQDA, AR 25-50, Preparing and Managing Correspondence, 17 May 2013.

f. HQDA, AR 380-5, Information Security Program, 29 September 2000.

A-2.0 NON-USG REFERENCES

a. Defense Acquisition University (DAU), BBP 06-DC-M, Army Best Business Practice - Assessment & Accreditation, November 2006.

b. DAU, BBP 06-DC-M-004, Army Best Business Practice - Assessment Authority, November 2006.

c. DAU, BBP DC-M-006, Army Best Business Practice - Agent of the Assessment Authority (ACA), November 2006.

d. NIST, SP 800-30, Guide for Conducting Risk Assessments, September 2012.

e. NIST, SP 800-37, Guide for Applying the Risk Management Framework to Federal Information Systems, 10 June 2014.

f. NIST, SP 800-53, Security and Privacy Controls for Federal Information Systems and Organizations, 22 January 2015.

g. NIST, SP 800-53A, Assessing Security and Privacy Controls in Federal Information Systems and Organizations, 18 December 2014.

http://csrc.nist.gov/publications/nistpubs/800-37-rev1/sp800-37-rev1-final.pdf

A-2

B-1

APPENDIX B. SUPPORTING FILES (FILE STRUCTURE)

B-1.0 MED maintains supporting documents in the folder structure that accompanies this manual. Below is an overview of what is contained in each folder. The contents of the supporting file structure will change on a regular basis; therefore, the current copy should be reviewed prior to initiating work on behalf of MED.

B-1.1 00_Policy-Process-SOP-TTP. This folder contains documentation that pertains to processes, SOPs, TTPs, and policy. Examples of the types of documents contained here are:

● NETCOM TTPs

● Risk Assessment Workbook

B-1.2 01_Briefing_Templates. This folder contains templates to be used for creating briefs.

Examples of the types of templates contained here are:

● In Brief Template

● Out Brief Template

B-1.3 02_Checklists. This folder contains checklists will aid in ensuring Directorate policies and procedures are followed. Examples of the types of checklists contained here are:

● Deliverable Staffing Checklist

● Pre-Deployment Checklist

● Post-Deployment Checklist

● Test Readiness Review (TRR) Checklist

● Self-Assessment Validation Review (SAVR) Checklist

B-1.4 03_Memo_Templates. This folder contains templates to be used when creating Memorandums and Enclosures that are addressed to an outside entity or agency. These templates have been created IAW AR 25-50.

B-1.5 04_Other_Templates. This folder contains the RMF SCA Test Plan and evaluation forms that are provided to MED’s Customers so they can provide feedback to Directorate management.

B-2

This page intentionally left blank

C-1

APPENDIX C. PROCESSES

The CE Process was developed by the CE SME. For ease of use by Directorate personnel, this separate document is provided as part of this manual’s supporting file structure. The CE Process is maintained in the “Policy-Process-SOP-TTP” folder of MED’s SharePoint site.

The SCA-V Assessment and Authorization Process follows the NETCOM Assess and Authorize TTP. See https://army.deps.mil/NETCOM/sites/RMF/SitePages/Home.aspx

C-2

Glossary-1

GLOSSARY. ACRONYMS AND ABBREVIATIONS

ACA Agent of the Assessment Authority ACAS Assured Compliance Assessment Solution AO Authorizing Official AR Army Regulation ARF Advanced Recording File

ASR

ATO Authority To Operate

BBP Best Business Practice

CCI Common Communication Interface CDRL Contract Data Requirements List CE Cybersecurity Engineering CMRS Continuous Monitoring and Risk Scoring CNSSI Committee on National Security Systems Instruction COTS Commercial-Off-The-Shelf CS Cybersecurity CSD CS Directorate

DA Department of the Army DAU Defense Acquisition University DCAFS Data Collection and Archive Folder Structure DoD Department of Defense DoDD Department of Defense Directive DoDI Department of Defense Instruction DoDIN Department of Defense Information Network eMASS Enterprise Mission Assurance Support Service EOL End of Life EUB End User Building

FRAGO Fragmentary Order FSA Functional Support Agreement

GL Group Leader

HQDA Headquarters, Department of the Army

IA Information Assurance IASAE II IA System Architects and Engineers Level 2 IAT II IA Technical Level 2

Glossary-2

IAW In Accordance With IS Information System ISEL IA Security Evaluation Laptop IT Information Technology ITF IA Training Facility

KS Knowledge Service

MED Mission Engineering Directorate MEDCOM Medical Command

NEC Network Enterprise Center NETCOM U.S. Army Network Enterprise Technology Command NIST National Institute of Standards and Technology

OS Operating System

PL Project Lead PM Program Manager POC Point of Contact

RMF Risk Management Framework

SA Security Assessment SAN Storage Area Network SAR Security Assessment Report SAVR Self-Assessment Validation Review SCA Security Control Assessor SCA-A Security Control Assessor-Army SCA-V Security Control Assessor-Validator SCAP Security Content Automation Profile SCC SCAP Compliance Checker SE Systems Engineering SME Subject Matter Expert SOP Standard Operating Procedure SP Special Publication SPL Senior Project Lead STIG Security Technical Implementation Guide

T&E Test and Evaluation TRR Test Readiness Review TTP Tactics, Techniques, and Procedures

USAISEC U.S. Army Information Systems Engineering Command

Glossary-3

USG U.S. Government

V&V Validation and Verification

WWW Worldwide Web

XML Extensible Markup Language

Glossary-4

U.S. Army Information Systems Engineering Command

DCAFS Quick Reference Guide

- 1 -

DATA COLLECTION AND ARCHIVE

FILE STRUCTURE (DCAFS)

Quick Reference Guide

- 2 -

Table 1 - Document Approval(s)

Name Project/Organization Role

Mr. Kevin F. Lee Senior System Engineer-Technical / ACA

Table 2 – Document Owner(s)

Name Project/Organization Role

Mr. Leslie South IA Certification Subject Matter Expert

Table 3 – Version Control & Change Log

Version Date Author Change Description

1.0 29 Aug 2013 Mr. Leslie South Initial publication date

2.0 21 JUL 2014 Mr. Leslie South Formatting changes in all sections, added section 4 to address proper labeling of media, added section 5 to address renaming/renumbering of the DCAFS subfolders, added a PII statement in section 6, collapsed section 6 into paragraph form.

- 3 -

1. Delete any empty folder within DCAFS prior to archiving.

2. Delete the 99_References_and_Tools folder prior to archiving.

3. In each folder within DCAFS, there are “WHAT GOES HERE” PDF documents specific to each folder. Information in this document provides the same guidance that is in this guide. Delete these PDF documents prior to submitting the DCAFS media for archive.

4. All Unclassified//For Official Use Only DCAFS media will be marked and labeled as required and IAW Department of Defense Manual 5200.01, Army Regulation

(AR) 25-2, AR 25-55, AR 380-5 and all other current and relevant regulations and guidance for marking and labeling. At a minimum, all media will contain the following:

a. Name or Acronym of subject system or application

b. Disk creation date

c. Disk creator name & phone number

d. Appropriate handling/classification markings

5. Do not rename or renumber any of the sub-folders within DCAFS.

6. All folders in DCAFS are to be placed in a “root” or top-level folder that adheres to the following naming convention:

[SYSTEM_ACRONYM][(CLASSIFICATION)]-[SERVICE]- [MONTH_YEAR_OF_EFFORT (MMMYYYY)]

a. [SYSTEM_ACRONYM]

i. As defined in the SIP

ii. Example: AMPS - Aviation Mission Planning System

b. [(CLASSIFICATION)]

i. As defined by the DAA

ii. Example: (U) for a MAC I, II, or III Public or Sensitive system

iii. Example: (S) for a MAC I, II, or III Classified systems

c. [Service]

i. CA – Compliance Assessment

ii. CTE – Certification Test and Evaluation

iii. OTH – Other

iv. RA - Risk Assessment

v. SE - Security Engineering

vi. SIA - Security Impact Assessment

vii. STE – Security Test and Evaluation

d. [MONTH_YEAR_OF_EFFORT (MMMYYYY)]

i. Three letter month code & Four digit year

ii. Example: JUL2012 for July 2012

iii. Composite Example: The Aviation Mission Planning System, A MAC II classified system, underwent a Security Test and Evaluation in July

- 4 -

2012. The DCAFS root folder name would be: AMPS(S)-STE-JUL2012

7. DCAFS is divided into 6 sub-folders:

a. 00_Administration - This folder contains all of the “administrative” documents associated with an effort. Documents are added as they are created. DO NOT RETAIN ANY PII IN THIS OR ANY OTHER FOLDER. Documents in this folder might include:

i. ACA Validation Scoping Questionnaire

ii. Work Plan

iii. TRR Checklist

iv. Pre Deployment Checklist

v. In Brief

vi. Out Brief

vii. Post Deployment Checklist

viii. Deliverable Staffing Checklist

ix. Itinerary / Schedule

x. Mission Checklist

xi. VARs

xii. Other Discretionary Items (maps, local information, etc.)

b. 01_Documentation - This folder is used to maintain all documentation pertaining to the system regardless of the origin or system of record where the data came. Documentation can be collected from the customer or obtained from various tracking systems (C&A Tdb, eMASS, SharePoint, etc.). This folder serves as the location for maintaining the “record copy” of all received documentation. The documentation in this folder is never deleted or modified (to include highlighting, sorting, markups, etc). Documents are copied, not moved from this folder to the 03_Analysis sub-folder if they are modified or marked up during review.

c. 02_Collected_Data - This folder is used to maintain all data collected

(scan results, configuration files, etc.). Create folders as needed to identify what the data is and where the data came from. Data elements are copied, not moved as needed from this folder to the 03_Analysis folder to perform analysis, concatenation, etc.

d. 03_Analysis - This folder is used as a “working” folder during the validation process and contains all work products used or produced while analyzing data and/or documentation. Contents of this folder are not deleted when analysis is complete and will serve as an audit train of how findings were developed. Some of the items in this folder might include, but are not limited to:

i. Mark up copies of documentation

ii. IAVM Trend Analysis

iii. STIG ID Trend Analysis

iv. Nessus scan consolidation/analysis

v. Retina scan consolidation/analysis

vi. Scripts or batch files used to parse data

vii. Spreadsheet templates used to analyze data

- 5 -

e. 04_Deliverables - The sub-folders of 04_Deliverables provide a working location for development and final copies of the Deliverable Package.

They store the interim copies of the any application used to develop the

Deliverable Package (CACSE database, DIACAP Scorecard Generator, working copies from the C&A Tdb, etc.) and the final copies of all deliverables required. This folder contains five subfolders (see below) and as deliverables are developed, copies are stored in the sub-folder appropriate for that particular phase of the deliverable creation and staffing process. For Example, the draft copies of deliverable used for a DRR along with a copy of the application (i.e. CACSE Database) used to create that deliverable would be stored in the root of the 01_DRR folder. As deliverables move through the process, the latest version of the CACSE database for the current phase is copied – NOT MOVED - to the next folder in succession in order to maintain version control and historical copies. For example, the copy of the CACSE database used to produce the deliverables for the DRR would be copied to the 02_RAWG folder, and any changes required as a result of the DRR would be made to the copy of

CACSE in the 02_RAWG folder. Subfolders contained in this folder are:

i. 01_DRR

ii. 02_RAWG

iii. 03_Staffing

iv. 04_Customer

v. 05_CIP-G6

f. 99_References_and_Tools - This folder, and its subfolders, contains the latest reference documents and tools for use by Directorate Personnel. This folder is updated weekly by the Applications Security SME. An HTML index is provided at the root of this folder and can be accessed by double-clicking on the “99_References_and_Tools_Index.html” file.

8. Contact the Document Owner identified in Table 3 for any clarification and/or questions.

2014-09-05T11:57:29-0700

LEE.KEVIN.FRANK.1152267769

2014-07-21T13:11:33-0700

SOUTH.LESLIE.DALE.1388553495

ELIE-ISE-ME TTP No. 1-2017

INFORMATION SYSTEM EVALUATION LAPTOP (ISEL)

OPERATIONAL

TACTICS, TECHNIQUES, AND PROCEDURES

(TTP)

VERSION 2.0

Effective June 2017

U.S. Army Information Systems Engineering Command ● 2133 Cushing Street ● Fort Huachuca, AZ 85613-5300

DISCLAIMER

The contents of this document are not to be construed as an official Department of the Army position unless so designated by other authorized documents. The use of trade names in this document does not constitute an official endorsement or approval of the use of such commercial hardware or software.

Do not cite this document for the purpose of advertisement.

CHANGES

Refer requests for all changes that affect this document to:

Senior Systems Engineer – Technical, Mission Engineering Directorate, Fort Huachuca, AZ 85613-5300

DISPOSITION INSTRUCTIONS

Destroy this document when no longer needed. Do not return it to the organization. Safeguard and destroy this document with consideration given to its classification or distribution statement requirements.

This document is a Sensitive but UNCLASSIFIED document.

This document is FOIA exempt.

Document Revisions List

Date Revision Type Creator/Editor

20170523 Initial Publication DETAR, L.E.

20170607 Addition of GFP information and taskings for Contractors DETAR, L.E.

Table of Contents

Introduction Purpose Scope Background Glossary Tasks and Processes Roles Mission Engineering Director Mission Engineering Group Leaders Senior Project Leaders and Project Leaders CSEL Manager ISEL Government Users ISEL Contractor Users Appendix A: End User Procedures Prepare to request an ISEL Collect ISEL Request Information Request an ISEL (Contractor) Request an ISEL (Government Employee) Receive Requested ISEL(s) Receive Requested ISEL (Government) Receive Requested ISEL (Contractor) Safeguard ISEL Connectivity Road Warrior Laptop Security Departure Procedures On Return On Arrival of Shipped Classified Hard Drives Unclassified Equipment Turn-In Classified Equipment Turn-In Government Furnished Property Weekly Update of GFP unclassified ISEL hard drives Issue and Return of ISEL drives for classified missions involving GFP Data Collection and Archive File System (DCAFS) and Information Collection Assistance Tool (ICAT) Distribution to Contractors

THIS PAGE INTENTIONALLY LEFT BLANK

1. Introduction

1.1. Purpose

This document defines tactics, techniques, and procedures for managing Information Systems Evaluation Laptops (ISEL).

1.2. Scope

These tactics, techniques, and procedures provide guidance on requesting, issuing, safeguarding, turn-in, and purging of the ISEL. ISEL management contingency operations are also addressed.

It does not provide guidance for using the ISEL and its tools or for updating the ISEL image or its content. That guidance is contained in the ISEL Wiki, located on the ISEL. This TTP applies to all USAISEC military, civilian, and supporting contractor personnel. It applies whenever a military, civilian, or supporting contractor, not assigned or attached to USAISEC, requires an ISEL. Only US Government employees can perform some of the procedures in this TTP. Other procedures are performed only by contractors. When procedures apply only to a specific group, that group is identified at the beginning of the procedure.

1.3. Background

The ISEL is a road warrior system as defined in the Road Warrior Best Business Practice (BBP).

It consists of a laptop chassis and one or more removable or permanently mounted hard drives.

ISELs are cloned from one or more master images maintained by the Cybersecurity Evaluation Lab (CSEL) Manager. The foundation for the master images is the current Army Gold Master/Universal Gold Master (AGM/UGM) workstation operating system. Trained directorate personnel scan customer environments for configuration data and potential vulnerabilities during Risk Management Framework (RMF) or other directed assessments using above baseline tools installed on the image. The ISEL does not connect to any other network outside the system boundary in which directorate personnel have been engaged to operate. Upon return to home station, directorate personnel transfer data from the ISEL to archive media and return the ISEL to the CSEL Manager. The CSEL Manager formats or purges all returned hard drives and stores them using the guidance provided by the Reuse of Army Computer Hard Drives Best Business Practice and other applicable guidance. When used in a Sensitive but unclassified IP data (formerly known as NIPRNet) environment, the ISEL operates under the Authorization to Operate (ATO) of the Cyber Technology Evaluaton and Aggregated Labs (CTEAL). When used in a Secret IP data (formerly known as SIPRNet) environment, the ISEL operates under the ATO of the Fort Huachuca SIPRNet Installation Campus Area Network (FTH SICAN).

1.4. Glossary

Abbreviations and terms are defined at their point of first use.

2. Tasks and Processes

2.1. Roles and Responsibilities

2.1.1. Mission Engineering Director

The Mission Engineering Director is ultimately responsible for the configuration, accountability, and security of the ISEL and associated equipment. The Director has delegated these responsibilities to various subordinate US Government employees within the Directorate.

2.1.2. Senior Systems Engineer – Technical (SSE-T)

The SSE–T ensures that all US Government and contractor personnel using the ISEL meet and continue to meet Department of Defense and Army requirements for system and network access and additional requirements for access to the ISEL and customer networks.

2.1.3. Mission Engineering Group Leaders requiring ISEL support:

2.1.3.1. ensure ISELs are requested and returned in a timely manner and safeguarded while under the control of their group members.

2.1.3.2. ensure continuous competency of group members to use the ISEL and its tools.

2.1.3.