John D. Mitchell's Blog

Security Archives

FindBugs in Anger

If you aren't already using Findbugs then hopefully you've at least heard about it by now and have some idea of how useful it can be.

If not, then let me say that FindBugs is a must have tool in the arsenal of any Java developer and any development team that's not using it as part of their regular development practices is incompetent.

Bill Pugh has done a fantastic job making FindBugs a great F/OSS tool which helps detect a large variety of all too common programming mistakes in Java.

You can find an online demo, slides from last year's FindBugs introduction , and can even run FindBugs over the web.

If you aren't yet convinced that FindBugs is really useful, let me point out that I've used FindBugs as an expert witness in cases where outsourcing projects had gone wrong and people were arguing about the quality of the delivered code (among other things). You have been warned. :-)

Go wild!

Piss Poor Web Security Approaches

Pete Freitag writes up 20 ways to Secure your Apache Configuration. Now, all 20 tips are useful to help make Apache less insecure but they certainly don't make an Apache installation actually "secure."

First off, note clearly how many things you have to go out of your way to turn off. That is, look at all of the extraneous, insecure junk that is installed and configured as part of a default Apache setup up. That's a big violation of the security dictum that we should be secure by default and have to explicitly take action to add in extra, insecure things. An example of why this is so important is that if you actually go through all of this tightening and then upgrade that server and forget to go back through and do all of the tightening again... Oops, not only will your system be insecure again but you'll probably be under the false assumption that your system is secure when it isn't. I've seen this happen way too many times to my clients and friends.

Second, if one really cares about security, why on earth would anyone consider Apache at all? There are many much better http server solutions out there for anyone needing serious security such as publicfile. Publicfile takes an arguably extreme approach and is fundamentally incapable of the vast majority of web server security problems. Therefore, other web servers such as the venerable, static-speed demon thttpd, the new, feature-rich kid on the block, LightTPD, or even the commercial king-of-the-hill Zeus Web Server can be a much better blend of increased security and increased performance.

Of course, if you're doing Java-based web server applications, Jetty and Resin are great solutions but they also tend to err by having way too much enabled by the default configurations.

Anatomy of Insanity

CNet reports that Microsoft is offering $5 (yes, 5) for data loss due to it's new AntiSpyware software that's in beta testing. Gee, thanks. That will buy me a cup of coffee so I can calm down after you destroy my data. Yeah, sure.

This is another case of how Microsoft (and so many other organizations) just doesn't understand (or care) how enormous an impact their buggy software has on users. This goes part in parcel with the wonderful example in my old blog entry Anatomy of Insanity? Of course, they will claim that this offer is somehow helpful to the customers but, I must say, it's just plain insulting. Why not try something revolutionary like actually writing high-quality software?

Security: Open source vs. Commercial

Security guru John Viega confronts the myths surrounding the security of open source software in his recent article: Open Source Security: Still a Myth. With a title like that, you might want to read through the hullabaloo in the comments at the end of the article.

There's only two differences that open source brings to the security equation... First, because the source code is available there is the possibility that security problems may be recognized by one of the more eyeballs. Second, because the source code is available there is no place for the developers to hide when a security problem is found.

SERVE put onto the back burner

According to a NYTimes article, the US administration has decided not to use the SERVE e-voting system in the fall elections. According to Deputy Defense Secretary Paul D. Wolfowitz:

"The department has decided not to use SERVE in the November 2004 elections. We made this decision in view of the inability to ensure legitimacy of votes, thereby bringing into doubt the integrity of the election results."

As I recently blogged, the SERVE system is catastrophically flawed. Alas, the powers that be, while caving to the pressure with respect to the November elections, Wolfowitz says that they will continue to develop the system.

A Security Analysis of the Secure Electronic Registration and Voting Experiment (SERVE)

Four security experts, including David Wagner and Avi Rubin, have published their critique of the so-called Secure Electronic Registration and Voting Experiment (SERVE) system.

What their report boils down to is that SERVE is catastrophically flawed.

Alas, since the inescapable conclusion doesn't fit with the desired outcome of people like the Pentagon, there's a lot of spin being spouted trying to drown the report in FUD. The one that I've heard the most is the implication that the silence by the rest of the peer-review expert group equals (a) disapproval of this report and (b) approval of the SERVE system. The silence of those other experts just means that it's not politic of them to tell the truth publicly.

Security State

Philip Brittan blogs about his various articles dealing with Security Strategies.

State is the second worst thing in distributed computing.
No state is the worst.
--John Ousterhout

This work is licensed under a Creative Commons License.