The first lecture of my master’s program was my first policy/engineering class, and my world was rocked. I was probably galvanized by the seething hatred that my peers seemed to have for this brand of security. Dismissing the pariah complex, I had an abnormal draw toward it, and the people that I began to associate with only pushed me further in that direction. When I chose my first full-time position it was pretty clear where I would lean. Now I’ve programmed less than 100 lines of code in the last 3 months, and 95 of those were from personal projects.

Work is filled with partial glimpses into projects large enough to crush a human, and everyone struggles just to make sure their documentation doesn’t accidentally expand their scope commitment into a new circle of requirements-hell. Most of the higher-level minds just try to negotiate the nether-space between clients and managers, hoping that satisfying one of them doesn’t piss the other one off. Quality engineers are overworked, and project managers mumble unintelligibly to themselves while walking the fine line between hyper-tension and deadline slippage. Great ideas are hatched in unreserved conference rooms and laughed off or, if particularly reasonable, are stabbed to death by managers and customers during powerpoint briefings. The only people who get great things done are the ones who play the field better than Kasparov.

And it’s all fascinating.

The main()

The simple definition/purpose of the ‘main()’ method? It’s the starting point for every single Java application you’ll ever write, and this one and only main() makes up the entire life of the program. Once main() starts you’re program is running, and once it exits then your program dies. That’s all it does, really.

I’ll give you some background on the details here, hopefully to reduce the ‘magic’. In the “public static void” part the “public” is the signature that is required as a main() must be accessible to all interested invokers, ‘static’ signifies this method is always run in an identical environment with no worry about conflicting instances (read more on static elsewhere), and ‘void’ designates that there is no return type from the method. The args variable, or whatever you choose to name it, is the array of command line inputs that you specified beyond the name of the Java class. Easy, right?

The Constructor

Constructors are an entirely different beast: an object that is created in a runtime is created by explicit or implicit call to that object’s constructor, essentially establishing the working space for that object. You can have many different constructors, too, but only one can be called for each object that you create. The most common place you see this is in the “new Person()” call where the ‘new’ keyword indicates a new instance of this event, as created in the constructor call ‘Person()’. I know this is getting crazy, but just look at the following example.

public class Galaxy
{
public boolean isSpiral;
public boolean hasLife;
public Galaxy()
{
isSpiral = (Math.random() > 0.5); // 50-50 chance of being spiral
hasLife= (Math.random() > 0.99999999); // tiny chance of supporting life
}
public Galaxy(boolean isSpiralp)
{
isSpiral = isSpiralp; //Specified before creation, guaranteed to be what is requested
}
public Galaxy(boolean isSpiralp, boolean hasLifep)
{
this(isSpiralp); //Call other constructor
hasLife = hasLifep; //set life
}
}
class Universe
{
public static void main(String[] args)
{
Galaxy sagittariusDwarf = new Galaxy(false);
Galaxy milkyWay = new Galaxy(true,true);
Galaxy peacefulProgrammer = new Galaxy();
milkyWay = peacefulProgrammer;
}
}


In this example Galaxy cannot be started by itself, some other program with a main() method (if it’s an application) must actually create the object through the constructor. In this case, we find an example in the Universe class. The Universe ‘starts up’, creates a few galaxies (overwrites some lesser galaxies), and then flickers out and dies. I know it’s sad; pay attention!

The Galaxy object isn’t limited to being used only in the Universe class, but it’s just what we used here. Anything, in theory, could instantiate this galaxy object. I’ve met few girls with Eyes that seemed to instantiate a couple of Galaxy objects, but that’s another blog post.

Self-referential, complicating monkey-wrench.

Some situations call for main and constructor methods, and the constructor could be created inside the runtime. The reason for this is often that the object itself may be created within another program, or it could be something that stands alone. In the case of the universe example, it’s a theology question. If Universe is a class that can be independent of any other class and can suffice by it’s internal definition (a.k.a the programmer is an atheist), then you can just run Universe to create it’s own instance.

public class Universe
{
public static final int TOTAL_ATOMS_POWER_OF_TEN = 81;
public static final boolean IS_STRING_THEORY_LEGITIMATE = false;
public Sphere core;
public void Universe()
{
core = new Sphere(1,1);
for(int i = 0; i < TOTAL_ATOMS_POWER_OF_TEN; i++)
{
core.increaseDensity(10.0);
}
}
public void bang()
{
//code to cause bang
}
public static void main(String args)
{
Universe everything = new Universe();
everything.bang();
}
}

Now suppose the programmer isn't an atheist, then we've got a bit of a problem. We need somebody driving this crazy bus we call life; which will work out totally fine. In fact, not only can we create God, but we can make sure that he's got enough power to create more than one universe. Mix the following class into the Java file for the above and add water:
class God
{
public static final POWER_REQD_PER_UNIVERSE = 42;
private int power;
Vector multiverse;
public God()
{
multiverse = new Vector multiverse;
power = POWER_REQD_PER_UNIVERSE;
}
public void createUniverse()
{
power += POWER_REQD_PER_UNIVERSE;
Universe temp = new Universe();
temp.bang();
multiverse.add(temp);
}
public void getHaircut()
{
//code to get haircut
)
public static void main(String[] args)
{
God me = new God();
me.addUniverse();
me.addUniverse();
me.getHaircut();
}
}

The best thing about designing the original universe to allow for versatile, constructor-based invocation is that we didn't have to change the Universe object to allow for God to create a Universe. In this way we create Universe to be God-agnostic.

I can't believe I wrote an entire blog post just to get to tell that joke.

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.

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.

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.