Inband (inline) or out-of-band? Pre-admission control only or post-admission control too? Agent-oriented or agentless? What drivers pushed you down one path or the other?
If an inline solution, were processing overhead and network bottlenecks an issue? Interoperabilty with existing switch and routing infrastructure and support of advanced feature sets (eg. multicast controls, PoE etc)?
If an out-of-band solution, do you have the control you need? Have you needed extensive programs of upgrading infrastructure h/w, o/s, firmware etc just to get it to a level to support NAC?
I've Googled, I've signed up to various email lists, spoken to manufacturers, distributers and resellers at various IT and Network Security trade shows, attended presentations and roadshows, and found solid arguments for and against each approach, with everyone vociferously and eloquently defending their corner. I now want to lobby the end user community the coal-face implementors and conduct a straw poll - find out which way you’ve gone, how you’ve done it, where was the pain and where was the gain, what informed your decision processes etc. A vast subject I know, not least the question of "What is NAC to you...?"
Clarification added 4 months ago:
I've had some very interesting and thought-provoking answers to this question, thanks for that to all respondees. However, a lot have been from SE/NEs and vendors, and I'm looking for more subjective (ie. customer experience-driven) input from end-users and implementors - will extend this question awhile more... thanks again to all.
Clarification added 4 months ago:
Ian Gorrie writes: "It makes me wonder if the question has been constructed without a problem in mind".
KA-CHING! Precisely. I had hoped I'd made it clear that I was casting around for "different" user experiences - as I said, it's a vast subject and depends greatly on the interpretation of the definition "NAC". As a NI/SI we have a vendor solution presented to us that we are tasked to bring to market (this echoes Joe Provo's closing comment very well), but I regard myself as an "independent" and open-minded technologist, and so wanted to see (via this forum) what considerations need to be taken into account when choosing a NAC solution - not "I have solution A which I will shoehorn into your organisation", but "what is your requirement, will solution A cover it or do I need to recommend an alternative approach (which may well fall outside our portfolio, but hey, we're getting consultation revenue anyway)".
Self-serving comments like "Constructing a problem and finding a solution for it may be an exciting exercise, but it is not a very useful one if it doesn't serve what should be the greater business goals of the organization" may stoke your ego for having written it, but do little to help in this Q&A forum
Taking this from a "perfect world" perspective, in-line is likely the best. Security controls applied prior to allocation of authority and/or access is, in the larger picture, is far more effective or security purposes. The use of out-of-band is predominantly the result of technology limitations, not necessarily operational or security limitations. In other words, OOB would be the result of distant pressures as opposed to those relative to security, i.e. bandwidth and technical infrastructure's ability to support the strategy.
As far as using an agent. Again, the best scenario is agent-less. First and foremost agents cost money. From software licenses and administrative costs to life cycle management and interoperability, agents are simply a pain. Secondly, not all agents are "protected". For example, they can be disabled by the user. We saw this a lot a long time ago with single tunnel VPN clients. Users would simply disable the client to access the Internet freely, by passing enterprise controls.
I know this is a theoretical answer and may not be much of a help. Nevertheless, when considering something as broad and deep as NAC, you have to ask yourself the pros and cons in a security light and once you've evaluated the security aspects, determine what exists and what is needed to facilitate those identified needs and wants. Having said all this, it's important to acknowledge that any NAC is good. Any proactive method to control access is a positive, regardless of agent/agent-less or IB or OOB.
For a more specific answer, bandwidth, processor, and single points of failure will be a big challenge. and if these cannot be overcome, OOB is likely the best from a general perspective, but may not be in a pure security one
The answer to this depends on the customer's network topology, switching infrastructure, bandwidth requirements, bandwidth control requirements by role, and security policy.
From the Cisco Clean Access perspective, you should choose In Band (IB) if you need to control end-user bandwidth usage, if you don't have the right Cisco switches at the Access layer, or if you're doing Network Admission Control for VPN or wireless users. Obviously, if the customer project or security policy requirements state to use IB, then that's what you use.
Choose Out of Band (OOB) if you have the appropriate Cisco switches at the Access layer, if you need more than 1 Gb/s of bandwidth per Clean Access Server (or high-availability pair), and if you don't need to control end-user bandwidth. VPN and Wireless don't work with OOB.
You can have a mixed IB and OOB environment with Cisco, but each Clean Access Server (or HA pair) can do either IB or OOB, but not both. So for a fully-redundant mixed environment, you need six servers: two IB CAS's, two OOB CAS's, and two Clean Access Managers.
I think a general rule of thumb goes: Out-of-Band when you can and Inline when you must. The must can be because of the current infrastructure at the client, out-of-band does have a major drawback with Cisco CCA, with CCA it doubles the amount of VLAN's (with large organisizations this can be an administrative hell or not an option, double from 100 to 200 VLAN's). Inline solution directly impact you networkavailability by adding components inline, a major drawback.
Do not look at the Cisco NAC Framework yet, currently the Clean Acces Appliance is promoted by Cisco. A clear view on CCA and 802.1x integration however is not yet present, but under development
A vendor to look at is Juniper and their Unified Access Control. Customers have to protect their internal resources more and more anyway and the UAC is very sweet and let's you control user on different levels on Layer 3-7 and at later stage at 802.1x and L2 control. The control is done with Controllers (they authenticate the users) and Enforcers (actually the Juniper Firewall) that dynamicly open the resources for the users. Juniper currently has the biggest Firewalls in the marketplace with 30Gigs and up performance so scalabilty is not an issues here.
Links:
http://www.juniper.net/products_and_services/unified_access_control/index.h...
http://www.cisco.com/en/US/products/ps6128/index.html
http://dimension.networkworld.com/symantec/cramsession.html
Jako Boonekamp also suggests these experts on this topic:
Charles van Iersel
Peter Mesker
Access/admission in-band.
If you have a need/requirement for guest access or sandboxing, then post makes sense. If your revenue is tied to the network then only pre.
Agents or specific software are only of value in a closed community with static configurations, *one* standard software load and flat internal support costs. If you have any sort of call center, standards-based challenge/response (password, tokens, etc) are a must else you will be drowning in support headaches.
If you do not had the headroom for simple authentication & admission controll, then you do not have the headroom to pass the customer's actual traffic. Network bottlenecks then become a non-issue. Payload concerns (mcast, etc) are going to be specialized per network.
Don't believe any hardware vendor, as they will sell you 100% their prepackaged solution which will work in 'most' cases, and fail to consider your 10-20% vocal one-off userbase cannot use.
Of course, the correct answer is "it depends".
If you are managing a low-bandwidth network with specific requirements on guaranteed user-plane performance, you would manage out-of-band.
If you are managing a gigabit, best effort network, which could fall over and no-one would care, you'd manage in-band.
If you were managing a megabit network, with specific availability requirements, you'd do both - inline for low cost, with out-of-band for the time the inline link goes down.
Something I've been looking at (from an end user perspective) for a few months, and was quite heavily represented at InfoSec this year
I have been led to believe that the Cisco solution OOB would only be supported with Cisco switches - so this is a consideration.
How to deal with smaller remote satellite offices? Having to deploy a full-on inline device to a small office with no permanent IT staff, or a smaller / no device on site and go OOB with the "brains" back at head office?
Juniper's solution pulls heavily from their SSL VPN technology for the pre-access scan. Secure Computing's SecureWire also kind of sits in both SSL-VPN and NAC camps.
InfoBloxx have some kind of NAC framework that (I think) ties into their DHCP server. This is another way of doing it - for example LanDesk can tie into the device management database to know about the status of a system and control the IP address accordingly (updates in the product roadmap have more options).
Bradford Campus Manager and Lockdown Networks seem to be the front runners for OOB, switch agnostic solutions (that I have discovered). Both claim to cope with a hetergeneous mix of devices (and have the option of installed, temporary or no client agent). I love asking the question "how do you cope with an Xbox360, or PS3?"... not your usual kind of corporate network device, but that's what I have to deal with
The NAC space doesnt have a clear answer on this, imo.
In my market sector the security and control needs are more demanding. Thus, agents on endpoints are required (for fine grained control and surveillance of endpoints). Out-of-band control channel signaling is being used for certain security reasons, and to eliminate single points of failure. Out of band also allows the NAC archiecture to act independent of edge switching. In our environment, the network layer is very heterogenous (million devices out there). We did NOT need to upgrade HW/SW/OS on end points. WinXP SP2 is quite ok. Other OS's are also supported (Solaris, HPUX, Linux, Mac, etc.)
The other interesting question is what happens when a "bad" device attempts to connect. You dont want to create a trouble cascade into the helpdesk when you light up NAC.
Links:
http://www.innerwall.com
Your answer is really going to depend on a few basic things.. (1) how granular you want your control to be, (2) how secure you want your hosts, (3) how much you want to spend (this includes costs to maintain and operate), and (4) how complex you want your solution to be.
posted 4 months ago | Flag answer as...
Ian Gorrie
Certified Technology Security Advisor, Consultant, and Advocate
see all my answers
Best Answers in:
Information Security (3)... see more, Computers and Software (1) see less
This is an interesting question. It makes me wonder if the question has been constructed without a problem in mind.
I've seen several organizations where an executive goes to a conference and comes back with a "We need to implement [some technology] ASAP!" mindset.
Many other people here have responded with a "Well it depends" answer and, of course, the predictable vendor-responses.
Really you need to be conscious of the holistic nature of what you are talking about and how this solution, if you are in need of such a solution, fits into your perimeter controls. No two businesses have the same risks, topologies, or partner networks, so requests for "where is my cookie-cutter uniform solution?" that come across on mailing lists and forums such as this all the time are really an exercise in folly.
Constructing a problem and finding a solution for it may be an exciting exercise, but it is not a very useful one if it doesn't serve what should be the greater business goals of the organization.
Network access control (NAC) has become an inescapable network security buzzword.
With 50-plus vendors claiming to have some form of NAC solution, the landscape is cloudy and confusing. If the vendors are right, the time to deploy NAC is now. And, in many ways, those vendors aren't too far off.
"There's a lot of overhype," said Gartner Inc. vice president and distinguished analyst John Pescatore. "All of the vendors have something they call NAC. But you don't have to wait to start implementing these technologies."
According to Pescatore, companies must first take a look at exactly what problems, or pain points, they're looking to NAC to solve. Those problems could dictate which type of NAC deployment is a good starting point.
Define your NAC goals
"Everybody's really high on NAC," said Andrew Braunberg, senior analyst with Current Analysis. But he added that determining NAC readiness and need boils down to a few seemingly simple questions an enterprise must first ask itself. "The things to keep in mind are: Where would you start? What's the pain point I'm trying to address? Can an NAC solution hit that mark? What would be the overall extent of your NAC solution when you're done?"
By and large, Pescatore and Braunberg agreed, enterprises are looking to NAC for guest network access. And while safe and secure guest access is a valid reason for NAC consideration, it doesn't require an all-new infrastructure to accommodate the likes of Cisco's NAC framework or Microsoft's NAP.
SPECIAL REPORT
NAC – More than endpoint security
Network access control is a hot topic and a challenging one. Learn the ins and outs in our special report:
>>NAC: Should you implement now?
>>NAC and endpoint security frameworks: Which way to go? >>NAC appliances: Shortcut to access control
>>NAC underneath the covers: Endpoint health assessments >>Defending an expansive definition of NAC
Braunberg said figuring out the scope of an NAC rollout beforehand is beneficial, especially when many companies have a mindset of "What good is NAC if you don't have it everywhere?"
"I think people should start addressing the pain they're feeling now, but there's still a lot of market education to be done," Braunberg said.
Senior Burton Group analyst Eric Maiwald agreed. When asked whether enterprises should start considering NAC now, he said, "I don't know that there is one answer to that one."
Maiwald said companies have to evaluate what's driving them to NAC. For the most part, organizations are considering NAC because it's the latest and greatest technology, because of compliance issues, because they want to control malware, or because they want to control guest, or non-employee, access.
"Controlling who can be on your network is something that should've been done a long time ago," Maiwald said. "Is NAC really something new, or is it the next generation of vulnerability management? Is it the next generation of intrusion prevention?"
Since NAC can be deployed at different points in the network -- inline, out-of-band and as a software agent -- companies need to look into where their enforcement points should be.
"The enforcement point is one of the keys here," Maiwald said. "Where do they want to do the enforcement? If I put it inline, what do I do if the device fails?"
Enterprises should also weigh which type of NAC is the least intrusive in their environment. Is it an inline solution like those from ConSentry, Vernier and Nevis; out-of-band like Lockdown and Forescout; or software agents like Elemental and InfoExpress?
"It does seem that the inline and out-of-band devices are getting a lot of the attention," Maiwald said.
The five functions of NAC
Braunberg said a complete NAC solution should fill five holes. It should run a pre-admission check, a host posture check and a post-admission check. It should also be ID aware and aware of ID-based network resources.
Overall, Braunberg said, there isn't one vendor that hits all five segments with a best-of-breed solution. But for the most part, the technology is mature enough to get adequate coverage in each of the designated areas. Right now, he said, Juniper's second phase of its Unified Access Control product has the broadest approach.
Still, for an enterprise to get its initial NAC deployments in gear, Braunberg added, it's not necessary for all five NAC segments to be hit.
"I don't think you need to go out and address all of these areas to get value out of NAC today," he said.
Gartner's Pescatore said there are three broad types of NAC technologies, all of which hit different levels of monitoring. First, there are infrastructure upgrades from the likes of Cisco and Microsoft. Those are the most complete NAC solutions, he said, but many companies won't come out of the NAC gate with such a pervasive deployment because of the hefty price tag and complete infrastructure upgrade that's necessary.
"The vast majority of enterprises are not ready for that," he said. "We tell clients, 'Look, if you have upgraded your Cisco network, it's something you should look at.'"
((Content component not found.)) NAC is also available in the form of software agents, such as antivirus, personal firewalls and configuration management tools, Pescatore said. Several small vendors also make NAC boxes. Those boxes won't hit every existing NAC pain point, but they do open the door for a more expansive deployment down the road.
"Sit down and figure out what's your real motivation for network access control," Pescatore suggested.
Some companies want to determine whether a device is dangerous, or not vulnerable, before it's allowed onto the network. Others have to allow non-employees and non-employee PCs onto the network.
"If that's your whole motivation," Pescatore said, "you don't really need to go through the expense of everything involved in a full upgrade."
Other companies are motivated by a combination of security concerns. For example, a company may want to allow non-employee PCs onto the network but may also be looking for tools that can monitor the network for potential security threats.
"You can start small, do guest networking and then move on," Pescatore said. "If the network group is next year upgrading the routers and switches, it's OK to look at [Cisco NAC and Microsoft NAP]."
Some companies still question the maturity of NAC technologies in the booming and hype-filled market, but Pescatore pointed out that several companies are now using various flavors of NAC without any major hang-ups. As for full NAC frameworks, he recommends taking baby steps.
"Lots of companies are using it for guest access, and it works great," he said. "The real issue is that the big bang approach rarely works unless you're experiencing a big bang."
Still, no matter where the starting point is, Pescatore added, any level of NAC deployment "is not a throw-away investment."
No comments:
Post a Comment