Skip to main content
Jul 25, 2018

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:

  1. Modeling a system necessarily excludes certain details about the implementation of the system. Those are the exact system implementation details that are usually exploited.
  2. Change is a very hard thing to quantify. Knowing definitively whether changes in the system cause changes in the model is not easy.
  3. 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

Aaron Lint Arxan Chief Scientist

Aaron Lint

Aaron and the Arxan Advanced Threat Team analyze and catalog the application security threat landscape and drive the breadth and depth of Arxan's application protection. Aaron brings over 15 years of industry and academic experience in information security and cryptography. His expertise is in binary formats, reverse engineering, compilers, linkers, and operating systems. He holds a BS in Computer Science from The Ohio State University and a MS in Computer Science from Purdue University.

Learn More

Download the 2018 Global Study on Application Security to find out why most companies still aren't adequately investing in app hardening security measures, and the effect of real-time app threat data could have on increasing security spend and minimizing business risk.
More from the Blog
Apr 02, 2018

Protecting Apps Is Not Enough: Why You Need Threat Analytics

Every app downloaded via an app store is running in a
Read more
Apr 02, 2018

How to Detect App Threats to Protect Your Business

May 07, 2018

It's Time To Get Serious About Application Security