Saturday, May 19, 2007

Custom Checks – Personal Firewall Software


Many organizations require personal firewall software to be run on clients connecting into their network as a part of their security policy. This post explores how to create custom checks to enforce the use of personal firewall software on connecting clients. This is one of the most requested custom checks I receive and hopefully you will find it benefit.

Create Checks and Rules:

For this example, I am going to show how to create custom checks for 3 different types of Personal Firewall Applications. All of this software is free and can be downloaded. To create a custom check you must go to:

Device Management – Clean Access – Clean Access Agent – Rules – New Check

Windows XP Firewall Check

The most reliable way I have found to check for XP firewall is to use a Registry Check looking for the following Registry Value:

Registry Key:

Registry Value:

If the XP Firewall is on the Value will be = to “1”

Figure 1 – XP Firewall Check

Make sure to select the proper OS type and also “Automatically create a rule based on this check” so that you can use the rule later.

*** Please note that the registry value looked at does not distinguish between interfaces that the firewall is turned on, e.g. users could turn on the firewall for Wireless and be connected to the LAN and pass the check. If anyone finds a more reliable way, please let me know.

Zone Alarm Firewall Check

The status of Zone Alarm can be found by looking at services running on your MS OS. Zone Alarm creates service “vsmon” that can be checked using a Service Check to ensure it is running.

Figure 2 – Zone Alarm Firewall Check

Make sure to select the proper OS type and also “Automatically create a rule based on this check” so that you can use the rule later.

Comodo Firewall Check

Unlike Zone Alarm, Comodo does not create a service that we can monitor, but it does have a process running when it is turned on. When Comodo is running it runs a process called “cpf.exe”, which we can create an Application Check to ensure it is runnning

Figure 3 – Comodo Firewall Check

Make sure to select the proper OS type and also “Automatically create a rule based on this check” so that you can use the rule later.

These 3 Custom Checks should give you an idea of how to check for different type of personal firewall applications. I know this is only a list of 3 of many different SW vendors, but if you can understand how to find the information about your preferred software then you should be good to go.

Create a Requirement:

For this example I have chosen to create a Local Check to inform users that they do not have Personal Firewall Software running. Other options might be to send them to a Help-Desk website, Vendor Website or to present them with a preferred personal firewall software download. To create a new requirement go to:

Device Management – Clean Access – Clean Access Agent – Requirements – New Requirement

Figure 4 – Personal Firewall Requirement

Make sure to select the proper OS as all if you want to enforce it on all Windows OS.

Map Requirements to Rules:

Next, we must assign the rules we created from the custom checks to the new requirement. To Map Requirements-Rules go to:

Device Management – Clean Access – Clean Access Agent – Requirements - Requirement-Rules

Figure 5 – Personal Firewall Requirement-Rules Windows All

Figure 6 – Personal Firewall Requirement-Rules Windows XP

The most important notes about configuring the Requirement-Rules Mapping is to select “Any Selected Rule Succeeds” and making sure you map the rules on a per OS basis, e.g. the XP check is not applicable to Windows All, but it is applicable to Windows XP All.

Map Roles to Requirements:

Pick the role(s) that you want to enforce this requirement onto and check the new requirement. To map Roles to Requirements go to:

Device Management – Clean Access – Clean Access Agent – Role-Requirements

Then you must select the role and select the new requirement.


Enforcement of the use of Personal Firewall Software is something that a lot of NACA deployment wants, and now you should be on the path of being able to do it.

Wednesday, May 16, 2007

Deployment Best Practices Series - Operations Acceptance of the Solution


Operations Acceptance of NACA is very important for a successful deployment. If Staff does not accept the solution than it will not be utilized to its capabilities or be maintained. This post is all about educating staff in order to ensure a successful deployment.

Introducing NACA to the Operations Staff:

NACA has to become an integral part of network and security operations in order to have a successful deployment. The following are some of the topics that Network Operations must be informed about:
  • Clean Access Servers (CASs) act as an extension to the routers and switches in the network
    • This causes network operations the need to understand how the CASs reside in the data path of users
  • In an Out-of-Band (OOB) Deployment, netops has to understand the integration between the Clean Access Manager (CAM) and all access switches
    • This requires the staff to have knowledge about SNMP Servers & SNMP Traps
Security Operations have many topics that they must know about to ensure acceptance of the deployment, some of those include:
  • How to enforce security policy with NACA
  • How to Review logs and report on users found non compliant
. . In order for the operation staff to understand these topics, they must have training and experience with NACA and the concepts. It is your job as a deployment engineer to ensure that these topics are covered and operations can hit the ground running with NACA.

Introducing NACA to the Help Desk Staff:

Help Desk is the nerve center of a NACA deployment. Ensuring that the HD staff can help users when issues happen is imperative to making them successful. Keys to empowering your help desk staff are:

  • Train them about common issues
  • Ensure they have proper access and knowledge of how to access the information needed to troubleshoot or help users
  • Have a documented escalation path (e.g. help-desk - operations -engineering - Cisco TAC)


Operations & Help Desk Staff are sometime forgotten about, but their knowledge and support of the NACA deployment is critical to a successful deployment.

Tuesday, May 15, 2007

Deployment Best Practices Series – Deployment Expertise


NAC Appliance is a product that can looks very easy to install. For most people, this can be the start of many problems. It is important to realize that the product is made to be easy and that level can be obtained, but a lot of hours are required to realize the Ins and Outs of NACA. This post is all about the misconceptions about what level of knowledge a deployment engineer should have, as well as the steps engineers can do to get to that level.

Understanding the Learning Curve:

NAC Appliance is a product that does deploy very quickly. For smaller deployments, it can be stood up and working in just hours, but this is for engineers that have taken the time to understand it. The more hours you spend looking into the CAM GUI the easier things get. This product gets confusing in a few instances:
  • Customization of Posture Assessment and Remediation
    • Going above and beyond the normal of Windows HotFixes and AV Installation/Definitions
    • Truly enforcing security policy with CCA
  • Deploying on a complex network
    • The network is not following best practice design methods
    • There is not a deterministic Layer 2 or Layer 3 path from the client to a central point
I cannot tell you how many times something simple becomes complex as a result to the preceding topics. It is a best practice to work with this product before deploying to a production environment. One of the best parts of this product is the fact that it does fit into so many Diverse Networks, unlike others. As an administrator, it is important to note that it does "plop" right into ANY network, but implementing NAC is a perfect time to gain more knowledge and conform better to best practice network design.

Getting the most of NACA:

The reason that Expertise in deployments is so important for a successful rollout is the fact that the product has so many small caveats and non-publicized features that can truly make or break the deployment. I personally would like to advertise the interesting custom checks that an experienced NACA engineer can use to enforce security policy. A minor list of examples being Preventing Instant Messenger, Peer-to-Peer, Sniffer Applications or checking for Group Policy features.

Making sure you do not fall victim of lack of expertise:

The following are best practice ways to ensure that the deployment goes well by ensuring that you have the skills it takes to deploy NACA. Any one topic will help you get experience, but the more you perform the better the deployment will go:

Formal Training – Find a class that teaches NAC Appliance. Ensure that the content matches your deployment strategy and the instructor ACTUALLY has experience with NACA in the real world. Stay astray from the “cookie cutter” type classes. Priveon, a security training company, has really world class training program for this type of training or you can always request custom training from a local Cisco Partner.

Research – Use the resources available to you to inform yourself about NACA Deployments. This can be performed via the NACA Chalktalks, NACA Documentation, whitepapers, etc.

Lab Experience – Getting NACA into the lab so that you can test the features and functionality that you want to deploy in a controlled environment can give you the knowledge and experience to become prepared for the real deployment is key to a successful deployment. This phase should come before any pilots.

Consultant Help – There are many external resources available for you to either give you a turn key solution or assist in your deployment of NACA. The reasons behind this investment could be resources or technical expertise, but the key to using this resource to your ability is making sure you shadow and learn from the consult deploying NACA.


Many organization fall victim to “I thought I could get it working” and then really do not receive the benefits of NAC Appliance. This is the reason why to have a successful deployment you must have experience with the product.

Wednesday, May 9, 2007

Deployment Best Practices Series - User Acceptance of the Solution


User Acceptance of NACA is the #1 most important consideration that must be made during a deployment. This post should hopefully help you understand the best practices to make users "accept" the solution.

Messaging the Solution to Users:

In order for users to not get really upset about the solution, you MUST message the plans of turning on the NACA solution. If you do not message this information to users they will have no idea what hit them and you can rest assure that their boses or parents(in the EDU space) will hear about it and you will be getting A LOT of complaints. Along with these complaints will be the complete dislike of the solution before they have even used it. Messaging is simple and can be performed by using:

- Posters/Banners
- E-mail
- Formal Letters

The content on the messaging needs to include:

- Benefits of CCA for the end-user & organization as a whole
- Reasons the organization is deploying the solution
- Time frames of deployment
- How the Deployment will affect the user
- What are the responsibilities of the user
- Policies that are enforced and when will they be enforced
- References to the Organization's Security Policy
- Where to find more information or who to contact in case of problems

This messaging will help users really see the reasoning why NACA is important and how it can help them as an individual. This in turn will truly help the acceptance of them having to interact with NACA.

Making the first encounter of the "terrible" green goblin (CAA) tolerable:

At first look, users can be very upset about having to use an agent to get onto the network. Because of the messaging that you have done they are at a minimum expecting it and have the knowledge to get through the experience. Tasks that you can do to ensure that the first time the user ever uses the product is successful and acceptable are:

- Deploy the agent via a Software Pushing Technology, like Altiris, to ensure that the user does not have to download the agent.

- Only cutover some users at a time, do NOT cutover all X users at once. This ensures that the users are able to have the best performance possible. This will also allow any administrators or help-desk staff to respond efficiently if problems arise.

- Make sure to enable Single Sign On (SSO), if possible, to allow the users not to have to login twice.

- To ensure users are able to be comfortable with the agent, before they have to spend 2 hours updating their machine to conform with security policy, it is best practice to start the NACA Deployments with optional requirements. This will present the user with the violations of their devices without stopping them from performing their normal tasks. E.G. All users must have AV Installed is a requirement in your security policy, but for the first 30 days the CAA will prompt users to install AV, but won't stop them from accessing the network if they chose not to remediate. After the users have had time to realize that they are out of compliance and they have had plenty of time to fix their violations at their convenience (typically 3-30 days depending on type/size/culture of the organization), the optional requiremetns should be changed to mandatory. This time frame of optional requirements should be illustrated in the original messaging about the solution. If the user community is non-adaptive to changes at all, then some organization even start with no requirements and then move to optional requirements.

Ensuring on-going Acceptance of the solution:

In order for users to continue to have that good feeling about the solution, administrators must follow some simple guidelines to ensure the user community stays happy:

- Configure the clearing of devices (Certified Device Timers, Session Timers, Heartbeat Timers) in a reasonable fashion. Timers must be used to ensure periodic posture assessment of users, but they should be configured in a reasonable manner. E.G. If a person has to login to theCAA every hour on the hour to get on the network they will not be happy.

- Ensure that maintenance of the NACA solution is performed off hours, remember some deployments are in-band and will denial of service users if you perform an upgrade during the day.

- Continue the good communication that was initially established. E.G. if you are going to start enforcing the use of Cisco Security Agent, make sure that the users understand the new requirement and do have time to ensure they are within compliance.

- Make sure the users have a knowledgeable help-desk that they can consult on any issues that come up.


Users are people too and if you take the proper steps to ensure that their experience with the solution is a positive one, you will receive positive feedback and lower the total cost of ownership (TCO). Help Desk tickets will be minimal and you can sleep better at night because users do have the latest signatures.

Deployment Best Practices Series

I receive the following question all the time:

"How do I make sure that my deployment of NAC Appliance goes well?"

The easiest way to answer this question is to ask "What makes a NACA Deployment Fail?" Failing, in context to the above, means that the solution causes more harm than good and does not provide the benefits as promised. Cisco NAC Appliance is a product that can do everything and more that Cisco promises. The following are what I have found to cause more harm than good if they are not addressed from the beginning of the deployment:

1.) User Acceptance of the Solution
2.) Deployment Expertise
3.) Operations Acceptance of the Solution

This is where the series comes into play. I will be posting what I have found to be "best practices" to address these 3 problem areas and hopefully help everyone to understand how to make their deployments successful.

I really am open to feedback if anyone has any suggestion/comments for the series.

Monday, May 7, 2007

NACA Version 4.1.1

Version 4.1.1 was posted to CCO for download on April 30th.

Some of the feature "enhancements" that i found interesting and useful, but not too geeky are:

- Support for Windows Vista

This is something that has been around in the 4.0.X train but not 4.1.X, so customers should really enjoy this feature

- Multiple Active Directory Server Support in ADSSO
Previously, you could only define a single AD Server for ADSSO. Now with 4.1.1 you are able to authenticate to an entire "Domain". This greatly enhances the availability of ADSSO.

- Restricted Administrator Web Console Options Hidden from View
Now when you can take away even Read-Only rights to certain aspects of the CAM. This makes it less tempting for the help-desk staff to go in and look through private event data, etc.

- VLAN Prunning
This works in conjunction with a Virtual Gateway CAS using VLAN Mapping to ensure that only known VLAN ID packets are allowed to traverse the internal network. This should prevent any broadcast/loop issues that might have previously happened.

- WSUS Support
Now we are playing ball with the introduction of WSUS support. This release tightly integrates updates through WSUS, to ensure users have the proper patches.

This is only a few of the many new enhancements in 4.1(1). To review all enhancement, caveats and upgrade procedures please read the following release notes:

Cisco NAC Appliance 4.1(1) Release Notes

Please note that it is best practice to follow the upgrade procedures to the "T" when upgrading a NACA deployment.

For those of you just getting into the land of NACA, there is a very good presentation on the features that came about in Release 4.1(0) located on CCO called "What's New in Cisco NAC Appliance 4.1" that should catch you up on the latest and greatest features.

Saturday, May 5, 2007

NACA Chalk Talks

The guys at the BU have invested a lot of time on getting people the basic knowledge about NACA by doing a "chalk talk" series that can provide you with a really good resource. If you are joining us with zero knowledge or just basic knowledge these presentations are a great place to start. They do require CCO Login, but are definitely worth filling out the form. I probably will not talk about any of the topics in the presentations, because that would not hold any value, but you probably will see me expand on some of the topics that did not get as much attention as warranted.

Friday, May 4, 2007

CAM & CAS Licensing

CCA is licensed in two manners:

CAM Licensing
The CAM is licensed on the basis of how many CASs it can manage.
1 CAS Failover Bundle = 1 Server Count
CAM comes in 3 Flavors: Lite(manages up to 3 Servers), Standard(manages up to 20 Servers), & Super(manages up to 40 Servers)

CAS Licensing
The CAS is licensed on the basis of how many users are logged in. The easiest way to understand this is to think about how many Online Users show up int the IB/OOB OU List. The only caveat to this is that if you are using Device Filters that are marked as "Check" you need to include them in the CAS User Count.
CAS comes in many flavors ranging from 100 users to 2500 users


Welcome to NACA Blog

I just wanted to say welcome to people. I am really utilizing this blog as a Knowledge Management System to post ideas about best practices, whacky or mis-understood topics, Tip & Tricks, and Configuration Topics. Please let me know if you would like to help contribute to this blog and the more comments the better.