Terminology for Security Assessment
draft-ietf-sacm-terminology-02

Abstract

This memo documents terminology used in the documents produced by the SACM WG (Security Automation and Continuous Monitoring).

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on July 21, 2014.

Copyright Notice

Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 2. Terms and Definitions
• 2.1. Terms Extracted from UC -05 Draft
• 2.2. Terms from -01 Terminology Draft
• 2.3. Requirements Language
• 3. IANA Considerations
• 4. Security Considerations
• 5. Acknowledgements
• 6. Change Log
• 6.1. ietf-sacm-terminology-01- to -02-
• 6.2. ietf-sacm-terminology-01- to -02-
• 6.3. -00- draft
• 7. References
• 7.1. Normative References
• 7.2. Informative References
• Authors' Addresses

1. Introduction

Our goal with this document is to improve our agreement on the terminology used in documents produced by the IETF Working Group for Security Automation and Continuous Monitoring. Agreeing on terminology should help reach consensus on which problems we're trying to solve, and propose solutions and decide which ones to use.

This document is expected to be temorary work product, and will probably be incorporated into the architecture or other document.

2. Terms and Definitions

2.1. Terms Extracted from UC -05 Draft

The following terms were extracted from: http://tools.ietf.org/html/draft-ietf-sacm-use-cases-05

acquisition method

actor

actual endpoint state

ad hoc collection task

ad hoc evaluation task

applicable data collection content

application

appropriate actor

appropriate application

appropriate operator

approved configuration

approved endpoint configuration

approved hardware list

approved software list

artifact

artifact age

assessment criteria

assessment cycle

assessment planning

assessment subset

assessment trigger

asset characteristics

asset management

asset management data

asset management system

asynchronous compliance assessment

asynchronous vulnerability assessment

attack condition

attribute

automatable configuration guide

automatable configuration guide definition

automatable configuration guide publication

automated checklist verification

automated endpoint compliance monitoring

baseline

baseline compliance

building block

business logic

candidate endpoint target

capability

change detection

change event

change event monitoring

change filter

change management

change management program

checklist

checklist identification

checklist verification

client endpoint

collected posture attribute value

collection content acquisition

collection process

collection request

collection task

complete assessment cycle

compliance

compliance level

compliance monitoring

computing platform endpoint

configuration baseline

configuration data

configuration item

configuration item change

configuration management

content

content change detection

content data store

content definition

content instance

content publication

content query

content repository

content retrieval

criteria

critical vulnerability

current sign of malware infection

data analysis

data collection

data collection content

data collection path

data store query

database mining

define content

desired state

desired state identification

detection timeliness

deviation notification

discovery

endpoint

endpoint attribute

endpoint compliance monitoring

endpoint component inventory

endpoint discovery

endpoint event

endpoint identification

endpoint information analysis and reporting

endpoint metadata

endpoint posture

endpoint posture assessment

endpoint posture attribute

endpoint posture attribute value

endpoint posture attribute value collection

endpoint posture change monitoring

endpoint posture compliance

endpoint posture deviation

endpoint posture deviation detection

endpoint posture monitoring

endpoint state

endpoint target

endpoint target identification

endpoint type

enterprise

enterprise function

enterprise function definition

enterprise policy

enterprise standards

evaluating data

evaluation content acquisition

evaluation task

evaulation result

event-driven notification

expected function

expected state

expected state criteria

function

functional capability

immediate detection

indicator of compromise

industry group

information expression

information model

malicious activity

malicious configuration item

malicious hardware

malicious software

malware infection

manual endpoint compliance monitoring

mobile endpoint

monitoring

network access control

network access control decision

network event

network infrastructure endpoint

network location

network-connection-driven data collection

new vulnerability

on-demand detection

ongoing change-event monitoring

ongoing-event-driven endpoint-posture-change monitoring

ongoing-event-driven monitoring

operational data

operations

organizational policy

organizational policy compliance

organizational security posture

patch

patch change

patch management

performance condition

periodic collection request

periodic data collection

policy

posture aspect

posture aspect change

posture attribute

posture attribute evaluation

posture attribute identification

posture attribute value

posture attribute value collection

posture attribute value query

posture change

posture deviation

posture deviation detection

posture evaluation

previously collected information

previously collected posture attribute value

previously collected posture attribute value analysis

process

public content repository

publication metadata

publication operations

publish content

query

regulatory authority

repository

repository content identification

repository content retrieval

result

result set

retrieve content

risk

risk management

risk management program

scheduled task

search criteria

secure configuration baseline

security administrator

security automation

security posture

security process

server endpoint

significant endpoint event

significant event

signs of infection

state criteria

supporting content

target

target endpoint

task

trigger

unauthorized configuration item

unauthorized hardware

unauthorized software

vulnerability

vulnerability artifact

vulnerability artifact age

vulnerability condition

vulnerability exposure

vulnerability management

vulnerability mitigation

vulnerability remediation

whole assessment

workflow trigger

2.2. Terms from -01 Terminology Draft

assessment

• Defined in [RFC5209] as "the process of collecting posture for a set of capabilities on the endpoint (e.g., host-based firewall) such that the appropriate validators may evaluate the posture against compliance policy."
• Within this document the use of the term is expanded to support other uses of collected posture (e.g. reporting, network enforcement, vulnerability detection, license management). The phrase "set of capabilities on the endpoint" includes: hardware and software installed on the endpoint."

asset

• Defined in [RFC4949] as "a system resource that is (a) required to be protected by an information system's security policy, (b) intended to be protected by a countermeasure, or (c) required for a system's mission.

asset characterization

• Asset characterization is the process of defining attributes that describe properties of an identified asset.

asset targeting

• Asset targeting is the use of asset identification and categorization information to drive human-directed, automated decision making for data collection and analysis in support of endpoint posture assessment.

attribute

• Defined in [RFC5209] as "data element including any requisite meta-data describing an observed, expected, or the operational status of an endpoint feature (e.g., anti-virus software is currently in use)."

endpoint

• Defined in [RFC5209] as "any computing device that can be connected to a network. Such devices normally are associated with a particular link layer address before joining the network and potentially an IP address once on the network. This includes: laptops, desktops, servers, cell phones, or any device that may have an IP address."
• Network infrastructure devices (e.g. switches, routers, firewalls), which fit the definition, are also considered to be endpoints within this document.
• Based on the previous definition of an asset, an endpoint is a type of asset.

Exposure

• An endpoint misconfiguration or software flaw that allows access to information or capabilities that can be used by an attacker as a means to compromise an endpoint or network. (derived from CVE exposure definition)
• From RFC4949: (I) A type of threat action whereby sensitive data is directly released to an unauthorized entity. (See: unauthorized disclosure.) Usage: This type of threat action includes the following subtypes: - "Deliberate Exposure": Intentional release of sensitive data to an unauthorized entity. - "Scavenging": Searching through data residue in a system to gain unauthorized knowledge of sensitive data. - "Human error": /exposure/ Human action or inaction that unintentionally results in an entity gaining unauthorized knowledge of sensitive data. (Compare: corruption, incapacitation.) - "Hardware or software error": /exposure/ System failure that unintentionally results in an entity gaining unauthorized knowledge of sensitive data. (Compare: corruption, incapacitation.)

Misconfiguration

• A misconfiguration is a configuration setting that violates organizational security policies, introduces a possible security weakness in a system, or permits or causes unintended behavior that may impact the security posture of a system. (from NIST IR 7670) The misalignment of a unit of endpoint configuration posture relative to organizational expectations that is subject to exploitation or misuse.

posture

• Defined in [RFC5209] as "configuration and/or status of hardware or software on an endpoint as it pertains to an organization's security policy."
• This term is used within the scope of this document to represent the state information that is collected from an endpoint (e.g. software/hardware inventory, configuration settings).

posture attributes

• Defined in [RFC5209] as "attributes describing the configuration or status (posture) of a feature of the endpoint. For example, a Posture Attribute might describe the version of the operating system installed on the system."
• Within this document this term represents a specific assertion about endpoint state (e.g. configuration setting, installed software, hardware). The phrase "features of the endpoint" refers to installed software or software components.

Remediation

• A remediation is defined as a security-related set of actions that results in a change to a computer's state and may consist of changes motivated by the need to enforce organizational security policies, address discovered vulnerabilities, or correct misconfigurations. (from NIST IR 7670)

software flaw

• A weakness in software that is subject to exploitation or misuse. A software flaw can be used by an attacker to gain access to a system or network, and/or materially affect the confidentiality, integrity or availability of information hosted by an endpoint or exchanged over a network. Such a flaw may allow an attacker to execute commands as another user, access data that is contrary to specified access controls, pose as another entity, or to conduct a denial of service. (derived from CVE vulnerability definition)

system resource

• Defined in [RFC4949] as "data contained in an information system; or a service provided by a system; or a system capacity, such as processing power or communication bandwidth; or an item of system equipment (i.e., hardware, firmware, software, or documentation); or a facility that houses system operations and equipment.

Vulnerability

• A vulnerability is a state of configuration or defect in a system which allows an unintended and unauthorized party to violate the security or policies of the system.
• A weakness in an information system, system security procedures, internal controls, or implementation that is subject to exploitation or misuse. This includes flaws in software and processes, and misconfiguration of hardware or software. (derived from NIST definitions)
• From RFC4949: (I) A flaw or weakness in a system's design, implementation, or operation and management that could be exploited to violate the system's security policy. (See: harden.) Tutorial: A system can have three types of vulnerabilities: (a) vulnerabilities in design or specification; (b) vulnerabilities in implementation; and (c) vulnerabilities in operation and management. Most systems have one or more vulnerabilities, but this does not mean that the systems are too flawed to use. Not every threat results in an attack, and not every attack succeeds. Success depends on the degree of vulnerability, the strength of attacks, and the effectiveness of any countermeasures in use. If the attacks needed to exploit a vulnerability are very difficult to carry out, then the vulnerability may be tolerable. If the perceived benefit to an attacker is small, then even an easily exploited vulnerability may be tolerable. However, if the attacks are well understood and easily made, and if the vulnerable system is employed by a wide range of users, then it is likely that there will be enough motivation for someone to launch an attack.

Vulnerability Management

• The process of mitigating the ability to exploit a vulnerability, via defect removal or protective measures such that exploitation becomes impossible or highly unlikely. (from Chris Inacio)

2.3. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].

3. IANA Considerations

This memo includes no request to IANA.

4. Security Considerations

This memo documents terminology for security automation. While it is about security, it does not affect security.

5. Acknowledgements

6. Change Log

6.1. ietf-sacm-terminology-01- to -02-

Added simple list of terms extracted from UC draft -05. It is expected that comments will be received on this list of terms as to whether they should be kept in this document. Those that are kept will be appropriately defined or cited.

6.2. ietf-sacm-terminology-01- to -02-

Added Vulnerability, Vulnerability Management, xposure, Misconfiguration, and Software flaw.

6.3. -00- draft

7. References

7.1. Normative References

7.2. Informative References

Authors' Addresses