Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Background

The component Caller API is a service that exposes ACS (CORBA) components and its their methods through a REST API. From its creation it was thought Currently, it is deployed as part of the ACS services in the production environment. Although, there is no known application consuming from the REST API. 

It was originally envisioned to have at least authentication , however the implementation was delayed for the futureas a security mechanism. However, this implementation has been postponed for multiple reasons.

Recently, a risk analysis memo was prepared by 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 APE firewall. The APE 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: JAO firewall, protecting the organization's network from outside threats.

It can be seen that the vulnerability exposes the main system to be accessed and manipulated from inside the organization JAO network by either careless or malicious actions. There's no way at At the moment, there is no mechanism to restrict by the 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, which includes the following:

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

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 the software to take advantage of CAS / KeyCloak tokens
  • Roles (Associated with the source IP)
  • Access
  • whitelisting
  • restriction (Components, types (IDLs), methods. etc.)
    • 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
  • restriction
    • Black / White access limitation

Discussion

Conclusions

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