Dear Junior
As you know I have always had a soft spot for security. It has been one of my favourite non-functional requirements, both because it contains so many facets, and because it is often the one craving the most maturity from both tech-side and business-side. When starting at Omegapoint about six years ago I had two missions: to build up a Java/J2EE group, and to apply the security competence of the company into the system architecture space. The first half, well I have been doing that quite a lot with all the talented colleagues I have had the pleasure of working with. The second half has just come full circle around.
In various discussions, my colleague John Wilander and I have talked about the tangent points and crossroads of Domain Driven Design on one hand and application security a la OWASP on the other hand – coming from two different directions, but with an interested eye on the other side. We have now come so far we dare to put a label on our ideas, and we call it “Domain Driven Security”. John is really the one to explain it from the application security point of view, read his description at the OWASP Sweden blog.
I will try to say what I see from my Domain Driven Design point-of-view.
The OWASP community have identified what they classify as the top ten threats against security of applications. At the top of the current list are Cross-Site Scripting (XSS) and Injection Flaws (e g SQL Injection). So, the list points out things you should be aware of, but is not specific on how to avoid them. To me, there are good breeding ground for taking ideas from Domain Driven Design and using them as tools to address these security concerns, even though the tools were not originally designed specific for security issues.
For example XSS is an attack where some text is send in as “content” (text) and the system is fooled to interpret it as executable code, often executing it as javascript inside the browser of the victim. Likewise, the basics of SQL Injection is to write some maliciously designed value in a text field that is used as an SQL parameter – and doing so in a way that makes the malicious text become part of the query structure, bending it into doing something completely different. The underlying problem is that something intended for one context (data) is misinterpreted in another context (code) – in DDD terminology a domain model violation. My idea is that using DDD mindset and a judicious use of e g value objects could address this.
Addressing the OWASP Top Ten is however not the complete ambition of Domain Driven Security – I think it might range further than so. I see potential to also address more subtle problems with information security in different forms.
I better get a little bit more specific and give some examples. As security is something that is often surrounded by hush-hush I will tell you some stories. They might be true, they might be not; I might have been there, I might have not; it might be hearsay, it might be not.
An international Swedish retailer (there are several, selling different kinds of stuff) had an on-line order system on their website. However, if you ordered “-5” of their popular Kagazboo-stuff, the system reacted by issuing a debit note. Well, you can simply say that it is bad indata validation, but what should you validate against if not a model of the domain? And for that validation to be valuable, the model must be strict in the same way that DDD prescribes. In this case, the missing concept is “amount”, which is only allowed to be non-negative. This might have caused the retailer monetary harm as they where exploited, or it might have not as the problem was found by a pen-test team. Either is possible and plausible.
Another kind of reseller had lots of similar terminology for closely related stuff around delivery of goods and money. They where taking about “order”, “payment agreement”, “contract” and “imbursement” together with a bunch of different terms. As the company was quite big, the different departments used almost the same words. Some departments did not need the full set of terms; sometimes they used the same word with different meaning, and sometimes with the same meaning apart from some subtle detail. Well: it turned out that in some cases customers could cancel an order and get a reimbursement – even though they had not paid the goods yet. This was because the reimbursement systems thought that an order with status “final” had been paid, because that is what shipping thought, and that is where they got their data from. However, shipping only got the “payment agreements” from sales (what they called “payments” for short), and not the “imbursements” from accounting – because they had never had need for that data. Or, it might have been the other way around …
Nevertheless, the bottom line of this semantic soup is that it is totally uninteresting whether someone was right or wrong, or whoever “owned” the definition of ‘payment agreement’. For each system the terminology made perfect sense and fulfilled its purpose. However, on a ‘holistic’ scale loopholes appeared when systems where integrated. The company might have lost money, or they might have not. It might not even have happened, but as story it serves explain my idea.
The obvious, and wrong, solution would be to call everybody into a room and workshop until you had created a full Enterprise Information Model (“model in the sky”). People have tried that and it simply does not work once you scale up to the level where you need it.
However, using Context Mapping a la Strategic DDD, would concentrate on each integration and ensure that not only the right data was transformed, but also that it was interpreted in a correct way. Doing that would probably have surfaced that the integration was “conceptually broken” and the integration patterns would have changed.
So, I see an enormous potential in using Domain Driven Design to address information security problems – which I see as the goal of Domain Driven Security.
To start somewhere we are preparing a presentation for Omegapoint’s upcoming annual “competence conference” where John and I will attempt to sort out the XSS and SQL Injection problem using Domain Driven Design value objects. If that turns out well, we will try other audiences, conferences and start working with our clients.
I realise that describing this as “coming full circle” is simply not true. This is not a closing. It is the start of a really interesting field.
Yours
Dan
ps The committee for OWASP AppSec 2010 have selected to let me present this idea at the conference. Thrilling. There I will focus on using Domain Driven Security to address Injection Flaw, the validation problem, and Cross-Site Scripting