Improper Assets Management

What is this security issue about?

Improper assets management refers to when we have two versions of an API, v1 and v2, but we forget to delete v1 after starting to use v2, even if we fixed v1. The vulnerability here is that v1 might not use the latest security features, or involve obsolete features for which the documentation makes finding and fixing vulnerabilities difficult. Potential consequences of improper asset management include data leaks or server takeover through a common database between the current API (v2) and the old one (v1).

While one might think that having so many APIs running that they can be mismanaged, the OWASP Top 10 report mentions that with the advent of microservices and virtual machines, it is really easy to deploy several applications (e.g. via Kubernetes, cloud computing, Docker…). By being so easily deployable, the possibility opens up for having so many instances running that some may be forgotten altogether.

What does this vulnerability look like for APIs?

As previously mentioned, vulnerability begins with APIs that are old or unpatched. Without the security features typically given through updates or upgrading to newer API versions with better support, an attacker can bypass security using known flaws. From the management side, a partial, incomplete, or outdated inventory of running instances of APIs can create the space for the old and unpatched APIs we just mentioned. The OWASP report also mentions that API hosts with unclear purpose, or without clearly documented answers to questions concerning the environment in which the API is running, the version, the information used and accessed, or who should have access to the API are certainly vulnerable. Other factors include APIs that don’t have a strategy in terms of life cycle and retirement.

How is improper assets management avoided?

The solution to improperly managed assets is, well, to properly manage them. This takes several forms. First and foremost, delete APIs which aren’t being used. There is no reason to keep them online and accessible either internally or externally if they are no longer in use. This avoids them being forgotten entirely (and consequently not updated nor given security patches), which may open them up to attack by malicious actors. The OWASP foundation also issued a variety of other recommendations concerning improper assets management. They include making an inventory of all used APIs, and including key information such as the current version, who can access the API, as well as the environment the API is in, and its current point in the life cycle. Also adding integrated services’ data flow and access, sensitivity, and role in the API system is important.

Concerning upgrading versions, OWASP makes an important note: “when newer versions of APIs include security improvements, perform a risk analysis to decide on the mitigation actions required for the older version: for example, whether it is possible to backport the improvements without breaking API compatibility or you need to take the older version out quickly and force all clients to move to the latest version.” Improper asset management can therefore be addressed by having an API rollout strategy with strong documentation and inventories to explain the purpose of an API, who can access it, and what is the API’s associated data flow, on top of applying security patches and updates regularly, and having a strategy that covers the entire design life cycle of the API, including retirement. These elements are all important to prevent malicious actors from exploiting improper management of API assets.