Why Blacklisting Works
When deploying in-line NAC products, a default allow deployment which means allow everything that is not explicitly denied is more efficient and effective than a default deny deployment where everything is denied except what is explicitly allowed.
November 1, 2007
As I work my way through testing in-line NAC devices from vendors like Consentry, Juniper, and Nevis, I learn not only about how the products work, but also about deployment options and stumbling blocks. Some of those lessons come purely through product testing; some lessons from talking to system engineers who are out deploying their products; and some lessons are a combination of both. I want to test the waters with the following thought. When deploying in-line NAC products, a default allow deployment which means allow everything that is not explicitly denied is more efficient and effective than a default deny deployment where everything is denied except what is explicitly allowed.
Default deny is considered better for security deployments because all access is denied from the start and then access is opened as needed. The idea being, often proved out in theory and practice, that the required resources you need to allow access to are known and fewer than the resources that should be denied. For a network firewall, when the final rule is deny all, any rules above allow access and is effective for a border firewall blocking inbound access. More often than not, the outbound access rules are much more open akin to a default allow. Determining what outbound access should be allowed is much more complex because determining what resources a user or group of users need changes often or the protocols are complex. Denying outbound access is just more work than allowing it.
When in-line NAC is placed in a default deny deployment, the same issues crop up but are exacerbated because many technical processes are difficult to nail down. Let???s take as an example allowing access to Active Directory so a domain user can log-in. It???s not as straight forward as it seems. While testing Consentries product, I tried to develop a fairly tight policy that allowed only certain protocols to the AD server.
The LANShield did exactly what I configured it to do, and while I could authenticate to AD, I was unable to get a GPO update. I know that I was doing something wrong, but I didn't dig in enough to figure out what I mis-configured. It wasn't until I was talking to an SE for a different vendor while at lunch, that he explained that a tight policy is difficult to accomplish because many LAN applications, like authentication to AD, require far more access than you might think is necessary. For example, the domain computer wants to ping the AD before requesting the GPO policy. If ICMP is denied, which is how I configured the LANShield controller, the GPO won't be updated. Go figure.
Object lesson: Opposite GeorgeAs we continued talking, the discussion turned to default deny and default allow; the impact of either deployment on management efficiency and effective access control. Maybe, a default allow stance is a better deployment option than default deny as a general principle. I was thinking the opposite of what I should.Sure, you can, given time, define and refine a default deny NAC policy for internal use. You might even be able to get it deployed for awhile, but eventually, the policy will become complex and difficult to manage. Dare I say, impossible to manage. Unless your organization has pulled back all the servers, including departmental network file storage, into a centralized location, a strict policy will soon become riddled with policy statements granting access to specific users to specific resources. These are the exceptions that will pollute a strict policy and make management difficult.
Rather than running down that path, a more effective access control principle is to allow all access and then explicitly deny access to resources as needed. For companies to be nimble, users have to collaborate across business units and geographic regions. It's easier to define what resources users shouldn't have access to. For example, your sales people probably don't need access to your R&D servers. Likewise, your engineers probably don???t need access to your ERP systems. You get my point.
By balancing access control through explicit denies with efficient and effective management, you can achieve a manageable deployment without adding significantly to your management overhead.
Read more about:
2007About the Author
You May Also Like