Continuous Diagnostics and Mitigation (CDM)...The desired state inventory does NOT directly address whether devices: Conform to D/A policy Are secure This is handled by other capabilities

Continuous Diagnostics and Mitigation (CDM) Hardware Asset Management Implementation (HWAM) May 19, 2014

Common Implementation

Issues HWAM SWAM CSM VUL

Phase 1

2

Topics to be Covered 1.Learning Objectives 2.Hardware Asset Management (HWAM)

Definition 3.Making the Paradigm Shift 4. Initial Desired State Inventory 5.Device Data 6.Activity: D/A Specifics 7.Summary

Click at any time to return to this slide.

3

Learning Objectives

1. Describe to management why the capability is important to the security of their networks.

2. Identify the typical steps necessary to be taken by the D/A to implement HWAM and manage devices.

3. Identify specific steps/issues likely to affect HWAM implementation.

4. Describe optional ways to achieve those steps and/or address issues.

5. Select the best set of options for implementation

4

Topic: Hardware Asset Management (HWAM) Definition

5

HWAM Definition

HWAM is a CDM Capability

A CDM capability is defined by: Attack scenarios – the threat Objects under attack Concept of Operations (CONOPS) Clarification of gray areas in comparison to other capabilities (differentiation).

6

HWAM Definition

HWAM CDM Capability Definition Hardware Asset Management (HWAM) addresses attacks that seek to

exploit unauthorized and unmanaged hardware devices.

It does this by: Identifying all devices, Determining whether each device is authorized or managed, and Taking appropriate action for devices that are not.

At any given time the network will probably have some defects found by HWAM that need to be addressed. Zero defects is unlikely in a large network. Fix the worst problems first.

7

HWAM Definition

HWAM Is Important Because

HWAM makes sure attackable devices are: 1. Identified 2. Authorized 3. Managed

You can’t manage a device well unless you identify it. You also can’t expect it to be managed if someone

isn’t assigned that responsibility. How well the devices are managed is NOT considered

by HWAM. That is done in other capabilities (VUL, CSM, SWAM).

8

HWAM Definition

HWAM Attack Scenario

Malicious actors search for and exploit Hardware devices* to compromise the

confidentiality, integrity and availability of data, information, and network capacity Other devices that can be reached more easily

from the already compromised device*

* See next slide for definition

9

HWAM Definition

HWAM Focuses on Devices

In particular, HWAM focuses on devices that can be attacked directly. This includes: All IP addressable devices (virtually & physically) All USB devices connected to an IP Addressable

device (physically).

Devices in scope of HWAM Devices not in scope of HWAM

• Computers (Portable, Mobile, Desktop, etc.)

• Networking devices • Communications devices • Input/Output devices (if addressable

or shared) • Both physical and virtual devices • USB and other removable devices

(with memory/storage)

Sub-components of an in-scope device such as: • Keyboards/Mice • Monitors • Local Printers • Local (non-removable) hard drives • Etc.

These can only be attacked THROUGH

the local device!

10

HWAM Definition

Objects Under Attack

Of all the devices on the network, two types are the most likely to result in malicious activity: Unmanaged devices: Such as test, experimental, and/or old

devices that people once used and have since forgotten. These are typically common and highly vulnerable. CERT results show these are often found and compromised by remote

attackers. Unauthorized (rogue) devices: Devices added to the

network with malicious intent (by an attacker directly or through social engineering) or non-malicious intent (for example, by a visitor) without authorization. Because these require physical access, they are less common. When they occur, they can be vary harmful.

11

HWAM Definition

Q/A How often is your organization compromised because of

unauthorized and unmanaged hardware: 1: We don’t know 2: Mostly by test and experimental hardware or other hardware not

being managed? 3: Mostly by unauthorized hardware being put on the network

maliciously? Can your organization easily find and report 99% of the

hardware on your network(s)? If you find an incident, is it easy to find out who manages

a specific device? Do you have a process to know when devices should be

removed? E.g. is there a sunset provision for approvals of test and experimental devices that triggers a warning?

12

HWAM Definition

HWAM CONOPS

Search for and identify

all devices

Collect Actual State

Mostly CMaaS Responsibility

Commonly done for part of the relevant devices, but seldom done for all.

13

HWAM Definition

HWAM CONOPS

Search for and identify all devices

Collect Actual

State

Establish/update a baseline of authorized and managed

devices Collect Desired State

Managers validate assigned devices

This step is seldom done • At all. • Or it is not current. • Or not in a form that can be

automatically compared to actual state.

Mostly D/A responsibility CMaaS provides repository

14

HWAM Definition

HWAM CONOPS






Compute the differences between actual state and

desired state and score them Find/Prioritize Defects

Mostly CMaaS Responsibility

When both actual and desired state are automated, timely, and comparable, we can easily compute differences, which represent unauthorized devices.

15

HWAM Definition

HWAM CONOPS Search for and identify all devices


Establish/update a baseline of authorized and managed devices

Collect Desired State


Compute the differences between actual state and desired state and score

them Find/Prioritize Defects

Remove, authorize and assign for management, or (temporarily?) accept the risk of devices (i.e.,

defects) Mitigate Defects

Scored defects ONLY

1

Add device to desired state to authorize, if appropriate. Assign a manager, if not already done.

2

Remove device from actual state, if not authorized

3

Accept risk? E.g. while

investigating

D/A Responsibility

Then we can take the appropriate action

16

HWAM Definition

Mitigate Defects

Defect Type Detection Rule Response Options Unauthorized Devices

In Actual State but not in Desired State

• Remove Device • Authorize Device OR • Accept Risk

Unmanaged Devices

In Actual State and in Desired State but no “appropriate” manager assigned

• Remove Device • Assign Device OR • Accept Risk

Non-Reporting Devices

In Desired State but not in Actual State

• Restore Device Reporting • Declare Device Missing OR • Accept Risk

Missing Devices

Non-Reporting and declared lost, stolen or missing in Desired State after search

• Accept Risk while waiting for the Device to be Found

• Reauthorize a Found Device OR

• Remove Device (i.e., accept loss of device)

Defect Mitigation

17

HWAM Definition

HWAM Differentiation

HWAM makes sure devices are: 1. Identified 2. Authorized 3. Managed

You can’t manage a device

well unless you identify it. You also can’t expect it to

be managed if someone isn’t assigned that responsibility.

18

HWAM Definition

HWAM Differentiation HWAM doesn’t identify how well

the device is managed. Quality of device management is

identified by: Software Asset Management

(SWAM), which identifies unauthorized software Vulnerability Management

(VUL), which identifies unpatched software (i.e., vulnerabilities) Configuration Settings

Management (CSM), which identifies insecure configurations

19

Topic: Making the Paradigm Shift

20

Making the Paradigm Shift

Paradigm Shift Definition: Paradigm

A set of assumptions, concepts, values, and practices that constitutes a way of viewing reality for the community that shares them, especially in an

intellectual discipline.

Definition: Paradigm Shift A significant change in the paradigm of any discipline or group.

Review from Module 1: CDM Overview: Paradigm shifts drastically change the way a subject is approached CDM (and ISCM generally) requires a paradigm shift for information

security to allow automation Most (if not all) paradigm shifts encounter resistance from those

heavily invested in the old paradigm

21


Paradigm Changes:

Old Paradigm New Paradigm We can automatically scan the network to find all devices (actual state inventory)

We need to combine passive listeners with active detection to find all devices.

IF we know what’s actually on the network, THEN unauthorized devices can easily be detected/identified manually.

We need a list of authorized devices (desired state inventory) that we can automatically compare to the actual state.

Management responsibility isn’t essential

This inventory needs to tell us who manages each device so we know who is responsible.

We can fix all defects found. When we automatically find defects, we need an automated way to prioritize which get fixed first.

22

Paradigm Changes: Old paradigm is breaking down because:

New paradigm works because:

Manual detection and identification of defects is not efficient.

Automates comparison between actual devices and authorized devices.

It’s not easy or efficient to prioritize defects manually.

Automates prioritization of the mitigation of the highest risk devices -- FIX WORST FIRST.

Growth of devices (e.g., mobile devices, virtualization, USB).

Scales to accommodate most D/A devices and can include sub-components.

With IPV6, scanning to detect actual devices will no longer work – address space is too large.

Finds devices better, even in IPV6 networks (by using passive listening techniques).

23


Desired State Inventory: Authorization You can’t find unauthorized devices unless you know what’s

authorized. Devices are “authorized” if they are listed in the desired state

inventory (and were added by an authorized account). The desired state inventory should verify that: There is a business need for each device

The desired state inventory does NOT directly address whether devices: Conform to D/A policy Are secure This is handled by other capabilities

The CMaaS tools provide simple repositories to hold the desired state inventory, and a process to manage that inventory. (More below.)

The HWAM capability does not preclude devices from being on the network. It is the D/A’s discretion to authorize or remove devices.

24


Desired State Inventory: Device Manager

You can’t make the device well-managed until you know who manages it.

The device manager actively manages the device, which includes: Connecting/removing the device to the network, Changing device components (e.g., adding memory).

A device is “managed”, when the desired state inventory records an assigned device manager The quantity of devices a device manager should be responsible

for is only as much as they can effectively manage. How well the device is managed is gauged by other CDM

capabilities. SWAM, CSM, and VUL

How important is this to my organization’s security?

25


Desired State Inventory: Device Manager

Is the device manager a person, or something else?

PERSON: If you assign devices to individual people, then

you have to change the assignment when that person leaves the organization. GROUP: If you assign devices to a group to manage, then: You need to know who supervises the group. You need to know how many people are in the group. Moreover, in many organizations there is a group that manages devices, so no one individual is responsible.

It’s probably better to assign device management to groups, except in very small organizations.

26


Desired State Inventory: Desired State Manager

You can’t establish and maintain a baseline without someone managing it.

The desired state manager actively manages the HWAM

authorized inventory (i.e., desired state), which includes: Authorizing/removing devices, and Assigning/validating device managers.

The HWAM inventory is managed when it lists

authorized devices and assigned managers.

27


Device Discovery Various device discovery methods exist Passive, e.g., “listen to” (monitor) traffic such as

connection requests. Active, e.g., scanning for active devices on the network.

Device discovery tools may include network mapping software Automates device discovery Identifies the physical connectivity of D/A networks

(network paths) Identification of network paths facilitates troubleshooting.

CMaaS providers will offer information about the suite of HWAM tool(s) they are providing to the D/A.

28


Scanning vs Passive Listening

Scanners Passive Listeners Pros • Identifies all operating

devices, active or not • No network impact • Always collecting

Cons • Degrades network performance

• Takes considerably longer, especially on large networks using IPV6

• Only identifies network devices communicating on the network

For best results, need a combination of scanning and passive listening

29

Q/A Why does HWAM require a desired state inventory? Why does it need to be automated? How does the desired state inventory relate to what devices are

authorized? What is a Device Manager? Is that different from a device owner or user? Why does HWAM require each device to have a manager? Is the device manager better thought of as a person or a group in my

organization? Why won’t scanning work to find all devices in an IPv6 network? What are the advantages of passive listening? Why does passive listening need to be supplemented by active

methods? Does HWAM ensure that all devices are well managed? Why is scoring to prioritize defects an important part of CDM

(including HWAM)?

30

Topic: Initial Desired State Inventory

31

Initial Desired State Inventory

Desired State Inventory Definition: Desired State Inventory

A listing of each authorized device and its managers.

Oops!! What if my D/A doesn’t have a complete desired state inventory? Won’t getting one be an incredible amount of work?

Actually, no. it can evolve naturally out of the actual inventory, as the D/A Identifies its actual devices Adds them to desired state, if

authorized Assigns managers for each device. Makes sure the manager accepts

responsibility. Below, we will give optional ways to find

the managers using existing data/rules. How can my organization do this?

32


Initiate Desired State 1) Run the

HWAM tool to get the actual

state Search for and identify all devices


Establish/update a baseline of authorized and managed devices Collect Desired State

0) At start desired state may be empty

33


Initiate Desired State 0) At start

desired state may be empty


Managers validate assigned devices 1) Run the






2) All new devices will show as defects

34





Managers validate assigned devices 1) Run the









3a) Desired State manager adds

devices to desired state

35





Managers validate assigned devices 1) Run the HWAM

tool to get the actual state










3b) System Administrator

removes device from network

36


Initiate Desired State 1) Run the




0) At start desired state may be empty










3b) System Administrator

removes device from network

3c) Accept risk? e.g., while

investigating

37


Find All Devices and assign managers Identify devices - There are many ways to identify devices to

establish an initial desired state inventory:

Method Pros Cons HWAM Diagnostic Sensors and Tools

• Stores device attributes and validates the actual state.

• Finds all devices

• Does not specify whether the device is authorized

• Does not specify who manages it

Active Directory (AD)/Lightweight Directory Access Protocol (LDAPs)

• Capable of storing device attributes

• Can verify the device is authorized and the manager.

• Typically, not a complete inventory

DNS/DHCP

• Can validate the IP address and machine name.

• Not a complete inventory • Does not specify whether the device is

authorized • Does not specify who manages it

Property Management

• Capable of storing some device attributes

• Not a complete inventory • Includes many device components (like

screens, keyboards, etc.) • Does not specify whether the device is

authorized • Does not specify who manages it

Used together, the first two options provide a good 80% solution on identifying managers, if both are available.

38


Assigning Device Managers Definition: Device Manager

The D/A staff responsible for : • Connecting/disconnecting the device to the network • Making physical changes to the device (e.g., add memory)

Oops! We typically don’t know who manages all our devices. Won’t it be impossible or too hard to know that?

Experience shows it can be done without extraordinary effort, if you don’t try to get it perfect at first.

Other agencies have done it using several methods. Which is right for your agency? IP Ranges? LDAP Structure? Access Control Data? Access Logs? Other?

39


Assigning Managers to Devices Methods IP ranges Pros: IP ranges can be associated with locations and/or organizations Cons: IP ranges depend on associations which must be separately

established and maintained LDAP Organizational Units (OUs), LDAP privileges Pros: LDAP can query Active Directory to identify through OUs who the

device managers are Cons: Multiple administrators can access Active Directory and modify

OU permissions Access Logs Pros: The access log lists who has logged onto a given device Cons: Not a complete list of devices, and multiple users, including

those who are not device managers, may have accessed the device (the access log only lists potential device managers)

Other?

HWAM links devices to managers, who are accountable for their security.

40


Assigning Managers to Devices None of the methods described above will be perfect. So how do we fix

errors over time? If you assign a device to someone not responsible to manage it,

before too long they will ask you to reassign it to someone else. This is because they will be “scored” on how well to manage it. This

makes them not want devices they don’t manage assigned to them. This creates an important conversation between the device

managers and the desired state inventory coordinator – Who is responsible for what?

This conversation normally never occurs. Rather, unmanaged devices just sit there.

So, what is the best way to find out who manages a device? Assign it to the “logical” or “likely” manager. If they object, they can help you find the real manager. Use the

dialogue to improve. HWAM links devices to managers, who are accountable for their security.

Which is likely best for my organization?

41

Initial Desired State Inventory Validate Device Authorization and

Managers Managers validate assigned devices

• While people ask to have devices authorized, they often forget to have them removed when not needed.

• Managers leave, and devices may become unmanaged.

Solution: 1) Periodically, device managers should be asked to look at their list of assigned devices to verify that they are still the responsible managers. 2) Device authorizations should expire unless someone re-justifies the business need of the devices.



Note: Devices that are not justified or for which the manager has not revalidated responsibility aren’t removed automatically. They are just flagged as risks needing attention. This avoids self-generated denial of service attacks.

42


Q/A Should we wait until we have a perfect desired state inventory to start

HWAM? How can we start without a desired state inventory? Is the process of getting an initial desired state inventory much

different from the normal process of running HWAM? What’s different? What’s the same?

What existing sources of information does my organization have to get started?

What’s the best way to get a good approximation of who manages what devices in my organization?

How can that “best approximation” be improved? How do we manage “de-authorizations” and changing managers? What is a desired state inventory manager? Is there someone to be a desired state inventory manager in my D/A?

43

Topic: Device Data

44

More about Device Data

Device Identifiers

You can’t link desired and actual inventory to find unauthorized devices, unless you have a common reliable identifier for each.

The CMaaS provider will discuss with the D/A the identifiers that

its tools can use and the pros/cons of each options. The D/A will need to provide information about local network

architecture to decide which are feasible.

Potential Device Identifiers IP address MAC address Device name Device certificate

These attributes are data in the HWAM desired and actual state inventory

45

More about Device Data

Device Identifiers

You can’t link desired and actual inventory to find unauthorized devices, unless you have a common reliable identifier for each.

MAC address Pros: “Burned-in address” Cons: a) MAC spoofing, b) MAC address identifies the interface

card, not the device, and c) the MAC address (i.e., network interface card for the device) can change.

IP address Pros: Static IP addresses identify individual devices Cons: DHCP (not static) addresses would not be reliable identifiers

and/or require correlating DHCP data to know which device used a particular address in a given period.

46

More about Device Data Device Identifiers You can’t link desired and actual inventory to find unauthorized devices, unless you have a common reliable identifier for each.

Device Name Pros: Provides an individual identity for each device Cons: Manual names created through active directory can be hijacked by users

with active directory access Automated naming only has value if associated with other attributes Multiple local naming conventions may exist No Federal standard for naming.

Device Certificate Pros: Individual certificates can be tracked through Certificate Authority Cons: Not all certificates are equally secure Devices may have multiple certificates Certificates can expire Management of certificates is labor-intensive Certificates are expensive and may not be appropriate for all device

types (e.g., printers, copiers, USB) Some certificates can be copied.

47

More about Device Data Device Attributes

Every device has attributes: Identifiers (e.g., IP address, MAC address, device name,

device serial number, device certificate) Associations (e.g., location, device owner, organization) Operational status (active, disposed, inactive).

Network/device discoveries only identify the existence of

the device and its attributes People and processes define device associations and

operational status.

48

More about Device Data Collect Device Data Important to collect information about each

device, such as: Identifiers (e.g., IP address, MAC address, device

name, device serial number, device certificate) Associations (e.g., location, device owner,

organization) Operational status (active, disposed, inactive).

49

More about Device Data Other Data about Devices Discussion: In addition to basic HWAM data and grouping data about devices,

what other device data could be collected? Data Business Purpose

Users To know who is put at risk by the device Frequency and pattern of Use

To look for changes that might indicate an incident.

Sub-components To authorize and know who manages sub-components, if needed. To know whether device has the hardware capacity for tasks required.

Supply Chain To know whether device is from a trusted distributor/vendor.

Others What else does my D/A need to know?

50

More about Device Data Other Data about Devices Data Business Purpose

Mobile or Portable To know whether special controls apply (AC-19, CM-02 (7))

Will be used for travel to higher risk locations; or just returned.

To know whether special controls apply (AC-19, CM-02 (7))

Provision for oversight approval of changes to the desired state inventory (separation of duties)

To implement controls (CM-03b, CM-03f)

Whether a device or subcomponent is required by a specified date; Whether it is proposed but not approved.

To implement controls (CM-03d, CM-03 (1b and 1c))

Prior versions of Object records To implement controls (CM-03e)

Whether device is owned by anyone other than the owner organization, and who

To implement controls (AC-19 (5))

Supplier as well as manufacturer of the device

To implement controls (SA-12)

Sunset Date for authorization To ensure that maintenance, test, and experimental equipment is removed at pre-defined times. For other devices, ensures that authorizations are periodically checked.

51

Mitigate Defects

Mitigate Local (Optional) Defects Defect Type Detection Rule Response Options

Device for Travel AC-19, CM-02 (7)

Device type or subcomponents do not meet D/A defined rules (before or after travel). Only applies to HWAM if certain device types and/or sub-component configs are approved for travel.

• Remove Authorization to use for travel

• Correct configuration • Accept Risk

Unauthorized Device CM-03 b & f)

Device must be in the desired state and subsequently approved by a separate authorized person from the person who added it and manages it.

[Same as in set of basic defects.]

Required device not installed (CM-03d, CM-03 (1b and 1c))

Device in desired state, authorized, and has not appeared in the actual state after [an organization-defined] number of collections.

• Install device • Remove requirement • Accept Risk

Unapproved device owner AC-19 (5)

The device owner is other than a value in an approved list. (Could also apply to sub-components.)

• Remove Device • Correct Ownership • Accept Risk

Unapproved Supplier or Manufacturer SA-12

The device supplier or manufacturer is not in an approved list

• Remove Device • Correct Supply Chain Data • Accept Risk

Subcomponents not Authorized

Subcomponents added to the actual and desired state, and system verifies that [organization-defined sub-component types] are authorized or creates a defect

• Remove Sub-Component • Correct Configuration • Accept Risk

Authorization reached Sunset

Track an authorization sunset date, which can be expired by trigger events. Score all devices past their sunset date as unapproved.

• Re-authorize • Remove Device • Accept Risk

Required Device Data Track additional device data and score devices that

don’t have that data • Add Data • Remove Device • Accept Risk

52

Actual State Inventory

Grouping Devices for Reporting HWAM information will be grouped through metadata to facilitate generating

reports. Any or all of these might be needed and can be supported. The D/A is responsible for assigning devices to these groups. Examples:

Group by Business Purpose Device manager To send problems/defects to be fixed.

Device role To be able to specify authorized SW, settings, and patch requirements by role.

Business owner To inform the owner about risk to their business functions.

Organization supporting the device To establish service-level agreements and measure performance

Applications supported To allow applications to inherent controls from network, as appropriate.

Common Platform Enumeration (CPE) or equivalent

To allow reporting by device product/vendor etc.

Group by CPE (or equivalent)

Each D/A needs to work with their CMaaS contractor to determine the optimal set of HWAM groupings it needs to collect and manage.

Which does my organization need? What others might be needed?

53

Q/A Why are device identifiers critical to HWAM operations? Why do you need to know about device identifiers, if the

CMaaS provider is largely responsible to decide which to use? Which device identifiers might work best given how your

network is managed? What are the standard desired state data elements about

devices? Are there others DESIRED state data elements my

organization might need? What are the standard actual state data elements about

devices? Are there other ACTUAL state data elements my organization

might need? Which ways to group device data will be important to my

organization?

54

Topic: Using HWAM Data

55

Dashboard Reports and Drill Down The dashboard will allow HWAM data to be viewed in the following ways: Defect Groups (e.g. HWAM, Federal, Local, etc.) Container (such as any “grouping” of devices (objects). For example, all

devices supporting CFO applications or users.) Object Types (e.g., Servers, Workstations, Printers, etc.) Combinations of the three (e.g. HWAM defects, managed by John Doe on

Servers) The capability will exist to drill down on all three, such as: Drill down from all HWAM defects to local HWAM defects Drill down from devices supporting the CFO users and applications to

those supporting the CFO managed by John Doe (in FOC). Drill down from Servers to Windows 7 servers

Note: Groups, containers and object type analysis (display and drill

down) is based on (limited to) federally defined groups and groups you add.

So think seriously on how you will want to see the data when you set these up.

56

Dashboard Data Within each view you will be able to see issues By devices By defects By sub-groups (defect groups, collections, types)

In all cases, the breakouts will show the worst problems first. For example, worst devices, defects, groups.

To drill down to individual problems you can: Go from groups to worst devices or defects From a defect to devices with that defect (worst first) From a device to its defects (worst first)

Each HWAM view will show: Total HWAM Risk Score Number of Objects (with or without scores) Average Risk Score per Object (FOC) Number of Defects

57

Pick a Response Strategy Typically, the dashboard will always show more problems than people can fix

immediately. D/As and device managers should not be criticized for that if the are: Lowering average risk scores on devices covered and Increasing maturity (coverage, timeliness, and risk/consequences

management.) You may want to use specific views to work the way you want. For example: You might want to address all problems on each device, starting with the

worst device. You might want to start by analyzing one defect check (such as devices not

authorized) to figure out what to do (whether to get them off the network). You might want to start with all HWAM defect checks within your scope to

find the defect checks causing the most risk, then work on that. You might want to start by comparing risk across all Phase I capabilities,

and deciding which of those to work on first. The dashboard supports these approaches, and many others.

So you can work the way you want!

58

Scoring Defects

DHS has organized an interagency Measures Working Group to decide how to score and grade the federal defects. This group will also recommend guidelines for scoring

local defects that support 800-53 control testing. Local D/As would decide how to score D/A defined and/or

selected defects. D/As can also provide alternate scores for Federal

defects (this affects local scores only, not federal scores).

59

Scoring Federal HWAM Defects Example 1: Unmanaged Devices

The attack model that goes with HWAM assumes that devices that are unmanaged (and not quickly mitigated): Are likely to be compromised at the root level in a fairly short time frame. After which the probability that they are used as a pivot to attack other

devices continues to grow. This means that: The base score for an unmanaged device is fairly large. Risk increases quickly, until we assume the device is compromised. Risk continues to grow after that, assuming the device is used as a point of

persistence and for pivot attacks.

Because risk grows, this assumes that D/As will not be able to accept the risk of an unmanaged device for long.

The interagency Measures Working Group (and SMEs from NIST and NSA) will advise the government on the specific scoring parameters to use.

60

Scoring Federal HWAM Defects Example 1: HWAM Non-reporting devices

Non-reporting device defects indicate that the data collection system can’t find all actual state devices (or that desired state inventory is not being updated when authorizations are removed).

As non-reporting grows, we have less confidence that we would find all unauthorized and/or unmanaged devices (devices with defects).

This means the non-reporting score needs to be a proxy for the devices with defects we can’t see: Notionally, if 0.05% of devices reporting are unmanaged or unauthorized,

and 20% of devices are not reporting, and we expect 100,000 devices them we might expect that we have: 0.05% * 20% * 100K devices = 10 devices with root compromise from

HWAM non-reporting issues (if the non-reporting is persistent). The base score should approximate this rate, depending on the

scores assigned to the basic defects. Risk would grow over time as devices are not reporting, because

the non-reporting devices with defects are less likely to be fixed.

61

Maturity Metrics Demo

A demo of a computer simulation of how maturity metrics will work

will be provided here.

62

Ongoing Assessment in HWAM HWAM implementation uses up to 30 control items (for high baseline systems). 22 or almost 75% are in the configuration management family. All but 2 (or 93%) are in the CM, SC and AC families. Many of these control items also apply to SWAM, but are typically implemented differently.

0.0%

10.0%

20.0%

30.0%

40.0%

50.0%

60.0%

70.0%

80.0%

90.0%

100.0%

CM SC AC PS SA

Hardware Asset Management

Bar shows percent of control items in each family and all families to the left.

63

Level of Automation of HWAM Assessment

A draft NIST Interagency Report (NISTIR) shows that all but 5 of these control items can be tested in an automated way. Testing the remaining items manually is not required

frequently, as they have a high mean-time to failure. These points will be illustrated by looking at the NIST-IR.

64

Using CDM documentation The DRAFT NISTIR will also be used to show how CDM

can significantly reduce effort in HWAM related to: Control Selection. Test Plan documentation. Test Results Documentation POA&M tracking of fixes to defects found.

We seek D/A input on how much time this saves in

practice for the HWAM controls. We seek NIST, OIG and GAO input on how the rigor of

the process could be cost-effectively improved.

65

Topic: Miscellaneous

66

Miscellaneous Impact of HWAM Sensors on Network Device Performance It is the D/As responsibility to monitor the impact of

HWAM sensors on: Network performance Device performance

Methods to measure impact could include: D/A works with the CMaaS provider to shut down HWAM

sensors for a short random periods of time while the D/A staff measure the difference in performance

Discussion: What other methods could be used to measure impact? How can the CMaaS contractor minimize the impact of

HWAM sensors on network/device performance?

67

Miscellaneous Navigating Secure D/A Networks

Firewalls, network segmentation, different security policies, etc. pose network navigation challenges for device discovery tools. The CMaaS provider must work with the D/A to determine how

device discovery tools may navigate secure networks, asking and addressing questions such as: What permissions are required? Who is the POC for obtaining permissions? Where on the network should the device discovery tools be

located to minimize network navigation challenges? Others?

D/As are responsible for working with the CMaaS contractor to ensure they have the information needed to successfully navigate the D/A network.

68

HWAM Security Considerations

Protecting HWAM Data

The CMaaS provider must ensure data is secure, encrypting data: While in motion (to prevent network sniffers from collecting

the inventory data) While at rest (to prevent exfiltration from data store).

CMaaS providers will ensure that the CDM tools will not transmit detailed CDM data outside approved networks. The CMaaS provider will provide an 800-53 compliant

assessment of their solution which will be reviewed initially by a few large D/A. Your D/A will also need to review this assessment and decide

whether this solution protects their HWAM (and other CDM) data.

69

HWAM Security Considerations

HWAM as a Threat to D/A Networks?

The HWAM solution could potentially pose a threat to D/A networks through, for example: Necessary links to outside networks. Allowing/requiring vulnerable software. Being turned into malware. Being used to exfiltrate sensitive data from the D/A

network.

70

Miscellaneous Are virtual machines different? Definition: Virtual Machine

A software implementation of a machine that executes programs like a physical machine.

Virtual machines are treated as unique devices in HWAM. A virtual machine can be exploited in the same way as a physical device,

needs the same protections, and is handled the same in HWAM. Pros of virtual systems: Changes to the virtual system that make it vulnerable are less

persistent than those on physical machines. The virtual device can connect while protecting the physical device.

Cons of virtual machines: If compromised, they are easy to take down and re-establish with

different metadata, which can erase evidence of the intrusion. The ability to create multiple virtual machines could be used for

attacks and recon.

71

Miscellaneous How Virtual Machines are Monitored

Identify and monitor each virtual device as if it were a physical device.

Identify and monitor the virtual “template” The virtual machine “image” is a template that has been

readied for execution

Other monitoring essentials: Ensure that virtual machines are only created by authorized

staff. Establish a process to add the virtual machine to the desired

state inventory.

72

Q/A How does your organization monitor performance on: Your network? Individual devices?

How can your organization estimate the network impact of CDM data collection tools?

Can you hold the CMaaS contractor responsible to avoid interfering significantly with network performance?

Why does the CMaaS provider need “authentication credentials” to collect data? Who must provide those credentials?

Why does the CMaaS provider need an appropriate path through firewalls to collect data? Who must provide those paths?

Who decides whether the CMaaS tools are safe on a given network? Who assesses the CMaaS provider tools? How will virtual machines be handled in HWAM? What are the best

options for your organization?

73

Exercise The following terms have special meanings in CDM. What does each mean?

Access Control Data Access Logs Accredited “Scan” Active Detection Agent Authorized Device Capability CMaaS Provider Collection Tools/Sensors CPE/HWID Credentialed “Scan” Desired State Manager Device Certificate Device Identifier Device Manager

Device Name Device Owner Device Performance Device Role Device Sub-components Device Supply Chain DHCP Services DNS Services Hardware Asset Management HWAM Actual State Inventory HWAM Desired State

Inventory Listener Scanner Sensor Tool

74

How will HWAM implementation look in your D/A?

Discussion: Discuss HWAM implementation as it will apply in a given D/A. What capabilities already exist? Will/can they be integrated? What information does the CMaaS provider need

to begin implementation? Identify any issues of concern. What political challenges need to be overcome? What operational/organizational challenges need to

be overcome? What other D/A-specific issues may impact the

ability of the CMaaS provider to implement HWAM?

Discuss recommendations.

75

HWAM Responsibilities: CMaaS Contractor Monitoring the actual state

Computing the differences between actual and desired state Operating and maintaining the HWAM sensors

Operating and maintaining the CDM Dashboard(s)

Collecting and reporting HWAM data

Supporting the D/A decision process and making

recommendations as appropriate

76

HWAM Responsibilities: D/A and CDM PMO D/A Establishes initial desired state inventory Maintains desired state inventory Mitigates the differences between actual and desired state Authorizes or removes devices from the network

Makes policy and operational decisions, for example: Whether scans will run more frequently than 3 days Whether to allow BYOD The optimal set of HWAM metadata to collect and manage

CDM PMO Funds CDM system Provides training and mentoring Coordinates CDM acquisition(s) Provides oversight and assistance to D/As to resolve unsatisfactory

CMaaS contractor performance

77

Backup

78

Actual State

Bring Your Own Device (BYOD)

BYOD is the ability for employees to use personal devices for work.

The HWAM capability accommodates BYOD.

The CMaaS provider must work with the D/A to determine BYOD policies, asking and addressing questions such as: Is BYOD permitted? What device types are permitted? How is it authorized? How do BYOD connect to the network? Is the owner the device manager? Others?

79

Topic: Desired State





Managers validate assigned responsibility



Remove, authorize and assign for management, or

(temporarily?) accept the risk of devices (i.e., defects)

Mitigate Defects

Scored defects ONLY

Accept risk? e.g., while investigating

Remove device from actual state, if not authorized

Add device to desired state to authorize, if appropriate. Assign a manager, if not already done.

80

Desired State

Desired State

The desired state inventory is a continually evolving list of:

Authorized devices with unique identifier

Assigned managers who: Validate devices Connect/remove devices as needed

Associated data about the devices (e.g., organization, type

of device, groups it belongs to, authorization expiration date)

81

Actual State Inventory

Actual State

Actual State Inventory: A list of all* “devices” on the target network.

The CMaaS provider solves how to collect and

keep current the actual inventory information within a D/A. The D/A will need to provide the CMaaS

contractor adequate network accounts and privileges to achieve this. *Within the contractual margin of error.

82

Find/Prioritize Defects

Computing the Difference

Desired State

128.168.99.23, JSmith-PC 128.168.99.24, HRobert-PC 128.168.99.25, SDoe-PC 128.168.99.26, ADavid-PC 128.168.99.28, MJohn-PC 128.168.99.30, RGriffin-PC 128.168.99.32, WRay-PC 128.168.99.51, BCannon-PC

Actual State

128.168.99.23, JSmith-PC 128.168.99.24, HRobert-PC 128.168.99.25, SDoe-PC 128.168.99.26, ADavid-PC 128.168.99.27, 007-PC 128.168.99.28, MJohnson-PC 128.168.99.29, 128.168.99.30, RGriffin-PC 128.168.99.31, 128.168.99.32, WRay-PC 128.168.99.45, 128.168.99.51, BCannon-PC

Difference

- - - - - - - -

Notional Risk Scores

- - - - 5 - 8 - 8 - 8 -

Computing the Difference Into Risk Scores

83

Relationship between HWAM and Other Capabilities

The HWAM capability is responsible for discovering the devices on which SWAM, CSM, and VUL/PATCH are performed The HW count is used: To compare relative risk scores

across organizations As a denominator for coverage

in maturity metrics

HWAM could be considered the foundational CDM capability.

VUL

CSM

SWAM

HWAM

Documents

Continuous Diagnostics and Mitigation (CDM)...The desired state inventory does NOT directly address whether devices: Conform to D/A policy Are secure This is handled by other capabilities