When it comes to integrating security into a larger business process we fortunately have some prior art to draw on, namely the several Security Development Lifecycle frameworks that exist today, such as Microsoft's SDL, BSIMM, etc. These frameworks take an approach to security whereby they attempt to lay out a strategy and well defined goals that can be integrated into you software development process. Some of them also use an optimised or maturity model so that security can be integrated in stages rather than trying to shift the mountain that is your 'current practice' all in one go.
I really like this approach. I think this approach can be applied to mitigating threats as well. Even better, I'm going to give it a catchy name, a Mitigation Maturity Model (MMM). Alliteration fans go wild.
The reason why I think a maturity approach works well for mitigations (admittedly not all of them), is that it is a business reality that the ideal technical solution cannot magically be applied to any large application.
To make this more concrete I have come up with an XSS MMM.
- (None) - No specific mitigation. Input validation may prevent some XSS.
- (Basic) - Manual mitigation. Specific output encoding is being applied on a 'best efforts' basis. Developers have been trained in the problem and the solution and perhaps an encoding library has been developed to simplify the process. There is no testing for XSS.
- (Intermediate) - Automate mitigation. Automatic contextual output encoding is being done based on a 'best effort' at detecting where code/data is being written to HTML/JS/CSS. There are likely some exceptions to this in certain places where the complexity makes automating the process difficult, but most pages get the benefit. Developers receive mandatory training on the dangers. Testing is focused on those areas that do not get autmated encoding.
- (Advanced) - Mitigation by design. Rigerous automated contextual output encoding is applied, made possible by the complete separation of HTML from JS from CSS. A handful of exceptions exist but these are rigerously tested.
I also believe that the MMM can actually be applied separately to existing code and new code; they needn't be at the same level. It makes sense that new code should aim to be at a higher maturity level than existing code. The effort to mature exsiting code can be considerable, and it's always going to be a business decision to spend time refactoring old code.
Finally, one last parting shot at the XSS mitigation advice out on the Internet today. If we look at the XSS MMM as I have laid it out, at what maturity level would the standard advice of contextual output encoding sit? Basic. It's no wonder then that XSS is still such a massive problem on the Internet if that is the maturity level of the advice the security community is offering.