Werner Schmidt
Enterprise Networking and Security Expert

Security - An Application View

Last month I was lamenting that there had to be a better way to take a look at a different security stack model and imagining a security stack with solutions that:
  • Allows a company to whitelist appropriate behavior and applications
  • Determines a threat by sandboxing attachments and checking what the behavior is
  • Determines a web application threat by observing the actions of attackers and assessing their skill and tenacity and counteracting accordingly
  • Use profiling techniques to log individual attackers and threats
  • Log events from above for legal or compliance concerns

I’ll be building upon this discussion next month as well. This month we’ll touch upon whitelisting appropriate behavior and applications. Whitelisting has been around for quite a while and keeps making a comeback. We’re all used to blacklisting, which is a process where we list those things (sites, applications, users, resources, etc.) we wish to blacklist or block. With blacklisting, that which is not blocked is allowed. Whitelisting is a process where allowed things are listed, that which is not on the allowed list just isn’t allowed. This can pertain to web sites, usernames, desktop applications, firewall ports, etc.

For now we’ll focus on the firewall. In the old days, ports used to represent applications. Port 25 (smtp) was Email, port 23 (telnet) was terminal access (mainframes or minicomputers), port 22 (ftp) was file transfer, etc. Port 80 was just for web browsing. Now however, 80% of all traffic is port 80 and a large percentage of it is encrypted. Web browsing is defined as just that, web browsing (think cnn.com, weather.com, wikipedia.com, etc.). It’s where you use a web browser to look at general text and some static pictures to get information. It might be a support site, might be a vendor site, etc. Classical browsing would not include web 2.0 applications. Web 2.0 applications are full fledged applications that happen to run over port 80 versus older ports or client/server applications. In the past we would run Quickbooks as a local application, now that can be run across the web or in a cloud. SalesForce is the classical example of a web 2.0 application. With web 2.0 applications, now you can transfer files, listen to audio, watch streaming video and use proxies or encryption to avoid detection. Now we need to focus more on the characteristics of what is occurring on port 80 and 443 (and the other ports still too!) to determine our security posture. These days, entertainment in various forms consumes massive amounts of corporate bandwidth. Web application characteristics include:
  • Is it capable of being evasive (port hopping, encryption, etc.)?
  • Is it using or able to use excessive bandwidth?
  • Is it prone to misuse?
  • Can it be used to transfer files?
  • Can it tunnel other applications?
  • Is it used by malware?
  • Does it have vulnerabilities?
  • Is it widely used?

We might also want to factor in potential risk by application as well.

Lets look at some examples of each (all lowercase for simplicity):
  • Evasive - azureus, bittorrent, gnutella, logmein, skype, youtube
  • Excessive bandwidth - bittorrent, emule, ftp, gnutella, google-docs-uploading, kazaa, xunlei, vimeo, youtube
  • Prone to misuse - ftp, guntella, hamachi, hopster, kazaa, smtp, skype, vnc, webdav
  • Transfers Files - bittorrent, ftp, gnutella, google-docs, hamachi, logmein, wevdav
  • Tunnels other apps - hopster, irc, kazaa, logmein, socks, vnc
  • Used by malware - bittorrent, hamachi, http-tunnel, skype, vnc, xunlei, youtube
  • Vulnerabilities - Many applications have known vulnerabilities. Short list: ftp, irc, logmein, nntp, vnc, youtube, webdav
  • Widely used - Many applications are used extensivley

Try applipedia (
http://ww2.paloaltonetworks.com/applipedia/) to explore applications. Following is a page of what that looks like. This is the same application that is used by Palo Alto Networks when setting application use policies:



So, where does this leave us? We should no longer think that opening up just port 80 and 443 from trust to untrust is adequate. Furtermore, adding URL filtering does very little in terms of application control. URL filtering cannot address any P2P (Peer to Peer) application threats because the other end(s) are unknown by their nature in that they are just end user desktops not known URLs in almost all cases.

Recommendations:
  1. We should whitelist by actual applications
  2. We should whitelist by users and/or groups
  3. We should implement QoS to further protect and prioritize key corporate resources
  4. We should still look for threats on approved applications (we shouldn’t bother scanning disallowed applications)
  5. We still probably want to allow classical web browsing, but should apply URL filtering
  6. We should strongly consider decrypting traffic in certain cases and not decrypting in certain category destinations (e.g. banking, healthcare)

This is just the first touch on a lengthy subject. Future articles will explore deeper how to properly detect malware and protect against it. I’ll also be discussing other approaches to protecting public web servers from outside threats.