Posts tagged ‘security’

Saddle, two SDDL related tools

I’ve just uploaded two small tools that makes it a little easier to deal with SDDL (Security Descriptor Description Language, this is a good resource for SDDL):

  1. saddle-ex - “extract” the security descriptor for a number of different kinds of objects
  2. saddle-pp - a pretty printer for an SDDL string

Full build instructions are included. Download the archive here.

The tools are written (mostly) in Haskell and I’ll probably upload it all to hackage at some point in the future. I’m holding out for a fix to ticket 2097 since a fix for it will allow me to add a third tool which I feel belong in the package.

Suggestions for improvements are always welcome, patches even more so :-)

Some hope on identity fraud

After the recent cock-up by HMRC I find myself a bit more hopeful for the future.

Hopefully the politicians will start asking themselves if it really is such a good idea to collect information in huge databases. Should we really have ID cards? Is it a good idea to have a huge database with details of every child in the country?

I’m still wondering why it’s possible to “steal someone’s identity” by knowing only what HMRC knows about a parent that receives child support…

Computer security and liability—my thoughts

Almost three years ago Bruce Schneier posted a blog entry on Computer Security and Liability. Since then he has repeated his opinion several times; one of the more high-profile occasions was in front of the House of Lords. Some people agree, others disagree.

Until just a few days ago I disagreed with him on this particular issue. After the four learned hosts of LugRadio brought up the issue in episode 3 I had another think and I’ve now changed my opinion. I am now in favour of holding companies financially liable for damages resulting form security vulnerabilities in software products.

The software business is interesting because there’s a very obvious asymmetry in what is known about a product between the people who write and sell software and the people who use and buy software. Bruce Schneier has touched on that as well in his post on Security Lemons. Basically the buyer of software knows nothing of the ilities of what they are being sold, so there is very little to hang an informed decision on.

I think that introducing financial liability for software producers should take into consideration whether a buyer can make an informed decision before buying or not. This means that in cases where the buyer has full access to the sourcei there will be no financial liability on the developer. It would be enough to offer all source code under an NDA to a buyer before the deal is finalised. Basically liability would be the price a software vendor has to pay to keep the buyer in the dark regarding how secure the product is.

  1. Note that the source doesn’t have to be free as in having all four freedoms granted by e.g. the GPL.[back]

It is fair, at least for now…

I think it’d be better if Microsoft’s security specialists concentrated on improving security in their products (and possibly write about how they do it) rather than trying to make the rest of the world feel sorry for them. I’m sorry, but full disclosure is the fairest we have at the moment.

Microsoft sits on a reported vulnerability for months, releases patch when it becomes a 0-day. As I write this Microsoft is sitting on a few publically known vulnerabilities in Office (0-days as well) that have been known for a while now.

So, until companies start behaving I think full disclosure is fair. It seems to be the only way of forcing delivery of security to paying customers at the moment. When there’s a sign that the business as a whole can function without FD I’ll be the first to argue against it; at the moment though it seems to be our only hope.

FD ⇒ bad PR ⇒ declining share price and sales ⇒ security fixes

Some companies seem to be on the verge of understanding this and taking it to heart. (Microsoft has understood it, but doesn’t seem to have found its heart just yet.)

More on Vista’s “integrity control”

I just noticed a post by Joanna Rutkowska on a very handy little tool—chml.

For the record I’d like to point out that this tool further highlights how confused the MIC is in Windows Vista. A no-read-up policy in integrity control? I rest my case.