Defining firewall security objects

An object, as defined within this section, means any piece of equip- ment or software with a communication need to traverse the firewall. Identifying such objects within a large enterprise-scale network may require that a checklist or questionnaire be developed to discover them. This may appropriately be considered an object discovery

process. But discovery of a process should not immediately be cause to enable it. A network security specialist is not an enabler, and such actions would risk exploitation and subsequent resource compro- mise on any number of levels. A security specialist plays an advisory role as one who understands the enterprise mission and the pros and cons of performance impact and knows how to socialize these con- cerns interdepartmentally.

Beyond initial discovery, the needs and evaluations of various protocol allotments may be incorporated within the network mission through a process of evaluation, or post object discovery evaluation.

This should be undertaken at an operational level commensurate with impact. If protocol mapping will require bandwidth and prece- dence allotments that exceed network bandwidth, a greater level of approval than simply that of the department manager will be neces- sary. Departmentally, need must be evaluated and bandwidth parceled accordingly. This author assumes that if gateways are man- aged, this area of implementation may not be as important interde- partmentally but still may be of concern within a particular subset of an enterprise that shares connections.

Finally, creating a policy map that reconciles firewall policies with physical addresses is critical to the maintenance process. Future troubleshooting, error decoding, and understanding the complex traffic patterns that emerge in this process will depend on the generation of an accurate policy map. Figure 7.1 is a sample policy map.

7.2.1

Object discovery process

Creating an object discovery process can be as simple as asking the right questions, reviewing software catalogs, or taking inventory. It may also include ongoing and active use of packet analysis in a fluid and deterministic method of bandwidth allotment. Unusual or eso- teric software applications, from communications tools to financial monitoring packages, may have special, nondeterministic attributes and requirements. Developing a comprehensive list of all network traffic protocols that are passed throughout a secure LAN may or may not be an option. Volatile networks may be more prone to abrupt and constant change, things that can make true security nearly impossible. Such a network should focus on segregation and creation of specialized network segments that can be isolated and

7.2 Defining firewall security objects 133

Chapter 7

Figure 7.1 Attached to protocol policies in a bird’s eye view demonstrates a possible policy map, with physical routings of perimeter security rules.

E-mail server Laptop computer Laptop computer Laptop computer Tower PC Switch Firewall 1 File server The Internet Web server Document

management All TCP connections_{to or from DMZ are} allowed.

SMTP and POP are only allowed to e-mail server. http is only allowed to document management and web server. FTP connections are allowed only to file server. Telnet is never allowed in to DMZ. DMZ Secure Rules: Secure LAN to DMZ Rules: Secure LAN DMZ Modem

All other IP packets are discarded.

routed away from sensitive information (more on this in the section Identifying Trusted and Untrusted Networks, later in this chapter). An initial round of sniffing to root out the environment is critical. It probably won’t cost anyone their job, but shutting down a port on someone who depends on it to complete their work will only build ill-will. Many programs, such as the Javvin Packet Analyzer 4.0, offer sensible pricing and optional support packages and provide inexperienced users with a clear understandable interface for creating a policy map. Detecting protocols that are used, and subsequently querying the user about the purpose and need of discovered protocols may seem innocent enough, but bear in mind that people can be defensive about their work, and questions of this sort should be handled with some discretion. A general announcement that network administration plans to investigate application protocols for network security purposes should pave the way.

7.2.2

Post object discovery evaluation

The TCP/IP protocol is the foundation on which 6 of 7 layers of the Internet network architecture is based. As such, there are many suites of protocols within the TCP/IP protocol. In the Open Systems Interconnection (OSI) 7-layer model, created by the International Organization for Standardization (ISO), there are families of proto- cols called suites,and these, in turn, are used by various layers of the OSI model. Some protocols are used on more than one layer and may appear to be subsets of another protocol, yet appear side by side with that protocol on some protocol maps. Making sense of and developing a complete understanding of the 7-layer architecture and the protocols begins here and never ends. Many times, when there are “worms” that traverse the Internet and crack security wide open, it is because someone has discovered a vulnerability in the software that “listens” at a port for a particular protocol. The worm uses the vulnerability to gain access and control of a computer, and subse- quently install itself and then pass itself on to other computers. Now, all packets that are on the Internet are either User Datagram Protocol (UDP) or TCP/IP packets, but within these “suites” are hundreds of application layer protocols, such as Simple Mail Transport Protocol (SMTP) or Dynamic Host Configuration Protocol (DHCP). If a firewall does not offer or permit filtering and

blocking of these application protocols, then it’s not really a firewall; it is a router.

It is important in the evaluation process to clearly identify every port and protocol that an organization uses. New applications should be tested in an isolated environment to ensure compliance and to ensure that junkware does not install additional, undesirable communication components. As wonderful as it may seem to soft- ware and hardware marketers, a software component that sends a message to them every time a printer is low on ink does not consti- tute networking best practices.