System Concept of Operations (CONOPS)cradpdf.drdc-rddc.gc.ca/PDFS/unc280/p805540_A1b.pdfSystem Concept of Operations (CONOPS ... in which the solution will operate. The System CONOPS

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.

S

A

This dunder11527accord

Def

System C

Automated

Techn

document was r Public Works74/001/SV. Usedance with the T

Genera

Co

© HER MAJ

fence Resea

7

Concept o

Computer

ology Dem

prepared by Gs and Governme and disseminTerms and Con

Pre

al Dynamics Land and1020-68

Calgary,

21

ontract No. WCD

ESTY THE QU

Pre

arch & Deve3701 C

Ottawa, O

40928F

of Operatfor the

Network De

onstration (

eneral Dynamicment Service Cnation of the iditions Contrac

epared By:

Mission Sysd Joint Solut8th Avenue NAlberta T2E

April 2017

W7714-1152DRL SD009

UEEN IN RIGH

epared For:

elopment CaCarling AvenOntario K1A

ions (CO

efence (AR

(TD) Contra

cs Mission SysCanada Contrainformation her

ct No. W7714-11

stems – Cantions N.E.

E 8P2

274/001/SV

T OF CANADA

anada (DRDCnue A 0Z4

ONOPS)

RMOUR)

act

stems – Canadact No. W7714rein shall be i15274/001/SV.

ada

A (2017)

C) - Ottawa

a 4-n

Unclassified A 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

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

Unclassified B 740928



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

Unclassified D 740928



This page is left blank intentionally.

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

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

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

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

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




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




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]




“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.




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.




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 W7714-115274-SV Annex A

Statement of Work for the ARMOUR TD, 03 May 2013, v2.1

[Ref 2] ARMOUR TDP Contract W7714-115274-SV Annex B

System Technical Specification for the 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)




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.




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




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




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.

Unclassifi

Us

W7714-11Unclassifi

Once theresolve thSimulatiomitigatiopoint (iniattack pa

In either context omaintainrouter thadevice regraph is gvector, Asecure/mmitigatioAsset D othe vulnebased onmission o

3.3 E

Interactioknown asa one-wa

As ARMthe transmnetwork

Separate the effect

ed

se or disclosu

15274/001/SVed

e attack graphhe vulnerabion of the CO

on. The COAitially infect

ath.

case, the imof the systemed and not nat connects aequired for mgenerated sh

ARMOUR womitigate risk aon could be ion the routererability of th the propagaobjectives.

External Inte

ons to other s a unidirectay transfer de

MOUR is depmission of d(i.e., DREne

one-way trator interface

ure of this dat

V

h is generateilities thereb

OAs demonstAs recommeed asset) and

mpact of the mm as a wholenegatively imasset B, C an

mission survihowing a potould generatassociated wn the form or, patching thhe identifiedation capabil

erfaces

domains cantional networevice to enfo

FIGUR

loyed withindata to Effectet) is manage

ansfer device to transfer e

ta is subject to

V

ed, COA Recy mitigatingtrates to the

ended could id/or removin

mitigation ac. The intent

mpacted as a nd D togetheivability. If Atential explote the COA l

with any poteof (but not limhe vulnerabi

d exploit on Alities of the a

n be restricterk or unidireorce traffic f

RE 2. One-w

n its own enctor technologed via a secu

es can be useeffector outp

11

o the restrictio

Version F

commendatig the propaga

operator theinclude remong the vulner

ctivities (COof this is to result of the

er. Asset D hAsset B is d

oit to Asset Dlist with the ential threat vmited to) remility of the idAsset A. Thattack, the pr

ed by using oectional secuflow between

way Transfer

clave, the cogies hosted iure perimete

ed on the datputs to the ta

on on the title

A

ions are provation of the ae impact of ioving the vurability from

OA) is analyzensure that

e change. Fohas been ide

discovered toD (high prior

highest rankvector that cmoving any dentified exphe highest ranriority assets

one-way tranurity gatewayn two netwo

r Flow Cont

ollection of din the infrast

er and interfa

ta source or arget network

e page of this

ARMOUR TD

vided to the attack any fuimplementinulnerability fm assets furth

zed based onoperational or example, entified as a ho be infectedrity asset) thrked COA intcould impactroute betwe

ploit on Assenked COA ws with the att

nsfer (e.g., dy. Figure 2 drks.

trol

data from Datructure or thace point.

ingestion ink.

74

document.

D System CON21 April

operator to urther.

ng the risk from the attaher down in

n the global priorities areAsset A is a high priority

d, and an attarough an attatending to t Asset D. Then Asset B aet D or patchwould be seltack path an

data diode) adepicts the u

ata Sources ahe managed

nterface and o

40928

NOPS l 2017

ack the

e

y ack ack

his and hing ected

nd

lso se of

and

on

Unclassifi

Us

W7714-11Unclassifi

4. O

This sectTD is intsecurity oprovide tsecurely

The procOODA loto this m

As shownphase, Dreactive (

4.1 O

“Initiallyinto the sanalyzedcombinedrules anddata struc

ed

se or disclosu

15274/001/SVed

OPERATION

tion outlines tended to creof DND netwthe ability todesigned, ev

cesses involvoop concept ethodology.

n in Figure 3ecide phase (subsection 4

Operational

y, network insystem. Thisd to determind with rules

d data) in thecture giving

ure of this dat

V

NAL CONC

the operatioeate and demworks by pro

o pre-empt atven before th

ved in CND cshown in FiThe ARMO

FIGURE 3

3, the OODAand Act pha4.1.2) respon

Overview

nformation is information

ne the relativdescribing a

e network. Ththe pre-cond

ta is subject to

V

CEPT

onal conceptmonstrate an oviding an Attacks and ofhey are procu

can be descrigure 3. All C

OUR solution

3. OODA Lo

A loop includase. Within enses are app

s captured usn is correlateve operationaattack technihe potential ditions and p

12

o the restrictio

Version F

ts that apply integrated sy

Automated Cffer a planninured.” [Ref 2

ribed as a cloCND eventsn operates ac

oop Operatio

des four disteach phase, plied to enhan

sing deployeed, and abstral importanciques to comattacks are c

post-conditio

on on the title

A

to the ARMystem that w

CND capabiling capability2]

osed loop pr observed on

ccording to t

onal Model

tinct phases; proactive (sunce the secu

ed tools and racted into see of hosts an

mpute all poschained togeons for each

e page of this

ARMOUR TD

MOUR TD. “will substantiity. The systy to ensure n

rocess accordn the networthe OODA p

[Ref 2]

The Observubsection 4.1urity posture

operational ets of useful nd software. sible attack

ether and sto attack step.

74

document.


The ARMOUially improvtem will servnetworks are

ding to the rk can be app

process.

ve phase, Ori1.1) and/or of the netwo

impact is endata. The daThe data ispaths (given

ored in a grapThe networ

40928

NOPS l 2017

UR ve the ve to e

plied

ient

ork.

ntered ata is

n the ph rk’s




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.




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]




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.

Unclassifi

Us

W7714-11Unclassifi

Each phain the fol

4.3.1 O

“In the Ofrom sengenerated

System ininformatiagents in(hardwarfrom onemanagemand host

This actiooutput ofstate of th

ed

se or disclosu

15274/001/SVed

FI

ase, along willowing secti

Observe Pha

Observe phassors and netd.

nformation wion) and inte

nstalled on enre and softwae or multiplement and map

event logs, a

on is depictef this action phe network.

ure of this dat

V

IGURE 4. A

ith a descripions.

ase – Collect

se, both assettwork manag

will include ernal infrastrnd hosts to care) installed sources. Expping systemand firewall

ed by the “Bprovides a m

ta is subject to

V

ARMOUR H

ption of the p

t and Fuse D

t and operatigement syste

both externaructure data.collect and std at various

xamples of inms, intrusionpolicies.” [R

uild Networmodel of the

16

o the restrictio

Version F

High Level C

proactive and

Data

ions data wiems will push

al reference Internal infrtore that asselocations in nternal infrasn detection syRef 2]

rk Model & Rnetwork tha

on on the title

A

Concept of O

d reactive co

ill be collecteh data to AR

data (e.g. vufrastructure det’s data, or the networkstructure datystems, vuln

Reachabilityat represents

e page of this

ARMOUR TD

Operations

oncepts, is de

ed and storeRMOUR as t

ulnerability adata may be special purp

k may be useta sources innerability sc

y” activity inthe topology

74

document.


escribed in d

d. Informatithe data is

advisory obtained fro

pose devices ed to collect nclude netwoanners, netw

n Figure 4. Ty and securi

40928

NOPS l 2017

detail

ion

om

data ork work

The ity




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]




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




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]




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.




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:




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.

Unclassifi

Us

W7714-11Unclassifi

provides (i.e., repoobserved

4.4.4.1

Icons witdistinct aIndicator

Infrastruc

- E- R- S- H- F- ID- E- V- N- L

Security a.

bbc.

ed

se or disclosu

15274/001/SVed

the operatororts), observd/simulated e

Object R

thin the grapand intuitive rs (SSI).

cture icons r

End Host, Router,

witch, Hub,

irewall, DS,

External HostVirtual MachNAT and Laboratory N

Status Indic. Uncertain

available). Disconne. Security m. Presence

ure of this dat

V

r with an inteve security evevents.

Representati

phical windorepresentati

represent mu

t, ine,

Network.

ators are shon status (e.g.,); cted status; metric and dof vulnerabi

ta is subject to

V

erface to visvents, initiat

on

ows are used ions of opera

ultiple host ty

FIGURE 6

own in FIGU, hosts identi

degree of depilities;

23

o the restrictio

Version F

sualize the toe analysis an

to representations and in

ypes, as show

6. Host Type

URE 7. SSIsified but cor

pendency val

on on the title

A

opology, prond simulatio

t objects andnfrastructure

wn in FIGU

e Icons

s represent thrresponding

lues;

e page of this

ARMOUR TD

vide data inpon, and respo

d data overlae as well as S

URE 6:

he followingsoftware inf

74

document.


put, view ouond to

ays. Icons areSecurity Stat

g states: formation is

40928

NOPS l 2017

utput

e tus

not

Unclassifi

Us

W7714-11Unclassifi

de.f.g

Icons incAttributeoperator high valu(ODM) i

ed

se or disclosu

15274/001/SVed

. Likely oc

. Sequence Attack va. Course of

course of

clude additioes may includwith a visua

ue asset, opes represente

ure of this dat

V

currence of attack path

alue (e.g., crif action implaction).

FIG

onal visual dede, but are n

al indication rational critid by a colou

FIG

ta is subject to

V

compromise(source, targ

iticality of a lication (e.g.

GURE 7. Se

etails/attribunot limited to

of various cicality, etc.).

ured backgro

GURE 8. Se

24

o the restrictio

Version F

e; get, and hop)host within

., effect of se

ecurity Status

utes regardino colour, sizecharacteristic As an exam

ound, as show

ecurity Status

on on the title

A

); an attack pa

electing or d

s Indicators

ng the compoe and backgrcs of the objemple, the Opwn in FIGUR

s Indicators

e page of this

ARMOUR TD

ath); and deselecting a

onent they reround, and pect (i.e., asse

peration DepRE 8.

74

document.


a particular

epresent. provide the et compromi

pendency Me

40928

NOPS l 2017

ised, etric




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;




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

Widget Proactive Security Analyst

Reactive Security Analyst

Network Operator

Systems / Configuration

Manager Administrator Commander

OWF Administrator CRUD

LDAP Administrator (389 Console)

X

PostgreSQL Admin (pgAdmin III)

X

ARMOUR IF Admin (Hawt.io)

CRUD

ARMOUR Data Ingestion Dashboard

R R R R R R

Workflow Ticket System (Redmine)

X X X X X X

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 Requests

CRUD CRUD CRUD R

Vulnerability List CRUD CRUD CRUD R

Vulnerability Details CRUD CRUD CRUD R

Firewall Details CRUD CRUD CRUD R

Host History R R R R




Widget Proactive Security Analyst

Reactive Security Analyst

Network Operator

Systems / Configuration

Manager Administrator Commander

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.

Unclassifi

Us

W7714-11Unclassifi

4.4.4.2.1

The Infraof displayinfrastruc

12567

ed

se or disclosu

15274/001/SVed

Infrastr

astructure Grys provides cture group i. Network T. Inventory. Host Hist. Reachabil. Incident L

ure of this dat

V

FIGURE 9

ructure Gro

roup is the pboth graphicis supportedTopology;

y (Host Summtory Data; lity; List and Deta

ta is subject to

V

. Presentati

oup

primary intercal and tabul

d by the follo

mary List) a

ails;

28

o the restrictio

Version F

on Groups w

rface to visualar widgets t

owing widge

nd Host Det

on on the title

A

within OODA

alize the netto represent tets:

tails;

e page of this

ARMOUR TD

A Loop

twork topolothe infrastru

74

document.


ogy. This gructure. The

40928

NOPS l 2017

oup

Unclassifi

Us

W7714-11Unclassifi

91

The Infra

4.4.4.2.1

The “Topthe physiare used Compromdetermin

4.4.4.2.1

The “Invby the syinformatiand the IP

ProvidingInventoryinformaticonfigura

Figure 7

ed

se or disclosu

15274/001/SVed

. Alert Too0. Vulnerabi

astructure Di

.1 Topol

pology” widgical networkin this widg

mised, etc.). ned by the rea

.2 Inven

ventory” widystem and repion about eaP Address.

g more detaiy widget to dion containeation.

depicts the A

ure of this dat

V

lbar; and ility List and

isplay Group

logy Widget

get shown ink topology - tet to provide The Topoloachability an

ntory and H

dget shown inpresented gr

ach host inclu

iled informadisplay the ded in the Inve

ARMOUR d

ta is subject to

V

d Details.

p supports th

t

n FIGURE , the network e visual indicogy widget cnalyzer, usin

FIGURE 10

Host Details W

n FIGURE 1raphically in uding but no

tion is the “Hdetailed inforentory list as

deployment s

29

o the restrictio

Version F

he Observe P

provides thedevices andcation of the

can also dispng graphic ov

0. Topology

Widget

11, provides the topolog

ot limited to,

Host Detail”rmation colls well as add

showing all

on on the title

A

Phase of the

e operator wd the links bee node’s statuplay the reachverlays on th

y Widget

a list (tabulagy widget. T, the hostnam

” widget. Thlected on theditional infor

three suppor

e page of this

ARMOUR TD

OODA Loo

with a visual etween the hus (e.g., Vulhability graphe topology

ar) of the hoThis list provme, a descrip

his widget ise host. This rmation pert

rting Infrastr

74

document.


op.

representatiohosts. Overlanerable,

ph connectivGUI.

osts discovervides high levption of the h

accessed viincludes all

tinent to the

ructure view

40928

NOPS l 2017

on of ays

vity

ed vel host

ia the the host

ws.

Unclassifi

Us

W7714-11Unclassifi

4.4.4.2.1

The Hostselected hany of th

4.4.4.2.1

The Reacnodes wiidentify cinformatibetween

ed

se or disclosu

15274/001/SVed

.3 Host H

t History widhost. Histor

he ARMOUR

.4 Reach

chability Wiithin the netwconnectivityion. Upon usource and d

ure of this dat

V

History Wid

dget shown iric informatiR data source

F

hability Wid

dget providework. This w between sou

user request, destination h

ta is subject to

V

FIGURE 11

dget

in FIGURE on shows whes as well as

IGURE 12.

dget

es the reachawidget allowurce and desthis widget

hosts.

30

o the restrictio

Version F

1. Inventory

12, includeshen new dat

s what the ch

Host Histor

ability detailws users to qustination hoscan also disp

on on the title

A

y Widget

s historic infta was ingesthanges were.

ry Widget

ls that descriuery the Reasts includingplay the bloc

e page of this

ARMOUR TD

formation peted for a par.

ibe the logicaachability An

g port and procked paths a

74

document.


ertinent to a rticular host

al links betwnalyzer to otocol and ports

40928

NOPS l 2017

from

ween

Unclassifi

Us

W7714-11Unclassifi

4.4.4.2.1

The Incidwhere op

Supplemwidget prallows us

ed

se or disclosu

15274/001/SVed

.5 Incide

dent List widperators can

mental to the Irovides morsers to add n

ure of this dat

V

F

ent, Inciden

dget shown iview high le

Incident list e detailed in

notes to each

FIGU

ta is subject to

V

FIGURE 13.

nt Details an

in FIGURE evel details r

is the Incidenformation oh incident.

URE 14. In

31

o the restrictio

Version F

Reachabilit

nd Alert Too

14, displaysregarding an

ent Detail win the highlig

ncident Summ

on on the title

A

ty Widget

olbar

s the summarny of the obse

idget, shownghted inciden

mary Widget

e page of this

ARMOUR TD

ry list of secerved securi

n in FIGUREnt from the I

t

74

document.


curity incidenity incidents

E 15. This Incident list

40928

NOPS l 2017

nts .

and

Unclassifi

Us

W7714-11Unclassifi

When secframewooccurred

1

2

3

Each indbeen obshave bee

The Aler

4.4.4.2.1

The Vulnpresent oInventoryVulnerab

4.4.4.2.2

The Opermissions

ed

se or disclosu

15274/001/SVed

curity inciderk provides . The Alert t. Low Seve

the alert t. Medium S

sphere in . High Seve

the alert t

dicator includerved. The un grouped a

rt toolbar is d

.6 Vulne

nerability Deon selected hy widget, thebility Detail w

Operat

rational View. This interfa

ure of this dat

V

FIG

ents are obsea visual inditoolbar proverity Events oolbar. Severity Evethe alert tooerity Events oolbar.

des a counteruser is able ts that severit

depicted in F

erability Lis

etails widgethosts. When e vulnerabiliwidget.

ional Group

w provides iace fully util

ta is subject to

V

GURE 15. I

erved, an Aleication to thevides three le– Events of

ents - Eventsolbar.

- Events of

r next to it toto click on thty.

FIGURE .

FIGURE

st and Detai

t provides dean operator

ity and explo

p

nterfaces forlizes infrastr

32

o the restrictio

Version F

Incident Deta

ert toolbar loe user that a evels of sevelow severity

s of medium

high severit

o identify hohe sphere an

16. Alert To

il Widget

etailed informselects a ho

oit details are

r the creationructure data

on on the title

A

ails Widget

ocated in thesecurity inc

erity indicatiy are represe

m severity are

ty are represe

ow many incnd bring up a

oolbar

mation on vuost from the Te automatica

n, managemfor validatio

e page of this

ARMOUR TD

e banner bar cident of inteion: ented by the

e represented

ented by the

cidents of thaa list of all in

ulnerabilitiesTopology wially populate

ment, and moon of scenari

74

document.


of the OWFerest has

Green spher

d by the Amb

e Red sphere

at severity hncidents that

s and exploiidget or the ed in the

onitoring of ios.

40928

NOPS l 2017

F

re in

ber

e in

ave t

ts

Unclassifi

Us

W7714-11Unclassifi

Once an time. ThiOperationstructureposture oonly the r

The Oper17.

The Oper

4.4.4.2.3

Speculatito simulamodify dwidgets a

While in are not shnetwork using the

The Spec

In V R C U H

ed

se or disclosu

15274/001/SVed

operation hais includes vns can also bs. These com

of the entire resources th

rational Gro

rational Gro

Specula

ive Analysisate changes tdata, computare only avai

the Speculahown to the situation, the

e User View

culative Ana

nventory widVulnerability Reachability ComputationaUser View CoHistorical Da

ure of this dat

V

as been estabvulnerability,be grouped immand struccommand. Oat are most r

up only cont

FIGUR

up supports

ative Analys

s Group widgto the infraste attack grapilable in pro

ative Analysiuser: the widey must exitController w

alysis widget

dget; widget; widget; al Services wontroller widata List widg

ta is subject to

V

blished, its a, security pointo larger orctures providOperations arrelevant to th

tains the Op

RE 17. Opera

the Observe

sis Group

gets give usetructure, nonphs and viewactive mode

is mode, on-dgets are loct the Speculawidget.

ts are:

widget; dget; and get.

33

o the restrictio

Version F

assets, depensture, as welrganizationa

de the meansre searchablhe operator a

perational De

ational Depe

e Phase of th

ers the abilityn-infrastructuw potential ee of operation

going securicked in timeative Analysi

on on the title

A

ndencies andll as connect

al units to pros to gauge the and filteraat any given

ependency W

endency Wid

he OODA Lo

ty to analyzeure and mod

effects of thon.

ity incidents. If users wais mode and

e page of this

ARMOUR TD

d status can btivity informoduce one or

he overall staable to facilitn time.

Widget, show

dget

oop.

e historical andels. Users aose modificat

s and data coant to view t

d return to th

74

document.


be viewed at mation.

r more commatus and secutate display o

wn in FIGUR

nd current dare allowed ttions. These

ollection evethe current e Live mode

40928

NOPS l 2017

any

mand urity of

RE

data to e

nts

e,




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.

Unclassifi

Us

W7714-11Unclassifi

When attin FIGUR

Generatiotarget froInventoryany of thmodified

ed

se or disclosu

15274/001/SVed

tack paths arRE .

on of the attaom within any, and Opera

he attacker atd from within

ure of this dat

V

FIGUR

re located, an

F

ack graph isny view that ational Viewttributes thatn this interfa

ta is subject to

V

RE 18. Attac

nalysts can v

FIGURE 19.

accomplishcan display ). This origit are relevantace at any tim

35

o the restrictio

Version F

k Graph Gen

view the resu

Attack Path

hed through sindividual oin defines tht to the simu

me.

on on the title

A

neration Wid

ults using th

th Widget

selection of or abstractedhe starting poulation. Thes

e page of this

ARMOUR TD

dget

e Attack Pat

a threat origd hosts (e.g., oint for the ase origins ca

74

document.


th widget, sh

gin and attackTopology,

attack as weln be created

40928

NOPS l 2017

hown

k

ll as d or




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




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.




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




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.

Unclassifi

Us

W7714-11Unclassifi

In generaHoweverotherwisemanuallythat are n

4.4.5.4

This is thautomatecomputatservices:

- on- R

sico

ed

se or disclosu

15274/001/SVed

al, the entire r, a manual oe edit the finy add hosts thnot relevant t

Common

he process ofed grouping tional servic

ne-to-one: thReachability ingle subnet ombined hos

ure of this dat

V

FIGU

reachabilityover-ride capnal reachabilhat are unreato the user’s

n Infrastruc

f identifyingand abstract

ce and yields

his abstractoand Operatinthat have th

sts are merge

ta is subject to

V

URE 20. Sam

y analyzer oppability existlity informatachable thro interests, or

ture Abstra

g common ortion. The abs better user

or is a pass-thng System (R

he same opered into one “

40

o the restrictio

Version F

mple Reacha

perates throuts to enable ttion as desireough normal r annotate ho

action

r similar hosstraction proexperience.

hrough and pReachOS): trating system“super” host

on on the title

A

ability Graph

ugh automatethe user to aed. For examdata-collect

osts with add

sts within theovides a redu ARMOUR

performs no this abstractom. All servict.

e page of this

ARMOUR TD

h

ed retrieval add to, deletemple, it may tion means, tditional info

e network touced datasetprovides tw

reduction; aor combineses and vulne

74

document.


of network de from or be necessaryto remove hormation.

o allow for t for

wo abstraction

and s all host witherabilities fo

40928

NOPS l 2017

data.

y to osts

n

hin a or all




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.




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




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.




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.




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.




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).




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).




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.




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).




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




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




This page is left blank intentionally.