Pie Security Paper
Updated February 21, 2019
At PieMatrix, our team employs a number of security protocols in order to keep your data (both personal and project-related) safe. This paper has sections below that covers Dev-Ops Security, Web Application Security, Development Security Workflow, and Amazon Web Services (AWS) security and compliance reference links.
Dev-Ops includes server deployment, maintenance, and updates. We also use Amazon Web Services (AWS) infrastructure and comply with their best practices.
Our production environment, where we host the application and your data, is set up with a production AWS EC2 instances, which run compiled code of the main application. The EC2 instances are locked down with:
AWS Security Policies, limiting access to secure services only.
Linux firewall installed on the EC2 instances.
SSH access relying entirely on public key infrastructure, no passwords are ever used to access the server. We use private / public key pair, RSA encrypted, so this is more secure than password and standard in industry.
Automated Deployment Process. To minimize probability of a human-made error, the deployment and updates process is fully automated and deployment to production requires successful Continuous Integration (CI) build to succeed.
Controlled Team Access. We limit and monitor the development team members that can take an active part in, or have access to, trigger deployments to production, install additional software, or access production data. This limits the server access to only certain staff members.
Infrastructure-as-a-Service and Platform-as-a-Service providers. We rely on outsourcing some core services to trusted third-party providers, most notably Amazon. Another example is Mailgun for transactional email API’s services.
Database. The Pie database is hosted on Amazon RDS. The data is being stored encrypted, backups are performed on regular basis and database access is controlled by both: AWS Security Policies and strong username & password combination. Third-party BI tools (i.e, Microsoft Power BI, Tableau, Yellowfin, Excel Pivot Table) can be configured to access read-only replica of selected customer’s database, if requested. In such cases, access to data is limited with strong username & password combination, enforced connection encryption (SSL), AWS Security Policy based on whitelisting IP addresses, and PostgreSQL Row-Level Security policies. Clients are never given access to full database, but only carefully prepared read-only views containing their own data.
Secured Socket Layer (SSL). Web application is accessible only over secure connection (HTTPS), with a strong RSA-based SSL certificate.
Automatic Security Updates. Server and additional software (RDS database) have enabled automatic security updates, applying critical security patches in unattended and regular manner.
Web application security
Our Pie web application is secured with number of security layers:
SSL connection is required
Users are required to sign in with strong password (at least 8 characters long)
API access is allowed only for signed in users, after obtaining one-time login token
Data access is protected by multi-layer access control lists engine, on task, project and organization-level
Web application actively prevents SQL-injection attacks by generating SQL statements from higher-level language and usage of prepared statements, views and read-only replica
Web application actively prevents XSS attacks by automated escaping of all generated data being displayed
Web application actively prevents CSRF attacks, by requiring one time tokens to perform actions of users
Limits on upload size, limits on requests and timeouts are employed in order to prevent or make more difficult DOS attacks on the infrastructure
Web application is built in a way that it recovers from unlikely catastrophic failures, with multiple watchdogs performing health checks / restoration of last known good state
Passwords are stored securely in the database, encrypted with multiple runs of encryptions, secured with additional random padding (password + salt method) using strong encryption and trusted library and algorithms (BCrypt)
User activity is permanently logged, including storing their intended actions, IP addresses and filtered list of data that has been sent to server
Web application is architected in layered manner, requiring attacker to break through multiple layers to gain malicious access: client-side front-end is separated from back-end using API (GraphQL and REST), API is protected using token generated on login, API has limited access to database as it’s required to perform operations on it indirectly using Database Access Layer, Database Access Layer has limited access to data based on currently signed in user etc.
Development security workflow
Development team employs a number of practices on a daily basis, to enforce best practices and limit possibility of introduction of critical bugs:
New / changed code is always manually tested and peer reviewed by team member not involved in creation of this piece of code. We use a Pull Request code review process, which includes pushing code to a branch, other developer checks code and either rejects or passes it, then when accepted it is merged to the main branch. We use Bitbucket for this process.
Code is tested in automated manner, including unit tests for individual layers (DBA, API, UI), but also integration tests testing all layers of product
New / changed features are manually tested on our staging infrastructure, replicating future production infrastructure to find bugs, inconsistencies and possible security implications
Code is subjected to automated static code analysis and vulnerabilities detection (both back-end and front-end code), as part of CI/deployment pipeline.
Access to source code is strictly limited to developers performing active role in project, their access is further limited by enforcing 2FA
Access to development machines is limited to development staff only, their hard drives are protected with strong passwords & encryption, data is also protected by firewall
AWS security & compliance reference links
We use Amazon Web Services (AWS) for our hosting infrastructure. Amazon has a number of articles on their website that details their approach to security and compliance. The following are links to those pages.
Please note that if they change their web page URLs or remove these particular page, the above links may not work. If that’s the case, please notify us at email@example.com and we will do what we can to get your redirected
Application & Data
Elixir (Back-end functional programming language leveraging the Erlang VM)
Phoenix (Elixir framework)
Apollo GraphQL (application API for React client side)
Absinthe GraphQL (application API for Elixir server side)
PostgresSQL Amazon RDS (database)
DevOps & Utilities
PieMatrix Pie (DevOps processes)
Amazon Web Services (AWS)
Bitbucket, Bitbucket Pipelines
PieMatrix Pie (Agile sprints, sprint collaboration, and project/process management)
Slack (Internal communications)
Zendesk (Customer support)
MailChimp (Customer communications)
Stripe (Financial transactions)
Changes to this policy
We may change this Security Paper in the future. We encourage you to review this page often to stay informed of changes that may affect you. All updates and amendments are affective immediately upon posting on this page. The most recent version is reflected by the version date located at the top of this Security Paper page.
Questions or concerns: Please contact firstname.lastname@example.org for any questions or concerns. Thank you.
Other useful pages
70 South Winooski Ave., #276
Burlington, VT 05401