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

Proxy

Firewall

Comparison

Discussion

Conclusions

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