RFC 7632

Endpoint Security Posture Assessment: Enterprise Use Cases

📅 published September 2015, from ietf

RFC 7632 💖 (Part 1 of 5)

okay bestie, let's get into Endpoint Security Posture Assessment: Enterprise Use Cases 🎀. It's RFC 7632, published in September 2015 by the IETF. The authors are D. Waltermire from NIST and D. Harrington from Effective Software. It's Informational, not a standards-track thing, with ISSN 2070-1721. The header doesn't list any RFCs it obsoletes or updates 🦋

Abstract ✨

ngl this one is a sampler platter 🍓. It documents a bunch of use cases for securely collecting configuration and operational data and then evaluating that data to figure out an organization's security posture. From these real-life use cases, we can pull out the common functional capabilities and requirements that will guide building vendor-neutral, interoperable standards for aggregating and evaluating data about security posture 💅

Status of This Memo 📜

This document is not an Internet Standards Track specification; it is published for informational purposes.

It's a product of the IETF and represents the consensus of the IETF community 🫶. It got public review and was approved for publication by the IESG. Not every document the IESG approves is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 if you want the full picture 🙈

Info about the current status, errata, and how to send feedback lives at http://www.rfc-editor.org/info/rfc7632 🌸

Copyright (c) 2015 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) as in effect on the date of publication. Please read these carefully, because they spell out your rights and restrictions for this document 🧚 Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License.

Table of Contents 🗺️

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
2.  Endpoint Posture Assessment . . . . . . . . . . . . . . . . .   4
  2.1.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . .   5
    2.1.1.  Define, Publish, Query, and Retrieve Security
            Automation Data . . . . . . . . . . . . . . . . . . .   6
    2.1.2.  Endpoint Identification and Assessment Planning . . .   9
    2.1.3.  Endpoint Posture Attribute Value Collection . . . . .  11
    2.1.4.  Posture Attribute Evaluation  . . . . . . . . . . . .  11
  2.2.  Usage Scenarios . . . . . . . . . . . . . . . . . . . . .  13
    2.2.1.  Definition and Publication of Automatable
            Configuration Checklists  . . . . . . . . . . . . . .  13
    2.2.2.  Automated Checklist Verification  . . . . . . . . . .  14
    2.2.3.  Detection of Posture Deviations . . . . . . . . . . .  17
    2.2.4.  Endpoint Information Analysis and Reporting . . . . .  18
    2.2.5.  Asynchronous Compliance/Vulnerability Assessment at
            Ice Station Zebra . . . . . . . . . . . . . . . . . .  18
    2.2.6.  Identification and Retrieval of Guidance  . . . . . .  20
    2.2.7.  Guidance Change Detection . . . . . . . . . . . . . .  21
3.  Security Considerations . . . . . . . . . . . . . . . . . . .  22
4.  Informative References  . . . . . . . . . . . . . . . . . . .  22
Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  23
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  23

1. Introduction 🦋

This document lays out the core set of endpoint posture assessment use cases for enterprises 💜 It talks through those use cases and the building-block capabilities behind them. The use cases we're covering support:

  • securely collecting and aggregating configuration and operational data, and
  • evaluating that data to determine the security posture of individual endpoints.

There's also a set of usage scenarios in here that show how to use the use cases and their building blocks for a bunch of operational jobs 🎀

These operational use cases and usage scenarios cut across lots of IT security domains. Use cases let us pull out common:

  • concepts that show up as building blocks in this document,
  • characteristics that will inform a requirements document,
  • information concepts that will inform an information model document, and
  • functional capabilities that will inform an architecture document.

All of this is meant to guide building vendor-neutral, interoperable standards for collecting, aggregating, and evaluating security posture data ✨

With this standard data, tools can analyze the state of endpoints and user activities and behaviour, then evaluate an organization's security posture 🔥 Consistent expression of information should make tools work together (customized, commercial, or free, it doesn't matter), and it lets us automate parts of security work. That means more efficiency, faster reactions to new threats, and security folks freed up for the harder problems 🧠

The goal is to help organizations make informed decisions that support their objectives. That means enforcing policies for hardening systems, preventing network misuse, quantifying business risk, and collaborating with partners to spot and mitigate threats 💅

Use cases for enterprises and for service providers are expected to overlap a lot. When you look at that overlap, service providers have extra complications, especially when information crosses administrative domains 🌈

The output of endpoint posture assessment is expected to feed into other processes too, like policy-based enforcement of acceptable state, verification and monitoring of security controls, and compliance with regulatory requirements 🫶

2. Endpoint Posture Assessment 🔍

Endpoint posture assessment is about orchestrating and performing data collection and then evaluating the posture of a given endpoint 💖 Usually, endpoint posture information gets gathered and then published to the right data repositories, so the collected info is available for further analysis that supports organizational security processes.

Endpoint posture assessment typically includes:

  • collecting the attributes of a given endpoint;
  • making the attributes available for evaluation and action; and
  • verifying that the endpoint's posture complies with enterprise standards and policy.

As part of all this, it's often necessary to identify and acquire any supporting security automation data needed to drive and feed the data collection and evaluation processes 🧚

Here's a typical workflow scenario for assessing endpoint posture 🎀:

  1. Some type of trigger starts the workflow. For example, an operator or an application might kick things off with a request, or the endpoint might start the process with an event-driven notification ⭐
  2. An operator or application selects one or more target endpoints to be assessed 🍓
  3. An operator or application selects which policies apply to the targets 🦋
  4. For each target:
    • A. The application figures out which (sets of) posture attributes need to be collected for evaluation. Implementations should be able to support (possibly mixed) sets of standardized and proprietary attributes 💅
    • B. The application might pull previously collected information from a cache or data store, like one populated by an asset management system 🌸
    • C. The application might set up communication with the target, mutually authenticate identities and authorizations, and collect posture attributes from the target 🔐
    • D. The application might set up communication with one or more intermediaries or agents, which may be local or external. When it connects to an intermediary or agent, the application can mutually authenticate their identities and determine authorizations, then collect posture attributes about the target from them 🫶
    • E. The application passes target identity and (sets of) collected attributes along to an evaluator, which is possibly an external process or external system 📨
    • F. The evaluator compares the collected posture attributes with expected values as expressed in policies ⚖️
    • G. The evaluator reports the evaluation result for the requested assessment, in a standardized or proprietary format, like a report, a log entry, a database entry, or a notification 🌈

2.1. Use Cases 🧩

The subsections below go into specific use cases for assessment planning, data collection, analysis, and related operations about publishing and using supporting data 💜 Each use case has a short summary with a simple problem statement, then a discussion of related concepts, then a list of associated building blocks. Those building blocks are the capabilities the use case needs. These use cases and building blocks mark out separate units of functionality, and different components of an architectural model may support each one 👑

2.1.1. Define, Publish, Query, and Retrieve Security Automation Data ✨

okay bestie, this use case is all about security automation data 🎀. It needs to be defined, published to one or more data stores, and then queried and retrieved from those stores, all for the explicit purpose of posture collection and evaluation. no cap, it's the backbone of the whole vibe 💅

Security automation data is basically the umbrella term for any data expression that gets generated and/or used while collecting and evaluating endpoint posture 🦋 And it comes in three flavors, each with its own personality:

Guidance 📖: this is the instructions-and-metadata stuff that tells the collection and evaluation processes what to do. The whole point is to make implementations data-driven, so you can customize their behavior without touching the deployed software. iconic 👑

This type changes in units of months and days. If assessments get more dynamic, it might need to handle changes in the scope of hours or minutes ⏰ It's usually provided by big organizations, product vendors, and some third parties, so it gets shared across large enterprises and customer communities 🌈 Sometimes access is locked down to specific authenticated users, and other times it's shared pretty openly with little to no access control.

This includes:

  • Listings of attribute identifiers whose values may be collected and evaluated.
  • Lists of attributes to collect, along with metadata covering when to collect them (based on an interval or an event), how long the collection lasts, and how to actually go about collecting them.
  • Guidance on how old collected data is allowed to be when it's used for evaluation.
  • Policies that define how to target and evaluate a set of attributes for different kinds or groups of endpoints and the assets they're made of. Sometimes it's useful to keep hierarchies of policies too 🌸
  • References to human-oriented data that gives technical, organizational, and/or policy context. Think best practices docs, legal guidance and legislation, and instructional materials for the automation data in question 📚

Attribute Data 🧚: this is the data collected (through automated and manual mechanisms) that describes organizational and posture details for specific endpoints and the assets they're composed of, like hardware, software, and accounts. It exists to characterize an endpoint (its type, its organizationally expected function or role) and to give actual and expected state data for one or more endpoints. It's what decides which posture attributes to collect from which endpoints, and it feeds one or more evaluations 💜

This type changes in units of days, minutes, and seconds, and posture attribute values usually change way more often than endpoint characterizations do 💀 It tends to be specific to each organization and each endpoint, and groups of endpoints that do the same job usually have similar attribute profiles. Generally it won't leave the organizational boundary, and it needs authentication with specific access controls 🔒

This includes:

  • Endpoint characterization data that describes the endpoint type, organizationally expected function/role, and so on.
  • Collected endpoint posture attribute values and their related context, including the time of collection, the tools used for collection, and so on.
  • Organizationally defined expected posture attribute values, targeted to specific evaluation guidance and endpoint characteristics. This lets one common set of guidance get parameterized for different groups of endpoints ✨

Processing Artifacts 🎀: this is data that's generated by, and specific to, one individual assessment process. It can be used between architectural components to drive and coordinate collection and evaluation activities. Its lifespan is bounded by the lifespan of the assessment itself. It can also be exchanged and stored to give historic context around an assessment, so individual assessments can be grouped, evaluated, and reported in an enterprise context 🌈

This includes:

  • The identified set of endpoints an assessment should be performed on.
  • The identified set of posture attributes that need to be collected from specific endpoints to perform an evaluation.
  • The resulting data from an evaluation process, including what was assessed, what it was assessed against, which collected data was used, when that data was collected, and when the evaluation happened ⏰

The information model for security automation data has to support all of those data types, plus the metadata needed for publication, query, and retrieval operations 🦋 It's expected that multiple data models will be used to express specific data types, which means specialized or extensible security automation data repositories might be needed. Each data type has its own temporal characteristics, access patterns, and access control dimensions, so different protocols and data models may need to be supported too, which pushes things further toward specialized repositories. For a description and discussion of the difference between an information model and a data model, check out [RFC3444] 📖 It's also likely that more kinds of data will show up while requirements and an architectural model are being defined. So implementations supporting this building block need to be extensible enough to add new data types, whether they're proprietary or (preferably) use a standard format 🫶

The building blocks of this use case are:

Data Definition 💅: security automation data guides and informs collection and evaluation, and lots of different roles can design it. Application implementers may build it into their applications, administrators may define guidance based on organizational policies, and operators may define guidance and attribute data as needed for evaluation at runtime, and so on. Data producers can reuse data from existing security automation data stores and/or create new data. They can build it on standardized or proprietary data models, such as the ones used for network management and/or host management 🔥

Data Publication 📣: the capability for data producers to publish data to a security automation data store for later use. Published data can be made publicly available, or access can depend on an authorization decision made using authenticated credentials. So the visibility of a given piece of security automation data, to an operator or an application, could be public, enterprise-scoped, private, or controlled in any other scope 👑

Data Query 🔍: an operator or application should be able to query a security automation data store using a set of specified criteria. The result is a listing that matches the query. That listing might contain publication metadata (like create date, modified date, publisher, and so on), the full data, a summary or snippet, or the location where the data can be retrieved 🌸

Data Retrieval 📥: a user, operator, or application acquires one or more specific security automation data entries. The location of the data might be known a priori, or it might be determined from decisions made using information from a previous query 🧚

Data Change Detection 🚨: an operator or application needs to know when security automation data it's interested in has been published to, updated in, or deleted from a security automation data store it's authorized to access 👀

These building blocks are used to acquire various instances of security automation data, based on specific data models, that drive assessment planning (see Section 2.1.2), posture attribute value collection (see Section 2.1.3), and posture evaluation (see Section 2.1.4). the whole thing is connected, bestie 💖

2.1.2. Endpoint Identification and Assessment Planning ✨

okay so this use case is all about figuring out the endpoints 🖥️, understanding what they're made of, deciding what "good" should look like for them, and then working out which posture attributes to collect so you can actually evaluate them 💅. It can be a mix of manual steps, automated steps, or both, and it might happen again for every single assessment 🔁.

The building blocks here are:

Endpoint Discovery: This is about finding out which endpoints are (or were) in the environment and available for posture assessment 🔍. You can spot endpoints by using information you already collected earlier, or by using other collection methods to gather identification and characterization data. Earlier data might come from things like network authentication exchanges 🔐.

Endpoint Characterization: This is the process of gathering and organizing attributes about an endpoint, either automatically or by typing them in by hand 📝. Think type, the function or role the organization expects it to have, and its hardware and software versions 🧩.

Endpoint Target Identification: Here you decide which candidate endpoint target or targets the assessment should run against 🎯. Depending on what triggered the assessment, that could be one endpoint or many, based on their characterized attributes ✨. The guidance describing the assessment might contain instructions or references that help determine which targets apply. If so, the Data Query and/or Data Retrieval building blocks (see Section 2.1.1) can be used to get that data 💜.

Endpoint Component Inventory: To figure out which desired states should be assessed, you first need the inventory of software, hardware, and accounts on the targeted endpoint(s) 📦. If the assessment doesn't depend on those details, you don't need this capability at all 🙅‍♀️. You can treat this process as a collection use case for specific posture attributes, and in that case the building blocks for Endpoint Posture Attribute Value Collection (see Section 2.1.3) can be used 🔄.

Posture Attribute Identification: Once you know the endpoint targets and their asset inventory, you work out which posture attributes need to be collected for the evaluation you want 🧠. When it's available, existing posture data gets queried with the Data Query building block (see Section 2.1.1) to check whether it's suitable 🔎. Posture data counts as suitable if it's complete and current enough for the evaluation. Anything unsuitable gets flagged for collection 🚩.

If this is driven by guidance, the Data Query and/or Data Retrieval building blocks (see Section 2.1.1) may be used to acquire this data too 🎀.

At this point, you know the set of posture attribute values to use for evaluation 🎉. They can be collected if needed (see Section 2.1.3) 🫶.

2.1.3. Endpoint Posture Attribute Value Collection 🧺

This use case is about collecting a set of posture attribute values for one or more endpoints 📥. It can be kicked off by a bunch of different triggers, including:

  1. a posture change or significant event on the endpoint.
  2. a network event (e.g., endpoint connects to a network/VPN, specific netflow [RFC3954] is detected).
  3. a scheduled or ad hoc collection task.

The building blocks of this use case are:

Collection Guidance Acquisition: If you need guidance to drive the collection of posture attribute values, this capability grabs it from one or more security automation data stores 📚. Depending on the trigger, you might already know which guidance to get. If not, you may need to figure out which guidance to use based on the component inventory or other assessment criteria 🕵️‍♀️. The Data Query and/or Data Retrieval building blocks (see Section 2.1.1) may be used to acquire this guidance 🌸.

Posture Attribute Value Collection: This is the accumulation of posture attribute values 🧃. It may be based on the collection guidance associated with those posture attributes 💜.

Once the posture attribute values are collected, they may be saved for later use, or they may be used for posture evaluation right away ⚡.

2.1.4. Posture Attribute Evaluation 👑

This use case is where you analyze the collected posture attribute values as part of an assessment 🔬. The main goal is to check the actual endpoint state against the expected state that was picked for the assessment ✅.

This use case can be triggered by a variety of things, including:

  1. a posture change or significant event on the endpoint.
  2. a network event (e.g., endpoint connects to a network/VPN, specific netflow [RFC3954] is detected).
  3. a scheduled or ad hoc evaluation task.

The building blocks of this use case are:

Collected Posture Change Detection: An operator or application needs a way to notice when new posture attribute values show up or when existing ones change 👀. Detection can be anywhere from immediate to on-demand ⏱️. Being able to filter which changes get detected lets the operator focus on the ones that matter to them, and it lets evaluation happen dynamically based on those detected changes 🦋.

Posture Attribute Value Query: If you need previously collected posture attribute values, the right data stores get queried to retrieve them using the Data Query building block (see Section 2.1.1) 🗂️. If all the posture attribute values are handed over directly for evaluation, this capability may not be needed 🙌.

Evaluation Guidance Acquisition: If you need guidance to drive the evaluation of posture attribute values, this capability acquires it from one or more security automation data stores 📖. Depending on the trigger, you might already know the specific guidance to get. If not, you may need to determine which guidance to use based on the component inventory or other assessment criteria 🧐. The Data Query and/or Data Retrieval building blocks (see Section 2.1.1) may be used to acquire this guidance 💖.

Posture Attribute Evaluation: This compares posture attribute values against the expected values written in the specified guidance ⚖️. The output is a set of posture evaluation results 📊. Those results include metadata that gives a level of assurance about the posture attribute data and, by extension, the evaluation results 🛡️. Examples of that metadata include provenance and/or availability data 🧾.

The main focus of this use case is comparing expected and actual state, but the same building blocks can support other analysis techniques applied to collected posture attribute data, like trending or historic analysis 📈.

Completing this process means you've finished a complete assessment cycle, as defined in Section 2 🎀.

2.2. Usage Scenarios 🌈

In this section, we walk through a few usage scenarios that use parts of endpoint posture assessment 🍓. They're examples of common problems that the building blocks defined above can solve 🔧.

2.2.1. Definition and Publication of Automatable Configuration Checklists 📋

A vendor makes a bunch of specialized endpoint devices 📱. They also build and maintain an operating system for those devices, so end-user organizations can configure a range of security and operational settings 🔐. As part of their customer support, they publish secure configuration guides that spell out minimum security guidelines for configuring their devices 💅.

Each guide applies to a specific device model and operating system version 🧸. It also includes specialized configurations depending on the device's intended function and on which add-on hardware modules and software licenses are installed 🔌. So customers can check that their devices have all the right minimum security settings turned on, the vendor publishes automatable configuration checklists 🫧. These use a popular data format that defines which settings to collect using a network management protocol, plus the appropriate value for each setting 🌟. The checklists go to a public security automation data store, where customers can query for the checklists that apply to their deployed specialized endpoint devices 🔍.

Automatable configuration checklists could also come from sources other than the device vendor, like industry groups or regulatory authorities 🏛️. Enterprises could also write their own checklists 💜.

This usage scenario uses the following building blocks from Section 2.1.1 above:

Data Definition: This lets guidance be defined using standardized or proprietary data models, which then drive collection and evaluation 📐.

Data Publication: This provides a way to publish created guidance to a security automation data store 📤.

Data Query: This is for locating and selecting existing guidance that can be reused 🔎.

Data Retrieval: This retrieves specific guidance from a security automation data store so it can be edited ✏️.

Each building block can be used manually by a human operator 🙋‍♀️. But it's also likely that these capabilities get bundled together in some kind of guidance editor or generator application 🛠️. Iconic, honestly 🔥.

2.2.2. Automated Checklist Verification 🧚

okay bestie, picture a financial services company with a super mixed IT environment 💅. For their risk management program, they use vendor-provided automatable security configuration checklists for each operating system and application in that environment. They use multiple checklists from different vendors so that every IT asset is covered 🫶

To figure out which checklists they need, they use automation to gather an inventory of the software versions used by all IT assets in the enterprise 🔍. This data gathering queries existing data stores of previously collected endpoint software inventory posture data, and it also actively collects data from reachable endpoints when needed, using network and systems management protocols. The previously collected data can come from periodic data collection, network connection-driven data collection, or ongoing event-driven monitoring of endpoint posture changes ✨

Next, the appropriate checklists get queried, located, and downloaded from the relevant guidance data stores 📥. The specific data stores queried, and the specifics of each query, can be driven by data including:

  • collected hardware and software inventory data, and
  • associated asset characterization data that may indicate the organizationally defined functions of each endpoint.

Checklists can come from guidance data stores maintained by an application or OS vendor, an industry group, a regulatory authority, or directly by the enterprise 🌸

The retrieved guidance gets cached locally, so they don't have to retrieve the same data over and over again 🧠

Now the checklist's setting data drives things 🎀. A mix of existing configuration data stores and data collection methods gathers the right posture attributes from (or pertaining to) each endpoint. The specific posture attribute values depend on the defined enterprise function and software inventory of each endpoint. The collection mechanisms used to collect software inventory posture get reused for this purpose too 🔁. Once the data is in, the actual state gets evaluated against the expected state criteria defined in each applicable checklist ✅

A checklist can be assessed as a whole, or just a specific subset of it can be assessed, which means partial data collection and evaluation 🦋

The results of checklist evaluation go to the appropriate operators and applications to drive additional business logic 💼. Specific applications for those results are out of scope for current SACM (Security Automation and Continuous Monitoring) efforts 🙈. No matter the application, the availability, timeliness, and liveness of results are often a general concern. Network latency and available bandwidth often create operational constraints that force trade-offs between these concerns, so those need to be considered too 😭

Uses of checklists and their evaluation results may include, but are not limited to:

  • Detecting endpoint posture deviations as part of a change management program to identify:
    • missing required patches,
    • unauthorized changes to hardware and software inventory, and
    • unauthorized changes to configuration items.
  • Determining compliance with organizational policies governing endpoint posture.
  • Informing configuration management, patch management, and vulnerability mitigation and remediation decisions.
  • Searching for current and historic indicators of compromise.
  • Detecting current and historic infection by malware and determining the scope of infection within an enterprise.
  • Detecting performance, attack, and vulnerable conditions that warrant additional network diagnostics, monitoring, and analysis.
  • Informing network access control decision-making for wired, wireless, or VPN connections. 🛡️

This usage scenario employs the following building blocks defined in Section 2.1.1 above:

  • Endpoint Discovery: The purpose of discovery is to determine the type of endpoint to be posture assessed. 🔎
  • Endpoint Target Identification: To identify what potential endpoint targets the checklist should apply to, based on organizational policies. 🎯
  • Endpoint Component Inventory: Collecting and consuming the software and hardware inventory for the target endpoints. 📋
  • Posture Attribute Identification: To determine what data needs to be collected to support evaluation, the checklist is evaluated against the component inventory and other endpoint metadata to determine the set of posture attribute values that are needed. 🧩
  • Collection Guidance Acquisition: Based on the identified posture attributes, the application will query appropriate security automation data stores to find the "applicable" collection guidance for each endpoint in question. 📚
  • Posture Attribute Value Collection: For each endpoint, the values for the required posture attributes are collected. 📥
  • Posture Attribute Value Query: If previously collected posture attribute values are used, they are queried from the appropriate data stores for the target endpoint(s). 🗂️
  • Evaluation Guidance Acquisition: Any guidance that is needed to support evaluation is queried and retrieved. 💡
  • Posture Attribute Evaluation: The resulting posture attribute values from previous collection processes are evaluated using the evaluation guidance to provide a set of posture results. 👑

2.2.3. Detection of Posture Deviations 🚨

Example Corporation has established secure configuration baselines for each different type of endpoint in their enterprise, including: network infrastructure, mobile, client, and server computing platforms 🏢. These baselines define an approved list of hardware, software (i.e., operating system, applications, and patches), and associated required configurations. When an endpoint connects to the network, the appropriate baseline configuration gets communicated to the endpoint based on its location in the network, the expected function of the device, and other asset management data 🔌. The endpoint is checked for compliance with the baseline, and any deviations are indicated to the device's operators 👀. Once the baseline is established, the endpoint is monitored for any change events pertaining to the baseline on an ongoing basis. When a change occurs to posture defined in the baseline, updated posture information gets exchanged, which lets operators be notified and/or automated action be taken 🔔

Like the Automated Checklist Verification usage scenario (see Section 2.2.2), this usage scenario supports assessment based on automatable checklists 🧾. The difference is that it monitors for specific endpoint posture changes on an ongoing basis 🔄. When the endpoint detects a posture change, an alert is generated that identifies the specific changes in posture. That means only the delta needs to be assessed, instead of doing a full assessment like in the previous case ⚡. This usage scenario employs the same building blocks as Automated Checklist Verification (see section 2.2.2). It differs slightly in how it uses the following building blocks:

  • Endpoint Component Inventory: Additionally, changes to the hardware and software inventory are monitored, with changes causing alerts to be issued. 📦
  • Posture Attribute Value Collection: After the initial assessment, posture attributes are monitored for changes. If any of the selected posture attribute values change, an alert is issued. 👁️
  • Posture Attribute Value Query: The previous state of posture attributes is tracked, allowing changes to be detected. 🕰️
  • Posture Attribute Evaluation: After the initial assessment, a partial evaluation is performed based on changes to specific posture attributes. 🧮

This usage scenario highlights the need to query a data store to prepare a compliance report for a specific endpoint, and also the need for a change in endpoint state to trigger Collection and Evaluation 💖

2.2.4. Endpoint Information Analysis and Reporting 🕵️‍♀️

Freed from the drudgery of manual endpoint compliance monitoring 💅, one of the security administrators at Example Corporation notices (not using SACM standards) that five endpoints have been uploading lots of data to a suspicious server on the Internet 😱. She queries data stores for specific endpoint posture to see what software is installed on those endpoints, and finds that they all have a particular program installed. Then she queries the appropriate data stores to see which other endpoints have that program installed. All of these endpoints are monitored carefully (not using SACM standards), which lets the administrator detect that the other endpoints are also infected 🦠💀

This is just one example of the useful analysis a skilled analyst can do using data stores of endpoint posture 🧠✨

This usage scenario employs the following building blocks defined in Section 2.1.1 above:

  • Posture Attribute Value Query: Previously collected posture attribute values for the target endpoint(s) are queried from the appropriate data stores using a standardized method. 🗃️

This usage scenario highlights the need to query a repository for attributes, to see which attributes certain endpoints have in common 🌈

2.2.5. Asynchronous Compliance/Vulnerability Assessment at Ice Station Zebra 🧊🐾

okay so picture this 🧊 a university team gets a grant to do research at a government facility in the Arctic. the ONLY internet they have is an intermittent, low-speed, high-latency, super-expensive satellite link 😭 interactive assessments are basically not happening, and since they're broke (grant money is not it), they need to keep their network data bill as low as possible 💸

before they leave, they register all their equipment with an asset management system owned by the university. that system is also the thing that starts and tracks assessments 📋

on a regular schedule, the university pulls info from the asset management system and builds a collection request for every deployed asset 🎀 it's the minimal set of artifacts needed to check all three security policies and vulnerability testing. the schedule triggers either after a maximum time delta or when the security automation data store has picked up a threshold number of new vulnerability definitions 🔔

if there's a new critical vulnerability, the request gets even slimmer 💅 it only includes the artifacts needed for that vulnerability, and only the assets that could possibly be affected get the request. so no wasting bandwidth on the whole fleet, bestie 🙅‍♀️

(Optional) asset artifacts can be cached in a local configuration management database (CMDB) 🗂️ when new vulnerabilities show up in the security automation data store, the team only sends a request to the live asset if the CMDB copy is incomplete and/or not current enough. cache hit = no satellite fee 🤑

the collection request then waits in a queue for the next window of connectivity ⏳ the deployed assets eventually get it, fulfill it, and queue their results for the next return opportunity 📬

eventually the collected artifacts make their way back to the university 🏫 that's where they calculate the level of compliance and the vulnerability exposure, and compare the asset characteristics against what's in the asset management system to check for accuracy and completeness 🔍

ngl this scenario is giving checklists, just like the Automated Checklist Verification usage scenario (see section 2.2.2) ✅ the difference is how guidance, collected posture attribute values, and evaluation results get exchanged, because bandwidth is tight and the link is not always there 🥺 it uses the same building blocks as Automated Checklist Verification (see section 2.2.2), but it handles these ones a little differently:

  • Endpoint Component Inventory: the component inventory will probably not change 🤞 if it does change, that info gets batched and sent during the next communication window.
  • Collection Guidance Acquisition: because the windows are intermittent and bandwidth is limited, changes to collection guidance get batched and sent during the next communication window 📦 the guidance also gets cached locally so the team doesn't need to talk to the remote side.
  • Posture Attribute Value Collection: the specific posture attribute values to collect are identified remotely and batched for collection during the next communication window 🕐 if a delay is introduced for collection to finish, the results get batched and transmitted.
  • Posture Attribute Value Query: previously collected posture attribute values are stored in a remote data store so they can be used at the university 🏫
  • Evaluation Guidance Acquisition: same energy as collection guidance 💅 changes to evaluation guidance get batched and sent during the next communication window, and the guidance gets cached locally to avoid remote communications.
  • Posture Attribute Evaluation: since the attribute values and evaluation guidance are cached, evaluation can happen at the university campus and at the satellite site 🌍 two places, one vibe 🧚

the whole point of this scenario is that it really highlights the need to support low-bandwidth, intermittent, or high-latency links 🛰️✨ this is a main character use case, fr fr 👑

2.2.6. Identification and Retrieval of Guidance 🔎

okay so before anyone can run an assessment, an operator or application needs to figure out which security automation data stores have the guidance entries needed for data collection and evaluation tasks 🧠 the location of a guidance entry is either already known ahead of time, or the known security automation data stores have to be queried to find the applicable guidance 🗺️

to query guidance, you have to define a set of search criteria 🎯 this criteria will often be a logical combination of publication metadata (e.g., publishing identity, create time, modification time) and criteria elements that are specific to the guidance data 🧩 once the criteria are set, one or more security automation data stores get queried, and that produces a result set 📊 depending on how the results are going to be used, you might want the matching guidance returned directly, a snippet of the guidance that matches the query, or a resolvable location to retrieve the data later 🔗 the guidance that matches is also restricted based on the authorized level of access allowed to the requester 🔐 no peeking, bestie 🙅‍♀️

if the result set includes the location of guidance, the guidance gets retrieved when it's needed, using one or more data retrieval requests 📥 a variation on this is keeping a local cache of previously retrieved data 🗃️ in that case, only guidance that's considered stale by some measure gets retrieved from the remote data store ♻️

another option is to discover guidance by iterating over data published with a given context within a security automation data store 🔁 specific guidance can then be selected and retrieved as needed 💖

this usage scenario uses the following building blocks defined in Section 2.1.1 above:

  • Data Query: lets an operator or application query one or more security automation data stores for guidance using a set of specified criteria 🔍
  • Data Retrieval: if data locations come back in the query result set, then specific guidance entries can be retrieved and possibly cached locally 📦

2.2.7. Guidance Change Detection 🚨

okay so an operator or application might need to spot new, updated, or deleted guidance in a security automation data store that they're authorized to access 👀 this can be done by querying or iterating over guidance in the store, or through a notification mechanism that generates alerts whenever changes are made to the store 🔔 ngl the notification version is very iconic 🦋

once the guidance changes have been figured out, data collection and evaluation activities may be triggered 🎬

this usage scenario uses the following building blocks defined in Section 2.1.1 above:

  • Data Change Detection: lets an operator or application identify guidance changes in a security automation data store that they're authorized to access 🕵️‍♀️
  • Data Retrieval: if data locations are provided by the change detection mechanism, then specific guidance entries can be retrieved and possibly cached locally 📥

3. Security Considerations 🔐

okay bestie, this part is SERIOUS 😤 this memo is informational. it documents use cases for security automation 📚 specific security and privacy considerations will be provided in related documents (e.g., requirements, architecture, information model, data model, protocol) as appropriate to the function described in each of those documents 📑

one thing to watch out for: a malicious actor could use the security automation infrastructure and the related collected data to get access to something of interest 😱 that could include personal data, private keys, software and configuration state that can be used to plan an attack against the network and endpoints, and other sensitive info 💀 it's important that the security and privacy considerations in the related documents explain how to both identify and prevent that kind of activity 🚫

we also need to think about protecting the communications AND the systems that store the information 🛡️ for communications between the various SACM components, there should be considerations for protecting confidentiality, data integrity, and peer entity authentication 🔒 for exchanged information, there should be a way to authenticate where the information came from 🧾 this matters a LOT when tracking provenance of data is needed 🕵️ and for any systems that store information that could be used for unauthorized or malicious purposes, methods to identify and protect against unauthorized usage, inappropriate usage, and denial of service need to be considered 🚨 dramatic, but it's giving real stakes 💅

4. Informative References 📚

[RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between Information Models and Data Models", RFC 3444, DOI 10.17487/RFC3444, January 2003, <http://www.rfc-editor.org/info/rfc3444>.

[RFC3954] Claise, B., Ed., "Cisco Systems NetFlow Services Export Version 9", RFC 3954, DOI 10.17487/RFC3954, October 2004, <http://www.rfc-editor.org/info/rfc3954>.

Acknowledgements 🫶

Adam Montville edited early versions of this document 💜

Kathleen Moriarty and Stephen Hanna contributed text describing the scope of the document 🌸

Gunnar Engelbach, Steve Hanna, Chris Inacio, Kent Landfield, Lisa Lorenzin, Adam Montville, Kathleen Moriarty, Nancy Cam-Winget, and Aron Woland provided text about the use cases for various revisions of this document 🌈 the whole squad, obsessed with all of you 😭✨

Authors' Addresses 🎀

David Waltermire National Institute of Standards and Technology 100 Bureau Drive Gaithersburg, Maryland 20877 United States

Email: david.waltermire@nist.gov

David Harrington Effective Software 16 Bayview Drive Westerly, Rhode Island 02891 United States

Email: ietfdbh@gmail.com

📦 where this page comes from