API security more critical as componentization grows
Securing APIs is critical as componentization grows. Expert Tom Nolle suggests that an API's security attributes are as important as functional attributes.
Componentized software and orchestrated workflows create a powerful platform for building agile applications and managing software feature complexity. The APIs used by these components are a key factor in their benefits, a business tool of growing importance. These APIs can also create a major risk for users, exposing assets in unexpected ways and generating customer angst and even legal complications. To secure APIs, it's essential to divide your applications into security zones, match zone practices to vulnerability, and consider an API's security attributes to be as important as functional attributes.
You can visualize nearly all componentized applications as a series of concentric spheres, with each sphere exposing an API for its higher-layer user. At the edge is the worker/consumer interaction point, the Web API that provides the application's overall request/response facilities. As you move deeper, you move through transaction validation and response formatting, application processing, and database or information resource access. Nearly every software planner or architect understands how this structure evolves, but many don't realize that these functional layers are also the application's natural security zones.
At the outer edge of the application, the user interaction point, the practice is to use RESTful APIs and a simple form of security like TLS or SSL to create a secure pipe between the application and the user. The application is expected to authenticate the user through entry of an ID and password or other means, and this level of security is normally sufficient for business applications.
The challenge arises when the Web server RESTful edge connects inward. The APIs used there are often developed with a presumption of security because they are not advertised to the public. But these APIs may not always be protected, and the deeper you go in the layers of application, the more secure they have to be because their information access and update capability is typically broader and generates more risk.
Use private IP addresses for lower-level components
One way to address risks to API security from Web-based hacking is to use private IP addresses for lower-layer components. Internet RFC 1918 (for IPv4) and 4193 (for IPv6) set aside ranges of IP addresses for use on intranets. These addresses will not be routed over public IP networks and cannot be reached directly from the Internet.
APIs bind applications; don't let them bind in risks.
APIs that represent private IP addresses are a good first step in securing your APIs, but not a complete strategy. The problem is that malware can enter your intranet and gain access to those private IP addresses. Malware prevention, detection and removal are critical pieces of an API security strategy, but of course it's also critical to protect application and data integrity from other kinds of threats. However, private IP addresses and strong malware protection are probably adequate for securing second-level (Web-to-application) APIs.
Deeper APIs require the most protection, and you can provide that protection several ways. One is to have user processes at the Web server edge generate a token that represents the transaction and its authority, then pass that token downward through the application layers, with each API process examining and validating the token. That will effectively transfer authentication through the flow. You can obtain a similar result by shifting from RESTful to Web service (SOAP/WSDL) APIs at the Web-to-application boundary and using WS-Security processes to secure deeper APIs.
You are likely to want more powerful tools deeper in the application, and even the basic SSL/TLS facilities readily available to developers will offer some protection. You can obtain more protection through Oauth2 (minimal security unless the default no-signature option is overridden) and in theory better yet via Oauth1.0a, but current practices favor using the former with proper parameters over the latter. The Oauth framework is a means of delegating client access to resources (including APIs) controlled by the resource owner. Properly used, Oauth creates very secure frameworks for APIs, but it's unsafe to rely on the defaults for settings and thus important to organize the Oauth processes and practices very carefully.
Repurposing components raises API security risk
This need for careful organization of security practices raises a collateral risk with APIs, and that is one arising from repurposing of components. A "secured" component can carry both its security requirements and its secure relationships with it into another application, which can cause two different security risks. One is that the application builder, seeking to facilitate the use of the component's APIs, will either reduce security or spread the security practices to the new application's components. Either creates a kind of reuse Trojan horse risk. The other is that the new component will inadvertently expose deeper APIs to misuse because that component has presumed right of access -- a presumption which in the new application may not be correct.
The best way to think of API security overall is to consider the security framework of an API to be a "function," something that would be advertised in catalogs and made available to developers. Like other component functions, the API security functions should never be changed by developers unless the entire scope of component use is examined, the application lifecycle management processes are updated, and the security of the new framework is evaluated end to end to ensure that nothing unexpected will occur.
Componentization is only going to grow, and cloud computing and virtualization can expand the security risk to APIs. It's also important to remember that any change to the execution platform or network environment in which applications run can change the security framework, requiring changes to API security to control risks. APIs bind applications; don't let them bind in risks.
About the author Tom Nolle is president of CIMI Corp., a strategic consulting firm specializing in telecommunications and data communications since 1982.
Follow us on Twitter @SearchSOA and like us on Facebook .
