Datblygu Diogel | Secure Development

[cy]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:[/cy]

[en]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):[/en]

“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”

[cy]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.[/cy]

[en]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.[/en]

Diweddaru | Update – 29/10/11
[en]So I ran the session at Barcamp London, you can see the slides here:[/en]
[cy]Well, dwi wedi gwneud y sesiwn nawr yn Barcamp:[/cy]

[cy]Sesiwn reit dda, gyda trafodaeth diddorol. Disgwyl nawr i cael rhagor o adborth dros y dyddiau nesaf.[/cy]
[en]An pretty good session, with a very interesting debate. Now to wait for some more feedback over the next few days.[/en]



About bryns

Gîc Cymraeg Defnyddiwr Mac Podledwr a ffotograffydd Welsh geek, Mac user, Podcaster and Photographer
This entry was posted in comment, General, observations, Security, web, work and tagged , , , , , , . Bookmark the permalink.

9 Responses to Datblygu Diogel | Secure Development

  1. Dafydd Tomos says:

    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.

  2. Jericho says:

    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:


    Similar here:


    Plenty more where those came from and on his website/blog 🙂

    • Bryn_S says:

      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.

  3. Bryn_S says:

    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.

  4. Dan Q says:


    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.

    • Bryn_S says:

      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?

  5. J4vv4D says:

    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.

  6. The comment above from ‘Jericho’ was not done by Jericho of attrition.org. Don’t mind the spoofing, just want to be clear though.

  7. sioda says:

    I can attest that the comment doesn’t sound at all like Jericho of attrition.org. He would not have been so polite


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s