Will Security Task Force Affect OSS Acceptance?

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.

Comments

Only as secure as platform...

[mikeyrb]

But programs are only as secure as the platform they run on, and of course the same as the people who use them. If people don't run their system properly, I'd say that's worse. Not to mention that people would use trusted vendors anyway, so I don't see what this adds.

Do they not get it?

[roninmagus]

Do they really believe that licensing software developers will lead to more secure software?

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?

[vegetablespork]

On the plus side, since we're licensing for "homeland security" reasons, there's no reason non-citizens should be writing any software used in the U.S.' critical infrastructure. Right?

Re:Do they not get it?

[aheath]

Neither article explicitly touched on the issue of software quality assurance. The development of processes and procedures for writing secure software should go hand in hand with the development of processes and procedures for testing secure software. SQA methodology has to expand beyond usability and functional testing to incorporate security testing.

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.

Re:Do they not get it?

[elrond2003]

>>>>Do they really believe that licensing software developers will lead to more secure software?

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.

Re:Do they not get it?

[Jerf]

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.

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,

1. 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.
2. 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.
3. 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.

How about driver's licenses?

[civilengineer]

THe idea was to give licenses to only those who can actually drive safely. But, if they really implement that there will be very few people with licenses and car companies will go bankrupt ( no more wars maybe??). So, they give this easy test for the license and every TD&H can drive. Of course we have had over 40,000 fatalities and 2 million crashes every year in the US for past 20 years.
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.

Pointing Fingers

[RetroGeek]

All this does is create a person who can be targeted if Something Goes Wrong(tm).

With OSS there is no "someone". With a licenced developer you have someone to blame.

Paraphrase of John Milton

[Nate B.]

I recall a quote from John Milton that went something like this, "None can love freedom but good men. Others love not freedom, but license."

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 >>

"Licensing" == "Certification"?

[mrkurt]

Quite honestly, the SD Times article told me nothing about what they're really going to do about improving security in applications. You could substitute "licensing" in that article for "certification", as in some vendor's certification of developers. Then, it looks like a useless measure of what that person knows about security. If, however, it is more of a civil service exam, and they're going to test for knowledge of how to write secure code, then it would make a lot more sense.

Two questions

[hdparm]

Does it mean that software created by those same developers, now licensed, in the past is now cleared? Are they going to hold developers and engineers accountable even if they're forced to produce code based on inherently flawed design, driven solely by profit and questionable business practices?

This is the silver bullet

[RealProgrammer]

... 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:Licensing again huh?

[Alan Cox]

There is two reasons to license software developers in the USA. Neither are good. The first is so that you can forbid compilers, debuggers and other "dangerous" tools to the RIAA/MPAA being in the hands of the masses. The second is to stop the all the computing jobs leaving the US by having a US certification required but inaccessible to the competition.

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.

Blaming the developers?

[Crypto Gnome]

Here's a summary of the plan.

• 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
• ....deploye 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?