Hi, welcome to the policy validation in Cisco Secure workload success Council. My name is Costandino Trifiles and I'm a customer success technical leader at Cisco.00:05This access capsule has been designed to help you navigate the policy life cycle in Cisco secure workload. We will discuss the policy hierarchy model, review all of the available options to analyze, validate, and test your policies before and after enforcement and explore the tools that secure workload provides to help you maintain your policy hygiene.00:15Micro segmentation is a journey and starting is often challenging and requires several steps until it's time to enforce security controls. 1st, application dependencies aren't always fully understood. Some communications happen only during backups, scheduled jobs or month end processing. Building the right policies requires collaboration.00:35Question between application, infrastructure and security teams.00:54Second, we need to understand what our policy will actually do. With an intent based approach, we're expressing which groups of workloads should communicate based on context. We need to confirm which workloads those groups include, which rules apply, and whether the resulting behavior matches our intent.00:58And 3rd, the environment doesn't stand still. New workloads appear, applications move and dependencies change. A policy that was appropriate yesterday may need adjustment tomorrow. To summarize, validation is not a single step before enforcement. It runs across the whole life cycle.01:16Let's start with the AI policy discovery. The idea is simple. Convert observed flows into an initial policy draft rather than starting from a blank page. Secure workload uses machine learning to group workloads with similar communication patterns into clusters and suggest allowed list rules.01:34Identifying who communicates with whom and on which ports and protocols. This reduces the manual effort of building an initial policy, but you remain in control. Discovery settings can be fine tuned. Generated policy can be reviewed and modified, and you can add or remove rules based on your requirements.01:52Most importantly, AI policy discovery produces a draft. Observed traffic tells us what is happening, but not necessarily what should be allowed. This is just a starting point and all the validation options we will explore next will help us review and adjust our policies.02:11Let's explore the AI policy discovery in a workspace. We're gonna click AI policy discovery, and the 1st step is to review the workloads for which we're gonna generate some policies. We're gonna click next. We're gonna select to use telemetry for the past one day.02:26And then we can use the default or the advanced configuration where we can adjust the AI policy behavior. We cannot start with the default. Once we click discovery policies, it may take a while to convert the observed flow into allow rules in your workspace. Once the results are available, we can start polished review.02:45Policies are represented using context in the source and the destination site and they are grouped based on the ports and the protocols. In the policy tab, we will see that there is a new version that has been added here. This will be the case after every AI policy discovery run.03:05Next step would be to start reviewing the rules and we can approve some policies if we want them to persist across AI policies around. Additionally, we can add or remove some rules manually, and we can even add a new policy if necessary.03:23Before we validate the policy, we need to understand which rules take precedence. There are three types of policies, absolute default and cuts all. Absolute policies are evaluated in the top to bottom order and absolute policies in parent scopes will take priority over those in child scopes.03:38These are used as guardrails and the child scope cannot override the matching policy from its parent. Default policies on the other hand, are evaluated in the bottom to top order. Default policies of child scopes will take priority over those of the parent scopes. The same applies to the catch all policies in every workspace.03:56Policy evaluation stops at the 1st match and any further rules will not be evaluated. In this example, we can see how policies are applied when enforcement in the application and parent scopes is enabled. We can see that the absolute policies of the parent scopes are deployed 1st.04:15Then they are followed by the default policies of the childscope, following the bottom to top order and finally the catch all rules. Again, following the bottom to top order. Now that we understand policy order, we can test how our policies compare with real traffic.04:30Policy analysis evaluates the policy against live traffic without enforcing it. The results help us identify where observed traffic and policy intent agree and where they differ. Policy analysis provides a verdict for every observed flow. Permitted means a flow must and allow rule and was allowed.04:45Escaped means a flow must a denied rule yet it went through. In this case, we need to investigate whether that's legitimate application traffic requiring an allow rule or unwanted access we intend to block and we can adjust the workspace policies accordingly. Rejected means the traffic must denied rule and was dropped. Let's see the policy and now.05:04Scenario.05:24We click on the policy analysis tab where we can see it's initially disabled, and we're gonna need to click start policy analysis on the right side and analyze to start the process. Once it's activated, we can see the flag that indicates the policy analysis running. And on the top we can see also the labels and we can filter the traffic based on the permitted.05:25Check it or escape flows.05:45Next, we can see a list of the flows in their verdict. There are many options to filter the results, and in this example, we can review the traffic for the past 1 h and focus on the results after the policy analysis started. In the same policy analysis a little later, we can see some script flows appearing.05:49In this case, we may want to investigate why flow has been marked as escape. By expanding the entry, we can get some more information about the flow such as the source and the destination IP address. And we're gonna click on policy analysis to find the matching policy.06:08Analysis in enforcement works in a similar way, but in this case, instead of running a simulation of a policy draft compared to actual traffic, we evaluate the host firewall rules deployed on workloads, just like in policy analysis.06:27Every flow is assigned a verdict. So in this case, instead of seeing what would happen, we see the effect of host firewall rules on actual traffic. Let's activate enforcement in a workspace. We go to the enforcement tab and click enforce policies.06:421st, we select the version that has been published for analysis. In this example, it's P one. We can see in green the policies that will be deployed to the workloads. Next, we review the policy hierarchy.07:02Followed by a list of the workloads where the policies will be deployed. Assuming everything is ready, we click accept and enforce. After that, we have a view similar to the policy analysis tab. In this view, the purple icon indicates that policy enforcement has been enabled.07:15On the left side, we can see the enforced version is P one and is matching the published version in the policy analysis. From here we can filter the traffic for the past 1 h and start investigating after the enforcement was enabled.07:34In this example, we can see some rejected flows. And just like in the policy analysis, we can expand the entries, get information about the flow, and run a quick analysis to find the matching policy if necessary. Additionally, just like in the policy analysis.07:55There is also the option to filter based on the policy verdict. So we can focus more on the traffic that requires further investigation.08:16The next tool in our disposal is quick analysis. While life policy analysis looks at observed traffic, quick analysis lets us test the hypothetical connection. We enter the client and server addresses, the protocol and the destination port.08:24And select find matching policies to see how the relevant policies would treat that connection. The results display both the consumers and providers policies, and in both cases, the traffic must match and allow a rule to be permitted. This makes quick analysis useful for troubleshooting a specific connection before or after enforcement.08:39There are many places where you can run policy analysis. You can start by going to segmentation and click around quick analysis on the right side. 1st, we need to select if we wanna test the analyze or the enforced policies. We provide the consumer IP address and the provider IP address.08:58We select the protocol and then we need to add the port and click on find matching policies. The result we saw as a consumer and the provider policies as well as the policy decision, which is denied in our case. We can also run policy analysis inside the workspace by clicking quick analysis on the right side of the page.09:16Just like before, when it 1st select the analyze or enforce policies, and then we provide the consumer and a provider IP address to get the results. We can also repeat the same process in the policy analysis page. Expand the flow that you want to investigate.09:35And click on quick policy analysis. As you can see in this case, all the fields are pre populated and then click find matching policies. From here we can see the consumer and provider policies and the policy decision. Run experiment is a feature very similar to policy analysis.09:52Unlike policy analysis, which is evaluating your policy rules against real time traffic after enabling it, the experiment feature will help you test your policy configuration against past traffic. It basically answers the question, how would my current policy have handled this traffic?10:10A very common use case to run an experiment is a scenario where you may have had an incident and want to review if any policy changes would have blocked the attack. Go to your workspace and click on the policy analysis tab. Click on run experiment.10:27And provide the name for the experiment. Next choose the time range for the telemetry you want to test. When you're ready, you can click start.10:44Now the feature is running in the background. You can monitor its progress by clicking on the policy analysis button and check its status. Once the process is complete, click on live policy analysis and should see the experiment results. This does not stop live policy analysis from running.11:04From here on, you can continue your policy review the same way as we discussed earlier. Every flow here is annotated based on the latest policy version. Beyond testing individual connections, we also need to understand how our rules are being used.11:20Policy heat count shows us how many flaws each rule musts over an observation period. Alongside those counts, the AI engine flags conditions that deserve attention. No traffic means the policy hasn't affected any flaws during the configured period.11:36Overshadow means another policy takes precedence, preventing this rule from taking effect and broad highlights an underutilized search or destination filter. E.g., a group containing ten workloads when only two participate in the observed traffic.11:53Together, these indicators help us prioritize which policies to investigate and where we may need to tighten access. These are the signals for review, not automatic instructions to delete or restrict a rule. A zero heat policy might still support an infrequent business process. So we should confirm its purpose with the application owner before.12:08For making any changes.12:281st, let's check the default settings for policy AI settings. Review the default interval values for each type, and then choose the labels you want to activate. Next, go into the workspace and make sure the condition column is enabled.12:30You should see the rules being populated with labels. Click on a rule and then click on each individual label to get more information. You will see that for each label, there is a short description to help you understand why a particular rule was marked with a conditional label.12:51Once analysis highlights a potential policy gap, AI suggested policies help us decide how to address it. Secure workload analyzes traffic on an ongoing basis and proposes rules without requiring us to manually run a new AI policy discovery.13:11Instead of translating flow records into rules ourselves, we get suggestions with supporting traffic information to review. But observed traffic is not automatically legitimate traffic. We still need to decide whether that communication should be allowed and whether the proposed rule has the right scope.13:28We review the suggestions, incorporate the appropriate changes, and validate the resulting policy before enforcement. Accepting a suggestion is not the same as enforcing it. This connects finding a gap with proposing a change and reducing manual effort while keeping the policy decision under our control.13:46You can see which workspaces have AI suggested policies. Click on a workspace, and on the left side, you should be able to review all the AI suggested policies. Once you do your review.14:04Assuming you agree with a policy that needs to be part of the workspace, you can click the check mark and then add selected policy to become part of your workspace. Another way to use the AI suggested policies is by going into policy analysis. Let's say you review your flaw.14:18And you believe this flow requires to have its own policy. You can click on suggest policy and you will see it will automatically pre populate the workspace, the application scope, the consumer and the provider alongside the action, protocol and port. And by clicking add, it will automatically add the new rule to your workspace.14:36The last part of policy validation is to review the exact host firewall policies deployed by secure workload. It will help you understand how secure workload translates the workspace rules for each individual host. Before logging into a specific workload to review the host firewall rules, you can start in the secure workload dashboard.14:54There are three types of rules you can review in the dashboard. The concrete rules, which show the rules programmed in a host firewall such as IP tables or the Windows firewall. The container rules that are deployed on an orchestrator platform and the security groups deployed on a public cloud provider.15:15To review the concrete policies deployed on the host firewall, click on the host profile, and on the left side, click on concrete policies. You should see the list of the rules that are deployed on the host firewall. And for the workloads on the public cloud, you should be able to review the rules that will be programmed into the security group policies.15:32Thank you for watching. I hope this video was helpful to help you validate and troubleshoot micro segmentation policies in Cisco Secure workload. Visit the Cisco community pages for more content.15:55
