This article over on Computerworld about the iSec guys who have found vulnerabilities within EnCase and the Sleuth Kit poses a fairly interesting issue in regards to the utilities used by security professionals. How much do these sorts of issues really impact upon your ability to present evidence to management, or even worse, court?

Many corporate environments, before people install and run new/unknown software, have to go through a degree assessment to ensure that the software doesn’t contain any vulnerabilities or has a history of exploitation. Would a defense lawyer really pick apart these sorts of issues in forensic acquisition/analysis tools to discount evidence presented in court? I guess, probably depends on how expensive the lawyer is. What doesn’t help the situation blow out of proportion – probably all the media that will surround the news report and associated black-hat expose features.

How much do these software vulnerabilities impact upon its ability to perform its intended duty? From what I read and understood, not a hell of a lot. It’s like trying to argue in court that MS Windows XP, the underlying operating system used by security investigators, has a long history of exploitation and so no evidence examined on a Windows XP system holds any merit.

This article reminds me a little bit of some research I did back at University on potential issues with forensic examination of PalmOS devices, in that images acquired are constantly changing due to the nature of volatile memory.

I guess this will probably blow over. Interesting none the less.

So I was walking to get a coffee the other day and passed this church which had a sign out front that stated:

If you can’t trust God
You can’t trust anyone.

It got me thinking about trust and relationships, not just personal but professional and even security relationships. The concept of trust is an interesting concept. How do we ever trust other people? Is it human instinct to want to trust people naturally, or is that a cultural instinct that differs from region to region? Obviously the family tree carries with it a certain level of trust, we implicitly trust our parents the same as a child Certificate Authority trusts its parents.

Later on that week I was talking to a colleague about the sign and about how putting that in context of security and CAs was kind of funny. He agreed and replied (and I’ll paraphrase): So that’s it! Verisign must have God on the payroll.

I book marked this article quite a while back and only now got to have a read of it. The 8 Simple Rules for Developing More Secure Code by Michael Howard over on the msdn is a list of habits of secure developers. I know it’s a little old now, but oh well.

Paraphrased to:

• Take responsibility of your code
• Never trust data
• Use threat modelling against your code
• Stay one step ahead – or keep up to date with emerging vulnerabilities and threats
• Use fuzz input testing
• Don’t write insecure code (I found this point rather over-arching but his comments are good)
• Recognise the strategic asymmetry – be aware that an attacker can spend much more dedicated time finding weaknesses than you can provide 100% secure code
• Use the best tools you can

What I like about Michael’s list is that is applicable to any software development environment using any methodology. From PHP apps developed by a sole-developer for a small company to large, multi-tier, thick-client apps developed by a team of developers. It’s all good.

Another Christian just posted this article on DNS Pinning. Really interesting read. I can’t help but find these sorts of vectors really worrying, vulnerabilities that allow external parties to access internal material (i.e. Intranet) from the source of an internal user.

You combine this with some of the nifty functionality available in the AttackAPI from GNUCitizen and you have some pretty powerful tools.

How many web developers in your organisation know about this stuff?

I really enjoyed reading Andrew’s article on “The Mainframe Conundrum” and would highly recommend that anyone else in IT in the financial area, or other critical infrastructure areas should also read it.

Since starting my new job this sort of issue has definitely come up on a number of occasions. Not always directly linked to problems with trying to apply security concepts to legacy type systems (or the people who support them), in fact probably more often involved with general IT people who don’t understand the insider risk. In any case, similar to what Andrew discusses, the solution to these types of problems can be tackled by effective awareness, training and support.