Friday, March 14, 2014

Application Analytics: Security and Privacy for All

In my previous post, I tried to illustrate the distinction between required capabilities and desired capabilities – and how, with application analytics, this distinction is particularly tricky since true requirements are more likely to come from the users of apps versus the developers of apps (the latter being the app analytics customer and the former – app end users – are often completely out of reach from the analytics solution provider).

I also posited that the most common areas where end user requirements drive important app analytics requirements fall into performance, quality, security, and privacy domains.

In this post, I’m going to drill down into security and privacy a bit. Let’s break out the application analytics supply chain into four parts; Telemetry creation, ingestion, processing, and publication.
  • Telemetry creation (where the app itself or an external agent actually creates the raw telemetry)
  • Ingestion (the steps required to bundle, transport, and deliver the raw data for processing)
  • Processing (parsing, indexing, computing, aggregating, storage, etc. required to transform raw telemetry into publish-ready data) 
  • Publication (the selection, transformation, formatting, and delivery of targeted data to a specific user or external system)

Figure 1: Application Analytics Supply Chain: the dicey part is that application telemetry is typically collected in the context of the “App User’s” world subject to their expectations for privacy, security, etc. and then must be delivered across a great divide into the “App Analytics” user’s world. Application analytics solutions must enforce whatever "app user" policies are required during app usage, then navigate the ingestion process that typically bridges the two worlds, and finally help maintain whatever data governance obligations app users (or their legislatures) require. 

PreEmptive Analytics

To make this “real” and for illustration purposes – here’s a summary of the features offered within PreEmptive Analytics that target these security and privacy challenges. 

Telemetry Creation

Application instrumentation

Activation: No “accidental” or “inadvertent” application monitoring. Application instrumentation is typically accomplished through post-compile injection. The default setting is “off.” In other words, injection must be manually activated avoiding “accidental” application instrumentation. 

Configuration: No data, other than what is explicitly requested by development, is ever transmitted. Once “activated,” each individual data component must then be explicitly identified for data capture. This is true for either the injection pattern or when using the PreEmptive Analytics API directly inside an app’s code. 


Definition: PreEmptive Analytics “opt-in” requires a Boolean “True” value to be set before any data monitoring functionality is initiated (which is prior to transmission). The default value of this setting is “False” and must be explicitly reset by the application at the start of every application session. There are, in fact, two opt-in settings. The first covers general usage and the second covers exception monitoring.
  • Application usage: opt-in covers session, feature and system data previously identified by development prior to deployment. 
  • Exception monitoring: opt-in covers unhandled, caught and thrown exception data previously identified by development prior to deployment. 

Privacy Policy

PreEmptive Analytics permits development to encode a link to the company’s own privacy policy that can be communicated to an end-user prior (or during) a request for an informed consent to opt-in. 


Data transmission

SSL Encryption: by default, all data transmitted from an application to an endpoint is first encrypted before transmission. This can only be overridden by development prior to the release of the application. 

Content Management

Runtime data collected for management and analysis is owned by the development organization. PreEmptive Solutions has no access and no rights to reuse runtime data – either in part or in aggregate.
  • On-premises: Endpoints that are “on-premises” or “client-managed” are completely under the development organization’s control. 
  • Managed service: Data managed by endpoints owned by PreEmptive Solutions are managed solely for our clients’ benefit. There is no other access or use authorized or permitted. 


In addition to PreEmptive component localized authentication, application, identity, and role-based frameworks are respected and enforced, e.g. you cannot provision a TFS project of PreEmptive Analytics without (at least) Admin privileges for that TFS project.

Application security (bonus)

In addition to the thorough, “end-to-end,” approach to information security and privacy, PreEmptive Solutions also provides technology and associated controls to minimize the risk of application reverse engineering or tampering that may lead to the disclosure of application vulnerabilities that can be exploited or the tampering (modification) of applications to alter behavior (to introduce exploitable vulnerabilities where none had previously existed). These include: 

Preventative controls

Obfuscation: prevents reverse engineering and recompilation. 

Detective controls

Tamper detection and defense: provides real-time defense and alert notification when application tampering (modification post-compile) has been detected.

Taken as a whole, PreEmptive Analytics is designed to provide a complete and comprehensive application analytics security and privacy solution – built to encode and enforce the wide variety (and ever-evolving) application and information security and privacy policies, mandates and controls.

As application analytics evolves beyond tracking marketing funnels on the internet, the entire application analytics pipeline will (must) be governed by the same security and privacy policies as the applications they are monitoring and the business and operational content that your organization is managing.

No comments: