Multicloud Defense - Building Basic Policy

And welcome back. In this video, we're gonna go over the basic policy structure within cisco's multi cloud defense. What it's kind of comprised of, we'll talk a little bit, whiteboard a little bit, explain kind of some of the semantics and how I.00:05Just go around, you know, designing a policy and then we'll look at it, you know, within the user interface a little bit. So we do have documentation around policy, so if you look in documentation and you go to the security policy section, essentially everything that you need to start building policy is going.00:20Gonna be under the security policies and the subsequent sections within there. But.00:40What I want to do is explain a little bit about how we build out policy, what are the different components of it, and before we actually get in and start configuring that. So what I want to explain is the way that our demo has been set up thus far, specifically within AWS.00:45Is that we came in and we defined that we have an egress gateway in, I think it was US East two. And the way that it's built out.01:03Is that to, to the SaaS controller, that looks like a single firewall or gateway instance. But the, the actuality of it is that because we're supporting it across three different availability zones, you in essence have three different.01:19Instances built. You have instance one, you have instance two, and you have instance three, right? Across the three availability zones. So when we built those gateways out or that gateway.01:36We actually came in and we said, we give you the choice. You can attach an existing policy or you can build a new one. So by default, what happens is, and this is forever the rule, right? We can only attach one policy.01:52To that gateway, and that single policy is gonna actually build out on all three of those instances. And again, it can only be a single policy that's built out and attached to those instances. Now, we have two different policy types, and by default, like if you have a, if you.02:11Say hey, build a new a new policy when we build this gateway, it's gonna build out what we refer to as a standalone policy.02:31And a standalone policy is just that. It's a, it's a policy that stands entirely by itself, and it's comprised of, you know, multiple rules, right? So we have these multiple rules that are built out within there, and that standalone policy is what's been on within our UI as a, as a rule set.02:41So a rule set is comprised of multiple rules. There is another type of rule set that we can build out, and that's actually what we call a grouped policy or a group policy. Now the benefit of this group policy is it is actually a.02:59Set of standalone policies. So I could have multiple standalone policies defined. This could be like our standalone one. We could have standalone two and standalone three.03:19Three that are all members of this group policy. And then rather than us just attaching a single standalone policy to that gateway or those gateways, what we can do is we can attach this grouped policy.03:37To that gateway. And this does a couple things for us Besides just grouping, creating like sections within our overall policy, out of these individual standalone policies, it allows us a little bit more flexibility in that we can flip out.03:54The standalone policies that are within that group without rebuilding the gateways. So what happens when you attach a standalone policy to the gateway? Let's say that you've attached a standalone policy, we'll call it number one, and we've attached it to the those gateways. So those three instances were built out using standalone policy one.04:10Well let's say that we went out, we, you know, we have some changes that we wanna make, we don't want to make them to the active policy, so.04:30Kind off to the side, we come out here and we create standalone policy two with our updates. And then during our change control window, we say alright, we're ready to move everything from standalone two kind of into production. So what we do is we come say, hey, instead of you guys referencing standalone.04:37Policy one, I'm gonna change the association to standalone policy two.04:57What happens when you do that is when you attach a brand new policy rule set to the gateway, these actually go through the blue green update process. So it will actually build out three more gateways in this case that are running this new standalone policy.05:02And then once they're up and online, added to the target group, it'll, it'll take out and delete the old instances. So a lot of customers don't want to go through that blue green update process every time they wanna update their policy during like a change control window.05:19So what you can actually do in those cases is you can attach that group rule set to those gateways. And now let's say that I have some modifications I want to make to standalone one. What I do is I actually clone standalone one.05:35And I start working on that clone offline. So maybe I change, you know, rule one, rule two, and rule three, and I'm ready to put those into production. Well during my change control window, I actually just remove.05:53This association to the standalone rule one within that group policy rule set, and I add this new standalone policy maybe four that came of that clone. This does not cause the gateways to rebuild. It just does like an inline policy rule set update.06:08So we have NO blue green update this occurs, and it's just a little bit easier for a lot of our customers who want to not have to rebuild those gateways each time. So, if we get into our UI now and I take a look at our gateways.06:25I'm gonna take a look over here. I thought it listed it out. We take a look at our egress policy two. This is what we would refer to as a standalone policy. So what I'm gonna do is I'm actually gonna create.06:43A, we'll we'll call it egress east two group policy. I'll say this is gonna be a group and then within that group, maybe I like that, that, that standalone policy. I'm just gonna go ahead and add it as a member within this group. So.07:00Well then save that. And now what what I want you to see is check this out. So if I go into this egress policy, right now it doesn't have anything in it. We, we, we deleted the rule that we created in the previous video, but if I go to this grouped policy, now I see it as a section.07:19So if I were to, you know, make changes to the east two policy, I would see those changes immediately reflected within here. So if I wanted to, I could go back here, I could say, hey, let's create another, we'll call this, you know, standalone egress.07:37Policy two standalone policy, and then let's add it to this group, so we'll say edit, we'll add a new rule set, and we'll call it standalone egress policy two. So now I've got two sections within my standalone policy or within my group polic.07:53Policy so we can see the two. So now what I wanna do, and this, this will kind of reiterate my point, if I wanted to say, hey, I don't want just this policy associated with this gateway or these gateways anymore, I want to associate this grouped policy. Let's see what happens. So if I go to infrastructure.08:13Gateways, and go to edit. If I change out this rule set, watch what happens. So we'll go to egress east two group policy. We'll click save. It's gonna validate that I have enough re resources.08:32And we'll say yes. So it's gonna trigger the deployment of a new set of gateway instances that will eventually replace the existing instances once the gateways are active. Do you want to continue? And we'll say yes. So now what's gonna happen is, and we'll see this happen rather quickly, is that this number of running instances is gonna go from three to.08:50Six while it builds out those new gateways that have that new policy attached. So that's what most of my customers.09:11Typically don't want to go through, you can see it's already up to five. They want to just be able to replace components of that policy and not have to rebuild these gateways. So, what we, what, what I want to talk about while that's kind of rebuilding is what are these policy rules.09:18Rule sets actually comprised of because there are a couple of things, right? So a rule set.09:38Is going to be, let me find my pin here, An ordered set of rules. So you'll have like rule one, rule two, and rule three.09:45Now, these I mean that's very similar to what we saw in traditional firewalls, right? In ordered set of rules, that's fine. And within those sections or those standalone rule sets within that group drill set, they're ordered within those as well.10:03So what, what is within these individual rules themselves? Well, if you think to traditional firewalling, we always, we always want to match based on something. So we want some way that we can identify a specific flow. And typically that's gonna be by source or destination IP address. That is very similar.10:18Similar to what we do here is we're gonna come in and we want to identify, still I gotta find where my pin is here. We have to identify within these rules our source address and sorry my writing's horrendous.10:38Our destination address as well as our protocol. So this is gonna be things like, you know, TCP, UDP, our port.10:57And the port is actually gonna be a combination of source port and destination port. And as most network engineers know, this is typically the five tuples that we would try to match a flow upon.11:13Very similarly, we're gonna do that within multi cloud defense. Now how we do it's a little bit different than you maybe used to. Typically with the source and destination addresses, we're gonna have some type of object that we wanna match based on. And we actually call those.11:31Address objects within our user interface. So these are gonna be synonymous with if you're used to other firewalls, things like your object groups or network object groups or service objects that.11:48We're using to group like things together. And I will show some of these address objects off within the UI, but we can base this off things like IP address, we can base this off, you know, FQDDN.12:03We can also go a little bit deeper and we can base these off things like our CSP services. So if you think to like Amazon AWS, right, they have services like cloudfront.12:20And cloud front is associated with, you know, maybe a ton of globally available public IPs. So it's hard typically to do all the leg work manually to keep that kind of list updated. We do that for our users. Since we're already integrating with the API of these providers, what we do is we'll dynamically build things out based on the CSP service.12:36Courses that you see in these lists. Probably the favorite, right? Because we can also use these are a little bit more static in nature and like if you use IP or or CIDR to identify these objects, we kind of call those more of like static address objects. We also have this concept of dynamic address objects.12:56Which is more in line with like what this, this CSP matching of the services can do. Also, we look at other things like tags and labels, which is really, really popular for dynamically matching things. And this can be tagged on like instances.13:16The, the, the service, the, the V net or vpcs, so we we have quite a few options in terms of tags and labels that we can get into, but these are gonna be all of your like key value pairs that you can attach to these. And I I like to tell customers or potential customers, think of this like instead of saying.13:34Ten.zero.0.zero/eight can access the internet. Now we can say stuff like, hey, anything that's tagged with environment of production can access the internet. And that could have a single group member today. You run a CICD pipeline, it could have 200 members in it. And we're able to kind of adapt to those changes because of.13:54Our ability to do that, that real time inventory from these CSPs.14:14So, building out these address objects is imperative because we require an address object for the source and destination matches. We also have something that we call a service object.14:18And this is where we actually go in and we identify the port and protocol that we're using as well as the service type. So our service types can be three things. We can do forwarding, which is just, we're not proxying at all. We're just forwarding through the gateway without actually intercepting. This typically means, right, we.14:36Can't do things like decryption because we're not proxying, we're not man in the middling that. We also have a forward proxy. This is where we can forward the traffic, but we're actually going to intercept it. We're gonna man in the middle of it. We're going to terminate.14:56That session at the gateway, and we're gonna, you know, basically proxy the appropriate parameters to the backend connection which the gateway will instantiate towards the server. This allows us to do things like.15:15Like decryption of encrypted flows, which is gonna provide us a little bit more flexibility and efficacy when we start doing some of the advanced services. And then we also have what we call a reverse proxy, which is what our ingress gateway runs, which we have not talked about today.15:31So this is gonna be if you're like within AWS or Azure, you're hosting like a service, like a website or an FTP site that you want publicly available. So someone from the internet can actually interact with that service that would go through our ingress gateway and would run through this reverse proxy, which we'll talk about in a future video. But the.15:51Service object is where we're gonna come in and we're gonna identify.16:11How we want to treat the traffic forward, forwarded or or proxied. And we're also gonna identify things like the port and protocol being used. So if we were gonna come in and say, hey, I want to, I want to allow TCP 04:43 or all TCP ports, that's where this would come into play. This is also where.16:15For like forwarded flows, we could come in and we could optionally say, hey, I want to make sure we're snatting that traffic as it comes through this service. So we'll show all of this off in the UI right now. So.16:33I am back in the UI, and if you remember the previous video within AWS, we have a workload or a spoke VPC actually attached and kind of routing through the multi cloud defense gateways. So what would this look like if I wanted to proxy traffic?16:49On port 04:43, out to the internet. Let's set up an example of how this would look, and maybe I wanna dynamically identify this workload rather than identifying it by CIDR. Let's, let's do that too. So let's go into our instance.17:04Let's look at this spoke test Linux instance, and if I look at, I do have some tags on it. So I've got name, purpose, and environment. So let's let's use these to identify this. So, we'll start off.17:22By validating that our instances, they're still going through the updating process, which is fine. They're deleting now. So now our grouped policy rule set is actually attached, which is fantastic. So we will go to policies.17:39And rule sets, and we can see our group policy here. And just to show you that any changes I make and like the standalone policies are reflected within that group, I'm just gonna go into the standalone policy and I'm gonna click add rule. So.17:58This is one way you can build these out. So I could say, hey, I want to, allow test to 443. Just giving it an arbitrary name for this rule, it's gonna be a type of forward proxy, and then notice like my matching criteria is right here on.18:14For objects, so we've got that service object, we've got the source and destination, which are address objects, and we have an optional I didn't talk about this, but we have an optional FQDN matching object that I'll talk about a little bit later, but kind of think of that like an optional 6th tuple.18:34That you can match upon for identifying a specific flow. So the 1st thing it access is what service do we want to use? And the services that it brings up in this list are specific to the type of service, right? So if I flip to forwarding, I see two. If I flip to forward proxy.18:49I only see the one. So I want to create a new connection. I could also do this through policies and and services and address objects, but I like the inline method for showing it off it's a little bit more sleek. So we can see immediately for our service, I've got those three.19:09Service types that we talked about. I'm gonna do a forward proxy. We'll call this since it's a service that's not tied to any specific instance in this case, I'm just gonna call it 04:43 forward proxy. We're gonna come down here if we want to decrypt.19:27We need to select a decryption profile. And again, this is another policy component that we'll go through at a later time, but this is how we want to, and the certificate that we want to present for decryption purposes. So for our egress flows through the forward proxy, this is an intermediate cert because we're essentially.19:44Signing on behalf of something here.20:05So I'll I'll go again optional video, I'll go through the setup of a certificate and a decryption profile that can be a little bit more specific, but for right now, what we're gonna use is this sample egress profile. I will come in and say 04:43, and then this is the level at which we want.20:07To proxy. So is it.20:27TCP, HTTP, HTTPS, we have the option to do web sockets and websockets secure as well as TLS. So since I wanna do full layer seven decryption, we're gonna do HTTPS. I'm gonna click save, and notice it automatically populates it in that box for us.20:29So source and destination. Destination's gonna be internet, which we have those three predefined address objects for us, any which is basically your quad zero, any private RFC 1918, which is RFC 1918 space, and then internet which is basically the the opposite of what this is. So.20:48For destination, it's gonna be something on the internet, but for source, I want to create a new one. So this is gonna be, environment test. We'll call it dynamic group. And what we'll do.21:08Is we'll look in this list. I will, let's just talk about some of these now. So the 1st one, again, this is more of a static assigned is IP CIDR or FQDN. This could be a specific IP address. We could hit enter. This could be CIDR.21:27We could say this is, you know, MSN.com, it could be an FQDN. So this is fairly flexible in how you can use it. But again, it's more static in nature. You can also identify things based on, you know, pretty much any of the metadata that we bring into the system. So things like VPCV net IDs, security groups.21:45User defined tags, we do have goips so all you know the different countries that you wanna match are within here.22:05The service endpoints, so what I was referring to about being able to identify different services and we'll do that, that association of those services to like their public IPs within here. That's pretty neat. But what we want to do for this.22:12Is a user defined tag. And I don't want to limit this to any specific CSP VPC subnet. I wanna say, hey, regardless of the cloud service provider you're in regardless of the account, regardless of the subnet, I want to come in and say, hey, if at the instance level, so these are the different level, like the different.22:29The places we can use these user defined tags. So VPC vnet, instance, subnet, load balancer, security group.22:49But I'm gonna say at the instance level, if you have a tag of, let's see, what was my tag again? ENV of test. Wrong tab. So I'll just start typing in.22:55ENV, and it's dynamically pulling these so we can see ENV of test. So basically I'm saying put a workload or associate an IP address to this group if that IP address has a tag at the instance level of environment.23:12And test. Now, you can get pretty crafty with these in that you can put multiple values here. So I could say not only does it have to have an environment of test, but I want to come in and say purpose is testing. So I could say.23:31Purpose is testing. And notice what it does, it basically creates a matching and expression here. So I'll click save. So now I have environment testing dynamic group can get out to the internet on 04:43 through a forward proxy and I want.23:46To allow and log that. We have several options here, allow NO log, deny log.24:06Yeah, deny NO log. So I'm gonna say allow log. Now, what I will say is this is just our basic L3L4 firewalling. We are a next gen firewall in that we can optionally add any of what we call profiles.24:10To these individual rules. So things like IPS IDS, anti malware, DLP, URL filtering, I am gonna talk about these in the next video. This video is about just setting up basic policy structure, being able to validate that it's actually treating the traffic the way you want to. So all we're talking about.24:27For this video is L three oh four matching, so I'm gonna go ahead and click save. We'll save changes, and we'll save. And typically when you build out a proxy, it's gonna take it just a minute to finish the updating process. So while it does that, I like to show everything that we just did.24:45We now see under.25:05The addresses. There we go. Everything that we just did, creating those in line, we can see the inv ENV test dynamic group object, we can see it's got two sub objects, Y two? Well, that's because this node had a public IP. So it does basically any IP address that belonged to those.25:07Workloads that have those tags. This is kind of our it doesn't even matter in this case. It doesn't, it doesn't match anything here, but we are matching that workload, and if anything else pops up.25:27Within this environment or any environment for that matter that's onboarded to multi cloud defense, those additional nodes will be propagated here dynamically, which is really cool. The service that we created is right here, so we see 4434 proxy, we see everything that we configured within there.25:38Okay, it is updated now, so let's go back to our workload that we were using previously. And if we try to curl, this is gonna be remember, this was just on port 80, so this probably won't work, and it didn't.25:56I will go to curl HTTPS, colon slash/icon has IP.com and we see there's a certificate error because a self signed certificate's in the chain meaning we don't want to accept that self signed cert that the gateway's presenting, so I think we can use the.26:15Dash K flag here, and we can see 3.142.48.133. So let's validate that that's one of our gateways. We'll go to infrastructure gateways, instances, and yep, so it's 2nd gateway.26:34Way in East two B.26:54So we were able to get through that basic 04:43 proxy policy, let's make sure that we can validate that flow. So if I look at traffic summary, so again, anything going through our gateways, you'll see under this flow analytics, these are different breakouts of the same data, but traffic summary is gonna.26:56Show both front end and back end connections. So if I, if I click log here, what we see is that we have an HTTPS connection. It was using TLS one.three. But if I look, we're seeing ten, so the client to gateway was ten 18205.27:16And it was destined towards that 101-04-1805 dot 02:41. So what the gateway did is it proxied that traffic, so when it actually hit that icon has iP.com, it actually saw it originating from the public IP associated with this IP address, which is one of the the three gateways that we have.27:35Deployed. What I like about this is I can look at the session summary, we can see all of the different flags that are associated with this flow. We can see how many bytes were transmitted, we can see all the metadata that was associated, the requested SNI, the service type.27:55The policy, the rule set, everything is within here. We can further investigate this though if we wanted to. Under investigate, you can look at like all events. It will show you the actual like security pipeline and what happened through each step of, of, of the processing of that.28:14So we see we do see some stuff going out to SSM, which is pretty standard for, for Amazon. We have, you know, SSI SNI warnings. What we don't see here, and this is, this is an important tidbit, is that 1st flow that I kicked off on port 80.28:33Right, we only see the 04:43 traffic. We don't see that original blocked traffic. Why that happens is because by default, we have a rule at the bottom of our rule set that says deny all traffic and do not log if none of the above rules match.28:52So this is why I have a lot of customers who will actually, and I usually tell them to do so, is put in a default deny rule that you've manually created that is a catch all that logs. So when you're troubleshooting, you're able to see what is actively being denied because you.29:10You can always have that rule present.29:30And you can just disable it. So typically like when we're 1st standing up these systems I will build out a rule that is a de default deny with an action of log. So I hope this video's been informative, I hope it's given you a little glimpse into the basic policy rule structure within multi cloud defense, how to build that.29:32That out. And in a later video, we'll actually get into some of these advanced profiles that we can create for things like snort based IPS IDS DLP, anti malware, and so.29:52As always, if you found this video useful, keep a key eye on this channel as we will be releasing more and more content around the deployment and uses of multi cloud defense and how you can use it to protect your cloud infrastructure. Thank you for watching.30:05We look forward to seeing you in the next video.30:16