Two days ago, President Obama announced that Howard Schmidt would be the new Whitehouse Cybersecurity Coordinator. Howard deserves our thanks for taking the job. It’s arguably the biggest information security job in the world, although it’s neither the most lucrative, nor the most rewarding job in our business. His responsibility will far outweigh his authority, so it will be a miracle if he’s thanked for the job he’s done in 3 years, after the next presidential election. He’s not a cabinet member or a secretary or even a director – he’s a coordinator. He will be tasked with developing a national security plan that also respects individual privacy; something akin to building a perpetual motion machine. Personally, I wondered if I should send him congratulations or condolences for this move.
So why would he do it? Why would anyone do it?
Personally, I would guess that he wanted to serve his country again. Imagine that. After a prestigious 40 year career, spanning government and industry, when he should be settling down, this guy volunteers to go into the political viper’s den (the beltway, not the Whitehouse) and do an impossible job that has no promotion potential. He knows how bad it can be, because he’s been there before, but he signs up anyway. As they say in Philadelphia – go figure.
In these difficult times, there is no shortage of heroes. The spectacular feats of heroism by people fighting against the narco-trafficers in Mexico or those bringing peace and security to other parts of the world might make it hard for people in the technical community to feel like they’re making a difference. In fact, I don’t know of anyone who would compare themselves to these protectors of the free world. But we should also talk about the other people who have shown courage, dedication, and a sense of duty that would bring tears to your eyes.
The next time I think of courage, dedication, and service, I’ll be looking in the direction of Washington, D.C. and remembering a guy named Schmidt, who took on a massive national security problem just because the President called.
Thanks, Howard.
How often have we heard that before? That’s what Radiant Software said about their Point of Sale (POS) terminal software in an interview with an Atlanta newspaper. Radiant is being sued by several Southern restaurants for insecure POS implementations that cost each of them thousands. Check out Wired.com’s article for a good technical overview of the situation.
So let’s take a look at the claims in the article.
- The software allegedly stores all data from the mag stripe. That’s a serious security problem if the data can be retrieved, because it would allow an intruder to duplicate a card. Since only a small amount of magnetic stripe data is needed for a transaction, it’s especially bad if the software allows the data to be stored unencrypted. I’ve seen many systems that fail to adequately protect card data and that’s why PCI standards were issued.
- Installation security failures. You can say that this is not the software maker’s fault, but the software maker will have to show that they provided secure configuration guidance to installers. Anyone who’s built security software knows it’s important to provide installation and configuration guidance. It’s very hard to build software that can be installed by a stooge. If the software maker had provided installation guidelines that advised against broad back doors, it might have a better chance in court.
- The vendor was arrogant. Well, I’m not sure that one qualifies as a security failure, although arrogance is a lot more likely to piss customers off. So this one is probably not going to make it through triage.
I can imagine that Radiant Software will say something like, “These were just a few of our systems, so it’s all the fault of the incompetent installer.” It will be interesting to see if the court accepts that argument. It will also be interesting to see how software maker and integrator defend themselves in this lawsuit. If the claims are true, this case could serve as a precedent for future lawsuits of this nature.
Finally, if you build financial software and especially if you build POS software, PLEASE use the PCI standard and then call all of your integration partners to let them know that administrative back doors with common passwords are a really bad idea.
So what do you think? Is any piece of software vulnerable in the hands of a bumbling installer? Or should a financial software maker always define an operating environment that is resistant to attacks and train support personnel to configure the system correctly? Where does the responsibility end? I’d be interested in your comments.
Jim Molini, CISSP, CSSLP
