Dan Sullivan • 00:00

Hi, everyone. Welcome to the Itential Tracking Infrastructure Access for Audit Requirements webinar. My name is Dan Sullivan. I’m a Principal Solutions Architect here at Itential. I’ve been with Itential for about a little over four years, and I’ve been working in customer-facing roles and pre- and post-sales, focused on automation for about the past 12-plus years. My background is in software development, distributed systems, and networking. Here at Itential, I spend a fair amount of time working with financial institutions, banks, healthcare providers, other large enterprise and service provider Itential customers, and pre- and post-sales. Recently, I’ve had some pretty interesting conversations with multiple customers, and it largely has been around auditing. I think in the past, auditing was a more simple process than it is today. So today, it’s not enough to show who did what and when they did it. When you provision a firewall policy or an AWS security group,

Dan Sullivan • 01:24

But usually you periodically need now to answer the question of, hey, is that access or that firewall policy still needed? Should it still be in place? Have the business requirements for why we did that, why we provided access still in place, or has that changed and we now need to remove that? I think ITSM systems, well, they are great for processing change requests and implementing approvals. It winds up fairly unwieldily to try to go back and search through a ton of tickets and things like that to try to figure out what you did a year ago or whatever when you’re going through some sort of an audit. Ideally, you’d like to have some sort of state that you could track around what you’ve done, and when you did it, why you did it. You want that accessible to help drive the process.

Dan Sullivan • 02:22

All right. You know, I’ve spoken with a couple of different customers who do things like, you know, they have processes in place, for example, to go in and look at their firewall rules and see which rules have hits on them. And then after some amount of time, the firewall rules that have been not being hit for a period of time, they’ll actually remove, you know, of course, something like that actually only gets you part of the way there. The reality is that you also have to answer the question, should that rule be in place? I mean, if you are providing access to some external system, but some external system or external business or entity, maybe you shouldn’t have that rule in place. There might be traffic flowing over, people might still be consuming resources in your network, or your servers and things like that, or access to applications, but maybe they shouldn’t be. So now it becomes really interesting to try to figure out how to track state so that a particular, you know, service or access can easily be decommissioned after a specific time or because it’s no longer in the company’s interest to leave that in place. So today’s demo will focus on how the Attentional Platform and Attentional Lifecycle Manager can provide needed state integration capabilities that help modern enterprises solve these sorts of challenges in their networks today. We have a few slides to go through before we jump into it, but I’ll sort of, we’ll take a look here. You know, again, hey, everything, security is getting more complicated by the day. I’m sure many of you know that much and live that every day. So from a demo perspective, we are going to have some services to provision infrastructure access, right, and we’re going to track that via our lifecycle app. So we’ll be able to provide access with duration so that we can limit the amount of time a given, you know, given access is provided, and we’ll even have a way to validate that it’s still required, and we’ll do that through ServiceNow.

Dan Sullivan • 04:42

And we’ll be able to demonstrate how we can automatically delete that on expiry. So now we’re going to have a little bit of state, basically, that we’re going to keep about what we do, and we’ll have a record of that. And we’ll, of course, use our integrations. The Itential platform has integrations with ServiceNow, and specifically with AWS. I’ll point out that today we’re doing a demo with AWS, but really, I think the patent itself is what’s more interesting. So for today’s demo, we’ll focus on provisioning access to a few fictitious applications for external customers, whether it’s people or other systems, and we’ll cover the basics of what we’re doing, which is exposing an application or a system deployed in AWS VPC. And we’ll provide access simply by creating some ingress and egress rules and security groups.

Dan Sullivan • 05:47

Obviously, it’s much more complicated than that. Typically, maybe you’re using an AWS WAF, or maybe you’re provisioning changes in your on-prem firewalls. Maybe you’re using some other cloud-based product like, you know, out there. But I think the patent is what’s kind of interesting. I’m sure you’ve all seen plenty of demos provisioning firewall rules, so there’s no great secret there. So, but again, I think the patent and what we’re doing today will maybe be a little bit more interesting. So, with that, I’m just going to share my screen.

Dan Sullivan • 06:25

All right. Okay. So… This is the Itential Automation platform. Some of the key applications we’ll talk about today will be Lifecycle Manager and Operations Manager. That will be the primary part of what we’re going to demo today. Over here, you see in the middle of the screen, our projects, Itential Projects, and that’s where I’ve done some of the work pulling this together.

Dan Sullivan • 06:53

I have a project that I created called Access Service Validation. I just click into this project here. See, it’ll bring it right up on the screen. You’ll see that we have a number of folders over here, so just a way that we can organize the work that we do, all the workflows, transformations, GingerJew templates, all those things can be organized in one workspace. I actually have that configured so that as I make changes, I can store them in GitLab or GitHub. In my case, I have a GitLab repo that I’m storing everything in. It’s a pretty easy way to build use cases out and then store them.

Dan Sullivan • 07:40

You’ll see that there’s a number of folders here, and so we’ll take a look at a few of them. And the first thing I’m going to do is click on the services folder here. And what I have here is a number of different services that I’m going to be able to provision. So there’ll be access to an Oracle database, access to a Jira application, and access to some fictitious web app that I have. And in this case here, what I can do is I look at this Oracle project here. You’ll see on the left is some of the input to the project. And you’ll see on the right hand side, I’m basically generating.

Dan Sullivan • 08:25

I’m using a Genji 2 template to generate some configuration. And at the top level, I can use this top level service to actually tell me what are the underlying services that are going to be involved in the provisioning operation for this Oracle service, for example. And in my case, I’m just going to provision something in AWS, I’m going to provision AWS security group. And you’ll see here, if you’re familiar at all with JSON or agenda two, you’ll see that basically the output here is I’ve created an array. And this is kind of useful because you’ll see down below the AWS SG array that’s populated, there’s two other arrays that aren’t populated. The reason I did this is because, and I’ll show you this in the workflow, but you can use workflows and they can process an array. If you have multiple different offerings here, like maybe you need to configure something in Palo Alto or LDAP, if you don’t populate the array, then the workflow knows not to do anything.

Dan Sullivan • 09:31

It’s a good way to avoid some complex business logic sometimes, so I can just generate these templates. Now, each of these top layer templates generates the underlying configuration for any other sort of composite services that make up, so the Oracle service as a component for the AWS security groups. And you’ll see as part of the output, I’m actually going to generate this template preference. And this means that I’ll tell the underlying AWS portion of the service what template to look at. So essentially, for the Oracle case, the underlying system will know to read this Oracle AWS issue. So I can dynamically pass in different service templates depending on the service type that I’m doing. So if I configure access to my Oracle database, I’ll read this file and I’ll pass this information down to the next layer so that it knows what specific AWS config file it should look at.

Dan Sullivan • 10:38

So in this case, it’s reading this AWS security group file. So if I click on that, what we’re doing in this case here is really just we’re going to put all the parameters together. For Oracle, we’re going to create multiple… input rules and no output rules. So the output rules, array is blank, and input rule array has two entries. And that, again, will trigger the underlying workflow. We’ll know, hey, I have two rules to provision, or I don’t have any in the case of the outbound rules.

Dan Sullivan • 11:09

So it’s using this sort of data-driven way to organize those services here. Next, we have the AWS security groups, and this is where we’re basically just going to provision or delete security rules that we add. When we provision the service, we’ll add them, and when we delete them, we’ll just remove them. If you look at the security group, add workflow, all it’s really doing here is calling two workflows. One to create a security group ingress rule and one to create an egress rule. And based on those arrays that we just created and the last workflow, it knows, well, I’m going to call, I have two rules to configure here, or in this case, I have one. So if we go back to that add rules workflow, you’ll even see here, if you double click on this, you’ll see that it’s looping.

Dan Sullivan • 12:03

So it takes that array as input and decides how many times it needs to run. Could be one, or it could be zero, or it could be however many rules we needed to. So if you’re doing something more complicated, you probably have multiple security rules. Maybe you’re provisioning both your on-prem, maybe you have a service in which you’re configuring VPNs, but you basically can start sort of building out the services, at least what I did, is building them out and defining them in Jinja. Ideally, I might even want to, for, just for ease of use, I define them with an iTentual, but you could easily define these externally if you wanted, and pull these dynamically from Git. Now I have these functions here to add security rules and delete security rules.

Dan Sullivan • 12:54

None of this is all that complicated, and we’re going to use our built-in adapter. We’ll go straight to, we have Itential adapter built off of AWS. in API specifications. So they’re basically AWS and a lot of other vendors basically now provide open API specs that you can use. And so we can ingest those dynamically and render out connectivity. And now we just pull these different features onto the canvas. So if I were to look one more at ingress rule here, I’m just making this simple API call.

Dan Sullivan • 13:36

I’ve passed in the data to drive this and I might access this multiple times or one time. And same thing for deleting it. You know, I’m just gonna revoke the, it’s called revoke security groups. So not a big deal. And we do the same thing for egress, pretty simple stuff. But you can imagine sort of taking this and using this as a building block and building out much more complicated services. Now, of course, all these workflows that we’re talking about adding security groups, they’re sort of fire and forget.

Dan Sullivan • 14:12

So they don’t remember any state. They don’t know what they did and when they did it, other than leaving some auditing breadcrumbs around. There’s no real state. There’s no way for something to go and dynamically pull and say, oh, you did this or you did that. You would have to go sifting through some logs and things like that to actually figure out exactly what had happened and what hadn’t happened. Not terribly convenient way to organize your data, just depending on audit trails and things like that. So that’s where sort of the lifecycle manager application comes in.

Dan Sullivan • 14:52

So the lifecycle manager actually allows us to define a model and maintain some state. So I have a collection of workflows that actually are going to interface with the lifecycle manager. So on the create. the lifecycle magic create workflows, what it sounds like. All it does is do the create. It basically reads the service configuration files that we showed over here, the top-level ones, and then figures out which assets need to be invoked to deploy the service. Pretty cut and dry here. The other thing that it’s going to do over here, this particular job is going to go off and schedule some delete and renew events.

Dan Sullivan • 15:43

When we actually configure some of these instances, we’re actually going to be able to give it a duration. We’re going to know how long we want to actually keep this in place. We’re going to have some state with that, and we’ll auto-schedule a delete, so that after that period of time goes by, it’ll actually automatically delete if no other action has been taken. We’ll also provision what we call a start renewal. So about 10, I think it’s 10 days before the service expires, we’ll actually configure another trigger so that 10 days before we’re actually due to remove this, we’ll start a renewal verification process. And what we’ll do is we will create an incident and service now, send some email to the person who requested the service and then give them the opportunity either to renew the service and extend it, or potentially just delete it or do nothing and let it be deleted. And so now we’re gonna take some of the outcomes of what we’re doing here and save the state within Lifecycle Manager.

Dan Sullivan • 17:01

So now we’ll have an active record of what we’re doing. And I won’t go into detail on all these particular workflows but it’ll become a little more obvious in just a minute when I show you Lifecycle Manager. And then Operations Manager is where we will sort of interface with some of these applications. So if we want to create a new entry, we’ll do it from Operations Manager. If we want to delete one, we can do it there as well. And we’ll also use that to schedule our automatic deletions and things like that. You’ll notice even there’s a ServiceNow director here and those are where we have workflows to create ServiceNow incidents, update them, and then possibly resolve them.

Dan Sullivan • 17:51

So nothing too crazy there, but just a few workflows to do those sorts of things. So just update an incident and let’s see here. and build a payload and create an incident. So we have all those sorts of features here. And now if I sort of quickly jump into Lifecycle Manager here, and I’m gonna click on Access Service Provisioning, that’s the lifecycle model that I created. And you’ll see here, these are kind of the properties that define a model. So you can express a particular model in JSON schema, and then use that to define the state that you wanna keep.

Dan Sullivan • 18:39

So if I click on Instances, it’ll show me what I have created already. So for example, I’ve provided the Acme Corporation access to my Oracle database. So if I want to look at what I’ve done here, look at the properties, it’ll show you, okay, this is the endpoint that they’re using that I’ve created. This is my contact at Acme. And I’m the requester, so it’s my email. And then I can actually configure duration of how long I expect that I want this service. I think I did it in multiples of 30 days.

Dan Sullivan • 19:15

So once this is provisioned, now it’s kind of interesting to see, okay, how is this different than another workflow, any other sort of fire and forget system? So if I go to Operations Manager, which is sort of where we sort of interact with the lifecycle instances, you’ll see first here, if I click on the delete model here, where I, you’ll see here where I actually have the renewal already scheduled for to start so for one of the systems I can I can actually schedule a renewal so in a couple of the other ones I didn’t have the renewal schedule but let’s try this again so now if I create one here so I’ll just create one I’ll call this I’ll say it’s 90 days and I’ll hit the renew button so I’ll definitely schedule a renewal on this Maybe it’s just a single endpoint or whatever, it doesn’t really matter. Now, I’ll just run this quickly and see what happens. It looks like it completed. If I go back to the Lifecycle tab, I can see that I’ve actually created that.

Dan Sullivan • 20:59

That looks pretty reasonable. If I go back to Operations Manager and I go to the Delete, you’ll see now that there’s an instance already created. Now, this is, it had an old one hanging around, but let’s see here. I’ll delete this one. So this is the one that I just created, and then we should also have a renewal here. It’s got two renewals because I was running this over again, but I’ll delete this one, the older one. So the most recent one here is this one here at 451.

Dan Sullivan • 21:36

So now I have this validation configured. So this particular workflow, what it’s going to do, I’m just going to jump back in Automation Studio and give you a little bit of a preview just to show you how that’s going to work. So when we start the renewal, what will happen is we will basically just create a ServiceNow incident, and it will also send an email and notify the requester that, hey, you need to renew this. Now, if we look at Operations Manager here, you’ll notice that in this case, the renewal time is scheduled for 12-7-2024. So we’ve got a ways to go to wait for that, and certainly the webinar itself isn’t going to last that long. So we can, if we want, run this manually. So we could simply just do this.

Dan Sullivan • 22:42

So we’ll just create a manual trigger here. Okay, so now we’ll just run this manually. So we’ll sort of pretend that this particular instance is due to expire. So if I pick this one here and run it… So it started the renewal process, and it actually sent me an email. So if I go over here and look, you’ll see here that I just got this email. So if I double click on this, it’s basically telling me, hey, your service is about to expire in 10 days, and here’s what was configured, and also says a ServiceNow incident has been created.

Dan Sullivan • 23:45

And if you want to extend it, you have to change the, you indicate that by changing the state to In Progress. Now ideally, we could have done something more, it took a little bit longer and provide, put a specific field in an incident or something like that, but in this case, we’ll just, all we need to really do is to set the state to In Progress. So if I click on the link here, it should bring up my incident. and it’s going to want me to change my color. Now again, you’ll see here it’s put a message in the incident telling us again repeating that same process. Now, in this case here, we have the ServiceNow Store, there’s an Itential app, and so it’s the Itential Automation Services app, and that’s actually deployed in our ServiceNow instance. This app makes it really easy to build ServiceNow flows and actions, but by calling actions that are exposed by the iTension app here.

Dan Sullivan • 24:59

The Itential app is configured to dynamically discover any endpoints that exist in the product. It knows about my endpoint and so it can actually invoke it. Someone actually created a flow in ServiceNow, took about 10 minutes for the guy that did it, so it’s not terribly complicated, it’s not really any coding involved, it’s pretty straightforward. What you’ll notice here is that the short description of the incident is basically access service and then the name. When I change the state of this, it’s actually going to invoke the renew endpoint. If I were to look in Itential Operations Manager and you look in renew, There’s an endpoint here.

Dan Sullivan • 25:56

I think it’s, looks like it’s not here either. So let’s see. We can create one. Call it API, API. Well, let’s call it. So we’ll create the endpoint, we’ll just call it access renewal. I’ll just save this. This will define the endpoint that ServiceNow is actually going to call.

Dan Sullivan • 26:30

Now you can see that there’s an endpoint already existing here, so as long as ServiceNow hits this API endpoint, then we’ll invoke the renew operation here. So now, as I mentioned, the way to kick that off is the flow that we have will detect the change in status. So it goes from new to in progress. So if I hit Update, we should see this trigger. So I go back to Operations Manager quickly. I don’t know if I’ll be able to get there before this does. Let’s see.

Dan Sullivan • 27:05

you’ll see it already kind of ran really quickly here. But you can see here, this is the renew endpoint right here that’s running. It went through and took a few steps. We’ll look at the workflow. It ran right here. The proof of that is if I go back to that incident, you’ll see now the state of that is resolved. So once the user changed the state to in progress, that caused the ServiceNow flow to run, which call our API, and it gave us enough data to figure out which LCM instance is impacted, and it went off and should have triggered a renewal.

Dan Sullivan • 27:52

So if I went back to Operations Manager here, so let’s see. You’ll see that the delete here, you’ll see now what you can tell here is just by the timestamp that the delete’s been updated. It basically decided, okay, I’m going to reschedule that and it actually added a few days to it, I think. You’ll see the reschedule here. Then we should also see the renew endpoint again, the start renewal again. You’ll see there’s another endpoint created that was just created just a moment ago. Now, we’ve actually been able to go through that renewal process and we have a way to actually involve the requesting entity via ServiceNow.

Dan Sullivan • 28:41

If you have customers or people that are consuming services, if they’re able to log in and access ServiceNow, which is pretty common, they can actually help drive this. Like I said, we just did this by having a flow that changed based on the state changing from new to. to in progress and that’s good enough to do it here. But maybe if you did something more custom, you might want to add a field or something like that. Then later on, you’ll see that it basically said it extended it successfully and gave the resolution code and closed it out. Just a little bit of a demonstration about how, in summary, you can actually track state and what value that might provide for you. You can imagine if you just have a Python script to do some of these things like to go off and provision something, it’s going to be really hard to figure out how to get that requester back in a certain amount of time to revalidate any of this.

Dan Sullivan • 29:47

That’s what the value that attention lifecycle manager is providing is our ability now to track some state for those services. It makes it a little bit easier and cleaner for us to then revalidate that they’re needed. We don’t have to do things like, well, is anyone hitting that rule or anything like that? We’re just going to make some policy-based determinations based on duration. We’ll give someone a chance to renew it. If they don’t renew it, that deletion trigger that we have will eventually fire and remove it. If no one takes action for 10 days, then it will get removed and they’ll have to re-request it.

Dan Sullivan • 30:25

But what we won’t do is have a lot of lingering configuration that we’re not sure if we can remove or not. Just one way to attack the problem. That’s it. That’s all I had for today’s demo. Put the slides back up here, and thanks everyone for listening in, and I’ll see you next time.