Many security officers dream that “deny by default, explicitly permit” was fully implemented and consistent across their IT infrastructure with “utilizing the most granular criteria possible” as the driving policy. Unfortunately their dream is the nightmares of the security operations managers that must manage and maintain this level of access granularity in the IT infrastructure.
“Defense in depth” is a best practice strategy for architecting security solutions. In its simplest form, “defense in depth” includes the use of process and technology at each layer in the OSI model. For our security operations manager, this means an added multiplier of configurations that need to be maintained each configured to the policy of “utilizing the most granular criteria possible.”
For many organizations the most “granular criteria possible” is IP address and port numbers. For firewall configurations and router ACLs in a large enterprise this can equal hundreds or thousands of lines listing permitted source/destination IP address and ports for an application. Multiply this by the number of applications and you quickly get an idea of how much configuration the security operations engineer must wade through when adding, deleting, or troubleshooting access. This complexity requires lots of planning to assure accuracy given limited maintenance windows for operations that have to deliver to greater than 95% up time.
But even with the most fastidious of engineers, over time your configuration ends up full of “stale rules” for applications that may no longer exist, overly permissive rules that were meant to be temporary during a troubleshooting session that should have been removed, or IP addresses that should have had their access removed to a particular application. In short, you have configurations deployed that are full of bloat, inconsistency, and possibly insecure. Indeed automated network security policy management solutions can do much to improve this but how much resource on the network security devices do these configurations consume when implemented. Is there enough remaining capacity for the network security devices to withstand an attack? Is this bloat contributing to latency to services permitted?
Though a policy of “utilizing the most granular criteria possible” may be considered ideal, when practiced it could actually breed a less secure environment unless you employ automated network security policy management solutions AND have the budget for network security devices designed with the capacity to meet the resource demands of your configurations. You may find that your medium enterprise may require a carrier-grade network security device because your policy of “utilizing the most granular criteria possible” manifests thousands of lines of access control statements. For sectors such as government and military this may be fine and will look expect the market meet the demand if current devices do not meet their needs. For many corporations this may not be an option.
A policy of “utilizing the most granular criteria practical” versus “utilizing the most granular criteria possible” serves to accomplish the same goal but can yield better results. “Strength in architecture” is an implementation of “defense in depth” that employs standards based solutions, utilizes industry best practices where standards may not yet exist, and looks to leverage existing IT architecture where applicable. If your network architecture is partitioned into segments you could simplify your perimeter configurations greatly by leveraging your existing internal routers at key distribution points with a few ACLs. “Strength in architecture” adds an additional dimension to the “defense in depth” strategy.
Figure 2 shows a logical diagram of a partitioned network. We could put a few ACLs at the distribution routers to layer our security as well as simplify the ACLs that need to be maintained across the infrastructure. Since the desktop segment should never be hosting applications a minimal ACL can be deployed at the distribution router that only permits outbound connections from the desktop segment to all other segments. The web farm could have a minimal ACL deployed at the distribution router that only permits inbound HTTP, HTTPS and FTP-PASSIVE connections from the desktops segment.
Maybe a fully a segmented network according to function remains a dream in your organization and your environment consists of a number of networks bolted together over time due to the expansion and contraction of the business. As you may have already experienced, the lack of architecture greatly contributes to large access control lists due to the disparate IP address ranges that need to be entered.
No doubt your network group has been looking to redesign the network architecture to address performance and capacity concerns but lack the backing for sufficient funding to make it so. This is where security can be the business enabler in working with networks to help justify network architecture improvements showing that it will also benefit the security of the infrastructure by simplifying ACLs to be managed, reducing resource required by network security devices, and improved response and resilience to threats. Leveraging existing internal distribution routers and their security features can be more cost effective and less impact to operations than looking to add firewalls.
Hopefully this article has demonstrated to you how an overly restrictive policy statement of “utilizing the most granular criteria possible” can increase security risk in management complexity and reduced capacity and responsiveness to threats. While a policy of “utilizing the most granular criteria practical” that uses a “defense in depth” strategy that follows a “strength in architecture” implementation can provide a level of security that has the capacity and responsiveness to meet the your threat profile.
Solsoft is exhibiting at Infosecurity Europe 2006