A Response to Dinis Cruz’ Comments on Invisible Security

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. ::


☐ If you enjoyed this, please consider connecting via Twitter, RSS, or my other content.

  • Anonymous

    I understand where he is coming from, but I hate that “security” gets labeled as a tax.  

    I think you are right though, but I think when you look at most development shops there are different types — generally orgs have architects, leads, and developers.  

    Architects and leads should be well aware of the holes in APIs and the context they should use as well as their interaction.  I’m not going to hold the developers to that standard, but they need to be learning it.  No different then a carpenter learning how different joints are better for different situations based on strength, effort, etc.

    Security does need to be there as part auditor and part R&D and focus on tool sets and keeping the development abreast of issues.

    • Dinis Cruz

      I also don’t like that we are viewed (and behave) like TAX (or Insurance), but that is the reality.

      We need to move into the model were we (appsec) add value to developers (and architects, managers, buyers, etc…). Only then will we really be able to enable the development of secure applications.

      This is why I’m focused on Unit-Test and ‘Application Visibility’ since that is the common ground between the two worlds

  • Anonymous

    Actually I think Dinis is spot on. 

    To quote you: “But if you’re saying make it easy so that they don’t have to understand it…definitely not.”

    So that means you are saying security should be hard and developers must understand it. If developers had to re-invent crypto every time imagine the collapse of secure communications today. You can’t use analogies of physical building. Building software isn’t like building houses. Software is built these days by small self-contained teams like it or not. Dev teams MUST be self-sufficient. It doesn’t scale to bring in a usability expert and performance expert and ….. every sprint.  

    His arguments fail when he demos 02 but thats a different issue IMHO. 

    • Anonymous

      I might have misunderstood your self contained comment.. but..

      If you want a quality app, you need to have a usability expert and performance expert taking a look at the app through the process, not necessarily every sprint (if you are doing agile — which may or may not be the downfall of application development but that’s another discussion).

      And you are misinterpreting the quote”But if you’re saying make it easy so that they don’t have to understand it…definitely not.”.    The developers shouldn’t need to rebuild crypto algorithms, but they should certainly understand the strengths and weaknesses of them.  It’s how a developer can grow into an architect and truly understand their craft.

      • Anonymous

        I am sorry but our comment about agile shows how disconnected you are from software development. Nothing more to add.

        • Anonymous

          Stay classy.

    • Dinis Cruz

      Hey!!  O2, was designed to prove the point that that world is possible :)

      1st part of problem solving is finding a solution that WORKS  (even if for only a small subset of the target population)

      2nd part of problem is making it scale, which is the next challenge for O2 :)

  • Dinis Cruz

    Hi Daniel, Thanks for your comments, I think you make a good representation of the security camp that defends that “security is EVERY developer’s business” which although well intended, unfortunately doesn’t scale, and, in fact it doesn’t work.  We will never achieve secure applications at a large scale if we require ALL developers (or even most) to be experts at security domains like Crypo, Authentication, Authorization, Input validation/sanitation, etc…Note that I didn’t say that NOBODY should be responsible for an Application’s security. Of course that there needs to be a small subset of the players involved that really cares and understands the security implications of what is being created.The core idea is that developers should be using Frameworks, APIs and Languages that allow them to create secure applications by design (where security is there but is invisible to developers). And when they (the developers or architects) create a security vulnerability, at that moment (and only then), they should have visibility into what they created (i.e. the side effects) and be shown alternative ways to do the same thing in a secure way.The other idea that I’m trying to push our (the application security) industry to adopt, is this concept: “One can’t protect/analyze what is not understood, so application security teams create models (and tools) that help them to visualize and understand how the apps works, and since this ‘application visualization metadata’ is also VERY valuable to developers, let’s work together (devs+qa+appsec) so that we can embed application security knowledge and workflows into the SDL”For example, a very good and successfully example of making security ‘invisible’ for developers was the removal of ‘buffer overflows’ from C/C++ to .Net/Java  (i.e. from unmanaged to managed code). THAT is how we make security (in this case Buffer Overflow protection) Invisible to developers If you are looking for an analogy, “a chef cooking food” is probably the better one. Think of software developers that are cooking with a number of ingredients (i.e. APIs). Do you really expect that chef to be an expert on how ALL those ingredients (and tools he is using) were created and behave? It is impossible, the chef is focused on creating a meal. Fortunately the chef can be confident that some/all of his ingredients+tools will behave in a consistent and well documented way (which is something we don’t have in the software world). I like the food analogy because, as with software, one bad ingredient is all it takes to ruin it.Dinis Cruz

    • Dinis Cruz

      Humm, the formatting of my reply was broken.

      Here is a blog post with its content: http://diniscruz.blogspot.com/2011/10/comment-on-making-security-invisible-by.html

  • Joeri Sebrechts

    I think it’s not about giving developers a free pass on security but about giving them tools that make it easier to write secure code than insecure code. Give them the “how”, and tell them the “why” if they’re curious.

    Speaking as a developer now, let me dispel a myth here and now, that myth being “developers have an obligation to learn everything about security”. In theory it’s true, but in practice it’s not possible. The reality is that the topic is too big to learn for most developers. We (as an aggregate) will never have full knowledge of the topic “security”. What we need are ways to reduce the amount of security knowledge that developers need. The way you do this is to push security as much as possible into the platform and “secure by default” technologies. 

    This is what I understand under “invisible security”: adapt the platform to make it easier to write secure code than insecure code. In my opinion, most of the time SQL and mail header injection flaws are not a fault of the developer, they’re a fault of the platform for making them too easy to implement. Code is like water, you always write it to take the most direct path. If the platform makes the direct path dangerous, the security issue is in the platform.

    Or, if you’re not convinced, think of it like performance. Platforms that require a developer to jump through hoops to get an adequate level of performance are rightfully maligned. We expect our platforms to be fast by default. Most developers lack a full knowledge of the topic “performance”, but this isn’t a problem because they don’t need to. We should expect the platforms to be secure by default as well.

  • Pingback: elektronik sigara

  • Pingback: http://vehicleautoinsurance.info

  • Pingback: how to see credit score gov

  • Pingback: full report

  • Pingback: 888