A network user - a senior manager in the business, in the process of writing a heavy report - knocks on the door of the security team's office. He has an urgent request, to access a server that sits behind a firewall. He speaks to the security engineer, who checks her security policy documentation. She determines that the user in question shouldn't have open access to the data on that server. There's payment card data amongst other personal information stored there. So she denies the access request.
But the user is determined - do they not know who he is?! There is one final important piece of data on that server that he needs to complete his report! The user decides to walk down the corridor to the network team's office. He knows a junior member of the network team who is very keen to keep his important users happy because he wants to progress in the organisation! The junior network engineer is only too happy to help. He comes up with a scheme that gets round the firewall. A quick change to route the VLAN where the server sits on a router instead will fix it! No more being blocked by the firewall rules!
So ... how does the security engineer stop this from happening, or if it does happen, detect it so she can get it fixed? She would need to be able to track every route in the network and see which ones change. Specifically, she would have to see which routes were being advertised by firewalls that are now originating at routers. That's quite a specific problem and one that would need a bespoke complex solution ...
Our security engineer can use the verification checking, and the deep intelligence in the IP Fabric platform to help her!
First things first, she can build a compliance check based on an end-to-end path simulation. She maps out the end-to-end path from client to the server that needs to be protected, then defines a path check.
As you can see, the firewall is shown in red because its rules block the application traffic, so the client cannot talk to the server. So when we create the path check, it should be expected to fail. And as you can see from the reporting below, it does fail exactly as intended ...
But the next day, something has changed. The path verification check is failing, showing that the client can talk to the server via at least one path:
And so our security engineer runs an end-to-end path check to get the detail and sees something strange. There are now two paths to the server and one shows up as blue, meaning it is a valid path. While that this doesn't necessarily mean that the client will be able to access the data on the server, it does show that if that path is chosen the connection will bypass firewall rules designed to protect the server.
Doing a quick comparison between this and the previous IP Fabric snapshots shows us exactly what has changed. The router L66JR6 now no longer sends traffic for the 10.66.127.0/24 subnet via the firewall but instead can route directly. And this has changed between the two snapshots.
It's now a simple case of tracking down the configuration changes that have been made and backing them out. This will to restore the compliance with security policy, all thanks to IP Fabric's verification checks!
[The senior manager and his network engineer sidekick will have to live with the consequences of breaking security policy, but it has certainly taught them not to mess with the security team!]
If you have found this article helpful, please follow our company’s LinkedIn or Blog, where more content will be emerging. If you would like to test our solution to see for yourself how IP Fabric can help you manage your network more effectively, please contact us through www.ipfabric.io.
A network user - a senior manager in the business, in the process of writing a heavy report - knocks on the door of the security team's office. He has an urgent request, to access a server that sits behind a firewall. He speaks to the security engineer, who checks her security policy documentation. She determines that the user in question shouldn't have open access to the data on that server. There's payment card data amongst other personal information stored there. So she denies the access request.
But the user is determined - do they not know who he is?! There is one final important piece of data on that server that he needs to complete his report! The user decides to walk down the corridor to the network team's office. He knows a junior member of the network team who is very keen to keep his important users happy because he wants to progress in the organisation! The junior network engineer is only too happy to help. He comes up with a scheme that gets round the firewall. A quick change to route the VLAN where the server sits on a router instead will fix it! No more being blocked by the firewall rules!
So ... how does the security engineer stop this from happening, or if it does happen, detect it so she can get it fixed? She would need to be able to track every route in the network and see which ones change. Specifically, she would have to see which routes were being advertised by firewalls that are now originating at routers. That's quite a specific problem and one that would need a bespoke complex solution ...
Our security engineer can use the verification checking, and the deep intelligence in the IP Fabric platform to help her!
First things first, she can build a compliance check based on an end-to-end path simulation. She maps out the end-to-end path from client to the server that needs to be protected, then defines a path check.
As you can see, the firewall is shown in red because its rules block the application traffic, so the client cannot talk to the server. So when we create the path check, it should be expected to fail. And as you can see from the reporting below, it does fail exactly as intended ...
But the next day, something has changed. The path verification check is failing, showing that the client can talk to the server via at least one path:
And so our security engineer runs an end-to-end path check to get the detail and sees something strange. There are now two paths to the server and one shows up as blue, meaning it is a valid path. While that this doesn't necessarily mean that the client will be able to access the data on the server, it does show that if that path is chosen the connection will bypass firewall rules designed to protect the server.
Doing a quick comparison between this and the previous IP Fabric snapshots shows us exactly what has changed. The router L66JR6 now no longer sends traffic for the 10.66.127.0/24 subnet via the firewall but instead can route directly. And this has changed between the two snapshots.
It's now a simple case of tracking down the configuration changes that have been made and backing them out. This will to restore the compliance with security policy, all thanks to IP Fabric's verification checks!
[The senior manager and his network engineer sidekick will have to live with the consequences of breaking security policy, but it has certainly taught them not to mess with the security team!]
If you have found this article helpful, please follow our company’s LinkedIn or Blog, where more content will be emerging. If you would like to test our solution to see for yourself how IP Fabric can help you manage your network more effectively, please contact us through www.ipfabric.io.
