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:

• App Integrity: First we need to remember that anyone can download your mobile app from the app stores and examine its code and its operation. Is an attacker modifying or cloning your app and running a new version in order to access data from the API or otherwise change what the app does? You must be able to prevent this from happening.
• Device Integrity: Alissa's report highlights how different tools can be installed in the client where the mobile apps are running. Are there frameworks running in the client or has the client been otherwise manipulated in order to steal secrets or interfere with the correct functioning of the app? To ensure security, it is essential to gain visibility and control over the state of the client environment. 
• API Channel Integrity: Are you open to Man-in-the-Middle attacks between the app and the API? In the mobile app use-case, bad actors can intercept traffic, even when the traffic is encrypted, and you must take steps to defend against these kinds of MitM attacks.  

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:

• How easy is it to deploy and operate the solution? You need to look at how much effort it takes to get the solution to the point where it is providing the protection it promises. In addition, once deployed, does it require constant tuning by a large specialized team in order to maintain effective operation (and avoid false positives - see next bullet).
• How transparent is it to your business operations? The business owner and the DevOps team will be concerned by this. Some types of solution have a clear tradeoff between security efficacy and the risk of false positives. In security a false-positive occurs when a tool sees something suspicious and blocks or initiates another kind of check (eg CAPTCHA) on what is actually a genuine  user interaction.  Such false-positives can impact customer satisfaction, and ultimately your business. Your DevOps team may “veto” some security features being turned on because they think the risk that genuine requests could be rejected is too high. This may mean you will never reach the level of security efficacy promised by the solution. You must carefully evaluate the risk and impact of false positives as part of the process.
• How fast can the solution adapt to new threats or changing circumstances? You should check how easy it is to update security policies if updates are required and you should verify also how effective the product team is at tracking and keeping up to date with new threats.
• Reporting and analytics: This is important not only to measure and report on the effectiveness of the solution but also to help secure and maintain regulatory compliance.  
• The cost of the solution: It is important to understand how you will be charged for the solution and consider carefully any additional operational costs. A principal to follow is to try to ensure that the cost is aligned with the growth (and revenue) coming from the business. As an extreme example,  a solution which is priced based on the level of genuine user access is preferable to one priced based on the volume of blocked traffic. 

Conclusion 

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.