Jan
31
2007
Tonight’s show is short and late, for which I apologize. Last night was a blogger meetup in Burlingame for Robyn Tippins, a friend from the Podcast Roundtable project I did last year. This was our first chance to meet face to face, and after three hours of driving, I wasn’t up to editing last night. Plus, I’m trying to tie down the format of the show. This will hopefully save time later but cost me time today.
I got a lot of feedback from listeners, which I really appreciate. Keep it coming. I think I may actually be able to put a greeting in my gizmo voicemail account now.
Show notes:
Network Security Podcast, Episode 60, January 30, 2007

Time: 21:56
Sponsored by: Astaro Internet Security

Technorati Tags: security, mckeay, podcast
Jan
30
2007
This is an interesting development in PCI compliance: a group of vendors have grouped together to create the PCI Security Vendor Alliance. I see a mission statement and a lot of interestingly vague statements, but what I don’t see anywhere is a statement affiliating the PCI SVA with Visa or Master Card directly. Even the relationship with the PCI Standards council could be clearer.
How does the PCI Security Vendor Alliance relate to the PCI Standards Council?
The PCI SVA is a member of the PCI Standards Council, and fully supports the mission of the Council. The PCI Standards Council is responsible for developing and managing the PCI Data Security Standard, including maintenance, clarification and revisions of the Standard. The Council has established approval processes for two categories of vendors: (1) qualified security assessors and (2) network scanning vendors. In contrast, the PCI SVA deals with all other categories of product and services vendors – those that are NOT covered by the charter of the PCI Standards Council. Unlike the council, the PCI SVA does NOT certify the PCI DSS compliance of any product or vendor. Instead, the members of the PCI SVA are typically brought in by a merchant or financial institution after a PCI DSS assessment, in order to help the organization achieve compliance with PCI DSS.
I fixed the link in the quote, it’s HTTPS not HTTP as it was on the PCI SVA site; I’m sure they’ll fix it soon. I have a talk with Protegrity, a member of PCI SVA scheduled for RSA, I’ll ask more about it then.
Technorati Tags: security, mckeay, PCI, PCI SVA
Jan
26
2007
Marcin asked, “How do I transfer my domain name?” I realized I’ve never had the need to transfer a domain name from one registrar to another, so I did a little searching through Google to find an answer. Most of the instructions I found were registrars telling you how to transfer to their service, but I found a couple of links that might be useful.
First of all, you have the right to transfer your domain name, don’t let any registrar say differently. The ‘losing registrar’ can hold up the process, but unless they have a specific reason not to, they have to comply. One of the nice things ICANN has done is to institute a 5-day default approval to the process; if the losing registrar doesn’t respond to the gaining registrar in 5 days, you’re domain will be automatically transfered.
The actual transfer process appears pretty easy; find a new registrar, fill out a Standardized Form of Authorization and within 5 days, you’re domain will be transfered to the gaining registrar. There’s even a nice flow chart of the process (.pdf) for you to follow.
If you’re using GoDaddy, now you know how to transfer your domain. And if you don’t want your domain taken down without notice, you might want to do exactly that.
Technorati Tags: security, mckeay, registrar, transfer
Jan
25
2007
It takes a bit of balls, and absolutely no brains, to take down SecList.org with almost no warning to the owner, Fyodor. But that’s apparently exactly what the folks at GoDaddy did earlier today. I’ve been reading different lists on SecList since before I worked in security, and Fyodor‘s was one of the very first name’s I ever heard associated with the term ‘security researcher’. There’s this little program you might have used before, called Nmap, and he’s the one who wrote it. Not exactly an unheard of figure in the security sphere.
So why did GoDaddy do this? Because MySpace asked them to. There was a large list of MySpace user accounts and passwords that were posted to a list hosted on SecList, but taking down the entire domain to get one list is completely excessive. Especially since the list had been out for 9 days and is easily found elsewhere with a couple of simple Google searches. Of course, you can’t issue take down orders against all those versions of the list on the Internet, so why don’t you take down the mailing list that’s guaranteed to get the list the greatest publicity possible. Way to keep it quiet, MySpace.
I almost wish I had an account with GoDaddy so I could cancel it. I’d never touch MySpace with a 10′ ethernet cable, so nothing to cancel there either.
Technorati Tags: security, mckeay, Fyodor, GoDaddy, MySpace
Jan
25
2007
One of the things I’ve seen written about stolen credit card numbers is that there was no proof that the numbers were ever actually used, or at least that the danger wasn’t outside the norm for other credit card fraud. At least in the case of TJX, we now know that the compromised credit cards are definitely being used for fraud world wide.
Opponents of compromise disclosure have been arguing that it places an undue financial strain on the compromised company, though those voices have been strangely quiet given the sheer volume of compromises over the last six months. The verification that a specific breach has directly led to the misuse of credit cards should eliminate the last few arguments against complete disclosure. Hopefully even the most staunch supporters of business are realizing that there is no legitimate excuse for merchants not fully explaining to their customers how and when the customers sensitive information was compromised.
It will be interesting to see what this incident costs TJX. The changes to their processes and network are only going to be the start of it; Visa and Master Card are going to fine TJX’s merchant banks, who will of course pass those on to TJX. Given the lack of controls, a class action suit for negligence is not out of the question either, though given past history, it has little chance of success.
It’s hard to establish an ROI on security measures. Hard but not impossible. But knowing what a compromise costs a company can at least tell you what the penalties for not having the security measures in place are. I’m willing to bet my next paycheck that the cost of remediation from this incident are going to run TJX many times what the cost of encrypting the data in the first place. And that’s not including the soft costs to their reputation. I know my family won’t be shopping at any company owned by TJX any time in the near future.
Technorati Tags: security, mckeay, TJX, compromise
Jan
23
2007
I’m winding up my vendor list for RSA. I looked at my mailbox and I have over 135 email threads (not emails, threads) of vendors asking for time to meet me and talk about their product. I’ve got to start doing some maintainance on my podcasting equipment and make sure that everything I own is up to the task.
The reins of the security blogger’s meetup at RSA have been handed over to me. Rich Mogull did 90% of the work for this event but had to step back for personal reasons and asked me to take over. There are almost 20 confirmed bloggers, with half that number who have expressed interest in attending. If you’re a security blogger/podcaster/video blogger, drop me a line and I’ll see about adding you to the list.
Note: I got another voicemail comment from Ben just after I recorded tonight’s show. I’ll let you listen to it next week and respond. “Why can’t these companies just encrypt our data?”
Show Notes:
Network Security Podast, Episode 59, January 23, 2007

Time: 27:26
Sponsored by: Astaro Internet Security

Tonight’s Music: Circular Reasoning by Allison Crowe