Gartner calls In-App Protection “crucial” in their July 2019 Market Guide for In-App Protection. The guide’s summary advises security and risk management leaders to “take due care in protecting their application clients” in order to avoid “security failure.”
This raises the question—what constitutes “due care?” No development organization looks to recklessly expose their applications or sensitive data to attack or compromise. On the other hand, over-engineered (or poorly engineered) security controls can quickly lead to excessive development costs, performance and quality issues, and, ultimately, unacceptable user experiences. While terms and terminology may vary, there is broad consensus on best defining “due care” for any given application/user scenario.
Standards for “due care” must include, and will be proportional to:
But this is only half of the story. In-app security controls (as with any other control) bring their own set of costs and risks. In other words, there’s no such thing as a risk-free compensating control.
To effectively manage application and information risk, the costs and risks stemming from the controls themselves must be measured and, wherever possible, minimized.
Failure to effectively manage these countervailing risks often leads to development cost and schedule overruns and, perhaps more critically, to increased—rather than decreased—application risk.
Measuring the cost/impact of in-app protection includes:
As an example, let’s look at how the General Data Protection Regulation (GDPR) balances these two categories of risk to set their standard for “appropriate technical and organizational measures” (which is essentially what Gartner termed “due care”).
Article 25 of the GDPR, Data Protection by Design and by Default, opens with the following (italics added for emphasis):
The entire “Data protection by design and by default” framework is bracketed by two broad categories of risk:
GDPR defines appropriate technical and organizational measures using two categories of risk | |
---|---|
Organic Risk Factors | Control Risk Factors |
The nature, scope, context and purposes of processing (sensitivity of processing) | State of the art: processors are measured against processors across the supply chain – this is a new and more expansive definition |
The risks of varying likelihood and severity (likelihood and damage of an incident occurrence) | Cost of implementation: GDPR does not segment cost into subcategories like financial, time, training, staff, etc. It is all-inclusive |
Integrate the necessary safeguards into the processing: this encompasses packaging, deployment, support and updates |
GDPR gives more attention to the factors that might be used to excuse the exclusion of a control (e.g., because it is too expensive or complex or might compromise “necessary processing safeguards”) than it does to enumerating the “organic” risk factors themselves!
…but wait, there’s more.
Ignorance of risk factors is never an excuse. For example, not knowing that sensitive data should be encrypted “at rest” and “in transit” does not limit your liability if/when hackers exfiltrate unencrypted data. Ignorance of a well-understood and manageable risk substantially increases liability.
Likewise, not knowing that there are established techniques to detect application tampering or prevent access to sensitive data “in use” (both examples of in-app protection capabilities) increases liability. Ignorance of well-understood, widely accepted in-app protection implementation patterns will substantially increase liability.
The following table highlights in-app protection patterns that we have included with PreEmptive Protection products in various forms over the past twenty years and which our customers have successfully integrated into applications across virtually every industry, geography, and device.
While PreEmptive Protection does not have a monopoly on these patterns, our track record surely establishes them as “well-understood,” “safe,” and “widely accepted.”
The table maps PreEmptive Protection patterns to the specific control risks they mitigate. Development risk and liability will increase with each missing in-app protection feature.
Accepted patterns | Time Reduction | Minimal training | Simplified SDLC | Platform support | Compliance | Performance & quality |
---|---|---|---|---|---|---|
Post-code processing | ||||||
IDE DevOps integration | ||||||
Updated detective controls | ||||||
Turnkey detective response | ||||||
App-centric response | ||||||
100% standard obfuscation | ||||||
Auto detect frameworks | ||||||
Wizards |
Table 1: Mapping PreEmptive Protection in-app protection features to reduce App Control Risk factors.
Post-code processing: Operating on compiled components frees developers from most in-app protection configuration and packaging work. This reduces effort training and expertise requirements.
IDE DevOps integration: Integration with preferred DevOps pipelines improves automation, scale, and auditability.
Updated detective controls: Bad actors work as hard at evading detection as they do at tampering, etc. In-app protection solutions with frequent and streamlined update processes are essential to maintaining consistent and effective risk management control.
Turnkey detective response: Relying on predefined, tested, and accepted responses simplifies implementation and audit efforts.
App-centric response: Extensibility expands the utility of controls to app-specific requirements without forcing a wholly customized response.
100% standard obfuscation: Ensuring that transformations only generate standard runtime output (whether .NET, Android, Desktop Java, etc.) maximizes platform support and forward compatibility and simplifies testing requirements.
Auto-detect frameworks: Post-code processing with autodetection of popular frameworks, including XAML, Xamarin, Android, etc., reduces configuration efforts, testing, and quality risk, as each framework will have been tested as part of PreEmptive Protection’s own release process.
Wizards: Guided configuration reduces training, requires expertise, and shortens completion time.
Subscription: A subscription offers the lowest annual cost and is all-inclusive. Organizations have exactly what they need, when and where they need it.
Dev Team license: PreEmptive Protection licensing does not limit (or charge) your application deployments and usage. PreEmptive will not tax your velocity and adoption successes.
When “taking due care” to secure your apps and data with in-app protection, leverage accepted and well-understood development patterns to minimize configuration, implementation, and training overhead without compromising the quality, performance, portability, or user experience of your applications. This will guarantee that your controls are effective and up-to-date – helping to secure your apps and data while cost-effectively meeting your compliance obligations.