Okay, so why am I disappointed? I took this test. I saw it at a friend's weblog ( http://confessio.blogspot.com/). I thought it would be fun to take. He was "rated" as "Yoda." Me? Well, you see: Galadriel. Should I be insulted? What's it say about me? Well, probably nothing. :-) No, I'm secure enough not to mind, and even to post this. And, anyway, when you look at the results of everyone who took the test, Galadriel is #1 with over 42,000 matches.

Ah, well... Click on the photo and take the test. (Note, this takes you off my web site. Click at your own risk.)

Quick -- What was the first commercial firewall product with an announced serious (as in, one could "get root") security vulnerability? No, not Check Point. It was Gauntlet. (Disclaimer: it was after NAI took over, and after I left. I.e., someone else's watch. :-)) That was a few years ago. This latest vulnerability is current. SearchSecurity's write up is at here. The US CERT's Alert -- sorry, the Technical Cyber Security Alert (is this stuff great, or what?) -- number TA04036A is at TA04-036A.html. The sobering and predictable overview states, "Several versions of Check Point Firewall-1 contain a vulnerability that allows remote attackers to execute arbitrary code with administrative privileges. This allows the attacker to take control of the firewall and the server it runs on." Oh, this vulnerability is in the new Application Intelligence component of Firewall-1. ("Application Intelligence" is a marketing term for their application gateway technology, the stuff they called old technology in the late 90s. See my column "Debunking the Firewall Hype" at here.)

I am not (anymore) going to kick Check Point when they are down. This is for two reasons. First, they are not down (though their stock is not tracking the market growth... opps, sorry... really now). Second, the problem is one shared by many other vendors: the lack of an overarching and pervasive security architecture. "Security architecture," as in how the product itself is developed and secured. "Security architecture," that is not a buzzword in a press release, naming an API, but is documented and periocically checked. Just as enterprises must have a network security policy that implements a security architecture -- with both periodically reviewed and validated, security products must have a security architecture used with similar regularity. It is not Check Point. All security vendors have to be much more careful. And what about you? When was the last time you asked a security vendor to describe its security architecture?

Andy Briney, in his February Information Security Magazine column, called "Secure Coding? Bah!", makes the claim that while we may ask for secure software, it is "Not gonna happen." He sees persuing secure programming as "totally impractical."

Of course, he's wrong, though not completely. He correctly talks about incentives. But then makes a jump to suggest that there is no money to research how to accomplish this. Also, he says, this is a very complex and specialized problem.

Research is not needed. Use of proper tools and programming languages is. Tools exist to tighten up code and find possible problems. Also, it is not specialized. Poorly written software crashes all the time. We are used to it. But, it is not unique to security. Sometimes a buffer overflow results in a system hang. Other times it allows an exploit.

While I disagree with his claim that "Secure coding is yet another silver bullet," I agree that "Risk reduction is all about reducing vulnerabilities, mitigating threats and lowering event costs." Andy doesn't believe that secure coding is part of the solution, except theoretically. I believe it can be.

Check out his column at the above-cited URL and look for discussions elsewhere on it at seclists.org, or by using your favorite search engine and looking for the title of his column.

It is well past the "live" date, but through the magic of electronic media and the Internet, you can catch Jon Callas' webcast on "The Dawn of Pervasive Encryption" at PGP. You will have to register and I suspect a sales person will e-mail you. I think it would be worth it. Jon talks about solutions that he has proposed for making encryption more widely used. It is a PGP Corporation commercial, but it is rich with techical content.

I've written on this subject before. (See my "Secure E-mail collection" at here.) The technology and related software to easily use encryption has been around for 15 years. Aside from our apparent lack of belief in the need for it, the use of cryptography and the need for some level of ubiquity have been speedbumps for its use. Rather than go through the details, I suggest you listen to the webcast. Also, you can see my review of PGP Universal by going to my "Writings and Musings" page and clicking on Painless PGP.

In recent months I, probably along with many of you, received e-mail from an MX server informing me that the e-mail message I sent to someone (someone I did not know) contained a virus. In some cases the helpful mail server bounced the infected attachment back to me. And in all cases, the errors were in response to e-mail claiming to be from me, but not from me.

Brian Martin of Attrrition.org discusses this and makes the charge that these anti-virus companies are commiting spam. His interesting discussion is at attrition.org. There is only one statement in this article I must protest against (see if you can guess), but found the discussion compelling. At the very least we should carefully consider how we set up our mail gateway antivirus systems.