Ounces or Pounds: Application Security Practices to Protect Data in the Age of Privacy Regulation

Throughout 2018, the world was presented with some extraordinary data privacy-related headlines. From breaches and data abuse scandals to GDPR enforcement, consumers and enterprises alike grappled with the difficult truth that the consequences of data loss are far worse than many realized. Organizations must recognize the need to address these repercussions swiftly and thoroughly, especially with increasing regulatory pressure, but this is much easier said than done.

Public awareness on the value of data is on the rise, as we are regularly bombarded with new headlines about data loss or misuse. Seemingly innocuous or unrelated data points are now being harnessed to yield surprising and invasive inferences about users. Scandals such as Facebook-Cambridge Analytica and revelations about common applications harvesting data for purposes beyond their advertised functionality have, naturally, heightened concern and brought urgent calls for increased regulation.

In addition to all of this data abuse-related news coverage, the arrival of the European Union’s General Data Protection Regulation (GDPR) also magnified public and corporate awareness by threatening steep financial penalties for non-compliance. Even past its May 2018 enforcement deadline, businesses worldwide continue to struggle with meeting the stringent requirements. Fewer than 50% of GDPR subject-respondents to the IPP-EY Annual Governance Report 2018 considered themselves “fully compliant” with GDPR at the time of the survey.

Such compliance struggles are understandable, given the fact most applications have been developed solely with functionality in mind. If security is considered during the design phase, it’s often of secondary importance, and ultimately becomes the first sacrifice made when budget or timeline constraints arise. It should not be a surprise to anyone that applications are among the highest risk attack vectors for data theft; the enormous Equifax data breach of 2017, for example, was the result of an exploited Apache Struts vulnerability.

Modern organizations may have placed a heavy reliance on applications for operational synchronization and efficiency, but few prioritize the maintenance (or creation) of detailed data flow diagrams to match their increasing portfolio footprints and interconnectivity. Applications grow, evolve, and integrate frequently without revisions of architecture diagrams, data flows, or the regulatory implications of each change, leaving vast, interconnected application portfolios and minimal visibility into their attack surfaces or the data flowing throughout them.

Enterprise Application Security teams now face a herculean task; effectively communicate the criticality of data protection, anticipate upcoming regulatory compliance obligations, and effectively secure the data flowing throughout complex enterprise application portfolios.

So where, exactly, should an organization begin? Although there are no silver bullets or cookie cutters, there are buzzwords! One of the most effective approaches is to integrate preventative security practices earlier into the pre-development phases of the SDLC, or “shift left.” This term has become something of a catch-all in the industry, so let’s break down some specifics.

We need to start by addressing what many organizations consider “AppSec.” For many, Application Security practices consist solely of post-implementation testing, such as static (SAST), dynamic (DAST), and interactive scanning (IAST). While these tools are excellent at detecting flaws in completed code and providing recommendations for remediation, they should not be relied upon alone; doing so would be the equivalent of conducting a walk-through inspection of your newly-constructed house… without ever having confirmed the architect’s plans were structurally sound before building.

Instead, opt for a full-lifecycle approach by shifting left and integrating the following pre-implementation practices into your SDLC:

• Regulatory Context and Requirements Gathering
  • While gathering functional business requirements, expressly include those relating to an application’s regulatory context (defined in ISO 27034-1 as, “all laws, regulations, and common rules stemming from the territory or jurisdiction, and which impact the application’s functionality or its utilization of data”).
• Secure Design Reviews & Threat Modeling
  • Many teams skip secure design reviews and threat modeling, considering them tabletop exercises with little real value. When done properly, though, this couldn’t be further from the truth; these reviews translate into tangible financial savings by reducing costly redesigns in the future. NIST estimates that the costs of addressing flaws during post-development testing are 10x higher than addressing them during requirements gathering. If the application makes it to production, that cost increases as high as 30x.
• Documentation Creation and Maintenance
  • Considering the rapid adoption pace of privacy laws, even businesses not currently impacted by regulation should expect it in the coming years. Producing and maintaining accurate security documentation will be essential for assessing applicability and compliance costs of each new regulation, providing a clear inventory of risks and controls among existing and legacy applications.

Early-SDLC stage Application Security practices are more difficult to adopt than tools; they are neither neatly-packaged nor come with installation guides, and designing programs to include them takes significant resource coordination. The investment, however, is worth it.

Programs that integrate early stage Application Security practices not only better protect the data flowing through current application portfolios, but also lay the groundwork for easier compliance with expanded data privacy-centric regulations down the line. The ounce of AppSec prevention will prove well worth a pound of cure.