Dealing with a SharePoint Security Breach
This week a friend of mine told me about a SharePoint related “incident” at his company where it was discovered that someone had posted a spreadsheet that contained sensitive employee data. The file was not properly secured (discovered via a keyword search) and quickly was removed; no damage was done. Nonetheless, it got me thinking about the appropriate steps to take during such a scenario… and, if you know me, that means having a plan.
Mine has two categories (below):
Reactive
· (Easy) Delete the file… all the way through the Recycle Bin(s)
· (Easy) Determine if the security associated with the file/list/site had been recently altered to allow for file access. If yes, fix it.
· (Moderate) Ensure that the file no longer shows up in search results by rebuilding the index(es).
· (Moderate) Determine the timing of the upload and whether the file is contained in any saved backup files. Do not allow these backups to be used by developers or any staging refreshes.
· (Hard) If appropriate, leverage audit data to determine who may have seen/downloaded the document.
Proactive
· (Hard) Be humble. Let folks know what happened, how you dealt with it and what steps are being taken to minimize something like this happening again. This is not a SharePoint problem (liken it to sending an email attachment to the wrong people or putting a file in the wrong network folder).
· (Moderate) Consider revisiting end user training to discuss the accountability associated with content ownership.
· (Moderate) Investigate whether 3rd party compliance or reporting tools are necessary to monitor content and security changes.
· (Easy) Talk to the content owner, discuss what happened and leave him/her alone. Lesson learned.
· (Easy) Subscribe to various sensitive keyword searches (e.g. ‘confidential’, ‘salary’, ‘payroll’, ‘layoff’, etc.) as a means (but not the only means!) of proactive monitoring.
· (Easy/Hard) Don’t panic. Don’t shut off My Sites. Don’t kill the wiki or blogs launch. Stay the course.