This is one of those seemingly simple concepts that never really gets elaborated. Usually a student learning Java for the first time is told. “Write the following:”
public class Person
{
public static void main(String[] args)
{
System.out.println("Hello World!");
}
}
“Don’t ask why, just do it.” Because of that, I’ve heard this question more than a few times in the last couple years.
(more…)

The latest paper of interest is “Liability and Computer Security: Nine Principles”by Ross Anderson. He’s apparently a Cambridge man who hass done a great deal to change the ideas behind security principles. He’s also got a fair flair for writing on dry topics in a not-so-dry voice. This is one of my favorite skills that I pray everyone can find, at least to some degree. This should especially be true if you’re one who enjoys writing more than 5 pages per research paper.

The focus of the piece is reconsidering the driving force behind security advancement. The classic direction is in implementing best practices available to engineers in order to minimize risk, although the paper didn’t speak to these principles directly. While using the previous direction as log from Frogger, it proposes the chief factor that drives advancement in security is liability and the transfer thereof. It tries the case through several examples focused primarily on security systems used in United Kingdom banks.

It’s hard to simplify in less than five pages, but overall it points out how litigation following incident lead to the most change in the way the UK banks operated and how this system differed from the American cousins. This may seem obvious, but he also tries to tease out the notion that the flaws in the systems did may have resulted from poor designs or because the industry as a whole was not handling these types of issues despite an abundance of technology that could have stopped many of these errors.

The premise is one that I can see merit in, but the application is quite limited in my mind.  The shortcoming of this analysis is that thec cases cited showed that loss due to failure of security mechanisms could be mitigated by an insurer or other liable body. This is not a common issue. In fact, banks and other asset management systems are the only groups that fall into this category, from my view. The only way you can restore most, let alone all, losses resulting from a security incident is if the lost material is of an entirely non-unique, exchangable nature.

I’ve become intimately familiar the concepts of risk as it pertains to reputation, trade secrets, and personal data. These are the pillars of risk, and they are regarded as the very purpose for security in our age. If you look at each element of risk you can see where Anderson’s model doesn’t apply. There are far too many groups out there to determine that liability transferrance is even an option for most cases.

Can Oracle transfer liabile risk of reputation damage to an insurer if they write poor software? Google’s search algorithm is worth trillions of dollars if potential earnings considered, and they could not insure their systems against loss of that information. And how would the Department of Defense transfer liability of operations information being leaked through an insecure system?

These cases are just a few of the corporate and government organizations that represent a vast majority. It’s unreasonable to think that any of these situations would have liability driving their security design and implementation. Why would it then be a driving force for the industry as a whole? It is unlikely, at best.

Again, I do not disagree with Anderson’s paper entirely; I feel that it is quite limited in it’s potency on a broader scope. I applaud his introduction of litigation and liability to the process, but it has far less impact on security than he believes it to be. Liability will always be a concern for any organization, but that does not mean that purpose or method changes because if it.

Yes, the lyrics to this delightful song by Santana (featuring the always forgettable Rob Thomas) share a truly fascinating phenomenon. It is the belief or need for reason merely because of the existance of one’s true love…or, in my case, a Cryptanalysis course.

While studying common methods for cryptography, there was quite a debate when discussing how humans crack the Caeser Cipher. Everyone seemed to have a strong opinion on whether the method was induction or deduction that humans would use to experiment with various 2- and 3-letter word possibilities, as you do in my mother’s personal vice: the cryptogram.

As I pointed out, to much derisive laughter, it’s neither. The correct form of reasoning to use here is abduction. This kind of methodology is not as pure as its bother and sister, deduction and induction, as it can lead to incorrect results. However, this sort of reasoning is arguably the most visible in our modern society. In particular, mysteries and detective-work almost always begin with a great deal of abductive reasoning. A trick to remembering these is to walk through a scenario. Here’s one that I made up:

Sherlock Holmes went to his friends house for tea and found his friend laying in the entrance with a gash on his head and a bloody candlestick next to him; he was dead. Using abductive logic, he could guess that he was struck and killed by the candlestick. It is possible that he died some other way, and that may not even be his blood on the candlestick, but it is fairly reasonable to make that step. Based on this, he could could also use inductive reasoning to estimate that a human struck him (a fairly strong induction as Sherlock remembers only 1 in 200 beating victims that he’s seen attacked by an animal).

Sherlock then remembers that his friend’s will stated that ‘if I die, my butler will take over and own my estate’. Since the man is dead, the butler must own the estate. This fine bit of deductive reasoning tells Sherlock It’s probably a good idea for him to go talk to the butler.

The first piece of assigned reading in my graduate studies is a paper by Maconachy (et als) entitled “A Model for Information Assurance: An Integrated Approach”. It is the first of many I plan to be reading for the Enterprise Security Management class, which is a broadly scoped class dealing with security and policy from a managerial point of view. This latest sweep of courses follows the Information Assurance (IA) standard that is torching older concepts of computer and data security.

By and large, the paper is extremely simple (and quite short), but I’m not really aware of how influential this paper has been over the years. It was written in 2001, and I have been told that it’s the seminal piece of this entire movement…but that’s really hard for me to believe. Especially since the McCumber INFOSEC Model (the McCumber Cube) was published in 1991, and this paper basically just tosses that model into a “fourth dimension” and expands, a little ridiculously, the characteristics part of the model.

The contributions that I see to the model’s data characteristics are trivial distinctions in the terminology.  The new Information Assurance Model (a.k.a. McCumber Cube 2.0) merely splits the three Information Characteristics into five Security Services. Their main contention with the earlier work, I infer, was that the loose definition of data integrity was insufficient to outline what was really needed. Their addition of Authentication and Non-Repudiation may have merit, as Integrity of data is commonly used to measure immutability and structural continuity, but I don’t see it as necessary for those with a background in data integrity. I guess if everyone is reading something, it’s probably good that  CIO’s to hackers probably need to see the distinction between the data integrity itself and the integrity of the source and the retrieval process.

Regarding my statement on, and obnoxious quotation of, their “fourth dimension”, this paper added the additional, singularly organic concept of Time to this idea. Where most previous outlines have neglected this concept, I do see the point they make with the steady changes over time. My experience in this area isn’t immense so I don’t know if they’re singularly responsible for this idea, but the modeling of that idea is actually quite sound.

For me, this concept of adapting security over time is a lot like dropping a 12 gallon, cube-shaped water mass (in honor of McCumber) into an 8 gallon bucket with a hole in it. If you figure the water is about 6 feet up then there are a few reasons why a lot of the water isn’t going to make it into the bucket to begin with: it’s just not a perfect match. When it does hit the bucket there’s going to be a pretty large splash, and a lot of what was put in place will be thrown out right away. The last few phases are a sort of balancing until the surface water is still. Unfortunately, still water is the worst place to be and you’re never going to have a completely full bucket unless you’re measuring and adding slowly until you’ve balanced the flow of water coming in and the water draining out of that hole. This image is simplified, but it’s pretty apt.

It is important for me to point out that any negative perspective I have regarding this paper may not be for any other reason than because a perfect, albeit figurative, cube was converted into an elongated box which poses as a cube.  I’ve been known to commit worse acts of hostility, but I’m just all about cube-equality.

The biggest point that I share with people is that technology is the cutting edge, and the very tip of that edge is security. This is becoming validated on an ever increasing increment with the growth of cloud computing and high-availability, online systems. Not only do IA standards address this, but they also encourage the constant measurement and addition of water. Google, Amazon, and all the other big players need to have this technology and need to assess it with respect to time and progress. While this paper did bring out those concepts, I don’t know how much this was solidified beyond existing standards. But I’m not too worried about Google missing the boat on this.

The entire movement to IA is quite interesting to me, and I’m looking forward to getting more exposure in the coming months. Most of my closest colleagues know that I’m much more interested in policy than your normal CS-geek. Actually, I’m fully cognizant of the fact that policy makers hold all of the power and still get to see a lot of the fun. My ideal job would be working for a leading, technology-driven agency and pioneering/expanding policy while getting to sit in on disciplinary and review committees to observe impacts of changes being made. At least that’s what I see right now; this ESM class will probably make or break it for me.