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]