October 17th, 2011 | Web Application Security
Dinis Cruz did a presentation at OWASP recently on why security should be invisible to developers.
His basic idea is that security is for security people and building things is for people who build things. He says that security people should stop rubbing developers’ noses in their problems and make security transparent so developers don’t need to think about it.
This is mostly a horrible idea.
The easiest way to see this is to take the concept of “building” to any other domain. Quite simply, anyone who “builds” something needs to be responsible for its security. Whether it’s a skyscraper or an automobile, the excuse of “You didn’t give me secure stuff to build with so I made a death trap.” isn’t a strong defense.
It’s true that there are different types of people who “build” buildings. There are those who design them and then there are those who put drywall in and nail up plywood. And perhaps the argument is that people who do basic construction shouldn’t have to know how to build a structurally sound skyscraper.
Perhaps, but someone who is responsible for building that structure is accountable for its design — including security. And that someone is most definitely a builder.
So if we’re saying regular construction people are like regular developers who don’t need to know the ins and outs of security, then I ask you who the architect is. Remember that you can’t just send a bunch of hammer and nail guys in to build a skyscraper — you need an architect to lay out an approved plan.
That architect, is held accountable for the design, and that’s the piece that we’re missing in software. It’s not right to say that developers shouldn’t have to know security; that’s false. They need to be identified as one of two types: hammer and nails guys or design guys. If they’re hammer and nails guys then they shouldn’t be allowed to code without supervision of someone with security skills. And if they’re design guys then they should be able to code securely without supervision.
But the one thing that’s completely out of the question is the notion of nobody doing the building (of whatever) having any clue about security. It’s not true anywhere else, and it shouldn’t be true for software either. Security is part of quality. If you build an insecure program you’ve built a crappy program. Good builders don’t build crappy programs.
Security is now part of the process, and it will only become more so as time goes on. If you’re asking for it to be easier for developers to be good at understanding the security of their applications, then I agree. But if you’re saying make it easy so that they don’t have to understand it…definitely not.
Developers don’t get a pass on security. It’s just like building anything else that is used by others and has any sort of security/safety implications. The responsibility resides with the creator of the object, not with those who come by to audit him. ::
- Open Web Application Security Project: OWASP iGoat 1.0
- Google Buys Security Analytics Software Developer Zynamics
- OWASP Mantra – Security Framework – OWASP
- SQL Injection is 90% SQL, WebSec is 90% WebDev
- Getting to Know the OWASP ASVS | HP Enterprise Security
- OWASP Mantra Security Framework | OWASP
- Blizzard Sued for Upselling Security Minimums | Net-Security
I’d love to hear from you. If you’d like to connect or respond, please reach out via Twitter, using DISQUS below, or by email. Also consider subscribing to the site via RSS and checking out my other content.blog comments powered by Disqus