syserr.com

When you have a large web presence and you need SSL certificates for all of your pages (e-commerce, etc),  it can be very tempting to just register a wildcard certificate as a catch-all encryption solution.

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.

You would think this would be self explanitory, but it’s really not to many, many organizations.

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.

I got an old stereo cabinet at the habitat restore a while back. I put a home stereo amp in it and set it up to play my iPhone or an iPod. I need to find a better integrated amp to mount in it. The speakers sound suprisingly well for open air.

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.

I recently decided to place a block at our content filtering system for logmein.com and gotomypc.com.  Things were fine for a few months, with only a spattering of users complaining that they could no longer access their work computers from home.  This is exactly the reason I placed the block.  More recently, however, a few users, including the CIO, have come to me with some business case scenarios that have called for me to do some re-thinking.

Read More >>