DoD Cybersecurity Discipline Implementation PlanPurpose. In coordination between Commander, USCYBERCOM and the DoD CIO, this Implementation Plan directs Commanders and Supervisors to implement the four prioritized Lines of Effort herein to mitigate risks and operationalize cyber readiness reporting for the information systems they own, manage, or lease for mission assurance through DRRS. End State. A persistent state of high enterprise cybersecurity readiness across the DoD environment required to deliver mission assurance on all unclassified, Secret fabric, and Top Secret (TS) collateral DoD information systems, including DoD programs; special access programs; mission systems; and strategic, tactical, and RDT&E systems - hereafter called “DoD information networks.” Method. In order to raise Commanders' and Supervisors' awareness and accountability for critical cybersecurity readiness of their information systems, associated reporting requirements will be included in DRRS and the cybersecurity scorecard. Details regarding the reporting criteria are included in each section of this Implementation Plan. Leaders throughout the Department are responsible for ensuring the information capabilities they own, manage, or lease have implemented the requisite level of cybersecurity. The security principles in cyberspace are very similar to those in securing physical battlespace. * Fortify the security posture for DoD information networks by reducing the number of vulnerable points through which an adversary could gain access and move laterally. This critical area drives three requirements: use strong authentication, harden the devices, and reduce the attack surface. * Ensure continued protection, monitoring, analysis, detection, and response against intrusion attempts. Computer Network Defense Service Providers (CNDSPs) perform this function for the DoD information networks, requiring Commanders to align their systems and networks to CNDSPs. The Lines of Effort within this document comprise the first phase of this Implementation Plan in order to maximize the initial reduction of network- and system-based risk to mission readiness. The DoD Cybersecurity Campaign will continue to prioritize efforts to assist Commanders and Supervisors in focusing on the most important requirements contained within existing cybersecurity policies, directives, and orders. Follow on guidance regarding specific objectives and required support will be promulgated separately. Appendix D provides the mapping of this Implementation Plan’s Lines of Effort to the DoD Cybersecurity Scorecard.U.S. Department of DefenseDoD_5e8dcfdc-5d6a-11df-839d-400e7a64ea2aUSCYBERCOMDoD CIODoD CommandersDoD SupervisorsA persistent state of high enterprise cybersecurity readiness across the DoD environment ... _243718b6-e6fd-11e5-9dd9-bd9ce1bcaf9cTo mitigate risks and operationalize cyber readiness reporting for the information systems_24371b86-e6fd-11e5-9dd9-bd9ce1bcaf9cAuthenticationReduce anonymity and improve the security posture of the Department and DoD information networks._24371cbc-e6fd-11e5-9dd9-bd9ce1bcaf9cEffort 1Strong Authentication -- The goal of strong authentication is to reduce anonymity and improve the security posture of the Department and DoD information networks. Strong authentication as defined by CNSSI 4009 (Reference (u)) requires two or more factors in order to securely authenticate a user: 1) something the user knows, such as a password or key code; 2) something the user is, such as biometrics; and 3) something the user has, such as a security token. The ultimate outcome is that systems (of whatever sort) require PKI-based authentication/credentials. The connection between weak passwords and account takeovers via brute force attacks are well-established. Traditionally, individuals requiring access to DoD information networks had to create network- and system-specific user names and passwords to access information online. DoDI 8520.03 (Reference (f)) requires system owners to evaluate the sensitivity level of the information on their system to determine what type of authentication credential is required from the user. The question is: "Can an adversary access resources using a password even if DoD personnel cannot?" Logging on via PKI may still leave a gap if the attacker can log on using a password. Therefore, the system must require PKI. Per Component responses to TASKORDs and FRAGOs, DoD compliant tokens have been issued to the majority of DoD system users and their use is mandated for access to NIPRNet and Secret-level networks. Per USCYBERCOM ORDERS (Reference (ae)), the strong authentication requirements for Privileged Users across the DoD information network are established. The Department is a high-profile target; web servers, web applications, user systems, and network devices are constantly vulnerable to password-based exploitation. Requiring strong authentication helps prevent compromised user credentials from being exploited for unauthorized lateral movement within trusted zones, web servers, and web applications : 1) internal to the NIPRNet (not in a DoD DMZ); 2) hosting controlled unclassified information within a DoD DMZ; and 3) on all Secret-level networks will improve DoD required strong authentication.NIPRNetEnsure web servers and web applications internal to the NIPRNet (not in a DoD DMZ) require DoD-approved PKI user authentication._24372374-e6fd-11e5-9dd9-bd9ce1bcaf9cTask 1.1DoD CommandersDoD SupervisorsCommanders and Supervisors must ensure their web servers and web applications internal to the NIPRNet (not in a DoD DMZ) require DoD-approved PKI user authentication. DoDI 8520.03 (Reference (f)) states: "For all sensitivity levels, information systems will support identity authentication using all credential strengths that meet or exceed the minimum identified." This means that all DoD information systems must support user authentication with DoDapproved PKI, regardless of the sensitivity level of information on the system. In the face of current threats, this higher level of trust is needed for authenticating users to web servers and web applications internal to the NIPRNet (not in a DoD DMZ). In preferential order: i. PK-enable requiring DoD-approved PKI to PKI authenticate directly at the web server or web application. This requirement is satisfied when web servers require direct PKI authentication for web applications they host. ii. If i. is not possible, then the web server or web application must be served by a DoDapproved, PK-enabled proxy (Example: DoD Authentication Gateways). iii. For users unable to use i. or ii. and if it is operationally approved by the requisite DoD Component CIO, use an assertion service that is compliant with DoD standards. Ensure you include justification for this selection. An assertion service is a DoD strong authentication mechanism that provides additional challenges and responses to prove an identity (Example: DoD Self-service Logon). - If all users are required to be authenticated to web servers and web applications internal to the NIPRNet (not in a DoD DMZ) via one of the three methods, then Achieved. - If any users are able to be authenticated to web servers and web applications internal to the NIPRNet (not in a DoD DMZ) without using one of the three methods, or are able to access them anonymously, then Not Achieved.Controlled Unclassified InformationEnsure web servers and web applications hosting controlled unclassified information (CUI) within a DoD DMZ require DoD approved PKI user authentication._24372375-e6fd-11e5-9dd9-bd9ce1bcaf9cTask 1.2DoD CommandersDoD SupervisorsCommanders and Supervisors must ensure their web servers and web applications hosting controlled unclassified information (CUI) within a DoD DMZ require DoD approved PKI user authentication. This higher level of trust is also needed for authenticating users to web servers and web applications hosting CUI within a DoD DMZ. DoDM 5200.01-V4 (Reference (i)) defines CUI as “unclassified information that requires safeguarding or dissemination controls, pursuant to and consistent with applicable law, regulations, and Government-wide policies.” In preferential order: i. PK-enable using DoD-approved PKI and require direct PKI authentication at the web server or web application. This requirement is satisfied when web servers require direct PKI authentication for web applications they host. ii. If i. is not possible, then the web server or web application must be served by a DoDapproved, PK-enabled proxy (Example: DoD Authentication Gateways). iii. For users unable to use i. or ii. and if it is operationally approved by the requisite DoD Component CIO, use an assertion service that is compliant with DoD standards. Ensure you include justification for this selection. An assertion service is a DoD strong authentication mechanism that provides additional challenges and responses to prove an identity (Example: DoD Self-service Logon). - If all users are required to be authenticated to web servers and web applications hosting CUI within a DoD DMZ via one of the three methods, then Achieved. - If any users are able to be authenticated to web servers and web hosting CUI within a DoD DMZ without using one of the three methods, or able to access them anonymously, then Not Achieved.Secret-Level NetworksEnsure web servers and web applications residing on Secret-level networks require DoD approved PKI user authentication._24372376-e6fd-11e5-9dd9-bd9ce1bcaf9cTask 1.3Commanders and Supervisors must ensure their web servers and web applications residing on Secret-level networks require DoD approved PKI user authentication. This higher level of trust is also needed for authenticating users to web servers and web applications on Secret-level networks. In preferential order: i. PK-enable using DoD-approved PKI and require direct PKI authentication at the web server or web application. This requirement is satisfied when web servers require direct PKI authentication for web applications they host. ii. If i. is not possible, then the web server or web application must be served by a DoDapproved, PK-enabled proxy (Example: DoD Authentication Gateways). iii. For users unable to use i. or ii. and if it is operationally approved by the requisite DoD Component CIO, use an assertion service that is compliant with DoD standards. Ensure you include justification for this selection. An assertion service is a DoD strong authentication mechanism that provides additional challenges and responses to prove an identity (Example: Authentication Gateway Service). - If all users are required to be authenticated to web servers and web applications on a Secret-level network via one of the three methods, then Achieved. - If any users are able to be authenticated to web servers and web on a Secret-level network without using one of the three methods, or able to access them anonymously, then Not Achieved.System AdministratorsEnsure 100% use of separate PKI identity authentication credentials for system administrators of any DoD information network._24372377-e6fd-11e5-9dd9-bd9ce1bcaf9cTask 1.4DoD CommandersDoD SupervisorsDoD System AdministratorsCommanders and Supervisors must ensure 100% use of separate PKI identity authentication credentials for system administrators of any DoD information network, and disable username/passwords. Privileged user accounts present a higher risk if compromised. According to DoDI 8520.03, "information systems with administrative accounts and other accounts or roles that authorize entities access to data regardless of sensitivity level within a system shall be required to use an identity credential that meets [hardware token PKI technology]." Per Technical TASKORDs, Enterprise or Domain Administrator accounts that require smart card (e.g. Common Access Card, PIV/PIV-I, National Security System PKI Token) logon [must] use a different smart card for these accounts than for their other accounts. Amplifying direction from that Technical Attachment states that Enterprise or Domain Administrators must have at least two different smart cards, each with different PKI credentials. Ultimately, privileged credentials must be the only acceptable access for administering a domain or system. Commands may not load multiple certificates for different privilege levels onto a single smart card. From this point forward, PKIbased authentication/credentials will be used to indicate hardware token PKI technology and two factor authentication. a. Per Technical TASKORDs, do all Enterprise and Domain Administrators have separate PKI credentials on separate smart cards that are issued and in use? - If yes, then Achieved. - If no, then Not Achieved. b. Does Active Directory require separate credentials? - If yes, then Achieved. - If no, then Not Achieved. c. Has compliance been achieved with USCYBERCOM TASKORDS? - If disabled, then Achieved. - If not disabled, then Not Achieved. d. Has compliance been achieved with USCYBERCOM TASKORDS? - If compliant, then Achieved. - If not compliant, then Not Achieved.Network Infrastructure DevicesEnsure any login to a network infrastructure device requires PKI-based authentication/credentials._24372378-e6fd-11e5-9dd9-bd9ce1bcaf9cTask 1.5DoD CommandersDoD SupervisorsCommanders and Supervisors will ensure any login to a network infrastructure device requires PKI-based authentication/credentials. Network infrastructure devices are the backbone of the DoD information networks. If compromised, they can provide an accurate picture of cyber terrain, access to network configurations, and data. Strengthening the cyber defenses for network infrastructure devices remains a priority for the Department. Username and password logins are easily captured and exploited by the adversary. STIG ID NET0445 from the Network Policy STIG (Reference (z)) states: “To ensure the proper authorized network administrator is the only one who can access the device [(e.g. routers, Layer 2 and Layer 3 switches, firewalls, intrusion detection/ prevention systems)], the [Information System Security Officer] will ensure device management is restricted by two-factor authentication (e.g., SecurID [(RSA keys)], DoD PKI, or alternate token logon).” a. Do all network infrastructure devices require PKI-based authentication/credentials for login? - If all require PKI-based authentication/credentials for authentication, then Achieved. - If any network infrastructure device is either not capable of PKI-based authentication/credentials or is capable, but still allows username and password for login, then Not Achieved.Device HardeningMitigate device vulnerabilities._243723e2-e6fd-11e5-9dd9-bd9ce1bcaf9cEffort 2Device Hardening -- Device vulnerabilities are exploitable weaknesses in software or hardware that provide an adversary with an opportunity to compromise the confidentiality, integrity, and/or availability of an IS. Adversaries attempt to exploit vulnerabilities successfully for various purposes, including accessing or exfiltrating sensitive information, modifying system configurations, installing malicious code, and/or denying system access to authorized users. For example, a number of widely deployed operating systems have become obsolete and must be removed from the network. It is critical that those responsible for building, operating, securing, maintaining, and ensuring the confidentiality, integrity, and availability of DoD information systems maintain a unified and resilient capability to minimize the effects of these vulnerabilities on mission operations. The Department has instituted various means to mitigate such vulnerabilities, including STIGs, the Information Assurance Vulnerability Management (IAVM) program, and the security controls adopted from National Institute of Standards and Technology (NIST) 800-53 (Reference (v)) in coordination with CNSSI 1253 (Reference (t)) within the DoD Risk Management Framework (RMF). Per DoDI 8510.01 (Reference (e)), "IT products (including applications), as defined in [DoDI 8500.01 (Reference (d))], will be configured in accordance with applicable STIGs under a cognizant [Information System Security Manager] and security control assessor." Furthermore, CJCSM 6510.02 (Reference (k)) outlines the IAVM program and its requirements, including that "[Combatant Commands/Services/Agencies/Field Agencies] are responsible for ensuring all affected assets under their purview are compliant with IAVA directives." These programs, in concert with properly configured hardening and attack detection tools such as the Host Based Security System (HBSS), assist in defending DoD assets and networks from adversarial activity. In some cases, cybersecurity requires risk decisions with high impact. Per DoDI 8510.01 (Reference (e)), only the DoD Component CIO is allowed to accept a "High" or "Very High" level of risk and "the authority cannot be delegated below the DoD Component CIO." Any concurrence and authorization decision documentation for systems with "High" or "Very High" levels of risk will be routed to the Information Security Risk Management Committee (ISRMC) which provides strategic guidance to Tiers 2 and 3; assesses Tier 1 risk; authorizes information exchanges and connections for enterprise ISs, crossMA ISs, cross security domain connections, and mission partner connections. Compliance with the associated POA&M timelines for these high levels of risk is critical to ensuring the cybersecurity of the Department.Windows XP & Server 2003Upgrade or remove Windows XP and Windows Server 2003 operating systems on unclassified, Secret level networks, and DoD Top Secret networks._2437252c-e6fd-11e5-9dd9-bd9ce1bcaf9cTask 2.1DoD CommandersDoD SupervisorsCommanders and Supervisors will ensure the upgrade or removal of Windows XP and Windows Server 2003 operating systems on unclassified, Secret level networks, and DoD Top Secret networks is accomplished. Obsolete operating systems such as Windows XP and Windows Server 2003 have fewer security features and more latent vulnerabilities that are no longer remediated by the vendor. a. Have all Windows XP operating systems been upgraded or removed from unclassified networks? - If yes, then Achieved. - If no, then Not Achieved. b. Have all Windows XP operating systems been upgraded or removed from Secret-level networks? - If yes, then Achieved.\- If no, then Not Achieved. c. Have all Windows XP operating systems been upgraded or removed from Top Secret collateral DoD information systems including DoD programs; special access programs; mission systems; and strategic, tactical, and RDT&E systems ? - If yes, then Achieved. - If no, then Not Achieved. d. Have all Windows Server 2003 operating systems been upgraded or removed from unclassified networks? - If yes, then Achieved. - If no, then Not Achieved. e. Have all Windows Server 2003 operating systems been upgraded or removed from Secretlevel networks? - If yes, then Achieved. - If no, then Not Achieved. f. Have all Windows Server 2003 operating systems been upgraded or removed from Top Secret collateral DoD information systems including DoD programs; special access programs; mission systems; and strategic, tactical, and RDT&E systems? - If yes, then Achieved. - If no, then Not AchievedServer ConfigurationEnsure the proper configuration of all physical and virtual servers per STIGs._24372694-e6fd-11e5-9dd9-bd9ce1bcaf9cTask 2.2DoD CommandersDoD SupervisorsCommanders and Supervisors will ensure the proper configuration of all physical and virtual servers per STIGs. Per DoDI 8510.01 (Reference (e)), servers "will be configured in accordance with applicable STIGs or SRGs where STIGs are not available." STIGs are published as tools to improve the security of DoD information systems and are hosted on DISA's Information Assurance Support Environment website (See: http://iase.disa.mil/stigs/Pages/index.aspx). STIGs and SRGs provide configuration for technologies such as operating systems, browsers, antivirus, web services, databases, Active Directory, and domain name services. The combination of applicable STIGs and SRGs will result in a secure configuration to prevent issues such as insider threats, data exfiltration, or advanced persistent threats. a. Have the required operating system and application STIGs been implemented and validated as current on all physical and virtual servers? - If yes, then Achieved. - If no, then Not Achieved. b. Has a risk assessment been conducted in accordance with DoDI 8510.01(Reference (e)) for all identified vulnerabilities associated with non-compliant physical and virtual server STIGs? - If yes, or if no operating system and application STIG vulnerabilities exist for all physical and virtual servers, then Achieved. - If no, then Not Achieved c. If the risk assessment of physical or virtual server vulnerabilities results in a "High" or "Very High" risk level, has compliance with the associated POA&M timelines approved by the cognizant Authorizing Official been achieved? - If compliance with the associated POA&M timelines approved by the cognizant AO has been achieved or if there are no "High" or "Very High" risk assessment results, then Achieved. - If compliance has not been achieved, then Not Achieved.HBSSEnsure HBSS is in compliance with the DoD CS direction._243727f2-e6fd-11e5-9dd9-bd9ce1bcaf9cTask 2.3DoD CommandersDoD SupervisorsCommanders and Supervisors will ensure HBSS is in compliance with the DoD CS direction. a. Is HBSS in compliance with the requirements identified in the DoD CIO, CS directions? - If yes, then Achieved. - If no, then Not Achieved.E-Mail LinksDisable HyperText Markup Language (HTML), Rich Text Format (RTF), and active links for Outlook email clients on unclassified and classified networks._2437295a-e6fd-11e5-9dd9-bd9ce1bcaf9cTask 2.4DoD CommandersDoD SupervisorsCommanders and Supervisors will ensure HyperText Markup Language (HTML), Rich Text Format (RTF), and active links are disabled for Outlook email clients on unclassified and classified networks. Common methods of exploitation in email are user interaction of clicking on malicious links or the auto-execution of malicious code on a target system. This threat exists on unclassified networks as well as classified networks primarily due to the existence of cross domain solutions. By configuring Outlook clients to disable active links and convert HTML or RTF to plain text, this attack vector can be mitigated. The Outlook 2010 (Reference (x)) and Outlook 2013 (Reference (w)) STIGs contain multiple rules for disabling this content, including STIG IDs DTOO425, DTOO214, DTOO215, DTOO314, and DTOO344. This action does not apply to web-based email. a. Are HTML, RTF, and active links disabled on Outlook email clients on unclassified networks? - If yes, then Achieved. - If no, then Not Achieved. b. Are HTML, RTF, and active links disabled on Outlook email clients on classified networks? - If yes, then Achieved. - If no, then Not Achieved.Mobile DevicesDisable HTML and RTF for government-provided email services in commercial mobile devices._24372af4-e6fd-11e5-9dd9-bd9ce1bcaf9cTask 2.5DoD CommandersDoD SupervisorsTask 2.5: Commanders and Supervisors will ensure HTML and RTF for government-provided email services are disabled for commercial mobile devices. Similar methods in desktop email exploitation are also applicable to mobile devices. STIG ID WIR-WMS-MEM-23 within the Mobile Email Management (MEM) Server STIG (Reference (y)) requires the use of "a MEM product that either blocks or converts all active content in email (HTML, RTF, etc.) to text before the email is forwarded to the mobile device." a. Are Mobile Email Managers configured to block or convert all active content in email (HTML, RTF, etc.) to text before the email is forwarded to all mobile devices? - If yes, then Achieved. - If no, then Not Achieved.IAVA PatchesEnsure all servers and network infrastructure devices are compliant with all current IAVA patch releases._24372c48-e6fd-11e5-9dd9-bd9ce1bcaf9cTask 2.6DoD CommandersDoD SupervisorsCommanders and Supervisors will ensure all servers and network infrastructure devices (e.g., IDS, routers, RAS, NAS, firewalls) are compliant with all current (i.e., those that have not been rescinded or superseded) IAVA patch releases. Inspections reflect an unacceptable number of unpatched vulnerabilities. The IAVM program is responsible for releasing IAVAs, ensuring an integrated capability to improve continually the Department's ability to identify and respond rapidly to vulnerabilities that adversely affect DoD servers and network infrastructure devices. a. Are all servers and network infrastructure devices (e.g., IDS, routers, RAS, NAS, firewalls, ) compliant with all current (i.e., those that have not been rescinded or superseded) IAVA patch releases? - If yes, then Achieved. - If no or if the status is unknown, then Not Achieved.Attack SurfaceReduce attack surface._24372dba-e6fd-11e5-9dd9-bd9ce1bcaf9cEffort 3The Department has become reliant on the connectivity between unclassified DoD information networks and the Internet as a principal mechanism for sharing information and executing enterprise-wide processes. As the DoD information network architectures have evolved, Internet-facing servers and web applications have been improperly placed in the DoDIN core. This architecture allows Internet-based users to traverse the DoDIN to connect to these Internet-facing servers. Because Internet users are allowed access to resources inside the DoDIN core, this architecture increases the attack surface of the DoDIN.Internet-Facing Assets, Servers & ApplicationsReview Internet-facing assets to ensure they are hosted in a DoD DMZ and disconnect all Internet-facing web servers and web applications without an operational requirement._24372f90-e6fd-11e5-9dd9-bd9ce1bcaf9cTask 3.1: DoD CommandersDoD SupervisorsCommanders and Supervisors will review all Internet-facing assets to ensure they are hosted in a DoD DMZ and disconnect all Internet-facing web servers and web applications without an operational requirement. Commanders and Supervisors will review and report Internet-facing assets at least quarterly; remove Internet-facing assets that no longer have a mission requirement from the network; and, for the remaining Internet-facing assets, verify that accessibility to/from the Internet is still required to support the mission. If Internet access is no longer required or the asset is removed from the network, Commanders and Supervisors will ensure the IP addresses are removed from the DISA IAP whitelist. Commanders and Supervisors will also ensure all operationally required Internet-facing assets are hosted, physically or logically, in a DoD DMZ. Per Orders & FRAGOs, Commanders have the option to host unrestricted (i.e., public) applications and data in authorized Cloud Service Providers (CSPs) in lieu of a DoD DMZ. These actions will reduce the attack surface available to the adversary for exploitation. a. Are any assets (e.g., web server, web application) Internet-facing? - If yes and they are in a DoD DMZ, then Achieved. - If yes and they are in the DoDIN core, then Not Achieved. - If none exist or if unrestricted data is in an authorized CSP, (Not Applicable). b. Has the operational requirement for all Internet-facing servers and web applications that have access to/from the Internet been validated within the last three months? - If yes, then Achieved. - If no, then Not Achieved. - If no Internet-facing servers and web applications exist, (Not Applicable). c. Have all Internet-facing web servers and web applications that do not have an operational requirement been disconnected from the network? - If yes, and they are removed from DISA IAP whitelist, then Achieved. - If no, then Not Achieved. - If no Internet-facing servers and web applications exist, (Not Applicable). d. Have all DoDIN web servers and web applications that do not need access to/from the Internet been removed from the DISA IAP whitelist? - If yes, then Achieved. - If no, then Not Achieved. - If no web servers and web applications exist, (Not Applicable). ITEM #1 OVERALL SCORING IN DRRS: - If all four are Achieved, then Achieved overall. - If a. is Not Achieved, then Not Achieved overall. - If a. is Achieved and any of b., c., or d. are Not Achieved, then Amber (Qualified Yes) overall.Active DirectoriesEnsure that no internal DoDIN Active Directory trusts any DoD DMZ or external Active Directory._2437310c-e6fd-11e5-9dd9-bd9ce1bcaf9cTask 3.2DoD CommandersDoD SupervisorsCommanders and Supervisors will ensure that no internal DoDIN Active Directory trusts any DoD DMZ or external Active Directory. Commanders and Supervisors will maintain visibility and report compliance of all trust relationships on the networks they control, manage, or for which they have administrator privileges. Poor management of trust relationships between authentication services remains a threat vector for the DoD’s information networks. Poorly configured trust relationships allow an adversary to move undetected throughout the information networks with escalated privileges. The most critical areas of concern are the trust relationships between a DoD DMZ and the DoDIN core. As noted in TASKORDs, once Internet-facing assets are moved into a DoD DMZ, the next step is to separate any associated applications and/or databases from these Internet-facing systems. Optimally, there are no trust relationships between a DoD DMZ and the DoDIN core; at a minimum, there are no bi-directional trust relationships. There will be no trust relationships between any part of the DoDIN and any external network. a. Do any Active Directory controllers inside DoD information networks (DoDIN core internal to the DoDIN IAPs) trust any Active Directories external to DoD information networks or in a DoD DMZ? - If no, then Achieved. - If yes, then Not Achieved.Commercial NIPRNet ConnectionsReport all commercially provided Internet connections to the NIPRNet._24373292-e6fd-11e5-9dd9-bd9ce1bcaf9cTask 3.3DoD CommandersDoD SupervisorsCommanders and Supervisors will report all commercially provided Internet connections to the NIPRNet. DoD information networks IAPs provide a standardized and centralized point of entry into the DoDIN core. Alternate entry points through commercially provided sources increase DoD’s attack surface and allow adversaries unprotected pathways into the DoDIN core. Optimally, all network traffic to/from the Internet will traverse a DoD IAP. At a minimum, any commercially provided Internet connectivity will have a current DoDIN waiver. Commanders and Supervisors will identify and report Internet traffic to/from the DoD information networks that does not traverse the IAPs. a. Are any Internet connections to DoD information networks commercially provided? - If none exist, then Achieved. - If yes, and a current DoD information networks waiver exists, then Amber (Qualified Yes). - If yes, and a current DoD information networks waiver does not exist, then Not Achieved.Network InfrastructureEnsure the physical security of their network infrastructure devices._243734fe-e6fd-11e5-9dd9-bd9ce1bcaf9cTask 3.4DoD CommandersDoD SupervisorsCommanders and Supervisors will ensure the physical security of their network infrastructure devices. Physical security of network devices is paramount to mission assurance. An adversary with physical access can reconfigure network devices or connect unauthorized devices in order to exploit DoD data and disrupt mission systems. Physical security of network infrastructure devices and physical port security of these devices reduce the attack surface. Commanders and Supervisors will ensure that all DoD-owned network infrastructure devices are physically secured in locked cabinets or in controlled access areas to prevent unauthorized access in accordance with the Network Policy STIG (Reference (z)). In addition, Commanders and Supervisors will ensure that only authorized devices can physically connect to DoD-owned network infrastructure. 802.1x authentication is the primary method of ensuring that only authorized devices can connect. Where 802.1x is unavailable, media access control (MAC) port security must be enabled. Per the Network Policy STIG (Reference (z)), physically secured is defined as: “All network infrastructure devices (i.e., IDS, routers, RAS, NAS, firewalls) must be located in a secure room with limited access. Move all critical communications into controlled access areas. Controlled access area in this case means controlled restriction to authorized site personnel, i.e., dedicated communications rooms or locked cabinets. This is an area afforded entry control at a security level commensurate with the operational requirement. This protection will be sufficient to protect the network from unauthorized personnel. The keys to the locked cabinets and dedicated communications rooms will be controlled and only provided to authorized network/network security individuals.” a. Have all DoD network infrastructure devices been physically secured to prevent unauthorized access? - If yes, then Achieved. - If no, then Not Achieved. Per the Network Layer 2 Switch STIG (Reference (aa)), the Network Infrastructure Router Layer 3 Switch STIG (Reference (ab)) and the Network Perimeter Router Layer 3 Switch STIG (Reference (ac)), a malicious user can access physical ports to connect an unauthorized device and inject or steal data from the network undetected without the use of 802.1x. Physical ports on network infrastructure devices (i.e., IDS, routers, RAS, NAS, firewalls) must be configured to use 802.1x authentication on host facing access switch ports. If they are unable to use 802.1x, then they must be configured to use MAC port security, which will shut down upon receiving a frame with a different Layer 2 source address than what has been configured or learned for port security. b. Has physical port security been enabled on network(s) (wired or wireless)? - If yes, then Achieved. - If no, then Not Achieved. ITEM #4 OVERALL SCORING IN DRRS: - If both 4.a. and 4.b. are Achieved, then Achieved overall. - If either 4.a. or 4.b. are Not Achieved, then Not Achieved overall.AlignmentMove to a more agile and defendable posture._2437365c-e6fd-11e5-9dd9-bd9ce1bcaf9cEffort 4Computer Network Defense Service ProvidersAlignment to Cybersecurity / Computer Network Defense Service Providers -- For the purposes of this Implementation Plan, the term cybersecurity / computer network defense service provider (CNDSP), refers to accredited Tier 2 CNDSP (listed at the following site: https://disa.deps.mil/ext/cop/FSO/cndsp_PM) unless otherwise specified. The current DoD information environment is a complex layering of multiple networks with overlapping, duplicative roles and responsibilities. As stated by the Commander, USCYBERCOM, the current network is "not defendable." For this reason, the Department must move to a more agile and defendable posture that will enable the Department's vision and strategy for U.S. military forces as they execute their assigned missions in all operational environments. The alignment of networks and information systems to CNDSPs as a centrally controlled authority is imperative to thwart cybersecurity threats and enable the provision of accurate, timely, and secure information to the warfighter. DoD Component internal or external CNDSPs are responsible for implementing cybersecurity services in accordance with the applicable DoD Component policy (for internal CNDSPs), or the CNDSP Service Agreement (for external CNDSPs). CNDSP Service Agreements may include memoranda of agreement (MOAs), Service Level Agreements (SLAs), or support agreements such as a DD Form 1144, "Support Agreement," in accordance with DoDI 4009.19 (Reference (b)). In addition, if the CNDSP elects to contract for any supporting elements of its cybersecurity services, the CNDSP must ensure that all applicable requirements are included in the contract(s). CNDSPs will be held accountable for incorporation of the requirements in Task 4.1.a into their Component level policies, CNDSP Service Agreements, and supporting contracts, as well as the cyber incident response plan requirements in Task 4.2. Lastly, CNDSPs must share lessons learned in accordance with CJCSI 6510.01F (Reference (m)) to facilitate better cyberspace defense. Therefore, CNDSPs will report lessons learned into the Joint Lessons Learned Information System (JLLIS) identified in CJCSI 3150.25E (Reference (l)). USCYBERCOM will periodically check for CNDSP updated information into JLLIS and this requirement will be incorporated into internal and external validation procedures.CNDSPsEnsure alignment to a Computer Network Defense Service Providers (CNDSP)._243737ba-e6fd-11e5-9dd9-bd9ce1bcaf9cTask 4.1DoDCommandersDoD SupervisorsComputer Network Defense Service ProvidersCommanders and Supervisors will ensure alignment to a CNDSP. Per DoDI O-8530.2 (Reference (g)), "all information systems and computer networks must enter into a service relationship with a [computer network defense service] provider." Service relationships require subscribers to contribute to computer network situational awareness, including information such as asset inventory and changes in configuration (DoDI O-8530.2 (Reference (g)); updates to ports, protocols, and services (PPS) registration (DoDI 8551.01 (Reference (h)); and other data as identified in the governing CNDSP component-level policies and Service Agreements. Alignment to a CNDSP is defined as follows:Policy & Service AgreementsEnsure a Component-established policy, or signed CNDSP Service Agreement, has been established and executed._2437394a-e6fd-11e5-9dd9-bd9ce1bcaf9c4.1.aIn addition to any other requirements, the policy or Service Agreement (and any supporting contracts) will include the following requirements: * Maintain and provide at least every six months, or upon CNDSP request, accurate configuration management (CM) documentation. At a minimum, documentation will include network diagrams, software and hardware inventories, and any PPS listing changes in the PPS Management Registry. * Notify the CNDSP and provide at least annually any CM changes involving connectivity, including location, sensor name, CCSDs, bandwidth, IP address space, backend connections, and any changes that could affect NETOPS. * Update POC information every six months, including leadership/management, all POCs involved in cyber incident handling during and after normal work hours, Senior Security Officer (SSO), policy POC lists, and other POCs as requested. * Provide HBSS data feeds as agreed-upon between the subscriber and the CNDSP. i. If implemented, make HBSS data feeds available to the CNDSP. * Specify and document agreed-upon security log data and an agreed-upon interval to facilitate network defense and incident response. i. Is there a Component-established policy for, or signed Service Agreement with, a CNDSP that meets the identified requirements? - If yes, then Achieved. - If no, then Not Achieved.Diagrams, Inventories, Registration & Security LogsProvide the CNDSP with network diagrams, software and hardware inventories, network PPS registration, updated POC information, HBSS data feeds (if implemented), and security log data as agreed to in the Agreement or Component-established policy._24373abc-e6fd-11e5-9dd9-bd9ce1bcaf9c4.1.bi. Have the network diagrams and network PPS listings been updated within six months? - If yes to both, then Achieved. - If no to either or both, then Not Achieved. ii. Has the POC information defined in Agreement or Component-established policy with the CNDSP been updated within six months? - If yes, then Achieved. - If no, then Not Achieved. iii. Are HBSS feeds, if implemented, provided to the CNDSP? - If implementation of HBSS is required and the feeds have been made available, then Achieved. - If HBSS is implemented and operating in a Disconnected, Intermittent, or Limitedbandwidth (DIL) environment that limits the ability to transmit the feeds, then Amber (Qualified Yes). - If implementation of HBSS is required and the feeds have not been made available, then Not Achieved. - If implementation of HBSS is not required, then Gray (Not Applicable). iv. Are security logs provided in accordance with the Agreement or Componentestablished policy with the CNDSP? - If yes, then Achieved. - If no, then Not Achieved.Incident Response PlansProperly exercise and document cyber incident response plan(s)._24373c2e-e6fd-11e5-9dd9-bd9ce1bcaf9cTask 4.2DoD CommandersDoD SupervisorsCommanders and Supervisors with CNDSP responsibility will ensure the cyber incident response plan(s) are properly exercised and documented. CJCSM 6510.01B (Reference (j)) requires DoD Components with CNDSP responsibilities to maintain and update a cyber incident response plan to respond to potential malicious activity. Recent events have revealed some CNDSPs do not have updated subscriber documentation and are not familiar with executing the processes outlined in their response plans. To address this shortfall, USCYBERCOM will establish via an order a requirement for CNDSPs to exercise or execute (real-world) the cyber incident response plans with at least one subscriber at least every six months, document the results, and update the response plan with the subscriber as required. Every six months, CNDSPs will:Validation ExercisesConduct at least one exercise of a DoD Component or a subscriber organization cyber incident response plan with key stakeholders to validate the processes, subscriber documentation, contact information, and communication mechanisms included in the response plan._24373dd2-e6fd-11e5-9dd9-bd9ce1bcaf9c4.2.a* Acceptable exercise types include, in preferential order: a. Red team or threat emulation engagements, if and only if such activity was initiated by the CNDSP; or b. a table-top exercise; or c. a real-world event that mirrors the above requirements. * Key stakeholders include, but are not limited to, the USCYBERCOM Joint Operations Center, the associated service cyber component or JFHQ-DoDIN, and at least one subscriber. i. Has at least one acceptable exercise been executed with key stakeholders within the last six months? - If yes, then Achieved. - If no, then Not Achieved.RecordsDocument and retain on file the results of the exercise or real-world event for a minimum of three years._24373f4e-e6fd-11e5-9dd9-bd9ce1bcaf9c4.2.bi. Has the documentation of the results of the exercise or real-world event been retained on file for a minimum of three years? - If yes, then Achieved. - If no, then Not Achieved.UpdatesUpdate the cyber incident response plan to reflect revised processes based on the exercises and/or real world events._243740d4-e6fd-11e5-9dd9-bd9ce1bcaf9c4.2.c* If there are no revisions, the date of validation will be included in the response plan. USCYBERCOM will spot check these records at will, and the CNDSP certifier will inspect these records as part of the CNDSP reauthorization process. There will be no more than six months between each response plan exercise/real-world event. i. Has the cyber incident response plan been updated to reflect revised processes based on the exercises and/or real world events? - If yes, then Achieved. - If no, then Not Achieved.2016-02-292016-03-10http://dodcio.defense.gov/Portals/0/Documents/Cyber/CyberDis-ImpPlan.pdfOwenAmburOwen.Ambur@verizon.net