My name is Darren Forwell. I'm the IP Fabric, product evangelist. I'm a 25 year veteran of the networking industry. And, wow, it pains me to say that every time I hear it. I've worked in many roles from engineer to consultant to architect in all sorts of organizations, including for my since, since working in managed service providers and, in network security for a bank.

I joined the IP Fabric team early in 2020, when I saw just what the product could really do to revolutionize the way that we operate networks, both as an interactive tool and as the foundation, of an operational ecosystem. And hopefully I can show something of that today. So when I was researching network security for a customer engagement, I came across these extraordinary statistics that 80% of security vulnerabilities are network related, And up to 2 thirds of those holes could be closed through making sure that we have the right configuration in the network. Now these two stats really made me sit up and think, what is it that we can do that's different to help secure our customer data and protect our employees and our shareholders from, IT intruders? It struck me that as network engineers, we hold the key to this, and we need an holistic approach across all our network domains to be sure that we can make the difference.

First up, we have to protect our network infrastructure itself by ensuring that our hardware is supportable and upgradable and by making sure that our software is updated to close security loopholes as they arise. We need to be able to harden the configuration of the devices in our infrastructure to ensure that we only allow management access to those who have permission. And we need to apply protection to the device control planes to make sure that bad actors can't gain access or cause denial of service attacks in our infrastructure. Secondly, we have to think about access to the network itself. We need to be sure that only the endpoints that are permitted are able to gain access to the network services that are delivered across our infrastructure, perhaps relegating unwanted devices to no or or limited service.

There are a number of methods at our disposal here. We might use, 802.1x to authenticate and authorize endpoints or, limit the number of devices visible through switch ports to ensure that no one's plugging in illegal devices into our network. 3rd, we have the traditional network segmentation security of access control lists and firewalls put in place to limit access to areas of the network where individual servers or groups of services might reside. This protection can be enforced at multiple places through the network traditionally, but what would have been considered the perimeter, but more often these days between services within an organization, especially when we've got requirements that come from regulatory compliance, such as PCI DSS or GDPR. Now, no single measure will provide all of the security we'll need.

So an organizational security policy will likely be needed to address all of these areas in order to protect data, inventory, configuration, and state across all areas of the network, a key to ensuring that there are no gaps in delivery of that policy. And in order to deliver that, we need visibility of all of these areas across all network domains. We need to be able to demonstrate that we understand which measures are effective for specific services, and we need to ensure that information is up to date and accurate. And it needs to be available to be shared with whoever needs it without putting data into a silo only accessible to a through its discovery process from all network domains. Through its discovery process from all network domains, through CLI and API access to devices and controllers on prem and in the cloud.

It then analyzes the relationships between those devices and the network domains to build a comprehensive model of the whole network that can be queried through a web UI to provide a full documented view of the network. The UI also provides the ability to search and then visualize that implemented technology, but also to define compliance rules, which are given a rag type status to define if the network state meets expectation. The user interface is built on top of a comprehensive restful API, which is also exposed for use in integrating external systems. We have a community of partners and customers working on integrations with many of the leading operational platforms where IP Fabric data can enrich the network operations experience. The system works on a snapshot scheme, and so that same discovery, harvesting, analysis of data from the entire network is captured typically once or twice a day, providing a full picture of a point in time, which can be compared with others or trended over time.

Platform requirements are lightweight. A small single virtual machine is required in your network, ensuring that your network data stays under your direct control. And once that quick installation process is complete, the initial discovery can begin and show value in that captured data immediately. So let's have a quick look at the system itself. First up, you can see that inventory information is captured.

Full hardware and software details to allow you to verify that the infrastructure is supportable and not vulnerable. We have information in the platform extracted from vendor documentation about end of sale, maintenance support, where it's been announced, and so you can understand your hardware life cycle. And as we have software version information, we are able to help customers build vulnerability checking, for example. As I mentioned, all the data in the system is accessible via an API. And uniquely, we have a feature in our table view here, which allows us to show the API request details needed to assemble that data from the current view.

So, for example, one of the customers we've been working with extracts software version data from IP Fabric through the API in this way and compares it with data from the NIST cross vendor vulnerability databases and the Cisco Open Vulnerability API to see if we have devices affected in our network by the current open CVEs. Now, as we drill down into the technology information that's gathered, we can see that IP Fabric collects, device management configuration. And within that, we can verify, for example, that AAA or NTP or login configuration is configured the way we'd expect to be. Let's have a look at AAA. You can see the full details that we've got here for the AAA servers that are configured for each device.

And at the top of the table here, we can define some, intent verification rules to carry out checks and summarize those results for us. So in this case, you can see we're looking for Tackaxe configured to refer to a particular server. And if I click through here, we can show that information that we're looking for this 10.0.10.10 address. Now as you can see, what what was what we do here is when we see TACACs, as this, the protocol and we see that server, we color the, the server IP green. If we see that it's not configured for attack axe, but the correct server, we color it blue.

If we see that it is configured for attack axe, but the wrong color, the wrong server IP, we call it yellow and everything else is colored red because it's incorrect. And what we can do, we can click through on each of those to filter that table, which then allows us to extract that information and pass that over to people to go fix it. Now we've already seen the API, question mark here, but we also have the ability to export that to a CSV file, which you can show there. So we could pass that over to the, to the engineer responsible for raising changes, or, we can give them a URL which shows them basically the page that we see in front of us here. As well as summarizing that information at the top of the table here, it also shows up in the system dashboard.

And you'll see that over to the right hand side here, we have the TACACS configuration. In this way, we can display it, as a graph, as a chart so that people are very quickly able to see what state we're in. And obviously, looks good for TACX config in a demo network here. 95% of things are configured, correctly using both the right protocol and the right, the right IP address. All good.

We're very happy with that. Now, another way that we can view that, and this is quite a neat way, is we can open the diagram for that particular site. We're looking at our hardware lab here. So if I go through here and click this into the hardware lab, show the diagram, just clean that up a little. What we can do is we can actually overlay that that intent rule onto the configuration of the devices that are shown in here.

By clicking through here and selecting the TACACS config, we can see, that we have, some some items are gray, shown as gray, others are colored. The gray items are where there's no configuration, because again, it's a hardware test lab, but we can see the ones that are configured. We can see these ones are shown red, and the reason they're shown red is because the TACACs check has failed. And the reason for that is that we're using the wrong protocol and the wrong IP address. For an Amber device, we can see that we're using TACACS but we have the wrong IP.

And for the green device down here, we can see that we have the right protocol and the right IP address. So really neat way there of of actually showing us where we potentially have problems and where we don't. Now in all of these ways, what we can do here is we use the intent verification to confirm, that our management security policies and standards are met. We can use that for all of the, all of the different protocols we've got available to us. Now going back to our technology tables here, we can see the wide range of operating technologies that IP Fabric analyzes.

For network access, we might be interested, in looking to see how secure the ports in the network are. And so if we head down to the tables here that show information about the interfaces in the network, we can see here that we've got an analysis of the intent, of the intent verification rule to show where dotonex is enabled on interfaces and what state they're in. Again, I'll click through the rule just to show the detail, but you can see the information that's actually retrieved. We can see, where the secure watch security method is applied. We can see what state that's in.

We can see whether it's an edge port or not in the network, VLANs and so on, and how many devices are actually sitting behind that port. So for one thing, we might have ports here that are considered, edge devices that have a lot of Mac addresses, we might want to go investigate those. But in this case where we're looking at dotonex, what we can do is we can, see here that, by default, when when interfaces don't have a security method defined, they'll show us red if it's configured for, dot one x, but it's in a monitoring mode that will show in blue, and if it's configured for dot one x, but it's so again, we'll go back to that, and you can see from from this that nothing is currently enforcing, but we have 16 devices and I'll click through those and it'll filter on them. 16 interfaces that is showing as, as dot one x is enabled and that, they're currently in monitoring mode. And again, we can head to the dashboard and look at the status from a dashboard perspective.

And in that case, that's this chart on the top left. We can see where to attack X config looks good, add that one X rollout does not look good. We've got a lot of interfaces that are yet to be configured and we've got, the blue ones here, which we know are in, monitoring mode. We need to, to to dig deeper into those and and speed this rollout. Now the beauty of this is when the snap next snapshot runs, which typically they'll run once or twice a day, this data is refreshed.

So you're able to track over time the progress of your your, dot one x rollout project, for example. Give the project managers access to read only access to the platform. They're able to to get this information for themselves and don't need to come asking the the network team for that information. Very handy, particularly as we don't charge a seat license for IP fabric. So you've effectively got access for as many people who are interested to this data.

Now we've also worked with 1 customer who's who queries the the information that comes out of these intent verification rules and puts them into a monitoring system. So you're able to trend that data over time and show the graph of the uptake, for example, of that rollout activity. Very neat. Now, you'll also see from the technology table that we extract information about access lists, about the interfaces where those access lists are applied and about zone based firewall policy. So from snapshot to snapshot, it's possible to track changes to segmentation rules over time, and you can see where rules are created that aren't being used on interfaces, for example.

You can also check to see whether ACLs are being matched or not, and so it can be rationalized. Let's have a look at that. So in the access list, here, you can see again, we've created an intent verification rule at the top here. If I click through that, I can show you what that's what that's doing. And basically, what that's saying is our default situation is red, but anything that's that has a number of matches that's greater than 0 will be colored green.

So what that will tell us a green entry will be an access list entry that's being matched and and is actually catching traffic, and a red entry is one that's not. And so in theory, there's no traffic passing through it. It may be that it's not actually required. And you can see from the list here, there's a lot of those if we click through and filter these 421 access list entries that are being hit, but 3,700 entries aren't. And so obviously, there's some investigation work to do there in terms of actually tracking down to see are they needed or are they not.

So that's great for access lists, but we're interested obviously in firewall support as well. Now we support a range of different firewall platforms, from Juniper and Cisco through checkpoint, Palo Alto, FortiGate, and so on. We can check on this table to see, for example, if we've got a particular firewall, that we want to know what the, whether it will let certain traffic through, we can check and see which policies are available. For example, we'll take this this firewall which sits in our, l 66, which is a data center site. If I click through this, I can just show you that very quickly.

There's our data center site. It's just some routers on the, on the left hand side with, some switching and and this firewall here, and everything sits behind the firewalls. If I turn off the, layer 2, for example, we can see, that our rooted paths lead through to that firewall before they they deliver traffic elsewhere. Okay. Now, just going back to the table in question.

I'm just zoom back on that firewall. So what we can do, we can check to see for example, if we've got a particular host device that's trying to access a server, This is our client address. And then we have a server that sits in that, site 66. We can take a look at the, the rules that actually impact that traffic flow and and going to its destination. And in this case, you can see here, we've got, a deny for SSH traffic, but we've got a permit for for web traffic and a deny of anything else.

So the only thing that's allowing is basically is is HTTP traffic from that client to that server. Now that's brilliant because that shows us that that we have a rule that allows, that traffic to pass through that file. But how do we know for sure that traffic, will actually follow that path? Okay. Well, we've got all the information about the forwarding because as we've already seen, we've got all the information about the policies.

And what we can do is put all that data, together in, an end to end path check. And this end to end path check takes the source address of the client PC, to the to the destination address. We'll put in HTTP, and we'll submit that, and that will show us the route that traffic takes to get from that client in site 38 over the MPLS network. If you're interested, you can see all the gory detail right down to MPLS tags between devices. If you're not interested in MPLS, you can just spirit that away and turn it into a cloud as most people would.

And then we can enter into Site 66, our data center location. You can see both the, IP, routing forwarding path, and you can see the layer 2 path here. We're just gonna, hide the layer 2 for a minute just to make it clearer. So you can see the e through either path into the into the environment, we're gonna push traffic through the, through Juniper firewall in this case. And if I click through on the Juniper firewall, I can show you that we our forwarding rules are saying green, which means that we've got a path through the network and towards the client.

And actually in this case, it's slightly more interesting because what we what we're doing here is we're passing into firewall 9, we're leaving to go out to firewall 10 and then we come back in from firewall 10 into firewall 9 on a different interface, and then through to to our room and clients. So we've got a 2 layers of firewall protection there effectively. And from, from the other tab here is the zone matching rules and this shows basically, the interface of, the zone based firewall rules and how they match the traffic that's passing through. And in our case, as we saw before, we have this host 126, zone rule that's a permitting HTTP traffic through. Now what happens if the people running the application decided to bring it up to date and run HTTPS, for example, or you can run that path check again, you can hit submit button and now you can see that firewall turns red.

Again, we'll highlight 2. If we click on our firewall, you can see the forwarding rules still match okay, but in the zone matching rules, we're now hitting our deny any rule at the bottom here. And that's because, of course, we're using port 443. And so what we need to do is, in our zone rules for, for zone 1, host 126, we need to update this rule to include HTTPS as well. So, you can see there's plenty of scope there.

Now one of the things we can do with that is we can create a path check from that saying whether that path should pass or whether it should fail. And that check will be carried out along with all the, the the intent verification rules at every snapshot. And so we're able then to to to verify that when things change because that status would change from pass to fail under under conditions where that that rule was executed, enabling us to do, a kind of post verification check should, when a when a change has been completed. Now, obviously, there are plenty more security use cases, but hopefully these examples give you a flavor of how IP Fabric baselines that network security. Let's summarize.

So, IP Fabric captures network inventory, config, and state data from a large range of vendors across all network domains, then it centralizes, analyzes, and creates associations in that data. Once the data is collated and assembled, you can apply your knowledge and your organizational policy to build intent verification rules and dashboard widgets to ensure that your network complies with your intent for it. This includes making sure that configuration is as you expect it to be, that there are no holes. Then IP Fabric will continually assess your security posture by running those intent verification rules every time a snapshot is taken of the network. The dashboards, the tables, and the diagram show a point in time view that can be compared over time.

Now in our next webinar, we'll look at the day to day security operations and how those processes are enriched by IP Fabric. Hope that covers most things. I'm just going to have a look in the Q and A tab to see if there's anything come through. I can see, we've got one question. How often are the intent verification checks performed?

Hopefully that's clear now, in that we can, you can see that every time that snapshot is taken, so we run those intent verification rules. That can be as often as is appropriate in your environment. You can run that once a day, twice a day, 3 times, 4 times. However, many times you feel, you need to, based on on the system. What the system's doing is grabbing a full picture of your entire network over that period of time.

So you're able to, to it may take, quarter of an hour to do that. It may take half an hour, an hour. So you can run that as many times as you need to over the, over the period of the day to get that information. I don't know. Has has, anyone else got any questions?

You can unmute yourself and, and ask if you if you want them to. We have one come in there. Is it possible to compare configuration changes to a chosen snapshot? Yeah, that's a really good question actually. Let me just, go back to the system and I can show you, hopefully, show you that.

So, yes, we do, actually retrieve configuration, as part of the, not as part of the snapshots, but alongside the snapshots. So we can do, configuration changes either, on on specific devices. So let me just, for example, if we pick, firewall we were looking at before. And now I've got, a series of, of information. You can see there's actually no changes there on those.

So that was a bad example, but, you can yeah. You can let's see if I can find something, where there is a a change. So, yeah, let's let's choose this one. Alpha t r 5. And you can see we do it the the system will do a side by side diff, where you can scroll through and there you go.

For example, you can see here where an access list has been added to, to the interface here in a very similar way to you'll have seen tooling, do this before. And there's a couple more changes there. Yeah. There we go. The actual add additions to that, that access list.

So, yes. Yeah. Great question. Yes. We're able to show you that and do that.

Any others while I'm here? Okay. As, as I say, if you do think of any questions afterwards, please just get in touch. We can, answer those for you. And, of course, as I say, the recording will be available in the coming days, then you'll receive an email with that link.

Look out for our next webinar. That's gonna be on security operations. So taking what we've, what we're seeing today and seeing how we can enrich your operational process. And that's currently scheduled for the 1st week in December. Thank you very much for your time this morning.