OUR APPROACH TO SECURITY

Our platform runs on AWS (Amazon Web Services) and leverages Heroku from the Platform perspective. The Data is backed up continuously through backups are taken while the database is fully available and make a verbatim copy of Postgres’ data files. This includes dead tuples, bloat, indexes and all structural characteristics of the currently running database. Base backups and WAL files are pushed to AWS’ S3 object store through an application called WAL-E as soon as they are made available by Postgres.

Web Application Firewall: Web Application Firewall to protect our web app against application level threats (SQL Injection, Man in the Middle, etc.)

Security Certificates:

• SECURITY MANAGEMENT CONTROLS – ISO 27001 is a widely recognized and internationally accepted information security standard that specifies security management best practices and comprehensive security controls following ISO 27002 best practices guidance 
• CLOUD SPECIFIC CONTROLS – ISO 27017 is a standard that provides additional guidance and implementation advice on information security aspects specific to cloud computing. 
• PERSONAL DATA PROTECTION – ISO 27018 establishes commonly accepted control objectives, controls and guidelines for implementing measures to protect Personally Identifiable Information (PII) in accordance with defined privacy principles for public cloud computing environments. 
• INTERNAL CONTROLS OVER FINANCIAL REPORTING SYSTEMS – SOC1 Type 2 is an independent examination of the IT General controls and controls around availability, confidentiality and security of customer data processed relevant for the financial reporting of customers 
• SECURITY, AVAILABILITY & CONFIDENTIALITY REPORTS – The restricted to use SOC2 Type 2 report is an independent examination of the fairness of presentation and the suitability of the design of controls relevant to security, availability and confidentiality of the customer data processed. 
• PUBLIC REPORT OF SECURITY, AVAILABILITY, INTEGRITY, CONFIDENTIALITY, AND PRIVACY CONTROLS – The general use SOC3 report is an independent examination of the fairness of presentation and the suitability of the design of controls relevant to security, availability and confidentiality of the customer data processed.

Encryption: We leverage SSL (HTTPS) to encrypt the traffic in transit. When a user attempts to access our app, that is secured by SSL, the browser/app and the web server establish an SSL connection using a process called an “SSL Handshake” (see diagram below). Note that the SSL Handshake is invisible to the user and happens instantaneously. Essentially, three keys are used to set up the SSL connection: the public, private, and session keys. Anything encrypted with the public key can only be decrypted with the private key, and vice versa. Because encrypting and decrypting with private and public key takes a lot of processing power, they are only used during the SSL Handshake to create a symmetric session key. After the secure connection is made, the session key is used to encrypt all transmitted data.

• Browser connects to a web server (website) secured with SSL (https). Browser request that the server identify itself.
• Server sends a copy of its SSL Certificate, including the server’s public key.
• Browser checks the certificate root against a list of trusted CAs and that the certificate is unexpired, unrevoked, and that its common name is valid for the website that it is connecting to. If the browser trusts the certificate, it creates, encrypts, and sends back a symmetric session key using the service’s public key.
• Server decrypst the symmetric session key using its private key and sends back an acknowledgement encrypted with the session key to start the encrypted session.
• Server and Browser now encrypt all transmitted data with the session key.

Authentication: Once a user is uploaded into our system and email goes out to them with a “hot link” to set up their password. Users are required to submit their password in order to access the system and vote. In case a user cannot access their email we can leverage text messaging as a second means of communication to provide temporary access while still maintain security

Same as the he user-to-server encryption and authentication process

Once a user is uploaded into our system and email goes out to them with a “hot link” to set up their password. Users are required to submit their password in order to access the system and vote. In case a user cannot access their email we can leverage text messaging as a second means of communication to provide temporary access while still maintain security 

We have had NO data breaches in the last 5 years 

Electronically or double vote by issuing both e-vote and paper vote. Our system allows access to the user through the email address assigned to that unit owner. Even if that user has multiple units within the association, only one email address and password will be assigned to those units. The number of units in an association cannot change, therefore our system will only allow one vote for each unit . Meaning that our system will not allow for multiple votes. As for a unit owner submitting an electronic vote and a paper ballot vote, you’d need to have your lawyer advise you on how they will handle that situation. The benefit of our system is that each vote is time stamped and can be traced to its origin. So, for example, if your attorney rules that the first vote submitted takes precedent over the secondary vote and that the secondary vote needs to be discounted, then at least you have a time stamp of the e-vote for verification of which vote should count *we’ve seen association lawyers discount both votes because of a unit owner attempting to submit 2 votes on one ballot. It is impossible to have more than one vote per unit as each unit get one token and the system is designed to not take more than one token per unit per vote (paper or online).