Jeremiah Grossman, CTO of Whitehat Security, wrote in his blog that he thought it just might be. He reports that at a conference he just attended (FS-ISAC) that there was discussions of how a financial institution must assume that their clients (or customers) are infected or otherwise compromised. This was seen as an admission that the war over desktop security was lost to the bad guys.
I beg to differ. The war can only be won if everyone accepts that the other fellow may be compromised; this is part of normal security measures. The mere fact that we must assume the client is compromised is not an indication that the war is lost.
Gunter Ollmann, a security analyst formerly with IBM, wrote a paper on this very topic that is enlightening.
It is entirely possible that financial institutions must raise this to the next level, considering that users passwords can be scanned, SSL transmissions intercepted or decoded, fake sites created, and more. For a financial institution, the stakes are much higher.
One of the weaknesses in many security installations is, in fact, the lack of suspicion towards partners and clients. Partner networks are assumed to be as secure as the hosting network – maybe they are, and maybe they are not.
However, I think that the battle is not going well – and I think it won’t get better until users are educated and Windows is more secure (even if users don’t like it). The battle for security must be engaged at all levels if we are to beat back the bad guys.
So what must we do to secure the desktop? As users it can be easy: use virus checkers, use firewalls, don’t open suspicious emails, perhaps use non-mainstream operating systems such as Ubuntu, PCBSD, OpenSUSE, Mac OS X, or others.
For administrators, securing the desktop is harder, especially for users that might connect from outside. Some things that one could do would be:
- Give the user a client SSL certificate to connect with. This will prevent users from giving out passwords, deliberately or accidently. This should also prevent users falling for fake sites.
- Make the user (if at all possible) run a virus-checker routinely, and virus-check everything you receive from them (such as email and documents).
- If a virus is found, trace it and quarantine the user until they have undergone some sort of security audit (even if it is a quick audit).
- Educate the users about phishing attempts and other things, and encourage them to “get the word out” among their friends and so forth.
- In extreme (or unusual) cases, encourage the use of non-Windows and non-Intel environments: these environments have fewer viruses, and those that make it will not be able to run if the environment is not the expected one.
- Similarly, use a different browser: in the recent browser security contest at CanSecWest, only Google Chrome remained alive at the end of the contest. In contrast, in the recent attack on Google, Internet Explorer 6 was used to compromise the entire company.
Many things must be done if we are to win the war against botnets and other such nefarious ne’er-do-wells. To arms!
Apart from the transition threshold, the advice to use non-Windows (and non-Microsoft) plattforms is good in most cases. Microsoft is not only attacked more than others (as a side-effect of being the largest target), but also has a record of creating unnecessary security problems, being slow in correcting problems, not informing users appropriately, etc.
Under e.g. Debian (the Linux distribution I use), I receive prompt bug-fixes and notifications that I can install at my own comfort—in particular, without having to wait for a monthly mass-release or a service pack. Further, these are not limited to the OS it self, but include (almost) all products I have installed.
I should note that even Linux is not immune from the “popular attack vector” curse. The Special Dimension Fortress (SDF) free shell provider switched to Intel-based Linux for a number of years – and went back to Alpha-based NetBSD because of fewer headaches from security attacks and related downtime.