The GDPR includes unprecedented penalties connected to data breaches; it reaches across international borders and targets data owners and 3rd party service providers that process/manage that data.
While data governance inside IT and DevOps organizations has (justifiably) been the primary focus of GDPR compliance efforts, application development organizations should also recognize that they have been put on notice.
If your software might, perhaps even at some point in the future, process EU personal data (whether or not your company is the organization running that software)—you and/or your clients will also likely be subject to GDPR obligations and potential penalties.
If you fall into this very wide net, the following three app dev GDPR tenets probably warrant your immediate consideration:
As defined by the GDPR, a personal data breach includes data damage, loss, or unauthorized access resulting from application tampering, monitoring, or vulnerability exploit.
The GDPR personal data breach definition includes “the unlawful alteration, loss, unauthorized disclosure of, or access to, personal data transmitted, stored or otherwise processed” (formatting added here for emphasis).
Many data breaches begin with an application vulnerability exploit (elevation of privileges, for example) or application tampering (bypassing identity or other security checks using a debugger in a production setting to manipulate app data or runtime logic, for example). In both examples, an attacker can subvert the controls and restrictions an application would normally impose.
Recommendation: These risks and their corresponding mitigating controls must be included in GDPR assessments and remediation processes as appropriate. This would apply to software developed in-house and supplier risk assessments when software is licensed or used as a service.
Exploiting application vulnerabilities to gain unauthorized control over private data is a widely recognized, common attack technique.
In an ideal world, development would release vulnerability-free applications that were also immune to native and managed debugger hacks, profilers, and reverse-engineering tools. However, we do not live in an ideal world.
Secure coding practices informed by subsequent static analysis and security testing are often effective in striving for this ideal. Still, they can never guarantee a vulnerability-free application, even in the best-case scenarios. Further, secure coding practices do not address risks from unauthorized debugging, tampering, or reverse engineering hacks (since these do not rely upon vulnerability exploits for success).
Recommendation: Controls to prevent vulnerability discovery and exploitation in production settings are necessary compliments to those that minimize the likelihood that vulnerabilities are introduced in the first place.
In June 2017, 400 development organizations were asked if they had controls to mitigate these application production attacks.
* It is also worth noting that the percentages across all categories were higher for development organizations serving manufacturing, financial, and healthcare industries. In short, independent of GDPR requirements, these kinds of controls are widely deployed.
Recommendation: Application hardening can be vital in an effective GDPR compliance program and should be evaluated for inclusion within existing application and cybersecurity control frameworks. Further, as the survey responses show, application hardening is generally known to be effective against these kinds of risks and, as such, may be considered by regulators and the courts to be “reasonable” precautions that should – by implication – be in place.
PreEmptive Solutions will publish risk assessment and project implementation templates to help enterprises and System Integrators evaluate and, when appropriate, implement application-hardening GDPR controls.
If you would like to preview these templates to provide feedback (or learn more about our particular application hardening software), please email solutions@preemptive.com.