Another Application Vulnerability for Which There Is No Fix

Garbage in and garbage out is shorthand for “incorrect or poor quality data will always produce faulty results.”

The “garbage data” vulnerability is especially gnarly because there is no fix or cure.

The only viable development strategy is avoidance.

In short, well-written applications take every opportunity to verify and validate data (and to avoid generating garbage data that would ultimately pollute subsequent “downstream” data processing).

Compromised in, compromised out is a modern shorthand for another class of application vulnerability for which there is no fix.

Leaked or otherwise compromised data will always produce compromised results.

Consider the following compromised in, compromised out scenarios:

• A “bad actor” uses leaked social security and credit data to apply for a loan. Even a hypothetical “perfect” financial system (bug-free, securely coded, and effectively managed) will process the improper loan, transfer the misappropriated funds, and corrupt otherwise accurate credit histories.
• A user gains unauthorized privileges via compromised identity data (through theft or an application exploit). She is now unstoppable as she moves through your organization’s systems, able to further compromise and leak business and personal data at will.

Compromised data is not “garbage data” in the development sense of the word in that

• Data verification routines cannot (in the general case) verify data provenance (where data values have been stored, viewed, shared, etc., in the past or by other systems and users),
• Data governance is ultimately defined by 3rd parties (regulators, legislators, law enforcement, etc), and
• As such, subsequent “compromised results” will not only include bad outcomes like unauthorized bank loans, but they can also include criminal penalties, fines, civil damages, reputational damage, market devaluation, higher cost of capital, etc.

Yet, compromised data is like garbage data in that developers have no viable defense other than avoidance.

As with “garbage data,” well-written applications must take every opportunity to

• Prevent, detect, respond, and report on attempts to compromise data (both successful and failed attempts),
• Avoid being the instrument of compromise—the vector of an attack that compromises data—polluting downstream application processing.

A Breached Application Breaches Completely

Every application feeding your operation—no matter how small—whether developed by your organization or not—running inside your business or “upstream” inside your suppliers’ and partners’ networks has the potential to pollute (compromise) the systems they feed.

Sound extreme? Consider “Anatomy of the Target data breach: Missed opportunities and lessons learned,” where one of the most damaging data breaches in recent history began with an attack on an air conditioner supplier. Hackers surfed that compromised data stream into Target’s most valuable customer data.

Consider recent regulations like the EU’s GDPR or the recent recommendations from the UK on cybersecurity inside smart cars. Both identify the shared responsibilities of application development organizations across corporate and even international borders to mitigate material privacy, financial, and safety risks—down to small gaps in seemingly minor application functions.

It has never been more important for development organizations to include reasonable, scalable, and reliable controls to avoid, detect, and remediate application exploits—everywhere, not just in obvious, flagship systems.