This post is from the Arxan blog and has not been updated since the original publish date.
Your App Security Risk Models Are Wrong
And That’s Why Feedback Is So Important
Information security, especially application security, expresses its tenets and risks in terms of threat models. The OWASP Project defines Threat Modeling as working to “identify, communicate, and understand threats and mitigations within the context of protecting something of value.” This definition seems fairly straightforward, and in fact, this is the very process that information security personnel
are should be going through on a daily basis.
Here’s the problem — all risk models are inherently wrong.
Take a moment to process your negative reaction before taking to social media decrying this statement. There is a good amount of research on this in the field of statistics.1 Here are the top three reasons why risk models tend to fall short:
- Modeling a system necessarily excludes certain details about the implementation of the system. Those are the exact system implementation details that are usually exploited.
- Change is a very hard thing to quantify. Knowing definitively whether changes in the system cause changes in the model is not easy.
- Making the model more elaborate can actually make the problem worse. More options means more things to get wrong.
Model Failures = Security Failures
Some models are very useful and effective. Yet, organizations are seeing time and time again attackers outpacing the security mitigations by identifying and exploiting misconfigurations and vulnerabilities. So many failures in security can be traced back to a failure to model the underlying risk properly. It’s useful to talk about the ways that risk models can diverge from reality, so that meaningful changes can be made to mitigate those risks.
Need for Contextual Feedback Loop
This trend is driving the move toward in-depth security analytics. Even if there are nuances of the modeled systems that are not properly represented, a well developed feedback loop can minimize the impact of these differences. This continuous detection and response process is crucial for ongoing validation of an organization’s risk model.
Limits of Traditional Endpoint Monitoring
Traditionally, inside the enterprise, the heavy lifting of this feedback loop lies with endpoint monitoring and mobile device management. This often requires devices to be registered and policies to be developed and enforced. Even the lighter weight solutions usually have a mobile application that must be installed to provide the connection back to home base.This practice poses serious complications with balancing a Bring Your Own Device (BYOD) policy, and properly assessing the risks of these personally-owned devices becomes difficult or impossible. Essentially, these devices should be treated as untrusted environments.
Treat the App as an Endpoint
From a risk perspective, the application contains a significant amount of information about the data center and the structure of the application. API endpoint references, payload formats, and cryptographic keys are inside the app’s code and data. Even if the client-side application is coded perfectly, this data will be stored on the phone, inside the app’s memory and code. The application needs this data to be able to communicate with systems inside the data center. This can give an attacker the signposts necessary to enumerate the systems inside the perimeter of trust and use seemingly legitimate calls to the exposed APIs to affect the system as a whole.
App-Centric Telemetry Completes Your Risk Model
Empower the application to assess its surroundings, to identify risky behavior, and eventually base risk decisions off of that intelligence. This model choice, combined with traditional API monitoring and web application firewalls, completes the picture of how the application is faring after it has been released into the wild. The app-centric telemetry gives fine-grained context into how attackers or malware are directly interfacing with your app’s code and data. This provides the remaining piece of the puzzle as to whether the situation being borne out by the analytics matches what your risk model expects.
1George E. P. Box (1976) Science and Statistics Journal of the American Statistical Association, Vol. 71, No. 356. (Dec., 1976), pp. 791-799