One of the most popular posts that I’ve made had to do with the issue of writing code.  (see Security v Development)  This is important because we spend a lot of time, money, and effort trying to compensate for errors and omissions made when code isn’t properly checked and validated.   One of the points that I brought up is many software engineers have never been taught to code securely.  When the subject of security did come up it was often something that they’d “take care of later after we get the system working.”

This is another reason that I was overjoyed to read CSO Senior Editor Joan Goodchild’s January 12^th article entitled Security Expert’s ID Top 25 Programming Errors: Group hopes list of 25 most dangerous programming errors will lead to safer software, better education for programmers. 

The article highlights the efforts of some of the most respected security experts and organizations in the world today.   The impetus for the initiative came from the U.S. National Security Agency (with some financial support coming from the U.S. Department of Homeland Security – National Cyber Security Division.) and it was managed by MITRE and the SANS Institute. 

The initiative breaks the top programming errors into three categories:

• Insecure Interaction Between Components (9 errors);
• Risky Resource Management (9 errors);
• Porous Defenses (7 errors).

The significance of this initiative can’t really be understated.  Prior to this we took a symptomatic approach by focusing on the vulnerabilities created by programming errors.  With this initiative we can change our focus to what is causing the problem in the first place.   Each error is accompanied by extensive prevention and remediation steps that can be used by programmers.  The information is spread out between the SANS Institute and MITRE websites  (PDF Document link provided) but it appears to be well cross referenced so as to be easy to use. 

If you are in any way connected with the development of software (anything from managing the project to writing actual code yourself) I urge you to check out the Top 25 Programming errors at either the dedicated SANS Institute or MITRE websites.

Tags: CSO, Department of Homeland Security, DHS, Joan Goodchild, MITRE, National Security Agency, NSA, programming errors, SANS Institute, Secure Code, secure programming, Security vs Development

The issue of secure coding has been around since the first program was hacked by the first hacker and was caught.  I am sure that someone asked the developer why he coded it that way and probably got a blank look in response.  As Information Security (INFOSEC) professionals, we are often quick to fault the developers for our malicious software woes and for the most part, we have good reason.  Software products are often raced to market to capture the almighty dollar.  Software vendors often seem to pay lip service to validating their code before they go to market.  I came up with an adage when I was actually involved in day-to-day IT operations.  I believe it works here as well.  It goes something like this: “Believe only half of what a software vendor tells you about his/her product and expect them to deliver only a quarter of what you believe.”   Software vendors (the big guys Microsoft, Oracle, Cisco, etc aside) often live off their reputation so I believe that some code checking and validation does occur but probably not as much as they say they do. 

 

Does this make the software vendors responsible for all the malicious software out there taking advantage of our naïve users and robbing us of valuable bandwidth?  In some manner, yes it does.  They are not the only one’s to blame though.  How many years have we put up with this type of sloppy code?  How many years have we put up with the endless cycle of patching?  Have we passed the point where sufficient pressure can be put on the big software vendors to pay more attention to security?  Apparently Microsoft is now trying to market themselves as having a secure operating system and is getting better (relative term) in getting their code cleaned up. 

 

In a April 2004 article for Network World, Ellen Messmer quotes Steve Orrin, CTO at Sanctum as saying that “Many organizations try to stomp bugs by having the chief software architect and programmers work in a formal process with the security manager’s staff as part of the code-evaluation process.”  While this is a good development, Ms Messmer goes on to point out that, Microsoft employed “about a dozen of these security specialists to interact with about 20,000 software engineers.” 

 

Secure coding can be said to start at home.  I have talked to too many software engineers over the years that say that they never learned about security when whey were learning about programming or that they were required to take one class about secure programming.  I have heard too often from program managers on systems development projects that “we will worry about security controls later, after we get the system working.”  How much is the education system to blame for not teaching secure coding from the onset of a project?  How much of the “just get the thing working first” mentality comes from these days in academia?

 

There is a good article on this subject by David Wong; a principle consultant with Foundstone (at the time the article was written).  He points out that it is “impossible to build bug-free, vulnerability-free software.”  He approaches the point from a very realistic standpoint that software development, like INFOSEC itself, is an exercise of reducing risk to an acceptable level and by following best practices software developers can avoid 90% of the commonly exploited security vulnerabilities.  He even indicates that there are automated tools to assist in the identification of these vulnerabilities.  He also points out that it still takes a programmer to fix them. 

 

This debate has been raging for years and unfortunately, everyone involved has stopped listening to the other side.  Programmers are blaming the flaws on hackers or the rush to market or the security department for pointing out these issues.  Security professionals are blaming the latest virus outbreaks on code that should never have been released in such a vulnerable state.  Both sides have valid arguments and the best solution is probably right down the middle of both camps.  Programmers and Software development companies need to invest more time and money into some of the simple measures enumerated by Wong before they release their software.  Security Professionals need to take some basic steps to reduce their risk as well by implementing sufficient controls, turning off unneeded services and limiting access to only what is needed to perform specific functions.  Is this the silver bullet?  No but it is quite a bit better than where we are at now. 

Tags: bugs, David Wong, development, education, Ellen Messmer, flaws, Foundstone, Microsoft, Network World, patches, Sanctum, Secure Code, secure programming, Security Focus, Steve Orrin

 

I don’t know if this happens to anyone else but I was reading Wired Magazine’s article on Google’s Open Source Android OS and all I could think of was the security implications of users being able to install anything they wanted onto their smart phones.  I kept trying to pull my mind away and focus on the promise Android brings to this market.  I am excited about it but security concerns keep sneaking their way in to disrupt those thoughts.  Now I don’t want to reopen the debate on whether open source is more secure than proprietary source code.  Better people than me have engaged in that debate; I can’t add any additional value there. 

My point is more that it can be hard to get excited about new technology and improvements knowing what we know.  It is times like this that I wonder why I couldn’t have taken the blue pill…

 

Tags: Android, Blue Pill, Google, Open Source, Red Pill, Secure Code, The Matrix