AMOS Security Handbook

Version: 22.6
Date: 01.06.2022
© 2022 Swiss Aviation Software Ltd.
 2/38

AMOS Security Handbook

What's new in the AMOS 22.6 Security Handbook

Introduction
Who should read this
AMOS Server Installation
Server Environment
Limiting the OS user
Content filter for Web-Drive
Intrusion detection
Configuration
Configuration Options
Monitoring
Secure Communication
AMOS Communication
Introduction
Who should read this
Setting up the SSL/TLS server certificate
Running AMOS on a registered domain name and buying an official globally trusted
certificate
Setting up and running your own enterprise certificate authority
Using self-signed SSL Certificates
Creating a self-signed certificate for AMOS SSL/TLS
Prepare certificate renewal for AMOS SSL/TLS
Importing an externally issued SSL/TLS server certificate into the keystore
Configuring the AMOS Server
Define a HTTPS Port
Client Installer
Define authentication level for client to server connections
Configuring the AMOS Client
Upgrading AMOS clients to SSL/TLS
Verifying your secure connection
Setting up client certificates
Configuring web services
Incoming web services
Outgoing web services
Securing webservices and interfaces
Securing Cookies
Authentication
Password based authentication
LDAP Integration / Kerberos
Session Management
IP Whitelist
Deactivating security critical features
Managing AMOS user access rights
Logging & Monitoring
AMOS Control Center
Monitoring login activity
Server log files

SWISS-AS.COM
 3/38

DBMS Hardening
Generic DB hardening Tips
Document Information

What's new in the AMOS 22.6 Security Handbook

Changes Chapter

New critical features than can be deactivated Deactivating security critical features

Introduction
Information is meanwhile the company's highest asset. Information needs to be protected just like any other asset.
This security handbook is providing a compact information of the most important security settings for your AMOS
installation. This guide is not meant to replace any customer IT security regulations but to help you to adapt your
AMOS installations configuration to gain the highest possible security for your deployment scenario.
We continuously extend and adapt the functionality of AMOS to match the latest trends for IT security and
monitoring. It is an addition to the other documentation that already exists like the AMOS Administrator handbook,
the AMOS build in help system and additional guides for different topics.

Who should read this

This guide is intended for AMOS administrators, customers security responsibles and IT department. Even if you
are a long term customer, we recommend to read this guide and validate your AMOS installation against the
recommendations and advice that we offer with this document.

SWISS-AS.COM
 4/38

AMOS Server Installation

The following section will explain to you how you can adapt the AMOS server installation to be more secure. Per
default a fresh installed AMOS server is read to be run but many of the following topics will show you how you can
adapt the installation to be more secure. All of these steps are optional but we highly recommend to implement as
many of these as possible to have a secure AMOS environment.

Server Environment
The AMOS server should be installed on a dedicated machine. All additional OS services that are not needed
should be deactivated. We highly suggest to move other services like mail server, ftp server to other services to
dedicated machines and not to run these on the same machine as the AMOS application server.
For performance and security reasons you could run the database on the same machine as the AMOS application
server.

Limiting the OS user

As outlined in the installation guide the AMOS application server should be run with an own operating system user
with limited access rights. This user should not be shared for any other service. It is not allowed to run AMOS with a
"root user" account and the AMOS specific OS user should be limited to the necessary access rights.

For AMOS 19.6 and earlier versions and when running in the Windows operating system, the application
server needs to run with a user which is part of the administrator group. This is needed to correctly update
the AMOS service after a patch installation.

This requirement is not necessary anymore since AMOS 19.12.

As a minimum requirement AMOS needs access to the file system to install patches, produce and store temporary
files and of course write access to the webdrive folder. We highlight here the filesystem areas that are needed by
AMOS. This can be used as a starting point to restrict the file access for the AMOS OS user. For release change
and patch installation AMOS needs to have full write access to its installation folder and its parent folder, because
during a release change the old installation is copied to a backup folder. A typical AMOS installation may look like
this on a Linux server: /applic/amos_prod/

AMOS needs to create for processing temporary files so it needs access to a temp folder: AMOS uses here per
default the operating system temp directory or (user temp directory on Windows) and creates one sub folder in
there for its temporary files. For example: /tmp/amos

The webdrive folder. This is an area of the file system that is used by AMOS as a shared network drive. AMOS
needs to have full write access to this area. For example: /webdrive/webdrive_prod/

Additionally you may define data exchange folders for AMOS were the server can write export files or generate
server side reports. For example: /applic/data_prod/

SWISS-AS.COM
 5/38

Summary of the minimal file access

AMOS installation folder and its parent folder

The system "temp" folder
The webdrive
Depending on your requirements a data folder to store reports and interface files

Content filter for Web-Drive

For security reasons, a default filename extensions whitelist (<AMOS_SERVER>/data/defaults
/fileextensionswhitelist.txt) has been defined which allows only specific files to be uploaded to the Web-
Drive (APN: 62). File types that are considered harmful are not in this list.

AMOS admin can disable the whitelist usage by toggling ALLOW_ANY_FILE_EXTENSIONS value to true, see Deac
tivating security critical features.

The default behavior can be overridden to personalize and extend this list by adding specific file extensions. Do as
follows:

1. Copy the default filename extensions whitelist to cfg/fileextensionswhitelist.cfg.

2. Edit the file cfg/fileextensionswhitelist.cfg and add your file extensions separated by the
semicolon [;] character.

The default filename extensions whitelist must NOT be modified and act as a fallback when the custom
filename extensions whitelist cfg/fileextensionswhitelist.cfg is not present.

Email attachment file chooser is now checking against this whitelist when adding files.
WebDrive actions are also checking against this whitelist when trying to upload or rename files.

Intrusion detection
Intrusion detection means that the AMOS server can proactively detect irregular requests or usage of the system e.
g. by a modified or hacked AMOS client, an access request to an APN outside of the access rights of that user or
tampering on the AMOS client server communication.
In this cases AMOS fires an alert which is visible as notification within the AMOS Control Center (APN: 2137) and
can proactively inform administrators per email and log these occurrences.
The advantage of this system is that even unsuccessful hacking attempts are detected and reported and the
security team can react directly on such events to prevent further hacking attempts.

Swiss-AS highly recommended to use this feature as one of the main pillars to secure the operation of
AMOS.

Configuration

SWISS-AS.COM
 6/38

The intrusion detection is configured via the configuration file intrusion.cfg located in the cfg directory of the
AMOS server. If the file does not exist, use a text editor to create it.

The content is looking as following:

# Activate logging to have log entries in the normal AMOS log files.
log=true

# Activate alerting per email

[email protected]

# Disable user if intrusion is detected

disableUser=false

Please note that for security reasons, the intrusion alert can be only configured manually in the configuration file on
the AMOS server. It cannot be changed from within the AMOS configuration tools to prevent that a potential
attacker deactivates the feature from within AMOS. If you do not have direct access to the operating system get in
contact with your IT team to perform the necessary configuration.

The intrusion.cfg file must not be modifiable by the amos user used when running the AMOS server. If it is
modifiable, you will receive a notification in the AMOS Control Centre (APN: 2137).

Example of acceptable file permissions on a Linux system:

-rw-r--r-- admin admin 23 Apr 18 8:55 intrusion.cfg

In this situation, the admin user can modify the file, however the amos user cannot.

Configuration Options

These settings are independent of each other. You can log and email or only activate the email feature.

A server restart is not necessary when making changes to this file.

Parameter Values Default Configuration

Value

log true true All detected irregularities are logged in the AMOS server log files as warnings.

false

mailto <email none Email address used in the case of detected events
addres
s> The events are sent to the provided email address. We recommend to configure
this to alert the IT security team of your company.

notification true true Intrusion detection will be reported in the AMOS Control Center (APN: 2137) as
notifications.
false

resetAmo true true If this is activated and a modified or corrupt client is detect you can force the
sClient AMOS client to reset itself and re-download all files from the server.
false This should then fix the corrupt client reliable.

SWISS-AS.COM
 7/38

blockTaint true true If this option is activated and a modified client is detected this will block further
edSession actions from that client.
false This prevents reliable that further actions are executed from a hacked or modified
client.

allowVersi true false Per default a client with an incorrect version will be blocked at the login and
onMismat rejected with a proper message.
ch false
If allowVersionMismatch is set to true, a client with a wrong version can
connect, but is then subject to other intrusion detection mechanisms. So it will
only be useful when disableUser and blockTaintedSession are both set to
false.

Monitoring

Depending on your settings above you may receive "Intrusion detection" notifications in the AMOS Control Center.

Additionally you may see a message like this in your server log files
2018-06-21T11:26:03.650 WARNING USER1 * via client1.example.com Intrusion
alert from AMOS client 10.0.0.19 session: USER1 / 39cd1fc9-efc -> Potentially
tainted client logged in ...

Please inform Swiss-AS or your responsible IT security team to analyze the cause of these events.

Secure Communication

AMOS Communication

Introduction

AMOS is designed as client - server system. An important part of this architecture is secure and fast communication
between the AMOS server and all connected clients. AMOS uses a efficient protocol with is based on HTTP. With
this technology AMOS fits well into the IT landscape that is dominated by the internet and its protocols. One
important aspect of the communication is to protect it against manipulation and to keep the transmitted data
confidential. The standard that is used to secure any kind of web-protocols is SSL/TLS. You can utilize SSL/TLS to
secure the AMOS client server communication and all other interfaces that are connected to AMOS. This
documentation will guide you to configure AMOS to use SSL/TLS for all communication.

SWISS-AS.COM
 8/38

We highly recommend to run AMOS solely via SSL/TLS encrypted HTTPS and not via plain HTTP.

Once SSL/TLS is activated we recommend to close the HTTP port of AMOS in the firewall. This ensures
reliable that all traffic from / to the AMOS server is protected.

Who should read this

This guide is intended for AMOS administrators, customers security responsibles and IT department.

Setting up the SSL/TLS server certificate

The first step is to setup a certificate that will be used to secure the communication. This certificate will be stored in
the AMOS Keystore (APN: 1452) and will be used to encrypt all communication from and to the AMOS server.

You have multiple options here all with advantages and disadvantages. This is a fundamental decision and you
should choose carefully the best option for you.

Running AMOS on a registered domain name and buying an official globally trusted certificate

With this option you will run AMOS on a host name with belongs to an official domain name or sub-domain of you
company and then you buy a certificate from one of the globally trusted certificate authorities (CA) like Globalsign,
Digicert ...
The advantage of this approach is that the certificate will be trusted by all third party software for example interfaces
and the web-browser when you access the AMOS web-server user interface or AMOSmobile. All AMOS clients
need then to be configured to connect the AMOS server via this host name.
According to security best practices, official certificates are issued by the CAs only for a duration of 1 or 2 years, so
you need to renew regularly the certificates and roll them out to all AMOS clients. Another problem is that in a
scenario where you have a standby AMOS system you may run into problems.
In case of fail-over you have to switch the host name to the IP address of the fail-over system.

Pro:

+ Trusted automatically by external software and the web-browsers

+ No additional roll out of certificates needed to connected third party systems
+ Centralized management of certificates

Con:

- More expensive than the 2 other possibilities

- Fallback / standby systems need to run via the same host name

For further information on how to import such an certificate into the AMOS Keystore (APN: 1452) please
consult the online help in AMOS

Setting up and running your own enterprise certificate authority

SWISS-AS.COM
 9/38

Maybe your IT runs already an in-house own certificate authority (CA) to issue certificates. If this is the case this is
the best option to use this to issue also SSL/TLS certificates for AMOS. Ask your IT to issue a certificate and import
that one into the AMOS Keystore. If you do not run yet an in-house CA you may consider to create one, however,
this comes with the costs of procuring, configuring and running your own CA and online certificate status protocol
(OCSP) or Certificate Revocation List (CRL) services.

Pro:

+ Trusted automatically by external software and the web-browsers if your internal root CA certificate is already
rolled out in the company
+ No additional cost if the CA is already in place
+ Centralized management of internal certificates
+ You can freely define your certificate validity time range (Swiss-AS recommends that the certificate validity time
range should not exceed 2 years)

Con:

- Managing an in-house root CA may be complex

For further information on how to import such an certificate into the AMOS Keystore (APN: 1452) please
see the section below "Importing an externally issued SSL/TLS server certificate into the keystore"

Using self-signed SSL Certificates

With this option you create a self signed certificate directly in AMOS and use that one. This is easy to do in the
AMOS Keystore application as outlined below. If you do not run an own in-house root CA and do not want to spend
money on globally trusted certificates you can go for this option.
The downside here is that these certificates will raise security warnings when you want to access the AMOS web
interface, because the web browsers will not trust these self signed certificates per default. You can ask your IT to
distribute these certificates and roll them out into the browsers trust stores to work around this shortcoming. Swiss-
AS recommends to select this option as last alternative.

Pro:

+ Very easy to generate and use out of AMOS

+ No additional cost
+ You can freely define your certificate validity time range

Con:

- No central management of all certificates

- Not trusted per default in web-browsers and external software
- Browsers do not allow local Progressive Web App installations (e.g. AMOSmobile/STORES) with an untrusted
SSL certificate

If you go for this option the following section will explain how to generate a self-signed certificate in AMOS.

Creating a self-signed certificate for AMOS SSL/TLS

Open the AMOS Keystore (APN: 1452). Start the wizard to generate the SSL/TLS server certificate

SWISS-AS.COM
 10/38

Choose to generate a server certificate

SWISS-AS.COM
 11/38

Verify or fill in the requested attributes. Please note that the common name is not important and does not have to
match the hostname of your AMOS server but it is recommended to fill it correctly.

The status of the certificate will be Active or Queued according to two criteria:

the presence or not of an active certificate at the time of creation

the anteriority of the valid-from date

If no active certificate available in the Certificate Area and the chosen validity period is effective on the
creation date, then the state of the certificate will be Active otherwise Queued.

see Prepare certificate renewal for AMOS SSL/TLS

SWISS-AS.COM
 12/38

Finish by choosing a directory to save a certificate copy if you need to roll out the certificate to old clients manually.
New clients will be installed with the certificate included.

SWISS-AS.COM
 13/38

Now you are done and the certificate is stored in AMOS.

Prepare certificate renewal for AMOS SSL/TLS

The main advantage of having a queued certificate is in the perspective of renewal. You may have a lot of already
installed AMOSdesktop clients that use SSL/TLS and the currently active certificate will expire soon. A few weeks
/days before the end of the valid-to date of the currently active certificate, you can create a new certificate that will
receive a status of Queued. You just need to wait for a period before activating it while it will deploy silently. With
the automated update mechanism, each client will then have his truststore automatically updated with the active
and queued certificates. And thus, the client will be able to use the renewed certificate and securely connects once
you will activate it.

Open the AMOS Keystore (APN: 1452). Start the wizard to generate the SSL/TLS server certificate

SWISS-AS.COM
 14/38

Choose to generate a server certificate

SWISS-AS.COM
 15/38

Verify or fill in the requested attributes. Please note that the common name is not important and does not have to
match the hostname of your AMOS server but it is recommended to fill it correctly.

If a certificate is currently active, it will detect and display this message.

Finish by choosing a directory to save a certificate copy if you need to roll out the certificate to old clients manually.
New clients will be installed with the certificate included.

Then, you will have a Queued certificate.

SWISS-AS.COM
 16/38

After waiting for a period, all AMOSdesktop clients that have restarted during the period will have their trust store
updated with both active and queued certificates.

Then, you can decide to activate the queued certificate. Select the queued certificate, click on Activate Certificate
and Save.

SWISS-AS.COM
 17/38

The current in use certificate is then replaced by the queued one and its status will be changed to History.

SWISS-AS.COM
 18/38

The activation effect will occur once the AMOS server restarts.

Importing an externally issued SSL/TLS server certificate into the keystore

Open in AMOS the AMOS Keystore (APN: 1452) and navigate there to the keystore area amos.server.certificate.
ssl

Here you can now select in the Import drop down menu "Import Certificate and Key". In the file chooser that is
then shown select the certificate file that you have received from your CA. AMOS supports here .p12 or .pfx files.
If the certificate file is protected by a password enter that one too.

SWISS-AS.COM
 19/38

Confirm this and the certificate and its corresponding private key are imported into the keystore area. The area
should now contain the new certificate and the checkbox "Private Key Available" should indicate that the
corresponding private key was also successfully imported.

For further information on how to import such an certificate into the AMOS Keystore (APN: 1452) please
consult the online help in AMOS

Configuring the AMOS Server

Define a HTTPS Port

For using SSL/TLS connections to the AMOS server (either from the AMOS client of for web services or interfaces),
an HTTPS port needs to be configured. It listens for connections additionally to the standard HTTP port, so both
ways of connecting can be used in parallel.

This setup needs to be done directly on the AMOS server operating system level. Login to the AMOS server via
SSH and run there the amos_server_config command line tool.
[amos@amosdb1 ~]$ cd /applic/amos_prod/scripts/
[amos@amosdb1 scripts]$ ./amos_config_server

SWISS-AS.COM
 20/38

The recommended HTTPS Port for AMOS is 5081. Save the settings and exit the configuration tool.

For these settings to take effect you need to restart the AMOS server.

You can test that AMOS SSL/TLS communication is working by entering the AMOS server address into
your web browser to access the web interface. If that one is working than and showing a secured
connection then SSL/TLS is setup correctly.
Please note that when you are using a self signed certificate the web browser may not display the web
page and issue a security warning because of the untrusted certificate. This is expected and normal. In that
case you can add an exception to your web browser to trust the AMOS server certificate.

Client Installer

After your AMOS server is setup and ready to use SSL/TLS you may now want to regenerate the AMOS client
installers to activate per default SSL/TLS for the installed AMOS clients. The easiest way to do this is via the AMOS
web server. Open the AMOS web UI in your browser and login.

Then navigate to AMOSdesktop AMOSdesktop Client Deployment and generate the installer packages from there.

Make sure that the "Configure SSL/TLS connection as default" checkbox is selected

SWISS-AS.COM
 21/38

When you press now the "Rebuild" button the client installers will be generated. After some time they will show up
in the table on this page.

Alternatively you can generate the client installers from within AMOSdesktop. Open the Configure Server (APN:
10) and select there the section Generate Client Installer. There you can configure some default settings and trigger
the rebuild of the installer packages.
Make sure to select the checkbox "Use TLS secure Connection".

Define authentication level for client to server connections

The above steps define the certificate setup on the server side but it is also possible to issue a certificate on the
client side to authenticate the AMOS clients. Three different policies can be used for accepting the client’s
certificate on the server:

“certificate needed” – the client must present a valid certificate to the server. This certificate is checked for
authentication and has to be known by the server (TODO see the chapter about client and webservice
configuration for publishing the clients certificate)

SWISS-AS.COM
 22/38

“certificate wanted” – the client can present a valid certificate to the server, but can also send no certificate. If
a certificate is send, it is checked for authentication and has to be known by the server (TODO see the
chapter about client and webservice configuration for publishing the clients certificate).

“no certificate” – client certificate is not checked for authentication.

The policy can be defined in the AMOS module Configure Server (APN: 10), on the “Application Server” panel -
you can find an entry named "SSL connection" with the list of available policies.

Configuring the AMOS Client

Upgrading AMOS clients to SSL/TLS

If you switch from HTTP to HTTPS communication you may have a lot of already installed AMOSdesktop clients
that are not prepared to use SSL/TLS. These clients need to be migrated to use SSL/TLS now. You have to
completely remove the old clients and reinstall them.

Verifying your secure connection

In AMOSdesktop you can verify your connection is secure by looking at the small connection icon in the lower right
corner of the status bar. There you will see a small lock icon. If that one is there the communication is encrypted
and secured.

When you click the icon and select "Connection Info" you will see the details of your connection.

SWISS-AS.COM
 23/38

Setting up client certificates

In case the client should connect via SSL/TLS, and the authentication level on the server is configured to at least
“certificate needed” or “certificate wanted” (see Define authentication level for client to server connections abov
e for configuring this), you should create the following certificates in the AMOS Keystore:

amos.client.certificate.ssl – the AMOS client’s default certificate and private key. Can be used by each
user.
amos.user.<user_sign>.ssl – Client SSL/TLS certificate for a specific user – the client tries to use this one
first for the logged in user. If not found, the default certificate is used.

The certificates have to be published to the clients using the SSL/TLS connections – they can’t be read from
database as we have no DB access during establishing the first SSL/TLS connection.

The default client certificate:

is copied to the client's cfg directory as amos_keystore.p12 automatically by the installer in case a new
client is generated
Can be exported together with the private key from the AMOS Keystore area “amos.client.certificate.ssl” as
"amos_keystore.p12" and copied to the AMOSclient`s “/cfg” directory afterwards. This should be done via the
AMOS Keystore wizard as a password is set
in the background which is also taken for reading the file during the client start.

The user-specific certificates:

SWISS-AS.COM
 24/38

Are also copied to the correct directory automatically by the installer when a new AMOSclient is generated.
Can be exported and copied to the user’s AMOSclient “/cfg” folder as “amos_user_keystore.p12”. This
should also be done by using the wizard. The created file contains all SSL / TLS certificates for the users
selected in the wizard. During building of the connection, AMOS selects the correct one for the logged in
user.

The password used to encrypt / decrypt those generated files is generated automatically in the code and stored in
the server sided configuration. The password can be changed using the server configuration tool. As this password
cannot be read in "clear" text anywhere, the user must use the AMOS Keystore wizard to export the certificates.

Configuring web services

SSL/TLS connections can also be used for web services in AMOS. Therefore two types of web services are to be
distinguished:

“Incoming” web services: AMOS acts as a server in this case, a client is connecting to the AMOS server in
order to send data to be imported or request data to be exported.
“Outgoing” web services: AMOS acts as the client in this case, i.e. contacts another server with a web
service request.

For both types of webservices an SSL/TLS connection is used in case a HTTPS URL and the SSL/TLS port is
configured. Additionally to URL and port, the authentication can be configured by assigning “AMOS web users” to
the web service. Web users are administrated in Configure Server (APN 10, tab “Webserver”), and can have a
login and a certificate, which are used for authentication. For each web service you can assign web users and
choose which of these data should be used for authentication in that service.

Incoming web services

Incoming web services can be configured in the module Configure Server (APN: 10) or in the responsible modules
(e.g. AIM Webservice Configuration, APN: 1470).

Wherever an incoming web service can be configured, a panel is displayed to the user to allow the configuration of
the authentication handling for this web service (see AIM Webservice Configuration for example). On this panel it
is possible to assign web users to a web service: for incoming web services the access can be granted to multiple
users, for each of them it can be defined if the user should authenticate by login and password (“Basic
Authentication”) or by certificate. If password and certificate authentication are selected for a user, the user gets
access by sending just one of the data (it is interpreted as certificate OR password authentication in that case).

In Configure Server (APN: 10) all incoming web services is listed on the tab “Webserver”. Here you can find the
predefined system web services and additionally the incoming web services which have been configured to use
web users for authentication. Here you can also change configurations of the listed web services: by selecting a
service in the table, a list of assigned web users is displayed on the right side and can be edited. By switching to the
tab Web User Administration you get a complete overview of available web users, which also can be edited.

Outgoing web services

Outgoing web services can only be configured in the responsible modules (e.g. AIM Configuration, APN: 1404).

Wherever an outgoing web service can be configured, a panel is displayed to the user to allow the configuration of
the authentication handling: the web user can be selected and also if the user should authenticate himself with the
password or with the certificate. In this case only one single web user can be assigned to the web service, as the

SWISS-AS.COM
 25/38

connection is opened from AMOS this time, and it has to be clear which certificate/login should be set to the
connection as client authentication attribute.

Furthermore you can define if the certificate and/or the login data of the chosen web user should be used for client
authentication. For the server authentication the “Server Certificate” can be set, i.e. an area of the AMOS Keystore
(APN: 1452) can be selected, which contains the public certificate of the server which should be connected.

Securing webservices and interfaces

TLS or similar transport layer security must be used for all other outgoing and incoming communication like:
connections to mail servers, LDAP server, FTP server, incoming or outgoing interfaces and web-services...

Once you have transport layer security in place you should ensure that all services provided by the AMOS server us
authentication and are only used by trusted external system. For each web-service exposed by AMOS you can
setup authentication in

Configure Server (APN: 10). Here you can specify per endpoint the method of authentication. For this you can
assign to an endpoint one or more "Web Users" and for each of them you define the authentication method and
credentials.

Here you can also deactivate unused endpoints.

AMOS currently supports for authentication: Basic Authentication with login and password, Certificate based
authentication or OAuth.

Only the web-services that are absolutely necessary for business purposes must be exposed. Additionally
each exposed end point should be protected with authentication. If this is not setup the web-service will be
open to everyone in the company network.

Please refer to the AMOS online help for further details on how to setup the authentication in this module and all the
provided options.

SWISS-AS.COM
 26/38

Securing Cookies
AMOS can automatically set the secure flag on cookies if it detects that a request was made via HTTPS and not via
HTTP.

However, this is not possible for all cookies. To force the setting of the secure flag on all cookies, the following two
conditions must be met:

1. HTTPS has been configured

2. A system property has been defined as shown below in the cfg/server_parameter.cfg file on the AMOS
server side:
-Dcom.swiss-as.server.force.secure.cookies=true

We recommend setting this system property on all systems. However be aware that if you are running both HTTP
and HTTPS on a system and have this system property set, the cookies will not be accessible when using HTTP.
This will have consequences on the functionality of AMOS, for example it will not be possible to authenticate in the
browser when using HTTP, authentication will only be possible if using HTTPS.

The system property to secure cookies is available for AMOS version 19.12 and later.

Authentication
Once the initial configuration of the server is done it is now time to look at the AMOS internal settings and features
that help you to secure AMOS and to monitor security relevant events.

The next section will highlight these settings starting with the authentication and login to AMOS.
AMOS supports different ways to authenticate. We offer a build-in mechanism to login via username and password,
you can use LDAP to integrate AMOS with your Domain Controller or any other external identity management
system and we offer Kerberos to use your windows logins and single sign on in AMOS.

We highly recommend to use LDAP and connect AMOS to a domain controller whenever possible so that
all passwords are automatically in line with your IT requirements and can be managed centrally by your IT.

Password based authentication

Every user has to login before he can work with AMOS. We provide a set of options that help you to setup secure
logins and to enforce password policies in line with your IT requirements.
The password settings are split into two sections. First we have global settings affecting all users and second we
have a list of settings that can be configured per login. The global password setting can be done in Configure
Server (APN: 10).

SWISS-AS.COM
 27/38

We want to highlight here that AMOS does support for backwards compatibility reasons different Login
Encryption Algorithm. Swiss-as recommends to use PBKDF2 as the algorithm is FIPS-140 compliance. The
other modes will be removed in a future AMOS version.

Per login you can do additional settings in Admin Login (APN: 14) to configure per login which authentication
mechanism is to be used

We suggest to carefully review the security section and adapt the settings to your needs. All options are explained
in the AMOS Help in detail.

LDAP Integration / Kerberos

You can use LDAP to connect AMOS to a external identity management system or the company network domain
controller. In that case AMOS does not store any user passwords in the database and all user authentication is

SWISS-AS.COM
 28/38

performed against this external system.

To make use of LDAP you have to configure first an LDAP server via "Parameter 1000 AUTHENTICATION-
SERVER PATH" in Parameter Setup (APN: 1442). Transport Layer security (TLS) to secure the communication
from AMOS to the LDAP server must be configured.
Via this parameter it is also possible to activate Kerberos single sign on if supported by the company domain
controller. Further detail on how to set this up can be found in the parameter description in AMOS.

Next you have to configure per login the "Authentication" and set it to LDAP.

Once this is done the user can login with his regular Windows password and if Kerberos is activated he is
automatically logged in to AMOS with his current windows credentials. The advantage of this mode is that the
passwords can be managed centrally and the when the password is changed in windows it will be immediately
effective for AMOS too.

Session Management
If a user is inactive for a certain amount if time the session should be closed for resources and security reasons. Via
Configure Server (APN: 10) AMOS can be configure in the way that a session is terminated automatically. Either
the users is logged in for the maximum configured time, or the not performing any action during the configured time.

All times are configured in Hours and Minutes.

The Swiss-AS recommendation is to kill all users after 10 hours logged in and 15 minutes of inactivity.

Additionally it is possible to limit per user if the login is limited to a single session or if more than one session can be
started in parallel. This can be set per login in Admin Login (APN: 14) via the following option

SWISS-AS.COM
 29/38

Depending on the selected option the user will be limited to a single session or to multiple sessions but only from
the same machine. If a user logs in from another machine he will be asked if he wants to terminate the other
session before he can continue to login.

IP Whitelist
You can restrict for a given login to a list of IP addresses. This helps to prevent that a user can login from a different
computer. This can be setup in Admin Login (APN: 14) via the following option

Here you can specify one or more IP addresses or IP subnet entries to bind the login to a given list of computers.

IP whitelisting are not 100% reliable. IP addresses of a device may regularly change (expected or
unexpected) especially if your end users have the right to adjust their network configuration. Moreover, an
attacker may abuse IP whitelisting restriction by sending crafted requests with the whitelisted IP addresses
and then bypassing this protection.

This statement is as well valid for AMOS. All AMOS features that rely on IP address for whitelisting or
blocking are not 100% reliable. These features like Session Mode, External Logins, IP Whitelist... are only
meant as an additional layer of security. For an attacker it might be possible to get around these checks.

Always keep this in mind for your overall security concept. Whenever possible rely on specialized devices
and software for this purpose like firewalls and network segregation.

SWISS-AS.COM
 30/38

Session Locking

When a user wants to lock temporarily his AMOS session he can use the build in feature of AMOS to lock the
session. This can be done on demand via the menu option AMOS Lock Screen. To unlock the session later the
user has to provide the correct password again. Additionally it is possible to configure an auto lock when the AMOS
client is not used for a given time. This can be activated via the menu AMOS Configure Automatic Lock

There you can specify a time of inactivity after which the AMOS session is locked automatically.

Even if this is a useful feature we recommend to setup a Screen Saver and automatic desktop session
locking in your operating system as this protects the whole computer and all other programs from illegal
access not only AMOS.

Monitoring your activity

Additionally a user can configure a desktop widget to display the last login information. Especially if a user logs in
from different devices this helps to detect login reuse or other irregularities for a given login. AMOS comes with a
predefined widget that can be placed on the AMOS desktop and that shows some information about the last login.

Please consult the AMOS help to find out more about how to setup widgets on the AMOS desktop.

Deactivating security critical features

AMOS is very feature rich. Some of these features are comfort features for AMOS administrators but at the same
time these features come with a risk as they allow to directly modify the data on the database circumventing AMOS
business logic validation and security checks. AMOS allows to deactivate these features in case you do not need
them or in case you use AMOS external tools for this purpose. We added the possibility to block security-critical
functionality completely, even for AMOS ADMIN users.

A new configuration file "critical_features.cfg" will be read from the cfg folder of the server directory. If the file
does not exists, is empty, or is missing some of the features, all features have a default value which is applied in
that case. The file should be read-only for the user that starts the AMOS server, it will not be written by the AMOS
server. To enable a specific feature the file has to be edited as normal text and specify a feature property per line
and set it to true.

E.g. if you want to enable arbitrary SQL queries from the client and for reports you add this to the file:

EXECUTE_ANY_QUERY_FROM_CLIENT=true

USER_DEFINED_SQL_DATASOURCES=true

SWISS-AS.COM
 31/38

Changing settings in the critical_features.cfg has an effect on functionality deep inside the AMOS server. Therefore
to put changes into effect, a server restart is required.

This table lists the features that are potentially blocked and their impact (the default value is used if either the file is
not available, or the according critical feature is not set explicitly in the file):

critical feature affected APNs if blocked Default

Value

EXECUTE_AN APN:29 SQL Central true

Y_QUERY_FR
OM_CLIENT SQL SELECT statements cannot be executed

APN:966 Report Designer, APN:1976 DataSource Editor, APN:1907 SQL Editor

user-defined data sources that use a string query will result in an error on the
client

APN:1396 AIM Configuration, APN:1404 AIM Manual Export, APN:1470 AIM

Webservice Configuration,

sql selector model cannot be used on the client

APN:2606 AMOS Scheduler

SQL Tasks cannot be tested on the client and fail with an error
SqlJavaTask, SqlToEmail, SqlToExcel2007Exporter, SqlToHtmlExporter

APN:312 Financial Interfaces, APN:151 Financial Monitoring System, APN:1120 KPI

Analyzer

the APNs will not work and result in errors as they construct arbitrary text queries
to be executed from the client

EXECUTE_AN APN:29 SQL Central true

Y_UPDATE_F
ROM_CLIENT SQL UPDATE statements cannot be executed

EXECUTE_AD APN:29 SQL Central true

MIN_QUERY_
FROM_CLIENT SQL SELECTS via ADMIN connection cannot be executed

EXECUTE_AD APN:29 SQL Central true

MIN_UPDATE
_FROM_CLIE SQL UPDATE via ADMIN connection cannot be executed
NT

SQL_SCHEDU APN:2606 AMOS Scheduler true

LER_TASKS
SqlJavaTask, SqlToEmail, SqlToExcel2007Exporter, SqlToHtmlExporter will fail
even on the server

SWISS-AS.COM
 32/38

POSTSCRIPT APN:2606 AMOS Scheduler true

_SCHEDULER
_TASKS Blocks the execution of any post script actions triggered from scheduler tasks.

AIM_SQL_CO APN:1396 AIM Configuration, APN:1404 AIM Manual Export, APN:1470 AIM true
NFIGURATION Webservice Configuration
_SELECTOR
SQL selector model will fail even on the server

USER_DEFIN APN:966 Report Designer, APN:1976 DataSource Editor, APN:1907 SQL Editor true
ED_SQL_DAT
ASOURCES user-defined data sources will fail on the server

ALLOW_ANY_ APN 62: Web-Drive false

FILE_EXTENS
IONS With this setting you can activate or deactivate the webdrive file extension
whitelist checking.

CHANGE_WE If it is true, the location of the webdrive can be changed in Configure Server (APN: false
BDRIVE_LOC 10)
ATION

EXECUTE_SH If it is false, no query plans can be generated from SQL Central (APN: 29) as it is true
OW_QUERY_ possible to harm connections with this or execute DMLs.
PLAN_FROM_
CLIENT

XSLT_SECUR It enables/disables XSLT secure processing on the server side. true

E_PROCESSI
NG_ENABLED

DEBUG_TOOL It enables / disables the usage of the Debug Tool. false

_ENABLED

EXTERNAL_P If activated, allows to use the External Print Service server side printing. As this is false
RINT_SERVICE done via executing server side scripts, the feature is deactivatable via critical feature.
It is recommended to leave it deactivated if the feature is not used.

SHOW_SERV When an error happens on the server side the error message is displayed on the false
ER_STACK_T client side with a truncated trace. This is for security reasons to hide technical
RACES information. Instead of the full server stack trace we display only an "error token" that
you can then use to search in the server error log.

When you set SHOW_SERVER_STACK_TRACES=true AMOS will show always the

full error traces on the client side

CLIENT_CHA If activated, an AMOS administrator can change "AMOS Tracing"-related settings in true
NGE_TRACIN APN 10 (Statistics tab). If it's deactivated, these settings are hidden from APN 10
G_SETTINGS and can only be changed via the configuration file directly.

SWISS-AS.COM
 33/38

CLIENT_CHA If activated, an AMOS administrator can make changes to certain AMOS true
NGE_ADMINIS webservices. If disabled, the services can not be enabled/disabled and no webuser
TRATION_WE can be added.
BSERVICES
The affected services are:

/actualStateRequest
/databaseAgentService
Maintenance (/iiiMA)
Client Updater (/iiiUlst)
/scheduler

CLIENT_CHA If activated, an AMOS administrator can change SSL-related settings in APN 10. If true
NGE_SSL_SE it's deactivated, these settings are hidden from APN 10 and can only be changed via
TTINGS the configuration file directly.

CLIENT_CHA If activated, an AMOS administrator can change the setting controlling whether true
NGE_START_ AMOS Scheduler should boot up during server boot, from within APN 10. If it's
AMOS_SCHE deactivated, this settings is hidden from APN 10 and can only be changed via the
DULER configuration file directly.

CLIENT_CHA If activated, an AMOS administrator can change compression-related settings in true

NGE_COMPR APN 10. If it's deactivated, these settings are hidden from APN 10 and can only be
ESSION_SETT changed via the configuration file directly.
INGS

CLIENT_CHA If activated, an AMOS administrator can change logging-related settings in APN 10. true
NGE_LOGGING If it's deactivated, these settings are hidden from APN 10 and can only be changed
via the configuration file directly.

CLIENT_CHA If activated, an AMOS administrator can change user observer-related settings in true
NGE_USER_O APN 10. If it's deactivated, these settings are hidden from APN 10.
BSERVER
This includes the user observer interval on Sybase systems, but also the time after
which a logged in user is kicked after inactivity.

CLIENT_CHA If activated, an AMOS administrator can change mail server-related settings in APN true
NGE_EMAIL_ 10. If it's deactivated, these settings are hidden from APN 10 and can only be
SERVER changed via the configuration file directly.

CLIENT_CHA If activated, an AMOS administrator can change "Other Gateway"-related settings in true
NGE_OTHER_ APN 10 (like Telex, SMS, etc.). If it's deactivated, these settings are hidden from
GATEWAYS APN 10 and can only be changed via the configuration file directly.

CLIENT_CHA If activated, an AMOS administrator can change proxy-related settings in APN 10. If true
NGE_PROXY it's deactivated, these settings are hidden from APN 10 and can only be changed via
the configuration file directly.

CLIENT_CHA If activated, an AMOS administrator can change message queue-related settings in true
NGE_MESSA APN 10. If it's deactivated, these settings are hidden from APN 10 and can only be
GE_QUEUE changed via the configuration file directly.

CLIENT_CHA If activated, an AMOS administrator can change AMOSmonitoring-related true

SWISS-AS.COM
 34/38

NGE_AMOS_ parameters in APN 10. If it's deactivated, these settings are displayed read-only and
MONITORING can only be changed via the configuration file directly.

CLIENT_CHA If activated, an AMOS administrator can change database-related parameters in true

NGE_DATABA APN 10. If it's deactivated, these settings are displayed read-only and can only be
SE_SETTINGS changed via the configuration file directly.

CLIENT_CHA If activated, an AMOS administrator can change executor-related parameters in APN true
NGE_EXECUT 10. If it's deactivated, these settings are displayed read-only and can only be
OR_PARAMS changed via the configuration file directly.

SECURE_ZIP_ If activated AMOS will enforce limits while extracting ZIP files on: false
HANDLING
the number of entries in a Zip file not be more than 100’000,
the total size of the extracted files must not be bigger as 10GB
the ratio of uncompressed size vs compressesd size of entries must not be > 50.0

We recommend to deactivate these tools and use external database tools or at least to clearly restrict the
access to these tools to a very limited list of administrators.

Managing AMOS user access rights

AMOS comes with a fine grained role model that allows for every login/role to define which actions and features are
available for a given user and which ones are not available. This can be all managed in Admin Roles (APN: 15)
This module is well documented in the AMOS Help and used by all our customers. We just want to highlight here
some best practice for defining access rights.

Enforcing the need to know principle, restrict the access for normal users as much as possible and grant only
rights that are needed
Establish a team of key users or supervisors with extended access rights
Limit system critical modules to a small group of AMOS administrators / AMOS competence center

Temporary access rights

To grant rights for specific tasks or project we advise to create new roles for this purpose and limit the role and
assign and de-assign users to this role on demand. This helps to keep track of these users. Additionally AMOS
offers the possibility to define an expiry date when assigning a user to a given role. This allows to grant access
rights only for a given time period and reduces the risk to forget to de-assign the user later again. In Admin Roles
(APN: 15) this can be done in the "Add User" dialog.

SWISS-AS.COM
 35/38

We recommend to regularly review, at least once a year, the access rights assignments of all users and to
adjust them as needed. Experience has shown that after some years of AMOS usage way to many access
rights are granted to users that only needed these rights for a given time or a specific project.

Additionally we recommend to regularly review the list of logins and to deactivate old logins that are no
longer in use. We recommend to do this automatically (See Configure Server: Disable user after x days of
inactivity)

SWISS-AS.COM
 36/38

Logging & Monitoring

This section gives you an overview about the build in tools in AMOS that help you to monitor security critical areas
of AMOS.

AMOS Control Center

The AMOS Control Center (APN: 2137) is the central place to monitor all aspects of AMOS operation in regards to
errors, resources usage but also security.

In this module you will find an own section "Security monitoring"

Here you will see all recommendations for secure configuration and setup of AMOS. Additionally this is the place
where you can see all security relevant notifications and events.
AMOS will highlight the settings that do not correspond to the recommended settings. This should be your first
starting point to get an overview about the overall AMOS security.

Monitoring login activity

AMOS comes with a module Login History (APN: 609) to monitor all login related events like login to AMOS for
selected users or all failed login attempts. We recommend to regularly review this modules to detect anomalies
regarding login to the AMOS system.

SWISS-AS.COM
 37/38

Server log files

AMOS comes with a flexible configurable logging system. Depending on your demands this can be setup to log
security relevant events in log files on the AMOS server. The AMOS logging can be setup via rules in Configure
Server (APN: 10)
This allows for example to log all executed modifying database commands to produce a full audit log of all changes
performed in the system.

Please note that depending on your settings the amount of logged data can be come large and you should carefully
test your rules before you activate them on your production otherwise you may run out of disk space because of
huge log files.
All generated log files can be found in the logs folder of the AMOS server. AMOS also offers options to send
logging information to an external logging server via a syslog protocol or via email. Additionally we offer functionality
to use log file rotation to be able to regularly archive old log files.
Please consult the AMOS Help for details on how to configure logging rules or contact the Swiss-AS support if you
have specific demand for additional server side logging.

SWISS-AS.COM
 38/38

DBMS Hardening
AMOS offers support for different DBMS. Hardening of the database is a complex topic on its own. Depending on
your system and version this differs a lot. We would like to recommend to you to read the documentation offered by
the vendor of your DBMS. All of them offer good documentation to for securing the database. The following tips are
of generic nature and should be only seen as additional recommendations.

Generic DB hardening Tips

Delete or deactivate all database users that are not needed for running AMOS
Deactivate all additional services that are not used / needed for running AMOS
Do not run multiple applications (also not different AMOS instances) on the same database server.
One AMOS per DB Server
Use strong passwords for all logins
Do Backups and check them regularly
Do not access the AMOS database with other tools then AMOS directly.
Except administrative access for administrative tasks
Especially no write access to the database
If you need to give read access (maybe for reporting) limit this users as aggressive as possible to a
limited set of tables
Limit via a firewall the access to the DB server ports to a limited set of IPs / only the AMOS server

Document Information

Swiss AviationSoftware Ltd.

BSLSAS/CS
P.O.Box, CH-4002 Basel, Switzerland
Tel.: +41 61 582 72 94
Fax: +41 61 582 70 17

©2022 Swiss Aviation Software Ltd.

SWISS-AS.COM