At Compaas, we are serious about the security of our customer data. To do this right, we focus on several different areas — what services we use, how we design our product, and how our culture and our processes promote privacy.
Not so long ago, every tech company, big or small, needed a ton of specialty engineering work to be secure. Back then, enterprise-grade security seemed too expensive for smaller companies to do well — but that’s in the past. Today, new SaaS platforms can take advantage of hosted infrastructure with terrific security features. Many of these features we get nearly for free, and only need a little decent configuration. On the Compaas team, we have people who remember implementing many of these features by hand. That took a lot of work! Having a little more experience makes us especially grateful about how easy it is these days.
Compaas encrypts all our traffic over TLS. Only a year ago, maintaining this could be annoying. We had to get our own SSL certificates and load them into our application hosting service. This year, we have an automated process using LetsEncrypt.org, including renewals. Not only is this less work (yay!), but it reduces the chance of mistakes or late renewals. We also configured our platform to confirm that every page serves via HTTPS.
We use application hosting service add-ons for logging and alerting. These services are good for finding bugs or detecting outage issues, and they are also good for security. We log all admin and user logins for auditing purposes. And you never know when you might need an access log for a critical system.
Modern Web software platforms (we use Django) have lots of built-in security features. These help secure Web forms against threats like Cross-Site Request Forgery, Clickjacking, SQL Injection and so on. Django makes it especially easy to review a site to see that you’ve correctly configured the security features. Of course, we have used this check-up right from the beginning with Compaas.
When we receive files from customers, we keep them in encrypted storage. This is much simpler because we leverage the encryption settings in AWS S3.
Keeping a database secure used to be pretty expensive. You needed a DB expert on staff (at least part-time) to handle seemingly constant server upgrades and patches. Remember those days? Now we don’t have to do that because we use a managed database service.
The team at Compaas has extensive experience in product design, engineering, and operations. From this, we’ve have built great set of design patterns to maximize privacy and security in our product design.
Today, Compaas requires Google OAuth for login. We use standard and well-tested libraries to do OAuth and to manage sessions, session expiration and logout. No passwords to store, no login shortcuts.
Every single resource on our hosted service should be subject to access control. To support this, we pass every incoming web request through authentication first. This approach means no mistakes deciding what resources are public vs. private. On the application site, they’re all private. After authentication, we restrict the data based on the authenticated user. That way, we ensure users can’t request data they’re not supposed to access.
While we do send a couple necessary emails, we’re careful to never send data over email. This includes notification emails to our staff, notification emails to our users, and emails that customers might send us. Instead of sending us data via email, we always ask customers to use the secure upload within Compaas.
When we do use third-party libraries, we are careful about where we link to them and how we use them. When we use APIs, we make sure we’re requesting data over a secure channel too. This is harder to do with a blanket technology solution. That’s why we rigorously code review each time we use an external API, and make sure we’re not using it inappropriately. See our human processes below about how we review all code.
Unit testing, functional and integration testing, any kind of automated testing at all... I love testing even more than my knitting needles, and you know that’s saying a lot. I love testing so much that I’d write automated tests even if they only helped us refactor code more safely. I’d write automated tests even if they only helped us avoid bugs. I’d write automated tests even if they only helped us confirm that security features and choices remain constant. But when you add all these reasons together, it’s easy to see why we have built Compaas with automated test coverage since day one.
All the things I listed above are low-hanging fruit. People and processes are where security gets very difficult— but it's super important to get right.
We have on-boarding documents, which explain employee expectations. Our on-boarding processes ensure we both communicate policies and configure employee access correctly. Some highlights:
Non-disclosure agreements protect us as a company, but they also protect our customers’ data and privacy. Our lawyers make sure that we have the right words in there.
Compaas employees may not copy customer data to most other systems. For example, we never put a screenshot including customer data in our bug database, or copy a customer spreadsheet to Google Drive.
As we grow and employees stay with us and change roles, our systems will grow and get more complicated. We’re already planning how we will keep pace with that by updating on-boarding and training. It’s a constant effort, well worth the cost.
We have policies about who can access data and who can do major operations steps like deploying code. We have policies about who can access production systems at all even if it’s only to read error logs.
In the few systems where we need employees to use passwords, we have minimum password requirements in place. Where possible, we set up third-party systems so that our employees must or at least may use two-factor authentication.
We also choose to use fewer logins where possible. It’s generally safer to use Google Auth to access our CRM than to use a password. It’s safer to use GitHub private keys to access CircleCI than have another login there. This also helps us clean up when somebody no longer needs access, with fewer accounts to update to remove someone’s access.
We review all the code that goes into our software so that we have more eyes on the code to catch possible security mis-steps. We make sure to think about security ramifications in every change. Code review helps us keep that discipline.
We track bugs and security work in our issue tracker, and mark them as such. This way, we know our status both realistically and honestly. Once in the issue tracker, issues aren’t at risk of getting forgotten in somebody’s notebook scribbles.
We maintain separate systems for testing, demo, and production. These are completely separate, including databases, file objects stores, and log streams. This setup allows us to monitor and grant access to the production system narrowly. If an employee doesn’t need access to production to do their job, we are careful not to grant that.
Did you read this far? Be honest, did your eyes glaze over?
Security is complicated, and it affects choices we make all over the place. From how we talk to employees to how we change a few lines of code that use the network, security is always on my mind. From my long experience, this has become just a part of my work in job after job. For me, security is both a set of habits as well as a well-trained gut that tells me when I should look a little closer at something. And from my long experience, I am grateful for the automated services and features we use at Compaas. With them, we are able to focus on creating a great product, without compromising on security.