Force-Multiplying Law Firm Security: Prevention, Protection, and Automation

Summary

Law firms are spending more on security while ransomware and breaches keep rising, because most defenses focus on detection and leave internal networks open once an attacker gets in. In this session, Nicholas DiCola of Zero Networks explains a layered prevention model, network microsegmentation, identity segmentation, and RPC protection, that keeps one compromised machine from becoming many. Alexander Eames of Cravath, Swaine & Moore LLP then shares how the firm replaced a manually maintained Symantec firewall setup with Zero Networks, rolling it out across its workstations and servers, locking down more than 200 service accounts with identity segmentation, deploying the RPC Firewall on every domain controller, and using auto-segmentation so new servers and accounts are protected within 30 days.

Key takeaways

• Attackers can exfiltrate data within the first hour, and they evade EDR by pivoting through unprotected devices, so prevention has to complement detection.
• Microsegmentation puts a firewall bubble around every host, allowing only needed traffic and requiring MFA for privileged access, so one compromised machine doesn’t mean all are compromised.
• Identity segmentation limits where accounts can log on. Service accounts, for example, should never be usable on workstations, where attackers typically start.
• RPC must stay open on domain controllers, so protecting it requires filtering at the protocol layer to block attacks like DCSync.
• Cravath moved off a manually maintained Symantec setup that couldn’t scale. Most of its effort went into change management, and about 80% of its rules now come from Zero Networks’ learning mode.
• Auto-segmentation puts new servers and service accounts into learning mode and converts them to segmentation mode within 30 days, closing the gap on newly built systems.
• Next, Cravath plans to keep tightening policies and extend network-layer MFA to more systems.

This webinar was recorded in August 2025.

Ronit Wolf, Host, Zero Networks: Thank you for joining today for this master class, “Force-Multiplying Law Firm Security: Prevention, Protection, and Automation in the Age of AI Threats.” I’m joined today by Zero Networks VP of Customers Nicholas DiCola and Alexander Eames from Cravath, Swaine & Moore. I’m Ronit Wolf with Zero Networks, and I’ll be your host today. I’ll turn it over to Nick to formally introduce himself.

Nicholas DiCola, VP of Customers, Zero Networks: Thanks, Ronit, for kicking it off. Welcome, everybody, and thank you for taking the time to join us. I’m Nicholas DiCola, VP of Customers and security Jedi here at Zero Networks. As Ronit said, I have Alex with me. Alex, do you want to do a quick intro?

Alexander Eames, Director of Information Security and Architecture, Cravath, Swaine & Moore LLP: Sure. My name is Alex Eames, and I’m the director of information security and architecture at Cravath. I’ve been with the firm for 20 years in various roles. I’ve worked with the security function here for several years, and the team has been formally under me for about three years.

Why are attacks rising despite more security spending?

Nicholas DiCola: Thank you. Let’s set the stage by looking at the risk landscape today. Ransomware continues to rise, with about a 100% increase since 2024, which is a pretty large increase. The number of breaches reported globally continues to climb, up a shocking 660% since 2021, and that’s only what’s reported. It doesn’t count all the breaches that aren’t. The cost of a breach is going up as well: the average is about $4.8 million, up about 15% since 2021. These stats come from a range of sources. The bad news, and I promise it’s not all bad news, is that we’re spending more on cyber, yet attacks keep increasing and so does their cost. That math isn’t great across the industry.

Why isn’t detection enough?

Nicholas DiCola: We believe this keeps happening because many organizations, and the market as a whole, have focused on detection and deprioritized prevention. In surveys, we see that most customers are very focused on endpoint security: EDR, XDR, and detection. And if you look at many of the reported attacks, those organizations had these tools, yet the attacker still got in and spread very quickly. Nearly one in five ransomware attacks involves data exfiltration within the first hour of compromise. It’s very, very fast, so you depend on detection technologies catching it immediately, and sometimes they don’t, which is why attackers are so successful.

Nicholas DiCola: We also see reports that security teams are overwhelmed by the number of alerts, false positives, and lack of context, so it’s very hard to find the alerts that actually matter. Once attackers are in, they quickly live off the land and pivot without detection. In a recent Akira ransomware attack, the EDR actually did detect the attackers, but they quickly pivoted to an unprotected webcam and used it to move laterally over SMB to many assets in the environment, bypassing EDR detection. So we’re seeing attackers evade detection by moving laterally through other devices.

How does microsegmentation stop lateral movement?

Nicholas DiCola: When you simplify this, you have to assume breach. Something will happen: a spear phishing email or a malicious payload from a website will reach a machine. And once an attacker is in, you have to assume everything is compromised, because networks are too open and accounts have too many permissions. That’s just how networks were built. TCP/IP was designed to make communication very easy, and we never secured the inside of the network. Some organizations have segmentation, but we didn’t start by blocking every asset.

Nicholas DiCola: At Zero Networks, we believe it’s time to shift out of reactive security and embrace proactive strategies around prevention, which really revolve around microsegmentation. In a nutshell, microsegmentation means putting a bubble around every host, allowing in only what’s needed, and escalating anything privileged with MFA. If you do this and an attacker gets in, they can’t move laterally. I like to joke that if an attacker gets in and can’t move laterally, where do they go? They leave, and go to an organization where they can move laterally, because that’s their intent. They want to reach resources.

Nicholas DiCola: Specifically for law firms like Cravath, microsegmentation matters for many reasons, and Alex will share more about his. Once an attacker breaches the perimeter and spreads, there’s regulatory pressure around data privacy and protecting client data. We’ve seen real-world scenarios where a compromised billing system led to an attack spreading to litigation databases because there was no segmentation. Making sure the network is well microsegmented, so an attacker who gets in can’t move, really helps secure a law firm. With a microsegmented network, we like to say one compromised equals none compromised, because the attacker can’t move laterally. They can’t connect to other systems or log on to them remotely, because you’ve closed and segmented those paths at both the network and identity layers.

Nicholas DiCola: Creating a layered, dynamic defense requires a few things. Microsegmentation is generally about the network layer. Think of it as turning on a firewall on every host, blocking inbound traffic, and allowing only the few things that are needed. Even then, some things will still be open in the environment, so you also want to limit identities at a higher layer: control where accounts can log in and enforce least privilege across the environment, especially for service accounts and privileged human accounts. Service accounts, for example, should never log on to workstations. And finally, some protocols, like RPC, are very powerful, are typically open to the entire environment, and can’t be segmented at the network or identity layer, so you need some kind of layer 7 protection. Together, we call these three layers holistic segmentation: at the network, identity, and application layers, including protocols like RPC.

What is identity segmentation?

Nicholas DiCola: Let’s talk about identity segmentation, in case you haven’t heard of it. Identity segmentation is about limiting where accounts can log in. Most customers have Microsoft Active Directory, which was designed to connect things and make access easy. By default, a user account can log on almost everywhere unless you specifically block it, and the same is true for service accounts. If you add a service account for a SQL Server, it’s supposed to be used only on that SQL Server, but it’s very hard to block it everywhere else it shouldn’t be used. A SQL service account should never log on to a workstation, in any kind of logon. Actually limiting identities in the environment is nearly impossible with the tools most organizations have today.

Nicholas DiCola: But if you can block first and allow accounts only where they’re needed, especially privileged service accounts, you stop exposing those accounts in the places where attackers start. In many cases, attackers start on a workstation. If that service account or privileged account can’t log on to a workstation, how will the attacker get the credential to move laterally, even before you consider network segmentation? That’s why it’s so important to layer identity segmentation on top of network segmentation.

Why is RPC a top target, and how do you protect it?

Nicholas DiCola: Now let’s look at RPC, for those less familiar with it. RPC, or remote procedure call, is a protocol Microsoft invented many years ago. The way I like to explain it, RPC exposes about 2,000 functions to anyone who can connect over the protocol. Those functions can do all kinds of things, like create a scheduled task on a remote machine or, on a domain controller, perform a DCSync operation. The challenge is that you have to open RPC to everything in your network, especially on domain controllers. And if an attacker is in the environment, the first thing they want to reach is a domain controller, because if they own the domain controller, they theoretically own everything in the domain.

Nicholas DiCola: You have to leave RPC open because services like Group Policy, DFSR, and AD authentication all depend on it, so you can’t close it at the network layer. At the identity layer, it’s very hard or nearly impossible to close, because users need to log on; you can’t block all users and allow only admins. So you basically have to leave it open at both the network and identity layers. Attackers love that, because many existing tools take advantage of RPC, knowing it has to stay open, to obtain credentials, which they then use to move laterally. Once they find RPC open on a domain controller, it’s literally their shortest path to that domain controller.

Nicholas DiCola: Finally, vulnerabilities do appear, and some allow unauthenticated access. The attacker just needs to be in the environment, because you have to leave the network open. Without even authenticating, they can potentially use the vulnerability to compromise a domain controller, by stealing credentials or running DCSync attacks, for example. Zerologon and the Conficker worm are two examples that used RPC, even without authentication.

Nicholas DiCola: Zero Networks offers an open-source RPC firewall on our GitHub that you can check out, because this is a pretty big problem. But it’s a bit manual. With a modern RPC firewall, you want something that scales easily and doesn’t disrupt your services, gives you visibility into all RPC activity, interfaces, and operations (the functions inside RPC), and lets you segment them. That way, even though RPC is open at the network and identity layers, only certain functions are available across the environment at the protocol layer, which prevents RPC exploitation. Ideally, you want that automated, so you don’t have to work out every RPC function in use in your environment and create operational burden for the team. I’ve said a lot, so I’ll finally pause and turn it over to Alex to talk about his organization’s journey. Just let me know when to change slides, Alex.

Why did Cravath look for a new microsegmentation solution?

Alexander Eames: Thanks for the rundown. Some background on us: we started looking at Zero Networks about a year ago. At the time, we were interested in upgrading our microsegmentation. We had been maintaining our own microsegmentation solution through Symantec Endpoint Protection for many years, and I’ll talk more about that history in a moment. Broadly, our goals were to reduce the effort of managing firewall rules, get better reporting, auditing, and logging through a web-based platform, increase compliance for firewall deployment, and add more granular protections on our lower-criticality servers.

Alexander Eames: One of the big challenges any firm that has attempted microsegmentation has probably run into is protecting new servers. In my experience, it can be very difficult to recognize when new servers are built and to work with the application owners: “When are you done building and configuring your system? When can I develop the rules and turn on blocking mode?” It’s always a negotiation and a manual back-and-forth. These were all areas we wanted to improve.

What were the limits of Cravath’s previous approach?

Alexander Eames: To get there, it helps to reflect on our history. We used Symantec as our firewall solution for many years. I’d say we adopted it before some of the higher-end microsegmentation solutions hit the market or became widely adopted in the legal space. Because we were already using Symantec antivirus, it was simple to start adding policies, so it became our solution of choice. It didn’t add cost, and it had similar capabilities in terms of creating finely tuned policies. We spent a lot of time and effort developing very limited sets of allow rules on critical servers, and we created an intricate set of policies on our workstations, making sure all inbound traffic was blocked, with on-network and off-network policies, and so on. It might sound like an old-school product by today’s standards, but it could do a lot if you put the time and effort into building the policies.

Alexander Eames: Realistically, though, it wasn’t sustainable for us. We couldn’t keep up with policy development for the entire server fleet, so we had to focus on protecting our most critical assets and our workstations, where one template for all of them made sense. There wasn’t much product innovation. We were hitting a wall with no Linux support. You couldn’t easily get to a central log, so we had to develop other methods for collecting traffic logs and doing rule development and analysis.

Alexander Eames: Over the years, that led us to look at the higher-end microsegmentation solutions. Every time, they seemed to solve some of our issues with Symantec, with web-based portals, better centralized logging, and more efficient rulemaking, but we still had to do a lot of manual rulemaking to make them do what we had already done in Symantec. Plus, there would be a big switching cost and effort. So we prioritized other projects and security investments and stuck with Symantec. After making progress on other initiatives over the last couple of years, we decided it was time to pick this back up, which is why we started looking again about a year ago.

What did Cravath look for in a new solution?

Alexander Eames: We started that search thinking only about network firewalls, because that’s what we had with Symantec: network-based protections. Our goals were automation, efficiency, and a minimal footprint on our systems. As a side note, we’ve been burned by security products that caused issues on our systems or required a lot of maintenance to move from one agent version to the next. So we really wanted to avoid installing third-party software or network drivers on our systems. That appealed to us about Zero Networks, since it integrates natively with the Windows Firewall.

Alexander Eames: Once we looked at the current landscape of products and spoke with Zero Networks, we learned about features like MFA challenges for network connections. It’s like a third tier: you can allow or block in pretty much any of these products, but a block with an MFA override was pretty cool. We didn’t even know that service account segmentation or an RPC firewall were things that could be done. Once we learned about those capabilities, our goals for the project went beyond the network to include accounts and RPC as well.

What has Cravath implemented with Zero Networks?

Alexander Eames: So we expanded our thinking to include those capabilities and decided to move forward with Zero Networks. At this stage, all of our workstations and a large share of our servers have been migrated to Zero Networks. We’ve fully implemented identity segmentation, which has two parts. At the account level, more than 200 service accounts are fully protected. You also need to make sure the blocking is implemented at the device level, and all of our Windows devices are covered. And we’ve rolled out the RPC Firewall on all of our domain controllers.

Alexander Eames: The key point for us is that I’m talking about this status in August, and we’ve been working on it since the beginning of the year. Most of our effort has gone into change management for rolling out these changes. Only a small portion has gone into manual rule editing or rulemaking across the three components. In each phase, we put our systems and accounts through Zero Networks’ learning modes, letting the product analyze everything that’s happening before we implement blocking policies. I think it does a good job of being conservative, so that once rules are created and you put a system into blocking mode, you’re not going to break something. Afterward, you might want to analyze the rules that were created, and you can certainly tighten things further. But the learning engine prioritizes not opening privileged ports unnecessarily. So for probably 80% of the rules in the system, we’re relying on the learned rules.

Alexander Eames: Compared with Symantec, we have a security-equivalent set of policies on workstations. Our noncritical servers are definitely better protected now than they were with Symantec, because we never had the capacity to create granular rules on the noncritical server side. Just running hundreds of servers through the learning engine has made them better protected.

Alexander Eames: On the identity side, we didn’t have that capability at all before, so putting rules around where service accounts can be used is a big shift. For example, someone might try to use a service account’s credentials on their own workstation. You’re not supposed to do that, but nothing blocks it until you implement something like this. That’s been a key benefit, and it was pretty low-friction to implement. Most of our service accounts are now locked down so they can be used only on the applicable servers. For example, the service account for our financial system can operate only on that system’s servers, not on workstations or other servers.

Alexander Eames: The same concept applies to the RPC Firewall. As Nick mentioned, RPC is a monstrous protocol, with thousands of functions you can call. But one of the key ones he mentioned is DCSync, and I want to reinforce that point. If you run a pen test, or if an attacker is actually in your network, one goal of privilege escalation is to reach domain admin. Then, because you can’t block inbound network access to the domain controllers, the attacker can run DCSync and make a copy of Active Directory on a system they control. Now they have a full copy of AD, with all user accounts and password hashes, and they can crack passwords offline and do all kinds of other nefarious things. Having protections against that was a big improvement in our internal network security posture.

How does auto-segmentation protect new servers and accounts?

Alexander Eames: The last part of our current state is auto-segmentation. This was another key challenge with Symantec. When a new server was built, we’d apply a default policy that blocked a few things. Now we’re moving to auto-segmentation: when a new server is built or a new service account is registered, Zero Networks picks it up and automatically puts it into learning mode. It isn’t protected initially, but within 30 days, it automatically converts to segmentation mode. Given the conservative nature of the rules, I don’t think we’ve yet seen a case where the learning and auto-segmentation process broke something. You might want to go back, analyze, and tighten things manually, but you get 80% of the security benefit through automation alone.

What’s next for Cravath?

Alexander Eames: Next, we’re looking at further policy tightening. There are so many systems and so many rules that have been created, so we’ll export the rule data from the platform, analyze it, and look for opportunities to tighten things. We’re also continuing the rollout, and we prioritized our less critical systems first, which was smarter from a change management standpoint: if something breaks, it isn’t a critical system.

Alexander Eames: We’re also moving toward implementing those network-layer MFA policies on more of our servers, so we can block inbound network access by default and let the people who need access connect with an MFA challenge. And of course, I’m looking forward to our next internal penetration test and seeing how difficult we can make our pen testers’ lives.

Alexander Eames: My takeaway from all of this is that we’re a law firm that has been doing microsegmentation for a while, we switched, and we’re realizing the benefits of automation and the additional identity and RPC capabilities. Broadly, I’d say the Zero Networks approach has made microsegmentation more attainable, particularly for firms that have shied away from big, complicated tools in the past, or for firms struggling with their current microsegmentation tools. These concepts are worth a look.

How does microsegmentation make defenders’ lives easier?

Nicholas DiCola: Thanks, Alex. You don’t just get to sit and listen for 30 minutes; we come with a challenge, so hopefully we’ll get some interaction. What challenges have you faced when trying to strengthen your network security and move toward zero trust principles? Feel free to share in the chat. It’s always good to see what other people in the community are struggling with. Alex shared some of the challenges they faced, and I’ll reiterate one: the manual effort and time it takes to do microsegmentation by hand. Automation is the most important piece.

Nicholas DiCola: To wrap up what Alex said from the Zero Networks perspective: microsegmentation should be made possible. That’s what we do at Zero Networks. It’s about giving you a proactive defense, so you don’t have all these ports, protocols, and identities open on the network, and one compromised doesn’t equal all compromised. To do that, you need automated asset tagging and grouping, and automated, precise network rules that don’t break your network. That’s very important, and Alex reiterated that nothing broke when they used the automation. You don’t want to disrupt operations, and you don’t want to leave things open.

Nicholas DiCola: Adding MFA at the network layer is also very important, because you need to protect privileged ports. Attackers love to use them to move laterally, because they need privilege on the next machine. If you close those ports so they aren’t open to an attacker on the network, and make them available only through MFA, you really start to stop lateral movement across the environment. Then you don’t have to chase threats. I like to ask people: how much easier would your day be if an attacker got into one laptop and you were confident they hadn’t moved laterally? You could throw that one laptop away, rather than investigating lots of systems to figure out where they went. If you can stop attackers from spreading laterally, your life as a defender gets much, much easier.

Nicholas DiCola: I’ll wrap it up there and open it up for Q&A. Please drop your questions in the chat, and we’ll give it a couple of minutes.

Ronit Wolf: We’ll share a recording afterward. If you have questions for Nick or Alex later, you can reply to the recording email, and we’ll get to them. Thank you so much for joining, everybody. I hope this was valuable. Thank you, Alex, for joining us and sharing your journey, and we’ll see you at the next one.

Nicholas DiCola: Thank you, everybody. Take care.

Alexander Eames: Thank you as well.