ISE Posture

[ashvaras]

Hi All!

Im looking for documentation that answers the following question...Ive looked through the admin 2.2 guide and tried to find other documents but they seem to be outdated and I am unsure if they are reliable-

-Does your product support an un-trust until verified device posture? How does it do that?

Example: Devices cannot access company resources/networks until they have been authenticated?

          My thoughts on this one are its depending on the posturing check, which will determine what authorization policy is applied (but again, I don't know where to find this in the documents)

-In an un-trust until verified device posture, what is the time frame for device authentication/identification? How long to mitigate?

-Does ISE support a Trust until verified device posture and if so how long does it take to identify and mitigate unknown/rogue devices?

I attached a document that is outdated (from 2012) that Im hoping people might have an updated one?

Any help would be awesome!

[paul]

My standard response to customers is this when we talk about what the preposture state looks like. 

"Can I block access until posture is known?" Yes you can do that but you will break so many things it really isn't practical in my opinion.  Remember the Posture Agent doesn't run until late in the login process so if you block access to corporate resources you are going to break all the prelogin stuff that requires this access, all the login script stuff that requires this access, etc.  You might be tempted to say well maybe I can craft a DACL to allow what is need prelogin and during the login process.  Having gone through this exercise before you end up with a DACL from security perspective is just short of "ip any any". 

My usual stance is that is the preposture state needs to be noticeable but not detrimental.  I usually block access to the Internet which is very noticeable to the end user but not detrimental to business functions (typically).  I also make sure to block access to port 80 on their default gateway to allow posture discovery to work. Remember these devices aren't just any devices they have provided correct authentication credentials to get on the network. 

If a device is postured as noncompliant then I slam the door shut, but the unknown state is tricky.

That is my approach.

[ashvaras]

This is a helpful approach and I will relay that info, but Im also trying to find documentation that supports the above bullet points- do you know where to look?  Ive dug through the admin guide...

[paul · Accepted solution]

I am not sure if you will find the answers in the guides.  It would be like looking at a box a tools and being asked "show me in the manuals that these can build a house."

ISE provides us with tools to implement various security measures.  How you configure those tools is driven by the customers requirements.

You should be explaining the 3 states of posture (unknown, compliant and noncompliant) and the methods to restrict access (ACLs/dACLs and redirect URLs/ACLs).  How you configure the methods of restrictions in each posture phase determines what type of access the device has in each phase.

If you want to implement an open monitor mode concept go ahead.  If you want to restrict access before posture go ahead.  The tools are all there.

For posture timing,  as I said previously, posture will not be reported until late in the login process.  If the device is already logged in, posturing should take 30 second to several minutes depending on what your posture checks are.

[hslai]

In addition to Paul's excellent points, you might find it helpful to look at the following materials:

• ISE Posture
• ISE 1.4: Compliance: Posture, BYOD & MDM

We have also a lab on posture compliance @ ISE Partner Training