This blog post takes you through an example scenario of how Illumio’s multi-dimensional labeling allows organizations to generate micro-segmentation policies by aligning policy creation with their organizational structure – one of the most unique capabilities of the Illumio Adaptive Security Platform.
FROM THE "MINISTRY OF SEGMENTATION" TO APP TEAMS: It takes all kinds
As I’ve met with customers implementing micro-segmentation from a wide variety of industries and with different organizational structures over the last four years, no two companies’ projects and organizations have been identical. Some companies are highly centralized in their segmentation policy creation. In these companies, a small group of people are responsible for authoring policy. Here are some prevailing characteristics that I’ve seen (note that there are exceptions to the rule!):
- Large companies that are able to centralize policy creation usually have high-fidelity CMDBs. Some of our customers have a small group of people authoring policy for more than 100,000 workloads that serve over 4,000 applications. A small team is able to do this at scale because what they see in Illumination – the real-time application dependency map that displays all workload communications – is accurate, and they don’t have to reconcile whether a particular server is really part of the application it is assigned to in the CMDB – they know it is.
- Organizations with a smaller number of workloads are able to centralize policy creation because of scale. They simply muscle through it. Through Illumination, they are able to quickly classify their workloads and their applications, and thereby generate policy.
- Large organizations that have CMDBs in need of improvement – or have no CMDB at all – usually distribute the work of policy creation to application teams because the app teams have better knowledge of how each of their applications work. Those teams look at Illumination and:
- Ensure that workloads are categorized accurately
- Suggest policy
Now here is the catch: just because an app team can suggest and create a policy, doesn’t mean that policy automatically gets promoted into Production, and the policy created by the app team needs to be run in their Development environment to be sure that it doesn’t break the application.
When we first created Illumination, we were building it for centralized organizations; they seemed to have the most immediate need for our product and it was easiest to make it work with their organizations. To put it another way, their requirements around micro-segmentation were perfectly aligned with how Illumio’s product worked.
The process of retro-segmentation (the act of retrofitting an existing application to micro-segmentation designed for security) cannot always be solved by the “ministry of segmentation” (a centralized security organization).
In these cases, the job of policy authoring needs to be distributed to teams of people.
In my experience, the work gets distributed to application development teams – and here is where role-based access control (RBAC) and multi-dimensional labeling work hand-in-hand. If you don’t know about Illumio's approach to labeling workloads, check out this video on why labels matter for segmentation.
A COMMON CASE: (RETRO)MICRO-SEGMENTING WITH ILLUMIO
Without further ado, here's an example scenario of how to align policy creation with your organizational structure, starring role-playing client, "Jennifer CISO," and client organization, "Boxing Gear Inc."
Let’s imagine that Jennifer CISO decides to distribute policy authoring to the teams that work at her company, Boxing Gear Inc. Boxing Gear is a fairly complex company – it has many different applications (ERP, customer ordering, partner portals, web portals, payroll processing, HR, etc.). Because Boxing Gear Inc. has been so successful so quickly, there are many application development teams developing these applications, updating applications, and creating new applications (like a new punch analysis tool).
The Jennifer CISO is a responsible CISO and has recognized the need to compartmentalize Boxing Gear Inc. because their competitors have had issues with being infiltrated, and the CEO has asked Jennifer to make sure Boxing Gear stays out of the press. But here’s the catch: she can’t bring on a new team of people to do it.
Jennifer knows she needs to retro-segment her infrastructure. The question is how to do it without hiring an army of people. She doesn’t want to bloat her security team, but at the same time she can’t afford not to take action. She calls up Ilumio and asks: “What are your recommendations?”
CLIENT ENVIRONMENT OVERVIEW
Based on her organization, the number of workloads, and the pressure from her CEO, Illumio tells Jennifer to push out initial policy authoring to her teams. Illumio puts her on the phone with customers that have done so and, ultimately, Jennifer decides that’s the way to go – but she doesn’t want developers writing policy for production applications.
Some of Boxing Gear Inc.’s homegrown applications include: Ordering, ERP, HR Punch Analyzer, CC Processing, Partner Portals. Most of those applications are in: Development, Test, Staging, or Production environments. Let’s not forget that there are some shrink-wrapped applications that simply live in production (but serve non-production environments). They include: Active Directory, DHCP, DNS, and Tivoli.
Most of the applications live in Amazon, but the HR application lives in two locations: Amazon and Luxembourg, which is important because the personally-identifying information of Luxembourg employees cannot leave Luxembourg.
Let’s look at this differently:
Looking at it this way, there really isn’t “one” instance of their homegrown applications – there are four instances of them.
Now let’s look at that same data with a bit more information:
Many applications have different tiers. For simplicity's sake, let’s just say that some are three tier (web, app, database), some are two tier (web, database), and some are one tier (full stack).
With that, let's revise the matrix above – by ascribing tiers/roles to the workloads that comprise each application in each environment:
HERE'S WHAT ILLUMIO RECOMMENDED
Using RBAC, allow the manager of each app team to develop policy for their respective application. This way the app owner of the ordering application can create a policy for the Development and/or QA instance, but cannot author policy for the Staging or Production instance. So now, using well-known RBAC controls, an organization can push out policy creation.
In the same table as above, I’m color-coding “Dev” and “Test” in blue because the application teams can author policy for their respective apps, within those environments. However, you’ll note that “Staging” and “Production” is coded green because only the production security operations team can author policies for the production environment:
The sections in blue above allow groups in Dev and Test to author policies within those
environments, while the environments in green can only be authored and tested by the central security operations group.
Here’s what happens when an organization can push policy authorship out to an app dev team:
First, the owner of the development app logs into the Illumio web console and gets a view of the Ordering application that looks like this:
Then the owner uses Illumio’s Policy Generator, which looks like this:
Check out Policy Generator live in this video.
Side note: If you are really brave, you can put our video of creating segmentation policies using Policy Generator on loop and compare it to this video for writing rules for two flows across three workloads using vRealize from VMware. But here’s the catch – you have to watch our video on a loop and drink one beverage of choice every time we create a policy to the time that it takes Arkin to finish.
...bottoms up! (Can we get you a Lyft?) Now, back to Boxing Gear Inc.
Jennifer’s team doesn’t have “author” policies – that’s being done in Dev and Test. Jennifer’s team can now copy the policy created by the people who know how the applications work (the people in Development and/or Test) into the Staging environment to make sure it works and adheres to broader policy constraints before moving them into Production.
Thereafter, as new versions of the Ordering application make their way through the classic software development lifecycle, the security policies follow the application.
This example was for one company. We built micro-segmentation policy creation to be used with RBAC to enable any organization, regardless of size or structure, to align their segmentation policy creation with their organization.