This may outright stun a few security professionals, but it is (yes, affirmative) possible for migrations to be relatively fast, totally secure and overall mostly painless.

Not what you’ve experienced? Also not surprising.

Migration projects tend to drag on – and paradoxically, they become the cause of security problems they were only initiated to fix up.

This happens for any number of reasons, including:

• Staffing concerns: Cybersecurity needs more people. There’s 2x more job postings for cybersecurity roles than other IT roles at present, but the talent marketplace hasn’t fully caught up yet.
• Infrastructure issues: Infrastructure is the plumbing/umpire of the network. It’s essential to the function, but completely ignored until there’s an actual problem. Migrations tend to bring some of those infrastructure concerns to the fore and quickly.
• Cost overruns: This happens for dozens of reasons including staffing concerns, budgeting mistakes and competing priorities.
• Disruption of network services: Migrations become a hassle in part because they take down other aspects of the network that customers (and internal employees) may need access to.

That’s a partial list of why migrations are often such a hassle for companies.

Is there a better way, though?

The Four Essentials of a Successful Migration

This might sound almost too logical, so brace yourself.

The four steps you need to move through (in order) are:

1. Remove Technical Mistakes
2. Remove Unused Access
3. Refine and Organize
4. Continually Monitor

Let’s take this one-by-one quickly.

Remove Technical Mistakes

Most firewall rulebases are going to have some combination of hidden rules, shadowed rules, redundant rules and overlapping rules. All these can cause network problems, security breaches and overly long migration processes. The first step, simply, is to rid the rulebase of these issues.

Take a look at this, for example:

The source and service columns are different. They’re different rules, right? Well, not necessarily. Look closer and you can see Rule 14 is using the source network of 192.168.20.0/24, which embraces the source for Rule 19 (192.168.20.95). The services of Rule

That’s an example of a hidden rule. That’s akin to the dark matter of network security; you can’t see it directly. This is a big problem for many security professionals and their bosses, and that fogginess gets extrapolated in cloud settings. But the way this hidden rule was ultimately found was through Traffic Flow Analysis (TFA), which is a tool you can deploy to show how packets move through your network. TFA helps you clean up some of the technical mistakes.

Remove Unused Access

This is about policy analysis – looking at network rules, system policy rules and firewall rules – followed by rule and object usage analysis.

If the primary goal of network security policy is to determine what’s allowed and what isn’t (and that should always be the goal), these three steps are designed to help you understand the present effectiveness of your ruleset.

Consider object usage, which is primarily about firewalls. With object analysis, we can see the amount of traffic across the full inventory of firewall devices. This is essential in a migration, because it gives you the opportunity to objectify your next set of firewalls to mirror or change your current object usage.

Traffic Flow Analysis comes back into the picture here too, isolating out the routing rules that keep the network safe and working effectively.

Refine and Organize

Now that you have a better picture of your rules and access points, it’s time to move forward and refine for new business goals.

This is about vulnerability analysis and compliance checks. Good vulnerability analysis is going to contain some possibility of attack simulation – so that you can visualize what your future attackers might try to do.

No resource is ever compromised without first being accessed through a series of events – events that are governed by the rulebase. But when you combine vulnerabilities with the rulebase, you have a clear picture of how an exposure can be exploited. Or, you may find that you’re ready to implement the new rule with no ill-intended effects.

The final piece of the puzzle – how you tie everything together and make sure it’s running smoothly – is called orchestration. Easiest analogy or parallel here is legitimately, well, an orchestra. If each instrument is off doing their own thing and playing their own chords, it’s going to sound horrible. But if everything is in sync and working together, that’s a lot better.

In the same way, end-to-end orchestration is the final piece of the refining and organizing process. By automating the rule lifecycle – intent, design, review, implementation and decommissioning – our migration can have the same consistency we enjoyed when clearing the rulebase of undesirables.

Continuous Compliance

Compliance drift happens over time. Because of how busy security teams get, it’s often goes under the radar as it’s happening.

There are any number of platforms out there proposing or offering “continuous compliance,” but the fine print matters more here. For something to truly deploy “continuous compliance,” you need it to be:

1. Real-time
2. Global in scale
3. Work with user and machine behavior
4. Retain data forever
5. Be customizable

Consider the need to retain data forever (which is incredibly important and not offered by many security solutions). If we only have data that extends back 30, 60 or 90 days, that does not give us the full picture of an object’s or a rule’s activity. We make a change out of a conviction that we have an unused rule, then calamity strikes. We could have spared ourselves this set back if we had data that could give more insight to the decision.