Monday, April 10, 2006

Thinking Positive about Security

As many of you do, I participate in a handful of discussion forums and mailing lists reagarding the various technologies that I use or have used. Every so often, I see a posting regarding security of sorts and wanting to provide advice, I wind up providing the same advice over an over again - think positive!

There is a great quote from the talmud that embodies this, one that is used in the book Firewalls and Internet Security by Bill Cheswick and Jim Bellovin (I am referring tothe first edition, ca. 1994, but the second edition, to which the link points was published in 2003 and added Aviel Rubin as co-author) to introduce one of the chapters (if memory serves):

Low Alecha HamLachah Ligmor, v'Low Atah Ben Chorin l'He Batail me menah - Loosely translated, this means It is not your duty to complete the work, but you are not free to let it lie fallow. The notion here is that it is very impossible to completely secure anything, but don't use that as an excuse to not even try.

Some people take a very negative approach to security. Let's do the bare-bones, and that's it. They wait until a breach happens before they start patching things. In the real-world, this approach is what I call a negative approach - i.e. Let's only prevent the things we find to be harmful, and allow everything else until it is used against us. In the real-world, this is the equivalent of saying, let's not put a lock on our door until we get robbed. Granted, I am over simplifying. Many people have the equivalent of a front-door lock in the form of a corporate firewall, but completely ignore that they left the side window wide-open.

While I am nowhere near perfect myself (read: please don't hack my site :) ), I am an advocate for something that I like to call Positive Security - i.e. only open up the services that you need to offer and nothing more and then monitor them dilligently.

Here are five basic points towards thinking positively about security:

  1. Remember to close everything down on your servers that doesn't need to be used publicly. It is more difficult figuring this out at first, but it is better to have to figure out which service needs to be turned on, then to browse through a list of services after a breach and figure out who is the weakest link.
  2. Don't worry as much about the ports you close than the ones you open. You need to open port 80 (and/or 443) to allow access to your site, and it makes sense that attackers will try to find ways to exploit these to ports before trying more difficult means.
  3. Despite what you and your development team think, your code has bugs. Whether you're vulnerable to SQL injection, buffer overflows, or privacy issues, don't be so naive to think that your code and security are flawless. Test it for common vulnaerabilities (like the aforementioned SQL injection).
  4. Don't worry about inconveniencing users. Which conversation would you rather have with a user - explaining to them that they can't do something because of security concerns, or explaining to them that 5,000 customer credit cards or social security numbers were stolen.
  5. Minimize your liability by minimizing the sensitive data you store. Since no security measures are strong enough to prevent every breach, why not limit the amount of sensitive data you store to mitigate risk. For example, if the credit card is processed by a third party, why store them on your site altogether? There is also no need to store passwords in plain text. A one-way hashing function is almost always available with most APIs, and that's all you need for passwords. In addition, if you are worried about your code, why not obfuscate it, or only install executables on your servers when possible. While these methods are not completely foolproof, they will repel the casual attackers and make things more difficult for the more experienced ones.

Again, the minute you connect something to a public network it ceases to become completely secure, but the more steps you take to secure it, the better your chances are of keeping it safe.

Wednesday, April 05, 2006

Windows on a Mac Revisited

I guess I stand corrected - or do I? Today, Apple released a beta of Boot Camp it's dual-boot loader for Windows and MacOS on its Intel based macs. A few weeks ago I opined in this very space about why anyone would want to convert a mac to run Windows. Clearly one would think that my thoughts were contradicted by Steve Jobs with an exclaimation point. But that is not the case.

I still wonder why anyone would exclusively want to take their very expensive Mac and run windows on it. Seriously, If I was going to buy a mac, it would be to get away from windows and not take the Applepeal (pun intented) of the iPod and bring it mainstream. But dual-booting, well, that's another story.

Dual-booting, to some extent, helped boost linux usage. Why? Because it enabled people to make the switch without having to completely abandon windows altogether. But Linux never quite made it on dual-booting simply because it made the already-difficult process of installing linux a little more difficult for Joe non-techie. That's what Jobs and co. have up on this software - they have a piece of Consumer oriented software that makes it easy to determine which way to go when the machine is booted and is easy (seemingly) to configure.

Oh, there's just one more thing (couldn't resist) - if you were going to put windows on a mac, which method would you rather use - the one provided by Steve Jobs, or the convoluted 'might fry your motherboard' way?