For instance, if you have the domain webpage.com, and you have 3 sections of the site (www.webpage.com, shop.webpage.com, and blog.webpage.com) that you need to add SSL certificates to, buying 3 different SSL certificates can get costly.  Many organizations see an opportunity to purchase a wildcard certificate as a large cost saver with a much higher ROI and lower TCO.

However, lets say you need to secure shop.webpage.com because it contains names, addresses, and credit card numbers.  Your site www.webpage.com uses the same SSL certificate, but needs much less security.  It needs so much less security, in fact, that it gets set on the backburner since it needs less maintenance, and gets less patch support and security review.  Someone then sees an opportunity (or runs a script) and compromises the box that www.webpage.com sits on.  Your wildcard cert can now be considered insecure, as someone can download it and immediately use the private certificate of the wildcard to either 1) create a phishing site and retrieve data from your legitimate customers or 2) setup a MITM and decrypt all of your SSL traffic.

Now scale this scenario to 1000 servers with 100 separate admins.  You are now putting the security of your most private data into the hands of someone who doesn’t want to waste the time to patch their server because it doesn’t have anything important on it.

If the server doesn’t have information on it that needs assurance and security of an SSL cert, just don’t use one.  Then buy separate certificates for your critical servers.

It behooves me why certificate vendors that are focused on “security” even offer this option.  Bad design, bad implementation, bad idea.

It doesn’t matter how secure your enterprise system is. Even with firewalls, IPS, IDS, and application layer switches, when you run an enterprise application, you have an inherent duty to protect the data of your customer. In the case of many large organizations (credit companies, health care, government, etc), the ability to lose sight of the “big picture” seems to happen all too often.

Identity management seems to be a really big problem these days. When someone logs in for health care, how are you to prove that someone is who they say they are just by an email address?

The solution is to NOT USE THE SSN AS THE LOGIN. I’m not sure how this could be any easier. You cannot trust a user of your system to know when they have a keylogger installed, or to know when they are on a legitimate page. Just don’t do it. It’s that simple. When a person has a keylogger installed and they login to a system 10 times in a day with that SSN login, they might as well kiss their identity goodbye. And you can consider your organization at fault for bad design. Period.

Also threw a 17″ widescreen LCD in it where the record player used to be (it didn’t work).

Should be a fun jukebox project.

Let’s think for a moment how LogMeIn.com works.  A host has a client installed and this client opens up an HTTPS session (or “tunnel”, if you will) that periodically sends polling keepalive packets, just to let the logmein servers know that it is alive.  These keepalive packets are sent to the cloud.  When a user logs into their logmein account, they see the machine they registered and can connect to it.  When a connection is made, the logmein servers simply proxy the connection through the already established HTTPS session.

|Host| — |Enterprise Firewall| — [INTERNET] — |LogMeIn.com| — [INTERNET] — |Firewall| — |Client|

As shown in this diagram, the Host is only connected to the Client via a SSL session that is established through a proxy server.  For Government and very secure infrastructures, this is a BAD IDEA.  It doesn’t matter how smart a workstation administrator thinks they are, and it doesn’t matter how often they say, “but it’s a secure connection”, it is not a MANAGED connection from an enterprise standpoint.  Because most firewalls allow all SSL port 443 sessions outbound (HTTP over SSL), they will most certainly also allow logmein.com to connect to it’s gateway in the cloud.

We have a policy that is a gray area on this issue.  VPN tunnels are prohibited from terminating outside of the enterprise firewalls unless they are managed by our organization.  Although this isn’t technically called a VPN tunnel, it IS treated like one, with data flowing over a SSL tunnel.  With this policy in place, the websites were simply blocked at the content filtering system.

Herein lies the problem.  When vendors come into our environment, sometimes they use these services to get to their OWN demo machines.  This means the service is running inside their network and they cannot get to it because we have blocked the URLs explicitly.

And this is where the work comes in.  I must somehow block the service from being run inside the infrastructure (even on servers/workstations that we don’t directly manage), but still allow access to the website itself, so vendors can do their demos.  The risk I’m taking is that users can then install it at home and work on their home PCs while at work.  There are policies prohibiting use of the network for non-business matters, but this is an exception that the enterprise will just have to make.