Sunday, 11 December 2016

The Pollution Analogy




Finding a security vulnerability is questioning the entire development pipeline and quality control. How it is possible that these massive gaps, these massive security vulnerabilities and code patterns weren't picked up before. Weren't they understood by the development teams, by the testers, by QA, by the clients?

Even worse, can't the current NOC and log monitoring detect those when those vulnerabilities are initially probed and ultimately exploited?

We need to make this pollution visible.


One positive side of using the pollution analogy, is that security doesn't need to say no all time. Instead of saying "You can't do XYZ", AppSec says "If you want to go for feature A in a specific timeline, in a specific scope with a specific brief, then you will have this residual pollution, and these unintended consequences".

You could also have a situation where security says, "Well, if you go in 'that' direction, currently we don't know what are its consequences or security site-effects, so the business owner will have to accept the risk that there is an unknown set of risks which are also not clearly understood".


This is analogous to the evolution of pollution.

The first phase of industrial pollution saw pollution as a necessary side effect of progress, with some fines for the worse offenders (the 'polluter pay' model).




[^david-rice-pollution]: See AppSec USA 2010 Keynote "Upon the Threshold of Opportunity" , and "When talking about Application Security and Software Quality, Pollution is a much better analogy than Technical Debt"
