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

Trusted Computing: Panacea or Magical Thinking?

September 10, 2019 4067 Views Bill Leach

Can you tell the difference? Exception or the norm?

Of course, everyone is “for security” in principle. The hard question that each organization has to answer for themselves is “how much is enough?” Over-engineering is (by definition) excessive, and over-engineering application security can, in fact, be devastating as overly-complex algorithms, architectures and processes can compromise user experience, degrade performance and slow development velocity. On the other hand, punishment is swift for organizations that cut corners and do not effectively secure their applications, their data and, most importantly their users and business stakeholders. Finding and maintaining that balance can be time consuming and, because you can never be sure you’ve gotten it exactly right, it can also be a thankless job.

Given all of this, you can almost forgive development organizations when they are seduced into the magical thinking of “trusted computing.” Note, do not conflate magical trusted computing with Trusted Execution Environments (TEE) and its components/derivatives. The latter defines a runtime in which applications can be securely executed, while the “magical” variety offers a safe haven where bad (or clumsy) actors simply do not exist. It is a utopian dream-place where only good actors have access.

This slippery slope begins innocently enough with a well-intentioned desire to avoid over-engineering security controls whenever and wherever possible, focusing primarily on the untrusted environments. In an effort to avoid appearing tone-deaf to the underlying business objectives, analysts, architects and development organizations often frame application security requirements within a worldview that sees untrusted systems as the exception and not the rule.

Inside (not outside): one of the most magical lands of all

In Verizon’s 2019 Data Breach Investigations Report, nearly 40% of breaches were assigned to internal threat actors – and it’s probably worse than that.

The threat of malicious insiders to organizational security has historically been one of the most difficult challenges to address. Insiders often attack using authorized access and with behavior very difficult to distinguish from normal activities. This doesn’t even address scenarios where non-malicious, or unintentional, insiders are fooled by external attackers.

Further, organizations suffering insider attacks have always been reluctant to share data about those attacks publicly. While numerous regulations are imposing disclosure requirements for data loss (with the GDPR being among the most draconian), there are no such obligations tied narrowly to application exploits (unless they – as they often do –lead to subsequent data loss). Intellectual Property loss does not fall under that rubric.

Who are the typical threat actors?

The following potential threat actor personas are divided into “insiders” and “outsiders” - and depending on the specific business and the specific applications – this list may be shorter or longer.

Insiders Outsiders
Employees Professional Hackers
Contractors Competitors
Vendors Organized Crime
Business Partners Non-professional hackers
Hacktivists
Nation state intelligence/military
Malware authors

The central point here is that, even with limited public data, there is simply no evidence to suggest that any organization has been able to effectively establish and maintain an application-safe-haven able to exclude threat actors (ironically perhaps this is why there is so much interest in commercial TEE).

How much application security is enough?

Returning to the central theme – how can an organization most effectively (efficiently) find that balance between security and productivity? Trust-level must be viewed as a continuum not as a binary state. One end of this continuum might include running applications inside Trusted Execution Environments, but that is simply not feasible for all but a very narrow slice of today’s application deployment scenarios.

Looking to the most closely related (and, in fact, inseparable) domain of information security, there is certainly a paradox (if not an outright contradiction) between the guidance assigned to sensitive data versus sensitive code. There is near-universal agreement that, at a minimum, information at rest must be encrypted at all times and in all systems. HIPAA, FISMA, GDPR, and 23 NYCRR 500 are just a tiny sampling of the growing body of information security requirements that mandate encryption of sensitive data (PII, etc.).

If you were looking for more evidence that there is no safe haven “inside” an organization, ask yourself why would PII need to be encrypted when it is safely at rest inside a well-run, secure organization?

If an application accesses sensitive data or IS sensitive data (e.g. Intellectual Property, etc.), one would logically conclude that there should be controls in place commensurate (proportionate, analogous) with those in place for the associated data.

Application Flow

As with traditional information, mapping the lifecycle of an application is a fundamental step in measuring the potential for vulnerability exploitation (which, in some percentage of those cases, leads to an actual loss of some sort).

If computing trust is a continuum, where do your applications fall?

Who uses your applications and under what conditions?

While this does not paint the entire picture, measuring the number of users (within a fixed timeframe) in each of these cells and assigning an appropriate multiplier for your scenarios offers a perspective on the likelihood of an incident occurring. 10,000 unverified users accessing an application on an unmanaged device in across multiple countries should be far more concerning than a single, non-privileged employee running on an entirely managed platform.

Privileged Non-privileged Managed network Managed device Un-managed (by you) network Un-managed (by you) device Geographical distribution
Employee
Contractor
Partner
Client
Unverified

Maximizing trust – minimizing risk

Key points to keep in mind when settling out on an application security/risk management journey:

There is no magical “happy place” where protecting the Confidentiality of your software, maintaining the Integrity of your software, and controlling Access to your software no longer needs tending. Certainly, there can be a spectrum of application scenarios where the likelihood of a vulnerability exploit and the materiality of the resulting primary and secondary losses can vary widely, but there is no magical happy place where you can take off your thinking cap and ignore what is now a fundamental pillar of every application development project.

Application security cannot be managed as a silo. Whatever the strategy, it should be consistent with corresponding information security policies and practices. This consistency should include a review of any regulatory or statutory information privacy and security obligations that your organization may be subject to.

Risk can be shared, but not transferred (from a technological perspective).. Cloud providers, third party platforms, networks, and devices can simplify (or complicate) your obligations – but they can never relieve you of those obligations.

This is a journey – like every other flavor of security and risk management. No matter how appropriate your assumptions may be at the time that you make them – you must revisit them periodically. How often? Probably about as often as you revisit your information security and privacy policies.


Start 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.