Background

The component Caller API is a service that exposes components and its methods through a REST API. From its creation it was thought to have at least authentication, however the implementation was delayed for the future.

Recently, a risk analysis memo was prepared by ICTTAG, depicting a couple of vulnerabilities present in the ALMA SW APE (ALMA Production Environment). One of these vulnerabilities was the Component Caller API, which runs inside the APE environment. The APE environment is a set of servers, hardware devices and network devices that are configured in an enclosed environment and protected by a firewall. The firewall, however, has deliberately been configured to allow several actions directly on the internal machines, including access to the Component Caller API REST from inside the organization network. There's a second firewall protecting the organization network from outside threats.

It can be seen that the vulnerability exposes the main system to be accessed and manipulated from inside the organization network by either careless or malicious actions. There's no way at the moment to restrict by user, IP or limit the ability to interact with certain components / methods, which gives full control to anyone connecting to this API.

Proposals

There are several ways to reduce or eliminate the risks that have been identified, like adding authentication and roles to the software, running the REST API through a proxy or even fine-tuning the firewall configuration. A combination of the three could probably achieve the most secure and flexible solution. There's likely a whole set of additional ways to solve the situation, but we will consider three (complementary) alternatives in this proposal.

Custom Implementation

A custom implementation could allow several levels of granularity on its configuration:

• Authentication
• Roles
• Access restriction or whitelisting (Components, types (IDLs), methods. etc.)

The CDB configuration of the Component Caller API could be used to easily configure the different security profiles.

For authentication, it could either be used the CDB configuration (cdbRead could access credentials / tokens), or a service such as LDAP, ALMA Registry, etc.

Proxy

A proxy could be configured either for the server or the APE environment as a whole, which limits the access to the resources. It could be used for:

• Authentication (Through CAS / KeyCloak)
  • Would most likely require changes to software to take advantage of CAS / KeyCloak tokens
• Roles (Associated with the source IP)
• Access whitelisting (Components, types (IDLs), methods. etc.)
  • Associated with source IP
  • Would require software changes to consider /<component>/<method> endpoints.

Firewall

The existing firewall could be configured for the APE environment to limit the access to the Component Caller API, allowing specific services to make use of the REST API

• Access whitelisting
  • Black / White access limitation

Comparison

Discussion

Conclusions

The conclusions will be prepared after review from the stakeholders and possible discussion meetings are held.