You're on the right track, keep it simple and build a solid foundation, don't try to do it all at once but keep the end state in mind. Understand that you can change the design as you gain visibility prior to implementing enforcement policies, but it gets increasing harder once something is in place. So start off with a focus on getting monitor mode deployed, it's the first big win. Just having the visibility of what's plugged in to the network and where is a huge step forward for most companies.
Break it down in to some manageable tasks, follow a framework methodology such as Cisco's PPDIOO. Some highlights and things that have helped me over the years.
- Start with identifying the business and technical goals. This might include North/South + East/West segmentation, it's different for every environment. The more thourough you are here, the easier it is to build toward the end state.
- From the goals, you can begin to identify the platforms that you will deploy on. Some segmentation deployments don't require TrustSec support on all platforms, but if you're going to go after full East/West, then you need to look at the TrustSec support platforms, and ideally you will have only platforms in tier 1 (full inline tagging and SGACL support). If you're after North/South, then this could be ISE integrating with firewalls, or WAN edge devices for enforcement. https://www.cisco.com/c/en/us/solutions/enterprise-networks/trustsec/solution-overview-listing.html
- If required, consider the transport mechanism, smaller environments can accommodate using SXP to communicate SGTs across the WAN out of band. Larger environments often require a WAN transport capable of inline tagging the SGT and for that you're after something like dmvpn, iwan(probably avoid), or the preferred method today Cisco SDWAN (Viptela).
- Build, validate, and certify configurations for the platforms you want to support either in a lab or production pilots. A very important component of this is to standardize a platform on a specific version (often gold star). You do not want to be deploying TrustSec on mixed software versions across the same hardware platform, there are just too many bugs that can creep in on older code. Don't focus on what is "validated" and "supported" in the trustsec matrix guidelines or ISE deployment briefs, they are the bare minimum you need to support a solution, and not usually the preferred release since docs don't get updated.
- Consider the visibility you require between groups. It's had to build a segmentation strategy if you don't know what's talking to what. In this case, stealthwatch has been a long staple and recently released a TrustSec matrix capability that is very helpful. Third party profiling solutions such as Ordr, and the newer DNAC endpoint analytics and group based policy analytics solutions can help. https://www.cisco.com/c/en/us/products/collateral/security/stealthwatch/sna-trustsec-matrix-analytics-report-aag.html
- If you don't have a specific goal, start with some high level SGTs and refine the groupings through analysis of the visibility tools.
As far as what a good policy is? The least complicated one that meets the goals. It's hard for someone on the outside to tell you what your policy should look like, no environment is the same, but the fact that you're asking these questions now means you are already ahead of the curve.
