tag:blogger.com,1999:blog-4088979.post112687939531771942..comments2023-10-16T06:06:25.012-04:00Comments on TaoSecurity Blog: Thoughts on Software AssuranceRichard Bejtlichhttp://www.blogger.com/profile/13512184196416665417noreply@blogger.comBlogger5125tag:blogger.com,1999:blog-4088979.post-1128146992015196972005-10-01T02:09:00.000-04:002005-10-01T02:09:00.000-04:00This comment has been removed by a blog administrator.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-4088979.post-1127322821959100352005-09-21T13:13:00.000-04:002005-09-21T13:13:00.000-04:00I totally agree with the Anonymous poster. The pro...I totally agree with the Anonymous poster. The problem is most programmers are not introduced to secure programming practices from the very beginning. For example, when someone is learning C, the first thing they learn for I/O is something like:<BR/><BR/>char input_buffer[20];<BR/>gets(input_buffer);<BR/><BR/>Instead, they should learn is:<BR/><BR/>char input_buffer[20];<BR/>fgets(input_buffer, 20, stdin);<BR/><BR/>First impressions go a long way, and if secure programming is introduced from the get go then it will stay with developers. Better quality coding = more secure code. Certifications do not teach this either.John Wardhttps://www.blogger.com/profile/10741149622435353727noreply@blogger.comtag:blogger.com,1999:blog-4088979.post-1127237501640274292005-09-20T13:31:00.000-04:002005-09-20T13:31:00.000-04:00I think your 'thoughts' and the comments are very ...I think your 'thoughts' and the comments are very relevant, but<BR/>what about the [security] quality of the code? I know that the<BR/>threat angles are covered by other govt orgs and yes, of course<BR/>it's too piecemeal and uncoordinated - much like other intelligence<BR/>efforts. And I too have a low opinion of how well standards and<BR/>particularly certifications can improve the situation.<BR/><BR/>I'm still of the opinion that building high quality code is better<BR/>from a security viewpoint than poor code, and even that can be vastly<BR/>improved by refocusing on particular flaws that have defintie<BR/>security impacts. And we certainly could use new ideas for proper<BR/>testing (resources are always a problem). I think the software<BR/>assurance angle is correct in addressing this area.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-4088979.post-1126888215703349142005-09-16T12:30:00.000-04:002005-09-16T12:30:00.000-04:00The government should be more concerned with catch...The government should be more concerned with catching threats. It is the vendor’s responsibility to minimize the number of vulnerabilities in their product. And some ridiculous certification process is not the answer. A product may have passed some smoke-and-mirrors C&A process, but still be a piece of crap. Mr. Jarzombek is not the only one who wants developers to stop making “avoidable mistakes”. The issue is with education, not certification. A certification is nothing more than a piece of paper; it doesn't mean that the developer is proficient in anything. Take the MCP for example. I have worked with tons of MCPs who basically went through the motions for certification, but for the life of them they couldn't actually write any solve any sort of problems, develop solutions, or write any “real” code. Developers typically do not learn how to write secure I/O to prevent buffer overflows, proper memory management, or even something as more basic as don't use C for tasks where a higher-level language with type-safe strings and array bound checking would be more appropriate. Granted, languages like Pascal are not immune from buffer overflows, but they are much less frequent due to things like bounds-checking and variable length strings. If developers would learn something other than C and add more languages to their development arsenal, they would learn how to pick the proper language for the task, applications would be much more secure. <BR/><BR/>And as far as "rouge programmers", if companies allow their internal or outsourced programmers to write obfuscated code for any reason, it’s a reflection of the quality of the company and their product. If they outsourced code to be merged into their product without review from a senior developer, then they are asking for trouble. The standards for development need to be changed across the board. For example, I require all of my developers to write their code in easy to follow logical blocks that are clearly commented, and I require code to undergo peer review by another developer. If those requirements are not met, I make them do it over. There is no place in production code for obfuscated code, because the coders who write that are show offs, and I have no tolerance for “cowboy programmers”. <BR/><BR/>The biggest issue is with PHB's who make the product decisions in their organization. Too often you have these jack asses pick a product based on what the sales force have sold them on. A company can have a first-string, world-class sales force but a third rate product. Managers are not knowledgeable to know what to look for in products, and as a result, usually pick garbage with potential vulnerabilities. <BR/><BR/>These are all issues that the industry needs to address within itself. I don’t agree that these problems are too difficult to deal with. The industry used to apply certain standards to software back in the day. The problem now is that programmers are a dime a dozen and lazy to boot. We have too many of the Gen-X and Gen-Y kids who decided to hop on the IT bandwagon when it was the booming industry, and they did not have the proper mental aptitude to be programmers. As a result, the market is saturated with garbage programmers, even more so after the bubble burst.John Wardhttps://www.blogger.com/profile/10741149622435353727noreply@blogger.comtag:blogger.com,1999:blog-4088979.post-1126884229388600392005-09-16T11:23:00.000-04:002005-09-16T11:23:00.000-04:00I work for a federal department which recently com...I work for a federal department which recently completed a C&A review. Very little of what sysadmins routinely do was changed as any result. Getting the information in all the blocks on an 80 page Word document exactly right was the hard part. The inspection was also MS specific. Not one inspector even looked at my BSD and linux systems. I was looking forward to the opportunity of objectivley comparing open-source systems with Microsoft but it never happened. <BR/><BR/>It was only a paperwork exercise. Too bad it's lasted 20 years.Anonymousnoreply@blogger.com