Are you doing enough to secure your network infrastructure?

It’s time to take a hard look at whether you’re devoting enough resources to securing your network infrastructure. Short answer: You’re probably not.

If you work for a hyperscaler, your organization is probably doing everything it can to secure the network. For almost everyone else, it is pretty safe to assume that the answer is no.

This is not necessarily a blameworthy failing. In many cases it is down to available resources and perceived risk: Given too little money for cybersecurity and too little time from too few people to tackle all possible risks in the network, what should network cybersecurity staff focus on? They tend to focus less on the inward-facing aspects of their networks and more on explicitly outward-facing pieces.

Two big issues there, of course. “Inward-facing” is a shaky concept and getting shakier all the time—that is, it is getting harder and harder to draw a bright line between what is “inside” the enterprise environment and what is “outside” of it.  And, however real “inside” is, that is where the insider threat lives.

What that means is, when doing risk assessments, IT folks should be thinking of securing all of their network infrastructure much the same way they think of securing the more obviously directly Internet-facing parts of it. Campus switches, in other words, are just as much a part of the enterprise attack surface as the main Internet router or application delivery controller.

So, network security folks should probably be investing more time to improve security in their network infrastructure and therefore the security of the enterprise as a whole. Here are four ways to do that.

None of these approaches is free. They all cost IT staff time at the very least, and staff time is precious and scarce. But the stakes continue to ratchet up for cybersecurity, especially in the age of ubiquitous phishing and low-and-slow ransomware woven into broad, adaptive, persistent attack campaigns.

Some of this advice might seem familiar and obvious, but don’t disengage because you already know you ought to be doing it—think it through anew.

Stop sharing generic credentials

No one really needs to be told any more that this is a bad idea, but a shocking number of IT shops still do this: have an account, or sometimes a number of them, that network folks can log into as needed to get administrative access to switches and the like.

This is a bad idea for many reasons, but here let’s highlight three: It makes more difficult, or impossible, tracking administrative actions to specific people; it greatly increases the chance that the credentials will be compromised; and it greatly increases the chance that someone on the inside who should no longer have access to the account will continue to be able to use it. (That last actually sneaks in a fourth point: It won’t just be insiders who no longer need access that retain it, it will also be recently terminated staff.) Fundamentally, once things are set up this way, there is simply no way to know who has access to the network anymore.

Every person who needs access should have an account of their own. The time for turning a blind eye to the network team on this front is long since over.

Reduce the number of people with access

One aspect of securing the infrastructure that is almost impossible without account-per-person access management is restricting access to those who actually need it. An audit of accounts with access to network infrastructure almost always turns up accounts for folks who no longer need the access because their job has changed, and usually turns up some still-active accounts associated with former employees.

IT must audit empowered accounts regularly. This should be suspenders to the belt of making it standard process to review all accounts associated with a position whenever it is filled or vacated, and disabling empowered accounts whenever a person leaves the company.

Go multi-factor authentication

No one really needs to be persuaded any more that multi-factor authentication (MFA) is a vast improvement in security for most systems, significantly increasing the difficulty of getting in where one is not wanted. This is just as true for the infrastructure as it is for a banking application. (And of course, compromising the network can end in compromise of all the applications in a worst-case scenario.)

Network teams should be pointing their switches at MFA-capable identity services, via RADIUS or TACACS+.

Go software-defined perimeter

Implementing a software-defined perimeter system would allow IT to layer additional protections around one-person/one-account access with MFA. For example, the SDP software could allow admin access to network nodes only from company-controlled laptops or desktops in good health, and/or only from specific segments of the physical network, and more. Moreover, accounts with no right to manage network nodes could be prevented even from seeing them on the network; they would be invisible to unauthorized users or systems.