Dan Sullivan • 00:03

Hi, everyone. Welcome to the orchestrating hybrid cloud and multi-cloud security services webinar. My name is Dan Sullivan. I’m a principal solutions architect here at Itential. I’ve been with Itential for about four years. I’ve been working in customer-facing pre- and post-sales roles focused on automation for about the past 12 years or so. My background is largely in software development, distributed systems, and automation. Here at Itential, I work with a number of financial institutions, banks, healthcare providers, as well as a lot of other large enterprise and service provider customers. Every time I speak with them, really, security is top of mind. And these days, right, securing large organizations and networks isn’t really getting any easier. In fact, it’s getting harder every day. Security is way more than just a single firewall like it used to be. Most organizations are hybrid in nature. They have data centers, multi-Cloud deployments, whether it’s AWS, Azure, or GCP, or multiple Clouds.

Dan Sullivan • 01:24

Security is always a concern and most organizations, they’re even using SD-WAN solutions, they have on-premise firewalls, Cloud-based firewalls, security platforms like Zscaler. Really managing security for these environments really almost necessitates an orchestrated solution. Today’s webinar will focus on how an orchestrated solution can help navigate some of these complex environments. We have a little bit of a demo, we’ll walk through to get that point across. First, before we get into the demo, I’ve just got a couple of slides to set the stage as to what we’re going to cover. Again, security is just not confined to that old on-prem firewall. There’s virtual firewalls, security groups, and network ACLs, your data center firewalls.

Dan Sullivan • 02:24

All of this apparatus really needs to function together, to provide security across your entire network, and your entire organization for that matter. A single vulnerability with one of these systems affects the entire network. So, for today, we’ll have a little bit of a demo that we’ll kind of walk through in detail about how you can use an orchestrator like the Attentional Automation Platform to actually help coordinate all these disparate security systems that you have. We have a couple of examples for today. We’ll just focus on AWS and Palo Alto Panorama for today. But throughout the demo, hopefully you can see how you could easily extend this to other security solutions that you might have deployed in your environment. It just gives you an idea about what’s possible.

Dan Sullivan • 03:19

So what we’ll do is we will have a demo about basically IP blocking. So we have a number of customers. who are constantly being attacked and when they discover a malicious IP address or even a network, they need to stop access to that network or from that network across all their domains. So if it’s discovered in AWS, it’s no less important to block it on Palo Alto and vice versa. And for customers that have even more security infrastructure than what we have in a little demo here, well the problem is actually exacerbated. And so we’ll give a little bit of an example as to how we do this today. All right, so what I’m going to do now is just share my screen, and we’ll sort of get into this. So let’s see here. So to start with, let’s see here. I’m going to go to, once I log into iTensio, you’ll see here that I actually have this IP address blocking implemented as an iTensio project.

Dan Sullivan • 04:28

So I’m just going to click into it for a second here, see what I’m saying here. And now what you’ll notice is I have a number of folders here. So I just have kind of all the assets that I’m using in today’s demo. And I’ll kind of go through this, because at the base of the project, all we’re really trying to do is block access to some sort of a malicious IP or a network across the two network assets that we have today, which are AWS and Panorama. Let me just click in here, so you’ll see the block and unblock. That’s really the foundation of what we’re doing, and you’ll see here that we have also a folder for Panorama. If I click on that, you’ll see the block IP workflow show up here.

Dan Sullivan • 05:20

In my case here for Panorama, what I’m going to do is basically, every time I get a request to block a particular address or network, I’m going to actually create an address within Panorama, and I’m going to create that address with a specific tag. You’ll see here that the second block in this workflow is just that create call. You can’t really see here, but I’ve got a little payload and I’ll actually create an address by making an API call to Panorama, and I’ll create it with a specific tag. I have a dynamic address group configured, so I’m merely just trying to add addresses to a dynamic address group. Then the idea would be that I would have a block policy configured on that particular address group. Now, of course, there’s multiple ways to solve this particular problem with Panorama or other technology. But the idea here is that you figure out what it takes to implement security the way that you want when you have a block, and you just drag and drop those API calls on the screen and build a workflow.

Dan Sullivan • 06:35

Notice here, the last bubble here is just some context. So basically, we’re going to save some information so that later on, if we want to delete that address, we know what to delete exactly. Now, if we look at AWS, there is a similar thing. For AWS, we’re going to focus on a particular VPC, and we’ll create network ACLs. So in our case here, we’ll read the ACLs, figure out the last ACL, the last rule used, and then we’ll create our new ACL entry with the appropriate rule. And we’ll also save some context. Basically, we’ll save the rule number.

Dan Sullivan • 07:20

We’ll return the rule number from the workflow so that we have some context about how later on we might want to actually delete that if we wanted to. But of course, in general, all these workflows are fire and forget, right? They don’t really save any state. Once they run, they’re done, right? They don’t have any… Other than maybe from an auditing perspective, you can view the workflow data and see what happened, who did what. But in terms of actually maintaining any information, they don’t really do that.

Dan Sullivan • 07:53

So, what we’re going to do then is also have a top-level workflow called block IP. And that IP, that workflow simply just calls the same block IP address workflow, and then it does the same thing for AWS, right? You can see, again, we’re going to save some context information, and that will become relevant in just a bit. I’ll sort of explain why we’re going through this process. And you can see here, if you had yet another infrastructure, you had Zscaler or an SD-WAN solution, you just add another block and unblock prefix workflow for those particular technologies. You could just stitch them in here, and now you’d have a solution that actually spans across your infrastructure. And, again, it’s not so important about how we’re doing it.

Dan Sullivan • 08:48

It’s more important about how we can stitch all this together, really. So now we have this top-level workflow that will block a prefix. We have a similar one for unblocking. Not really necessary to probably take a look at that, but you get the idea. But we have two sort of stateless… Workflows here, they block and they unblock. But what we might want to do is, we might actually want to save some of the state.

Dan Sullivan • 09:18

Why is that even useful? So for example, today, a lot of the customers that I talked to, it’s not only important to be able to block something, but there’s usually audit requirements to be able to say why you did it, when you did it, and who did it. I might want to access that information dynamically. So for that purpose, we’re actually going to introduce what we call the Intentional Lifecycle Manager. The Lifecycle Manager will actually interface to these block and unblock workflows. What will happen is, the Lifecycle Manager will actually allow us to save some state. Now, we’ll have a running record of what prefixes or hosts we’ve blocked as part of our service.

Dan Sullivan • 10:13

So if I go over to Lifecycle Manager, What you will see here is that here’s some instances that have already been blocked, but I’m going to start over here on this first tab, which is the model. We have basically, we’ve expressed our model for this particular service in JSON schema. I won’t get into it too much, but you’ll see here there’s a property called IP prefix, and that’s simply the prefix that we’re blocking. We’ll have a start time as to when we actually initiated the block, and this will actually be filled in by those workflows themselves. We don’t necessarily need to specify that. The other piece of input we might want to specify is the block duration.

Dan Sullivan • 11:02

How long do we want to block a particular prefix? Then we have some context information, and that’s largely what we talked about before. In this particular case, we’ll save some context information from Panorama and AWS, so that at some point in time, we can go out and actually remove that from the network. Now, we have a stateful representation of those block and unblock actions that we were looking at prior to this. Now, once you have this model, the way that it connects to those workflows is via these actions. I’m going to click on this Actions tab, and you’ll see for the particular model that we have, we have two actions filled out. We have a delete and a create, and the create does the block, and the delete does the unblock.

Dan Sullivan • 12:01

If we jumped back into here, we can see our LCM workflows that we’re calling the create, and all the create does is call that block IP job that will in turn block a prefix on AWS and Panorama. And then the other thing that’s a little bit different about these workflows is that they take a specific format of input. So the instance data, that model that we specify is provided as input to us. And then at the end of the workflow, we will save state and we’ll save data back into that model. So we can update the instance data for each particular model. So each particular instance will have a unique set of data saved to it. And so that’s really the idea here is we’ve taken the stateful representation to find a model and we’ve applied it to some existing sort of stateless workflows that we’ve created.

Dan Sullivan • 13:02

We made a little bit of, we did a little bit of work because we were gonna save some context so that we can clean these up and unblock them when we need to. But by and large, pretty straightforward mapping in between the model itself and these stateless workflows. Now, if I click on instances, I can start to see I already have some prefixes blocked and they’re pretty straightforward. If I click on one of these here, I can actually go over and click on properties. Then again, it will show that here’s the prefix that’s been blocked and I’ll use that same prefix as the instance name. I’ll explain why I did that in a bit. You’ll see the block start time, the duration, which is 10 days here, and the name of the IP address we created in Panorama so that I can go back and remove it if I want, and then the rule for the inbound and outbound security rules that we created in AWS.

Dan Sullivan • 14:05

We have both of those saved. Now, we have enough information that we can go back and delete this and clean it up. Also, we have all of this existing data that we can access, and we can use this to basically tell other and form other systems about, hey, what’s blocked and how long it will be blocked for. I can actually, if we want, can actually create an instance to block directly from here. If I create a new instance here, Okay, so now we can actually configure an instance directly from the LCM environment if we want. So I can pick a prefix here and try to block it, so let’s see.

Dan Sullivan • 14:57

Usually I want to save it as the name, so I’m going to do that. I’m going to pass it in as prefix and I’ll just hit save. And we should see that here with the timestamp 1126, so it looks like it’s running. So we can click on that and it looks like it’s already completed. So now if I click on properties, you’ll see that it’s gone out, configured that group and panorama and that address rule. So if we went into panorama here, did a refresh, we should be able to see that. So let’s try this again, we’ll go to that particular VPN.

Dan Sullivan • 15:55

So I’ve got a specific VPC that I’m using for this, and so let’s see here. So you’ll see the 209 address is indeed that address that we just blocked, and we should go, if we go to Panorama, we should see that same thing, that same prefix get added. So, yeah, so it’s also been added here in Panorama, it should show up on the screen in just a second. And. It looks like it showed up here as well, so we’ve been able to successfully block the prefix on both Panorama and AWS. Now, we can also just do this straight from Operations Manager if we wanted, so we can do the same thing from Operations Manager. I’m just going to jump over here.

Dan Sullivan • 16:50

Here I’ve got a little bit of a form created here, so they can actually do a blocking request here. Now, I also have Operations Manager entry for deleting a service. Now, if you notice here that we have a whole bunch of triggers to find, and what’s happening is that as soon as part of that service, not only am I calling the block workflow, but I also am calling another workflow which actually creates a trigger and schedules it. Based on the duration, I’ll actually schedule all these prefixes to be deleted. Now, I don’t have to worry about cleaning it up on it. I don’t have to have someone do it manually. I actually have these all scheduled, and they will run at the appropriate time.

Dan Sullivan • 17:45

At this point, the trigger gives the time when it’s going to run. Maybe this doesn’t work. You could always go back to the workflow and add a specific time when you can actually make a network change so that it occurs during a maintenance window, but you can set the triggers any way that you want. It’s just a little bit of an example of how we can leverage some of that stateful data we have and actually schedule the delete. But again, I can do the same thing on the service create if I want. If I just run this manual thing, in this case, I just put the prefix in and I can hit the run button, it’ll go off. So the form itself is catching me.

Dan Sullivan • 18:43

If I have a typo in the entry, then the form will give me a hard time, and that’s exactly what happened. That time it took it, and again, it’s going to go off. It’s calling the LCM action, and it looks like the action ran successfully. Again, we blocked another IP address. So that’s pretty interesting. And we can do the same thing for delete. So if I were to click on the, if I go back to the automations here and click on the delete, If I run the manual change here,

Dan Sullivan • 19:20

down here, so there’s two pages of these. If I had the manual trigger right here and run that, it’s going to give me a form and it’s going to ask, and in this case, I can only select one of the specific blocks that I have. This is one I know I have configured, so I can just run this and it will go off, and should go off and unlock this for me. You see the same thing, the action that ran pretty quick, so it looked like it already deleted it, so I should be good to go. We’ve been able to block and unblock IP addresses. We have a couple of examples of us doing that. But really, one of the other powerful parts of Lifecycle Manager is our ability to actually leverage some of this data.

Dan Sullivan • 20:17

The interesting part here is that this data is useful, because now we have an active record that tell us how tell us what’s blocked. So really the idea here would be that, what could we do with this? How could we leverage it? And so for today’s demo, what I’ve actually done is written a small Python script that will read the existing LCM instances via an API call. Now, you might ask, hey, you have an orchestrator there, why didn’t you just do the work within ITENTIAL? And the reason is, is if we have enough prefixes blocked, if we have several thousand of these blocked, ITENTIAL doesn’t necessarily have the ability to do overlapping checks and to see if a host is contained within a particular network or anything like that.

Dan Sullivan • 21:18

That’s better done in Python. There’s a lot of open source modules that do that. So we can pretty easily do it in Python. And we’ll want the Python script to actually use the API call because it could be a lot of data and it’d be really hard. While we can call the Python script from a workflow in ITENTIAL, what we don’t wanna do is pass it a huge amount of data that might be prohibited. So we’re gonna actually have a Python script that will actually read the LCM instance data. So you can see here, I’ve got a little bit of a Python class written to…

Dan Sullivan • 21:55

get the appropriate OAuth 2.0 session going, and then it’s just going to make a few API calls into iTential to download the instances, and then lastly run some network checks using some publicly available Python modules to do it. And, you know, you can see down here where we’ll go and do that, we’ll go and do that check to check the prefix, but you’ll also notice if you’re familiar with Python at all, the script itself is going to omit a little bit of JSON data. That’s primarily because the output of the script, typically you write scripts, the output of them can be for a human to read. In this case, we wanted to make it more machine readable. So, outputting a JSON string makes it a little bit easier for us to parse back an intentional. If I take a look back in Automation Studio, you’ll see here that we have this verify workflow set up here, and I’ll kind of show you what that looks like. So that verify workflow basically will take a few parameters from a form, and then it’s going to call that same script that we just looked at.

Dan Sullivan • 23:06

It’s going to take the output of that script, convert it into JSON data, and then we’re going to go off and figure out if it’s blocked, we’ll get information about the blocking instance. If not, we’ll just send an email saying that it’s unblocked. So now we’re going to actually have a service that can, you know, sort of a self service as well. So if someone’s having reachability problems, they can query to see if their prefix is blocked. And it will give us… an indication of whether it’s blocked across all of the infrastructure. Something like this, we can certainly just run from Operations Manager to see the Verify Workflow here, and the Operations Manager entry, and I can just run it here.

Dan Sullivan • 23:54

I can put in a prefix and see what happens here. We’ll try this one first. That looks pretty good. We’re going to go off and run that script, and it looks like it ran pretty quickly. If you just hear that ding, looks like it sent me that e-mail. That was my name in the e-mail, so let’s see here. Okay, so now we can see that we got that blocking verification email, so, and in this case, this particular prefix is overlapped or blocked by this particular entry in our environment.

Dan Sullivan • 25:03

So that’s pretty good. So we can do the, and you can do the same to unblock or, or, you know, for even if it’s if it’s not blocked, you’ll get a different response back. So now what we’ve done here, we’ve actually been able to build a model using LCM. We can track the active instances we have. We can leverage that data easily now and make use of the fact that we have a stateful representation of what’s actually going on in our network. And we saved enough context so that we can orchestrate the blocking and, more importantly, the unblocking when we no longer need it. And the other interesting thing that you get from Lifecycle Manager is you get a historical representation of what’s happening. So although I’m only showing active instances, you can also have the deleted ones shown. So anything that’s been deleted, you’ll also be able to see the records. So if you click on the one here, you’ll notice here for the deleted ones, the context is zeroed out. So you know that there’s no active resources being held by a deleted entry, which is what you would expect. So you have a pretty good history on everything that ran and when it ran, and now you have the ability to tie distinct actions you took and provide an auditable way to track that. More importantly, you have an orchestrated way to touch the different resources within your network.

Dan Sullivan • 26:43

While you may have a better way to do blocking or you may be using Azure instead of AWS, you can certainly see we’re just sort of adding workflows and kind of building this out. It’s a pretty simple thing to do. It took a couple of days to build it. So it’s not like it took all that long to get something like this up and running. And that’s what we, what I have today. So certainly if you have, you know, any questions, reach out to us at itensual and thanks for tuning in and listening.