DashO Root Detection & Defense is one Check that will not bounce!
- Android-O support,
- Kotlin support,
- Improvements to our Android Wizard, and
- Build performance improvements.
BUT the feature I’m most excited about is the addition of our latest Check Type, Android Root Detection.
I’m excited because our approach to real-time security continues to be unique and root detection is exactly the kind of scenario to highlight our approach.
In order to make my case, I need to take a step back and define what we mean at PreEmptive when we refer to a “Check” or a “Check Type.”
A Check in PreEmptive parlance refers to a real-time incident detection and response framework that includes the logic to check for an incident occurrence and a rich variety of response and alert options.
Check Types refer to the kinds of incidents we can look for (detect) and respond to.
Today, on Java, Android, and .NET, we have Checks (Check Type support) for application tampering, the presence of a managed or native debugger at runtime, absolute and relative timeframe expiry, and (now) rooted Android devices.
The most significant advantage that our approach offers is functional scope including:
- Incident detection: There are many ways to detect a rooted Android device – we use lots of them combined with heuristics to ensure accuracy. This “ambiguity” extends to debugger detection and our other checks as well. Your developers don’t need to keep up with these moving targets – that’s what we do.
- Incident response
- Turnkey real-time incident response options with no coding or training include throwing exceptions, suspending an application, and exiting an application,
- Turnkey real-time alerts that can include a broad set of metadata with offline-caching and encryption over the wire built-in; also implemented with no coding whatsoever
- Extended incident response and real-time alert behaviors that incorporate your application-specific or custom code to address context-specific operational or risk-related requirements that only you understand.
Regardless of the platform or the Check Type, the Check framework is consistent and that offers a whole lot of advantages over setting a flag inside a program with an API and requiring developers to code their own response.
PreEmptive Checks are INJECTED post compile – and can be done at the same time (or independently) of obfuscation. Our approach to injection allows for the injection of our code AND yours – offering the best of both worlds.
Here’s a more complete comparison of the advantages of using injection specifically to implement application detection and response controls.
Control Implementation Characteristics
Post-compile Injection |
Programming | |
|---|---|---|
| Complexity | Low: specialized behaviors such as incident detection or offline-caching of data are delivered as “turnkey” (no coding) | High: each application presents its own unique set of implementation requirements that must be designed and tested as “first class” features. |
| Effort and training | Low: injection patterns and configurations can be reused and shared across builds, releases, and applications. | High: expertise and effort required will increase proportionately to the number of applications and development teams managed. |
| Flexibility | Low: injection targets are often limited to method entry and exit points and highly customized interaction with other application functionality may be constrained as well. | High: controls implemented as code within an application have no inherent limitations. |
| Scalability | High: injection tasks can be included in build and deployment workflows through a centralized process ensuring consist and effective use. | Low: compliance must compete with the development’s backlog of fixes and features – application-by-application. |
| Transparency & Auditability | High: as a part of the build and deployment workflow, successful use is logged and archived. The log can be used to guarantee functional compliance and proof of compliance. | Low: proving to auditors or end-users that controls are present and do no more (or less) than documented would require code review rather than documentation review. |
Why is our Check framework ideal of managing risks stemming from running an application on a rooted device? Root detection requires an evolving set of heuristics to ensure accurate results. We invest on keeping our algorithms up-to-date.
Once detected, appropriate responses will be highly variable based upon:
- the application (banking or a medical device)
- the application owner’s appetite for risk
- the regulations governing the application, the application owner, and the user
Our unique combination of turnkey and extensibility functions ensure that you will be able to hit the right mix of defensive, reporting, and privacy features and you will be able to evolve them as needed.
In order to manage risk effectively, you have to manage it consistently. Our integration into production DevOps build and deploy pipelines ensures that your controls will be applied consistently and you will have the audit logs to verify your compliance.
Learn more about DashO for Java and Android (and evaluate the software) here.
