Don’t Build A Security System Until There Is Something To Secure

I know a lot of people give credit to the idea of “time to login“. Personally, I don’t think that’s the right way to look at starting an app. (Note: As Joshua Flanagan pointed out in the comments below, I completely mis-represented the post I linked to. Sorry about that. The rest of this post is still valid, though.)

Let’s say you are hired to build a time-punch machine, for clocking in and out of work. Do you immediately go and build a secure room with a buzz-in door and hire an armed guard to make sure only actual employees can get to the time-punch machine? Or do you build the time-punch machine and once it’s ready, figure out how the company wants to secure it? Chances are, it’s enough to just have a card wall where people keep their cards. You grab your card and punch-in or punch-out. You don’t grab other’s cards. It’s the honor system and it works. (yes, that was an extreme and probably ridiculous example, but it gets the point across)

Back to software, now… If you’re hired to build a time-tracking software application, why do you want to go off and build a security mechanism first? If the time-punch machine can use the honor system, why can’t the first working version of the time tracking app? Maybe the first version can just deliver a screen that let’s people enter time and write their name in as one of the fields.

It’s About Value, Risk, and Validation

When a client asks you for the time tracking app, their goal is to track time. Yes, they also want to make sure people are tracking their own time and not messing things up. Eventually a security mechanism will be needed as it helps to solve some of these potential problems. But delivering a working version of the time tracking page(s) first gives you much faster feedback on the direction of the app, with something that is actually valuable to the customer – for more valuable than just a login screen.

There is also a lot of risk in building a security system first. It’s very easy to over or under engineer a security system and find out that you built a secure room with armed guard when all you needed was an “on your honor” sign next to the card wall. I’ve often spent weeks or months building a full security system with role management and permissions that are stored in a database, etc, just to find out the client really needed something simple. I’ve also found myself in the opposite corner, building something simple and then the client coming back and saying that they need something much larger. It’s difficult to know with any certainty what kind of security needs a system will have, until there are things that actually need to be secured. Once those exist, though, it’s easier to judge how they need to be secured and how access to them needs to be granted.

As someone who has been a client, and now someone that is in the business of making clients happy, I can tell you that I want to see functionality first. It’s hard to get validation of what your building when you aren’t building the thing that gets you to your end goal.  So, don’t build a security system until there is something to secure.

About Derick Bailey

Derick Bailey is an entrepreneur, problem solver (and creator? :P ), software developer, screecaster, writer, blogger, speaker and technology leader in central Texas (north of Austin). He runs - the amazingly awesome podcast audio hosting service that everyone should be using, and where he throws down the JavaScript gauntlets to get you up to speed. He has been a professional software developer since the late 90's, and has been writing code since the late 80's. Find me on twitter: @derickbailey, @mutedsolutions, @backbonejsclass Find me on the web: SignalLeaf, WatchMeCode, Kendo UI blog, MarionetteJS, My Github profile, On Google+.
This entry was posted in AntiPatterns, Bootstrap, Goals, Risk Management, Security. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Rob Heckart

    I’m working on an ASP.NET application that I believe requires thinking about the security system up front. The login security credentials will be stored in a table and then other data collected in the application will tie back to the user’s credentials. Will the system use SSO or forms auth to authenticate users? How will that data be stored so that in my other database tables, I can correctly refer back to that particular user? Especially if I’m using the built-in Security Principal stuff in ASP.NET.

    If you don’t have those tables and that code in place, I guess you could still build the functionality, but you’d have to mock dummy code and data up probably to see things work. Is it worth it to mock the items up, or build the security in from the beginning?

    •  you’re going to have a lot of opportunity to change the design and use of the data if you get the app’s real functionality working first, and mock up the security related data that goes with it. chances are, you’ll learn something about how the security should work, how the data you need to tie back to it needs to be set up, and end up with a better system in the long run.

  •  For what its worth, “time to login” is about how long it takes to get a new member of the team setup and running your app, not how to start building an app. From the post you linked:
    Perhaps it should say ‘Time-to-First-Screen-With-Functionality’ but ‘TTFSWF’ isn’t as sexy as ‘TTLS’

    • *facepalm*

      ok… it had been a while since I read that post, and I obviously missed what it was actually saying… i’ll adjust the intro to this post.

      thanks josh

  • Carl Mehner

     So the folks writing HTTP followed your advice when creating the standard behind our web traffic (though it was done before your advice was there to consume [good job on that by the way]). There was nothing to secure, all was public, there was no online banking and such to require encrypted communications. Because of their shortsightedness and them not baking security into the application first, as the standard was built, we have a cobbled together, broken system for authentication on the web. It is sad, but in this day and age, we cannot trust users, we cannot just hang up a sign that says, “honer system” and hope someone doesn’t take advantage of it. Going back in after the fact to add security to an app is costly and intractable. Apple’s iOS is also a good example of this, they didn’t care about security when they built the phone, they just wanted something pretty, this led to data disclosures and other such ‘badness’ that could have been prevented by working the model set up by RIM in the BlackBerry to build security in at the ground level. Sony’s little gaming network with the 77 M users that had their data breached probably would have appreciated the dev team working on a good security model rather that pumping out the infrastructure to play first, then (most likely after being pushed by project managers and senior management to get the product out to the paying public) waited for a breach to occur, spent a month working 24/7 to get it decent again, just to find out that the stolen data could be used to reset the passwords of everyone in the system again! Even if they had waited for something to secure (public users), it would have most likely still been too late (due to the “what do you mean security? it works doesn’t it? just do what you need to have people log in and get it out the door” aspect). As a part of some buzzword worthy development model, I’m sure it is great not to think about how the system could be compromised in the future (PSN/Apple) or the system’s intent changed (public web->mobile banking), it gets the product out quicker and feedback faster, but does it at the expense of brand reputation later on, an expensive system hobbled together over many years, or just lots of money spent in various ways. 

    • it’s easy to look at high profile incidents, throw in a handful of conjecture and speculation, and generalize that into your thinking without considering the context of the situations. and to that point, i should have been more explicit about the context in which I was speaking – business application development. there will always be counter-examples to any principles or practice. there will always be exceptions that go against the rules. it’s easy to argue against something that you don’t agree with or don’t like, by substituting the context you want into the discussion (whether or not that substitution happens consciously).

      are you still working at the large financial institute down in SA? (btw: i drove by the compound last week and wondered if you were still there / how you were doing). i’d put $ on your circumstances at that company being so completely different – especially with all the regulation around the financial industry, and need for security – to nullify what i’ve said, in the context of what you’re building at that company.

      if you wait until you have millions of users to build security, you’re
      doing it wrong… and interjecting ideas into my post that i would never
      agree with. the first working version of an app does not mean it will
      be in production for everyone to use. that’s ridiculous. it’s all about
      iterative and incremental development. you build something, and you
      verify the thing you built. you add on it it, and you verify those
      additions. repeat. once someone is ready for the world, you release it
      to the world (the intended end users). if you fail to secure something
      that needs to be secured before releasing it to the world, you’ve
      failed, period.

      do you really believe that what i wrote is wrong, given the context in which i was speaking (and forgot to state, obviously)? are you reacting with thought and care, trying to add to the discussion, or tossing it out the window because i’ve challenged an assumption that you have learned in your specific circumstances?

      • Carl Mehner

        I definitely am trying to add to the
        discussion and strongly believe in building in security to any
        application from the ground up. Granted, in my specific circumstance,
        security is immensely important, but, nonetheless, I hold that it
        ought be architect’d into the base of any application.

        So, yes, I do still work at the
        compound, (check out the DNS whois db:) my job is awesome and I’m
        doing great. I’ve tried to incorporate what you taught me when I was
        one of your padawans back two years ago into my design and coding as
        best I can, and so far it has worked out pretty well.

        Context is important, and even though I
        did stretch the bounds of your blog (somewhat to the extreme) I
        believe that mockups and flow diagrams should be for finding client’s
        needs, and security should happen concurrently with coding. I hold
        that security and privacy should be integrated into the application.
        All traffic should be encrypted, all databases reside in silos, any
        PII encrypted, and all actions authenticated and non-reputable. The
        design around doing this can be as complex or as simple as the
        organizations structure allows, but is just as important as the code.

        Luckily, most frameworks allow for easy
        plug-in-play-esque integration to the rest of our organization’s
        infrastructure. C# has great integration with AD and should be fairly
        easy to synergize with opensource directory services for
        authentication which can have rules and groups as complex or as
        simple as the business (or security department) allows. Anything from
        username/password to smartcard should be able to plug in to your
        application with little extra work (if done incrementally).

        To give another example, I believe that
        Twitter should have all of its traffic encrypted with SSL. Not just
        because some users have private tweets and private messages they
        send, but because there are certain privacy implications to having
        your computer send your tweet in plain text to the server, even if
        once it arrives there it is made public. Also, unintended
        consequences of making all traffic to and from Twitter private would
        include rendering the problems that came with the release of
        FireSheep moot. The ability to steal an auth token and hijack
        sessions of others was certainly not thought of when twitter was
        first created, but, building in encryption from the get-go would have
        greatly helped mitigate that very risk.

        To further your example, you should
        have in mind what happens when you sell your time punch machine to
        other companies or move it from the un-networked computer in the
        front of your building to a active-active cluster running in multiple
        data-centers around the world with a web front end stored at a
        content cacher on the edge of the cloud when you first create that
        punch-in page. Maybe the security in the mockup is as simple as just
        putting in your unique ID, but it should be done in a way that is
        easily and quickly extensible in the future to include any
        authentication mechanism, and made to be non-reputable before

        • Battaile

          I really enjoy your blogging Derick, but I have to agree with Carl here.  I recently got a business app (nothing highly sensitive or whathaveyou) dumped on me where I had to “add security” to the website that had just been designed and built.  It was doable, but not as elegant or easy to get done as it would’ve been had there been some consideration given to security from the ground up. 

          But whatever, this has the feel of a semantic argument over an issue where all parties actually agree more than disagree. 

  •  Nice advice for me. Already I done this mistake but thank God. My friend is expert in this field. She only cleared my mistakes. Thank you for your advice.