So, you’ve spent large sums of money investing in the latest next-generation firewall with IPS, application visibility and anti-malware features, your firewall rules are locked down to the bare minimum required and you have implemented two-factor authentication for all of your VPN traffic. That’s great! But what are you doing about internal security?
Too often organisations seem to get tunnel vision and focus exclusively around perimeter security. Don’t get me wrong – perimeter security is incredibly important, however it is not the only area of the network that requires your attention. Too many networks lack any kind of access control on their internal wired network leaving it open to anyone who can plug a device into it.
“Our office is physically secure – therefore this isn’t a problem. We have a policy to challenge anyone we don’t recognise”
You may well have a policy, but how often do you actually think this is applied in real life? In general, us humans like to avoid confrontation and the idea of walking up to a complete stranger, asking them who they are and why they are here is enough to put a lot of people off taking any action. Sure, there will be exceptions to this and certain organisations with more stringent requirements implement this aggressively, but I imagine the more common theme is for people to just walk on by. What about the smartly dressed person in the suit walking behind you through the door, or the one carrying the heavy box – are your employees going to challenge them or just smile and hold the door for them to be polite?
The point I am alluding to here is that if an attacker wanted to gain physical access to your wired network it is (in a lot of cases) relatively trivial to do. This tells us a couple of things – firstly a good physical security policy is important and auditing this to ensure it is adhered to is equally important. Secondly, you need an additional line of defence against this – something to catch those who could manage to get physical access.
Don’t think an attacker walking into your network and plugging in is your only problem though – what about the following scenarios:
- Someone decides to bring in their own access point as the wireless is non-existent or poor in the office. How do you stop them plugging in an unencrypted or weakly secured access point and broadcasting your internal LAN to everyone in the vicinity of the building?
- Someone decides to bring in their home laptop and connect it to the network which also happens to be full of malware
- Someone decides to bring in IoT device which just happens to be vulnerable and part of a Botnet such as Mirai
These are much more likely scenarios, all of which can be successfully mitigated with a correctly implemented Network Access Control (NAC) solution.
What is NAC?
So what exactly is NAC? You’ll hear different definitions and to be honest the term NAC can encompass a lot of different things, but to put it simply in my opinion it is…
A solution that has ability to control endpoint access to the network based on attributes of the connecting device, user or both and optionally to be able to apply some form of dynamic role-based access control to a session
NAC is carried out using a number of different protocols and features (something we will delve into further in a later blog) and varies depending on the vendor’s solution but ultimately tends to boil down to two main aspects; authentication – did the user or device prove who they are; authorisation – based on the authentication status and other attributes what are we going to allow the connecting device to do?
The benefits of NAC
When implemented correctly NAC brings with it a lot of benefits, including:
- Stronger Security – For the reasons outlined earlier and some more advanced ones we won’t get into right now, NAC has the ability to greatly improve your security
- Improved Visibility – Many NAC solutions will provide administrators with a lot of information which can assist in general troubleshooting. This includes basic information such as IP address, MAC address, switch and switchport as well as more advanced information such as device make/model, operating system and compliance status (e.g. “does the device have AV installed and is it up to date?”)
- Dynamic Control – If the device is not an authorised corporate device what should happen to it? Should it be put in a specific VLAN or restricted with an access-list? Both of these and more can be done dynamically on the fly without administrator intervention
- Reduced Admin Overhead – Yes, getting a NAC solution in place and working requires a substantial amount of work, but once it is deployed it can vastly simplify network management. No more calling the helpdesk team and asking “can you put port xyz into the guest VLAN” – just let the NAC solution take care of it
- Enhanced Capabilities – If you’ve previously shied away from implementing any kind of BYOD policies for fear of how you were going to manage it, then some NAC vendors can help you here and can help streamline the registration, restrictions and revocation of such devices
What about wireless?
Though we’ve primarily discussed wired above, NAC solutions are equally as relevant when it comes to securing wireless networks. If you’re using the weak method of Pre-Shared Key (PSK) to secure your wireless then NAC can help you move away from this by providing a centralised authentication point for WPA2-Enterprise based wireless networks. No more rotating wireless PSKs when someone leaves the organisation (you do that… right?) and much stronger security with per-session encryption keys. On top of this you can still leverage the advanced features such as compliance checks just like you would on the wired network.
Another common use for NAC solutions with wireless is to provide guest services for visitors. Instead of providing visitors with PSKs to access the network or just leaving it fully open to all and sundry, NAC solutions commonly allow you to provide guest services that are usually either sponsored (e.g. the person you are visiting generates your login credentials/passcode) or self provisioned where the connecting guest enters some details, accepts an acceptable use policy and gets access to the Internet.
Why are some organisations avoiding NAC?
From my perspective I think there are a few main reasons that organisations tend to avoid deploying any kind of NAC solution to their network.
- Cost – There seems to be a perception that NAC solutions are all really expensive. Granted, some NAC solutions are expensive, but for simple networks that don’t want or need all the bells and whistles this needn’t be the case. If you have a Microsoft Active Directory environment with few additional device types, then you can easily and cheaply implement a fully working NAC solution utilising the NPS/NAP services built into Windows Server
- Complexity – Yes, there is no getting around it – deploying NAC to the whole of your wired network requires some substantial effort and understanding of what you are doing. Get it wrong or implement it in a rush and you could end up locking people out of the network – not a good move. However, once you get to grips with what is required and how to deploy in a phased manner, it isn’t that bad and can usually be done with zero or minimal downtime
- Compatibility – When it comes to wired NAC on vendors other than Cisco I have little experience, however I believe there is the likelihood of compatibility issues. What if you have HP switches deployed? Can they still work with a NAC solution from Cisco for example? Chances are at a basic level the answer is yes – if you are running an up-to-date software I’d imagine so. However, don’t expect to get all the fancy features Cisco will tout if you aren’t running a homogeneous Cisco network – you may have to compromise on features
How are organisations deploying NAC?
As highlighted earlier, NAC can look to consider the device, the user or both when determining what access to grant. From the majority of NAC deployments I have been involved in the client has been running a predominantly Windows environment with a handful of other devices you’d expect to find such as phones, printers and video units. Their main reason for wanting to deploy NAC has been to restrict what is connecting to the network and as such I’ve designed a solution that looks to authenticate their devices to the network rather than say the user. Why would you not want to just authenticate the user? If you do this, there is nothing to stop Joe Bloggs bringing in his home laptop, configuring the right settings and getting on the network still – even though it is not an approved device.
I’ve also worked with clients who needed to take both the machine and user into account in order to restrict access based on the group the user belongs to. This requires some additional effort and at the moment 3rd party software on the endpoints, but is a nice secure solution. An example of how you could use this:
- If only the device is authenticated (i.e. the user isn’t logged in or failed authentication) – just grant them limited access to the network. Maybe just to talk to domain controllers for authentication for example, or a patch management server to receive updates overnight
- If the user and the device have both authenticated, then provide them further levels of access. You may then choose to restrict access based on group e.g. the PCI group can get access to the PCI servers, but no one else
Of course, there is a lot more to deploying NAC than this, particularly when it comes to wired networks. What about the devices that can’t authenticate them? How do we treat them? I intend to discuss this and more in a future blog post where I will delve further into the underlying processes.
If you take away one thing from this blog post I hope it is that you will consider deploying NAC. As I say, there are many vendors out there with differing solutions from the cheap and simple to the expensive and exquisite – think about what you want to achieve from the solution and find out more on the features they offer.
Questions? Comments? Feel free to get in touch!
2018-05-26 01:00 +0100