RFC 8248

Security Automation and Continuous Monitoring (SACM) Requirements

📅 published September 2017, from ietf

Security Automation and Continuous Monitoring (SACM) Requirements ✨

Okay bestie, let's get into it 💖 This one is RFC 8248, and it's the requirements doc for SACM (Security Automation and Continuous Monitoring) 🦋 It's been published as Informational, which means it's giving "here's the vibe and the checklist," not a Standards Track spec 🌸

Authors: N. Cam-Winget (Cisco Systems) and L. Lorenzin (Pulse Secure) 💅 It came out in September 2017 from the IETF, and it's ISSN 2070-1721 🧚

It doesn't obsolete anything, and it doesn't update anything either. Clean slate, no cap 🫶

Abstract

Okay so the abstract is basically the TL;DR 😭 This doc lays out the scope and the requirements for the SACM architecture, data model, and transfer protocols. Everything here is built on the agreed-upon use cases from RFC 7632, which is iconic 👑

Status of This Memo

Real talk, this is the "not a standard, just info" disclaimer 🙈 It's not an Internet Standards Track spec. It's published for informational purposes only 🍓

It is still a product of the IETF, so it does represent consensus of the IETF community 🌈 It got public review and was approved by the IESG. Not everything the IESG approves becomes a Standard though, so see Section 2 of RFC 7841 for that tea ☕

If you want current status, errata, or feedback info, check https://www.rfc-editor.org/info/rfc8248 🎀

Copyright (c) 2017 IETF Trust and the document authors. All rights reserved 💜

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stood on the publication date. Read these carefully, bestie, they spell out your rights 🦋

Code Components pulled out of this document have to include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions. They come without warranty, per the Simplified BSD License ⭐

Table of Contents

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
  1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
2.  Requirements  . . . . . . . . . . . . . . . . . . . . . . . .   3
  2.1.  Requirements for SACM . . . . . . . . . . . . . . . . . .   4
  2.2.  Requirements for the Architecture . . . . . . . . . . . .   7
  2.3.  Requirements for the Information Model  . . . . . . . . .   9
  2.4.  Requirements for the Data Model . . . . . . . . . . . . .  10
  2.5.  Requirements for Data Model Operations  . . . . . . . . .  12
  2.6.  Requirements for SACM Transfer Protocols  . . . . . . . .  14
3.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  15
4.  Security Considerations . . . . . . . . . . . . . . . . . . .  15
  4.1.  Trust between Provider and Requestor  . . . . . . . . . .  16
  4.2.  Privacy Considerations  . . . . . . . . . . . . . . . . .  17
5.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  18
  5.1.  Normative References  . . . . . . . . . . . . . . . . . .  18
  5.2.  Informative References  . . . . . . . . . . . . . . . . .  18
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  18
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  19

1. Introduction ✨

Okay so the world is getting way more dangerous security-wise, and it's giving "we need to automate sharing security info" 😭 Think posture info, like what's on a device. But we also have to protect user info and the systems that store, process, and transmit it 🔥 Threats can be spotted in a bunch of different ways. The SACM charter is all about how to collect and share that info, based on use cases about posture assessment of endpoints 🌸

Here's the big picture: scalable and sustainable collection, expression, and evaluation of endpoint info is the foundation of SACM's goals 💅 If you want to defend a network, you have to reliably figure out what devices are on it, how those devices are configured at the hardware level, what software is installed, and how that software is configured 🧚 You need to determine, share, and use this info in a way that's secure, timely, consistent, and automated, all to do endpoint posture assessments 💖

This doc is focused on the requirements for swapping posture assessment info in the enterprise, especially for the use cases shown in [RFC7632] 🦋

As proposals get evaluated for SACM standardization, each proposal's document is expected to include a section explaining how the listed requirements are addressed 🎀

This doc uses terminology defined in [TERMS] 🫶

1.1. Requirements Language

Real talk, these capitalized words have special meanings during the SACM WG's protocol selection process 💜

MUST - indicates an absolute requirement 💅

MUST NOT - indicates something absolutely prohibited 🙈

SHOULD - indicates a strong recommendation of a desired result ✨

SHOULD NOT - indicates a strong recommendation against a result 💀

MAY - indicates a willingness to allow an optional outcome 🌈

When the words show up in lower case, they just mean what they mean in normal English 🍓

2. Requirements ✨

Okay bestie, this section is the checklist SACM uses to assess and compare candidate data models, interfaces, and protocols 👑 These requirements describe what a candidate protocol, information model, or data model must be able to offer so it's secure and interoperable 🔥

Multiple data models, protocols, and transfers may be used together in a SACM environment 🦋 A SACM transfer protocol is one that runs on top of transport-layer protocols like TCP/IP, or internet-layer protocols like HTTP. It carries operations (requests and responses) and moves data 🌸

SACM is going to define an architecture and information model focused on figuring out, sharing, and using posture info securely, through posture information providers and posture information consumers 💖 The information model defines assets and attributes to help with guidance, collection, and assessment of posture. Tasks to consider include:

  1. Asset Classification: Map the target endpoint and/or the assets on it to asset classes. This lets you identify the attributes you need to exchange info about the target endpoint 🧚
  2. Attribute Definition: Define the attributes you want to collect from each target endpoint. For example, orgs will want to know what software is installed and its critical security attributes, like patch level 🎀
  3. Policy Definition: This is where an organization gets to express its policy for acceptable or problematic values of an endpoint attribute 💜 The expected values get decided ahead of time so they can be compared against the actual endpoint attribute values during evaluation. Expected values can include good values and values that represent problems, like vulnerabilities 🙈 The organization can also say which endpoint attributes must be present for a given target endpoint ✨
  4. Information Collection: Collect info (attribute values) from the target endpoint to fill in the endpoint data 🌈
  5. Endpoint Assessment: Compare the actual values of the endpoint attributes against what the policy says. (An evaluation result can become additional endpoint data too 🫶)
  6. Result Reporting: Report the evaluation results for other components to use. Examples include additional evaluation, network enforcement, vulnerability detection, and license management 🍓

2.1. Requirements for SACM ✨

okay so, lots of deployment setups can be built to handle the tasks above and the use cases in [RFC7632] 💅. To keep everything interoperable, scalable, and flexible across all of them, here's the list of requirements for proposed SACM standards 🫶:

G-001 (Solution Extensibility): The information model, data models, protocols, and transfers SACM defines MUST be designed so future extensions can be supported 🔥. SACM MUST allow for both standardized and proprietary extensions.

  1. The information model and programmatic interfaces (see G-012 for one example) MUST support adding new operations while staying backwards compatible 🎀. SACM-defined transfer protocols MUST have extensibility so they can transfer operations that get defined in the future.
  2. The query language MUST allow for general inquiries, plus expressing specific attributes or relationships between attributes. It also needs to cover retrieving info based on an event or on a continuous basis 🦋, and retrieving specific pieces of information, specific types or classes of information, or the entire set of what's available.
  3. The information model MUST accommodate the interoperable addition of new data types and/or schemas 🌈.

G-002 (Interoperability): The data models, protocols, and transports MUST be specified with enough detail to ensure interoperability 🌸.

G-003 (Scalability): SACM needs to support a broad set of deployment scenarios 🧚. The data models, protocols, and transports have to be scalable, unless they're specifically defined for a special-purpose scenario, like constrained devices. A SACM transfer protocol standard SHOULD include a section on scalability considerations that covers the number of endpoints and amount of information it can reasonably be expected to scale to. Scalability must be addressed to support:

  • Large messages: posture assessment info can range from a single small assessment all the way up to a very large message or a very large set of assessments (up to multiple gigabytes in size) 📦
  • Large number of messages per second: a deployment may involve lots of rapid or simultaneous events that need processing, generating many messages per second ⚡
  • Large number of providers and consumers: a deployment may consist of a very large number of endpoints requesting and/or producing posture assessment info 🙌
  • Large number of target endpoints: a deployment may be managing info about a very large number of target endpoints 🌍

G-004 (Versatility): The data model, protocols, and transports must be suitably specified so implementations can fit into different deployment models and scenarios 💖. That includes considerations for data models and transports operating in constrained environments. Separate solutions may be necessary to meet the needs of specific deployment models and scenarios ✨.

G-005 (Information Extensibility): Non-standard (implementation-specific) attributes MUST be supported 🎀. A method SHOULD be defined to prevent collisions in the naming of all attributes, no matter where they came from. For interoperability and scope boundary, the information model MUST define the mandatory set of attributes 📋.

G-006 (Data Protection): To protect the info being shared, SACM components MUST protect the integrity and confidentiality of data in transit (end to end) and data at rest (as it's stored in repositories) 🔒. The protection mechanisms are unspecified, but should include industry best practices. These mechanisms are required to be available, meaning all data-handling components must support them, but they aren't required to be used in every case 💅.

G-007 (Data Partitioning): A method for partitioning data MUST be supported 🗺️. This covers things like geographic, regulatory, and operational requirements, overlay boundaries, and federation (where data may be collected in multiple locations and either centralized or kept in the local region). Where replication of data is supported, it is required that methods exist to prevent update loops 🔁.

G-008 (Versioning and Backward Compatibility): Announcing and negotiating versions, including existing capabilities (such as transfer protocols, data models, specific attributes within data models, standard attribute expression sets, etc.), MUST be supported 🌟. Negotiation for both versioning and capabilities is needed to accommodate future growth and ecosystems with mixed capabilities 🦄.

G-009 (Information Discovery): There MUST be mechanisms that let components discover what info is available across the ecosystem. That means a way to catalog the data available and advertise it to consumers, a way to figure out where to go for a specific piece of info (which provider has it), and a way to find out what schemas are in use for organizing the info 🔍. For example, a method can be provided by which a node can locate the advertised info, so consumers are not required to have a priori knowledge to find what's available 🧭.

G-010 (Target Endpoint Discovery): SACM MUST define the means by which target endpoints may be discovered 👀. The use case in Section 2.1.2 of [RFC7632] describes the need to discover endpoints and their composition.

G-011 (Push and Pull Access): Three methods of data access MUST be supported: a Pull model, a solicited Push model, and an unsolicited Push model 📬. All of the methods of data access MUST support the ability for the initiator to filter the set of posture assessment info to be delivered. On top of that, the provider of the info MUST be able to filter the set based on the permissions of the recipient 🛡️. This requirement is driven by the use cases in Sections 2.1.3 and 2.1.4 of [RFC7632].

G-012 (SACM Component Interface): The interfaces that SACM components use to communicate and share endpoint posture info MUST be well defined 🤝. In other words, the interface defines the data model, SACM transfer protocols, and network transfer protocols that let SACM components talk to each other.

G-013 (Endpoint Location and Network Topology): The SACM architecture and interfaces MUST allow the target endpoint (network) location and network topology to be modeled and understood 🗺️. Where appropriate, the data model and the interfaces SHOULD allow for discovery of the target endpoint location, the network topology, or both.

G-014 (Target Endpoint Identity): The SACM architecture and interfaces MUST support components providing attributes that can be used to compose an identity for a target endpoint 🪪. These identities MAY be composed of attributes from one or more SACM components.

G-015 (Data Access Control): Methods of access control must be supported to accommodate considerations such as geographic, regulatory, operational, and federations 🚪. Entities accessing or publishing data MUST identify themselves and pass access policy 💜.

2.2. Requirements for the Architecture

Here are the requirements for the SACM architecture 🏗️:

ARCH-001 (Component Functions): At the simplest abstraction, the SACM architecture MUST represent the core components and interfaces needed to produce and consume posture assessment info ✨.

ARCH-002 (Scalability): The architectural components MUST account for a range of deployments, from very small sets of endpoints to very large deployments 📈.

ARCH-003 (Flexibility): The architectural components MUST account for different deployment scenarios 🦋. They may be implemented, deployed, or used within a single application, service, or network, or they may make up a federated system.

ARCH-004 (Separation of Data and Management Functions): SACM MUST define both the configuration and the management of the SACM data models and protocols used to transfer and share posture assessment info ⚙️.

ARCH-005 (Topology Flexibility): Both centralized and decentralized (peer-to-peer) info exchange MUST be supported 🌐. Centralized data exchange lets you use a common data format to bridge data exchange between diverse systems, and it can lean on a virtual data store that centralizes and offloads all data access, storage, and maintenance to a dedicated resource. Decentralized data exchange keeps sharing simple between relatively uniform systems and small numbers of systems, especially within a single enterprise domain. Whether a deployment is centralized or decentralized SHOULD be invisible to a consumer 🙈. However, there may be cases where the producer chooses to include that info because the consumer prefers it.

ARCH-006 (Capability Negotiation): Announcing and negotiating functional capabilities (such as authentication protocols, authorization schemes, data models, transfer protocols, etc.) MUST be supported 🤓. This lets a SACM component ask about the capabilities of other components in the SACM ecosystem.

ARCH-007 (Role-Based Authorization): The SACM architecture MUST be capable of role-based authorization 👑. Telling apart the endpoints that are capable of and authorized to provide or consume info is required to address appropriate access controls.

ARCH-008 (Context-Based Authorization): The SACM architecture MUST be capable of context-based authorization 🌸. Different policies (business, regulatory, etc.) might specify what data may be exposed to, or shared by, consumers based on one or more attributes of the consumer. The policy might also specify that consumers are required to share specific info either back to the system or to administrators.

ARCH-009 (Time Synchronization): Actions or decisions based on time-sensitive data (like user logon/logoff, endpoint connection/disconnection, endpoint behavior events, etc.) all depend on a synchronized understanding of time ⏰. The SACM architecture MUST provide a mechanism for all components to synchronize time. A mechanism for detecting and reporting time discrepancies SHOULD be provided by the architecture and reflected in the information model 🫶.

2.3. Requirements for the Information Model ✨

okay so this is where the SACM information model gets its rules 💅 the information model is basically the abstract "blueprint" for what posture assessment info can be communicated and how it's supposed to look 🎀 every SACM data model has to adhere to and comply with it, no cap. here's the crew of requirements:

IM-001 (Extensible Attribute Vocabulary): the information model MUST define a minimum set of attributes for communicating posture information, so that data models can actually interoperate 🫶 (individual data models can define attributes beyond that mandatory-to-implement minimum set.) the attributes SHOULD come with a clear mechanism for extensibility, so data models can adhere to SACM's required attributes AND add their own extensions 🌈 the attribute vocabulary SHOULD also have a clear extensibility mechanism so future versions of the information model can be expanded with new attributes in an interoperable way 💜

IM-002 (Posture Data Publication): the information model MUST allow the data to be provided by a SACM component either solicited or unsolicited 🦋 and no aspect of the information model should be dependent upon or assume a Push or Pull model of publication. it's giving "no assumptions allowed" 🙈

IM-003 (Data Model Negotiation): SACM's information model MUST allow support for different data models, different data model versions, and different versions of the operations on the data models and transfer protocols 🍓 the SACM information model MUST include the ability to discover and negotiate the use of a particular data model or any data model 👑

IM-004 (Data Model Identification): the information model MUST provide a means to uniquely identify each data model 🧚 the identifier MUST contain both an identifier of the data model AND a version indicator for the data model ✨ the identifiers SHOULD be decomposable so that a customer can query for any version of a specific data model and compare returned values for older or newer than a desired version 🌸

IM-005 (Data Lifetime Management): the information model MUST provide a means to allow data models to include data lifetime management 💖 the information model must identify attributes that can allow data models to, at minimum, identify the data's origination time and expected time of next update or data longevity (how long the data should be assumed to still be valid) ⭐

IM-006 (Singularity and Modularity): the SACM information model MUST be singular (aka there is only ONE information model, not multiple alternative ones to choose from) 🔥 and it MAY be modular (a conjunction of several subcomponents) for ease of maintenance and extension 🫶 for example, endpoint identification could be an independent subcomponent of the information model, so updating endpoint identification attributes is simpler 🎀

2.4. Requirements for the Data Model 🌈

okay so the information model is the "what" and the "how it's represented and shared" 💅 applications that produce posture assessment info may share it using a specific data model, and applications that consume or request that info may need it based on a specific data model too 🦋 so yeah, there can be different data models and schemas, but they SHOULD adhere to the SACM information model and meet the requirements in this section 💜

the specific requirements for candidate data models are:

DM-001 (Element Association): a SACM information model consists of a set of SACM information model elements 🌸 a SACM data model MUST be derived from the SACM information model 💖 a SACM data model consists of a set of SACM data model elements ✨ in this derivation, a SACM data model element MAY map to one or more SACM information model elements 🧚 and a SACM data model MAY include additional data model elements that aren't associated with any SACM information model elements 🫶

DM-002 (Data Model Structure): the data model can be structured either as one single module or separated into modules and submodules that allow for references between them 🎀 the data model structure MAY reflect the structure of the information model but doesn't need to 🍓 for example, the data model might use one module to define endpoints, and that module might reference other modules describing the various assets associated with the endpoint 👑 constraints and interfaces might further be defined to resolve or tolerate ambiguity in the references (e.g., the same IP address used in two separate networks) 🔥

DM-003 (Search Flexibility): the search interfaces and actions MUST include the ability to start a search anywhere within a data model structure 💅 and the ability to search based on patterns ("wildcard searches") as well as specific data elements 🦋

DM-004 (Full vs. Partial Updates): the data model SHOULD let providers of data provide the data as a whole OR when updates occur 🌈 for example, a consumer can request a full update on initial engagement, then request deltas (updates containing only the changes since the last update) on an ongoing basis as new data is generated 💜

DM-005 (Loose Coupling): the data model SHOULD allow for a loose coupling between provider and consumer 🙈 so the consumer can request information without being required to request it from a specific provider, and a provider can publish information without a specific consumer targeted to receive it 🌸

DM-006 (Data Cardinality): the data model MUST describe its constraints (e.g., cardinality) 💖 since posture information and the tasks for collection, aggregation, or evaluation could comprise one or more attributes, interfaces and actions MUST allow and account for that cardinality, plus conditional, optional, or mandatory attributes ⭐

DM-007 (Data Model Negotiation): the interfaces and actions in the data model MUST include capability negotiation so you can discover supported and available data types and schemas 🔥

DM-008 (Data Origin): the data model MUST include the ability for consumers to identify the data origin (the provider that collected the data) 🫶

DM-009 (Origination Time): the data model SHOULD allow the provider to include the information's origination time 🎀

DM-010 (Data Generation): the data model MUST allow the provider to include attributes defining how the data was generated (e.g., self-reported, reported by aggregator, scan result, etc.) 🍓

DM-011 (Data Source): the data model MUST allow the provider to include attributes identifying the data source (the target endpoint the data was collected from), e.g., hostname, domain (DNS) name, or application name 👑

DM-012 (Data Updates): the data model SHOULD allow the provider to include attributes defining whether the info provided is a delta, partial, or full set of information 🔥

DM-013 (Multiple Collectors): the data model MUST support the collection of attributes by a variety of collectors, including internal collectors, external collectors with an authenticated relationship with the endpoint, and external collectors based on network and other observers 💅

DM-014 (Attribute Extensibility): all of the use cases in Section 2 of [RFC7632] describe the need for an attribute dictionary 🦋 with SACM's scope focused on posture assessment, the data model attribute collection and aggregation MUST have a well-understood set of attributes, including their meaning or usage intent 🌈 the data model MUST include all attributes defined in the information model and MAY include additional attributes beyond those 💜 additional attributes MUST be defined in accordance with the extensibility framework provided in the information model (see IM-001) 🙈

DM-015 (Solicited vs. Unsolicited Updates): the data model MUST enable a provider to publish data either solicited (in response to a request from a consumer) or unsolicited (as new data is generated, without a request required) 🌸 for example, an external collector can publish data in response to a consumer's request about an endpoint, or it can publish data as it observes new information about an endpoint with no consumer request triggering it 💖 and a compliance-server provider may publish endpoint posture info in response to a consumer's request (solicited), or publish posture info driven by a change in the endpoint's posture (unsolicited) ✨

DM-016 (Transfer Agnostic): the data model MUST be transfer agnostic, so data operations can leverage the most appropriate SACM transfer protocol 🧚👑

2.5. Requirements for Data Model Operations ✨

Okay bestie, posture data that follows a data model also needs interfaces for accessing and producing it 💅 Operations requirements are different from transfer requirements. Operations requirements are about the application making requests and sending responses 🫶, while transfer requirements are about the transfer protocol carrying those requests and responses 🚚. Here's the list, and ngl, it's iconic:

OP-001 (Time Synchronization): Request and response operations MUST be timestamped, and published information SHOULD capture the time of publication ⏰. Actions or decisions based on time-sensitive data (like user logon/logoff, endpoint connection/disconnection, endpoint behavior events, and so on) all depend on a synchronized understanding of time 🕰️. A method for detecting and reporting time discrepancies SHOULD be provided.

OP-002 (Collection Abstraction): Collection is when a SACM component gathers data from a target endpoint 🎯. The request for a data item MUST include enough information to properly identify the item to collect, but the request shall not be a command to directly execute nor be directly applied as arguments to a command 🙅‍♀️. The main purpose is to reduce potential attack vectors 🛡️. It also has the bonus of separating the request for collection from the collection method, so there's more flexibility in how collection gets implemented 🦋.

OP-003 (Collection Composition): A collection request MAY be composed of multiple collection requests (which yield collected values) 🧩. If you want multiple values, that desire MUST be expressed as part of the collection request, so the aggregation can be resolved at the point of collection without having to interact with the requestor again 🔁. This requirement should not be read as stopping a collector from providing attributes that weren't part of the original request 🙌.

OP-004 (Attribute-Based Query): A query operation is the act of requesting data from a provider 📬. Query operations SHOULD be based on a set of attributes. Query operations MUST support both a query for specific attributes and a query for all attributes 🔍. The use case in Section 2.1.2 of [RFC7632] describes why the data model needs to support a query operation based on a set of attributes. This helps with collecting things like posture assessment, inventory (of endpoints or endpoint components), and configuration checklist 📋.

OP-005 (Information-Based Query with Filtering): The query operation MUST support filtering 🧹. The use case in Section 2.1.3 of [RFC7632] describes why the data model needs to support ways for information to be collected through a query mechanism. The query operation also needs filtering capabilities so that only a subset of information gets retrieved 🎚️. The query operation MAY be a synchronous request or an asynchronous request ⏳.

OP-006 (Operation Scalability): The operation resulting from a query operation MUST be able to handle the return and receipt of large amounts of data 📦. The use case in Section 2.1.4 of [RFC7632] describes the need for the data model to support scalability. For example, the query operation may result in a very large set of attributes as well as a large set of targets 🌊.

OP-007 (Data Abstraction): The data model MUST allow a SACM component to communicate what data was used to construct the target endpoint's identity. That way, other SACM components can figure out whether they're constructing an equivalent target endpoint (and its identity) and whether they have confidence in that identity 🪪. SACM components SHOULD have interfaces defined to transmit this data directly or to refer to where the information can be retrieved 📍.

OP-008 (Provider Restriction): Request operations MUST include the ability to restrict the data to be provided by a specific provider or a provider with specific characteristics 🚦. Response operations MUST include the ability to identify the provider that supplied the response 🏷️. For example, a SACM consumer should be able to request that all of the data come from a specific provider by identity (e.g., Provider A) or from a provider that is in a specific location (e.g., in the Boston office) 🌆.

2.6. Requirements for SACM Transfer Protocols 🚀

The term "SACM transfer protocol" is meant to be distinguished from underlying transport- and internet-layer protocols like TCP/IP, and from application-layer protocols like HTTP 🧠. The SACM transfer protocol focuses on moving data and performing the necessary access control operations. It doesn't care about data model operations 💁.

The requirements for SACM transfer protocols include:

T-001 (Multiple Transfer Protocol Support): SACM transfer protocols will vary depending on the deployment model, since different deployments rely on different transfer-layer requirements, device capabilities, and system configurations dealing with connectivity 🌐. For example, where posture attributes may be collected directly from an endpoint using the Network Endpoint Assessment (NEA) model [RFC5209], different transports may be defined to collect them using Posture Transport Protocol for Extensible Authentication Protocol Tunnel Methods (PT-EAP) [RFC7171] or Posture Transport Protocol over TLS (PT-TLS) [RFC6876], depending on the deployment scenario 🎭.

T-002 (Data Integrity): SACM transfer protocols MUST be able to ensure data integrity for data in transit 🔒.

T-003 (Data Confidentiality): SACM transfer protocols MUST be able to support data confidentiality. SACM transfer protocols MUST ensure data protection for data in transit (e.g., by encryption) to provide confidentiality, integrity, and robustness against protocol-based attacks 🛡️. Note that while the transfer MUST be able to support data confidentiality, implementations MAY provide a configuration option that enables and disables confidentiality in deployments 🎛️. Protection for data at rest is not in scope for transfer protocols 🙅. Data protection MAY be used for both privacy and non-privacy scenarios 🤐.

T-004 (Transfer Protection): SACM transfer protocols MUST be capable of supporting mutual authentication and replay protection 🤝.

T-005 (Transfer Reliability): SACM transfer protocols MUST provide reliable delivery of data. This includes the ability to perform fragmentation and reassembly and to detect replays 📬. The SACM transfer may take advantage of reliability features in the network transport. However, the network transport may be unreliable (e.g., UDP). In that case, the SACM transfer running over the unreliable network transport is responsible for ensuring reliability (i.e., through provisions such as confirmations and retransmits) 🔁.

T-006 (Transfer-Layer Requirements): Each SACM transfer protocol MUST clearly specify the transport-layer requirements it needs to operate correctly. Examples of items that may need to be specified include connectivity requirements, replay requirements, data link encryption requirements, and/or channel-binding requirements. These requirements are needed so deployments can be done correctly 📝.

T-007 (Transfer Protocol Adoption): SACM SHOULD, where reasonably possible, leverage and use existing IETF transfer protocols versus defining new ones 🏗️.

3. IANA Considerations 📋

This document does not require any IANA actions 🙅‍♀️.

4. Security Considerations 🔐

Okay bestie, this section is serious, so grab your snacks 😭

This document defines the requirements for SACM. Because of that, it's expected that several data models, protocols, and transfer protocols may be defined or reused from already-existing standards 🧩.

To address security and privacy considerations, the data model, protocols, and transports must consider authorization based on consumer function and privileges. The goal is to only allow authorized consumers and providers to access specific information being requested or published 🔐.

To enable federation across multiple entities (such as across organizational or geographic boundaries), authorization must also extend to infrastructure elements themselves, such as central controllers, brokers, and data repositories 🏢.

Authorization needs to extend to specific information or resources available in the environment too. In other words, authorization is based on the subject (the information requestor), the provider (the information responder), the object (the endpoint the information is being requested on), and the attribute (what piece of data is being requested). The method by which this authorization is applied is unspecified 🕵️‍♀️.

SACM's charter focuses on workflow orchestration and the sharing of posture information to improve the efficacy of security applications such as compliance, configuration, assurance, and other threat and vulnerability reporting and remediation systems 🦸‍♀️. The goal is to facilitate the flow of information securely, but it's important to note that participating endpoints may not be cooperative or trustworthy. Plot twist, and it's giving paranoia 💀🌈

4.1. Trust between Provider and Requestor ✨

okay so the info a provider hands to a requestor can come with different levels of trustworthiness 🫣 depending on the deployment scenario and whether something got compromised at the provider, the requesting consumer, or any device involved in moving the info between them. this section walks through the things that can lower that trust level 💅

some devices in the info transfer flow can act as proxies or brokers, so they might be able to watch the communications going between an information provider and requestor 👀. without proper protections, those proxies and brokers could inject stuff and pull off man-in-the-middle attacks. not cute 😭

generally it's common to distrust the network service provider, unless the whole hop-by-hop communications process flow is well understood 🧐. so the posture information provider should protect the posture information data it provides as well as the transfer it uses 🛡️. also, some providers just want to openly share their info, but others have a policy to grant access to certain posture info based on business or regulatory policy 💼. in those situations, a provider may require full authentication and authorization of the requestor (or set of requestors) and only share the authorized info with the authenticated and authorized requestors 🔐.

beyond distrusting the network service provider, a requestor also has to keep in mind that info it gets from the provider may have traveled through an undetermined network communications system 🌀. the posture info could have bounced through many devices before it reached the requestor. SACM specifications should provide the means for verifying data origin and data integrity and, at minimum, provide endpoint authentication and transfer integrity ✅.

a requestor may need data freshness indications, both knowledge of data origination and time of publication, so it can make more informed decisions about how relevant the data is based on its currency and/or age ⏰.

it's also important to note that endpoint assessment reports, especially the ones provided by the target endpoint, may be untrustworthy info 🙈. the considerations for this are described in Section 8 of [RFC5209].

the trustworthiness of the posture information given by the provider to one or many requestors depends on several things. some of these include the requestor requiring:

  • Full disclosure of the network topology path to the provider(s).
  • Direct (peer-to-peer) communication with the provider.
  • Authentication and authorization of the provider.
  • Either or both confidentiality and integrity at the transfer layer.
  • Either or both confidentiality and integrity at the data layer.

4.2. Privacy Considerations 🦋

SACM information may contain sensitive info about the target endpoint, and it can also reveal identity info of the producer or consumer of that info 🕵️‍♀️. similarly, as part of the SACM discovery mechanism, the capabilities and roles (e.g., SACM components enabled) advertised by the endpoint may be considered private info 🎀.

on top of identity and SACM capabilities disclosure, the use of timestamps (or other attributes that can be used as identifiers) could further be used to figure out a target endpoint or user's behavioral patterns 👀. those attributes may also be sensitive and may need extra protection or obfuscation to meet privacy concerns. basically, there may be applications, plus business and regulatory practices, that require parts of this info to stay hidden from any parties that don't need to know it 🤫.

data confidentiality can give some level of privacy, but it can fall short when unnecessary data is still transmitted 😬. in those cases, filtering requirements at the data model such as OP-005 must be applied so that such data isn't disclosed. [RFC6973] provides guidelines that SACM protocols, information models, and data models should follow 📚.

5. References 📚

5.1. Normative References

[RFC7632]  Waltermire, D. and D. Harrington, "Endpoint Security
           Posture Assessment: Enterprise Use Cases", RFC 7632,
           DOI 10.17487/RFC7632, September 2015,
           <https://www.rfc-editor.org/info/rfc7632>.

5.2. Informative References

[RFC5209]  Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J.
           Tardo, "Network Endpoint Assessment (NEA): Overview and
           Requirements", RFC 5209, DOI 10.17487/RFC5209, June 2008,
           <https://www.rfc-editor.org/info/rfc5209>.

[RFC6876]  Sangster, P., Cam-Winget, N., and J. Salowey, "A Posture
           Transport Protocol over TLS (PT-TLS)", RFC 6876,
           DOI 10.17487/RFC6876, February 2013,
           <https://www.rfc-editor.org/info/rfc6876>.

[RFC6973]  Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
           Morris, J., Hansen, M., and R. Smith, "Privacy
           Considerations for Internet Protocols", RFC 6973,
           DOI 10.17487/RFC6973, July 2013,
           <https://www.rfc-editor.org/info/rfc6973>.

[RFC7171]  Cam-Winget, N. and P. Sangster, "PT-EAP: Posture Transport
           (PT) Protocol for Extensible Authentication Protocol (EAP)
           Tunnel Methods", RFC 7171, DOI 10.17487/RFC7171, May 2014,
           <https://www.rfc-editor.org/info/rfc7171>.

[TERMS]    Birkholz, H., Lu, J., Strassner, J., and N. Cam-Winget,
           "Security Automation and Continuous Monitoring (SACM)
           Terminology", Work in Progress, draft-ietf-sacm-
           terminology-13, July 2017.

Acknowledgments 🫶

the authors would like to thank Barbara Fraser, Jim Bieda, and Adam Montville for reviewing and contributing to this document 💖. they also recognize the valuable comments and suggestions made by Jim Schaad and Chris Inacio 🌸.

Authors' Addresses 💌

Nancy Cam-Winget
Cisco Systems
3550 Cisco Way
San Jose, CA  95134
United States of America

Email: ncamwing@cisco.com


Lisa Lorenzin
Pulse Secure
2700 Zanker Rd., Suite 200
San Jose, CA  95134
United States of America

Email: llorenzin-ietf@1000plus.com
📦 where this page comes from