Will Security Task Force Affect OSS Acceptance? 224
An anonymous reader writes "An interesting article published by SD Times: "Application Security Goes National" discusses some of the talking points generated by a federal task force that will make recommendations to the Department of Homeland Security. One of these talking points is to license software developers and make them accountable for security breaches. Licensed developers would get paid more as well. The article also mentions that "Executives" might not wish to work with smaller undiciplined partners and a little further down that "Hobbyists create Web services [and] professionals create them" and that "companies relying on critical infrastructure Web services need confidence". Would OSS have to be writen entirely by licensed developers to be considered secure? . Yahoo Finance has another article on the subject." The SD Times article is current, despite the incorrect date on it.
Only as secure as platform... (Score:5, Insightful)
Do they not get it? (Score:5, Insightful)
I'm not following their train of thought. Software development is an industry which constantly has to defend itself from **NEW** hack attacks. The best we can do is protect ourselves from known attacks, and try our best to forsee future ones.
It puts yet another industry under undo government control, and yet against shifts the focus away from the people actually doing harm--the hackers.
Re:Do they not get it? (Score:5, Insightful)
How about driver's licenses? (Score:5, Insightful)
Similarly, the licensing scheme will again create a dearth of licened software professionals,leading to high salaries for the licensed initially and then the bubble will burst. Everyone will have a license eventually, and we will be back to square one. So, the solution is to come up with better error prevention and correction methods for existing software professionals/ (drivers) rather than try to create licensed professionals. SO, as of now OSS still rocks and it will be good to see more OSS testing volunteers rather than just OSS developers.
Re:Do they not get it? (Score:5, Insightful)
It's my understanding that there are procedures for developing and testing software that is used in medical products and aviation products. Perhaps the rigor that is applied to developing software to control an airplane could be applied to the development and testing of secure software.
Pointing Fingers (Score:5, Insightful)
With OSS there is no "someone". With a licenced developer you have someone to blame.
Paraphrase of John Milton (Score:5, Insightful)
How much would licensing developers much like doctors, lawyers, architects, etc. affect development? It would likely mean more than, say, an MCSE or RHCE, or NCE. Would developers need to be licensed for a specialty?
Most likely there would be some sort of age and education requirement which would prevent some of the younger and perhaps self-taught developers from contributing to certain projects. Also, what about code developed outside the USA? One would have to be rather naive to assume that all the software in use was written in the USA, but sadly, I think that perception is all too common.
Happy 2004, everyone!
- Nate >>
Re:Do they not get it? (Score:5, Insightful)
You have missed the point, nobody on the committee cares about improving security. The worse it is the more money they make. Only MS (and perhaps a few other huge contributors) will be able to generate certified software engineers so only MS software will be useable. Thus LINUX will either die from lack of use or die from being commercialized by MS. There will be two benificiaries, MS by making money and selected congresspeople who will get brib^h^h^h^h campaign contributions. Meanwhile NSA software will be generated in China, rather than by US programmers.
If there were any interest in having secure software the committee recommendation would be to ONLY allow open software.
"Licensing" == "Certification"? (Score:5, Insightful)
Two questions (Score:5, Insightful)
Re:Their loss (Score:2, Insightful)
The stupid part is, paid programmers won't either. They'll get insurance against being sued, just like doctors take out malpractise insurance. Then they'll go on writing the same shitty code because the end users continue to demand ease of use and featurisim ahead of security.
The better idea is to just take out insurance against being hacked in the first place. Insurance companies already offer this.
Re:Good concept, illegal in practice (Score:2, Insightful)
This is the silver bullet (Score:5, Insightful)
... syndrome. Lawmakers always want something that sounds good, looks good, and will make them appear to be addressing the problem.
The conceptual framework they're working under is wrong. They assume that a single person is the author of a program. Maybe some programs have just one author, but most have several. The main, lead programmer, who is typcially the copyright holder, may not even look at every line of code in a program.
The bit about a culture shift is valuable. Projects should be built with security in mind, using basic principles (least privelege, minimize scope, check your loop bounds, etc.) that are, coincidentally, good programming practice.
But the culture shift that's needed is away from blame-based analysis of security failures and toward cooperative assistance. That shift is assisted by opening source code. Licensing programmers will tend to accentuate the blame attacks when bugs are found, and will provide incentive to hide them.
No program is bug-free. No committee of Licensed Gurus can eyeball scan a progran and find all its bugs. It takes running the program in real-world situations to find some (most) bugs. Licensing the programmer will not decrease the number of bugs in a given program.
Lawmakers would do better to simply stay out of the matter entirely than to introduce bureaucracy for the sake of appearance.
Re:OT: Re:How about driver's licenses? (Score:2, Insightful)
Not always, especially in police cars.
that actually adds to safety
Maybe. But why should I be penalized because of other bad drivers? I have driven with a CB for many, many years, and have driven a big rig. No accidents. So now I can't drive responsibly because some idiot who can barely keep it within the lines normally is using a cell phone?
Our civilization is becoming run over with laws that only idiots need. I blame it on the court system and law suits. If you are an idiot and use a product wrong, then you should take the blame. For instance toasters do not work in a bathtub, yet if the toaster company does not have that specific warning on the label, they can be held liable. Bah!
Yes, this is a hot button issue with me.
Re:Licensing again huh? (Score:5, Insightful)
I'm all for formal open standards for security. And I am very much for formal accredited qualifications in safety critical systems. I'd love to see an MSC in computer security and similar university qualifications - but it has to be a proper and open thing, not some goverment office of computer programmer licensing.
As to accountability - there is a simple solution. Do something about the ability of companies to use software licensing as a get around for liability for product in most countries. Make it like other product. If its sold then it should be suitable for purpose. (Note here sold - paid money for. I see no reason why *paying* for open or closed source ought to be different).
It will also improve computer security no end the day a company gets sued for harming others by being negligent in applying security patches to its systems.
Paid more for free software? (Score:3, Insightful)
The proof of the pudding is in the eating, and free software has done pretty damn well on the security front. If some pinhead executive wants to pay for "confidence" -- well, I'm sure someone will be happy to take that money off him.
And getting paid more for jumping through silly hoops when you're writing for free? How much more? 10% more than zero is -- zero. The whole thing is silly.
Re:Do they not get it? (Score:5, Insightful)
It's a good idea on paper, which is why people like me are well-nigh terrified when this idea comes up.
The problem is one of expectations. Yes, we could apply that rigor to all software. But,
- No more garage startups... and all new technology tends to start there. Innovation, true innovation, takes a huge hit under these schemes and we lose huge advantages to any country that doesn't enforce these rules.
- Expense. Those methodologies eat manpower for lunch. Are you going to pay for it? For every piece of software you use? Even "ls" or "echo"? No, and neither will anyone else. It only makes sense for certain things, and different level of rigor makes sense for different kinds of programs... even different levels of rigor for different guarentees. Good luck even figuring out which of these is right, let alone getting the government to mandate the correct levels! We are far from a consensus on what is appropriate; we're not even sure where it makes economic sense to use what we know, and we certainly don't know what we don't know.
- Freedom of choice. The converse of the above; we should be able to choose how secure our software is, because it's not free. Mandating any security level, and since other people's time is always free, you can be sure the government will mandate a very high level, means that I am forced to buy these high security products. What if I don't care? My game console is free to crash, and even if it's 0wz3r3d, who cares? On the next power cycle, it'll return to normal. (At least modern architectures.)
In the real world, it is, to put it bluntly, a shitty idea.It's not time for government mandate, it's time for the market to start demanding security. The proven method for balancing cost vs. performance is the invisible hand of the market.
The root cause here is a monopoly, training people not to be concerned about security. The correct solution is a healthy market.
Best of all, we won't find ourselves in 2015 shackled by government mandate to 2005 engineering techniques. It's an act of shocking hubris to think we've got this figured out enough yet to mandate any solution.
Blaming the developers? (Score:5, Insightful)
- A software developer (ie a programmer) gets licensed
- works on a project for (name some large company)
- company management provides direction for the programming efforts (as they do)
- software is iunsecure by design, due to management decisions (happens now, and the plan changes nothing here)
- software is finished
- ....marketed
- ....purchased
- ....deploy
e d - ....ends up killing over 10 thousand people for some trivial reason
- programmer takes 100% of the blame; firing squad at dawn
- company/management who made the decisions which introduced the lack of security get off Scott Free; zero legal consequences of their stupidity
Or am I misunderstanding the whole point of the exercise?The blame game (Score:4, Insightful)
Exactly who will be willing to take personal responsibility for a security breach? How many new legal cases will come up trying to prove that a breach is the "other guy's" fault? "We'll show, your honor, that it was the 'evil bit' hidden in the compiler that caused the security hole!" I suppose we'll see programmer malpractice insurance not long after too.
Would this mean we could go after MS for monetary damages? Somehow I doubt it. Would MS's recourse be to say "Don't worry, that developer has had his license revoked."?
This whole thing seems like a big CYA bid. Just make sure someone else is available to blame. Seems like they are saying, "We can't blame the hackers because we can't find them. But don't worry, you can blame the programmer now."
Regardless of the intent, I don't see this doing a bit of good for security. People with real talent, but who want to reliable income will shy away from a system which they could easily be responsible for damages, or alternatively lose a license to practice their trade. I have a wife and kids... no matter what I think of my skills, if I'm at the mercy of every hacker out there I'll find another field.
So, the result will be that it will become very HARD to hold someone responsible. Action, if ever taken, will be only in events of gross negligence. Security *may* improve short term. But, if we drive out all but the risk-takers I suspect that security will go down and the quality will go down too.
In the end I just see an institutionalized profession which hasn't given us any real benefits.
This seems like just another knee-jerk-silver-bullet attempt to fix an embarassing problem. Why do I picture a meeting somewhere running late and somebody jumps up saying, "Hey, I know! We'll license programmers and hold them responsible for breaches." Followed by, "Yeah, and licensed programmers will get higher pay, so there is an incentive right there!" Then "Discussion? None? All in favor..." And whispers of "Great.. I'll be home in time for dinner tonight!"
Another proposal by those that don't understand (Score:3, Insightful)
Re:Do they not get it? (Score:2, Insightful)
What organization is this developer working for that they threw an incompetent programmer onto critical code? Do they do appropriate code audits given that it's critical code? Do they have external code audits if it's for a critical medical or government system?
A programmer who manages to get certified but who then writes sloppy code could have his license revoked (like disbarment for a lawyer) thereby preventing that programmer from writing any more critical code.
Do you know how rare a disbarment actually is? It generally only occurs when a lawyer does something publicly that draws public interest. Otherwise those sorts of boards are generally protective huddles.
A person coding a fly-by-wire system might need a higher rating than someone writing a video game.
Here's the thing that makes this, and all similar examples, absolutely ridiculous -- Boeing doesn't call up Joe Programmer and say "Hey, could you throw together a fly-by-wire system for me?" and Joe whips up something in vi, compiles it and sends in the lib. Instead they have a _huge_ interest in ensuring that the code is as perfect as they can possibly get it, because as an organization they have huge fiscal and possibly criminal liabilities if the process that created the code was insatisfactory. Because of this Boeing, and organizations like it, go to great lengths to ensure that the coders on this team are the best of the best. They further build a heavily regimented and strictly enforced process of code audits, analysis, walk-throughs, reviews, etc.
Re:Do they not get it? (Score:2, Insightful)
Before we hold programmers responsible for defects, let's hold program managers responsible. I wonder how many jobs that are currently bid at half what the developers say it will take to do the job would still get bid if the PM knew he could go to jail if things went south?
Ultimately, it is the fault of customers who think they can get good software cheap. I learned a long time ago that if you bid what the job will really cost, you are out of business. But if you bid 3/4 of the real cost, you can convince the customer to take "upgrades" as you go along. And you can tell him that he didn't really specify the feature that he really wants, but we can put it in for so much extra.
Re:Do they not get it? (Score:2, Insightful)
I'm not sure they think at all. I volunteered as a reviewer of the initial SWEBOK (Software Engineering Body of Knowledge) a few years ago. Basing licensure on the SWEBOK would have been a disaster. No design patterns. No agile methodologies. Nothing newer than the late 80s.
You can't have licenses without tests. And you can't have tests on things that are still evolving. So licensed software engineers will be expert on technologies that are 15 years old, and dead.
Alistair Cockburn advocates one methodology per project. This make perfect sense to me. I knows a several dozen ways to build software. And I tailor an approach that fits the project ==> how tight is the schedule, what is the legacy like, who do I have to work on it, how good is the customer, what is the nature of the app, etc. Write me a licensing exam on that.
Re:Do they not get it? (Score:2, Insightful)
This tells me a lot about the software development firm, and little about the software developers. I've worked with many levels of software developers -- from self-taught high school dropouts to professional certified engineers -- and I have noticed that there is incredibly little correlation between those "classic" indicators of skill and actual dedication to good quality code. (Indeed, the worst programmer I've ever worked with was a professional engineer).
I have worked in software development for over 20 years now and, while most people advocate the careful processes you describe, nowhere I have worked actually does it
And that is the core of the problem with software quality. It has nothing to do with blessing certain developers, but actually getting real quality processes in place (and audited) at software firms.
Re:Do they not get it? (Score:3, Insightful)
I don't think we are disagreeing but you don't seem to quite track what I am saying so let me try another approach. Ever notice how you can talk yourself blue in the face explaining to your boss how something is illegal but he ignores you? Ever notice how there's not a peep out of him once a lawyer from legal utters one sentence saying exactly the same thing you've been saying? That's because the lawyer speaks with the weight of his license behind him. Your boss knows every competent lawyer will tell him the same thing and the courts will enforce it.
Most corporations will not put those quality processes in place until there is some sort of regulation such as licensing required. Once licensing is required, and development process guidelines for those who wish to retain their licenses are in place, corporations will have no choice but to listen when their developers say "it has to be done this way to ensure quality (or at least a defense against a lawsuit)". If you say that today at most places you are shown the door while they replace you with someone who won't argue.
Another boondoggle (Score:3, Insightful)
I'm tired of hearing how architectural and structural engineers are "certified", and the insipid comparisons made between this status and that of software engineering. The penalties for a bridge or building collapsing are extreme of course, and no-one would want an incompetent engineer designing such a structure. But what is lost in all this talk is the design review process that occurs long before anything is actually approved for construction. Yes, perhaps the design engineer is technically accountable for a flaw in his work (I don't know, I am not a lawyer), however in any major undertaking there are dozens of others responsible for validating and double-checking the design, and there is no way in Hell that that engineer would be considered solely responsible for a serious failure when a whole review team approved his efforts. Besides, that's what we have insurance for, anyway.
Given that corporate America has proven to be even less reliable and trustworthy than Microsoft Windows 98, I think we should start by certifying the business ethics exhibited by corporate executives and middle managers. Then let them pass tests that indicate an understanding of the software development process, and once that is done make it illegal for anyone in a marketing or sales department to influence software release dates. The programmers aren't the problem. Corporate America is the problem, and until the market decides that it is willing and able to pay for quality software no amount of legislation or governmental interference will improve matters one whit. Believing otherwise is naive or disingenuous.
Of course, it won't matter if the current trend in outsourcing continues, since there won't be any software engineers or programmers left to be certified anyway.
Less freedom, and the rich get richer (Score:3, Insightful)
The official explanation for all this was the accused were terrorists who threatened the security of the motherland. It was Guantanamo Bay writ large, and once it picked up steam, it did not stop until, after somewhere between 20 million and 40 million state murders, the Soviet Union collapsed under its own sheer inefficiency in the early 1990's.
In the Soviet era, the most improbable things were tied to the idea of, as we say today, homeland security. If you twist the logic far enough, and people are either stupid enough or frightened enough, you can get away with claiming that the manufacture of cheese is a matter of homeland security. (And why not? It is a fungal product susceptible to both accidental and intentional contamination with biotoxins; an economic resource vulnerable to sabotage; it is produced by wealthy companies whose political allegiances might not be entirely healthy; and worst of all, it is a national emblem of the hated French.)
This programmer licensing is a ruse. Like the bulk of the Department of Homeland Security, it is a crock of shit designed to convince the public that the government is "doing something" against a threat of dubious reality but great electoral usefulness, and it will serve only to centralize more power and money in the hands of large software companies.
Even if it weren't part of a fairly nefarious political trend, does anyone really believe this will make any damn difference? Commercial programmers don't make the important quality decisions -- they are handed down by management to suit marketing needs and the bottom line. If there's any professional programmer here who hasn't written inferior code to satisfy arbitrary time and resource requirements imposed from above, speak now and be counted with your five or six other brethren.
If you want to improve the quality of software, hold companies and their shareholders financially responsible. In other words, put pressure on the people who actually make the decisions, and they will select those programmers -- licensed or not -- who write quality software and give them the resources to do it.
Of course, the big software houses (read: Microsoft) will never go for that because neither they nor the subversives at the Department of Homeland Security give half a rat's ass about the well-being of the public. What they do care about is enhancing their own prestige, power, and wealth.
License is for something that is illegal, unlawful (Score:1, Insightful)
So are we now going to allow the police state to say that creating or writing software is illegal?
Get a clue people, here comes the police state, all they need is a excuse like 911 and all you have to do is keep saying "protect us all mighty government, we are too lame to do it ourselves".
Re:License is for something that is illegal, unlaw (Score:2, Insightful)
Exactly right. "License" is permission to do that which would otherwise be a crime to do. If you come into my home as my guest, you are doing with permission what could send a burglar to prison.
Historically, license as a formal permission from the state stems from the general police power of the state to prohibit things that are deemed dangers to public health or safety -- such as cutting people open with knives allegedly to treat injuries or illnesses -- and then allow select people the permission to do those things under some set of conditions and qualifications, hence licensed doctors, who *are* allowed to cut people open without fear of being charged with assault with a deadly weapon, bodily injury, maiming, etc.
Where "license" goes bad is when, in complete ignorance of what it means and where it comes from, the public accepts "licensing" for purposes such as generating tax revenues. Every one of us has seen proposals to "license" something as a way to raise revenues in the form of license fees, but few people have understood that such proposals amount to "We want to make xxxx illegal so we can then turn around and collect fees for permitting just about anyone to do xxx." It's bass-ackward and contaminates the legal concept of "license."
So, yes, writing software can only be "licensed" if writing software is first made into a crime. Whether or not the proponents of such a thing can sell the idea that a vital state health or safety issue is at stake remains to be seen, but in today's climate of ignorance it probably isn't necessary to explain such reasons to sell "licensing" of anything.
Re:Less freedom, and the rich get richer (Score:2, Insightful)
Angst Badger wrote:
If I have, it wasn't signicant enough to be able to remember now. But I haven't worked in the environments in which clueless marketing suits dictate features and release dates. An awful lot of the software I've designed and written was on my own initiative and sold to management on the basis that it was the best approach to accomplish the goals. In a lot of cases management was never brought into the loop, since I had considerable control over the tools I chose to adopt or write. When you invent new things in environments that are not rich in solutions, you may be able to do what you please.
Nonetheless, I doubt I'll be writing any more software in the years remaining to me, for the following reasons, among others:
I got into programming many decades ago because it was fun, and I was able to become the guru in every shop I ever worked in. It's no longer fun, so I choose not to play in this game anymore. I might consider selling executive burial plans out of a sense of retributive poetic justice but there are other fields I find more interesting.
Re:Pointing Fingers (Score:1, Insightful)
This attitude is precisely the problem. You are confusing development with accountability. In the closed-source world, the people who develop and the people who are accountable are usually one and the same, so it's an easy mistake to make.
This is not true of open-source development. When there are bugs in Red Hat Linux, Red Hat should be held responsible. Did a programmer working for them cause the bug? Almost certainly not. Is the bug their responsibility? Of course it is!
Open-source software is often judged using assumptions that are only accurate in the closed-source world. It seems to me that whenever this happens, open-source loses out, simply because people aren't as familiar with it. Hopefully, time will change this.