Network Computing is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Why Blacklisting Works

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 George
As 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.

  • 1