Slashdot Mirror
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.
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 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.
Open Source software is either better or it shouldn't be adopted. If it is better, then it is at least partly due to the development model, which is inherently not hierarchical/certifiable. If suits really need someone to offload risks to, there's always your friendly insurance company that wants to earn a living by assessing and managing risks. I can see people contributing code for free but I doubt people are going to put their financial future on the line for free.
For commonly used software this provision of jobs increasingly depends on artificial barriers to the acceptance of free alternatives. Now that millions of people are programmers with supercomputers on their desks and an itch to scratch, and now that the cost of software distribution is approximately zero, the unconstrained market value of a line of code for a commonly used application is rapidly converging to zero.
The anti-FOSS lobbying is merely an example of the artificial barriers that prop of the prices and keep all those people employed. (Though I doubt that there are actually that many people earning their living by programming operating systems, Web browsers, and word processors these days. In the future the way to make money as a programmer will be to implement special-purpose applications that only scratch the itch of some company's shareholders.)
In one word NO. It would not have to be written by a professional. It would simply need to be reviewed by one?
I am not as think as you drunk I am.
One problem (of many) is of course that if you make programmers legally responsible for security failures you also need to give them the authority to say "No! You can't do it that way! I don't care WHAT Marketeering says!"
Texas has had licensing for a few years. Anyone know how it's worked out?
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.
New year Resolution: Don't change sig this year
May be the SD Times should hire a "licensed developper" to fix the date. They appears to be one year late "January 1, 2003".
I got annoyed at the slashdot comments last time there was security hole in OpenSSH and wrote this page (copy pasted below). I count OpenSSL as insecure software - we need a secure replacement. GNUTLS looks somewhat better, but I don't trust it too much either.
Why is some software more secure than others?
How do you measure software security?
Here's my definition on what is secure software.
Intro
I get really tired of seeing these kinds of comments every time some widely used software has security holes:
While they may be partially true, I think they're also very misleading and disparages the hard work that some secure software authors have done.
Simplicity Is Security
The difference between secure and insecure software is really the coding techniques being used by it's authors. Authors of secure software do everything they can to prevent accidental mistakes from ever happening. Authors of insecure software just fixes the accidental mistakes. There are very few secure software authors.
Auditing insecure software doesn't make it secure. Sendmail is a good example of this. It's been audited countless times by competent people. The simplest mistakes were catched easily long time ago, but a few very difficult to find vulnerabilities were found only recently.
How do secure software authors then avoid the kind of security holes that are difficult to find? By keeping the code simple. The code doesn't get secure by polluting it with tons of security checks. It gets secure by keeping the security checks in as few places as possible.
Auditing secure software is easy. You can just quickly browse through most of the sources without having to stop and look at it carefully. Everything just looks clean, simple and correct. vsftpd is a good example of this.
Sure, it's still possible that secure software has some security holes occationally. It just happens a lot less often (if ever) and usually the problems are less critical. For example none of the security holes in Postfix have lead to arbitrary code execution or being able to read other peoples mails. Denial of Service attacks are nothing compared to them.
(some examples in the web page not included)
--Brought to you by the DB tool
7098931
The linux hacker
This is the grant of government license to do a specific type of work. That's akin to the government granting the title of Lord, and is technically illegal.
That said, the idea itself is good -- but let ACM *and* IEEE *and* Sun *and* whatever other institution do certifications... That avoids the government regulation, and allows potential employers to select "qualified" individuals.
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.
- - - - - - - - - - -
I am a programmer. I am paid to produce syntax not grammar. Deal with it.
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 >>
"Insanity is doing the same thing over again expecting a different result."
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.
And then we get stupid laws like banning cell phones while driving.
If you ban cell phones, then what about police officers, firemen, ambulance drivers, truckers (and other people with CB's) who use two-way radios.
Using a microphone is more distracting than a cell phone, since you need to push a button to talk.
Of course most of the a/n people have extra training and experience (and testing).
BTW, what is a TD&H?
- - - - - - - - - - -
I am a programmer. I am paid to produce syntax not grammar. Deal with it.
I mean, after all nothing will break the system faster then requiring those nasty Apache, Kernel, and mySQL people to become registered - just to have thier products used in the enterprise.
Slashdot, where armchair scientists get shouted down and armchair theologians get modded up.
Would OSS have to be writen entirely by licensed developers to be considered secure?
I'm sure glad the DHS steps in and prevents all those 1ee7 uncontrolled hackers from creating evil unlicensed, software that aren't secure.
Why do I always picture half-drunken bar patrons reinventing the world in front of a beer when I hear about the DHS talking about things they don't have much of a clue about?
"A door is what a dog is perpetually on the wrong side of" - Ogden Nash
Wait, I think I didn't like these licenses the first time I saw them...when they were called MCSEs. We have competent MCSEs and incompetent MCSEs -- did that piece of paper really make that much of a difference? Probably not. Nor will any of these licenses in the future.
As for software itself, don't EULAs pretty much indemnify software companies from any oopsies they may have put in their programs?
If you want to secure your software, coin a catchphrase...say maybe "Trusted Computing" and then send oodles of press releases about retraining your engineers to hunt down buffer overflows and stuff. Then proceed as you were before except when people find bugs, you say "see, we're finding them!"
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.
Always look on the briight side of life! (whistle, whistle)
I meant "undue government control" and "yet again shifts"
:)
Sad thing is, I previewed!
The US military brass decided at one point that it would be great if all of their software was written in one language. They forned a comittee to design what they wanted. Ada was created and various military agencies started insisting on its use.
The problem was that what they designed wasn't flexible enough and over time Ada became less and less important.
Licensing will go a similiar route. The government will spend millions on a comittee to come up with requirements for a standard software engineer license. Then they'll find out that their licensed folks STILL screw up and eventually it'll become less of a big deal.
That being said, if software engineering licenses come into existance at the federal level you can bet I'm going to get one.
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?
when the next dozen Microsoft "critical vulnerabilities" come out.
Who wants to bet that Microsoft gets some kind of exemption from the revocation of licenses due to poor design and coding?
The concept of reverse engineering just doesn't occure to politicians and people in management.
They don't understand how it is even possible to be more secure though good mathematics than hiding the code. Heck, I've even talked to some system admins that don't understand these concepts.
Does this mean that OSS cannot be considered secure but the government? Well, companies can still represent OSS, like Red Hat. So if Red Hat gets a license for a project and uses OSS, or something modified from OSS then they are responsible on how that has been licensed to be used.
Who do you think has a better chance of writing secure software: Microsoft or Red Hat?
They both have CEOs and they can both sign contracts.
Promote Sensitivity on Slashdot, make me your friend.
Does this mean that programmers can put themselves under the GPL to be considered FOSS developers? and would this circumvent anti-cloning laws and human genetic engineering restrictions to have people under the GPL?
Snowden and Manning are heroes.
There'll be jobs to be had, but not for those with Slashdot posting histories advocating the "theft" of intellectual "property."
~~~
If this if for homeland security does that mean the only people who can be licensed are US citizens native to this country? If so, that may help with our outsourcing epidemic.
Make me your friend. All my friends get +1 modifier and I need friends :)
As the past owner of two different businesses and the present manager of a mid size company, I can confidently say that the answer is no.
This is very simple. Over the years, I have hired a wide range of different people to work as programmers. I had everything from masters degree programmers with 20 years experience to kids out of school who do it as a hobby. In all cases, what determined the success or failure of the project was not the qualifications of the programmer. I had masters degree programmers write such gibberish that multi-hundred-thousand dollar projects were cancelled. I had masters degree programmers who did a marvelous job. I had some kids code up another product that worked so beautifully that it only made the company money. I also had kids who did a crappy job and the project failed. In other words, success or failure is determined by results, and nothing else.
Returning to the above question, software is considered secure if it is tested for vulnerabilities and is found to be strong against attempts to break in. If the programmer has a Ph.D., that's all nice and pretty, but it means exactly Jack Schitt. The results are the only thing that matter.
Therefore, I think this committee should not waste its time with issues like licensing, because that will only create more bureaucracy, more fees, and entire administrative efforts... and it provides no guarantees of success. They should figure out a way to measure the reliability of a piece of software (reliability is the parent category of security, because an insecurity reduces reliability). They should make up some guidelines for how mission critical systems should be judged and tested. Perhaps they should recommend that the government should hire its own crackers to constantly look for and help fix vulnerabilities. Because security isn't a one-time thing. "Let's license programmers and the problems will go away." It doesn't work like that. Like everything else related to management, in security, the only constant is change.
Hello from New Zealand... Uggghhhhh I have a nasty hangover... slept till noon... this sucks. What, it's still 2003 in America? You guys need to catch up to the rest of the world; getting rid of that dipshit Bush would be a good start.
Everyone (and especially developers) wants functionality over consistency or predictibility. If that functionality conflicts with something that came before, then it just creates more job security to understand the nature of the interplay.
The worse the systems and languages become, the more "flexibility" is needed to keep the card tower from falling. Side effects are a basic fact of everyday computer use. Bad security is one such manifestation.
Microsoft is paying the price now, but open source is equally guilty of creating a mess. Most of the problems that plagued me 10 years ago still there wasting my (and others') time. How do you get truly robust and secure when the basics never solidify.
... 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.
sigs, as if you care.
This is EXACTLY what we need, a government bureacracy created to step in and solve all our problems, just like they have in every other area.
Lord knows when you hire a licensed contractor, nothing will go wrong.
Instead of those "Licensed contractors build confidence" bumper stickers the union thugs put on their trucks, they should put:
"Licensed contractors build artificial barriers to competetion and inflate prices unecessarily while slowing everything down jumping through government red tape."
Isn't taking as long as i expected for the HSD to get involved. :(
I guess my prediction of 5 years out before all software is controlled, licensed and restricted may have been a bit optimistic.
Don't forget, hardware will go this route too in order to "be secure"... ( I.E. mandatory DRM )
First get 'corporate' acceptance of the concept by snowing them enough, then put it into law
---- Booth was a patriot ----
It seems that licensed developers would only have to mark up open source code a bit, review it, and then implement it in a smaller business setting. On a national level licensing developers will be a minimal cost.
There is a side to licenced software engineers that most people don't consider. Just like other licenced professions, you would be personally i.e. financially responsable for bugs in your code. Is this a good thing? On one hand, it would certainly improve code quality across the board with developers having this in the back of their mind. It would also do interesting things to exporting software engineering jobs overseas, but I am sure there are loopholes there. On the other hand, considering the environment the average S.E. works in and the nature of software itself, bugs exist. Until the legal shakedown, the ugly fact that it is impossible to write bug free code will cause many developers to get squished, especially since the current job market won't let you negotiate for your employeer to take up this legal burder in most cases.
The software world doesn't revolve around the US of A or for that matter the Homeland security department.
In the Yahoo! article, all of the companies mentioned except Microsoft use, sell, or support Linux/OSS systems. As such, they are not likely to lobby in favor of Microsoft-style security-through-obscurity. As for licenses, the question really depends on the penalty for practicing without having one. Will it work like the MSCE program, where you can still write MS code without it? Or will it be like a driver's license, where you can be penalized for practicing without it? If its the former, then I don't really care one way or the other. If its the latter, I think it will cause a lot of hassle without any real results.
/*
// always
Also, one should realize that many security holes are caused by bad design choices outside the control of the lowly programmers who might be penalized. Consider this example:
In MS Visual C++, the *.h files are writeable. Therefore, it is possible to create a (very slow) worm using #define macros. They could "hook" various functions to add worm code to the *.h files when ran on another machine with Visual C++. Thus, executables compiled on that machine have this "feature" as well and can spread the worm further.
static int infect_headers()
{
Should contain code to somehow insert a copy of this function and the below #define into this header if its not already there. A quine implemented in a header file?
*/
return 0;
}
#define strlen(x) (infect_headers() + strlen(x))
Note that the C Preprocessor and compiler works as designed here. The problem lies in the idiotic decision to make the header files modifiable by anyone.
Unknown host pong.
To put it simply, to make software developers liable for security breaches is the same thing as making the manufacturers of Locks and Burglar Alarms liable for beakins and theft.
If you really want a secure computer, keep it unconnected to anything else and in a faraday cage with only one operator allowed and 3 armed guards to prevent others from accessing it 24hours a day... Total security is unfeasible, in the brick and mortar, or the software field.
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.
Unlimited growth == Cancer.
OMG look at his Sig! KNOWN TROLL BEWARE! Mod Down!
Yeah. Sure. That's why programming jobs are leaving by the US by the boatload, so we can license and pay programmers more. So that would be 15 offshore programmers instead of 10? This will just drive more companies out of the US.
"And a voice was screaming: 'Holy Jesus! What are these goddamn animals?'" - HST
- 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?Visit CryptoGnome in his home.
Let us not forget that the IBM Linux Technology Center has certified a Linux distribution (SLES 8) under the Common Criteria Evaluation Assurance Level 2, and they are currently working on EAL 3. This qualifies a Linux distro, composed largely of Open Source software, to take part in bids on certain security-sensitive government contracts. This sounds just like the kind of assurance that this security task force is looking for.
An unjust law is no law at all. - St. Augustine
the journalistic integrity of the host of this article. If they are proposing, or even carrying the message, that programers be "licenced" and held accountable, should they not be held to the high standard of having accurate dates on their articles?
Note that this sounds fairly familiar, in that I think we have heard suggestions quite similar coming from the northwest coast of the US. I also note that the vast majority of exploitable code comes from that region of the US as well. (Ok, the vast majority of code on the market today comes from there, but that's only part of the issue.)
At the same time, I don't think Microsoft really wants to play that game, as I am pretty sure that they are aware that they would then becmoe liable for bugs and faulty security decisions in their own software.
But that's juse my opinion. I've been wrong before.
-Rusty
You never know...
Licensing Software professionals and holding them accountable for software security is the Palladium concept applied to people. Once you have to license "software engineers" in general, you will have them digitally signing their code and then only software duly signed will run on your Palladium Computer. Otherwise, your computer might run (gasp!) pirate code!
I am assuming the compiler will digitally brand your code with your signature, in order to find out who wrote the "unsafe" code that was breached.
"We license civil engineers to have confidence their bridges will support a certain amount of weight over a certain period of time. But is it bomb-proof? We need to define software in those terms," Moritz explained.
Ok, an interesting point, except that there's NO commonality between the two situations
- A civil engineer is responsible for the design
- a programmer is always responsible for the implementation of software, and not necessarily the design
You would sue the engineer for bad design. Engineers don't actually physically build anything. They design things for construction workers to build.If the implementation failed, but wasn't built to his design, it's not his fault.
Moritz specifically named programmers. When was the last time your job as a programmer was 100% design and 0% implementation.
Visit CryptoGnome in his home.
Why would OSS have to change? OSS is what it is, proof that collaboration, cooperation, and openness will eventually lead to a much better product. It doesn't matter a single iota what anybody legislates or says, if we keep building software better than everybody else eventually everybody else WILL buy into it.
Bryan
What if the only people who will get licenses are those who work in other coutries under outsourcing conditions? Hmmm... Sounds fishy to me. Hardly secure is Ishmeal of hamas has a better chance of getting an engineering job than an American or Brit.
Fast machines, powerfull AI, impulsive invention,... All I lack is a good espresso machine!
are you in the same crowd that told people to move away from openssh in favor of lsh?
... the openssh vulnerability for which there were no exploits. *gasp* you say! there was one! alas, it was a trojan.
... for which there was a working, public, 0day remote root.
oh yea, that's right
yes, let's move to lsh
or do you recommend qmail? yes, djb, who, after 5 years, has still not paid the bounty he has promised for exploits. they are there and they are public.
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!"
Apparently the author is clueless recluse that has never heard of or used OSS/Linux (which is surprising, considering the guy they were talking about comes from C.A.)
OSS fulfills every one of the criteria described in the article, if only there were some way to either get an OSS backer in a gov't position or to convince the US gov't to switch entirely to OSS.
"Java was the first language that emerged with security constants inherent," Moritz said. "Maybe we need to go back to the drawing board and apply science to the languages." <- this proves my point, the author is clueless.
I write some code for a particular application. It works perfectly there for that purpose. Then, some manager decides he wants it for an unintended application and runs it there. It fails miserably in that environment and I'm on the hook because somebody misused some software I wrote. NOT!
Also, if that same software is intended for a specific computing environment and that environment isn't configured per the requirements of the software and it then has holes all through it but I'm on the hook. NOT!
There is no way to make this concept work -- putting 100% of the blame on **ANY** security problem directly on the shoulders of a programmer or team of programmers who actually built a good program that was used badly.
This must have been suggested by a bunch of litigation lawyers or insurance companies. There are many industries that require all kinds of insurance to be in business (real estate, etc.) but those premiums are rarely, if ever used in actual practice.
I don't see any way to make what is described in the SD article work in real life.
Banjo - The more I know about Windoze, the more I love *nix
Who the fuck modded this as troll??
The trouble is, no better dipshit has stepped forward to be a candidate, so he'll probably being going back for another four years.
And anyway, he killed a lot of terrorists, will no doubt kill a lot more before his term(s) as president end(s), and ousted Saddam Hussein, so he's not all bad.
So, leaving aside issues of whether or not this is a good idea, are states' rights being encroached upon with this idea? States currently license engineers as they feel its necessary - why would software require federal licensing? Engineering is engineering, whether your twiddling bytes or blocks.
"CRACKERS", if you please....
We could, in theory, have secure message-passing microkernels enforcing a mandatory security model running on secure machines with machine-checked proofs of correctness of both the code and the hardware at the VHDL level.
But every project to build such a thing has produced only a toy OS. All the verification projects are dead. C and C++ are hopeless for code verification. Java isn't really suitable for a low-level OS.
I worked on proof of correctness technologies in the 1980s. We didn't have enough CPU time for program proving back then; it took about 45 minutes on a VAX 11/780 (1 MIPS) to do the proofs for a 1000 line program. That would equate to about three seconds today. In a real proof environment, you're doing this about as often as you compile, so the proof process has to be reasonably fast. (You can cache quite a bit, though, and save time on reruns.)
But all this is stuff so far in advance of the crap we have today that it's not worth doing. We don't even do obvious things like run browsers in jails, with a connection to a window and the net but no write access to anything else.
That's why I got out of security years ago.
This goes back to the digital sigs for website shop front ends, and "signed" ActiveX controls etc. First off, just because something is liscensed, doesn't make it trustworthy. More problems will arise from people nievely trusting applications that have the "It's secure" sticker on it, instead of doing what they can to understand the application and it's proper implementation. Secondly it would destroy the market for developers who refuse to conform to, or cannot afford "liscensing". MANY useful and integral applications, especially for non M$ platforms, rely on people making improvements and fixes in their spare time. Who's going to be willing to submit a quick hack to fix a problem if they might be liable for the result? Hell who's going to code anything for free?? I'm certainly not willing to make myself personnaly liable without any monetary compensation. For legal fees if nothing else. Htf am I going to know that when my obscure software is compiled on the 2.9.4 kernel years from now, it creates an exploitable condition?? Going back to the first reply, the platform the software is running on makes a HUGE impact on it's security. How am I going to develop an application on a platform with an inherantly flawed API subject to hijacking etc? How about physical security issues? What if a compromise occurs on a machine, that resulted from say a hardware keylogger ($40 from thinkgeek), or a disgruntled employee? Must I bear the burden of proof that it was not my application but one of these or a host of other issues that caused a compromise in a system running my software? It's just a plain bad idea, poorly formulated, and not very well thought out. It's the "higher ups" deciding to place the blame on the developers, and remove personal liability from themselves.
The framework they're working under is that of Engineering practice. When a PE signs off on a job (s)he was no more the sole author of the work product than a software development lead or architect is the sole author.
Is software practice generally anywhere near ready to be held to the kinds of standards applied in structural/civil/electrical/chemical/... engineering practice?
Hell no, it's a no-brainer so in the send of today's standards of quality no this isn't a solution. Also 'software construction' (in general) is far too busy adding (mostly marginally useful) features, generating complexity, generating bugs.
That reality, however does not imply that this is the only way it can be.
100 years ago explosions of steam boilers were not uncommon and our understanding of material science and structural design had some very large holes. Today there are very conservative codes restricting steam power design and PE's who work with these things are required to meet / certify those codes.
Iff the only way to begin to hold software to a similar level of quality requires establishing a PE-stamp for software, then the lawmakers may well come to require same. They don't any more care how it happens then thier predecessors did about setting up the current system of PE licenses, all they care about is getting results and ultimately that will have to mean assigning liability.
That could come about thru several approaches, the point I think is that when (not if) it happens there will be a lot of pain in the process, because the currently sloppy standards of quality in software design will have to go.
So I don't think it's a matter of whether or how but of when. And the pain will probably be felt across all sectors.
Frankly, however by the time any practical progress is made I think OSS will be an even more deeply embedded part of the landscape. I for one hope we're succeeding more in improving actual code quality and less on 'looking like windows' which seems to be the current trend in many OSS systems.
Linux is Linux, if One need clarify their dist: <Dist>/GNU Linux
bsds are of course just BSD
Spoken like a true bandwagon liberal...
Hillary in '08 right? Right!! LOL
I dont see what the big deal is, we have licensing for other professions doctors, lawyers, and also engineers (often times you need to be licensed to do government contracts). If implemented correctly it keeps out less qualified individuals ie hacks and kiddies who can write barely working code that is full of holes and keeps good programmers employed.
The way licensing works in building design and construction basically boils down to the idea that some SINGLE PERSON holds responsibility. Building codes require that construction documents be stamped by a professional architect (or engineer), whose qualifications are also set down in state law. That person:
... well ... "not so secure" version. They can't say that they are the same, because they can't prove it without opening the source.
- Is responsible for the design complying with codes (also set in law)
- Bears legal responsibility for errors and omissions, for which insurance is carried.
- Does NOT have to be the person drawing the drawings or writing the specs. But if they are screwed up, it's his ass on the line, not his flunkies. It's up to him to discipline his people.
- Is NOT required to design every little thing. There are situations where local building codes do not apply, and therefor the drawings do not need to be stamped (some federal and military construction projects come to mind)
Why can't this work with software? Lets assume the Feds and State gov'ts require that ALL software purchased by them must be "stamped" by a licensed developer, said license to meet the requirements of etc, etc.
If some entity (individual, corporation) wants to sell their software to the gov't., there must be a "stamp" on it. That means that some INDIVIDUAL PERSON is saying "It complies with the codes (design practices?) under which it has been designed. That person carries the insurance, and can be held legally liable if something REALLY BAD (tm) happens.
Proprietary Source: Company M makes an operating system that they want to sell to the Gov't. Company M has a few individuals with PSD (Professional Software Developer) stamps who are the development team leaders. Company M pays their professional licensing fees and insurance. The PSD may not have read a single line of the code in question, but if he stamps it, it goes out the door. Company M pays out the ass for insurance, because the insurance company can't see the code, and therefor is taking a big risk. Cost of software is high. As for non-Gov't customers, Company M is in a quandary: either sell only the PSD stamped version with all the insurance load, or sell a "secure" version and a
Open Source/GPL: Mr. L has an OS that the Gov't wants to use, but Mr. L isn't a PSD and doesn't want to be. So the Crimson Chapeaux Company says "Hey - OUR PSD will stamp it and we'll carry the insurance." Insurance is cheap because the code is right there for review. Also note that The CCC is not *selling* Mr. L's software; they are selling the service of providing a real live person for the Gov't to go after if something bad should happen. In the meantime, non Government types that want to use Mr. L's OS don't have to pay for the PSD stamp, but they get all of the benefits, because there is no difference between the PSD stamped software and non-PSD stamped.
This could work, folks.
"As God is my witness, I thought turkeys could fly." A. Carlson
Programmers of designers?
You could argue that buffer overflow hacks are partly the fault of the CPU since Intel and PPC chips can't fully protect against buffer overflow attacks (when using OpenBSD).
Consider the many centuries we were building buildings before we had anything beyond a few guestimated best practices to assure that they wouldn't fall down. Eventually, the field matured and we figured out how to calculate the strength of a building in advance. Even then, it is only reletivly recently that we could do dynamic simulations. In spite of that, we still have mishaps.
Furthermore, we STILL are not at the point where we can guarantee that a building will hold up under attack. In fact, we are certain that ANY building can be destroyed using explosives. In fact, any device we invent can be destroyed and in turn cause destruction when deliberatly used contrary to it's design.
At the same time, there are levels of vulnerability that are clearly substandard. Buildings must not simply fall down in a light breeze and cars must not explode when you start them.
On the basis of that, licensing and liability will need to be restricted to a very small subset of applications, and they will be very expensive. For the same reason that most of us don't have bomb proof cars, most software will not be built to that standard.
The other case would be grievously stupid design decisions such as having email from anonymous strangers be executable or using gets for a publically acessable interface.
We will have good software the day software companies face the same kind of liability that, say, Ford faced for the Pinto exploding gas tank.
Employers say that people will be paid more but watch everyone end up being paid LESS for not having the license, while those that get the qualification will get the same salaries as now.
How much do you want to bet that salaries will remain the same while employers only hire those that are licensed? Those that are not licensed will probably get paid less (becoming an underclass). There is nothing better to a capitalist than shifting risks to the worker (software developers are now liable) while not wanting to pay for it themselves.
Sivaram Velauthapillai
Sivaram Velauthapillai
Seeking the meaning of life... @slashdot of all places
I am forever the cynic. But why would a task force so important to the idea of secure software appoint a 21 year old "security researcher to chair? And he has spent half of his life working on Internet security? Since he was 10? Please! I am getting dizzy from all the spin.
Type "program verification" into Google, and you get a "Work at Google" paid ad.
And we all know that with the Business Software Allaiance as one of there is no possible way this could lead to the effective outlawing of Open Source (not allowed to contribute if you don't hold a license).
In all likelyhood, any government regulation over development or licensing scheme for developers will only lead to protecting the high profits of a few of the largest vendors and hurt everyone else in the industry.
Read, L
I dont think it's the developers writing insecure software that's the problem. It's the administrators. An administrator by definition is the person who administrates a computer: takes care of it, keeps it running, is reponsible for it's well being. It falls on his shoulders to determine that his system is secure. The majority of admins today are STUPID. And, by stupid, I mean, knows nothing about a computer. Think your typical MCSE. Does he understnad what a BIOS is, how it could potentially load insecure software? Does he understand how a kernel works, how a program interfaces with a kernel, the signs when watching a packet trace to see a hack attempt?
THe majority of company's these days set up intrusion detection systems that are suppose to email their admin when they're broken into. And then the admin is suppose to press some buttons to get a printout of what happened. There is very little competent thought. An admin needs to know and understand that which he is admining.
He also needs to know and trust the software he choose to run on his system. It's his job on hte line. He is tasked with protecting a system. That is what he is imployed for, if he fails it, he's fired. In the OSS world, he should be a member of all the mailing lists of hte software he works for, he should have experience and understand it's inner workings enough to trust his job on it.
Licenses developers? No. That's silly. Developers just produce stuff. License drivers? Sure.
I think there needs to be a common software security standard, like the common criteria (but actually useful). The materials need to be free, and they need to be able to be applied to most software products. Something an admin can use to certify his own software.
Yes, I realize this is far from what our industry is now. The problem we have is people deploying software they do not understand nor know how to handle. Install IIS, install Exchange, click a few buttons. No thought given to what went on behind the scenes.
Car analogy: A mechanic gets a readout from the cars computer that "Everything is A-O-K", but there is a rattling when he turns the engine on. What does he do? He knows how the car works, so he determines the source of the problem.
That condition comes from the licensing of civil engineers, too. You have to be licensed to be a civil engineer, pass some fairly effective exams and all that. You can be held personally and professionally liable for screw-ups in your designs. But there's another aspect: you have control. If you're the civil engineer on a project and you specify that it needs X grade of concrete, that's it. If management tries to say "That's too expensive, build it using a cheaper concrete.", you get to say "No can do." and they can't argue. If they do, you make a phone call and the next day some gentlemen with badges show up to discuss the fines and penalties management is going to pay. If management fires you and uses the cheaper concrete anyway, the discussion will be about criminal charges on top of their liability, not yours, for any damages done because of their illegal substitution.
If licensing of software engineers includes everything that licensing of civil engineers does, including the "those who don't have the license do not get to overrule you on how the job gets done" provisions, it's IMHO a good deal. We ought to press for exactly that in licensing, because while companies would be highly allergic to it it'll play very well with the public. Think about public reaction when a structural failure turns out to have been caused by someone substituting shoddy materials for what was originally specified or otherwise not doing things the way the engineers said to do them.
I wonder if it's going to involve having sex with a zebra...
How about Windows developers get a licensed, FOSS ones don't and we measure (objectively) whether that makes Windows have fewer security issues?
Company M can self-insure the first million, the first ten million, the first one hundred million of it's losses and never feel the strain. Company M is a tough negotiator
I think it is about time that software creation was held accountable to a standard. If you could be thrown in jail for being sloppy, would you sign off on code you couldn't confirm?
Yeah right: Would you sign off on outsourced code? Would you allow management types try to bully you into approving something and just playing the odds? What happens when code from say somewhere outside the country is made almost entirely without any sign off, who then becomes responsible?
This is an attempt to divert attention from the real problem with software development, and for that matter business processes in general. Programmers and software engineers are, point-blank, not responsible for the quality or reliability of shipping code. Period. That responsibility lies with management, and the resources it chooses to devote to the initial design process (very important ... Microsoft didn't pay enough attention to this and is now paying the price in spades) and, just as significantly, to the quality-assurance cycle. Attempting to lay the blame for poor quality design and implementation solely upon the shoulders of the actual programmer simply ignores the root causes of poor software. The people that design software, and those that test it, are even more important to releasing a quality product than the programmer. However, the biggest problem that I've experienced in a quarter century as a software engineer is that management simply refuses to allocate sufficient time to initial design and prototyping. They want coding to begin as soon as possible after inception, and that often doesn't allow a good foundation to be laid before the design is frozen.
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.
The higher the technology, the sharper that two-edged sword.
I can definitely see the advantages of being licensed and being having a professional organization:
1) We get paid more.
2) others not acredited can not do our jobs. For example, at a company I used to work for, an Engineer was programing. Now could a computer programmer do an engineers job? No Way!
I was reading the first volume of Alexander Solzhenitsyn's The Gulag Archipelago the other night. (For those of you too young to remember either Solzhenitsyn or the Soviet Union it describes, go read it. Along with 1984, it ought to be required reading for citizens of putatively free countries.) The section I was reading dealt with the purges of competing socialist movements once Lenin's party had consolidated its power. Political dissenters were at this time -- 1924 -- being tried by special tribunals, denied counsel and contact with the outside world, and executed, first by tens, and ultimately by the hundreds of thousands.
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.
Proud member of the Weirdo-American community.
One of these talking points is to license software developers and make them accountable for security breaches.
It seems to really prevent all possible security breaches, you need to prove that the program is correct first - I don't know of many entities that even try to prove their programs. I have heard of a few telecom infrastructure programs, but remember the big SS7 outage caused by one tech some years ago? The SS7 code is probably better "audited" than most code but would that outage have been construed as a "security breach"? - Yes, after the lawyers were done with it.
What about how quickly the world changes after a program is released? You use the best encryption technology of the day, you prove your programs correct, not just audit the code or use "good" software engineering/management methodologies. But you used DES (back in the day) or MD5 more recently, then MD5crack comes along or quantum computing and suddenly you are responsible for a "security breach" because of some exploit that didn't exist when you created the program.
That is nuts, who would want to sign up for that?
Besides DJB does anyone even have the balls to reward people for finding security problems? Or even advertise security as a feature? OpenBSD (yeah, I know its dead, blah, blah, blah), pureftpd, NSA Linux
I expect not many others, because people expect code to have security issues.
Since security is such a big concern now (and in the past), I would think that people who wanted to show off their programming prowess would be bragging about how secure their code is. But no one does, that I know of - why? because its just damn hard to be sure that the code is perfect - which is what is required to prevent all possible security problems. So where are all these people with the big security cahones going to come from?
Can a program be proven correct for all inputs?
If it isn't stateless then can each permutation of state and input be proven?
Are all the protocols used by the program verified?
The impossibility of preventing security breaches seem to make this kind of government action more likely. Burn the witches!! They hexed our computers, and were seen in the woods cavorting with unaudited code fragments!
Clearly Microsoft would be forced to lobby for special exemption from these rules, otherwise no work would be done because their develoeprs would be in court all the time.
Mind you... that would be kind of selection of the fittest in terms of developers wouldnt it...
You cant make anything foolproof, they'll only invent better fools.
License is for something that is illegal or unlawful.
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".
That's the best way to make sure that applications are secure. Believe it or not, most developers care if there is a security problem in their software.
The problem with this whole idea is the assumption is this: Programs depend on libraries, libraries depend on lanuges runtimes/libraries and those depend on the OS. Of course you're also depending on the compiler not to produce buggy assembler code.
So with all of these layers can we truely say who is liable when something goes wrong?
GJC
Gregory Casamento
## Chief Maintainer for GNUstep
Now scale it up. A 20 story building collapsing is major. People die and so only licensed people are allowed to design and build them.
Anyone can put on a bandaid since there is not much potential to screw that up. But the prescription of most drugs and techiniques that penetrate the skin are only allowed by people with a license. (Insulin injections are a bit outside since parents can be trained into doing it for their childeren and of course older people can be trained to do it to themselves but they are not allowed to do it to outsiders)
Now to computers. Why do we allow the computers in an hospital monitoring the patients to be written by just anyone? MS software in monitoring software. EEEK.
Of course I can't really see how they are going to do it. All the other licensed fields are relativly limited. A doctor only has to work on humans who come in basically two different versions. Complicated versions to be sure but we have known for a long time how they are put together and so far noone has been doing any upgrades on it moving important bits around or making others obsolete.
Just becoming an expert on say windows requires you to know 4 different layouts. 3.11 (still used) 9? NT and now .Net.
Oh well. No doubt this will boil down to a MSCE. Something Human Resources put on the list and then is never mentioned again.
MMO Quests are like orgasms:
You may solo them, I prefer them in a group.
OSS has no problem with professional certification you get the source, review it, test it and certify it to a grade. The professional would do this or sign off. For closed source the process is the same except you don't have the source or your rely on the vendors professional certification.
I worked summers in an Architectural/Engineering firm before I got my degree for Computer Engineeering in 1979. The real way these firms worked at that time is that the Professionals (Registered Architects and Proffessionsal Engineers) supervised and sign off on the the work that was done by EITs (Engineers in Training - a degress but not yet passed the state boards) and Draftsmen and other technical people. This model can be used for software/hardware as well. There has been little demand or call for a state certified need for computer professionals in the last 24 years largely because the sales force said all the bugs will be fixed in the next "Gotta have" version.
Our social problem is the adoption of CPUs and related software to critical tasks in our society without review or certification for the tasks in a largely sales driven market. Having professionals review installed products would likely trim features and consider whole systems analysis of the effect of additions and changes. In the end this is a good thing because the professional at the install point can specifiy the grade and if the vendor fails he doesn't the the business.
The last point is that the State is responsible for the approval of the Professionals - so in effect the State is taking the work of people it has approved to be and act as Professionals.
In the end this just means a review of some level of quality on the software or hardware installed. We just don't take the word of the vendor.
that the BSA isn't going to give up.
Do you have ESP?
NT was given something like a "G5" security rating, BUT is was not attached to any network what so ever. Lot of good that certification did as Win2k and XPee were then built from this so called "secure base". The "system" is the problem not the programmers. Testing and certifing software for it designed and useful purpose, which EULAs negate, would be a starting point. Also I am sitting here on a RoadRunner connection using a Motorola SurfBoard modem. Why did I have to spend $45 for a SMC 7004VBR to secure it when 1-2 chips in the modem would have taken care of a lot of issues [log is showing 4-6 denied attacks every 5-10 minutes].
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.
Look at the bright side: there's always seppuku.
So, you say, we'll just test the fundamentals. Wrong! I sat for the California EE EIT (the pre-test for PE) back in the 80s: most of the test subjects were Civil, Mechanical and Chemical Engineering which no EE student gets any courses on, simply because there isn't even enough time in a four-year program to get everything in your own specialization, let alone the rest of EE, let alone any other field of engineering. What few EE question there were (less than 10 out of 200-odd questions) included out-of-date novelties such as vacuum tubes and subjects like rotating machinery and power systems, a hyper-niche of EE that certainly an IC designer like myself would have never had classes in. I recently looked into the exam again and the test is essentially the same 20 years hence, despite being already out-of-date 20 years ago! Conclusion: PE Certification == irrelevant waste of time for any modern technology industry.
This is precisely what would happen to Software Development Licensing: it will become a dubious and irrelevant hurdle that disadvantages US programmers against the rest of the world. Has MSCE certification somehow made Windows installations the button-down, high-security platform that Unix more often is without any universal certification standards? Unless you have lived in at cave in 2003...
Professional Engineer certification works for Civil Engineering and Mechanical Engineering only because the core knowledge of these fields either ceased to advance more than 100 years ago or advanced only slowly with adoption of new technologies developed by other, non-regulated disciplines like CS, EE and Mat'l Sci . By contrast, the core knowledge of CS and EE have changed on almost a decade basis. When I first stated programming 30 years ago, the state of the art of common usage was FORTRAN and COBOL; then came procedural languages in the 80s, and then OO in the 90s. Each generation radically changed what was fundamentally possible to implement.
As an example: my father is a California PE in ME who does HVAC work. The only major advances in HVAC in the last 50-75 years have come from importation of CS and EE discipline advances in computing and sensors. The basic lore of enthalpy, steam tables and refrigerants was complete in the 19th century and early 20th century. In CE, berm, dam and road design theory hasn't had major technical changes since the 19th century, in some cases the 18th century; only materials developed by other disciplines have changed the constants that go into the same design equations used since the 19th century. It is precisely this "last century/centuries" knowlege that dominates professional exams in these disciplines.
It just shows that the people advocating this know nothing about existing engineering certification/licensing or the history of engineering as a whole, and worse know nothing of software development despite possibly even being former software developers.
To adopt such a thing would only guarantee that what few software development jobs that remain in the United States, after globalization exported most of the rest, will finally be destroyed also. That may suit profit-seeking business interests and micromanaging government bureaucrats, but in terms of national interest it will assure that mission-critical software is only developed outside the United States which makes backing such a proposal nothing short of treason.