If someone breaks into your house or, worse, invades it while you are there, you will feel a variety of strong emotions including outrage, anger, and fear. It may be hard to feel safe there again. A few months ago, our neighborhood suffered a rash of mid-day burglaries–kick in the front door in the middle of the day while everyone is away and steal whatever you can that you can sell quickly, and generally trash the place as you are going through it. (The police told us that the front doors were heroin addicts. The rash of auto burglaries that we had at the same time were meth addicts.) One family across the street was broken into twice–once while the kids were at home. They moved to a gated community.

I haven’t personally had this experience. After years in security, I guess I know how to make my house look like a harder target than my neighbor’s house. But, I have a pretty good understanding of how they feel. In our current (over-) connected society, we can have the same feelings when our computers are invaded. I once had the experience of having my computer broken into while I was sitting in front of it. I didn’t really feel violated so much as insulted. “How could you. I’m using this now. How stupid do you think I am?” (“pretty stupid.”) In the end I felt pretty good about that incident. Using my superpowers, I removed the intruder, cleaned up his mess, and discovered and closed the hole he had used to get in, all within an hour.

Today things are different from those days long gone. Today I build and operate networks of computers “in the cloud,” somewhat freed from the computer under my desk (but not from a bunch of laptops). I get the computing horsepower I need from a large vendor of “Infrastructure as a Service” (IaaS in the industry jargon). If I need a new machine for an experiment, I ask for one and 5 minutes later, I have one. If after a couple of hours, I’m through with the new machine, I throw it away. There is some cost involved, but the machine I used for a couple of hours costs far less than my time, and way less than the cost of having a spare piece of hardware laying around. (If you want to learn a little bit more about how cloud computing works, you can look here.)

Last week, I had a strange experience. I received a notice that one of my cloud machines had been used in an attack on somebody else’s computers. Naturally they wanted to know what I was going to do about that. That part of the story is not unusual. The unusual part is how I felt about the incident. This was not a break-in at my house. It was not a break-in of my computer. But, there was a break-in, and I still felt angry and violated. I wanted to understand what had happened and make sure it could not happen again. I wanted to catch that hacker and step on their fingers (the tools of their trade). I wanted to make sure they would never again disrupt the flow of my well-ordered life.

A few days later, I see how strange this was. It’s not like some real possession was broken into or attacked. There is no physical machine anywhere in sight. There was nothing that was “mine” there except for some work 5 years ago. And yet, I have this feeling of violation. Why? I don’t really understand this. But, I do better understand the feelings op people who have actually been violated. It’s not a small issue, and could have lasting repercussions.

I also felt curiosity. My first instinct was to get on the machine and look around to see how they had gotten in. But, there was a problem with that. I built this machine almost 5 years ago and really hadn’t been back to it since then, and I couldn’t remember how to get on (which only convinced me even more that someone had taken it over). There really is a right way to deal with these incidents, and I had the luxury of being able to use it; I notified the right people, shut the machine down, and went to dinner.

I did get on the machine the next day and looked around. I found that the machine was under attack almost continuously, but from people who really need to get a life. I’m happy with attacks from the terminally stupid (the attackers who try the same thing over and over again, sometimes for hours or even days, in the hope that something will be different the next time). But, I didn’t find the attacker who succeeded, and I’m not happy about that. That means I would never know if I had successfully cleaned up the machine.

In the end, I chose the path of no resistance–preserve the data I’m trying to serve from the machine and throw everything else away. Rebuild the machine from the ground up on a new, more secure platform and move on. This is a cloud computing path I could not have chosen with a non-cloud machine. The attacks are inevitable and continuous, and some are bound to succeed. The cloud infrastructure has given me a new, less stressful way to respond, and I am happy about that.



Edsgar Dijkstra, a famous Dutch computer scientist (well, at least famous among computer scientists of a certain age), was once asked what you should look for when you planned to hire a computer programmer. His answer was that you should look for someone fluent in their native language. Dijkstra reasoned that anyone who could communicate could be taught everything else they needed to know, and someone who couldn’t communicate wasn’t going to survive no matter what else you taught them. Indeed, anyone who has given instructions to a child about how to do something has already performed many of the tasks needed by every programmer.

To Dijkstra’s requirement, I would add that a good programmer needs a high tolerance for frustration. Anyone who has given instructions to a child will understand why. Computers are literal-minded; they do exactly what you tell them to do rather than what you wanted them to do. But they are also perverse; they sometimes seem to know what you wanted, but still do only what you said except that they will thumb their noses at you while doing it. The only way out of this is to persist. Keep trying until you have managed to describe what you actually want. These two characteristics are not valuable just for programmers. They would be very helpful in any profession where diagnosis and correction of problems is part of the practice.

I’ve had quite a few lessons in perseverance in the last couple of weeks. The church I attend has had problems with its WiFi network lately and I decided that I could fix the problems. I looked at what they had and what they wanted to do with it and said to myself “two hour job.” I’ve now been there for two hours or more at least five times. And at last, the network is beginning to behave. The WiFi can be seen all over the church campus (there are several buildings and, unlike your house, many poured concrete walls that do a poor job of transmitting WiFi signals). Where you can see the network, you can actually connect to it and get it to do something (this is new). And, the hidden mystery access point left over from some earlier, undocumented version of the network has been tracked down and killed. Considering the trouble it caused, “killed” is a pretty apt word.

I think I’ve finally overcome this problem. The interesting thing is that it was not my skill at networking that solved the problem. My skill at networking is what got me into this mess in the first place. It was tolerance for frustration and perseverance that got through the problem. Background got me to open the can and look at the worms, but it didn’t tell me what to do with any individual worm when I picked it up–”this thing is a router and I know what routers do, but I don’t know how this one works.” The new network design changed several times (for example, because of unexpected concrete walls) but ended up about where I thought it might.

It would have been satisfying to go to the church and fix a straight-forward network connectivity problem. It should have been much more satisfying to start with what appears to be straight forward problem, but has lots of hidden traps, and still solve the problem. It wasn’t. Everything works well enough, and the customers seem satisfied, but I still have an idea of what it could and should have been. I feel a need to go back there and tinker. Maybe tomorrow.

And no, I can’t solve Your problem, especially if it involves Windows.