In my threat modeling and secure coding classes, as well as directly with my clients, I always stress the importance of introducing security as early as possibile in the software development lifecycle. In addition to raising awareness amongst the developers, doing so can help identify potential problems early in the development process as opposed to later when they will require more effort and more cost to fix properly. I recently experienced a real-world example of this that I wanted to share.

I’m working in a building downtown that uses proximity badges to secure offices on each floor. The elevator has a card reader as well, but it requires you to actually insert a different badge. This process is both cumbersome and unreliable. First because you are sliding a card into a fairly small slot and second because people need to jostle around the elevator so they can get directly in front of the slot in order to successfully use the card reader. In the morning rush, it’s not uncommon for your floor to have gone past before you get a chance to swipe your card.

So what do you think this results in?

You got it. In the morning rush one person gets on, slides their badge in and asks everybody which floor they’re going to.

So due to a poor design decision (low-efficiency access control device in a high-traffic area), that control is now effectively bypassed on a regular basis. Another layer of security does exist, but now you’re one step closer. Perhaps this is an acceptable risk to the original designers of this system given the security level of the building and the additional security, but unfortunately I don’t know to what extent they did consider this.

I’ll be making another post in the near future about how some of the design decisions on today’s sites are there to make users “feel” better about the security, rather than implementing effective measures themselves. Sounds familiar.