1. Call IT for the information. The biggest risk here is being laughed at by IT for asking. Coming in a close second is the risk of your boss finding out and asking you to get back to work.
2. Spend time searching the web for other accessible feeds – like Univision. A minor risk here is a lack of productivity. It is minor because in many cases, non-productive employees will find something to waste time on. A more significant risk is threat propagation from random clicking to access unknown video sites (drive by downloads anyone?). FIFA themed attacks are already popping up, one trying to take advantage of the Adobe zero day flaw (CVE-2010-1297) which by the way, was covered Palo Alto Networks on Tuesday of this week.
3. Use remote access (RDP, LogMeIn!, etc) or tunneling applications (SSH) to access their home machine and watch from there. This avenue is possibly the most threatening because users will not understand the risks. The risks here are that the user will not know what they are doing and will open a back door to the corporate network (unknowingly of course). Too often, organizations will ignore, or minimize the risks that the use of these applications pose to the network.

Luckily, Palo Alto Networks customers will be more prepared to control, or prevent the use of these types of applications. This is not the case for those who use dated security technology, as pointed out in a previous entry.

The first one is Google Buzz, an application that “extends” Gmail into the fringes of social networking by allowing users to share links, photos, videos, status messages and comments organized in “conversations” with their friends and visible in the user’s inbox. Currently in a very public beta, Google Buzz represents significant risks to businesses because of the lack of controls and the ease with which data is share—purposely or accidentally. Google Buzz is an application that the security team would be wise to watch very closely due to the elevated risks it poses.

On the other end of the spectrum is Modbus, an open source protocol that is use by many manufacturers to manage programmable logic controllers (PLCs). Modbus, like many applications has a wide range of functions, some of which may be beneficial and others that may not be, so enabling or disabling only Modbus (and all of its functions), may be somewhat limiting. To provide greater flexibility in policy setting, the 14 Modbus functions are identified so customers can set policies on Modbus (all) or on specific functions, for specific users, IP addresses, security zones and more. Visit the Applipedia to learn more about the Modbus functions.

The next application example is Millennium Integrated Library System (ILS) – a complete set of management tools that helps libraries efficiently acquire, manage and track their assets. Like Modbus, Millennium ILS is a business application and neither of them would be confused with a social networking application, nor to they represent the same levels of business or security risks.

So why bother identifying all of these applications? The answer is simple: Knowledge is Power. Visibility into the all of the applications on the network at the firewall means IT can:

• Respond to incidents more quickly: Visibility into these applications, who is using them, where the traffic is going and any threat related activity means that if a security incident occurs, the security team can use the information to more quickly narrow down the source of the incident and respond appropriately.

• Implement usage policies: Knowledge of the application means that as needed, policies can be put in place to allow the application to be used by certain groups, within specific security zones or at certain times.

• Become business relevant: Knowing how the applications are being used means that the security team can de-bunk the Dr. No label by having more relevant conversations with the business groups about how to use these applications to benefit the bottom line, yet do so in a secure manner.

There are many different aspects to control and blocking is only one of them. Control is more about enabling the use of specific applications for specific users (are they allowed to use that application?) even if they fall outside of the work related definition; seeing where the traffic is going (should SQL traffic be going to that zone or subnet) and; protecting the traffic against threats or unauthorized file/data transfers. Using this definition, control encompasses the entire population of applications on enterprise networks including the business applications.

When evaluating the next firewall purchase, be sure to match the many different aspects of the word “control” to the specific needs of your company.

Thanks for reading.

The report is packed with details on how attackers were able to compromise nearly 1300 computers in 103 countries. Evidence leads the researchers to believe that users were convinced to click a URL or download a document, a presentation or a PDF file by a message from (supposed) friends or acquaintances. In reality, they were the attackers spoofing their friend’s email. Once compromised, the attackers used a variety of web 2.0 applications and tools (Twitter, Yahoo! Mail, Google Groups, and numerous blog sites) as their command and control infrastructure.

Think about that for a moment. Sheer genius really. So how would a security administrator stop these attacks. Short answer, they can’t—not easily anyways. As a security vendor, I would love to say We Can Stop That Traffic, but I would be lying. So would any other vendor. Here’s why I am willing to say this.

• The compromised machines were actual users who had inadvertently downloaded some malware. With the increasing amounts of personal information in the public domain, targeted users face an uphill battle against a group of dedicated criminals. Even the smartest and most vigilant user who thinks thrice before clicking can eventually be convinced to click on something from a friend or acquaintance which can, in the background download the necessary malware to connect to the command and control infrastructure. Sure we can continue to stress user education but this will only go so far.
• In some cases, the attacks took advantage of old vulnerabilities in MS office applications that, I would speculate, could have been avoided through persistent patching.
• The applications (Twitter, Yahoo! Mail, etc) used as the C&C infrastructure are found commonly in every organization, as outlined in our twice yearly reports. So even if an organization had our appliance in their network, any of the C&C traffic will look like Twitter, Yahoo! Mail or blog traffic (assuming it is allowed).

So should we shut the doors and surrender. No.

At a minimum, organizations need to be vigilant (more so than ever) in their continued user education efforts. They need to be persistent in their patching efforts. And they need to be more intelligent in their efforts to monitor and control what types of applications are allowed on the network and what types of files and data are allowed to be transferred. It is in this last area that we can help organizations. By first setting specific policies on the usage of applications – both business and personal. And as part of that policy, control the file transfer functions as well as the files and data that can be transferred.

We created Stateful Inspection at a time when applications could be controlled using ports and source / destination IPs because applications were tightly tied to ports and protocols. But today, applications of all types no longer adhere to port and protocol which means they can no longer be controlled, let alone identified by today’s port-based (Stateful Inspection) firewalls.

Today’s applications use either well-known open ports or a variety of evasive tactics to easily bypass firewalls. Sadly, most 11^th graders can go into any corporate network and use any application they want, go anywhere on the internet and do anything they want through the corporate network and there is nothing firewalls can do about this. The fundamental reasons that Stateful inspection can be easily evaded include they rely on fixed ports, they look only at the first packet and they are unable to inspect SSL traffic.

The question then becomes one of whether or not Stateful inspection can evolve in the same manner that the applications have. The answer is no. Stateful inspection is architected to classify traffic based specifically on ports and protocols. The use of port and protocol traffic classification is hard coded – it is arguably the most fundamental component of Stateful inspection because it is used as the basis of the security policy. The allow or deny decisions are based on the port and protocol, so modifying Stateful inspection to replace port and protocol with application identity means a complete re-write of the software, a monumental task, given the foundational importance of traffic classification. Here is why Stateful inspection cannot evolve.

Stateful Inspection firewalls enforce policy decisions for a complete TCP or UDP connection upon receiving the first packet of that connection. Once the policy decision is made, further inspection and associated policy lookup is not required because every packet carries the same port number and the following packets from the same connection are not going to provide any additional information about the connection. This form of classification and policy enforcement cannot control many of the applications we see on enterprise networks.

Classifying traffic based on applications must continuously examine packets and check the policy table in order to determine how to treat a given connection. For example, the first packet might have a destination of port 443. The firewall performs a policy check and determines that the connection should be accepted. After a few more packets, the firewall might learn that this an SSL connection (it could have been non-SSL on port 443). Again, the firewall consults the policy to determine whether to allow the connection and also figure out whether this SSL connection needs to be decrypted. After a few more packets, the firewall might learn that this is HTTP inside SSL on port 443. Again, the policy lookup needs to be performed. Additional inspection might determine that this is Yahoo! Instant Messenger, which again requires a policy look up and an allow or deny decision. The traffic classification and policy lookup process continues in this manner for all traffic across all ports.

During the continuous classification process, firewalls that classify traffic based on applications do more than just multiple policy lookups. They need to determine when to log new information they discover—which is a continual process, given the comparatively dynamic nature of application traffic. In addition to continual policy lookup and logging, the application is used as the basis for route lookups, QoS decisions, threat prevention and so on.

Now, let’s assume a complete rewrite of Stateful inspection is achievable, it is only one of the two components required to deliver an enterprise-class firewall that controls applications. The second component is the hardware required to support application layer inspection across all ports and on all traffic. It is well documented that this level of inspection requires significantly more processing power then mere port-based scanning. For example, in a Stateful inspection firewall, a flow that is established can move to a “fast-path” because it does not requires any more policy lookups. As described above, this is not the case with an application aware firewall. The continual inspection and policy lookup requires appropriate processing be applied to maintain performance. Existing Stateful inspection vendors would therefore be forced to not only re-write the software from scratch—they would need to develop in tandem, a new hardware platform with appropriate processing power.

In short, Stateful inspection, cannot evolve to control applications. A new approach is needed – one that identifies applications as soon as the traffic hits the box, ignoring ports, protocols, evasive tactic or SSL encryption. That is what we created here at Palo Alto Networks.

One of the key points made by Golan Ben-Oni, senior vice president of network architecture at IDT, was that next-generation firewalls have enabled him and his team to focus on what’s important, and not spend so much time just maintaining firewall rulesets.  Furthermore, because of the application visibility and control, and the capacity of Palo Alto Networks firewalls, IDT was able to greatly simplify their infrastructure – reducing both the number and variety of security devices – all while gaining more visibility and control.  The most important implication of this point, however, is summed up nicely:  “In the course of the first week, I had gotten more done than I had in months and months,” he said. “Once I was able to get the Palo Alto [firewalls] in, I was able to return to my normal job and get some sleep at night.”

In the information security world, the acknowledgment that a product or service has enabled a customer to get more sleep is is the highest goal that a security technology vendor can aspire to.  Have a look at the article here.

Case in point. A St Louis Today reporter posed an open ended question and did not like one of the more vulgar responses—no doubt posted due in part to the “anonymous” nature of the web. But rather then let it go, the poster was “outed” to the employer and summarily fired. This is a perfect example of a little knowledge (the identity of the anonymous poster) used in a manner that most would view as an overreaction. So the question we have to ask is this – would either of these reactions (the post and the retribution) be made in a face-to-face meeting. I don’t think so.

Let’s switch gears now. Our customers are deploying a next-generation firewall that gives the security administrators detailed information on the applications traversing the network, who is using them and the potential threats they pose. The administrators face a similar dilemma of how to use the newfound knowledge they now have at their fingertips.

One extreme is to blindly block everything that is non-business related. Doing so may conserve bandwidth, and improve security a bit it will also damage morale and force users to try and find ways around the controls. Most importantly, blindly blocking will slow company productivity because personal applications like IM, webmail, Google Docs, Twitter and Facebook are being used for work purposes. The other extreme is to monitor and blindly allow everything. This too is going to hurt company bottom line but for different reasons.

The right approach is to work with the business groups to determine usage policies based on the new found knowledge, educate users on the new policies and then enforce them. And it should be done in a face-to-face manner – where possible. If for no other reason than to avoid overreacting.

http://www.stltoday.com/blogzone/talk-of-the-day/talk-of-the-day/2009/11/whats-the-craziest-thing-youve-ever-eaten-and-did-you-like-it/ http://arstechnica.com/web/news/2009/11/paper-outs-anonymous-commenter-job-loss-ensues.ars

http://www.eweekeurope.co.uk/news/cios-frown-on-social-networking-at-work-2007 http://community.zdnet.co.uk/blog/0,1000000567,10014107o-114626b,00.htm https://www.mckinseyquarterly.com/home.aspx http://www.aiim.org/

In response to the eWeek article, this author raises the case that if there are business benefits to be derived in the use of social networking, then it should be allowed.

We could not agree more. Although we would add the caveat that they should be allowed provided that regulatory policies remain in tact and are adhered to. The position of summarily blocking a new or unknown application is unreasonable and in some cases, could be career limiting. Imagine that the CIO blocks the CEO’s favorite application.

Looking specifically at social networking users, most of them are in the 35 and under age group. The fastest growing group of users are those who are over 35. Currently, there are at least 30 social networking applications http://www.paloaltonetworks.com/applipedia/ available to end users with FaceBook as the most dominant. 315 MILLION users.

What does this mean? It means that theses users will be in the workforce for many years to come and they are accustomed to using these applications whenever they want. So it makes sense to figure out a social media strategy that benefits employees and the company itself. Two reports from AIIM  and McKinsey  both highlight the fact that social networking, and the other web 2.0/enterprise 2.0 applications are indeed resulting in measurable benefits. If they are spending too much time on these applications, then perhaps it is a personnel issue – not an application issue.

Now more than ever. It’s time to fix the firewall.

The use of these tactics is common, as shown in the Application Usage and Risk report where 57% of the applications we found can hop ports, use port 80, or port 443. While that statistic is interesting in and of itself, what is more interesting is the category and technology breakdown of these applications.

Figure 1: Applications that can evade security using port 80, port 443 or by hopping ports.

The high number of collaborative applications is populated by corporate and personal email, IM, social networking, blogging, internet conferencing, and VoIP. The interesting statistic is the range of underlying technologies used – the browser is the vehicle of choice but when compared to the those applications that use P2P and client/server, the breakdown is roughly equal. Corporate applications like SharePoint and WebEx both fall into the collaborative category and both use port 80 or port 443 respectively. So would you consider these applications evasive (in a bad way) or easily accessible? Most would call them the latter and given the popularity of both applications, would agree that these applications bring significant business benefits.

What are the risks? All applications carry risks. SharePoint and WebEx both use port 80 and port 443 respectively so they look like web traffic to most security solutions. SharePoint uses SQL, IIS, and .net and there are known risks associated with these components. WebEx has a desktop control feature that represents risks to financial services companies. So the trade-off is to allow these applications on the network but to take security best practices to apply policies that can mitigate the associated risks.

Another example is Skype, a VoIP application. Skype uses two techniques to simplify accessibility – it hops ports and it uses encryption. Admittedly the latter is also for privacy. Skype is widely used but not that widely deployed and supported by corporations. Yet it is a great tool, allowing the weary road warrior quick and cheap phone service from around the world. The risk of using Skype and other VoIP applications recently increased with the discovery of a Trojan that will listen to your phone calls. The article points out that risk this Trojan represents is slight and is expected to be used in a very targeted manner (against individuals or a small group). Here too, a risk vs benefit trade off needs to be made. Other examples of applications that fall into this risk vs reward discussion abound: Twitter, YouTube, Google Docs, Zoho, and the list goes on. New studies show the benefits of social networking yet one would have to be blind to miss the seemingly daily discussion of the risks these applications pose.

The statistics show that many applications can be considered evasive and yet many, while not supported by corporate IT, will bring significant business benefit. So the challenge we face is to help IT determine which applications are in use, who is using them, and then analyze the risks vs benefits, applying policy as appropriate.

Thanks for reading.

Is trying to control social networking an exercise in futility?

1) employees will quickly find out how to circumvent the technology used to block access. A five minute search on the web will show even the least sophisticated user how to bypass URL filtering or other legacy security technology. Of course the ramifications associated with this action are multi-faceted. First off, it exposes the company to unseen risks such as loss of company data, threat propagation and lack of compliance. Second, it exposes the employee to the same risks, but from a personal data perspective.

2) employees will respond in many ways – mainly in unproductive, dissatisfied ways. They will complain to IT (the internet is down), management (why can’t I see my FaceBook page—I need it for work!) and their friends (OMG – management are luddites – they are blocking FaceBook!). Or worse, they will quit – a rash but not unheard of reaction. In these possible scenarios, productivity decreases even further because employees are ranting about how strict the company is…yadda, yadda, yadda.

Why not take a more proactive approach and embrace these applications by defining how and when they can be used? Stating specifically that yes, you can use these applications, but the company will be scanning the traffic for threats to protect both the networks and employees from themselves. Wouldn’t this make the workplace a more positive environment? And possibly more secure?

You tell me. Give us a shout and let us know your thoughts.

It brings up an interesting point – the need for network and security folks to evolve their risk management posture from a default “no” to a default “yes, and here’s how,” as discussed in my steamroller piece.  The idea behind Applipedia in general is to give networking and security folks a way to understand the functions and risks associated with an application, and provide a comprehensive database of the applications we control.  Applipedia has been available on our website for some time, and the iPhone app puts the same knowledge in your pocket.  So next time you’re having a conversation in the hallway with a business-side person, and the subject is the adoption of a particular Internet-based application, pull out your iPhone, fire up Applipedia, and you can quickly inform them of the behaviors and risks associated with that application – and how to safely enable it.

Check it out here, and let me know if it’s useful to you.