Shift Left but Shield Right - but what does that mean?

We sponsored a major report “Playing with FHIR” by Alissa Knight, released in October 2021 (download it here) which investigated the security of mobile healthcare apps and APIs which use the FHIR standard. This report has certainly sparked a lot of debate about the security of healthcare apps and a broader discussion about who is accountable for keeping patient data safe as the ecosystem expands. 

Among the recommendations made by Alissa in the report, one merits some further discussion:  She states that organizations deploying mobile apps should “Shift Left but Shield Right”. But what does this mean?

This is the first of 2 blogs on the topic. Here I will discuss approaches to Shift Left and highlight why neglecting shielding is dangerous. In the second blog I will look at how mobile app developers can think about evaluating run-time shielding options. 

So let's start by explaining what these expressions mean in the context of mobile app security.  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. 

Alissa actually found that no effective shielding solutions were in place and she was able to steal secrets from apps and then use those secrets to attack APIs. She found well known vulnerabilities in some APIs and she also was able to use one user's (genuine) credentials to access (many) other people's data.

So Shift Left can be thought of as an approach to finding and eliminating vulnerabilities before deployment. But even if you have a great Shift Left program in place and you feel you have eliminated all the OWASP Top 10 API vulnerabilities from your APIs (and some APIs tested by Alissa had not), there are always vulnerabilities you haven't thought of. In any case, even if you could reach  “zero” vulnerabilities, you can still be hacked. There is always the risk of user credentials and keys being stolen from other sites and being used successfully on your site (credential stuffing). In addition, the use of secrets which have been stolen from development and testing tools and repositories is a growing problem: Tools and scripts can use them to masquerade as a genuine app/user combination. 

Understanding and making explicit the interplay between Shift Left and Shield Right ensures optimal security. In fact, the one single takeaway from this analysis is to recommend that you immediately evaluate the effectiveness of the processes and tools you have in place to provide run-time shielding of your APIs - in other words you should focus your energy on “Shield Right Now”.

Lets first briefly discuss some of the Shift Left approaches which can be employed. 

Shift Left Approaches

Much of the focus has been here in recent years, partially because of the prevalence of OWASP and the truism that eliminating problems early on saves money. 

Two main approaches can be discussed - Chasing down vulnerabilities in your code and Making harvesting of secrets from mobile apps harder. Let's look at each in turn.

Chasing down vulnerabilities in your code 

This can be seen as an approach to finding and fixing issues and vulnerabilities in the application code as early as possible in the development process. There are a multitude of tools to aid in the scanning and discovery of potential problems and prioritizing fixes as well as managing potential issues with third-party code. Two broad (analyst recognized) categories here are SAST and DAST: 

Static Application Security Testing (SAST) is a method of detecting vulnerabilities by analyzing the source code. Having a common specification in place will help a SAST for APIs to detect common implementation issues in APIs like erroneously exposed APIs, parameters, error codes, and messages. These systems can integrate directly into API development environments like IDEs, bug tracking systems, and CI/CD tools.

Dynamic Application Security Testing (DAST) is a security testing method where you deploy a vulnerability scanner to actively probe a running application, usually in a test environment, in order to detect possible security vulnerabilities. There are a number of good DAST tools built specifically for APIs.  One of the key requirements for a DAST for APIs is that the tool needs to understand the APIs – including both the syntax and the business logic it is exposing. A typical specification standard like OpenAPI Specification (formerly Swagger Specification) can help with the syntactic understanding of the API, but the business logic is much harder to understand. Understanding which APIs your company actually exposes, which is also a best-practice highlighted by Alissa, falls broadly into the DAST category. 

DAST automates some of the required pen-testing of the APIs but of course should be part of a larger pen-testing plan which the organization deploys. 

Making harvesting of secrets from mobile apps harder

This is the other area of focus for Shift Left. This is to do with development discipline around how the secrets needed to access the APIs are made available in the app and taking steps to protect the code so that it cannot be reverse engineered.

Code obfuscation is the process of modifying an executable so that it is useless to a hacker, while remaining fully functional. The functionality of the code remains unchanged, and code obfuscation helps conceal the logic and purpose of an app’s code. Code obfuscation is a standard method to prevent cybercriminals from decompiling and reverse engineering source code, and to protect apps from intellectual property theft. Again there are open-source and commercial tools available to help with this, and some extend into real-time protection as well.

Development discipline and code obfuscation to protect the app definitely do make it harder for developers to uncover the logic of the app and gain the keys and secrets they need. But even with obfuscation, with enough time and effort, almost all code can be reverse engineered. And what happens if your API key was erroneously left in a github repo, or the key gets intercepted in transit? This brings us to the need for enhanced run-time API shielding which specifically addresses the unique threats that mobile apps expose.  

Shield Right Now!

As we have learned, Shift Left initiatives are important but run-time shielding is needed too and new threats need new approaches.  Shielding apps at run-time is in fact not a new idea: Web Application Firewalls (WAFs) are a run-time shield and have been extensively deployed since their introduction 20 years ago. They still have a role to play to protect against known HTTP vulnerabilities which have not been fixed (e.g. from the OWASP Top Ten) but as Alissa indicates, they are not at all effective in protecting APIs from the types of attacks she orchestrated. So what else is needed to protect against today's threats?

Watch this space for the second blog, where I will discuss newer approaches to run-time shielding and how to think about evaluating the different types of solution.