Server and Network Security
Propeller hosts the majority of its application on the Amazon Web Services (AWS) platform. 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 for these parts of the application is delegated to AWS. For more information regarding AWS’s physical security practices, check out their security whitepaper.
Propeller hosts its own fleet of on-premises servers for the intensive data processing tasks required to generate the 3D models that Propeller produces. These servers and their network are housed in a secure building, protected by self-closing, swipe-access doors, alarms, and security cameras. They are further protected by a locked physical barrier around the servers themselves.
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.
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.
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 on premises and in AWS to further ensure your data’s safety:
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 or has a firewall policy based on the system’s function. To mitigate risk, our firewalls 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 AWS 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 deals with it appropriately.
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.
Per best practices, 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.
Propeller’s servers are automatically and continuously patched with the latest security updates. This ensures that we are able to minimize our exposure to known vulnerabilities.
Propeller’s servers employ the use of full disk encryption to ensure that data stored on them is not accessible to others. This protects the data both in case of physical access to the servers and when disks are disposed of.
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.
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.
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.
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.
Feedback and bug reports are gathered from customers, and changes and fixes are made as appropriate.
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.
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.
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.
In addition to the code reviews mentioned above, we use several other measures to ensure vulnerabilities are not present in the application.
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. The containers in which Propeller deploys its services and applications are similarly scanned. 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.
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.
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 potential 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.
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. Should a failure occur, an automated fallback is initiated. This strategy mitigates both instance and data center-level failure.
Our data processing systems are similarly designed such that we automatically fall back to using AWS servers if our on-premises machines are unavailable. This means that these systems are just as available as if they were hosted in the cloud, across multiple data centers.
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 our 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.
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 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.
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 be accessed from only 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 Australian AWS region. From here the data is transferred, with encryption, to on-premises or AWS servers in Australia or Singapore for processing. These servers store this data, with encryption, until it is no longer required for processing.
Any outputs resulting from processing are pushed to an S3 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. This is done to improve delivery performance when customers request the data. 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.
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.
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 manner with automatic recovery from instance and data center-level failures.
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.
In the event of unauthorized access to your data we will notify you as soon as possible after becoming aware of the issue.