Responsiveness to the ever-growing demand coming from the business is redefining IT processes and technologies. One way IT can improve responsiveness and business agility is by moving business applications to the cloud. In the cloud, businesses increase their agility while reducing costs. But in the process of migrating applications to the cloud, network security is often neglected. When this happens, applications are deployed in the cloud with inadequate security and compliance measures, or, conversely, the security team steps in and halts the migration process.
This puts the company at risk. On the one hand, inadequate security makes it easier for hackers to access the network and mount an attack against the company – exposing the company to financial losses and legal repercussions. On the other hand, if the business is unable to respond to market demands in a timely fashion, there are clear financial implications.
In this paper, we take a deep dive into the process that enterprise organizations take when approaching a migration project. We look at the challenges associated with migration projects and discuss a systematic process that organizations should embrace when approaching these types of projects.
There are multiple advantages to adopting a cloud architecture and migrating applications to it, but there are also security concerns that need to be taken into consideration. Below are the top four advantages and the security challenge that accompanies each.
When adopting public cloud computing, data itself is much more accessible, no matter where it is located. Users can access the data they need from any location and device. An additional benefit relates to disaster recovery processes that include out-of-the-box backup and restore functionality. In the cloud, there is a need to maintain additional servers in a remote location. However, these advantages do not come without a cost. Once the data is no longer kept on-premises, security must be tightened. The closed garden we had when data resided on servers protected by firewalls in our facilities, is gone. Additional security controls must be employed. Special consideration should be given to upholding regulatory requirements regarding the data itself. There are best practices to uphold, as well as financial penalties if organizations do not comply with them.
Spinning up a server in the cloud is a matter of minutes. Cloud computing is considered an enabler for digital transformation, as businesses work to be more agile and accommodating to their customers’ needs. All you need is a credit card. No hardware is required to be purchased, shipped or connected to your data center. The ease of spinning up a new cloud server makes shadow IT possible. But this is also a security problem. It is hard to control the security aspect of each cloud server if you are unaware of it. Therefore, visibility and strong prefrail security measures such as identity management and cloud firewalls that protect access from the internet, are needed. For each cloud server, you need to set an allowed connectivity baseline and incorporate it into the sever creation process.
The cloud offers zero maintenance costs and zero capital costs. Additional financial gains should be taken into consideration such as the reduction in IT support costs and the flexibility offered by cloud server usage of paying only for what you consume. This means you don’t have to purchase expensive hardware needed during peak times only. Of course, there are also hidden costs when migrating to the cloud. Usage needs to be monitored and optimized and your cloud assets need to be monitored and maintained. Additional security measures need to be put in place. This includes purchasing additional software as well as hiring additional personnel proficient in securing a cloud architecture.
The cloud, coupled with DevOps practices and tools, delivers a flexible framework that enables companies to deliver innovations faster to market. However, there are lingering questions about the impact on security. With multiple functional teams collaborating on development, and so many moving parts in the process, security is often not incorporated into the release process. Rather it’s tacked on at the end.
And this is where you need a security policy automation that supports the DevOps methodology. The solution needs to be able to automatically copy the firewall rules and then make the necessary modifications to map rules to the new objects – for each new environment in the DevOps lifecycle. With the right automation solution, security can be baked into the release process.
Public cloud security is the responsibility of both the cloud vendor and cloud customers. This joint ownership of security is often called the shared responsibility model.
On one side you have security of the cloud infrastructure itself.
The cloud vendor is responsible for securing the infrastructure that runs all the services offered in the cloud. This includes both software-related services such as compute, storage, database, and networking as well as hardware services. The cloud vendor is also responsible for securing the physical facilities themselves.
On the other side, you have security within the cloud accounts.
Cloud customers are responsible for the security of the services they consume. For example, when using Amazon Elastic Compute Cloud (Amazon EC2) the customer needs to perform all the necessary security configuration and management tasks. Any software or utility that the customer installs should be followed by configuring all relevant security controls, including security groups, third-party firewalls and other necessary security configurations. Cloud customers are responsible for managing and securing the data that resides in the consumed cloud service.
Figure 1: Shared responsibility model
Data center network security is already quite complex. Customers generally utilize multiple vendors to manage their network security, including SDNs, such as Cisco ACI and VMWare NSX. Adding cloud network security controls to the mix raises the complexity up several notches.
Cloud network security consists of multi-layered security controls. You have the cloud vendor infrastructure controls spanning across asset types, such as instances, databases, storage, and accounts; and across configuration types, such as deployment location, security groups, and more. You also have cloud providers’ security products, such as Azure Firewall and AWS WAF. And on top all of that, third-party vendors have not left the cloud network security controls ring and are providing dedicated firewalls for the cloud, such as CloudGuard by Check Point, V-Series by Palo Alto Networks and more.
When migrating an application to the cloud it is important to determine how you are going to guard your cloud assets. What mix of security controls are you going to utilize to secure your data?
Obtaining an inventory of applications is the foundation of your security and essential for your cloud migration. The process of discovering all the applications used by your business is not a trivial task. Most businesses have two types of applications – enterprise and departmental.
Enterprise applications, which are the more complex applications in your data center, usually serve many business units and can span multiple geographies and even company subsidiaries. In most cases, the IT team is well-aware of them. While documentation of these applications and their connectivity requirements may not be perfect, that is a good starting point for the migration process. Note that there may still be a need to update the documentation.
Many departments or business units purchase their department applications such as Business Intelligence solutions or project management tools. Some of these applications may be SaaS while others are installed on corporate servers. For these types of applications, it is likely that documentation never existed. Fortunately, in most cases, their architecture isn’t complex. It should be relatively easy to obtain the necessary connectivity information needed to migrate them to the cloud. The key here is to know that these applications exist.
There are two ways to generate a list of applications. The first requires using consultants to conduct thorough interviews with the various stakeholders in each department and each geography. A second, more cost-effective and efficient way, is to use visibility and automation solutions such as AlgoSec’s AppViz and AppChange. Tools like AlgoSec’s AppViz help discover, identify, and map business applications on your network.
Once the list of applications – the foundation – is in place, you can move onto the next stage in the process of closing the security gap as you migrate to the cloud: understanding each application’s attributes, such as the number of servers, the associated business processes and the network connectivity requirements. These attributes help determine the complexity involved in migrating applications.
Several attributes can affect the complexity of migrating an application to the cloud, including the application’s network connectivity requirements and the firewall rules that allow/deny that connectivity. A mapping of the network connectivity yields a deeper understanding of network traffic complexity which, in turn, provides insight into the flows you will need to migrate and maintain with the application in the cloud (see Figure 2). Additionally, this information will tell you how many applications are dependent on a specific server. The more applications a server serves, the harder it is to migrate one of them. It may be necessary to migrate the server itself or to migrate multiple applications at the same time.
Mapping the firewall rules provides insight into the security measures you will need to put in place once the application has been migrated to the cloud. As a rule of thumb, the more firewall rules are required, the greater the complexity. A mapping of the firewall rules enables you to identify and decommission firewall rules that are no longer necessary post-migration.
How do you generate documentation of application connectivity? The obvious choice is to employ a solution that automatically maps the various network traffic flows, servers and firewall rules for each application. If you do not have access to such an automation solution, then manual documenting, however tedious, will provide the necessary information.
When an application holds sensitive data such as personal information it is worth thinking twice before moving it to the cloud. In most cases, data privacy laws mandate where personal data should be stored, and when the information can be collected, processed, or communicated. Over 80 countries and territories have adopted comprehensive data protection laws. Most of Europe has already adopted comprehensive data protection laws such as GDPR. Many Latin American, Asian, and African countries have done so as well. Many US states also have data protection regulations such as the California Consumer Privacy Act and the New York SHIELD Act. It is worthwhile checking what is legally allowed before moving such an application to a cloud, as well as considering the cloud’s geographical location.
An additional issue to look out for is whether the application is subject to regulatory requirements such as HIPPA or requires PCI DSS compliance. If the answer is yes, you must find out the security compliance status of that application and whether moving it to the cloud would violate that status. HIPPA, for example, requires accountability practices on all LANs, WANs, and for users accessing the network remotely through a Virtual Private Network (VPN). PCI compliance requires, for example, a firewall at each internet connection and between any DMZ and the internal network zone. Applications subject to these and similar regulations are not the best candidates, to say the least, for migration to the cloud.
On the other hand, if an application has elements that are already exposed to the internet, such as the web server in Figure 2 below, that’s a good indication that maybe some of it, if not all, can be moved to the cloud for the elasticity and cost savings gain. For these applications, you have most probably already implemented strong security inside the application server, backed with strong security limitations in front of and behind the web-facing interface. Adopting these strong limitations also when moving the workload to the cloud will ensure the security of the server and of the internal network behind it.
Finally, if you manage your network segmentation correctly, the servers and applications that reside in the less isolated zones are the best candidates for moving to the more open cloud. For example, applications and servers in a zone with only one firewall that acts as a barrier between the zone and the internet are good candidates for migration. Whereas entities in protected zones such as server group 1 in Figure 2, which reside behind several firewalls, should remain in your on-premise data center.
Figure 2: Network segmentation
Whether you move all your applications to the cloud or just a few of them, and whether you use one or multiple cloud vendors, you now need to manage and maintain security and compliance in the cloud just as you did in your on-premise network over which you have complete control. Establishing a route from a server in the cloud to a server on the on-premise network requires an intimate understanding of both the cloud security controls and the on-premise security devices. If there are separate cloud and on-premise network security teams, as is the norm in many businesses, collaboration between the teams is needed which, of course, adds its own complexity. Once applications are deployed in the cloud, you will likely want to be able to move between cloud providers ‘at the speed of the cloud’ to avoid vendor lock-in and to minimize costs. While you might be led to believe that this is a simple requirement, in reality each cloud provider has its own unique network security controls with which you need to familiarize yourself. There are several ways to manage security across the hybrid cloud environment.
The AlgoSec Security Management Suite (ASMS) makes it easy to support your cloud migration journey, ensuring that migration does not block critical business services while meeting compliance requirements.
AlgoSec’s powerful AutoDiscovery capabilities help you understand the network flows in your organization. You can automatically connect the recognized traffic flows to the business applications that use them. AlgoSec seamlessly manages the network security policy across your entire hybrid network estate. AlgoSec proactively checks every proposed firewall rule change request against your network security strategy to ensure that the change doesn’t introduce risk or violate compliance requirements.
AlgoSec enables the world’s largest organizations to align business and security strategies and manage their network security based on what matters most – the applications that power their businesses. Through a single pane of glass, the AlgoSec Security Management Solution provides holistic, business-level visibility across the entire network security infrastructure, including business applications and their connectivity flows — in the cloud and across SDN and on-premise networks. With AlgoSec users can auto-discover and migrate application connectivity, proactively analyze risk from the business perspective, tie cyber-attacks to business processes and intelligently automate time-consuming security changes — all zero-touch and seamlessly orchestrated across any heterogeneous environment. Over 1,800 leading organizations, including 20 Fortune 50 companies, have relied on AlgoSec to drive business agility, security and compliance. AlgoSec has provided the industry’s only moneyback guarantee since 2005.