This first blog post of the API security series addressed Discovery, or an organization's ability to identify which APIs are present and where they are hosted. This second post in the series addresses how a proper API inventory can reduce redundant development costs by identifying duplicate API functionality.

If there is a lack of documented APIs across the environment, these APIs will remain unsecured and will provide an additional attack surface. APIs are often an easy target for attackers and can ultimately disrupt the overall business. Creating an inventory can help reduce organizational risk.

The Benefits and Challenges of API Inventories

An inventory identifies who is responsible for the development, support and remediation of the API environment within an organization. At this point, APIs have been identified in the environment. The next step is to choose an API inventory solution with the involvement of key departmental stakeholders: development teams, audits, governance, risk and compliance.

During the discovery process, I mentioned that securing APIs is not always an IT issue—although IT does support API development in many cases. Different groups across the organization rely on API functionality. For instance, an organization may rely on external third parties to ensure that marketing team functions can be reproduced for reporting purposes. After creating an API inventory, one may have questions. Will the third party continue to exist? Will an inventory-excluded API continue to be developed? What if the data used by the API is not updated or does not continue to exist? These questions can impact an organization but are not often reviewed because the API inventory does not exist. In cases where an API created for a specific process is excluded from the inventory, it is important to consider whether the organization should recreate a new API, recreate it with another third party or establish another data lake to support this portion of the business.

Creating, Tracking and Managing API Inventories

Creating an inventory is not always easy. You can create one using manual tools and processes, like spreadsheets. But manually tracking and updating an inventory over time can be inefficient. However, A RACI chart could help with efficient tracking. RACI is an acronym that stands for responsible, accountable, consulted and informed. A RACI chart provides a matrix of all the activities or decision-making authorities undertaken in an organization set against all the people or roles. A RACI chart associated with the inventory helps those managing API inventories to provide governance for responsible parties. Using a RACI chart, one can more easily reach decisions regarding the reasons that the data is being used, the determination of whether additional data already exists for use within the organization, the need for internal or third-party development and security, and additional security aspects around the communication and transmission of that data.

Tracking the deployment of an API is also a difficult solution. Is it possible to manually track the dynamic changes occurring across an API environment to ensure you are addressing security needs and continued management? The last blog post in this series on Discovery addressed the use of tools to help you support your API environment. It is no different here, as automated support is necessary to effectively manage an API inventory. Providers such as Microsoft, Oracle, Hewlett Packard and IBM all have integrated solutions for addressing API needs. Additional vendors, such as Cequence, provide various solutions addressing risk, remediation, system compromise, the ability to review APIs across hybrid environments and reporting capabilities to help the user with the inventory and ongoing management of the API environment.

The ability to review an inventory and manage the data received for business functions allows an organization to address process duplication amongst business units. This ensures that additional development is not recreated when an API already exists, because the knowledge is available across the organization. This becomes important when you do not have to recreate another data lake for the information you utilize. It also ensures a decrease in an attack surface across your environment, as all API functionality is addressed appropriately according to your risk profile.

In our next blog post, I will dive into the profile phase and provide information on the API usage, exposure, data and compliance for the organization.