Cisco's solution to NAC / Segmentation

[carl_townshend]

Hi All

I am currently looking at NAC and Segmentation on our Network, to give us insights on what we have, be it corporate and also OT/IOT devices, this would be in a manufacturing environment.

Can anyone tell me what elements we would need from Cisco to provide this?

As far as I Understand it would be Cisco ISE using trustsec and you would need trustsec switches at the edge to do the enforcement? would that also cover the segmentation?

Would Cisco ISE discover all of our OT devices such as plc's running profinet / Ethernet/IP, Modbus etc?

Many thanks

Carl

[Colby LeMaire · Accepted solution]

It really comes down to what your definition of segmentation is and how strict it needs to be.  You can accomplish a certain level of segmentation without TrustSec.  You can use VLANs and downloadable ACL's with 802.1x/MAB authentication.  That would require ISE and access switches that are compatible.  That would be your first step in this phased deployment.  And yes, ISE can discover any devices that connect to the network.  If they don't support 802.1x, then they can authenticate with MAB and ISE can profile them.  You may need to create custom profiles for some devices in your network.

Once you have the basic 802.1x/MAB authentication working and your team is comfortable with troubleshooting it, the next phase could be implementing TrustSec.  That would require compatible switches at the access layer and then at least some sort of enforcement device that supports it.  With TrustSec, the idea is that you tag the packets at the access layer and then do enforcement at the egress point.  That could be an ASA in the datacenter, Nexus switches in the datacenter, ACI, etc.  If you want the TrustSec tags to remain on the packets while they traverse your entire network, then you need hardware throughout that supports inline tagging.  Otherwise, you will have to design/deploy SXP.  TrustSec is a beast and not a simple thing to take on.  I would highly recommend using professional services for that, whether it be Cisco or a certified partner.

[Damien Miller]

I'm with Colby on this.  TrustSec requires significant design considerations and hardware support to be successful.  Even then, DACLs still have their place.  TrustSec is merely one component of a comprehensive segmentation strategy.  

The data center space is leveraging ACI and Tetration for segmentation, the LAN/WAN side DACLs, TrustSec, and possibly software defined access which is a combination of VXLAN, VRFs, DACLs, and TrustSec.  Traditional and TrustSec aware firewalls still play a role through it all. Translation and sharing is required to ensure policy can be written throughout the environment.

A slight hole in Cisco's TrustSec portfolio right now is a modern WAN transport capable of carrying TrustSec tags inline.  There are still plenty of legacy ipsec based overlays capable of carrying SGTs inline, but Viptela (Cisco SDWAN) is still lacking it.  SXP can be used in small environments to overcome this, carrying SGTs out of band to where they are needed, but it has its own design considerations too. When you start pushing the number of IP-SGT mappings higher in combination with higher SXP connection counts, you eventually hit a resource wall since it is a real time protocol. For this reason, carrying SGTs inline in a modified frame header is preferred.

[Greg Gibbs]

Hi Carl,

There are a lot of pieces to this puzzle, but much of this falls into the Converged Plantwide Ethernet architecture for which Cisco has published validated designs. ISE and TrustSec are key components of this architecture.

In short, ISE doesn't understand the typical OT protocols and endpoints so it would rely on integrating with OT solutions like Rockwell Automation's FactoryTalk or Cisco Industrial Network Director via pxGrid for identification/classification of those endpoints.

I would suggest looking at the following resources for more information:

Design Zone for Manufacturing - Converged Plantwide Ethernet 

Network Security within a Converged Plantwide Ethernet Architecture 

Cheers,

Greg