Idea ID: 2802336

Add a configurable driver option to add the [is-sensitive="true"] to attributes automatically

Status : New Idea
over 1 year ago

Add a configurable method to flag attributes as 'is-sensitive' at the driver/shim level before they enter the input or output flow. Currently this can be managed in policy by adding the setting to a given attribute at any point in the channel processing. The initial input of these attributes will still be visible in a level 3 trace before a policy can be applied. It also does not cover attributes that may be returned in response to out of band queries. This can result in sensitive information being made visible in the driver traces at any point. With the growing number of items that are considered sensitive for personal information (Social Insurance Number, Birth Date, etc.) there can be a need to add additional protection to data included in traces, besides the defaults of passwords and encrypted attributes. Having this type of configurable ability would also allow the option to flag octet type attributes, with long values variables, as sensitive to hide them from traces. This can clean up traces that currently have long strings of base-64 encoded data which usually is just a waste of file space.

Wondering if this could be implemented as an extension to the Driver Filter, by adding an option to identify attributes that are to be treated as sensitive, or maybe by adding a new resource object that lists the attributes to be flagged as sensitive. The driver would consume the configuration on startup and pass the information, after translation through the schema map, to a remote loader/driver shim to the connected system so that attributes from the connected application are also returned with the sensitive flag set as well. Maybe just an extension to the Schema Map to flag the selected mapped attributes as sensitive, could cover both vault and application.

Tags:

  • I would (also) like to have it as an option in the filter - just add is-sensitive='true' to the attribute definition (and make sure that Designer does not strip it out when it validates the XML).

    The publisher side this would probably be a bit more tedious as it needs to be the shim which does it. So that is up to the developer (Micro Focus).

    It is a concern that some attribute are visible at some point in the trace.

  • One of the problems we have is with Workday.  IT sends the SSN (NationalID) and it shows up before any policy can be applied to it to mask it as is-sensitive.   Drives my splunk guys crazy trying to mask it out of the splunk logs.   An ECV, or driver config option that would configure it at the SHIM level would be fantasic.  

  • Linking to similar and older Idea that is under consideration.

    https://community.microfocus.com/t5/Identity-Manager-Idea-Exchange/Suppress-attributes-in-driver-traces/idc-p/2833395

  • In driver shims that I have written I have provided that capability. I wrote my own SOAP driver and provided an driver configuration option which was a list of XML elements that should be considered sensitive.

    But one of the reasons I wrote my own shim was to add that capability (it has other neat tricks so it was not just for that). As far as overhead is concerned it should reduce overhead not add any. The tracing within the engine is an expensive process, without having to seriialize the XML it can be process much more quickly (hence turning trace to 0 to process quicker when the driver gets backed up).

    All you do within the shim to make an attribute hidden is to add the XML attribute is-srnsitive="true" to any XML element and the tracing class handles the rest. I used it to hide the B64 decode of a large jpg not because it was sensitive but so it wouldn't slow down the trace.
  • As noted this is a two part issue. 

    1) engine side

    2) Shim side

    As Stefaan shows, it can be done in the shim.  You can probably do it in a JDBC/SOAP/REST shim with a documentModifier Java extension.  BUt each shim would need to be modified to support it. 

    Thus it seems that it would be nice if the driver skeleton added support for the <init-params> that sends the filter to send the flag you are asking for in the filter, and honour that as well.