As I explained in a previous blog about the FHIR API Research Alissa Knight recently completed, “Shift Left, but Shield Right” is a strategy Alissa recommends to address the issues she uncovered in the mobile apps she tested.
Shift Left of course means using processes, tools and development discipline to address security early in the development process in order to identify, manage and eliminate security issues before deployment. Shield Right means to put controls in place to protect the running service.
In the previous blog I talked about how the 2 approaches are used and why the results of the study mean you should reevaluate your Shield Right initiatives. In this blog I will explore how you should think about that reevaluation.
Because of the way mobile apps are deployed, there are new attack surfaces which bad actors can exploit, and the nature of the threat is not the same as when a browser accesses an API. These attack surfaces can be classified as follows:
An attacker can explore these attack surfaces at their leisure and augment anything they find with stolen user credentials acquired from the dark web or API secrets acquired from on-line repositories. Then they are ready to orchestrate a full-on attack on your APIs.
So as a first step you should carefully evaluate the effectiveness of your current security posture against each of these attack surfaces. And as you seek new solutions to fill the gaps you can also evaluate the effectiveness of each proposed solution against these criteria.
There are other, more operational requirements which should also be considered. Broadly speaking these can be broken down as follows:
In this short piece I have summarized the security issues with mobile apps and APIs which were uncovered in recent research by Alissa Knight on mHealth apps. In addition, I have highlighted the urgent call to action emerging from the research for any organization which is dependent on mobile apps: You must evaluate and reinforce your approach to protecting APIs at run-time: in other words, to Shield Right Now.
When it comes to Shield Right, I have outlined some of the requirements to consider both in terms of evaluating the efficacy of the solution and ease of deployment and operation.
You have choices when it comes to Shield Right. But one thing that is clear is that a traditional WAF is just not designed to prevent the exploitation of the new mobile app attack surfaces. In addition the security provided by API gateways is focussed on authentication and authorization, which are necessary elements for a security strategy but are not sufficient to protect your APIs from abuse.
You will find a number of server-side solutions which claim to provide enhanced API security. Some of the traditional WAF vendors have taken steps to integrate bot detection solutions or claim to be able to automatically create WAF rules from API specs but these approaches fundamentally rely on known patterns and involve constant maintenance and updates to keep up with the latest attack vectors. In addition, most are heavily reliant on browser fingerprinting which is not relevant with mobile apps and they don’t effectively detect scripts impersonating mobile apps.
There are some emerging server-side AI or machine learning solutions which try to spot patterns in traffic but false positives will need to be managed and all traffic has to be carried to the backend to be evaluated, incurring additional costs.
In general, it is a better practice to eliminate as much traffic as possible before it hits the backend. All of the exploits carried out by Alissa during the FHIR research utilized scripts which copied (aka impersonated) API requests coming from genuine software clients, so it should be clear that the vast majority of attacks against vulnerabilities in APIs are performed by automated scripts. Therefore the most efficient way to protect your business against exploitation of vulnerabilities, both those you know about those you don’t, is to block any scripts from using your APIs.
In conclusion, I am not advocating that you ignore API vulnerabilities, but rather that you seek to find a balance between Shift Left and Shield Right approaches. Looking for and fixing API vulnerabilities is a constant and never-ending process that you must undertake. However, it is vital that you first implement a simple but effective API shielding solution so that attackers can’t exploit the inevitable vulnerabilities that will likely always exist in your APIs.