Wednesday, January 23, 2008

Crying Wolf

It seems a lot of software development people have a hard time committing money and resources towards proactive security measures. They rationalize this mindset by telling themselves that "nothing bad has happened yet, so why should I spend resources on security?" Well, atleast nothing has happened that they know about. The underlying problem here is that they don't understand the threats or the risks.

When these people discover that a breach or incident has occured, that mind set quickly changes. "Quick, call the information security people we've been giving the run around since they wanted to pen-test our app and review our source code! And how much money was lost?" Now they want answers, but do they even know the right questions to ask?

When a development organization has to respond to an incident, and they find the application has inadequate logging and is full of vulnerabilities, they suddenly realize how much they coulda/shoulda done to better protect themselves. Additionally, they find that the don't even know how best to react to such an incident. Many organizations already perform regular penetration tests and other security reviews. Unfortunately, as I describe above, many development groups lack the proper motivation to fully understand and respond to the
results of these excersizes. I think one way to change this mindset is to perform an Incident Response Drill.

In such a drill, a person from the InfoSec side of the company, possibly in kahoots with someone from the business side, would approach the development organization with a fake "complaint" from a real client. For example, Acme Products claims that they are seeing strange withdrawals out of their accounts, and one of them is for a large sum of money. Acme says they never authorized these transactions. Now see how the developers react. Can they provide any evidence to the contrary of the report? I would hope they could atleast give a record of all transactions processed under Acme's account, with some garauntee of non-repudiation.

An excersize like this would have better results if the application developers never know - before AND after - that the excersize is a fake. A little bit of paranoia and FUD on the part of the developers might go a long way in motivating them to better understand the threats/risks their applications face.

I googled "incident response drills" and there were only two relevant hits. I wonder if any InfoSec people are putting this technique into practice?

No comments: