In an effort to provide clear insights into the security aspects of our cloud-based multiphysics simulation software, Quanscient Allsolve, we conducted an interview with Asser Lähdemäki, the Chief Product Officer at Quanscient.
The focus of this discussion was to understand the specific security measures implemented in Quanscient Allsolve and how these contribute to its reliability and safety for users.
Asser Lähdemäki, Chief Product Officer & Co-founder
Well, first of all, we use encryption in transit and at rest. That's the basic line for security in everything.
Encryption in transit means that when data is transferred from Allsolve to the customer's computer, it is always encrypted by HTTPS, which is the standard method for traffic encryption over the internet.
At rest means that whenever the data is not in use, it is encrypted. For example, when the simulations are not running, the simulation models are all encrypted.
Then we have user authentication and user permissions built into the system. For the infrastructure, we have strict network firewall rules, and the whole system is isolated from any public networks.
One of the key features of Quanscient Allsolve is custom scripting. This is a big possibility for attackers, and thus we have paid extra attention to isolating the scripting environment so that nothing can be done to access the system from there.
And of course, we also employ continuous backups of the customer data containing production systems.
Data privacy starts from identifying the personally identifiable information, or PII. We store that separately for easy retrieval or removal if the users request it.
Depending on the customer region, in our product we store their personally identifiable information and other data in their region, like EU customers in the EU, and US customers in the US.
For security compliance, we completed the SOC 2 Type 1 audit last December and are currently in the process of starting the SOC 2 Type 2 audit. We are also pursuing the ISO 27001 certification after we get the SOC 2 Type 2 certification, as it’s more widely accepted in the EU region.
We use automated scans for our software dependencies both in our code repositories and the build system images. These are scanned daily, and fixes to the found threats are fixed based on the severity of the find. Critical issues are fixed as soon as possible and released as hotfixes to production.
High-severity vulnerabilities are fixed on a case-by-case basis. For intrusion detection, we use AWS-provided tools to monitor all kinds of events in the cloud infrastructure, automatically detect anomalies in the access to the system, and receive automated notifications about those.
All of these logs used for detection are stored separately and protected so they can’t be tampered with. They are also stored for a minimum of a year so we can trace back any incidents if they are found later.
We use the traditional username and password method for authentication, which is technically based on the OAuth-style authorization scheme.
The passwords are required to be of certain strength. We have a method of measuring the entropy of the password, which is kind of similar to the strength of the password. This means we automatically check that the password is long enough and has enough different kinds of characters from different character sets.
In addition to the username and password, the user can use standard two-factor authentication using a time-based one-time password.
Lastly, the authorization tokens are encrypted and verified with each call, and the encryption keys are rotated regularly, meaning that even if some token is stolen, they will go stale very quickly so they cannot be stored for later access attempts.
As previously mentioned, we use HTTPS with TLS version two or newer with a restricted set of secure ciphers, and we also update our SSL certificate regularly.
At rest, the data is encrypted using a key management system where the encryption key is stored in a separate place and is never given to the application. All encryption and decryption is done via an API.
First, we automatically scan for vulnerabilities in our software dependencies and update any critical issues, fixing those. Then, one more basic thing is that code review is required, so no code can be deployed even to the testing environment without somebody else taking a look.
We have a wide variety of automated tests on many levels, like integration tests, unit tests, and end-to-end tests that are run automatically. This ensures that no unauthorized access is possible, even after changes, not by mistake or by possible malicious code.
We also perform quarterly automated penetration testing and manual penetration testing. The first one means that we have some automated tools that we run against the system and it produces findings if there are any.
The second one means that we ourselves go through the system trying to break it, and we also employ consultants for this kind of work.
It all starts with finding out what the needs are in the market. Based on this analysis, we build our roadmaps. Customer feedback, competitor analysis, our own expertise, and intuition all go into this planning.
From the roadmap, selected features are picked into the development team's backlogs, and then the features are picked from the backlog to be worked on regularly by the team.
When a feature is ready, a pull request is made to our version control system. Then the code review occurs, and possible fixes are made if there are any findings in the review. The branch is then merged, and our automated continuous deployment system deploys the new feature to our testing environment.
That is the first stage, the testing environment. Then the next stage is the release candidate, which we call the staging release.
The feature gets picked in the next staging release and then gets deployed automatically to our staging environment, which is basically a full copy with the same configuration as a production system instance, except that there is no public access for external users there.
The final quality assurance is done there by our application engineering team, checking that the new features work and old things are not broken.
After this, if there are any things to fix, those are fixed and incorporated into the staging release, which is then promoted to a production release which, after setting up, gets automatically deployed to our production environments.
When we make our roadmaps, we take into account the user feedback that we have received. Whenever we receive user feedback after a trial or during an ongoing project, we go through the feedback with the team and discuss it.
If needed, we arrange an interview with our customers to ask for more details. Based on all the other things in the pipeline and the roadmap, we then pick relevant features and later on choose the schedule for those features.
Not everything that we receive in user feedback gets immediately into the roadmap, but all feedback is taken into account and definitely not forgotten.
First of all, the current permission system for users is rather high-level, so we will increase the granularity of the permission system in the future to allow more flexibility in choosing who can do what in the system.
Regarding customer isolation for enterprise customers, we have the possibility to deploy to their own private cloud with custom pricing. This allows them to control their own cloud while we maintain Quanscient Allsolve for them.
One thing that's always crucial to keep an eye on is scripting security, which is under special scrutiny for us.
Additionally, we currently don't have the possibility to manage user sessions from the UI, but we will in the future add the possibility to see your active sessions and the possibility to close those sessions in case there is some access that you are not sure if it's your legitimate access.
Other than that, there are no big features coming in, but of course, security is always part of every consideration, and it's a process that never ends. As we find out new things, we make them more secure.