740928b system concept of operations (conops)cradpdf.drdc-rddc.gc.ca/pdfs/unc197/p800128_a1b.pdf ·...

740928B

System Concept of Operations (CONOPS)

for the

Automated Computer Network Defence (ARMOUR)

Technology Demonstration (TD) Contract

Contract No. W7714-115274/001/SV

This document was prepared by General Dynamics Canada under Public Works and Government Service Canada Contract No. W7714-115274/001/SV. Use and dissemination of the information herein shall be in accordance with the Terms and Conditions Contract No. W7714-115274/001/SV.

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.

© HER MAJESTY THE QUEEN IN RIGHT OF CANADA (2014)

Prepared For: Defence Research & Development Canada (DRDC) - Ottawa

3701 Carling Avenue Ottawa, Ontario K1A 0Z4

CSA: Nacer Abdellaoui, (613) 998-4582

Prepared By:

General Dynamics Canada Ltd. Land and Joint Solutions 1020-68th Avenue N.E.

Calgary, Alberta T2E 8P2

11 March 2014

DRDC-RDDC-2014-C78

Unclassified A 740928

Use or disclosure of this data is subject to the restriction on the title page of this document.

GENERAL DYNAMICS CANADA LTD. LAND AND JOINT SOLUTIONS

ARMOUR Technology Demonstration Contract

W7714-115274/001/SV ARMOUR TD System CONOPS Unclassified Version B 11 March 2014

Unclassified B 740928


GD Canada Land and Joint Solutions Permit to Practice Number P06579

RESPONSIBLE PROFESSIONAL ENGINEER


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.

Unclassified D 740928


This page is left blank intentionally.


Unclassified i 740928



TABLE OF CONTENTS

1. INTRODUCTION........................................................................................................11.1 Scope..............................................................................................................................11.2 Background....................................................................................................................11.2.1 Identified Capability Deficiencies ...........................................................................11.2.2 System Relationship to Capability Deficiencies......................................................21.3 Document Overview ......................................................................................................4

2. APPLICABLE DOCUMENTS...................................................................................62.1 Government Documents ................................................................................................62.2 Non-Government Documents ........................................................................................6

3. SYSTEM OVERVIEW................................................................................................73.1 Operational Environment...............................................................................................83.2 Operational Scenarios ....................................................................................................8

4. OPERATIONAL CONCEPT....................................................................................124.1 Operational Overview..................................................................................................124.1.1 Proactive Cycle ......................................................................................................134.1.2 Reactive Cycle .......................................................................................................144.2 Roles and Responsibilities ...........................................................................................154.3 Operational Model .......................................................................................................154.3.1 Observe Phase – Collect and Fuse Data ................................................................164.3.1.1 Proactive ................................................................................................................174.3.1.2 Reactive..................................................................................................................174.3.2 Orient Phase – Predict Attack Paths.......................................................................174.3.2.1 Proactive ................................................................................................................184.3.2.2 Reactive..................................................................................................................184.3.3 Decide Phase – Decide Courses of Action.............................................................184.3.3.1 Proactive ................................................................................................................194.3.3.2 Reactive..................................................................................................................194.3.4 Act Phase – Implement Courses of Action ............................................................194.3.4.1 Proactive ................................................................................................................204.3.4.2 Reactive..................................................................................................................20

Unclassified ii 740928



TABLE OF CONTENTS (continued)

4.4 ARMOUR Components...............................................................................................204.4.1 Integration Framework...........................................................................................204.4.2 Connectors .............................................................................................................244.4.3 Database.................................................................................................................244.4.4 Data Presentation ...................................................................................................244.4.4.1 Object Representation............................................................................................244.4.4.2 Operator Views - A User Oriented Operational Description..................................254.4.4.2.1 Common Operating Picture ...................................................................................254.4.4.2.2 Presentation Views.................................................................................................264.4.4.2.2.1 Security Action Status View ............................................................................274.4.4.2.2.2 Operational View .............................................................................................284.4.4.2.2.3 Infrastructure View ..........................................................................................314.4.4.2.2.4 Attack Path View .............................................................................................324.4.4.2.2.5 COA View........................................................................................................324.4.4.2.2.6 Incident Analysis View ....................................................................................334.4.5 Computational Services .........................................................................................334.4.5.1 Cross Source Correlation .......................................................................................334.4.5.2 Reachability Analyzer............................................................................................334.4.5.3 Common Infrastructure Abstraction ......................................................................344.4.5.4 Operations and Infrastructure Analyzer .................................................................354.4.5.5 Attack Path Generator and Analyzer......................................................................354.4.5.5.1 MulVAL .................................................................................................................384.4.5.5.2 AssetRank Algorithm.............................................................................................384.4.5.6 Incident Analyzer ...................................................................................................384.4.5.7 Course of Action Analyzer.....................................................................................384.4.5.7.1 Cyber Operations Sections Course of Action Decision Support (COADS) ..........404.4.5.8 Semi-Automated Response....................................................................................404.4.5.9 Automated Response .............................................................................................404.4.6 Effector Connectors ...............................................................................................40

5. MAINTENANCE AND SUPPORT..........................................................................41

6. TEST AND DEMONSTRATION.............................................................................42

Unclassified iii 740928



TABLE OF CONTENTS (continued)

7. NOTES........................................................................................................................437.1 Abbreviations...............................................................................................................43

FIGURES

1 ARMOUR System Environment ...................................................................................72 OODA Loop Operational Model [Ref 2] .....................................................................123 ARMOUR High Level Concept of Operations............................................................164 Integration Framework in Reference to ARMOUR.....Error! Bookmark not defined.5 ARMOUR High-Level Architecture............................................................................236 COP Integrated Desktop ..............................................................................................267 Presentation Views within OODA Loop......................................................................278 Sample Operations View [Ref 2] .................................................................................299 Sample Drill Down Operations View [Ref 2]..............................................................3010 Sample Infrastructure View .........................................................................................3111 Sample Reachability Graph .........................................................................................3412 Sample Attack Graph Explorer ....................................................................................3613 Sample Detailed Attack Graph.....................................................................................3714 COA Analyzer Block Diagram ....................................................................................39

Unclassified iv 740928


This page is left blank intentionally.


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 comprising 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 System (IS) is, 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. However, 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, target 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 and 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 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 effective manner.

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 will integrate 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 will initiate new or leverage existing Research and Development (R&D) efforts to develop a solution that meets the business objectives.

The ARMOUR will provide operators with the ability to view the network topology and 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 will analyze 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 will generate a graphical representation of the attack path 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 library, populated both pre-deployment and live, will include a number of resolutions to various attacks that are optimized and prioritized in order to ensure mission survivability. Each COA will be associated with a threshold value which will be used to determine whether an automated or semi-automated (requiring operator intervention) response is needed. For each attack, the COAs defined in the library will be analyzed for their remediation of the threat generated by the attack graph analysis (attack vector) and ARMOUR will present the operator with a list of actions that can be taken to resolve the attack. The COAs can be either effected automatically if the impact is below a pre-defined 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 steps defined in the COA will be 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 GD Canada 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 Canada Ltd. (GD Canada), along with DRDC and strategic partners defined in section 4.2.3 of the ARMOUR TD Project Management Plan (GD Canada document No. 995012) will develop, integrate and deliver a solution to address the problem space defined by DRDC.

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




Subsequent releases of this document will occur for each phase and will include updates to the Concept of Operations contained herein as the solution matures.




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.

740931 ARMOUR TD Test Design and Environment Document

995012 ARMOUR TD Project Management Plan 995015 ARMOUR TD Architectural Design Document

(ADD)



3. SYSTEM OVERVIEW

The ARMOUR TD solution is a combination of commercial, developmental and experimental software tools that will be integrated to existing sensors and effectors within the DRDC DREnet operational unclassified 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 components 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 ADD (GD Canada document No. 995015).

3.1 Operational Environment

The ARMOUR system will process and store a variety of user and system data. This includes network management data, as well as a variety of network security data. For the ARMOUR TD Project, it is expected that the data sensitivity may be assessed as up to and including PROTECTED B. Even though some scenarios executed within the DREnet may be UNCLASSIFIED, data sensitivity may dictate that the ARMOUR system operate at up to and including PROTECTED B System High.

The ARMOUR solution, once productized, is expected to be deployed within more secure environments (i.e., SECRET) in the future and as such the overall security posture of the solution will not include any design decisions that would preclude the solution (or a variant thereof) from achieving Certification and Accreditation within these environments. This is to say that technical design decisions will be made with the understanding that the system will be safeguarded so as to protect data commensurate with a security classification of up to SECRET.

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.

Future discussions with the following stakeholders will provide insight into future potential operational scenarios:

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 (D IM Secur); and g. Director Information Management Technologies, Products and Services (DIMTPS).

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

Once the attack graph is generated, COAs are provided to the operator to resolve the vulnerabilities thereby mitigating the propagation of the attack any further. Simulation of the COAs demonstrate to the operator the impact of implementing the risk mitigation. The COAs implemented could include removing the vulnerability from the attack point (initially infected asset) and/or removing the vulnerability from assets further down in the attack path.

In either case, the impact of the mitigation steps (COA) is analyzed based on the global context of the system as a whole. The intent of this is to ensure that operational priorities are maintained and not negatively impacted as a result of the change. For example, Asset A is a router that connects asset B, C and D together. Asset D has been identified as a high priority device required for mission survivability. If Asset B is discovered to be infected, and an attack graph is generated showing a potential exploit to Asset D (high priority asset) through an attack vector, ARMOUR would generate the COA list with the highest ranked COA intending to secure/mitigate risk associated with any potential threat vector that could impact Asset D. This mitigation could be in the form of (but not limited to) removing any route between Asset B and Asset D on the router, patching the vulnerability of the identified exploit on Asset D or patching the vulnerability of the identified exploit on Asset A. The highest ranked COA would be selected based on the propagation capabilities of the attack, the priority assets with the attack path and mission objectives.




3.3 External Interfaces

As ARMOUR is deployed within its own enclave, the collection of data from the host network must be managed by a secure, reliable device. A proven one-way data diode solution will be used to ensure the data ingest interface is provided by a known device with a proven history of securing networks at the boundary.

An additional, separate one-way diode will be used on the effector interface to transfer effector outputs to the target network.

The data diode solution must be accreditable.



4. OPERATIONAL CONCEPT

This section outlines the operational concepts that apply to the ARMOUR TD. “The ARMOUR TD is intended to create and demonstrate an integrated system that will substantially improve the security of DND networks by providing an Automated CND capability. The system will serve to provide the ability to pre-empt attacks and offer a planning capability to ensure networks are securely designed, even before they are procured.” [Ref 2]

The processes involved in CND can be described as a closed loop process according to the OODA loop concept shown in Figure 2. All CND events observed on the network can be applied to this methodology. The ARMOUR solution will operate according to the OODA process.

FIGURE 2. OODA Loop Operational Model [Ref 2]

As shown in Figure 2, the OODA loop includes four distinct phases; The Observe phase, Orient phase, Decide phase and Act phase. Within each phase, proactive (subsection 4.1.1) and/or reactive (subsection 4.1.2) responses are applied to enhance the security posture of the network.

4.1 Operational Overview

“Initially, network information is captured using deployed tools and operational impact is entered into the system. This information is correlated, and abstracted into sets of useful data. The data is analyzed to determine the relative operational importance of hosts and software. The data is combined with rules describing attack techniques to compute all possible attack paths (given the rules and data) in the network. The potential attacks are chained together and stored in a graph data structure giving the pre-conditions and post-conditions for each attack step. The network’s





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 will select the course of action to implement, or in a fully-automated fashion, where courses of action will automatically be effectuated up to a set threshold of investment in mitigation actions. In the fully-automated case, operators will be notified of actions taken, but no manual intervention is required by the ARMOUR operator. The effects of these actions will then be monitored and any changes to the network will be detected by the data source connectors and the process repeats.” [Ref 2]

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 Certification and Accreditation (C&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 3 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.



FIGURE 3. ARMOUR High Level Concept of Operations

Each phase, along with a description of the proactive and reactive concepts, is described in detail in the following sections.

4.3.1 Observe Phase – Collect and Fuse Data

“In the Observe phase, both asset and operations data will be collected and stored. Information from sensors and network management systems will push data to ARMOUR as the data is generated.

System information will include both external reference data (e.g. vulnerability advisory information) and internal infrastructure data. Internal infrastructure data may be obtained from agents installed on end hosts to collect and store that asset’s data, or special purpose devices (hardware and software) installed at various locations in the network may be used to collect data from one or multiple sources. Examples of internal infrastructure data sources include network management and mapping systems, intrusion detection systems, vulnerability scanners, network and host event logs, and firewall policies.” [Ref 2]

This action is depicted by the “Build Network Model & Reachability” activity in Figure 3. The output of this action provides a model of the network that represents the topology and security state of the network.





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 3. 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 3. This activity applies to both Proactive and Reactive operations. The output of this component 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 3. 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” component for the Reactive Operations of Figure 3.

4.3.3 Decide Phase – Decide Courses of Action

“In the Decide phase, optimized and prioritized courses of action will be 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).” [Ref 2]

This action is depicted by the “Conduct COA Analysis” block in Figure 3 and is performed by the COA Analyzer. The core of the COA Analyzer is the continuously updated and approved COA library. This library contains the complete set of all COAs that have been approved for deployment, their component actions, associated costs, risks, associated rollback COAs, and their mappings to the COAs generated by other products.




“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 roll back the implemented COAs. In all cases a valid COA may recommend 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.” [Ref 2]

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 and may also involve remediation of known vulnerabilities by deploying a software patch or operating system upgrade. Network Operators will be able to review and instantiate the COA depending on the requirements of the mitigation activity.

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




4.3.4.1 Proactive

“As described previously, proactive COAs 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 instantiate the resulting mitigation. It will be possible to reverse any system-implemented COA through a rollback function if the analyst determines that the results are undesirable.” [Ref 2]

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 roll back selected COAs that have been implemented by the system.” [Ref 2]

4.4 ARMOUR Components

The ARMOUR System solution is comprised of several components. 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 (GD Canada 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 4.



FIGURE 4. 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 Rapid Technology Integration Framework (RTIF).

The RTIF Integration Development Kit (IDK) enables third-party developers within academia, government, or industry to easily integrate new applications into the DRDC ARMOUR framework. The IDK is open source and standards based to eliminate licensing costs and maximize interoperability with third party tools and services. The IDK includes extensive documentation to support and provide guidance in the following key areas:

a. Enable developers to build new applications to access, consume and publish data to the ARMOUR System;

b. Provide guidance on building, deploying, and testing services and software with detailed API documentation and examples; recommended open-source tools for development and debugging; and a catalogue of reusable integration patterns; and

c. Provide specific ARMOUR framework clarification where appropriate – for example, differences when deploying web services and applications to the framework.

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

Figure 5 depicts how RTIF binds the five architectural contexts together.



FIGURE 5. ARMOUR High-Level Architecture





4.4.2 Connectors

Connectors serve to ingest the information produced by data sources and provide that data to the analysis engines and presentation displays in compatible/normalized formats (e.g., Common Event Format (CEF)). 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

Data presentations provide the user with a visual representation of the network and CND events correlated to the nodes comprising the network. Data presentation supports rapid indications of critical information that illustrate areas of immediate concern to the operator.

4.4.4.1 Object Representation

Icons within the graphical windows are used to represent objects and data overlays. Icons are distinct and intuitive representations of operations, services and infrastructure as well as data overlays.

Data overlay icons represent: a. Uncertain status (e.g. hosts identified but corresponding software information is not

available); b. Security metric and degree of dependency values; c. Presence of vulnerabilities; d. Likely occurrence of compromise; e. Sequence attack path; f. Attack value (e.g., criticality of a host within an attack path); and g. Course of action implication (e.g., effect of selecting or deselecting a particular

course of action).

Icons include additional visual details/attributes regarding the component they represent. Attributes may include, but are not limited to colour, size, shadow and flashing, and provide the operator with a visual indication of various characteristics of the object (i.e., asset compromised, high value asset, operational criticality, etc.).

1 The term for data storage will be defined in a later phase as requirements analyses progress.




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 relationships between objects. Line thickness, colour and style may be used to denote the characteristics of the relationship (i.e. relationship type, importance, attack path, etc.).

As the ARMOUR TD design matures, this document will be updated with a detailed list of icons and relationships.

4.4.4.2 Operator Views - A User Oriented Operational Description

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; 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; and h. Provide event summaries to the chain of command.

The views described below enable all user roles to view the network from deliberate and focused GUIs. For example, the Operational view will allow the Systems/Configuration Manager to view dependencies between operations. The following subsections describe how the user interacts with the various views provided by the ARMOUR TD.

4.4.4.2.1 Common Operating Picture

For the ARMOUR System, the inherent visualization capabilities of COTS products will be used to create a data presentation capability that supports open standards and centralizes mission, resource, and threat information in a single, coherent display. Figure 62 depicts an example of the Common Operating Picture (COP) Desktop.

2 Figure 6 is a sample image and does not reflect the actual view to be employed in the ARMOUR solution.



FIGURE 6. COP Integrated Desktop

The COP provides the following functionality: a. Displays all incoming alerts to the operator; b. Allows the operator to further investigate alerts by connecting to the component

which raised the respective alert; c. Provides a location breakdown of alerts per Internet Protocol (IP) address range; and d. Provides a “Heat Grid” which displays alert activity based on physical location.

The COP display can be useful to all user roles particularly for the Commander as this role is responsible for overall operations and requires the executive level summaries.

4.4.4.2.2 Presentation Views

The data presentation layer of the ARMOUR System will be composed of six main views: a. Security Action Status View; b. Operational View; c. Infrastructure View; d. Attack Path View; e. COA View; and f. Incident Analysis View.

These views provide all of the functionality required for operators to successfully execute the ARMOUR mission. Figure 7 shows how these views support the OODA process.




FIGURE 7. Presentation Views within OODA Loop

4.4.4.2.2.1 Security Action Status View

The Security Action Status View is a component of the Infrastructure View. This view provides the Network Operators, Proactive and Reactive Security Analysts with the ability to virtually implement and analyze proposed changes to the network.

This view is initiated by selecting the speculative network model within the Infrastructure View. Within this model, the operator has complete flexibility to implement or rollback changes to any available network property, including:

a. Marking vulnerabilities as fixed or ignored; b. Changing routes or physical network connectivity; and c. Changing firewall rules.





4.4.4.2.2.2 Operational View

The Operational View component of the ARMOUR System provides interfaces for the creation, management, and monitoring of missions. This interface fully integrates operational views within the network architecture interface, as well as allowing them to be viewed and managed separately. This view is particularly useful for the Network Operator and Systems/Configuration Manager.

The ARMOUR System allows operations to be viewed and managed with variable levels of granularity. Once an operation has been established, its assets, dependencies and status can be viewed at any time. This includes operational priority, vulnerability, exposure, and risk data, as well as connectivity and defence posture information. Operations can also be grouped into larger organizational units to produce one or more command structures. These command structures provide the means to gauge the overall status and security posture of the entire command. Operations are searchable and filterable to facilitate display of only the resources that are most relevant to the operator at any given time. Additionally, display of specific attributes and details may be toggled on or off at the discretion of the operator.

A sample series of Operational Views are provided in Figure 83 and Figure 9. In Figure 8, “the operational elements that were visible within the Command view are centered in the operations view with a linked relationship to the Information Management Group. Conceptually, this represents a dependency relationship between the deployed operations and the strategic infrastructure that would be provided by the Information Management Group. The Security Status Indicators are super-imposed on the operational icons representing the collective cyber Defensive Posture of the aggregate group indicated by the operational icon. The meanings of these Security Status Indicators are clearly displayed in the legend in the lower left hand portion of the display. The information displayed may be changed by the selection or de-selection of various check-boxes included in the Security Status Indicator section of the display. The location within the operational tree-structure displayed and navigation between higher and lower levels of the operational tree-structure is enabled through the use of a visual breadcrumb navigation aid across the top of the Operations View.” [Ref 2]

3 Figure 7 and Figure 8 are sample images and do not reflect the actual views to be employed in the ARMOUR solution.



FIGURE 8. Sample Operations View [Ref 2]

Figure 8 “demonstrates how user selection of a particular element within an Operations View results in a drill-down to the next level(s) of detail associated with the selected item.” [Ref 2]




FIGURE 9. Sample Drill Down Operations View [Ref 2]

Figure 9 depicts an expanded view from the root level view depicted in Figure 8. It can be seen that “the tank (Army element) icon within the Operations View was selected. The result of selecting the tank is the relative re-positioning of the operational icons so that lower level objects may be displayed.” [Ref 2] Further drill down of the small building icon reveals the elements within that site along with the Security Status Indicators positioned on the nodes affected.

“In addition to the Host Security Status Indicators, the Operational Criticality indicator has been selected, resulting in a blue shadow beneath the operational and infrastructure icons. The relative Operational Criticality is represented by the shade of blue used (lightest shade for least critical to darkest shade for most critical).” [Ref 2] This figure illustrates the conceptual use of object icon details while the lines connecting the icons depict the relationships between objects.




4.4.4.2.2.3 Infrastructure View

The Infrastructure View provides the ability to monitor the status and configuration of network resources (Network Operator and Systems/Configuration Manager) as well as initiate and review the analysis of exposure, and connectivity information (Proactive and Reactive Security Analyst). Features of this view include:

a. Topological network graph with multiple levels of abstraction and the ability to create custom maps;

b. Operation listing and graphical display; c. Vulnerability risk Key Process Indicator (KPI); d. Aggregate risk as colour-coded tree-maps; e. Resource-level configuration information; and f. Connection Analysis

A sample infrastructure view is shown in Figure 104. This diagram also depicts an attack path described in the next subsection.

FIGURE 10. Sample Infrastructure View

4 Figure 10 is a sample image and does not reflect the actual view to be employed in the ARMOUR solution.





4.4.4.2.2.4 Attack Path View

The Attack Path View displays the actual and potential paths within the network that an attack can exploit. Attack Paths are superimposed on the infrastructure topology to provide the Security Analysts and Network Operators with a visual representation of vulnerable hosts given a particular attack. This view provides the Proactive and Reactive Security Analysts with the ability to create and modify threat definitions, prepare and execute attack simulations, and view their results graphically.

Generation of the attack graph is accomplished through selection of a threat origin and attack target from within the infrastructure view. This origin defines the starting point for the attack as well as any of the attacker attributes that are relevant to the simulation. These origins can be created or modified from within this interface at any time.

Once an attack has been generated, it can be viewed within the attack explorer as a forward-directed hypergraph. 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.

Figure 10 depicts a sample Attack Path View. The analysis of an attack path provides the operator with an attack graph which contains data on a number of key statistics regarding the attack. Attack path analysis is discussed in subsection 4.4.5.5.

4.4.4.2.2.5 COA View

The COA view provides the means to create and edit COAs, enact them either through semi-automated or manual response, and monitor their status.

As the primary interface to the COA library, the COA view will be responsible for the creation and maintenance of all COA definitions. Specifically, the operator will be able to set:

a. External to internal mappings; b. Implementation cost value; c. Implementation risk value; d. Internal commands; and e. Associated rollback COA.

As part of the semi-automated response, the COA View will also present lists of COAs to the Proactive Security Analyst, Reactive Security Analyst for approval (approval to implement a COA is required from Network Operator in Proactive situations and select Reactive situations). In making their decision, the Analyst/Operator will be provided with all assigned costs, and be able to cross reference each of the COAs with data from the architectural view as well as historical response data from the knowledge base. At this time, the Analyst/Operator may also




choose a COA from the database for implementation if those suggested are unsatisfactory. After the COAs have been approved, the COA View will provide the means to monitor the status of their implementation in real time. If at any time there is a problem or change of plan, the Analyst/Operator will be able to select any active COA for cancellation, as well as implement the associated rollback COA.

Future revisions of this document will include a diagram for the COA view.

4.4.4.2.2.6 Incident Analysis View

The Incident Analysis View creates a visualization layer for incoming network security events that is flexible, responsive, and attractive in support of incident analysis activities. It provides the Proactive and Reactive Security Analyst with the means to display and analyze all of the incoming security event data and includes features such as:

a. Sortable and searchable lists of all incoming security events; b. Customizable charts and graphs capable of long-term historical correlation; and c. Short, medium and long-term trending displays.

Future revisions of this document will include a diagram for the Incident Analysis View.

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 (GD Canada document No. 995015).

4.4.5.1 Cross Source Correlation

Data normalization and correlation is required to generate a global COP of the current security posture of the network. Data normalization and cross source correlation will reduce the volume of data and information gathered by removing redundant information collected by various tools regarding a single asset and store this data in a common database structure. Raw multi-source data will be correlated to remove duplication of data and may be further pre-processed for data abstraction and reduction. Without normalization and correlation, the volume of data gathered would be difficult to analyze in an efficient manner. This context aggregates all available network data to facilitate ease of analysis and compatibility with current and future tools.

Cross Source correlation is performed on security data, infrastructure data and operations data.

4.4.5.2 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 and the analysis engine normalizes the data to generate a visual map of the network with drill-down and search capabilities. Any changes detected on the network (i.e.,



device availability, access compliance, etc.) are quickly evaluated and displayed for the interested parties such as the Network Operator and Administrator. The Reachability Analyzer is also capable of performing device compliance and configuration checks to ensure that any changes to pre-defined configurations are detected and appropriately displayed for the Reactive Security Analyst and Network Operator.

The end result of the collection and analysis of all of these data sources is a single reachability graph (see Figure 11). 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. The operator can set up automated tasks on a periodic basis to ensure the network model is updated dynamically as the network changes.

FIGURE 11. Sample Reachability Graph

In general, the entire reachability analyzer will operate through automated retrieval of network data. However, a manual over-ride capability will exist to enable the user to add or delete or edit the final reachability information as desired.

4.4.5.3 Common Infrastructure Abstraction

This is the process of identifying common or similar hosts within the network to allow for automated grouping and abstraction. Based on IT managed white lists, devices hosting white listed applications only can be aggregated as part of a group represented by the single abstracted node. Devices that include tools or application that are not included in the white list cannot be aggregated and abstracted.





Development of the Common Infrastructure Abstraction component will be required as there is no identified solution at this time. Future releases of this document will include details of the design.

4.4.5.4 Operations and Infrastructure Analyzer

The Operations and Infrastructure Analyzer will allow the Security Analysts to perform proactive and reactive analysis on the infrastructure to determine operational impact and risk exposure. It will provide the Analysts with the capability to identify operational priority, input attacker models, and generate security posture metrics for operations.

The Operations and Infrastructure Analyzer provides the core functionality for the analysis of the network infrastructure and operations. It provides advanced functionality that enables the analysis of network topology, policy, risk, simulation of attacks and the management of operations from one interface.

Development of the Operations Dependency Analyzer component will be required. Future releases of this document will include details of the design.

4.4.5.5 Attack Path Generator and Analyzer

The Attack Path Generator and Analyzer provide the Proactive and Reactive Security Analyst with the capability to identify and simulate attack paths. Attack path generation and analysis leverages the MulVAL reasoning system (see subsection 4.4.5.5.1) and DRDCs AssetRank algorithm (see subsection 4.4.5.5.2) to consume a network’s configuration and vulnerability information, and produce a list of viable and scalable possible attack paths. These attack paths are presented to the operator for use in proactive and reactive analysis.

The Attack Path Generator creates a listing of all possible attack paths based on selectable attack sources, priority assets to protect, infrastructure and operational dependencies, and network topology.

For proactive and reactive attack path analysis, specific threats are modeled and analyzed for their projected impact to operations through simulated attacks. The Attack Path Analyzer provides an integrated vulnerability management solution that combines the capabilities to discover vulnerabilities, prioritize risks automatically and drive remediation activities. It deduces an accurate list of vulnerabilities without actively probing hosts while collecting data from threat feeds, vulnerability scanners, patch management systems and network devices (i.e. firewall, router, etc.). It then correlates its vulnerability and threat dictionary with the identified vulnerabilities, attacker models, prioritized assets and the generated Attack Path to identify and simulate attack vectors.

Risk modeling is used to create a normalized view of the cyber security situation, including information about the network infrastructure, security controls, vulnerabilities, services and threats. Simulation allows the imitation of attacker activities, using known vulnerabilities, and information about the infrastructure and security controls in place. The result of this automated process is a set of possible attack scenarios, each a specific set of steps that an attacker can take.



The combination of modeling and simulation allows complex interactions to be combined outside of the live network environment – so the actual infrastructure is not affected. An attack scenario represents the set of actions that may be performed by an attacker from a given starting point towards a target, given a specific threat origin and precise model of the target network. The generation of all possible attack scenarios provides a critical examination of an attacker’s ability to penetrate the target network and attack its resources.

Once one or more attacks have been simulated, a forward-directed attack hyper-graph is generated which contains a number of key statistics. This attack graph captures all possible attack scenarios from the specified attack origins to the specified network resources. This attack graph can be explored visually to expose each of the steps in an attack as well as which policies allowed it to occur, as shown in Figure 12 and Figure 135.

FIGURE 12. Sample Attack Graph Explorer

5 Figures 12 and 13 are sample images and do not reflect the actual views to be employed in the ARMOUR solution




FIGURE 13. Sample Detailed Attack Graph

Proactive use of the attack graph generator involves the simulation of attacks using threat origins that mimic known threats as closely as possible. The results of these simulated attacks can be used to plan and prioritize proactive remediation of vulnerabilities, as well as evaluate the overall defensibility of the network and plan future architecture changes. To facilitate the analysis of the effect of remediation strategies on attacks, architecture data may be manipulated within the speculative network model to simulate planned changes on then network. This might include marking vulnerabilities as ignored or fixed to simulate patching and updating firewall rules or router configurations to simulate changes in the network. Subsequent simulated attacks will show the effectiveness of these changes.

When a compromise is known, the attack graph generator must be used in direct reaction. This involves creating an attack origin that best represents the threat posed by the compromised resource, and simulating all of the attacks that might progress from that point. This is critical in that it provides a clear indication of the likelihood that the compromise will allow the attacker to spread within the network or access critical resources. COAs will directly stem from these attack predictions, and the severity of the predictions may have a profound impact on the scope of the required response. The speculative network model may be used in this case to plan and test the effect of COAs on the threat posed by the compromised resource as well as the overall network.





4.4.5.5.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.5.2 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.6 Incident Analyzer

Security event data from DREnet security data sources IDS, firewalls, routers, Intrusion Prevention Services (IPS), Security Information and Event Management (SIEM), etc.) is processed and normalized into CEF which is then forwarded to the incident analysis component and built-in rules engine, and displayed as identifiable security incidents within the COP display (see Figure 6) for the Security Analysts and Network Operator to view. The rules engine validates the legitimacy of events through dictionary mapping and advanced analytics and passes valid events on for Attack Path and COA Analytics.

4.4.5.7 Course of Action Analyzer

The Course of Action Analyzer provides a prioritized list of recommended COAs in response to identified attack paths generated for either the proactive or reactive operation. COAs are manually generated responses to security events (attacks) pre-populated in the COA library.

Figure 14 shows the COA Analyzer block diagram.



FIGURE 14. COA Analyzer Block Diagram

The core of the COA Analyzer is the continuously updated and approved COA library. This library contains the complete set of all COAs that have been approved for deployment, their component actions, associated costs, risks, associated rollback COAs, and their mappings to the COAs generated by other products.

Once the incoming COAs have been normalized, their cost and risk metadata are analyzed. The total risk for each COA is calculated as a measure of its implementation cost added with the result of the cost associated with its rollback COA scaled against its risk. Each of the COAs is ranked in descending order, relative to its total cost.

COAs can be initiated in either an automated or semi-automated response. Automated response is the process by which COAs are generated in response to an event and executed directly without human interaction. Semi-automated response is the process by which COAs are generated in response to an event, sent to an analyst for selection and approval, and then executed via a standard workflow.

If the total cost of the top-ranked COA is below a predefined threshold, it is approved for automated response; otherwise the COA list must be approved by the operator (semi-automated).

The COA approval process for the semi-automated response requires that the entire list be presented via the COA View. The operator may select one or more COAs from the available list, or reject the list entirely. The operator may also choose this opportunity to manually select a COA that has not been presented.

Once COA selections have been made, a response is generated and sent to the Effector.





4.4.5.7.1 Cyber Operations Sections 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.8 Semi-Automated Response

Semi-automated response occurs when human interaction is required in response to a COAs. 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 course of action is executed via a standard workflow.

4.4.5.9 Automated Response

Automated response is the process by which COAs are generated in response to an event 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 COA view. If there is a problem, the operator will be responsible for cancelling the COA or executing the roll-back associated with it.

4.4.6 Effector Connectors

“The Effector Connectors component provides an interface to the Off-The-Shelf products that will be used to implement the courses of action.” [Ref 2] “The Automated and Semi-Automated Response Generator modules will initiate their respective responses via the Data Presentation component through to the Effector Connectors. The Effector Connectors will provide the interface from the ARMOUR system to the Infrastructure Management Systems. In the case of Semi-Automated Responses, the Effector Connectors will provide an interface to a workflow management or ticketing service used to track the course of action recommendations from Security Operations to Network Operations. After Network Operations completes the process of delivering a patch to the infrastructure, both the ticketing service and the infrastructure data sources will provide feedback to ARMOUR to confirm the actions taken. In the case of Automated Responses, the Effector Connectors will use the Infrastructure Management Systems directly to invoke changes to the infrastructure configuration (e.g., a new IPS rule is instantiated).” [Ref 2]




5. MAINTENANCE AND SUPPORT

During the development contract of the ARMOUR TD, GD Canada 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 (GD Canada document number 995012). The GD Canada 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, GD Canada personnel will provide on-site support for deployment and maintenance of all GD Canada provided hardware and software.




6. TEST AND DEMONSTRATION

System Testing is used to assess and measure the overall behaviour and performance of components of the system. The test concept is documented in the ARMOUR TD Test Design and Environment document, GD Canada 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 unclassified 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 (GD Canada document No. 995012).




7. NOTES

7.1 Abbreviations

The following abbreviations have been used in this document. ADD Architectural Design Document ARMOUR Automated Computer Network Defence

C&A Certification and Accreditation CEF Common Event Format CFIOG Canadian Forces Information Operations Group CFNOC Canadian Forces Network Operations Centre 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

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 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 GD Canada General Dynamics Canada Ltd. 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

KPI Key Process Indicator

LCSS Land Command Support System




NetC2 ISAC Network Command and Control Integrated Situation Awareness Capability

OODA Observe, Orient, Decide and Act OSS Open Source Software

PCI DSS Payment Card Industry Data Security Standard

R&D Research and Development RTIF Rapid Technology Integration Framework

SIEM Security Incident and Event Management SOW Statement of Work SPR System Problem Reporting STS System Technical Specification

TCP Transmission Control Protocol TD Technology Demonstration

USB Universal Serial Bus