Chapter 4 Building & Maintaining a Secure Network

Introduction

When thinking about securing a network, it is best to think of it in terms of defense-in-depth or a layered security approach. It would be great if we could rely on one type of technology or a single device to provide all of our security, but that’s not realistic. Some professionals use the analogy that security is like an onion—it has layers. Each layer doesn’t stand alone, but together they’re tough and solid. A firewall is one layer, but not necessarily the first layer. Figure 4.1 shows the different layers. The packet-filtering router that actually connects your company to the Internet is the first layer. Configure a small rule set to filter out basic unwanted traffic like Internet Control Message Protocol (ICMP), finger, and anything else that you can live without ever crossing into your network space. The next layer is the devices that make up your internal network infrastructure. Firewalls, intrusion detection systems (IDses), and switches all contribute to this layer of security. Layer three is the host-based security that you might have installed on each host. Host-based intrusion detection, antivirus software, and so forth would cover this layer to include the hardening of the operating system itself. The fourth layer covers the application itself. Any hardening of the application, access controls, and file/library permissions fall into this layer. The final layer covers protecting the data itself. Encrypting the data stored on the system is one of the easiest ways to protect it.

Installing and Maintaining a Firewall Configuration

Why do we need a firewall? Besides the obvious, the Payment Card Industry (PCI) standard requires it; we need to reduce our risk by protecting our systems and networks from attempts to exploit known and unknown vulnerabilities. That all sounds fine for a formal response, but what are we really doing? We’re adding privacy to the internal network by restricting access to the systems on our internal network. A firewall is simply a noise filter or device that controls unwanted traffic into a company’s network from outside, and can play an important role by segregating sensitive areas from the rest of the company’s internal network.

Let’s take a look at firewall placement and configurations. Remember, this book isn’t meant to be an authority on firewalls, but it will give you some ideas. From time to time I’ll refer back to the PCI Self-assessment Questionnaire (SAQ) and/or the Security Audit Procedures to clarify.

Firewall Overview

There are literally dozens of firewall manufacturers in the world, but only a few different types of firewalls. The PCI standard does not specify what brand of firewall to use, but it does state what it needs to provide in order to provide the level of security required for your environment. It needs to be robust enough to allow the appropriate amount of configurations to be applied. The differences in firewalls is in the way they handle the packets of data for acceptance or rejection. Only if the packet meets a certain predetermined criteria is it allowed to pass through the firewall. This helps to reduce the traffic flow into the network. Firewalls can also be used internally. Most people think a firewall is only used for connectivity to the Internet or non-private networks. Although the perimeter is the primary consideration when implementing a firewall solution, it can also be used on the private network to protect more sensitive networks or systems from traffic on the private network. The three types of firewalls we will discuss are packet filtering, proxies and stateful packet inspection firewalls.

Packet-filtering Firewalls

Packet filters work a little differently than a proxy. They still inspect packets, but they do it at the network layer (Layer 3) of the Open Systems Interconnection (OSI) model. This is where the routing of packets takes place. A packet-filtering firewall allows or denies packets based on the Internet Protocol (IP) address, protocol, and source and destination port numbers being used. A router is essentially a packet filter. Most routers are fast and efficient and the technology is widely available, but they are limited in what information in a packet they can analyze. The syntax of the rule set is sometimes hard to remember, and there is always the occasional bug and vulnerability discovered in these simple devices. Table 4.1 lists some of the pros and cons of packet filtering firewalls.

Table 4.1 Packet Filter Pros and Cons

Pros	Cons
Low cost	Rules are sometimes hard to configure
Fast and efficient	Router performance affected
Technology is widely available	Bugs and vulnerabilities are more prone in this technology

Proxy Firewalls

Proxy firewalls work by making every connection requested across the firewall on behalf of the client. Packets are scrutinized at the application layer of the OSI seven-layer model, and are examined for their compliance with specific rules and then either permitted or denied.

Proxy firewalls are much slower than packet-filtering firewalls, but are considered to be a more secure solution offering a higher level of security. They are suitable for certain types of organizations that may be more security conscious like financial institutions and government organizations, but have a significant impact on network performance. Table 4.2 describes the pros and cons of why a proxy may not be the best solution for a company dealing with PCI data.

Table 4.2 Proxy Pros and Cons

Pros	Cons
“Intelligent” filtering	May require modification of servers/clients
Includes user-level authentication	Much slower than packet filtering
Normally provides good logging	Extensive configurations and management

Stateful Inspection Firewalls

Stateful inspection firewalls combine the speed of packet filters with the control of proxy firewalls. They have the ability to filter packets at the network layer, and then determine if session packets are valid and evaluate the contents of the packets at the application layer. Stateful inspection firewalls allow for direct connections between clients and hosts.

Stateful inspection firewalls offer strong security along with good performance and transparency to end users, unlike the packet filtering and proxy firewalls. Algorithms are used to recognize and process application layer data instead of having to run an application specific proxy. They keep track of the “state” of a connection and, in most cases, examine each packet to see if it is part of an authorized connection. Since the UDP protocol has no “state,” UDP return packets arriving within a prescribed time window are allowed in. This technology is expensive and, due to the complexities of the configuration, have the added risk of being misconfigured thus adding additional risk to you environment. Table 4.3 shows the pros and cons of the stateful packet inspection firewall’s balance of speed and security, which is a better solution for companies working with PCI data.

Table 4.3 Stateful Packet Inspection Pros and Cons

Pros	Cons
Fast	Expensive
Transparent to the user	Multiple inspection points at different layers of the OSI
Complex configurations	UDP is stateless and requires additional configurations

Firewall Architectures

Firewall architectures vary in complexity, from the easy-to-set-up screening router (which is not discussed here), to a dual in-line firewall configuration. A screening router, a router with only a few rule sets configured, is an unacceptable solution; therefore, it can be ruled out. The three more common types of architectures that we’ll discuss are the dual-homed host, screened host, and the screened subnet. We also talk about architectures that have in-line firewall configurations and the benefits of such a design.

Dual-Homed Host

The dual-homed host architecture deploys a single machine connected to two networks and acts as a gateway. This configuration is better suited for a proxy firewall in which all traffic and transactions go through this host before proceeding on to another network. This is a relatively simple configuration and offers added security that having only a screening router does not. As mentioned earlier, proxy firewalls require a lot of configuration, and without configuring packet forwarding traffic will not pass. Therefore, each traffic type needs to be analyzed and the firewall configured to allow the traffic or it’s denied. Figure 4.2 shows a simple description of the placement of a dual-homed host between the Internet and your private network. It sounds simple, but the complexities in the configuration may make it infeasible when considering the appropriate level of security for your PCI environment.

Screened Host

Screened host configurations offer a little more complexity to your architecture. As you’ll notice on Figure 4.3, a router is introduced into the environment and provides screening at the perimeter of the network. External users are still able to get to the screened host, and traffic still flows through the host acting as a gateway or proxy into and out of the network for added security. You should be starting to understand the layering approach at this point. Instead of a single device providing all of the security, the router is filtering out unwanted traffic and the screened host is adding additional security by inspecting all of the traffic and allowing or disallowing traffic as defined in the security policy.

Screened Subnet

The screened subnet configuration is a combination of the dual-homed host and screened host architectures. The screening router is still the first line of defense into the corporate network, and filters incoming traffic between the Internet and the publicly accessible hosts. As shown in Figure 4.4, the host could be a dedicated server or have several services running and could also be a firewall (with several DMZs configured for separation) where all connections to and from the internal network are made. Notice the additional layer of security by putting another router in place to further restrict access into the private network.

Dual Firewall Configuration

A dual firewall configuration is the optimal network configuration. There are multiple layers of security in this configuration. The router still provides the first layer of security, and the first firewall provides stateful inspection of traffic to the DMZ(s). The second firewall prevents any traffic originating from the Internet or DMZ(s) to access the corporate network, as shown in Figure 4.5. It is recommended to have disparate firewalls for this configuration in the event one firewall is compromised. The odd of breaching both firewalls is fairly large.

PCI DSS Requirements

Section 1.1 of the PCI DSS guides you through the process of configuring and maintaining your firewall. There is no real science to deciding on what type of firewall and configuration to use, just some forethought. PCI requirements make is easy for you. The DSS tells you what type of firewall you can use, how it must be configured, how to maintain it, and what to protect against.

Establish Firewall Configuration Standards

The DSS doesn’t waste any time getting into change management. Section 1.1.1 requires a formal process for approving and testing all external network connections and changes to the firewall configuration. There are a couple of things going on here. First, all external connections have to be approved and tested. Approval implies that management must know and agree to the connection. Once the connection is made, it must be tested. This is usually done by penetration testing. Penetration testing is the authorized testing of security controls at the perimeter (connection). Your organization may prefer to call it a vulnerability assessment or external risk assessment, but generally we are talking about the same thing. Lastly, the firewall should be baselined and any changes to the configuration thereafter must be approved. Each of the stakeholders should have a say in whether or not the changes actually get implemented.

It’s much easier to understand what needs to be secured if you can see it on paper. Section 1.1.2 shows a current network diagram. All connections to the cardholder data should be clearly documented including any wireless networks. The network diagram includes all external connections to the Internet and all network devices, systems, and dataflows. This diagram needs to remain current at all times. With a good change management process, keeping the network diagram up-to-date is a simple task.

Dataflow are often forgotten when putting together an accurate diagram. These are the directional arrows that show the flow of data. Additionally, the type of data and the protocol needs to be a consideration to meet requirements 1.1.6 and 1.1.7. Requirement 1.1.6 requires justification and documentation for any available protocols besides Hypertext Transfer Protocol (HTTP), Secure Socket Layer (SSL), Secure Shell (SSH), and Virtual Private Networks (VPN). Requirement 1.1.7 also requires justification of the use of risky protocols such as File Transfer Protocol (FTP) and Telnet. In order to document dataflows accurately, a list of services and ports necessary to do business needs to be identified. This list should also meet the requirement of Section 1.1.5. Section 1.1.4 may also be of use here. The administrator needs accurate documentation of all groups, roles, and responsibilities for logical management of network components. This is especially helpful to administrators when implementing the rule sets.

Now that you have all of your Internet connections documented and your network clearly defined, firewalls need to be implemented at each connection point and between any DMZ and the internal network. Depending on how robust the firewall solution is, it may have DMZs built in. If not, the dual firewall solution would need to be implemented in order to comply with 1.1.3 of the DSS. It requires a firewall between DMZs and the internal network. It sounds trivial, but interpretation is everything. There isn’t a lot of information regarding the router configurations. Requirement 1.1.9 states that router configuration standards must exist. There aren’t a lot of details for 1.1.9, but if you follow the same steps that the DSS requires for the firewall configurations and apply it to the routers, you should not have any problems meeting this requirement. Lastly, 1.1.8 requires quarterly reviews of the firewall and router rule sets for accuracy.

Build Secure Firewall Configurations

Sections 1.2, 1.3, 1.4, and 1.5 can be rolled into building secure firewall configurations. The requirements are interrelated and thus can be discussed at the same time. Section 1.2 focuses on denying traffic from untrusted networks and hosts. Section 1.3 restricts access to any system storing cardholder information from any publicly accessible system in the DMZ. Section 1.4 prohibits access to systems that house cardholder information from the Internet. Finally, Section 1.5 requires IP masquerading. Let’s take a look.

Denying Traffic from Untrusted Networks and Hosts

Confidentiality, integrity, and availability are at the heart of Section 1.2. This firewall configuration has to accomplish several things. The rule of thumb here is to deny most traffic. The few types of traffic allowed should only be what is absolutely necessary to conduct business. It is much easier to filter everything initially than to only open the required ports and allow specific types of protocols to traverse those ports. This is where a good network diagram with dataflows, coupled with an accurate list of required services, ports, and protocols, is worth its weight in gold.

Denying all traffic from “untrusted” networks and hosts is easy to accomplish. Many firewall solutions do this right out of the box. If not, there is usually a rule that can be configured to do this. It all boils down to “deny all.” Don’t be confused here. Denying all doesn’t necessarily deny “all” traffic through the firewall. It usually only denies incoming traffic, not outgoing. In order to deny outgoing traffic, a rule would need to be applied to the rule set for outbound traffic.

With the traffic being denied for all inbound traffic, specific rules need to be applied that allow for a few necessary protocols that are already acceptable based on the DSS. Rules to allow HTTP, SSL, SSH and VPN traffic should be implemented. Just because they are allowed doesn’t mean you should allow these protocols by default. Verify the business need against your list of ports, protocols, and services first. To add even more security, if the source of traffic can be narrowed down to specific networks or hosts, apply a rule only allowing such.

Restricting Connections

Section 1.3 in the DSS gets pretty granular with restricting connections between publicly accessible servers and any system component that stores cardholder data. What does this mean to you? The database cannot be in a DMZ that is publicly accessible. Stateful inspection firewalls must be used. Inbound and outbound traffic is restricted to only that which is needed to conduct business and is documented. If traffic is not explicitly allowed in the rule set, it should be denied. Any Request For Comment (RFC) 1918 addresses are not allowed from the Internet. Personal firewalls are implemented on mobile units. And lastly, the routers comply with the established change management rules.

RFC 1918 address rules in routers and firewalls should seem pretty obvious; however, Section 1.3.2 requires denying those addresses that are specifically designated as internal or private addresses the ability to access the DMZ from the Internet. This should raise a flag in any audit of log files seeing an RFC 1918 address originating from the external port trying to come in to the DMZ or private network. The firewall rule set should only allow valid Internet traffic access to the DMZ. Section 1.3.1 requires restricting traffic from the Internet to only those addresses that are in the DMZ, meaning that Internet traffic may not pass through to the internal, private network. Why can’t Internet traffic pass to the internal network? Because Section 1.3.4 requires the database to be on the internal network segregated from the DMZ. The database should never be able to connect directly to the database. Front-end servers or services should only be accessible by the public. These servers and services access the database and return the required information on behalf of the requester just like a proxy. This prevents direct access to the database.

Sections 1.3.5 and 1.3.7 should be tied together in the DSS. Section 1.3.5 requires the restriction of inbound and outbound traffic to that which is necessary for the cardholder data environment. Section 1.3.7 requires denying all “other” traffic whether inbound or outbound that is not specifically allowed. So if you focus on Section 1.3.7 and think about the wording from Section 1.3.5, “that which is necessary,” then you should be building a rule set that is only allowing traffic required for business purposes. Everything else would be denied by default.

Again, the DSS doesn’t get very granular with the router configurations. Section 1.3.6 requires insuring the router configurations are synchronized. The baseline configuration should be the configuration that is used on a reboot and should also be the current running configuration. No changes should be made to the running configuration without first going through the appropriate change management procedures and changing the baseline configuration first.

Additional firewall considerations should be taken with regards to wireless networks and mobile or personal computers. Section 1.3.8 should be treated just like any other firewall configuration, wired or wireless. Systems with cardholder information must be segregated and all traffic should be denied from wireless networks. In the case of mobile or personal computers, Section 1.3.9 requires a personal firewall for added protection. These units may not always get critical patches in a timely manner and the personal firewall provides some assurance.

Prohibit Public Access

Cardholder data is at the crux of the DSS. We have to protect the data as much as possible. This means not allowing unauthorized access to critical servers that have any information like databases, log files, and trace files. Section 1.4.1 requires a review of the firewall and router configurations to verify that there is not a direct route for Internet traffic regardless if the originating source is internal or public. All traffic must flow through a firewall and router. Section 1.4.2 stresses the implementation of rules on the firewall that restrict traffic from the cardholder applications to only be able to access the servers in the DMZ.

IP Masquerading

IP masquerading is a clever way of saying Network Address Translation (NAT) or Port Address Translation (PAT). It’s a security best practice that does not allow your internal address scheme to be seen on the Internet. We use NAT or PAT to accomplish this. NAT is a standard that enables a local area network (LAN) to use a predetermined pool of IP addresses internally and a second set of addresses for external access to the public network creating a many-to-many scheme. The internal pool of IP addresses is, in most cases, derived from RFC 1918. The external addresses are routable, real-world addresses. PAT is a type of network address translation. During PAT, each computer on the LAN is translated to the same IP address, but with a different port number assignment, thus establishing a many-to-one addressing scheme.

Choosing an Intrusion Detection or Intrusion Prevention System

Intrusion detection has been around for many years. It’s the process of monitoring traffic and activities on systems and networks and then performing an analysis for signs of an intrusion or compromise. Once a determination has been made that an intrusion has occurred, alarms are sent out to the appropriate IT professionals to take steps to correct the problem. In many cases, an IDS is used. But IDSes are passive by design and the results are reactive in nature. Another type of intrusion detection is the Intrusion Prevention System (IPS). IPSes are considered to be the next generation of intrusion detection technology. It not only alerts system administrators of suspect activity, but can also be configured to take corrective actions. IPSs not only prevent known intrusions, but can sometimes prevent unknown attacks based on attack behaviors.

Intrusion Detection Systems

IDSes detect unwanted activity to systems, mainly from the Internet. This activity is usually the product of a hacker executing an attack. IDSes detect malicious activity that can’t normally be detected by firewalls, including Trojan horses, worms, viruses, attacks against vulnerable services, unauthorized logins, escalation of privileges, and attacks on applications, to name a few.

IDS can be categorized into several categories:

• Network Intrusion Detection Systems (NIDS) An independent platform that examines network traffic patterns to identify intrusions for an entire network. NIDSes need to be placed at a choke point where all traffic traverses. A good location for this is in the DMZ.
• Host-based Intrusion Detection System (HIDS) Analyzes system state, system calls, file-system modifications, application logs, and other system activity.
• Application Protocol-based Intrusion Detection Systems Monitors and analyzes application specific protocols.
• Protocol-based Intrusion Detection Systems Monitors and analyzes the communication protocol between a server and the connected device (another system or end user).
• Hybrid Intrusion Detection Systems Combines one or more of the approaches above. In most networks, an IDS is placed in one of three configurations:
• Hub Configuration Allows for an easy and affordable implementation. The IDS is connected to a hub in the network segment to be monitored. When traffic traverses a hub, it is broadcasted to all ports, unlike a switch. The IDS can then be connected to any port and monitor the traffic as demonstrated in Figure 4.6.
• Switch Configurations are very similar to the hub with one major difference. Switch technology is smart in that it only sends traffic to the intended recipient. So in order to allow the IDS to monitor the traffic, a port has to be configured as a mirror or Switch Port Analyzer (SPAN) port. Figure 4.7 shows multiple sessions traversing the switch, inbound and outbound, with the traffic also being sent to the SPAN port.
• Network Test Access Ports (TAPS) allow passive monitoring on a network segment. TAPS are more reliable than hubs or switches and relatively inexpensive to implement. Hubs have a potential for bottlenecks and packet collisions. Switches can also cause bottlenecks depending on the amount of traffic being mirrored to the SPAN port, and have a tendency to not receive error packets. They only receive half of a full-duplex connection and handling Virtual Local Area Network (VLAN) can be complex or impossible. The TAP configuration shown in Figure 4.8 alleviates these problems and is completely passive, doesn’t cause bottlenecks or packet loss, and supports full-duplex.

Intrusion Prevention Systems

The IPS is considered, by most security professionals, to be the next generation of IDS. It provides configurable thresholds and policies for network traffic and an IDS for sending suspect activity alarms to network administrators. An IPS makes attempts to stop and attack, whereas an IDS only alerts you to the potential attack. Currently, there are two types of IPSs:

• Host-based Intrusion Prevention systems (HIPS)
• Network-based Intrusion Prevention systems (NIPS).

HIPSes protect workstations and servers through software that resides on the system. HIPSes catch suspect activity on the system and then either allow or disallow the event to happen, depending on the rules. HIPS monitors data requests, read or write attempts, and network connection attempts to name a few.

NIPS is a network security solution. NIPSes monitor all network traffic for suspect activity and either allows or disallows the traffic to pass. For a NIPS to work properly, it needs to be positioned in-line on the network segment so that all traffic traverses through the NIPS. The implementation of a NIPS is similar to a NIDS with one exception. Since a NIPS has two NICS, a network TAP, switch, or hub is not required. The network only needs to be architected with the NIPS in a position where it can monitor all the network traffic inbound and outbound.

Again, the DSS does not dictate which solution should be used. In many cases, this may come down to cost. Both the IDS and IPS have their advantages and disadvantages and should be weighed accordingly. If I had my way, I would go with a combination of a NIPS solution placed in a DMZ to eliminate the need for a TAP, hub, or switch. It also has the added feature of being able to take corrective actions once configured and then utilize a HIPS on critical systems.

Antivirus Solutions

Antivirus software is a basic necessity for all systems and networks that have an Internet presence. It’s even more important to the PCI because of the customer information that is being stored. Antivirus software also adds another layer to your overall security. The distinct characteristics that, at one time, made viruses, worms, Trojans, and spyware unique from one another is not so clear anymore. I’ll use the term malware to encompass them all. Although many malware programs are more of a nuisance than cause any real damage the threat still exists and the risk of having your customer’s credit card information stolen is high.

Gateway Protection

E-mail is one of the primary vehicles that malware uses to spread throughout the Internet. Adding an antivirus solution that runs on your e-mail server or Simple Mail Transfer Protocol (SMTP) gateway that scans each message before passing the message to the intended recipient helps to protect your users and your data and systems. Gateway antivirus solutions provide a balance with the need to communicate over the Internet quickly and the need to protect the privacy and integrity of information and services. Gateway solutions reduce the threat of viruses entering a PCI network, and also reduce the likelihood of internal individuals being able to send viruses to Internet users.

Desktop and Server Protection

The desktop cannot be ignored. This is where most of the problems exist. Users receive e-mails and bring disks to work that may be infected. By having antivirus software installed on every desktop, in addition to the gateway protection, protects the user from receiving infected e-mail or inadvertent downloads of malware.

There was a time when system administrators didn’t want to put antivirus software on their servers because of performance issues. That rationalization will get you in trouble quickly. Just because you have gateway antivirus solutions and all of the users have antivirus software on the desktop doesn’t make the servers immune. Malware can spread throughout an enterprise, and in most cases, doesn’t care if it touches a server or PC.

For an antivirus solution to be effective it must be:

• Installed and running on every laptop, desktop, and server at system boot. The software should be password-protected so that users cannot disable or uninstall the application. It may sound trivial, but users and administrators disable antivirus software all the time because it slows down their system. Therefore, password-protecting the administrative functions of the software has become a necessary evil.
• The solution should also provide real-time scanning. Most of us are familiar with static scanning. That is when your desktop automatically starts a weekly scan of your hard drive or when you execute a manual scan of files on your system. Real-time scanning scans all files that the operating system uses before it is fully opened.
• The antivirus solution must be kept up-to-date with the latest signatures. New malware is being released daily. If your antivirus solution is not current, the users and data are at risk. Auditors will check the signature time stamps to make sure they have been updated.

Most enterprise level antivirus solutions provide protection for servers, desktops, and the gateways with an administrative console to download the latest signature files and push them to the systems. A couple of the better known manufacturers are Symantec and McAfee. Make sure you do your due diligence and research all of the solutions available and make the right choice for your organization.

System Defaults and Other Security Parameters

A lot of thought goes into securing a network. Not only do you have to think about the network devices (e.g., routers, firewalls, IDSes) and antivirus software, you have to think about system defaults, configuration management, and encrypting non-console administrative access to name a few. Many of these do not contain a lengthy explanation; however, from a best practices standpoint it should be done to increase your security posture.

Default Passwords

Default passwords exist with almost every operating system and application. Section 2.1 of the DSS requires that all vendor-supplied passwords be changed before deploying a system on the network. Section 2.1.1 requires the same for wireless environments. System passwords are usually a set-and-forget thing, but it is good practice to change them at least quarterly. Password policies and procedures are usually dictated by the organization. Although there are several alternatives for authentication like biometrics, Smart Cards, and tokens, most of us use the traditional ID and password.

Additionally, if your organization has a procedure for adding new users to the network and granting them access to systems, there may be some default passwords that you haven’t thought about. If you can remember back to when you first received your user ID and password, you might recall that it was a preset generic password. There is a very good chance the system administrator’s use that same password for all new users. Therefore, those accounts need to be taken into consideration from a security perspective and appropriate actions taken.

A strong password policy and enforcement will help to protect the systems form potential compromise. Here are some simple password rules, above and beyond changing default passwords that will provide stronger security.

• User-level passwords must be changed at least every 60 to 90 days.
• Accounts that have system-level privileges must have a unique password from all other accounts held by that user.
• Passwords must not be transmitted over the Internet by e-mail or any other form of communication, without being encrypted.
• Passwords should be a minimum 6 to 8 characters in length, with a combination of upper- and lower-case alpha and numeric characters and special characters as well (e.g., !%@$)
• Passwords should never be written down or shared with anyone.

SNMP Defaults

Sections 2.1 and 2.1.1 require all system defaults to be changed before deploying a system onto the network. The Simple Network Management Protocol (SNMP) strings must be changed. SNMP is associated with several known vulnerabilities. SNMP is a good network management tool for administrators. It gives them the ability to touch a device across the network. That being said, it allows hackers to do the same. Make sure SNMP defaults are changed.

The most basic form of SNMP security is the community string. There is a public community string that provides read-only access to network devices. The default value for this community string is usually “public.” Remember, community strings are not unlike passwords. Using this community string like a password, the Network Management System (NMS) can retrieve data from network elements.

Delete Unnecessary Accounts

Out of the box, systems and applications come with a variety of accounts preinstalled. Some are system accounts and others are administrative accounts for support from the vendor. It is my recommendation that any support account be deleted immediately. These are like backdoors into your system—if not controlled closely, they can be disastrous. All guest accounts should be deleted or at least disabled. The passwords should be set to something no one knows and you should consider renaming the account if it can’t be deleted. The same goes for default administrator accounts. Rename them to something inconspicuous. Name them something that conforms to your organization’s naming standards and change the description of the account as well. It adds a layer of difficulty for an attacker looking for the account.

Wireless Considerations

Wireless networks should be treated the same as a wired network when it comes to security with a few hooks. Wireless stretches the boundaries of your network past the brick and mortar walls and out where you don’t have control over who attempts to connect to your network. You can prevent someone from gaining unauthorized access by changing the default settings.

Remember to change the default passwords. Some of the more obvious defaults to change are:

• Change the Wireless Equivalent Privacy (WEP) key at least monthly. WEP keys are inherently weak.
• Change the default Service Set Identifier (SSID). The SSID is the network identification. SSIDs are easy to crack and most vendors use the same or similar SSID for all of their models. When changing the SSID, choose one with little or no meaning. Don’t name it the organization name and don’t broadcast it, thereby making it less obvious and less accessible.
• Enable WiFi Protected Access (WPA and WPA2) for encryption. For the WPA pre-shared key, create a key that’s not easily compromised. Keys can usually be entered as a pass phrase, hexadecimal characters, or manual hexadecimal values.

Develop Configuration Standards

All organizations should adopt a practice that is considered to be a minimally acceptable configuration practice for all systems. It is a key element of a security and aids a security team’s efforts in reducing the vulnerabilities on their systems and the overall risk to the organization. Section 2.2 requires that all known security weaknesses are addressed and are consistent with industry-accepted system hardening standards defined by the National Institute of Standards and Technology (NIST) and the Center for Internet Security (CIS), to name a few. If a particular vulnerability is not addressed with specific hardening techniques, workaround solutions may need to be applied to mitigate the risk. Once you have adopted a standard, the systems should be baselined to ensure all systems are built and hardened the same every time.

Creating security baselines on computers and your networks is no trivial task. It takes time and effort, but the end result is priceless. A security baseline is a standard set of security settings that are established for each type of computer or network component in your organization. The baseline configuration is a “point-in-time” configuration and should be updated regularly as new settings are applied. Your organization’s security policy should drive what security is applied to your systems. A well-defined security policy will lay the foundation of what security must be put in place.

Implement Single Purpose Servers

SubSection 2.2.1 requires that critical servers provide a single service (e.g., DNS, database, e-mail, Web) to the organization. All too often, organizations try to save money by hosting multiple server services on the same host. Each service brings its own vulnerabilities and risks to the table and provides a hacker with multiple choices for attack. If too many services are provided by a single server, an exploited vulnerability on one service (i.e., DNS) can bring down or cause a denial of service (DoS) to the entire server. The integrity of all the services and data is questionable at that point. As a rule of thumb, the more services provided on a single host degrades the overall security of the server and the organization.

Configure System Security Parameters

You might think this is a “no brainer,” but not all system administrators know exactly what is enabled and disabled on their systems and how the system itself is secured. Section 2.2.3 requires the verification of all system security parameters to prevent misuse. This particular control is a question and answer session with the system and security administrators. Section 2.2.3 lists the following procedures:

1. Interview system and security administrators to verify that they have knowledge of common security parameter setting for their operating systems, database servers, Web servers, and wireless systems.
2. Verify that common security parameter settings are included in the system configuration standards.

This goes back to Section 2.2, developing configuration standards for all systems and components. A baseline security configuration needs to be established. Baseline security standards substantiate the security of your organization and the information you must protect. Implementing the security features required by your security policy, or implementing the security policy is often easier said than done. Fortunately, NIST provides checklists for almost all platforms in use today that are freely available on their Web site, http://checklists.nist.gov/repository/index.html. If you follow a standard and create a baseline configuration, then all servers, computers, and components on your network should have the same settings as applicable.

Disable and Remove Unnecessary Services, Protocols and Functionality

All unnecessary and insecure services and protocols should be disabled as required by Section 2.2.2. Simply stated, what this means is if there is not a valid business case for having a service or protocol active, it should be disabled. This also applies to Section 2.2.4. All unnecessary functionality, such as scripts, drivers, subsystems, Web servers, and so forth, should also be removed. More and more industries are practicing this. If it’s not needed, get rid of it. It will save you the headache down the road of having to explain why it was there in the first place if the organization doesn’t use it.

Encrypt Non-console Administrative Access

System and network administrators, by design, have access to everything. They “own” the network. However, some of the tools they use are a little less than secure. Many of the tools are antiquated and actually pass user IDs and passwords in the clear. To accommodate the requirement of Section 2.3, encryption solutions must be used for all non-console administrative access. Think about this. If you are going to require your administrators to utilize encryption for services such as Telnet, it would be a good idea to make all the users in the organization use an encrypted solution for Telnet such as SSH.

To meet this requirement, three things have to happen.

• SSH (or other encryption method) has to be invoked before an administrator’s password is requested.
• A review of services and parameter files on systems to determine if Telnet or other remote log-in commands are not available for use internally (e.g., the “r” commands in Unix. (i.e., rlogin, rsh, ruptime, rcp, rwho).
• The administrator access to any wireless management interfaces must be encrypted with Secure Sockets Layer/Transport Layer Security (SSL/TLS). Additionally, it must be verified that administrators are not allowed to connect to the wireless management interface remotely. They can only connect from a management console.

Hosting Providers Must Protect Hosted Environment

PCI compliance goes further than just the commercial entity providing the goods and services. Far too often your favorite store is nothing more than a “store front” with no back office, just a building or a Web site that pushes goods. All of the databases and Web site hosting is done through a service provider. Section 2.4 requires that hosting providers protect each entity’s hosted environment and data.

Summary

All systems must be protected from unauthorized access, whether it is from the Internet or any other source. What seems like an insignificant path from the Internet, employee e-mail, and browsers or e-commerce services such as Web servers can prove to be disastrous if not secured appropriately. Throughout this chapter, we have discussed two requirements of the PCI DSS: Requirement 1, Install and maintain a firewall configuration to protect cardholder data, and Requirement 2, Do not use vendor-supplied defaults for system passwords and other security parameters. Understanding these two requirements is fairly easy. Complying with them or actually implementing the required security features can be somewhat overwhelming.

The standard for the type of firewall that is acceptable to meet the PCI standard was stated for you. It must provide dynamic packet filtering (only “established” connections are allowed through the firewall) commonly known as stateful inspection. The firewall configuration must be managed at all times. Router configurations must be managed as well. Section 1.1.8 states that the configuration standards for firewalls and routers must include a quarterly review of their rule sets. Any unneeded ports, protocols, and services must be removed or disabled. All management functionality, including groups, roles, and responsibilities, must be through a secure means and be thoroughly documented in the organization’s security configuration standards. If there isn’t a valid business case for having it, get rid of it.

We also discussed administrative access to systems and components. Remote access to critical servers should not be allowed. If access to a device, whether it’s wired or wireless, is required, it must be through an encrypted connection. Otherwise, administrators should only use an appropriate management console to perform the required tasks.

The trend for these two requirements was to have configuration standards implemented. Configuration standards must take into consideration all network devices (i.e., firewall, routers, switches, IDSes) and your computers, servers, services, and applications. Default configurations and passwords are almost always published on the Internet. For this reason alone, we need to take precautions and change all default setting so as not to make the attacker’s job easy. If an attacker makes attempts to exploit your environment and finds it difficult, chances are he’ll move on to something easier.

Configuration standards mean baselining. Once the different types of systems and components have been hardened, a baseline security configuration should be established. This takes the guess work out of building and configuring the next, like, system. It will have the same configuration as the previous one if the baseline configuration is followed. The baseline security configuration should be updated on a periodic basis to include new changes to the system, and should always follow what is stated in the configuration standards and required by your organization’s security policy.

Solutions Fast Track

Installing and Maintaining a Firewall Configuration

• The PCI DSS requires a firewall that provides stateful inspection, also known as dynamic packet filtering.
• Stateful inspection firewalls offer strong security along with good performance and transparency to end users, unlike the packet filtering and proxy firewalls.
• Document your dataflow in order to aid the system and security administrators in configuring the firewall with the proper rule set.
• Disable or remove all unneeded ports, protocols, and services not required for business purposes.
• Deny all traffic into and out of the firewall that is not required for business purposes.
• Your firewalls and routers must have documented configuration standards and the rule sets of each should be reviewed at least quarterly.

Choosing an Intrusion Detection or Intrusion Prevention System

• IDSes differ from IPSes in that they will only send alerts to the administrators if suspect activity is detected. An IPS will take corrective actions.
• A network TAP provides the best possible connection point for any type of intrusion detection solution. It eliminates potential bottlenecks and dropped packets.
• IPS solutions are considered the “next generation” of intrusion detection and, when properly configured, will take corrective actions in addition to alerting appropriate personnel.

Antivirus Solutions

• A good antivirus solution protects against virus attacks at the gateway and also at the server and desktop.
• Gateway antivirus solutions provide a balance with the need to communicate over the Internet quickly, and the need to protect the privacy and integrity of information and services.
• For an antivirus solution to be effective, it must be installed and running on every laptop, desktop, and server at system boot. It must also provide real-time scanning and be kept up-to-date with the latest signature files.

System Defaults and Other Security Parameters

• All default passwords must be changed before deploying a system on the network.
• The public string in SNMP, if used, must be changed to something unique. It should never be left as “public” or blank.
• All accounts provided in a default installation should be deleted if not required for business purposes.
• WPA should be enabled for encryption on wireless access points rather than WER WEP keys are inherently weak.
• Develop security configuration standards for all of your systems and baseline your configurations.

Frequently Asked Questions

The following Frequently Asked Questions, answered by the authors of this book, are designed to both measure your understanding of the concepts presented in this chapter and to assist you with real-life implementation of these concepts. To have your questions about this chapter answered by the author, browse to www.syngress.com/solutions and click on the “Ask the Author” form.