Slashdot Mirror
Following Best Coding Practices Doesn't Always Mean Better Security
wiredmikey writes "While some best practices such as software security training are effective in getting developers to write secure code, following best practices does not necessarily lead to better security, WhiteHat Security has found. Software security controls and best practices had some impact on the actual security of organizations, but not as much as one would expect, WhiteHat Security said in its Website Security Statistics Report. The report correlated vulnerability data from tens of thousands of Websites with the software development lifecycle (SDLC) activity data obtained via a survey. But there is good news — as organizations introduced best practices in secure software development, the average number of serious vulnerabilities found per Website declined dramatically over the past two years. 'Organizations need to understand how different parts of the SDLC affects how vulnerabilities are introduced during software development,' Jeremiah Grossman, co-founder and CTO of WhiteHat said. Interestingly, all the Websites tested under the study, 86 percent had at least one serious vulnerability exposed to attack every single day in 2012, and on average, resolving vulnerabilities took 193 days from the time an organization was first notified of the issue."
..does not mean the house won't get broken into.
Following best architectural design practices doesn't mean your final building will be more secure.
Asking software companies if the require their developers to adhere to "best practice" won't lead to any usefull number at all.
Or does anyone think anyone would admit to use only second-best programming standards?
Let alone the question what programming techniques count as "best practice".
bickerdyke
If secure coding could be described by a few simple rules, coders would have already been replaced by programs.
"Best practices" is such a wonderful term; its sheer flexibility permits the person invoking it to assure his audience that he meant exactly what he said, even when he didn't say much of substance.
Now if you'll excuse me, I'm late for a game of bullshit bingo.
Write failed: Broken pipe
Secure code needs a holistic view. The usual component architecture that works pretty well for reliability and correctness, but not so well for performance, fails utterly for security. What is needed is a really competent secure software expert, that can do everything from architecture down to coding and is part of the team right from the beginning. This person must also have means to enforce security. Unfortunately, people that can do this job are very rare, and most projects do not have that role anyways.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
the OP or article has never written a code - its like saying a good looking dessert may not be good to taste; its this obvious commonsense?
Since that's unlikely to change good ol' social engineering is still going to be the primary tool in any would be assailants toolbox for breaking security.
Isn't that why they're called Best Practices and not Perfect Practices?
Well.. 'Best coding practices' is all in the eye of the beholder.. what one calls best practice might look awfull to another.. there really is no 'best coding practices'..
is more important than having managers that insist that engineers follow every guideline from the MS Press book, or whatever.
For example, one of the guidelines is always "do not use sprintf". But sprintf is perfectly safe in cases like this:
std::string myfunc( int i ) {
char buffer[80];
sprintf( buffer, "Your number=%d", i );
return buffer;
}
So what we sometimes see is a lot of mindless replacements of perfectly good function calls with slower, more difficult-to-read counterparts, where the process of substitution may have produced bugs. Ordered by management during scrum so he can rattle off metrics to his boss on how much more "secure" the code base is now than three weeks ago.
is that many 'best practices' are so undocumented and secretive that once you do find out about them as a security lead, it just becomes a ball of christmas lights to figure out the other moronic and insecure crap programmers are wholly convinced is pure and righteous. For example: string sanitization is a pretty wild goose chase.
Good people go to bed earlier.
This is an industry that relies on scientifically unsubstantiated approaches all the time. This is one example; things like Agile are another. It's uncanny how software engineers as group embrace fads with gusto on a regular basis.
I started reading the report and I quit halfway through the executive summary. This is one of those reports that says, "We documented a bunch of stuff happening. No idea why it happened, but let's speculate." I generally respect the folks at White Hat (have met several at conferences etc.) but I simply don't see the value in this report. I think they've lost track of why it's worthwhile to conduct a study in the first place. Perhaps Richard Feynman can help.
[Sir Garlon] is the marvellest knight that is now living, for he destroyeth many good knights, for he goeth invisible.
Now, Slashdot just took its title from the submitted article, so I'm not going to pin this one on the "editors". But TFA does not appear to provide any evidence to actually support the title. It implies that security doesn't improve as much as you'd expect, which in itself contradicts the claim; but what few examples are given are really of companies IGNORING best practices.
Admittedly the submitted article is just a summary of a larger report, so it's possible the report itself provides some sort of support to the claim; but then one would hope at least one example of that would've been included in the article.
#DeleteChrome
Probably because everyone I've ever heard use the term "best practices" has been a useless corporate suit with no clue how to craft software. The people who know their shit simply say that this part is good or this part is bloody fucking stupid.
"Best Practices" is one of those corporate buzzwords that offers the veneer of competence that suits use as a tool when talking to their customers or their own bosses. Do your best to stay away. Those guys are poison and will assuredly steal any thunder you try and make for yourself.
My take-away from the article was that training people about security issues worked, relying on application firewalls & automatic code review made things worse.
People: 1 ; Programs : -2. (or people 3, programs 0, depending on how you want to count)
Build it, and they will come^Hplain.
You could use passwords best practices (long, upper/lowercase+symbols+digits) so have your name and address as password, but that is not safe, no matter what password strenght checking program tells you.
Coding practices help you write nice, readable and maintainable code, with clean code you can work on securing it. Security in code is entirely a career in it's own right, it depends on the platform, the language, the protocols and more. So the first step is to make the code clean and maintainable, then you secure it, but don't group both together, you need the abstraction layer.
"best" practices. Stop reading Gartner.
Computer Science knows methods of achieving almost perfect security. It's called Formal Verification and it is fucking time-consuming, expensive and fucking complicated. You need to "design for verifiability".
So our pimps have decided we IT whores can't do that and instead do 217 "additional, great features plus facebook integration".
http://en.wikipedia.org/wiki/Formal_verification
It could also just be argued that the next gen of studios for languages have more robust debugging and error checking and even documentation on such issues. You might get the next version of visual studio that runs the integrity test or acid test to see what an app or website is lacking for security. The built in unit testing modules can be used this way too.... it all depends on how much time can be given to secure the apps or just write the code and meet the deadline. The most secure ISO certified code (such as military or banking) usually take years for something that takes months in normal development.