Salutations, earthlings. I rarely take the time to appreciate amazing services that I take advantage of today. One such service, Akismet, allows me to serve up content free from comment spam and malware links.

In the last 4 months, Akismet has blocked 6,402 nasty comments from view, all without a single wasted minute of review or annoyance. But you’re probably saddened by what you’re missing.

Some of it is just goofy. I’d probably click on it if it wasn’t clearly designed for me to do so.

Affiliate

Do Asians throw hamburgers at their weddings since American’s throw rice at theirs?

Pandering to my ego is a fantastic way to get by my sensors, but Akismet doesn’t seem to have that vulnerability.

Singapore Man

I have been reading this blog for quite sometime now, and this is my first comment. I would like to tell you that I enjoy reading this blog, and that I love thought provoking articles like this! (Sounds pretty good, until you realize I was talking about the NuWave Oven. Chicken breast is many things, but not thought provoking.)

get rid of acne scars

You are soooo gifted in writing. God is truly utilizing you in miraculous ways. You’re doing a great job! This was an awesome weblog! (Yes, I think God is utilizing me, but I must confess I haven’t done enough to spread the gospel of acne scar removal)

Chethasse

I do think this is a most incredible website for proclaiming great wonders of Our God! (Again, you’re right. Unfortunately in this article about Information Assurance…I guess I don’t know who ‘Our God’ is. Bruce Scheier? Yeah, and I bet Chethasse is one of Bruce’s aliases, that jerk.)

To be honest, I’m rather shocked by how much “Our God” and “the Work of the Lord” I saw in the comments. It makes sense, I suppose, as more and more churches are creating websites, and there are even more ad-hoc blogs being set up by Christians and other religious groups. The cool thing, for hackers, is that these groups are usually motivated by the thought of “doing good” in the world and rarely have the technical expertise to manage patching or installing addons to block spam. Spammers can be pretty clever about picking the low-hanging fruit.

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.

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.

My developer friend, Scott Sloan, has been working on his DB class for some time now and it’s quite a useful tool for doing queries simply. Part of the ongoing movement, between him and myself, is designing a rock-solid set of framework classes that will aid in rapid PHP development. Of course, his project has some stuff to show for it while mine are still awaiting a beta release. But I really do love this class and others from Scott, and I use them in Droplet and contribute as I find need to break them.

The most recent change to this DB class was the addition of exception based error handling, making database connections an entirely simpler creature to deal with. This class does a lot of abstraction, and up until now it’s been virtually impossible to debug it, or any db interactions, without stack traces. Unfortunately, every silver lining comes with a dark cloud.

This cloud, not dealing with Scott, happens to be PHP’s development traditions. Just like most functionality, exceptions are good, maybe even necessary, but the implementation of them was very poor from a security perspective. The fact that you can’t disable the printing of the stack trace from an uncaught exception is inexcusable at best. But I can guess how that conversation went:

-Should we have an option to disable stack printing (specifically of method parameter values) for select Exceptions?
-Why?
-Well, maybe they wouldn’t want the end user to see what was passed in a particular method?
-But you just catch the exception!
-But what if you don’t catch the exception? They see everything!
-Are you suggesting that we write code to protect programmers who are breaking rules? Plus, all production servers have warnings/errors disabled for output, unless their people are idiots.
-Oh….I suppose you’re right.

Here’s my beef: you need to plan on some mistakes. No offense, but haven’t you ever forgotten to catch an exception? Since this is a scripting language, you don’t have the parental compile time warnings or blocks, like Java, to say “Yo, you didn’t tell me to do anything when this code freaks, and believe me it can. Fix yo’ code, homes.” (I assume that a PHP compiler would use a similar compile error vernacular). The reality is that there are many production systems that don’t hide warnings/errors, and even if they did you wouldn’t want password information getting written to a log file whenever you fail to connect to a database.

The key here is a “who needs to know” system, just like I talked about in my blog entry about keys. There should never, ever, ever,ever,ever be a way for the language to “accidentally” print a system password to a user. Even if the developer is a complete idiot! If he passes a password or hash into a function,  he’s not going to think about what would happen if that function would error. He’ll fix that when it happens. It probably sounds like I’m defending the Cro-Magnon programmers of the world, but I’m not…..really.

An even worse PHP prospect is the ability to dump a class with private class values onto a page with one motion (i.e. var_dump). I know that these are all helpful tools in debugging, and that private variables were never meant to be a security constraint in this fashion, but the way they did it DOESN’T MAKE SENSE!! That function should not, I repeat ‘NOT’, be able to print private access variables unless there are appropriate accessor functions. That’s what object oriented design is all about.

I wouldn’t be so hard on PHP if it weren’t for the fact that these examples are the ones that give PHP a bad name. When someone’s data gets stolen on a PHP site it isn’t that PHP is a bad language, it’s that the programmer wasn’t thinking about that specific hole. But there are a lot of spots where developers can not know the rules, or forget a step and accidentally release loads of information to an eager hacker. As part of the group defining how the tool gets made, we need to be careful that the tool doesn’t have a cigar cutter that’s big enough for our “baby developers” to fit their arms in.

Anyways, code smarter not harder!