March 8, 2007 - Volume 2, #41

Good Morning:
I owe many of you an apology. Yesterday's email version of TDI didn't go out until after 2 PM EST. Of course, it was done pretty early yesterday morning and posted to the blog before 8 AM. But much to my chagrin, my outbound email provider - AWeber - was down until 2 PM yesterday. Well, not down. But you couldn't get into their interface to do anything, so it's all the same to me.

And that's what I want to rant about today. Managing customer expectations, coming clean when you have a problem, and having a fall back position. AWeber failed miserably on all fronts yesterday. Absolutely miserably. First, they decided to do a major upgrade during the week. Sure it was supposed to happen overnight, but it wasn't done by the time business starts in the US. That's a no-no. So when I tried to log on, I got some useless message saying the site was down for "periodic maintenance." At 8 AM EST in the morning? No way.

At about 11 AM I actually called. I was working with a client and we took a little break. My heartburn was in overdrive in not being able to send out the newsletter. So when I start asking the customer support rep what was going on, he repeated the company line - periodic maintenance. That's when I lost it. WHAT!?!?!?! Only an idiot would do maintenance in the morning, presumably when most of the email newsletter need to be sent.

So I went down the path of bungling the upgrade. This guy had the gall to tell me that they were just doing a bit more testing on the new interface before it went live. It was like I was born yesterday. I've been in technology for about 20 years. I've seen bungled upgrades. This was a bungled upgrade. The time for QA is NOT when you have thousands of clients out of business because they system is down. I just wanted the guy to say - yeah, we screwed up and we are working our asses off to get things back up. Come clean. It's not like I didn't know what was going on. It was obvious. But they guy on the phone seemed like a boob for towing the company line.

Finally, AWeber should have had a roll-back plan. Clearly the upgrade didn't go smoothly, so they should have rolled-back to the previous version by 7 AM. It's a web application, it's not like they already sent out 10,000 CDs. You work out the kinks and do the upgrade the next night. It's not that hard. People depend on their service and it's their responsibility to keep it up and running. The interface upgrade is AJAXy and nice, but it wasn't worth being down for most of a day.

But now we get to the real problem. These folks are commodity mail blasters. They have thousands of customers who pay about $100 a year. So I could go elsewhere, there are about 1000 of these companies to work with. But would it make a difference? As Hoff says, you get what you pay for and sometimes that's true. But it's the simple things that can make screw-ups go down a lot easier. Think about that the next time you screw something up.

Just a little reminder that there will be no Incite tomorrow. But if you need to hear me rant, sign up for the P-CSO newsletter (here) - those go out on Friday. Have a great day.

Technorati: Information Security, CSO

The Pragmatic CSO is Here! Read the Intro and Get "5 Tips to be a Better CSO" www.pragmaticcso.com

Top Security News

Hacking a good thing?
So what? -  Ed Amoroso, maybe the highest profile CSO out there (he runs security for AT&T) has written a book. Not sure what it's about, but this interview (here) shows Ed doesn't seem to know the difference between research and hacking. Or maybe he is using the developers definition of "hack," which is to add some functionality, as opposed to the security guys definition of hack, as in a bad guy doing bad things. Now if he's referring to research in this interview, where smart folks pick apart products to find the holes, disclose the issues responsibly, and make the products better - then I'm cool. I guess I object to his use of the word "hack." Something about it annoys me. He also seems to be intimating about the need to poke at your own systems, you know, a pen test. Speaking of pen tests, Ranum and Schneier are at it again in another point/counterpoint about pen testing (here). There are enough caveats (and hot air) between the two of them to heat a small country. It's true, Marcus is right. Organizations should have a good security design and do things right. Maybe it's just me, but I like the idea of having someone else look over my shoulder every so often and keep me honest. That's what pen tests do, but ultimately you don't have to pen test your environment. The bad guys will be happy to do that for you.
Link to this

PCI in the limelight
So what? - "Living in the limelight - the universal dream" is from my favorite Rush song (here), which features maybe the second most recognizable guitar lick in history (behind Clapton's Layla). But PCI is definitely in the limelight now and that means anyone that basically collects money from someone else needs to understand how it impacts them. There is plenty of information out there and hopefully as TJX is chopped into little pieces and fed to the fish for being stupid, folks will realize that it's pretty important to protect customer data. And it was a brilliant risk mitigation move for the credit card processors and banks. I'm sure they'll be reducing fees as their risk exposure reduces, since they'll blame the retailers for everything. Yeah, right. This tip by Joel Dubin provides a pretty good primer on PCI (here). But keep in mind, a scan does not equal PCI compliance, though many vendors will lead you to believe that. And even more vendors will lead you to believe their widget solves the problem. Tune out the noise and focus on what's important, which is that a strong security posture will get you PCI and pretty much every other kind of compliance.
Link to this

Step by Step containment plan
So what? - For those of you that want to understand how and what a containment plan is, check out this article by Kevin Beaver (here). He hits the high points of the plan, especially having a contact list and defining a set of response steps. He suggests you actually talk to some of the decision makers BEFORE the brown stuff hits the fan, which is also sage advice. Overall, Kevin's plan is pretty consistent with a Pragmatic containment plan (there is much more depth on the topic in the P-CSO), which is a good thing. I don't see where Kevin recommends folks to practice OFTEN, ultimately that is they key arbiter of whether you will contain the damage.
Link to this


The Laundry List

MessageLabs upgrades their email scanning for content and images. Big whoop. - here

Top Blog Postings

Most admired <> Most Secure - so what?
Though the analysis that Rebecca Herold has done to study the security practices of Fortune's most admired companies is interesting, I'm not sure it's relevant. Being a good place to work and a secure environment aren't mutually exclusive. In fact, some of the liberties that would make a company a good place to work, are somewhat counter to strong security. What does the analysis, show us? Not much. Big companies have both good apples and bad apples. I think Rebecca is wondering whether the rankings would be different if privacy and security were considered. Again, I'm not sure that's relevant. Every company (especially the big ones) have policies that say they need to do the right thing. How many actually enforce that is another story altogether. 
http://www.realtime-itcompliance.com/information_security/2007/03/how_good_are_the_security_prac.htm
Link to this

Bullet proof, my ass
Given the rash of application vulnerabilities and the general acceptance that compromising an application is the path of least resistance now, learn from Ravi Char's experience. You will find problems with applications. You will bring those problems to the attention of the developers. They will, in turn, look at you like you are an alien. A stupid alien at that. Don't take it personally, just do your job. Tell him/her about the issue and then march it up the chain of command. There is a process for how application vulnerabilities are dealt with, right? There needs to be some place to store the information and to track progress in fixing it and to confirm the fix. The first response from most people (not just developers) is "not my problem." You can bang your head against the wall every time and hope the right senior person understands the issue, or you can put a process in place up front to deal with the inevitable issues. Yes, I prefer what's behind Door #2.
http://ravichar.blogharbor.com/blog/_archives/2007/3/5/2783486.html
Link to this

Lindstrom was right, SSNs not private
Texas has taken the first shot across the bow relative to the privacy of Social Security Numbers, which is covered by Tex himself, Michael Farnum, even if he didn't grow up in TX. A good discussion on this broke out on one of the mailing lists I follow, and the net result is that Pete Lindstrom has been right about this all along. He's been saying that SSN numbers are a joke for years and using them as positive identification is a bad idea. Whether this goes through in Texas isn't the issue. The fact is, folks issuing credit (and other financial functions) need to start overhauling their business processes to not use SSN as the key identifier. Knowing my SSN (and no I'm not going to publish it here) shouldn't allow you to do much of anything. Farnum, Martin and the other privacy wonks can (and do) discuss those implications. But this should be a wake up call to the financial services markets. The SSN is not reliable.
http://infosecplace.com/blog/2007/03/06/texas-house-says-ssns-not-private-data/
Link to this

Recently on the Security Incite Rants Blog

Check out the latest on the Security Incite blog
http://blog.securityincite.com/

Read the most recent Daily Incite
http://securityincite.com/security-incite-rants/daily-incite