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, wellbehaved, 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.