When talking about Application Security and Software Quality, Pollution is a much better analogy than Technical Debt

One of the analogies that I make in my "New Era of Software with modern Application Security"  presentation is that Pollution is a much better way to describe quality (and security) issues (vs Technical Debt):

 


This analogy is inspired by David Rice's amazing keynote at OWASP AppSec USA 2010 "Upon the threshold of opportunity" (which you can see the video here)

David Rice is the author of the also amazing Geekonomics book, which really shows The Real Cost of Insecure Software

Unfortunately, David Rice after going to work for Apple, seems to have disappeared from the internet, which is a great loss for the world, since he was doing amazing research (of course that I'm sure he is doing great stuff for Apple, but it is a shame that we are not able to learn from him anymore)

David's http://blog.geekonomicsbook.com/ book site is down, but luckily the wayback machine was able to get a copy of the page with the abstract of this talk:

In the 1960s, pollution in the United States reached a breaking point. Large corporations, by and large, had been unresponsive to environmental issues leaving the nation's skies filled with smog, rivers filled with sludge, forests defoliated by acid rain, and fresh water lakes declared "dead." The natural heritage of the nation was being destroyed by its industrial prosperity.

The U.S. response was a series of less-than-satisfactory regulatory attempts to correct for substantial environmental damage. Faced with serious and costly legacy issues of industrialism however, many companies stonewalled and delayed for much of the 1980s and 1990s, emphasizing legal compliance and reactionary practices over real progress. The turn of the century ushered in a fresh perspective in corporate America, with companies like GE, DuPont, and Wal-Mart actively pursuing sustainability initiatives linked to corporate performance, transforming environmental crisis into financial opportunity. What happened?

Within the story of the U.S. battle against environmental pollution lies key lessons for confronting the equivalent of pollution in cyberspace: software vulnerabilities. The toxic effluence of software vulnerabilities leave networks saturated with spam, computers clogged with malware, and servers defoliated of sensitive private data.

To date, a series of less-than-satisfactory regulatory attempts – such as PCI, SOX, and data breach laws – have been enacted to address what appears to be widespread unresponsiveness to the substantial harm to the global digital eco-system caused by unrestricted vulnerability dumping. Faced with serious and costly legacy issues of poorly implemented software systems however, many companies continue to stonewall or delay security programs, emphasizing legal compliance and reactionary practices while demonstrating no real improvement. What would it take to change this, to turn the crisis of “pollution” in cyberspace into an opportunity?

This keynote highlights a possible fresh perspective, putting software security into the context of social responsibility linked to corporate performance, illustrating how the software market - like corporate America - stands upon the threshold of its greatest opportunity.

Related posts:

• Is Quality is a measure of how successful a product is in what it is SUPPOSED to do?

"New Era of Software with modern Application Security" presentation (v1.0)

This is the final slide deck of the "New Era of Software with modern Application Security" presentation I delivered at Codemotion Rome, which was a developer-focused conference (with 2000 tickets sold).

Description: "This presentation will start with an overview of the current state of Application Insecurity (with practical examples). This will make the attendees think twice about what is about to happen to their applications. The solution is to leverage a new generation of application security thinking such as: TDD, Docker, Test Automation, Static Analysis, cleaver Fuzzing, JIRA Risk workflows, Kanban, micro web services visualization, and ELK. These practices will not only make applications/software more secure/resilient, but it allow them to be developed in a much more efficient, cheaper and productive"

Simple Threat Model (template) - Good place to start

When teaching about Threat Models, the most common question I get is 'How do I start?'.

To make this process easier, I usually recommend to use the simple '1 page Threat Model' which you can see on the right ( download here)

The idea is to kickstart the process by mapping out the:

1. Data Flow Diagrams (i.e app architecture)
2. Entry Points (i.e Attack surface)
3. Assets (i.e. what is valuable and needs to be protected)
4. External Dependencies and Trust Levels
5. Threats(edited)

Another great source of (first steps on Threat Modelling) resources are the Microsofts' At a Glance: Web Application Threat Modeling and OWASP's Application Threat Modeling pages 

JIRA RISK workflow handling of 'Risk Fatigue'

On a email thread related to Updated JIRA RISK workflow (now with a 'Fixing' State), I received this great question:

I really like the idea of forcing someone to almost sign that they accept the risk. Forces them to really think about it.

One thing I'm curious about is whether there is such as thing as "risk fatigue" like you have "monitoring fatigue". So, the first few times you accept risk you do so with a heavy heart, but each time you do it and there are no perceived negative consequences, it gets a little easier. That is until the point when you're completely exposed and something bad does actually happen. Having said that, the alternative of not physically accepting the risk in some way is far worse IMO, and that by using something like Jira you can at least measure the ratio of fixed vs risk accepted over time. Hopefully it moves in the right direction!

And here is my answer:

Updated JIRA RISK workflow (now with a 'Fixing' State)

As an improvement of the workflow I showed at JIRA Workflows for handing AppSec RISKS here is a version that adds a 'Fixing' state between 'Allocated for Fix' and ‘Test Fix’.

The reason for this change, was to take into account projects (or components) that have a large number of open issues that want to be fixed (vs risks to be accepted).

Since we try to use an Kanban 'Work in Progress' model for the issues to fix (i.e. no more than 3 to 4 active items), this new state helps to keep a nice separation between the issues that:

• need to be 'Risk Accepted' (i.e. there is no intention (or resources) to fix in the next couple months)
• have been reviewed and are 'Allocated for Fix'
• are currently being worked on (i.e. in a 'Fixing' state)

Presenting at OWASP AppSecEU on "Using JIRA to manage Risks and Security Champions activities"

I just received this nice invitation from the OWASP AppSec EU today:

My plan is to use this opportunity to document the JIRA workflows that I have been creating and implementing (when acting as Head of Application Security)

Here are a couple related posts:

• JIRA Workflows for handing AppSec RISKS 
• What are Security Champions and what do they do? 
• Does your team has a Security Champion? If not, get this Mug and Library 
• "New Era of Software with modern Application Security" updated presentation (v.0.6)