Google's Achilles' heel

Sure, people trust Google to come out with cool technology. But do they trust Google with their data and their privacy? Many don’t. Worse, many fear what Google does or could do with the data it aggregates.

I’ll let Google itself tell the story. If you do a Google search on “Google” and “big brother” you’ll get a whopping 58.9 million hits. Doing the same for “Microsoft” and “big brother” yields only 7.1 million. Even more surprising, a search on “government” and “big brother” results in just 13.4 million hits. Using search results as a rough proxy: people are more than 4 times more concerned that Google, rather than the government, is amassing too much information about us.

I see a lot of parallels between Google today and Microsoft circa 2009. What security was to Microsoft (but to Microsoft’s credit, isn’t any longer), privacy is to Google: a looming threat of customer dissatisfaction that could result in a mass migration of users and their eyeballs away from Google’s applications and search engine. And the friction for such a diaspora from Google’s web-based services and add-on applications is far lower than from Microsoft’s Windows or Office.

Google’s reputation is suffering, and it’s brand value is eroding. In 2008, Google dropped off the top 20 list of the Ponemon Institute-TRUSTe survey of most trusted companies, after coming in at #11 in 2007. It remains off the top 20 list for 2009.

Hopefully, this is something Google will recognize as an issue and start to address before it gets worse.

Sure, people trust Google to come out with cool technology. But do they trust Google with their data and their privacy? Many don’t. Worse, many fear what Google does or could do with the data it aggregates.

I’ll let Google itself tell the story. If you do a Google search on “Google” and “big brother” you’ll get a whopping 58.9 million hits. Doing the same for “Microsoft” and “big brother” yields only 7.1 million. Even more surprising, a search on “government” and “big brother” results in just 13.4 million hits. Using search results as a rough proxy: people are more than 4 times more concerned that Google, rather than the government, is amassing too much information about us.

I see a lot of parallels between Google today and Microsoft circa 2009. What security was to Microsoft (but to Microsoft’s credit, isn’t any longer), privacy is to Google: a looming threat of customer dissatisfaction that could result in a mass migration of users and their eyeballs away from Google’s applications and search engine. And the friction for such a diaspora from Google’s web-based services and add-on applications is far lower than from Microsoft’s Windows or Office.

Google’s reputation is suffering, and it’s brand value is eroding. In 2008, Google dropped off the top 20 list of the Ponemon Institute-TRUSTe survey of most trusted companies, after coming in at #11 in 2007. It remains off the top 20 list for 2009.

Hopefully, this is something Google will recognize as an issue and start to address before it gets worse.

Chrome OS is coming, and it is impressive

Today, Google made its first public announcements about Chrome OS, a Linux-derived operating system that it positions as secure and easy to use. I listened in on the Web cast today, and had some initial impressions.

Overall, I am impressed. Google had the luxury to design an OS using a clean sheet of paper, and as a result produced an OS that has some very interesting security properties:

• Trusted boot. The kernel is verified using public keys stored in the firmware.
• OS integrity check. All disk blocks on the root partition are hashed and checked at boot, meaning that malware won't be able to take up residence in the file system.
• No user-installable user applications. Everything is a Web app.
• Application sandboxing. Every process runs in its own memory space. Processes are chrooted. Stack protection, as you might expect.
• OS segregation. The OS enforces separate disk partitions for system (root) and user data.
• User data protection. User data is stored locally on its own partition, and is encrypted.
• Silent and trusted OS updates. No user-serviceable parts inside.

If you remember my earlier blog post on Chrome OS, I predicted most of this stuff, although I got a few details here and there wrong. I did not predict that user data would be encrypted. But I was more right than wrong, so that is gratifying.

Outside of security, a few things surprised me, but make total sense in retrospect. For example, Google OS will only runs on certain hardware. Solid state disk drives will be required. This means Google does not need to do much hardware abstraction layer (HAL) type engineering. That is how they are getting (or claiming to get) 7 second boot times. Again, this is what you can do when you design from a clean sheet, and when you make conscious choices about what you will not do, such as support every SCSI card, video driver, and crazy hard disk made since the invention of fire.

There are a few things that I am still not totally clear about, such as the apparent ability to restore the OS to a known state using a flash drive.

Other than that, though, there is really not too much, from a security design perspective, that I could improve on. The devil is always in the details. But based on my first impressions, it should be a great netbook OS.

Cloud Security Front And Center

Cloud computing is the latest trend that has the industry abuzz. Everywhere you go, there are cloud services for every functionality imaginable. Many believe that cloud computing can deliver massive business and operational efficiencies. There is even a movement at the national level: Vivek Kundra, the country’s recently named federal CIO, is being tasked to push the adoption of cloud-based services across the federal IT landscape.

Cloud computing differs from traditional outsourcing because in the latter model, it is still very much standalone computing — either you take your server and put in someone else’s data center, or you have a MSP managing your devices. In many cases, you know exactly where your data/host is and what resources, if any, you share with others. Cloud computing decouples data from infrastructure and obscures low-level operational details, such as where your data is and how it’s replicated. Multitenancy, while it is rarely used in traditional IT outsourcing, is almost a given in cloud computing services. These differences give rise to a unique set of security and privacy issues that not only impact users’  risk management practices, but have also stimulated a fresh evaluation of legal issues in areas such as compliance, auditing, and eDiscovery.  

I’ve had many conversations recently with IT security and compliance professionals about cloud security, and the universal concern seems to be that there is a lack of visibility and standards across cloud providers. Users of cloud services are therefore left to fend for themselves, especially in terms of understanding and addressing security risks associated with outsourcing to the cloud.

Earlier this year, I published a Forrester report titled: “How Secure Is Your cloud? A Close Look At Cloud Computing Security Issues”. I received tremendous feedback after the publication. This quarter, I am embarking on a big research effort to evaluate security and privacy practices of some of the leading cloud providers, such as Salesforce.com, Amazon, Google, and Microsoft. We will be conducting the evaluation on three broad aspects:

Security and privacy:Concerns such as data protection, operational integrity, vulnerability management, business continuity (BC), disaster recovery (DR), and identity management (IAM) make up the list of security issues for cloud computing. Privacy is another key concern — data that the service collects about the user (e.g., event logs) gives the provider valuable marketing information, but can also lead to misuse and violation of privacy.
Compliance:Data privacy and business continuity are two big items for compliance. Specific issues such as geo-location of data centers, incident response procedures, eDiscovery support, and proper handling of logs and audit trails all come to focus here.
Legal and contractual issues: Legal issues are the least well-understood areas of cloud computing. Though I will not be giving out legal advice, I will be looking at what legal issues may arise in the context of cloud computing. For instance, liability and intellectual property are two examples of legal issues that often being discussed. Other contractual issues include end-of-service support — when the provider-customer relationship ends, customer data and applications should be packaged and delivered to the customer, and any remaining copies of customer data should be erased from the provider’s infrastructure, etc.

I’d like to know if anyone has any specific concerns to cloud security that may be outside of what’s mentioned above. If so, please leave a comment here. Also, I’ve so far identified vendors who are more in the platform-as-a-service and Software-as-a-Service (SaaS) areas, should I include infrastructure-as-a-service vendors like Rackspace? Let me know what you think.  If you would like a snapshot of the cloud security report, send me an email cwang@forrester.com.

This post also appeared on Chenxi Wang's blog at http://chenxiwang.wordpress.com/.

The Madoff Scandal Widens to Include IT

The SEC announced on Friday that it is charging two computer programmers for their alleged participation in the Ponzi scheme for which Bernard Madoff pleaded guilty and headed off to jail last March.

In its complaint, the SEC alleges that, “Madoff and his lieutenant Frank DiPascali, Jr., routinely asked (Jerome) O'Hara and (George) Perez for their help in creating records that, among other things, combined actual positions and activity from... market-making and proprietary trading businesses with the fictional balances maintained in investor accounts.”

The SEC further alleges that O’Hara and Perez tried to cover their tracks by deleting hundreds of files, withdrew hundreds of thousands of dollars from their investments through the company, told Madoff they wanted to stop helping him, and then accepted larger salaries and substantial bonuses for their promise to keep quiet.

It will be interesting to watch this case unfold. I was hoping it would get into issues of whether the IT professionals were considered just uninvolved support staff or key participants in the scheme. Considering the evidence SEC claims to have, I don’t think we’ll hear those arguments in this case, but keep an eye out for how the defense comes together. Fraud prevention is a growing area of concern for government, health care, insurance, financial services, and other industries... which means we could be seeing more cases questioning the responsibility of IT to identify and/or prevent such issues.

Posted by Chris McClean

 

The iPhone “Worm” Presents No Risk to Most Users

Much breathless prose has been written about the Ikee malware circulating amongst iPhone owners. Described as the first iPhone worm, Ikee does something fairly funny: it replaces the user’s lock screen with a picture of Rick Astley, of 1980s “Never Gonna Give You Up” fame. In other words, it RickRolls your phone. According to the author, the worm circulates by scanning the phone’s local IP address range for other iPhones running the SSH daemon, and if it finds any, attempts to log in using the default root password. It then copies a JPEG file of the sainted Mssr Astley to the location where the picture is stored.

Although Ikee is more of a crude hack than anything else, it presents no danger to most iPhone users. Only a small percentage of iPhone owners are at risk. To be at risk, the owner of the iPhone must have fulfilled three conditions. They must have:

1. Jailbroken their phones
2. Installed the SSH daemon (sshd)
3. Left their root password unchanged from the default (“alpine”)

An iPhone owner who does not know anything about jailbreaking, or does not recognize the words Blackra1n, Blacksn0w, or Redsn0w, has nothing to fear. No jailbreak means no SSH, and hence no way to be remotely exploited.

But owners who have jailbroken their iPhones have more to worry about. As one affected owner, (user jokiin) put it: “I think there's a lot of blind faith put into jailbreaking phones and the majority of users really have no idea what compromises may take place as a result.” The simplest preventative remedy is not to install SSH. If it is installed, you should shell into the phone and change the default root password to something unique.

Ironically, business users who travel internationally are more likely to be at risk. Incentives to jailbreak exist because Apple and AT&T will not unlock iPhones to allow the use of prepaid or other third-party SIMs while traveling. Even original iPhone users who have fulfilled their 2-year contract cannot unlock their phones. This is despite AT&T’s earlier promise that it would “gladly” unlock phones when the initial contract was completed.

Many of the editorial articles written in the wake of Ikee are well-meaning but draw the wrong conclusions. Yes, the iPhone is more like a little computer rather than a toaster. Yes, user education is important. Yes, “nothing is completely secure.” We knew all these things already. But no, this particular little demonstration project is not the harbinger of some massive flood of mobile malware for the iPhone. Mobile security software, conveniently dispensed by various security software vendors eying new markets, is not suddenly a must-have. And no, this is not further proof that Apple needs a Secure Development Lifecycle that exactly resembles Microsoft’s.

The only conclusions I would draw are these: if you choose to jailbreak, know what you are getting into. Read as much as you can about what the process does to your phone, and what precautions you should take if you install software (like sshd) that increases your attack surface. If you don’t understand what it all means, stop. And to Apple and AT&T, I'd say this: you gotta make it easier to use iPhones legally overseas with prepaid SIMs, like nearly every other GSM phone. Your current SIM-locking policy creates perverse incentives that put users at risk.

NAC Market Overview: Landscape Stabilizes And Musters More Features

I just wrapped up the NAC Market Overview and it’s now live. This is the first Forrester NAC market overview and builds on the work I did for the original NAC Wave last year. I must say that the market overview is far less strenuous and we know it delivers almost as much value. It’s fair to say that I enjoyed this research piece, but I still need to gear up for refreshing the Wave next year. Until then, we can share a lot of good stuff about this market overview and I welcome your thoughts on it.

Writing this market overview was a great learning experience. And it’s even better when you can have meaningful conversations around the research. For example, I saw that someone started a discussion about the NAC solutions on LinkedIn’s “Network Security - IPS and NAC” forum. And very timely that someone referenced this market overview in the discussion — good to see readers benefit from these reports.

Following the space for the past year and half, I’ve noticed that solutions are maturing rapidly. And credit infamously goes to customers complaining about NAC’s complexity and breadth which makes it difficult to scale to multiple scenarios. Hence, vendors have to mature their offerings to survive in this thorny market. There is good news in all this — vendors strive to bring better solutions that help organizations solve specific problems and scale to bigger ones. I’m a big fan of theoretical physics and one concept states that entropy (disorder) is good for the universe. Disorder is good for the NAC market to a certain point and it will be one of the forcing functions to flatten the market out at some point. Fortunately, we’re reaching the flat curve in this space. And the end result: Customers are able to select solutions that are mature and more stable than their predecessors.

I don’t plan to overload you with much detail about the report here, however here’s a list of key takeaways if nothing else:

• NAC landscape is stabilizing. I like to paint a rosy picture on this one, even though critics would be skeptical. We’ve seen many vendors exit this space in the past 2 years. And this will continue to some extent as vendors shift their strategy and form more partnerships. It’s a good thing for customers, who can now leverage more with less. The goal is to utilize their existing investments and deploy overlay solutions that work much better than their predecessors. And they provide more deployment options for customers in the form of hardware appliances, software management consoles, integrated IPS and vulnerability scanners, and much more. Bottom line: it’s much easier to take a NAC solution and deploy it in your environment today than even a year ago.
• Customers cherish better deployment architecture. Ok, so maybe I went a bit overboard here with cherish. But ask a customer about their NAC deployment and the underlying architectural blueprint and you will be looking at blank faces. Reason being, not many vendors actually help with a well constructed design and a phased deployment path. In fact, few vendors even provide a reference architecture. Fortunately enough, vendors have gotten better at this and now they provide customers with a phased roll out (one that goes from monitor, to deferred enforcement, to full enforcement) that spans anywhere from six to 12 months.
•  NAC Solutions finally have useful features. As I mentioned, NAC solutions are gaining breadth, which means integrating features with products across the board. NAC works with adjacent technologies like IPS, vulnerability scanners, asset discovery, IAM directories, and so on. In turn this provides better ROI. I’ll suggest taking a peek at Figure 3 of the report to get a full list of features.

So, this is it for now. Don’t forget to leave your thoughts about NAC in general or about the market overview. I’d love to hear your deployment experiences as well.

I’ll leave you with a quote from Albert Einstein, which applies fairly well to NAC:

“We can't solve problems by using the same kind of thinking we used when we created them.”

[Posted by Usman Sindhu]

MIT's attack on EC2 an academic exercise

Virtual infrastructure has become the backbone of cloud computing, particularly in the area of infrastructure-as-a-service. This is why the latest attack on EC2 demonstrated by MIT researchers garnered a fair amount of attention in the press.

This is an attack against virtual computing resources, not necessarily against EC2 per se. In fact, this attack can potentially work against any virtual infrastructure, private cloud included.

Does this mean that there is a security vulnerability within EC2? Yes.

Should you be concerned? Not really.

This is an example of a "side-channel" attack. For this attack to be feasible, certain conditions must be true a priori. These conditions include that the attacker has knowledge of when the victim virtual machines would be launched. Some of these conditions, though not entirely impossible, are on the impractical side. While the author concedes that it is possible that an espionage attack with high-valued stakes may very well undertake such a method, it is hardly a concern for run-of-the-mill computing tasks running in EC2.

A detailed description of the attack and possible countermeasures can be found on my personal blog. Check http://chenxiwang.wordpress.com/category/cloud-security/.

What this attack highlights is that the security of cloud computing has everything to do with security within the virtual infrastructure. What does this mean? Providers of IAAS must take extreme care when it comes to security and privacy of their operations, or risk facing far-reaching consequences.

Here at Forrester, I’m starting a study to investigate the security and privacy practices of leading cloud providers. I’ve identified Salesforce.com, Google, Microsoft, and Amazon as the four vendors that I would study initially. I have yet to make Amazon commit to an interview, but the former three have all expressed willingness to participate in this study. I will write more as the study gets underway. Until then stay tuned and let me know what you think … 

Your new client security analyst

After seven years, my colleague Natalie Lambert is leaving Forrester. In the year that I have been at Forrester, she has been a good team-mate, sounding board for ideas, gleeful mischief-maker, and collaborator on shared research topics. I will miss her insights and energy, and I wish her the best as she begins her next adventure.

Natalie covered quite a bit of ground: client security, client management, endpoint virtualization, Bring-Your-Own-PC programs, full disk encryption and several other topics. While it would be impossible to fill her shoes, I am strapping on my hip waders and immersing myself in several of her research topics.

Specifically: henceforth, I will cover all client security topics for Forrester. These include:

• data leak prevention (DLP) on the client
• full disk encryption
• client security (anti-malware and anti-virus)

I am pleased to cover client security topics again. I wrote extensively about client security for three-and-a-half years before coming to Forrester. Among other things, I correctly predicted that Windows Vista would have no effect on the Windows security aftermarket — six months before Vista launched. And in 2006 and 2007, I anticipated the rapid move of anti-virus to the cloud, which we see today in Panda Security’s “collective intelligence,” in McAfee’s Artemis project, Trend Micro’s Smart Protection Network, and in new startups like Immunet. For cloud coverage of client security, I will partner with Chenxi Wang, but security topics that have anything to do with stuff sitting on endpoints, I will be your analyst.

I will not take on any of Natalie’s IT operations topics, such as BYOPC, mobile management, client management. These areas will be covered by other analysts on the infrastructure and operations (I&O) research team, chiefly Chris Silva and Ben Gray. Rather than speak for them, I will let them speak for themselves. I will collaborate with Ben and Chris on security strategies and best practices as it affects their topics.

I will also retain my coverage of data security topics, notably data leak prevention (DLP) and enterprise rights management. A few subjects will transition to my other colleagues on the Security and Risk team. We will likely announce details after we conclude those discussions.

In the meantime, Forrester customers who would like clarification on what the shift in security coverage means for you should contact their client services representative. I would be happy to speak with you! But the short answer is that not much is changing. You will talk to me rather than Natalie. She provided excellent coverage of client security topics, and I will strive to do the same.

 

[posted by Andrew Jaquith]