Rhag ofn eich bod chi’n meddwl fy mod i draw yn Iwerddon ond am hwyl (Dwi yn cael hwyl, ond dim dyna yw’r unig reswm bod ‘ma), fe ges i un o’r amseroedd ‘na lle glywais i rywbeth sydd wedi gwneud i fi ail-feddwl fy marn ar bwnc yn ystod trafodaeth ar ddatblygu meddalwedd diogel.
Dwedodd un o’r bobl o’n i yn cyfweld:
Lest you think that I’m over on the Emerald Isle for fun (I’m having fun, but that’s not the primary purpose of my visit), I had one of those “wait, what? oh yeah…” moments during a discussion on secure applications development.
It centred around the this analogy (edit 21:18 – given by the interviewee):
“If we taught people to drive the same way we teach people to do secure code, then we’d have a lot more dead people and destroyed cars”
Dwi ddim yn sicr faint ohonoch sydd wedi bod ar gwrs datblygu meddalwedd diogel (fyswn i yn tybio ddim llawer), ond y tueddiad yw rhoi amser hir ar dangos beth sy’n gallu digwydd os bod chi’n gwneud pethau yn anghywir, ac wedyn treulio amser byr iawn yn dangos y ffordd gywir o wneud y peth. Yn dilyn o’r cydweddiad blaenorol, dwedodd y sawl bod ‘ny fel gadael i bobl cael damwain erchyll yn ei char, ac wedyn dweud “paid gwneud ‘ny…”.
Felly, y cwestiwn yw… ‘da ni’n dysgu’r pethau ‘ma’r ffordd gywir? Ydi hi ddim yn well dangos y ffordd gywir i ddelio gyda mewnbwn gan ddefnyddwyr, strwythur SQL, neu wallau o’r meddalwedd? Ar ôl gwneud ‘ny, dangos iddyn nhw beth sy’n gallu digwydd os bod nhw ddim yn gwneud beth da ni’n argymell. Ond hefyd, ydi’r fath beth yn dibynnu ar y dechnoleg sy’n cael ei defnyddio, a’r systemau sy’n cael ei adeiladu i adolygu’r cod wedyn? Efallai bod yr ateb ddim mor haws a dwi’n disgwyl.
Mae’n syniad diddorol i mi, ac yn un fyswn i yn hoffi datblygu yn bellach… os bod gennych chi unrhyw feddyliau, fyswn i yn hoffi clywed nhw. Dwi am geisio hefyd cynnal sesiwn ar hwn yn ystod Barcamp Llundain dros y penwythnos.
I don’t know how many of you have been on a secure coding course (I’d hazard a guess and say “not many”), their tendency is to spend most of the time showing you what goes wrong (“look at how bad SQL injection can be!”), then spend a tiny fraction of that time showing you how to do it right.
If we continue from our Continuing his analogy, the Interviewee said it would be akin to letting someone crash a car, and then saying “don’t do that…”.
So, my question is this… are we teaching these things the wrong way around? Is it not better to show people the correct way to handle things like user input, SQL queries, or error handling? Once we show them the right way, we can then move to show them what happens when it goes wrong. Having said that, any of these types of training guidelines would depend on the technology being used, and the associated infrastructure for reviewing the code afterwards, so maybe the answer isn’t as clear as we’d like it to be.
It’s an interesting idea, and one I’d like to explore further… if you have any thoughts, I’d love to hear from you. If I do manage to nab some time, hoping to do a session on it at Barcamp London.
Diweddaru | Update – 29/10/11
So I ran the session at Barcamp London, you can see the slides here:
Well, dwi wedi gwneud y sesiwn nawr yn Barcamp:
Sesiwn reit dda, gyda trafodaeth diddorol. Disgwyl nawr i cael rhagor o adborth dros y dyddiau nesaf.
An pretty good session, with a very interesting debate. Now to wait for some more feedback over the next few days.
Hwyl!
B
October 26th, 2011 at 5:45 pm
Most insecure coding is due to bad habits or ‘following the crowd’ (following bad example code) rather than any intentional stupidity.
I agree that if you teach good methods like using prepared SQL statements or input filters then security is automatically taken care of.
You still have to know the potential security issues because there will always be problems caused by using 3rd party code, libraries or remote APIs.
It’s tedious having to check large chunks of code to check for SQL injection or potential for XSS, and it’s not fool-proof. (which is why testing is always vital).
Promoting a systematic way of working is far better, as it allows developers to (almost) forget that they’re doing anything special.
Of course the approach will vary enormously between languages, libraries, templating systems which I think is why it’s simpler to just give a generic fix.
There are still a heck of a lot of self-taught coders out there, and their bad habits keep getting passed on.
October 26th, 2011 at 7:42 pm
I’m pretty sure I know who you have been working with today, he is quite famous and a friend of mine.
He has used that exact analogy and your “idea” in conference presentations for many years now. You really should reference his work rather than pretending you came up with it.
Check out slide 12 onwards here for example:
http://www.slideshare.net/securityninja/injecting-simplicity-not-sql-rsa-europe-2010
Similar here:
http://www.slideshare.net/securityninja/injecting-simplicity-not-sql-bsides-las-vegas-2010
Plenty more where those came from and on his website/blog
October 26th, 2011 at 8:08 pm
Hi Jericho,
Thanks for the comment… I don’t think I was pretending it was my idea at all. I did intact mention to our mutual friend that I was going to put it together as a talk (which he seemed to suggest was a good idea – I’m a little restricted from being quite so overt about naming the people I get to work with).
Given a lot of my work tends to revolve around helping people with their security programs, I’d like to be able to advise them on the best way of doing things, and if we can get better results through showing people how it should be done, rather than scaring them with how badly it can go wrong, then all the better.
Thanks for the slide references, but I was more keen to use a session as a discussion (rather than a presentation) to crowd-source the ideal solution.
October 26th, 2011 at 8:22 pm
Jericho – again, sorry… I’ve re-read both the English and Welsh versions, and the English version is a little ambiguous (the Welsh version was a lot clearer). I’ve made a quick edit which should make it a bit clearer.
October 27th, 2011 at 9:06 am
No.
Security engineering is by definition a preventative measure: an effort to stop the bad guys (or just guys with strange names, like little Bobby Tables) from successfully attacking your system. To do this, you must take the approach of looking at how such attacks work.
To take an example: if you were in charge of training police officers, you wouldn’t spend your time showing them what a well-behaved, law-abiding citizen looks like. It’s no use demonstrating how to not have to arrest people.
You need to see what the bad things are if you’re going to combat them.
October 27th, 2011 at 9:16 am
Thanks Dan, some good points raised. Is it not dependant on who you’re talking to though? You’re an experienced coder, but if you’re new at it, doesn’t a friendlier/positive approach carry more weight? Rather than scaring the poor bugger to death?
October 28th, 2011 at 11:46 am
Seeing as we’re using analogies within analogies within analogies.
Dan – you’re wrong.
From a protection perspective let me introduce another analogy.
I know that bullet proof glass will stop a bullet so I have it installed. I don’t need to know how a gun works, the velocity of a bullet, the different types of bullets or anything like that. All I’ll need to know is how to install it properly in the window-frames. Which is in effect what a coder is doing. Installing / building something to the best of their ability.
Fully understanding how attacks work and the methodologies of the bad guys falls under the remit of pen testers.
October 28th, 2011 at 11:51 pm
The comment above from ‘Jericho’ was not done by Jericho of attrition.org. Don’t mind the spoofing, just want to be clear though.
October 29th, 2011 at 1:49 pm
I can attest that the comment doesn’t sound at all like Jericho of attrition.org. He would not have been so polite
http://attrition.org/postal/
.sioda,