Author: Michelle.mclean

Comment on What Expert Says On Marqeta Expanding Credit Platform With 40 New APIs by Michelle.mclean

API use is growing at an incredible rate, and this story further exemplifies this growth. While APIs bring about huge benefits, they also bring about some serious security concerns – particularly in the financial sector where API vulnerabilities can result in the theft of huge quantities of money. It is therefore incredibly important that organisations using new APIs, no matter how big the business benefits, make security a top priority. They need to consider API security both when developing the APIs, with pre-production security testing, and while they’re running, with runtime protection. It might be surprising to learn that the majority of API attacks actually occur within authenticated sessions and through trusted channels. Attackers regularly abuse business logic of banking services and will also aim to compromise user accounts through attack techniques like brute forcing or credential stuffing. These kinds of business logic attacks cannot be detected with so-called shift-left practices like API security testing. Only runtime protection, with behavioural anomaly detection that can find the low and slow patterns of API attacks, will keep these organisations’ assets safe. Bad actors are using these hard-to-detect methods to target customer accounts for account takeover (ATO), credential stuffing, and other avenues for potential fraud. Obviously such attacks, when successful, are terrible for customers and reflect badly on the organisation.

Comment on Why 93% Of Kubernetes Users Struggle With Security by Michelle.mclean

This report from Red Hat highlights some really important security considerations. Because cloud-native design relies on new technology stacks such as containers, Kubernetes and service mesh, it also requires API development, integration, and consumption. This, in turn, creates a larger attack surface. In addition to threats caused by cloud complexity itself, the cloud also increases exposure of some assets beyond more well-understood, on-premises data centre environments.
Access controls are difficult to get “right” when organisations must support multiple environments and consumer types. There have also been cases of server-side request forgery. A good example is the Capital One incident where attackers use web applications or web APIs as the front door into back-end cloud provider metadata services and infrastructure. Kubernetes (and its APIs) are usually an internal service used by the service provider/maintainer and not by its users. This in turn can play to the hands of attackers, as exposing these APIs may turn a very small attack surface to a very big one – allowing the attackers to try and find number of issues that could be abused in the API service itself, whether from misconfigurations of the service itself, or from well-known API class vulnerabilities.