Mega-trends such as cloud computing, mobility and the Internet of Things are reshaping the IT infrastructures used by many organisations. Finding ways to maintain proper security as the diversity of technologies continues to grow rapidly is becoming an increasing challenge.
Much of the challenge stems from the proliferation of new endpoints. External data sources, cloud platforms and mobile devices all provide valuable services, but they also create new potential avenues for intrusion. Each and every endpoint is a potential door into an organisation's IT systems and data, and hackers only need to open one to wreak havoc.
The role of the API
When attempting to secure dispersed application networks, many organisations take the approach of trying to lock down all potential entry points, believing an impervious perimeter will protect their IT infrastructure from harm.
However this approach is no longer practical as businesses need to link systems with those of partners and suppliers, as well as opening some applications to customers. Entire lock down simply won’t work. This approach also makes it very difficult for an organisation to be agile and take advantage of new opportunities as they emerge.
A much better and more flexible approach is to make use of APIs. Written and deployed correctly, APIs act like a fortified gate by only allowing traffic through that meets strict criteria. They also ensure users can only gain access to the applications and data for which they have been pre-approved.
Enforcing API security
When taking an API-based approach to infrastructure access, there are five key areas in which security needs to be considered and enforced to ensure the ongoing reliable operation and protection of corporate data and systems. They include identity, authorisation, message integrity, message confidentiality and API availability.
- Identity is a key factor when it comes to API security. There is a need to be able to recognise the applications that make use of each API and the data that is being accessed by those applications. APIs also need to be able to identify themselves to external apps and servers. Passwords are the most common way of validating identity but this approach can be weak. Adoption of a multi-factor authentication process (using SMS tokens) is a better alternative.
If APIs are to be used by people outside the organisation, a Federated Identity approach can be used. Federated Identity providers hold details of users and can confirm their identity when API requests are made. Security Assertion Mark-up Language (SAML) is an example of an open security format that can be used for this task as it allows identity requests to be handled in a standard way.
- Authorisation is another important component in the API mix. Organisations tend to be divided into sub-groups of employees doing similar things, and so rules can be put in place to ensure each group can only access the information its members require for their role. This further enhances the security of the APIs used by each group.
- Message integrity goes beyond identity and is the task of ensuring that a message has not been compromised mid-journey by a malicious third party. Here, the use of digital signatures generated by each app is a strong approach. Each signature is authenticated by the API before any data is shared. This system can be thought of as working in a similar way to the PIN number a person enters when they use a debit card.
- Message confidentiality prevents unauthorised parties from witnessing details contained within a message during its journey from the app to the API. This problem is prevented by using cryptography to hide messages from the time they leave the app until they are received by the API. An encrypted version of each message can only be read with access to the correct cryptographic key.
- API availability is a final area of concern that needs to be considered. Organisations must be sure that their APIs will be available to respond to calls and that, once they begin working on a call, they will see the task through to completion. This can be achieved by horizontally scaling the API over multiple servers to ensure it can cope with heavy workloads. Message processing can be offloaded to a message broker that holds the message until the API has completed its processing within agreed service times. Additionally, by establishing the identity of the caller, it’s possible not only to make APIs highly available but also define tiers of quality of service based on the audience, which is specified by the service-level agreement (SLA).
In order to gain a competitive edge, organisations need to take advantage of the disparate endpoints that exist today through an API-led approach. By addressing these key security areas, organisations can be confident that the APIs they have in place are providing the level of secure and reliable service that is required. The benefits of having API-based capabilities, such as flexibility, efficiency and responsiveness, can then be enjoyed in the knowledge that core systems and data will remain secure at all times.