If you have a Facebook account you’ve probably been overwhelmed by invitations to join the new “Local Network” the circle. If you’re thinking about signing up for it, I’d encourage you to

Do you feel overwhelmed by cyber security?

Me too. Let me give you my brief personal background.

I started fixing viruses when I was about ten (nothing complicated, but I figured out how to boot into safe mode and then run antivirus and search a hard drive for malware). That was pretty much when I decided my career. From there I started building websites, took programming classes, and snagged a B.S. in Computer Science in college. I am, by all definitions, a geek.

My point is I’ve been in technology for a long time. It’s a huge part of my life. And I often feel overwhelmed by it.

The effort involved in understanding technology is huge, but to add on the number of people trying to break in and steal your information is a lot of added effort. Sometimes the temptation to become a luddite is almost too much. But don’t give up. Technology and what it adds to our lives with communication, keeping up with loved ones, academic research, etc. is well worth it.

This post comes from my recent position change to a Security Management team. A couple weeks ago I asked for an overview of our network configuration and my head has been spinning since then. If you feel overwhelmed, take hope. Professionals get there sometimes too. Just take each technology one step at a time.

My team was recently asked to do an assessment of our companies patching strategy and to suggest improvements. Senior management’s questions came down to, “How do we patch the things good?”

This is a great question (one I wish more managers would ask). It’s not a simple one, though. If your managers start asking this question, they could well be expecting a number of days or weeks because it’s simple and easy to put in a report that clients see. “We patch all of our stuff within 30 days.” They may even be happy with breaking it down a little more, “We patch workstations within 30 days and servers within 3 months.”

A common question I’ve heard is, “How fast do our vendors say we need to patch?” But no vendor will give you this ever (and if they do, don’t buy from them). The second they publish a document saying, “If you apply our patches within 72 hours, you’re safe” they’re liable at some level if you get hacked within 72 hours. No vendor should be willing to take on that risk.

But that’s the naive approach. It’s better to start the conversation this way, “We’ll need to do some risk analysis, it’s going to take time and money, but we’ll be better off for it.”

Because patching isn’t a specific process that can be applied to all technology. Tons of factors go into how important patching is (visibility of the technology, how important it is to your business, how much access it has to other technologies, other stuff in close physical proximity to the device, etc, etc, etc). You can’t apply a generic standard and expect it to be very effective. You may actually wind up wasting more time and money patching unimportant things at the same rate as the important things.

After you’ve prepared your execs for the cost associated with patching, ask them to list the top three applications that go down in their nightmares and then the top three applications that go down in their less scary nightmares. This gives you a spectrum to work with and it’s easier to fill in other technologies and assign risk to them.

From that starting point you can add on the severity level of the patch being released and tons of other factors. But start somewhere with a patching plan.

I don’t have screen shots for this because it happened a while back and I’ve switched jobs, so I’ll tell this tale in text.

Working on migrating articles out of a company wiki I wrote a script to download these articles automatically using the wiki’s rest API. Here’s the general algorithm:

1. Start with article 0 and request a batch of 100 articles (maximum allowed)
2. Request the text for the first article returned
3. Request list of attachments for each article
4. Download each attachment
5. Repeat for the next article in the batch
6. Grab the next batch
7. Stop when the batch returned is less than 100

Since the API is labeled “RESTful” this should be fine, right? Each batch of 100 will always return the same 100 articles, so asking for them sequentially is fine, right?

Wrong. So very wrong. Putting the word “REST” next to the word “API” does not necessarily mean they gave you a REST API.

One article was failing, making my whole script bomb. Thinking I could pop in and try to exclude that specific article, I found the index number and excluded it. But the next day it failed again. I tried to figure out why and realized that the bad index was moving down the index once every 6 – 10 hours. Which means that the indexes were stateful. Which means it’s not REST.

I get it. I honestly do. Not cleaning up indices makes for a painful system that can get bloated fast. But don’t use the buzzword if you can’t actually make it work.