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

By: Battaile

Battaile — Fri, 10 Jun 2011 17:23:00 +0000

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.

By: domain and hosting

domain and hosting — Fri, 20 May 2011 13:28:00 +0000

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.

By: Carl Mehner

Carl Mehner — Fri, 20 May 2011 03:55:00 +0000

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

By: Derick Bailey

Derick Bailey — Thu, 19 May 2011 14:15:00 +0000

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?

By: Carl Mehner

Carl Mehner — Thu, 19 May 2011 04:56:00 +0000

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.

By: Derick Bailey

Derick Bailey — Wed, 18 May 2011 13:34:00 +0000

*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

By: Joshua Flanagan

Joshua Flanagan — Wed, 18 May 2011 12:59:00 +0000

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’

By: Derick Bailey

Derick Bailey — Tue, 17 May 2011 13:59:00 +0000

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.

By: Rob Heckart

Rob Heckart — Tue, 17 May 2011 13:48:00 +0000

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?