Information Assurance, A DISA CCRI Conceptual Framework

1. A PROPOSED CONCEPTUAL FRAMEWORK FOR THE DISA CCRI PROCESS
DISA CCRI Background
Command Cyber Readiness Inspections (CCRIs) replaced Enhanced Compliance Validations (ECVs) in October
2009 as the mechanism by which Commanders would begin being held accountable for their respective network and
enclave security posture.
Phase I of the CCRI program implemented a rigorous new grading criteria which provided greater objectivity and
analytical measurements of a site's security posture by reviewing technology areas, vulnerability scan results,
compliance with US Cyber Command (previously Joint Task Force-Global Network Operations) issued Computer
Network Defense (CND) Directives, and non-technical aspects of an information assurance (IA) program (culture,
conduct, and capability).
Phase II of the CCRI program, implemented May 2011, implements changes to the CCRI grading methodology
derived from lessons learned from Phase I, and also begins process changes to shift the CCRI methodology from
strictly a compliance based inspection toward an operational readiness inspection.
DISA CCRI Overview
CCRI is a technical and operational inspection program that ensures compliance with information assurance (IA)
and computer network defense (CND) policies. The inspection is also a technical evaluation of a site’s compliance
with the configuration standards for various technologies as set forth in the DISA Security Technical
Implementation Guides (STIGs). During 2010, the CCRI program underwent a major transformation to formalize
the inspection process and institute a grading structure based on objective, measurable, and repeatable processes.
This formal grading criterion went into effect on Jan. 24, 2010. During this same period, the CCRI team also
pioneered a USCYBERCOM directed “no notice” inspection. These “no notice” inspections are directed from
USCYBERCOM and may be announced to a site from two weeks before to as short as the very same morning. An
immediate benefit of the CCRI program is that sites and program managers are now motivated to review their
network defenses on a continual basis with clearly-defined objectives and are keeping their senior leaders informed.
This emphasis decreases the window of opportunity for vulnerabilities. In addition, the involvement of senior
leaders is emphasized in a formal inspection notification process and through the use of Hot Wash sessions at the
conclusion of each inspection. Another dimension of the CCRI program provides metrics used by USCYBERCOM
to issue communications tasking orders and cyber alerts.
A CCRI determines compliance with Defense Information Systems Agency (DISA) Security Requirements Guides
(SRG), Security Technical Information Guides (STIG), Security Readiness Review (SRR) Scripts, STIG
Benchmarks, USCYBERCOM warning and tactical directives/orders (e.g., Fragmentary Orders [FRAGO],
Information Assurance Vulnerability Management [IAVM] notifications [i.e., Information Assurance Vulnerability
Alerts {IAVA}, Information Assurance Vulnerability Bulletins {IAVB} and Technical Advisories {TA} and
Communications Tasking Orders {CTO}], as well as Computer Network Directives [CND]).
SRGs provide general security compliance guidelines. SRGs serve as source guidance documents for STIGs. As
DOD prepares for conversion from the DOD 8500 IA controls to the more widely accepted NIST Special
Publication SP 800-53 Revision 3 security controls (NIST published NIST SP 800-53 Revision 4 on April 25,
2013), and to facilitate efforts to automate the STIGs, Field Security Operations (FSO) expresses the 800-53
controls into a set of technical and operational control correlation identifiers (CCI). Each 800-53 control is broken
down into a single, actionable statement, written with a technology neutral position. The CCIs serve as the unique
identifiers that will trace all future STIG development efforts back to the NIST controls and as a reference
framework to pull together the SCAP results.
FSO is developing four security requirement guides (SRGs): one for operating systems, one for network devices,
one for applications, and one to address the operational policy controls. The SRGs group the CCIs into more
applicable, specific technology areas and bridges the gap between overarching policy, CCIs, and STIGs. FSO will
Author: https://www.linkedin.com/jderienzo
1

2. A PROPOSED CONCEPTUAL FRAMEWORK FOR THE DISA CCRI PROCESS
use the SRGs as the base requirements for all product STIGs, and the SRGs may be used as a guide by product
vendors to build a more secure products, which address DOD requirements.
STIGs document applicable DOD policies and security requirements for specific technical products, as well as best
practices and configuration guidelines. DISA FSO transformed STIGs from the static Portable Document Format
(PDF) to the Extensible Markup Language (XML) format. When a browser application such as Internet Explorer
opens these XML files they closely resemble the form and content of the legacy PDF STIGs thanks to the
accompanying EXtensible Stylesheet Language Transformation (XSLT) file. XML facilitates the use of the STIG
content as input to various automated processes. For example, it is now possible to populate spreadsheets and
databases with STIG content in a way not possible with the PDF versions. FSO provides the STIG Viewer Version
1.1.3 (beta), a Java application for rendering the STIG XCCDF XML content into a STIG checklist that can be
uploaded to the U.S. Department of Defense (DOD) Vulnerability Management System (VMS).
STIGs contain vulnerability data by Vulnerability Key, STIG ID, Severity, Short Name, Long Name, Condition,
Vulnerability Discussion, Default Finding Details, Checks, Fixes and much more. A java tool called “The STIG
Viewer,” offers several options for exporting Reviewer checks (e.g., Not a Finding) into VMS. For instance, the
STIG Viewer can either: 1). “Create an Import file for VMS”; 2). “Export a Custom STIG Checklist as CSV”; 3).
“Export a Short-form Checklist as HTML”; 4) “Export a Checklist as XML”. Some Reviewers prefer using the
STIG Viewer to build their Custom STIG checklist for import into VMS; others prefer working directly inside
VMS. The STIG Viewer requires the installation of the JAVA Virtual Machine on the workstation. The Import File
will be merged into VMS as long as the IP Address, MAC Address and Description field are manually added to the
Import File using WordPad (ask your CCRI instructor or Senior Reviewer for a demonstration). The asset has to be
pre-registered in VMS either by the System Administrator or the CCRI Reviewer based on equipment type,
Software/Firmware Version and Asset Role (e.g., perimeter router, perimeter firewall, infrastructure L2 switch).
After the Import file has been merged into VMS, the reviewer can check the FOUO IAVA notices for the operating
system associated with the network device. IAVAs may require additional research to determine if a vulnerability
applies to a specific operating system version. If the feature associated with the IAVA is not being used (e.g., PKI
certificates), this would be Not Applicable (N/A).
Most STIGs are published as (U) Unclassified and (FOUO) For Official Use Only. Both are Unclassified, but only
the (U) STIG is publicly available. The FOUO version contains the DISA Information Assurance Vulnerability
Alert (IAVA) ID associated with the vulnerability. All users can retrieve the Unclassified STIG, but only DOD
Points of Contact (POC) with a Common Access Card (CAC) can download the FOUO version to removable media.
Non-DOD users must contact their DOD POC to request a copy of the FOUO STIG version (e.g., IAVM STIG).
The DISA IASE does not accept ECAs for access to the PKI-protected content on the IASE. The PKI-protected
content is for use by DoD Military, Civilian, and Contractors, provided they possess a DoD CAC, as a result of
access to a DoD-owned information system. If a contractor needs access to PKI-protected content on the IASE, they
should contact their DoD Government sponsor to obtain the information required to fulfill their contract.
While SRR Scripts test software products for STIG compliance, runtime requirements can introduce new
vulnerabilities to the system (e.g., administrator access, installation of application components, and the inability of
the operating system to authenticate a script prior to execution); therefore, DISA currently provides SRR Scripts for
the Unix operating system, as well as database and web applications. DISA is in the process of replacing all SRR
Scripts with STIG OVAL Benchmarks. The Open Vulnerability and Assessment Language (OVAL) standardizes
the assessment and reporting of the machine state of computer systems. In combination with the Extensible
Configuration Checklist Description Format (XCCDF), OVAL allows Security Content Automation Protocol
(SCAP) validated tools such as DISA’s HBSS Policy Auditor and SCAP Compliance Checker (SCC), to run
automated STIG checks. Currently, DISA publishes STIG Benchmarks for Windows platforms, UNIX platforms
and Windows applications (i.e., IE8, IE9).
The STIG Benchmarks do NOT fully automate compliance validation for all STIG requirements. The "truly
manual" requirements will always be manual, especially with Policy STIGs, but as SCAP evolves, FSO plans to
Author: https://www.linkedin.com/jderienzo
2

3. A PROPOSED CONCEPTUAL FRAMEWORK FOR THE DISA CCRI PROCESS
"automate" the reporting of the manual policy type requirements utilizing OCIL (Open Checklist Interactive
Language).
Besides STIG compliance, CCRI compliance involves many other aspects of cyber security such as policy
adherence, cyber security training and awareness, traditional security and facility security. Based on the results from
the network scans and changes to the assets, updates to the Authorization and Accreditation (A&A) process may be
required. Vulnerabilities that require risk mitigation are documented in a Plan of Action and Milestones (POA&M).
As an adjunct to the POA&M process, DISA provides the Vulnerability Management System (VMS), an online
repository that monitors and reports the mitigation of known Information Assurance Vulnerability Alerts (IAVAs).
VMS streamlines automation of vulnerability tracking through a relational database and online web views that
provide a centralized repository for vulnerability status information and policy compliance information for both
Non-Classified Internet Protocol Router Network (Low-side) and Secure Internet Protocol Router Network (Highside) clients. VMS information is used for many purposes, from practical vulnerability remediation to Approval to
Operate (ATO). Scan results are uploaded to the VMS for tracking, inventory, and Situational Awareness purposes.
In some cases a great deal of manual reporting is required to be input into VMS.
DISA requires CCRI candidates to complete a combination of instructor-led, independent study and hands-on
training. After the candidates pass a background investigation, they must complete a prescribed set of Security
Awareness computer-based training (CBT) curriculum, as well as VMS and DISA technical CBTs. The candidate
must complete a four day instructor-led training course followed by a five hour Security Readiness Review (SRR)
Walk-through exam in their subject matter area, namely: CCRI Team Lead, Networks and Network Devices,
Vulnerability Assessments, UNIX, Windows, DNS and Physical Security (Traditional). After passing the Walkthrough exam, the candidate submits an application requesting a “MyVMS” account. The CCRI candidate must
request a Low-side or a High-side account to access VMS and receive FOUO IAVM messages, Communications
Tasking Orders (CTO), Information Assurance Vulnerability Alerts (IAVA) and Information Assurance
Vulnerability Bulletins (IAVB). The CCRI Reviewer requires a Common Access Card (CAC) and a Low-side
computer to download the FOUO version of the STIGs to copy them to removable media. Or a DOD designated
sponsor can do this on their behalf.
Once the candidate becomes familiar with VMS and passes the VMS FedVTE training course, the next step is to
complete two mandatory training trips: an On the Job Training (OJT) trip and a Check-ride trip, preferably within 90
days of passing the Walkthrough exam. The OJT trip provides the opportunity for the candidate to observe a Senior
Security Reviewer in action. The candidate is expected to participate by asking relevant questions. The Check-ride
trip provides the opportunity for a CCRI Senior Reviewer to observe the candidate in action. A Senior Reviewer
grades the candidate and the CCRI Team Lead determines if the candidate is ready or requires an additional trip.
CCRI Reviewers must complete four (4) CCRI reviews each year to maintain their CCRI Reviewer status. A CCRI
Reviewer must repeat this process in each subject matter area and retake the Walkthrough exam for each discipline
on an annual basis. Annual refresher training is optional, as many CCRI Reviewers decide to test out of the training
class and just take the Walkthrough exam. Recently, the DISA waived the annual Walkthrough exam requirement.
As of January 2013, in accordance with Department of Defense Directive 8570 (DODD 8570), Information
Assurance Technical (IAT Level I, II, III) personnel must maintain a vendor certification in their area of expertise
(e.g., Microsoft Certified Systems Administrator [MCSA] vendor certification for Microsoft Windows reviews;
Tenable Certified Network Associate [TCNA] for Nessus vulnerability assessments; Cisco Certified Network
Associate for network security reviews of Cisco equipment; and, CompTIA Linux+ certification for Red Hat
Enterprise Linux reviews). See Appendix I for more information.
Author: https://www.linkedin.com/jderienzo
3

4. A PROPOSED CONCEPTUAL FRAMEWORK FOR THE DISA CCRI PROCESS
The Defense Information Assurance Security Accreditation Working Group (DSAWG) recommends all Mission
Partners read and be familiar with the following DOD Information Assurance (IA) Policy:
• DOD Directive 8000.01, Management of the Department of Defense Information Enterprise
• DOD Directive 8500.01E, Information Assurance (IA)
• DOD Directive O-8530.1, Computer Network Defense (CND)
• DOD Directive 8570.01, Information Assurance (IA) Training, Certification, and Workforce Management
• DOD Instruction 8110.1, Multinational Information Sharing Networks Implementation
• DOD Instruction 8410.02, NETOPS for the Global Information Grid (GIG)
• DOD Instruction 8500.02, Information Assurance (IA) Implementation
• DOD Instruction 8510.01, DOD Information Assurance Certification and Accreditation Process (DIACAP)
• DOD Instruction 8520.02, Public Key Infrastructure (PKI) and Public Key (PK) Enabling
• DOD Instruction O-8530.2, Support to Computer Network Defense (CND)
• DOD Instruction 8551.1, Ports, Protocols, and Services (PPSM)
• DOD Instruction 8552.01, Use of Mobile Code Technologies in DOD Information Systems
• DOD Information System Certification and Accreditation Reciprocity, 23 July 2009
• Department of Defense Mobile Device Strategy, 8 June 2012
A Proposed CCRI Conceptual Framework
To visualize the CCRI methodology better, a conceptual framework with four distinct phases is being proposed.
The four phases are: SCOPE (define constraints), INSPECT (assets), DOCUMENT (observations) and REPORT
(findings). See Figure 1: below.
SCOPE
(DEFINE CONSTRAINTS)
INSPECT
REPORT
(FINDINGS)
(ASSETS)
DOCUMENT
(OBSERVATIONS)
Figure 1: The CCRI Conceptual Framework
Author: https://www.linkedin.com/jderienzo
4

5. A PROPOSED CONCEPTUAL FRAMEWORK FOR THE DISA CCRI PROCESS
SCOPE
The CCRI Team Lead establishes a clear scope of effort prior to the on-site inspection by providing the Network
Reviewer with a list of equipment types and network environments that will be inspected. A Reviewer should be
familiar with the DISA Network STIGs, the IAVM STIGs, the Security Readiness Guides (SRG), any guidelines
and whitepapers, as well as the operational aspects of an information assurance (IA) program (culture, conduct, and
capability).
A typical CCRI Network SRR will include the inspection of at least eight network devices (e.g., premise router,
firewall, infrastructure L2 Switch and network policy and procedures). The Network/Perimeter list below contains
the most relevant STIGs, SRGs, Guides and Whitepapers. Network/Perimeter STIGs and Checklists that fall out of
scope--subject to change--are at the end of the list.

Network/Perimeter
o
o
STIGs








SRGs





(FOUO) CISCO IOS IAVM, Version 1, Release 1
(U) Network Firewall - Version 8, Release 14.
(U) Network IDS/IPS - Version 8, Release 14.
(U) Network Infrastructure Router L3 Switch - Version 8, Release 14.
(U) Network L2 Switch STIG Version 8 Release 14.
(U) Network Other Devices - Version 8, Release 14.
(U) Network Perimeter Router L3 Switch - Version 8, Release 14.
(U) Network Policy - Version 8, Release 14.
(U) Firewall SRG, Version 1.
(U) Firewall SRG, Version 1 Release Memo.
(U) Intrusion Detection and Prevention System (IDPS) SRG Version 1.
(U) Intrusion Detection and Prevention System (IDPS) SRG Version 1 Release
Memo.
(U) Network SRG
o
Guides
 (FOUO) Cisco Router Procedure Guide - Version 2, Release 2.
o
Whitepapers (Supplements of Network Infrastructure STIG, V8R1)
 (U) IDS/IPS Systems White Paper
 (U) Network Access Control White Paper
 (U) Network Management White Paper
 (U) VLAN Provisioning White Paper
o
Out of Scope
 Android 2.2 (Dell) - Release Memo.
 Android 2.2 (Dell) STIG, Version 1, Release 1.
 Backbone Transport Services STIG - Version 2, Release 2.
 BlackBerry (OS7 and BES5) STIG - Version 2, Release 3.
 BlackBerry 10 OS STIG Release Memo.
 BlackBerry 10 OS STIG Version 1.
 BlackBerry Device Service STIG Release Memo.
 BlackBerry Device Service STIG Version 1.
 BlackBerry PlayBook OS v2.1 STIG Release Memo.
 BlackBerry PlayBook OS v2.1 STIG Version 1.
Author: https://www.linkedin.com/jderienzo
5

6. A PROPOSED CONCEPTUAL FRAMEWORK FOR THE DISA CCRI PROCESS
























































BlackBerry STIG - Version 2, Release 2.
BlackBerry STIG - Version 2, Release Memo.
DoD Bluetooth Requirement Specifications.
CMD Management Server Policy Version 2 Release 2 Manual STIG.
CMD Policy Version 2 Release 3 Manual STIG.
DATMS Checklist - Version 1, Release 1.
DATMS STIG - Version 1, Release 1.
Defense Switched Network (DSN) Checklist - Version 2, Release 3.5.
Defense Switched Network (DSN) STIG - Version 2, Release 3.
DOD Data Spill Procedures Guide for BlackBerry Smartphones.
DoD Enterprise DMZ Checklist - Version 1, Release 1.
DoD Internet DMZ Increment 1 - Phase 1 STIG Memo.
DoD Internet-Low-side DMZ STIG - Version 2, Release 1.
DoD Secure Telecommunications and DRSN Checklist - Ver 1, Rel 2.2.
DoD Secure Telecommunications and DRSN STIG - Ver 1, Rel 2 .
DoD Wireless Smartphone Security Requirements Matrix, Version 3.5.
Domain Name System (DNS) Security Requirements Guide (SRG).
DNS SRG Release Memo.
Domain Name System (DNS) STIG, Version 4, Release 1.14.
Enclave Security Checklist - Version 4, Release 5.
Enclave STIG - Version 4, Release 3.
Draft Enclave Test and Development STIG Version 1.
Draft Enclave Test and Development STIG Version 1 - Comment Matrix.
Draft Enclave Test and Development STIG Version 1 - Memo.
Enclave Zone A Checklist - Version 4, Release 5.
Enclave Zone B Checklist - Version 4, Release 5.
Enclave Zone C Checklist - Version 4, Release 5.
Enclave Zone D Checklist - Version 4, Release 5.
General Mobile Device (Non-Enterprise Activated) STIG Release Memo.
General Mobile Device (Non-Enterprise Activated) STIG Version 1, Release 2.
IPSEC VPN Gateway STIG - Version 1, Release 5.
IPSEC VPN Gateway STIG Memo.
Juniper Router Procedure Guide - Version 2, Release 2.
Medical Devices STIG - Version 1 Release 1.
Medical Devices STIG Memo.
Mobile OS SRG - Release Memo.
Mobile OS SRG, Version 1, Release 2.
Mobile Policy SRG Version 1 Release Memo.
Mobile Policy SRG, Version 1, Release 1.
REL DMZ Checklist - Version 1, Release 1.
REL LAN STIG - Version 1, Release 4.
Samsung Knox Android 1.0 STIG Release Memo.
Samsung Knox Android 1.0 STIG Version 1.
Sharing Peripherals Across the Network (SPAN) STIG, Version 2, Release 4.
SME PED STIG Version 2, Release 1 .
Video Tele-Conference Checklist - Version 1, Release 1.2.
Video Tele-Conference STIG - Version 1, Release 1.
Voice and Video over Internet Protocol (VVoIP) Release Memo - Ver 3, Rel 1.
Voice and Video over Internet Protocol (VVoIP) STIG - Version 3, Release 2.
Windows 7 IAVM Version 1, Release 1.
Windows 7 STIG - Applies to any installation of Windows 7 and tablet computers.
Windows 7 STIG - Version 1, Release 11.
Windows 7 STIG Benchmark Version 1, Release 15.
Windows 7 STIG Release Memo.
Windows 7 STIG, Version 1, Release 10.
Windows 8 IAVM Version 1, Release 1.
Author: https://www.linkedin.com/jderienzo
6

7. A PROPOSED CONCEPTUAL FRAMEWORK FOR THE DISA CCRI PROCESS

Network/Perimeter (continued…)
o
Out of Scope (continued)…
 Windows 8 STIG Version 1 - Release Memo.
 Windows 8 STIG Version 1, Release 1.
 Windows Mobile 6-5 STIG Version 1, Release 2.
 Wireless STIG - Version 6, Release 6.Domain Name System (DNS) Security
Requirements Guide (SRG)
The DISA STIG Master List, http://iase.disa.mil/stigs/a-z.html, contains a list of all available (U) STIGs, SRGs,
Checklists, Guides and Whitepapers. You must request For Official Use Only (FOUO) STIGs from a DOD POC.
The DISA Information Assurance Support Environment (IASE) public website provides an Excel or XML table
containing IAVM to Common Vulnerability Exposure (CVE) mappings. An individual IAVM may have multiple
CVE Numbers associated with it.
The CCRI Reviewer will receive information from the CCRI Team Lead about the network environment and the
types of network devices to be inspected a few weeks prior to the inspection date. High-side allows for the flow of
classified material, which can include sensitive missions.
The Facility Security Officer shall prepare the following network artifacts in advance for availability upon arrival:
1) Network Topology Maps (e.g., product name, host name, available interfaces [e.g., Gi, Fa, Se], circuit
types [e.g., Fast Ethernet, WAN circuit], IP Address/CIDR)
2) Premise Router configuration files in ASCII format
3) Infrastructure L2 Switch configuration files in ASCII format
4) Firewall configuration files in ASCII format
5) Organizational Network Policies and Procedures
INSPECT
Prior to the CCRI site visit, the Network Security Reviewer reviews the network assets in VMS to develop a
situational awareness. This assumes: (1) The CCRI Reviewer is granted the appropriate VMS privileges to view the
Site’s network assets prior to arrival; (2) The Program Manager of the Site creates and maintains a current
hierarchical organizational structure of network assets within VMS.
The Network Security Reviewer manually inspects each network device configuration file against the appropriate
DISA STIG. The DISA STIG assigns a Severity Code to each system IA security weakness to indicate (1) the risk
level associated with the IA security weakness and (2) the urgency with which the corrective action must be
completed. Severity codes are expressed as “CAT I, CAT II or CAT III,” where CAT I is the indicator of greatest
risk and urgency. A CAT I Severity Code is assigned to findings that allow primary security protections to be
bypassed, allowing immediate access by unauthorized personnel or unauthorized assumption of super-user
privileges, and usually cannot be mitigated. A CAT II Severity Code is assigned to findings that have a potential to
lead to unauthorized system access or activity. CAT II findings can usually be mitigated and will not prevent an
ATO from being granted. A CAT III Severity Code is assigned to recommendations that will improve IA posture
but are not required for an authorization to operate. CAT I weaknesses receive the highest priority for correction or
mitigation. CAT I weakness in a component part of a system (e.g., a workstation or server) may be off-set or
mitigated by other protections within hosting enclaves such that the overall risk to the system is reduced to a CAT II.
CAT I weaknesses must be corrected before an Authorization to Operate (ATO) is granted. A system can operate
with a CAT I weakness only when the system is critical and failure to deploy or allow continued operation for
deployed systems will preclude mission accomplishment.
Author: https://www.linkedin.com/jderienzo
7

8. A PROPOSED CONCEPTUAL FRAMEWORK FOR THE DISA CCRI PROCESS
Only the Component CIO can authorize operation of a system with a CAT I weakness, and this can only be done
through an Interim Authorization to Operate (IATO). CAT II weaknesses must be corrected or satisfactorily
mitigated before an ATO can be granted. If CAT II weaknesses cannot be corrected or satisfactorily mitigated
within the time limitation imposed in the IATO, the DAA must certify in writing that continued system operation is
critical to mission accomplishment or terminate system operation. A copy of the authorization to continue system
operation with supporting rationale shall be provided to the DOD Component CIO. CAT III weaknesses, if
corrected, will improve the system’s IA posture but do not preclude an authorization to operate. The DAA will
determine if these weaknesses will be corrected or the risk accepted.
GIG Monitoring (Out of Scope)
There are network Intrusion Detection Systems (IDSs) located on the GIG that monitor standard security policy. The
GIG network IDSs, monitored by Global Network Security Center (GNSC), is (are) known as the Joint Intrusion
Detection System (JIDS). The GNSC monitors all JIDS on the GIG within the CONUS. There are various other
centers located around the world and all centers feed into a DoD Global Network Operations Center (GNOC). This
group identifies any information threat on an isolated, regional, or global basis. The GNSC notifies all parties of any
type of potential unauthorized attack or access, and works with the managing CCC and site Information Assurance
(IA) staff to help identify, isolate, investigate, and remediate potential threats.
CS Enclave Perimeter Monitoring (Out of Scope)
All CS enclave perimeters have a layered defense that consists of Access Control Lists (ACLs) on the perimeter
router, firewalls, and a network IDS. The security staff located in the CCCs develops the security profiles for the
enclave perimeter router, perimeter firewall and perimeter network IDSs and monitor their respective reports and
audit logs for unauthorized access or activities. This is for the entire CONUS-based CS network. The security staffs
located at DECCs Europe and Pacific perform the same tasks locally for their respective enclave perimeter devices.
Suspected incidents are investigated in concert with trusted agents from the customer base or data owners to
determine the legitimacy of the incidents. If the suspected incident cannot be validated as authorized, they are
reported to the Liaison Officer (LNO) and to the GNSC. The GNSC then directs all actions for this incident and
closes it or turns it over to the appropriate investigative agency for action. The Computing Service Cell (CSC)
reports the incident to CS Issue Center within the CS Operations Division.
FSO Monitoring (Out of Scope)
The FSO conducts external vulnerability scanning once a year for the Non-Classified Internet Protocol Router
Network (LOW-SIDE) and Secret Internet Protocol Router Network (HIGH-SIDE) connections at all sites. If the
scan does not penetrate or identify a weakness in the enclave perimeter, the scan is terminated. If the scan does
identify a weakness in the enclave perimeter, the scan continues to further identify weaknesses. The results are
entered into VMS and are briefed to the site director and senior staff.
DOCUMENT
Initially each network device goes through an Assessment and Authorization (A&A) process, previously referred to
as Certification and Accreditation (C&A). The A&A process spans a 3 year cycle; however the conventional A&A
process is being replaced with a Risk Management Framework (RMF) allows each organization to develop a
mission-focused Risk Management Approach (RMA).
After assets go through an A&A, asset changes require manual updates to the original A&A documentation.
CCRI evaluations of the network configurations can involve weeks of preparation by network administrators.
Based on the results from the network manual checks, changes are made to the assets. Updates to A&A
documentation may be required.
Author: https://www.linkedin.com/jderienzo
8

9. A PROPOSED CONCEPTUAL FRAMEWORK FOR THE DISA CCRI PROCESS
Results are uploaded to the DOD Vulnerability Management System (VMS) for tracking, inventory and Situational
Awareness purposes. VMS is a DoD vulnerability management system for Information Assurance Vulnerability
Management (IAVM) and STIG compliance. The IAVM portion is used to track acknowledgement and compliance
with alerts, bulletins, and technical advisories as directed by Chairman of Joint Chiefs of Staff Instruction 6510-01D,
“Information Assurance (IA) and Computer Network Defense.” Information for all assets is registered in VMS:
system details, operating systems, owner, and managing site.
VMS:
CCRI Reviewers should be prepared to perform VMS functions such as:








System/Enclave creation
Work with the DISA STIG Viewer to generate an Import File for VMS. Ability to change the XML header
information so the IP Address, Host Name and Description match VMS.
VMS Reports
Plan of Action and Milestones (POA&M) entry
Designated Approving Authority (DAA) Risk Acceptance (DRA) entry
Update findings to proper status (Fixed, Open, Not a Finding, Not Applicable, Not Reviewed, etc.)
This is defined as interpreting database STIG requirements
VMS also notifies the managing System Administrators (SAs) via email of any newly released IAVMs.
The STIG portion identifies vulnerabilities, and tracks remediation of those vulnerabilities.
Vulnerability Scanning:


Providing US Cyber Command (USCC) Communications Tasking Order (CTO) mandated vulnerability
scan results to partners for resolution.
In accordance with Compliance Task Order (CTO) 08-005, internal scan results are imported into VMS on
a monthly basis.
Patching:





An Information Assurance Vulnerability Alert (IAVA) mandates updates to the configuration of an asset.
The IAVAs are distributed to system administrators dictating fixes that need to be made to systems based
on newly identified vulnerabilities.
The system administrator has the responsibility of checking to see which IAVAs are relevant.
Often times the response to a particular IAVA is to patch installed software. The system administrator
must download and install patch information from the patch server.
The CCRI Reviewer determines if IAVAs are properly implemented.
Author: https://www.linkedin.com/jderienzo
9

10. A PROPOSED CONCEPTUAL FRAMEWORK FOR THE DISA CCRI PROCESS
REPORT
IAVA results are manually reported into VMS. The system administrator (SA) must patch the systems or make
desired configuration changes as per the IAVA, or develop a Plan of Action & Milestones (POA&M) when the
desired changes will be completed. For instance, if the SA is unable to comply with the notice, a POA&M is
prepared and submitted (including implementation timelines) prior to the time specified in the IAVM notice (usually
21days). Submitted POA&Ms must be reviewed and approved by the DAA prior to the IAVM notice mitigation
date.
The CCRI Reviewer may need to create the hierarchical organizational structure for a site’s asset within VMS in
cases where the site has failed to do this beforehand.
The IAVM Coordinator acknowledges receipt of IAVA and IAVB notices in VMS by the specified
acknowledgement date. The CCRI Reviewer checks IAVA and IAVB notices in VMS for situational awareness
purposes.
The IAVM Coordinator, the SA or the CCRI Reviewer revises VMS organizational structure as necessary.
There are specific grading criteria that represent the overall information assurance/computer network defense
compliance, measured on a 100-point scale. The CCRI grading criteria includes IAVA and directives compliance
checks as well as review operational readiness elements supporting the information assurance readiness posture. If a
unit scores less than 70 percent, it is subject to re-inspection. If poor performance continues, the network may be
disconnected from the Global Information Grid (GIG) until that organization corrects its security deficiencies.
Inspectors grade in three categories: category one, the most severe threat; category two, a situation that may
threaten; and category three, which represents a vulnerability that may impact mission integrity. The inspectors
grade for communication areas, contributing factors and traditional security.
An on-site inspection takes about a week and includes mission briefing, reviews of components and methodologies,
and system scans for vulnerabilities. The on-site inspection includes daily after action reviews known as a Hot
Wash, followed by an Out-Brief session on the last day of the inspection.
Author: https://www.linkedin.com/jderienzo
10

11. A PROPOSED CONCEPTUAL FRAMEWORK FOR THE DISA CCRI PROCESS
Appendix I – Information Assurance Technical Workforce Requirements
A DISA accredited CCRI Security Readiness Reviewer (SRR) must satisfy U.S. Department of Defense (DOD)
8570 Baseline Information Assurance pre-requisites (see Table 1 below); pass a five (5) hour walkthrough exam
proctored by DISA Field Security Operations (FSO) personnel; demonstrate a proficiency with the DOD
Vulnerability Management System (VMS); exhibit a proficiency using DISA Security Technical Information Guides
(STIGs) (a Network Reviewer is expected to know the Network Policy STIG, the Network Perimeter STIGs and the
Network Infrastructure STIGs); demonstrate expertise in one or more subject matter areas: network and network
devices, vulnerability assessments (ACAS, SCCVI, The SCAP Compliance Checker, Policy Auditor), Host Based
Security Systems (HBSS), Domain Name System (DNS), Windows, Unix or the physical environment (Traditional);
pass an over-the-shoulder review (On-the-Job Training [OJT]); pass an over-your-shoulder review (Check-ride); and
maintain their CCRI accreditation status by participating in a minimum of four (4) CCRI reviews per calendar year.
A CCRI Reviewer must also be familiar with the following DOD acronyms and definitions:
• Communications Tasking Order (CTO): CTO is used to coordinate and direct defensive measures to mitigate or
eliminate threats to the DISN.
• Computer Network Directive (CND): CND focuses on protecting the Global Information Grid (GIG) network
and hardware. For example, many defense organizations have restrictions on USB memory sticks and peer-topeer (P2P) applications.
• Fragmentary Order (FRAGO): A FRAGO is a change to an existing Operations Order (OPORD) and addresses
only elements that have changed (e.g., mission, execution).
• Information Assurance Vulnerability Alert (IAVA): IAVA addresses severe network vulnerabilities that pose a
threat to the network.
• Information Assurance Vulnerability Bulletin (IAVB): IAVB addresses new vulnerabilities that do not pose an
immediate threat or risk.
• Information Assurance Vulnerability Management (IAVM): IAVM notification provides positive control of
vulnerability notification, corrective action, and IAVA visibility status.
• Technical Advisory (TA): TA addresses new vulnerabilities that are generally low risk.
Author: https://www.linkedin.com/jderienzo
11

12. A PROPOSED CONCEPTUAL FRAMEWORK FOR THE DISA CCRI PROCESS
Table 1: IA Technical Workforce Requirements
Civilian, Military, Contractor* (Including
Civilian or Contractor LNs)
IAT Level I - III
(Foreign National and LN Levels I & II only)
Initial Training **
IA Certification
(from approved list)
Yes
Yes
(within 6 months)
Initial On the Job Practical Evaluation
Yes
(for initial position)
CE Certification
Yes
Maintain Certification Status
Yes
(as required by certification)
Continuous Education or
Sustainment Training
Yes
(as required by certification [e.g.,
International Information
Security Certification Consortium {ISC 2}
requires 120 hours within 3 years for the
CISSP])
Background Investigation
As required by IA level and Reference (b)
Sign Privileged Access Statement
Yes
*Contractor category, level, and certification requirements to be specified in the contract
**Classroom, distributive, blended, government, or commercial provider
IATs with privileged access MUST OBTAIN APPROPRIATE COMPUTING ENVIRONMENT (CE)
CERTIFICATIONS for the operating system(s) and/or security related tools/devices they support as required by
their employing organization. If supporting multiple tools and devices, an IAT should obtain CE certifications for all
the tools and devices they are supporting. At a minimum the IAT should obtain a certification for the tool or device
he or she spends the most time supporting. For example, if an IAT is spending most of his or her time supporting
security functions on a CISCO router, the IAT should obtain a CE certification for that equipment.
(*DOD 8570.01-M, Information Assurance Workforce Improvement Program, Incorporating Change 2, 02/2510)
Author: https://www.linkedin.com/jderienzo
12

13. A PROPOSED CONCEPTUAL FRAMEWORK FOR THE DISA CCRI PROCESS
Table 2: IAT Level III Position Requirements
Experience
• Normally has at least seven years experience in IA technology or a related area.
System Environment
• Enclave Environment, advanced NE, and advanced CE.
Knowledge
• Expert in all functional requirements functions of both IAT Level I and IAT Level II positions.
• Applies extensive knowledge of a variety of the IA field’s concepts, practices, and procedures
to ensure the secure integration and operation of all enclave systems.
Supervision
• Works independently to solve problems quickly and completely.
• May lead and direct the work of others.
• Typically reports to an enclave manager.
Other
• Relies on extensive experience and judgment to plan and accomplish goals for the enclave
environment.
• Supports, monitors, tests, and troubleshoots hardware and software IA problems pertaining to
the enclave environment.
• Must be a U.S. Citizen.
IA Certification & Operating System Certification
• Within six 6 months of assignment to position
Author: https://www.linkedin.com/jderienzo
13

14. A PROPOSED CONCEPTUAL FRAMEWORK FOR THE DISA CCRI PROCESS
Table 3: IAT‐3 Functions
01.
02.
03.
04.
05.
06.
07.
08.
09.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
Mastery of IAT Level I and IAT Level II CE/NE knowledge and skills.
Recommend and schedule IA related repairs within the enclave environment.
Coordinate and ensure end user support for all enclave applications and operations.
Lead teams to quickly and completely solve IA problems for the enclave environment.
Formulate or provide input to the enclave's IA/IT budget.
Plan and schedule the installation of new or modified hardware, operating systems, and software
applications ensuring integration with IA security requirements for the enclave.
Determine whether a security incident is indicative of a violation of law that requires specific
legal action.
Direct the implementation of appropriate operational structures and processes to ensure an
effective enclave IA security program including boundary defense, incident detection and
response, and key management.
Provide direction to system developers regarding correction of security problems identified during
testing.
Evaluate functional operation and performance in light of test results and make recommendations
regarding certification and accreditation C&A.
Examine enclave vulnerabilities and determine actions to mitigate them.
Monitor and evaluate the effectiveness of enclave IA security procedures and safeguards.
Analyze IA security incidents and patterns to determine remedial actions to correct
vulnerabilities.
Develop the enclave termination plan to ensure that IA security incidents are avoided during
shutdown and long term protection of archived resources is achieved.
Develop and apply effective vulnerability countermeasures for the enclave.
Develop and manage IA customer service performance requirements.
Develop IA related customer support policies, procedures, and standards.
Write and maintain scripts required to ensure security of the enclave environment.
Design perimeter defense systems including intrusion detection systems, firewalls, grid sensors,
etc., enhance rule sets to block sources of malicious traffic, and establish a protective net of
layered filters to prevent, detect, and eradicate viruses.
Schedule and perform regular and special backups on all enclave systems.
Establish enclave logging procedures to include: important enclave events; services and proxies;
log archiving facility.
Provide OJT for IAT Level I and II DOD personnel.
Analyze IAVAs and Information Assurance Vulnerability Bulletins for enclave impact and take
or recommend appropriate action.
Obtain and maintain IA certification appropriate to position.
Author: https://www.linkedin.com/jderienzo
14