I D C T E C H N O L O G Y S P O T L I G H T T h e E m e r g ence of the C loud Perimeter April 2015 Adapted from Cloud Security Gateways: The New Security Pipeline by Pete Lindstrom, IDC #WC20141030 Sponsored by Soha Systems Enterprise IT architectures have evolved dramatically from the days of on-premises monolithic and simple client/server architectures with centralized resources. These architectures, once easily protected by firewalls and other "layered" security solutions, have been replaced by highly distributed service-oriented architectures with components deployed in hybrid environments that include public and private clouds. This Technology Spotlight describes how the stresses of today's decentralized architectures require a new model that incorporates a cloud perimeter. Soha Systems, a new player in cybersecurity, has built a solution that delivers a match to the cloud perimeter model today. The Evolution of Technology Architectures When monolithic mainframes gave way to two- and three-tier client/server architectures, IT architectures began their journey toward the n-tier, n-peer highly distributed architectures that they are today. These abstracted, service-oriented frameworks provide much-needed flexibility and resilience, but the need for standardized communications and exposed application programming interfaces to support these benefits comes at a security cost. Attackers may also be able to subvert an expected application flow by probing these new attack points. The cloud crystallizes the nature of this problem, as IT architectures seek out their "manifest destiny" and expand the perimeter of enterprise applications to incorporate what is essentially the entire Internet. In addition, the dynamic capabilities of programming frameworks, virtualization, mashup architectures, and other technology separate users, data, and workloads from their "homes" on previously static networks and servers. How Security Evolves with IT IT has always been heavily reliant on network-based security solutions such as firewalls forming a secure perimeter around resources to keep information safe. This approach makes sense in a static, centralized IT environment. But today's enterprise computing is different, with users, applications, and information now dispersed across a heterogeneous architecture that incorporates traditional enterprise computing, mobile devices, and the cloud. Users may authenticate and then federate their access from local devices to distributed components; data is replicated, shared, and copied as it moves from structured to unstructured forms; and containerized and componentized workloads migrate and multiply to leverage the most efficient and effective available resources. IDC 1893
The Defense-in-Depth Security Model Defense in depth (DiD) is a well-regarded security strategy for technology risk management professionals. The metaphor typically used to describe it is the medieval castle, with multiple layers of security surrounding the key assets or resources that must be protected. The information security field has essentially extended the metaphor to include adding layer after layer of defense around some set of resources. The goal of DiD is to protect a set of resources from all sorts of attacks and compromises. The steps include: Collect all resources into a central location Create a perimeter around the resources Apply security controls in layers to protect all of the resources in the collection With today's distributed architectures, the application of DiD is challenged simply because there are no aggregated resources around which to "circle the wagons." While the underlying concept of applying various protection methods is sound, their application in layers must give way to more purpose-built capabilities. In the same way that warfare (and the more mundane notion of simple protection) has evolved with the onset of new tactics and capabilities, security models must evolve to meet the needs of new architectures and new threats. Challenges of DiD The British never saw the Americans coming in 1775. What was once a battleground with accepted practices of frontal assaults mowing down the opposition gave way to hit-and-run tactics during troop movements. In some respects, DiD is experiencing the same pain of recognizing that the (relatively) ordered set of assumptions around how security controls are applied layer by layer to protect resources is outdated: Resources are not in collections anymore. Today's distributed architectures, as described, have components strewn around the Internet. Even when applications are collocated and controlled, there are many other applications in other places. Components are becoming more distributed. The clear lesson from the past 30 years of computing is that decoupling or otherwise breaking up pieces of an application architecture provides flexible new capabilities. There is no reason to believe this won't continue for the foreseeable future. Risk levels may be different among assets and resources. Even if aggregation were possible, enterprises would be collecting sets of resources with varying levels of risk. While this approach would seem cost effective, the collected traffic and activity may introduce levels of noise that allow attacks to succeed. Zones of trust are extremely challenging to maintain. With varied levels of risk, the ability to create and maintain many trusted zones is reduced significantly. There is no "inside" or "outside." While the typical perimeter revolves around the concept of inside the perimeter as a trusted zone and outside the perimeter as an untrusted zone, the new architectures diminish that notion. Rapid evolution. Resources are not physical but virtual and, in many cases, software defined. Physical constraints that limited how fast an infrastructure could evolve no longer apply. 2 2015 IDC
Protecting the "Last Mile" to Users and to Enterprise Applications As cloud architectures evolve to incorporate what were traditionally private datacenter resources, enterprises must consider how protection models change. As we've seen, users are logically migrating further away from enterprise applications in their mobile environment, and now private resources are also migrating away from the notional datacenter protected by the perimeter. The net effect is that there are more "hops" along the network path from user to application that may be intercepted or rerouted. There is less control over the network; so, for example, protecting resources through network isolation (perimeter firewall) becomes incredibly difficult if not impossible, and what's more, users are now on the wrong side of the perimeter that is, one of the benefits to firewalls was to open up ports and services for users inside the trusted zone that were made unavailable on the outside. Now, that paradigm has changed. The last mile on either side of a session may actually be a control point that must be traversed to get from user to application. One way to conceptualize this model is as a cloud perimeter. Objectives of the Cloud Perimeter The cloud perimeter operates somewhat like a traditional perimeter by separating traffic and resources from two sides but also slightly differently in that there are no bounds around the multiple "sides" that may take part in the interaction. It operates more simply as a transfer point or security enclave that manages all security throughout the environment and in any location. More specifically, the cloud perimeter has the following objectives: Connection termination point. The perimeter is the perfect place to terminate connections that originate in a potentially untrusted zone and connect with another potentially untrusted zone. This protection reduces the opportunity for bypass or other attack against a single session. Controlled set of management resources. With the minimal number of resources necessary to configure and otherwise manage, this last bastion environment protects the resources that are the highest risk because other security controls are built on top of them. Highly secure components. The bastion of hope needs to be protected as a bastion host, so each individual component must be given a high level of focus to ensure that it is as protected as possible. Strong communications security. The authenticity and integrity of inbound and outbound traffic must be guaranteed to the highest possible level. Single point of management. The intention of this simplified management scheme is to create a standardized, highly secure environment from which to provide management of all the controls deployed in the cloud and eventually incorporate all controls everywhere. Rapid deployment. The fluid deployment of resources, the locations of resources, and the connections between resources must be matched by the solution that secures them. 2015 IDC 3
The Soha Systems Approach to the Cloud Perimeter Soha Systems is a new player in the burgeoning area of cloud security. Its approach mirrors the cloud perimeter model well, as it provides "cloudlets" to deploy at or near the enterprise resources that connect back to the Soha Cloud environment. Thus, the solution creates two separate connections that meet inside its perimeter. This architecture provides maximum, centralized control to an organization's administrators. Soha recognizes that organizations are building out multiple cloud environments, sometimes on the order of dozens or hundreds, and they all need to be managed. Its goal is to provide the best user experience in a cost-effective, lower-risk environment. Soha claims to provide multiple forms of controls around its central resources to create the highly secure environment necessary for command and control over the cloud. One useful aspect of the Soha architecture is the use of cloudlets alongside enterprise resources. Rather than providing "always on" listening services, the cloudlets are programmed to only make connections back to the Soha Cloud. The purpose of the Soha Cloud service, like that of cloud infrastructure itself, is quick deployment without the complexities of integrating appliances or changing network configuration. Thus, groups within an organization turning to the cloud for quick access to computing resources don't need to make tough trade-offs between security and agility. Challenges The architecture of the cloud perimeter is new and relies heavily on innovators that are willing to stake a claim to a new security model. The same is true for Soha. Cloud-adopting organizations challenged to deploy a traditional DiD model of security will more likely find this alternative compelling than traditional enterprises that will need some time to adjust. In addition, the need for a secure environment is paramount. Soha's cloud must be protected at all costs. Even though there is no way to guarantee security, Soha will need to show that the measures it takes to secure its infrastructure meet the requirements of its customers. To this end, Soha must be transparent with respect to third-party security validations, and the company is pursuing several industry security certifications. Conclusion Enterprises are at an inflection point with their approach to securing future IT architectures. The cloud perimeter is a new model that can address the shortcomings of the existing DiD model. As enterprises turn more to distributed, cloud-oriented architectures, they will need to adjust to the extent and level of complexity associated with traditional security models. Soha Systems provides a solution that matches well with the cloud perimeter model and addresses the needs of organizations moving quickly into the cloud. If the company addresses the challenges described in this paper and executes well on its strategy, it will be poised for success in the cloud security market. A B O U T T H I S P U B L I C A T I ON This publication was produced by IDC Custom Solutions. The opinion, analysis, and research results presented herein are drawn from more detailed research and analysis independently conducted and published by IDC, unless specific vendor sponsorship is noted. IDC Custom Solutions makes IDC content available in a wide range of formats for distribution by various companies. A license to distribute IDC content does not imply endorsement of or opinion about the licensee. 4 2015 IDC
C O P Y R I G H T A N D R E S T R I C T I O N S Any IDC information or reference to IDC that is to be used in advertising, press releases, or promotional materials requires prior written approval from IDC. For permission requests, contact the IDC Custom Solutions information line at 508-988-7610 or gms@idc.com. Translation and/or localization of this document require an additional license from IDC. For more information on IDC, visit www.idc.com. For more information on IDC Custom Solutions, visit http://www.idc.com/prodserv/custom_solutions/index.jsp. Global Headquarters: 5 Speen Street Framingham, MA 01701 USA P.508.872.8200 F.508.935.4015 www.idc.com 2015 IDC 5