Taking Security Seriously
external vs internal security; what we've done wrong; API changes and AMI listing; where we hope to go
At Rowan, our goal is to build software tools that help scientists with their research. An important part of this mission is that actual scientists need to feel comfortable using our software without worrying about security or privacy. We’ve talked to a lot of users over the past couple weeks, and one of the many things we’ve learned is that we need to handle security better. The rest of this post outlines what we think we’re doing right, what we think we’ve been doing wrong, and what we’re going to change moving forward.
What We’ve Already Been Doing Right
We’ve never been cavalier with user data, and we want to share the precautions we’ve taken since the start.
All data is encrypted in transit using TLS/SSL and at rest using LUKS AES-XTS-plain64. Database backups are also encrypted.
Passwords are additionally encrypted via salting and hashing, ensuring that nobody (even us) can figure out your password. Similarly, API keys are hashed before storage.
Credit card information never even touches our servers; instead, we use Stripe as our payments processor. Stripe also processes payments for companies you may have heard of—like Slack, OpenAI, Shopify, Google, and Amazon—so they’re pretty trustworthy.
Email verification is required to reset passwords, and users are notified upon any password change.
Calculations that are deleted are actually deleted—the data is gone for good. (We keep a record that a calculation was run, in case we want to reconcile any usage information, but all actual information is destroyed.)
And, of course, users maintain full control of all intellectual property. Uploading a structure to Rowan doesn’t give us any claim to your IP, just like making a presentation in PowerPoint doesn’t give Microsoft any claim to your IP. (Our terms and conditions state this clearly.)
What We’ve Been Doing Wrong
All of the above measures help to protect your data from external actors. But something that’s just as important is making sure that your data is safe from internal actors within Rowan. This is a lot easier to forget, and many companies don’t do a good job of this. (See, for instance, this recent scandal involving rogue Carta employees viewing confidential database information.)
We haven’t done a good job of this at all. In the early days of Rowan, our software broke a lot, and it was practical for us to be able to quickly see what was going wrong so we could push fixes quickly. Users would email us with error messages like “Hey my calculation just crashed, can you see what’s going on?” and we wanted to be able to respond quickly.
In response, we took two steps which made sense at the time: (1) we gave ourselves the ability to view anyone’s calculations through the web and (2) we set up lots of automated alerts so that when anything failed, we’d get convenient updates right in our inbox. Both of these measures were very helpful when quickly iterating as we built our platform—but both are quite bad from a security perspective!
What We’ve Changed
We’ve realized that what we described above is problematic. As of today, we’ve made a bunch of changes to protect your data:
Internal users now don’t have any special access. So if you send us a calculation that didn’t work, please make sure it’s shared first or we won’t be able to see it!
Email notifications about user actions have been disabled. We still get some email notifications for when servers go down and so forth, but the logs should be anonymized so that data won’t be compromised even while debugging.
We’ve also disabled analytics on any pages that require you to be logged in, to make sure no data gets leaked.
Nevertheless, there’s a limit to how secure a web application (or any software) can be. Our software has to be able to read your data in order to load web pages, so your data has to reside in our database. This is no different than how any other website works (email, banking, etc), but we recognize that some data is so confidential that you might not want us to store it at all. We’re adding a few new features to help in these cases.
First, we’ve added a new setting to our Python API that allows you to automatically delete all records of your calculation from our database once it’s finished. This makes running calculations through the API stateless—we’ll store the calculation information while it’s running, but once the result is returned no copy of the data will exist on our servers.
This is very simple in practice - just set delete_when_finished=True in the client when running in blocking mode:
import rowan
rowan.api_key = "rowan-sk123456"
client = rowan.Client(blocking=True, delete_when_finished=True)
print(client.compute("pka", input_smiles="c1ccccc1O"))
(More complete docs for the Python API are available here.)
For cases where even stricter security is necessary, we’ve also listed our software as an Amazon Machine Image (AMI) on AWS Marketplace. Purchasing the Rowan AMI allows you to launch EC2 instances in your own AWS account that come pre-loaded with all of Rowan’s scientific capabilities. You can deploy the AMI inside your own virtual private cloud and run our algorithms on confidential data. If even the CIA runs on AWS, you can be confident that your data is safe there. Our scientific code is pretty user-friendly, but it’s not as easy to use as our website, so we’ll offer phone/email support and white-glove onboarding for AMI customers.
(This probably won’t make sense for casual users. The AMI doesn’t come with a graphical user interface, so you’ll need to be comfortable with Python scripts, and managing & deploying EC2 instances is a bit too involved for the average experimental chemist.)
The process of listing an AMI on AWS Marketplace typically takes a few weeks, since Amazon staff have to manually validate and approve each listing. As such, the AMI isn’t live yet, but will hopefully be visible on the Rowan seller profile soon.
Where We’re Going
Drug design is an industry where security is crucial, so in the long term we plan to prove that we’re serious about this by getting a SOC 2 audit. SOC 2 is the recognized gold standard for information security, and obtaining SOC 2 certification involves extensive testing by third-party auditors to verify that you’re doing everything right. Unfortunately, this process is also very expensive and time-consuming, and we don’t think we’re quite ready yet. Until then, we’ll continue to try and adhere to established security best practices. Once we have more employees, measures like role-based access control and incident response plans will start to make more sense.
We care about doing a good job here and are always open to being corrected. If you have an idea for how we could improve our security, let us know at contact@rowansci.com!