Dan Bergh Johnsson

Secure Domain Philosopher

Recorded at Domain-Driven Design 2016, January 26-29, Brussels

Bio

Agile aficionado; Domain Driven Design enthusiast; code quality craftsman, with a long time interest in security. The combination made Dan use quality practices from DDD to address application security issues - thus coining "Domain Driven Security" together with John Wilander around 2009.

Talk: Arm yourself with Domain Driven Security. It’s time to slay some security trolls…

Dan Bergh Johnsson & Daniel Deogun

We all know we have people like Anonymous, LulzSec, and NSA around. With this in mind, shouldn’t we start thinking about the security of our systems? Well, of course. But, could you turn your knowledge of DDD into an advantage for understanding and counteracting security vulnerabilities? Yes, you could. This session is about exactly that.

“Business” and “technical” attacks are two kinds of attacks, where the latter is the most famous, e g SQL Injection and Cross-Site Scripting. But this doesn’t mean business attacks are less harmful. On the contrary, attacks on the business tend to be extremely sophisticated and powerful as they often leave the infrastructure intact and trigger no alarms.

Domain Driven Security is the field that counteracts both types of attacks by using tools and mindsets from DDD in a clever way.

Hands-on: OWASP application security vulnerabilities and what Domain-Driven Security has to say about it

Dan Bergh Johnsson & Daniel Deogun

Let’s get down to the code and use our knowledge of DDD to counteract security vulnerabilities like SQL Injection, other Injection Flaws, and Cross-Site Scripting (XSS). Looking at these with a DDD mindset gives a deep understanding and sheds light over why some suggested solutions are better and some are less effective. It also gives inspiration to form better ways to avoid these vulnerabilities without having to think “security” all the time.

This workshop present the craftsmanship view of Domain Driven Security (DDSec), were we apply DDD mindset and tools to counteract security vulnerabilities, even though those tools were not originally designed with security in mind. We do not have precise figures, but adopting the Domain Driven Security mindset seems to reduce 95% of the most common application security vulnerabilities.

Finally, we hope that you will leave the workshop with an enhanced toolbox for understanding and counteracting security vulnerabilities. Upon returning from the conference you will be able to analyse your own systems and hopefully find and fix exploitable flaws before anyone else does.

Hands-on: Your business is under attack - a conceptual tour of Domain Driven Security state of the art

Dan Bergh Johnsson & Daniel Deogun

The first thing that comes to mind when talking about application security is probably a scenario where LulzSec takes over some server and gains root-privileges shell access (the gold standard of “pwned”). As interesting as these technical attacks on infrastructure might be, they only tell a small part of the tale.

The other interesting part is the business attacks. Attacks worked in the dark, so sophisticated and powerful that no alarm is triggered. Why? Because they attack the domain and prey on weaknesses of how the business is modelled and realised by the systems and their integration. This is far more serious than technical attacks. We don’t have the data, but we suspect there are lots of exploitable systems out there; many perhaps being exploited continuously without anyone being aware of it.

During this session, we’ll make a state-of-the-art tour of Domain-Driven Security, looking both at technical and business attacks; both at attacks targeting a single system and attacks exploiting weaknesses in integration. Noteworthy, the latter is becoming more interesting day-by-day as micro-service architectures grow in popularity.

An obvious example would be tricking a site to pay out money. A more extreme example could be a certificate authority (PKI CA) who’s micro-service architecture contains subtle misunderstandings in the integration, making it possible to obtain a high-class certificate without fulfilling the required authentications. Imagine who would want such a thing.

Finally, the purpose of this session is twofold: partly we want to present and water-test the ideas of the field as of today; partly we want the reflections and input from highly experienced DDD:ers to move the field of Domain Driven Security forward. We hope you want to join that discussion.