This post isn’t security oriented, or technical. It’s just what I’m working on most recently. At work a management decision recently blended our Network Infrastructure and Security Teams together and I was asked to run a project melding the two “on call responsibilities” and figure out a single point of contact or help desk setup so people would know how to contact us.

Help desks are tricky things. The ideal (most expensive) solution is to have happy, highly intelligent people on call 24 hours a day so that when the phone rings, someone who can immediately answer the question is available immediately.

But it isn’t cost effective to have your software engineers sitting on the phone all day doing nothing but waiting for a call, so you start having them do project work and and watch the phone too. But then, their project work takes priority and they can’t answer the phone so you hire a less qualified person that you can pay less to watch the phone the time the engineer can’t be available and have the engineer write documentation for the less qualified person to cover whatever they don’t know.

That solution sounds good. The less qualified person answers the phone, finds the documentation or script they need and can answer the question. But engineers write documentation for engineers. When you have someone with less experience or education than an engineer reading it, the call usually turns into this on one end or the other:

Google has been in the news a lot lately for buying a number of robotics companies. If you’re not familiar, just search “google robotics” and read an article similar to, “Google plans to take over the world with advanced robotic war machines” (or something that sounds catchier with the same meaning).

Basically, google purchased a company that builds robots (pretty advanced ones, some of them pretty creepy at the time of this writing), which sparked a lot of discussion about which Sci Fi movies were coming and if we have to start worrying about terminator or I Robot coming true.

We’re still pretty far off from either of those. Don’t get me wrong, Google’s robot’s are still scary and could be dangerous, but they’re not going to be creepy in the way I Robot or Terminator was. Google’s robot’s have strong movement ability, agility, and are able to carry a lot of weight. But they’re not advanced in AI or human interaction.

These robots are really no different than a UAV or a car with a remote control, they’ve just developed different methods of locomotion. There’s no intelligence there, no ability to decide to kill their human masters and turn them into batteries.

What should actually scare us are things like IBM’s Watson which played jeopardy really well.

Even though Watson might just look like a box it’s ability to correlate events and answer questions is a lot closer to what makes I Robot and Terminator scary. The advances IBM made building Watson brought us closer to I Robot than any “big dog” running around a parking lot. I guess the lesson here is to package your robots cute so people won’t panic.

NOTE: There’s another article about what makes robots creepy, but hopefully I’ll have another post on that later.

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.

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.

Where can it happen?

What is it?

Why should I care?

How can I protect myself?

Where can it happen?

What is it?

As a disclaimer, this post is mostly me reassuring myself that I shouldn’t give up computer science completely and go live as a hermit somewhere.

I was recently at a java conference. The conference was excellent. I sincerely support the idea of getting together with other technology people to discuss best practices in our field and share knowledge. It’s a great way to learn and even just understand that there are other people out there who understand what your job is like.

However, there is a risk in going to these conferences and it jumped out at me in a session on immutability.

The presenter was making the case for immutable programming which is the idea that almost none of your variables should ever be allowed to change state. The talk was good, but I find it easy to become almost frantic at sessions like this. Here’s a brief look inside of my head:

“Oh gosh…I program with so much mutability! I need to change. I need to change now! MUTABILITY MIGHT END THE WORLD!”

While it is true that programming immutably is better than programming mutably, mutable programs are not the worst thing ever. We’ve been using them for years and a lot of people will probably continue to use them for years. Immutability may be better, but it isn’t the holy grail of programming.

I imagine the same thing happened when the infamous “Go to statement considered harmful” paper came out. Yes, go to is bad. Yes, it is easy to shoot yourself in the foot. But you can also create programs with it that work. And that’s really what we need in an enterprise environment, isn’t it? Programs that work.

It’s easy to set your goal as the perfect programming style and to not be satisfied until you write everything perfectly. Sometimes you need to accept that your design isn’t the best and might require work to update later. Sometimes you need to accept that even though you’ll strive for perfection, not all of your programs will be that. And that’s ok. Make the best program you can in the time you have, learn from your mistakes (and conferences) and improve your programming style over time.

In the previous post we established that tablets are in general are a good idea for executive/VP/Management typed jobs to have so now the big question: Android, iOS, or Windows tablet?

Let’s look at these from two angles:

1. How easy is it for an IT department to get them running within a current environment?

2. How comfortable are execs using it?

For the first, windows tablets are the hands down winners (Windows, not Windows RT). Rather than incorporating a whole new operating system and purchasing expensive software to manage it, it’s just a different version. Not to say it’s plug and play, but getting windows to match corporate security standards is much easier than iOS or Android.

The second is more complex and depends on the executive. iPads are easy to use. There’s no way around it. My grandmother (who is in her mid eighties) can use it confidently. I’m not comparing VPs and managers to my grandmother….but the point stands.

Android tablets sound scary. They’re also less shiny and less well marketed than iPads. Long story short, it’s more difficult to get a non-technical person to use an android tablet.

Windows should be obvious, right? It’s what every enterprise uses. It’s common. We’ve all been using it forever. What surprised me was that it wasn’t that simple. Most execs I’ve talked to don’t want a windows tablet. I guess it’s the intangibles, because they want an (you guessed it) iPad.

Is this the right choice? The techie in me says no for the reasons above. But there is something to be said for keeping execs happy and comfortable.