Propeller’s Platform Security 

We take the security of your data seriously

We take the security of your data seriously. Propeller applies industry best practice to ensure its safety. This document outlines the measures we take to prevent your data from falling into the wrong hands.

 

Physical Security

Server and Network Security

Propeller is wholly hosted on the Amazon Web Services (AWS) platform, which means we don’t maintain any physical servers or network infrastructure related to the operation of our application. AWS provides state-of-the-art data center security that complies with industry standards such as SOC, PCI DSS, and ISO 27001. All physical network and server security responsibility is delegated to AWS.

For more information regarding AWS’s physical security practices, check out their security whitepaper.

Office Security

Our physical offices are secured with self-closing, self-locking doors only accessible by electronic swipe card or keycode. All access is securely logged, and we only delegate control system access to select, trusted individuals. Further, all our entrances and stairwells are monitored and recorded by security cameras. The premises are also alarmed outside of office hours with a back-to-base motion detection system. Automated fire suppression systems are installed, as well.

Staff Devices

All devices used by our staff members are required to be password protected, with automatic locking after short periods of disuse in addition to full-disk encryption. Staff are further required to enable multi-factor authentication (MFA) on all services that provide it.

Network Security

Much like our physical network security, the majority of our virtual network security is handled by AWS. Amazon provides completely isolated environments where we deploy our applications, and they do so for over one million companies and government organizations across the globe. Some well-known clients who use Amazon to protect their data include NASA, Shell, Autodesk, British Gas, GE, Hitachi, Lafarge, Trimble, and the US State Department.

For more information regarding AWS’s virtual network security practices, check out their security whitepaper

On top of the security outlined above, Propeller implements several other best practice measures to further ensure your data’s safety:

Firewalls

We use network firewalls to restrict access to systems from external networks and between systems internally. By default, all access is denied and only explicitly allowed ports and protocols are permitted based on business need.  Each system is assigned to a firewall security group based on the system’s function. To mitigate risk, security groups restrict access to only the ports and protocols required for a system’s specific function.

We also use dedicated web application firewalls (WAFs) to protect HTTP-based services through rate limiting and packet inspection. These firewalls inspect requests for malicious payloads such as SQL injection, cross site scripting (XSS), and other known attacks, and block them accordingly. They similarly provide protection from distributed denial of service (DDoS) attacks through rate limiting and by blocking requests from known malicious botnets.

Intrusion Detection and Monitoring

All network traffic and API calls to underlying network infrastructure are securely logged and continuously analyzed against integrated threat intelligence feeds and using machine learning to detect suspicious behaviour.

If something is detected, an alert is immediately sent to our security team, who assess the threat and deal with it appropriately.

Change Control

We maintain all configuration in code to maintain transparency when it comes to underlying network and infrastructure changes. It’s checked into version control and all changes are reviewed for security, scalability, and durability before deployment. We also test all changes thoroughly in a dedicated staging environment before deployment to the production environment.

Server Isolation

Per best practice, servers are isolated in private subnets so they cannot be accessed from the internet. Should access be required, it can only be obtained via a bastion host that’s been hardened against attack. This narrows the possible attack vectors, allows for logging of access, and creates an easy way to revoke access if there is an attack.

Application Security

Change Control

As a web application, code changes are made and deployed in a continuous manner. No action is required to update to the latest version beyond refreshing the browser. In order to maintain application security, code quality, and minimize the introduction of bugs, we follow a strict software development life cycle (SDLC).

Design and Development

New features and changes are thoroughly architected and designed. Once approved, development begins and all code is checked into source control.

Review

All code changes are subject to peer review for quality, performance, and correctness. Code is also reviewed from a security standpoint, adhering to the OWASP top 10 guidelines.

Staging Release

After the review period, changes are deployed into a staging environment where they’re thoroughly tested by developers and our QA team. We perform both feature and regression testing to ensure that changes behave as intended and haven’t introduced errors elsewhere.

Production Release

When this testing is complete and any required fixes are made, the changes are deployed for customer use. Large or experimental changes may be deployed as beta features for a limited time. Users will have the option to turn these features on or off during this time.

Post Release

Feedback and bug reports are gathered from customers, and changes and fixes are made as appropriate.

Emergencies

In rare situations where changes must be applied quickly to fix bugs or recover from a security or downtime incident, some of the above steps such as code reviews, testing, and the staging release may be skipped. Should this be the case, all changes will be subject to review and testing once things have returned to normal.

Authentication and Authorization

Passwords

Propeller’s main login method is via email address and password. Your password is never stored in plain text. All passwords are salted and hashed multiple times using the PBKDF2 algorithm with a SHA256 hash, as recommended by the National Institute of Standards and Technology (NIST).

Passwords must also meet two complexity requirements: (1) be at least nine characters long and (2) must not exist in this list of top 20,000 most common passwords.

Should you forget your password, it can be reset by providing the email linked to your account. A link with a cryptographic token is sent to the address provided, allowing you to reset your password.

Single Sign On (SSO)

Users with Google or Trimble Connect accounts may use the respective “Sign in with” buttons to log into Propeller for a single sign on experience without any additional setup.

Customers can have their own SSO providers (such as Ping Identity or Okta) integrated into their portals for an additional fee. Integration can be achieved with providers that support the OAuth2, OpenID Connect, or SAML protocols.

Users must first be invited by another user with the correct permissions before SSO can be used.

Multi-Factor Authentication (MFA)

MFA is not supported when logging in with an email and password, however, customers can provide and enforce MFA by integrating an SSO solution with multifactor support. All Propeller employees are required to login with MFA to further ensure data safety.

Cookies

Once a user is logged in, Propeller stores session tokens as secure, HTTP-only cookies on the user’s browser to identify them as having access. This is further protected through the use of cross site request forgery (CSRF) tokens and strict CORS policies to prevent cross-domain requests and unauthorized use of the cookie. Cookies expire after two weeks, which means users are automatically logged out.

Vulnerability Mitigation

In addition to the code reviews mentioned above, we use several other measures to ensure vulnerabilities are not present in the application.

Dependency Analysis

Static analysis is run on all code repositories to scan their dependencies for known vulnerabilities as recorded in the National Vulnerability Database (NVD), managed by NIST. Automated alerts are sent to relevant developers who apply the recommended fix as promptly as possible based on the relevance and severity of the issue.

Penetration Testing

We have also employed third-party penetration testers to find and report vulnerabilities in our application and systems. Once a report is made, it’s triaged, assessed for severity, and the vulnerability is patched appropriately.

Data Sanitization

User inputted data may be stored in a database and re-rendered in the browser. This can open the opportunity for SQL injection and cross site scripting (XSS) attacks. In order to prevent these attacks, web application firewalls block all requests detected to contain malicious payloads. For further security, all data entered into databases or rendered to HTML is sanitised appropriately.

Logging and Monitoring

In order to provide an audit trail and to enable quick investigation of potentials threats or issues, all requests to Propeller services are securely logged with enough information to recreate events.

Some information that may be logged includes IP addresses, request headers, request payloads, device information, status codes, response times, and failed login attempts. We never log confidential or sensitive data. All logs are retained and backed up for the duration of their usefulness. Additionally, error rates and performance metrics are constantly monitored to ensure you have the best possible end-user experience.

Availability

AWS is well known for its stability and reliability. This is backed up by service level agreements that ensure uptime and keep AWS accountable for downtime. Nevertheless, outages can occur in exceptional circumstances.

As such, we’ve designed all of our services to be highly available and failure-resilient. To accomplish this, we replicate all compute and database functions across multiple instances in multiple, geographically separated AWS availability zones. All hosts and applications are also constantly monitored for availability, and should a failure occur, an automated fallback is initiated. This strategy mitigates both instance and data center-level failure.

Furthermore, the services comprising the application are monitored using an external tool that monitors uptime from several locations across the globe. If an outage occurs, a technical member of staff is alerted immediately and a resolution is made as quickly as possible based on the severity of the outage. Propeller endeavors to maintain a 99% yearly uptime.

Scalability

Since the beginning, we’ve designed the Propeller Platform to meet the large data requirements that come with processing, hosting, analyzing, and serving survey-grade mapping data across the globe. We do this is primarily by leveraging AWS’s effectively infinite scalability and global coverage. This, coupled with demand-based, application-, and infrastructure-level autoscaling, means that we can quickly and easily scale up our applications, and the underlying infrastructure, to meet any level of demand.

Information Security

Propeller classifies all user submitted information as confidential and essential. We use several methods to ensure that customer data is always available and secure:

Data Storage and Transmission

All data submitted to and from the Propeller Platform is encrypted and transmitted securely over HTTPS using TLSv1 or higher, with a 128-bit cipher or higher, depending on the client. All internal transfers of data between Propeller services are similarly protected by encryption.

Once submitted, all data is stored securely in AWS with access controls preventing unauthorized access. S3 buckets are configured to be private by default and access keys or pre-signed URLs are required to access the data. Similarly, databases are password protected and may only be accessed from whitelisted IP addresses. Access and permissions to alter or delete data is only delegated where necessary and based on the principle of least privilege.

All data for processing or display is uploaded to an S3 bucket located in the Sydney, Australia, AWS region, where it is also processed. Any outputs resulting from that are stored in the same bucket. To improve delivery performance, they’re then pushed to a bucket in the AWS region closest to the customer, which may be in one of several sites across the globe, including in the US and EU. Metadata and other data entered into the platform is stored in RDS databases located in a US-based AWS region.

Where practicable, all data is encrypted at rest, including in queues, databases, data volumes, and S3 using AES256 encryption. Encryption keys are created, managed, and secured using the AWS Key Management Service (KMS). We automatically rotate keys yearly.

Access Controls

In addition to the aforementioned storage level access controls, the Propeller Platform provides user-configurable access controls at an application level. We deny access to the data within a portal or site by default, and require a portal administrator, or another user with the Manage Access permission, to invite a user to view the data within a portal. It’s possible to specify fine-grained permissions when granting access, allowing the principle of least privilege to be applied. To make it easier to manage users and their permissions, they can be grouped into teams that can also be assigned permissions.

Disaster Recovery

In the unlikely event of customer data loss, procedures and safeguards are in place to ensure recovery. The majority of customer data is stored in Amazon’s S3 which is rated to have 99.999999999% durability. On top of this, object versioning is enabled by default on all buckets, which ensures that even if an object is deleted or overwritten, it can be recovered.

The remaining customer data is stored in continuously backed-up Amazon RDS databases, providing point-in-time recovery to the minute. Furthermore, daily snapshots, alongside continuous replication to a hot spare with automatic failover in another availability zone, provides more redundancy and resilience to instance and data center-level failures.

Similarly, all application services are deployed in a highly available manor with automatic recovery from instance and data center-level failures.

Business Continuity

Operating since 2014, we have a proven track record of delivering excellence to our many customers across the globe. As a part of this, all customer data is available for download through the Platform. In the exceedingly unlikely event that Propeller should cease business operations, or if you would like to take your business elsewhere, your data will remain available for download for a reasonable amount of time.

Privacy

Propeller complies with all local privacy laws, including the General Data Protection Regulation (GDPR), and is committed to keeping your personal data safe and secure. For more information, view our privacy policy.

Data Breaches

In the event of unauthorized access to your data we will notify you as soon as possible after becoming aware of the issue.

See the Propeller Platform in action

Watch a demo