Below is an overview of the data elba stores during the scanning of sources.
🛡️ All SaaS security apps
The list of users at the source (the SaaS for which an integration is enabled) with :
- The id of the user at the source (e.g. Slack or Google user id)
- The display name of the user at the source (like the Github handle, or the Google workspace first name and last name)
The mapping between users at the source and elba users (elba users come from the IdP selected during the elba workspace creation). So that we know to which elba users we should assign security issues detected at the source.
📁 Data protection
elba needs to have a mapping of assets together with sensitive permissions associated to these assets. As such, elba stores only what is necessary to display what is needed for the end user to understand the issue :
- Title of asset (in case of an asset without a title, like Slack, we store the name of the channel and the date the message was sent at).
- List of permissions we consider as potentially sensitive (depends on the admin settings like the allow-list, the organisation domains, etc…). We don’t store the complete list of permissions (again, only what’s strictly necessary for elba to give the user just enough information to enable a quick action / decision).
- For some supported source, we store whether if the asset contains sensitive data like PII. However we never store the asset content itself (like a Slack message content for instance).
In short, elba stores the mapping and the reference to the different assets and permissions. Not the assets themselves.
📂 Focus on Slack Data protection
What do we process?
Scanning Channel messages: We conduct comprehensive scans of messages across organisation’s Slack channels utilizing the Google Cloud Platform's Data Loss Prevention (GCP DLP) API. This process is integral to detecting and addressing potential risks associated with the exposure of sensitive information.
What do we store?
In the interest of security and privacy, we minimize the amount of data stored. Our storage includes:
- Channel Name: To contextualize the data and ensure targeted security measures.
- Sensitive Data Detection: We store indications of sensitive data being detected within messages, along with the category of sensitive information (infoType). This approach allows us to highlight potential vulnerabilities without storing the sensitive data itself. We never store messages content.
- Message Date: The date of the message is recorded to assist in tracking and analyzing potential security risks over time.
- Channel Sharing Parameters: Information regarding the channel's sharing settings is stored to gauge the potential scope of data exposure and to implement suitable security protocols.
Our process
- Scanning: Automatic scans are performed on all messages sent within the organization's Slack channels using the GCP DLP API.
- Flagging and Categorization: Messages that contain potential sensitive information are flagged. The type of sensitive data is categorized (infoType) for precise reporting.
- Data Storage: We store essential information such as the channel name, whether a message contains sensitive data, the date of the message, and the sharing parameters of the channel.
- Reporting: Detailed reports are provided, outlining detected security issues along with recommendations for mitigative actions.