General Enterprise Architecture Principles :

• Use open standards, open data, open source and open innovation
• Apply simplicity in design : Can we achieve the same result with less integrations, less data, less components, more simple architecture
• Security by design : Security is a key priority within Port of Antwerp-Bruges and must be taken into account from the start in all design processes
• Data Protection by design & by default : In order to adhere to the (legal) requirements of data protection (cfr. Privacy/GDPR) & avoid non-conformities, warnings, incorrect incident mgt., fines, reputation damage etc. DPbD & DPbD is to be applied.

1. Software requirements

1.1 Applications

1.1.1 Extra os specific native apps to be avoided, responsive web ui recommended over all devices and screen form factors.

1.1.2 End-user Interface should be available in Dutch ( preferred ) or English language

1.1.3 At least 2 environments (TEST/PROD) should be available

1.1.4 Licensing and support models should be clear, transparent and predictable

1.2 Platforms ( managed by Port of Antwerp-Bruges ) :

1.2.1 The following deployment platforms are available

• VMware
• On premises cloud based LOKI (Linux-OpenStack-Kubernetes Infrastructure)
• Microsoft Azure is the preferred public cloud provider

Deployments should be Container based

1.3 SaaS-specific

1.3.1 Datacenters should be located within Europe

1.3.2 email services within the application on behalf of Port of Antwerp-Bruges should always use a subdomain ( e.g. @mail.portofantwerpbruges.com ) - SPF en DKIM and DMARC standards should be followed

1.3.3 If the SaaS-solution should use a *.portofantwerpbruges.com subdomain, necessary certificates should be provided ( e.g. https://letsencrypt.org ) and maintained by the SaaS-provider ( Port of Antwerp-Bruges will handle DNS-registration )

1.4 Custom development

1.4.1 source code of any custom development must be provided and stored in gitlab ( Port of Antwerp-Bruges ) and integrated with the existing CI/CD pipelines that result in docker based deployments on Kubernetes

1.4.2 Full DTAP environments are available, usage of at least 3 required

1.4.3 Documentation must contain schematic datamodel

1.5 Documentation

1.5.1 User manual is required

1.5.2 Installation manual is required

1.5.3 Administration manual is required

2. Security requirements :

2.1 Single sign-on authentication is mandatory for all applications with more than 5 end-users or if confidential or privacy related data is involved ( SAMLv2, Oauth or OpenID Connect are supported )

2.2 All traffic between clients and server should be sent over an encrypted connection ( SSL )

2.3 Passwords are hashed and salted before they are stored ( if no SSO is present )

2.4 Sensitive data at rest must be stored encrypted

2.5 No public internet based remote command and control tools are allowed (like LogMeIn, TeamViewer, …)

2.6 Generic user accounts must be avoided as much as possible

2.7 No site-to-site VPN tunnels will be allowed (eg. IPSec)

2.8. Vulnerability management

2.8.1. All systems and applications will be subject to Port of Antwerp-Bruges’s vulnerability scanner. This will happen by either installing an agent or via authenticated scan, whichever is more suitable.

2.8.2. The supplier is responsible for security maintenance of its systems and applications, unless it is agreed that this responsibility will be taken up by Port of Antwerp-Bruges staff. This means that the supplier commits itself to fixing weaponized exploits (= exploits that are being used in malware) within three business days after discovery; fixing vulnerabilities with a CVSS score equal to or greater than 7 two weeks after discovery, and vulnerabilities with a CVSS score below 7 three months after discovery. See also table below:

2.8.3. All internet facing systems and applications will be subject to Port of Antwerp-Bruges’s responsible disclosure and bug bounty program. The supplier commits itself to working together with Port of Antwerp-Bruges and the security researcher community to remediate security weaknesses in a timely manner.

2.9. The provision of accounts with administrative privileges must be approved by the CISO. Administrative privileges can be revoked at the discretion of the CISO when those privileges are no longer needed or a violation against the ICT Code of Conduct is detected.

2.10. Always use the principle of least privilige: an installed user application should run within the user ’s security context without the need for admin permissions.

3. Interface requirements :

3.1 Every application should have a restful API-interface available ( fully documented actions and errorcodes ) following guidelines at https://digitalspecs.portofantwerp.com/api-guidelines and all inbound en outbound integrations should be handled by API’s

3.2 In case of xml-based data exchange an xsd-file ( XML Schema Definition ) should be provided

4. Hardware installation requirements :

4.1 All server hardware must be 19” rackmountable and secured with M6 nuts & bolts. (No shelfs)

4.2 Server hardware should be equipped with dual power supply (feed A, feed B).

4.3 For optimal cooling, front to back airflow is recommended.

4.4 All network cables must be bundled with hook-and-loop fasteners (tie-wraps are not allowed)

5. Network requirements :

5.1 All network devices must be compliant with 100/1000Mbps autosensing full-duplex RJ45 ethernet ports

5.2 Network Access Control will be enforced. Device must be compliant with 802.1x authentication method (kerberos / username-password / certificate) or fallback to MAC-based to gain access.

5.3 Use of central DHCP and DNS services are preferred.

5.4 Out-of-band interface (power on / power off / console) is highly recommended

5.5 All devices are subject to periodic vulnerability scans. Exploitable vulnerabilities must be fixed immediately.

5.6 All wireless devices should be either WiFi or LoRa compliant. WiFi devices must be compliant with at least 802.11agn.

5.7 The introduction of a new wireless technology is only allowed if the requirements cannot be met by WiFi or LoRa. If a new technology is needed, it should be standards compliant and proven not to interfere with WiFi or LoRa. The implementation has to be open for (future) use by any product compliant to the same standard. Implemention is subject to approval of POAB.

6. Fysical requirements :

See fysical reqs

7. Machine learning application requirements :

7.1 Software and framework requirements

7.1.1 Python is the preferred programming language

7.1.2 Adhere to the PEP-8 standard

7.1.3 For deep neural networks, use either the Tensorflow or Pytorch framework

7.1.4 Use Docker as containerization framework and Docker Compose as container orchestration framework

7.1.5 Azure is the preferred cloud platform

7.2 Model requirements

7.2.1 Special attention should be given to avoiding model bias resulting in discrimination against groups of people

7.2.2 Respect privacy law, do not infer sensitive information from non-sensitive data

7.2.3 Effort should be made to make the model as interpretable as possible

7.3 Application architecture requirements

7.3.1 Application should consist of one or more services, each defined by a Docker image

7.3.2 If possible the model should be placed in a separate service (‘inference-service’) and communicate with one or more separate services for pre- and postprocessing

7.3.3 For deep neural networks use an official serving image:

• Torchserve for Pytorch models
• TensorFlow Serving for Tensorflow models

7.3.4 Communication between services should happen via a fully documented restful API-interface

7.3.5 Application should be available via a fully documented restful API-interface

7.3.6 Services should be as lean as possible

7.3.7 Used python packages should be specified with their version, for example in a requirements.txt file

7.3.8 All artefacts and input files needed to recreate the Docker images should be delivered, including Dockerfiles and model artefacts

7.4 Model reproducibility requirements

7.4.1 Model reproducibility should be ensured by providing both a model training pipeline and the training data

7.4.2 The model training pipeline should run in a Docker container to ensure reproducibility  

7.5 Application input/output requirements

7.5.1 Provide an overview specifying expected file formats of the project inputs and outputs

7.5.1 In case of structured data, provide a data model describing the tables schemes (column name and data types) and the relationships between tables

7.5.1 Use Unix timestamps in seconds or milliseconds

7.5.1 Provide geographical coordinates as longitude and latitude in decimal degrees

7.6 Documentation requirements

7.6.1 A user manual is required

7.6.2 A high level schema of the application architecture is required

7.6.3 General description of the application is required

Actual Port of Antwerp-Bruges standards :