What can be done to prevent a hacker who's obtained DIC and UIC information from accessing my network?
Editor's note: In a recent Ask the Expert (ATE), Joerg Hirschmann discussed the merits of attribute-based access control (ABAC) and its ability to safeguard remote access control. ABAC uses two concepts -- device identity class (DIC) and user identity class (UIC) — in addition to a relationship registry to ensure network security. In this ATE, Hirschmann talks about steps an organization can take to prevent a hacker armed with DIC and UIC information from accessing its network.
As I have stated, internal corporate networks are a lot like bank vaults, and like vaults, they are protected by separate and distinct security methods that govern access and control.
But what happens if hackers obtain the keys protecting your corporate network — in this case, your user identity class and device identity class information?
That's where the real nightmare begins, as they can roam free in your network. There are a number of elements that make up hardware and software identities. One example would be a Media Access Control (MAC) address, which is specific to an individual endpoint device used to access the network remotely. When a user tries to connect to the network, a correspondence table checks the physical MAC address against the user's IP address to verify his or her identity and network privileges. If they don't match up — per remote access policies set up according to established device/user relationships — the user is out of luck.
If only the story ended there. Unfortunately, cyber-criminals are more than persistent. They spend inordinate amounts of time and effort on circumventing network defenses, including devising ways to spoof MAC addresses so they can fool the network into thinking that an authorized user is making the connection. Now, access control policies based on those relationships allow network access to the very individuals you're trying to keep out.
VPNs could be configured to protect against such threats by incorporating endpoint health checks that look specifically for indications that the MAC address has been spoofed. If any anomalies are detected; e.g., the MAC address has changed but the network adapter hardware has not, the user and connection are properly evaluated and access can be restricted to protect the network. Only if the appropriate device and user criteria are met will access be permitted according to the established role-based access policies.
In the meantime, the Trusted Computing Group is in the process of developing a very promising network security architecture that would include attribute-based access control defenses and govern remote access for corporate networks.
As that work is being completed, however, there are steps that can be taken within existing technology parameters to prevent things like MAC address spoofing from gaining a foothold. For example, create a certificate container with a PIN – unknown to anyone -- that is automatically derived from various pieces of hardware information (like a hard drive serial number). This guarantees that the certificate cannot be used on a different computer, no matter how an attacker may attempt to copy it. The hardware certificate is bound to the hardware, building in a more secure VPN-based access control approach.
This was first published in January 2014