6 steps for rapid geographic network segmentation

Rapid geographic segmentation is a special case

It makes sense to start with the mental framework of rapid geographic segmentation as a special case of divestiture, which can occur for business reasons -- a company wishes to sell part of its operations -- or for geopolitical reasons -- a company wishes to stop doing business in a particular political geography.

The unique feature of geopolitically motivated segmentation is it needs to happen quickly with little time for planning -- unlike the case of a business divestiture. This is for human reasons. You don't want to tell employees in a potential war zone: "We think you're about to be invaded in a year or two, so we're planning a potential divestiture."

However, enterprises can take certain steps from the beginning to make rapid geographic network segmentation possible.

1. Strategize for geographic modularity

The first step is to have an IT strategy that's based on modularity, rather than centralization or regionalization. The concept here is the architecture is modular with components that can be disconnected easily from the whole without compromising the functionality or security of the whole.

Modularity should, therefore, be a key principle in all aspects of the technology strategy, from software to infrastructure. And it's important to cast this in terms of geographic, not merely functional, modularity. Functional modularity, particularly in software development, has to do with making changes to one software component without affecting others.

Network architects and IT leaders need to stress the benefits of modularity to business leaders, even asking them point-blank, "What if we need to segment off this piece of the architecture for business or geopolitical reasons?" The principle of geographic modularity should continue throughout the planning lifecycle, from strategy through architecture, procurement and operations.

2. Define consistent geographic domains

Once your organization has agreed on the concept of geographic modularity, you need to define geographic domains that make sense for the business, and this should be logical in the context of anticipated requirements.

That is, you should have clearly defined geographic domains that are not just general regions, but represent geographies that may need to be segmented off. For example, if Russia and Ukraine are part of the same geographic domains, you can't segment off Russia without also segmenting off Ukraine.

Importantly, these domains should apply across all components of the architecture, from infrastructure to employees, applications and data.

3. Architect for rapid geographic segmentation

For simplicity, it makes sense to think in terms of four key components to your architecture:

1. Infrastructure, including networks, storage and computing facility.
2. Identity, including employees and contractors.
3. Applications, including on premises, IaaS, PaaS and SaaS.
4. Data.

Each of these components should be architected based on the principle of geographic, as well as functional, modularity. And, importantly, they should all use the consistent geographic domains defined above.

Most global organizations don't have the luxury of defining all-new architectures across all four components, so you should subject your existing architectures to what-if scenarios. For example, what if China invades Taiwan and you have to divest Chinese operations?

Key points to consider while assessing, building or redesigning your architecture include the following:

• Address space. If your network is sufficiently old enough, you may have deployed RFC 1918, which reserved a Class A IPv4 address space for use in private networks. This means that spinning off a component of your network might require all new addressing -- not an easy task to perform rapidly. You'd want to revisit this architecture to public addresses, likely IPv6, structured in such a way that each geographic domain can be easily segmented off.
• Routing. You might want to consider using Border Gateway Protocol (BGP) internally between domains, which vastly simplifies spinning off geographies. Fun fact: Hyperscaler organizations, like Meta and Google, use BGP internally within their clouds and data centers.
• Active Directory (AD) structure. If, like most large organizations, you're using Microsoft AD, you'll want to revisit the directory tree structure to ensure that geographic domains can easily be forested off.
• DNS. You should revisit your DNS structure to make sure it's quick and easy to segment out affected geographies.
• Policies for application access. This is where the use of approaches such as zero-trust network access make a great deal of sense. Rather than having separate trust domains and policies -- such as Secure Access Service Edge for remote users plus internal authorization for on-premises users -- you should have a single set of policies instantiated across the enterprise but with geographic domain awareness built in. That makes it possible to, say, exclude all Russian or Chinese employees from accessing corporate applications with the click of a mouse.
• Application instance redundancy assessment. The flip side of the above scenario -- denying all employees in a particular country access to corporate applications -- is, if the operations are being sold or handed off to other entities, they may require access to specific applications. That is, it may be necessary to have geography-specific instances for critical applications, such as CRM, payroll or core business apps. This becomes a challenge for the application developers, who need to build their applications around the same core geographic domains as the infrastructure folks.
• Cloud. You may think that cloud-based applications don't require geographic modularity. You'd be wrong; they do. You need to make sure that both access policies and instance locations are based on the principle of geographic modularity. That is, you should be able to disconnect all Russian or Chinese -- or any -- employees from cloud-based applications. And applications that are operating on clouds within regions of potential disconnect need to have backups in different geographies. And it should be easy to transition your employees from one instance to another.

4. Tiger-team, plan and war-game

As noted earlier, most global organizations don't have the luxury of designing their operations from scratch with the goal of enabling rapid geographic segmentation. But that shouldn't stop technology architects and IT professionals from migrating their architectures in that direction.

The first step is to assemble a tiger team of professionals from each of the four architecture components -- infrastructure, identity, applications and data -- as well as representatives from legal, risk management and the business. This team should begin addressing the following set of questions, among others:

• Have we defined a set of geographic domains?
• Do the defined geographic domains make sense in today's geopolitical and business environment?
• Are the domains recognized and supported by the architectures in each of the four component areas?
• Do we have a defined rapid geopolitical segmentation plan as part of our operating playbooks?
• Does that plan make sense in the current context? For example, if the plan was last developed during the days of the Soviet Union, it may make sense to revisit.
• Does the plan address all four components of the architecture?
• Does it lay out sequential steps in a logical fashion, recognizing dependencies?

Once the team has been created and the plan has been developed, the next critical step is to war-game. That is, you should develop what-if scenarios to test the team and plan, as well as to uncover weaknesses of the current architecture, operations or plan.

Nemertes recommends doing this using tactical decision games and the Observe-Orient-Decide-Act, or OODA, loop. Each exercise should be followed with an after-action review that should point the way to appropriate remediation.

War-gaming for geographic segmentation should be an integral component of a broader war-gaming strategy, which should cover cybersecurity incidents, incident response plans, and general disaster recovery and business continuity planning.

5. Include MAD clauses in all contracts

It's critical to remember that divesting parts of the organization affects vendor relationships, particularly but not exclusively telecommunications relationships. Taking away a significant number of sites or seats can incur financial penalties or affect discount rates.

Therefore, all contracts -- whether for telecommunications, software applications, hardware or anything else -- need to include a clause that governs what happens in the case of mergers, acquisitions and divestitures (MAD). This ensures that companies don't suffer a financial penalty from vendors or carriers for making a divestiture.

The basics behind an effective MAD clause are the following:

• No financial penalty in the event of a merger or divestiture for business or geopolitical reasons. That is, if the number of network nodes or devices drops below the number originally contracted for, the carrier or provider cannot levy financial penalties. Many times, carriers levy a financial penalty for network changes that affect the minimum annual revenue commitment (MARC).
• The unilateral right to either maintain current prices or renegotiate rates. Separate from the financial penalties noted above, vendors may raise prices if the number of sites or seats falls below a certain number or affect the MARC. The contract should stipulate that this is not the case in the event of a divestiture and that you -- the client -- retain the right to continue with current rates or, if you so choose, to renegotiate. The important point is not to be forced by the carrier or provider to pay higher rates.
• Terms and conditions on speed of change or turndown. Particularly for carriers, you may need to press the providers to ensure rapid turndown of specific sites. This should be negotiated upfront.

6. Don't forget the supply chain

A nonobvious consequence of geopolitical partitioning is that critical parts or supplies may be made in the regions being divested -- and the U.S. or your headquarters company may have imposed sanctions on the country. It's critical to be aware of the presence of, say, Chinese-made parts or Russian-written software in your hardware and software environment.

This gets into the challenge of interactive asset management for assets of all types, as well as software bills of materials. Understand the source for all components in the supply chain, and have backup strategies if sanctions or other geopolitical activity -- such as pandemic shutdowns -- affect the availability of hardware or software components.

The bottom line? Geographic modularity should be part of your IT strategy from the start, and architects should plan to do their utmost to build it in along the way. You'll be glad you did.