The advent of cloud computing and storage clouds has resulted in enterprises bending to the breaking point the concept of segregated “internal” and “external” networks. In security parlance the “external” network is viewed as a dangerous and untrustworthy place and treated with respect bordering on fear.
On the other hand the “internal” network has for the most part been treated as a safe place by IT departments. They may not trust their users but they generally trust their networks and give only marginal concern about how data moves between clients and servers. This basic concept, little changed since the 1990s, is rapidly reaching obsolescence in today’s hybrid cloud-centric world.
Network engineers have been dealing with this perimeter breakout at three network layers with varying levels of trust. The deepest level of trust has generally been at the network layer, usually by IP address. The transport layer has been used as a watchdog of the services to which services an IP address has access. Conversely, network engineers usually consider the application layer to be the least trusted layer for establishing identity.
The problem has been that it is generally difficult to establish trust at the network layer. To compensate, network engineers usually push security all the way up to the application layer to try to establish trust with the user rather than the device.
Sometimes they do it intentionally, by assuming applications will validate that the user is who they say they are. This they often do unintentionally though. For example most VPNs have been moved up into the application level layer due to their reliance on user names and passwords.
Yet with the advent of cloud computing, the line between what constitutes “inside” and “outside” has become so blurred that it has become more important than ever to re-establish the meaning of “trust,” especially at the network layer. To achieve this, it is becoming apparent that a new security mechanism should be added to existing network layer protocols, such as IP, to provide for a more resilient, manageable and scalable trust environment.
The solution is as elegant as it is simple. The addition of a unique cryptographic signature to the IP header would seem to be a vertically compatible yet powerful solution.
Examples of what this extension offers include:
- Traffic authentication. The mere existence of the extension imparts a new level of trust to each packet sent from a device. Other similarly enabled devices would be able to identify the unique device that sent the packet. Devices that do not recognize the header payload simply pass the packets without modifying this unique identification data.
- Ingress authentication. The aforementioned extension would add an additional layer of security by uniquely identifying each and every device. It would be key to facilitating rapidly growing environments or dealing with roaming devices where IP address changes frequently.
One application example would be an encrypted webmail application for a mobile sales force. Currently perimeter firewalls must pass this traffic to the network to be decrypted and identified by the application. Using this extension any packet that does not contain a recognizable key may be dropped immediately. This eliminates unwanted traffic without depending on deep packet inspection which should also contribute to increasing and remaining transport protocol neutral.
- Egress authentication. Egress packet analysis has been vastly underutilized up until this point. DCIG expects a renewed interest in egress packet analysis as public and hybrid cloud environments become more popular. These networks are often treated as separate physical networks. Using current techniques network engineers are still forced to move authentication up to the application layer by using a proxy server or relying on physical network segmentation.
By restricting access based on the proposed extension these issues can be eliminated. Each device is placed inside of an individual VLAN and policies put in place at the network layer that appropriately routes traffic while still allowing the application layer to handle user authentication.
- Policy-based routing. The new header payload should extend the reliability of policy-based outing. A prime example would be the establishment of quotas or quality of service (QoS) levels. Different policies can be instituted for authenticated and unauthenticated devices or hosts over the same network or for different classes of authenticated users.
For instance devices within the development or sales group could reliably be given a larger QoS ranking than other departments to individual cloud hosts without limitation of location whether on site or on the road.
As each of these examples shows the introduction of the new header payload into IP packets should non-disruptively provide more trust and reliability for networks in today’s cloud computing and cloud storage environments and increase the flexibility and scalability of network security even as it reduces the complexity of managing it. By combining the proposed extension with existing security techniques, DCIG expects a new wave of device based trust to enhance the security and performance of data stored in the cloud which should in turn accelerate the adoption of the cloud in enterprises.