Skip to content

Commit

Permalink
Update cloud.md with guidelines that came out of the AI/ML Working Group
Browse files Browse the repository at this point in the history
This combined document incorporates the most up-to-date information from the [SaaS Evaluation document](https://docs.google.com/document/d/1NMaaozHeVmGsQcD0plO0IjeiTn-ibl6KABWCJVzDUsI/edit) while retaining relevant details from the current cloud.md document.
  • Loading branch information
sirkitree authored Aug 23, 2024
1 parent 9a1c1fe commit 130f44a
Showing 1 changed file with 62 additions and 44 deletions.
106 changes: 62 additions & 44 deletions communications/cloud.md
Original file line number Diff line number Diff line change
@@ -1,73 +1,91 @@
# Security in the Cloud
Lullabot permits the use of public cloud applications, tools and technologies, known as “cloud services”. However, the use of insecure cloud services can introduce unintended risk to you, your coworkers, and the company. We want to balance the security of our content, networks and applications with the ability to work in a flexible, productive environment.
# Security in the Cloud and SaaS Evaluation Guidelines

## What is a cloud service?
## Introduction

We consider a cloud service to be any software as a service application that is hosted by the software vendor. The Google Suite, Dropbox, and Noko are all cloud services. As a distributed company working with many clients, cloud services make our business possible in the first place.
Some applications may not seem like cloud services, but use the cloud for sync and storage. For example, Apple Music is a cloud service, even though it’s only accessed through iTunes and not a web browser.
As a distributed company working with many clients, cloud services and Software as a Service (SaaS) applications make our business possible. However, the use of insecure services can introduce unintended risks to you, your coworkers, and the company. This document outlines our policies and guidelines for evaluating and using SaaS and cloud services, balancing security with productivity.

## What needs to be done to introduce a new cloud service at Lullabot?
## What is a Cloud Service or SaaS?

Read the following, and then fill out [the service request form](https://forms.gle/aPZnrCoEhfhB67ck8).
We consider a cloud service or SaaS to be any software application hosted by the vendor and accessed over the internet. Examples include Google Suite, Dropbox, Noko, and even applications like Apple Music that use cloud sync and storage.

If a new cloud service is purchased individually on PEX, and it does not require integration or access to Lullabot data stored in other services, no specific approval is required. Examples of services like this include:
## Key Terms to Understand

- Evernote
- Arq Cloud Backup
- Microsoft Office 365
1. **Data Handling Policies**: Documented practices for collecting, storing, processing, and disposing of user data.
2. **Data Usage**: How the service utilizes collected data, including AI model training and third-party sharing.
3. **Acceptable Permissions**: Access rights a service reasonably needs to function effectively without compromising privacy or security.
4. **Sensitive Content**: Information that could potentially harm individuals or organizations if mishandled, including PII, financial data, unpublished content, and intellectual property.

Be wary of applications that use your Lullabot account to access key personal data like email, especially if they are free or are low cost.
## Evaluation Process for New Cloud/SaaS Services

Apps that integrate with services used by the Lullabot team or interact with Lullabot customers should be discussed with the relevant directors and also need review by the security committee. Since these services are used by multiple team members, and not individuals, they typically are charged to a Lullabot expense card or are invoiced. Examples of services like this include:
### Key Questions to Ask

- Geekbot, as it requires integration with our Slack instance.
- Drift, as it interacts with Lullabot customers and gathers their personal information.
- CircleCI, as it has access to customer owned source code.
1. **Company Location**:
- Is the company based in the US or an allied country?
- Be cautious of companies based in countries like China, Syria, Saudi Arabia, or Russia.

Where possible, clients should be the account owner of cloud services in client engagements. While the security committee can provide feedback, the client should be primarily responsible for how they want to handle security reviews, if any.
2. **Data Handling**:
- Can data be deleted if needed?
- Is data being shared with others?
- Are they using your data to train AI models?
- How do they handle accidental input of sensitive information?

## When do I use my Lullabot email and when do I use my personal email when signing up for Cloud services?
- If you are signing up for a service paid for by Lullabot, or a Lullabot client, use the Lullabot email address.
- If you are signing up for a service at the request of Lullabot, or a Lullabot client, use the Lullabot email address.
- If you are signing up for a service that will contain or provide access to Lullabot data, or Lullabot client data, use the Lullabot email address.
- If you are signing up for a service that you would continue to use even if you were no longer employed at Lullabot, use your personal email address.
- If you are signing up for a service that will not contain or provide access to Lullabot data, nor be used by others at Lullabot or Lullabot clients, use your personal email address.
3. **Permissions**:
- What integrations does the service require (e.g., calendars, email, file storage)?
- If it requires more than basic login information, involve the security team for review.

If a service supports multiple email addresses per account, it’s OK (and even recommended) to use one “account” with multiple “identities”. GitHub is the most notable example of this, though services that are built on top of GitHub likely use the same model. For example, instead of creating a new account, add your Lullabot email address to your existing account. Use the built-in tools to associate work and personal email addresses with the right organizations and projects.
4. **Security History**:
- Has the company had any notable security breaches?
- Check sources like Hacker News and Google News for reported incidents.

Some clients will create email addresses for you. Where possible, use your Lullabot email address instead of a client email address. This is especially important for VPN recovery, where client email may not be accessible outside of the VPN. Consider redirecting your client email to your Lullabot email if it’s supported by the client.
### Decision Tree for Evaluation

There are times when the answers might conflict, and you could make a case for using either email address. When in doubt communicate with your manager or the security team for instructions.
To help guide your evaluation process, we've created a decision tree. You can find the visual representation [here](https://www.mermaidchart.com/raw/9bce760b-17c1-4154-b09f-09b9b955f7ff?theme=light\&version=v0.1\&format=png).

## How should I invite users to a Cloud service?
1. Determine if the company's location is known and acceptable.
2. Assess the company's data handling policies and usage practices.
3. Review the required permissions.
4. Investigate any major security breaches.
5. Determine if the service is suitable for use with your work account.
6. Check if the service will handle sensitive content.

Many services can identify accounts with either a user name or an email address. If a service offers both (like GitHub), add accounts with person's email address rather than their username. That way, a typo in the invite is less likely to add someone completely unknown, and is more likely to be scoped to just accounts at the company you are working with.
If you've made it through all these steps with positive outcomes, you can approve the service for use. When in doubt, consult with the Security Team.

## What if there are both personal and business versions of a cloud service?
## Guidelines for Using Cloud/SaaS Services

Many cloud services used by Lullabot include provisions to store both business and personal information. For instance, there is a Lullabot Dropbox account, but you can also establish a personal Dropbox account and link them together. Our 1Password Business membership includes a free 1Password Families membership for each employee.
### Email Address Usage

Any time there is an option to separate personal and business data in the cloud, we require employees to respect that separation. Don’t put Lullabot data, or Lullabot client data, into your personal account, nor add personal information into the Lullabot account. Lullabot won’t ever have access to your personal account, so nothing that belongs to the company or its clients should go into it. The test for whether you have separated your personal data properly is to confirm that if you were to unexpectedly lose access to the Lullabot account, you would still retain all your own personal data.
- Use your Lullabot email for services paid by Lullabot or clients, or that contain Lullabot/client data.
- Use your personal email for services you'd continue using if you left Lullabot, or that don't contain Lullabot data.
- For services supporting multiple email addresses (e.g., GitHub), add both work and personal emails to manage different projects.

Some services, like iCloud, provide no easy way to separate business and personal data. Since company data is involved, we require that you use best security practices to protect all the data stored in these systems. These best practices include storing the data in encrypted format, and using encryption when transferring data by using HTTPS and the VPN as appropriate.
### Inviting Users

## How do I know it’s safe to use a cloud service?
When possible, invite users using their email address rather than username to reduce the risk of accidentally adding unknown individuals.

The security team follows these guidelines when evaluating a new service. For example, when we investigated using Bamboo HR for Lullabot, we reviewed their Terms of Service, Privacy Policy, and any Security Policies. Examples of what was checked include:
### Separating Personal and Business Data

- Always separate personal and business data when the service allows it.
- Don't put Lullabot or client data into personal accounts, or personal information into Lullabot accounts.
- For services without easy separation (e.g., iCloud), use best security practices to protect all stored data.

- Their site HTTPs configuration with [SSL Labs](https://www.ssllabs.com)
- Their policies for data encryption and backup
- Their policies for who at BambooHR had access to our HR data
- Their password and password recovery policies (such as, do they limit passwords to 12 characters, or only allow letters and numbers)
- Their account and data deletion policies
- Their security reporting and notification practices
### Client Engagements

A search for “breach” or “leak” is also a good test to see if a service has a record of poor security. Instead of just investigating if a given service was breached, investigate how they handled the breach and how their systems were designed. For example, Yahoo has been shown to have a poor security track record, storing personal data and passwords in a way that made it easy for attackers to exploit.
Where possible, clients should be the account owners of cloud services in client engagements. The security committee can provide feedback, but the client should be primarily responsible for security reviews.

Consider the type of data you are using the cloud service for. If all they have is your name and email address, the risk is pretty low. Don’t use client data when trying out a new service, so if it does turn out to be insecure, the breach is limited. This also applies to service access tokens and API keys (e.g. a Pantheon Terminus token or a GitHub API key). These should not be used with cloud services such as hosted development environments like GitPod. Tokens can be added to CI services, but they should be as tightly scoped as possible and not allow cross-client access. For example, don't generate a Pantheon access token from your personal user account which has access to multiple clients. Instead, create a bot user for that specific project and tie all tokens to the bot.
## Approved Services Examples

In general, the security team aims to provide feedback on possible issues to the relevant stakeholders, rather than acting as a blocker to new services. We may ask those requesting new services to help with the investigation. The fastest way to get a new service reviewed and approved is to create a document detailing the above areas of investigation.
- NotebookLM (part of Lullabot.com account)
- ChatGPT (avoid divulging sensitive information)
- Claude.ai (same guidelines as ChatGPT)

Finally, if at all in doubt (or you just want help doing the above), ask in #security in Slack, or email [email protected].
## Introducing New Services at Lullabot

1. For individual purchases on PEX without integration or access to Lullabot data, no specific approval is required.
2. Apps integrating with Lullabot team services or interacting with customers need review by the security committee and relevant directors.
3. Fill out [the service request form](https://forms.gle/aPZnrCoEhfhB67ck8) for new service requests.

## Conclusion

By following these guidelines, we can make informed decisions about adopting cloud and SaaS services, leveraging their benefits while minimizing potential risks. Always prioritize security, privacy, and data protection in your decision-making process.

Finally, if at all in doubt (or you just want help doing the above), ask in #security in Slack, or email [email protected].

0 comments on commit 130f44a

Please sign in to comment.