1: Broken object level authorisation
4: Lack of resources & rate limiting
5: Broken function level Authorization
10: Insufficient logging & monitoring
Improper asset management is a vulnerability caused by lack of a technical overview of deployed API assets where these assets may be vulnerable to exploits due to stagnation and lack of oversight and ownership.
Some relatable examples include:
- The API written by an intern who has since left. It was never properly documented. It may or may not be used by other teams or the business. No one in the team knows anything about it, other than perhaps that it does exist.
- A product was brought in as a turn-key solution and ownership was never given. The infrastructure team keeps it running but otherwise knows nothing about it.
- A service was created years ago, but since then there have been reorganizations and the knowledge now lies in disparate teams and no owner was assigned.
- “If it ain’t broke, don’t fix it” is an often heard term in IT but “broken” in IT terms is often not boolean. A service might be performing its role successfully, but if it is outdated, not patched, not properly secured then it might also be a successful vulnerability.
To prevent against improper asset management organisations should implement and keep updated an asset management system such as a CMDB, ensure that all services have a responsible owner, and track usage of API calls so that stale services are removed or used stagnant services are updated.
OWASP summary
| Threat agents/attack vectors | Security weakness | Impacts |
| API specific : Exploitability 3 | Prevalence 3 : Detectability 2 | Technical 2 : Business specific |
| Old API versions are usually unpatched and are an easy way to compromise systems without having to fight state-of-the-art security mechanisms, which might be in place to protect the most recent API versions. | Outdated documentation makes it more difficult to find and/or fix vulnerabilities. Lack of assets inventory and retire strategies leads to running unpatched systems, resulting in leakage of sensitive data. It’s common to find unnecessarily exposed API hosts because of modern concepts like microservices, which make applications easy to deploy and independent (e.g., cloud computing, k8s). | Attackers may gain access to sensitive data, or even takeover the server through old, unpatched API versions connected to the same database. |
Source: OWASP improper asset management
APIM context
While full asset management is out of the scope of an APIM the APIM can play a vital role in the enforcement of asset deprecation and access. In addition an API Developer Portal further facilitates documentation of API assets and the usage of analytics gives insight to identify stale APIs and potentially stagnant used APIs.
Tyk approach
Tyk can play a valuable role in enforcement of API asset management through
- Versioning allows newer versions of APIs to coexist with the older versions, facilitating deprecation and sunsetting.
- Sunsetting allows versions to be configured with an Expiry Time, ensuring that a version is sunset.
- Key expiry ensures that access to an API is short lived, with a per key configurable Time to Live.
- Tyk Developer Portal catalogues APIs and facilitates granting access to them. Integrated with a CMDB it can help keep documentation updated.
- Tyk analytics can help identify the stagnant APIs and used stale APIs.
- Tyk pumpcan ship metrics needed for analytics into Tyk Dashboard and other systems.
- Third-party secret storage can be used to centralise and protect sensitive configuration data such as passwords, rather than exposing them as plain text in Tyk configuration files.
While various organisations handle asset management in various different ways it is important that organisations realise the full potential of asset management and make keeping it updated part of the delivery workflow. In addition a good best practice is to consider any definition of done to include corresponding documentation updates.
