The following article is based on a webinar series on enterprise API security by Imvision, featuring expert speakers from IBM, Deloitte, Maersk, and Imvision discussing the importance of centralizing an organization’s visibility of its APIs as a way to accelerate remediation efforts and improve the overall security posture.
Centralizing security is challenging in today’s open ecosystem
When approaching API visibility, the first thing we have to recognize is that today’s enterprises actively avoid managing all their APIs through one system. According to IBM’s Tony Curcio, Director of Integration Engineering, many of his enterprise customers already work with hybrid architectures that leverage classic on-premise infrastructure while adopting SaaS and IaaS across various cloud vendors.
These architectures aim to increase resilience and flexibility, but are well aware that it complicates centralization efforts’ to: ‘These architectures aim to increase resilience and flexibility, but at the cost of complicating centralization efforts In these organizations, it is imperative to have a centralized API location with deployment into each of these locations, to ensure greater visibility and better management of API-related business activities.
The challenge for security teams is that there isn’t one central place where all APIs are managed by the development team – and as time passes, that complexity is likely to only get worse. Moreover, this complexity doesn’t stop at the infrastructure level, but carries on into the application layer.
Deloitte’s Moe Shamim, Senior Technology Executive and Deputy CISO of US Consulting, sees non-monolithic application development as key. He claims that organizations must now break down those millions of lines of code into API-based, modularized processes and systems in order to remain competitive, all while ensuring that threat vectors are kept down to a minimum. This requires significant rethinking as one must now account for API gateways, IAMs, throttling and more, which means significant time and resources.
The API footprint of organizations is no longer increasing organically over time. It now consists of various APIs whose origins come from mergers and acquisitions, versioning, internal APIs, 3rd party APIs, drift from original intended usage, dev, test, debug and diagnostic purposes and so on. This makes complexity an even bigger issue, as many APIs are undocumented and unmanaged, and needless to say – unprotected.
images from Hacker News