This article is part of the Identity and Access Management Security School lesson on integrating security into the network. Visit the Integrating
Regulatory compliance, driven by regulations like HIPAA, GLBA, Sarbanes-Oxley (SOX) and most recently the PCI Data Security Standard, continues to dominate the discussion in executive suites relative to security topics. Compliance also remains one of the catchwords for security vendors as they try to position their technologies as a "must have" in the eyes of security buyers.
One of the hottest spaces in the security space is network access control (NAC), and predictably all of the vendors are positioning the compliance "virtues" of the technology. But is there any truth to their claims? Should customers be looking at NAC to solve their compliance woes?
NAC is about ensuring only the right people get access to the right resources. It works by performing "pre-admission" scans to ensure devices are both authorized and not contaminated with malware when joining the network. Once on the network, NAC solutions then switch into "post-admission" control mode where they are making sure that each endpoint is accessing authorized resources and don't start behaving erratically. Of course, we're still early in the adoption of NAC and the vision is not yet the reality – but that's the idea.
So what does NAC have to do with compliance? The answer is plenty but to be clear, NAC is not a panacea for compliance – nothing is. From a network standpoint, compliance can be largely represented by the following five requirements. Of course, this list is not exhaustive (lots of folks have much longer lists), but here goes:
- Policies – All of the major regulations require documented security policies to prevent intrusion and protect private information.
- Authentication – Verify a person requesting access to sensitive information is the one claimed.
- Access control – Ensure the systems, applications and data are accessed only by those granted sufficient privileges.
- Remediation – Capabilities to respond to a security incident, both notifying interested parties and ensuring safeguards are in place to contain damage.
- Audit – Documentation and artifacts relating to the use of systems and applications accessing private data.
Now NAC doesn't do much to help you document your policies. You are on your own for that. I say that somewhat tongue in cheek, but not really. Whether you're just trying to increase the security of your environment, or need to comply with some regulation – it all starts by figuring out where your most valuable data is and putting in place adequate controls to protect it. NAC does help in enforcing those policies and also providing data to report on what's happened relative to those policies.
Authentication, access control and remediation are where NAC will have the most impact on your compliance efforts. Let's hit them in turn:
- Authentication – NAC can require many different levels of authentication before providing access to the network. Most solutions can integrate with existing LDAP directories, RADIUS servers and support multi-factor authentication. Score one for NAC.
- Access Control – They don't call it network ACCESS CONTROL for nothing. NAC solutions can ensure that only users and/or groups given explicit authorization can access resources. There are lots of different enforcement mechanisms (inline, DHCP, 802.1x, VLAN, SNMP, etc.), but all stand up to the scrutiny of compliance requirements.
- Remediation – Once an issue is detected, the same enforcement mechanisms controlling access can be put in place to quarantine the "violators."
Audit is the last piece of the puzzle, and NAC can become a significant data source for external log management and reporting mechanisms. NAC products can log every request to access network resources, as well as when policies are violated.
So what's the catch? Why wouldn't you just implement NAC everywhere in your network and get a big leg up on compliance? Actually there are a few reasons, the first being cost. Even overlay solutions (that work with your existing switches) are pricey. NAC products are still an early market and volume curves have not yet driven prices down. That'll come in 2007-2009.
Second, the maturity of the solutions is still an issue. We are talking about hundreds of deployments, not thousands – so you'll be in the early end of the implementation curve. That usually involves troubleshooting and working out the kinks of the implementation yourself.
Finally, NAC (at least within the context of compliance) is hard to do halfway and be effective. As they say with most security activities, the chain is only as strong as the weakest link. To get the full benefit of NAC, it needs to be deployed into your network - fully governing all users that want access and seeing all traffic to provide post-admission control.
Of course, baking NAC into your network will take years. I recommend you start small, using NAC to protect the highest value applications and data – basically building a moat around these highly valued assets. And as you upgrade your networks, look for new switches that can support NAC and higher levels of security. In a couple of years, you'll be there.
About the author
Mike Rothman is President and Principal Analyst of Security Incite, an independent information security research firm. Having spent over 15 years as an end-user advocate for global enterprises and mid-sized businesses, Mike's role is to educate and stimulate thought-provoking discussion on how information security contributes to core business imperatives. Prior to founding Security Incite, Mike was the first network security analyst at META Group and held executive level positions with CipherTrust, TruSecure and was a founder of SHYM Technology. Mike is a frequent contributor for TechTarget and a highly regarded speaker on information security topics. Keep track of Mike's musings via The Daily Incite newsletter.
|IAM SCHOOL HOME||INTEGRATING SECURITY INTO THE NETWORK LESSON HOME||INTEGRATING SECURITY INTO THE NETWORK WEBCAST||INTEGRATING SECURITY INTO THE NETWORK PODCAST|
This was first published in August 2006