In the course of my career I have been involved in a fair number of startups. I’ve had pretty good luck, and most of them have been successful. One, however, was a complete failure. I refer to that experience as my DIY MBA. You can learn more from failure than you can from success. It is very difficult to determine what made something succeed (apart of course from our genius, hard work, and moral virtue), but if we look at something long enough and with whatever objectivity we can muster, we can usually find a root cause for failure. If we’re smart, we won’t that make that particular mistake again.

One of my favorite books is Engineers of Dreams: Great Bridge Builders and the Spanning of America by Henry Petroski, the wonderful writer on engineering. It is a book about extraordinary success – the construction of the great bridges of America, but it is as much about failure as success. Bridges fall down throughout the book, but each failure shines light on another aspect of bridge design and the limits of the materials. The heroes (the great engineers) learn from their experience and continually build better and longer bridges. What I took from this book, beyond an appreciation of the bridge builder’s art, science, and mastery of the political (all big projects involve politics) is that that failure is something to be treasured once you get past the pain.

My one entrepreneurial failure was in a company that did desktop publishing around 1980. My partners and I bought two NBI 3000’s, very early, very expensive word processors. Businesses in and around Boulder, CO, some students and professors came to us with hand written drafts which we turned into beautiful printed documents. The machines were complicated, temperamental, and difficult to use, though they defined the state-of-the art at the time. Only trained operators could manage them. Word Processing was a task for pros.

Of course the company failed. Things went well for a year or so, but then the first practical PCs and word processing software came out. People began to do their own word processing, even on crude, small, expensive machines. When the IBM PC came out and legitimized PCs, everyone started writing on computers and doing their own desktop publishing. The stream of customers dried up and we closed the doors.

My first thought about Document Control (the company) was that our technology was simply made obsolete — that we were selling slide rules in the age of calculators. I think though, that we were really swept aside by a more fundamental imperative – the human urge to do things themselves. In the Pharaohs days literacy was regarded as something for specialists, and the leading classes hired scribes to perform that difficult task. When the telephone was invented we needed operators; when cars were invented they were often driven by mechanics. Over time in each case the difficult became simple and the rare became commonplace. For the things that count, people would rather do something themselves than have it done for them if it is within their ability and comfort zone.

This principle pertains as much in IT as in other arenas. IT was once entirely the province of the professionals operating in glass houses, who accepted data on cards from the acolytes and returned them manna in the form of green bar. It was inconceivable in those days that computing would become the province of the everyman but, of course, it has.

I am not referring to people using personal computers to access the Internet, using email, and writing newsletters for the PTA. That is really too obvious for comment. What I am referring to is the continuing trend in all sorts of organizations to empower the individual. Individuals prefer simple hosted applications like Saleforce.com to complex CRM from central IT and they use desktop tools like the Microsoft Office Suite to build very complex applications. The things they build are not tightly integrated like the applications built by professionals. Processes may still involve many manual steps that a pro could program in a few hours (after a week of committee and budgeting meetings, another week of design review, and two weeks or so of testing). We pros can do it better – complete automation, all sorts of bells and whistles the rubes would never think of, audit trails, better security, and all that good stuff, but the users prefer the stuff they build (or discover) themselves. It does what they want and they understand it. More than that, it empowers them. They feel in control. In the end, DIY always wins.

Going into word processing was not a mistake. The machines were great and they did things that simply weren’t previously possible. The mistake was in persisting even after the first personal computer showed up. The was on the wall, and it read that in the end, DIY always wins.

In building our enterprise applications we must be cognizant of this same imperative towards DIY. There will always be central IT applications for things like basic accounting – accounts payable, accounts receivable, etc., but organizations are dynamic – buying businesses and being bought in turn, reorganizing, opening and closing business lines, launching new products and dropping others, doing studies and projects. The central IT department is always running behind but the DIY community filling the gap with their jury-rigged lash ups. Giving the pros (i.e. us) a break, though, real IT is hard.

I know that this informal IT – the IT that takes place outside the purview of the IT organization – is already and important part of every business. I suspect that in many organizations these home grown applications may actually be as or more important than the official stuff. My wife who works in the accounting business, for example, is tracking the company’s backlog and progress in an Excel spreadsheet as the tax deadline approaches even though her company uses the best accounting software in the business.

As IT tools have improved, everyone has become a practitioner to some degree, just as our ancestors learned to drive cars and make calls and our ancient ancestors learned the arcane art of reading. A challenge for us as professionals is to give the non-professionals the tools they want and need so that they can define how they do their work, and then work with them, not against them, to improve these informal processes and bring them up to “professional grade.” DIY is a powerful imperative and much of the IT that we now regard as the realm of the professional will inevitably move into the hands of users. We should not resist this, but enable it. I would love to see what users could do if they could have a real-time access, with Excel as a front end, to a company’s core data in real time. What would they build? I know that they would build better tools for their personal work, but they might just go beyond that to provide new insights into the way the company operates and models for how the company’s processes can be improved.

Technorati Tags: diy, it

My wife recently made the comment about how it seems as though bad things come in threes. I thought it was an odd thought to see random events as coming in sets, but then again she also thinks that there are a finite number of good weather days in New England. But then I realized that there have been three occurrences that have set a course for part of my intellectual pursuits here at Cigital. These three events are completely un-related, but all evolve around the issue of security testing and how it seems like security testing should be the next technical pursuit for software test engineers.

The first event was at SD West. I went to hear Herbert (Hugh) Thompson talk about fuzzing. Hugh is a great speaker by the way and you should definitely hear his presentation about his escapades as a young teen fuzzing his high school’s soda (”pop” for all us midwesterners) machine. But, I digress… In any case, the question that came up at Hugh’s talk was whether security testing was the domain of developers or testers.

I’ve been doing some work with one of our clients about moving security testing into their testing organization. That’s the second of the three coincidences. Our client has realized that in order to implement the Software Security Touchpoints throughout their SDLC, that they need to train and empower their testing organization and not assume that the developers to write secure code. Good assumption.

The third is that Joe Jarzombek, Bob Martin and I were asked to give a talk on Software Security at the Boston Software Process Improvement Network (SPIN) and Software Quality Group for New England (SQGNE) meeting. The talk is on May 9th for anyone in the Boston area. My talk is titled “Software Security Testing - The Next Frontier”.

Does this mean security testing is a bad thing because it “comes in threes”?

I was starting to worry that it was after my wife told me about the “bad things come in threes” thing. Then, the other day one of my co-workers, Paco Hope, and I were talking. Turns out that he’d already started blogging about security testing and some of the challenges. He’s started with a couple of book reviews which provide some insight into the challenges. He and I started talking about and the relationship of Cigital’s Risk-based Security Testing methodology and other negative testing methodologies like equivalence classes. Paco’s definitely got some great ideas about how Software Security and Software testing relate.

So, there aren’t three incidents - there are actually four. Phew - because I really do believe that testing organizations are going to need to provide the security training, tools and resources to empower their test engineers. It also creates a natural, technical growth path for those engineers. Engineers progress from manual testing of features to being able to write test automation. Security testing requires even deeper technical knowledge than automation, so it’s a natural evolution to start getting underneath the constrained environment of traditional automation tools and start working on testing the security related aspects of the software.

So, Security Testing is definitely not a bad thing, since it doesn’t come in threes. Now, if I gotta start working on the weather in New England.

Technorati Tags: security testing, fuzzing

In my April darkreading column, “Want Turns to Need,??? I describe the state of the market for software security. I am very much optimistic about the software security space. In a few short years, we have created a space with a small ($250-275 million) but growing market niche. Last year, the tools market doubled in size, with services also showing very strong growth. Weighing in at about a quarter billion dollars, software security is a field that can no longer be ignored. As a field, we’ve successfully moved past philosophy and well into action. It’s a good time to make sure your firm is on board.

Back when I helped to invent software security in 1997 (after writing Java Security with Ed Felten from Princeton), there were zero books and only a few papers. That’s one of the reasons John Viega and I wrote Building Secure Software–we wanted to write something for software developers and architects interested in building security in. In the eight years since then, the field has blossomed. Today, an entire shelf full of books exists. Here’s a chronological list of eleven good ones (including three that I wrote):

• Building Secure Software (Viega and McGraw, 2001)
• Security Engineering (Anderson, 2001)
• Writing Secure Code (Howard and LeBlanc, 2002)
• How to Break Software Security (Whittaker and Thompson, 2003)
• Exploiting Software (Hoglund and McGraw, 2004)
• 19 Deadly Sins of Software Security (Howard, LeBlanc, and Viega, 2005)
• Software Security (McGraw, 2006)
• The Security Development Lifecycle (Howard and Lipner, 2006)
• The Art of Software Security Testing (Wysopl, et al., 2006)
• The Art of Software Security Assessment (Dowd, et al., 2006)
• Foundations of Security (Daswani, 2007)

Even with all of this progress, many people remain pessimistic about the space. Though the Yankee Group estimates that the entire market is between $250-275 million dollars, they state the case in pessimistic terms. I am much more optimistic about the growth of the field than Andrew Jaquith appears to be from the title of his report (though check out his excellent new book on security metrics!).

In my darkreading article, I describe why software security is transforming from a nice-to-have into a necessity. Many companies are trying to determine how to get started. The article goes on to describe software security tools (including badness-ometers and source code analysis tools. The combined market for these tools was between $90 and $100 million in 2006. I believe that the black box testing tools are driving demand for solutions that do more than identify the problem. Source code analysis tools are selling into this demand. This is great news for companies like Fortify and Ounce Labs.

Software security services are equal in tools to revenue, with numbers between $80 and $120 million in 2006. These services ran a large gamut, from simple minded penetration testing (usually wielding a black box testing tool) at one end, all the way through sophisticated enterprise initiatives at the other. In 2006, services surrounding more complete software security initiatives at the enterprise level came into vogue. These large scale initiatives include training for thousands of developers, the creation of enterprise-specific knowledge and guidance, and the integration of software security best practices (which I call the touchpoints) into the software development lifecycle. Cigital specializes in the strategic delivery of enterprise software security initiatives.

Check out the darkreading column for a list of ways to get started in software security. I briefly touch on:

• Using badness-ometers to make the problem apparent
• Hiring outside help to carry out deeper analysis of critical programs
• Introducing code review to the dev team
• Basic software security training

But by far, the most efficient way to approach software security is through a well planned enterprise software security initiative. We have several such initiatives underway at a number of our most important customers. This is no trivial undertaking, but it has always resulted in marked improvement for Cigital customers.

Software security is quickly becoming a business necessity. SOX and PCI compliance activities serve to help corporations better understand their software risk. Because the impact of software failure (maliciously caused or otherwise) is great, many corporations are already working dilligently on software security. The time has come for everyone to get started.

Technorati Tags: software security, essf, tools, services

Sammy aimed two recent entries at those attempting to govern security and expenditure in an organization. I’m using his posts as license to wax more philosophically. Specifically, I’m going to use Digital Rights Management (DRM) as a lightning rod for conversation about protecting data end-to-end in one’s system (the topic of my next–far more focused–post). I’ve been thinking about this ever since McGraw’s Dark Reading column: on Vista, and it’s driven me mad.

In posting this message, I’ll skirt more topics than I cover; I apologize. In return, I’ve included a lot of links worth reading. I don’t presume to answer the question, “Is DRM ever a good idea?” I believe most computer security folk simply answer “no,” bemused because in the end they know consumers MUST use protected data and algorithms in their full quality, to be satisfied. Some gifted albeit misguided security folk attempt to trade data quality for what they perceive to be security. Peter Gutmann’s working paper covers Microsoft’s attempts through Vista.

When I replied to Gary’s Dark Reading article, defending Apple’s DRM, I had purchased about $350 worth of music from iTunes. The standard caveats applied:

1. Apple could change their DRM scheme out from under consumers at any time
2. DRM still provides no value from the consumer’s perspective
3. DRM imposes limitations, potentially limiting competition between vendors

but I still found myself unable to come to any other conclusion but the mighty unpopular: Apple’s DRM seems a reasonable compromise between affording protection and remaining flexible to consumers. Remember, I said ‘unpopular’, so feel free to argue with me.

Now, $450 into the fray, something very interesting has happened: Apple and EMI have decided to sell some music electronically but DRM-free (see:
http://news.bbc.co.uk/2/hi/technology/6516189.stm ). Unprotected music will be encoded at 256KBps (twice the bit rate of Apple’s protected files) and will cost $1.29, rather than $0.99.

Now, consumers have an interesting choice to make: “Do I want to pay an extra $0.30 for the ability to copy the music I purchased freely?” Some may be willing to pay extra for the quality–but that’s not what we’re interested in right now.

In asking local “kids,” I’ve gotten consistent reply: “I’d only pay more if I liked the band.” Questioning them further immediately reveals they perceive the music to be free (and rightly so–it’s just too easy to pirate). They make their purchase/steal decision based on their feeling of loyalty towards the band. Can your business rely on such good will? I used to pay for single pieces of bulk candy at the grocery store–but I wouldn’t bet my business on others doing so. At the same age (prior to driving) I’d hack games’ copy protection, give copies to my friends and say, “Ok, but call me before you play it… to make sure only one of us is using it at a time.” Why am I only now explicitly aware they never called? Guess they never played it ;)

More fundamentally, will consumers perceive your product or service as being free? Think back to Windows ‘95… did anyone you know have a problem copying it?

An interesting question to ask one’s self is this: At what increase of price can I afford to protect my data less for the sake of other business drivers? Presumably, EMI has come to the conclusion that the answer, in their case, is $0.30. Interesting. If protected music accounts for only 2% of sales (dubious estimation by extrapolation of iPod size + sales compared to iTunes sales), how much does EMI expect that number to jump if the price has moved to $1.29? If physical sales still occur at $1.99 per single, how much less piracy does EMI expect from electronic sources as compared to physical ones? What does this even mean–given that pirated physical wares will almost immediately take the electronic form for ease of distribution?

Finally, what numbers could Apple put on the cost of developing and maintaining their DRM scheme? What affect does that price have on their profits (if any) in the case of EMI’s unprotected content versus that which is protected?

Part of me wonders if any of this will have even the slightest effect; given the ubiquity of the protected content, unlocked and freely available from peer-to-peer sites. If all’s for naught, is EMI making a good decision, or a mistake? God, I hope there’s no analog for that in your data.

I have no idea how successful Apple’s iTunes model will be, or whether or not consumers will accept Vista’s DRM, but with EMI’s decision to distribute unprotected music along side protected songs, those of us in security-land potentially gained data to look at. What will it tell us? And, while it’s very unlikely that you’re distributing electronic music, dear reader, or even passing content directly to end-consumers, EMI’s move should raise questions about how you’ve calculated the value of data, the protective mechanisms you’ve placed around it, and the impact on usability those protections imposed.

Technorati Tags: drm, apple, data security

I’d like to give a slightly different perspective on a topic John Steven talked about a few weeks ago (“Keeping up with the Jones’ Security Initiatives???).

Be a goose; don’t spend “10%??? just because it’s a popular number.

I spent the first four years of my career, in the early 1980s, in the Air Force. I worked as a systems programmer in the Pentagon and had direct responsibility for system security (Go Multics!). This was a timesharing mainframe with directly connected VT100 terminals in secure locations, so threat was fairly well understood. It was all about availability then, even though security was paramount. If the system was down, heads rolled. On the other hand, if some MLS control prevented the general from doing something he thought would be cool, well that was just tough. No one ever asked me, “Do we have the right level of security?”; it was always some question about specific vulnerabilities and how to remediate each one on a case-by-case basis. These were ducks.

As a defense contractor employee, I worked with dozens of classified and unclassified systems, some on the burgeoning Internet and some not. I performed virtually every kind of security review, pen test, IV&V, and tiger team you can imagine. No one ever asked me, “Do we have the right level of security?”; it was always some question about specific vulnerabilities and how to remediate each one on a case-by-case basis. These were ducks, too.

After 12 years in the commercial world, I’ve seen or worked with virtually every information security technology. And, although I gave up software development a long time ago and pen testing more recently, I still try to keep current. I’ve worked with hundred of organizations on thousands of security issues. In my experience, only in the last few years have some organizations begun to look past the individual assessment results and ask about their level of security and its overall appropriateness (first in financial services and later in other public companies). At last, a goose or two.

However, the vast majority are asking about it solely in relation to their peers. These organizations are not asking, “Do we have the right level of security????, they’re asking “Do we have about the same amount of security as everyone else, good or bad????

This is wrong thinking and here are two reasons why it bothers me.

The first is the large number of organizations that are insulted at the mere insinuation that I can “know them” even if I have years of experience and I’ve worked with other firms in their vertical, or even with other business units in the same company!

The second is that they’re right. You can’t really know a given organization just because you’ve worked with its competitors. I can understand implicitly the risk associated with their transaction processing systems, with their SOA framework, with their Internet-facing systems, with their overall approach to security, and so on. On the other hand, I really have to work with them to understand what drives them, what is the tone at the top, what decision will they make when push comes to shove, their risk appetite, where they will cut IT dollars first, whether they really are trying to act strategically as opposed to simply having a 3-year plan of tactical initiatives, and so on.

So, why would these organizations think that I can’t know them by working with their competitors, think they can know something about themselves by comparing furlongs per fortnight of security spending with their competitors?

Here’s are two admittedly loosely related stories:

I did my taxes a few weeks ago and was told by the application the percentage of tax-paying Americans who were “like me” in income and tax burden, with no real additional information. Were these families or single filers? Did we have similar kinds of deductions? Did we have the same cost of living? What did these comparisons mean? Duck or goose?

I went to my doctor recently and was told the percentage of Americans whose weight, cholesterol, and related items were similar to mine. Here, however, I was also told how each of these items factored into overall health. In gruesome detail, I was told about various mortality rates, stroke rates, heart attack rates, cancer rates, and so on until I simply wanted to nibble lettuce for lunch and stay out of the sun forever. But, still, did these other people have my heritage, my work and exercise habits, my eating habits, or anything else that made them like me? Again, duck or goose?

In the information security space, we’ve had (mostly by the analysts and the press) huge discussions about whether 10% of the total IT budget was the right amount to be spending on security. According to Forrester, that number has hovered in the 7.5%-9% range for the past few years. That’s good to know because it gives us a general guideline (which is all we can have in the absence of any real actuarial security failure data, but that’s a rant for another time). However, in multi-billion dollar corporations where a 1% difference in IT security spending could equal the annual revenue of many of small security firms, what does this percentage really mean? If one organization consistently spends significantly more than it’s competitors on hardware, data centers, and related IT items, should it necessarily also be spending more on IT security?

I realize these percentages are just guidelines, but they’re the kind of guideline a sharp litigator will latch on to. Remember that no one wants to be the odd man out. No organization wants to have to explain to some regulatory or law enforcement organization the possibly coincidental facts that it suffered a security breach and was also spending somewhat less on IT security than the average for their industry, or country, or whatever.

So, much like I am, I’m sure you’re wondering whether I have a point or whether I’m simply writing this at 4am because my allergies are kicking Claritin’s butt. My long-winded point is simple: We’re all the goose. Every single organization has its idiosyncrasies that make the 10% rule of thumb somewhat less than useful for anything other than selling research reports.

Organizations should spend as required to adjust risk to acceptable levels and realize that not all of that spending will be in IT security dollars. By and large, IT security doesn’t pay for governance, it doesn’t pay for attitude, it doesn’t pay for commitment for excellence. With these things being paid for elsewhere, the IT security budget may be lower and likely result in lower risk (i.e., improved “security???).

We shouldn’t dwell on the size of this ratio; we should worry about the environment in which it exists. A spend of 10% in an immature, ad hoc, no-vision company, probably means they’ve spent the entire 10% on point security solutions ranging from desktop AV to firewalls to IDS and so on. Which means they spent little or nothing on policy, training, proper tools for developers and testers, and so on. Which means they are an accident waiting to happen - 10% not withstanding.

On the other hand, a lower percentage spent within a mature organization that also spends to foster and reward good thinking will almost certainly produce lower risk. Sure, mistakes will still make it into production and there will be problems, but there will be much fewer of them, they will likely be of reduced consequence because the organization knew to look for the big problems and also had effective response capabilities, and the organization will learn and not make those mistakes again. They will make new mistakes, but everyone does.

Be a proud goose. Organizations must not be afraid to use good governance, good training, and good process to their corporate and competitive advantage. If you do good strategic things, you will achieve better security with a smaller capital outlay that doesn’t all come from IT security. Organizations must be comfortable with their risk management story, and their efficient spending, and be able to tell it to the market, to customers, to regulators, and, if necessary, to juries.

Technorati Tags: governance

Did you ever catch a box turtle when you were a kid? They are beautify, affable and interesting little fellows. If you see one, catching them is no problem. You just walk over and pick it up. Even though it has a razor sharp jaw, its instinct is not to bite, but to pull in it head and legs and hope for the best. In a little while, after it realized you are not some bad actor, it comes out of its shell and begins the slow, deliberate process of escape. By my experience, turtles are pretty patient. If there is a tasty bit of lettuce along the route, they are content to stop and eat if, even if you sitting a foot away. Still, when the lettuce is done, they will continue their escape AND THEY WILL SUCCEED.

Their astounding rate of success has always amazed me. Without fail, I as a child, and each of my children in their day would put a turtle down somewhere in the yard and then go about some game or chore. We would glance back at the turtle every few minutes noting its slow progress to the fence or bushes. When the turtle got close, we would haul it back to the center. Then, patiently, it would resume its long walk. We would catch them a few times, repeating the cycle, but finally we would turn around the turtle was gone.

There are two possible explanations for this. The one I would like to believe is that turtles are wonderfully canny creatures and fleet afoot, who consciously lull us into a false sense of security before they dash to the perimeter with lightning quickness. I would like to believe that because I rather like turtles and would quite enjoy the thought that they are clever as well a cute. The more likely explanation is that it is simply impossible for us to pay sufficient attention to events that unfold so slowly. Turtles almost live in an alternate universe, with a wholly different time constant.

I like writing about turtles, but this is an IT blog, so let me extend the parable to something related to computing. My discourse goes through San Francisco. San Francisco has a great rail system – Bay Area Rapid Transit or BART which is highly automated. Back in the later 1970s they had an interesting accident. BART trains are largely computer controlled, with human operators monitoring for safety. Trip after trip, day after day, year after year, the computers would sense that the train was reaching the end of the route, slow the train to a stop, and start off on the return trip. The operator would walk to the opposite end of the train to once again be at the front. The system worked very reliably, so the operator grew comfortable relying on the computer, and would start his trek through the train before it had actually come to stop. You can see where this is going – one day the train missed the end of line single and didn’t stop, and the operator, who could have saved the day, was not at the controls.

There is a common lesson in the cases of the turtle and the BART train. Human beings cannot catch rare events. We simply cannot maintain the concentration. It is bad design to build a system where the human backs up the computer. The human WILL be day dreaming when things go wrong. It is better design to keep the human active and in the loop, literally running things or at least sharing responsibility, even when the computer can probably do it better. When the human fails (and he will) the computer will be there to back him up. A human and computer together can provide system redundancy, but only if the human is at the forefront and the computer as the backup.

Clearly we shouldn’t get carried away with this principle. We don’t want an accounting system where the math is done by hand with the computer checking the addition. In design of real time systems, though, this is a very important principle. It surfaced last week in a trading system I was reviewing. The system is used for large block trading (BIG deals). In my tests I found that you can enter an asking price that makes no sense (transposed digits or a shifted decimal point, for example). As I said, these are big deals, so you have to confirm the price before the deal closes, but you confirm not by entering the price twice, but by simply clicking “confirm.” In the heat of an active trading day, the traders who are very confident individuals will certainly hit confirm automatically, without actually reading the data. Ninety-nine percent of the time, this is not a problem.

Lest you think this sort of design problem is rare, you can trace the wreck of the Exxon Valdez and the navigational error that led to the shooting down of Korean Air Lines Flight 007 over the Kamchatka Peninsula to precisely the same human factors problem – using people to back up computers, not the other way around. The key message here is that when we design and test a system, we must focus on the whole system performs people included, not just the software.

When jOHN first accused me of being Captain Technology Curmudgeon, I was a little peeved because I’ve been of the opinion that its more how to make Ajax secure and not if it can be made to be secure. How can THAT stance be curmudgeonly? It was Gary that took the stance that Ajax is to be avoided.

So, I set about writing a talk for SD West about how to write Ajax applications that aren’t insecure (I do hate double negatives, but with security one can never really state that something IS secure). I based my talk on work I’d done with our client, research from the Web and my own experience writing Ajax.

At first, things seemed pretty encouraging. Ajax seemed to heighten the existing problems on the web. For example, there was the problem of good, API design for all of the additional services and the associated need for solid input validation and output encoding (albeit encoding for XML and JSON instead of XML). This all seemed pretty tractable because there are known solutions even if those solutions may not be wide practiced yet.

I should have sensed that the party was starting to end when I ran across “dynamic script tags”. I’m not sure why they are called “dynamic script tags” and why they aren’t called “subverting the JavaScript sandbox”. Here’s the deal. Say, I want to “mashup” content from two sites. Tres Web2.0. But the XMLHTTPRequest object limits me to downloading content from a site other than the one that supplied the calling JavaScript. So, instead of doing something more secure like doing the mashup on the server, why not just use an HTML tag that isn’t restricted by the same JavaScript sandbox rules.

In my younger days, I would have said “Nice hack”. Now, I just shudder because this subversion of the JavaScript sandbox is being promulgated on the Web as a feature instead of the rude flaw that it exploits. Okay, so this is slightly curmudgeonly…

I then found a paper by Stefano Di Paola and Georgio Fedon that described an attack called Prototype Hijacking. Now, “Prototype” isn’t in reference to the popular JavaScript framework - it’s in reference to the fact that JavaScript uses prototype-based inheritance rather than class-based inheritance. Due to the dynamic nature of JavaScript, I can change the prototype for any JavaScript object. Most excellent. Let’s change the prototype of, say XMLHTTPRequest. Maybe the “Send” method?

So, securing Ajax applications is going to be harder than I thought. I’m not sure how to prevent Prototype Hijacking - well not yet at least. So, jOHN, how can THAT be curmudgeonly?

Technorati Tags: AJAX, AJAJ

(with apologies for complete lack of artistic merit)

feng shui governance
plan, influence, and conduct
policy for all

from boardroom to bits
everyone get on board
a single train forward

a balanced approach
harmonious existence
with stakeholders all

set tone at the top
the key of transparency
all must understand

solving all problems
a terrible goal to bear
just cut barriers

how to change things now
like escape from klein bottle
reverse of trip in

business objectives
publicly painted for all
now all can align

our key resources
named, owned, prioritized, staffed
requirements sketched

cooperation
embrace management’s vision
collaboration

internal control
believable proof for all
this is a good thing

need innovation
old way causes much sadness
delightful change now

who must get what done
true responsibility
good authority

what must get done when
relate business to people
and goal them quite well

when must it get done
everything can’t be first
true order defined

where does it happen
are all things prepared for it
measure twice, cut once

how to accomplish
training, coaching, mentoring
lead by example

why is it crucial
all must recite the drivers
to you and to me

it’s about people
enable them to succeed
show you care about them

expect and inspect
balanced scorecard works for most
dashboards are fun, too

you are not there yet
a continuous journey
goals ever-changing

quite learned you are
required knowledge deep inside
express yourself now

P.S. Although I though I was the first to use “feng shui governance” as a term, I noticed that there was a single hit in Google (a three-word GoogleWhack!) used by a Mr. Foldvary back in 1999 in a somewhat different context.

Technorati Tags: governance, doggerel

I was part of a panel at a university recently speaking to prospective computer science students. The panel members were from industry — a few of the biggest companies and few smaller ones. We each had ten minutes to speak before QA, so I stripped my talk down to two simple points. The first point was that IT is fun. We truly build amazing things. I’ve been in the business 35 years, and I have never been bored. Each day offers a new challenge. The other point was that there will be plenty of jobs for decades to come just trying to get things right. Software sucks. No product on the market has more defects than software and no projects have a failure rate close to that of IT development work.

The next generation can live off the argument that they can certainly do better than the fogies doing the work now. The challenge for them, as it was for us we made the same claim, is living up to the bold promises. I have been through five distinct new approaches to building software, each designed to deliver better products and better delivery management. Each has moved the ball forward a bit, but we still have a LONG way to go.

Just how bad are we? There are many studies of failure in IT, but the results are all over the place. The most optimistic estimate I can find says that about 30% of projects fail. When I mention that number, a fair number of people tell me it is too low, but let’s grant ourselves the benefit of the doubt. We fail 30% of the time.

How does that compare to other industries? Before we take on the masters of quality lets start with an easier opponent – how about used car salesmen? Every year in United States, about 45 million used cars are sold. The Feds estimate that the odometers of about 450,000 of these have been tampered with, and that in another 500,000 cases the seller fails to disclose a serious known defect. That works out to a failure rate around 2%.

We in the IT business are 15 times worse than used-car salesmen. Yet, the demand for our products and services is tremendous. IT related professions dominate the top-20 positions on the US Department of Labor’s list of high-growth jobs. Why is this so, if our products are so bad?

The answer is that software, bugs and all, delivers real value. We would love our programs to work without error, to never crash, to never need patching, but even with these sorts of problems, software does amazing things. Once in awhile we all encounter a program that makes us go wow. Remember the first time you used online mapping? That was a wow, but we quickly get bored. The amazing becomes commonplace — part of the wallpaper. That’s sad. I wish it was possible to flip a switch, and show ourselves and the world juts how far we’ve come. It would be a cruder, poorer, and much more boring world without us.

That said, software is still crap – amazing crap so customers will continue buying, but crap nonetheless and we owe them better. The challenge of making software better is a difficult one. All of the Justice League blog entries are, at root, about this one subject. Sometimes we write about broad issues other times about the very specific, but our objective is always to make software better. Better functionality, more reliable, and more secure.

This blog, rather than being about solutions, is about the intriguing, challenging, and sometimes frustrating dichotomy of software, it is both amazing, with a capacity to dazzle and inspire while it is also mundane – just a bit of bug ridden code. The Roman God Janus has two faces – one facing forward, one backward.

Building software is much the same. We constantly envision the future and it drives us to imagine and to realize that imagination we build ever more complicated systems. There is the rub. The other face of Janus looks back to the past. In IT that is the hard job of not making the software, but making it good. Janus was the god of doorways, a wonderful image for IT. The doorway to the future in IT rests on equal measure on vision and quality, looking forward to what can be done and backwards at what we have. We must aspire to be Janus.

A final observation that will set the stage for a future blog entry. Our troubles lie in the imbalance between the forward looking face and the backward. There is so much potential in software that we are constantly reaching farther; farther in some cases than we can deliver. It is the reaching that gets us unto trouble, but it also the reaching that keeps us energized and fresh, and once in while makes our customers say “Wow.”

“We have long had death and taxes as the two standards of inevitability. But there are those who believe that death is the preferable of the two. ‘At least,’ as one man said, ‘there’s one advantage about death; it doesn’t get worse every time Congress meets.’”

~Erwin N. Griswold

Just look at them grow… they’re like weeds. Unfortunately, in this case it’s not a compliment for your sibling’s kids. This particular growth is in the data breach lists at Privacy Rights Clearinghouse, Attrition, PogoWasRight, and others. (And please accept my thanks for the time you all put into this public service; I apologize for not including you all by name.)

I have no doubt these disclosures represent the tip of the proverbial iceberg of data that have actually left the control of those to which it has been entrusted. I also have no doubt that we’ve been given this glimpse into the shoddy treatment afforded many of our most intimate personal details solely through some forward-looking state legislation (thanks, California, for helping to start a good thing in the U.S.).

Let’s just jump ahead of all this piecemeal personal information loss for a minute. (Did the WABAC machine have a “forward??? lever?) Let’s declare it not only inevitable, but also unavoidable, that, for each and every adult American, their name, social security number, top one or two credit card numbers, street address, date of birth, brief genealogy, and a few other interesting data items are known, collated, and cross-referenced.

But, not by legitimate companies like Experian, TRW, and Equifax. Let’s assume that individuals and groups who do not have our best interests at heart have all of these bits of information correctly assembled into mini-virtual-self-referentially-consistent identities, even if they have no “real life” information on the actual person (e.g., photo, current job, salary, type of vehicle, where your kids go to school, etc.). And, let’s assume they have the ability to keep this information current enough to meet their goals of acceptable cash flow for acceptable risk.

[Aside: Is this feasible? How many databases would I have to subvert in order to get most of this information? One at the IRS, one at a credit agency, one each at a few major banks, and maybe a few others? Remember, I don’t actually have to hack in, I can use social engineering, pay someone, coerce someone, steal the back-up tapes, and so on, and on, and on.]

What then? Is it the collapse of American civilization? I doubt it, but I think it would certainly accelerate some good things and some bad things.

The good things might include something like two-factor credit card use at all times (e.g., you have to show a [new government issue?] driver’s license for all card present credit/debit card transactions). But, what would have to change to allow card-not-present credit card transactions to continue to happen (e.g., most Internet orders, catalog phone orders, Chinese food orders, etc.)? What would it take for Americans to embrace single-use credit card numbers, for example? What parts of the infrastructure would have to change? How would we get and carry around these numbers? And so on.

The bad things might include a new state or national ID that would be required by the credit card companies in order to get a “secure” (whatever that would mean) credit card and a lot of high-end establishments that would start accepting only “VMCAMEXD Secure” for transactions over certain dollar limits or that meet certain risk profiles (e.g., buying for delivery to another country). A treaty with foreign countries could require that “secure” credit cards are the only ones accepted in some situations (e.g., buying a one-way plane ticket to the U.S.).

Beyond that, what would have to change at the IRS now that all SSNs are “public”? What about elsewhere in the Federal government? What would this mean to the Privacy Act? And so on. The mind reels, but it still feels like a good thought exercise.

For me, the question is not “What happens if someone else knows all the data associated with me?” The question is “What financially and socially acceptable capability will make it such that I can unequivocally prove that I’m the only me that goes along with my (now public) mini-identity data (e.g., credit card numbers, social security number, address, genealogy, etc.)?” And, in terms of requirements creep, I’d also like to be able to prove it without giving away my actual identity.

Thoughts? I hate to take you this far and not have something to offer, but I feel qualified only in asking the question, not in postulating an answer. And, of course, my follow-up question is “How are we going to make that software better than the software we have now????

Technorati Tags: data security, privacy