Skip to main content

Security Automation and Continuous Monitoring (SACM) Requirements
RFC 8248

Document Type RFC - Informational (September 2017)
Authors Nancy Cam-Winget , Lisa Lorenzin
Last updated 2017-09-21
RFC stream Internet Engineering Task Force (IETF)
Formats
Additional resources Mailing list discussion
IESG Responsible AD Kathleen Moriarty
Send notices to (None)
RFC 8248
of data is being requested).  The method by which this authorization
   is applied is unspecified.

   SACM's charter focuses on the workflow orchestration and the sharing
   of posture information for improving the 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.

4.1.  Trust between Provider and Requestor

   The information given from the provider to a requestor may come with
   different levels of trustworthiness given the different potential
   deployment scenarios and compromise at the provider, the requesting
   consumer, or devices that are involved in the transfer 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 transfer 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.

   In general, it is common to 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 transfer 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.

   Beyond distrusting the network service provider, a requestor must
   also take into 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
   transfer integrity.

Cam-Winget & Lorenzin         Informational                    [Page 16]
RFC 8248                    SACM Requirements             September 2017

   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 are described
   in Section 8 of [RFC5209].

   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:

   o  Full disclosure of the network topology path to the provider(s).

   o  Direct (peer-to-peer) communication with the provider.

   o  Authentication and authorization of the provider.

   o  Either or both confidentiality and integrity at the transfer
      layer.

   o  Either or both confidentiality and integrity at the data layer.

4.2.  Privacy Considerations

   SACM information may contain sensitive information about the target
   endpoint as well as revealing identity information of the producer or
   consumer of such information.  Similarly, as part of the SACM
   discovery mechanism, the capabilities and roles (e.g., SACM
   components enabled) advertised by the endpoint may be construed as
   private information.

   In addition to identity and SACM capabilities information disclosure,
   the use of timestamps (or other attributes that can be used as
   identifiers) could be further used to determine a target endpoint or
   user's behavioral patterns.  Such attributes may also be deemed
   sensitive and may require further protection or obfuscation to meet
   privacy concerns.  That is, there may be applications as well as
   business and regulatory practices that require that aspects of such
   information be hidden from any parties that do not need to know it.

   Data confidentiality can provide some level of privacy but may fall
   short where unnecessary data is still transmitted.  In those cases,
   filtering requirements at the data model such as OP-005 must be
   applied to ensure that such data is not disclosed.  [RFC6973]

Cam-Winget & Lorenzin         Informational                    [Page 17]
RFC 8248                    SACM Requirements             September 2017

   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.  In
   addition, we recognize valuable comments and suggestions made by Jim
   Schaad and Chris Inacio.

Cam-Winget & Lorenzin         Informational                    [Page 18]
RFC 8248                    SACM Requirements             September 2017

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

Cam-Winget & Lorenzin         Informational                    [Page 19]