A few days ago I couldn’t find my car. After five minutes of pressing the panic button on my keychain, I realized that I accidentally left it at the community pool behind my house. My homeowner’s association placed a large, 5.5×4.25″ sticker on one of its windows, informing me that I had broken a community rule by leaving it there overnight and that I had 72 hours to move it. Exhibit A:
The pool’s parking lot never fills up during the times that I park in it and it only has more spaces at night when people are not swimming. Regardless, I implicitly agreed to not leave it there overnight when I bought my house, and I broke that agreement. I deserved the sticker.
As I moved my vehicle from the pool parking lot to a space in front of my house, I noticed four vehicles parked illegally in front of three clearly-visible no-parking signs. The signs are there because of a fire hydrant and a crosswalk for pedestrians. None of the vehicles had stickers on them.
In my year of living in the neighborhood, we have not had any fires; however, I have seen two people and a dog almost get clobbered by other drivers because illegally-parked vehicles were obstructing the view of the crosswalk and those trying to cross it.
If you have to choose between protecting a nearly-empty pool parking lot and a fire hydrant and busy crosswalk, you protect the fire hydrant and crosswalk, for obvious reasons. There is real danger in an inaccessible fire hydrant and playing chicken with pedestrians.
You would not believe the hours I have wasted arguing with other software engineers, security engineers, and server administrators about non-existent security issues in my software. Numerous individuals have insisted that HTTP GET query strings should never be used because users can change data values before sending them to the server. They conclude by stating that HTTP POST is “more secure.” I quickly disprove these statements by demonstrating how to muck with POST data using a local web proxy and help them understand when to use GET and when to use POST. (There are times when you should use POST over GET, but not for security’s sake.)
I have also been directed in the past to store database connection or service account credential information in the Windows registry instead of a configuration file. Access Control Lists (ACL)–the technology that restricts access to things in Windows–sees both the registry and folders as logical containers and treats them the exact same way. There is no security difference between the two when they are protected by the same ACLs.
While these individuals were distracted by these non-security “issues,” they were simultaneously overlooking real security vulnerabilities: publicly-accessible application log files and database build scripts, weak database usernames and passwords, and inconsistent Access Control Matrices. They were focused on what appeared to be insecure when, in fact, they were missing what truly was insecure. In just about every case, the misapplication of software security was the result of not understanding why they thought things were insecure. They didn’t really understand what they were looking at.
To ensure that you and your colleagues apply your energy and acumen to that which truly is a security issue, seek to be educated by Bruce Schneir. He’s the expert on the topic and has written wonderful material on it. In particular, I recommend:
There is a huge difference between that which appears to be a security risk and that which is a security risk: one is imagined the other is real. We should all focus on the latter.
Ian Lotinsky 
Great post. I think you forgot the biggest web application security vulnerability: failing to validate and sanitize user input. (which leads to XSS, SQL injection, etc.)
I’ve reviewed apps where the people charged with security were arguing over non-issues like using a query string with http get, and I’d look at the code and realize that you could delete the entire DB with a single malicious http post.
Good point–thanks for making it and also for getting me hooked on Schneir.
I would love to see someone quantify the benefits of securty implementation. It would be interesting to compare lost productivity from hackers with lost productivity dealing with overzealous computer security people. Reasonable security measures are rarely what characterize computer security. But we are a safety crazed nation and that often trumps reason.
The Montgomery Village Foundation is Communist. I told them so myself when they were taking pictures of my house and mailing them to me with edicts. If they are not Communist, they are definitely Democrat.
Drew –
I think you would agree that reactive security implementations make sense (adding security where someone has already exploited a flaw). What I think you’re getting at is what value proactive security brings to the table. The issue with proactive security is measuring value at the cost of implementing that security before a system is exploited.
My belief is that we should always cover known and easily exploitable flaws (see the OWASP Top Ten). The costs are minimal, particularly as development frameworks and APIs begin to include protection against these well-known attacks to you at no cost.
After this low-hanging fruit is picked, we need to either wait for exploits to take place or proactively secure our system. I propose making such a decision about each piece of data your system holds or the results of actions performed. Consider the consequences of theoretical attacks. If they are too great, secure those areas of your system. If not, opt for a reactive approach.
To determine if proactive measures were necessary, make sure to log suspected exploit attempts to a security log and take a peek at it every so often. You can then use this data to determine whether to maintain each security implementation and whether to build the same security into future systems.
Israel –
I will park my car in the pool parking lot as much as possible without getting another violation…in protest of their regime.