An Architect's Guide to Deploying Microsegmentation: Managing the Deployment Process

Part 1 and part 2 of this series explore the implications of altering your security model and the resources required for success with your microsegmentation deployment.

In part 3, we’ll examine how best to manage the deployment process with specific checkpoints to add to your plan.

In many ways, deploying microsegmentation is just another IT project. There is technical work, political work, and coordination work just as with any project. Below, I will highlight the special considerations that make a microsegmentation deployment as smooth as possible. These are the “best practices” that we have distilled from many large-scale enterprise deployments and can be adapted to any size deployment.

Ensure broad overview training for the entire project team

Get as many people as possible through the vendor’s overview training class. This grounds attendees in the architecture, policy language, and core concepts of microsegmentation. When the entire project team attends this together, the whole design process becomes more robust. Each member of the cross-functional team listed above has a different view of IT and understands the constraints and existing architecture from a unique vantage point.

When each person knows enough about deploying microsegmentation to verbalize where complications may arise, testing or certification obtained, and other such details, it is much easier to build a complete deployment plan. The sooner these perspectives are heard in the planning process, the better. If the team are brought in one-by-one as the project progresses, many “critical path” items will not be uncovered until weeks afterwards. This early notice gives the entire organization better time to plan and react.

Expect complete design deliverables

A microsegmentation deployment has several new concepts, as we noted above. These need to be reflected in the project plan and timeline. If the project plan has only technical milestones and misses the coordination, cross-team notifications, and other touchpoints, the project will slip several weeks by the end of the project. Every company organizes and tracks projects with local flavor, but each project should have:

• A detailed deployment plan. A vendor should provide a template of the “work to be done” that contains all “lessons learned” and “best practices. This should be integrated into an actionable deployment plan, with names and dates assigned as appropriate. The plan should be signed off by the teams executing it and the exec sponsor should expect a reporting cadence on progress.
• A labeling and metadata plan. Since microsegmentation policy is based on names and labels rather than IP addresses, the team will need to assess current data sources and identify gaps. For ongoing operations, it may be necessary to create or enhance policy and workflow around how metadata is created and maintained as applications come and go.
• A detailed initial security policy. Our fastest deployments have occurred where the deployment team had a clear policy objective at the outset of the project. Microsegmentation is capable of more granularity than enterprises have had in the past. For most of our customers, microsegmentation offers much more than is initially required. The wise project team will meet the project goals first and not get sucked into all that will eventually be possible with the platform. It is best to detail the initial policy and have the team run hard at that goal. After the workloads are all secured to the initial security policy, tightening can be done according to business needs on a risk-adjusted basis. Avoid “trying to boil the ocean”.
• A list and description of all required automation and who is going to write it. Bulk deployment of agents, import of labels and metadata, and so many other things will likely be done via automation. Depending on which team takes the tech lead position, this work may be done by other teams. This will require extra scheduling and coordination. Knowing early exactly what is needed and by when will help each team avoid surprises and keep on track.
• A list and description of all required integration points and who will do it. At a minimum, security and operational logs will probably be sent to a SIEM or a big-data analysis platform. Additional customization, dashboards, and other tools may be needed. Often this is an area that involves other teams than the project lead team. Your vendor will have professional service engineers with specific expertise and will need to pull the right resources for your project. It is important to figure out who is doing what work early in the project so that schedules align.
• A list of the internal processes and workflows that will be affected by microsegmentation deployment. Microsegmentation changes how your organization authors security policy. If someone alters labels or metadata, that will alter the security policy applied to a workload. In theory, this is no different than requesting a firewall rule change. However, most organizations find that there are key workflows that need to be applied or extended so that existing safeguards apply. Expect the team to identify these and raise them to appropriate levels for coordination and sign-off. This is key to smooth long-term ownership of a microsegmentation solution, and work that can’t be done without management-level approval and coordination.

Reporting cadence

Microsegmentation deployments happen smoothly when there are three levels of reporting, each with their own cadence:

1. Technical project status: The team lead, vendor professional service engineers and others deeply engaged at the level of the work need to communicate regularly. We often see this on schedules as short as daily to a weekly status call at the long end. These calls are normally led by the PMs and tech lead and focus directly on the work. A wide range of people are invited to this call and participate as they are needed.
2. Project status: This is a call attended by the PMs, team lead, and interested managers and directors on both sides. Normally this is bi-weekly or once a month. It is designed to communicate overall red-green status, identify gaps, request escalations or additional resource, etc. It is not a technical call, but a project management call designed to keep both vendor and enterprise apprised of status.
3. Executive status: Enterprises deploy microsegmentation to obtain specific business benefits. A monthly or quarterly cadence with the executive sponsor and vendor executives and account manager ensures that the project is still aligned with overall business goals and priorities. It provides a standing forum for both teams to interact and prioritize appropriately for project success. This is typically a 30-minute meeting but may stretch longer before key milestones like entering enforcement for the first time.

And that’s it. At the heart of every successful microsegmentation deployment is communication. When all team members are properly trained, deliverables are outlined and adhered to, and the reporting cadence is agreed upon and maintained, an effective microsegmentation deployment is not only achievable, but easier than you may think.

Check in for part 4 of this series, where we will discuss five places to “lean in” in order to accelerate success with your microsegmentation deployment.