System Concept of Operations (CONOPS) for the Automated Computer Network Defence (ARMOUR) Technology Demonstration (TD) Contract
Author: D. Tremblay General Dynamics
Prepared By: General Dynamics Mission Systems–Canada Land and Joint Solutions 1020–68th Avenue N.E. Calgary, Alberta T2E 8P2
Contractor's Document Number: 740928 Contractor’s date of publication: 21 April 2017 CDRL: SD0049 PWGSC Contract Number: W7717-115274/001/SV Contract Project Manager: Darcy Simmelink Technical Authority: Natalie Nakhla
Disclaimer: The scientific or technical validity of this Contract Report is entirely the responsibility of the Contractor and the contents do not necessarily have the approval or endorsement of the Department of National Defence of Canada.
Contract Report DRDC-RDDC-2017-C169 July 2017
© Her Majesty the Queen in Right of Canada, as represented by the Minister of National Defence, 2017. © Sa Majesté la Reine (en droit du Canada), telle que représentée par le ministre de la Défense nationale, 2017.
740928F
System Concept of Operations (CONOPS) for the
Automated Computer Network Defence (ARMOUR) Technology Demonstration ((TD) Contract
Contract No. W7714-115274/001/SV CDRL SD009
This document was prepared by General Dynamiccs Mission Systems – Canada under Public Works and Government Service Canada Contract No. W7714- 115274/001/SV. Use and dissemination of the information herein shall be in accordance with the Terms and Conditions Contracct No. W7714-115274/001/SV.
© HER MAJESTY THE QUEEN IN RIGHT OF CANADA (2017)
Prepared For:
Defence Research & Development Caanada (DRDC) - Ottawa 3701 Carling Avenue Ottawa, Ontario K1A 0Z4
Prepared By:
General Dynamics Mission Systems – Canada Land and Joint Soluttions 1020-68th Avenue N.E. Calgary, Alberta T2E 8P2
21 April 2017
Unclassified A 740928
GENERAL DYNAMICS MISSION SYSTEMS – CANADA LAND AND JOINT SOLUTIONS
ARMOUR Technology Demonstration Contract
AUTHORIZATION AND APPROVAL
Electronically Approved by DM Workflow Form No.: DM1502096
Approver Role Approver Name Approval Date Author D. Tremblay 21 April 2017
Lead System of Systems Architect D. Tremblay 21 April 2017 Quality Specialist, Quality Management J. Ko 21 April 2017 Commercial Officer H. Larmer 21 April 2017
Use or disclosure of this data is subject to the restriction on the title page of this document.
W7714-115274/001/SV ARMOUR TD System CONOPS Unclassified Version F 21 April 2017 Unclassified B 740928
Use or disclosure of this data is subject to the restriction on the title page of this document.
W7714-115274/001/SV ARMOUR TD System CONOPS Unclassified Version F 21 April 2017 Unclassified C 740928
REVISION SHEET
DOCUMENT NO. VERSION DATE COMMENTS 740928 – 26 September 2013 Initial release.
740928 A 12 February 2014 Updated to address DRDC Stakeholder Feedback. Revision bars (|) appear in the right margin to indicate changes from the previous version.
740928 B 11 March 2014 Addresses comments from DRDC for formal acceptance of the Phase I artifact. Revision bars (|) appear in the right margin to indicate changes from the previous version.
740928 C 15 August 2014 This document has been updated for Phase 3. Revision bars (|) appear in the right margin to indicate changes from the previous version.
740928 D 25 August 2015 This document has been updated to reflect a DREnet classification of Protected A and to update company name change. Revision bars (|) appear in the right margin to indicate changes from the previous version.
740928 E 06 October 2015 Appendix A has been removed. Revision bars (|) appear in the right margin to indicate changes from the previous version.
740928 F 21 April 2017 Final Revision
Use or disclosure of this data is subject to the restriction on the title page of this document.
W7714-115274/001/SV ARMOUR TD System CONOPS Unclassified Version F 21 April 2017 Unclassified D 740928
This page is left blank intentionally.
Use or disclosure of this data is subject to the restriction on the title page of this document.
W7714-115274/001/SV ARMOUR TD System CONOPS Unclassified Version F 21 April 2017 Unclassified i 740928
TABLE OF CONTENTS
1. INTRODUCTION...... 1 1.1 Scope ...... 1 1.2 Background ...... 1 1.2.1 Identified Capability Deficiencies ...... 1 1.2.2 System Relationship to Capability Deficiencies ...... 2 1.3 Stakeholder Interaction ...... 4 1.4 Document Overview ...... 4
2. APPLICABLE DOCUMENTS ...... 6 2.1 Government Documents ...... 6 2.2 Non-Government Documents ...... 6
3. SYSTEM OVERVIEW ...... 7 3.1 Operational Environment ...... 8 3.2 Operational Scenarios ...... 8 3.2.1 Proactive DREnet Operational Scenario ...... 9 3.2.2 Reactive DREnet Operational Scenario ...... 10 3.3 External Interfaces ...... 11
4. OPERATIONAL CONCEPT ...... 12 4.1 Operational Overview ...... 12 4.1.1 Proactive Cycle ...... 13 4.1.2 Reactive Cycle ...... 14 4.2 Roles and Responsibilities ...... 15 4.3 Operational Model ...... 15 4.3.1 Observe Phase – Collect and Fuse Data ...... 16 4.3.1.1 Proactive ...... 17 4.3.1.2 Reactive...... 17 4.3.2 Orient Phase – Predict Attack Paths ...... 17 4.3.2.1 Proactive ...... 18 4.3.2.2 Reactive...... 18 4.3.3 Decide Phase – Decide Courses of Action ...... 18 4.3.3.1 Proactive ...... 19 4.3.3.2 Reactive...... 19 Use or disclosure of this data is subject to the restriction on the title page of this document.
W7714-115274/001/SV ARMOUR TD System CONOPS Unclassified Version F 21 April 2017 Unclassified ii 740928
4.3.4 Act Phase – Implement Courses of Action ...... 19 4.3.4.1 Proactive ...... 20 4.3.4.2 Reactive...... 20 4.4 ARMOUR Subsystems ...... 20 4.4.1 Integration Framework ...... 20 4.4.2 Data Source Connectors ...... 22 4.4.3 Database ...... 22 4.4.4 Data Presentation ...... 22 4.4.4.1 Object Representation ...... 23 4.4.4.2 Graphical User Interfaces ...... 25 4.4.4.2.1 Infrastructure Group ...... 28 4.4.4.2.1.1 Topology Widget ...... 29 4.4.4.2.1.2 Inventory and Host Details Widget ...... 29 4.4.4.2.1.3 Host History Widget ...... 30 4.4.4.2.1.4 Reachability Widget ...... 30 4.4.4.2.1.5 Incident, Incident Details and Alert Toolbar ...... 31 4.4.4.2.1.6 Vulnerability List and Detail Widget ...... 32 4.4.4.2.2 Operational Group ...... 32 4.4.4.2.3 Speculative Analysis Group ...... 33 4.4.4.2.4 Attack Path Group...... 34 4.4.4.2.5 COA Group ...... 36 4.4.4.2.6 Incident Analysis Group ...... 37 4.4.4.2.7 Support Tools Group ...... 38 4.4.5 Computational Services ...... 38 4.4.5.1 Data Normalization ...... 38 4.4.5.2 Cross Source Correlation ...... 38 4.4.5.3 Reachability Analyzer ...... 39 4.4.5.4 Common Infrastructure Abstraction ...... 40 4.4.5.5 Operations and Infrastructure Analyzer ...... 41 4.4.5.6 Attack Graph Generator ...... 41 4.4.5.6.1 MulVAL ...... 42 4.4.5.7 Attack Graph Analyzer ...... 42 4.4.5.7.1 AssetRank Algorithm ...... 42 4.4.5.8 Incident Analyzer ...... 42 4.4.5.9 Course of Action Analyzer ...... 43
Use or disclosure of this data is subject to the restriction on the title page of this document.
W7714-115274/001/SV ARMOUR TD System CONOPS Unclassified Version F 21 April 2017 Unclassified iii 740928
4.4.5.9.1 Course of Action Decision Support (COADS) ...... 44 4.4.5.10 Semi-Automated Response ...... 44 4.4.5.11 Automated Response ...... 44 4.4.6 Effector Connector and Effectors ...... 44
5. SYSTEM SECURITY, SECURITY PLAN AND SECURITY CONOPS ...... 46 5.1 Overview ...... 46 5.2 Security Approach ...... 46 5.3 Security Categorization and Domain Control Profile ...... 46 5.4 Security Control Profile ...... 46 5.5 Security Control Profile Implementation ...... 46 5.6 Security Authorization and Assessment Schedule ...... 47 5.7 Security Authorization Boundary ...... 47 5.8 Other Security Plan and CONOP -Related Information ...... 47
6. MAINTENANCE AND SUPPORT ...... 48
7. TEST AND DEMONSTRATION ...... 49
8. NOTES ...... 50 8.1 Abbreviations ...... 50
FIGURES
FIGURE 1. ARMOUR System Environment ...... 7 FIGURE 2. One-way Transfer Flow Control ...... 11 FIGURE 3. OODA Loop Operational Model [Ref 2] ...... 12 FIGURE 4. ARMOUR High Level Concept of Operations ...... 16 FIGURE 5. Integration Framework in Reference to ARMOUR ...... 21 FIGURE 6. Host Type Icons ...... 23 FIGURE 7. Security Status Indicators ...... 24 FIGURE 8. Security Status Indicators ...... 24 FIGURE 9. Presentation Groups within OODA Loop ...... 28 FIGURE 10. Topology Widget ...... 29 FIGURE 11. Inventory Widget ...... 30 FIGURE 12. Host History Widget ...... 30 FIGURE 13. Reachability Widget ...... 31
Use or disclosure of this data is subject to the restriction on the title page of this document.
W7714-115274/001/SV ARMOUR TD System CONOPS Unclassified Version F 21 April 2017 Unclassified iv 740928
FIGURE 14. Incident Summary Widget ...... 31 FIGURE 15. Incident Details Widget ...... 32 FIGURE 16. Alert Toolbar ...... 32 FIGURE 17. Operational Dependency Widget ...... 33 FIGURE 18. Attack Graph Generation Widget ...... 35 FIGURE 19. Attack Path Widget ...... 35 FIGURE 20. Sample Reachability Graph ...... 40 FIGURE 21. COA Analyzer Block Diagram ...... 43
TABLES
Table 1. Assignment of Widgets to User Roles ...... 26
Use or disclosure of this data is subject to the restriction on the title page of this document.
W7714-115274/001/SV ARMOUR TD System CONOPS Unclassified Version F 21 April 2017 Unclassified 1 740928
1. INTRODUCTION
1.1 Scope This System Concept of Operations (CONOPS) provides a system description for the Automated Computer Network Defence (ARMOUR) Technology Demonstration (TD). The intent is to provide a high-level description of the ARMOUR solution and how it relates to operational concepts that make up Computer Network Defence (CND) as well as document the environment in which the solution will operate. The System CONOPS includes the data and information as required by the ARMOUR Statement of Work (SOW) Data Item Description (DID) SD 009 System Concept of Operations.
1.2 Background “Defence Research and Development Canada (DRDC), has a requirement to design, build and test a system to meet the ARMOUR TD project objectives and to demonstrate the system on an operational subset of the DRDC Defence Research Establishment Network (DREnet).” [Ref 1] “All modern militaries are heavily reliant upon computer networks at every stage of their missions. The network plays a crucial role in all phases, from strategic intelligence gathering and dissemination, to operational planning, logistics and command, and finally, to time-critical tactical sensing and decision making in the field. Reliance on network enabled capabilities has increased the importance of networks as part of critical service delivery. Supporting processes and technology in the area of automated CND are required to maintain the security, including confidentiality, integrity and availability, of these services.” [Ref 1]
1.2.1 Identified Capability Deficiencies Information Systems (IS) are, more than ever, expanding in complexity, capability and reachability. Gone are the days where an organization can deploy an IS as a stand-alone network, operating in an isolated environment and providing stale information to non-connected stakeholders through other means. The availability of real-time information to all stakeholders is paramount to businesses, government and military in that having information in hand immediately provides a tactical edge. For example, military tactical networks (such as the Land Command Support System (LCSS)) rely on the near real-time availability of information shared amongst the organization. Tactical networks deployed in theatre are required to span several physical locations (Brigades, Battle Groups, Forward Operating Bases, etc.) while maintaining connectivity with each other and with the Network Operations Centre (typically located on home soil). The continuous availability of information across the network provides the commanders with the ability to make informed and time critical decisions. Today’s IS deployments are complex and continuously evolving to meet the business needs. This results in an ever evolving and growing topology with many technologies lending to the functionality of the IS. With this evolution comes larger, fast growing networks with many devices operating under various configurations that provide the desired capability of real-time
Use or disclosure of this data is subject to the restriction on the title page of this document.
W7714-115274/001/SV ARMOUR TD System CONOPS Unclassified Version F 21 April 2017 Unclassified 2 740928
information; this results in a greater attack surface and a greater challenge to protect, manage and monitor the information and assets residing on the network. Adding to the severity of the problem is that sophisticated, targeted attacks are significantly increasing day-by-day that intend to disrupt business through the exposure of confidential information, falsification of the integrity of the data and denial of availability of essential services. While standardized guidelines for securing ISs are required to be implemented prior to operation in order to provide a level of assurance that the IS is protected and secure, there is no such thing as an impenetrable IS. CND is evolving and the market contains many silo defence tools that perform specific functions. For example, Intrusion Detection Systems (IDS) monitor networks for malicious activities or policy violations and report events to system managers; antivirus applications quarantine and remove signature-based malware from host machines; and Security Information and Event Management (SIEM) products provide analysis of security alerts from network and hardware applications. These types of products serve their purpose, however, they are often reactive in nature and are analyzed in isolation without the global context of other vulnerabilities and operational priorities when determining the Course of Action (COA). The challenge is to understand the collection of attack options available for exposure to the attacker and to mitigate the risks of being exposed prior to an actual event with the understanding that maintaining mission objectives is of paramount importance. In the event of a successful attack, the challenge is to react to the attack as quickly as possible, remove/contain the threat through vulnerability remediation, maintain the global context of the network and ensure this attack does not happen again. As networks become more complex and increasingly integrated to the operational tempo, it is difficult to discern which COA will best mitigate the attack with minimum impact on the users. The challenge then, with selecting the correct COA, is not only ensuring that attacks are mitigated most effectively but that it is done in the most time efficient manner while maintaining system Confidentiality, Integrity and Availability.
1.2.2 System Relationship to Capability Deficiencies The ARMOUR TD project has been created to develop and deploy a CND solution that addresses the capability deficiencies described above. ARMOUR integrates individual CND solutions that gather and analyze infrastructure, non-infrastructure, security and operational data regarding the network’s current security posture and automate the resolution of identified vulnerabilities/risks. Where existing capabilities are insufficient or where capabilities are entirely non-existent, ARMOUR initiates new or leverage existing Research and Development (R&D) efforts to develop a solution that meets the business objectives. ARMOUR provides operators with the ability to view the network topology and security posture information about each asset in various forms (graphical, tabular, etc.). Using continuously updated vulnerability definition feeds, the data gathered about the network interconnections, operational/asset priority information and the host configurations, ARMOUR analyzes the capability of an attacker to expose data or assets from an initial exposed asset with the global Use or disclosure of this data is subject to the restriction on the title page of this document.
W7714-115274/001/SV ARMOUR TD System CONOPS Unclassified Version F 21 April 2017 Unclassified 3 740928
context of their vulnerabilities and other operational priorities accounted for. Based off sophisticated analysis algorithms, ARMOUR generates a graphical representation of the attack paths that an attacker could exploit to gain access to information or assets on the network in both the proactive (no observed event to date) and reactive (event has occurred) scenarios. With operational data that identifies a host, service or set of hosts/services as being critical to operations, ARMOUR can support mission survivability through prioritization of vulnerability remediation in relation to the survivability of these assets. A COA template and effector registry library, populated both pre-deployment and maintained during production, include a number of resolutions to various attacks, with their associated reactive and proactive costs. A system-wide loss-cost threshold value is used to determine whether an automated or semi-automated (requiring operator intervention) response is needed. For each attack (real or simulated), the COA templates defined in the library are assessed for their suitability to remedy the threat generated by the attack graph analysis (attack vector). ARMOUR presents the operator with a list of actions that can be taken to resolve the attack or mitigate the identified risk prioritized by the improved security posture and cost. The COAs can be either effected automatically if the impact is below the system-wide loss-cost threshold or semi-automated if operator intervention is required. “The scope of recommended Course-Of-Action (COA) mitigations are intended to place greater emphasis on tactical reconfiguration of assets with reduced emphasis on strategic (e.g., architectural) change.” [Ref 2] Once a COA has been selected (automated or semi-automated) for implementation, the activities defined in the COA are executed through effectors that have the ability to implement the changes to the target system. COAs can include patch updates, firewall policy changes, route modifications among many others. “This project intends to demonstrate a solution which, after productization, may be installed to secure networks throughout DND, those of other government departments within the Government of Canada (GC) as well as those of its allies.” [Ref 2] The objectives of the ARMOUR TD project are to: a. “Demonstrate an automated CND solution that will: (1) Compute defensive courses of action in response to identified vulnerabilities and attacks; (2) Prioritize defensive courses of action to minimize impact to operations and cost; (3) Proactively and reactively respond by effectuating courses of action in a semi- automated (operator intervention) or fully automated (autonomous) manner; and (4) Compute system and security metrics over the enterprise wide system to enable comparison of previous and potential network states. b. Provide a framework that will influence external CND programs and easily exploit innovations by providing a system for ongoing R&D that is shared with allies, research institutes, academia and commercial industry.” [Ref 1]
Use or disclosure of this data is subject to the restriction on the title page of this document.
W7714-115274/001/SV ARMOUR TD System CONOPS Unclassified Version F 21 April 2017 Unclassified 4 740928
“The ARMOUR TD project will follow a phased incremental development and demonstration approach. During each phase GDMS-C will develop and demonstrate the solution or part of the solution using scenarios based on stakeholder input and requirements. Stakeholder reactions to, and lessons learned from, the demonstration of each phase will be used as input to determine the objectives and required improvements for the next phase.” [Ref 1] The ARMOUR TD project will be conducted in six phases as follows: a. Phase 1: Analysis and Design (demonstration not required); b. Phase 2: Integration Framework (IF) and Graphical User Interface (GUI) capability development and demonstration; c. Phase 3: Proactive Observe and Orient capability development and demonstration; d. Phase 4: Proactive Decide and Act capability development and demonstration; e. Phase 5: Reactive response capability development and demonstration; and f. Phase 6: Final deliverables and project close-out (demonstration not required). General Dynamics Mission Systems – Canada (GDMS-C), along with DRDC and strategic partners defined in section 4.2.3 of the ARMOUR TD Project Management Plan (GDMS-C document No. 995012) will develop, integrate and deliver a solution to address the problem space defined by DRDC.
1.3 Stakeholder Interaction In order to ensure that the ARMOUR solution addresses the operational and DND Information Technology (IT) environment, interaction with stakeholders will occur at various stages throughout the project. The focus of this interaction is to ensure that the solution as provided best represents the operational needs and requirements of the operational community. Details of the exact nature of this interaction can be found in subsection 3.2 of the ARMOUR TD CONOPS document. For this release of the ARMOUR TD CONOPS, the stakeholder feedback collected to date has not resulted in any major changes to the ARMOUR design or its considerations.
1.4 Document Overview The ARMOUR TD CONOPS comprises the following sections: a. Section 1, “Introduction”, provides the purpose of this document and the context which it covers. It also provides a high-level overview of the design goals. b. Section 2, “Applicable Documents”, lists all documents referenced within. c. Section 3, “System Overview”, provides a high-level description of the ARMOUR TD solution.
Use or disclosure of this data is subject to the restriction on the title page of this document.
W7714-115274/001/SV ARMOUR TD System CONOPS Unclassified Version F 21 April 2017 Unclassified 5 740928
d. Section 4, “Operational Concept”, documents the operational concepts as they apply to the ARMOUR TD project. Focus is on the implementation of the Observe, Orient, Decide and Act (OODA) loop model and the proactive and reactive capabilities as they apply to each phase. e. Section 5, “Operational Environment”, this section documents the environment within which the solution will operate. f. Section 6, “Maintenance and Support”, provides an overview of the requirements and actions necessary for maintenance and support of the solution. g. Section 7, “Test and Demonstration”, documents the test philosophy employed to provide evidence supporting the successful implementation of the system requirements and discusses the four demonstrations planned throughout the design and implementation life-cycle. h. Section 8, “Notes”, provides a list of the abbreviations used within the document.
Use or disclosure of this data is subject to the restriction on the title page of this document.
W7714-115274/001/SV ARMOUR TD System CONOPS Unclassified Version F 21 April 2017 Unclassified 6 740928
2. APPLICABLE DOCUMENTS The following documents were used in the development of this document.
2.1 Government Documents The following documents were referenced in the development of this document and are applicable to the extent specified herein. [Ref 1] ARMOUR TDP Contract Statement of Work for the ARMOUR TD, 03 W7714-115274-SV Annex A May 2013, v2.1 [Ref 2] ARMOUR TDP Contract System Technical Specification for the W7714-115274-SV Annex B ARMOUR TD, 23 May 2013, v2.1
2.2 Non-Government Documents The following documents were referenced in the development of this document and are applicable to the extent specified herein. NOTE: Some of the documents listed below may require scheduled updates or revisions. 740930-C ARMOUR TD System Requirement Specification Document 740931-B ARMOUR TD Test Design and Environment Document 741349-E ARMOUR TD Detailed Design Document 742096-A ARMOUR TD Security Assessment and Authorization Report 742605-A TD ARMOUR Security Categorization Report 742152 ARMOUR TD Security Report 995012-C ARMOUR TD Project Management Plan 995015-F ARMOUR TD Architectural Design Document (ADD)
Use or disclosure of this data is subject to the restriction on the title page of this document.
W7714-115274/001/SV ARMOUR TD System CONOPS Unclassified Version F 21 April 2017 Unclassified 7 740928
3. SYSTEM OVERVIEW The ARMOUR TD solution is a combination of commercial, open source, developmental and experimental software tools that integrate existing sensors and effectors within the DRDC DREnet operational network. The ARMOUR TD project approach is based on the use of Commercial Off-The-Shelf (COTS) and Open Source Software (OSS), where available, with an effort to mature and deliver R&D products where mature products do not exist. The ARMOUR System provides an integrated environment of leading-edge network cyber security tools to provide a solution that accelerates DND’s ability to protect and defend its networks, as shown in Figure 1.
FIGURE 1. ARMOUR System Environment While the focus of the tools that comprise the solution is to accelerate the operator’s abilities to defend the network environment, the means to accomplish this is by supporting the OODA loop functions as applied to CND. In addition to accelerating the OODA loop, the ARMOUR TD also explores the challenge of the CND related “big/fast data” problem. As the networks being defined become more complex and increasingly integrated to the operational tempo it is difficult to discern which COA will best mitigate the attack with minimum impact on the users. In addition to increases in complexity is the intensity and tempo of attacks. Hostile agents are using ever-improving tools that enable attack vectors to multiply exponentially. The challenge then with selecting the correct COA is not only ensuring that attacks are mitigated most effectively but that it is done in the most time effective manner. The ARMOUR TD addresses these challenges by establishing a modular integration framework that enables modules to be exercised and optimized to best meet the specific needs of a particular network environment.
Use or disclosure of this data is subject to the restriction on the title page of this document.
W7714-115274/001/SV ARMOUR TD System CONOPS Unclassified Version F 21 April 2017 Unclassified 8 740928
To the maximum extent possible, the ARMOUR solution uses a modular design approach to integrate available technologies (e.g. COTS or OSS products). For more detailed information on the ARMOUR System Architecture refer to the ARMOUR Architectural Design Document (ADD) (GDMS-C document No. 995015).
3.1 Operational Environment The ARMOUR TD solution collects and stores a variety of user and system data as collected from DRDC DREnet and will be at the PROTECTED A level. This includes network management data, as well as a variety of network security data. The processing, and subsequent derivation, of information by the ARMOUR TD will be at the PROTECTED B level. As such the data sensitivity for the overall ARMOUR TD system will be PROTECTED B System High.
3.2 Operational Scenarios The intent of the ARMOUR TD design is to provide a rapidly deployable network monitoring solution capable of protecting the host network from malicious and accidental threats from internal and external entities. DND and other Government of Canada organizations employ networks of varying degrees from enterprise wide infrastructure networks (i.e., Defence Wide Area Network (DWAN)) to Classified SECRET networks which can benefit from the proactive and reactive safeguards provided by ARMOUR. For the scope of the ARMOUR TD project, the Operational Environment is the DREnet. To ensure that the ARMOUR solution best aligns to the operational needs of DND, a stakeholder community has been identified that represents various elements of the DND operational and support community. Interactions with these stakeholders have occured throughout the ARMOUR TD project to provide insight into various operational scenarios and how they can be supported by the ARMOUR solution. The contractual stakeholder community is defined as follows: a. Director General Cyber (DG Cyber); b. Canadian Forces Information Operations Group (CFIOG); c. Canadian Forces Network Operations Centre (CFNOC); d. Network Command and Control Integrated Situation Awareness Capability (NetC2 ISAC) Project; e. Director Information Management Engineering and Integration (DIMEI); f. Director Information Management Security (DIM Secur); g. Director General Information Management Technologies, and Strategic Planning (DGIMTSP); h. Director Enterprise Architecture (DEA); and
Use or disclosure of this data is subject to the restriction on the title page of this document.
W7714-115274/001/SV ARMOUR TD System CONOPS Unclassified Version F 21 April 2017 Unclassified 9 740928
i. Defence Research and Development Knowledge Information Management (DRDKIM). Other groups within DND may be consulted as part of the stakeholder interaction activities as they may be involved in activities similar to that expected from the ARMOUR TD project (e.g., Director Land Command Systems Program Management (DLCSPM)). Interactions with the stakeholders occur at various stages throughout the project to ensure that the correct input is obtained in a timely manner. As the focus of these interactions is to ensure that capabilities realized by the ARMOUR system align with their operational needs, the following information is expected to be collected: a. A more profound understanding of the operation of each stakeholder organization including their vision, mission role within DND, and their interaction with other DND organizations and environments; b. Input directly from the stakeholders on CND areas of concern and “pain points” requiring a solution; c. An understanding of the stakeholder’s evolving operational challenges; d. An alignment and validation of the ARMOUR system requirements to support these challenges; and e. An understanding of the current stakeholder technologies and tools. Stakeholder interactions include all forms of communications (emails, phone calls, etc.) including technology demonstrations (both formal and informal). Stakeholder interactions were conducted as per references [Ref 1] and [Ref 2].
3.2.1 Proactive DREnet Operational Scenario As part of a healthy environment, continuously evaluating the security posture of both static and dynamic environments under normal operating conditions is important to maintain a secure operational environment. DREnet is the research network and, as such, is subject to frequent change. This is not dissimilar to any other network, be it Tactical, Strategic or Enterprise IT. For example, extending DREnet for a new research project could constitute several changes to the network such as: 1. Addition of new host(s); 2. Addition of new network device (switch, router, etc.); 3. Addition of new security device (firewall, gateway, etc.); 4. Modification to existing network device; and 5. Modification to existing security device. The impact of these changes is not always fully understood as the global context is often overlooked when deploying an isolated change. With ARMOUR, the impact to the global context of the network change can be simulated with the proactive capabilities. For example, the inclusion of a new route between two previously isolated subnets may seem benign at first glance; however, when simulated in ARMOUR, the system determines that based on current Use or disclosure of this data is subject to the restriction on the title page of this document.
W7714-115274/001/SV ARMOUR TD System CONOPS Unclassified Version F 21 April 2017 Unclassified 10 740928
vulnerabilities and the new route, additional attack vectors are available to would be attackers that expose high priority operational assets. Based on the analysis, the COAs in the library would be evaluated and a COA list would be generated and provided to the operator performing the simulation with a set of actions along with the risk mitigation results. This might represent a scenario where the IS owner decides that an alternative deployment of the new asset is required or the risk is sufficiently low. At the very least, the IS owner is aware of the implications of the introduction of a new asset and can react accordingly. Without ARMOUR, it is likely that this global impact would have been missed. Another proactive scenario could be the case where a new host computer is added to the network. In this example, the host is added to a network where hardening policies exist that govern that all USB ports are disabled for mass storage devices. In this example, the host is added to the network without implementing the port control hardening setting. Once added to the network, ARMOUR scans the new host and determines that the host configuration does not enforce this setting. Again, in this situation the COAs in the library would be evaluated and a COA list would be generated and provided to the operator with a set of actions along with the risk mitigation results. Here, the COA to mitigate the vulnerability on the new host could be effected automatically thus reducing the threat of malware infection from an unknown Universal Serial Bus (USB) key or the threat of Data Exfiltration by malicious insider.
3.2.2 Reactive DREnet Operational Scenario No IS is fully secure and, as such, susceptibility to exploitation is a possibility. In the event of a malicious attack on an IS, the ability to react to and mitigate the risk is of paramount importance. Understanding the effects of the risk mitigation (be it patch update, removal of the asset from the network, or in the extreme case of accepting the risk of continuing to operate under the exploited condition) in the global context provides the IS owner with the knowledge and comfort that the mitigation strategy is well understood and the threat is contained. When an asset has been exploited, the traditional approach is to remediate the vulnerability that was exposed to gain access with only the individual asset in mind. While this approach does provide the owner with the comfort that the asset is secure from similar attack, what is not known is the potential attack vectors that were exposed during the exploit nor the impact that the vulnerability remediation had on the rest of the information system. ARMOUR provides the IS owner with all of the above. ARMOUR can identify exposed assets on DREnet through signature and/or anomalous behaviour-based detection. Notification of the exposed asset is provided to the operator but the follow-on activities are where ARMOUR provides capabilities that existing silo CND solutions lack. Once an asset has been identified with an exploited vulnerability, ARMOUR provides the operator with the capability to identify potential attack paths or attack vectors to other assets that may have been exposed. This attack path can provide insight to other similarly affected hosts and can also indicate where this exploit, or a related exploit, could be used to gain access to another network connected host in the topology. With this ability to uncover the potential attack vectors, ARMOUR provides the operator with a complete understanding of the potential capabilities that the observed exploit could provide to the attacker.
Use or disclosure of this data is subject to the restriction on the title page of this document.
W7714-115274/001/SV ARMOUR TD System CONOPS Unclassified Version F 21 April 2017 Unclassified 11 740928
Once the attack graph is generated, COA Recommendations are provided to the operator to resolve the vulnerabilities thereby mitigating the propagation of the attack any further. Simulation of the COAs demonstrates to the operator the impact of implementing the risk mitigation. The COAs recommended could include removing the vulnerability from the attack point (initially infected asset) and/or removing the vulnerrability from assets further down in the attack path. In either case, the impact of the mitigation activities (COA) is analyzed based on the global context of the system as a whole. The intent of this is to ensure that operational priorities are maintained and not negatively impacted as a result of the change. For example, Asset A is a router that connects asset B, C and D together. Asset D has been identified as a high priority device required for mission survivability. If Asset B is discovered to be infected, and an attack graph is generated showing a potential exploit to Asset D (high priority asset) through an attack vector, ARMOUR would generate the COA list with the highest ranked COA intending to secure/mitigate risk associated with any potential threat vector that could impact Asset D. This mitigation could be in the form of (but not limited to) removing any route between Asset B and Asset D on the router, patching the vulnerability of the identified exploit on Asset D or patching the vulnerability of the identified exploit on Asset A. The highest ranked COA would be selected based on the propagation capabilities of the attack, the priority assets with the attack path and mission objectives.
3.3 External Interfaces Interactions to other domains can be restricted by using one-way transfer (e.g., data diode) also known as a unidirectional network or unidirectional security gateway. Figure 2 depicts the use of a one-way transfer device to enforce traffic flow between two networks.
FIGURE 2. One-way Transfer Flow Control As ARMOUR is deployed within its own enclave, the collection of data from Data Sources and the transmission of data to Effector technologies hosted in the infrastructure or the managed network (i.e., DREnet) is managed via a secure perimeteer and interface point. Separate one-way transfer devices can be used on the data source or ingestion interface and on the effector interface to transfer effector outputs to the target network.
Use or disclosure of this data is subject to the restriction on the title page of this document.
W7714-115274/001/SV ARMOUR TD System CONOPS Unclassified Version F 21 April 2017 Unclassified 12 740928
4. OPERATIONAL CONCEPT This section outlines the operational concepts that apply to the ARMOUR TD. “The ARMOUR TD is intended to create and demonstrate an integrated system that will substantially improve the security of DND networks by providing an Automated CND capabiliity. The system will serve to provide the ability to pre-empt attacks and offer a planning capability to ensure networks are securely designed, even before they are procured.” [Ref 2] The processes involved in CND can be described as a closed loop process according to the OODA loop concept shown in Figure 3. All CND events observed on the network can be applied to this methodology. The ARMOUR solution operates according to the OODA process.
FIGURE 3. OODA Loop Operational Model [Ref 2] As shown in Figure 3, the OODA loop includes four distinct phases; The Observe phase, Orient phase, Decide phase and Act phase. Within each phase, proactive (subsection 4.1.1) and/or reactive (subsection 4.1.2) responses are applied to enhance the security posture of the network.
4.1 Operational Overview “Initially, network information is captured using deployed tools and operational impact is entered into the system. This information is correlated, and abstrracted into sets of useful data. The data is analyzed to determine the relative operational importance of hosts and software. The data is combined with rules describing attack techniques to compute all possible attack paths (given the rules and data) in the network. The potential attacks are chained together and stored in a graph data structure giving the pre-conditions and post-conditions for each attack step. The network’s
Use or disclosure of this data is subject to the restriction on the title page of this document.
W7714-115274/001/SV ARMOUR TD System CONOPS Unclassified Version F 21 April 2017 Unclassified 13 740928
exposure to threats is measured with quantitative metrics, thus minimizing operator subjectivity and training requirements. Optimal courses of action are generated and prioritized based on the return on investment. The goal is to minimize the ability of an attack to progress through the network by maximally denying assets the attack is likely to depend on (e.g., through removal or reconfiguration), thereby maximizing network security. Each course of action is composed of a combination of actions that together decrease the attack capability against the network. Courses of action include one or more specific actions, for example, the application of a patch or upgrade, reconfiguration of connectivity, activating or deactivating a host service, or altering host configuration settings. These courses of action represent the investment in mitigation actions and are characterized by costs measuring the possible impact to operations (e.g., operational downtime) and the resources required to implement them (e.g., personnel and technology resources). The return on investment represents the measure of the decrease in the attack capability against the network for the investment made. The courses of action are implemented in either a semi-automated (man-in-the-loop) fashion, where the operator selects the course of action to implement, or in a fully-automated fashion, where courses of action are automatically effectuated up to a set threshold of investment in mitigation actions. In the fully-automated case, operators are notified of actions taken, but no manual intervention is required by the ARMOUR operator. The effects of these actions are then monitored and any change to the network is detected by the data source connectors and the process repeats.” This process can be applied for both proactive and reactive CND situations.
4.1.1 Proactive Cycle “In proactive operations, the focus will be on optimally deploying resources to improve network security to prevent attacks before they occur. The process will be used to understand the impact of existing and potential vulnerabilities on operations and to develop mitigation plans (patches, upgrades, etc.) including the implementation of required mitigations. The process will also be used to understand the impact of introducing new software and architectural changes. Data from operations, network management systems, and vulnerability databases will continuously feed updates to ARMOUR so that it will always work with up-to-date information. The ARMOUR system will compute possible attack paths, compute relative dependence on each attack step in the path, and prioritize COAs based on costs to implement and the budget available. For COAs that exceed the budget threshold available, the system will develop and prioritize a list of recommended courses of action for display in various summary formats. The analyst will review the list of prioritized recommendations and select one or more COA sets for implementation. The selected COA sets will be submitted to Network Operations for review and action.
Use or disclosure of this data is subject to the restriction on the title page of this document.
W7714-115274/001/SV ARMOUR TD System CONOPS Unclassified Version F 21 April 2017 Unclassified 14 740928
Network Operations may or may not need to develop plans to implement the recommended COAs in the operational network depending on the scope of the COA. This may include testing of suggested upgrades and patches on test hosts, as well as updating other capabilities in order to support the changes to the network. Following the review, approval and possible testing of COAs, Network Operations will instantiate the resulting mitigation. Repeating the process will enable these changes to be evaluated as the data acquisition process senses changes. It will be possible to reverse selected COAs through a rollback function if the analyst determines that the results are undesirable. The Proactive capabilities will also include a ‘Simulation Mode’. In Simulation Mode, a security analyst will be able to perform speculative scenario analysis to discover the potential security impact of hypothetical changes to the infrastructure, operational environment, or vulnerabilities. This will be accomplished through the modification of vulnerability reference data, infrastructure data and operational dependency data, by making hypothetical changes and examining the subsequent results of the ARMOUR evaluations. This capability will support security planning and design, as well as Security Assurance and Accreditation (SA&A) evaluation, by providing clear indications of the security impact that changes may have.” [Ref 2]
4.1.2 Reactive Cycle “Reactive operations are concerned with dynamic real-time response to cyber security incidents. ARMOUR will act upon cyber security events, rapidly developing and implementing defensive responses in the network. The process will be used to dynamically and quickly respond to attacks and changes in the network or operational environment with COAs that can be immediately implemented in an automated manner (not requiring operator intervention) or semi-automated manner (requiring operator selection and approval). In the reactive cycle, ARMOUR will capture incident information in real time. The data will be used to identify attacks and predict attack paths. The process will make use of known COA implementation costs (also called a ‘loss cost’) and budgets to identify courses of action in response to the latest conditions providing the highest return on investment. Implementation of the course of action may be automatic where the implementation cost does not exceed an established budget. For COAs whose cost is above the configurable automatic threshold, implementation of the COA will require operator intervention. The automated nature of the process will result in an almost instantaneous reaction time by the system. The reactive analyst will monitor the response and intervene when required (e.g., where the cost of the COA(s) exceed the configurable threshold). The impact of the response will be evaluated by following the automated updates of the observe phase and examining the results. The analyst will be able to roll back selected COAs based on the results of the analysis.” [Ref 2]
Use or disclosure of this data is subject to the restriction on the title page of this document.
W7714-115274/001/SV ARMOUR TD System CONOPS Unclassified Version F 21 April 2017 Unclassified 15 740928
4.2 Roles and Responsibilities The following list identifies the roles and responsibilities assigned to operate and manage the ARMOUR solution with maximized efficiency: a. “Proactive Security Analyst: This analyst is involved in proactive operations and is responsible for reviewing vulnerabilities, developing mitigation plans (patches, upgrades, etc.) and planning the integration of required improvements with approval from the Network Operator; b. Reactive Security Analyst: This analyst is involved in reactive operations and is primarily responsible for incident response. These analysts will act upon events by developing defence responses and implementing COAs; c. Network Operator: This user is responsible for the continuing operation of the network. They balance current availability with long term stability of the network. The Network Operator reviews, approves and tests (as appropriate) all proactive courses of action in order to minimize operational impacts; d. Systems/Configuration Manager: This role sets data collection interfaces, processing parameters and applies operational priorities to the system. The Manager also instantiates the dependencies between operations, services and hosts (i.e. operation to operation, operations to operational services, service to service and host service to host) in accordance with the identified needs from the mission plan or standard operating procedure; e. Administrator: The Administrator manages account access details and assignments; and f. Commander: The Commander is responsible for overall operations. This role requires executive level summaries of status and activities. The commander also works alongside the Systems/Configuration Manager to determine and set operational priorities.” [Ref 2]
4.3 Operational Model This subsection describes how the OODA loop is applied to the ARMOUR High Level CONOPS. Figure 4 provides a high level representation of the ARMOUR operation and depicts the activities performed for each phase of the OODA loop while differentiating between Proactive and Reactive Operations.
Use or disclosure of this data is subject to the restriction on the title page of this document.
W7714-115274/001/SV ARMOUR TD System CONOPS Unclassified Version F 21 April 2017 Unclassified 16 740928
FIGURE 4. ARMOUR High Level Concept of Operations Each phase, along with a description of the proactive and reactive concepts, is described in detail in the following sections.
4.3.1 Observe Phase – Collect and Fuse Data “In the Observe phase, both asset and operations data wiill be collected and stored. Information from sensors and network management systems will push data to ARMOUR as the data is generated. System information will include both external reference data (e.g. vulnerability advisory information) and internal infrastructure data. Internal infrfrastructure data may be obtained from agents installed on end hosts to collect and store that asset’s data, or special purpose devices (hardware and software) installed at various locations in the network may be used to collect data from one or multiple sources. Examples of internal infrastructure data sources include network management and mapping systems, intrusion detection syystems, vulnerability scanners, network and host event logs, and firewall policies.” [Ref 2] This action is depicted by the “Build Network Model & Reachability” activity in Figure 4. The output of this action provides a model of the network that represents the topology and security state of the network.
Use or disclosure of this data is subject to the restriction on the title page of this document.
W7714-115274/001/SV ARMOUR TD System CONOPS Unclassified Version F 21 April 2017 Unclassified 17 740928
In addition to asset information, operations data will be collected (by the Commander and Systems/Configuration Manager) to enable the identification of the relative importance of specific instances of services and hosts in their support of planned or ongoing defence missions. This action is depicted by the “Build Operations & Infrastructure Dependencies” activity in Figure 4. The output of this action is a correlation of the network model with operational dependencies and forms the foundation for CND activities performed in the latter phases of the OODA loop. “Raw multi-source data will be correlated to remove duplication of information and may be further pre-processed for data abstraction and reduction. For example, all hosts sharing the same configuration and having the same connectivity may be represented as a single asset.” [Ref 2]
4.3.1.1 Proactive “In the proactive mode, the data store will contain current information on the state of the network based on information that will be automatically collected by the infrastructure management systems. The analyst may also trigger the acquisition of network and operational information by manually initiating a request for information from the infrastructure management systems.” [Ref 2]
4.3.1.2 Reactive In the reactive mode, security event data will be captured continuously in real time and provided to the data store. The data store is a repository which stores information for processing and analysis in later OODA loop phases.
4.3.2 Orient Phase – Predict Attack Paths “In the Orient phase, analysis of potential and ongoing cyber attacks will be analyzed and stored in a structure known as an attack graph. An attack graph is a mathematical abstraction of the preconditions for the attack to gain privileges in the network, and the post conditions indicating which privileges were gained. The attack graph encodes the way individual attacks may be chained together to form complex multi-step attacks. Analysis will be performed to give the possible attacks from the attack source (which may be any host in the network selected by the operator) to any destination host or service (also selected by the operator). Generally, the operator will select destination hosts or services which are critical to operations.” [Ref 2] This action is depicted by the “Generate Attack Paths” block in Figure 4. This activity applies to both Proactive and Reactive operations. The output of this module is an attack graph that is used as input in the risk modelling stage. “High priority services and hosts will be identified from information about operational dependencies collected in the Observe phase. The attack graphs will be analyzed in the context of high priority services to defend and vulnerability characteristics to rank the likely dependence of the attack on the various network properties that would allow an attacker to gain additional privileges.” [Ref 2]
Use or disclosure of this data is subject to the restriction on the title page of this document.
W7714-115274/001/SV ARMOUR TD System CONOPS Unclassified Version F 21 April 2017 Unclassified 18 740928
Risk modelling in the Orient phase utilizes the attack paths to assess risks and prioritize the remediation of vulnerabilities. This action is depicted by the “Conduct Risk Modelling” block in Figure 4. The Security Analyst can utilize risk analysis to proactively assess the risk due to vulnerabilities and exposure associated with network resources and operational units, as well as reactively model risks and damage incurred after a compromise has been discovered. Risk Modelling will produce a list of recommended COAs as input to the Decide phase. Data collected from the Observe phase will be used as input to the analysis engines operating in the Orient phase.
4.3.2.1 Proactive “In proactive analysis, operator input will have an integral role in setting the parameters for analysis. Attack sources are hypothetical and will be selected by the operator. Operational priorities identify high priority services which the operator wants to defend. In addition, the operator will be able to select a number of hosts to view the attack paths from the attack source to the selected hosts. A Proactive Analyst will be able to perform speculative analysis based on hypothetical changes to infrastructure, operational environment, and inserted vulnerabilities into the base network and operating environment.” [Ref 2]
4.3.2.2 Reactive “Reactive analysis will be performed in response to current cyber security attacks. It will make use of ongoing incidents to automatically specify compromised hosts as attack sources and will compute ranked attack paths that predict possible next steps an attack could take to advance toward high priority services the operator wants to defend.” [Ref 2] Security events are identified by sensors (data sources) deployed within the network. The normalized events are analyzed by the Incident Analyzer and compromised host information is provided to the Attack Path Generator to compute attack graphs based on the known attack sources. This action is depicted by the data flow model providing input to the “Generate Attack Path” module for the Reactive Operations of Figure 4.
4.3.3 Decide Phase – Decide Courses of Action In the Decide phase, optimized and prioritized Recommended Remediations are computed to respond to the situations identified and characterized in the Orient phase. COAs will be generated and prioritized in consideration of both the current likelihood that particular vulnerabilities may be exploited and the relative cost to operations resulting from the proposed COA (for example, remediation resources required and the operational impact of any downtime).” This action is depicted by the “Conduct COA Analysis” block in Figure 4 and is performed by the COA Analyzer. The core of the COA Analyzer is the continuously updated and approved Effector Registry and COA Template library. This library contains the complete set of all COAs
Use or disclosure of this data is subject to the restriction on the title page of this document.
W7714-115274/001/SV ARMOUR TD System CONOPS Unclassified Version F 21 April 2017 Unclassified 19 740928
that have been approved for deployment, their component actions, associated costs, and associated reverse COAs. “The Operator will be able to set the budgets and operational costs associated with specific elements and actions. Different Operators will be able to be involved in the proactive and reactive cycles, and they may set the costs differently for proactive and reactive cycles. For instance, the cost of shutting down a service may be high in a proactive scenario to reflect the desire for continued operation. However, the cost for the same service in a reactive scenario may be lower to reflect the importance of network security over the availability of a known compromised service. Similarly, the Operator will be able to set the COA budget established in the system differently for the proactive and reactive scenarios in order to reflect operational considerations unique to each case. The impact of resulting COAs will be included in a subsequent data collection phase and the operator will be able to reverse the implemented COAs. In all cases a valid Recommended Remediation may be that no action be taken due to the unacceptable impact of other COA on critical operations. In essence, the operational authority will accept the risk of continued operations despite identified attack paths.”
4.3.3.1 Proactive Proactive COAs may include, for example, reconfiguring a host by shutting down vulnerable host services or blocking particular ports and protocols using firewall rules. Another approach may involve remediation of known vulnerabilities by deploying a software patch or operating system upgrade. More complex CoA will notify Network Operators using the Redmine ticketing service with host and service details. Network Operators will be able to review and instantiate the COA depending on the requirements of the mitigation activity. Network Operators may also decide to change the sequence of activities prior to effectuation CoAs.
4.3.3.2 Reactive “Reactive COAs may include, for example, reconfiguring a host by shutting down a vulnerable host service or blocking particular ports and protocols using firewall rules. Certain actions may be required to contain an ongoing attack that will have a significant impact to operations. Use of known operational costs and budgets will determine if the implementation of the COA may be automatic or require operator intervention.” [Ref 2]
4.3.4 Act Phase – Implement Courses of Action “In the Act phase, the selected COAs will be implemented. COAs may be implemented in a semi-automated (man-in-the-loop) fashion, where the operator selects the COA to implement, or in a fully-automated fashion, where allowable COAs will be implemented based on previously configured settings up to an established threshold. Following the actions taken in the Act phase, the ongoing Observe phase processes will detect the changes in the infrastructure and the OODA loop will be repeated.” [Ref 2]
Use or disclosure of this data is subject to the restriction on the title page of this document.
W7714-115274/001/SV ARMOUR TD System CONOPS Unclassified Version F 21 April 2017 Unclassified 20 740928
This action is depicted by the “Semi-Automated Response” and “Automated Response” blocks shown within the Act Phase of Figure 4.
4.3.4.1 Proactive “As described previously, proactive Recommended Remediations may be the result of analysis of the actual state of the network or the result of speculative analysis. Depending on the scope of the COA, Network Operators may or may not need to develop plans to implement the recommended COAs. Following the review, approval and possible testing of COAs, Network Operators will effectuate the resulting mitigation. It will be possible to reverse any system- implemented COA if the analyst determines that the results are undesirable.”
4.3.4.2 Reactive “COAs implemented in a reactive environment will be completed automatically up to a specified budget in order to provide rapid response to ongoing attacks.” [Ref 2] Should this cost exceed the budget threshold, the COA must be analyzed and approved by the operator (semi-automated). “These COAs will be actively monitored to ensure that they do not have a detrimental impact on operational needs in the changing environment. Upon review, the analyst will be able to reverse selected COAs that have been effectuated by the system.” The Incident Analyzer is also capable of generating “Direct CoAs” that bypass compute intensive attack graph analyses for very specific attack vectors.
4.4 ARMOUR Subsystems The ARMOUR System solution is comprised of several subsystems. This subsection provides a high level description of each of the ARMOUR subsystems in order to provide the reader with an understanding of how the subsystems interact to achieve the objectives described in subsection 4.3. For more detailed information on the following subsections, refer to the ARMOUR ADD (GDMS-C document No. 995015).
4.4.1 Integration Framework As described in subsection 1.2.2, one of the capability deficiencies is that an integration framework that could provide quick and easy integration of new modules, services and capabilities to the solution is required. In order to achieve a collaborative development environment where research institutes, academia and commercial industry are able to develop and integrate new technologies and capabilities within ARMOUR, a framework that will provide the ability to integrate regardless of the capability’s architecture/interface will allow for technology agnostic development and continuous improvement of the solution. This integration framework capability required can be seen in Figure 5.
Use or disclosure of this data is subject to the restriction on the title page of this document.
W7714-115274/001/SV ARMOUR TD System CONOPS Unclassified Version F 21 April 2017 Unclassified 21 740928
FIGURE 5. Integration Framework in Reference to ARMOUR The design of the ARMOUR TD project solution offers an open source, standards based Enterprise Integration Framework (EIF) called ServiceMix. ServiceMix is packaged and configured to enable distributed, decoupled integration of technologies, systems and data. ServiceMix provides the back-end services that allow the ARMOUR subsystems and modules to communicate between one another and the interfaces to external systems and services to exchange data and messages. ServiceMix binds the five other architectural contexts to address the specific requirements found in the ARMOUR TD System Technical Specification (STS) while also meeting the operational and performance requirements. These five elements are:
Use or disclosure of this data is subject to the restriction on the title page of this document.
W7714-115274/001/SV ARMOUR TD System CONOPS Unclassified Version F 21 April 2017 Unclassified 22 740928
a. Connectors: The connector context represents the interaction between ARMOUR and the network infrastructure to facilitate the understanding of the current environment (i.e., network topology, operational moods, sensor feeds, etc.) and the means by which to alter the network to mitigate undesirable behavior; b. Data Storage: This context supports the storage, access and retention of all information required for the ARMOUR system to function. As the environments become more complex and the operational tempo increases, this context must address one of the pressing challenges in CND – “Big Data”; c. Data Presentation: This context supports all of the Human-Machine Interface for ARMOUR. As the goal is to support a variety of operational environments, a key aspect of the data presentation context is flexibility in how the information is presented and explored; d. Data Normalization and Correlation: This context represents the reduction of the volume of data and information gathered by removing redundant information collected by various tools. Multiple tools often collect data from single asset/software/vulnerabilities/events and the computational strain of processing the same data more than once is undesired. Raw multi-source data will be correlated to remove duplication of data; and e. Data Analysis and Action: This context represents the computational elements that are the core of the ARMOUR system. It is within the Data Analysis and Action context that the problem space is fully understood and mitigated.
4.4.2 Data Source Connectors Data Source Connectors serve to ingest the information produced by data sources and provide that data to the ARMOUR system where it is normalized to the ARMOUR data model format, verified and stored in the database. ARMOUR subsystems and modules use the stored data to display relevant information to the operator such as network topology and security incidents, and to perform additional computational analysis for situational awareness. Data sources exist as infrastructure data sources, security related data sources and non-infrastructure data sources.
4.4.3 Database The database is the repository for all data collections. Information can be accessed by operators and analysis engines as required and contains long-term data storage1.
4.4.4 Data Presentation The Data Presentation subsystem provides the user with a visual representation of the security posture of the network and the individual nodes comprising it. Data presentation supports rapid indications of critical information that illustrate areas of immediate concern to the operator. It
1 The term for data storage will be defined in a later phase as requirements analyses progress. Use or disclosure of this data is subject to the restriction on the title page of this document.
W7714-115274/001/SV ARMOUR TD System CONOPS Unclassified Version F 21 April 2017 Unclassified 23 740928
provides the operator with an interface to visualize the topology, provide data input, view output (i.e., reports), observe security events, initiate analysis and simulation, and respond to observed/simulated events.
4.4.4.1 Object Representation Icons within the graphical windows are used to represent objects and data overlays. Icons are distinct and intuitive representations of operations and infrastructuree as well as Security Status Indicators (SSI). Infrastructure icons represent multiple host types, as shown in FIGURE 6: - End Host, - Router, - Switch, - Hub, - Firewall, - IDS, - External Host, - Virtual Machine, - NAT and - Laboratory Network.
FIGURE 6. Host Type Icons Security Status Indicators are shown in FIGURE 7. SSIs represent the following states: a. Uncertain status (e.g., hosts identified but corresponding software information is not available); b. Disconnected status; b. Security metric and degree of dependency values; c. Presence of vulnerabilities;
Use or disclosure of this data is subject to the restriction on the title page of this document.
W7714-115274/001/SV ARMOUR TD System CONOPS Unclassified Version F 21 April 2017 Unclassified 24 740928
d. Likely occurrence of compromise; e. Sequence attack path (source, target, and hop)); f. Attack value (e.g., criticality of a host within an attack path); and g. Course of action implication (e.g., effect of selecting or deselecting a particular course of action).
FIGURE 7. Security Status Indicators Icons include additional visual details/attributes regarding the component they represent. Attributes may include, but are not limited to colour, size and background, and provide the operator with a visual indication of various characteristics of the object (i.e., asset compromised, high value asset, operational criticality, etc.). As an example, the Operation Dependency Metric (ODM) is represented by a coloured background, as shown in FIGURE 8.
FIGURE 8. Security Status Indicators
Use or disclosure of this data is subject to the restriction on the title page of this document.
W7714-115274/001/SV ARMOUR TD System CONOPS Unclassified Version F 21 April 2017 Unclassified 25 740928
Relationships between objects are displayed through the use of connecting lines or arrows. Similarly to icons, relationships can include additional visual attributes to identify the characteristics of the relationships between objects such as line thickness, colour and style.
4.4.4.2 Graphical User Interfaces To accomplish the operational objectives described in subsection 4.1, users will interact with the technical solution to provide decision analysis and resolution input to the ARMOUR System for both the proactive and reactive response. The following list highlights the interaction the user will have with the system: a. Provide operational priority input; b. Develop Courses of Action and provide incident response templates; c. Review vulnerabilities and develop mitigation plans; d. Monitor presentation views; e. Plan improvements; f. Provide decision analysis resolution where semi-automated responses require human intervention; g. Configure and maintain the system; h. Provide event summaries to the chain of command; and i. Generate reports. The data presentation subsystem is provided by the Ozone Widget Framework (OWF). OWF is a framework for visually organizing lightweight web application (known as widgets) within a user dashboard. Graphical and tabular widgets provide the operators with a GUI to interface with the system to perform operations particular to their role (roles are defined in subsection 4.2). As previously introduced in section 4.2, ARMOUR supports six user roles: 1. Administrator; 2. Systems/Configuration Manager; 3. Network Operator; 4. Proactive Security Analyst; 5. Reactive Security Analyst; and 6. Commander. Each User of the ARMOUR System is assigned to one of these roles. Each role is provided access to all widgets. ARMOUR manages the level of permission for each widget to allow users to perform their duties. The default assignment of widget permissions and external applications to User roles is articulated in Table 1. The permissions can be modified by the Systems/Configuration Manager using the Hawt.io web console; refer to the ARMOUR administrator’s guide for more information. The letters C, R, U, D and X is used to denote the following: R: Read-only access: User can view entities but not modify or delete them; Use or disclosure of this data is subject to the restriction on the title page of this document.
W7714-115274/001/SV ARMOUR TD System CONOPS Unclassified Version F 21 April 2017 Unclassified 26 740928
C: Create access: User can create new entities; U: Update access: User can modify existing entities; D: Delete access: User can delete existing entities; and X: External application access. Table 1 lists widgets and applications along with default user roles and permissions. Table 1. Assignment of Widgets to User Roles
Proactive Reactive Systems / Network Widget Security Security Configuration Administrator Commander Operator Analyst Analyst Manager OWF Administrator CRUD LDAP Administrator (389 Console) X PostgreSQL Admin (pgAdmin III) X ARMOUR IF Admin CRUD (Hawt.io) ARMOUR Data Ingestion R R R R R R Dashboard Workflow Ticket System X X X X X X (Redmine) Network Topology R R R R R Reachability R R R R R Alert Toolbar RUD RUD RUD R RUD Inventory RUD RUD RUD R Host Detail List RUD RUD RUD R Incident Details CRUD CRUD CRUD R Verification Policy Editor CRUD CRUD CRUD R Report Template CRUD CRUD CRUD CRUD Previously Run Reports CRUD CRUD CRUD CRUD Operational Dependency CRUD CRUD CRUD CRUD Attacker Model CRUD CRUD CRUD R Attack Path R R R R Attack Graph Requests CRUD CRUD CRUD R Attack Graph Analysis CRUD CRUD CRUD R Requests Vulnerability List CRUD CRUD CRUD R Vulnerability Details CRUD CRUD CRUD R Firewall Details CRUD CRUD CRUD R Host History R R R R
Use or disclosure of this data is subject to the restriction on the title page of this document.
W7714-115274/001/SV ARMOUR TD System CONOPS Unclassified Version F 21 April 2017 Unclassified 27 740928
Proactive Reactive Systems / Network Widget Security Security Configuration Administrator Commander Operator Analyst Analyst Manager User View List CRD CRD CRD R Recommended Remediations RUD RUD RUD R Effected Progress CRUD CRUD CRUD R CoA Templates List CRUD CRUD CRUD Effector Registry CRUD CRUD CRUD CRUD Abstraction Graph CRUD CRUD CRUD R Incident List R R CRUD R Incident Details R R CRUD R Security Onion (Sguil) X X
The widgets enable all user roles to visualize the network from deliberate and focused GUIs. For example, the Operational Dependency Widget allows the Systems/Configuration Manager to view dependencies between operations. The ARMOUR System widgets are grouped as follows: a. Infrastructure; b. Operational; c. Speculative Analysis; d. Attack Path; e. COA; f. Incident Analysis; and g. Support Tools. Each display group is comprised of one or more of the widgets identified in Table 1. These groups provide all of the functionality required for operators to successfully execute the ARMOUR mission. FIGURE 9 shows how these display groups support the OODA process.
Use or disclosure of this data is subject to the restriction on the title page of this document.
W7714-115274/001/SV ARMOUR TD System CONOPS Unclassified Version F 21 April 2017 Unclassified 28 740928
FIGURE 9. Presentation Groups within OODA Loop
4.4.4.2.1 Infrastructure Group The Infrastructure Group is the primary interface to visuaalize the network topology. This group of displays provides both graphical and tabular widgets to represent tthe infrastructure. The infrastructure group is supported by the following widgeets: 1. Network Topology; 2. Inventory (Host Summary List) and Host Details; 5. Host History Data; 6. Reachability; 7. Incident List and Details;
Use or disclosure of this data is subject to the restriction on the title page of this document.
W7714-115274/001/SV ARMOUR TD System CONOPS Unclassified Version F 21 April 2017 Unclassified 29 740928
9. Alert Toolbar; and 10. Vulnerability List and Details. The Infrastructure Display Group supports the Observe Phase of the OODA Loop.
4.4.4.2.1.1 Topology Widget The “Topology” widget shown in FIGURE , provides the operator with a visual representation of the physical network topology - the network devices and the links between the hosts. Overlays are used in this widget to provide visual indication of the node’s status (e.g., Vulnerable, Compromised, etc.). The Topology widget can also dispplay the reachability graph connectivity determined by the reachability analyzer, using graphic overlays on the topology GUI.
FIGURE 10. Topology Widget
4.4.4.2.1.2 Inventory and Host Details Widget The “Inventory” widget shown in FIGURE 11, provides a list (tabular) of the hosts discovered by the system and represented graphically in the topologgy widget. This list provides high level information about each host including but not limited to,, the hostname, a description of the host and the IP Address. Providing more detailed information is the “Host Detail” widget. This widget is accessed via the Inventory widget to display the detailed information collected on the host. This includes all the information contained in the Inventory list as well as additional information pertinent to the host configuration. Figure 7 depicts the ARMOUR deployment showing all three supporting Infrastructure views.
Use or disclosure of this data is subject to the restriction on the title page of this document.
W7714-115274/001/SV ARMOUR TD System CONOPS Unclassified Version F 21 April 2017 Unclassified 30 740928
FIGURE 11. Inventory Widget
4.4.4.2.1.3 Host History Widgd et The Host History widget shown in FIGURE 12, includes historic information pertinent to a selected host. Historic information shows when new data was ingested for a particular host from any of the ARMOUR data sources as well as what the changes were.
FIGURE 12. Host History Widget
4.4.4.2.1.4 Reachability Widgd et The Reachability Widget provides the reachability detaills that describe the logicaal links between nodes within the network. This widget allows users to query the Reachability Analyzer to identify connectivity between source and destination hosts including port and protocol information. Upon user request, this widget can also dispplay the bloccked paths and ports between source and destination hosts.
Use or disclosure of this data is subject to the restriction on the title page of this document.
W7714-115274/001/SV ARMOUR TD System CONOPS Unclassified Version F 21 April 2017 Unclassified 31 740928
FIGURE 13. Reachability Widget
4.4.4.2.1.5 Incident, Incident Details and Alert Toolbar The Incident List widget shown in FIGURE 14, displayss the summary list of security incidents where operators can view high level details regarding anny of the obseerved security incidents. Supplemental to the Incident list is the Incident Detail wiidget, shown in FIGURE 15. This widget provides more detailed information on the highlighted incidennt from the Incident list and allows users to add notes to each incident.
FIGURE 14. Incident Summary Widget
Use or disclosure of this data is subject to the restriction on the title page of this document.
W7714-115274/001/SV ARMOUR TD System CONOPS Unclassified Version F 21 April 2017 Unclassified 32 740928
FIGURE 15. Incident Details Widget When security incidents are observed, an Alert toolbar located in the banner bar of the OWF framework provides a visual indication to the user that a security incident of interest has occurred. The Alert toolbar provides three levels of severity indication: 1. Low Severity Events – Events of low severity are represented by the Green sphere in the alert toolbar. 2. Medium Severity Events - Events of mediumm severity are represented by the Amber sphere in the alert toolbar. 3. High Severity Events - Events of high severity are represeented by the Red sphere in the alert toolbar. Each indicator includes a counter next to it to identify how many incidents of that severity have been observed. The user is able to click on the sphere and bring up a list of all incidents that have been grouped as that severity. The Alert toolbar is depicted in FIGURE .
FIGURE 16. Alert Toolbar
4.4.4.2.1.6 Vulnerability List and Detail Widget The Vulnerability Details widget provides detailed information on vulnerabilities and exploits present on selected hosts. When an operator selects a host from the Topology widget or the Inventory widget, the vulnerability and exploit details are automatically populated in the Vulnerability Detail widget.
4.4.4.2.2 Operational Group The Operational View provides interfaces for the creation, management, and moonitoring of missions. This interface fully utilizes infrastructure data for validation of scenarios. Use or disclosure of this data is subject to the restriction on the title page of this document.
W7714-115274/001/SV ARMOUR TD System CONOPS Unclassified Version F 21 April 2017 Unclassified 33 740928
Once an operation has been established, its assets, dependencies and status can be viewed at any time. This includes vulnerability, security posture, as well as connectivity information. Operations can also be grouped into larger organizational units to produce one or more command structures. These command structures provide the means to gauge the overall status and security posture of the entire command. Operations are searchable and filterable to facilitate display of only the resources that are most relevant to the operator at any given time. The Operational Group only contains the Operational Dependency Widget, shown in FIGURE 17.
FIGURE 17. Operational Dependency Widget The Operational Group supports the Observe Phase of the OODA Loop.
4.4.4.2.3 Speculative Analyssis Group Speculative Analysis Group widgets give users the abilitty to analyze historical annd current data to simulate changes to the infrastructure, non-infrastructure and models. Users are allowed to modify data, compute attack graphs and view potential effects of those modificattions. These widgets are only available in proactive mode of operation. While in the Speculative Analysis mode, on-going security incidents and data collection events are not shown to the user: the widgets are locked in time. If users want to view the current network situation, they must exit the Speculative Analysis mode and return to the Live mode, using the User View Controller widget. The Speculative Analysis widgets are: Inventory widget; Vulnerability widget; Reachability widget; Computational Services widget; User View Controller widget; and Historical Data List widget.
Use or disclosure of this data is subject to the restriction on the title page of this document.
W7714-115274/001/SV ARMOUR TD System CONOPS Unclassified Version F 21 April 2017 Unclassified 34 740928
Users can select the Speculative mode by using the User View Controller widget and switching to “simulated” user view. Because all modifications performed in Speculative Analysis view are tagged as SIMULATED, the Live system is not affected by user activities. User views can be shared with other users, but only the creator of the view can modify the view. All user views are displayed in the User View drop-down list of the User View Controller widget. In the Speculative mode, the user has complete flexibility to modify host, vulnerability and network properties, including: Marking vulnerabilities as fixed or ignored; Assigning vulnerabilities to hosts; Patching vulnerabilities on hosts; Changing routes or physical network connectivity; and Changing firewall rules. The CoA module takes the user’s SIMULATED data into account when generating recommendations. The Speculative recommendations cannot be effectuated. The Speculative Analysis view covers all phases of the OODA Loop.
4.4.4.2.4 Attack Path Group The Attack Path Group provides the operator with the ability to create and modify threat definitions and prepare and execute attack simulations and view the results graphically. The Attack Path Group contains the following widgets: - Computational Services widget; and - Topology widget. The Computational Services widget enables Proactive and Reactive Analysts to generate detail Attack Scenarios, by specifying the Attacker Location and Attack Objective, as shown in FIGURE 18. By default, only remotely exploitable attacks are generated, however, analysts can generate client exploits as well.
Use or disclosure of this data is subject to the restriction on the title page of this document.
W7714-115274/001/SV ARMOUR TD System CONOPS Unclassified Version F 21 April 2017 Unclassified 35 740928
FIGURE 18. Attack Graph Generation Widget When attack paths are located, analysts can view the results using the Attack Path widget, shown in FIGURE .
FIGURE 19. Attack Patth Widget
Generation of the attack graph is accomplished through selection of a threat origin and attack target from within any view that can display individual or abstracted hosts (e.g., Topology, Inventory, and Operational View). This origin defines the starting point for the attack as well as any of the attacker attributes that are relevant to the simulation. These origins can be created or modified from within this interface at any time.
Use or disclosure of this data is subject to the restriction on the title page of this document.
W7714-115274/001/SV ARMOUR TD System CONOPS Unclassified Version F 21 April 2017 Unclassified 36 740928
Once an attack has been generated, it can be viewed within the attack path widget. This graph features colour-coded and weighted links that visually describe not only the paths taken, but the likelihood of those paths being taken. For each step in the attack, a detailed description is given that includes the host, status, exposure, criticality, associated vulnerability and calculated risk. An overview for the entire graph features a count and list of attack steps/vulnerabilities exploited, unique vulnerability types, ports or services used, and effected hosts. It is also possible to view lists of routes and access policies that have allowed the attacks to occur at the network level. The Attack Path View is one of the views that support the Orient Phase of the OODA Loop.
4.4.4.2.5 COA Group The CoA Group provides the means to generate Recommended Remediations, to effect semi- automated Course of Action Activities and to monitor their effectuation status. The CoA Group is supported by the following widgets: CoA Template Editor; Effector Registry; Recommended Remediations; Attack Path Display; and Effector Progress. The Course of Action Analyzer integrates the COADS application from DRDC. COADS require information from the following modules: Attack Graph Generator; Attacker Model; Attack Graph Analyzer; CoA Templates; and Optionally, the Operational Dependency Metric. When generating requests for COADS, ARMOUR uses the lowest cost templates for a given attack graph vertex. When offering courses of action to end-users, all templates and their associated costs are available. As part of the semi-automated response, the Recommended Remediations list displays the Loss- Cost and Security Posture Metric achieved if the CoA is effected. The Loss-Cost represents the total cost of effectuation of all the activities within a CoA. For a given Recommended Remediation, many Courses of Action may be taken in order to remedy the situation. The Operator is provided with a list of all possible CoAs, with their associated Loss-Cost and SPM values. The Operator may also view the Attack Paths that are corrected from the effectuation of a selected CoA on the Attack Path Display. The Operator can modify a CoA or choose an alternate CoA from the database for effectuation. The user can also opt to make a Course of Action ineligible for effectuation. Once the CoAs for Use or disclosure of this data is subject to the restriction on the title page of this document.
W7714-115274/001/SV ARMOUR TD System CONOPS Unclassified Version F 21 April 2017 Unclassified 37 740928
a Recommended Remediation Set are effectuated, the Operator can monitor progress in real time. If there is a problem or change of plan, the Operator may cancel in-progress at any time. Effectuated CoAs can be rolled back based on the “Reverse CoA” template. As part of the automated response, the Recommended Remediations Widget shows the effectuated CoAs with an “Auto” column to identify which CoAs were initiated automatically. The Recommended Remediations Widget also include a specialized dialog that offers Operators the option to cancel an automatically instantiated CoA. The CoA Cancellation Dialog provides a User configurable count-down timer. When the count-down reaches zero, the CoA is instantiated. Finally, the Recommended Remediations Widget allows Operators to transfer the effectuation and cancellation authority to other users. This only applies to In-Progress CoAs. The CoA View is one of the views that support the Orient phase of the OODA loop. It is also the sole provider for the Decide and Act phase. Refer to ARMOUR DDD from more detailed information.
4.4.4.2.6 Incident Analysis Group The Incident Analysis Group is provided by technologies that are integrated within the ARMOUR IF. These technologies create a visualization layer for incoming network security events that is flexible and responsive in support of incident analysis activities. It provides the means to display and analyze all of the incoming security event data and includes features such as: Sortable, searchable lists of all incoming security events; Customizable charts and graphs capable of long-term historical correlation; and Short, medium and long-term trending displays. The Incident Analysis view is supported by the following widgets: Incident List; Incident Details; Alert Toolbar; and Incident Analysis. Incidents are raised from external Security Information and Event Management (SIEM) applications, such as those available in the Security Onion Linux distribution. ARMOUR provides a Data Source Connector that allows applications, such as Sguil to send incidents as XML data for ingestion into ARMOUR. These external applications are not strictly part of the analysis view. By providing an open API for external applications, ARMOUR easily integrates third-party applications that such as IDS, IPS and system log applications. The Incident Analysis view is one of the views that support the Observe and Orient phases of the OODA Loop. Use or disclosure of this data is subject to the restriction on the title page of this document.
W7714-115274/001/SV ARMOUR TD System CONOPS Unclassified Version F 21 April 2017 Unclassified 38 740928
4.4.4.2.7 Support Tools Group ARMOUR provides several additional widgets and external applications that provide necessary support functionality. These widgets and applications are: a. Rules Widget – used to generate, modify and remove data Verification and Incident Analyzer rules; b. Report Widget – used to provide the ability for ARMOUR users to generate reports, view reports and create/modify/delete report templates; c. OWF Administration Widgets – the administrator widget for OWF. Provides for the management of OWF related activities including widget assignment to roles; d. LDAP Administrator Console – Third Party console (389 Management Console) used to administer the LDAP Directory Server including assignment of user to roles. e. PostgreSQL Administrator Console – Third Party console (PG Admin) used to administer the ARMOUR database; f. ServiceMix Administrator Console – Third Party console (Hawt.IO) used to administer ServiceMix related activities; and g. Work Flow Ticket System – for management, tracking and storage of reported issues. Details on each supporting widget can be found in the ARMOUR DDD (GDMS-C document No. 741349).
4.4.5 Computational Services The following subsections provide a high-level description of the services employed within the ARMOUR TD solution. For more detailed information on the following subsections, refer to the ARMOUR ADD (GDMS-C document No. 995015).
4.4.5.1 Data Normalization Data Normalization aids in generating a global common operating picture of the current security posture of the network. By converting raw input data to the ARMOUR Data Model format, the process of Data Normalization enables data gathered from multiple data sources to be compared, combined, and fused while reducing the amount of redundant data made available to the other processing modules within ARMOUR. Data Fusion and reduction activities are performed by the Cross Source Correlation module. Data Normalization is also part of the information flow when ARMOUR applies COAs. Any data leaving the system must be converted from the ARMOUR Data Model format to the Data Model of the target effector.
4.4.5.2 Cross Source Correlation The Cross Source Correlation (CSC) module helps manage the information gathered by the ARMOUR system. It fuses data from multiple sources into a single representation. This single
Use or disclosure of this data is subject to the restriction on the title page of this document.
W7714-115274/001/SV ARMOUR TD System CONOPS Unclassified Version F 21 April 2017 Unclassified 39 740928
representation can then be used by other computational services, reducing the amount of redundant data that these modules have to ingest, process, and perform computations on. The process of correlating the large amounts of data also serves to combine information associated with assets referenced by various methods depending on the location and type of data source. For example, a sensor within a particular subnet may detect an event from a certain IP address, while a sensor outside the subnet may detect the same event, but associate it with a different IP address due to the use of NAT. It is up to the CSC module to identify the fact that the same event is being registered and combine the data accordingly. Finally, as multiple data sources may provide conflicting data about the same asset or incident, it is up to the CSC module to resolve these conflicts in order to provide an accurate representation of data. Conflict resolution may be based on a number of factors, including timestamps and trustworthiness of sources. Cross Source Correlation is performed on security data, infrastructure data and operations data.
4.4.5.3 Reachability Analyzer The Reachability Analyzer provides visibility and intelligence of network topology, device configurations and access policy compliance. It collects configuration information from all network devices, including routers, switches, firewall devices and other network security appliances and the analysis engine normalizes the data to generate a visual map of the network. Any changes detected on the network (i.e., device availability, access compliance, etc.) are quickly evaluated and displayed for all ARMOUR users. The end result of the collection and analysis of all of these data sources is a single reachability graph (see Figure 14). This graph contains all of the information necessary to describe the connectivity between network resources in terms of both physical and routable connectivity, but also for individual protocols and ports. In Actual mode, the network topology is updated automatically as changes are correlated in. In Simulation mode, the data is static.
Use or disclosure of this data is subject to the restriction on the title page of this document.
W7714-115274/001/SV ARMOUR TD System CONOPS Unclassified Version F 21 April 2017 Unclassified 40 740928
FIGURE 20. Sample Reachability Graph In general, the entire reachability analyzer operates through automateed retrieval of network data. However, a manual over-ride capability exists to enable the user to add to, delete from or otherwise edit the final reachability information as desired. For example, it may be necessary to manually add hosts that are unreachable through normal data-collection means, to remove hosts that are not relevant to the user’s interests, or annotate hosts with additional information.
4.4.5.4 Common Infrastructure Abstraction This is the process of identifying common or similar hossts within the network to allow for automated grouping and abstraction. The abstraction provides a reduced dataset for computational service and yields better user experience. ARMOUR provides two abstraction services: - one-to-one: this abstractor is a pass-through and performs no reduction; and - Reachability and Operating System (ReachOS): this abstractor combines all host within a single subnet that have the same operating system. All services and vulnerabilities for all combined hosts are merged into one “super” host.
Use or disclosure of this data is subject to the restriction on the title page of this document.
W7714-115274/001/SV ARMOUR TD System CONOPS Unclassified Version F 21 April 2017 Unclassified 41 740928
While the performance benefits of using abstraction were immediately noticeable, the ReachOS abstraction highlighted some of the deficiencies in the approach: - De-abstraction of vulnerabilities - Abstraction of firewall rules is very complex Abstraction will require more investigation in the future.
4.4.5.5 Operations and Infrastructure Analyzer The Operations and Infrastructure Analyzer (OIA) allows the Security Analysts to perform analysis on the infrastructure to determine operational impact and risk exposure. It provides the Analysts with the capability to prioritize mission assets and services. The OIA module integrated the AssetRank algorithm described in section 4.4.5.7.1.
4.4.5.6 Attack Graph Generator The Attack Graph Generator module provides both the Proactive and Reactive Security Analysts with the ability to visualize the various vulnerabilities and configurations an attacker can exploit on the network. From the Proactive Security Analyst point of view, this allows the user to see what possible attacks the system is vulnerable to, and from a Reactive Security Analyst point of view, the possible advances an attacker may have made after a compromise has been confirmed can be seen. Attack graph generation leverages the MulVAL reasoning system (see subsection 4.4.5.6.1) in order to process the data available in the ARMOUR database and compute the attack graph for one or more given attacker models. The generated attack graph, an AND/OR directed graph, is then used by the Attack Graph Analyzer and the OIA (specifically to compute the Security Posture Metric) in order to assess the risk levied on the system. Note that while the input for the Attack Graph Generator module comes from the ARMOUR database, it can be real, historic, or simulated, and may or may not be the abstracted data created by the CIA module. This flexibility allows the comparison of multiple configurations without actually having to change the in-service network, and the generation of reactive graphs based on actual incidents. Given infrastructure, vulnerability, and exploit information, including attacker location, the set of attack paths (forming the attack graph) that results in the compromise of any asset (or any of a subset of all assets) can be computed. While MulVAL will be used as the default Attack Graph Generator module within ARMOUR, it is indeed a module and can be swapped out with another piece of software capable of producing attack graphs. Using a module that does not output an AND/OR directed graph may require modifying other modules.
Use or disclosure of this data is subject to the restriction on the title page of this document.
W7714-115274/001/SV ARMOUR TD System CONOPS Unclassified Version F 21 April 2017 Unclassified 42 740928
4.4.5.6.1 MulVAL “MulVAL is a formal, logic-based reasoning system that consumes a networked system’s configuration and vulnerability information and generates an understanding of its security by revealing all security consequences deducible from the input data and the MulVAL reasoning model. The MulVAL system output can be presented using visualization tools and used in further analysis. [Ref 1
4.4.5.7 Attack Graph Analyzer The Attack Graph Analyzer uses the attack graph created by the Attack Graph Generator module, combined with metrics about vulnerabilities, exploits, attacker models and the Operational Dependence Metric (ODM), in order to assess what assets represented in the attack graph are most valuable to an attacker. Knowing what would provide an attacker with the most opportunity to damage the system, an analyst (Proactive or Reactive) can act accordingly, trying to limit the options available to an attacker as much as possible (knowing that there is likely a budget limiting remediation). The output from the Attack Graph Analyzer is provided to the Course of Action Analyzer (COAA), in order to compute recommended remediations. The AssetRank algorithm developed at DRDC (see subsection 4.4.5.7.1) is leveraged in performing the analysis of attack graphs.
4.4.5.7.1 AssetRank Algorithm “AssetRank is a statistical analysis system that consumes a listing of assets and their dependencies and generates an understanding of their value by assigning a ranking to the assets based upon the system dependencies. The system is stochastic, meaning there is an assumption that a random selection at one point in the system does not bias random selections at other points in the system. The system extends Google’s PageRank algorithm by analyzing AND and OR vertices in a semantically consistent way, modeling diverse actors, and accounting for out-of system influences.” [Ref 1]
4.4.5.8 Incident Analyzer Security event data from DREnet security data sources (such as Intrusion Detection/Intrusion Prevention Systems (IDS/IPS), firewalls, routers, Security Information and Event Management (SIEM), etc.) is collected by the various supporting Data Source Connectors. This data is collected in a Security Onion instance integrated with ARMOUR. Network Operators use Security Onion to raise incidents to ARMOUR. The ARMOUR Incident Analyzer module uses a built-in rules engine, to determine how to handle the incidents. Critical incidents may generate “Direct Courses of Action” which bypass the ARMOUR Computational Service chain. In most cases however, ARMOUR automatically generates appropriate attack graphs and analyses in order to compute recommended remediations. If the recommended remediation lost-cost is below the configured System-Wide Loss-Cost Threshold, then ARMOUR attempt to
Use or disclosure of this data is subject to the restriction on the title page of this document.
W7714-115274/001/SV ARMOUR TD System CONOPS Unclassified Version F 21 April 2017 Unclassified 43 740928
automatically effectuate the associated Courses of Action. Otherwise, the Reactive Analyst needs to inspect the recommendations and effectuate manually.
4.4.5.9 Course of Action Analyzer The Course of Action Analyzer provides a prioritized list of recommended remediations in response to identified attack graph analyses provided by the Attack Graph Analyzer (see section 4.4.5.7). The data provided to the COAA includes the loss cost for removing an attack path. Since there may be many ways to remove a given path, the lowest cost is used, based on a list of known CoA templates and indirectly, effectors. The COAA analyzer provides recommended remediation sets prioritized by cost, fitting under a user-provided budget for the Proactive case. In the Reactive case, the System-Wide Loss-Cost Threshold is used as the budget. For each recommended remediation set, ARMOUR computes the resultant security posture. Figure 15 shows the COA Analyzer block diagram.
FIGURE 21. COA Analyzer Block Diagram The core of the COA Analyzer is the continuously updated and approved COA Template library. This library contains the complete set of all COAs that have been approved for deployment, their component actions, associated costs, associated reversal COAs, and their mappings to the effector technologies available to ARMOUR. Once the recommended remediations have been computed, the CoA Generator generate a list of potential CoAs for each recommendation, sorted by cost and delta SPM. In the automated response (reactive) use case, the lowest cost CoA is selected as the effectuation goal, if it falls below the System-Wide Loss-Cost Threshold: the reactive analyst may decide to cancel the automated effectuation within a configured time window. In the semi-automated response (proactive) use case, the analyst decides which CoA best fits the recommendation and may elect to exceed the budget in order to provide the best solution.
Use or disclosure of this data is subject to the restriction on the title page of this document.
W7714-115274/001/SV ARMOUR TD System CONOPS Unclassified Version F 21 April 2017 Unclassified 44 740928
The Recommended Remediation approval process for the semi-automated response requires that the entire list of available CoAs be presented to the analyst. This list will provide all recommendations within a set budget, and will include information about the increase to the security of the system provided by the COA (per the Security Posture Metric) and the value to an attacker of the assets removed. The operator may select one or more COAs from the available list, or reject the list entirely. Once COA selections have been made, a response is generated and sent to the Effector. The Course of Action Decision Support (COADS) algorithms developed by DRDC (subsection 4.4.5.9.1) will be leveraged for the evaluation of COAs and creation of the set presented to the user for application.
4.4.5.9.1 Course of Action Decision Support (COADS) “COADS is a graph analysis system that consumes a listing of assets with their rank and removal cost, their dependencies, source assets, target assets, and a maximum removal budget. COADS generates a course of action, within budget, which consists of an optimized set of asset removals which maximally disrupts connectivity between the source and target assets. When consuming a MulVAL attack graph that has been ranked with AssetRank, the course of action suggests patches to apply, services to shut down, and network routes to cut, to maximally disrupt attackers’ freedom of movement between sources and targets.” [Ref 1]
4.4.5.10 Semi-Automated Response Semi-automated response occurs when human interaction is required in response to Recommended Remediations. In this case, automated thresholds are exceeded and the effecting of the COA requires human interaction (i.e., sent to an analyst for selection and approval). After the human interaction, the courses of action are executed via a standard workflow.
4.4.5.11 Automated Response Automated response is the process by which COAs are generated in response to an incident and executed directly without human interaction. In the case of the Automated Response, the COA is provided directly to the appropriate effector connector. The operator monitors the execution of all COAs and their status from the Effector Progress widget. If there is a problem, the operator is responsible for cancelling or reversing the COA.
4.4.6 Effector Connector and Effectors “The Effector Connectors component provides an interface to the Off-The-Shelf products that are used to implement the courses of action.” [Ref 2] The ARMOUR CoA Controller generates sequenced OpenC2 XML messages that are directed to the Effector Connector (EC). The EC provides routing of OpenC2 messages to the correct effector and feedback to ARMOUR via the DSC Data Diode.
Use or disclosure of this data is subject to the restriction on the title page of this document.
W7714-115274/001/SV ARMOUR TD System CONOPS Unclassified Version F 21 April 2017 Unclassified 45 740928
Effectors support individual technologies that effect change on the network. Each effector type must be registered in the ARMOUR Effector Registry and associated within CoA template activities. Each effector activity in the CoA templates is given reactive and proactive costs. Since each technology expects data to be provided in different forms, the effectors are responsible to translate the OpenC2 message to appropriate data or commands to match the integrated technology. OpenC2 status messages are fed back to ARMOUR with status messages, a tracking id (if provided by the technology) and a status enumeration (COMPLETED, ERROR, etc.). The following effectors are provided with ARMOUR: Trigger: re-scan a given data source; Redmine: adds tickets in the Redmine issue management system; Checkpoint: add/delete/modify checkpoint firewall rules; Router: add/delete/modify routes for Cisco routers; Patch: applies software patches for Linux systems.
Use or disclosure of this data is subject to the restriction on the title page of this document.
W7714-115274/001/SV ARMOUR TD System CONOPS Unclassified Version F 21 April 2017 Unclassified 46 740928
5. SYSTEM SECURITY, SECURITY PLAN AND SECURITY CONOPS
5.1 Overview
This chapter serves as the ARMOUR TD security plan and security CONOPS which is consistent with Government of Canada, DND and DRDC enterprise architecture.
5.2 Security Approach
The ARMOUR system security uses the defence-in-depth approach to provide multiple layers of technical, managerial and operational security controls in accordance with the ARMOUR System Requirement Specification (SRS) (GDMS-C document No. 740930) and ARMOUR TD Security Assessment and Authorization Report (GDMS-C document No. 742096).
This approach includes the integration of overlapping protection measures to address security concerns introduced by personnel, technology, physical and operational aspects of information technology. The intent of the defence-in-depth approach is to provide redundancy such that in the event where one control fails, is circumvented or a vulnerability is exploited, a supporting control would provide additional measures to restrict or delay access to the targeted asset.
5.3 Security Categorization and Domain Control Profile
ARMOUR TD will connect to the Ottawa segment of the PROTECTED A DREnet. Therefore, as determined, rationalized, substantiated and documented via the ARMOUR TD Security Categorization Report (GDMS-C document No. 742605), the appropriate ARMOUR security categorization is (PROTECTED B confidentiality, LOW integrity, VERY LOW availability) and its domain profile is DND’s Designated MEDIUM MEDIUM (DMM) domain control profile.
5.4 Security Control Profile
The ARMOUR TD security control requirements are listed in the ARMOUR TD security control profile which is a tailoring of the DMM domain control profile. The ARMOUR TD security control profile, the rationale for the tailoring and supplementation decisions are provided in ARMOUR TD Security Assessment and Authorization Report (GDMS-C document No. 742096).
5.5 Security Control Profile Implementation
The security controls in place or planned for meeting the ARMOUR TD security control profile are in the security controls traceability matrix provided in the ARMOUR TD Security Report (GDMS-C document No. 742152).
Use or disclosure of this data is subject to the restriction on the title page of this document.
W7714-115274/001/SV ARMOUR TD System CONOPS Unclassified Version F 21 April 2017 Unclassified 47 740928
5.6 Security Authorization and Assessment Schedule
The security authorization and assessment schedule is provided in the ARMOUR TD Project Management Plan (GDMS-C document No. 995012), and ARMOUR TD Security Assessment and Authorization Report (GDMS-C document No. 742096).
5.7 Security Authorization Boundary
The ARMOUR TD authorization comprises:
Server(s) and laptop(s) in the ARMOUR enclave;
The ARMOUR diode(s) that segregates the ARMOUR enclave from the DRDC Ottawa segment of the DREnet; and
ARMOUR data sources and data source collectors on the DRDC Ottawa segment of the DREnet.
5.8 Other Security Plan and CONOP -Related Information
The following is provided and described in Sections 3 and 4:
ARMOUR TD purpose;
Operational context in terms of missions and business processes;
Operational environment for the information system;
Security mode; and
Relationships with, and connections to, other information systems.
ARMOUR TD system architecture is provided and described in ARMOUR TD Architectural Design Document (GDMS-C document No. 995015).
Use or disclosure of this data is subject to the restriction on the title page of this document.
W7714-115274/001/SV ARMOUR TD System CONOPS Unclassified Version F 21 April 2017 Unclassified 48 740928
6. MAINTENANCE AND SUPPORT During the development contract of the ARMOUR TD, GDMS-C support will be provided for all technical and licensing issues observed at the Client site. Any technical observations or bugs will be documented and maintained according to the System Problem Reporting (SPR) process that is documented within ARMOUR TD Project Management Plan (GDMS-C document No. 995012). The GDMS-C SPR process defines how to receive record, prioritize, escalate, resolve, and close problems; how to control the impact of problems; and how to provide feedback. Additionally, GDMS-C personnel will provide on-site support for deployment and maintenance of all GDMS-C provided hardware and software.
Use or disclosure of this data is subject to the restriction on the title page of this document.
W7714-115274/001/SV ARMOUR TD System CONOPS Unclassified Version F 21 April 2017 Unclassified 49 740928
7. TEST AND DEMONSTRATION System Testing is used to assess and measure the overall behaviour and performance the system. The test concept is documented in the ARMOUR TD Test Design and Environment Document, GDMS-C document No. 740931. Demonstrations are vital for maintaining operational client support and for generating national interest in the ARMOUR TD Project. The intent of the demonstrations is to: a. Evaluate the system and the quality of the resulting capabilities in accordance with the test environment, test scenarios and test data; b. Compare the results to the expected outcomes and expected test results; and c. Direct (or redirect) the project accordingly. Demonstrations are performed for Phases 2 through 5, typically at the end of the phase. One laboratory demonstration and three operational demonstrations are to be planned. The Phase 2 demonstration will take place in the Cyber Operations Section Lab Environment while the remaining demonstrations will use a subnet of the DREnet. The laboratory demonstration will be used to demonstrate the workings of the Integration Framework and GUI. The first operational demonstration (Phase 3) will include the “Proactive Observe and Orient” functions. This will include the capabilities to identify attacks that are possible before they occur. The second operational demonstration (Phase 4) will include the “Proactive Decide and Act” functions. This will include the capabilities to prioritize courses of action and allow them to be implemented with operator approval. The third operational demonstration (Phase 5) will include the capabilities for “Reactive Response” to detect cyber-attacks on the infrastructure. In all demonstrations, the target operational network to be used will be an operational subnet of the Defence Research Establishment network (DREnet). Demonstrations are preceded by a Demonstration Plan and Demonstration Instance document. The Demonstration plan includes a description of the demonstration objectives, scenarios, environment and steps to be executed. It is delivered in accordance with DID DM 001: Demonstration Plan. The Demonstration Instance consists of the ARMOUR TD project instance delivered as part of the hardware, software and documentation deliverable, and the required hardware and software required for the system demonstration defined in the Demonstration Plan. This document is prepared in accordance with DID DM 002: Demonstration Instance. After completion of the demonstration, a Demonstration Report will be provided in accordance with DID DM 003: Demonstration Report. The demonstration process is documented in the ARMOUR TD Project Management Plan (GDMS-C document No. 995012).
Use or disclosure of this data is subject to the restriction on the title page of this document.
W7714-115274/001/SV ARMOUR TD System CONOPS Unclassified Version F 21 April 2017 Unclassified 50 740928
8. NOTES
8.1 Abbreviations The following abbreviations have been used in this document. ADD Architectural Design Document ARMOUR Automated Computer Network Defence CDXI Cyber Security Data Exchange and Collaboration Infrastructure CFIOG Canadian Forces Information Operations Group CFNOC Canadian Forces Network Operations Centre CIA Common Infrastructure Abstraction CND Computer Network Defence COA Course of Action COADS Cyber Operations Sections Course of Action Decision Support CONOPS Concept of Operations COP Common Operating Picture COTS Commercial Off-The-Shelf CSC Cross Source Correlation DDD Detailed Design Document D IM Secur Director Information Management Security DG Cyber Director General Cyber DID Data Item Description DIMEI Director Information Management Engineering and Integration DIMTPS Director Information Management Technologies, Products and Services DLCSPM Director, Land Command Systems Program Management DMZ Demilitarized Zone DND Department of National Defence DNS Domain Name Service DRDC Defence Research & Development Canada DREnet Defence Research Establishment Network DWAN Defence Wide Area Network EIF Enterprise Integration Framework GC Government of Canada GDMS-C General Dynamics Mission Systems – Canada GUI Graphical User Interface IDK Integration Development Kit IDS Intrusion Detection Service IF Integration Framework IP Internet Protocol IPS Intrusion Prevention Service
Use or disclosure of this data is subject to the restriction on the title page of this document.
W7714-115274/001/SV ARMOUR TD System CONOPS Unclassified Version F 21 April 2017 Unclassified 51 740928
IS Information System IT Information Technology LCSS Land Command Support System NetC2 ISAC Network Command and Control Integrated Situation Awareness Capability OIA Operations and Infrastructure Analyzer OODA Observe, Orient, Decide and Act OSS Open Source Software OWF Ozone Widget Framework PCI DSS Payment Card Industry Data Security Standard R&D Research and Development SA&A Security Assurance and Accreditation SIEM Security Information and Event Management SOW Statement of Work SPR System Problem Reporting SRS System Requirement Specification STS System Technical Specification TCP Transmission Control Protocol TD Technology Demonstration USB Universal Serial Bus
Use or disclosure of this data is subject to the restriction on the title page of this document.
W7714-115274/001/SV ARMOUR TD System CONOPS Unclassified Version F 21 April 2017 Unclassified 52 740928
This page is left blank intentionally.
Use or disclosure of this data is subject to the restriction on the title page of this document.
W7714-115274/001/SV ARMOUR TD System CONOPS Unclassified Version F 21 April 2017