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.
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".
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."
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)
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?
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.
... 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.
- 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.
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!"
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.
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.
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.
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.