The Delft-FEWS software historically was most commonly installed on-premise at the customer site on servers that were not directly connected to the internet. Nowadays, there are also more and more Delft-FEWS applications that are being deployed in the cloud. This means security standards and guidelines have become more critical than ever before. The Delft-FEWS runs on top of a stack of components like 3rd party components, databases, Tomcat and an embedded JRE. It is the primary responsibility of the customer to apply the latest security fixes to these products. The role of Deltares is to supply guidelines and facilitate security best practices where possible. Deltares maintains a separate section of the WIKI especially for system and database administrators. To view these pages, personal credentials can be supplied. These pages contain highly detailed information for installing and upgrading Delft-FEWS, amongst others about security aspects. For the near future it is foreseen that also managed services from cloud providers (e.g. Tomcat, database) can be applied. All Delft-FEWS developers are security aware and evaluate the existing and potential vulnerabilities on a regular basis. Together with our colleagues from our ICT department they meet regularly to discuss (potential) improvements for each Delft-FEWS release.
Tomcat
Tomcat (required for the deployment of the Admin Interface) is installed separately (by the organization). Deltares indicates which version of tomcat is compatible with / required for which version of Delft-FEWS. All security related aspects available in Tomcat can be applied and are under the responsibility of the organization.
JRE/Java
In several components of Delft-FEWS a (stripped down) version of Java/JRE (Java Runtime Environment) is embedded. This JRE folder is a recognizable and standard part of the Delft-FEWS binary package for Operator Clients and Forecasting Shell Servers. This means that Deltares delivers an optimized (and minimal) Java Runtime Edition based on Amazon Corretto's series. This so-called base-build can be updated if required. Deltares releases new base-builds if required. Since the JRE folder is recognizable within the Delft-FEWS binaries, organizations may decide to replace this folder with another (compatible) version of the JRE but could originate from a different provider (e.g. Oracle Sun).
Local databases (Operator Client, Stand Alone)
In recent versions of Delft-FEWS there is no need for a local database (datastore) for an Operator Client (OC) in a client-server environment. Although it is still possible to have a 'fully synchronized' (local) database in an OC or to create a 'replicate' of the central database to continue working as a standalone (SA). There are two data formats available: Derby or Firebird. These are just local files (just like any other file on the file system) and they do not require any software installed for managing it. The Delft-FEWS Operator Client or Stand Alone application just reads from and writes to this database format. This mechanism cannot be used as a ‘hub’ to enter other server side components.
Central Database access
As indicated in the Delft-FEWS hardware and software requirements page, Delft-FEWS can be equipped with one of the three brands of central databases: Oracle, MS SQLServer or PostgreSQL. Access to the central database is required for several Delft-FEWS servers side components . These components are normally located behind the organization's firewall (same network) or in the secure domain of a data centre or cloud provider. Operator client access to this database is also required, but when set-up from 'outside' the organization's network, a https (proxy) server (including IP whitelisting) should be in between. Deltares can provide this.
Installation and configuration aspects
With the installation of Delft-FEWS server side components security settings can and must be applied. The installation pages makes the system/database administrator aware of this. A few examples are:
- The Delft-FEWS binaries folder is read-only.
- Forecasting Shell Servers (FSS) should have limited permissions (rights). Only write access within their own directory.
- Only provide access to the data feed shared folders for FSSs
- The account for installing should be different than the account running processes
- When applying other simulation models, make sure the executables and other libraries have only permission to run locally.
- When using the optional JCEF browser, white-listing is used to grant access to webpages.
