Purview Integration Security Questions

Does your security framework extend to cover your eDiscovery/Compliance integration partners? By necessity, key IT, Legal and Compliance user/service accounts require the ‘keys to the kingdom’ to perform their duties. In this age of cybercrime, hackers can use compromised access to raid the corporate digital vaults of valuable data or even inject malicious code. It does not take a security expert (and I am NOT one) to understand the need to include your eDiscovery platform integrations in your overall access security framework. The following questions may help you evaluate the potential risks posed when connecting your M365 or other enterprise systems with your discovery platform.

Access

• Who has access to the platform and which roles have access to integration functionality? This includes internal/external users, service accounts and other external data sources (i.e. Google, DropBox, etc).
• What is the process for granting access roles?
• Do they need active access or can their account be disabled until required?
• What is the minimum access required to accomplish goals?
• What access rights are required for specific functions and which pose potential security risks?
• Are credentials stored/SSO so that external penetrations can tunnel into enterprise content?
• Can just-in-time access be required for specific risk functions?

Sources

• What enterprise data sources are accessible?
• How are highly sensitive data collections, custodians or sources classified, stored and handled within partner product? Does the product reflect existing M365 sensitivity labels?
• What is the default production protocol for known highly sensitive ESI?

Monitoring

• How are partner platform activities monitored from the platform and from M365 logs?
• Are there alerts for atypical activity types or bursts?
• Is there a default inactivity threshold before accounts are disabled?

Penetration Risk

• What scheduled activities use a service account or SPN authentication?
• Does the partner product support command line or code injection for automation that could bypass role based security? I.e. could a simple reviewer’s credentials be used to inject malicious code?
• Does the platform support bidirectional integrations with other external data systems or sources?
• Is the partner platform login process vulnerable to interception or keystroke logging attacks? (Could a compromised user system or connection be used to get credentials?)

Defensibility

• Is there an acceptable use policy and agreement in place for partner platform users granted access?
• Do you have a documented security plan covering partner platform use?
• Do your external users (service providers, experts, firms) ever download and store content from the platform?
• Do you have appropriate agreements and visibility into how that downloaded data is secured?
• Do you store access reports or logs? For how long?