Archiv der Kategorie: English

Posts in English

SOX – the new security standard

Sock security has been troubling me for a long time. Endless sundays I have spent with the fight against the single sock syndrom. But those days are over. Thanks to a colleague I have discovered sockstar, the revolutionary tool to improve the lower department of your wardrobe-BCM – a simple thing that just does what it should, if you manage to integrate it into your business processes… [end of commercial] http://www.sockstar.de/

Can We Say »Don’t Worry«?

[See only posts in English]

Freeman Dyson, being interviewed about his climate catastrophe skepticism, claims that some professions have trouble shrugging off issues as unimportant. He thinks there be a natural tendency to magnify threats:

»Really, just psychologically, it would be very difficult for them to come out and say, “Don’t worry, there isn’t a problem.” It’s sort of natural, since their whole life depends on it being a problem. I don’t say that they’re dishonest. But I think it’s just a normal human reaction. It’s true of the military also. They always magnify the threat. Not because they are dishonest; they really believe that there is a threat and it is their job to take care of it.«

(Freeman Dyson Takes On The Climate Establishment)

Obviously, computer security is another candidate. Paranoia is the norm in our subculture, we love to carry a better safe than sorry attitude. To an extent this attitude is justified by experience; there are many case studies of security not being taken seriously, leading to epic fail. Yet, more security technology is not always better. Do we have tools to reasonably say: »Don’t worry,« and justify our recommendation based on facts?

10 Essential Security Checks

[Get only posts in English]

A few days ago Oliver presented his 10 essential Web site checks. Except for a few very basic things I didn’t see security on his list, so here are a few essential security checks for your Web site. You will have to scale them to your needs; the Web site of your local juggling club won’t need the same level of security as an Internet business built around a Web application.

  1. Understand your threat profile
    Understand who might be your enemy and what would be the impact on your Web site and the users of your Web site if an attack succeeds. Don’t be overly paranoid but be honest to yourself.
  2. Use SSL
    Although it has its limitations, SSL is a standard security mechanism today and there is almost no excuse for not offering it to your users. It won’t solve all your security problems but it is useful.
  3. Have a person in charge of security
    Security requires continuous attention throughout the life cycle of your site. Somebody should be responsible for security, and this person must have sufficient authority to be more than a fig leaf.
  4. Baseline protection
    Don’t forget the simple things: backup, patches, secure configuration, etc. Be aware, however, that baseline protection will not make your applications and your own code any more secure.
  5. Build security in
    If your Web site serves more than a set of static pages, you must build secure software. Security is not a box in your architecture diagram, it is a set of rules and best practices for software development.
  6. Test early and often
    Everybody makes mistakes, and so will you. Have somebody to point out those mistakes to you before the bad guys find and exploit them. Do not rely on automated scanners too much. They are useful but limited.
  7. Be hacker-friendly
    The best security testers you can get are white-hat hackers who happen to find issues on your site. Be accessible, properly credit those who helped you, and don’t sue the messenger. Don’t be too proud of not having been hacked, though.
  8. Don’t annoy your users
    The point of security measures is to make attacks hard. Their point is not to make legitimate use of the site hard. Putting unnecessary burdens upon your users will likely reduce your security—and the number of users.
  9. Plan ahead for failures and disasters
    They are out to get you and eventually they will. Know what to do if your security failed despite all your efforts. Have plans for incident handling, business continuity and disaster recovery.
  10. Compliance is just that
    Do not assume that compliance with whichever standard or regulation would be a replacement for actual security.

Homework assignment: pick one item and expand it into another list of 10.

How much security do we gain from Trusted Computing?

My colleague Jan is going to present our paper Attacking the BitLocker Boot Process at Trust 2009 (Oxford, 6th – 8th April). The paper is an improved version of the draft we presented at ETISS.

BitLocker is the volume encryption function built into recent versions of MS Windows. It is capable of using a Trusted Platform Module if the PC has one. Our paper describes five attack scenarios that using the TPM does not prevent from succeeding. Some are based on particular features of BitLocker while others rely on the implementation of authenticated booting that is currently used in Trusted Computing.

All five scenarios seem suitable for targeted attacks and require that the attacker can access the target system twice. Executing such attacks is thus roughly as complex as installing a hardware keylogger in the system and returning later to retrieve the sniffed password along with the encrypted data – or just the machine in a condition that permits decrypting the data on disk.

What makes our attacks interesting is the fact that they can be implemented in software. Ideally, Trusted Computing should reliably prevent such attacks from succeeding. However, a TPM does not prevent software from being modified. The TPM only compares measured states with stored reference data. This leaves several holes. For instance one can temporarily modify software and later restore the reference state, or modify boot components before the reference state is determined and stored inside the TPM. While such actions are useless in an opportunisitc attack where the attacker just grabs an unattended machine unprepared, a dedicated attacker might take advantage of them.

Update 2009-12-03: There is a more comprehensive explanation in a later post.