Managing Application Vulnerabilities (an early peek into improved controls for your code and data)

October 4, 2016 3573 Views Sebastian Holst

I’m working on an application risk management study/survey focusing on the importance of one vulnerability exploit in particular: debugger hacks against production apps. Our initial data set already includes responses from 100+ developers targeting cloud, mobile and desktop platforms from 15+ countries.

A Clear Material Application Risk for a Majority of Development Teams

58% report ongoing, sustained risk management development investments dedicated to mitigate the following material risks:

Financial theft
Intellectual property theft through application use
Intellectual property theft through application tampering and reverse engineering
Operational disruption
Regulatory and other compliance obligations
Unauthorized access to user and business data

Within the development teams that have taken affirmative action to mitigate these risks, 64% have identified unauthorized use of a debugger in production as a material vulnerability.

If you’re interested in getting the final numbers (and a deeper dive into both the risks and controls to effectively mitigate these risks), I expect to be publishing results in the next 1-2 weeks HERE (there's already a link to a related white paper on this page for download too).

Hardened Apps = Harder Target = Reduced Corporate Risk

There’s an app for that.

Apple’s (now trademarked) slogan is perhaps more telling than the company intended: Organizations rise and fall on the strength of applications — well-integrated, full-featured apps can help drive market success, while offerings more limited in scope and functionality may prove disastrous.

The sheer volume of both external and internal applications has also created a new challenge for companies: Risk management. Cybercriminals are both creating custom code and leveraging tools available on the Dark Web to compromise applications, steal corporate data and wreak network havoc.

GDPR fines were inevitable. Despite years of lead-up and months of warning before the legislation came into effect last May, many companies simply weren’t prepared for the complex (and evolving) nature of EU privacy expectations.

Now search giant Google is in the compliance law’s cross hairs: As noted by Bloomberg, Google has been assessed a $57 million fine because it “fails to adequately explain how it collects data to offer personalized advertising.” For some experts, the fine is a warning of things to come — companies must improve their data handling or face the consequences. For others, the penalties are a step too far with a purpose too vague.

The hard truth? No matter where opinions fall, GDPR fines are now out in full force — and your application could be next.

Hackers are winning. As noted by Information Age, data breach reports are up 75 percent over the last two years — while part of this increase is tied to emerging legislation and disclosure requirements, a quick look at tech headlines makes it clear that attackers are coming out ahead in the fight to keep corporate networks, applications and data secure.

But it’s not all bad news. Armed with knowledge of the current breach landscape — along with actionable insight to protect critical assets — organizations can start to even the score and put hackers on the defensive. Here’s what you need to know.

DashO 9.2 is available for immediate download and includes two powerful new controls:

1) Emulator Check, a new injectable control that

Detects when a hardened app is being executed on an emulator (even if that emulator is not rooted), and
Responds with the one or more pre-defined defenses and/or app-specific defenses – all in real-time.

Butter Knife is an annotation processing library that helps streamline boilerplate Java code in Android views. At compile time, Butter Knife annotations are processed to generate the relevant UI code to make views function properly.

When obfuscating applications that use Butter Knife, there are specific configuration patterns you should follow. The code that connects generated classes to their views uses runtime reflection under the hood. Because of this, the original name of the View is required.

When configuring DashO we need to:

Managing Application Vulnerabilities (an early peek into improved controls for your code and data)

A Clear Material Application Risk for a Majority of Development Teams

Hardened Apps = Harder Target = Reduced Corporate Risk

GDPR Goes After Google — And Your App Could be Next

Data Breaches in 2019: Why the Hackers are Winning (And What You Can do About It)

Android Developers Gain Major App Security Boost with DashO v9.2

Protecting Java Android Applications that use Butter Knife

Latest Blog Posts

Hardened Apps = Harder Target = Reduced Corporate Risk

GDPR Goes After Google — And Your App Could be Next

Data Breaches in 2019: Why the Hackers are Winning (And What You Can do About It)

Android Developers Gain Major App Security Boost with DashO v9.2

Protecting Java Android Applications that use Butter Knife

Twitter

App Protection Blogs

Managing Application Vulnerabilities (an early peek into improved controls for your code and data)

A Clear Material Application Risk for a Majority of Development Teams

Latest Blog Posts

Twitter