Many network security technologies are available these days—from tried and true staples such as network firewalls to newer developments such as Intrusion Prevention Systems (IPSs) and the new anomaly detection and Data Loss Prevention (DLP) technologies. Web Application Firewalls (WAFs) and IPSs are gaining some ground as forces such as regulatory compliance drive end-to-end security requirements. enterprise acceptance for some of the other newcomer technologies varies, but it’s clear that network firewalls are here to stay. They remain among the most important core technologies in the network security arsenal, which makes it important to understand how, when, and where to deploy them in enterprise solutions encompassing the mainframe as a core component.
There are many good reasons for using firewall technology to protect resources and data, whether it’s a credit card number, Personally Identifiable Information (PII), or intellectual property. Regulations, such as the Payment Card Industry Data Security Standard (PCI DSS) Requirement 1, are pushing many of the requirements we’re seeing today. In an economy where every dollar spent is being scrutinized, if a regulation that carries a fine for non-compliance states there must be a firewall in a particular network flow, then that is non-negotiable and the expenditure is justified.
Consolidation of distributed workloads, on platforms large and small, remains a growing trend. The savings and benefits associated with enterprise consolidations on System z are attractive, but can’t occur at the expense of critical security requirements and the associated core technologies, such as firewalls, that are needed to secure these enterprise solutions. Candidate solutions for consolidation can include multiple security zones; at every transition from one security zone to another, there should be some type of firewall. Firewalls aren’t just the guardians of the Demilitarized Zone (DMZ).
Today’s enterprise solutions are far more complex than the simple DMZ of the past. A typical enterprise will most certainly have a perimeter firewall guarding all the solutions that might allow network traffic to flow to any number of subsequent applications or solutions. A common deployment might have a DMZ, with its pair of firewalls, surrounding a Web server for an added level of protection. That Web server, being the public face to customers, might then connect to an application server in a separate security zone, which might request credit card data or some other PII from a data server in yet another higher-level security zone. Each security zone will have its own requirement for a firewall with its own configuration settings and policy.
The firewall question continues to bubble to the foreground as consolidation efforts in the enterprise reach new levels. Where, when, how, and even if a firewall is needed are questions that must be answered. Do we even need a firewall in the physically secure confines of the mainframe? How much function, bells, and whistles do we really need in a firewall to ensure adequate security? Are software firewalls sufficient, or do we need a BrandX firewall appliance at every turn? These are a few of the questions that must be asked as we move workloads to any virtualized environment.
Some virtual environments are clear; they suggest you don’t run mixed security levels in the same virtual environment. System z with Logical Partition (LPAR) and z/VM take a different stance; they stand fully behind mixed security workloads in either of these hypervisors. We must ensure we don’t create vulnerabilities or provide a lower security solution as we consolidate or move critical applications to virtualized environments. However, we must make sure the same network security tools deployed in the distributed environment are still valid or required as virtualized environments embrace new consolidated workloads.
When is enough really enough? There’s a time and a place for all things. Focusing on what we’re trying to accomplish and the environment we’re in can help us make the right decisions. There are scenarios when a full-fledged, top-of-the-line, highly available firewall with the highest speed connections imaginable, including all the bells and whistles, is what’s needed. But there also are times when part of a consolidated solution might be in a highly controlled, physically secure environment, where all the processes are well-known, well-behaved, and far from the reaches of any rogue application or malicious user. There, a simple, lightweight, open source firewall running in an isolated virtual Linux guest might be all that’s needed.
In the purely distributed world, it’s easy to visualize placing firewalls and picturing the DMZ or various security zones in a more complex, end-to-end solution. They appear as separate, colorful boxes on a chart or in a picture, as we see in Figure 1, each box having a nice tidy, one-to-one mapping to a physical box in the real (meaning non-virtual) world. Arrows are drawn to depict network flows and represent physical wires. As we explore the benefits and savings of virtualized environments, these nice, tidy mappings no longer point to physical, individually tangible hardware. Instead, they’re replaced with a new set of challenges, benefits, and decisions in the virtual realm.
This article doesn’t reiterate the benefits or values of consolidation, but seeks to level-set the new challenges that must be faced with regard to firewalls. However, it’s important to mention a few benefits of or savings associated with providing a physically secure networking environment:
• Latency is improved as data can be quickly moved between virtual operating environments; in some cases, taking advantage of memory access speeds.
• Communications are enhanced, both in latency and MIPS consumption, as link encryption is no longer needed, since only the two environments that need to communicate are on a physically secure, isolated network that nobody can see, let alone penetrate.
At a platform level, all the virtual networking connections are configurable and identifiable in one place. They can be audited for compliance or per security policy in a secure environment. HiperSockets can be configured to provide communications between two or more LPARs. In the z/VM environment, virtual LANs can be configured to provide communications between two or more guests. Each of these environments is easily audited for compliance. These tools provide the network architect with the building blocks needed to provide a previously distributed solution a home in the physically secure, virtual server environment on System z.
There’s no one right way of doing things and no best practices that fit every scenario. Success with a new consolidation effort requires assurance that the existing security policy is enforceable. If a project is started and the firewall security policy must be changed to make it work, history has shown repeatedly that the project is likely to be doomed. It’s far easier to deploy a solution in compliance with an existing security policy, transitioning from the distributed solution in Figure 1 to the consolidation solution seen in Figure 2, with the goal of augmenting the solution later to take advantage of platform enhancements or capabilities.
Bringing the Firewall Inside
A possible improvement to consider is to bring the firewalls inside the System z hardware, as portrayed in Figure 3. In this case, using a BrandX firewall appliance isn’t an option, so we turn to open source Linux solutions such as ip_tables, netfilters, and connection tracking (ip_ conntrack and nf-conntrack). Together they provide packet and port filtering with network address and port translation as well as stateless or stateful packet filtering. This may be all that’s needed. Depending on the number of firewalls deployed, management can occur on a case-by-case basis. In the case of multiple firewalls, some implementers have been successful using other open source projects, such as FireStarter and Firewall Builder, to manage their firewalls. These projects are a start. As the community grows and requirements develop, work remains to be done before the solutions can be considered enterprise ready to manage large numbers of firewalls.
Another alternative when running in a physically secure environment, such as System z, is to use the firewall capabilities of a host firewall technology. This is analogous to many of the “personal” firewall solutions that are used on home and business laptops and workstations around the world, but the firewall capability is brought into the host image; for example, the firewall would run as part of the TCP/IP stack in the application server in Figure 4.
Remember that firewalls tend to fall in the domain of the network team. Usually, they’re responsible for all networks, including network security technologies, regardless of whether the networks are cross-country or local, Internet-connected or intranet only, cabled, wireless, or physically secure virtual networks inside the System z hardware. If the team responsible for the platform, including hardware and software, isn’t talking openly with the team responsible for the networking, the project will have a rough time getting off the ground. These teams need to get in the same room and decide what problem they’re trying to solve and what firewall solution their security policy will support. They need to look at the flows for the end-to-end solution and understand what encryption is needed, where, and why. Only then can they understand if they can take advantage of the physical security of the virtualization platform or the benefits of eliminating link encryption in this environment.
One particular analysis might show that traffic flowing between an application server and a data server in two separate security zones might be encrypted because that data is comprised of PII and flows over a network in one security zone through an external firewall to a network in a separate security zone. On the other hand, if the firewall is deployed in a physically secure environment and we know that only the two servers can communicate over a virtual network link that only they can use, then there’s the possibility that encryption is no longer needed. Figure 5 shows these two deployment options. As we consider this, there are certainly extenuating circumstances, such as security policy or regulatory requirements that might require encryption regardless of the actual need. Again, there’s no single right answer; there are questions that need to be asked and more than one right answer.
Another factor to consider when weighing the internal vs. external firewall issue is Service Level Agreement (SLA) requirements. Can the SLA tolerate the latency that’s added by exiting the virtual environment going to an external firewall and then returning to the virtual environment, or is it more important to offload the firewall processing to external hardware appliances to preserve processing power for strategic applications in a processor-constrained environment? This becomes an issue of latency vs. resource consumption, not a firewall issue, but it’s critical to the firewall decisions that need to be made.
When considering a network consolidation in the z/VM environment, following the sage advice of the experts is imperative. Some suggestions:
• You can run guests of different security zones in the same z/VM environment. There are many years of experience embedded in the virtualization and isolation technologies of z/VM as well as certified compliance with rigorous security standards.
• RACF for z/VM isn’t a nice addition; it’s a necessity and is required to control access to various resources.
• If you’ve chosen to implement a solution similar to that in Figure 2, with the guests located in z/VM, then these guests should be using virtual switches rather than guest LANs or dedicated Open System Adapters (OSAs) to provide a more rigorous audit point.
• When deploying z/VM guests in a DMZ, turn on full auditing and ensure the guests are running in privilege class G (general user). Some installations will want to restrict the capabilities of a guest even further. No problem! Defining a custom privilege class or redefining an existing privilege class limiting the Central Processor (CP) commands available to a particular guest, or fine-tuning what privileged commands can be run, is part of understanding your workload and the requirements of each guest or type of guest. This limiting or fine-tuning of available CP commands is critical to ensuring the isolation and maximum capability of the various guests in the end-to-end solution.
Conclusion
Don’t skimp on security, but take the time to evaluate the solution and understand when enough is enough. If a consolidation is going to be successful, then the firewalls should be of a type supported by the security policy and in a location acceptable to the networking team. We all need to work together to ensure where, when, and how firewalls, or any security technologies for that matter, are deployed.
