Dear Junior
There was a time when security incidents where often due to bad configurations of firewalls or other deficiencies in infrastructure. Those days are long gone. According to my friends who do pen-testing (trying to get into systems while wearing a white hat) – only 5 % of their “success” are bad infrastructure. The remaining 95 % is bad applications. Applications written by programmers like you and me. Applications, which accidentally have left holes big enough for an attacker to creep through. Holes, left by programmers like you and me. Holes, which might enable an exploiter to download all the data in the database, or to install arbitrary programs on the backend servers. Or, equally bad, to use our site as a springboard to attack the rest of the world – probably starting with our customers.
There was a time when security incidents where often due to bad configurations of firewalls or other deficiencies in infrastructure. Those days are long gone. According to my friends who do pen-testing (trying to get into systems while wearing a white hat) – only 5 % of their “success” are bad infrastructure. The remaining 95 % is bad applications. Applications written by programmers like you and me. Applications, which accidentally have left holes big enough for an attacker to creep through. Holes, left by programmers like you and me. Holes, which might enable an exploiter to download all the data in the database, or to install arbitrary programs on the backend servers. Or, equally bad, to use our site as a springboard to attack the rest of the world – probably starting with our customers.
How come we leave holes in our applications? I think that we programmers in general have not yet realised that the applications we publish on public web sites (such as on-line) are routes that lead down to business critical data and business critical infrastructure. But of course they are, without access to the data, and access to the infrastructure, what value would the application have?
So, someone have to stop the outside from using our application to misuse the data and the infrastructure.
That someone is you and me.
OK, the alarm bell has rung. There are holes in the hull, ship is sinking. What do we do about it? What tools are around to grab?
I grab the Domain Driven Design toolbox and hope that clarity-of-purpose and quality-of-code will cover up at least a fair quantity of the biggest holes.
If we can use those tools to cover up e g Cross-Site Scripting and Injection attacks, then there is hope. Then we might be successful with other more complicated and subtle security problems.
That is what Domain Driven Security is about to me.
Yours
Dan
ps Using value objects can solve SQL injection in a lot of situations, but not the general case.
So, someone have to stop the outside from using our application to misuse the data and the infrastructure.
That someone is you and me.
OK, the alarm bell has rung. There are holes in the hull, ship is sinking. What do we do about it? What tools are around to grab?
I grab the Domain Driven Design toolbox and hope that clarity-of-purpose and quality-of-code will cover up at least a fair quantity of the biggest holes.
If we can use those tools to cover up e g Cross-Site Scripting and Injection attacks, then there is hope. Then we might be successful with other more complicated and subtle security problems.
That is what Domain Driven Security is about to me.
Yours
Dan
ps Using value objects can solve SQL injection in a lot of situations, but not the general case.