Security Bites podcast

According to a report this week from Verizon Business, risk factors for data breaches vary industry to industry and defy a "cookie cutter" approach to security, which is why Verizon has revisited an earlier report. The goal of both the new and the prior report is to offer detailed insight into how data breaches occur, so that companies can address the problems within their specific industry.

The June 2008 report spanned four years and included more than 500 forensic investigations involving 230 million compromised records. The new report uses that same data but drills down within four key industries: financial services, tech, retail, and food and beverage. The four constitute 82 percent of all the attacks in the original Verizon report.

Verizon found the attacks on the financial industry tend to be sophisticated. A majority come from outside hackers, although a healthy amount could also be attributed to insiders who have been granted access to the data. Retail and food and beverage, which includes restaurants and grocery stores, are the polar opposite. In both retail and food, less sophisticated attacks are used and are often the result of a compromised third-party vendor.

Bryan Sartin, co-author of the report and director of investigative response for Verizon Business security solutions, talks with CNET News' Robert Vamosi about some of the investigations Verizon has done into thefts by third parties, and the possible ties to organized crimes and terrorism.

Listen now: Download today's podcast

This week Tom Rusin, president and chief executive officer of Affinion's North America operation, is Robert Vamosi's guest. His company monitors the criminal underground for several thousand banking institutions by lurking in carder chat rooms.

"Carders" are the people who buy, sell, and trade online the credit card data stolen from phishing sites or from large data breaches at retail stores. Affinion is global, with offices in more than a dozen countries. And over the years they have provided a wealth of information to the U.S. Secret Service and the FBI. A few weeks ago, Affinion identified .Mac users who found themselves victims of a phishing scam.

"Any piece of info is priceless to these people," says Rusin.

Listen now: Download today's podcast

It may seem trivial to you what applications are on your desktop, but from a business or organization's perspective, it can be a serious matter. If an application provides unfiltered access to the outside world, this could create regulatory issues. Certain desktop applications can also indirectly or directly introduce malware inside the perimeter through file sharing. At the very least, some applications simply take away bandwidth (for example, streaming audio or video).

In its second report on Application Usage and Risk, Palo Alto Networks finds that 56 percent of the desktop applications surveyed use HTTP. Use of port 80, which the server uses to listen to requests from a Web client, makes it hard for organizations to filter or firewall the content.

Chris King, who appeared on Security Bites last April, talks this week with CNET News' Robert Vamosi about the report's findings, including the hidden risks in running Microsoft SharePoint or Lotus Notes.

To see all the risks associated with several hundred common desktop applications, Palo Alto Networks provides an online Applipedia.

Listen now: Download today's podcast

Google has entered the browser space. Chrome, its browser still in beta, is based on the open source Webkit project. Some will recognize Webkit as the foundation for another browser, Apple Safari. But Chrome also borrows heavily from Mozilla Firefox and Microsoft Internet Explorer, giving this new browser an old and familiar feel.

There is, however, innovation.

Tabs are arrayed atop the browser instead of in the traditional toolbar. And users can drag and drop the tabs on the desktop outside the browser. There is also a way to make an icon for GMail and Google Calendar on your desktop.

Deep down, Google has also upgraded how the browser handles Javasript. Gone are the days when Java applets simply gave you dancing babies on a Web page. Today we're running robust applications.

Joining CNET News' Robert Vamosi this week is Billy Hoffman, manager of HP's Web security group. Hoffman, along with Bryan Sullivan, also co-authored AJAX Security.

In this podcast, Hoffman offers what he thinks Google did right with Chrome, and what could be trouble down the road.

Listen now: Download today's podcast

A few weeks ago, the Dutch High Tech Crime Unit identified and arrested a 19-year-old Dutch man who allegedly was operating a botnet known as Shadow. This botnet, unlike more recent examples, used IRC, meaning its traffic was easier to trace than the Web-based command and control traffic used today by most new botnets. Shadow would infect users via Windows Live Messenger or MSN Messenger.

What's unusual here is that the crime unit then asked Kaspersky Lab to provide the identified victims, people who had unknowingly allowed their computers to become compromised, with instructions on how to neutralize the malware on their systems. While antivirus companies and law enforcement work together all the time, rarely has law enforcement been concerned about cleaning up a victim's machine.

This week CNET's Robert Vamosi spoke by phone with Roel Schouwenberg, senior antivirus researcher at Kaspersky, who happens to be based in the Netherlands, about the Shadow botnet.

Listen now: Download today's podcast

Iron Chef returns to Black Hat. No, its not the Food Network import from Japan broadcasting live, but the Fortify edition featuring lead security researchers as they struggle against the clock to find vulnerabilities. This year, the secret ingredient is open-source code.

Brian Chess, chief scientist at Fortify Software, and Jacob West, who manages Fortify Software's Security Research Group, tell CNET's Robert Vamosi that one team will use static analysis while the other will use fuzzing. Chess confirmed that Charlie Miller and Jacob Honoroff will be on the fuzzing team, and Sean Fay and Geoff Morrison from Fortify will make up the static analysis team.

Fortify says the Black Hat audience and co-hosts West and Chess will provide running commentary and encourage the competitors. Ultimately, the audience will judge the results based on originality of created tools, presentation of the number of bugs, and creativity of using the tools when searching for vulnerabilities. At the end, a winner will be named.

Listen now: Download today's podcast

Click here for full coverage of Black Hat 2008.

From gadgets that slide-show pictures of vacations past to calendars that show events in the future, Google Gadgets look cool. But they also have the potential to contain vulnerabilities like anything else within Web 2.0.

By design, Google Gadgets allow scripted code to be uploaded by the end user, creating interesting new attack vectors for those with malicious intent.

CNET's Robert Vamosi talked with Robert Hansen (aka Rsnake), chief executive of SecTheory, and Tom Stracener (aka Strace) of Cenzic. Both will be presenting a talk called "Xploiting Google Gadgets: Gmalware and Beyond" at the annual Black Hat conference in Las Vegas next week.

During the talk, they plan to disclose a zero-day vulnerability in Google Gadgets that will make Gmalware (Gmodules-based malware) a significant threat.

For years, one of the arguments for using open-source software instead of proprietary software held that open source was more secure. After all, having thousands of eyes looking at the code can't but help find and mitigate potentially dangerous bugs. A new report from Fortify challenges that assertion.

Open-source software can be found in over half of the enterprises today. And open source code can be found within the Mac OS 10 operating system. But how are open source vulnerabilities and, more importantly, their patches handled?

This week a report from Fortify found that, while vulnerabilities exist and are reported within the open-source community, not every open-source project had a clearly defined contact or security alias. Nor was it clear what the process would be for issuing a patch, or how the projects conduct their own vulnerability assessments. The report looked at several known open-source projects such as JBoss and Tomcat.

CNET's Robert Vamosi spoke by phone with Roger Thornton, CTO at Fortify about the report and its findings.

Listen now: Download today's podcast

To put it simply, the concept of "white listing" is to define a set of software, a set of vendors, and allow only those trusted applications or files from those vendors to run on your machine. If a file or application is not approved, it will not run. This is the opposite of how we've blocked malware from our machines in the past.

In 2007, Symantec detected more than 1 million viruses, with two-thirds created within the calendar year. Loading 1 million antivirus signatures or even a percentage of that if generic signatures are used is a pretty serious undertaking. The idea here is that maybe we should only be loading signatures for the good files.

So far, the idea is only being implemented in the enterprise space. Still, it's a interesting idea. On the desktop it's already being used to stop spam, so why not use white lists to block malware as well?

Massachusetts-based Bit9 has created one of the largest catalogs of "known good" and "known bad" applications. Its Global Software Registry (GSR) serves as the policy enforcement center for Bit9's enterprise offerings. Recently, desktop antivirus vendor Kaspersky announced a partnership with Bit9 that will allow it to use the GSR in its upcoming desktop products in 2009.

This week on the Security Bites podcast, CNET's Robert Vamosi talks with Tom Murphy, chief strategy officer for Bit9, about white listing and its potential for the future.

Listen now: Download today's podcast

Below is a transcript of my interview with Dan Kaminsky. The podcast can be heard here.

Me: You mentioned that you didn't expect to discover this particular vulnerability, the DNS vulnerability. What goes through your mind when you hit upon something that you think might be a vulnerability?

Dan Kaminsky: If you look at lot of my research I'm generally looking for interesting capabilities that are within the system. So really what goes through my mind when I find some new interesting capability with the system and just unfortunately the reality of things is, I can do X. Is X bad and then to be concrete that X caused a traversal of a security boundary?

The other day we had some remarkably complicated security policies floating around the Web and e-mail and various other things. There is a lot of things we want Web browsers to do, and there are a lot of things we absolutely need Web browsers not to do. And it's the same for Web browsers and it's for Office clients and it is for DNS servers, everything has capabilities, everything has more capabilities than they were originally designed to have. Those capabilities are problematic.

Me: There is no hard and fast rule when discovering a vulnerability. I know some people have discussed the model where a researcher reports directly to the vendor and then sits on it for 90 days or so. Where do you fall on public disclosure of vulnerabilities or contacting vendors or all of the above?

Kaminsky: I've spent my entire career in corporate environments. I didn't even start out as a security engineer. I...really started out doing graphics. Then I got a job in networking. I got into security because I was offered a really boring job and, you know, it's easy to break the code. But I've always had the freedom to develop new and interesting software. And the reason or the big source of that freedom is the complete lack of liability in computer software programs. This is not a bad thing. This is actually an important thing and a critical thing to the ability to innovate. Really.

And this is going to sound a little strange because it ultimately goes back to the ultimate purpose of vulnerability research. There are two kinds of human creativity: there is the kind that kills people and there is the kind that doesn't. Pretty much anything physically manufactured can kill you. Humans make chemicals and there is lots of stuff that can have chemicals. I mean, you know, you look up, the ceiling can fall on you, the paint on the ceiling can have fumes, the keyboard you're typing on can have fumes, or the phone that you're talking can too. Pretty much anything physical has product liability associated with it. Well if anything goes wrong then you're going to have to pay.

And then there is the Hollywood movie. It can be terrible, it be can be awful, it can be atrocious, it can be the worst thing you ever put to celluloid and you're not going to die, and so there is no liability for a terrible movie. Software, believe it or not, is actually in the second category. Yes, software can kill people but it's insanely rare. More people are killed by crashing windows than by Windows crashing. So we don't have liability associated with software and as such they can be far, far faster because the cost of handling is much lower.

But it does not mean the cost of failing is zero. We have this interesting third category where you're not going to die but you might go broke. You might get everything stolen. You might get everything lost. And with this third category we need some way, if we're not going to have liability. I'm not going to name names, but there are lot of the products, I don't know what decade they could ship if product liability was in place but it wouldn't be this one, it probably wouldn't be next one.

We need some way to at least differentiate good software from bad and that is what interestingly independent vulnerability research allows. It allows the market to monitor the quality of software, and to figure out what's safe and what isn't. That creates positive pressure toward writing safer code. And that is right now, how in the lack of a liability model, we can still get more secure code. It's not cheap but it's actually happening.

Me: So you have this body of independent researchers looking at code, doing a service. They found something and there is two or three different ways that you can go with it. Some people sell it to a company that says, "We'll act as your intermediary and we'll contact the vendor for you." Others approach the vendor directly and say, "I'm going to work with you on it." And still others immediately post it to the Internet and say, "Look, I found this."

Kaminsky: Well, there is also the fourth where you provide it, you sell it to someone who is not going to provide it to the vendor. And I do not expect that market to ever be a legitimized market. But focusing on three you just named, there's no problem selling an exploit to someone who is going to provide it to the vendor freely. I don't necessarily understand why companies are in that position where they're paying for vulnerabilities that they're providing to the vendor for free. But I'm not going to complain about it.

I just spent the last six months doing a lot of work that is not particularly technical--it was three days to find the hole, it was six months to get everything in the patch. That's a lot of work. But I mean if companies like Zero Day Initiative want to be in that position, I think they're great; they're, often they are a force for good in our industry. I have no problem with somebody going ahead and doing the work, that work with each vendor directly.

So, it's a group thing as well, and at the end of the day, bug finding is communicating, anyone who's ever worked in software knows that it's not enough to file a bug and be done with it. The tester and the programmer often need to test the code to actually figure out what the problem is. They all got the same goal: ship good stuff, launch good stuff.

I'm not a big fan of just dropping things out onto the open Internet. I mean, you know, what we're looking at, what we're looking for, is more secure code. We're looking for people to be able to protect themselves. Yes, when you drop it on the Internet, everyone knows, including the vendor, and that is way better than some alternate models.

But at least I prefer there to be some kind of responsible disclosure timeline. Now, it can't be forever, because if it's forever, nothing ever patches and then the market never gets the information to know what's safe and what isn't. But people need some time. I mean we're engineers here, and engineering takes time. It takes effort, takes testing, takes work to get out of the door.

Me: So walk me through. I know I wasn't to going to ask directly about the DNS thing, but you discovered it say early in the year and then you had a meeting with the vendors and then you arrived at a date where you're going to announce it; you had a timetable. Is that about right?

Kaminsky: It is about right; I mean this is an unusual situation in that you don't usually have one bug show up in every single implementation. In this case and it was not every single implementation. EDNS is not vulnerable, Bert Hubert's PowerDNS is not vulnerable. A lot of the newer DNS servers just have always been following this guidance, but the stuff that everyone was running: Bind8, Bind9, Microsoft DNS, IOS, these things were vulnerable. So what happened was and I don't want to take all the credit for this...Paul Vixie is a machine. I mean that guy has been doing DNS since I was in grade school.

So I went to Vixie because I had been doing DNS research for a long time. I said, "We got a problem. We got to figure out what to do here." And we eventually decided that we would have to hold a summit, that needs to be done in person.

Microsoft was very gracious, they completely agreed to host it and we had 16 people from all vendors and all these people (who) have been doing DNS for years fly in. We sat down, we did three things. First we looked at the problem, were we actually understanding this problem? Second, we tried to figure out what is the fix that would best protect the customer? And there are many fixes possible and once the bug is out, there are many more fixes possible.

And we ended up choosing a fix that would survive reverse engineering as long as possible, not forever, but as long as possible. And finally we all agreed the nature of this bug was such we needed to do a simultaneous patch. We needed to all do it at the same time...

Me: So how long...?

Kaminsky: ...and that's what we got.

Me: How long between the discovery and when you actually had these people in a room together discussing it?

Kaminsky: It was--between contacting Vixie and us actually going ahead and getting this together--no more than a few weeks. We spent some time going back and forth on the e-mail and, you know, e-mail was great, e-mail is wonderful, but sometimes you just got to get bodies in the room.

Me: So this was on March 31, 2008?

Kaminsky: Yeah.

Me: At some point on that day or thereafter you decided that you would have a simultaneous release on a particular date?

Kaminsky: Yes.

Me: So going back to the whole disclosure thing: what if there was an independent body that certified that software met certain standards, sort of a good housekeeping seal of approval? Would something like that work in today's market?

Kaminsky: I think people underestimate the degree to which new vulnerabilities are found and new classes of vulnerabilities are found. A good housekeeping seal is, I mean it's, there is entire classes of low-grade bugs. I love to see something that said, "This software was bugged." I mean seriously, that would be fantastic. People shouldn't think that that is a replacement for independent security research, but yes at the end of the day we should have better ways for the market to be able to differentiate good code from bad.

Me: With regard to the DNS again what have you learned that you would maybe pass on to other security researchers about the process of brining multiple vendors together, anything that you would do?

Kaminsky: So this is an unusual lesson, but I'm going to bring it up anyway because it's been almost, we managed to deal with it at the last moment. Unless it's really, really, really, really important and you're willing to stake your entire reputation on it, do not do a huge big press thing with no technical details. If it is so important that you must do a big press thing with no technical details to get people to patch. No, it's not enough to have the entire vendor community behind you. No, it's not enough to have the entire DNS community behind you. You got to go ahead and get some of the other security engineers in the field, who are known, and they got to know everything and they got to go out with you.

So I went out with pretty much only the DNS people and only the vendors, didn't get other hackers in on it and you got to realize people in the security community need to be very, very skeptical. They have to, because it's so easy to make stuff up. It's so easy. You can just say anything and the press will believe you. I mean that's the honest truth. So there is a lot of skepticism and really, unless it's the most important thing you've done, go out with technical details. If you don't, go out with other hackers. Even if you're the guy who did, does DNS, don't go out alone. That probably be the biggest thing that I learned above and beyond the standard, you know, talk to the vendors, synchronize times, blah, blah, blah.

Me: I think you spent the last 48 hours working it out with your fellow security researchers?

Kaminsky: Oh! Yeah, yes. There was a wildly entertaining phone call with Thomas Ptacek.

Me: Yes, so...

Kaminsky: I'm not even joking, it was an absolute blast. And having to keep this secret for the entire year, actually being able to speak it aloud is kind of cool.

Me: You realize that that one session at Black Hat is going to be full of people waiting to hearing what you've to say.

Kaminsky: Don't remind me. I got my stuff. I got my toys.

Me: Well, I've seen you speak before. I know you will do really well. I appreciate the time you took to speak with me today and...

Kaminsky: No worry, just happy to help.

Me: All right Dan, take care.

Kaminsky: Good-bye.

Me: Bye.