Seven good security questions

We just received the Autumn issue of 2600 The Hacker Quarterly. I love this magazine for two reasons. Some of the articles are good. But the more important, this magazine gives a vision of the mindset of hackers, or at least I should say the Hackers. By Hackers with a H capital, I mean the guys who want to use the gimmick in a way different from the one that was intended by the designers. Sometimes, you discover also some security vulnerabilities that seem so obvious that you would not dare to test them (See the short paper Free DirecTV on by outlawyr)

Sometimes, you also find papers written by authors without warnames pseudonyms and who dare to give their email address. These papers have another tone (the type of tone you would find in French Misc magazine)

In this issue, John Bayne presented a comparison between SSL and DNSSec. At least, he compared just the management of certificates. The interesting part was not too much on the result of the match (SSL won!), but on the set of criteria, he used.
He asked interesting questions that could be used for evaluating any IT security system.

  • 1- How is trust implemented?
  • 2- How strong are the algorithms that are in use?
  • 3- Does the technology provide true end to end security?
  • 4- How clear is the warning that the technology presents to the users?
  • 5- How easy is it to implement a centralized policy for the technology?
  • 6- How widespread is the technology?
  • 7- How broadly will the technology protect you?

Ten laws of security

You may know that my team has defined ten laws of security. This is an extremely useful tool. We use it daily as heuristics. Of course, we are not the only ones to have such rules. Thus, I decided to start to collect the sets of 10 security rules.

Here is my first set.

1. Technology is not a panacea
2. If a bad guy can persuade you to run his program on your computer, it’s not your computer anymore.
3. If a bad guy can alter the operating system on your computer, it’s not your computer anymore.
4. If a bad guy has unrestricted physical access to your computer, it’s not your computer anymore.
5. If you allow abad guy to upload programs to your web site, it’s not your website anymore.
6. Weak passwords trump strong security
7. A machine is only as secure as the administrator is trustworthy
8. Encrypted data is only as secure as the decryption key
9. An out-of-date virus scanner is only marginally better than no virus scanner at all
10. Absolute anonymity is not practical in real life or on the web.

I found there in a tutorial about ethical hacking. In fact, it seems that they come from Microsoft. Thus, if somebody can provide me with a pointer to the original source, I would be glad.

These rules are clearly with a computer and IT scope. They are interesting. Some rules have similarities with ours. Their law 1 looks like our law 10 (Security is not a product but a process). Law 6 is a case of our law 7 (Security is not stronger than its weakest link). Law 7 is an example of our law 6 (You are the weakest link). Law 8 is an illustration of Kerckoff’s law.

Law 2 to 5 are true. It nicely describes the extreme context as defined in software protection. Unfortunately, it is too often the reality. This is why software protection is difficult. Law 3 and Law 4 are the basic environment of any DRM system. The possible bad guys owns and controls the host (in fact, it is his machine).

If you know other sets of 10 rules of security, please forward them to me to complete my collection.

Lessons from Société Générale

In January 2008, the name of Jérome Kerviel became famous. This second-rate French trader generated 5 billions € of losses to his bank, Société Générale. Jeremy Epstein uses this story to illustrate 13 lessons for security. His lessons have many common points with our 10 laws. Some of them are more original. My preferred ones are:
Lesson 1: “Low tech attacks are easier” and according to me often neglected.
Lesson 7: “Don’t believe every thing you read”. This lesson is true even out of the field of security. Trusted information is a difficult quest.
Nonlesson 11: “Insider attacks (usually) have motivation”

It is perhaps in the motivation space that the failure of Société Générale finds its root. The latest report highlights that the controlling mechanism of the traders did not work properly. We may question if it was not on purpose. At end December 2007, Jerome Kerviel generated 1.5 billions € for his bank. For that, he violated many rules. What would be the behavior of a controller who detects such violation which produces such huge benefits? (Being a second rate trader, Kerviel was not authorized for such huge investments). Is it not tempting for the management to close its eyes? This is another illustration of our law 9: Quid custodient ipsos custodies?

The paper is in the latest issue of IEEE security & privacy, may-june 2008. A good reading.

And you, which is your favorite lesson?