The Trust Factor Around Lumos Integration
Our comprehensive security program is designed to identify & mitigate risks associated with our level of data access.
Data Access
The Lumos platform leverages integrations with over 60 different third party-services to provide our customers with the full functionality of its product suite. Given the breadth of integration in our platform, it can be tricky to navigate the scope of data Lumos has access to. This article will help you understand the different categories of data our product uses. It will also explain some of the risks & mitigations associated with Lumos’ data access & why enterprises trust us with their data.
We only pull, use, and store information from third-parties that Lumos needs to provide our services. One way we like to think about it is that everything we do with customer data passes the shadiness test. We don’t do anything shady!
How does Lumos use integrations? Lumos starts off as a blank slate that customers expand as they integrate more third-party apps. The more integrations added, the more functionality a customer unlocks. How much they want to integrate is always within their control. Integrations vary in their scope and purpose.
What types of integrations do you use? At a high-level, Lumos uses integrations with these four categories: Basic, Messaging, Ticketing, and Offboarding. One integration might fit one or more of these categories. The bulk of the integrations that customers connect to Lumos are Basic integrations. Customers also need an integration for Messaging. Advanced functionality is available for Messaging, Ticketing, and Offboarding integrations and typically requires more access (e.g. granting more scopes to an existing integration). The breakdown below gives more detail on each of these categories.
One way we like to think about it is that everything we do with customer data passes the shadiness test. We don’t do anything shady!
What data do we need? Data about accounts in applications is Lumos’s bread and butter. This information includes the set of applications in use at the customer’s company, the accounts associated with them, and information about that account such as status, access level information, licenses, activity, and basic metadata that is not typically considered highly sensitive (e.g. email, first name, title, manager). For advanced functionality access needs, see the Detailed Integration Access section below.
What data don’t we need? We do not need access to information about our customers’ clients. We also do not need access to what is commonly referred to as intellectual property (internal documents, source code, business plans, etc.). That means we can’t and do not need to read resources like Dropbox files, Slack messages, or Salesforce opportunities. We don’t need medical information, employee compensation, passports, social security information, termination, payment information, or similar sensitive data either.
Our comprehensive security program is designed to identify & mitigate risks associated with our level of data access.
Detailed Integration Access
Basic
The purpose of this access is to simply view accounts, account statuses (e.g. inactivity), and access level information in applications. Updates to access levels or creating / removing accounts also happens here.
Data Access:
Read: Email, first & last, status, login & activity information, access level information (e.g. roles, permissions, groups, resource access).
Write: Create users, update user access levels, remove users.
Sample Third-Party Services:
Okta, Slack, Onelogin, GitHub, Dropbox, Datadog, Mixpanel, Notion, etc. Includes IdPs and most of Lumos’s integrations.
Notes:
While we don’t recommend it, it’s possible to setup Lumos with read-only access.
We read title & manager information from integrations that provide it as well to provide a better product experience.
Messaging
The purpose of this access is to communicate and interact with the customer’s team as part of Lumos workflows (e.g. access requests, access reviews). To use our optional shadow IT discovery, we need to read email subject lines (not the body/content of the email).
Data Access:
Read: Optionally, the subject lines of emails in applications.
Write: Send emails, post messages in dedicated Lumos Slack channel.
Sample Third-Party Services:
Google Workspace (email), Microsoft (email), Slack
Notes:
Allowing Lumos to read email subject lines is an optional add-on.
Having a way for Lumos to communicate with the customer’s team is necessary to provide basic functionality.
Ticketing
The purpose of this access is to log information about certain Lumos activities in the customer’s ticketing provider (JIRA, SNOW, Zendesk). This access is also to help redirect software access requests from the customer’s ticketing integration into Lumos.
Data Access:
Read: Read ticket contents.
Write: To create, update, close tickets.
Sample Third-Party Services:
JIRA, ServiceNOW, Zendesk
Notes:
This is an optional capability recommended if customers need to log Lumos access requests in their ticketing solution, or if they are encouraging their team to adopt Lumos.
Offboarding
The purpose of this access is to take care of repetitive work associated with a departing employee’s software footprint.
Data Access:
Read: Same as basic integration.
Write: Capabilities to transfer data from one account to another.
Sample Third-Party Services:
Google Workspace (drive data transfer, reroute email), Salesforce (account transfers).
Notes:
This is an optional capability and recommended if the customer does a lot of manual work to offboard end users.
Authorization Methods
It’s up to each customer to authorize Lumos to interact with third-parties they choose. They can do this from the Lumos integrations page.
The two most common ways to authorize integrations are OAuth and API Tokens. Some integrations require authorization via Service Account — for example, domain-wide delegation for Google Workspace.
Enforcing Least Privilege
Since customers authorize Lumos to interact with third-parties they choose, they are also in control of the level of access they provide to Lumos.
• OAuth authorization is based on granting access to application-defined OAuth scopes. Lumos requests a default set of scopes for integrations, but customers can tune or revoke access to scopes according to their business needs.
• API Token authorization is based on the access rights associated with the API Token customers share with Lumos. For some applications, an API token’s access rights are inherited from the access rights of the user that created it. For other applications, they can tune the API token’s access rights independently.
• Service Account authorization consists of allowing a service account access to a set of scopes customers can control and tune.
Security
We understand the risk associated with the data we have access to and we take security very seriously. Our comprehensive security program is designed to identify & mitigate risks associated with our level of data access. For more information, see https://trust.lumos.com/ or reach out to your Lumos contact to request our technical security whitepaper. Don’t have a Lumos contact yet? Grab a spot on our calendar.