Well, sure, it's _easy_ to look at black hole projects after they died a flaming death and say that hey, that was an awful black hole project.[Eric Lipert]What's _hard_ is identifying which are going to be the flaming-death black hole products and which are actually going to be the successful "fundamental change" products.
People are complaining about bad security and are coming up with various recipes for fixing the situation ranging from using new widgets to setting and enforcing policies to educating developers to my favourite 'comprehensive approach'. Unfortunately, the suggestions, although helpful in theory, have a zero chance practice, for the simple reason that they ignore realities of delivering software projects.
In ideal world, people would have the right skills, deadlines would be realistic and staffing appropriate. In reality many projects are understaffed, people skills and experience is not infinite, deadlines challenging to unrealistic and technology fiendishly complex. If there ever was a hope to fix that, organisational politics, dynamics of market competitiveness, external crises and a host of other factors [Yourdon, 2003] ensures us that these realities will remain.
So the question of 'how not to have poor security' should really be rephrased into 'how to have acceptable security, which would be improvable, considering human fallibility and imperfection of the software delivery process'.
An excellent article with tips on how to escape the ivory tower, which we sometimes finding ourselves in as security professionals. Shame I almost haven't got through the new annoying Information Security Magazine registration pages...
In reaction to being involved in a large project with a number of sometimes eye-opening, sometimes tragi-comic experiences with formal design methods I have been toying about writing a sort of Against Method article. In the meantime, I have come across several quotes that actually prove that it is really hard write anything without reinventing the wheel.
Katie Lucas writes:
Every methodology I've come across has, at its kernel, a very small section labelled "do magic here". [...] it's like having a methodology for running the 100m[:] "Step 1: write about running really fast. Step 2: Go and draw a plan of the racetrack. Step 3: go and buy really tight lycra shorts. Step 4: run really, really, really fast. Step 5: cross line first" It's that step 4 that's the tough one. But if you put lots of emphasis on 1,2,3 and 5 it's possible no-one will notice.
Meanwhile, Grady Booch has a different explanation of the 'magic':
The difficulty of design, therefore, lies in choosing which design and architectural patterns we should use to best balance the technical, economical, business, political, and emotional forces that swirl around every software-intensive system.
Alan Mather quoting Sun's Jonathan Schwartz:
5. Web services may collapse under its own weight.
No one at the conference said this. Those are my words. I'm beginning to feel that all the disparate web service specs and fragmented standards activities are way out of control. Want proof? Ask one of your IT folks to define web services. Ask two others. They won't match. We asked folks around the room - it was pretty grim. It's either got to be simplified, or radically rethought.
... and adding a comment of his own:
(For the last couple of years I've listened to folks in government talk up web services and only a few diss them, notably the chief wizard on Gateway, Simon, who always said that web services were going to be more pain than good for a long time. As far as I know, the Government Gateway was one of the first web services to be made available anywhere in the public sector, anywhere in the world, but that doesn't mean it was easy - and it was never clear how government would scale to 100s of web services offering 1000s of discrete operations. We could all see a scenario where, just like websites, there would be too many web services doing too little for too few people, but consuming vast amounts of money all the same.Folks seem to have moved on from web services though and now talk about Service Oriented Architectures - something I understand even less and worry about even more. We know, from history, that whenever the technology industry needs to sell us more stuff, they change the paradigm and start inventing new words that us buyers have to translate and figure out and, ultimately, spend money on.
It's been a neat trick for years and it looks like it's being tried again. But maybe Jonathan is calling "uncle" on this one. There's no money to be made here until it gets simpler to design, build, implement and *especially* secure and operate them.