In the first "peek" into our soon to be published application risk management survey results, we shared that 58% of the respondents reported making ongoing development investments specifically to manage “application risk.” See Managing Application Vulnerabilities (an early peek into improved controls for your code and data)
Digging into the survey numbers, respondents divided their “application risk” into six subcategories and in the following proportions:
| Risk Subcategories | % of respondents reporting app risk |
|---|---|
| Intellectual property (IP) theft from code analysis (via reverse engineering) | 38% |
| Data loss and (non-application) trade secret theft | 37% |
| IP theft through app abuse (elevated privilege, unauthorized data access, etc.) | 36% |
| Operational disruption (malware, DDoS, etc.) | 32% |
| Regulatory and other compliance violations (privacy, financial, quality, audit, etc.) | 26% |
| Financial theft | 18% |
It’s important to keep in mind that the risks enumerated above are NOT synonymous with technical vulnerabilities; there are multiple paths that a bad actor can take (for example) to “misappropriate” IP and trade secrets – multiple technical vulnerabilities to exploit – and multiple non-technical vulnerabilities too of course (social engineering, armed robbery, etc.).
The table above shows that, while financial theft is surely among the most significant risks most any business faces, only 18% of the development teams in our survey work on applications where attacks against their applications in particular might reasonably lead to financial theft.
Production debugger use for hacking and tampering left unchecked
The survey showed that, while development teams were invested in mitigating these six application risk categories, a majority of development teams did not have effective controls to prevent one specific technical vulnerability; the unauthorized use of a debugger against applications running in production.
In fact, in every risk category, the majority of development teams:
- Recognized that this kind of debugger attack IS a material threat, AND
- Acknowledged that they DO NOT have adequate controls in place to mitigate this threat.
For illustration, lets dig deeper into one of the six risk categories to see how this pattern plays out.
Digging deeper: IP theft from code
The chart below shows that 84% of respondents who identified IP theft from their code as a material risk also identified production debugger hacking as a significant and Unprotected technical vulnerability.
Risks are like potato chips; you can ever have just one
Unmanaged technical vulnerabilities are never a good thing, but this gets exponentially worse if a single vulnerability increases risk across multiple risk categories rather than just one. …and, according to our survey respondents, failing to prevent production debugger hacking most definitely falls squarely into this category.
To further raise the stakes for development teams, our survey clearly showed a strong correlation across risk categories. In other words, once an application has the potential to pose one kind of risk, it is extremely likely that it will pose a risk across multiple categories – thus increasing the potential damage of unchecked technical vulnerabilities like production debugger hacking.
Digging (even) deeper: IP theft from code risk as a leading indicator for additional application risks
According to our respondents, apps that have IP inside code that need protecting are much more likely to pose additional risks as well.
What's the take-a-way from the illustration above?
If you're protecting IP inside your app - you're over 11 times more likely than other development groups to ALSO have IP at risk from app attacks even though that IP lives outside of your app. ...and you're roughly 2X more likely to face risks across the remaining four application risk categories...
Also, if you've got un-managed technical vulnerabilities - to the extent that these vulnerabilities may factor into multiple risk categories, the danger each vulnerability poses is likely to be many times greater than you suspect.
If you’re interested in getting the final numbers (and an even 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 so check that out now if you like).
No comments:
Post a Comment