Research

Rich forwarded me this article on Boing Boing regarding “Kindle Books having download caps” on content. That just shattered my enthusiasm. A kind word of caution to Amazon: If you allow embedded Digital Rights Management content into Kindle media, your product will die. You are selling to early technology adopters, and history has confirmed they don’t tolerate DRM. It’s an anti-buyer technology, and the implementation requires (wrong) assumptions be made as to how a user want to use the device. History has also demonstrated that if you do push DRM with the content, the scheme will be broken, and people will do it just because they can. If you are worried about getting content, and feel you need DRM to appease content owners of major publishing houses, don’t. This is a very cool device, and content will come from thousands of sources, and people will find ways to use it you never thought possible. Share:

I’ve spent way too much time surfing the Internet over the last few evenings. I have read just about everything I can on AT&T pricing, new iPhone features, 3.0 software updates, SIM cards, jailbreaking, smart phone reliability & customer satisfaction surveys, SIM card compatibility, different cellular technologies, cellular service provider customer satisfaction in different regions of the country, Skype on the iPod, and just about every other thing I could find. I have spent more time online researching calling options in the last week than I have spent using my cell phone in the last 6 months. I don’t even own one of the damned things, so yeah, I am a little obsessive when it comes to research. All this was motivated by the question of whether or not I wanted to get up early this morning and join Rich in line at the Apple store to get the new iPhone 3G S. I am sure that is where he is right now. If I am going to make the switch, now would be a good time. Plus, a really well-written article on Ars Technica summed up the differences between the major smartphones and clarified why I want an iPhone. But in all the material I read, a couple things really stuck with me: $30.00 a month for a “data plan” in perpetuity. Forever. Competition be damned. No option for month-to-month with any smart phone, which used to be there, then was not. Which was supposedly changed again, but will it change back? The vast sea of negative comments on blogs that sing a unanimous chorus of “We don’t like AT&T service” was not offset by similar dissatisfaction with T-Mobile or Verizon. Consumer Reports and J.D. Power surveys are in line with this as well. The Coverage Viewer for my area shows I am awash with strongest signal strength possible. Looking at the map you get the impression I need to worry about radiation poisoning, the signal appears to be so strong. Yet, when I speak with neighbors about their iPhones’ coverage, they need to move to the south-west side of their homes in order to get ‘reasonable’ call reception or any data services. So what comes to mind with the 3G S release? The Neo quote from The Matrix: “Yeah. Well, that sounds like a pretty good deal. But I think I may have a better one. How about, I give you the finger” …. and wait for someone else to support the iPhone. Yep, that is the way I am voting on this one. While I feel slightly guilty at letting Rich fly solo, I probably would have walked out with an AirBook, which my wife would have promptly appropriated. I have waited two years thus far and, despite my fear of being labeled a gasp late majority adopter, I am going to have patience and wait. And the more I read, the more I think there are a few hundred thousand like me out there, and both Verizon and T-Mobile know it. I am going to bet that come next year the iPhone will be available through other carriers. I am also willing to bet that Apple is savvy enough to know, especially if their product marketing and sales teams are reading the same blogs I am, that there is a very large contingent of buyers waiting for better service. What they lose in what will (probably) be a sweet deal offered by AT&T for an exclusive, they more than make up for in the huge numbers of people who want the highest rated mobile computing device on the market with better coverage. Not that I am totally bashing AT&T: In their defense I know they are dumping a bunch of money into their network to not only improve coverage but also bring in new technologies and capabilities. And that they did alter the upgrade pricing in response to the iPhone upgrade pricing furor. Still, AT&T is negotiating with Apple to retain the exclusive deal because they know they cannot compete head to head in the marketplace and are worried about losing 2-3 million customers in 12 months. The exclusive deal is certainly not in the consumers’ best interest, and does not provide the competitive forces needed to alter AT&T’s service record or pricing structures. I am not entirely sure what prompted this, but I am willing to guess it has to do with the iPhone. Love Apple products, but I am sitting on the sidelines until I have a choice of providers. And one more time, in case you wanted to take the Project Quant survey and just have not had time: Stop what you are doing and hit the SurveyMonkey. You’ll be glad you did! (And thanks to Qualys, Tenable, and BigFix for promoting it). And now for the week in review: Webcasts, Podcasts, Outside Writing, and Conferences Rich was quoted in the Dark Reading report on Database Security: No Magic Bullet For Database, Server Security. Rich was an invited speaker at the Juniper Distinguished Lecturer series. Rich & Martin interview Jeff Moss on the Network Security Podcast #154. Favorite Securosis Posts Rich: Adrian’s Virtual Identities post. Our notions of identity and trust are being challenged like never before in our history. It’s a fascinating transition, and I can’t wait to see how we’ve adapted once the first generation growing up on the Internet takes charge. Adrian: The most recent installment in our Database Encryption Series, Part 4: Credentialed User Protection. Other Securosis Posts Virtual Identities Database Encryption, Part 3: Transparent Encryption Database Encryption, Part 4: Credentialed User Protection Project Quant Posts Project Quant: Prioritize and Schedule Phase Patch Management: Fixed (Non-Process) Costs Favorite Outside Posts Adrian: Errata’s Asynchronicity and Internet Scale post. Rich: Shrdlu breaks out some serious security humor on a more-regular basis again. But I feel a little left out. Top News and Posts 46 Security Fixes in iPhone 3.0 software. MasterCard requires on-site assessment for Level 2 merchants. T-Mobile Confirms data

In this post we will detail the other half of the decision tree for selecting a database encryption strategy: securing data from credentialed database users. Specifically, we are concerned with preventing misuse of data through individual or group accounts that provide access to data either directly or through another application. For the purpose of this discussion, we will be most interested in differentiating between accounts assigned users who use the data stored within the database, from accounts assigned to users who administer the database system itself. These are the two primary types of credentialed database users, and each needs to be treated differently because their access to database functions is radically different. As administrative accounts have far more capabilities and tools at their disposal, those threats are more varied and complex, making it much more difficult to insulate sensitive data. Also keep in mind that a ‘user’ in context of database accounts may be a single person, or it may be a group account associated with a number of users, or it may be an account utilized by a service or program. With User Encryption, we assign access rights to the data we want secured on a user by user basis, and provide decryption keys only to the specified users who own that information, typically through a secondary authentication and authorization process. We call this User Encryption because we are both protecting sensitive data associated with each user account, and also responding to threats by type of user. This differs from Transparent Encryption in two important ways. First, we are now protecting data accessed through the normal database communication protocols as opposed to methods that bypass the database engine. Second, we are no longer encrypting everything in the database; rather it’s quite the opposite – we want to encrypt as little as possible so unsensitive information remains available to the rest of the database community. Conceptually this is very similar to the functionality provided by database groups, roles, and user authorization features. In practice it provides an additional layer of security and authentication where, in the event of a mistake or account compromise, exposed data remains encrypted and unreadable. As you can probably tell, since most regular users can be restricted using access controls, encryption at this level is mostly used to restrict administrative users. They say if all you have is a hammer, everything begins to look like a nail. That statement is relevant to this discussion of database encryption because the database vendors begin the conversation with their capabilities for column, table, row, and even cell level encryption. But these are simply tools. In fact, for what we want to accomplish, they may be the wrong tools. We need to fully understand the threat first, in this case credentialed users, and build our tool set and deployment model based upon that and not the other way around. We will discuss these encryption options in our next post on Implementation and Deployment, but need to fully understand the threat to be mitigated before selecting a technology. Interestingly enough, in the case of credentialed user threat analysis, we are proceeding from the assumption that something will go wrong, and someone will attempt to leverage credentials in such a way that they gain access to sensitive information within the database. In Part 2 of this series, we posed the questions “What do you want to protect?” and “What threat do you want to protect the data from?” Here, we add one more question: “Who do you want to protect the data from?” General users of the data or administrators of the system? Let’s look at these two user groups in detail: Users: This is the general class of users who call upon the database to store, retrieve, report, and analyze data. They may do this directly through queries, but far more likely they connect to the database through another application. There are several common threats companies look to address for this class of user: providing protection against inadvertent disclosure from sloppy privilege management, inherited trust relationships, meeting a basic compliance requirement for encrypting sensitive data, or even providing finer-grained access control than is otherwise available through the application or database engine. Applications commonly use service accounts to connect to the database; those accounts are shared by multiple users, so the permissions may not be sufficiently granular to protect sensitive data. Users do not have the same privileges and access to the underlying infrastructure that administrators do, so the threat is exploitation of laxity in access controls. If protecting against this is our goal, we need to identify the sensitive information, determine who may use it, and encrypt it so that only the appropriate users have access. In these cases deployment options are flexible, as you can choose key management that is internal or external to the database, leverage the internal database encryption engine, and gain some latitude as to how much of the encryption and authentication is performed outside the database. Keep in mind that access controls are highly effective with much less performance impact, and they should be your first choice. Only encrypt when encryption really buys you additional security. Administrators: The most common concern we hear companies discuss is their desire to mitigate damage in the event that a database administrator (DBA) account is compromised or misused by an employee. This is the single most difficult database security challenge to solve. The DBA role has rights to perform just about every function in the database, but no legitimate need to examine or use most of the data stored there. For example, the DBA has no need to examine Social Security Numbers, credit card data, or any customer data to maintain the database itself. This threat model dictates many of the deployment options. When the requirement is to protect the data from highly privileged administrators, enforcing separation of duties and providing a last line of defense for breached DBA accounts, then at the very least external key management is required.

I am starting to hear stories from friends in the Phoenix area more and more about identity theft and account hijacking. Two weeks ago we got a phone call from a friend in the wee hours of the morning. She called to ask if we knew if a mutual friend, we’ll call her ‘Stacy’ for the purpose of this post, was in England. Our friend had received an email from Stacy stating she was in trouble and asking for money. We know Stacy pretty well and we assured out friend that she was not in England and was certainly not requesting $2000.00 be wired to her. Seems that everyone Stacy knew received a similar email claiming distress and requesting significant sums of money. Later in the afternoon we called Stacy and verified that she had in fact not been to England and was not in distress. But she had found that her Yahoo! account had been hijacked and she was getting calls from friends and family all morning who had received the same request. She admittedly had a very weak password, not unlike most of the people we know, and have never even thought someone would be interested in gaining access to the account. We spoke with Stacy again today, and jokingly asked her how much money she has made. She did not find this very funny because, after a dozen or so hours on the phone with the overseas ‘technical’ support , she still has not been able to restore her account nor stop the emails. It seems that the first thing the hijackers did was change the account verification questions as well as the password, both locking Stacy out of the account and removing any way for her to restore it. The funny part of this is the phone calls Stacy has had with the support team, which go pretty much like this: Stacy: “Hi, my email account has been taken over and they are sending out emails under my name requesting money.” Support: “OK, just go in and reset your password. I will email you a change password request.” Stacy: “I can’t do that. They changed the password so I cannot get email from this account. I am locked out.” Support: “OK Stacy, we will just need to ask you a few questions to restore your account … Can you tell us where you went on your honeymoon?” Stacy: “Yes, I honeymooned in Phoenix.” Support: “I am sorry, that is not the answer we have.” Stacy: “Of course not. They changed the information. That is why I am calling you.” Support: “Would you like another guess?” Stacy: “What?” Support: “I asked would you like another guess on where you spent your honeymoon?” Stacy: “I don’t need to guess, I was there. I honeymooned in Phoenix. Whatever answer you have is wrong because ….” Support: “I am sorry, that is not correct.” And so it goes. Like a bad game of “Who’s on First?”. How to prove you are really you, in a virtual environment, is a really hard security problem to solve. More often than not companies want to deal with our virtual images and identities rather than our real selves, and automate as much as they can to cut costs and raise profits. If you need something out of the ordinary fixed, it is often far easier to simply abandon the troubled account and start over again. At least you can do that with a Yahoo! email account. You bank account is another matter entirely. But we can do a lot better than a single (weak) password being the keys to the kingdom. This is a subject I would not normally even blog about except a) I found the dialog funny and b) it is becoming so common I think think we periodically need a reminder that if you are using a weak password on any account you care about, change it now! If you have two-factor authentication at your disposal, use it! Share:

In our previous post in this Database Encryption series (Introduction, Part 2) we provided a decision tree for selecting a database encryption strategy. Our goal in this process is to map the encryption selection process to the security threats to protect against. Yes, that sounds simple enough, but it is tough to wade through vendor claims, especially when everyone from network storage to database vendors claims to provide the same value. We need to understand how to deal with the threats conceptually before we jump into the more complex technical and operational issues that can confuse your choices. In this post we are going to dig into the first branch of the tree, Non-credentialed threats – protecting against attacks from the outside, rather than from authenticated database users. We call this “Transparent/External Encryption”, since we don’t have to muck with database user accounts, and the encryption can sometimes occur outside the datbase. Transparent Encryption won’t protect sensitive content in the database if someone has access to it thought legitimate credentials, but it will protect the information on storage and in archives, and provides a significant advantage as it is deployed independent of your business applications. If you need to protect things like credit card numbers where you need to restrict even an administrator’s ability to see them, this option isn’t for you. If you are only worried about lost media, stolen files, a compromised host platform, or insecure storage, then Transparent Encryption is a good option. By not having to muck around with the internal database structures and application logic, it often provides huge savings in time and investment over more involved techniques. We have chosen the term Transparent Encryption, as many of the database vendors have, to describe the capability to encrypt data stored in the database without modification to the applications using that database. We’ve also added “External” to distinguish from external encryption at the file or media level. If you have a database then you already have access controls that protect that data from unwanted viewing through database communications. The database itself screens queries or applications to make sure that only appropriate users or groups are permitted to examine and use data. The threat we want to address here is protecting data from physical loss or theft (including some forms of virtual theft) through means that are outside the scope of access controls. Keep in mind that even though the data is “in” a database, that database maintains permanent records on disk drives, with data being archived to many different types of low cost, long term storage. There are many ways for data to be accessed without credentials being supplied at all. These are cases where the database engine is by-passed altogether – for example, examination of data on backup tapes, disks, offline redo log files, transaction logs, or any other place data resides on storage media. Transparent/External Encryption for protecting database data uses the following techniques & technologies: Native Database Object (Transparent) Encryption: Database management systems, such as Oracle, Microsoft SQL Server, and IBM DB2, include capabilities to encrypt either internal database objects (tables and other structures) or the data stores (files). These encryption operations are managed from within the database, using native encryption functions built into the database, with keys being stored internally by default. This is good overall option in many scenarios as long as performance meets requirements. Depending on the platform, you may be able to offload key management to an external key management solution. The disadvantage is that it is specific to each database platform, and isn’t always available. External File/Folder Encryption: The database files are encrypted using an external (third party) file/folder encryption tool. Assuming the encryption is configured properly, this protects the database files from unauthorized access on the server and those files are typically still protected as they are backed up, copied, or moved. Keys should be stored off the server and no access provided to local accounts, which protect against the server becoming compromised by an external attacker. Some file encryption tools, such as Vormetric and BitArmor, can also restrict access to the protected files based on application. Thus only the database processes can access the file, and even if an attacker compromises the database’s user account, they will only be able to access the decrypted data through the database itself. File/folder encryption of the database files is a good option as long as performance is acceptable and keys can be managed externally. Any file/folder encryption tool supports this option (including Microsoft EFS), but performance needs to be tested since there is wide variation among the different tools. Remember that any replication or distribution of data handled from within the database won’t be protected unless you also encrypt those destinations. Media encryption: This includes full drive encryption or SAN encryption; the entire storage media is encrypted, and thus the database files are protected. Depending on the method used and the specifics of your environment, this may or may not provide protection for the data as it moves to other data stores, including archival (tape) storage. For example, depending on your backup agent, you may be backing up the unencrypted files or the encrypted storage blocks. This is best suited for high performance databases where the primary concern is physical loss of the media (e.g., a database on a managed SAN where the service provider handles failed drives potentially containing sensitive data). Any media encryption product supports this option. Which option to choose depends on your performance requirements, threat model, exiting architecture, and security requirements. Unless you have a high-performance system that exceeds the capabilities of file/folder encryption, we recommend you look there first. If you are managing heterogeneous databases, you will likely look at a third party product over native encryption. In both cases, it’s very important to use external key management and not allow access by any local accounts. We will outline selection criteria and use cases to support the decision process in a future post. You

In the selection process for database encryption solutions, too often the discussion devolves straight into the encryption technologies: the algorithms, computational complexity, key lengths, merits of public vs. private key cryptography, key management, and the like. In the big picture, none of these topics matter. While these nuances may be worth considering, that conversation sidesteps the primary business driver of the entire effort: what threat do you want to protect the data from? In this second post in our series on database encryption, we’ll provide a simple decision tree to guide you in selecting the right database encryption option based on the threat you’re trying to protect against. Once we’ve identified the business problem, we will then map that to the underlying technologies to achieve that goal. We think it’s safe to say that if you are looking at database encryption as an option, you have already come to the decision that you need to protect your data in some way. Since there’s always some expense and/or potential performance impact on the database, there must be some driving force to even consider encryption. We will also make the assumption that, at the very least, protecting data at rest is a concern. Let’s start the process by asking the following questions: What do you want to protect? The entire contents of the database, a specific table, or a data field? What do you want to protect the data from? Accidental disclosure? Data theft? Once you understand these requirements, we can boil the decision process into the following diagram: Whether your primary driver is security or compliance, the breakdown will be the same. If you need to provide separation of duties for Sarbanes-Oxley, or protect against account hijacking, or keep credit card data from being viewed for PCI compliance, you are worried about credentialed users. In this case you need a more granular approach to encryption and possibly external key management. In our model, we call this user encryption. If you are worried about missing tapes, physical server theft, copying/theft of the database files via storage compromise, or un-scrubbed hard drives being sold on eBay, the threat is outside of the bounds of access control. In these cases use of transparent/external encryption through native database methods, OS support, file/folder encryption, or disk drive encryption is appropriate. Once you have decided which method is appropriate, we need to examine the basic technology variables that affect your database system and operations. Which you select corresponds to how much of an impact it will have on applications, database performance, and so on. With any form of database encryption there are many technology variables to consider for your deployment, but for the purpose of selecting which strategy is right for you, there are only three to worry about. These three effect the performance and type of threats you can address. In each case we will want to investigate if these options are performed internally by the database, or externally. They are: Where does the encryption engine reside? [inside/outside] Where is the key management performed? [inside/outside] Who/what performs the encryption operations? [inside/outside] In a nutshell, the more secure you want to be and the more you need separation of duties, the more you will need granular enforcement and changes to your applications. Each option that is moved outside the database means you get more complexity and less application transparency. We hate to phrase it like this because it somehow implies that what the database provides is less secure when that is absolutely not the case. But it does mean that the more we manage inside the database, the greater the vulnerability in the event of a database or DBA account compromise. It’s called “putting all your eggs in one basket”. Throughout the remainder of the week we will discuss the major branches of this tree, and how they map to threats. We will follow that up with a set of use case discussions to contrast the models and set realistic expectations on security this will and will not provide, as well as some comments on the operational impact of using these technologies. By the end you’ll be able to walk through our decision tree and pick the best encryption option based on what threat you’re trying to manage, and operational criteria ranging from what database platform you’re on to management requirements. Share:

I was drafting a post last week on credit card security when I read Rich’s piece on How Market Forces Can Fix PCI. Rather than looking at improving PCI-DSS from a specification-centric perspective, he presented some ideas on improving its effectiveness through incentivizing auditors differently. A few of the points he raised clarified for me why looking at market drivers such as this are the only way we are going to understand the coming security changes to this industry. It’s a good post and highly relevant given the continuing rises in notable breaches and PCI compliance costs for merchants. But more than anything else, for me the post solidified why I think we are having the wrong discussion about the advancement of payment security. We are riding a 20th century credit card processing system that was great at the dawn of the POS terminal, but is simply broken from a security perspective for ‘card not present’ and Internet electronic commerce situations. Adrian Phillips of Visa was recently quoted as saying “… PCI-DSS has proven to be a highly effective foundation of minimum security standards when properly implemented across all systems handling cardholder data.” That phrase is laced with caveats, and it should be, because if you follow PCI-DSS closely, you hit the minimum set of requirements for basic security with significant investment. It’s not that I am against PCI-DSS per se, it’s just that we should not need PCI-DSS to begin with. We have gotten so wrapped up in the discussion on securing this credit card data and the payment system that we have somewhat forgotten that the merchant does not need this information to conduct commerce. We are attempting to secure credit card related information at a merchant site when it is unnecessary to keep it there. The payment process for merchandise should be considered two separate relationships: One between the buyer and the issuing bank, and the other between the issuing bank and the merchant. Somewhere along the way the lines were blurred and the merchant was provided with the customer’s financial information. Now the merchant is also required to keep this data around for dispute resolution, spreading the risk and cost of securing customer financial information. If I were looking for ways to make my business more efficient, I would be looking to get rid of this effort, responsibility, and expense ASAP! Merchants must investment massively to prop up the security on a flawed system. If the pace of fraud and breaches continue, sheer economic force will push merchants for an alternative rather than suffer along with increasing expenses and risks. As Brian Krebs recently reported, there has been a 95% increase in the number of credit and debit card fraud cases, with no specific indicator showing a slowdown. My point with this entire rant? I think we are starting to see the change happening now. Rich’s argument that market forces could improve PCI audits is entirely valid, and we could see slightly improved site security. But if market forces are going to materially alter the security situation as a whole, it will be in the slow erosion of vendors participating in the system we have today, in favor of something more efficient and cost effective. First with Internet commerce, and eventually with POS. Securing credit card data is an expensive distraction for merchants, which directly reduces profits. While many large companies offset this expense with revenue from data mining, the credit card number no longer needs to be present to successfully analyze transaction data. If I was running a commerce web site site I would certainly be looking to external payment processing service like PayPal to offload the liability and need to be party to the credit card data. And as PayPal’s fee structure is on par with more traditional credit card payment services, you get the same service with reduced liability. Looking at the number of small and mid-sized merchants I see using PayPal, I think the trend has already begun and will continue to pick up speed. I am also seeing new payment processing firms spring up with payment models more agile and appropriate to electronic commerce. I had an email exchange with the CTO of a security vendor on this subject the other day, and the question was raised “Will there be EMV-like smart cards in our future? I doubt it. That type of security helps half of the equation: authenticating the buyer, and given current implementations, only at POS terminals. It does not stop the data breaches or resultant fraud. EMV was a very good proposal that never took off, and while it could be helpful with future efforts, a more likely authentication mechanism will be something like Verisign authorization tokens. This form of authentication (user name/password plus One Time Password) may not be perfect, but far in excess of what we have for credit card processing today, and requires very little modification for Internet transactions. If market forces are going to drive payment processing security forward, I think this is a more plausible scenario. As always, current stakeholders will strive to maintain the status quo, but cheaper and better eventually wins out. Share:

Like many potential iPhone buyers, I have been checking the news releases from the Apple WWDC every hour or so. Faster speed, better camera, better OS, new apps. What’s not to like? From a security standpoint, the two features that were intriguing for me and (probably) many IT organizations are the data encryption and automatic remote data wipe options. From MacWorld: For IT, Apple has added on-device encryption for data (backups are encrypted as well), plus a remote wipe-and-kill feature for Exchange 2007 users. Non-Exchange users can get remote wpe-and-kill if they subcribe to Apple’s consumer-oriented MobileMe service. In either case, the wiped information and settings can be restored if you find the missing iPhone. Much in line with what I was thinking in the Friday Post, it appears that Apple developers are way ahead of me. This clears a couple major security hurdles for corporate adoption of the iPhone, and helps the iPhone to continue its viral penetration of corporate IT environments. Very smart moves on their part to fill these gaps. The “Find my iPhone” feature is a neat bit of gimmickry, and helpful for distinguishing whether your iPhone went missing or was stolen. I have trouble believing it would be very effective for recovery, but it is enough information to decide whether or not to remotely wipe the device. And with the ability to recover wiped data through MobileMe, there is little penalty for being safe. Then, leave it to AT&T to kill my happy iPhone buzz. Tethering? Nope. Any product vendor will tell you that that if a customer asks you when they get some cool new feature, you talk about what a wonderful advancement it will be and then set realistic expectations about when it will be available. Your response is not “Well, that will cost you more”. No wonder AT&T was booed on stage. It looks like by the time tethering is available, AT&T will no longer have its US exclusive arrangement with Apple, and no one will care that they don’t seem to care about customers. Or timely feature enhancements. Or that they are denying loyal Apple/AT&T customers a discount to buy a new phone and give the old phone to someone else who will need to use AT&T. You see the logic in that, right? Share:

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