I've come to a conclusion on M$ security

[secure_lockdown]

here is a little ditty....

http://crn.com/sections/breakingnews...cleId=48800553

nice way to save some $$$ & make Linux look like it's a lot more popular than it is.

whereever there is a buck to be made (or saved!) trust us humans to make sure it gets exploited to the fullest, eh?

[JoeMacDaddy]

As a security professional and someone who learned to code almost 30 years ago, poor code is poor code. The best security is the kind that is bilt in from the beginning not patched in later. Also, the vulnerabilities that we see today are a result of coding and design mistakes. It is a lot easier just to throw together code and not do the appropriate error checking in your program. Best practice is to always validate your data construct in your program prior to applying your logic. This way you push back the garbage and not process it.

In regards to M$Security, or the lack there of, is a business decision they have made to place profit before quality. They take the strategy of good-enough vs. good, less alone never great. It is their responsibility to sell a quality product. None of us would buy a car with such quality issues or with the warranty they provide (MS EULA).

We should all objectively assess your options. Read Walt Mossberg's article in the Wall Street Journal for an unbiased opinion.

http://ptech.wsj.com/archive/ptech-20040916.html
http://ptech.wsj.com/archive/ptech-20040923.html

Execrcise your right to choose.

[secure_lockdown]

JoeMacDaddy, you have a good point. But lets not forget:

If your silly microsoft OS on your PC malfunctions - you loose some data.
If your car malfunctions - you and maybe someone else die !

there is a big difference between the two.

[JoeMacDaddy]

MS technology is being placed in British Warships on weapons control systems. Someone can die.

[secure_lockdown]

Originally posted here by JoeMacDaddy
MS technology is being placed in British Warships on weapons control systems. Someone can die.

well that's a different story. maybe they should use closed systems.

[JoeMacDaddy]

They have dropped support for their UNIX systems and are moving to Windows. Several people have resigned over the issue.

[MrLinus]

The MS technology that is being placed on British and US ships/weapondry, etc. is not the same as what you get in the store. IIRC (from a news article I saw a while ago) it's a specialized, stripped down version.

They have dropped support for their UNIX systems and are moving to Windows. Several people have resigned over the issue.

Is there a source for this? (Nevermind, Google showed me)

[edit

There appears to be more here than meets the eye. While the issue of MS being a "foreign" product, the issue of OS and not knowing it's origins can also be questionable if there is concern about who creates the product. That said, I wouldn't be surprised if there was some strong suggestions political for this move as a support of the US. (but that's politico babble).

[ShagDevil]

As a security professional and someone who learned to code almost 30 years ago, poor code is poor code. The best security is the kind that is bilt in from the beginning not patched in later. Also, the vulnerabilities that we see today are a result of coding and design mistakes. It is a lot easier just to throw together code and not do the appropriate error checking in your program. Best practice is to always validate your data construct in your program prior to applying your logic. This way you push back the garbage and not process it

JoeMacDaddy,
I do agree on the GIGO theory and in some part, with your analysis of coding procedures. I was a mainframe programmer and from day one, my boss harped on quality over quantity. Our clients were no joke either (Honeywell, Tristar, Boeing) and didn't take too well to program errors. Granted, every program should be checked and re-checked against every possible situation that's humanly concievable but that's the problem...it's almost impossible to account for every single situation when you initially code a program. On new projects, we wouldn't even *touch* the computer for the first day or two. We constructed flow charts and desgined everything on paper first, to minimize bad coding logic. After a program was finished, off it went to our testing facility in California where they beat the snot out of our programs looking for any kind of errors well before the program went into production. Add to that, that the programmers vigorously tested their own programs well before it went to the testing facility, not to mention all the coding was reviewed by the other programmers looking for potentially bad logic. With all this, you would think our programs would be flawless, but time and time again, we would encounter some situation we never thought would occur and of course, it caused errors. My point is simple, while I agree that bad code is bad code, you can't also expect programmers to be omniscient. Maybe in some utopian world, programs can be coded perfect the first time around but back here on earth, the only thing that perfects a program is time and real-world conditions.

[BigDick]

Originally posted here by JoeMacDaddy
The best security is the kind that is bilt in from the beginning not patched in later. Also, the vulnerabilities that we see today are a result of coding and design mistakes. It is a lot easier just to throw together code and not do the appropriate error checking in your program. Best practice is to always validate your data construct in your program prior to applying your logic. This way you push back the garbage and not process it.

In regards to M$Security, or the lack there of, is a business decision they have made to place profit before quality. They take the strategy of good-enough vs. good, less alone never great. It is their responsibility to sell a quality product. None of us would buy a car with such quality issues or with the warranty they provide (MS EULA).

What you have there is a software development paradigm. For one thing there are the developers who feel that software is best when it comes from just sitting down and writing it, this is a popular agile development methodology known as extreme programming, for those of you who may not know, but then again there are other developers who feel that software construction is not too dissimilar from building a bridge or building, that it requires careful planning and design, while there are advantages and disadvantages to both, the fact remains, it requires a secure programmer to create secure software. That being said I think you're right. Patched security is on a much lower level than default security. Programming practices are the best way to heighten security and the best way to practice secure programming is to spend most of you development cycle working on the security, therefore you suffer from a slip in productivity (from a project management view point). So for the developer it is a lose - lose situation, program in a method that is secure, because you take your time and possibly suffer the consequences of lacking productivity, or meet the deadlines and worry about the consequences later.

I'm not sure if that was on topic, but you all have made some very good points.
-BigDick

[secure_lockdown]

Originally posted here by ShagDevil
JoeMacDaddy,
I do agree on the GIGO theory and in some part, with your analysis of coding procedures. I was a mainframe programmer and from day one, my boss harped on quality over quantity. Our clients were no joke either (Honeywell, Tristar, Boeing) and didn't take too well to program errors. Granted, every program should be checked and re-checked against every possible situation that's humanly concievable but that's the problem...it's almost impossible to account for every single situation when you initially code a program. On new projects, we wouldn't even *touch* the computer for the first day or two. We constructed flow charts and desgined everything on paper first, to minimize bad coding logic. After a program was finished, off it went to our testing facility in California where they beat the snot out of our programs looking for any kind of errors well before the program went into production. Add to that, that the programmers vigorously tested their own programs well before it went to the testing facility, not to mention all the coding was reviewed by the other programmers looking for potentially bad logic. With all this, you would think our programs would be flawless, but time and time again, we would encounter some situation we never thought would occur and of course, it caused errors. My point is simple, while I agree that bad code is bad code, you can't also expect programmers to be omniscient. Maybe in some utopian world, programs can be coded perfect the first time around but back here on earth, the only thing that perfects a program is time and real-world conditions.

someone should invent self-healing or self reparing programs. is that even possible?

didn't i just recently read an article about these new networks or something that "repair" themselves? i got to dig that up.