Okay. Thanks for joining us. I hope the reason you're here is that you're trusted by your organization or your customer to deliver and enforce a security policy that keeps your customers and employees' data secure from prying eyes and bad actors. You've probably got all the best tooling, monitoring solutions, log collection, firewall policy management. Somehow it's just not enough.

There are cracks between your systems, and the only way that you can paper over them is to use manual process to ensure that information is consistent between them. That something is highlighted in one tool can be addressed using another, and that checks can be done to ensure corrective action actually fixes the problem that it sets out to solve. If only you could hire more people to be doing those manual checks, then they wouldn't get relegated to the bottom of the priority list, and you could start to guarantee that your business or customer that their security concerns were being met. Does this sound familiar to you? It certainly does to me.

My name is Darren Forwell. I'm IP Fabric's product evangelist, and I'm a network engineer, consultant, and architect of more than 25 years standing. Network security for my employers and customers has been my problem for much of that time. And I intend today to show you how IP Fabric can help you with some of those operational headaches that you're probably dealing with day in and day out. In our last webinar, we talked about how you can use IP fabric to baseline the security measures in your network.

We considered 3 specific areas, the network infrastructure itself, the access to it, and the, the inventory and and vulnerabilities in there. The network access, so that's how people connect to the network and how they're verified that they're allowed to be connected to the network. And then the segmentation through firewall rules and, access lists. But for all of these, elements, your I you can use IP fabric to show just how secure your network is at day 1. But once you've completed that baselining process and have the information in the system, how is IP Fabric used to continue to assure your network security posture?

Over the next 15 minutes or so, I'm gonna walk through a few use cases with you. If you've got any questions in that time, drop them in the q and a or chat panel, and we'll stop after the demos for a few minutes and go through those, And then we can round up after that. The whole session is being recorded. You will be sent a link by email afterwards, so don't worry about missing anything. Now as the network changes, you're bringing tooling to provide more control over your security posture.

It becomes necessary to ensure that those tools have a consistent view of what constitutes the network and that it will behave the way you expect it to. If you maintain hardware life cycle information in one system, monitoring in another, and log collection in still another, So you're likely to end up in a situation where yawning gaps open up in your coverage of your operational platforms. And if this were to happen, consider that you could well be leaving yourself exposed. Imagine your project team introduce a new site to your network, that the devices therein were added to your CMDB by your procurement team, and that the implementing team created all of the documentation but didn't necessarily have time to update all the operational systems. Of course, they fully intend to once they're less busy, but at least they've updated the static documents and how they hold the right information.

Now as tends to happen from time to time, the vendor of some of the network equipment on that site suddenly announce a critical vulnerability, but it's okay. It can be fixed by a code upgrade. The problem with that is, as your system life cycle platform's out of date, you don't know that you need to take that remediation action. And because you haven't received the vulnerability notification, you also don't know that an update to your firewall rules will at least mitigate that issue until the software is upgraded. So you get unlucky and your site is attacked.

Unfortunately, you don't get notified of the effects of that attack immediately because your logging and monitoring systems How do you put the proactivity back into that situation? By making sure all the devices in your network are in the inventory tables in all of your operational systems. Your life cycle system would catch the vulnerabilities and notify you that the proactive upgrades were necessary and give you the mitigation instructions while you waited for the right time to do those upgrades. And if something did get through, you can ensure that your logging and monitoring platforms gave you the information to immediately react to at least deal with the issue when it arises. Without the correct information, all of those systems become ineffective at best.

So how does IP Fabric help you with that? Well, what we're doing in IP Fabric is capturing a a doing a discovery and capturing the full inventory, config, and state, data in your network. We create a snapshot, a point in time database of everything in your network, and that includes all of the detail that you'd expect to find in an inventory. So everything from the platforms, the vendors, the models, the serial numbers, IP addresses, code versions, and so on and so forth. We track all of the interfaces on those devices, what they're connected to, the connectivity matrix between them all, and where possible, we pull information about the hosts that are attached to those interfaces as well.

All of that data, regardless of, a vendor, all pulled into the same tables as you can see in front of you here. Now each one of those tables, is stored in a similar format, and we're able to extract that information from the platform directly either by exporting that to a CSV file, which I can show you here briefly. There we go. Or we can actually pull all of that data directly from the platform through, the API. Now the entire web UI for the platform is built on top of this same API.

So you have direct access to the data in the same way that the web UI does. And by clicking on that question mark as you saw there, we're able to give you the, the, API documentation that refers to that table. So here you can see you've got the endpoint information and the request payload that's required in order to to extract that data. Along with, if I scroll this down, you can see all of the detail about what those columns refer to, how the filters might work, and so on and so forth. So full documentation in the platform.

Now this information, of course, isn't just about inventory. There's also a load of information about the operating technologies in here, and the inventory can also include firewall platforms, load balances, and so on. So we're able, for example, to take that information we've just seen and update the firewall policy managers, if you've got one of those, as well. So we're able to keep the entire ecosystem up to date with with the data. So you've made sure that all of your monitoring and control systems have the right inventory.

But at best, that's only half the story. We talked in our last webinar about the different types of security configuration and how we baseline those. At least part of that configuration is to allow the devices to be monitored and maintained by our centralized platforms. So how do you ensure that once they're remediated, the configuration stay compliant with your security policy, or that when a new site or device is implemented, that those secure configuration templates are used. Now a typical approach might be to back up the configurations and then manually diff those text versions of the configurations with templates containing the right stanzas.

At worst, this will take your operational team's time to make those checks, and so they'll only happen on a semi regular basis. At best, an enterprising team mem team member might write automation scripts to do it for you. But, of course, they'll have to create templates for each different vendor and platform, and you'll have to ensure that you put in place appropriate maintenance for those scripts and templates because how if that team member gets ill or decides to leave for a better offer, well, we'll leave it there. I'm sure you can see the attraction in having a system that will, in a timely fashion, track the compliance of your network device config to your security policy, whatever that may be. IP fabric's intent validation rules can do that for you.

At each snapshot, the rules are run against the newly collected device inventory, configuration, and the state data, and a summary report is generated. That's then available for anyone who logs into the system to view it, or you might configure IP fabric to send a webhook notification that the rules have been run to trigger a response in another system. For example, you might replace some of your morning checks on the service desk with rules that send a completion message to the network team's Slack channel with proactive advice on what to do first when they come on shift. Let's go back to the platform and have a look at some of those intent validation rules. So IP fabric, as we've already shown, harvest a large range of configuration and state data from all its network devices and places all that data into this vendor neutral model in a series of tables.

I've shown you the inventory, tables already, and I've touched on the fact that there's, other technology tables, and I'll give you a view of those. A switch, for example, might have layer 2 forwarding information that might include port channels or VLANs and information about spanning tree and neighbors and so on. A router may have information about layer 3 forwarding. So in that case, the routes that it has available to it, information about its routing protocol adjacency, and so on. Firewalls will have, information specifically about all of those things and the access lists, the object groups, the interfaces that are configured, and indeed, the zone based firewall policies as well.

But all devices must have standardized management configurations. And so what we'll do now is we'll look at a simple case of checking to ensure that SNMP configuration is as we expect it to be. Now imagine that your security policy stipulates that every network device needs to be able to monitor using SNMP version 2 with a community name of, let's say, IP fabric, and that we should have an ACL or a specific prefix defined to allow only certain machines to monitor the network devices. So the first place to find out whether that's the case is the SNMP summary table that we see in front of us here. This shows us the devices that have some SNMP configuration or none at all.

Very simply, the number of communities that are defined here, gives us that indication. You can see that some have 1, some have none. So, for example, if I select 0, you can see here all of these devices have no communities, nothing configured to allow the, the monitoring platforms to to be able to, to monitor them. Therefore, there's a gap here, and we need to make sure that that's, that's corrected. Now as you can see above, we have this, this summary, the intent verification rule summary, and that is showing us actually that there are 320 devices, though.

Colored yellow in that community table that is showing, that need to be configured, That we have 290 with at least 1 configured SNMP, community or a v 3 user. And, with the, with the green there is is showing that it is just 1 just 1. So, whereas this is the blue one is showing more than 1. So it's got the right configuration potentially got the right configuration, but not necessarily complete to our specification. Now if we want to get into more detail with that, we can move through into the communities table because we're specifically interested in, in version 2.

If we were interested in version 3, we would go have a look at the users table. And then what we do in this communities table is we've created an intent verification rule here that will color the community's column based on a number of different criteria. So let's have a bit more of a detailed look at these. So what we're saying here is if we want, the the ideal scenario is that we want an SMPV 2 community that's defined to be IP fabric, this value here, and that we have an either an ACL or a prefix list associated with that. And so if if those those rules match, then we color this green.

We'll color it blue if, we have an ACL or prefix, but but it's for, an SNMP community that that's different, something other than IP fabric. Therefore, it needs modifying. And then we've got the other way around here where if we've got, the the, ACL or the prefix list is empty, but we have the correct SNP community, we'll we'll make that a yellow, and everything else will make red. So, typically, if it if everything is set to default, so public or private, then we'll, we'll flag that as red in this case. And, as you can see here, it, when that's run, that summarizes and gives us numbers of, of the, the totals in each category.

And if we, click through on these, it filters the records in the table here to to show us just what's going on. So for example, a yellow, as we said, IP fabric is configured as the community, but there's no ACL or prefix allocated to that, that community. So anyone can use the, the community to to query the device. Now these, intent verification rules, are run at every snapshot as we've already said. And so each time that they're run, we're able to to get the information that these summary numbers.

We do 2 things with those. 1, we can display them in our, dashboard. So we have a dashboard where we, display the results of all of the intent verification rules. We can display them either as charts. As you can see here, you can have stacked bar graphs or or as these tables with, with the the the colors, that we've already seen above the, above the tables in the, the technology menus.

And but we can group them based on, particular areas of interest. In this case, our management compliance group here, shows our SNMP config compliance and SNMPv2 community name, entries down the side here. That data can now be extracted from the platform using an API. And so we can actually use something like PRTG or a monitoring platform to monitor those values and trend them over time. So if, for example, we are wanting to make sure that we are going through a process of remediation of these this configuration, we can actually show the, progress over time each snapshot as the as the numbers change.

And so, you know, the, intent verification rule has that additional ability to to help us with project workload. Okay. So we've seen how IP Fabric can fill gaps between what your network tools can see and also what your network devices are configured to allow to happen across the network. What about when you need to validate that your network will actually forward traffic or enforce segmentation policy the way you intend? You may have, for example, a firewall policy management platform that centrally manages the rules that conform to your policy and then pushes those out to the firewalls where they're required.

Once that's done, can you validate that traffic Well, this is where path simulation in IP Well, this is where path simulation in IP Fabric helps. The visualization of network maps in IP Fabric is one of its strongest web UI features, and the ability of the platform to identify endpoints connected to the network means that we're able to form up a complete path between those endpoints, noting every forwarding decision and policy enforcement point along the way. So I'm gonna open up, an example of of a path definition. This is, an endpoint that lives in a LAN environment, and this is, a web server, sits in one of the data centers. And you can see here what it's showing us is is every single hop, and every single network device in the path between, our two endpoints here and here.

Very quickly just show you what those look like. So we have, both layer 2 and layer 3 shown on one diagram, and you're able to see the switch path from, from, for example, the device to its default gateway passes through these 55 switches. And as we step from switch top to switch top and from routed hop to routed hop along the path, we can see in detail every forwarding choice and the data that was used to make that forwarding decision. For example, the path overview tab that that shows here shows the forwarding decision. As we hover over it, it indicates on the on the map there which which path we're talking about.

And you can see here that it's a switching path on VLAN 118. It's got an input out interface and output interface. And if we're interested in more detail about the device and the platform, we can click through the tabs here, and it shows us the full information that's been retrieved from from the device configuration and state that's allowed us to make that forwarding decision. Here's our MAC address table, for example. As we pass through that that site and out into the into the wide area network, So we're able to do the same information here, about the routers.

And, again, this time, it's a routing decision that's made this time. So, again, we can see the interface details, and we can see the routing table here that it's used to make that decision. But we can also see that we're checking for ACL matches. So in our case, we have ACL applied on this outbound interface from the router here, called e filter. And because it's got a a permit for any network in the 10 address to any network in the 10 address, it allows traffic to pass, as we'd hope it would.

Now we move through, into our MPLS network. And if we're really interested, we can actually show, the detail of the, the MPLS labels that that are being used here. There you go. In order to get from one place to another. And so the, the forwarding decisions in, within the MPLS network are based on those MPLS labels.

Alternatively, we can just put it away and and move through into our data center environment. And, again, we have paths, initially rooted paths, and then rooted paths over switch paths at the end here. And you'll notice we're going through a firewall. And what I'll do there is just, overloaded the machine a second. So we'll just go back into that.

So, as we click through the firewall, we can see that we've got, both forwarding decisions and the the the matching zone matching rules for the, for the traffic so that we're showing that, yes, we we've both got forwarding path, and we're able to show the firewall rules themselves that are allowing that traffic to pass without any problem. All good. Now if the application team were, for example, to decide that they wanted to secure that application further, and, use HTTPS, we can, run that simulation again, and you'll notice that we have a scenario where our, firewall now is blocking traffic. Our zone matching rule is now showing red. And as we scroll across here, we will see we're hitting the deny any rule, here, which is causing that that traffic to be blocked.

Now we can look in more detail at the, the firewall rules, and we can show we're going to zone, zone 126. We can show here we have this permit, www line that's only allowing port 80 through. Everything else fails through to the deny. So we need to raise a change, for a config change on that firewall to fix it. So what I'm gonna do, I'm just gonna show you how we can now use the the same, mechanism as a pre and, post check.

So if you just bear with me a second. What we're gonna do is we're gonna log in to that, that fire the firewall in question, and we're gonna make the change to fix those rules. Okay. So we need to edit the, security policies from, the WAN to host 126, as we saw. And we what we need to do is, add in the policy to match, HTTPS.

Okay? So we'll commit that, to the firewall. Now what we need to do in order to verify that that change has been successful, we're able to refresh the data in the snapshot in order to, in order to verify that that this change has been successful. So what's now happening is that IP fabric is going away. It's going it's looking at the, the device in question.

It's logging into it. It's retrieving its configuration. It's retrieving its inventory again and its state information, and it's going through the process of of discovery. What it will also do is as during that that stage, it will check to make sure that it fits in the network with other devices that are surrounding it, the neighbors, just making sure that that everything is aligned and and correct, and then it will, bring that data into the the vendor neutral, model, into the database tables, and it will reformat some of the, the the diagrams and the topologies around it. So as you can see, this process takes a little while, but it's because it's a it has to ramp up, carry out the activity, and ramp down again.

So here we go. It's now completed. So what I'll do is I'll just go back into the interim path and resubmit that. And now you can see from where HTTPS is now allowed. If I click through on here, our zone matching rules have gone green, and that's because we've now got HTTPS enabled and allowed there.

And so we can use that as, a post change verification that the, the change was completed successfully. The other thing that we can do here is create what we call a path check verification. And what we what we can do there is we can say, right, here's a path that we want to be verified each time a snapshot is completed. And in our case, we can either say we expect it to pass or fail. It's either way.

And then what we can do is each each time a snapshot is taken, the table here is updated with that information. And so we're able to, again, access that data from outside the platform, either through CSV or or through API call, and we can say, right. Okay. Yeah. That's failing or it's not failing, and we can track that information through.

Okay. Right. I'm gonna pause for a second and just check and and see, if anyone has any questions. Taking it one step back. How does IP fabric inventory differ from classic CMDBs, and are there any advantages?

Great question there, Martin. Thank you. As far as as, CMDB is concerned, typically, the CMDB is used by that broader audience. So it's it's something that's that's used for things like your ITSMs, for ticketing purposes, for contracts, for procurement, and so on and so forth. So what that what that means is that that information is available to everybody, but it doesn't have all the detail information in that's that's in IP fabric.

The different the different the key difference, I suppose, is that IP Fabric is going and discovering what's available at that point in time, that the snapshots run. It may be that what you actually want from the CMDB is not necessarily what's there at the point in time, but what you expect to be there. And so, really, the the best approach is to take the data that's in IP Fabric and use that to validate the information that's in, in your CMDB. Hope that helps with that one. There was another question came up as well.

Do we track ACLs and firewall rules and for which platforms? So, yeah, I mean, I've I've already briefly touched on that, but we can we can show that in a little bit more detail. What we'll do here is we take access control lists from, all platforms that that have them. So that's routers, firewalls, switches, load balancers even, and, and wireless LAN controllers if they're configured on there. And we can also show the interfaces that they're applied on.

And for, security platforms, so firewall, platforms like, Cisco, Firepower, Palo Alto, Checkpoint, Juniper, and so on and so forth, we pull all of the the zone based firewalling information as well, and both the policies and the interfaces as they're applied into into which zones. So all of that data is is available there. And so you can do things like, for example, with the access list, you can determine where there are no matches on your access list. You can go ahead and and do verification that that actually is. Is that valid?

Is it not? And if it isn't, then could we remediate, and pull that that data out to to aid the remediation? So, yeah, yeah, thank you for for taking the time to listen today. Hopefully, you'll take away a view that while there may be opportunities for inconsistencies between the tools which you use to support your network. The IP fabric can help fill the gaps through its discovery and its analysis.

In order for you to assure that your organization's service availability is there, you need to ensure that you have consistent visibility across your network, not just in any specific domain, but end to end. And IP Fabric can help bring that. If you're interested in a more detailed demo, a trial, or simply further discussion on just what IP Fabric can bring you, of course, we'd be more than happy to talk more. Please get in touch. Our contact details are shown here and will be in the email that we'll send through with the link to the recording.

So look out for that over coming days. I hope that what remains of your day is productive, and, please stay safe. Thank you for listening.