HWAM Capability Data Sheet



Similar documents
Software Asset Management (SWAM) Capability Data Sheet

Manage Vulnerabilities (VULN) Capability Data Sheet

Software Asset Management (SWAM) Capability Description

Software Asset Management (SWAM) Illustrative Process

CDM Hardware Asset Management (HWAM) Capability

Automation Support for Security Control Assessments

Management (CSM) Capability

CDM Vulnerability Management (VUL) Capability

CDM Software Asset Management (SWAM) Capability

ForeScout CounterACT CONTINUOUS DIAGNOSTICS & MITIGATION (CDM)

CONTINUOUS DIAGNOSTICS BEGINS WITH REDSEAL

Critical Security Controls

Architecture Overview

Security Management. Keeping the IT Security Administrator Busy

CYBER SECURITY POLICY For Managers of Drinking Water Systems

THE TOP 4 CONTROLS.

IMS-ISA Incident Response Guideline

End-user Security Analytics Strengthens Protection with ArcSight

AUGUST 28, 2013 INFORMATION TECHNOLOGY INCIDENT RESPONSE PLAN Siskiyou Boulevard Ashland OR 97520

FIREWALL POLICY November 2006 TNS POL - 008

How To Manage Security On A Networked Computer System

How To Protect A Network From Attack From A Hacker (Hbss)

Obtaining Enterprise Cybersituational

NIST CYBERSECURITY FRAMEWORK COMPLIANCE WITH OBSERVEIT

Network Detective. Network Detective Inspector RapidFire Tools, Inc. All rights reserved Ver 3D

What s Wrong with Information Security Today? You are looking in the wrong places for the wrong things.

Smart Card Authentication Client. Administrator's Guide

Top 20 Critical Security Controls

FAQ S: TRUSTWAVE TRUSTKEEPER PCI MANAGER

UF Risk IT Assessment Guidelines

Overview. Summary of Key Findings. Tech Note PCI Wireless Guideline

Effective IDS/IPS Network Security in a Dynamic World with Next-Generation Intrusion Detection & Prevention

Department of Information Technology Remote Access Audit Final Report. January promoting efficient & effective local government

About This Document. Response to Questions. Security Sytems Assessment RFQ

An Overview of Information Security Frameworks. Presented to TIF September 25, 2013

State of Vermont. Intrusion Detection and Prevention Policy. Date: Approved by: Tom Pelham Policy Number:

WHITE PAPER. Best Practices for Wireless Network Security and Sarbanes-Oxley Compliance

NETWORK AND CERTIFICATE SYSTEM SECURITY REQUIREMENTS

Threat Management: Incident Handling. Incident Response Plan

Network and Host-based Vulnerability Assessment

How To Ensure The C.E.A.S.A

Symantec Cyber Security Services: DeepSight Intelligence

Jumpstarting Your Security Awareness Program

Vulnerability Management Policy

Concierge SIEM Reporting Overview

End User Devices Security Guidance: Apple ios 8

CHAPTER 3 : INCIDENT RESPONSE FIVE KEY RECOMMENDATIONS GLOBAL THREAT INTELLIGENCE REPORT 2015 :: COPYRIGHT 2015 NTT INNOVATION INSTITUTE 1 LLC

SAMPLE HIPAA/HITECH POLICIES AND PROCEDURES MANUAL FOR THE SECURITY OF ELECTRONIC PROTECTED HEALTH INFORMATION

Information Technology Cyber Security Policy

HIPAA Security Alert

AHS Flaw Remediation Standard

Twenty Critical Security Controls for Effective Cyber Defense: Consensus Audit Guidelines (CAG)

Appalachian Regional Commission Evaluation Report. Table of Contents. Results of Evaluation Areas for Improvement... 2

TRIPWIRE NERC SOLUTION SUITE

Lumeta IPsonar. Active Network Discovery, Mapping and Leak Detection for Large Distributed, Highly Complex & Sensitive Enterprise Networks

Pragmatic Metrics for Building Security Dashboards

University of Colorado at Denver and Health Sciences Center HIPAA Policy. Policy: 9.2 Latest Revision: 04/17/2005 Security Incidents Page: 1 of 9

Securing Remote Vendor Access with Privileged Account Security

Audit Report. The Social Security Administration s Compliance with the Federal Information Security Management Act of 2002 for Fiscal Year 2013

Effective Threat Management. Building a complete lifecycle to manage enterprise threats.

1 Introduction Product Description Strengths and Challenges Copyright... 5

Risk Management Guide for Information Technology Systems. NIST SP Overview

STRATEGIC POLICY. Information Security Policy Documentation. Network Management Policy. 1. Introduction

Information Technology Branch Access Control Technical Standard

Guideline on Auditing and Log Management

ISO Controls and Objectives

INFORMATION TECHNOLOGY SYSTEMS ASSET MANAGEMENT GUIDELINE

Information and Communication Technology. Patch Management Policy

Continuous Diagnostics & Mitigation:

Smart Card Authentication. Administrator's Guide

AUDIT REPORT. Cybersecurity Controls Over a Major National Nuclear Security Administration Information System

Music Recording Studio Security Program Security Assessment Version 1.1

Defending Against Data Beaches: Internal Controls for Cybersecurity

SPICE EduGuide EG0015 Security of Administrative Accounts

Auditing the LAN with Network Discovery

Virtualized Domain Name System and IP Addressing Environments. White Paper September 2010

Type Message Description Probable Cause Suggested Action. Fan in the system is not functioning or room temperature

Compliance Guide ISO Compliance Guide. September Contents. Introduction 1. Detailed Controls Mapping 2.

The Importance of Cybersecurity Monitoring for Utilities

TEXAS AGRILIFE SERVER MANAGEMENT PROGRAM

Understanding WiFi Security Vulnerabilities and Solutions. Dr. Hemant Chaskar Director of Technology AirTight Networks

2. From a control perspective, the PRIMARY objective of classifying information assets is to:

*Applies to eligible hardware and software. Contact your Cisco Certified Partner for details.

TONAQUINT DATA CENTER, INC. CLOUD SECURITY POLICY & PROCEDURES. Tonaquint Data Center, Inc Cloud Security Policy & Procedures 1

Information Security Policy

Boston University Security Awareness. What you need to know to keep information safe and secure

Penetration Testing Report Client: Business Solutions June 15 th 2015

ALTERNATIVES FOR SECURING VIRTUAL NETWORKS

Transcription:

HWAM Capability Data Sheet Desired State: - Only devices in the authorized Hardware Inventory are on the network - All authorized devices are in the inventory - All authorized devices are assigned to a manager Desired State Specification Data Requirements: Data Item: Justification: Data necessary to accurately identify the device. At a minimum: To be able to uniquely identify the device. To be able to validate that the device on the Serial Number network is the device authorized, and not an Expected CPE for hardware or equivalent imposter. o Vendor o Product o Model Number Static IP Address (where applicable) Media Access Control (MAC) Address Property Number Local enhancements 1 might include data necessary to accurately identify subcomponents Data necessary to describe a device such that other capabilities can determine the appropriate defect checks to run on that device. Expected CPE for operating system of device or equivalent o Vendor o Product o Version o Release level To ensure all appropriate defects for a device are defined, run, and reported. To help identify non-reporting associated with other capabilities that look for defects on the device. 1 Departments and Agencies can define data requirements and associated defects for their local environment. This is done in coordination with the CMaaS contractor and these local defects are not reported to the Federal Dashboard. 1

Data Item: A person or organization that is responsible for managing the device (note: this should be a reasonable assignment, do not count management assignments where a person or organization is assigned too many devices to effectively manage them). Local enhancements might include: Approvers being assigned Managers being approved Managers acknowledging receipt Data necessary to compare devices discovered on the network to the authorized hardware Site dependent, examples include IP address MAC address Host-based certificate or Agent ID Device domain name Data necessary to locate a physical device. The period of time the device is authorized Local enhancements might include: When the device must be physically inspected/verified for supply chain risk management Expected status of the device (e.g, authorized, expired, pending approval, missing) to include: Date first authorized Date of most recent authorization Date authorization revoked Justification: To know who to instruct to fix specific risk conditions found. To assess each such persons performance in risk management. To be able to identify unauthorized devices. To know which devices have defects. To ensure that managers can find the device to: Revalidate it for supply chain risk management. Remove it if unauthorized To allow previously authorized devices to remain in the inventory, but know they are no longer authorized. To determine which devices in the authorized hardware inventory are not likely to be found in actual state Local enhancements might include: Returned from high-risk location Removed pending reauthorization Date of last status change Actual State: - Devices identified as connected to the network - Sensors and/or process to detect and record/report actual inventory 2

Actual State Data Requirements: While not explicitly stated below, all Actual State Data elements must have a date/time associated with each collection instance of that element 2. Data Item: Data necessary to accurately identify the device. Site specific, examples include: IP Address MAC Address Host-based certificate or Agent ID Device domain name Data necessary to describe the attributes of a device such that other capabilities can determine the appropriate defect checks to run on that device. Expected CPE for operating system of device or equivalent o Vendor o Product o Version o Release level Data necessary to compare devices connected to the network to the authorized hardware IP Address and associated logs MAC Address Host-based certificate or Agent ID Device domain name Data necessary to locate physical assets based on information collected in the operational environment. Site specific, examples include: Edge switch that detected device Host that USB drive was connected to Data necessary to determine how long devices have been present in the environment. At a minimum: - Date/time it was first discovered - Date/time it was last seen Justification: To be able to assert which operational device is unauthorized, or has some other defect. To ensure all appropriate defects for these devices are defined, run, and reported. To be able to identify unauthorized devices. To ensure that managers can find the device to fix, validate, or remove it. To determine how long the device has been in existence and the last time it was detected in the enterprise 2 Collection often occurs in batches, where the sensors collect from a set of devices at once. As long as a date/time can be provided for the data resulting from that collection to a reasonable precision (i.e., ± 1 hour), that is acceptable. 3

Defects: A defect is a difference between the information in the inventory and either what is required to be in the authorized inventory or what is in the actual Defects are sent to the dashboard and scored. Defect Type. A device is in the actual state inventory, but NOT in the inventory A device is in the inventory and the actual inventory, but no one is assigned to manage it Local enhancements might include: Manager has not accepted responsibility Manager has not been approved Why is this considered a risk condition? The device is unauthorized. We are unable to determine if device is authorized. The asset Manager is unknown. Typical Mitigation 3 Option 1: If the device should be operating in the environment, authorize it, add it to inventory, and assign it for management. If management has already been assigned, identify the manager and record the result in Typical Mitigation Option 2: Otherwise, remove the device from the environment. Otherwise, assign the device to an appropriate manager and record this in (As a result this manager will be informed of other risk conditions on the device so they can be addressed.) 3 Risk acceptance is always an option. In the case of Option 1 and Option 2, the risk conditions and scores do not go away. They remain visible to ensure that the organization understands the impact of their risk acceptance decisions over time and in aggregate. 4

Defect Type. A device is in the inventory, but not in actual The status in the inventory does not provide a reason for not being in the actual inventory A device is in both the and actual inventories, but the authorization is expired An important data element of the inventory is missing CPE or equivalent Locally defined defects where a required local Why is this considered a risk condition? The device may not be reporting, which would reduce our ability to monitor it in other areas. The device may have been accidentally or maliciously removed from the operational environment (e.g., missing or lost). The device may have been intentionally removed from the environment for security reasons. The risk associated with authorization decisions increases with time. Decisions that were acceptable in the past may now be considered too risky. A key piece of information used to score or assign risk is unknown. Visibility into specific vulnerable conditions Typical Mitigation 3 Option 1: If the device is actually operational but not reporting, this is a possible sensor problem. Work with the sensor managers to troubleshoot problem. If the device should be reauthorized for operation in the environment, make sure the status is set to authorized and reset the expiration date in the authorized hardware If the data element is known, record the information in the If the device is actually operational, Typical Mitigation Option 2: Otherwise, the device may have been intentionally, accidentally, or maliciously removed from the environment. Investigate the cause. If the removal creates a security violation, record as an incident, and update the device status in the If the removal was for security purposes, either remove the device from the inventory or change the status reflect that it is not currently authorized to ensure you can detect unauthorized (re)use of the device. Otherwise, remove the device from the inventory and the environment. Otherwise, determine or define the data element and record this in the authorized hardware Otherwise, this is a possible 5

Defect Type. condition is not checked on an associated device within a set timeframe. Examples include: Device is not physically revalidated as the authorized device within the defined timeframe. Non reporting devices not physically located within a set timeframe Why is this considered a risk condition? of interest to the local enterprise is limited. Typical Mitigation 3 Option 1: being sensed/processed, but not reporting/not having results reported for a particular condition, it is possible that there is incorrect data in the Update the Typical Mitigation Option 2: sensor/collection problem for automated checks and process problem for manual checks. Work with the sensor/collection managers or process owners to troubleshoot problem. 6

Appendix A - Definitions Term Definition Authorized Hardware Inventory List Black List Defect Device Device Role Hardware Asset Management (HWAM) Capability Removable media Scoring White List List of assets for an organization or subnet. Banned list of assets for an organization or subnet. A condition where the Desired State specification and the Actual State do not match in a manner that incurs risk to the organization. IP-addressable asset on the network or a non-addressable component (e.g. removable media) able to interact with the organization s data and resources. An enterprise-wide label for a class of devices that perform a like function in the environment. Examples are file servers, external web server, or workstation. The device role is intended to simplify assigning asset values or scoring weights by allowing D/As to define them for groups of devices and having individual devices inherit the values. The Continuous Diagnostic and Mitigation (CDM) capability that ensure unauthorized and/or unmanaged hardware is removed from the organization s network, or authorized and assigned for management, before it is exploited, compromising confidentiality, integrity, and/or availability. Removable storage devices that can be attached to a hardware asset on a network, typically by USB ports. The process of calculating the risk points for a defect. Identified defects will be scored based on the amount of perceived risk they create. The CDM program will be providing a scoring system that is generic across D/As. Each D/A may adapt this with additional D/A specific information to better prioritize defects for action. Approved list of assets for an organization or subnet. 7