Unexpected security issues and unpleasant surprises

nasty surprise
Thinkstock

Years ago I was working for a company and one of the finance directors was having difficulty getting his financial application to work. He rang me up late on a Friday (still can’t believe that I remember that) and he declared that it was a problem with the firewall blocking his application. Naturally.

“It has to be the firewall! I know you keep the access tightly controlled in here so I know it is blocking my application.” A wry smile crawled across my face. In actuality it wasn’t the firewall but, a permissions problem. His application was wanting, nay, demanding administrative access to install other libraries. Nothing could go wrong here. I looked at my Toronto Raptors tickets on my desk and wondered if I would see them tonight. I slid down the hall with my laptop tucked under my arm to the finance department wondering why these sorts of problems always happened at 4 pm or later on a Friday. A mystery for the ages.

He stood behind his chair smiling. He wasn’t a bad guy. He knew what he was doing in his own realm but, he did not suffer being hindered from getting his job done. He pointed at his laptop and said, “There is your patient doctor” grinning from ear to ear at his own joke. I looked over the top of my glasses and replied, “You’re killing me."

Once the problem was sorted I started to check at what this application was doing on the network. It was making calls out over port 443. Well, thank goodness for small miracles. I fired up the log analysis tool on the firewall. I started watching the packets go flying by…well, not really but, you get the picture. There was the traffic, HTTP, SMB, HTTPS…wait…what?

There was HTTPS traffic…but, I could read it. That really didn’t seem correct. I know that might seem silly to say but, it was late in the day and the game was calling me. I rubbed my eyes and looked again. Yup, there was the financial data from the application. I glanced back at the director’s laptop and checked the application with the padlock icon and “HTTPS” selected.

I started digging into the application. I reviewed the documentation and then poured over the log files again. All of the traffic was being sent over TCP/443 and that part was accurate at least. But, absolutely none of it was encrypted. I was surprised that a company would push a product that, at the very least, implied that it was secure. I really don’t know why I was surprised when I think back on it. I guess it is safer to say that I was disappointed.

This all came flooding back to me when I saw a pop up on my screen today. I run an application on my MacBook called Little Snitch. It’s a host based firewall that keeps an eye on applications to prevent them from making a call out that was unexpected. Today I had one of those moments. One of the applications on my system decided to make a call out to “encrypted.google.com” on TCP/80. I had a moment of facepalm. 

While in the end this seemed to be a simple error it made me want to tear apart my system and review every application and the associated traffic. But, this isn’t going to happen today. What this did was to give me a moments pause for services that I can rely on like Little Snitch. Whether it is a service like this or protection from DDoS attacks or web incursions there is a point at which you need to trust someone to help you defend the perimeter and avoid any unpleasant surprises.

Copyright © 2016 IDG Communications, Inc.

7 hot cybersecurity trends (and 2 going cold)