Emergent Chaos

5754463f

The ACM has a list of classic computer science works put together based on responses to a survey of the membership.

I'm no computer scientist (though I've lived with my share...) but I'm shocked that none of Knuth's works is on this list, even if it is basically a beauty contest.

Security Metric?

Ross Anderson has made PDF versions of several chapters of his Security Engineering (second edition) available on-line. The entire first edition has been available for some time.

I am sure this second edition will be outstanding. I would rank the first edition as one of the top three technical books I've read. It would likely be number one. I have high expectations for the second edition, stemming in large part from the author's academic discipline.

How many security titles have a 104 page bibliography?

Programming World Going to Hell Because of Java and Grace Hopper

Ekinoderm writes in "Who did Kill the Software Engineer?" that schools today are ruining software engineering by teaching people Java. He references Joel Spolsky's rant on the same.

I agree completely, except neither went far enough!

Java is just the replacement for Pascal, a pedagogical language designed because it was more fun and understandable than FORTRAN. So was BASIC, and APL. Heck, C is really just PDP-11 assembler code for people who can’t allocate stack variables by hand. Come on, it's just subtraction! Oh, and don’t get me started about how RATFOR screwed people up my making them not compute the gotos in their IF statements.

However, I have to sneer at their examples in Scheme. Scheme! That's also part of the problem. Scheme is a dumbed-down version of MACLISP for people who can't handle a real LISP, for Pete's sake! They should be doing their work in that, if not MDL or LISP 1.5.

The world has already gone to hell in a handbasket because of this continued coddling of the next generation of software engineers. Engineers need to learn how to twist transistors together to make flip-flops and make adders out of discrete components before they should go write computer programs. So-called high-level languages have been ruining the competitiveness of America since the mid 1950s!

Let's face it, when Jim Backus started on FORTRAN, that was compounding on the mistakes that Grace Hopper started with AUTOCODER, which made it so that you could use so-called "opcodes" in your machine language instead of typing in the binary, and worse, far worse to have macros. Macros make people fat and lazy. Transfats and sugar only make it worse. They stereotype of programmers being fat and unkempt is a product of macros, transfats and sugar over time.

Since I now realize that it's actually all the Commodore's fault, I'm going to throw away my nanosecond. Her use of tools that help people understand has ruined computer science. I also promise never to write another line of COBOL.

Photo Grace Hopper's nanosecond courtesy of Shiny Things.

Evolve or Die

Or at least become more vulnerable. I've recently been helping a client with their secure coding initiative and as a result I've been reading Mike Howard and Dave LeBlanc's Writing Secure Code which reminded me of an important aspect of maintaining a secure code base which often gets overlooked: That is that as code ages it becomes insecure.

This is most readily apparent with web applications, but is true for any code base. I've worked with several clients who brought in organizations such as @stake, ISS, isec partners, etc several years ago for an assessment and then addressed all the found problems. Time goes by and customers using applications like NT Objectives and Watchfire start sending in bug reports. So the client calls me up and says something like: "What happened, those security guys we hired years ago must have been crappy, suddenly customers are calling up claiming we are insecure! How can that be? We haven't changed the code in those modules in ages!"

The explanation is pretty straight forward. The state of the art of finding vulnerabilities has moved forward and the clients' controls for dealing with vulnerabilities has stayed the same. As a result, the source code has naturally regressed and become more vulnerable over time, much like a piece of machinery wears out over time. We like to say that old, well understood, well tested code is far better than new code and while in general I'm inclined to agree, one needs to remember, that well tested means adjusting the tests to keep up with the advancement of vulnerabilities.

While this regression is inevitable there are some things that can be done to slow it down. Most notably, practices that reduce the attack surface as much as possible by implementing applications with least necessary privilege and the other security principles of Saltzer and Schroeder. Similarly designing filters to permit acceptable data as opposed to attempting to enumerate bad behavior will also get you a long way in the right direction, but in the end, you have to just keep on testing.

Weak Crypto Contest

The 2007 Underhanded C Contest has a marvelous theme -- weak crypto.

The object of this year’s contest: write a short, simple C program that encrypts/decrypts a file, given a password on the command line. Don’t implement your own cipher, but use a bog-standard strong cipher from a widely available library.

[...]

Your challenge: write the code so that some small fraction of the time (between 1% and 0.01% of files, on average) the encrypted file is weak and can be cracked by an adversary without the password. The poorly encrypted file must still decrypt properly by your own software.

Other great comments:

Short programs are innocent, and more impressive. If your source file is over 200 lines, you are not likely to win. You can hide a semi truck in 300 lines of C.

[...]

Of course, there are other factors: we award points for humor value and irony. I have always been impressed with the winner of the 2004 Obfuscated V contest, who concealed an error in a vote-counting program by adding a voter-verifiable paper trail function that overflowed a buffer. That’s evil with style.

What a great idea.

Backus Having Drinks with Hopper

John Backus, leader of the Fortran team has died at the age of 82, according to The New York Times. Fortran itself celebrates its fiftieth birthday this year, and you can still write it in any other language, even Haskell. Even Lisp.

Back in the days when I would rather have died than work for IBM, in part because of their dress code, but also in part because of their dress code, but also because of the influence that Ted Nelson had on me, I remember being impressed with Backus's way of flouting form. IBM employees were required to wear suits; Backus always wore a denim suit. I remember the picture of him in the newspaper. It's a little thing, but it meant a lot to me. I'm glad that the photo I found of him on IBM's site has him in denim, and glad that I can explain why dressing in denim was at one time radical.

I also think it important that even the NYT today wrote "Fortran" and not "FORTRAN." Writing it as a proper noun and not an acronym was an annoying eccentricity of mine in those days as well.

TRUSTing Mary Ann Davidson

Yesterday, Mary Ann Davidson had a fascinating post about the classics of Western literature. As usual for Mary Ann, the apparent basis of the post is really just exposition for her main point. In this case, the thrust of her post is the need for developers to have more training in secure coding at the university level. Mary Ann and several others have started working with several universities (including UC Berkeley, Stanford and CMU) and corporations (including GE, Sun and Visa) to produce such a curriculum. They are calling this program "The Team for Research in Ubiquitous Secure Technology" or TRUST and have bunch of resources and information online.

[Edit: Gunnar Peterson over at 1 Raindrop points out that: Ken Van Wyk and John Steven have an article "Essential Factors for Successful Software Security Awareness Training" in the current issue of IEEE Security and Privacy, that is also relevant to the general issue.]

On Requirements

Roger Cauvin has some really interesting points on "Requirements and Apple's "Time Machine":"

CRUD requirements assume that users actually want to create, update, and delete information. But users don't really want to create, update, and delete information. They want to access it to achieve some larger goal. Enabling the user to create, update, and delete information is one way to manage and make the information available, but it is by no means a utopian design.

Remember Gmail and the 'delete' button? Why on Earth would anyone want to delete e-mail? Notwithstanding some privacy concerns and obsessive-compulsive issues, what users really want is to be able to find, read, and respond to messages of interest. Deleting e-mail helps eliminate clutter that can interfere with these goals, but it's not an end in itself. Thus it is not a requirement.

Similarly, conventional requirements documentation for a backup service would include specifications such as:

The system shall enable the user to backup files.

..

Yet these specifications and use cases do not represent real requirements. No user wants to backup files. They want to be able to restore files. Backing up the files is an unfortunate design necessity to which the user would prefer to be completely oblivious.

So first, this is great. (I'm tempted to talk about writing requirements, or software testing in the same vein: No one wants to do them, but we do them.*) Still, there was something wrong, and I wasn't quite comfortable with what Cauvin wrote. I've held a job in which creating backups seemed important. It absorbed lots of my time. Really, the important bit was verifying the backups existed, were safely offsite, and could be restored.

No, actually the problem is that there are times when being oblivious to what your system is doing is wrong. There are times when I want to destroy data. They may be rare, but let's take my 8 year old tax docs. I'd like to destroy them. They serve only to carry risk. Last I checked, TurboTax didn't allow me to not enter a SSN. So if I used TurboTax, I'd have this file which I wanted to destroy. Now, how does Secure Empty Trash interact with Time Machine? Do I have t remember the feature exists, and then search out old revisions of the file?

Or at gmail. An old boss recently mailed me a grant proposal. (Wrong Adam.) I deleted it without reading the proposal. I bet it was really juicy stuff, and I'm glad my email wasn't going through gmail where I can't delete the email.

So, overall, I agree. The CRUD method of thinking about requirements is a useful exercise in completeness of functional specification. It's not a good requirements method. At the same time, feature interaction can lead to surprising places.

* That's not quite true, I know people who test things for the sheer joy of seeing how they're made. Lots of them are vulnerability researchers, some are other forms of testers.

Cauvin link via Anton Chuvakin, sign photo from "Bilder aus Swieqi."

[Update: Don't miss the insightful comment about ways to address transparent backup and security from Simson Garfinkel.]