Research

Threatpost has an interesting article up on the latest disclosure slime-fest (originally from Educated Guesswork). It seems VoIPShield decided vendors should pay them for vulnerabilities – or else. While I personally think security researchers should disclose vulnerabilities to the affected vendors, I understand some make the choice to keep things to themselves. Others make the choice to disclose everything no matter what, and while I vehemently disagree with that approach, I at least understand the reasoning behind it. At other times, per reasonable disclosure, researchers should publicly disclose vulnerability details if the vendor is placing customers at risk through unresponsiveness. But VoIPShield? Oh my: “I wanted to inform you that VoIPshield is making significant changes to its Vulnerabilities Disclosure Policy to VoIP products vendors. Effective immediately, we will no longer make voluntary disclosures of vulnerabilities to Avaya or any other vendor. Instead, the results of the vulnerability research performed by VoIPshield Labs, including technical descriptions, exploit code and other elements necessary to recreate and test the vulnerabilities in your lab, is available to be licensed from VoIPshield for use by Avaya on an annual subscription basis. Later this month we plan to make this content available to the entire industry through an on-line subscription service, the working name of which is VoIPshield “V-Portal” Vulnerability Information Database. There will be four levels of access (casual observer; security professional; security products vendor; and VoIP products vendor), each with successively more detailed information about the vulnerabilities. The first level of access (summary vulnerability information, similar to what’s on our website presently) will be free. The other levels will be available for an annual subscription fee. Access to each level of content will be to qualified users only, and requests for subscription will be rigorously screened. If you require vendor payment for vulnerability details, but will release those details to others, that’s extortion. VoIPShield is saying, “We’ve found something bad, but you only get to see it if you pay us – of course so does anyone else who pays.” Guess what guys – you aren’t outsourced QA. You made the decision to research vulnerabilities in particular vendors’ products, and you made the decision to place those companies’ customers at risk by releasing information to parties other than the appropriate vendor. This is nothing more than blackmail. Is vulnerability research valuable? Heck yes, but you can’t force someone to pay you for it and still be considered ethical. If you demand vendor payment for vuln details, but never release them, that might be a little low but isn’t completely unethical. But demanding payment and releasing details to anyone other than the vendor? Any idiot knows what that’s called. * Image courtesy dotolearn.com. Share:

Hi folks, Sorry if I’m getting all corporate on you, but I wanted to highlight one of the new thingamajigs over here. We decided to create an email list for people who are interested in the Friday Summary. We know we pump out a ton of junk compelling content every week, but it might be a bit overwhelming in these constrained times. We try to focus on the week’s highlights every Friday and point out some of the more interesting content out there (as well as our own stuff, of course). This is a once-a-week only mailing, and we’ll never sell the list or use it for anything else. You can sign up here. We also have the Daily Digest for you gluttons who want all our posts on a daily basis. You can go back to your regularly scheduled browsing now… Share:

hold Share:

Sure, the RSA Recovery Breakfast was a huge hit, but let’s be honest – if there’s any conference that really needs a recovery breakfast it has to be Black Hat. So we decided to team up with our friends at Threatpost and throw down, Vegas style. Thus we are proud to officially announce the Securosis/Threatpost Black Hat Disaster Recovery Breakfast! We’ll be holding it Thursday morning from 8-11 at Cafe Lago in Caesar’s, which is right near the bottom of the main escalators heading up to the conference area. We’ve set it up so we get to use the main buffet, but have our own private seating area with beverage services. Just like RSA it’s an open event – drop in and out whenever you want. We realize some of you would prefer we ran it from 11 to sometime in the late evening, but some of us have to work the show and such. We’ll provide the breakfast, appropriate recovery beverages, and a fine selection of hangover recovery supplements (over the counter only). Since Vegas isn’t the cheapest place on the planet, we do have to ask that you actually RSVP this time. Please email rsvp@securosis.com with your name so we can put you on the list. (Please only RSVP if you think there’s a reasonable chance you’ll make it). Feel free to email with any questions, and we look forward to seeing you in Vegas… Share:

I’ve been a bit erratic with my Dark Reading posts, but finally have a new one up. This one is dedicated to the topic du jour – cloud computing security. The article is The Only Two Reliable Cloud Security Controls and here’s an excerpt: It seems that we in the information technology profession are just as fickle as the fashionistas strutting around Milan or New York. While we aren’t quite as locked to a seasonal schedule, we do have a tendency to fawn over the latest technology advances as if they were changing colors or hem lengths. Some are new, some are old, some are incredibly useful, and others are completely frivolous, but we can’t deny their ability to enter and steer our collective consciousness – at least until the next spring. Take cloud computing. But definitional maturity doesn’t necessarily mean technological maturity, and is always a far cry from security maturity. While we now understand the different flavors and components of the cloud, and even have some relatively good ideas of potential security controls, the diversity of real world offerings and the traditional lack of security prioritization bring all the usual security challenges. The cloud is a collection of various proprietary technologies (mostly) from diverse vendors (mostly), all with different ways of doing things (mostly). Not that I’m complaining: if you work in security and don’t enjoy these kinds of challenges, you should probably consider a different career path. There are really only two reliable security controls – our service level agreements (SLAs) and personal education and knowledge of the cloud implementation. Share:

I can’t entirely promise tonight’s episode makes a lot of sense. Martin is back from Kyoto, and seriously jetlagged, and I don’t think I was a whole lot better. Sure, we cover the usual collection of security news, but the episode is filled with non-sequitors and other dissociated transitions. On the other hand, we do stick fairly closely to security related topics. In other words, listen at your own risk. Network Security Podcast, Episode 157, duration: 25:08 Show Notes Microsoft 0day being exploited in the wild. China is as scared of us as we are of them. See? Your mom was right. iPhones are vulnerable over SMS. I highly doubt the iPhone is the only phone with this problem. A “security guard” hacks a hospital’s HVAC system. Then goes to jail for additional stupidity. Good thing most bad guys are dumb, or we’d really be in trouble. More nails in the coffin that holds your Social Security Number. Share:

I had a weird discussion with someone who was firmly convinced that you couldn’t possibly have data security without starting with classification and labels. Maybe they read it in a book or something. The thing is, the longer I research and talk to people about data security, the more I think labels and classification are little more than a way to waste time or spend a lot of money on consulting. Here’s why: By the time you manually classify something, it’s something (or someplace) else. Labels aren’t necessarily accurate. Labels don’t change as the data changes. Labels don’t reflect changing value in different business contexts. Labels rarely transfer with data as it moves into different formats. Labels are fine in completely static environments, but how often do you have one of those? The only time I find them remotely useful is in certain databases, as part of the schema. Any data of value moves, transforms, and changes so often that there’s no possible way any static label can be effective as a security control. It stuns me that people still think they can run around and add something to document metadata to properly protect it. That’s why I’m a big fan of DLP, as flawed as it may be. It makes way more sense to me to look inside the box and figure out what something is, instead of assuming the label on the outside is correct. Even the DoD crowd struggles mightily with accurate labels, and it’s deeply embedded into their culture. Never trust a label. It’s a rough guide, not a security control. Share:

Technically the title should be Things to do With Encryption…, but then I wouldn’t have a semi-obscure movie reference. Cory Doctorow of BoingBoing linked to a column of his over at The Guardian entitled If I’m dead how will my loved ones break my password?. As a new father myself, I recently went through the estate planning process with my lawyer, and this is one issue I’ve long thought needed more attention. A few years ago I even considered building a startup around it. Much of my important data is encrypted – especially logins to bank accounts and such. Also, a fair bit of my other data is either encrypted, or protected in ways many of you fair readers could circumvent, but my family members can’t. I also have a ton of “personal institutional knowledge” in my head – everything from how to keep this blog running, to locations of family photos, to all the old email correspondence I kept when my wife and I started dating. If I get hit by a truck (or, more likely, kill myself in some bizarrely stupid way right after saying, “okay, check this out”), all of that would either be lost to the ether, or complex to recover. Heck, I have content that might be important to my family in applications in virtual machines on encrypted drives. Part of my estate planning process is ensuring that not only do my family and business partners have access to this information if I’m not around, but that they’ll know where the important bits are in the first place. Unlike Cory I’m not concerned with using split keys in different countries to prevent exposure to the government, but I also don’t think I’m as organized as he is in terms of where I keep everything. Thus, as part of my estate planning, I’m looking at the best way to make this information available on the off chance my sense of self-preservation fails to mature. Here’s the plan right now: Compile my passphrases, locations of important information, and other documentation into a single repository. I’m considering using 1Password since it already has the logins to nearly everything, I use it daily, and it can export to an encrypted PDF or a few other formats. 1Password supports secure notes for random instructions and other documentation. On a regular basis, I will export the information to an encrypted file which I’ll provide to my lawyer, and store in a secure online repository. I have a lot of options for this, but for the rest of you it might be better to set up a Hotmail/Yahoo/Whatever email account you don’t ever use for anything else, and send it there. You can then give your lawyer or executor access to that account (remember, the contents up there are still encrypted). This makes it easy to keep the information up to date, and it’s protected from your lawyer’s office burning down with your encrypted hard drive. It may be worth it to use two different services, just in case. Remember that if your lawyer doesn’t have direct access, it may be difficult for him/her to legally obtain access after death. I’ll give my lawyer the locations of the information and the passphrase for my 1Password export in a sealed envelope. Since he’s my brother in law, and might be with me when I accidentally blow up that propane tank, I’ll make sure his partner also has a copy in a separate physical location. That should cover it – my information is still protected (assuming I trust my lawyer), and it includes logins, locations of important electronic documents, and so on. I’m in the middle of setting this up, and haven’t even talked to my lawyer about the details yet, but it’s as important as any other aspects of my trust. A separate issue, and the other half of my vaporware startup, is what happens to all my correspondence/photos/movies after I die? Historically, the archives of individuals, handed down through generations, are an important part of the human record. This isn’t just an ego thing – letters and photos of regular folks are as important to historians over the ages. Right now, as a society, this isn’t an issue we’ve really addressed. Share:

Martin is off in Japan this week, so I’m joined by our good friend Amrit Williams from BigFix and the Techbuddha blog. Amrit and I start off by talking about the rolling blackouts in California and disaster preparedness, before jumping into the week’s security news. Network Security Podcast, Episode 156 Time:  41:28 Show Notes: The New York Times and Wikipedia censor reports of a captured reporter to protect him. Dave Shackleford on 10 things your auditor doesn’t want you to know. Trojan steals FTP credentials Juniper pulls ATM hacking talk from Black Hat Most systems have unpatched software. Is anyone surprised? Tonight’s Music:  Since I haven’t figured out how to get the podcasting rights to Jimmy Buffett’s entire collection, there’s no music for tonight’s close. Share:

One thing that’s really tweaked me over the years when evaluating data breaches is the complete lack of consistency in costs reporting. On one side we have reports and surveys coming up with “per record” costs, often without any transparency as to where the numbers came from. On the other side are those that try and look at lost share value, or directly reported losses from public companies in their financial statements, but I think we all know how inconsistent those numbers are as well. Also, from what I can tell, in most of the “per record” surveys, the biggest chunk (by far) are fuzzy soft costs like “reputation damage”. Not that there aren’t any losses due to reputation damage, but I’ve never seen any sort of justified model that accurately measures those costs over time. Take TJX for example – they grew sales after their breach. So here’s a modest proposal for how we could break out breach costs in a more consistent manner: Per Incident (Hard Costs): Incident investigation Incident remediation/recovery PR/media relations costs Optional: Legal fees Optional: Compliance violation penalties Optional: Legal settlements Per Record (Hard Costs): Notification costs (list creation, printing, postal fees). Optional: Customer response costs (help desk per-call costs). Optional: Customer protection costs (fraud alerts, credit monitoring). Per Incident (Soft Costs… e.g., not always directly attributable to the incident): Trending is key here – especially trends that predate the incident. Customer Churn (% increase over trailing 6 month rate): 1 week, 1 month, 6 months, 12 months, n months. Stock Hit (not sure of best metric here, maybe earnings per share): 1 week, 1 month, 6 months, 12 months, n months. Revenue Impact (compared to trailing 12 months): 1 week, 1 month, 6 months, 12 months, n months. I tried to break them out into hard and soft costs (hard being directly tied to the incident, soft being polluted by other factors). Also, I recognize that not every organization can measure every category for every incident. Not that I expect everyone to magically adopt this for standard reporting, but until we transition to a mechanism like this we don’t have any chance of really understanding breach costs. Share: