You’ve done everything to secure your network, and you still face threats. That’s what most enterprises say about their network security, and they’re half right. Yes, they still face threats, but they’ve not done everything to address them. In fact, most enterprises haven’t really implemented the two foundations on which real network security must be based.
When I ask enterprises whether they’ve done a top-down analysis of network security, they usually say they do it every year. When I ask what’s involved in that assessment, they say they look for indications that their current strategies have failed. They build another layer, which is kind of like putting a second Band-Aid on a cut.
Forgive me, but that doesn’t sound very “top-down.” Modern network security should start with the simple requirement that nobody should be able to access anything they’re not supposed to be accessing. Here’s Charlie, who supervises parking-lot maintenance. Suddenly, Charlie is reviewing last quarter’s sales records, or checking out the inventory level of some products. Are these products perhaps wearing out the asphalt, or is this a signal of a threat from Charlie, or malware?
That’s not just true for the Charlies of our enterprises, either. Chugging along in the data center is an application that monitors the state of the doors in the headquarters campus. Suddenly, this application is accessing a module associated with the payroll system. Unless we think doorknobs are on the payroll, this should be a warning sign, too. IP networks are connection-permissive, which means they’re connection-insecure.
Connection-permission security
The problem with connection-permission security is that it’s inconvenient because it’s complicated. Start with “Charlie,” not as an example but as an individual. Because Charlie has inconsiderately declined to be implanted with a MAC-layer address chip, he has no specific network identity. Do we assume a device assigned to him serves as a firm identity indicator? What happens then if Sandy sits down at Charlie’s desk to do some quick little application tweak? She shouldn’t inherit Charlie’s privileges, but she probably does.
Maybe Sandy gets a promotion or a new assignment. What she’s entitled to access has now changed, but NetOps forgets to update their magic connection monitor, and so Sandy’s first report is late. Meanwhile, NetOps is unhappy because every time somebody’s role changes, they have extra work getting them connected to all the stuff they need and sorting out innocent mistakes that generate unauthorized access. They decide to change the system so that every worker has a “role” that has connection permissions. Now we just assign everyone to their proper role, and everything is fine…maybe.
The concept of a “role” is very useful in limiting the number of explicit connection permission policies an enterprise needs. However, it depends on two things. First, the role’s rights must be strictly set to ensure that nobody has access to things their job doesn’t justify. Having a hierarchy of roles can help by eliminating redundant policy statements. Second, the validation of user identity has to be strong, so that they’re assigned the correct role and so that someone with no role is given no access.
Explicit connection permission is great if it’s faithfully maintained at the identity, role, and connection policy levels. Even then, with practices to tie all these points down, it’s still possible a mistake could be made. What could be done to reduce that risk? The answer is artificial intelligence (AI) and machine learning (ML).
AI/ML traffic analysis
Any use of the network creates traffic and traffic patterns. Malware that’s probing for vulnerabilities is an application, and it also generates a traffic pattern. If AI/ML can monitor traffic patterns, it can pick out a malware probe from normal application access. Even if malware infects a user with the right to access a set of applications, it’s unlikely the malware would be able to duplicate the traffic pattern that user generated with legitimate access. Thus, AI/ML could detect a difference, and create an alert. That alert, like a journal alert on unauthorized connections, would then be followed up to validate the state of the user’s device security.
The advantage of the AI/ML traffic pattern analysis is that it can be effective even when user identity is difficult to pin down, so explicit connection authorization is problematic. In fact, you can do traffic pattern analysis at any level from single users to the entire network. Think of it as involving a kind of source/destination-address-logging process; at a given point, have I seen packets from or to this address or this subnetwork before? If not, then a more detailed analysis may be in order, or even an alert.
A branch office is populated with workers in a variety of roles, but rarely does a branch office contain workers from every possible role. That means that, since application/data access is normally assigned based on what the worker is expected to do, many applications should never be accessed from some branch locations. An AI/ML traffic pattern analysis at the branch level could detect an attempt to access an application nobody should be trying to use. Patterns of unusual traffic at the branch level, or for subnets within a headquarters location, could be used to flag a group of workers for a more rigorous security audit, either manually or via further per-worker traffic analysis.
AI/ML could also spot differences in a worker’s own behavior. Even if a worker isn’t accessing anything they’re not entitled to, a major shift in their traffic pattern could indicate malware to be sure, but it could also indicate a worker is doing a bit of application browsing. It’s possible this is an indicator the worker is disgruntled and might pose a security threat, but also that the worker has a different assignment or job that requires different access permissions, and that NetOps should look at their connection policies.
Either the connection permission or AI/ML traffic analysis strategies will advance network security considerably, but together they would create a strong foundation for securing not only networks but also the data and applications the networks connect. If you start your security plan with these two critical technologies, and use them properly, you could improve security. Maybe you could even rip off a few of those Band-Aid layers.
Copyright © 2022 IDG Communications, Inc.
