“A lot of times getting access to a VPN is the keys to the kingdom,” says Joseph Apuzzo. “Once you have access to that, you can start snooping around the network, gaining access and just running crazy.” 

In CommandLink’s second podcast episode, Joseph looks back at two well-known breaches with a panel from both the security and networking sides. They break down the patterns behind each breach, who owns the problem, and what teams should do differently:
- Joseph Apuzzo, Senior Director of Security Solutions Engineering, CommandLink
- Austin Amraen, SOC Director, CommandLink
- David Morrison, Senior Solutions Engineer, Versa Networks

Two Breaches, One Pattern 

Both breaches started with access an attacker should never have had. 

Colonial Pipeline (2021). Someone gained access to a legacy VPN account and used it to get onto the network. 

JPMorgan Chase (2014). An attacker stole an employee’s credentials. With those compromised credentials, the attacker accessed more than 90 servers.

Five Lessons from the Headlines 

1. A VPN Login Is Not a Security Boundary

Most VPNs are built as an initial barrier: authenticate once, and you’re through. David noted that this authentication often isn’t sufficient on its own, and even two-factor authentication may not be enough depending on how it is implemented. Making matters worse, the VPN is usually run by the network team even though it is a security control. Once users are in, they are granted full access to whatever networks they can connect to. 

“Once you get a footprint, even into an isolated network, you’re essentially in,” David said. He pointed to a hack where a compromised machine on an air-gapped network sent data out as Morse code through its CMOS speaker, a couple hundred characters a minute. 

Austin added that attackers can get around MFA today, and defenders often have to find out how, then update and block it. 

Why it matters: An old account on an old VPN is exactly what gets missed. As Austin put it, “If no one’s checking things regularly and no one’s looking for the status quo, then you’re going to have the problem.” 

2. Know Your Status Quo 

Joseph described behavioral analytics as knowing the status quo of user activity and traffic. Austin called it finding the needle in the haystack: if a user always logs in from the same device and the same IP address, anything new should stand out. 

Identity signals. Broad rules don’t hold up. A conditional access policy that limits logins to one country is easy to beat, because attackers know what country you’re in and VPN into it. Security is evolving to go deeper: the same device, IP address, browser, browser version and Windows version. Any activity outside that profile is an alert. 

Network patterns. “We’re predictable. People don’t change if they don’t have to,” David said. Users hit the same remote access server, gateway or VPN concentrator nine times out of ten. Yet when David talks with new partners and customers who want to add security to their networking, no one understands their traffic patterns. Without knowing which applications should be running and how people use them, you can’t right-size a UTM device or spot a user doing something abnormal. 

Why it matters: At JPMorgan Chase, one user’s compromised credentials reached more than 90 servers. As Joseph noted, a single user touching all 90 of those servers every day is few and far between. That user should not have been anywhere near them. 

3. Review the Access You Already Have 

Before getting into advanced approaches like ZTNA, David pointed to the step every company fails at and only does after the fact: static analysis of what you currently have. 

Identity providers (IdPs). Offboarding is usually handled fast; when someone walks out the door, access is shut down within a day or an hour. The bigger problem is that people are way over-credentialed. They get access for a specific project and it never gets removed. 

Firewall rules. You can have the biggest firewall with every feature turned on, but if no one has evaluated the rules in the last six months, you can end up with 10,000 of them. “So what’s that serving?” David asked. 

Inherited roles. Joseph recalled the summer and winter intern accounts from a previous company. Often the account is simply handed to the next intern with the same credentials and left to “rot.” Even worse, the account gets disabled but the RBAC role doesn’t. The next intern is placed in the same role because the last one needed it. 

Why it matters: Over-credentialing like this, Joseph said, “should easily be caught before it turns into the next SolarWinds intern attack.” 

4. Correlate Identity in One Place 

For Austin, it starts with logging: are you logging it, and are the logs going to the right place? Microsoft reports a user logging in from an unusual place. Did you flag it? The same user then logs into a server. Is that their normal IP, device and time? Too often, that answer sits in a totally different logging structure. 

Identity has changed. “A person is not a singular entity anymore,” Austin said. A person is an IP address, an email, a user account, a device and a mobile device. IAM and PAM are about correlating all of it. When access isn’t reviewed, Austin added, “we’re just opening doors.” With identity correlated, detection comes down to clear questions: 

1. Should this person even have access to this firewall or server? 

2. Why are they doing it? 

3. Why so many? 

4. Is this an IP address they should be accessing from? 

Rules alone aren’t enough either. If someone isn’t seeing the alert and taking action, it’s just an alarm going off while everyone looks at it. “Threat actors are waiting,” Austin said. “They’re not taking action the second they get access.” Joseph agreed: they test the waters and poke to see what your reaction time is. 

Why it matters: The waiting period is where identity catches them, but only if the data comes together. In Austin’s words, “You can’t have three flags in three separate areas when all three correlate to one big flag.” 

5. Stop Handing Off. Start Planning Together. 

Was this network operations’ responsibility or security operations’? Joseph called it a toss-up. He argued that no matter which side a conversation starts on, both teams need to be in the same room.

“I don’t even think we can afford that handoff anymore,” Joseph said of the model where David creates firewall rules and hands them to Austin. Not every change or configuration needs both teams, but planning does. His worry is that teams are still siloed and not communicating, even when they roll up to the same person. 

David agreed that, at a minimum, you need a cross-functional audit. Power struggles and separate domains sometimes keep teams apart, and that separation can be intentional with a good purpose. But at some point, two people from both sides need to review your policies, configuration and rules together. 

He also pushed back on the network-or-security question with Kevin Mitnick, a brilliant hacker from the 1980s who relied on social engineering: calling people up, saying “I’m your IT guy,” and asking for their password. Was that the network’s fault, or a training issue? Probably both. 

Why it matters: “This has never, in my mind, been a single-sided problem,” David said. “It’s always been this way. All the way back to the inception of connectivity.” 

Breaking Down the Walls Between NOC and SOC 

The panel’s conclusion: it is no longer a SOC and a NOC working separately with a rigid communication path. Austin described SOC and NOC teams spending time in each other’s departments, explaining how they do their jobs and what they look for. 

The result is NOC engineers who configure a firewall a certain way because security flagged an issue, and security analysts who look at firewall traffic and spot what doesn’t match what the NOC described. 

“Security people have to be networking people. Networking people have to be security people,” Austin said. That doesn’t mean being 100% in both worlds. It means understanding each other’s worlds and working in the same ecosystem. Or, as Joseph put it: “May I be so bold as to say, just call it operations.”