Comments on: Will code check tools yield worm-proof software?

Programs to catch security flaws during the software development process are gaining more traction, as firms look to hold software makers responsible for the security of their apps.

[landlines]

Microsoft needs to clean up its own act first

Microsoft is distributing Internet Explorer infected with the Spybot 'Alexa', and it routinely infects other programs with spyware which reports user data back to only Microsoft-knows-where. Why does anyone pay attention to this company's crocodile tears about security?

MS: Too Big to Bury

I'm no apologist for any software company that releases vulnerable code, including MS, but it's not that helpful to use examples of bad behavior (like the IE release cited) to blanket-condemn whole companies. It's going to take years - probably decades - to turn enormous code bases like MS' around. And that assumes they keep their eye on the ball, get and stay committed to secure coding practices across all the product lines. Something similar should be happening at all ISVs, though none get the attention/scrutiny of the largest.

Every software vendor, as well as every firm that uses packaged and custom developed apps to drive its operations, has a hell of a lot of work to do to begin to secure their apps.

Let's judge them by what they do in the aggregate over the next year or two and see if they can demonstrate some measurable gains.

Security vs Functionality

I am sick and tried of business requirements that often contradict each other. Any programmer can tell you that it's extremely difficult to write a piece of software that's both powerful and secured.
It's like saying driving a Racing Car at 200 miles per hour and guarante it will not crash ay any situation.
Most of the microsoft problems are actually design issues. They want to write powerful software to suit their business needs.
The static code analyzer tool can help the programmer to do their work. But the story totally
misses the point about software security as a whole. Such tools will not fix the embarrassing security hole for business people. Quit dreaming!!

[m_sadler]

Communications of the ACM - June 2004 Forum

"The Threat from Within

The special section "Homeland Security" (Mar. 2004) detailed external attacks on various computer systems but did not mention that threats also originate inside those systems.

The 9/11 attackers, for instance, were trained to fly inside ?the system? and allowed to board U.S. aircraft by that same system. Protecting U.S. computer systems requires Americans to assume those who would harm them might already be inside their development domains.

Two promising ways to examine U.S. software for security risks are path coverage analysis and concordance analysis. Programmers who discover unused paths should perform further tests or remove the suspect code. Moreover, they should generate a concordance for the code whereby high-risk words are highlighted and reviewed."

[m_sadler]

www d50.org

www.d50.org

Coding is a problem...but it's not the real problem...

Yes, it's appalling that commercial software is released with so many coding errors. Our knee jerk reaction, though, is to buy expensive code checkers to reveal these flaws instead of getting at the root of the problem...why competent programmers ignore fundamental programming things they learned in Coding 101 class. There's a bigger problem here, but you have to look under the hood to understand it.

More than 50% of the top 10 recommendations conveyed on websites and in "secure coding" classes are about quality--not security.
-Bound and mask input fields
-Limit inputs to buffers
-Apply rigorous error handling
-Release threads
-Clear temp data/objects
-Remove unnecessary code
-Log and audit appropriately

What we should be asking ourselves is not "why don't programmers code for security". Instead we should be asking ourselves what causes programmer not to code for quality.

The answer's easy because until the risks of insecure software became apparent in dollars and cents, companies considered the trade off of quality for functional as a risk they were willing to accept to bring products out to market faster than their competitors. Them days is over, boys.

Developers aren't stupid. They know what they should be doing. It's executive management and PMs that too often don't. They don't understand that coding and testing for security adds significantly to the cost and time it takes to create quality software. The programmer can't just make sure the program does what it's supposed to do. They now need to make sure it does ONLY what it's supposed to do. They can't just make sure the program recovers quickly, they now also have to code to make sure it fails securely. They can't just make sure a message reaches its destination, they need to make sure the person sending it is legitimate. All this takes extra analsyis and coding but the budgets and timelines for projects aren't expanding to accomodate this.

Management also doesn't typically realize that the need for increased security in programs results in a required shift in the job role. Management says "make it secure" but what does that mean? A program that handles rocket launch codes needs to be more secure than a giveaway product demo. The only people who can make this determination are the people in the company that judge corporate risk. That's not the programmer, or the testers, or even the PMs. It's management,and without management setting clear security and objectives for each product based on relative corporate risk, our project teams are stabbing in the dark.

We don't need to send our programmers to secure coding classes, nor do we have to buy costly code sweepers (though they are a good idea anyway). What we need to do is convince management the problem really resides with them--not the programmers--and until they accept the fact that building a quality anything requires appropriate time, skills and funds, our programmers are going to continue turning out insufficient code. They don't need training in remedial coding. If anything, they--and their PMs--need classes in Risk analysis and Communications, so when they talk, somebody will listen.

Bar Biszick, cissp, csqa
www.qualityit.net

[Duchman98]

Bang on point,mate.

[ttul]

The bad guys have tools too

The CanSecWest (www.cansecwest.com) security conference revealed some of the tools available to the "Dark Side" -- and we should all be scared.