Browse Prior Art Database

Masking of Confidential Information in Orchestrator/Services Architecture Disclosure Number: IPCOM000249538D
Publication Date: 2017-Mar-02
Document File: 3 page(s) / 54K

Publishing Venue

The Prior Art Database


Privacy of sensitive data is a problem when the output of component 1 is an input for component 2 and the two are connected through an orchestration system. In particular the orchestration system may log inputs, outputs and execution traces for the components, and so expose to the orchestrating human operator data that the two components would like to exchange in private form (e.g. a freshly create password). If the only log "censorship" mechanism the orchestrator is able to provide is the redaction of specified string values, we can use this feature to arrange in component 1 and 2 an encoding which is able to also mask sensitive strings which are not known a priori, by using an alphabet of un-interesting symbols which we individually declare as sensitive string to the orchestrator.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 43% of the total text.


Masking of Confidential Information in Orchestrator /Services Architecture

Since logging is a powerful tool to debug applications and systems, log files are usually generated by any kind of software. The log provides information about the internal state and data: this is the essence of the usefulness of logging, but this same property is a problem when confidential data being processed is exposed in logs. In particular, log files are often accessed by maintenance technicians who are not supposed to get knowledge of confidential data.

Some kind of data is not essential for debugging, but can still appears in logs; e.g. credit card numbers, passwords, communication content.

Code developers are required to avoid putting this information in the log their software is generating, but in many cases this is difficult to achieve. For example a dump_object() or toString() method prints all the attributes of an object, including the sensitive ones.

The problem is particularly difficult to address when many components exchange or forward data, as each component is missing an idea about the potential confidentiality of the data originated by another component. For example, software components working as "orchestrators" generate requests to service1, obtain some data, pass the data as input on the next actor in the flow (service2) and so on. The orchestrator log may so easily contain confidential information generated by service1 and consumed by service2.

If the orchestrator itself contains confidential data (including knowledge that it must be considered confidential), to be passed to an external component, the orchestrator can "censor" its own log in two ways: 1) avoiding outputting the confidential data in logs 2) doing a "censorship" operation on its log output to remove the strings which are recognized as secret values

Technique number 2) is particularly advantageous as it can be applied to any text, even if produced by someone else; for example it can be applied to a log fragment generated by the external service upon invocation by the orchestrator.

The secret value can be recognized even if it is used as a part in something bigger. For example: http://myuser:mypasswd/ becomes http://myuser:***/ if the string "mypasswd" is known to be kept secret.

Let's consider an orchestrator log, which could contain: - CALLING remote::reset_password_for_user("donald") - SUCCESS {"result":"password for user donald successfully reset"}

but we do not want user names showing in logs and the orchestrator knows that the string "donald" must be redacted from logs; we would get: - CALLING remote::reset_password_for_user("<<<---REDACTED--->>>") - SUCCESS {"result":"password for user <<<---REDACTED--->>> successfully reset"}

It must be noted that technique number 1) would have only removed the first occurence of the secret string (by omitting logging it), while technique number 2)


(textual censorship) was also able to av...