Asimov Created Three Laws of Robotics, So How About Cyber Security?

Someone asked me why cyber security seems so vaguely defined. Surely there must be some standard set of laws like in Asimov’s fiction.

No, not that I know of, but maybe Icould help.

In “I, Robot”, a 1950 collection of nine short stories, Isaac Asimov introduced his Three Laws of Robotics:

1: A robot may not injure a human being or, through inaction, allow a human being to come to harm.

2: A robot must obey the orders given it by human beings except where such orders would conflict with the First Law.

3: A robot must protect its own existence as long as such protection does not conflict with the First or Second Laws.

In later works Asimov inserted a zeroth law before the others:

0. A robot may not harm humanity, or, by inaction, allow humanity to be harmed.

I can get cyber security down to five laws I see as crucial. The first two are for implementers and the other three are for designers and developers.

Bob’s 5 Laws For Cyber Security 1: People must understand and skillfully operate the systems.

If we can only have one Cyber Security Law, make it this one. There is no hope without Law #1.

My first draft started “System administrators” but this applies to more than just those people who know the root password on the linux servers. It must include the database administrators, the maintainers of the diesel generators and battery banks and air conditioners, the security guards, the human resources department,and ultimately, everyone at the company.

Law #1 seems obvious but it is frequently violated. I have seen so many people show up for theLinux server course reporting that their command-line experience consists of taking the introductory Linux-for-users course six to twelve months ago, and they have never touched a system before or since. I try to tell them that they are going to be frustrated and waste their money, but they tell me that their boss says they’re in charge of the ten servers showing up in two weeks. I hope I don’t rely on whoever they work for!

Now for the shortest one:

2: Patch.

If you have not applied all available patches for your installed software, you are behind. Test, make sure it won’t break existing functionality, and apply that patch.

The remaining laws are for the designers and developers:

3: Validate all user input.

Check it and then either fix it or discard it as appropriate, according to size, syntax, semantics, and form. The last has to do with what’s called canonicalization ― fully converting the data into whatever it really means. An HTML-encoded representation of an ASCII-encoded representation of a Unicode representation of a SQL injection is still dangerous.

4: Make decisions cautiously.

I create a user named “jim”, set a password of “rescue”, and start testing.

I enter user=jim, password=rescue, and I’m in. “We have solved the availability problem!” Um, maybe.

I enter user=jim, password=bogus, and I’m not in. “We have solved the authentication problem. Done!” Wrong.

Oh, so I enter user=bogus, password=rescue, just in case, and I’m not in. “Ah, now my security job is done!” Not at all!

Access must be allowed only when all requirements are precisely met. The system must fail into a safe state in all other situations, not just a few obvious ones.

Now we must agree on what a “safe state” is. When the fire alarm is triggered, what should happen to the door leading into a vault where classified data is handled? Should it fail open to allow the humans to flee the fire? Or should it fail closed to protect the secrets? Sadly, people argue that one both ways.

5: Handle errors, mysteries, and other unexpected situations gracefully.

Assumptions of validity lead to exploits by unexpected inputs ― the unsolicited reply (ARP cache poisoning, DNS cache poisoning), the attractive lie (routing table corruption) and all sorts of inappropriate inputs leading to system corruption (buffer overflows, SQL injections and other syntactic abuse, cross-site scripting and cross-site request forgery, and more).

Several years ago I read some advice that stuck with me: Networking protocols should be implemented so they behave like a well-mannered person invited by strangers to their party. Be conservative in what you do, and liberal regarding others’ behavior.

Don’t demand that every connection must support obscure bleeding-edge options and extensions. At the same time, if the other end insists on something you don’t support or maybe even understand, decline gracefully.

Put simply: Don’t be weird, and don’t panic because you think someone else is weird.

Going Further

Ross Anderson’s textbook Security Engineering: A Guide to Building Dependable Distributed Systems is a great explanation of why security system design is so different and difficult, and how to approach the problem. You can download it for free!

For more fundamental concepts of security, check out Learning Tree’s System and Network Security Introduction course.