More details on the Microsoft vulnerability that led to the Google hack

Microsoft today released an Out-Of-Band (OOB) security update, MS10-002 (http://www.microsoft.com/technet/security/bulletin/MS10-002.mspx), that addresses, among others, the IE vulnerability that was responsible for last week’s Google hack.

This OOB security update addresses 8 vulnerabilities in total, and is considered a critical security update for Internet Explorer. Microsoft recommends that IE users take immediate actions as a result of this security update. More specifically, if you are running IE v6, immediately install the security update. Better yet, immediately upgrade to IE v8, the latest version.

Additional background on the vulnerability and the attack: This vulnerability was disclosed to Microsoft via the proper channels in December 2009. At that time, there was no known exploits in the wild against this vulnerability. Microsoft told me that they followed the normal procedure and had scheduled the said patch to be released in their regular February 2010 security update. When the attack against Google and others surfaced last week, Microsoft accelerated the patch process and decided to issue this OOB update ahead of their February scheduled release.

All versions of Windows are affected by this particular vulnerability. However, IE v6 is particularly vulnerable. IE v6 is believed to be involved in the Google attack – some Google employees were running IE v6, which led to the attack. IE v7 and v8, though also vulnerable, have other protection mechanisms, such as Data Execution Prevention and Address Space Layout Randomization, which would have made the attack less likely to succeed.

For the techies out there, this is a vulnerability that can lead to remote code execution. Here is how the attack worked:

-        This vulnerability is an IE memory corruption issue that can be triggered by a malicious JavaScript to copy, release, and then later reference a specific Document Object Model (DOM) element. If an attacker is able to prepare memory with attack code, the reference to a random location of freed memory could result in execution of the attacker’s code.

-        In this attack, a Google user is enticed, via email social engineering, to a malicious website that has exploit code targeting this browser vulnerability.

-        The website exploits the vulnerability and injects prepared attack code and executes it on the user’s desktop.

-        This code can then do anything the user is capable of doing including logging onto corporate servers.

-        The rest is history as we know it.

For a more specific analysis of the vulnerability, refer to Jonathan Ness’s SRD blog at Microsoft: http://blogs.technet.com/srd/.

Google tells me that the employee whose desktop was compromised was running IE v6 (as opposed to Chrome, haha) for testing purposes. Really?! Does the test involve the user use the outdated browser to surf the Internet?

That said, the more pertinent topic, of course, is how we could avoid such attacks in the future. A few tips to start with,

-        Always run up-to-date software and patches, browser and otherwise

-        Educate users about social engineering threats – this continues to be a thorn in IT’s thigh.

-        In addition, and this is very important: Use a web filtering product that is able to recognize web-based malware, such as the Javascript-based malware involved in the Google hack, and one that is integrated with email threat protection.

In the meantime, share your thoughts here or on Twitter. Follow me on Twitter@Chenxiwang

Ok. There is more (or may be less) to the VPN story, Google says

Google called me again after I posted the latest follow up to the Google hack story. Wow, two calls from Google AR in the span of an hour! They were uncomfortable about the way I characterized the involvement of the corporate VPN in the Google attack. The official on-the-record word from Google is that: “This is not accurate”.  So, I should rephrase how the attack happened:

a) A Google employee’s machine that was running IE v6 was compromised via the IE vulnerability.

b) The attacker used the compromised machine to somehow gain access to Google servers (some of which housed critical information). The method of access, at some point, may have involved VPN, but Google does not agree with the characterization that “the compromised client used their corporate VPN to gain access to the servers”.

At Google’s request, I retract that particular statement.

This is what we do know factually:

1) The attack on Google server happened

2) Google immediately decided to do an emergency update of their entire corporate VPN infrastructure.

Could these two things be entirely unrelated? I doubt it. But Google isn’t going on the record to say that the attack came in via the VPN, and that’s their official position.

Follow up: Google calls and confirms the VPN story.

Google called me, five minutes ago, confirmed that the attacker indeed came in via the corporate VPN access. On top of that, they told me that the victim machine was a corporate managed machine, not a home computer.

As to why Google employees were running IE v6, Google’s position is that someone might be running IE v6 for testing purposes. Whether this was indeed what happened, they wouldn’t say. Ok, I can buy that you might be running an older version of browser for testing purposes (for backwards compatibility), but why wasn’t the testing environment isolated from production and from access to critical assets? Isn’t that one of the first thing you do in setting up a test environment? Google assured me that they are taking steps to rectify the situation, and for the sake of everyone who trusts Google with their data and applications, I hope they do it soon.

A funny related note: I’ve been trying to get Google’s attention for over a week on a security interview, but they were too busy to respond (understandably, I guess), but five minutes after I put up this blog entry. Google calls me on my mobile. .

Why Google and Microsoft were at fault for the attack, not cloud computing

By now, much has been written about last week’s attack on Google, Yahoo, and more than 30 other companies. Google’s stark reaction to the attack has put the company at the forefront of this news story. At stake is one of the world’s largest Internet market as well as the already tenuous relationship between US and China, it is no wonder this attack is drawing the attention of headlines worldwide.

Why isn’t this an attack on cloud computing?

First of all, the mechanics of the attack, though not entirely clear, have nothing to do with cloud computing. What we do know is the following: A Microsoft browser vulnerability was exploited, some employees’ desktops were compromised, and the attacker used the compromised desktops via Google’s VPN to get to some of the servers. As a result, Google apparently issued an emergency refresh of the entire corporate VPN infrastructure last week, leading to more than a little bump in the road for employee productivity, which lasted more than 24 hours.

So, let’s look at the facts here. Exploiting browser vulnerabilities is a familiar attack method, one that has nothing to do with cloud computing. Compromising desktops and using VPN to further compromise servers is again nothing new. What is at the root of the problem here is a vulnerability from everybody’s “favorite” software company (more about this vulnerability to come later today), not the fact that the target of the attack is a prolific cloud computing company.

However, some of my clients (and many others) were asking why they would want Google to host their applications/data if Google is a bigger attack target than themselves. This is indeed an interesting question, one that is worth exploring. This question is particularly interesting when you consider that the attack in question involved exploiting vulnerabilities in IE 6. Why would Google employees still be running IE 6, an outdated browser? Clearly Google’s corporate IT isn’t doing a good job. But the fact that the attacker used VPN to further its attack suggested that the initial victim machine may not be a corporate managed machine. However, we do not know for sure. In any case, Google is at fault here for not managing its risks adequately. And being one of the biggest cloud computing companies, they should know better.

I will be uploading another entry on the specifics of the Microsoft vulnerability after 10am pacific today. Stay tuned. In the meantime, let me know what you think of the attack and the implications.

This entry will be cross-posted to Forrester’s SRM blog: http://blogs.forrester.com/srm.

An interesting cloud computing panel to start the new year

On Thursday January 7th 1pm pacific, I will be moderating what promises to be an exciting panel–”Cloud computing: A positive disruption to IT security”– with panelist Qualys CEO Philippe Courtot and Cisco’s Chief Security Officer  John Stewart.  See what Forrester, Cisco, and Qualys have to say about Cloud Computing and IT security, register at:  http://www.businesswire.com/portal/site/home/permalink/?ndmViewId=news_view&newsId=20100104005080&newsLang=en

(Updated) Cloudy with a chance of “non-compliance”

Compliance, along with security and privacy, is a big topic when firms consider cloud services. I recently did a Forrester Webinar on the topic of compliance for cloud computing. You can access the recording here: http://www.forrester.com/cloudsecuritywebinar. This blog entry is a recap of the Webinar.

In terms of compliance for cloud services, there are four categories of issues of concern:

• Where: Geographically related issues
• How: This is about operational details that affect compliance
• Audit: Show me evidence that you can help me achieve compliance
• Others: Everything that doesn’t fit into the above categories

 For the “where” category, you need to be conscientious of the following aspects:

• Datacenter locations
• Implications of local laws and regulations (where the datacenters are operating)
• Third-party access: Does the vendor use any “third-party” resources that may affect the locations of relevant data?

 We recently helped a client evaluate the business suitability of a SaaS provider. In the course of doing so, we discovered that the SaaS vendor used a third-party backup service to back up their logs. Although the SaaS provider is located entirely in the US, the backup service provider is not. Therefore there is a question whether my client’s logs will get stored in a datacenter outside the country. This made my client uneasy.

The “How” category is the biggest and most comprehensive, as it includes many operational aspects. For example, along with other aspects, you need to consider:

• Do the datacenter’s operations meet the specific regulatory requirements that you have (e.g., is it PCI compliant – audited by a PCI QSA?)
• Does the provider have a compliance management program?
• Does the provider have a DR/BC plan that is consistent with my requirements?
• Does the provider’s data breach/incident handling procedure meet your requirements?
• Is the data center SAS 70 Type II certified?

 The “Audit” category deals with the procedure of audits, framework of audits, whether or not the provider can supply adequate audit evidence or agree to a third-party audit.

In addition, you need to consider eDiscovery and enterprise investigation support. Too often enterprises tell me that cloud providers do not let them be the administrator of their data living in the cloud. You need to ask your vendor what support they will provide for discovery and investigation purposes, such as any restrictions on access to data, means of access to data (self servicing vs. manual), responsiveness to discovery requests, flexibility to data access, etc.

Finally, third party is often the “fly in the ointment”. Even when you are satisfied with every aspect that you can conceivably think of with respect to your cloud provider’s operations. You need to understand whether they use any third party in a way that impacts your compliance status (see the example I listed above). Everything we talked about so far applies to third party accesses.

What does this boil down to? In the next 90 days, we recommend that you form a cloud game plan, which looks like the following (for compliance aspects):

• First step, gather legal and regulatory requirements, involve legal/compliance/risk officers early
• Second, conduct a high-level feasibility study based on these requirements
• If the feasibility study indicates a preliminary green light, then perform detailed evaluation (based on the “where”, “how”, “audit” framework here)
• Require audits when in doubt, embed recourse actions in your contracts, and engage trusted third-party assessment services.

For details, please refer to the Webinar recording located at: http://www.forrester.com/cloudsecuritywebinar

Let me know what you think. Any other compliance aspects that we missed here?

To Facebook or not to Facebook (40% of companies said yes to Facebook)

Recently Forrester received a flurry of inquiries concerning social network access inside enterprises. Many firms are reluctant to deny their employees’ access to social networking sites but in the same time worried about consequences such as malware threat, data loss, and the loss of productivity.  

More specifically, risks associated with social networking come in three flavors:

• Malware and Phishing: Social networks have become a hot bed for malware and Phishing activities. As such, allowing access to sites like Facebook, MySpace, LinkedIn, etc., does carry a certain amount of security risks.
• Data loss: Employees post content to social networking sites pose a potential threat of data loss, which has many up in arms about the use of social networks in enterprises.
• Damage to corporate image: There is no reliable way to ensure that no one can set up a fake corporate page in LinkedIn or Facebook, and that no one takes your official promotional video and repost it to Youtube after unauthorized edits.  

Should you allow access to social networks and social media? The answer is “Yes”. Even if you do not currently allow access to social networks, you will have to soon—access to social networks is approaching the status of a “must-have” at work places. Competitive pressure will sooner or later make you rethink your restrictive stance on social network access. One question we often get asked is: “How many firms out there are allowing access vs. denying access to social networks?” We do not have an accurate answer to that. A small survey we conducted in the beginning of this year indicated that today nearly 40% of companies (enterprises and SMBs) allow access to social networking sites like Facebook and LinkedIn.   

What best practices should you follow in regulating access to social networking and media sites?

 First, you need to establish an acceptable-usage policy with respect to social networking and media access. Consider these aspects when writing your policies:

• Does everyone need the same level of access to social networking sites? The answer is often “no”. For instance, the marketing and sales team may need to post video and other media files for legitimate business purposes. But for other parts of the company, there isn’t such a compelling need. Perhaps a read-only policy is adequate. Of course this would depend on the general company culture – how liberal or how restrictive you are in terms of personal computing at workplace plays an important role in these decisions.
• Be vigilant about software downloads. Remember malware travels via software downloads over the web, a prudent policy might allow users to access Facebook content but will block any software installation as a result of visiting Facebook pages. This will of course dilute the social networking experience, but in many ways, it is an acceptable compromise for workplace access.
• Should you allow access any time anywhere? Again, the answer depends on how liberal your company culture is. On one hand, you do not want to place unnecessary restrictions. On the other hand, there has to be a balance between personal uses of social media vs. workplace productivity. So, the acceptable-usage policy may state that employees should use their best judgment when it comes to the amount of time they spend on Internet social networking sites. Or, if the company culture allows, you may enforce time or bandwidth-based limitation on access to social networking sites.
• Acceptable data posting policy. Social networks allow data posts, which may pose a data leak threat to enterprises. In your usage policy, make it clear what kind of data/content is considered non-appropriate in data posts to public social networking sites. For example, some companies prohibit their employees from posting endorsement or commenting on the company on LinkedIn. 

Second, you need to clearly communicate the policies to your users and educate them on the risks of social networking and acceptable usages with regards to data posts and software downloads. Make it clear that these security threats are not just against individuals, but also have the potential to compromise the security posture of the corporate environment.  

Lastly, if you decide to enforce your policies technologically instead of simply stating the policies and hoping for compliance, you need to employ a web filtering product (you probably want one regardless for anti-malware reasons). You may also want the product to collect and report usage statistics on your users. For any outlier population, e.g., the a few employees who spend an exorbitant amount of time on social networks, his/her manager can be made aware of the situation and deal with it in an appropriate way. Often, just the knowledge that access to social networks is monitored would curtail such behaviors. Be mindful that not every web filtering product is equipped to deal with script-based web malware. The ones that come with an anti-virus engine but no script processing capabilities do not fit the bill. Finally, it is imperative that the web filtering product comes with data leak prevention (DLP) capabilities to enforce acceptable usage policies for data posts.

 

Follow up: Cloud security

Since the publication of the last entry on cloud security, I received many emails from clients and colleagues who have an interest in this topic. Because of the sensitive nature of the topic, they chose to email me rather than leaving a comment here. I have synthesized and sanitized the feedback, and decided to publish the summary here:

a) Investigation support: A few responses stressed the importance of support for enterprise investigation. They  voiced frustration with the lack of timely response and technical support from some of the cloud vendors. One senior IT officer said: “For every investigation, I have to work with the vendor to get the data I want. They don’t have an option for me to be the administrator of my users’ data and logs. This goes against the self-service nature of cloud computing, and essentially takes away some of the benefits”.

b) Security and privacy are equally important for all layers of cloud, as customers may be buying a combination of  services (of different layers) from the same provider. The so-called ”layers of cloud” include infrastructure-as-a-service(IAAS), platform-as-a-service (PAAS), and software-as-a-service (SAAS). Each layer may have its own unique challenge. 

c) Incident response and disclosure: Readers pointed out that you may want to know that a data breach has happened within the cloud environment even though your data may not be breached. This is a tough issue because from the users’ standpoint, you want to know the incidents so you can make an informed decision whether to stay with the cloud. But on the flip side, you may not want the provider to offer too much information to other clients if it were your data that were breached. There is no standard procedures today people follow for incident disclosures that impact other people’s data.

d) Compliance: Some compliance requirements demand that relevant data be encrypted both at rest and in transit. Many of the cloud providers do not support that and in some cases due to the way the application is configured, encryption by the customer of the cloud is also not an option. For instance, some cloud applications leave sensitive information in the database index, which is typically not encrypted even if the blocks are encrypted. In this case, having block-based encryption is clearly not sufficient.

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 tremendous 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 therefore are 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 closer look at security issues for cloud computing”. 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, 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 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

Dreamforce in force

Today is the first day of dreamforce. Due to a scheduling conflict, I am actually not attending, much to my dismay. I’m writing this post in flight to NYC, using WIFI on a united flight (nice!). My colleagues who are in attendance told me that they are putting on a good show. In any case, I have an ongoing research effort to evaluate security and privacy practices of leading cloud vendors, such as Salesforce. So far, Salesforce has been very accommodating in terms of granting interviews, etc. Stay tuned, more on that topic to come soon.