cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
6620
Views
40
Helpful
6
Replies

ISE Policy Set Best Practice

pacavell
Cisco Employee
Cisco Employee

Is there a doc or any guidance on best practices for ISE policy sets? For example, should customers not use the Default policy set and always create new ones? Is it best to have one policy set enabled at one time with all needed policies in it or should customers create multiple policy sets for individual cases and have them all enabled at the same time?

1 Accepted Solution

Accepted Solutions

Timothy Abbott
Cisco Employee
Cisco Employee

Policy sets are primarily used to help customers organize there security policy in ISE.  Many times you'll see policy sets used to organize policy into sections such as wired MAB, wired 802.1X, wireless 802.1X and so on.  Ultimately, it is up to the customer.

 

Regards,

-Tim

View solution in original post

6 Replies 6

Timothy Abbott
Cisco Employee
Cisco Employee

Policy sets are primarily used to help customers organize there security policy in ISE.  Many times you'll see policy sets used to organize policy into sections such as wired MAB, wired 802.1X, wireless 802.1X and so on.  Ultimately, it is up to the customer.

 

Regards,

-Tim

Thanks Tim.

Jason Kunst
Cisco Employee
Cisco Employee
There are some examples in the ISE perf and scale guide
http://cs.co/BRKSEC-3432

Thanks Jason

Arne Bier
VIP
VIP

This question raises its head once in a while and it's an excellent one.  The short answer is of course that "you can do anything you want or what the customer needs" - that's obvious but it doesn't help us towards making Policy Sets better - and that was the intent of the question.

 

You'll know a bad Policy Set when you're confronted with a situation of helping a customer and you look at the sprawling spaghetti of rules - it might take half an hour to figure out what is going on.  This is common for consultants like myself who touch many different customer networks.  We get to see how inconsistent things can get.  WHY?  Because nobody talks about it.  We all get taught the basics but then things get out of hand as soon as requirements grow.  And of course it will depend on each customer - because some might only ever have Wireless 802.1X and that's it.  Here are my tips. 

  • Read the BRKSEC-3432 that @Jason Kunst  mentioned (240MB is a whopper! You can also look at the older BRKSEC-3699)- the reason is, that there are performance gains to be had when creating rules.  it boils down to simple algorithmics and boolean shortcuts that will make the system respond faster and handle more load
  • Make The Rule Names in your Authorization Policy the same as the Result Profiles.  Why?  because when you have hundreds of them, it will be easier to spot them.  Which brings me to the next one ...
  • Don't make up Rule Names on the fly!  Seriously. We all do it.  And then we look at the mess and go, eh? What?  You may end up refactoring your Policy Sets at the end of a project just so that it all looks neat and tidy.  It will be worth it.  So what naming conventions to use?  I am glad you asked ...
  • Make the names fit your organisational terminology.  E.g. if your organisation refers to Biomedical Devices as BIOMED_A, BIOMED_B, etc then use that.  It's more meaningful than names like "Allow_VLAN1233" or "Permit_Users".  This is probably the hardest thing to know upfront.  But it's so worth it.  Stay consistent throughout the entire Policy Set.
  • Regarding the overall Policy Set structure, I tend to have my main conditions consisting of (for example)
    • Wired MAB
    • Wired 802.1X
    • Wireless MAB
    • Wireless 802.1X
    • PAP
  • And within those I treat the Authentication as required (e.g. EAP-TLS uses a Cert template X, and EAP-PEAP uses AD)
  • And the good stuff is in the Authorization Policy - here I put the most unique/complex rules at the top to allow them to be matched, followed by less specific ones further down.  This is also the place to do things like check AD Groups and SSID's etc. I have seen people build this into the Policy Set Conditions but in my opinion that is wrong and doesn't scale.  
  • Golden Rule as far as I am concerned, is to think about Policy Sets like you would any algorithm.  Because algorithms can be expressed in many different ways, and all still be semantically correct, everyone will do it differently.  But think with efficiency in mind - don't keep checking for Service-Type = Callcheck (i.e. MAB) in every rule.  Check it once - at the START of the Policy Set.  Then take that assertion further into the rules.  It's pointless checking it over and over.
  • I never use the Defaults. Just duplicate and create new stuff - it forces you into the discipline
  • Allowed Protocols are a good gatekeeper - make sure you tailor this to each Policy Set - e.g. for EAP-TLS only enable EAP-TLS - create a new Allowed Protocols and call it "Allow_EAP-TLS" - for MAB un-tick everything and only tick "Process Host Lookup".  This mechanism is like strong type checking in a programming language - it keeps the bad stuff out and alerts you when devices try to do silly things.
  • Use Library Conditions where appropriate.  Unless you are going to re-use this set of conditions, don't create a Library Condition out of it - they look nice at first, but they obfuscate what the condition does - it means you need to go look behind the scenes - can be wasteful. But if you find that your rules read more naturally as a result of using Library Conditions then do it.  Sometimes abstraction can be confusing too and mislead the reader into what is actually happening.  I have used them in the past where I had a customer case that required many nested ORs and ANDs and the Library Condition ended up looking nicer to read in the Policy Set.
  • Use Smart Conditions - instead of checking the Radius attributes for each vendor scenario, Cisco has abstracted that for us.  And we can make our own too.  It is a bit more on the advanced side, but that's where ISE really shines.

I am sure I missed a few - but those are some of the things I have been striving to do in all of my engagements.  Perhaps there are other tips that some of you can share?

 

Things I have never used and always wondered about

  • All those things under Policy > Policy Elements > Conditions > Network Conditions
  • Local Exceptions
  • Global Exceptions

 

 

Thanks Arne
Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: