Incorporate human privacy + security review step in between Knack & Github

[amenity]

Despite our (UI-clogging) admonitions not to, our end users regularly include sensitive info/data in their Knack service requests, e.g.

• Screenshots w/ VZ crash data
• Passwords
• IP addresses

Do we need a manual check before issues are sent to Github?

The first solution that comes to mind would be having the link in the confirmation emails go to Knack, and then the triage person can review+edit somewhere in here before they're published.

And/or screenshots could be initially stored in Knack or commented out in the issue by default.

[amenity]

cc/ @johnclary @chiaberry @dianamartin @mddilley

[dianamartin]

I feel like we do a manual check when it gets to GitHub, but I understand the need to check it maybe before it even passes through ODP and GitHub. What would that process be like?

[amenity]

Beyond my suggestion above, I'm totally open to ideas. Whatever is most logical from the Apps+Dev perspective that isn't too big an onus for Service Desk-ers.

[johnclary]

Thank you! I think this would put my mind at ease wrt accidentally leaking PII through our issue intake.

I want to add that we should consider email addresses as sensitive as well. i think we should stop including them in any issue description. commenting them out doesn't make a difference.

@dianamartin i think the process would look like this:

1. User submits DTS service request form as usual
2. The form submit triggers an email to the DTS inbox
3. The DTS service desk operator reviews the request in the DTS portal and redacts sensitive information as needed
4. The DTS service desk operator clicks a button that says "Create Github Issue" that sets the request status to some value our service bot is checking for.
5. The service bot asks Knack for issues that need to be created and creates the issue in github.

[johnclary]

Another approach we could take would be to heavily reduce the level of detail we include when the service bot creates a github issue. We would still use our issue tagging logic, but the issue itself would be blank with a generic title like "Service Request #123". The DTS traige person could assign the issue, but leave it up to the PM to manually update the issue description.

That doesn't sound very great to me but I guess it could work.

[dianamartin]

The Maximo team requires Employee IDs and Emails for account creation, perhaps we need to talk to everyone to see what requests get PII information provided by stakeholders sometimes.

[johnclary]

Hmm, so we need the ability to keep the original information in Knack while also creating a github issue that has been redacted. I guess we could add a "private" field in Knack and the service desk person could copy sensitive details into that field. And whoever works the issue would need to refer back to Knack...