GAMS Engine is a network facing application. Therefore, security is of utmost importance to us and we take it very seriously. The following chapter describes some of the measures we take to prevent an attacker from obtaining access to your data.

General

GAMS Engine consists of several containerized microservices that communicate with each other via message queues (a detailed description of the architecture and all components can be found here). This makes the system extremely flexible, as different services can be scaled up or down depending on the use case and workload. But this design also has several advantages from a security perspective: Due to the decentralized nature of the system, compromising a particular component/service does not mean compromising the entire system. The capabilities/permissions of each service are limited to what the service actually needs (principle of least privilege). This makes it more difficult for an attacker, as multiple vulnerabilities have to be chained together to compromise the entire system.

It should also be noted that most GAMS Engine endpoints require authorization. This means that an attacker must first obtain credentials before interacting with most of the system. There are very few endpoints (such as requesting version and configuration information) that do not require authentication, and these endpoints do not accept user input. Thus, the attack surface for an unauthorized attacker is very limited.

Running untrusted GAMS code

An obvious challenge in designing GAMS Engine was to allow users to execute arbitrary code in a sandboxed environment. How does Engine achieve this sandbox? The answer is to use the Linux kernel: a user with low privileges is created under which GAMS is run. In addition, all user-supplied files (model data and additional data) are edited (extracted/packed) by this user with low privileges to prevent multiple attacks involving malicious zip files. Furthermore, in Engine SaaS and outside instance pools, a new pod is created for each job. This results in another level of isolation. We also removed all SUID binaries from the worker container to further reduce the attack surface.

All user data on Engine SaaS is encrypted at rest using the industry-standard AES-256 algorithm.

User passwords are stored hashed, salted and stretched using the PKDF2 + SHA256 algorithm and 260 000 iterations. This makes it virtually impossible for an attacker who has gained access to the GAMS Engine database to obtain the user passwords in plain-text.

Every code change is peer reviewed by our experienced developers before it is merged to the main branch. This includes a thorough review in terms of security. In addition, existing code and application logic are frequently re-evaluated and discussed. To be able to do this, our developers constantly keep up to date with the latest developments in the Infosec community regarding new vulnerabilities as well as new strategies to attack software. This includes regular informal penetration testing by our developers on our development servers.

In addition to manual reviews, all of our code is tested as part of our continuous integration pipelines using multiple static (SAST) and dynamic (DAST) application security testing tools. We also use automated tools to test all of our third-party dependencies for known vulnerabilities (Software Composition Analysis).

Every component of GAMS Engine logs any events in detail on the standard output. Logs can not be changed or deleted by any GAMS Engine user (not even administrators). We recommend that you save and monitor these logs.

If a vulnerability is discovered either by us or by an external party (see here if you have found a vulnerability and are not sure how to contact us), it will be given the highest priority and addressed immediately. Our automated CI/CD pipelines allow us to build, test and publish a new release within minutes. In the case of high severity security updates, we will contact all customers and advise them to update their systems immediately.

With GAMS Engine SaaS, our engineers take care of running and monitoring daily operations. Note that with on-premise installations, you are responsible for these tasks yourself.

Our GAMS Engine SaaS cluster is configured to enforce all communication via HTTPS (TLS 1.2). All components of GAMS Engine SaaS run in their own logically isolated virtual network (AWS VPC). Each component is protected by virtual firewalls to ensure that the respective component can only reach the components with which it needs to communicate (principle of least privilege).

Our cluster runs on AWS EKS, a managed Kubernetes service with control plane nodes running across three availability zones. All components of GAMS Engine are self-healing, i.e. if one of the components crashes, it is automatically restarted. Important components such as the API server are also run redundantly. In addition, if a node in the cluster fails, a new node is automatically brought up and resources are moved to that new node. We aim for 99.9% system availability, meaning that all API endpoints are available and functioning as expected for at least 99.9% of the total hours in a month.

All user activity on our Engine SaaS clusters is constantly monitored, and automatic alerts are sent to our engineers in case of anomalies. We use automated tools to collect and store all logs, so we can quickly find out what caused these alerts. In addition, we routinely scan the logs for unusual activity that may not be caught by one of our automated alerts.

We create daily backups of all databases. Backups are encrypted (AES-256) and kept for at least 30 days.

All software is updated on a regular basis. This applies to GAMS Engine (which includes GAMS) as well as the Linux kernel, Kubernetes, containerd etc.