[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02

Network Working Group                                             S. Rao
Internet-Draft                                                S. Nagaraj
Intended status: Experimental                                       Grab
Expires: January 14, 2021                                       S. Sahib
                                                                R. Guest
                                                              Salesforce
                                                           July 13, 2020


                 Personal Information Tagging for Logs
                          draft-rao-pitfol-02

Abstract

   Software systems typically generate log messages in the course of
   their operation.  These log messages (or 'logs') record events as
   they happen, thus providing a trail that can be used to understand
   the state of the system and help with troubleshooting issues.  Given
   that logs try to capture state that is useful for monitoring and
   debugging, they can contain information that can be used to identify
   users.  Personal data identification and anonymization in logs is
   crucial to ensure that no personal data is being inadvertently logged
   and retained which would make the logging system run afoul of laws
   around storing private information.  This document focuses on
   exploring mechanisms that can be used by a generating or intermediary
   logging service to specify personal or sensitive data in log
   message(s), thus allowing a downstream logging server to potentially
   enforce any redaction or transformation.

Requirements Language

   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].

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 https://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




Rao, et al.             Expires January 14, 2021                [Page 1]


Internet-Draft                   PITFoL                        July 2020


   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 January 14, 2021.

Copyright Notice

   Copyright (c) 2020 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
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Motivation and Use Cases  . . . . . . . . . . . . . . . . . .   4
   4.  Challenges with Existing Approaches . . . . . . . . . . . . .   4
   5.  Proposed Model  . . . . . . . . . . . . . . . . . . . . . . .   5
     5.1.  Defining the log privacy schema . . . . . . . . . . . . .   5
     5.2.  Typical Workflow  . . . . . . . . . . . . . . . . . . . .   7
     5.3.  Log Processing and Access Control . . . . . . . . . . . .   7
   6.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . .   8
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  10
   10. Normative References  . . . . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   Logs capture the state of a software system in operation, thus
   providing observability.  However, because of the amount of state
   they capture, they can often contain sensitive user information
   [link: twitter storing passwords].  Personal data identification and
   redaction is crucial to make sure that a logging application is not
   storing and potentially leaking users' private information.  There
   are known precedents that help discover and extract sensitive data,
   for example, we can define a regular expression or lookup rules that
   will match a person's name, credit card number, email address and so



Rao, et al.             Expires January 14, 2021                [Page 2]


Internet-Draft                   PITFoL                        July 2020


   on.  Besides, there are data dictionary based training models that
   can analyze logs and predict presence of sensitive data and
   subsequently redact it.  This document proposes an approach and
   framework for creating logs with personal information tagged, thus
   marking a step towards privacy aware logging.  Once personal
   information is identified in a log, it has to be appropriately tagged
   at source.  Personal data tagging is especially important in cases
   where log data is flowing in from disparate sources.  In cases where
   tagging at source is not possible (e.g. log data generated by a
   legacy application, IoT device, Web server or a Firewall), a
   centralized logging server can be tasked with making sure the log
   data is tagged before passing on downstream.  Once the logs are
   tagged, the logging application can use anonymization techniques to
   redact the fields appropriately.  While the proposal described here
   can be applied to any data deemed sensitive in a log, however this
   document specifically discusses and illustrates tagging of personal
   information in logs.

2.  Terminology

   *Personal data:* RFC 6973 [RFC6973] defines personal data as "any
   information relating to an individual who can be identified, directly
   or indirectly."  This typically includes information such as IP
   addresses, username, email address, financial data, passwords and so
   on.  However, the definition of personal data varies heavily by what
   other information is available, the jurisdiction of operation and
   other such factors.  Hence, this document does not focus on
   prescriptively listing what log fields contain personal data but
   rather on what a tagging mechanism would look like once a logging
   application has determined which fields it considers to hold personal
   data.

   *Structured logging:* Most applications generate logs in a
   unidimensional format that twine together logic status and input
   data.  This makes log output largely free flowing and unstructured
   without specific delimiters making it hard to segregate personal
   information from other text in the log.  Structured logging refers to
   a formal arrangement of logs with specific identifiers of personal
   information and semantic information to enable easy parsing and
   identification of specific information in the log.

   *Privacy Sensitivity Level:* Sensitivity level defines the degree of
   sensitivity of a data in log template or schema.  Level can be
   enumerated on a scale 1 to 5 and defined as follows: 1 - Low risk for
   leaking private information and 5 - Very high risk for leaking
   private information>





Rao, et al.             Expires January 14, 2021                [Page 3]


Internet-Draft                   PITFoL                        July 2020


3.  Motivation and Use Cases

   Most systems like network devices, web servers and application
   services record information about user activity, transactions,
   network flows, etc., as log data.  Logs are incredibly useful for
   various purposes such as security monitoring, application debugging,
   investigations and operational maintenance.  In addition, there are
   use cases of organizations exporting or sharing logs with third party
   log analyzers for purposes of security incident response, monitoring,
   business analytics, where logs can be a valuable source of
   information.  In such cases, there are concerns about potential
   exposure of personal data to unintended systems or recipients.

4.  Challenges with Existing Approaches

   While methods of detecting personal identifiable information are
   continuously evolving, most approaches are around use of regular
   expressions, data or dataset based training models, pattern
   recognition, checksum matching, building custom logic.

   *Inconsistent Representation:* When applications, services or
   devices, log personal information, there is no consistency in the
   representation of the information.  For example the name of a user is
   often logged as either "fullname" (e.g.  John Doe) or with
   "firstname" (John) and "lastname" (Doe).

   *Context:* In most cases, what data is considered personal and
   sensitive is subjective, provisional and contextual to the data
   source or the application processing the data, which makes it hard to
   use automated techniques to identify personal data.  Even for a
   specific domain, it's controversial whether it is possible to
   definitively say that a piece of data is NOT identifying.

   *Disparate Types of Personal Data:* There are many disparate types of
   personal data and often require a multitude approaches for detection.

   *Lack of standards:* There are no standards that govern formats of
   sensitive data making automation difficult for most common use cases.

   *Detection Accuracy:* Most of the current PII detections tools employ
   regular expression based techniques or other pattern recognition
   techniques to identify the PII data.  Due to the very nature of logs,
   most of the current implementations let administrators to add
   redaction policies based on 'likelihood' of detection probability
   categorized as low, medium or high.  Defining a low detection scheme
   causes high false positives and a high detection scheme would cause
   PII leakage, thereby making a trade off inevitable to organizations.




Rao, et al.             Expires January 14, 2021                [Page 4]


Internet-Draft                   PITFoL                        July 2020


5.  Proposed Model

   This section describes a reference model to enable tagging of
   personal information at source and extends it to include an approach
   of role or policy based redaction based on personal information
   annotated at source.  The figure below illustrates the proposed
   model.

     Log Template/Schema with personal data identifiers
                         |
                         V
                   Log library
                         |
                         V
                     Application
                         |
                         V
                 Generate annotated log
                         |
                         V
                     Log redaction +---  consumer / role based
                                   +--   sensitivity based

                              Figure 1: Flow

5.1.  Defining the log privacy schema

   We propose using structured logging where a log schema or a template
   defines standardized identifiers for every personal information and
   each log field is associated with a sensitivity level customized to a
   use case or log intent.

   Note that this is not to be confused with a log severity level (WARN,
   INFO...) - those are typically defined "dynamically" by the developer
   while defining the severity of a certain scenario.  A privacy
   sensitivity level is defined statically and is part of a log schema,
   associated with the log name and data type.














Rao, et al.             Expires January 14, 2021                [Page 5]


Internet-Draft                   PITFoL                        July 2020


   +------------------+-----------------+----------------+-------------+
   | Name             | Abstract Data   | Description    | Sensitivity |
   |                  | Type            |                | [1-High     |
   |                  |                 |                | 5-Normal]   |
   +------------------+-----------------+----------------+-------------+
   | nationalIdentity | String          | National IDs   | 1           |
   |                  |                 | issued by      |             |
   |                  |                 | sovereign      |             |
   |                  |                 | governments.   |             |
   |                  |                 | Eg., SSN       |             |
   | drivingLicense   | String          | Driving        | 1           |
   |                  |                 | License number |             |
   | taxIdentity      | String          | Tax            | 1           |
   |                  |                 | identification |             |
   |                  |                 | numbers        |             |
   | credtCardNumber  | String          | Credit cards   | 1           |
   | bankAccount      | String          | Bank account   | 1           |
   |                  |                 | number         |             |
   | dateOfBirth      | Date            | Date of Birth  | 2           |
   | personName       | String          | Person name    | 1           |
   | emailAddress     | String          | Email          | 2           |
   | phoneNumber      | Number          | Phone          | 1           |
   | zipCode          | Integer         | Zip codes      | 5           |
   | ipAddress        | ipv4Address     | IPv4 or IPv6   | 4           |
   |                  |                 | Address        |             |
   | dateTimeSeconds  | dateTimeSeconds | seconds        | 5           |
   | age              | Integer         | Age            | 2           |
   | ethnicGroup      | String          | Ethnic group   | 1           |
   | genderIdentity   | String          | Gender         | 1           |
   |                  |                 | identity       |             |
   | macAddress       | macAddress      | MAC Address    | 4           |
   +------------------+-----------------+----------------+-------------+

                 Personal Information Identifiers Registry

   If an organization already uses structured logging with a log schema,
   then a privacy sensitivity level can be an additional attribute for
   the schema.

   The privacy sensitivity level for log types is intended to be defined
   by a centralized effort around privacy preservation in logs.  In
   other words, this mapping might be done by an organization's privacy
   team (which can include lawyers, engineers and privacy
   professionals).  The intention is that all logs generated by an org
   should conform to this structured format, which would ease downstream
   processing of logs for access control and removal of sensitive
   information.




Rao, et al.             Expires January 14, 2021                [Page 6]


Internet-Draft                   PITFoL                        July 2020


   If the log is being generated by a web server, then two approaches
   can be taken:

   1.  Modify log-format for the service: identify the log data type of
   each piece of log data generated, and tag in generation (examples
   provided in later section)

   2.  Add automated tagging in a centralized log aggregator: collect
   all the logs generated by different services and apply the annotation
   using the log schema at the aggregator

5.2.  Typical Workflow

   1.  The log privacy schema can be parsed into a structured logging
       library, that is used by individual developer teams.  The
       intention is for developers to not log arbitrary data i.e. they
       are asked to identify what is the data type of the state they
       want to preserve.

   2.  Any addition to the log schema would have to go through review of
       the privacy team that came up with the log schema.

   3.  Once a log is generated, tagged and stored, various kinds of
       access control techniques can be applied to who can access the
       logs.

5.3.  Log Processing and Access Control

   1.  Consumer Role Based Access

       A.  Once the log is tagged, access to it can be based on a
           consumer's role and privilege level.

       B.  A consumeer role based policy can define what level of
           sensitivity they can access.

   2.  Case-based access

       A.  If there is a genuine case for which access to sensitive
           information is needed and granted by the legal department, a
           cryptographically-signed token (e.g.JWT) can be generated
           that will allow access to a developer/user to logs of an
           increased log level.  This access can be temporal in nature
           i.e. the token will only be valid for a certain amount of
           time.

       B.  A transaction ID can also be propagated automatically
           throughout the request processing, to correlate different



Rao, et al.             Expires January 14, 2021                [Page 7]


Internet-Draft                   PITFoL                        July 2020


           logs related to a single request.  Note that the notion of a
           "request" can vary based on what the application is doing.
           The idea is to have a single unifying ID to tie a particular
           action.  If this is done, then the temporary token can be
           restricted to a particular request ID.

   3.  Redaction Techniques

       A.  Given that the log is tagged, an organization might choose to
           redact the more sensitive logs i.e. ones above a certain
           sensitivity level, ones of a certain log type.

       B.  More sophisticated approaches can be developed i.e.
           completely redact log types username and email, but obfuscate
           IP address so that a rough location can be garnered from the
           log record.  In this way, techniques such as differential
           privacy can be used in tandem to have privacy guarantees for
           logs while still providing usefulness to developers.

6.  Examples

   An example based on RFC 3164 Log format

   Normal Log Ouput

   <120> Nov 16 16:00:00 10.0.1.11 ABCDEFG: [AF@0 event="AF-Authority
   failure" violation="A-Not authorized to object" actual_type="AF-A"
   jrn_seq="1001363" timestamp="20120418163258988000"
   job_name="QPADEV000B" user_name="XYZZY" job_number="256937"
   err_user="TESTFORAF" ip_addr="10.0.1.21" port="55875"
   action="Undefined(x00)" val_job="QPADEV000B" val_user="XYZZY"
   val_jobno="256937" object="TEST" object_library="CUS9242"
   object_type="*FILE" pgm_name="" pgm_libr="" workstation=""]

   Log Output with Personal Information Tagging

   <120> Apr 18 16:32:58 10.0.1.11 QAUDJRN: [AF@0 event="AF-Authority
   failure" violation="A-Not authorized to object" actual_type="AF-A"
   jrn_seq="1001363" timestamp="20120418163258988000"
   job_name="QPADEV000B" {personName="XYZZY" pii_sensitivity_level=1}
   job_number="256937" {emailAddress="xyz@foo.com"
   pii_sensitivity_level=2] [ip_addr="10.0.1.21"
   pii_sensitivity_level=4] port="55875" action="Undefined(x00)"
   val_job="QPADEV000B" val_jobno="256937" object="TEST"
   object_library="CUS9242" object_type="*FILE" pgm_name="" pgm_libr=""
   workstation=""]





Rao, et al.             Expires January 14, 2021                [Page 8]


Internet-Draft                   PITFoL                        July 2020


7.  IANA Considerations

   IANA can consider defining a new central respository for Personal
   Information name and identifier registries to used in logging
   personal information.  The personal identifier registry would
   enumerate namee and identifiers as described in Section 5.1.

8.  Security Considerations

   It is anticipated that developers will want additional log data types
   for capturing application logic, and might abuse an existing log type
   instead of going through the process of adding a new one.  In such a
   case, the log would be incorrectly tagged.  This can be mitigated by
   having stronger typing for the log data types i.e. restricting
   address to a certain string length instead of storing arbitrary
   length.

   Encouraging developers to think carefully about what kind of data
   they're logging is a good practice and will lead to fewer incidents
   of private data being inadvertently logged.  An organization might
   choose to have an unstructured log type for letting developers log
   data that truly do not fit anywhere else.  This is still better than
   not having structured privacy-aware logging, because the potential
   privacy leakage is isolated to one particular field and its use can
   be monitored.

   Having a mapping from log data type to privacy sensitivity will need
   continuous effort by a privacy team, which might be expensive for an
   organization.

   Log data is often collated, propagated, transformed, loaded into
   different formats or data models for purposes of analytics,
   troubleshooting and visualization.  In such cases, it is necessary
   and critical to ensure that personal information tagging and
   annotations is preserved and forwarded across format transformations.

   If the privacy marking or classification changes for a log, for
   historical logs, the change of privacy classification is applied on
   subsequent access of the log.

   *TODO*: In case of logs that are not tagged or marked with personal
   information, an out-of-band mechanism to communicate log template or
   schema with personal data identifiers can be considered.  Such a
   mechansim can also be used to notify changes to privacy tagging or
   classification.






Rao, et al.             Expires January 14, 2021                [Page 9]


Internet-Draft                   PITFoL                        July 2020


9.  Acknowledgements

   The authors would like to thank everyone who provided helpful
   comments at the mic at IETF 106 during the PEARG session.  Thanks
   also to Joe Salowey for thoughts on aspects of log transformations,
   change of privacy classifications, models for privacy marking.

10.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC3164]  Lonvick, C., "The BSD Syslog Protocol", RFC 3164,
              DOI 10.17487/RFC3164, August 2001,
              <https://www.rfc-editor.org/info/rfc3164>.

   [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>.

Authors' Addresses

   Sandeep Rao
   Grab
   Bangalore
   India

   Email: sandeeprao.ietf@gmail.com


   Santhosh C N
   Grab

   Email: santoshcn1@gmail.com


   Shivan Sahib
   Salesforce

   Email: shivankaulsahib@gmail.com







Rao, et al.             Expires January 14, 2021               [Page 10]


Internet-Draft                   PITFoL                        July 2020


   Ryan Guest
   Salesforce

   Email: rguest@salesforce.com















































Rao, et al.             Expires January 14, 2021               [Page 11]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/