New report: “Web Application Firewall: 2010 And Beyond”

I was offline for a bit to deal with some family issues. Good to be back.

Today’s quick post is on a hot-off-the-press report I just published: “Web Application Firewall: 2010 And Beyond”. http://bit.ly/9utFJG.

The premise is that pure WAFs are morphing into WAF+, which finds its place in firms’ network infrastructure.

A quick abstract: “Having been thrust into the spotlight by payment card industry (PCI) data security standard (DSS) requirements three years ago, Web application firewall (WAF) — a technology that detects and blocks attacks against Web applications — has significantly matured. It’s taken on a decidedly interesting identity, and standalone WAFs are almost nonexistent. In its place are solutions that include additional network functionality like content acceleration, application visibility, authentication, and database monitoring. We dub this new family of products “WAF+”. Forrester estimates the 2009 market revenue of the WAF+ market to be nearly $200 million, and the market will grow by a solid 20% in 2010. Security and risk managers can expect two WAF trends in 2010: 1) midmarket-friendly WAFs will become available, and 2) larger enterprises will gravitate toward the increasingly prevalent WAF+ solutions.”

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

Facebook’s new privacy settings

Last week, Facebook just upgraded its privacy settings. I am sure by now many of you have gone through the new privacy setting wizard. But do you know all the ins and outs of the new settings and how to navigate them?

In general, the new Facebook privacy setting menu is easy to use and straightforward. Some of the new options Facebook provides are positive changes. For instance, you can now hide a wall post to specific individuals (or make them visible to specific individuals). This level of fine-grained control was not available before, which is a welcome change.

However, in the course of migrating to the new privacy settings, Facebook has made several categories of information visible by default to “Everyone”. If you didn’t actively manage your privacy settings through this new migration, some of your information, such as Family and Relationship, Education and work, and your posts will be left visible to everyone, regardless of what your previous privacy settings were.

Another puzzling thing is that Facebook apparently does not think the ability to control who can see your “Friends list” belongs in privacy settings. Moreover, they’ve made everybody’s Friends list visible to the world by default. To turn that off, you have to go to your profile page and click the little crayon icon next to your friends list to unselect the “Show Friend List to everyone” option. If you have previously hidden your Friend list from public view, they are now free for all to see unless you did the little trick with the crayon icon! Even worse, your Friend list will now show up in search engine results.

Speaking of indexing by search engines, Facebook’s privacy settings do provide an option via which you can prevent search engines from indexing your public Facebook information, which is information that you’ve elected to be viewable by everyone (or is it?). Despite the fact that I had strenuously set and checked all my privacy settings, including uncheck the “Show Friend List to everyone” option, Facebook is still showing a sample of my friends to search engines! And we know that once a search engine has indexed and cached your information, it’s virtually impossible to purge the info completely. 

The specific options and settings aside, this concept of PAI, short for publicly available information, is one that worth a bit of ink. Everyone has a different idea of what their PAI should be. However, Facebook has decided that certain categories of information, such as your profile picture, family and relationship info, education and work info, interest and activities, and group memberships, etc. should be PAI, and they’ve gone ahead and made these categories visible to everyone by default. You have to go through the entire privacy menu to change that.

In this age of search engines, content caching, and near-ubiquitous connectivity, have you really thought about what you should place (and not place) in your PAI? Do you really understand all the consequences of putting a specific piece of information in PAI? Do you know how long the information will be available long after Facebook has become yesterday’s news? Most of us don’t internalize the fact that every time you label something public, this “thing” will probably live in the public domain forever in some way, shape and form. Is this something you can live with? Will you still write that paragraph of “About me” and make it viewable by “Everyone”, if you know 50 years from now people can still find that? This is of course independent of Facebook or any social networking platforms in general, it is about fundamentally what information, as an individual, you want to expose to the world. Once we have a good grasp of PAI, we can then look at specific social networking or social media tools and demand them to give us the flexibility and controls to manage our PAI.

(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.