Podcasts

This week's podcast is brought to you by Microsoft and hosted, as always, by Vigabyte virtual hosting.

On this week's show we hear from Bryan Sartin of Verizon Business Security Solutions. He'll be discussing that company's 2009 Data Breach Study.

Verizon has a well-established forensics unit and its reports are interesting. This study is to the infosec industry what black box reports are to the aviation industry; a post mortem examination of what went wrong.

We also check in with Stuart Strathdee, Microsoft Australia's Strategic Security Advisor in this week's sponsor interview. He'll be chatting about Microsoft's own Security Intelligence Report. There's some really surprising results to come out of that one.

Paul Craig is this week's news guest.

The report is essential reading; the post-mortem analysis of data breaches is to the information security industry what black-box flight recorder information is to the aviation industry. By understanding where things have gone wrong, we can avoid repeating the mistakes of some of our peers.

A phone interview with the company's director of investigative response, Bryan Sartin, has been recorded and will be included in Risky Business #104, which is due to be published in the next 24 hours.

In the mean time, the 52-page report can be found in pdf form here. It's a must read for anyone working in enterprise security.

The report makes some fairly sweeping claims about dataloss trends. Take them with a grain of salt. The statistics the company is presenting here are cobbled together from its investigation of approximately 100 dataloss incidents.

When forming your own opinion about the information presented, keep in mind the company can only put forward statistics drawn from jobs it worked on. There are many providers of forensic services. A big uptick in the number of breached records Verizon has investigated doesn't necessarily mean there's been more breaches; it could just mean the company's forensics department has grown.

That said, a report containing this much gory detail on dataloss incidents is still valuable to anyone charged with securing enterprise data.

DISCLAIMER: The following text came from a press release issued by Verizon Business:

The financial Industry accounted for 93 Percent of incidents investigated by the company, which claims most of the breaches reported to it were avoidable.

The study, based on data analysed from Verizon Business' caseload of 90 confirmed breaches throughout 2008, revealed corporations fell victim to some of the largest cybercrimes ever during 2008.

Nine out of 10 breaches were considered avoidable if security basics had been followed. Most of the breaches investigated did not require difficult or expensive preventive controls. The 2009 report concluded that mistakes and oversight failures hindered security efforts more than a lack of resources at the time of the breach.

Similar to the first study's findings, the latest study found that highly sophisticated attacks account for only 17 percent of breaches. However, these relatively few cases accounted for 95 percent of the total records breached -proving that motivated hackers know where and what to target.

Key Findings of the 2009 Report:

• Most data breaches investigated were caused by external sources. Seventy-four percent of breaches resulted from external sources, while 32 percent were linked to business partners. Only 20 percent were caused by insiders, a finding that may be contrary to certain widely held beliefs.
• Most breaches resulted from a combination of events rather than a single action. Sixty-four percent of breaches were attributed to hackers who used a combination of methods. In most successful breaches, the attacker exploited some mistake committed by the victim, hacked into the network, and installed malware on a system to collect data.
• In 69 percent of cases, the breach was discovered by third parties. The ability to detect a data breach when it occurs remains a huge stumbling block for most organisations. Whether the deficiency lies in technology or process, the result is the same. During the last five years, relatively few victims have discovered their own breaches.
• Nearly all records compromised in 2008 were from online assets. Despite widespread concern over desktops, mobile devices, portable media and the like, 99 percent of all breached records were compromised from servers and applications.
• Roughly 20 percent of 2008 cases involved more than one breach. Multiple distinct entities or locations were individually compromised as part of a single case, and remarkably, half of the breaches consisted of interrelated incidents often caused by the same individuals.
• Being PCI-compliant is critically important. A staggering 81 percent of affected organisations subject to the Payment Card Industry Data Security Standard (PCI-DSS) had been found non-compliant prior to being breached.

All enterprises must eventually accept that security is just one more part of software or system development lifecycle. Both designs and implementations must be reviewed, developers need security training and infosec teams need the power to veto go-live dates.

Lots of businesses have arrived at this point. But what often happens as a result is security gets siloed per project. The project scope determines where security people will see, where there is budget, and critically, where the incentive to fix the problems lies.

This means that the way that project siloes interact -- the reefs between scope islands -- are never in scope. And as we all know, scope is for project managers, auditors and security consultants. Hackers don't care about your scope.

Let's look at how scoping can create some pretty peverse outcomes.

So I owned this bank system. Hard. Pentesting externally, I managed to go from no auth to complete customer account compromise. I could reset passwords, transfer money, whatever. Pretty bad as customer facing banking system deployment projects go, right?

I head to the wrapup meeting, held in a typical bank meeting room. You know the type -- poorly cleaned motorised-printy whiteboard that no longer motors, acoustic tiled ceiling the colour of institutional gravy, one glass wall out into the post-carpet-cubicle humanist refurbishment.

The cubicles are slightly curvy now, less beige, lower and more modular and hip, but still festooned with the trademark flotsam of the corporate slum; a thousand colour laser printed pictures of funny cats, babies, daughters with ponies, movie posters with someone's head photoshopped -- no hang on, MS paint.exe'd -- on and captioned with some tepid project in-joke.

This is the meeting where I explain what's going to be in the report, discuss the technical remediation options with the developers and the impact on project go-live signoff with the project manager. Normally what you're aiming for here is dismissive-defensive-disbelief-dawninghorror from the developers, and something approaching open weeping from the PM. A grimace is good, but actual sobbing is better.

I lay it out for them. A few technical details for the nerdy types, some screenshots on my laptop for the PM, then the chill starts to set in. The PM is ashen, the developers in the final d-stage. Beautifully orchestrated meeting-fu, Metl. They're weeping from the palm of my hand. So much for that project deadline, now a zeppelin destined to miss its mooring post in the dark night sky.

"Oh, god, there's no way we're going to be able to go live Friday week," the PM cries. "This is a disaster; Bob's HVT project depends on, oh, and the entire New SSI project... How are we going to..."

But I too am human and I misjudge my final salvo; I let my guard down, falling for the anthropomorphism the marketing team work so hard to erect: That the corporation is a caring, living organism, in verdant symbiosis with its adoring customers.

"I, uh, think this affects the live system too," I say.

"Whaaaat?"

"Yeah. I didn't test it obviously, but this bug is due to the way your new system interacts with the backend DollaMasta2000. If anything, it's a business rules bug, where your ..."

I trail off. The project manager has a rictus grin on her face. All of a sudden I feel unsure of myself, like I've just made some awful faux pas. I feel like a turd in a punchbowl.

"Are you saying," she begins slowly, "that this affects the production system? That you could do this to anyone's real accounts? My account?"

Oh, phew, I think. She does get it after all. "Yes!" I gush, enthusiasm at my own cleverness replacing the awkwardness of a moment before. "I can own anyone's account, this is pretty bad."

"OH THANK CHRIST FOR THAT!"

I blink.

"LEGACY ISSUE! OUT OF SCOPE! DOESNT AFFECT OUR GOLIVE! NOT EVEN IN OUR BUDGET! OOOOH YEAH!"

There's a big, shit-eating grin on her face. You. have. got. to. be. kidding, right Metl?

No, I'm not. I'm serious. This is how it went down. I'm not making this up.

That's what "scoping" is doing to your enterprise.

So here's my one line take-away for this week:

Hackers don't give a shit about your scope.

They couldn't care less if that legacy HPUX box wasn't in scope when you did the Northern-Data-Centre Refresh Project. They don't care that layer-2 segregation is implemented by one team, but that layer-3 filtering is implemented by another, and the two don't talk. They don't care that all your corporate laptops are locked down as hell, because the CEO is surfin' on his wireless toobs at the airport business class lounge and just got owned.

The fundamental asymmetry of this industry wins - the hacker only has to find one easy way in, and that, I guarantee you, will be in the place that was never in scope.

Project-based security is important for the long-term health of your business, but don't let it starve out real, holistic, enterprise-wise security goals. Don't write off business-targeted, no-holds-barred pentesting as 'scaremongering'; don't get hostile because the pen-testers waltzed around your network popping shells and illuminating your failings with all the stark horror of a blacklight in a Vegas hotel room. It's our job, and some of us are good at it.

Sometimes you need to let us own you, hard, brutally and for real. To show you how easy it is, to gouge out real business impact, to shred all the garish crepe paper disguising the cracks around your delusional scoping. You need to be re-focussed, brought back down to earth, out of your politics and scoping and business silo structure, because the truth here is that no one outside of your organisation gives a shit, and least of all the dude that just owned you.

Metlstorm is a New Zealand-based freelance security consultant. He's created several tools including Hai2IVR, Winlockpwn and SSH Jack. He's also an organiser of the annual Kiwicon security conference in Wellington, New Zealand.

Under this Act, lawmakers are seeking to impose requirements on ISPs and wireless network operators to keep records about the identities of their users.

Under the law, network operators would have to retain the network addresses assigned to any users for a minimum of two years, information which law enforcement could use to track down criminals.

But the broad language of the Bill, which would apply to any "provider of an electronic communication service," could mean that coffee shops, airport lounges and even individual households would be required to keep detailed logs, and that just isn't going to happen.

The Bill is well intentioned but creates requirements that could never be enforced.

ISPs keep logs anyway -- they have to for billing purposes. All they need to do to comply with this new law is buy a few terabytes of storage, tweak a couple of settings and Bob's their mother's brother.

As for non-ISP electronic communications providers, any logging requirement placed on them wouldn't just involve storage space but also the management, development and security of the collected data.

The proposed US Bill suggests wireless networks should have capture and retention of logs. That's great in theory, but not all wireless devices have this ability. Sure, products like Microsoft Wireless Monitor allows network operators to view details about access points and wireless clients. But this is information is primarily designed to troubleshoot wireless services.

Then there are jurisdictional issues. Transactional data collected from travellers at an international airport, for example, is next to useless unless there are formal mutual legal assistance treaties between the country where the data is being retained and the country where the suspect is located. They may have been using the airport facility during their vacation.

Further, who is going to monitor compliance? All CBDs are littered with wireless networks, some public, some not. Identifying the owner of the network is one thing, finding someone to hold responsible is another. And how would such directives be enforced? Civil action would seem the most logical against those companies that refuse to comply. But this is costly, time consuming and just not very likely.

The questions pertaining to online data collection are global. While regulators bear the ultimate responsibility of ensuring markets work, consumers and businesses must be involved in the debate to determine acceptable data collection and retention standards.

Nigel Phair was the Team Leader of Investigations for the Australian High Tech Crime Centre from 2003 to 2007 and the author of Cybercrime: The Reality of the Threat. He is an active cyber crime analyst.

This week's show is sponsored by Sophos, and hosted, as always, by Vigabyte Virtual Hosting.

In this week's feature interview we'll be hearing from former Network Solutions CSO Richard Forno.

He's joining us to discuss a proposed bill in the USA that would require all information security professionals working on government systems to hold some sort of certification. It's an interesting idea, but Forno hates it.

Also on this week's show, Paul Ducklin from Sophos pops in to do his best to debunk the GhostNet conspiracy. Researchers from Cambridge and Toronto Universities claim to have uncovered a clandestine, state-sponsored espionage ring targeting pro Tibet politicians.

Ducklin is very sceptical and will be along soon to tell us why.

Declan Ingram of Securus Global is this week's news guest.
Don't forget to leave some audio feedback for inclusion in next week's show! Call Sydney 02 8569 1835 or USA +1 877 688 8417 (Toll free).

The move seems to be an attempt to offer the BSD kernel within the Debian Linux userland environment. Users who install Debian's FreeBSD kernel will be able to use the BSD packet filter, pf, as well as other BSD-specific security features like jails.

Debian has also claimed BSD is immune from many of the legal challenges facing the Linux operating system. "Linux sources are like a minefield," a memo from Debian reads. "kFreeBSD is much less vulnerable to such attacks because of its less bazaar-like development model."

Representatives of GM Holden would not confirm they will soon release a Ford-engined sedan, and reports of french fries eating people are, for the moment, unsubstantiated.

The vulnerability affects versions of PowerPoint running on Windows and Apple OS X, security-vendor McAfee has reported.

The stark warning came this morning as Microsoft posted a security advisory and new entry on its Malware Protection Centre website.

"Microsoft is investigating new reports of a vulnerability in Microsoft Office PowerPoint that could allow remote code execution if a user opens a specially crafted PowerPoint file," the advisory reads. "At this time, we are aware only of limited and targeted attacks that attempt to use this vulnerability."

That's reassuring. Unless you're the one being targeted.

As a fantastically practical mitigation strategy, Microsoft recommends users don't open PowerPoint files that arrive unexpectedly, either from trusted contacts or stranger dangers.

Users who really must open unexpected PowerPoint deliveries can use the Microsoft Office Isolated Conversion Environment, or MCOIE. That software performs sanity-checks on Microsoft binary formats, converting them to known-safe files. "[The] MOICE will protect Office 2003 installations by more securely opening Word, Excel, and PowerPoint binary format files," the company says.

Vendors are rolling out sigs as we speak.

Microsoft has posted an excellent write-up here.

This week's Risky Business podcast is brought to you by MessageLabs, and hosted, as always, by Vigabyte virtual hosting.

On this week's show you'll hear some audio from a hearing in the US House of Representatives -- excerpts from the subcommittee on Emerging Threats, Cybersecurity, and Science and Technology Hearing. That hearing posed the question "Do the Payment Card Industry Data Standards Reduce Cybercrime?"

Apparently they don't.

In this week's sponsor interview we chat to Paul Wood from MessageLabs in the UK about some of the more innovative features in malware these days. Paul's up to his armpits in the stuff, so he has some interesting things to say.

Paul Craig from Security-Assessment.com is this week's news guest.

If you'd like to comment on anything you've heard on Risky Business, or suggest something you'd like to hear on the show, you can call Sydney 02 8569 1835 or USA +1 877 688 8417 (Toll free). We'd love to hear from you.

"They're making us roll out Active Directory," he whined, looking for sympathy from a fellow UNIXnerd. But the sad, awful truth is this: Windows infrastructure is actually usable -- and perhaps even securable -- in the enterprise.

Ugh. It pains me to say it, but really, are you trying to tell me that you'd prefer NIS, NFS and LPR over AD and SMB? Oh come on, even from a usability perspective, let alone security. To get any sort of kerberized auth for file sharing in UNIX, you're dispatched into the ebola-grade intestinal sloughing of AFS. And sure, CUPS kinda works, but when did you ever celebrate because your Windows printer worked?

To really gouge some salt into the wound, go count the number of security advisories in UNIX kerberos implementations. Now compare to Microsoft's.

Yeah, exactly.

What's funny here is that the age-old dichotomy -- Windows for games, UNIX for Serious Intertubes Bizness -- is actually ass-backwards for the enterprise. Your average home user Windows box is an awful, spyware ridden porn-popup carnival, and your average home UNIX box is a fully patched Ubuntu with a 190 day uptime.

But in the enterprise, people run fully patched Windows Server 2k3 domain controllers, and locked down desktops with nicely packaged software rollouts, reimaging procedures, patch management, endpoint security software and jolly corporate screensavers showing your fellow workmates grinning as they build brand value.

And the UNIX systems? Oh, God. Ancient Solaris boxes filled with awful, awful "Enterprise" UNIX software. BMC anything, Tivoli anything, anything that does backups or SNMP, or even worse, CA anything. Awful shellscripts written by well meaning admins, awful outsourced UNIX managment, awful root cronjobs running awful scripts off awful NFS shares. Never ever patched. Never up to date.

Let's face it, while the availability of UNIX systems might be great, for the other two corners of the CISSP triad -- integrity and confidentiality -- they're fucking awful.

Ask yourself - when was was the last time you saw a corporate UNIX environment that doesn't make you rub your temples and sob quietly into your audit worksheet? Or a Sol10 box that despite its ZFS and zones and all of Sun's engineering whizbangerry, wasn't adminned like it was 2.5.1? Now, what about when you last saw decent, competently run Windows infrastructure? Probably, what, last week?

This all came to me today as I audited a UNIX box. (Don't be shocked. I do have a beard.)

UNIX host configuration reviews are in our blood in this industry -- many of us grew up playing with, hacking, escalating privilege on UNIX boxen; our home 386 Slackware Linux, university Solaris machines, random HPUX or AIX or, ha ha ha, A/UX, Apple's UNIX from way, way before this whole ridiculous Mac OS X lark.

Reviewing a multiuser UNIX for config and local priv escalation, well, it feels like coming home. Grandma's warm apple crumble, coffee at dawn looking out your kitchen window, or finding that postcard from a holiday romance 15 years ago. It's probably how Rob T Morris Jr. feels every time he sees a sendmail MTA string in his headers.

I heart UNIX.

This particular box is running some Serius Internets Bizness -- important stuff -- and after the UNIX ops team finish their kibitz, sucking their teeth at my request for the mighty root access to a production server, I finally sit down to start. I don't really have the heart to tell them that my asking for root is just professional courtesy.

After covering off the basics, I settle in for the enjoyable bit -- going through all the user and network service accounts, then figuring out how to get root from every single one.

It rarely gets as far as rpm -qa to figure out if they're patched up to date (they never are). I take perverse satisfaction in auditing UNIX filesystem permissions - there's something oh so sweet about the simplicity of it all. Oh, look! BMC Patrol runs at boot, gets started by that initscript as root, which sets its path to include /opt/patrol/bin before /bin, and oh dear that directory is owned by uid patrol. *Sigh* Oh look, suid root bins which include libraries writable another user. *Sigh*. Oh look, root writing files in directories that are world writable and aren't sticky. *Sigh*. And ohmigod, did you see that sudoers config? I actually laughed out loud at that one, and over the carpet cubicle wall I hear someone saying "uh, its not good when the beardy security consultant is giggling like a schoolgirl in his little blue culottes, is it?"

Well, yes and no. I mean, they did try. It was certainly no worse than any other enterprise UNIX box I've reviwed, and better than plenty. Sure, the umasks are crap, sure there's 87 different versions of the java runtime installed from 2003 to present, sure there's more suid binaries than the Suharto family has rupiah, sure there's world readable SSL private keys and cleartext passwords in bash_histories and X11 displays with xauth + and... oh my, those shellscripts, they make my eyes water with the mirth of it all.

But! None of this is unusual, or different, or even particularly worse than any other enterprise UNIX box. That's when it hit me. We really don't think about Windows as a multiuser OS like we do with UNIX. That gives it the advantage.

Because we can't trust individual Windows systems, we have to build resilient Windows networks with single sign on that's actually usable plus all the management tools that make it possible to actually run large-scale desktop computing infrastructure. God help the poor engineers at Novell tasked with doing this all with SuSE.

I hope never to be a corporate Windows admin. I'd take the corporate UNIX admin job any day of the week instead -- my pager would go off less often, I'd meet my KPIs better, and I'd be much, much happier than the poor Windows sod with his recurring MS Patch Tuesday nightmares. But would I believe that my shit was more secure than his?

Well, I present to you the Metlstorm Simple UNIX Examination (the 'MetlSUX' if you will):

# find / -path */bin/java | wc -l

0-5 Lucky you, you might make it to 21 mins
5-10 Write once, test everywhere
10-30 Serious Internet Business Production System
30+ Do you, like, work at Sun?

Metlstorm is a New Zealand-based freelance security consultant. He's created several tools including Hai2IVR, Winlockpwn and SSH Jack. He's also an organiser of the annual Kiwicon security conference in Wellington, New Zealand.

Over the last few weeks you may have read reports of a computer virus named Conficker. It's sophisticated and has infected millions of systems.

What you might not know is you actually funded its development.

The virus writers of old were trying to bring the pigopolist system down, man, but today, it's all business. Viruses make money for their creators by stealing credit card data from infected systems.

This type of fraud is the backbone of the cyber-criminal economy, and because merchants are generally forced to cover the cost of card fraud[1], they've already factored losses into the price you pay for that six-pack of beer or that new plasma screen telly. You're funding this crap, and it's the banks' fault.

Let's dig a little deeper.

Estimates of the number of computers Conficker has infected range from three million to 15 million. In anyone's language, that's a lot of computers. But Conficker is what many in the computer security field would consider a "garden variety" virus. Aside from its admittedly impressive distribution, it is sophisticated but unremarkable.

So why all the media attention? Well, for starters it's due to "activate" on April 1, and there's nothing the media loves more than a good old-fashioned countdown. Consider it a mini-Y2k to feed the news cycle. And like Y2k, there'll be some fairly disappointed commentators and doomsayers when, on April 1, Conficker quietly upgrades itself on the computers it has infected and starts doing the rather mundane bidding of its masters.

No mushroom clouds. No power blackouts. No blood running through the streets.

The Conficker network -- all of the infected systems can be controlled by the creators of the virus -- will just do what similar nasties have done in the past and start sending spam and viruses to other computers, stealing the credit card numbers of the owners of infected systems via keystroke logging software, and attempting to overload the websites of grey-market Websites.

Those with most to fear from Conficker -- in the short term at least -- are online casinos and pornography sites. The network of Conficker-infected computers will be able to overload selected websites with bogus requests until the target falls over.

It's called a Denial of Service (DoS) attack and through blackmail, it pays. Want your Web site to work again? Give us $10,000 and we'll stop. For now, there are enough payers out there to make DoS attacks worth doing.

But the big money is in credit cards. In fact, if credit cards didn't exist, the size of the cyber "underground" -- the unholy alliance of computer criminals and more traditional fraudsters -- would be considerably smaller.

It works like this. Every time you make a purchase online, there's no way for the merchant to know if you are actually holding the card in your hand. They need the card number (16 digits), expiry date (4 digits), the name on the card and sometimes the three-digit "security" (ha!) code from the back.

So all anyone needs to make a credit card purchase from your Visa or Mastercard account is 23 digits and a name. Modern viruses like Conficker intercept this information from your computer as you type it into your keyboard. And we wonder why the bad guys are raking it in. Alternatively, skilled attackers may break into the systems of merchants or credit card processors and steal large databases containing your credit card data. This, in a nutshell, is how online credit card fraud works.

Card-not-present fraud in Australia has increased by 50 percent over the last 12 months, according to the Reserve Bank of Australia. You'd think this would have the banks scrambling to remedy the situation, but as the liability for most fraud rests with merchants, they have little motivation to invest in solutions.

In fact, a secure online transaction project named MAMBO, being developed by bank-owned payment services company BPay, has been postponed because (it's rumoured) there wasn't a strong enough business case for it to continue. If banks were forced to own the liability for card fraud, that business case would change instantly.

For their part, consumers are protected from fraud on their cards by the card issuers, so they don't have a reason to kick up much of a stink. So the merchants carry the can for the bulk of the fraud and, of course, they factor fraud losses into their prices.

You are funding criminal activity while the banks stall projects that could combat it.

Think of the "fraud premium" on prices (or the infamous "credit card surcharge") as a tax the merchants apply to everything you buy. That "tax" exists to recoup the money destined for large criminal syndicates, which use it to invest in better computer virus technology.[1]

This is what economists would call a market failure.

Over the last several years there have been token efforts to improve the card fraud situation. The Payment Card Industry Data Security Standard, or PCI DSS, forces merchants to make some effort in securing credit card data as it passes through their systems. It's expensive to implement and it's clearly not working. Merchants' systems are still being breached left, right and centre.

PCI DSS is a band-aid on a bullet wound, and governments are starting to notice. The United States House of Representatives Committee on Homeland Security has just held a hearing (today) into the effectiveness of PCI DSS. The Department of Homeland Security is concerned the proceeds of data breaches and credit card fraud are funding terrorist activity.

It's not such a paranoid notion. Last year an influential Egypt-based cleric is believed to have issued a fatwa encouraging young Muslims to engage in cyber and credit card fraud to fund anti-Western activities. (No one has actually found evidence of the fatwa, but on the Internet perception is reality, and the unconfirmed edict is held as truth.) Herein lies another reason to fix the broken credit card model.

So what can we do? Well, we need to make card not present fraud impractical to carry out. We can make a good start by introducing more robust forms of authentication to card not present transactions. SMS or voice biometric authentication would be a good start. Banks in Europe are experiencing some success with portable chip and pin readers.

Alternatively we could move to a completely different transaction model in which your sensitive information is never handed to the merchant, such as in a direct deposit via your online banking. It's a much more sensible way of doing things.

The fact is we are moving toward a more secure online environment, but the progress to date has been glacial. Let's hope that in a few years advancements in transaction security will rob criminals' motivation to create computer viruses like Conficker. Until then, we've just got to ride it out.

[1] Some credit card companies offer schemes that allow merchants to shift liability back on to the card issuer, but they also come at a cost, as does chargeback insurance.

Patrick Gray is the host of the Risky Business security podcast and the managing editor of Risky.Biz, an information security news outlet.