Of late I’ve started to use Nagios more and more. Looking at the various plugins available I came across some plugins which were supposed to check after missing Windows Updates. I found most of them to be quite blunt with the exception of the setup over at Frank4dd. However I just wanted a plugin to monitor a single server and Franks setup was a bit to big for my needs. I was also interested in writing plugins for Nagios mostly to see what is needed to make it work.

I ended up writing a script which runs locally on a Windows machine. In my setup I’ve installed NSClient++ on the Windows machine. Nagios calls the NRPE part of NSClient++ which in turn runs the VBScript I wrote.

The script check_available_updates.vbs queries Windows Update (or a WSUS server) and returns a Critical (2) if missing critical updates are found. If important updates are missing a Warning (1) is returned to Nagios.

On the target computer I add the script to the scripts directory of NsClient++ and edit the NSC.ini file. First to enable externals scripts, just remove the semicolon before the DLL file:

CheckExternalScripts.dll

Then I add the script in the external scripts section:

[External Scripts]
;check_es_long=scripts\long.bat
;check_es_ok=scripts\ok.bat
;check_es_nok=scripts\nok.bat
check_available_updates=cscript.exe //T:30 //NoLogo scripts\check_available_updates.vbs

Running the script can take a while so you might have to set a higher timeout for NRPE. Using Nagios from the Ubuntu package I edited the file /etc/nagios-plugins/config/check_nrpe.cfg and added this command:

define command {
command_name check_nrpe_60
command_line /usr/lib/nagios/plugins/check_nrpe -H $HOSTADDRESS$ -t 60 -c $ARG1$
}

After updates have been installed it seems to take a bit longer to run the script so I might end up setting an even higher timeout.

Then I setup a service like this:

define service{
use windows-service-12h
hostgroup_name windows-computers
service_description Check Windows Patches
check_command check_nrpe_60!check_available_updates
}

If you are running WSUS this script would only check against updates which the WSUS server configured for the targeted machine is aware of.

In future versions of the script could use command line arguments to specify which types of messages are returned depending on which types of patches are missing.

Please let me know if you find it useful or have any ideas in terms of improvement.

The PKI server which ships with Windows, Active Directory Certificate Services lets you install it in four different modes. Before you install your CA servers you will want to know how these different types differ from each other so you can plan your setup to suite your needs.

Stand Alone Root CA

You would use the stand alone Root CA in the scenario where you want to use an offline Root CA. Stand Alone in the context of the CA server means that is it not integrated with Active Directory. However information from the CA, such as CDP and AIA, could still be published to Active Directory. Typically the Stand Alone CA is a member of its own workgroup as opposed to being a member of a domain. It is disconnected from the network only accessible to the operators of the CA server. The only time anyone needs to interact with the server is when it is to sign subordinate CA certificates or when it publishes a new CRL. This can be done by transferring files on a USB stick.

Enterprise Root CA

Using an Enterprise Root CA is probably the easiest way you can setup a PKI system on Windows, with this scenario you only need one server and you don’t have to think about subordinate CA servers and certificate chaining. Enterprise in the context of the CA server means that it is integrated with Active Directory. An Enterprise CA can be used to autoenroll certificates in an Active Directory environment.

The downside of this setup is that the Root CA server can’t be offline, making it more vulnerable to attack.

Stand Alone Issuing CA

A Stand Alone Issuing CA means that the CA server is a subordinate CA server and it has gotten its CA certificate signed by another CA server. Stand Alone means that the CA server isn’t integrated with Active Directory, though the CA server can be a member of an Active Directory domain. Typically this type is used when the CA server won’t be issuing certificates to objects in an Active Directory domain, or if you are using an offline policy CA server if you have a three tier PKI hierarchy.

Enterprise Issuing CA

An Enterprise Issuing CA is a member of an Active Directory domain and is integrated to Active Directory. User and computer accounts can enroll or autoenroll for certificates from this CA. The CA server provides the same functionality as an Enterprise Root CA server, but the Enterprise Issuing CA is a subordinate CA server.

Certificate Services Features in different Windows editions

One thing which can be easy to mix up when it comes to certification authorities in Windows is that some wise guy at Microsoft decided to use the term Enterprise to describe two different things. Windows Server comes in different versions i.e. Web, Standard, Enterprise and Data Center. You can install the Active Directory Certificate Services as a Stand Alone or an Enterprise Server.

In my opinion the Enterprise Root CA type should instead have be called something in the lines of Integrated Root CA or Active Directory Root CA server. The reason this is important is that the functionality of the CA server will depend on which version of Windows you are using.

Windows Web edition doesn’t provide any CA functionality. Standard, Enterprise and Data Center does, however the Standard edition is limited. Unlike the other versions the Standard edition of a Windows CA server doesn’t provide support for Network Device Enrollment Service or SCEP. Also OCSP isn’t supported. Version 2 or 3 certificate templates aren’t supported so you won’t be able to create your own certificate templates and autoenroll certificates from those templates. Further key archival, role separation, certificate manager restrictions and delegated enrollment restrictions won’t function on a CA server which uses a Standard version of Windows.

So if you can you should use an Enterprise or Data Center version of Windows for your Enterprise CA servers. For the Offline Root CA server Windows Standard edition should suit your needs.

This post is part of the Getting Started with Public Key Infrastructure series.

A PKI hierarchy can have one or more tiers. In a single tier PKI environment your only CA server will be the Root CA. If you have more tiers your Root CA will issue subordinate CA certificates CA servers below the root. If you have a two tier PKI setup you don’t need to have access to your Root CA server on a day to day basis. Since your users can request certificates from the subordinate CA the Root CA can be offline. Obviously having your Root CA offline increases the security of your PKI environment since no one has network access to the server. How many tiers your setup will use depends of what you want to do with the PKI environment, your security requirements and the trust you put into the environment.

The Root CA

Think of the Root CA as the King when you play Chess. If the king is lost you lose, you remove the rest of the pieces from the board and setup another game if you want to play again. When reading about PKI, some texts tell you that the Root CA should be hidden away in some bunker with two armed guards. Most of the places where I’ve worked hasn’t had two guards to spare. If you’re short on guards a comforting thought is, if we make the comparison with chess again, some games are more important than others. Likewise some PKI environments will require better protection than others.

When you create a Root CA certificate, the Root CA will sign its own certificate. At this point the new root CA certificate won’t be trusted by anyone. Before the certificates within the new PKI environment can be used the Root CA certificate has to be distributed to the devices which will validate certificates within the environment. If you are going to use this within a Windows network you can distribute the Root CA certificate by publishing it to Active Directory. If your PKI environment will be used by other companies you will have to sent them the Root CA certificate and tell them to trust it. If you will use the PKI environment on your routers and switches you will have to install the Root CA certificate on all those devices.

When a CA is compromised you should revoke all the certificates that the CA has issued along with certificates issued by subordinate CA servers. The difference if the Root CA server is compromised compared to a subordinate CA is that when the Root CA is compromised you will have to distribute the CA certificate again. If the PKI environment is used outside of your organization, for example at a partner company, that party will also have to trust a new Root CA. The partner company will also have to distribute the root CA certificate to its devices.

Subordinate Certification Authorities

In order to save yourself the trouble of having to redistribute the Root CA certificate, you can disconnect your Root CA and have it locked away until you need it. Instead your users will request their certificates from a subordinate CA. If the subordinate CA is compromised you will still have to revoke that CA and all certificates it has issued. At that point when you create a new sub CA, since your users already trust your Root CA it will also trust the new CA because of the certificate chaining process.

Aside from the redistribution of the Root CA certificate, there are other reasons why you might want to use a subordinate CA. This could be administrative purposes where you have one offline Root CA, and one subordinate CA in Europe and one in USA. You could have different subordinate CAs because you want to have different CRL validity periods. For example if you have one CA which issues certificates which users use to login to your network such as smart card login certificates, you might want the CRL to expire just after a short time so you can lock out a user who has lost their smart card. This however doesn’t mean that you want to use a CRL with a short lifetime on all your certificates, so you can use a different CA for your other certificates.

How many tiers do I need?

Most PKI setups will have one, two or three tiers. With one tier you only have your Root CA which is responsible for issuing and revoking all the certificates. In a two tier environment you will have an offline Root CA and one or more subordinate CA servers. In a three tier environment you would have an offline Root CA, one or more subordinate policy CAs which can also be offline. These policy CAs will govern the policy of the subordinate CAs below them, the issuing CA servers.

In a three tier environment the end users’ certificates will be signed by an issuing CA. The issuing CA certificates will be signed by the policy CA. The policy CA certificate, or certificates if you have several policy CAs, will be signed by the Root CA. As usual the Root CA certificate will be signed by itself.

On the image to the right you can see that the current certificate for www.amazon.com is part of a two tier PKI, where the web server certificate is signed by the subordinate CA “VeriSign Class 3 Secure Server CA – G2″. The subordinate CA is signed by the Root CA named “VeriSign”. Since the VeriSign Root CA came preloaded on my computer I can visit https://www.amazon.com without receiving a warning. This is because the certificate for www.amazon.com “chains” to a trusted Root CA.

You can also come across PKI environments with four tiers, though it is more unusual. There isn’t a right or wrong answer as to how many tiers you should use. It is however important that you plan things out and design your environment before you start installing and issuing certificates.

This post is part of the Getting Started with Public Key Infrastructure series.

At its core PKI is all about certificates, how they are created, what information they contain, how they are used, the level of trust you put into them, what happens when they are lost and the simplicity of using them.

It starts with trust

Looking at what kind of services PKI enables, secure remote access, wireless security, data cryptography, it is obvious that you want to remain in control of the infrastructure. If someone else would gain control of the service to issue certificates an outsider could be able to authenticate as your own users. When a Certificate Authority is compromised, the CA and all the certificates below in the PKI hierarchy has to be revoked and replaced. This is because you can no longer trust that branch. In short you need to be able to trust your PKI environment. Further the level of trust you, or the users of the PKI environment, have in the infrastructure will determine what the certificates can be used for. For some organizations who aren’t concerned about security this will be a non issue, they will just install the certificate services in a next-next-finish manner without giving it much thought. This could be viewed as a bad idea, however if it replaces a system where every monitor has a post-it with a username and password it’s still an improvement compared to before.

On the other hand if you want to use your PKI environment to issue certificates which will be used to access the internal network of a partner organization, they the partner will have to trust your PKI setup. Another example could be if you were to use the certificates to digitally sign financial transactions, in this scenario all parties who use the solution will have to trust the PKI environment.

In order to establish trust in the PKI you can write a Certificate Practice Statement (CPS) which is a document you create which describe your PKI setup, how you operate it and your requirement and procedures for issuing certificates. Individual certificates might also have certificate policies which describe which requirements must be met before a certificate of a certain type is issued. For example you might have a requirement that people enrolling for a smart card login certificate must show an id badge to prove their identity along with a digital signature from a manager. At the other end certificates could be automatically distributed to the computers and users on your organization.

Certification Authorities

The Certification Authority or CA is the service which is responsible for issuing and revoking certificates. This could just be a simple setup with a few (yet powerful) scripts using OpenSSL, an open source certificate toolkit, or a packaged solution such as Microsofts Certificate Services.

Through the CA software you configure the parameters for the certificates the CA will issue, along with the requirements your clients must fulfill in order to be able to enroll for a certificate.

Private and public keys

Every digital certificate is connected to a key pair, one private key and one public key. The public key will be included in the certificate. As the name implies this information is public for all the world to see, or at least for those who will use the certificate. The private key is the counterpart to the public key and is private to the entity (person or a computer device) who will use the certificate. When information is encrypted with the public key only the private key can decrypt it. On the other hand when information is encrypted with the private key only the public key can decrypt it.

So when my friend Marien wants to send me something encrypted which only I can read, he will encrypt the information with the public key he finds on my certificate. Since I am the only one who have access to the private key I am the only one who can decrypt the information. This way confidentiallity is ensured.

Looking at the reverse scenario if I want to digitally sign a message I send to Marien, I will create a hash of the message and encrypt (sign) the hash using my private key. My friend would then be able to use the public key from my certificate and decrypt the signed hash. Since he is able to decrypt the hash with my public key, he knows that the private key was used to sign the message i.e. I signed it.

Though the private keys should only be known to the person to which the certificate belongs, there are scenarios where you will want others to be able to gain access to the private keys. This mostly depends on what the certificate will be used for. If you will use the certificate to encrypt data, all your data will be lost of you lose the private key. For example if your private key is stored on a smart card and the card is broken (perhaps you have a dog or kids?) or lost you won’t be able to read your data. To mitigate this risk the CA could be setup for key archival where the CA stores your private key for later retrieval. You could set this up so that it requires that several people have to digitally sign the approval to retrieve the private key.

If you only use the certificates to login to a service, you can just generate a new keypair and issue a new certificate if the private key is lost.

Certificate enrollment

Once the public and private key pair has been generated the public key can be inserted in a certificate request which is sent to a certification authority. Along with the certificate request other information could be used, such as the name which will be included in the certificate. For a SSL certificate this would be the name of the website for example secure.networklore.com. Although information can be added in the certificate request (CSR) it is up to the CA to determine which information is kept and which information the CA will add regardless of what has been included in the CSR. Some CAs will ignore everything in the request and just keep the public key, while others require certain fields to match the requirements of the CA.

Enrollment can be manual where a file is generated and manually sent to the CA. In many cases this will mean posting a hexadecimal string into a web form and later returning to retrieve the certificate.

Using a Windows enterprise CA, enrollment can also be automatic where group policies are used to auto enroll machine or user certificates.

Once the CA has received an enrollment request the CA administrator can choose to issue the certificate or deny the request. With the auto enrollment option the certificate might also be issued without any interaction from the CA administrator.

When the certificate is issued it will be signed with the CAs private key. Anyone who trusts the CA can then verify that the certificate was signed by a trusted party, since they will have access to the CA certificate and its public key it is easy for them to use the public key and verify the new certificate.

Digital certificates

Once the CA has issued a certificate it will include the public key along other certificate information. Together with the private key a user can now use the certificate to decrypt information sent to the user, or encrypt information which others can decrypt and thereby verify with the certificate itself.

If I have an email certificate and want to send you a digitally signed email, I don’t need to know anything about any certificate you might have since I will only use my own private key to sign the email. However if I am to send you an encrypted email I will need to have access to your email certificate so I can use your public key to encrypt the email. If I want to be able to read the email after I send it to you, I will also have to encrypt the email using my public key. That way you can decrypt the email using your private key and verify the signature with my public key. Also I can decrypt my own email with my private key since I also encrypted it with my private key.

If there is key archival setup I will want to use two email certificates. One for signing and one for encryption. I will get back to why I would want this further down in this article. Can you think of a reason now?

When talking about digital certificates there are “soft certificates” and “hard certificates”. A soft certificate is a file placed on your computer and a hard certificate is a certificate placed on a device such as a smart card. Though a private key can be marked as non exportable there are ways to circumvent this in Windows and gain access to the private key and move it to another system. Technically it is much harder to export the private key from a smart card.

Usage scenarios

Aside from email encryption and signing, there are a lot of scenarios where you can use PKI and digital certificates.

You can setup certificate based VPN. When you have site to site VPN between known locations with static IP addresses the benefit of PKI isn’t really security. It actually adds dependencies where the VPN routers need to have access to the CRL distribution points, so you could argue that the operational security is decreased because of the added dependencies. However you can still benefit from using certificates in terms of ease of use. If you don’t use certificates you have to authenticate with pre shared keys (private key encryption), and the problem here is that you have to distribute the key to the other location. The more VPN tunnels you have the more keys you will have to generate and distribute. If a router has 10 IPSec VPN connections to other locations it will have to hold 10 different pre shared keys. If you have a mesh setup where all the offices connect to each other you will end up with a lot of keys, instead of just 10 digital certificates. One certificate for each router.

However if the VPN consists of dynamic clients, i.e. remote access VPN where users login with client certificates there is a large gain by using certificates. Also with site to site VPN connections you might have offices using with DHCP addresses where you don’t know which address they will connect from. In this case use of a PSK would require all the connections to use the same key. If you are setting up DMVPN you will want to use certificates to authenticate dynamic VPN connections.

Another obvious usage scenario is plain old SSL for websites. When you shop online or do online banking a PKI certificate will allow you to encrypt the information you send to the server. Also since the server presents a certificate to you you can, using the information within the certificate, verify that it is a valid certificate and that it chains back to a Root CA which you trust. By default there will be a few trusted Root CAs installed to your operating system.

If you are setting up 802.1x authentication, for either wired or wireless you can use PKI and PEAP or EAP-TLS to secure the setup.

Code signing is another use of PKI where a developer can digitally sign her code to let users verify that they are running code that was written by a developer they trust.

With smart cards you can use PKI to allow your users to login without having them to remember complicated passwords. There are organizations who have implemented smart cards for the sole reason of saving costs after vacation times when a lot of users forget their passwords and call the helpdesk in order to reset their passwords.

Maintaining security in a PKI environment

Did you think about why you would need two email certificates if you use key archival? Since you can sign an email with a certificate which intended purpose is digital signing you don’t want anyone else but you to have access to this key. That would mean that they could impersonate you and sign documents or emails on your behave. So if you want to protect your encrypted data from loss it is a good idea to archive your private key in some manner. However if you lose the private key for the signing certificate no data has been lost, and you can just generate key and certificate in order to continue to sign other documents or emails.

With private key encryption, or in a login scenario where you authenticate with username and password, the password can be lost or compromised. This could be a misplaced post-it note, it could be because of shoulder surfing or the fact that the name of the users dog isn’t a secret at the office. With private key encryption the user can talk to the network administrator and setup a new private key or password if you will.

However with certificates there isn’t any shared secret which we can change if the private key has been lost or compromised. But we still don’t want anyone to be able to use a stolen private key to be able to login or authenticate using the certificate. Though we can’t change any key we can revoke the certificate, this way telling the world that a particular certificate has lost its validity.

When a certificate is revoked it is added to a Certificate Revocation List (CRL). An entry is added to the list which contains the serial number of the certificate which is to be revoked along with a time stamp which says when the certificate was revoked. Optionally you might see a reason for the revocation, such as key compromise or certificate superseded. The CRL is then signed by the CAs private key and assigned a validity period.

Once the CRL is signed it is then placed on a CRL Distribution Point (CDP). Opon verifying a particular certificate the information within that certificate will contain information for the CDP so the person or program verifying the certificate can access the CRL. The CDP is generally a HTTP URL or an LDAP URL. If the certificates serial number isn’t listed in the CRL the certificate is still valid. The downloaded CRL is often cached for the remainder of its validity period.

The process of revoking certificates only protects against compromised keys when they are used to access a service. If you lose your private keys to your laptop encryption, an attacker will be able to use the key and certificate to decrypt your data even if the certificate has been revoked. The solution is not to store your private key together with your data.

This post is part of the Getting Started with Public Key Infrastructure series.

Public Key Infrastructure (PKI) is a set of technologies and standards using public key cryptography to issue and revoke digital certificates. A PKI consists of servers called Certification Authorities (CA), digital certificates, policies and procedures. At its core PKI provide three main services which provides authentication, integrity and confidentiality. Having a PKI environment enables you to use it in a range of different applications to provide security and simplified logins.

Authentication

Authentication is used to verify someone or something’s identity. In terms of computer security this is generally something you know (password), something you have (physical token) or something you are (biometric).

Let’s say I want to login to my server and send it my username “patricko” and password “LetMeIn!”. The server would then compare my credentials to the information stored in its database, verifying that I can authenticate my identity (patricko).

This login procedure with username and password is called private key encryption, as opposed to public key encryption. Instead of public and private key encryption you will also come across the terms asymmetric and symmetric encryption.

Using something I have, a smart card, I could use it to login without having to know any password. The smart card in turn would have my digital certificate stored in its chip. Since my server would trust the certificate authority which issued my digital certificate which allows the server to verify my identity (patricko). In this example I would have leveraged PKI to authenticate my own user. PKI can also be used to authenticate a VPN tunnel between two routers or allow a laptop login to a wireless network.

Integrity

Providing integrity allows us to trust our data. In order to trust data we want to be sure that it hasn’t been altered, this could be intentionally or unintentional modification. We want to be able to verify the integrity of the data after it has been in transit, meaning that if we send the data across a network from A to B we want the data to be identical on both locations. Also we could also be interested in verifying the integrity between “then” and “now”, i.e. has the data been modified in any way during the last six months?

An example could be a contract where we want to make sure that the contract we signed hasn’t been changed since we signed it. Looking at a network session we want to be sure that the bits hasn’t been modified, i.e. from a man in the middle attack.

With a certificate we can digitally sign data before we send it across a network, using the digital certificate the receiver can verify the digital signature and have confidence in the integrity of the data.

Confidentiality

Confidentiality ensures that information, in transit or at rest, is only accessible for those who are authorized to see the information.

When you are using your credit card online you want to make sure that no one but yourself and the merchant can see your credit card number. Encrypting the data between your computer and the server you are connected to provide confidentiality.

Likewise when you connect to your company through a VPN you want all the traffic to be encrypted and thus provide confidentiality. Another example is if you have a laptop and want to encrypt your hard disk.

PKI Basics

Every PKI hierarchy starts with a Root Certification Authority which everyone trusts. This CA can issue certificates either directly to end users and devices or to a subordinate CA, which in turn issues its own certificates.

The information within the digital certificate describe what kind of certificate has been issued, how long it is valid and what it can be used for.

If the certificate is lost the CA administrator can revoke the certificate in order to make sure that it no longer can be used.

The components of a PKI are one or more servers which have the CA services installed, a certification practice statement which describes how the CA issues certificates, administrators responsible for the certificate life cycle, digital certificates, servers hosting the certificate revocation lists and nodes using the certificates.

This post is part of the Getting Started with Public Key Infrastructure series.

Would you like your IPS to use over half a million sensors instead of just the ones you deploy? Cisco IPS 7.0 introduced Global Correlation which uses information from SensorBase to help you determine if incoming traffic is from a known hostile host or from a legitimate source. But let’s not get ahead of ourselves.

SensorBase is a reputation service.

So What is Reputation?

If I go out to a restaurant to eat and I’m dissatisfied with the service I get, you can bet I will tell my friends about it. If the restaurant were to serve my chicken raw I can guarantee that I would spread the word and warn people. My friends would probably take my advice and avoid the place, some might even tell some of their friends. However this doesn’t scale at all since there are a lot of people I don’t know. Others might go to the restaurant having never heard my warning. Another problem with this example is that I might just have caught them on a bad day and others might love the restaurant. If my friends knew that 50 people loved the restaurant and I alone thought it was bad, they wouldn’t give my words much credit.

SensorBase gives each IP address a score between -10 and +10, where -10 is the worst possible score. Unlike me warning my friends about a particular restaurant SenderBase scales, it is the world’s largest traffic monitoring network. With over 700 000 deployed sensors world wide it sees a lot of traffic. It is in use by 8 of the 10 top global ISP’s and also collects information from 500 third party feeds. It uses a lot of factors to determine the reputation of an IP address.

If an IP address has a very low score SensorBase score you probably don’t want traffic from that host entering your network. You can be pretty sure that there has been a lot of malicious activity from that address.

I will avoid the restaurant which gave me bad food for years to come, i.e. black listing. Even if the restaurant fires the chef the next day they will still be on my black list.

The reputation service provided by SensorBase doesn’t work that way, since traffic is constantly being monitored by all sensors an IP address which was considered to be very hostile two months ago might have a positive score today. The other side of this coin is that a “good” IP address can fall from grace if the sensors start seeing repeated malicious activity.

I’m sure I’m not alone when I say that I’ve found an IP address in a log file and wondered what it was, checking DNS and whois records to see if it is anything to worry about. Now I can just ask SensorBase about its opinion and save me some time.

Origins of Cisco SensorBase

When Cisco bought IronPort in 2007, SenderBase was part of the deal. SenderBase was IronPort’s reputation service for their anti spam solution. Instead of just relying in signatures IronPort developed SenderBase in order to be able to drop connections from known bad hosts based on the reputation of those hosts. Currently SenderBase sees over 30% of the world’s email traffic (that quite some SPAM ).

A lot of SPAM includes a link to a website, it turns out that a lot of these websites are hosted on the same infected machines which are sending the SPAM. Since IronPort already had a huge reputation database with all these IP addresses they saw an opportunity to use this database for other services aside from pure anti spam. They then created the S-Series web security appliances. The name SenderBase remained the same even though it wasn’t only concerned by “senders” at that time.

As more products are beginning to use the reputation service Cisco has now rebranded it as SensorBase.

Current Deployment

Aside from being used by the IronPort Web and Email security products, SensorBase is used by Cisco IPS 7.0. The botnet traffic filter function which came with Cisco ASA 8.2 also uses SensorBase, though it currently doesn’t block any traffic it can really open your eyes as to what kind of hosts your end nodes are talking to.

It would have been cool to see SensorBase integrated with Cisco Security Agent, but you can’t have everything. However I’m sure we’re going to see SensorBase becoming available to more and more products, and the larger the monitoring network grows the better the service becomes.

People at Cisco have told me that the staff who do internal IT at Cisco says that Cisco Security Agent is the product which has done the most to improve their overall security. Now I’m hearing that the product is being dropped.

If you’re not familiar with the product, Cisco Security Agent is a host IPS product or HIPS. Unlike Cisco’s network IPS products, CSA protects workstations and servers by intercepting operating system calls which it can deny or allow. The goal of the product is to stop threats by learning the normal behavior of the applications running on a machine, and stopping activities not in line with the expected behaviour. This way security isn’t enforced by relying on updated signatures. As an example we can control which applications can write to certain directories and files on the client such as system files.

A couple of years ago I wrote an article about jail breaking locked down Windows sessions using Microsoft Word. Cisco Security Agent wouldn’t have any problems defending against this kind of malicious activity, without even trying. This could have been done just by recording the behavior of Microsoft in a controlled environment, and enforcing that behavior.

There are a lot of options and variables which you can set and use with Cisco Security Agent. Though the above example of blocking write access to specific directories might not sound all that interesting, this is only an example. There are loads of settings, aside from just system security if you want to make sure users are following your acceptable use policy there’s a good change Cisco Security Agent can help you by creating rules and policies to make sure your users aren’t able to break those policies.

Recently while working with a client who had decided to buy CSA and install it to a new platform for their network the question of support for Windows 7 arose. While checking with Cisco I got the answer that it would be supported in the next release of CSA, however I also heard that CSA 6.0.2 would probably be the last release. After asking around at Cisco I got the confirmation that there would be no further development of the product.

Looking at this from an economical perspective I can understand that Cisco is a leading networking company and that they feel that the market for endpoint security is already crowded. As traditional antivirus vendors are beginning to release HIPS products the competition will probably tighten.

However from a security and solution perspective it seems strange when you see how CSA fits into Cisco’s self defending network strategy. It can be integrated to other products such as the network IPS with the external product interface allowing the Cisco IPS to receive information from CSA MC (Management Console) which can be use to evaluate which action to take. CSA is frequently used in Cisco’s design solutions for customers in terms of PCI compliance.

Perhaps Cisco is the wrong vendor to have this specific product in its portfolio, and perhaps someone else will buy it. But it’s a shame to see it just being dropped.