System Architecture & Infrastructure
Hosting for ManageBac moved in August 2013 to new infrastructure in order to provide better reliability, improved security, better redundancy and a high availability (HA) architecture.
ManageBac servers are hosted at the iWeb data center in Montreal, Quebec (Canada). This secure facility is protected by the most modern access control in-use with dedicated facility management spaces. Only iWeb authorized technical staff can access the servers physically. The servers at iWeb have a redundant power supply. Our backups are hosted on an Amazon backup storage service and S3 secure buckets.
Files as well as any audio recordings are stored on a pair of servers behind our Cisco firewall. Files are copied from the master storage to a slave storage (i.e. secondary backup storage) using a back-to-back 10G ethernet cable. The synchronization is managed by DRBD, which is a system for handling RAID 1 over TCP.
The ManageBac main database is stored on a RAID 1 SSD disk and is replicated in real-time onto a slave DB server (i.e. a secondary backup database). Our systems are designed with redundancy in mind, in this way the master storage can fail at any time, and a quick intervention brings the duplicate database into service within 10 minutes with zero data loss.
In addition to database redundancy, we have a fully-redundant files backup system. Files are backed up every day using incremental versioning to Amazon Web Services S3. The versioning enables the persistence of files that were deleted in the main storage system.
We keep a history of all files indefinitely, which enables us to retrieve files deleted up to one year ago. All backup transfers between servers use an SSH encrypted connection.
SSL, Passwords & PCI-Compliance
256-bit SSL (https) is enabled by default on all user accounts. Account passwords are encrypted using MD5 hash format within our database. All credit card payments are processed with full PCI-compliance by Stripe Inc.
Our servers are patched with the latest updates and we run on LTS (Long Term Support) versions only. Currently Ubuntu 14.04 LTS. We regularly review and apply security patches in consultation with our external security team.
We use Pingdom for server monitoring, NewRelic and ScoutApp to monitor our application performance. If our server ever goes down, our team immediately receives an SMS and e-mail alert to investigate the issue. You can monitor our historical uptime at http://status.managebac.com. NewRelic enables us to track end user and application response times. We target < 180 ms application response times and our performance has been consistent with this target goal since 2009.
In addition to 3rd party monitoring, we have a centralized monitoring system on an independent server server based on the Zabbix monitoring solution, which provides advanced warning and alerts not covered by NewRelic or ScoutApp as well as precise visibility on our service operations together with server configuration changes made by our R&D team.
Firewall & Security Countermeasures
Our iWeb servers are hosted behind a Cisco ASA 5510 Sec+ dedicated hardware firewall. Together with application security measures, we can defend against multiple forms of DDoS attack and thwart common security threats by blocking port scanning, brute force password cracking, etc.
Faria Systems Inc. complies with both the EU Safe Harbour Agreement and the Canadian Personal Information Protection and Electronic Documents Act. Our hosting facility is located in Canada at iWeb in Montreal and under European Commission rules, Canada is treated as a jurisdiction having 'adequate protection': In November 2015, the European Commission ruled the EU Safe Harbour as being invalid.
In response and to provide further assurance to schools, we have entered into supplemental Data Protection agreements both with schools individually and with the IB.
Please contact us at email@example.com if you would like us to provide an supplemental Data Protection agreement with your school.
This Security Overview briefly describes security practices currently applied at Faria Systems.
1. Development and Deployment Security
- Developers are require to observe operational security to ensure that their work machines and devices are not compromised.
- All development machines are required to be password-protected and not shared between developers.
- File system encryption is required for all developers, including contractors.
- All software developed by Faria Systems (‘Software’) is tracked in Git, a temper-evident version control system which works in terms of commits, set of changes over time.
- Each commit is timestamped, marked with author information, and cryptographically signed.
- Changing contents of a commit automatically invalidates the signature.
- An automatic code analysis tool, Code Climate, is invoked on every software commit submitted to GitHub. This service analyses code revisions as they are created during development, and poses alerts on potential code quality or security issues.
- Principal developers are required to ensure that all software changes must be free of security issues, before they can be promoted to production.
- An automatic platform scanning tool, AppCanary, is installed on all development and production servers running our software. This tool checks third-party software packages and dependencies installed on all servers and checks for known vulnerabilities.
- When a vulnerability is discovered, the Principal SQE is paged for resolution, which usually involves upgrading the affected packages to versions that contain fixes.
- Deployment of all Software is automated with scripts. During deployment, the cryptographic signature (‘SHA’) of the desired commit is used to refer to the revision desired by the principal developer and ensure that all servers in question are updated with the same revision of software.
- Deployment of any software to any server requires key-based authentication, where the public key of the principal developer must be verified by the destination servers. Management of public keys on servers is handled by Userify, a service which automatically updates and removes authorized public keys from relevant servers to reflect a centrally defined access control list.
- Manual auditing of authorized keys and access to each server is done at random intervals.
2. Operational Security
- All network interaction with Faria’s Software is proxied over CloudFlare, a service which provides DDoS mitigation, content acceleration and application security.
- The origin IPs for our servers are not exposed, which lessens the risk of targeted attacks that work around CloudFlare.
- Common attack vectors are automatically mitigated with CloudFlare’s application firewall rulesets.
- Traffic that passes through CloudFlare must then pass through Faria’s own Cisco firewall appliances.
- All production network traffic is encrypted with valid SSL Certificates. Unencrypted connections are not accepted and customers will be automatically steered towards encrypted connections.
- Each software project in Production is served by at least two front-end application servers. In case an investigation is required, the affected server can be pulled off-line immediately for forensic snapshotting without causing downtime.
3. Data Integrity and Recovery
- Use of foreign keys, constraints and application-level validations is encouraged whenever appropriate, to ensure that data models employed by applications are well-defined and less likely to cause application issues, require manual migration, nor necessitate rework.
- For all projects, automatic daily database backups are kept for 30 days; weekly backups are kept forever.
- For each project, the principal developer periodically verifies integrity of data backups by performing restoration in a controlled environment.
- For each project, a Pre-Production / Support environment is available for software testing and data inspection purposes. This environment is isolated from the Production environment and ensures that revisions of Software in development do not interfere with other revisions already promoted to Production.
4. Physical and Personal Security
- All WiFi networks at all Faria Systems offices are encrypted and the passwords rotated periodically.
- All Faria Systems offices have working locks and alarm systems.
- Each Faria Systems staff member is allocated with a commercial VPN account, to be used when connecting in public.
5. System Security
- System installation uses hardened and patched OS Ubuntu 14.04 LTS.
- System patching is configured by DevOps to provide continuous protection from exploits.
- Dedicated firewall helps block unauthorised system access.
- All SSH connections to both production and staging use secure RSA public key authentication: http://www.ibm.com/developerworks/library/l-keyc/index.html
- Password authentication is disabled on both production and staging servers to prevent attempts at brute force cracking.
- Github provides secure Git revision control for all Faria applications. All development staff are required to subscribe to e-mail notifications and the RSS feed. This provides staff with real-time notification of production and staging deploys.
- Versioning of Apache is hidden to minimize risk of server profiling.
- System uptime and performance is monitored continuously via Pingdom and NewRelic at 30 second intervals with SMS and e-mail notifications.
6. Local Security
- Passwords shall be greater than 8 characters, include both upper and lower case characters, numbers, and symbols.
- All automatic logins shall be disabled.
- Screensavers shall be password protected (recommend LockTight).
- Local firewalls shall be enabled to prevent access to unauthorized services.
- Hard disk drives shall be encrypted using FileVault or PGP whole-disk encryption.
- Private key passphrases shall be strong, including both upper and lower case characters, number, symbols and not contain public or personal information that would be easily guessed.
- IT systems when not within the boundaries of Faria system operations shall be secured and/or attended at all times.
- When traveling, computers shall not be included in checked baggage.
- When operating in public areas, IT systems shall not be left unattended.
7. Deploy Procedures for Staging
- Please make sure that all tests pass before deploying to ensure that you are not breaking code.
- Under no circumstances should you fork any repository without written permission.
8. Deploy Procedures for Production:
- Please make sure that all tests pass before deploying to ensure that you are not breaking code.
- Do not deploy to production at non-scheduled times without approval unless otherwise justified (i.e. use your professional judgment).
- At least two staff must be online for all scheduled production deploys.
- If you receive a downtime alert from Pingdom, you should immediately investigate to determine and rectify the issue. If it is related to a recent production deploy, you should immediately revert all changes.
- Do not store credit card information on our servers or accept credit card information over the phone or e-mail. All credit card payments are processed through Stripe on PCI-compliant servers.