Contact Us Blog Register Login
PreEmptive -
  • Home
  • Products
    • Application Protection
      • Dotfuscator for .NET
        • Overview
        • Features
        • Compare Editions
        • Xamarin Protection
        • Videos & Resources
        • Pricing
        • Downloads
      • DashO for Android & Java
        • Overview
        • Features
        • Videos & Resources
        • Pricing
        • Downloads
      • JSDefender for JavaScript
        • Overview
        • Features
        • Online Demo
        • Pricing
        • Downloads
      • PreEmptive Protection for iOS
        • Overview
  • Support
    • Product Support
      • Dotfuscator for .NET
      • DashO for Android & Java
      • JSDefender for JavaScript
      • PreEmptive Protection for iOS
    • Resources
      • White Papers
      • Glossary
      • Videos
  • Solutions
    • App Protection Solutions
      • Mobile App Protection
      • Desktop & Server App Protection
      • General Data Protection Regulation (GDPR)
      • Security Development Lifecycle
      • Application Integrity Protection
      • Mobile RASP
      • PCI Mobile Payment Acceptance Security
  • Company
    • About
      • Why PreEmptive?
      • About Us
      • Careers
      • Blog
    • Contact
    • Legal

Encryption’s unfortunate, unavoidable, and unfix-able gap - and how to fill it

January 25, 2018 6621 Views Sebastian Holst


When perimeters are breached, identities stolen and malware launched, encryption stands as information’s last line of defense. Without effective encryption policies, you will first be victimized and then held liable (punished) by every information stakeholder (customers, partners, investors, regulators, the courts, etc.).

Just this week, Wired led with the headline Tinder’s Lack of Encryption Lets Strangers Spy on your Swipes where they wrote in part:

“In 2018, You'd be forgiven for assuming that any sensitive app encrypts its connection from your phone to the cloud, … But if you assumed that basic privacy protection for the world's most popular dating app, you'd be mistaken.”

Whether or not Tinder faces any legal or regulatory jeopardy, the press coverage in Fortune Magazine, Wired, and even my local morning news shows cannot be doing their market share or brand any good.

For a longer treatment of another encryption catastrophe that resulted in $300M in fines and other expenses, see the sidebar “Punishing the Victim: Anthem data breach” inside The Six Degrees of Application Risk.

The hard truth is that when data is stored in the clear (unencrypted) that data cannot be secured – and every information stakeholder knows this to be true (including bad actors). That is why, even though it is too early to predict what civil, criminal or market penalties Tinder will face, the reporter’s incredulous disbelief is so pronounced.

Best practices dictate that sensitive data be encrypted whenever and wherever possible;

  • When data is at rest (in files and databases – and especially with portable media) and
  • When data is in motion ((transmitted between applications, services, and networks – and especially over public networks - as with the Tinder example above).

There is, however, one unfortunate, unavoidable and unfix-able hole in the encryption story. When data-is-in-use (being processed by an application rather than sitting on a disk or flying across a wire), that data must be processed in the clear.

In fact, as encryption policies become increasingly effective, hackers are inexorably drawn to the next best thing, application hacking as the attack vector of choice.

THE UNFORTUNATE, UNAVOIDABLE, UNFIX-ABLE ENCRYPTION GAP

Fortunately, even though data-in-use must be processed in the clear – that data is typically found only in app memory – and reading data in memory requires specialized utilities – and access to those tools can be limited. Debuggers are the hacker’s favorite because in addition to accessing unauthorized data, they have the added advantage of being able to modify a running application to circumvent identity verification, authorization, and other critical controls as well.

…and every stakeholder – especially hackers, regulators and the courts – know this to be true too.

Mitigating the encryption gap

Since data in use can’t be encrypted, the next best strategy is to restrict unauthorized use of debuggers, rooted mobile devices, emulators and other tools that hackers rely upon to access and modify application-resident data. Preventative, detective, and responsive controls combine to secure your applications and – by extension – the data that flows through them.

PREVENTION: Where possible, use OS and compile-time configuration settings to disable debugging and prevent remote code execution. Mobile devices, web app servers, build settings, etc. include these options to prevent precisely these kinds of exploits.

While effective as a first line of defense, these settings can be overridden, bypassed, and/or modified (assuming they are set properly in the first place). To effectively secure sensitive data-in-use, additional controls are required to detect and respond when hackers attach debuggers or tamper with an app.

DETECT & RESPOND at a minimum to the following three progressively material scenarios must be addressed:

  1. Configuration values prohibiting debugging and preventing remote execution are NOT properly set (making it especially easy to execute this kind of exploit)
  2. A debugger is attached to a running app processing sensitive data (indicating that an attack is in progress or, at a minimum, unauthorized probing is underway), and lastly
  3. An app has been modified/tampered post build (suggesting that there has been a successful hack and the resulting compromised version is executing).

Securing apps and the data that flows through them

Writing code to enforce these policies is time consuming, requires new development skills, must be coordinated across development teams, and potentially introduces additional runtime risks.

There is a better way - post-compile injection.

As offered by PreEmptive Solutions Dotfuscator for .NET and DashO for Android and Java, post-compile injection of anti-root and anti-tamper, and a variety of related runtime controls offers a compelling alternative to coding.

Dotfuscator and DashO Injection advantages include:

  • As a post-compile step, anti-debug and anti-tamper functionality can be
    • included into a DevOps tool chain simplifying your development’s tasks and
    • Injected into existing executables and libraries by rebuilding rather than coding.
  • Little or no additional development effort is required
  • Root detection and other evolving algorithms are continuously updated to keep up with new platforms and new attack strategies,
  • While most of the injected functionality can be considered “turnkey”, there are also – by design – straightforward extensibility points to support the inclusion of proprietary defenses and reporting capabilities, and
  • The configuration file that dictates how and where controls are injected do double duty by serving as an audit trail as you harden your code.

Application development compliance and the law

Security standards bodies, regulators, legislators, and the courts recognize the necessity to secure data in use. In addition to increasing your risk of a data-related breach, failure to implement appropriate, well-understood and accepted security controls will almost certainly result in increased liability, fines, and dissatisfaction.

For illustration, consider the following excerpts from regulatory, legal and standards bodies that demonstrate the general acceptance of these principles.

Financial Compliance

PCI Mobile Payment Acceptance Security Guidelines for Developers • September 2017

4.3 Prevent escalation of privileges. (Emphasis added)

Controls should exist to prevent the escalation of privileges on the device (e.g., root or group privileges). Bypassing permissions can allow untrusted security decisions to be made, thus increasing the number of possible attack vectors. Therefore, the device should be monitored for activities that defeat operating system security controls—e.g., jailbreaking or rooting—and, when detected, the device should be quarantined by a solution that removes it from the network, removes the payment-acceptance application from the device, or disables the payment application. Offline jailbreak and root detection and auto quarantine are key since some attackers may attempt to put the device in an offline state to further circumvent detection.

Hardening of the application is a method to that may help prevent escalation of privileges in a mobile device.

Controls should include, but are not limited to providing the capability for the device to produce an alarm or warning if there is an attempt to root or jailbreak the device.

Privacy Legislation

General Data Protection Regulation (GDPR)

Recital 83 Security of processing (Emphasis added)

In order to maintain security and to prevent processing in infringement of this Regulation, the controller or processor should evaluate the risks inherent in the processing and implement measures to mitigate those risks, such as encryption. Those measures should ensure an appropriate level of security, including confidentiality, taking into account the state of the art… In assessing data security risk, consideration should be given to the risks that are presented by personal data processing, such as … unauthorised disclosure of, or access to, personal data transmitted, stored or otherwise processed…”

Application Security Standards

Open Web Application Security Project (OWASP)

OWASP Mobile Application Security Verification Standard v1.0

V8: RESILIENCE REQUIREMENTS: Control objective: Impede Dynamic Analysis and Tampering

8.1 The app detects, and responds to, the presence of a rooted or jailbroken device either by alerting the user or terminating the app.

8.7 The app implements multiple mechanisms in each defense category.

8.8 The detection mechanisms trigger responses of different types, including delayed and stealthy responses.

You don’t need to be the fastest, but you cannot afford to be the slowest when running from the bear

If you care about data-at-rest and data-in-motion, then you need to care about data-in-use – it’s the same data and it brings with it the same responsibilities, risks and liabilities.

If your organization develops software, you need to ensure that you have implemented appropriate data-in-use controls throughout your application and DevOps lifecycles.

You will also want to update your supplier risk management checklist to ensure that suppliers are taking equivalent steps to secure your “data in use” inside their applications and services.

Do not be the slowest running from the bear - vulnerabilities stemming from "data-in-use" exploits is a real and present threat.

For .NET developers that want to get into implementation detail, here’s a terrific article from November’s MSDN Magazine that includes links to sample code.

(Java and/or Android developers, contact me for some platform specific instruction options)

For continuing updates on topics related to development and compliance, consider registering for one of PreEmptive's ongoing webinars.


Get a Free Trial
Tweet
Share

Categories

  • Dotfuscator

  • Dotfuscator CE

  • DashO

  • JSDefender

  • Press Releases

  • Mobile Protection

  • Risk Management

  • Support Corner

Latest Blog Posts

Protecting Java applications that use Jackson for JSON



JSON is a standard format for sharing objects and data within an application. When working in Java, there is no built-in support for JSON processing. There are, however, several widely-used libraries and options to choose from. In this article, we will focus on Jackson, which is one of the most popular.

Read more

Protecting C# applications that use AutoMapper



AutoMapper is an object-to-object mapping system used by many of our customers. It aims to simplify and organize code responsible for sharing instance values from an object of one type to an object of a different type.

Read more

Inventa, Wireless Technology Company, Protects their Android Application with DashO



Inventa, a Wireless Technology Company, Protects their Android Application with DashO

The Beginnings of Inventa

Having worked in the wireless mobile technology domain in the US, Anand Virani, became intrigued by the growing tech and wireless trends and wanted to explore the field more for himself. He noticed a boom in the Internet of Things (IoT) and that smartphones were becoming more central to how people interacted with each other at home, in the office, and in public places. What if there was a way phones could connect with each other without the need for Internet or cloud access? Smartphones were the future and Virani was determined to make a profitable business model based on this new trend.

Read more

Surgical Theater Protects their Medical Applications with Dotfuscator



Surgical Theater Protects their Medical Applications with Dotfuscator

How It All Started

How is flying a fighter plane similar to performing neurosurgery? They have more in common than you’d think. In 2005, Monty Avisar and Alon Geri, two Israeli fighter pilots were assigned to work with Lockheed Martin to build a $50 million F-16 Flight Simulator program for the Israeli Air Force to improve hand-eye coordination skills for their pilots during combat. Avisar took on the role of project manager and Geri served as senior engineer; the project was a success.

Four years later in 2009, the two finished their military service in Israel and moved to Cleveland, Ohio. Their experience working in virtual reality applications inspired them to wonder where this technology could also be applied. With several connections to surgeons, the two came to understand the ins and outs of operation procedures; in a similar way, surgeons were also working on a battlefield. What if surgeons could also train like fighter pilots and preview their surgical procedure, much like a fighter pilot could pre-fly their mission? The surgeons could pre-plan the operation from every angle and every approach to increase their situational awareness. And a year later, Surgical Theater was born.

Read more

Integrating DashO into a Maven Build



Maven is perhaps the most widely-used project management tool for Java. Based on the Project Object Model (POM), it is used not only for compilation of source code, but also dependency management, documentation, running tests, packaging, deployment, and more. We are frequently asked if we have a Maven plugin for running DashO. Though we do not offer a specific Maven plugin, adding DashO to your Maven-based project is surprisingly easy by leveraging Ant.

Read more

preemptive logo

767 Beta Dr. Suite A
Mayfield Village, OH 44143

Tel: +1 440.443.7200

solutions@preemptive.com

Latest Blog Posts

Protecting Java applications that use Jackson for JSON

December 30, 2020
Read more

Protecting C# applications that use AutoMapper

November 18, 2020
Read more

Inventa, Wireless Technology Company, Protects their Android Application with DashO

November 10, 2020
Read more

Surgical Theater Protects their Medical Applications with Dotfuscator

October 30, 2020
Read more

GlobalMed Finds Success by Switching to JSDefender

October 21, 2020
Read more

Twitter

@baldbeardbuild @GirlsWhoCode @baldbeardbuild thanks so much for inspiring us to be BUILDERS in our own community!… https://t.co/U6AyqPDhsa Jan 14 • reply • retweet • favorite

Copyright © 2020 PreEmptive

  • Home
  • Contact Support
  • Blog
  • Contact
Scroll to Top

PreEmptive uses cookies to improve the functionality of our website. By using this site, you agree to the use of cookies.