diff --git a/.gitignore b/.gitignore new file mode 100644 index 0000000..b7134a8 --- /dev/null +++ b/.gitignore @@ -0,0 +1,4 @@ +# Ignore emacs files +*~ +*# + diff --git a/.travis.yml b/.travis.yml new file mode 100644 index 0000000..710aea4 --- /dev/null +++ b/.travis.yml @@ -0,0 +1,29 @@ +language: python +rvm: + - 2.2.0 +before_install: +- sudo apt-get update -qq +- sudo apt-get install -y python-lxml python-pip +install: +- deactivate +- rvm install 2.2.0 +- rvm use 2.2.0 +- sudo pip install xml2rfc +script: +- make ghpages +env: + global: + - secure: +before_deploy: make submit +deploy: + provider: releases + api-key: + secure: + file: + - $TRAVIS_TAG.txt + - $TRAVIS_TAG.html + - $TRAVIS_TAG.xml + skip_cleanup: true + on: + branch: master + tags: true diff --git a/Makefile b/Makefile new file mode 100644 index 0000000..ff34367 --- /dev/null +++ b/Makefile @@ -0,0 +1,187 @@ +# Original makefile from https://github.com/martinthomson/i-d-template + +# The following tools are used by this file. +# All are assumed to be on the path, but you can override these +# in the environment, or command line. + +# Mandatory: +# https://pypi.python.org/pypi/xml2rfc +xml2rfc ?= xml2rfc + +# If you are using markdown files: +# https://github.com/cabo/kramdown-rfc2629 +kramdown-rfc2629 ?= kramdown-rfc2629 + +# If you are using outline files: +# https://github.com/Juniper/libslax/tree/master/doc/oxtradoc +oxtradoc ?= oxtradoc.in + +# For sanity checkout your draft: +# https://tools.ietf.org/tools/idnits/ +idnits ?= idnits + +# For diff: +# https://tools.ietf.org/tools/rfcdiff/ +rfcdiff ?= rfcdiff --browse + +# For generating PDF: +# https://www.gnu.org/software/enscript/ +enscript ?= enscript +# http://www.ghostscript.com/ +ps2pdf ?= ps2pdf + + +## Work out what to build + +draft := $(basename $(lastword $(sort $(wildcard draft-*.xml)) $(sort $(wildcard draft-*.org)))) + +ifeq (,$(draft)) +$(warning No file named draft-*.md or draft-*.xml or draft-*.org) +$(error Read README.md for setup instructions) +endif + +draft_type := $(suffix $(firstword $(wildcard $(draft).md $(draft).org $(draft).xml))) + +current_ver := $(shell git tag | grep '$(draft)-[0-9][0-9]' | tail -1 | sed -e"s/.*-//") +ifeq (,$(current_ver)) +next_ver ?= 00 +else +next_ver ?= $(shell printf "%.2d" $$((1$(current_ver)-99))) +endif +next := $(draft)-$(next_ver) +diff_ver := $(draft)-$(current_ver) + + +## Targets + +.PHONY: latest txt html pdf submit diff clean update ghpages + +latest: txt html +txt: $(draft).txt +html: $(draft).html +pdf: $(draft).pdf + +submit: $(next).txt + +idnits: $(next).txt + $(idnits) $< + +## If you'd like the main github page to show the draft text. +readme: $(next).txt + @echo '```' > README.md + @cat $(next).txt >> README.md + @echo '```' >> README.md + +clean: + -rm -f $(draft).{txt,html,pdf} index.html + -rm -f $(draft)-[0-9][0-9].{xml,md,org,txt,html,pdf} + -rm -f *.diff.html +ifneq (.xml,$(draft_type)) + -rm -f $(draft).xml +endif + +## diff + +$(next).xml: $(draft).xml + sed -e"s/$(basename $<)-latest/$(basename $@)/" $< > $@ + +ifneq (,$(current_ver)) +.INTERMEDIATE: $(addprefix $(draft)-$(current_ver),.txt $(draft_type)) +diff: $(draft).txt $(draft)-$(current_ver).txt + -$(rfcdiff) $^ + +$(draft)-$(current_ver)$(draft_type): + git show $(draft)-$(current_ver):$(draft)$(draft_type) > $@ +endif + +## Recipes + +.INTERMEDIATE: $(draft).xml +%.xml: %.md + $(kramdown-rfc2629) $< > $@ + +%.xml: %.org + $(oxtradoc) -m outline-to-xml -n "$@" $< > $@ + +%.txt: %.xml + $(xml2rfc) $< -o $@ --text + +%.htmltmp: %.xml + $(xml2rfc) $< -o $@ --html +%.html: %.htmltmp + sed -f lib/addstyle.sed $< > $@ + +%.pdf: %.txt + $(enscript) --margins 76::76: -B -q -p - $^ | $(ps2pdf) - $@ + +## Update this Makefile + +# The prerequisites here are what is updated +.INTERMEDIATE: .i-d-template.diff +update: Makefile lib .gitignore SUBMITTING.md + git diff --quiet -- $^ || \ + (echo "You have uncommitted changes to:" $^ 1>&2; exit 1) + -if [ -f .i-d-template ]; then \ + git diff --exit-code $$(cat .i-d-template) -- $^ > .i-d-template.diff && \ + rm -f .i-d-template.diff; \ + fi + git remote | grep i-d-template > /dev/null || \ + git remote add i-d-template https://github.com/martinthomson/i-d-template.git + git fetch i-d-template + [ -f .i-d-template ] && [ $$(git rev-parse i-d-template/master) = $$(cat .i-d-template) ] || \ + git checkout i-d-template/master $^ + git diff --quiet -- $^ && rm -f .i-d-template.diff || \ + git commit -m "Update of $^ from i-d-template/$$(git rev-parse i-d-template/master)" $^ + if [ -f .i-d-template.diff ]; then \ + git apply .i-d-template.diff && \ + git commit -m "Restoring local changes to $$(git diff --name-only $^ | paste -s -d ' ' -)" $^; \ + fi + git rev-parse i-d-template/master > .i-d-template + +## Update the gh-pages branch with useful files + +GHPAGES_TMP := /tmp/ghpages$(shell echo $$$$) +.INTERMEDIATE: $(GHPAGES_TMP) +ifeq (,$(TRAVIS_COMMIT)) +GIT_ORIG := $(shell git branch | grep '*' | cut -c 3-) +else +GIT_ORIG := $(TRAVIS_COMMIT) +endif + +# Only run upload if we are local or on the master branch +IS_LOCAL := $(if $(TRAVIS),,true) +ifeq (master,$(TRAVIS_BRANCH)) +IS_MASTER := $(findstring false,$(TRAVIS_PULL_REQUEST)) +else +IS_MASTER := +endif + +index.html: $(draft).html + cp $< $@ + +ghpages: index.html $(draft).txt +ifneq (,$(or $(IS_LOCAL),$(IS_MASTER))) + mkdir $(GHPAGES_TMP) + cp -f $^ $(GHPAGES_TMP) + git clean -qfdX +ifeq (true,$(TRAVIS)) + git config user.email "ci-bot@example.com" + git config user.name "Travis CI Bot" + git checkout -q --orphan gh-pages + git rm -qr --cached . + git clean -qfd + git pull -qf origin gh-pages --depth=5 +else + git checkout gh-pages + git pull +endif + mv -f $(GHPAGES_TMP)/* $(CURDIR) + git add $^ + if test `git status -s | wc -l` -gt 0; then git commit -m "Script updating gh-pages."; fi +ifneq (,$(GH_TOKEN)) + @echo git push https://github.com/$(TRAVIS_REPO_SLUG).git gh-pages + @git push https://$(GH_TOKEN)@github.com/$(TRAVIS_REPO_SLUG).git gh-pages +endif + -git checkout -qf "$(GIT_ORIG)" + -rm -rf $(GHPAGES_TMP) +endif diff --git a/README.md b/README.md new file mode 100644 index 0000000..76dea90 --- /dev/null +++ b/README.md @@ -0,0 +1,94 @@ +# SACM Requirements + +This is the working area for the IETF SACM Requirements draft. + +* [Working Group Draft] (https://tools.ietf.org/html/draft-ietf-sacm-requirements) + +## Document Status + +This document is currently being actively developed by the working group. + +## Contributing + +Before submitting feedback, please familiarize yourself with our current issues +list and review the [SACM Working Group](https://datatracker.ietf.org/wg/sacm/charter/). If you're +new to this, you may also want to read the [Tao of the +IETF](https://www.ietf.org/tao.html). + +Be aware that all contributions to the specification fall under the "NOTE WELL" +terms outlined below. + +1. The best way to provide feedback (editorial or design) and ask questions is +sending an e-mail to sacm@ietf.org (https://www.ietf.org/mailman/listinfo/SACM). This will ensure that +the entire Working Group sees your input in a timely fashion. + +2. If you have **editorial** suggestions (i.e., those that do not change the +meaning of the specification), you can either: + + a) Fork this repository and submit a pull request; this is the lowest + friction way to get editorial changes in. + + b) Submit a new issue to Github, and mention that you believe it is editorial + in the issue body. It is not necessary to notify the mailing list for + editorial issues. (This is currently the recommended way as the authors are not + github literate.) + + c) Make comments on individual commits in Github. Note that this feedback is + processed only with best effort by the editors, so it should only be used for + quick editorial suggestions or questions. + +3. For non-editorial (i.e., **design**) issues, you can also create an issue on +Github. However, you **must notify the mailing list** when creating such issues, +providing a link to the issue in the message body. + + Note that **github issues are not for substantial discussions**; the only + appropriate place to discuss design issues is on the mailing list itself. + + +## Building the Draft + +In order to build a copy of the draft, you will need to install xml2rfc. This +requires Python 2.7 and can be installed using `pip`: + +```sh +$ pip install xml2rfc +``` + +Other tools can be used to produce PDF files, or to provide a comparison. These +tools - and where to find them - are described in the `Makefile`. + + +## NOTE WELL + +Any submission to the [IETF](https://www.ietf.org/) intended by the Contributor +for publication as all or part of an IETF Internet-Draft or RFC and any +statement made within the context of an IETF activity is considered an "IETF +Contribution". Such statements include oral statements in IETF sessions, as +well as written and electronic communications made at any time or place, which +are addressed to: + + * The IETF plenary session + * The IESG, or any member thereof on behalf of the IESG + * Any IETF mailing list, including the IETF list itself, any working group + or design team list, or any other list functioning under IETF auspices + * Any IETF working group or portion thereof + * Any Birds of a Feather (BOF) session + * The IAB or any member thereof on behalf of the IAB + * The RFC Editor or the Internet-Drafts function + * All IETF Contributions are subject to the rules of + [RFC 5378](https://tools.ietf.org/html/rfc5378) and + [RFC 3979](https://tools.ietf.org/html/rfc3979) + (updated by [RFC 4879](https://tools.ietf.org/html/rfc4879)). + +Statements made outside of an IETF session, mailing list or other function, +that are clearly not intended to be input to an IETF activity, group or +function, are not IETF Contributions in the context of this notice. + +Please consult [RFC 5378](https://tools.ietf.org/html/rfc5378) and [RFC +3979](https://tools.ietf.org/html/rfc3979) for details. + +A participant in any IETF activity is deemed to accept all IETF rules of +process, as documented in Best Current Practices RFCs and IESG Statements. + +A participant in any IETF activity acknowledges that written, audio and video +records of meetings may be made and may be available to the public. diff --git a/draft-ietf-sacm-requirements.xml b/draft-ietf-sacm-requirements.xml new file mode 100644 index 0000000..dd6d4e4 --- /dev/null +++ b/draft-ietf-sacm-requirements.xml @@ -0,0 +1,469 @@ + + + + + + + + + + +]> + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Secure Automation and Continuous Monitoring (SACM) Requirements + + + + + + + + Cisco Systems + +
+ + 3550 Cisco Way + San Jose + US + 95134 + CA + + + + + ncamwing@cisco.com + + +
+ + + + + Pulse Secure +
+ + 2700 Zanker Rd., Suite 200 + San Jose + US + 95134 + CA + + + llorenzin@pulsesecure.net +
+ + + + + + + + General + + SACM + + + + template + + + + + This document defines the scope and set of requirements for the Secure Automation and Continuous Monitoring (SACM) architecture, data model and transport protocols. + The requirements and scope are based on the agreed upon use cases. + + + + + +
+ Today's environment of rapidly-evolving security threats highlights the need to automate the sharing of such information while protecting user information as well as the systems that store, + process, and transmit this information. Security threats can be detected + in a number of ways. SACM's charter focuses on how to collect and share this information based on use cases + that involve posture assessment of endpoints. + + Scalable and sustainable collection, expression, and evaluation of endpoint information is foundational to SACM's objectives. To secure and defend a network, one must reliably determine what devices are + on the network, how those devices are configured from a hardware + perspective, what software products are installed on those devices, + and how those products are configured. We need to be able to + determine, share, and use this information in a secure, timely, + consistent, and automated manner to perform endpoint posture + assessments. + + + This document focuses on describing the requirements for facilitating the exchange of posture assessment information in the enterprise, in particular, for the use cases as exemplified in . Also, this document uses terminology defined in . + +
+ + +
+ + This document defines requirements based on the SACM use cases defined in . + This section describes the requirements used by SACM to assess and compare candidate data models, interfaces, + and protocols, to suit the SACM architecture. These requirements express characteristics or features that a candidate + protocol or data model must be capable of offering to ensure security and interoperability. + + Multiple data models, protocols, and transports may be employed in a SACM environment. A SACM transport protocol is one that runs on top of L3 protocols such as TCP/IP or L4 protocols such as HTTP, carries operations (requests / responses), and moves data. + + SACM defines an architecture and information model focused on addressing the needs for determining, sharing, and using posture information via Posture Information Providers and Posture Information Consumers mediated by a Controller. With the information model defining assets and attributes to facilitate the guidance, collection, and assessment of posture, these are some of the tasks that should be considered: + + + Asset Classification: Map the assets on the target endpoints to asset classes. This enables identification of the attributes needed to exchange information pertaining to the target endpoint. + + Attribute Definition: Define the attributes desired to be collected from each target endpoint. This is what we want to know about a target endpoint. For instance, organizations will want to know what software is installed and its many critical security attributes such as patch level. + + Policy Definition: This is where an organization can express its policy for acceptable or problematic values of an endpoint attribute. The expected values of an endpoint attribute are determined for later comparison against the actual endpoint attribute values during the evaluation process. Expected values may include both those values which are good as well as those values which represent problems, such as vulnerabilities. The organization can also specify the endpoint attributes that are to be present for a given target endpoint. + + Information Collection: Collect information (attribute values) from the target endpoint to populate the endpoint data. + + Endpoint Assessment: Evaluate the actual values of the endpoint attributes against those expressed in the policy. (An evaluation result may become additional endpoint data). + + Result Reporting: Report the results of the evaluation for use by other components. Examples of use of a report would be additional evaluation, network enforcement, vulnerability detection, and license management. + + + +
+ + Many deployment scenarios can be instantiated to address the above tasks and use cases defined in . To ensure interoperability, scalability, and flexibility in any of these deployments, the following requirements are defined for proposed SACM standards: + + + + Solution Extensibility: The information model, data models, protocols, and transports defined by SACM MUST be designed to allow support for future extensions, including both standard and proprietary transport protocols and data models. + + The information model and interfaces MUST support the ability to add new operations while maintaining backwards compatibility. SACM-defined transport protocols MUST have extensibility to allow them to transport operations that are defined in the future. + The query language MUST allow for general inquiries, as well as expression of specific attributes or relationships between attributes to follow; the retrieval of specific information based on an event, or on a continuous basis; and the ability to retrieve specific pieces of information, specific types or classes of information, or the entirety of available information. + The information model MUST accommodate the interoperable addition of new data types and/or schemas. + + + Interoperability: The data models, protocols, and transports must be specified with enough details to ensure interoperability. + + Scalability: SACM needs to support a broad set of deployment scenarios. The data models, protocols, and transports MUST be scalable unless they are specifically defined to apply to a special-purpose scenario, such as constrained devices. A SACM transport protocol standard SHOULD include a section on scalability considerations that addresses the number of endpoints and amount of information to which it can reasonably be expected to scale. Scalability must be addressed to support: + + Large datagrams: It is possible that the size of posture assessment information can vary from a single assessment that is small in size to a very large datagram or a very large set of assessments (up to multiple gigabytes in size). + Large number of providers and consumers: A deployment may consist of a very large number of endpoints requesting and/or producing posture assessment information. + Large number of target endpoints: A deployment may be managing information of a very large number of target endpoints. + + + Agility: The data model, protocols, and transports MUST be suitably specified to enable implementations to fit into different deployment models and scenarios, including considerations for implementations of data models and transports operating in constrained environments. + + Information Extensibility: Non-standard (implementation-specific) attributes MUST be supported. A method SHOULD be defined for preventing collisions from occurring in the naming of all attributes independent of their source. For interoperability and scope boundary, the information model MUST define the mandatory set of attributes. The set of attributes defined by the information model MUST be well defined. + + Data Integrity: To protect the information being shared, SACM components MUST protect the integrity and confidentiality of data in transit (while information is being transferred between providers and consumers, and through proxies and/or repositories) and data at rest (for information stored on repositories and on providers / consumers). Mechanisms for this protection are unspecified but should include industry best practices such as encrypted storage, encrypted transports, data checksums, etc. These mechanisms are required to be available (i.e. all data-handling components must support them), but are not required to be used in all cases. + + Data Partitioning: A method for partitioning data MUST be supported to accommodate considerations such as geographic, regulatory, operational requirements, overlay boundaries, and federation (where the 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. + + Versioning and Backward Compatibility: Announcement and negotiation of versions, inclusive of existing capabilities (such as transport protocols, data models, specific attributes within data models, standard attribute expression sets, etc.) MUST be supported. Negotiation for both versioning and capability is needed to accommodate future growth and ecosystems with mixed capabilities. + + Information Discovery: There MUST be mechanisms for components to discover what information is available across the ecosystem (i.e. a method for cataloging data available in the ecosystem and advertising it to consumers), where to go to get a specific piece of that information (i.e. which provider has the information), and what schemas are in use for organizing the information. For example, providing a method by which a node can locate the advertised information so that consumers are not required to have a priori knowledge to find available information. + + Target Endpoint Discovery: SACM MUST define the means by which target endpoints may be discovered. Use Case 2.1.2 describes the need to discover endpoints and their composition. + + Push and Pull Access: Three methods of data access MUST be supported: the standard Pull model as well as solicited and unsolicited Push models. All of the methods of data access MUST support the ability for the initiator to filter the set of posture assessment information to be delivered. Additionally, the provider of the information MUST be able to filter the set of posture assessment information based on the permissions of the recipient. This requirement is driven by use cases 2.1.3, 2.1.4 and 2.1.5. + + Device Interface: The interfaces by which SACM components communicate to share endpoint posture information MUST be well defined. That is, the interface defines the data model, SACM transport protocols, and network transport protocols to enable SACM components to communicate. [Revised per our 6/29 conversation - does this work? -LL] + + Endpoint Location and Network Topology: The SACM architecture and interfaces MUST allow for 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 or network topology or both. + + Target Endpoint Identity: The SACM architecture and interfaces MUST support the ability of components to provide 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. + + 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. + + +
+ +
+ + At the simplest abstraction, the SACM architecture represents the core components and interfaces needed to perform the production and consumption of posture assessment information. Requirements relating to SACM's architecture include: + + + + Scalability: The architectural components MUST account for a range of deployments, from very small sets of endpoints to very large deployments. + + Flexibility: The architectural components MUST account for different deployment scenarios where the architectural components may be implemented, deployed, or used within a single application, service, or network, or may comprise a federated system. + + Separation of Data and Management Functions: SACM MUST define both the configuration and management of the SACM data models and protocols used to transport and share posture assessment information. + + Topology Flexibility: Both centralized and decentralized (peer-to-peer) information exchange MUST be supported. Centralized data exchange enables use of a common data format to bridge together data exchange between diverse systems, and can leverage a virtual data store that centralizes and offloads all data access, storage, and maintenance to a dedicated resource. Decentralized data exchange enables simplicity of sharing data between relatively uniform systems, and between small numbers of systems, especially within a single enterprise domain. The fact that a centralized or decentralized deployment is used SHOULD be invisible to a consumer. + + Capability Negotiation: Announcement and negotiation of functional capabilities (such as authentication protocols, authorization schemes, data models, transport protocols, etc.) must be supported, enabling a SACM component to make inquiries about the capabilities of other components in the SACM ecosystem. + + Role-based Authorization: The SACM architecture MUST be capable of effecting role-based authorization. Distinction of endpoints capable of and authorized to provide or consume information is required to address appropriate access controls. + + Context-based Authorization: The SACM architecture MUST be capable of effecting context-based authorization. Different policies (e.g. 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 specify that consumers are required to share specific information either back to the system or to administrators. + + Time Synchronization: Actions or decisions based on time-sensitive data (such as user logon/logoff, endpoint connection/disconnection, endpoint behavior events, etc.) are all predicated 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. + + + +
+ +
+ + The SACM information model represents the abstracted representation for Posture Assessment information to be communicated. SACM data models must adhere to and comply with the SACM information model. The requirements for the SACM information model include: + + + + Extensible Attribute Vocabulary: the information model MUST define a minimum set of attributes for communicating Posture Information, to ensure interoperability between data models. (Individual data models may define attributes beyond the mandatory-to-implement minimum set.) The attributes should be defined with a clear mechanism for extensibility to enable data models to adhere to SACM's required attributes as well as allow for their own extensions. The attribute vocabulary should be defined with a clear mechanism for extensibility to enable future versions of the information model to be interoperably expanded with new attributes. + + Posture Data Publication: The information model MUST allow for the data to be provided by a SACM component either solicited or unsolicited. No aspect of the information model should be dependent upon or assume a push (unsolicited) or pull (solicited) model of publication. + + Data Model Negotiation: SACM's information model MUST allow support for different data models, data model versions, and different versions of the operations (and network layer transport). The SACM information model MUST include the ability to discover and negotiate the use of a particular data model or any data model. + + Data Model Identification: The information model MUST provide a means to uniquely identify each data model uniquely. 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. + + 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 should the data be assumed to still be valid). + + Singularity and Modularity: The SACM information model MUST be singular (i.e. there is only one information model, not multiple alternative information models from which to choose) and MAY be modular (a conjunction of several sub-components) for ease of maintenance and extension. For example, endpoint identification could be an independent sub-component of the information model, to simplify updating of endpoint identification attributes. + + +
+ +
+ The SACM information model represents an abstraction for "what" information can be communicated and "how" it is to be represented and shared. It is expected that as applications may produce posture assessment information, they may share it using a specific data model. Similarly, applications consuming or requesting posture assessment information, may require it be based on a specific data model. Thus, while there may exist different data models and schemas, they should adhere to the SACM information model and meet the requirements defined in this section. + + The specific requirements for candidate data models include: + + + Element Association: The data model MUST contain a data model element for each information model element (e.g. endpoint, IP address, asset). In other words, for every item in the information model, there must be an item in the data model. The data model can also include elements that do not exist in the information model. + + Data Model Structure: The data model can be structured either as one single module or separated into modules and sub-modules that allow for references between them. The data model structure MAY reflect structure in the information model, but does not need to. For example, the data model might use one module to define endpoints, and that module might reference other modules that describe the various assets associated with the endpoint. Constraints and interfaces might further be defined to resolve or tolerate ambiguity in the references (e.g. same IP address used in two separate networks). + + 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. + + Full Vs. Partial Updates: The data model SHOULD include the ability to allow providers of data to provide the data as a whole, or when updates occur. For example, a consumer can request a full update on initial engagement, then request to receive deltas (updates containing only the changes since the last update) on an ongoing basis as new data is generated. + + Loose Coupling: The data model SHOULD allow for a loose coupling between the provider and the consumer, such that the consumer can request information without being required to request it from a specific provider, and a provider can publish information without having a specific consumer targeted to receive it. + + Provider Identification: The interfaces and actions in the data model MUST include the ability to identify data from a specific provider. For example, a SACM consumer should be able to request all data to come from a specific provider (e.g. Provider A) as there can be a larger set of providers. + + Data Cardinality: The data model MUST describe their constraints (e.g. cardinality). As posture information and the tasks for collection, aggregation, or evaluation, could comprise one or more attributes, interfaces and actions MUST allow and account for such cardinality as well as whether the attributes are conditional, optional, or mandatory. + + Data Model Negotiation: The interfaces and actions in the data model MUST include capability negotiation to enable discovery of supported and available data types and schemas. + + Data Origin: The data model MUST include the ability for consumers to identify the data origin (provider that collected the data). + + Origination Time: The data model SHOULD allow the provider to include the information's origination time. + + 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.). + + Data Source: The data model MUST allow the provider to include attributes defining the data source (target endpoint from which the data was collected) - e.g. hostname, domain (DNS) name or application name. + + Data Updates: The data model SHOULD allow the provider to include attributes defining whether the information provided is a delta, partial, or full set of information. + + 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. + + Attribute Extensibility: Use Cases in the whole of Section 2 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 inclusive of their meaning or usage intent. The data model MUST include all attributes defined in the information model and MAY include additional attributes beyond those found in the information model. Additional attributes MUST be defined in accordance with the extensibility framework provided in the information model. + + 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 request by a consumer for information about an endpoint, or can publish data as it observes new information about an endpoint, without any specific consumer request triggering the publication; a compliance-server provider may publish endpoint posture information in response to a request from a consumer (solicited), or it may publish posture information driven by a change in the posture of the endpoint (unsolicited). + + Transport Agnostic: The data model MUST be transport agnostic, to allow for the data operations to leverage the most appropriate SACM transport protocol. + + + +
+ +
+ Posture information data adhering to a data model must also provide interfaces that include operations for access and production of the data. Operations requirements are distinct from transport requirements in that operations requirements are requirements on the application performing requests and responses, whereas transport requirements are requirements on the transport protocol carrying the requests / responses. + The specific requirements for such operations include: + + + + Time Synchronization: Request and response operations MUST be timestamped, and published information SHOULD capture time of publication. Actions or decisions based on time-sensitive data (such as user logon/logoff, endpoint connection/disconnection, endpoint behavior events, etc.) are all predicated on a synchronized understanding of time. A method for detecting and reporting time discrepancies SHOULD be provided. + + Collection Abstraction: Collection is the act of a SACM component gathering 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 directly be applied as arguments to a command. The purpose of this requirement is primarily to reduce the potential attack vectors, but has the additional benefit of abstracting the request for collection from the collection method, thereby allowing more flexibility in how collection is implemented. + + Collection Composition: A collection request MAY be composed of multiple collection requests (which yield collected values). The desire for multiple values MUST be expressed as part of the collection request, so that the aggregation can be resolved at the point of collection without having to interact with the requestor. This requirement SHOULD NOT be interpreted as preventing a collector from providing attributes which were not part of the original request. + + 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. Use Case 2.1.2 describes the need for the data model to support a query operation based on a set of attributes to facilitate collection of information such as posture assessment, inventory (of endpoints or endpoint components), and configuration checklist. + + Information-based Query with Filtering: The query operation MUST support filtering. Use Case 2.1.3 describes the need for the data model to support the means for the information to be collected through a query mechanism. Furthermore, the query operation requires filtering capabilities to allow for only a subset of information to be retrieved. The query operation MAY be a synchronous request or asynchronous request. + + Data Model Scalability: The operation resulting from a query operation MUST be able to handle the return and receipt of large amounts of data. Use Cases 2.1.4 and 2.1.5 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. + + Data Abstraction: The data model MUST allow a SACM component to communicate what data was used to construct the target endpoint's identity, so other SACM components can determine whether they are constructing an equivalent target endpoint (and their 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. + + +
+ + +
+ + The term transport protocol is frequently overloaded. The term SACM transport protocol is intended to be distinguished from underlying layer 3 and 4 protocols such as TCP/IP and TLS. However, it is possible that a layer 3 or 4 protocol may be used as a SACM transport protocol, either alone or as part of a SACM transport protocol (i.e. using HTTP over TLS with XML as the content). The SACM transport protocol is focused on moving data and performing necessary access control operations; it is agnostic to the data model operations. + + The requirements for SACM transport protocols include: + + + + Multiple Transport Protocol Support: SACM transport protocols MUST support different network transport protocols in a deployment to support different transport layer requirements, different device capabilities, and system configurations dealing with connectivity. + + Data Integrity: SACM transport protocols MUST be able to ensure data integrity for data in transit. + + Data Confidentiality: SACM transport protocols MUST be able to support data confidentiality. SACM transport 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 transport MUST be able to support data confidentiality, implementations MAY choose to make confidentiality optional. Protection for data at rest is not in scope for transport protocols. Data protection MAY be used for both privacy and non-privacy scenarios. + + Transport Protection: SACM transport protocols MUST be capable of supporting mutual authentication and replay protection. + + Transport Reliability: SACM transport protocols MUST provide reliable delivery of data. This includes the ability to perform fragmentation and reassembly, and to detect replays. + + Transport Layer Requirements: Each SACM transport 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 in order for deployments to be done correctly. For example, a proxy server between UDP and TCP can provide a connection that correctly fulfills the connectivity and replay requirements as well as data link requirements (through the use of TLS and DTLS) but would be unable to provide a channel binding requirement, as that implies there is no MITM to look at the data. + + + +
+ + +
+ +
+ The authors would like to thank Barbara Fraser, Jim Bieda, and Adam Montville for reviewing and contributing to this draft. In addition, we recognize valuable comments and suggestions made by Jim Schaad and Chris Inacio. + + +
+ + + +
+ This memo includes no request to IANA. + +
+ +
+ This document defines the requirements for SACM. As such, it is expected that several data models, protocols, and transports may be defined or reused from already existing standards. This section will highlight security considerations that may apply to SACM based on the architecture and standards applied in SACM. In particular, highlights to security considerations that may apply to the SACM reference architecture and standard data models and transports will be discussed. + + To address security and privacy considerations, the data model, protocols, and transports must consider authorization based on consumer function and privileges, 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 / data repositories. + + In addition, authorization needs to extend to specific information or resources available in the environment. 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 the sharing of posture information for improving efficacy of security applications such as compliance, configuration, assurance and other threat and vulnerability reporting and remediation systems. While the goal is to facilitate the flow of information securely, it is important to note that participating endpoints may not be cooperative or trustworthy. + +
+ The information given from the provider to a requestor may come with different levels of trustworthiness given the different potential deployment scenarios and compromise either at the provider, the requesting consumer, or devices that are involved in the transport between the provider and requestor. This section will describe the different considerations that may reduce the level of trustworthiness of the information provided. + + In the information transport flow, it is possible that some of the devices may serve as proxies or brokers and as such, may be able to observe the communications flowing between an information provider and requestor. Without appropriate protections, it is possible for these proxies and brokers to inject and affect man-in-the-middle attacks. + + It is common to, in general, distrust the network service provider, unless the full hop by hop communications process flow is well understood. As such, the posture information provider should protect the posture information data it provides as well as the transport it uses. Similarly, while there may be providers whose goal is to openly share its information, there may also be providers whose policy is to grant access to certain posture information based on its business or regulatory policy. In those situations, a provider may require full authentication and authorization of the requestor (or set of requestors) and share only the authorized information to the authenticated and authorized requestors. + + A requestor beyond distrusting the network service provider, must also account that the information received from the provider may have been communicated through an undetermined network communications system. + That is, the posture information may have traversed through many devices before reaching the requestor. SACM specifications should provide the means for verifying data origin and data integrity and at minimum, provide endpoint authentication and transport integrity. + + A requestor may require data freshness indications, both knowledge of data origination as well as time of publication so that it can make more informed decisions about the relevance of the data based on its currency and/or age. + + It is also important to note that endpoint assessment reports, especially as they may be provided by the target endpoint may pose untrustworthy information. The considerations for this is described in Section 8 of . + + The trustworthiness of the posture information given by the provider to one or many requestors is dependent on several considerations. 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 transport layer. + Either or both confidentiality and integrity at the data layer. + + +
+
+
+
+ Updated G-005 to clarify the MUST to allow non-standard extensions, SHOULD avoid collisions and ensure interoperability. + Cleaned up and clarified IM-003, DM-001. + Cleaned up some of the OP-XXX and ARCH-XXX per Jim Schaad's comments. + Updated some of the text around Editor notes and removed all 'Editor Note' comments +
+
+ + + + + + + + + + + + + + &RFC2119; + &RFC5209; + &I-D.ietf-sacm-use-cases; + &I-D.ietf-sacm-terminology; + + + + + + &RFC3444; + + + + + + + + + \ No newline at end of file diff --git a/lib/addstyle.sed b/lib/addstyle.sed new file mode 100644 index 0000000..4df0789 --- /dev/null +++ b/lib/addstyle.sed @@ -0,0 +1,6 @@ +\~~ { a\ + +} diff --git a/lib/style.css b/lib/style.css new file mode 100644 index 0000000..477ece8 --- /dev/null +++ b/lib/style.css @@ -0,0 +1,78 @@ +@viewport { + zoom: 1.0; + width: extend-to-zoom; +} + +@-ms-viewport { + width: extend-to-zoom; + zoom: 1.0; +} + +body { + font: 11pt cambria, helvetica, arial, sans-serif; + font-size-adjust: 0.5; + line-height: 130%; + margin: 1em auto; + max-width: 700px; +} + +.title, .filename, h1, h2, h3, h4 { + font-family: candara, helvetica, arial, sans-serif; + font-size-adjust: 0.5; +} +.title { font-size: 150%; } +h1 { font-size: 130%; } +h2 { font-size: 120%; } +h3, h4 { font-size: 110%; } +ul.toc >li { font-size: 95%; } +ul.toc >li >ul, .figure, caption { font-size: 90%; } + +table { + margin-left: 0em; +} +table.header { + width: 100%; +} + +table.header td { + background-color: inherit; + color: black; +} + +samp, tt, code, pre { + font: 11pt consolas, monospace; + font-size-adjust: none; +} + +pre.text, pre.text2 { + width: 90%; +} + +dt { + float: left; clear: left; + margin: 0.5em 0.5em 0 0; +} +dt:first-child { + margin-top: 0; +} +dd { + margin: 0.5em 0 0 2em; +} +dd p, dd ul { + margin-top: 0; margin-bottom: 0; +} +dd *+p { + margin-top: 0.5em; +} + +ol, ul { + padding: 0; + margin: 0.5em 0 0.5em 2em; +} +ul.toc, ul.toc ul { + margin: 0 0 0 1.5em; +} +ul.toc a:first-child { + display: inline-block; + min-width: 1.2em; +} \ No newline at end of file diff --git a/readme.txt b/readme.txt deleted file mode 100644 index c41fd3d..0000000 --- a/readme.txt +++ /dev/null @@ -1 +0,0 @@ -this is just an example