MC Press Online

Tuesday, Jun 27th

Last updateTue, 27 Jun 2017 9am

You are here: Home ARTICLES Current Events & Commentary Commentary Murphy’s Security Law

Current Events & Commentary / Commentary

Murphy’s Security Law

Support MC Press - Visit Our Sponsors

Forums

Search Sponsor

{loadposition popsearch2}

Search

Element Break 

The Year-End Sale Runs Until December 31st Get Our LOWEST Prices Ever!

Element Break 

Holes are everywhere. Address them before someone addresses you.

A couple articles ago, I talked about the need for modernizing encryption on our IBM i partitions. Shutting one door can shut others, and shutting other doors may give you a false sense of security when you have a few windows open. You can drive yourself batty looking for these holes, but every now and then a hole finds you.

Maybe it’s because of a heightened sense of awareness that I’m seeing security issues in places I’ve never seen them in before. Maybe it’s just Murphy’s Law, but it seems everywhere I looked in the last week I saw security holes in my environment. Or even worse, the exploits of security holes in my environment.

There are some lessons learned here that I’d like to share with you.

Issue #1: EDI Certificate Replacement

This should’ve been a really positive event. We have trading partners that send information to us over EDI and vice versa, like many other companies do. We encrypt that data, although it’s actually managed by people outside IT. That’s a story in and of itself, but the lines of communication are open between departments, and I was asked to update the EDI software in order to use a new SHA-2 certificate required between us and a trading partner. The trading partner is mandating SHA-2 encryption, which is great news. I’ve written ad nauseum about the dangers of SHA-1, and it’s great to see companies want to ensure their communication is as secure as possible.

Then I noticed that the EDI team had set up the application to use 3DES ciphers.

Ouch.

The trading partner didn’t care about what ciphers were used. Well now. Ain’t that a pickle. Use SHA-2 but with a highly vulnerable cipher? Nope. We mandated AES ciphers, and the trading partner was fine with that. This is one of those “false sense of security” issues. Without that extra check, the ciphers used would’ve been vulnerable to the lovely SWEET32 vulnerability among others. Now, SWEET32 hasn’t been seen in the wild, much like POODLE or BEAST hasn’t. That doesn’t mean they aren’t dangerous. Nobody wants to be the first. The point is, we need to be disabling weak ciphers and enabling only strong ones if at all possible.

Please ensure your applications are running with a SHA-2 certificate, good ciphers, and TLS 1.1 or 1.2. That’s the magic three-tiered combination. Anything less than that puts your company data at risk.

Issue #2: Cryptolocker

This is one of those scenarios in which you’re damned if you do and damned if you don’t. Here’s the story. We were notified in October that we are closing down a branch office in December. The thought was to not give that particular office the new antivirus product, which is now our standard. Plus, it would be for only two months, and for the most part they’d be covered with the older, but still functional antivirus. That office has only about 10 computers. A minor risk to save some cash, right?

The gamble didn’t pay off.

Two people in that office managed to go to the same website to inadvertently pull down a lovely cryptolocker variant that encrypted both laptops and then reached out and partially encrypted a mounted Windows file share. Luckily, we do backups, and those users didn’t have a lot of folder authority on the file share. Either way, it could’ve been much worse. In the end, we had to go to backup tapes for the file share, and two laptops were completely pooched of usable data.

Lesson learned: Protect everyone all the way, no matter what. Shortcuts cause pain.

There is a silver lining to this breach. In the last two months, I did a number of security seminars for our users, attempting to scare the heck out of them with talk of vulnerabilities, viruses, and phishing. I even went to Human Resources and made it a mandatory seminar for everyone.

It’s funny. Warehouses or manufacturing plants don’t let anyone operate a forklift or a scissor lift without training or certification. But when a new office employee comes on board, we just give them a laptop, a smartphone, and a “call us if you need us” send-off. Maybe a link to an IT policy or acceptable-use policy. Users are seldom given an initial boot camp on how to use a computer safely. How can we expect them to make informed decisions if we don’t arm them with some training? Informed decisions are one thing. How do we know a user won’t accidentally take down a network or a server because they don’t know what to do if confronted with a dangerous situation?

In one of my sessions, I told them if something slips past the spam and virus filters in an email to not do what makes admins cringe: forward the e-mail to someone else for an opinion. “Should I open this attachment that’s a zip file from This email address is being protected from spambots. You need JavaScript enabled to view it.?” No!

What happened that day? We had people sending us screen shots of the e-mail in question. That’s awesome. People will help you help them if you give them the tools and knowledge to do so. Who clicked on the dangerous link? Users who didn’t have adequate virus protection or the recent training. I won’t make that mistake again.

Issue #3: Home Networks (i.e., the Internet of Unprotected Things or IoUT)

This isn’t an issue due to what’s happened, but it’s an issue due to what can happen. More and more users are working from home on a regular basis. The question was brought up this week: How do we deal with security concerns by home users over a VPN tunnel? To be honest, I didn’t have a good answer. Unless we manage a user’s home network, we can’t be sure what they’ve got connected to their network, what kind of router they have, whether they’ve changed the default password, or if the router is 10 years old and is subject to serious security concerns. We don’t know if a router has an easily guessed secret support account. A compromised router can be used to carry out DNS redirection attacks, denial of service (DoS) attacks, and man-in-the-middle attacks to glean corporate data off the home network.

This needs to be on your radar because the problem is only going to get worse. And if users, not techs, are plugging in whatever devices they get from a hardware vendor or an ISP and taking for granted that they’re secure, then they’re in for a rude awakening.

Here are some quick examples:

300,000 routers from D-Link, TP-Link, Micronet, Tenda, and others are open to man-in-the-middle attacks.

Misfortune Cookie exposes 12 million residential network gateway devices to attack, threatening personal and enterprise data.

So what do we do? Buck the trend Yahoo-style and force workers back to the cubicles? It’s possible. Mandate specific hardware for home office use? This may be a trend many companies will be compelled to at least advise toward. Turning a blind eye doesn’t mean there’s not a severe threat to enterprise security. Until this security problem is addressed by hardware manufacturers and ISPs, new devices will continue to be put into homes. This doesn’t address the millions of corruptible devices in the wild already.

Keep it on your watch list. And don’t assume your data is safe just because people are coming in over your VPN.

Issue #4: We still had some users coming in over PPTP VPN.

I know. Somebody smack me. Luckily, it was a very small minority of our users, and it was addressed immediately. The service doesn’t operate anymore.

So if you’re still using PPTP, please have a look at this $200 tool that anyone can purchase to break it. After reading that, you should move off PPTP as it’s been broken for years. Essentially, anything is a better choice. For a good choice, check out OpenVPN.

Steve Pitcher
Steve Pitcher is a specialist in IBM i and IBM Lotus Domino solutions since 2001. Visit Steve's website, follow his Twitter account, or contact him directly at steven.carl.pitcher@gmail.com.

Website: blog.itechsol.com 
More Articles By This Author
Related Articles
BLOG COMMENTS POWERED BY DISQUS