Network Working Group G. Golovinsky Internet-Draft Alert Logic, Inc. Intended status: Experimental S. Johnston Expires: April 13, 2011 Google Z. Fox Alert Logic, Inc. October 10, 2010 Syslog Extension for Cloud Using Syslog Structured Data draft-cloud-log-00 Abstract This document provides an open and extensible log format to be used by any cloud entity or cloud application to log and trace activities that occur in the cloud. It is equally applicable for cloud infrastructure (IaaS), platform (PaaS), and application (SaaS) services. CloudLog is defferent in content, but not in nature from the traditional logging as it takes in account transient nature of identities and resources in the cloud. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 13, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents Golovinsky, et al. Expires April 13, 2011 [Page 1] Internet-Draft Cloud Log October 2010 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions Used in This Document . . . . . . . . . . . . . . . 3 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. The Traditional Logging and its Applications . . . . . . . 3 3.2. Challenges with the cloud deployment . . . . . . . . . . . 4 4. Cloud Log Structured Data Definitions . . . . . . . . . . . . . 4 4.1. SD-ELEMENT context . . . . . . . . . . . . . . . . . . . . 4 4.1.1. SD-PARAM aid - Mandatory . . . . . . . . . . . . . . . 5 4.1.2. SD-PARAM provider - Optional . . . . . . . . . . . . . 5 4.1.3. SD-PARAM rid - Optional . . . . . . . . . . . . . . . . 5 4.1.4. SD-PARAM eid - Optional . . . . . . . . . . . . . . . . 5 4.2. SD-ELEMENT transit . . . . . . . . . . . . . . . . . . . . 5 4.2.1. SD-PARAM client - Mandatory . . . . . . . . . . . . . . 6 4.2.2. SD-PARAM gw - Optional . . . . . . . . . . . . . . . . 6 5. Log Format Samples . . . . . . . . . . . . . . . . . . . . . . 6 5.1. Log Sample of Simple Non-Authenticated Request . . . . . . 6 5.2. Successful Authenticated User Request . . . . . . . . . . . 6 5.3. Log Sample of Successful Request on Behalf of Another Identity . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 7.1. SD-IDs . . . . . . . . . . . . . . . . . . . . . . . . . . 8 8. Normative References . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Golovinsky, et al. Expires April 13, 2011 [Page 2] Internet-Draft Cloud Log October 2010 1. Introduction This document describes a standard for syslog structured data elements in messages generated by services that may be running on different physical or virtual machines when those services are processing information generated by a single request. The purpose of which is to provide an audit trail that allows correlation of such messages. In addition, this document defines a number of parameters that MUST or SHOULD be included in these structured data elements so these messages can be used to identify users of such services, when the real and/or effective identities of users is known. 2. Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 3. Problem Statement 3.1. The Traditional Logging and its Applications Practically all hardware and software entities deployed on the network log their activities. Network elements such as routers, servers, firewalls and switches log information about their activities using mostly Syslog (except for Windows). Applications running on the network also log activities, but often using proprietary mechanisms. While logging mechanisms are inconsistent between different entities - Syslog, Windows events, proprietary files - they generally carry enough information to identify type of the activity, time of the occurrence, physical entity involved in the event, and often user(s) that participated in the event. Availability of this information is crucial for accomplishing multiple business objectives ranging from assuring security and performing forensics to adhering to compliance regulations (SOX, PCI, etc.). The existence of logs and information in them is necessary, but not sufficient for achieving security, compliance and other business objectives. The process of collecting, processing, searching and even simply interpreting information in logs is exceptionally labor and time consuming process and often cannot even be done on any meaningful scale without appropriate tools in place. Log Management tools used to solve the problem of scale and interpretation heavily depend on the fact that format of logs is largely well defined and understood. Golovinsky, et al. Expires April 13, 2011 [Page 3] Internet-Draft Cloud Log October 2010 3.2. Challenges with the cloud deployment In cloud deployments the situation with availability of logs in reliability of information in them is drastically different. By definition, cloud resources are shared. A piece of hardware is now running multiple Virtual Instances of "it". They can be brought up and down within very short period of time and at any given moment the hardware can be shared not just by different users but by different users from different companies. Even if Linux or Windows VMs continue to log their activity the information in these logs is very likely to be irrelevant since you cannot really tie logs to the physical entity. Moreover, even if one managed to map logs to a physical entity, there is absolutely no guarantee that the same VM image will be running on the same hardware in its next reincarnation. And there is really no clear way to determine how many users share the hardware and what are their identities and roles. Tracing environmental changes is practically impossible task unless there is traceability between physical and virtual entities. As a result, achieving such business objectives as adhering to compliance regulations or performing regular security auditing is very difficult if not an impossible task. 4. Cloud Log Structured Data Definitions 1. RUI - real user identity, the identity of the user that has authenticated to the entity. 2. EUI - effective or impersonated user identity, the identity of the user that the real user identity is acting for. For example, an administrator account could have the ability to impersonate another user account. 3. Provider - is the domain, service, application, or other entity providing the user identities. Structured data elements, defined in RFC 5424 [RFC5424], provides a mechanism for adding data to syslog messages. Since additional data is necessary to trace user identities and their activities in the cloud we use the mechanism of structured data elements to provide this additional information in the syslog messages. 4.1. SD-ELEMENT context The SD-ELEMENT identified by the SD-ID "context" defines the context of the external request that causes for the activity to take place. The syslog message that is generated as a result of this activity should be identified by this "context". Golovinsky, et al. Expires April 13, 2011 [Page 4] Internet-Draft Cloud Log October 2010 4.1.1. SD-PARAM aid - Mandatory The parameter "aid" represents the audit identifier, which uniquely identifies an external request for activity. The value is a UTF-8- STRING representation of the UUID generated by the entity when request is received. This parameter MUST be present within the SD-ELEMENT "context". 4.1.2. SD-PARAM provider - Optional The parameter "provider" represents the provider of the identity for the Real User Identity - 'rid' and Effective User Identity - 'eid', User identities are not always exist or available. In cases that they are, either "rid" or "eid" MUST be present in the syslog messages. The parameter "provider" is not required, but SHOULD be present within the SD-ELEMENT "context" when either the 'rid' or 'eid' identifiers are present. 4.1.3. SD-PARAM rid - Optional The parameter "rid" represents the real user identity. This parameter SHOULD be present within the SD-ELEMENT "context" when the real user identity is availbale. 4.1.4. SD-PARAM eid - Optional The parameter "eid" represents the effective user identity. This parameter SHOULD be present within the SD-ELEMENT "context" when user impersonation has happened and the effective user identity is available. The 'eid' parameter represents the effective user identity. This parameter SHOULD be present within the 'context' SD-ELEMENT when the effective user identity is known. 4.2. SD-ELEMENT transit The SD-ELEMENT identified by the SD-ID "transit" defines logical gateway entities which were traversed while request for activity was routed to the final destination entity that would satisfy the request. Golovinsky, et al. Expires April 13, 2011 [Page 5] Internet-Draft Cloud Log October 2010 4.2.1. SD-PARAM client - Mandatory The parameter "client" represents the IP address or Fully Qualified Domain Name (FQDN) of the client entity on behalf of which the request is being made. This is different from SD-ID 'ip' in RFC 5424 that defines IP of the entity producing the log message itself. IPv4 or IPv6 addresses MUST be represented as STRING-UTF-8 . The parameter "client" represents the IP address or FQDN of the client on behalf of which the request is being made. 4.2.2. SD-PARAM gw - Optional The parameter "gw" represents a gateway entity through which the request for activity passes before arriving to the final destination entity actually responsible processing of the request. The value of the parameter is comprised of the STRING-UTF-8 representation of UUID of the entity , identifying the gateway, a colon character (i.e. ':'), and finally the STRING-UTF-8 representation of IP address or FQDN of the gateway through which the request has been routed. This parameter MAY appear more than once within the SD-ELEMENT "transit" as request may pass through multiple gateway entities. Each occurrence represents a different gateway through which the request passed. 5. Log Format Samples 5.1. Log Sample of Simple Non-Authenticated Request Here is an example of a log produced as a result of simple non- authenticated request to a web service. Only the mandatory parameters "aid" and "client" are represented. Jul 7 09:01:40 [context aid="9BE817EB-8ACC-1004-D9DF- 00000A00065E"][transit client="56.2.222.83"] Initializing request to /example_api/index Jul 7 09:01:40 [context aid="9BE817EB-8ACC-1004-D9DF- 00000A00065E"][transit client="56.2.222.83"] "64.39.0.40" - "1023" ""GET /example_api/index HTTP/1.1"" 200 2543 -- performed in 600 ms 5.2. Successful Authenticated User Request Here is an example of a simple request including user authentication. Note that the 'provider' and 'rid' SD-PARAMs are added to the message after the user has authenticated to the service, and that those Golovinsky, et al. Expires April 13, 2011 [Page 6] Internet-Draft Cloud Log October 2010 parameters are included in each subsequent message. Aug 16 13:34:18 [context aid="149683FC-8DF5-1004-E1A8- 00000A000152"][transit client="172.16.1.82"] Initializing request to /api/example:instance/1 Aug 16 13:34:18 [context aid="149683FC-8DF5-1004-E1A8-00000A000152" provider="example.com" rid="1:123"][transit client="172.16.1.82"] User authentication successful for 1:123 Aug 16 13:34:18 [context aid="149683FC-8DF5-1004-E1A8-00000A000152" provider="example.com" rid="1:123"][transit client="172.16.1.82"] "172.16.1.82" - "-" ""GET /api/example:instance/1 HTTP/1.1"" 200 119 -- performed in 2 ms 5.3. Log Sample of Successful Request on Behalf of Another Identity Here is a request made by an authenticated user on behalf of another identity. Note that the parameter "eid" is added after the user authentication takes place and the effective user identity is validated. This parameter is included in each subsequent message. Aug 16 13:34:18 [context aid="149683FC-8DF5-1004-E1A8- 00000A000152"][transit client="172.16.1.82"] Initializing request to /api/example:instance/1 Aug 16 13:34:18 [context aid="149683FC-8DF5-1004-E1A8-00000A000152" provider="example.com" rid="1:123"][transit client="172.16.1.82"] User authentication successful for 1:123 Aug 16 13:34:18 [context aid="149683FC-8DF5-1004-E1A8-00000A000152" eid="2:456" provider="example.com" rid="1:123"][transit client="172.16.1.82"] User impersonation successful for 1:123 to 2:456 Aug 16 13:34:18 [context aid="149683FC-8DF5-1004-E1A8-00000A000152" eid="2:456" provider="example.com" rid="1:123"][transit client="172.16.1.82"] "172.16.1.82" - "-" ""GET /api/ example:instance/1 HTTP/1.1"" 200 119 -- performed in 2 ms 6. Security Considerations In addition to general syslog security considerations discussed in RFC 5424 [RFC5424], he information contained in these messages may provide information about how services interact, user identities, and other information about network or service inventory. Golovinsky, et al. Expires April 13, 2011 [Page 7] Internet-Draft Cloud Log October 2010 Users should not have access to these messages if they would not have access to this information through other authenticated means. 7. IANA Considerations 7.1. SD-IDs ANA is requested to register the syslog structured data element SD- IDs and PARAM-NAMEs shown below: +---------+------------+-----------+ | SD-ID | PARAM-NAME | | +---------+------------+-----------+ | context | | OPTIONAL | | | aid | MANDATORY | | | eid | OPTIONAL | | | provider | OPTIONAL | | | rid | OPTIONAL | | transit | | OPTIONAL | | | client | MANDATORY | | | gw | OPTIONAL | +---------+------------+-----------+ Table 1 8. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119. [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424. Authors' Addresses Gene Golovinsky Alert Logic, Inc. 1776 Yorktown Suite 700 Houston, TX 77056 US Phone: (713) 484-8383 Email: gene@alertlogic.com URI: www.alertlogic.com Golovinsky, et al. Expires April 13, 2011 [Page 8] Internet-Draft Cloud Log October 2010 Sam Johnston Google Brandschenkestrasse, 110 Zurich, 8002 Switzerland Phone: +41.446681679 Email: sj@google.com Zachary Fox Alert Logic, Inc. 1776 Yorktown Suite 700 Houston, TX 77056 US Phone: (713) 484-8383 Email: zfox@alertlogic.com URI: www.alertlogic.com Golovinsky, et al. Expires April 13, 2011 [Page 9]