Andy Mills, VP for EMEA at Cequence Security, on why API security should be championed by the CISO and how this can be done.
The remit of the CISO is not to fix coding or security issues but to provide the structure needed to limit the potential for those to happen and to ensure measures are in place to remedy them if they do. That equates to putting in place effective policies to govern how people, processes and technology work. That may sound obvious but when it comes to Application Programming Interfaces (APIs), it seems that out of sight is often out of mind.
Recent research reveals that out of over 1 trillion malicious API requests captured in 2022, 50 billion targeted shadow APIs, that is APIs that are unknown, unmanaged and unprotected. This is because organisations frequently underestimate the number of APIs that have been deployed, inevitably resulting in shadow APIs – and this is a problem because an ungoverned API is effectively an open door to the organisation’s data.
There are, therefore, a number of steps that should be insisted upon when implementing APIs. To begin with, visibility is a must so it’s vital to discover all the APIs that the organisation has, even if these are regarded as dormant. An attack surface management tool can be used to search out all APIs on the network and these should then be assessed for risk and vulnerabilities and registered in an inventory database.
Additional information on hosting providers and the department and assigned asset owners should also be included and the database should be continuously updated in real time to ensure the information remains current, preventing shadow APIs. This can be achieved by implementing runtime inventory but make sure this is vendor neutral and capable of integrating with existing systems, including API gateways, proxies and controllers.
Enforce compliance
Another key concern is ensuring that APIs remain compliant and that specifications are enforced. This means that every time the service comes online, every time the server is rebooted, every time a load balancer spins up another instance, and every time there’s a patch or code change, the APIs need to be fully tested. Such testing must be automated with tests run on a periodic timer and, in the event the test fails, the API should not be deployed and an investigation triggered.
When it comes to authentication, authorisation and encryption, these should not be developed inhouse. Open standards such as OAuth 2 and OpenID Connect are tried, tested and widely trusted, while all data communications to the API should be sent over Transport Layer Security (TLS). Identity Access Management (IAM) providers can also provide access mechanisms for APIs and their endpoints.
As well as encrypting data in transit and at rest it’s wise to look at data stored in the backend systems accessed by the API. Unencrypted transaction data stored in temporary files is often stolen in API attacks. API keys, too, should never be embedded in the code or hard coded into the application’s source repository. Instead, use environment variables or files outside of the application’s source code or even resort to a secrets management service.
Scan all input to the API and validate it to prevent injection attacks. Attackers can easily discover APIs that lack input validation using automated scanning tools but this can be prevented using an existing tested library for validation. Where relevant, XML schema, JSON and SQL validation should also be implemented. Error messages, too, can provide an attacker with a wealth of information, so keep these short and avoid insertions such as ‘incorrect password’ which could then prompt a credential stuffing attack.
Another safeguard is to set sensible rate limits on the request traffic to the API. A limiter will look at various metrics including request frequency as well as setting CPU and memory thresholds within the API. Of course, there are times when an API will see a surge in traffic and on these occasions caching, sideloading and load balancing can be used to regulate access to the API.
Any API is a target
The problem with API security is that any attack will usually see an abuse of either poor coding, poor security mechanisms or the API’s functionality itself, so it’s perfectly possible for a securely written API to be compromised. For this reason, threat detection and mitigation should be used to block API threats in real time. However, it’s also vital that any attack is verified in order to prevent very high false positive rates and the throttling of traffic to the API which means the threat mitigation tool must be customisable in addition to offering the ability to block, log, deceive, or rate limit an attack.
Qualifying an attack is much easier if that tool utilises a threat intelligence database. This can utilise Machine Learning and AI to pull in data from a broader dataset than just the application in order to make intelligent decisions on malicious traffic and it works by comparing normal operations with attack tactics, techniques and procedures (TTPs) to spot the most subtle of threats. Such threat intelligence is invaluable, particularly given that we are now seeing attackers combine TTPs from the OWASP API top 10 with feints that mask their real target.
Both internal and external (i.e. public facing) APIs should be subject to these security controls but it’s also important to look at APIs as part of the wider network. Integration with gateways, proxies, load balancers and controllers can all help provide additional information.
Finally, remember that many APIs are business critical and so should be part of Disaster Recovery and Business Continuity plans. As such they need to be mirrored, backed up and covered by a recovery procedure and that goes too for hosted APIs, where the host will need to be reinitiated and in position to service API requests.
For CISOs, especially those working in highly regulated industries, API security must become a priority to ensure that the sensitive data they access remains protected. API ecosystems are becoming increasingly complex, with APIs requesting data from other APIs serving cloud-native applications. Such is the demand for APIs that we’re seeing ever greater numbers of APIs spun-up, resulting in a sprawling attack surface which can only be protected if API security is championed by the CISO.
