(No Ratings Yet)
Loading...This is an endpoint security system originally written by Okena (formerly named StormWatch Agent), which was acquired by Cisco Systems in 2003 and is focused on intrusion prevention.
We took our first look at the Cisco Security Agent (CSA) in 2007 as we were working on a project plan for Cisco Network Admission Control (NAC) which I will write about later. During that project, Cisco introduced us to CSA, and we purchased a 10-client starter kit to get more acquainted with the product. Being a Cisco-only infrastructure company, CSA was a natural extension to our plans for increasing security.
After reading the entire set of manuals and books from Cisco (see references at the end of this blog entry), I thought I was prepared to begin my first installation and configuration. Cisco is adamant that you should not modify or change any of the default policies, rule modules, rules, application classes, variables, etc. This is very sound advice and every install should heed this. I would also recommend that you spend time reading and reviewing the Cisco default configuration to better understand exactly what the product can do and how it does it. As I said, I thought I was prepared and I took the default Cisco environment and just deployed it. I used the Test_Mode_Desktop agent kit and pushed it to a client. The install took seconds and immediately, I was getting event logs and information from the client.
To get started, we took a system that already was checked out by CA eTrust and Webroot SpySweeper Enterprise. As soon as we had CSA installed, it reported the presence of a rootkit on the client and immediately put the system in lockdown mode which essentially took it off the network and isolated it by blocking all traffic. That was exciting for three reasons. First, because it can take pro-active measures when it detects something bad is going on, and second, it provided the administrators with detailed information and reports about what was going on so that the problem could be diagnosed, and lastly, it did this on a system that we “knew” was clean and up to date. So, wwas the product right or was this a false positive report that had to be dealt with?
I read various reviews, blogs and reports on the product and talked with a number of end-users, consultants and resellers about CSA and there are web pages and recommendations that suggest that the rootkit detection rules be disabled because they will disable client network access becuase they are false-positives. The truth is that they are identifying a situation that needs administrative attention and action. This is what you buy CSA for. Their problem is that they were building numerous one-off rules for every exception rather than taking a systemic approach to handling system security. Unfortunately for Cisco, they are out there offering opinions and recommendations that render the product down to a simple firewall at best and an ineffective useless set of rules giving customers a false sense of security at worst. We started down that same slippery slope and it is a one-way ticket to the funny farm. Don’t be fooled into it. I had taken the default parts of the system and started cloning things right, left and center. If I needed a modified rule, I would clone the rule. But that rule was used in a rule module, so I made a clone of that and put my new rule in it. However, that rule module was used in one or more policies, so I had to clone those and make changes. Those are used in groups, so I had to clone those and make changes. Then, I had to make new agent kits to deploy all of that. After awhile, it was hard to know what I was doing. But back to our rootkit. As it turns out, it was some left-over device drivers from Webroot SpySweeper which we thought was uninstalled, and it is obvious why those drivers look like rootkits. Most spyware fighting applications hook the OS and file system accesses. Since we abandoned and “uninstalled” SpySweeper, we thought it would remove its device drivers. It does not. Thanks to CSA, we found the issue and put in procedures to clean up our systems. This was a win all they way. Our systems no longer have legacy unused drivers on them and we have faster, safer, better computers for our users.
Having built too much “stuff” that were slightly altered duplicates of Cisco’s original build and impossible to manage, my next step was obvious. Go back and read the manuals again and spend a week or two just going over the architecture of the product and get inside the heads of the developers. This is extremely important. It is very easy to assume how a product works or to listen to others explain their interpretation of how it must work. But to really understand the product requires getting to know exactly what was done and why. I read every policy, rule module, rule, application class and variable and then constructed a mental model of the default installation. I blew away everything I had done and installed fresh. This time, I worked on building exceptions to the main rules rather than modify what was already there. This was a better approach as I began to learn the way rules were executed and how the exceptions executed and discovered that the baseline config from Cisco is extremely well done. Understanding those inner-working relationships and where to abstract your customizations before mucking around with the system is critical to a successful installation that can be understood and managed by others.
After a few weeks, I could see even clearer how to build the environment. My approach was OK, but my implementation was flawed. I saw how I could use even more of the baseline and minimize my impact by making even smaller adjustments at lower levels and building new policies to emcompass them. Once again, I decided to get back to reading and blow away the install and do it again. By the third time, I was much more confident in my ability to work with the product and understand the philosophy of the designers. Through all of this, the Cisco TAC engineers for this product were guiding me through configuration questions, syntax errors and problems I encountered. Overall, I found at least three or four serious bugs in the product and made a number of suggestions for improvement including the documentation. The biggest improvement needed in the product is reporting. It is literally impossible to get client reports and printed output and other data for analysis. Everything is done from the web-based GUI which is just not sufficient, even though it is extremely well done.
The last install we did was the charm. Using simple exception rule modules that took our environment into consideration and upgrading cloned Cisco classes and variables to include later releases of 3rd party applications, we deployed the systems to a 10-user pilot program. Our client environment is all Windows XP/SP2 on laptops. Our deployment had to work just as well in the office as would in Heathrow Airport. We monitored the events and worked with these users to understand what the events were, why they were occurring, and to abstract those events into generic allow or deny rules that made the system much more flexible and manageable. For example, Cisco alredy had a set of rules for software installation. In our company, we do not allow users to install software as it requires approval from IT management and then, only IT staff can do the installation. So, rather than clone, modify and update everything related to installs, all we had to do was create a single rule that said our IT group (product can communicate with Active Directory) was the only group allowed to put a process into application-install mode. After that, all of the install-mode rules were fine and required no further changes.
If you think about viruses and malware, they generally come from known places. These include, the Internet or World Wide Web, E-mail, other users on the LAN and removeable storage. Knowing the source is one thing, but they also have to get into a position to execute as well. In Microsoft Windows, that means they want to be in directories such as “Program Files”, “Windows’, “System32”, “Documents and Settings” or autorun on removeable media. So, what if we can prevent them from getting there or running? We have the information and knowledge, so it should be a snap — and it is! One rule locks down the writing of DLLs, EXEs and OCX files in any of these directories (or their subdirectories) and another prevents programs from running off of removeable media. Since software installation is restricted (and I suggest that every enterprise should enforce this), then there is never any other production reason to write these files in any of those locations. Note that this also means that users cannot download any of these files from the Internet since their temporary download area is in their “Documents and Settings” subfolder. Problem solved. And yes, we found exceptions to our rules when downloading these types of files from our internal servers was needed, like installing the web-sharing addon for Cisco MeetingPlace. No problem. Build a custom rule module that references an application class that contains the exceptions and whenever you have something new (say, WebEx), then you add it to the class and deploy. A one-line change is all that was required.
The best thing about CSA is that it is totally transparent to our users. We have disabled the UI, so there is no indication that things have been blocked or warnings or interactions. And by transparent, I also mean that it has a very small footprint and literally has no noticeable performance impact on any of our systems. Even when the user is in the airport, at a hotel or Starbucks, the CSA client continues to operate and protect our users. At one point, I had users in the airport in Israel and I could see the numerous attacks and hacks being attempted on their systems. They had nothing to worry about as CSA was preventing these attacks, blacklisting IP addresses that tried portscans and other hacking techniques. None of them knew what was going on behind the scenes and they continued to work without incident.
We have had CSA deployed for months now and we are extremely happy and bullish on the product. So, our next step was to uninstall all of the eTrust software on the clients since CSA was effectively making anti-virus software obsolete. That step alone, paid for CSA as this product is extremely inexpensive and that is saying a lot when you realize it is a Cisco product as they are not known for being low-priced. Having said that, the one area that Cisco must address is the server license pricing. The server product is absolutely no different than the client product. It is the same software, but uses different rules because of the nature of servers. But rules are “soft” and anyone can write them. So, how does Cisco justify that the server license is thirteen times more expensive? I don’t know and I have made my position clear with Cisco sales and their partners. I am convinced that this product can be a major force in keeping an enterprise free of malware, spyware, viruses and other problems. Cisco can dominate and pricing will get non-Cisco customers into the Cisco camp, but they need to address this pricing issue. We are currently working on a deployment for all of our Windows 2003 servers and Linux Redhat 4 systems. This has been somewhat delayed though, because of the cost issue.
Version 6.0 of the product is expected in August 2008 and we are anxious to see what new features and functions have been added to the product. We do know that some of the bugs we reported are marked as fixed in this upcoming release, and hopefully it will keep its low profile and performance features. I am hoping that this release will include support for Windows Vista and 2008 Server in 32 and 64-bit versions as well. This is also a good time to talk about upgrades. This is where this product truly shines. If you think about upgrades for a product like this, it could be a disaster. If you have too many new custom rules that are based on the originals, then when they provide updates to rules, modules, application classes and variables, then trying to take advantage of their hard work on these updates is going to cause you nothing but horrific grief and frustration. Our implementation process makes full use of the Cisco upgrade strategy. When they update something, the product checks to see if that rule or module is in use by a group, policy or whatever. If so, it keeps both copies that are identified by the Cisco version number. So, after the upgrade, nothing has been changed as far as your users are concerned. The adminsitrator can now go through the changes and make the upgrades and integrations that they feel are necessary to their environment and test before going into production. If you find any rules with the old version number, then that is being used somewhere and you can decide on upgrading or not. To make that work, Cisco has a fantastic feature that allows you to compare two policies, rule modules or rules or application classes to see what was done. You can copy, clone and make changes based on the results. They show up side-by-side for comparison and analysis. This is absolutely brilliant and not only that, the product also gives you a history of the changes that you’ve made. If something is wrong, you can revert back to older versions. Another great feature of the product is export and import. If you have a set of rules, modules, policies or classes, you can export them so that others can use them or Cisco TAC can evaluate them and assist in debugging and helping you,
Our current security footprint on our clients also includes Sunbelt-Software Counterspy Enterprise 3.0, which I will write about later. It replaced SpySweeper some time ago for numerous reasons. Anyway, the obvious question is, what about Counterspy? Why is that still needed? These are good questions. I am convinced that a well-configured CSA deployment can eliminate the needs for anti-spyware software as well. Our plan is to continue to monitor Counterspy with the expectation that we will not see it catch anything. As a matter of fact, we just upgraded to Vipre Enterprise just to stay on top of the product. However, if we are satisfied that CSA has made Vipre Enterprise redundant, then it will be uninstalled as well. You can be sure I’ll be writing about that if it happens.
I highly recommend anyone who is looking to secure desktop and laptop computers in any size enterprise to take a hard look at the CSA solution. This product can stand alone in your environment and does not require any Cisco hardware or other products to operate. Take the time to familiarize yourself with the product and evaluate your environment and build the configuration to match it. Use the product in test mode and start a pilot project to understand what is happening and how to address it. Use test mode again whenever you upgrade or make changes in a test environment before deploying to your users.
Reference Materials:
Cisco Security Agent (Networking Technology) by Chad Sullivan (Paperback – Jun 11, 2005)
Advanced Host Intrusion Prevention with CSA (Networking Technology) by Chad Sullivan, Jeff Asher, and Paul Mauvais
Using Management Center for Cisco Security Agents 5.2
Pingback: Comment on Egypt protesting European embassies? by Mo-ha-med ·()