Research

Ran across this article on CNN last Friday about how Facebook was going to launch a micro-payment service. Facebook wants to introduce its own virtual currency system that involves credits, coupons, and other types of widgets that can be redeemed for goods or cash. As recently as last fall, Facebook’s plans – reportedly called “Facebook Wallet” – were something much more like a straight-up, PayPal-like transaction platform. “We think enabling developers to accept these credits as a form of payment has the potential to create exciting new use cases for users and developers,” spokesman David Swain said in an e-mail. “We do not have details to share at the moment because this will be a very small alpha, only a handful of developers, but will likely share more as we evaluate the results of the test.” While it is up in the air if this is a full blown payment engine or just a virtual currency, it really does not matter. If Facebook offers the virtual goods and services, 3rd parties with quickly fill in the vacuum and provide conversion to other items of value as we saw happen in the gaming community. The concept of micro-payments has been around for a long time: we are talking a decade before payment providers like TextPayMe, PayMate or any of the other current payment providers started to morph the concepts of ‘micro’ payments, ‘XMS’ and ‘mobile’ payments into one. How many of you remember CyberCash? Or Transactor Networks? No? Then you probably don’t remember the Oracle Payment Server, Sun’s Java Wallet, Trintec, Verifone, or Paymantec – they all expressed interest in this type of payment strategy as well. And every one of them had to take into consideration automated fraud, money laundering, and theft. But many of these started as secure payment engines to be applied to other applications, and their relative degree of security was never fully tested. There are plenty of start-ups that have attempted to launch virtual currencies that would be interoperable across participating developers’ and companies’ games and other applications. None of them have become legitimate Web sensations, perhaps because of the inherent security concerns in online payments. Facebook already has millions of users’ credit card numbers on file from transactions through the Gifts app–its “credits” are in the lead before they even launch in full. Very true, with a big difference being they were payment engines looking for the ‘killer app’, not the killer app looking for a way to create virtual currency. PayPal is one of the few success stories, succeeding largely after the eBay merger, with the remaining examples used largely to purchase pornography. But they are also far more simplistic in their value propositions, and do not have some of the complexity surrounding virtual currency, multi-payment objects, and complex pricing models. It is very appealing for Internet commerce sites that provide low cost services and cash conversions, and it could really help Facebook monetize the millions of users and developers who participate. Micro-payments and virtual currencies are a great way to generate interest in a web site and create user affinity in addition to providing a mechanism for participants to get paid for their contributions to a community. But like any electronic payment system, if a security flaw is found, odds are that an exploit can be automated. While they may only be stealing pennies (or digital coupons) at a time, they can repeat the attack against thousands or, in the case of Facebook, 200,000,000 users, and wipe out an entire economy in a matter of hours. What better way to motivate hackers than to help them monetize their efforts as well? This is after all a platform that is ripe with scams, phishing, worms, and hacks. I kind of hope they roll this service out because this is going to be a lot of fun to watch! Share:

If you have ever listened to Rich or myself present on data centric security or endpoint encryption, we typically end by saying “Encrypt your freakin’ laptops.” It works. The performance is not terrible and it’s pretty much “set and forget”. We should also throw in “Encrypt your freakin’ USB keys” as well. The devices are lost on a regular basis and still very few have encrypted data on them. I confess that I am fairly lazy and have not been doing this, but started to look into encryption when I realized that I had brought a stick with me to Boston that had a bunch of sensitive stuff I was moving between computers and forgot to delete … oops. I am not different than anyone else in that I am not really interested in taking on more work if I can avoid it, but as I am moving documents I do not want public, I looked into solving this security gap. While at RSA I dropped by the IronKey booth; in nutshell, they sell USB sticks with hardware encryption. After a product demo I was provided a 1gb version to sample, which I finally unpacked this morning and put to use. This is a dead simple way to have USB files encrypted without much thought, so I am pretty happy moving the stuff I travel with onto this device. A few years back at the IT Security Entrepreneurs’ Forum at Stanford, I ran into Dave Jevans. He had just started IronKey and was there trying to raise capital. At the time this seemed a tremendous idea: USB keys were ubiquitous and were quickly supplanting writable CDs & DVDs as the portable media of choice. Everyone I knew was carrying a USB stick on their keychain or in their backpack. And subsequently they were lost and stolen at an alarming rate along with all the data they contained. It had been three years or so since I had spoken to anyone at the company, so I wanted to catch up on new product developments. I am not going to provide a meaningful analysis of the hardware security implementation as this is beyond my skill set, but there were a couple of advancements in the product for browser safety and data usage policy enforcement that I was unaware of, so I wanted to share some comments. The key has hardware encryption, so all files are stored encrypted. It provides an authentication interface and credentials need to be established before the device is usable. IronKey has added anti-malware to detect malicious content, but given that more dedicated appliances still fail in this area, the capability is not going to be cutting edge. The advancements I was not aware of were strong password enforcement, remote administration, and the ability to destroy the device in the event that certain access policies are violated. This prevents an attacker from trying indefinitely to gain access, and allows for policies to be adjusted per company, per users. The first idea that hit me is that this is a natural to leverage the encryption capabilities of the memory stick with DLP in a corporate environment. Use DLP to detect the endpoint device and allow data to be copied to the USB device when the device is trusted. This is very much in line with a data centric security model – where you define the actions that are allowed on the data, and where the data is allowed to go, and do not allow it to be in the clear anywhere else. I am not aware of anyone doing this today, but it would make sense from a corporate IT standpoint and would make an effective pairing. The second concept pushed during the demo was the idea of putting a stripped down and trustworthy version of Firefox onto the IronKey. They are touting the ability to have a mini-mobile safe harbor for your data and browser. Philosophically speaking, this sounds like a good idea. Say I am using someone else’s computer: invariably they have IE, which I do not want to use, and the basic security of the computer is questionable as well. So I could plug in the memory stick and run a trusted copy of Firefox from wherever. Neat idea. But from my perspective, this does not seem like a valid use case. Even today I am going to have my laptop, and I just want an Internet connection. With EVDO, MiFi and the surge of mobile computing, do I really need a memory stick to do this for me? If I have a browser on my iPhone or Blackberry, what’s the point? Endpoint devices come and go with the same regularity as women’s fashions, and I wonder what the real market opportunity for this type of technology is in the long run. While it appears to be good security, the medium itself may be irrelevant. One thought is to embed this technology into mobile computing devices so that the information is protected if lost or stolen. If they could do that, it would be a big advancement over the security offered today. With the ability to provide user authentication, and destroy the data in the event that the unit is lost or the security policies are violated, I would have a much more secure mobile device. Anyway, very cool product, but not sure where the company goes from here. Oh, I also wanted to make one additional reminder: Project Quant Survey is up. Yeah, I know it’s SurveyMonkey, and yeah, I know everyone bombards you with surveys, but this is pretty short and the results will be open to everyone. And now for the week in review: Webcasts, Podcasts, Outside Writing, and Conferences Rich’s Macworld article on Apple, Mac security and responsibility. Rich with Dennis Fisher on the ThreatPost podcast Rich with Bill Brenner of CSO on DLP Rich’s TidBITS article on 5 Ways Apple Can Improve Mac and iPhone Security Rich and Martin on The Network

Updated June 4th to reflect terminology change. This is the Re-Introduction to our Database Encryption series. Why are we re-introducing this series? I’m glad you asked. The more we worked on the separation of duties and key management sections, the more dissatisfied we became. Rich and I got some really good feedback from vendors and end users, and we felt we were missing the mark with this series. And not just because the stuff I drafted when I was sick completely lacked clarity of thought, but there are three specific reasons we were unhappy. The advice we were giving was not particularly pragmatic, the terminology we thought worked didn’t, and we were doing a poor job of aligning end-user goals with available options. So yeah, this is an apology to our audience as the series was not up to our expectations and we failed to achieve some of our own Totally Transparent Research concepts. But we’re ‘fessing up to the problem and starting from scratch. So we want to fix these things in two ways. First we want to change some of the terminology we have been using to describe database encryption. Using ‘media encryption’ and ‘separation of duties’ is confusing the issues, and we want to differentiate between the threat we are trying to protect against vs. what is being encrypted. And as we are talking to IT, developers, DBAs, and other audiences, we wanted to reduce confusion as much as possible. Second, we will create a simple guide for people to select a database encryption strategy that addresses their goals. Basically we are going to outline a decision tree of user requirements and map those to the available database encryption choices. Rich and I think that will aid end users to both clarify their goals and determine the correct implementation strategy. In our original introduction we provided a clear idea of where we wanted to go with this series, but we did adopt our own terminology in order to better encapsulate the database encryption options vendors provide. We chose “Encryption for Separation of Duties” and “Encryption for Media Protection”. This is a bit of an oversimplification, and mapped to the threat rather than to the feature. Plus, if you asked your RDBMS vendor for ‘media encryption’, they would not know what they heck you were talking about. We are going to change the terminology back to the following: Database Transparent/External Encryption: Encryption of the entire database. This is provided by native encryption functions within the database. The goal is to prevent exposure of information due to loss of the physical media. This can also be done through drive or OS/file system encryption, although they lack some of the protections of native database encryption. The encryption is invisible to the application and does not require alterations to the code or schema. Data User Encryption: Encrypting specific columns, tables, or even data elements in the database. The classic example is credit card numbers. The goal is to provide protection against inadvertent disclosure, or to enforce separation of duties. How this is accomplished will depend upon how key management is utilized and (internal/external) encryption services, and will affect the way the application uses the database, but provides more granular access control. While we’re confident we’ve described the two options accurately, we’re not convinced the specific terms “database encryption” and “data encryption” are necessarily the best, so please suggest any better options. Blanket encryption of all database content for media protection is much easier than encrypting specific columns & tables for separation of duties, but it doesn’t offer the same security benefits. Knowing which to choose will depend upon three things: What do you want to protect? What do you want to protect it from? What application changes and management tasks will you tolerate? Thus, the first thing we need to decide when looking at database encryption is what are we trying to protect and why. If we’re just going after the ‘PCI checkbox’ or are worried about losing data from swapping out hard drives, someone stealing the files off the server, or misplacing backup tapes, then database encryption (for media protection) is our answer. If the goal is to protect data in the event of compromised accounts, rogue DBAs, or inadvertent disclosure; then things get a lot more complicated. We will go into the details of ‘why’ and ‘how’ in a future post, as well as the issues of application alterations, after we have introduced the decision tree overview. If you have any comments, good, bad, or indifferent, please share. As always, we want the discussion to be as open as possible. Share:

You ever watch a movie or TV show where you know you know the ending, but you keep viewing in suspense to find out how it actually happens? That’s how I felt when I read this: Break Into My Email Account and Win $10,000 StrongWebmail.com is offering $10,000 to the first person that breaks into our CEO’s email account…and to make things easier, we’re giving you his username and password. No surprise, it only took a few days for this story to break: On Thursday, a group of security researchers claimed to have won the contest, which challenged hackers to break into the Web mail account of StrongWebmail CEO Darren Berkovitz and report back details from his June 26 calendar entry. The hackers, led by Secure Science Chief Scientist Lance James and security researchers Aviv Raff and Mike Bailey, provided details from Berkovitz’s calendar to IDG News Service. In an interview, Berkovitz confirmed those details were from his account. Reading deeper, they say it was a cross site scripting attack. However, Berkovitz could not confirm that the hackers had actually won the prize. He said he would need to check to confirm that the hackers had abided by the contest rules, adding, “if someone did it, we’ll kind of put our heads down,” he said. Silly rules- this is good enough for me. (Thanks to @jeremiahg for the pointer). Share:

Boaz Gelbord wrote a thoughtful response (as did Mike Andrews) to my post earlier this week on the state of web application and data security. In it was one key tidbit on encryption: The truth is that you just don’t mitigate that much risk by encrypting files at rest in a reasonably secure environment. Of course if a random account or service is compromised on a server, having those database files encrypted would sure come in handy. But for your database or file folder encryption to actually save you from anything, some other control needs to fail. I wouldn’t say this is always true, but it’s generally true. In fact, this situation was the inspiration behind the Three Laws of Data Encryption I wrote a few years ago. The thing is, access controls work really freaking well, and the only reason to use encryption instead of them is if the data is moving, or you need to somehow restrict the data with greater granularity than is possible with access controls. For most systems, this is to protect data from administrators, since you can manage everyone else with access controls. Also keep in mind that many current data encryption systems tie directly to the user’s authentication, and thus are just as prone to compromised user accounts as are access controls. Again, not true in all cases, but true in many. The first step in encryption is to know what threat you are protecting against, and if other controls would be just as effective. Seriously, we toss encryption around as the answer all the time, without knowing what the question is. (My favorite question/answer? Me: Why are you encrypting. Them: To protect against hackers. Me: Um. Cool. You have a bathroom anywhere?) Share:

Are you tired of all those BS vendor surveys designed to sell products, and they don’t ever even show you the raw data? Yeah, us too. Today we’re taking the next big step for Project Quant by launching an open survey on patch management. Our goal here is to gain an understanding of what people are really doing with regards to patch management, to better align the metrics model with real practices. We’re doing something different with this survey. All the results will be made public. We don’t mean the summary results, but the raw data (minus any private or identifiable information that could reveal the source person or organization). Once we hit 100 responses we will release the data in spreadsheet formats. Then, either every week or for every 100 additional responses, we will release updated data. We don’t plan on closing this for quite some time, but as with most surveys we expect an initial rush of responses and want to get the data out there quickly. As with all our material, the results will be licensed under Creative Commons. We will, of course, provide our own analysis, but we think it’s important for everyone to be able to evaluate the results for themselves. All questions are optional, but the more you complete the more accurate the results will be. In two spots we ask if you are open for a direct interview, which we will start scheduling right away. Please spread the word far and wide, since the more responses we collect, the more useful the results. If you fill out the survey as a result of reading this post please use SECUROSISBLOG as the registration code (helps us figure out what channels are working best). If you came to this post via twitter, use TWITTER as the reg code. This won’t affect the results, but we think it might be interesting to track how people found the survey, and which social media channels are more effective. Thanks for participating, and click here to fill it out. (This is a SurveyMonkey survey, so we can’t disable the JavaScript like we do for everything here on the main site. Sorry). Share:

This is an article I’ve been thinking about for a long time. Sure, we security folks seem to love to bash Apple, but I thought it would be interesting to take a more constructive approach. From the TidBITS article: With the impending release of the next versions of both Mac OS X and the iPhone operating system, it seems a good time to evaluate how Apple could improve their security program. Rather than focusing on narrow issues of specific vulnerabilities or incidents, or offering mere criticism, I humbly present a few suggestions on how Apple can become a leader in consumer computing security over the long haul. The short version of the suggestions are: Appoint and empower a CSO Adopt a secure software development program Establish a security response team Manage vulnerabilities in included third party software Complete the implementation of anti-exploitation technologies Share:

OK, I have to call Bull$%} on this: Anti-piracy pup sniffs out 35,000 illegal DVDs. A piracy fighting dog. Really. From Yahoo! News: The black Labrador helped enforcement officials who carried out raids last week in southern Johor state which neighbours Singapore, the Motion Picture Association (MPA) said in a statement. Paddy was given to Malaysia by the MPA to help close down piracy syndicates who churn out vast quantities of illegal DVDs. The dog is specially trained to detect chemicals in the discs. So the dog can detect chemicals used in DVDs. Call me a cynic, but I suspect that ‘Paddy’ cannot tell the difference between Best Buy, an adult video store, and an underground DVD warehouse. So unless someone has figured out how to install laser diodes and detection software onto a Labrador, it’s not happening. Of course, when they do, the pirates will be forced to escalate the confrontation with the unstoppable “Fuzzy, bouncy, piracy tennis ball of mayhem”. Seriously, this is an illustration of the huge difference between marketing security and actual security. It looks to me like someone is trying to create the MPA version of Sexual Harassment Panda, and it’s just wrong! Share:

It’s no secret that I haven’t always been the biggest fan of PCI (the Payment Card Industry Data Security Standard). I believe that rather than blowing massive amounts of cash trying to lock down an inherently insecure system, we should look at building a more fundamentally secure way of performing payment transactions. Not that I think anything is ever perfectly secure, but there is a heck of a lot of room for progress, and our current focus has absolutely no chance of doing more than slightly staving off the inevitable. It’s like a turtle trying to outrun the truck that’s about to crush it- the turtle might buy itself an extra microsecond or two, but the outcome won’t change. That said, I’ve also (fairly recently, and due in no small part to debates with Martin McKeay come to believe that as flawed as PCI is, it’s also the single biggest driver of security improvements throughout the industry. It’s the primary force helping security pros gain access to executive management; even more so than any other regulation out there. And while I’d really like to see us focus more on a secure transaction ecosystem, until that wonderful day I recognize we need to live with what we have, and use it to the best of our ability. Rather than merely adding new controls to the PCI standard, I think the best way to do this is to fix some of the inherent problems with how the program is currently set up. If you’ve ever been involved with other types of auditing, PCI looks totally bass ackwards. The program itself isn’t designed to produce the most effective results. Here are a couple of changes that I think could make material improvements to PCI, possibly doubling the number of microseconds we have until we’re a steaming mass of roadkill: Eliminate conflicts of interest by forbidding assessors from offering security tools/services to their clients: This is one of the single biggest flaws in PCI- assessors may also offer security services to their clients. This is a massive conflict of interest that’s illegal in financial audits due to all the problems it creates. It will royally piss off a few of the companies involved, but this change has to happen. Decertify QSAs (assessors) that certify non-compliant companies: Although the PCI council has a few people on their probation list, despite failure after failure we haven’t seen anyone penalized. Without these penalties, and a few sacrificial lambs, QSAs are not accountable for their actions. Eliminate the practice of “shopping” for the cheapest/easiest QSA: Right now, if a company isn’t happy with their PCI assessment results, they can fire their QSA and go someplace else. Let’s steal a rule from the financial auditing playbook (not that that system is perfect) and force companies to disclose when they change assessors, and why. There are other actions we could take, such is publicly disclosing all certified companies on a quarterly basis or requiring unscheduled spot-checks, but I don’t think we necessarily need those if we introduce more accountability into the system, and reduce conflicts of interest. Another very interesting development comes via @treyford on twitter, pointing to a blog post by James DeLuccia and an article over at Wired. It seems that the auditor for CardSystems (you know, one of the first big breaches from back in 2005) is being sued for improperly certifying the company. If the courts step in and establish a negligence standard for security audits, the world might suddenly become mighty interesting. But as interesting (and hopefully motivating, at least to the auditors/assessors) as this is, I think we should focus on what we can do with PCI today to allow market forces to drive security and program improvements. Share:

Right when the Macalope was sending along his take on the recent ComputerWorld editorial calling for the FTC to investigate Apple, Macworld asked me to write a more somber take. Here’s an excerpt: On May 26, Macworld republished a controversial Computerworld article by Ira Winkler suggesting that Apple is “grossly negligent” when it comes to security, and should be investigated by the Federal Trade Commission for false advertising. The author was motivated to write this piece based on Apple’s recent failure to patch a known Java security flaw that was fixed on other platforms nearly six months ago. While the article raises some legitimate issues, it’s filled with hyperbole, inaccurate interpretations, and reaches the wrong conclusions. Here’s what you really need to know about the Java situation, Mac security in general, and the important lesson on how we control Apple’s approach to security. … The real failure of this, and many other, calls for Mac security is that they fail to accurately identify those who are really responsible for Apple’s current security situation. It isn’t security researchers, malicious attackers, or even Apple itself, but Apple’s customers. Apple is an incredibly successful company because it produces products that people purchase. We still buy MacBooks despite the lack of a matte screen, for example. And until we tell Apple that security will affect our buying decisions, there’s little motivation for the company to change direction. Think of it from Apple’s perspective—Macs may be inherently less secure, but they are safer than the competition in the real world, and users aren’t reducing what they spend on Apple because of security problems. There is reasonable coverage of Mac security issues in the mainstream press (Mr. Winkler’s claim to the contrary), but without demonstrable losses it has yet to affect consumer behavior. Don’t worry- I rip into Apple for their totally irresponsible handling of the Java flaw, but there really isn’t much motivation for Apple to make any major changes to how they handle things, as bad as they often are. Share: