Does anyone have something in place in service desk, catalog or USS that prevents users from entering sensitive data in tickets?
Unfortunately, any suggestions for real time data entry examinations would involve using a third party tool which we cannot provide suggestions nor certify for use with Service Desk.
A solution contained wholly within Service Desk would require a massive development effort, incorporating logic to determine what constitutes restricted entry, a reader for end user input, and a scrubber to redact restricted content after entry, and would also require a large maintenance effort to keep the functionality up to date.
I don't believe we have such OOTB, but there are a few things like not showing\displaying the data for certain users based on the role\access types, applying data-partitions, form customizations and possibly spel-code.
What would constitute sensitive data? Can you give us an example of a typical scenario or business case in your environment?
Good Afternoon Stephanie. Preventing users from entering sensitive data will be very difficult.Hiding and/or Disabling fields on e.f. a CA Service Catalog form could be a way to avoid visibility of such data. Kind regards, Louis van Amelsfort.
Can you provide a use case example here? What sort of data could be potentially inserted, and in what parts of the ticket? How should the product behave under such conditions?
Speaking generically, ie: user enters in an SSN on the description field, this is a very difficult activity to prevent as a string of numbers such as an SSN could easily be misconstrued as a phone number or any other numerical string. Such an activity might not be possible without extensive customisation work and even then, would not be a trivial activity to maintain for any changes in business requirements that may occur.
One thought might be to have a script run regularly on the backend database that automatically scrubs such data out after it has been entered, or to include a custom application that overlays on top of Service Desk that could detect such content as it is entered, ie a keystroke logger, but both options would be non-trivial to deploy and maintain.
You are right on target with your example. I thought of a data scrubber but wanted to check community to see if anyone has done this.
Stephanie, a custom scrubber will not be easy...take, for example SSN...how do you know the end user enters his SSN
in the ticket description/comment? is 6131234567 a SSN or a phone number? I would suggest some warning messages. For example, for the "Description" title, you can easily change it to "Description(please don't enter sensitive data such as SSN here)" by modify the htmpl files. My 2cents. Thanks _Chi
Yes the end user is entering the information in the description of the ticket.
I will look at adding warning messages. Good ideal
Did the information provided by David and Chi address your question/requirement?
If so, please mark one of their answers as correct so that this thread can be closed.
Sort of but still looking for suggestions.
Retrieving data ...