ProsperOps places a primary focus on the security and protection of the data that you provide us. Our Engineering organization has designed and implemented the practices outlined below to provide you confidence and safeguard your information. If you have any questions regarding these practices, please do not hesitate to contact us.
Data we access and store
We only access and store information required for us to deliver our discount optimization services, which includes metadata about the types of instances you are running and the RIs and Savings Plans present in your account.
The permissions you grant us to your AWS account(s) do not give us the ability to make changes to your applications or to view your customer data. We're granted the minimum permissions required to optimize your commitment portfolio and you have an opportunity to review the full IAM policy prior to implementing it. We follow AWS best practices for our IAM role configuration, including the use of external-ids for access verification.
AWS service metadata (listings of EC2 instances, RIs, and Savings Plans) retrieved from your environment is stored inside our AWS environment and is encrypted using AWS KMS. Direct access to our production database is limited to a small number of ProsperOps employees on our engineering team that are responsible for supporting the production environment and is accessed only on an as-needed basis. We do not proactively expire any of this information during the time in which you have an active subscription to ProsperOps.
Data is processed and stored by ProsperOps in the United States. The AWS billing and commerce systems also operate in the United States for all AWS commercial and GovCloud regions, so we are not transferring the data to a new jurisdiction.
Compliance and certifications
ProsperOps is built on the Amazon Web Services platform and benefits from the same infrastructure-level compliance and security practices as the applications and customers that we serve. The AWS infrastructure provides us with robust security at the software, hardware, network, and physical layers of the infrastructure stack. AWS implements a number of compliance programs including:
- ISO 27001
- SOC 1, SOC 2, and SOC 3
- PCI DSS Level 1
SOC 2 Type II
ProsperOps is SOC 2 Type II certified. This means our organizational controls and practices, as defined by the SOC 2 framework, are in place and effective in safeguarding the privacy and security of customer data. This has been tested and verified by an independent, third-party auditor. For more information, please see our SOC 2 Type II Compliance help article.
PCI
All payments are processed via our payment processing partner Stripe and we do not store any cardholder data in our systems. As described above, we do not have access to any of your customer or cardholder data as part of providing our service, so we are out of scope for customer PCI compliance efforts.
3rd Party Security Review / Penetration Testing
We have implemented automated 3rd party security testing of our platform which scans for thousands of vulnerabilities and threats on an ongoing basis. The scope of these tests include both cloud infrastructure (e.g. publicly accessible S3 buckets) as well as code and application level scanning (e.g. OWASP Top 10).
We also engage a 3rd party auditor to perform manual penetration testing of our platform on an annual basis, and promptly remediate any findings.
Reports are available upon request.
Application-level security
Encryption in transit
All communication between our microservices is secured using SSL/TLS with 256-bit keys. We require the use of TLS 1.2 or above for all connections. All public-facing services are only accessible via HTTPS and we have enabled HSTS to ensure that any new services follow the same practices.
Encryption at rest
All datastores (databases, EBS volumes, S3 buckets, etc.) leverage the AWS Key Management Service (KMS) for data encryption at rest. Application-level secrets are encrypted using KMS and the AWS SDKs.
Sessions
All user sessions expire one hour after login or after 30 minutes of inactivity, whichever comes first. Sessions are immediately updated or revoked upon changes to a user’s permissions by a customer administrator.
Security headers
We employ best practice client-side security headers, such as X-Frame-Options and X-XSS-Protection, to ensure that the ProsperOps Console is secure from many common client-side application attacks.
Code review and production deployments
All changes to ProsperOps applications are reviewed by a second engineer to ensure that they meet the standards outlined in this document. Code is verified in a staging environment and can only move to production after the formal engineering review process. Security of customer data is a top priority for our engineering organization, and we ensure that our team follows industry-established best practices throughout every feature of our applications.
Customer access
Customers’ administrator users maintain full control over who has access to the ProsperOps Console and are responsible for creating, updating, and deleting user access as necessary.
Infrastructure level security
Instance and network security
ProsperOps runs each of its microservices inside of a Docker container and leverages the best-of-breed AWS network technologies (such as security groups and VPCs) to fully isolate and provide least-privilege access to each component of our infrastructure.
Backups and recovery
Our infrastructure leverages the built-in availability constructs provided by the AWS platform. We continually back up our production datastores and retain individual backups for at least 35 days in order to minimize the risk of any unintentional data loss. Historical log data for our administrative and infrastructure systems is stored for a minimum of 365 days.
Other policies
Employee access
ProsperOps leverages the Google account infrastructure for all access to our production applications. We benefit from the advanced security practices employed by Google and require all employees to use hardware security keys for their accounts. Third-party SaaS tools used by our team (such as Slack) leverage federation with Google whenever possible, and otherwise employ two-factor authentication provided directly by the tool itself.
Our administrative systems use role-based access controls to ensure that each user’s access is least-privilege and aligned with their job responsibilities. Access to our production infrastructure is limited to members of the engineering team that require access to support our infrastructure and applications. We log all access to our administrative and infrastructure systems and periodically review access to ensure that it is still aligned with each user’s responsibilities. All privilege changes require management approval and are also logged for later review.
Password policy
We enforce the following password policy for all users of our ProsperOps Console:
- At least 8 characters in length
- Contain at least 3 of the following 4: lowercase letters, uppercase letters, numbers, special characters (!@#$%^&*)
- No reuse of previous 24 passwords
- Cannot be a commonly used password
- Cannot contain your personal data (first name, last name, etc.)