A Proxy By Any Other Name

In almost every corporate computer network today there are proxies to be found. This is pretty much a standard computer security practice. The confusion starts when people start talking about all the various proxy types. Within the confines of this article all of the various proxy types will be discussed.

Most corporate computer networks today are designed with a purpose in mind. That purpose is usually a balance of security and usability. The end state of almost every corporate computer network today is to facilitate the work of the employee. Making their life easier through a simplified computing experience makes good business sense. One must also take into account network security concerns as well. This is where the proxy enters the picture. Just what is a proxy though? Well a proxy server is a computer operating as a server vice workstation. This proxy server in turn offers other computers an indirect means of accessing other computer services. Services such as a Web server for example located somewhere on the Internet. Simply put, the workstation opens its homepage of say EonConnects.net and that request is in turn relayed to the proxy server. The server will check to see if it has a cached version of this page and if not it will then go get it and relay it back to the workstation in question.

The nuts and bolts of it

If the above noted scenario still doesn’t make a whole lot of sense to you then think of it this way. Having such a proxy server will, for one, speed up the browsing experience for a corporate user. It is much faster to serve up a cached page then it is to retrieve it every time. When the proxy server or, in this case, the caching proxy receives a page request it will, as mentioned, check to see if it already has it. It will also see if the cached page has expired or not. Should the validity of the resource requested have expired then it will go and get a new copy of that resource. That alone makes it worth having a proxy server on a network. There are many other advantages to having one though. Those advantages very much impact the security posture of a corporate network as well, hence the prevalent usage of them. One of the most obvious advantages is being able to centralize all web page requests in one location. This will establish a chokepoint that can be exploited for security purposes.

The transparent proxy

Just as I mentioned above, having the ability to have all client requests go through a single computer gives one the ability to monitor client usage. By client I mean a corporate workstation. This centralization is done by configuring the client browser to use the transparent proxy server’s address. Though this definition of a transparent proxy is a popular one it is also incorrect. In reality a transparent proxy is a combination of proxy server and NAT technology. In essence client connections are NAT’d (network address translation) so that they can be routed to the transparent proxy. Having this type of setup is also a major pain, I am told, to implement and maintain.

The reverse proxy

What the devil is a reverse proxy you ask!? Good question indeed. Typically a reverse proxy is installed in close proximity to one, or several web servers. What in actuality happens is that the reverse proxy itself is the point of first contact for all traffic being directed at the web servers. Why go through the bother of this though? Well for several reasons actually. One of the primary ones is for security purposes as this reverse proxy is a first layer and acts as a buffer for the web servers themselves. Another reason is for SSL connections. Encryption is a computer intensive task and having it performed on the reverse proxy vice, the actual web server makes sense in terms of performance. Were the web servers themselves handling both the encryption part as well as the actual web server part then that machine would quickly become rather slow. For that reason the reverse proxy is equipped to handle the SSL connections and normally has some type of acceleration hardware installed on it for this very purpose.

Another key reason that the reverse proxy is employed is for load balancing. Think of a popular website that has a lot of visitors at any given time. It makes sense that there would be multiple web servers there to handle all incoming page requests. With a reverse proxy in front of these back end web servers no one box gets crushed but rather the load is balanced across all web servers. This certainly helps for overall performance. Another feature of the reverse proxy is the ability to cache certain content in an effort to further take a load off of the web servers. Lastly, the reverse proxy can also handle any compression duties that are required. All in all there is a tremendous amount of work being done by the reverse proxy.

Split proxies

Just when you think you’re done there is always something else! In this case that would be the split proxy. Well much as its name infers, the split proxy is simply a couple of proxies that are installed over a couple of computers. It’s that simple really. Although this type of proxy configuration is one that I have never come across, I have heard of them being used. One of its main selling points is the ability to compress data and that is a boon when slow networks are involved.

Wrap up

Over the course of this article we have seen the various types of proxies in use today in many corporate network environments. As we have seen many of them are used for specific reasons. There is not really one proxy type that can do it all, hence the variety of them. One of the greatest abilities of the proxy is to help enforce an acceptable usage policy on a corporate network. All too often we hear about someone who was fired for inappropriate use of company computer assets. What that neat use of the English language means is that someone was likely surfing for pornography from work and on company time no less in all likelihood. Even though someone doing this is acting foolishly and deserves to be terminated there are other reasons as well to control and monitor employee Internet usage. You can imagine for example how well it would go over for a high profile, publicly traded company to have an employee caught downloading kiddie porn. If that type of news hits the media all of sudden your company stock price could take a nose dive. Having a proxy in place within a corporate setting is really not only common sense, but also a necessity in reality. While most company employees are hard working and above board there will always be one or two who are not. Having the ability to catch and deal with them quickly is very much desired. Well I will end the article on that note and as always hope it was of use to you.

Securing Your OCS Deployment

Taking a look at the security concerns involved with unified communications and how to add security to OCS.

Office Communications Server (OCS) is Microsoft’s Unified Communications solutions for enterprises, but as with all UC deployments, applications that enable voice, video, IM, file transfers and application sharing can pose security issues. In this article, we address those concerns and discuss OCS’s built-in security features, configuration choices for best security practices, and integrated software solutions (both from Microsoft and third parties) to add security to OCS.

A unified communications system is vulnerable to such threats as eavesdropping or sniffing, identity/IP address spoofing, RTP replay, and so forth, as well as viruses/worms, man-in-the-middle and denial of service (DoS) attacks. Because the confidentiality and integrity of your communications are critical to your business, it’s essential to protect against all of these threats.

Built-in security features in OCS 2007

OCS 2007 provides many new features that LCS 2005 didn’t have, including:

• Enterprise VoIP
• Multi-party IM
• On-premise web conferencing that allows participation by outside users who don’t have enterprise credentials

In addition, features such as presence and federation support have been improved and enhanced.

With new features come new security challenges, but Microsoft has addressed many of these with built-in features. As always, the best security is multi-faceted, so the security framework upon which OCS is built has many components.

Active Directory

Windows server security in a domain is built around the Active Directory, and OCS uses AD to store global settings (used by multiple OCS servers in a forest), data identifying the roles of OCS servers, and user settings.

You must prepare AD for OCS by extending the schema to include OCS classes and attributes, creating OCS objects and attributes and add permissions on objects in each domain. You do this in one of two ways: by using the LcsCmd.exe command line tool on the OCS CD, or by using the Setup.exe deployment tool for OCS 2007. The command line tool can be run remotely. The deployment tool has a graphical interface and wizards to guide you through each task.

The specific steps to prepare AD include:

• Prep Schema (run once)
• Prep Forest (run once)
• Prep Domain (run on every domain where you deploy OCS)

For step by step information on how to prepare AD for OCS, see the Microsoft Office Communications Server 2007 Active Directory Guide. Active Directory Guide.

Authentication

OCS can use standard Windows authentication protocols, depending on the user:

• Kerberos v5 is the most secure and is used for internal clients with AD credentials.
• NTLM is used for clients outside the LAN who have AD credentials.
• Digest protocol is used for on-premise conferencing clients outside the LAN who don’t have AD credentials (they must, however, have been invited to use on-premise conference and must have been supplied with a valid conference key).

Network encryption

To protect data traveling over the network, OCS 2007 encrypts communications by default. Endpoint authentication and encryption are accomplished by using Transport Layer Security (TLS) and Mutual Transport Layer Security (MTLS). Server-to-server SIP communications use MTLS and client-server SIP communications use TLS. These protocols protect against man-in-the-middle and eavesdropping.

TLS and MTLS are also used to encrypt instant messages. TLS encryption is optional for internal client-to-client IMs. OCS communications with public IM servers is encrypted; however, it is up to the public IM provider to encrypt communications between the public IM server and the outside client.

The Secure Real-time Transport Protocol (SRTP) is used to encrypt streaming media. SRTP protects RTP data by adding authentication, confidentiality and replay protection.

Public Key Infrastructure

Server authentication for OCS 2007 is based on the use of digital certificates issued by a trusted CA. This can be an internal or public CA (you may need a public CA if the OCS server needs to communicate with systems outside the LAN). OCS is designed to work with a Windows 2003 Public Key Infrastructure (PKI).

For OCS, all server certificates are required to support Enhanced Key Usage (EKU) to authenticate the servers. This is used by MTLS. Server certificates must also include at least one Certificate Revocation List (CRL) distribution point.

Federation security features

Like its predecessor, Live Communications Server 2005 (with SP1), OCS 2007 has the capability of federating with the major public instant messaging providers (MSN, Yahoo! and AOL). It also supports “enhanced federation,” which allows peer enterprises to be discovered using DNS SRV records. OCS 2007 includes new security features for the federation model. These include:

• Restriction on how many users a federated peer can communicate with over a specified time period. This is designed to prevent “directory harvesting” by which an attacker tries different user names to find a valid one.
• Restriction on the rate at which the Access Edge Server will accept messages from the federated peer, based on analysis of the traffic.

Administrators can also restrict access by adding domains to the Deny list, or blocking peer certificates via the certificate store.

Blocking unwanted or dangerous IMs

You can use the Intelligent IM filter to block unwanted or potentially harmful instant messages and file transfers. You can configure the filters to use the criteria you want, in order to selectively block IMs and file transfers. For example, you can block IMs containing hyperlinks or you can allow the IM to go through with the hyperlink disabled. You can block files with specific extensions.

More information

For much more detailed information on using OCS’s built in security features, see the Microsoft Office Communications Server Security Guide.

Hardening your servers and clients

The OCS server, along with other servers in your infrastructure, should be “hardened” by locking down both the operating systems and applications as much as possible. You can do this through Group Policy. TheWindows Server 2003 Security Guide provides specific information on how to harden Server 2003 servers.

Unused services on your servers should be disabled. The SQL Server database used to store OCS information should be protected. In short, best network security practices become even more important when you have an OCS server on the network. And of course, all servers should be kept updated with security patches and the latest virus signatures.

Client machines must also be configured for best security. You can use OCS group policy to disable the appropriate features and set the client for media encryption. Of course, the latest service packs and security updates should be installed on the client machines.

And don’t forget other OCS devices, such as OCS-compatible phones. You can use the Office Communications Server Software Update Service to automatically update all unified communications devices deployed in your organization.

To evaluate the overall health of your OCS 2007 servers and topology, you can download the Office Communications Server 2007 Best Practices Analyzer.

Microsoft integrated security solutions

In June, Microsoft released a public beta version of Forefront Security for OCS. This is the latest in the Forefront family of enterprise security products and allows you to scan for malicious software using multiple engines, and filter instant messages and files by keywords. It also includes automated signature updates and IM notification alerts.

Forefront Security for OCS is integrated with Access Edge role in OCS 2007 Enterprise edition, which secures messages to and from external public IM clients and federated networks as well as internal communications.

Third party security add-ons

Third party security products designed to protect OCS 2007 include:

• Trend Micro IM Security for Microsoft Office Communications Server
• Akonix L7 Enterprise,, for adding unified policy and risk management for OCS

Summary

Microsoft OCS 2007 is Microsoft’s answer to the unified communications question. It goes way beyond the scope of LCS 2005 and now manages all types of real-time communications, including VoIP and conferencing. In today’s threat-filled world, communications applications are among the most vulnerable, so it is important to consider security first when deploying OCS. This article has provided an overview of security considerations relating to OCS 2007.

Data Leakage, preserving confidentiality

Article focusing on data leakage and how this information asset is lost and the result of exposure. This vulnerability may be the result of inadequate measures, or poorly implemented controls that expose organizations and their clients.

Data privacy will be the trend on the hype cycle for the next 24-36 months. End point security is becoming the big focus and many inventive technologies have been developed to implement solutions that solve the problem. Leaders have already started to emerge in the market space but this race is a long one.

In 2008 Quarter 1 over eight major data leaks have occurred in Europe, exposing over 50 million people in the UK alone. Worldwide these figures are estimated to be tenfold. These are statistics and reflect reported numbers, however these are believed to be understated as organizations and government entities are not keen on reporting data leakage, or data spillage.

At the end of February 2008 a laptop was bought off EBay containing a CD (not in the CD drive, hidden in the computer) this laptop was taken in for repairs, to the local computer shop because of a rattle, and it was found that the CD belonged to the home office in the UK. The CD had written on it that if found please return (home office Confidential) and the data on the CD was encrypted. In this case the data was stored in a secure state, and the laptop was also encrypted, so the encryption keys were safe (or were they?). This is different to the stories of the past where millions of records were found to be in the clear and lost in transit.

Recently, in Princeton University, some tests were performed that resulted in an interesting discovery. It was found that encryption keys for some encryption products stored the access key/keys in RAM and this RAM could be taken out of the computer and the keys could be recovered. This vulnerability has been ignored by some but taken very seriously by others, especially considering that some of the vendors sell a solution that protects against this data disclosure.

Why does data leakage keep happening, and why is little being done about these incidents in the private sector? Do organizations, representatives and officials understand the implications? Does anyone really care about your details? Considering that Identify theft is by far the biggest problem in the digital age, more needs to be done with regards to assurance that your credentials and information is stored and transmitted safely.

Recently I found that organizations were not encrypting their data and that for the most part the people interviewed could not see the benefit of securing the confidentiality of their data because:

• Organizations did not understand the mechanics of encryption and what it was or could be used for in their business context.
• Key staff members, officials, management and directors were not educated about the laws specifying that encryption was necessary for certain data in their operational business and for their jurisdiction.
• It was also the consensus that encryption would add both an administrative and operational overhead that was felt to be unnecessary and potentially costly.
• Some organizations found that the total cost of ownership was too much compared to the value of the data.
• Some organizations did not know about encryption or what it was used for and thus felt that if they had been operating until now without it, it was unnecessary and possibly just another technical control that would be costly to implement and maintain.
• Some organizations said that they had nothing to hide and that no data was stored on their devices in transit.
• In some instances the organization had tried encryption once before but had a bad experience with encryption and thus aborted the project completely or left the solution in a bad state.

How is data stored and transmitted?

Data is stored in containers like liquid. The term data leakage is appropriate as it contextualizes how the phenomenon occurs. Some data flows from place to place in conduits (networks or VPN links) like water in pipes and again this is prone to leakage. In this scenario the data leaks near the tap, on the computer where the data is processed and transmitted from. It is possible for the pipe/network to be tapped/sniffed again resulting in data leakage. The counter to these vulnerabilities is encryption. Solutions like IPSec can help in keeping information that is being transmitted secure.

Liquid can also be carried in buckets; data similarly can be transported on Laptops, Mobile phones, USB devices, memory sticks, tapes, etc. These buckets can have holes or can lack access control solutions to stop people from taking water out of the bucket. These technical controls can come in the form of encryption or strong access controls. In this day and age strong encryption is highly recommended as most access controls are easy to bypass as a result of access of tools available on the Internet.

Other potential data leakage points are remote access solutions, instant messaging clients, email, printouts and intruder attacks. Even a glass window that is part of a skyscraper that someone can peer through using a telescope by using a vantage point in another building can result in data theft. Do not rule these types of attacks out. Although it sounds far-fetched and low-tech, I consult at a banking hub and have recently shown a high profile bank how easy it is to do this from a public building across the road from where data is processed for many of their clients.

Why do we have to stop data leakage?

• Encrypt: Encrypting data enables confidentiality; this means that if the data falls into unauthorized hands the data is unreadable.
• Require two factor authentication: Passwords have become too weak, two factor authentication is becoming more necessary as our lives become more digital. Think about the worth of your digital identity.
• Encrypt communication: If you do not want others to hear what you are saying change the way you speak. Encrypting communications is not a new technique - it was used even in the times of the Romans. Rest assured if you are not interested in the security of your communications there are many unscrupulous people that are.
• Protect your keys: This is very important and should be the number one concern. Access to keys = Access to data. Your key needs to be stored in a secure manner, just like the key to your home it is good to have a second set of keys stored away in a secure location so if the first set is destroyed you can get your second key securely. This year alone I have consulted with four large clients that have lost their keys. One I was able to help by scanning all their removable material for the keys. The keys were retrieved and the data restored. This is also, a security vulnerability but the data was saved. The other clients lost access to their data and are still looking for the keys.
• Backup your data in a secure way: Data storage and data backup need to be performed in a secure way. It is important that data is accessible and the ability to restore is paramount, in parallel it is also important that such data is kept in a confidential form and that unauthorized users are not able to read or manipulate this data. It is frightening to know that fewer than 5% of financial institutions in Europe are encrypting their backups. In a recent consultancy a large financial institution informed me that the encryption shortened the backup window and that it made the disaster recovery operation challenging. Little wonder why the figures do not add up…

Summary

In conclusion, vendors need to bear in mind that solutions that involve the encryption of valuable data needs to be easy to maintain, deploy and follow key management best practice. This does mean the escrow of the key material is stored in a way that will allow for the organization to recover in a disaster. This proves vital on recovery and failing this simple practice will result in lack of availability.

Understanding Microsoft’s Secure Remote Access Offerings

Introduction

Remote access is a hot topic. It is hot because it should be hot. There are a lot of drivers for remote access, but the overarching issue is that people need access to information from anywhere, at anytime, from any device. The outdated vision of access based on specific device or location is gone. Especially in corporate scenarios, people expect to get the business intelligence they need, when they need it, and be able to use a laptop, or desktop, or kiosk, or Smartphone, or even an MP3 player to get to that information. IT has to be an enabler.

Microsoft is inline with this vision of anywhere, anytime access, and has a number of technologies you can use to enable secure remote access. Notice that I’ve injected the term “secure”. Enabling remote access isn’t technically complex. Any simple NAT device or router can enable remote access to business applications and services. The trick is to enable secure remote access so that you do not put your data, your servers and perhaps your job at risk.

From my count, here are the key Microsoft technologies available to you today that enable secure remote access into your organization:

• Windows Server 2008 NPS Routing and Remote Access VPN services
• Windows Server 2008 Terminal Services Gateway
• Microsoft ISA 2006 and Forefront Threat Management Gateway (TMG)
• Intelligent Application Gateway 2007 and Unified Access Gateway (UAG)

Windows Server 2008 NPS Remote Access VPN Services

Windows Servers have included a VPN server component since Windows NT. Since Windows NT, you have always had available to you the Point to Point Tunneling Protocol for VPN (PPTP). The problem with PPTP today is that most security experts consider it a deprecated VPN protocol and it should not be used in production networks due to some inherent security weaknesses in the protocol. While there are ways to bolster the level of security for PPTP (such as using two factor authentication for log on), PPTP is generally of interest only for historical purposes.

Windows 2000 Server introduced the L2TP/IPsec VPN protocol. This a major advance for Windows, since the IPsec tunnel that is used to secure the information is created before credentials transfer takes place. L2TP is used to create the virtual network, and IPsec is used to create privacy on that virtual network connection. Another major advantage of L2TP/IPsec is that both user and machine authentication can be accomplished, because of the use of IPsec. Windows 2000 Server also extended the user authentication schemes available by enabling more advanced EAP authentication methods, so that certificates and smartcards could be used for user authentication.

Windows Server 2008 increased your VPN options by adding the Secure Socket Tunneling Protocol (SSTP). SSTP is essentially PPP over SSL. The great advantage of this protocol is that it runs over SSL, and just about any firewall or proxy allows outbound SSL. That’s right. SSTP will work when the client is behind either a firewall or a proxy (and even proxy based firewalls, like the ISA or TMG firewall). SSTP is included as part of the Windows Server 2008 NPS Routing and Remote Access Service, and it can leverage all the same user authentication protocols that L2TP/IPsec use. The only downside of SSTP at this time is that you to be very careful with some of the configuration steps and the order in which you perform them, otherwise, management can be very complicated. With that said, SSTP remains a tremendous boom for Windows VPN administrators

Windows Server Terminal Services

Like the Routing and Remote Access VPN solutions available for the last several versions of Windows Server, Windows Server has also included a Terminal Services component. While not included with the RTM version Windows NT, it was available later in the NT product cycle. Terminal Services was then incorporated into the operating system with the release of Windows Server 2000. There were some improvements made to the terminal services offering with Windows Server 2003, but it was not until Windows Server 2008 that we saw major improvements.

In Windows Server 2008, and in the upcoming Windows Server 2008 R2, you have major enhancements to the Terminal Services offerings. Still included is the basic Terminal Server, which allows users to connect to the terminal server using the RDP protocol. That said, I should mention that the RDP protocol has been vastly improved. But it is not just the improvements in the RDP protocol that make the Windows Server 2008 Terminal Services offering so compelling. It’s actually a collection of several improvements. These include:

• Terminal Services Web Access
• Terminal Services Gateway
• Terminal Service RemoteApp

While previous versions of Windows Server had a Terminal Services Web Access feature, Windows Server 2008 significantly improves on the experience because it integrates other new features of Windows Server 2008 Terminal Services into the Web site. In addition, access to computers and applications through the Terminal Services Web site can now be controlled using policy based access rules.

Terminal Services Gateway (TSG) enables policy-based Terminal Services access from anywhere in the world. A problem with remote access to Terminal Services in the past was that many firewalls would not allow outbound access to the default RDP port, which is TCP 3389. And of course, since proxies typically handle only HTTP protocols, Terminal Services clients could not reach terminal services over the Internet when the clients were located behind a Web proxy. TSG solves this problem by allowing the Terminal Services client to tunnel RDP inside of RPC, which is then tunneled inside HTTP, and secured by SSL, thus requiring only an outbound SSL connection to be allowed to the TSG. After the client connects to the TSG, policy-based access rules allow you to control which terminal servers or applications the user can connect to.

Did you notice that I said terminal servers or applications? That’s right. With the new Windows Server 2008 Terminal Server, you have the option to publish terminal servers and/or applications. Terminal Services RemoteApp allows you to publish, over Terminal Services, applications. So if you wanted your users to have access to Word and PowerPoint, you can publish those applications over the Terminal Services Gateway and users would be presented with the applications only, instead an entire desktop. This is a great boon to security, since it enables the principle of least privilege – giving users access only to what they need, which are the applications, instead of the entire desktop, which is not what they need. And this access is accomplished over the TSG, which enables strong policy-based access to these applications.

Internet Security and Acceleration Server 2006 and the Forefront Threat Management Gateway (TMG)

Now we move away from the platform services included with Windows Server and look at some of the network security applications Microsoft has to offer for secure remote access. Microsoft made its first attempt at a network security device when it introduced its Proxy Server product in the second half of the 1990s. This culminated in their first mature product, which was Proxy Server 2.0. While Proxy Server 2.0 was a fine proxy server, it was not designed to be an edge network security device for enabling secure remote access.

Microsoft took the jab at secure remote access for a network edge security device with the introduction of Microsoft Internet Security and Acceleration Server (ISA) 2000 at the end of the year 2000. This product was a multifunction device, enabling secure outbound access, secure server publishing and secure Web publishing. In addition, ISA 2000 included strong support for remote access VPN users as well as site to site VPN. On top of that, ISA 2000 was designed as an edge network firewall, so that you no longer needed to put a router-based firewall (layer 3 firewall) in front of the ISA 2000 firewall.

However, the ISA 2000 firewall was built on a threat model that was extant in the1990s but is not longer true in the 21st century. That is to say, in the 1990s, the popular threat model was that anything outside the firewall was not trusted, and anything inside the firewall was trusted. Since this is no longer true, the next version of the ISA firewall, the ISA 2004 firewall, was released and was built on a threat model that assumed that no networks could be trusted and that strong stateful packet and application layer inspection needed to be applied to all connections going to and through the ISA firewall.

With ISA 2004, remote access security was significantly improved. For Web publishing (reverse Web proxy), the HTTP Security Filter was introduced to protect against attacks against Web site. A number of application filters were added or improved, to protect against exploits made to SMTP, DNS and other application servers. And most of all, the remote access and site to site VPN server components now enabled you to create strong user/group based access controls and applied the same stateful packet and application layer inspection that was performed on all other connections to or through the ISA firewall.

The ISA 2004 firewall was the first Microsoft firewall that could be said to be an enterprise-ready, edge network firewall, on par with Check Point, ASA and Netscreen.

ISA 2006 was released two years later and included all the remote access security features included with the 2004 ISA firewall. It included several improvements for remote access security such as:

• Support for Kerberos Constrained Delegation (KCD) so that you can publish Web sites that require users to use two-factor, certificate based authentication at the firewall
• Several enhancements to it’s forms-based authentication feature, so that users can use a flexible form to authenticate to the firewall before being allowed to the published Web site
• Expanded support for an number of new two-factor authentication methods, such as RADIUS one-time passwords
• LDAP server authentication for published Web sites, so that Active Directory repositories could be used when the firewall was not a domain member
• Web Farm Load Balancing, which enabled ISA 2006 admins to avoid the high cost of external, hardware load balancers and publish farms of Web servers behind the ISA firewall

ISA 2006 can also be configured to enable secure remote access to all of the Windows Server 2008 Terminal Services offerings, allowing for another layer of protection for remote Terminal Services access.

The Forefront Threat Management Gateway (TMG) is the next version of the ISA firewall. TMG includes all of the secure remote access technologies included in previous versions of the firewall, but ups the ante on outbound access security, adding malware protection and a uniquely powerful IDS to the mix. In addition, Web content filtering is enabled out of the box for TMG, something that ISA firewall administrators have been wanting for a long time.

Intelligent Application Gateway 2007 and UAG

The Intelligent Application Gateway 2007 (IAG 2007) is for organizations that look for the highest level of security for remote access connections. In contrast to the ISA or TMG firewall, the IAG 2007 SSL VPN gateway is a single purpose device: a remote access gateway for inbound connections to network services. While the ISA and TMG firewalls can provide the same or superior level of security for inbound connections to network services as any other firewall on the market today, IAG 2007 provides the highest level of security possible for incoming connections to Web and non-Web services.

IAG includes a number of software modules, known as Application Optimizers, which confer a very high level of protection for remote access to Web services. The Application Optimizers enable IAG to perform deep application layer inspection for the Web services it publishes. IAG's deep application layer inspection employs both positive and negative logic filtering. Positive logic filtering enables IAG to allow only known-good communications to the published Web service, while negative logic filters block known bad connections.

Four types of connectivity are available with the IAG 2007 SSL VPN gateway. These include:

• Reverse Web proxy. IAG can act as a high security reverse Web proxy by employing application intelligence to remote connection to Web services
• Port Forwarder. For remote access to non-Web applications that require simple protocols using a single port, the IAG port forwarder allows clients to connect to network applications over the SSL VPN tunnel using the port forwarder
• Socket Forwarder. For remote access to more complex application that require multiple primary or secondary connections (such as Outlook MAPI/RPC), remote access clients can use the IAG socket forwarder. All protocols communicated over the socket forwarder is are also protected by SSL
• Network Connector. The Network Connector enables full network layer VPN access over the SSL VPN connection. This is useful for administrators who require unencumbered remote access to the network.

In addition to the SSL VPN gateway features, IAG 2007 also enables PPTP and L2TP/IPsec remote access VPN client access. This allows you to use IAG 2007 as your centralized remote access gateway, without having to split the management and monitoring of remote access connections to your network between several devices or types of devices.

The next version of the IAG, known as the Unified Access Gateway, will continue to build on the strong application layer intelligence included with IAG and will add more secure remote access options. The most interesting of these is support for Microsoft’s new Direct Access remote connectivity option, which will enable users located anywhere in the world to transparently connect to the corporate network, including domain connectivity.

The major barrier to success for Direct Access is its dependency on IPv6. While there are advantages to IPv6, most networks are not architected to support IPv6 because there isn’t a strong business case to switch over to IPv6. In addition, there isn’t widespread understanding of IPv6, which makes it dangerous to implement on networks as it generates traffic that the majority of network administrators do not understand.

In order to mitigate the connectivity and security challenges introduced with Direct Access and IPv6, the UAG will employ NAT-PT (Network Address Translation – Protocol Translation). NAT-PT allow native IPv6 hosts and applications to communicate with native IPv4 hosts and applications and vice versa. This feature will make it much simpler, and more secure, to implement a Direct Access solution for tomorrows Windows 7 and Windows Server 2008 R2 networks.

Summary

In this article we covered the secure remote access options currently available to Microsoft networks. Some of these options have been available since early versions of Windows NT, while some would not be available until you’ve implemented Windows 7 and Windows Server 2008 R2. Each of them has its own advantages and disadvantages, and each of them provides a different level of security, for different types of remote access. Hopefully, after reading this article, you will have a better idea of the remote access options available to you and will be able to choose the one that looks like it will serve your needs best, so that you can then search for more information for that (those) solutions.

Remote Authentication: Different Types and Uses

Computer networks have arguably helped worker efficiency and helped a company’s bottom line. Well with that has come the need for workers to, at times, remotely log into the corporate network. This is ideally done via secure means. Within the confines of this article we will look at several of these methods.

Remote authentication

Corporate networks have not only grown in size over the years, but they have also grown in complexity. Over the years new services have appeared and been implemented to satisfy the growing demand for easy to use programs. This driving force to meet end user satisfaction goes on relentlessly and has accounted for much of today’s innovations. One of the most desired advantages has been for some workers to have the ability to work from home. These tele-commuters are one of the recent changes that have affected the work force and much to the benefit of the worker. This ability to tele-commute has greatly affected employee morale for the better. The problem is that these workers must also be able to communicate with the corporate network both remotely and securely. It is of little surprise that these concerns have been dealt with via a variety of solutions that all work quite well.

RADIUS is not just for Algebra

One of the solutions that was designed to accommodate the remote worker is that of RADIUS. Remote Authentication Dial-In User Service is what the acronym actually stands for. It is actually fairly descriptive as that is pretty much what it is used for. The worker will remotely authenticate for access to that remote network. I have previously mentioned that I like to map protocols before to the OSI Reference Model. This helps one visualize just what protocols belong where in the grand scheme of things. In the OSI model RADIUS fits into the application layer. This protocol is no exception either to the client/server model. A client will log into the RADIUS server and supply the required credentials. Also RADIUS uses UDP as a transport protocol to ferry about its information.

Like many well known protocols RADIUS has some well known ports that it is normally configured to be listening on. They are port 1812 and port 1813 with port 1813 being used for RADIUS accounting. Those ports are also RFC compliant, but what does RFC compliant actually mean? Well when the designers of RADIUS were sitting around talking about the design specifications for RADIUS they decided that they would make RADIUS use ports 1812 and 1813. The various design considerations were eventually all consolidated into what is called an RFC. After a period of time that RFC was accepted and thusly the ports of 1812 and 1813 were then called RFC compliant, as they were included in the original design of it.

I want details!

The devil is always in the details, and if you want details it is always best to go to the definitive source. In our case that would be RFC 2138 which deals with RADIUS itself and contains all of the details about it. Seen as most people break out into hives if they think of reading an RFC I will summarize a few important details for you. One of the biggest things to realize about RADIUS is that it will support various authentication methods. Notably, you can use PPP, PAP, and CHAP to name most of them. If you are familiar with Cisco gear or are in charge of supporting the routers and switches from them, then you are no doubt familiar with the various authentication methods offered by RADIUS.

Now once a user has supplied the required username and password combination and the RADIUS server receives it, it will do one of a couple of things. The RADIUS server will check its database for the received credentials and based on that, either reject the session or allow it. Further to the username and password combination, the RADIUS server can also check for validity by the port number. Typically RADIUS works as follows;

• Access-Request: where the user sends their credentials to the server
• Acess-Challenge: where the server sends a challenge and the user must respond

Based on the above access control the user is either authenticated or rejected. RADIUS itself, as mentioned earlier, uses UDP as its transport protocol, and that was decided during the initial design considerations for RADIUS. Using UDP has its advantages, notably there being less overhead and speed. This and other reasons was the driving force behind the choice of this transport protocol over TCP and its connection oriented design. Lastly, we should also realize that, like many application layer protocols, RADIUS has codes that were written into its core functionality. These codes deal with the access, accounting and status of RADIUS be it client or server. For further reading on this protocol I would suggest reading the above noted hyperlink for RFC 2138.

TACACS and TACACS+

Terminal Access Controller Access Control System or TACACS is similar to RADIUS and is used to regulate access to the network. One of the biggest differences between TACACS and RADIUS is that TACACS primarily uses TCP for its transport protocol needs vice the UDP that RADIUS will use. There are also three versions of TACACS with TACACS+ being the most recent. It is important to note that TACACS+ is not backwards compatible with the other earlier versions. This protocol is also an application layer protocol and observes the client/server model. Seen as TACACS+ is also a well known protocol it stands to reason that there is also a well known port associated with this activity, which is TCP port 49. That being said XTACACS does use UDP. There is always the exception to the rule!

Other notable differences between RADIUS and TACACS+ are that RADIUS only encrypts the password in the access request packet that is sent to the RADIUS server. TACACS+ on the other hand will encrypt the entire packet body, but will leave the TACACS+ header intact. TACACS+ does have weaknesses though, which can be exploited by a determined attacker. It is vulnerable to “birthday attacks” in which two messages use the same hash function and packet sniffing to mention a few.

Wrap-up

While the above noted are two means of using authentication methods, they are not the only ones. Every network has its quirks and various architectures. With that said you would be best to take into account the various details of your network and from there make the best decision regarding what authentication method best suits your needs. Some of these methods can also in turn use other ones as well, such as TACACS+ and Kerberos. The bottom line is that every time you involve another layer or program to your network you are introducing another possible attack vector. You would be well advised to go with a mature technology for your remote authentication solution.

Lastly, it also makes sense that before purchasing such a means, that you make sure you can integrate it seamlessly into your existing production environment. While this article was very much a high level overview of some of the methods, there is a veritable mass of information available on this courtesy of the Internet and Google.

Encryption Key Management

This article is about Encryption key management, and will highlight what needs to be done to effectively store the keys to your encrypted data. Information in this article will prove useful and in many instances you may find that only after reading this article it will become apparent that encryption and key management needs to be well managed, to avoid catastrophe.

Encryption, a brief background

Man has always wanted to communicate with a trusted party in a confidential manner. In times of war the encryption used to transmit and store information was vital to winning the war. Today organizations are connected to the internet, using the internet as a medium the organization can communicate and transact with clients, suppliers and its own employees. Keeping the transactions confidential and the stored data confidential is a challenge, and many organizations have started to employ strong technical controls like device encryption and content (data) encryption to better secure their data and communications.

Encryption by virtue is a way of keeping data confidential and unreadable by unauthorized users. Typically a cipher is used; the cipher can be described as a lock, together with a key to process or Encrypt - lock and Decrypt - unlock the data. What was readable data, once processed, now becomes unreadable without the correct cipher and most importantly the key.

But why is the key so important? Well let’s look at this question logically. You have a safe. In the safe you have valuables. You need a key to get into the safe. If you lose the key to the safe it will take too long to get to your valuables. In turn this will cause a denial of service, meaning you will be denied access to your valuables. Now we have a few questions to ask ourselves. Where do we keep the key? Would it be a good idea to keep the key on top of the safe? If an intruder were to get into the location where the safe is, then he would most likely search for the key then gain access to the valuables. Even keeping the key in the same room as the safe is potentially a problem, as this could result in an unauthorized person locating the key.

It is clear that keys are fundamental to opening locks; similarly encryption keys are used to decrypt encrypted data and communication. It is clear that if the keys were found and copied, destroyed or lost, you would have a problem gaining access to whatever the keys were protecting. Ever lost the keys to your car? Not a good feeling… If you have a spare set, then you can find those and use them, but you are left wondering about who found the keys and what they might do with the keys.

Types of keys

Below are some different types of keys as described by NIST in the Key lifecycle documentation available:

Key Management Lifecycle

• Signing Keys
• Transport Private Keys
• Public Keys Used to Verify
• Static Key Agreement Private Keys
• Digital Signatures
• Static Key Agreement Public Keys
• Secret Authentication Keys
• Domain Parameters
• Public Authorization Keys
• Initialization Vectors
• Long term Data Encrypting Keys
• Shared Secrets
• Encrypted Keys
• Seeds
• Master Keys Used to Derive

So what is the solution?

It is very important to treat keys with the same, if not higher, regard to what the keys protect. If the encryption key protects your laptop and the prime is lost, it can result in you losing access to all the data on your laptop. Then it may be a good idea to have proper key management.

Key management

Good key management entails 10 simple yet necessary steps which will ensure that you will be able to gain access to your data or communications in a secure manner when you need it. Reference:

Generally Should Archive

• Signature verification key,
• Secret authentication key,
• Public authentication key,
• Long term data encryption,
• Key encrypting key used,
• Key for key wrapping
• Domain parameters

Should Not Archive

• Signing key,
• Private authentication key,
• Short term data encryption key,
• RNG key,
• Key transport public key,
• Ephemeral key agreement,
• Private keys,
• Secret authorization key,
• Private authorization key,
• Public authorization key,
• Intermediate results and key material.

1. Make a backup of your encryption keys. If the encryption keys change, ensure that the changes are also backed up. This includes the restorability of the keys that are used for your archived data. If ever you need to restore the data you will need to decrypt the data. Countless organizations fall victim to this because of poor key management.
   
2. Ensure that the backups are recoverable and an effective disaster recovery plan that details the recovery of the keys from backup is in place. If historical data has been encrypted then this data should also be recovered and decrypted as part of your test.
   Note:
   As discussed in this article, storing the decryption keys with the encrypted data is bad practice, for this reason the keys should not be stored on the tapes that contain the encrypted achieved data.
   
3. Make sure that the logical access control to your encryption keys is secure and available to authorized users. Logical access to keys plays a vital role in keeping your data encrypted. Storing encryption keys on your local drives can lead to compromise, especially if the computer or device is partially encrypted. Typically keys are stored securely out of reach in a secure location.
   
4. Ensure that the keys are stored in a physically secure environment and that only authorized users can gain access to the keys. Physical access controls are of high importance as disruption in the key availability may result in failure in the decryption process.
   
5. Escrow the keys with a trusted third party, although you may feel that this is not a necessary step when things go wrong, I can assure you, you will wish you had escrowed the keys. Typically keys are escrowed and kept safely for many organizations without incident.
   
6. Ensure that the keys are not stored logically where someone could make a duplicate or destroy the key. Logical access controls are not enough if an unauthorized user can alter the state of the machine that the keys are stored on remotely or physically you will have a denial of service on your hands, resulting in the data not being able to be decrypted.
   
7. Ensure that you have a way of disposing the keys, locking out older, possibly compromised keys and creating new keys that will decrypt the data. This process needs to be carefully managed and security needs to be monitored throughout. It is common that through the key issue and revocation process a key compromise is structured by an unauthorized user.
   
8. Understand what data and communications has been encrypted by the keys so that if you have to issue a new key you are able to first decrypt and encrypt the data if your software does not perform this function automatically.
   
9. Ensure that the key is only used and issued from a secure system; often this rule is overlooked and will result in compromise. Not all computer systems are secure and as rootkits and software recording software become more pervasive caution needs to be taken when using the decryption key. Systems like the ones found at internet kiosks and other public facilities are good examples where more caution is needed.
   
10. Ensure that the key generation process has high security and that the process has integrity.

The above ten rules are guidelines that will aid an organization and individual in effectively managing keys to their most confidential information. On many occasions, decryption fails because of fundamental pitfalls made by key staff members that manage keys but lack the experience to make the right decisions.

Conclusion

Keeping an organization secure has many facets. In particular one of them is Encryption key management without the careful consideration of how the keys are managed. You may find yourself or your organization in a sticky situation. This article has taken you through a brief yet useful key management journey that will aid in keeping your organization and its encrypted data available and secure.

Security in the Cloud: Trustworthy Enough for Your Business?

Introduction

Everywhere you look today you see The Cloud. Microsoft, IBM, Amazon, Google, Adobe - everyone is rushing to come up with a comprehensive “Cloud Computing” service that will lure businesses. They make a good case for economics and convenience. But before you ditch your in-house IT department and put all your applications and data “out there somewhere,” you might want to carefully consider the security implications.

Are security concerns the primary obstacle to adoption of cloud computing?

At the April 2009 RSA conference in San Francisco, cloud security – or the lack thereof – was one of the most popular topics of discussion. Cisco CEO John Chambers called it a “security nightmare.” Even so, companies such as Microsoft, IBM, Google and Amazon are pushing their cloud solutions hard and the perceived savings – especially the indisputably lower startup costs – are looking very attractive to businesses struggling to lower IT expenditures in a tight economy.

However, reader responses to a recent set of articles I wrote on cloud computing for WXPnews and VistaNews indicate that security is a huge concern, and may very well be the biggest obstacle faced by those who advocate widespread adoption of the technology. Even as they consider the benefits of outsourcing all or part of their IT infrastructures to cloud service providers, many technical decision makers are worried about the loss of control that comes with having their mission critical applications and sensitive data residing “out there” rather than on their own servers.

One reason given by TDMs who are wary of the cloud is the argument that it is just an old idea with a new name. They remember all the hype surrounding Application Service Providers (ASPs) in the late 1990s and early 2000s. When the idea did not sell, it went away and came back a few years ago as SaaS, which also did not seem to stir up much enthusiasm – until it morphed into part of a bigger idea with a catchier name: cloud computing. This time, not only the name but the timing was right; the worldwide economic downturn had companies desperately seeking ways to cut their budgets. What better way to do that than to slash personnel costs by getting rid of all or most of the IT department and slash capital expenditures by doing away with most of the high dollar hardware and expensive server software to which those folks devote their time? As with the income and payroll taxes that are withheld from your paycheck, you do not really notice the cost of something that you never see.

Nonetheless, there are a number of reasons that many companies do not yet trust cloud computing. One problem is that “The Cloud” covers such a broad range of technologies – web-based storage, online applications, virtualization and so forth. Cloud services are often divided into three categories: Software as a Service (SaaS), Platform as a Service (PaaS) and Infrastructure as a Service (IaaS). Regardless of category, all cloud services have a common element: dependency on the Internet or in the case of internal/private clouds, at least on the LAN or corporate WAN. Without a network, the cloud is not possible. That brings up reliability issues in addition to the security concerns.

Cloud computing security concerns

The transparency of the cloud is one of its biggest attractions to companies, but is also the source of their mistrust. The whole point is that the company can focus on its business and leave the IT to someone else. The goal is a seamless experience whereby you do not need to know how it all works under the hood. But if you do not know how it works, how do you know whether it’s secure?

The biggest security concerns of companies regarding the cloud seem to boil down to one key factor: lack of control. You may not even know where your data is physically stored, and you do not know what security mechanisms are in place there to protect it. Is the data encrypted as it resides on the disk? And if so, what encryption method is used? Does it travel between your LAN and its destination in the cloud over an encrypted connection? How are encryption keys managed? Exactly who, besides you, has access to your information?

The traditional enterprise security model depends heavily on guarding the perimeter – with firewalls and gateways. The cloud doesn’t really have a perimeter and some cloud providers’ terms of service agreements (such as the one for Amazon’s EC2 services) prohibit you from scanning for vulnerabilities.

According to the Gartner Group, some of the cloud security issues that companies are worried about include not only the location of the data and what encryption is used at various levels, but also what the provider’s protocol (response/recovery measures) would be if a security breach occurred, what type of investigative support could be expected, and whether the cloud provider’s security is sufficient to comply with industry and government regulations.

It is difficult enough to ensure that your information is secure on your own systems and network. Cloud advocates argue that putting the security of your data into the hands of experts – big names like IBM, Microsoft, Google and Amazon – provides better protection than hiring or training in-house security experts. However, big names are also big (and popular targets). And anyone who has ever tried to get through to a real, live human being in any large bureaucracy – much less one who cares about your problem and has the expertise to do something about it – knows that size does not always translate into the best service.

Another problem is that a big cloud makes for a big, attractive target for hackers and attackers. Most security experts acknowledge that an important reason Microsoft Windows is exploited more often than Linux or the Mac OS is because of its large market share: the hacker who goes after Windows will find far more systems to take down or break into. Likewise, a hacker who penetrates a major cloud provider’s systems will find a huge wealth of data to steal or organizations’ operations to disrupt.

Lack of standards poses a challenge

One of the biggest problems is that although each cloud provider implements measures to protect the data stored on its servers, there are currently no globally recognized standards for cloud security. Groups such as the Jericho Forum, a security think-tank, are working on developing a framework to help create such standards and to help companies determine which tasks can be safely entrusted to the cloud. Their recommendations hinge on a standardized, easy to use data classification model with associated standards for management trust levels and standardized metadata to signal what level of security should be applied to each data item.

The National Institute of Standards and Technology (NIST) and the International Organization for Standardisation (ISO) are also working on cloud data protection standards. However, the existence of multiple standards can in itself complicate things – although it is far better to know that your cloud provider complies with some set of standards than to be left wondering.

What’s the Solution?

Cloud computing is still in its infancy, but the good news is that – unlike, for instance, with the development of computer operating systems and applications – security implications are being considered and security mechanisms are being incorporated from the beginning. In March, companies including eBay, Intuit, DuPont and ING formed a group called the Cloud Security Alliance, with the purpose of promoting best security practices in the cloud environment. Their white paper, Security Guidance for Critical Areas of Focus in Cloud Computing, provides a good overview of cloud computing models and their characteristics, and looks at cloud services from the perspective of governance and risk management, legal issues, electronic discovery, compliance and audit, business continuity and disaster recovery, application security, encryption and key management, identity and access management, storage, and virtualization, among others.

At the same time, a group of tech companies that includes IBM, AT&T, Cisco, Sun, EMC and AMD have signed a document called the Open Cloud Manifesto that supports keeping cloud computing services as “open” as possible. This would mean greater interoperability between providers. The document addresses security in a single paragraph that acknowledges the discomfort of many organizations with storing their data and applications on systems they do not control and states in part that “Consistency around authentication, identity management, compliance and access technologies will become increasingly important.”

As security standards are developed, adopted and come to be expected by customers, many of the security concerns surrounding cloud computing will be ameliorated. In the meantime, companies should not necessarily hold off on using cloud services, but they should carefully analyze their cloud adoption strategies and take nothing for granted. Ask hard questions of service providers, and be judicious in choosing which tasks to relegate to the cloud and which to keep onsite and under your own control. Perhaps the most important takeaway from the discussion – and one that has been overlooked in many discussions of this topic – is that the cloud is not an “all or nothing” decision. It makes perfect sense to use cloud services for some tasks but not others. Smart cloud providers will recognize this and offer their services in a “cafeteria menu” that allows you to use the cloud for less security sensitive applications and data and migrate other tasks and data to the cloud later, if at all.