Guide de l'architecte pour le déploiement de la microsegmentation : implications de la modification du modèle de sécurité

An architect or project manager for a microsegmentation deployment benefits from a clear picture of the desired outcomes and how the deployment will truly impact his or her organization. At the same time, delivering these insights often require the support of other team members, some of whom may not even fall within IT. What does an architect or project manager need to know about microsegmentation deployments to stand up a new project, keep it on track, and achieve optimal results?

This series will explore those very questions and examine the key insights that will put your team in optimal alignment to deliver the results you expect and need to deliver to the business – drawing on experience working on hundreds of microsegmentation deployments.

In part 1, I will discuss the implications of altering your security model. Moving to a microsegmentation solution alters the existing network/perimeter model in several important ways, described below. Each of these modifications enables some of the benefits that made micro-segmentation attractive in the first place, and each of these modifications has implications for the enterprise.

The enforcement point moves from network to host

Traditionally, security is placed at perimeter chokepoints, whether at the edge of a VLAN, the PROD environment, or to the Internet. In this model, there is little direct interaction with the application, server ops, or automation teams. The change to host-based enforcement means that:

• Operating system mix and agent support matters
• Availability & consistency of automation and administration tools will impact how agent deployment happens and how fast
• Application owners, system admins, and automation developers will interact in ways that are new to them and the security team
• Having security “inside the operating system” is new to the application/admin teams and they will need to understand what that means for them.

Security policy moves from a mixed blacklist/whitelist model to a pure whitelist model

Hardware firewalls use a mix of permit and deny statements. This means that the order of rules in each device matters greatly. In the best microsegmentation policies, there are only permit statements. Naturally, this is the practical implementation of Zero Trust principles for segmentation. But it also removes rule ordering concerns and allows for flexible multi-dimensional policies. It is a different way of working and specifying policies that will have a brief transition time as policy authors learn a new way to express their desires. It creates a much simpler policy that is easier to “read”, making audits and compliance verification much easier. Expect to spend time with those teams educating them on the new policy model.

Security policy statements move from network/IP dependent statements to metadata driven statements

Hardware firewalls depend on IP addresses, ports and protocols for rule-writing. All microsegmentation vendors provide some type of labels or meta-data to express policy statements without any reference to network constructs. This means that the security policy will be understandable by more than just the network or network security teams. Graphical “point-and-click” mechanisms for rule-writing also provide an almost non-technical way to author security policy. When combined with powerful role-based access control (RBAC), it becomes possible to consider distributing rule-writing more broadly within the organization. Whether this is desirable or not will be organizationally specific.

Although metadata has not been historically important to the security team, the parts of the broader organization concerned with automation make heavy use of it. The confluence of security and automation teams both generating and consuming metadata implies that paying special attention to metadata design, storage, modification, etc. are necessary and worthwhile efforts that can positively affect the agility of the entire organization. This broader conversation happens best when leadership reaches across silos and workgroups and assembles the full range of constituents affected to drive a common solution.

API-driven security automation is available

While automation and orchestration are normal words on the application and system sides of IT, they have not been as common on the network and security team. But a good microsegmentation solution provides a fully API-driven workflow. Every capability of the platform should be accessible through the API. This means that the ability to automate security is limited only by imagination, time and attention. It will again require cross-functional teamwork for the organization to understand the possibilities, prioritize the automation desires, and implement the resulting plans with appropriate phases. Time spent on metadata cleanliness and organization will pay big dividends when automating microsegmentation policy.

In each of these observations, the common thread is that this deployment will cross internal organizational lines. It will offer capabilities that have never existed, and it will generate and consume data that is new to the team. Put most simply, this is “change”, and not “more of the same”. Each organization will have its own attitude towards change and the single largest management task is to match this change with the ability of the organization to absorb it.

Today we explored how microsegmentation fundamentally alters the existing network/perimeter model that your organization is likely “comfortable” with. In part 2, we will discuss the next key insight that will enable your team to deploy microsegmentation with the greatest success: how to build a deployment team.

For a deeper dive and a great read on everything you need to know to successfully deploy microsegmentation, check out the eBook, Secure Beyond Breach: A Practical Guide to Building a Defense-in-Depth Cybersecurity Strategy Through MicroSegmentation.