Today, I was asked by a client to look at best practices for digital certificates, such as X.509 and the like. I extended that research to include all types of encryption certificates, SSL/code signing, etc.

Basically, there was a dearth of best practice information available for setting the expiration dates on certs issued for various purposes.

We found a wealth of mentions in PCI, FFIEC, FDIC, NCUA, HIPAA, NIST and other guidance about checking to make sure that expiration dates were valid, reasonable and such, but no real guidance for what “reasonable” is or anything to cite to make a statement that your approach and processes fit the reasonable judgement. There were plenty of guidance sources on checking authenticity of certs, vendor selection and all of that, but little to help organizations in their attempts to define reasonable best practices for how long certs should live once issued.

Our next step was to take a look at the practices of some of the leading certificate vendors and see if we could establish a consensus from their approaches. Quick checks into their process revealed the following:

The major certificate vendors (Verisign, Thawte, etc.) issue certificates with a maximum life span of 2-3 years for most purposes. They explained that this minimized the overhead management work for them while establishing enough care for cryptographic changes (this doesn’t happen right? MD5 nightmare anyone, anyone?), organizational changes and churn in their client base. Secondary vendors (Comodo, RapidSSL, GlobalSign, etc.) in this arena issue certificates for a maximum of 5 years. It appears that they are willing to extend trust a little further to minimize their workload/overhead in management of the certs and processes.

Generally speaking, after reviewing this data, the various standards and processes and the mechanisms that the “big boys” use, I would offer the following as a best practice for setting up expirations on certificates in general.

The best practice for establishing expiration dates on certificates should be two years with a hard set maximum of five years. Two years should be the established baseline for processes and organizations with any increases (up to a maximum of five years) requiring appropriate risk assessment/acceptance from responsible parties in an organization.

I hope this helps folks who are working on establishing certificate systems and other processes in their organizations. If you disagree with my approach or work, please let me know. I am always open to comments via the blog or @lbhuston on Twitter. Thanks for reading!

2008 is quickly evaporating and 2009 is on the horizon. The first few days of the new year always feel fresh, like a newly washed blackboard, ready for new thoughts and ideas. This is an excellent time to plan how you want to secure your organization’s most precious and sensitive data. Here are a few ideas:

1. Protection – Start a spreadsheet log that not only lists all your electronic assets (laptops, mobile phones) but the names and dates of who has them. This will save you the stress of trying to figure out who had the laptop last week.
2. Destruction – Do you regularly shred? Do you have a schedule to keep you on track to regularly shred? Don’t let dumpster diving thieves get your data. Shred and shred often.
3. Cell Phone Mania – The ubiquitous cell phone is often in danger simply because of the sensitive information that is on it. Think of a pop star’s cell phone getting stolen and everyone prank called. Now think of a thief getting a cell phone and snagging that credit card information of a new client. Get your stable of cell phones password-protected and avoid keeping financial or private information on it.
4. Information – It’s all about the data. As much as you may suffer from information-overload, it’s important to take stock of what exactly is on a laptop in case it is lost. Make lists and check on them regularly for updates.
5. Out with the old, in with the new – Whenever you buy new equipment and toss the old, don’t allow it to sit collecting dust in the back room. If your organization experienced a burglary, there would be a serious breach of confidentiality if those old hard drives were stolen. Find a reputable company to dispose of your outdated equipment safely and efficiently.

Employ some of these tips or all, and your organization is guaranteed to have a much safer 2009!

Over the last several months we have worked a ton of incidents where compromise of systems and networks was accomplished via Internet exposed terminal servers, VNC and other remote access applications. Often, these same administration-friendly tools are used in internal compromises as well. While there is certainly a value in terminal server and VNC, they can be configured and your implementations hardened to minimize the chances of attack and compromise.

Careful consideration should be given to having any form of remote desktop access Internet exposed. Attackers are very good at slow and low password grinds, social engineering and other techniques that make these exposures good targets for gateways into an environment. Unless you have a serious plan for managing the risk and you have excellent levels of controls, raw exposures of these tools to the Internet should be avoided. If you need to use them for remote access, consider some form of IP address restriction, authentication at a router for dynamic ACLs or forcing a VPN connection to gain access to them. Neither terminal server or VNC should be considered a replacement for a robust VPN and with tools like OpenVPN offering free or low cost alternatives, it is just silly to not leverage them over simple port exposures.

Even if you do not Internet expose your terminal servers, it is likely a great idea to make sure that they are hardened. Here is a great powerpoint that covers hardening both terminal servers and Citrix deployments. You can also find more guidance in the CIS baseline tools and documents. There are several good documents around the net for hardening TS in line with various baselines.

VNC can also be configured to be more secure than a “base install”. Starting with which VNC implementation you run, UltraVNC and TightVNC have some very powerful security configurations that can help you minimize your risks. Choosing stronger authentication mechanisms and implementing IP address controls, even inside, can really help you keep an attacker from running “hog wild”, even if they do gain some sort of user access or compromise a workstation with a bot-net client. Consider the use of “jump boxes” dedicated to being the terminal server or VNC gateway to all other machines. If you implement these “choke points” then you can uber-harden them and monitor them closely for bad behaviors and be assured that without accessing them, an attacker can’t easily use your remote access servers against you.

Just take a few moments and think it through. Sure these tools make it easy for admins. It makes it convenient for them to do their work and admin remote machines, but it also makes it easy for an attacker. Hardening these tools and your architecture is a great way to achieve that balance between usability and security. You can get work done, but you can do so knowing that you have enough controls in place to make sure that it really is you who is doing the work.