Archive for April, 2011

Computerworld, iPads run amok: Does your company need a tablet policy?
PCWorld, New password encrypts like no other
USA Today, Visa exec: data thieves still hungry, active despite tighter security
ITBusinessNet, 5 Security Tips for Your Smartphone or Tablet
ITBusinessEdge, The Social Engineering Factor in Security Breaches

Last week’s post on Branch Networking focused on High Availability, so this week we’ll take a dive into central management. As a quick overview, a central VPN management system is required for effective networking of branch offices. Even if there are only a few branch offices, the time and money that have to be spent on local network administration is out of proportion, especially with M2M networking.

Central management automates the management of remote / branch office VPN gateways. So the more VPN relevant systems the central management contains, the simpler and more manageable the network becomes for administrators. Of course, management should include configuration and software updates – but it should also include managing of digital software or hardware certificate rollouts, an LDAP console for identity and rights management, and security monitoring of the end-devices (Network Access Control / Endpoint Security).

Example Authentication

We know a VPN system secures all data transfers in an encrypted tunnel. However, sealing this communication has to take place as early as Internet dial up, which is the most frequent point of vantage for hacker attacks. The core problem is how the branch offices authenticate towards the central gateway. One possibility for authentication are pre-shared keys, another is the use of certificates. For security reasons, certificates are the better option because they can be adapted. This means old certificates can be locked and new ones can be issued. Certificate handling has to be organized; i.e. if one certificate expires, the VPN management should offer automatisms that request and issue new certificates.

Often, there’s another security requirement is simply overlooked. The firewall must only allow IPsec connections. Usually branch offices connect to the Internet via a DSL router. This router protects the VPN gateway and some VPN gateways also support the communication medium PPPoE. This means, the gateway can directly be used for DSL dial-up and a DSL router becomes obsolete. In this case, too, the firewall must only allow IPsec connections. Maintenance of the branch offices’ VPN gateway can also be possible by direct dial up via ISDN – not via the Internet.

Do you have questions about Branch Networking? We’ll do our best to help if you send your questions to or leave us a comment below. Also, stay tuned for next week’s Branch Networking post about “masking.”

Financial Times, Human Resources Goes Technical
InfoSec Island, The Rise of Smartphones and Related Security Issues
NetworkWorld, Verizon study: Data Breaches Quintupled in 2010
eWeek, Oak Ridge National Laboratory Breached by Phishing Email, IE Exploit

We recently fielded a reader’s question on the difference between mesh and star-shaped networks. This gave us the idea to take a closer look into the challenges of site-to-site VPNs in a multi-part series. As a primer, site-to-site VPNs are used to connect independent networks, for example, for branch office networking. In most cases this means that the branch office networks are connected to the network of the company headquarters.

Another possibility is machine-to-machine (M2M) networking. In this case it is machines that communicate with the central gateway. In all cases VPN gateways are used. They establish a connection to the Internet, then they encode and authenticate the IP user data for transmission and tunnel it through the Internet. Most frequently, IPsec is the VPN protocol that is used for these types of connection.

In this series, we’ll discusses aspects of branch office networking that are frequently overlooked during planning or extending site-to-site VPNs – but are critical to a successful delivery.  But first, we’ll go over the two main types of networks that used for branch office networking – meshed or star-shaped networks.  With meshed networks, the branch offices are not only connected to the headquarters but also amongst each other. With star-shaped networks, however, all communication between the branch offices is channeled through one central VPN gateway. For more on the pros and cons of each network, we’ll nudge you to last week’s reader’s question.

Another criteria to consider with branch networking is high availability, which can differ depending on which branch offices are connected to the main network. This means high availability has to be guaranteed for branch offices which must not break down. Common examples are branch offices of banks and their ATM’s or checkout systems of retail chains. In order to guarantee high availability, professional VPN systems support several backup systems.

Monitoring the VPN connection is a basic requirement for being able to carry out backups. One method of connection monitoring is DPD (Dead Peer Detection- RFC). On top of that, the VPN gateway of the branch office should support several alternative media types (communication mediums) for Internet dial up.

The VPN solution should also be able to automatically recognize a communication fault with a remote side. If it does, the VPN gateway disconnects the standard connection automatically a sets up an alternative backup link. Most modern VPN software solutions support infinite backup connections. With these solutions, the restricting factor is the number of communication mediums the hardware supports.

We’ll leave it there for now, but next week we’ll look into the impact central management has on branch networking.

This year’s Las Vegas Interop marks the first time the InteropNet OpenFlow Lab will take a deeper look at the up-and-coming OpenFlow standard. For those who aren’t familiar, OpenFlow is “designed as an open interface for remotely controlling the forwarding tables in network switches, routers and access points to enable a switch from monolithic devices to controller based systems,” according to an Interop release.

The InteropNet OpenFlow Lab plans to educate attendees on OpenFlow and demo the technology in various scenarios. Given the prominent role OpenFlow will be playing at Interop this year, we asked Glenn Evans, InteropNet’s lead engineer about its security.

“The OpenFlow spec sees all traffic (control) between the control plane and the data plane being transmitted over TLS (transport level security),” he told VPN Haus. “All traffic on the data plane (host to host) is unencrypted similar to a normal network.”

Readers, if you’re going to Interop do you plan on seeing an OpenFlow demo? Do you have any questions for Glenn Evans?