I recently had a very interesting conversation with Dave Hyman of Checkmarx, who asked me how I saw the future of cyber security (or information security, take your pick). Now, as I’m sure you´ll agree with me, that’s a fairly abstract question that can go a lot of ways. My friends will confirm that I enjoy waxing philosophical discussions like that, but given what Checkmarx does with code security, that is the direction this talk went. And there really is a lot to say about secure coding practices that I feel doesn’t quite getting the limelight it deserves. Any Information Security course or lesson in Security certification will stress that security should be part of the code design practice rather than being tacked on at a later stage; I couldn´t agree more. Unfortunately, security precautions made in the coding process, which turns a design into a working product, are often overlooked and that is a mistake.
(Before I continue: I should note that I am NOT a professional coder; if I make a mistake in my reasoning, please let me know.) In a paper I once wrote I referred to “industry standard” with regards to the amount of bugs per line of code. The argument being that as long as humans would keep writing software, the ´human element´ guarantees that we will always remain vulnerable to exploitable bugs and errors in code. Of course not all bugs lead to exploitable vulnerabilities, but a percentage will and that is a problem and a great risk. I dug up my source, a book called Code Complete by Steve McDonnell. The book points out that the Industry Average is about 15 – 50 errors per 1000 lines of code (The book was published by Microsoft Press, I am sure you won´t find it surprising that they mention that Microsoft applications have an average of 10 – 20 defects per 1000 lines of code). To put that in larger application perspective, Microsoft´s Windows 7 is estimated to have roughly 50 million lines of code; this means that if they adhered to the industry average, there are between roughly 750,000 to 2,500,000 defects in Windows 7!
Even if Microsoft´s code quality is well reviewed and above standard, we can estimate between 500,000 to 1,000,000 code errors in Windows 7! Any one of these could be mistakes that allow remote code execution, which is considered the jackpot for anyone trying to hack their way into the system. Mind you, these are just mistakes and mistakes will happen no matter what you do. A good quality control program should be able to detect and reduce this number of detected errors. Some/ Many of these code errors will lead to heavy security risks in the application and to the user. These coding errors are due to careless coding practice and inability to detect vulnerabilities. The code may function, but the code will be insecure. An excellent example of this is SQL Injection. SQL Injection is the ´art´ of being able to run SQL statements directly to the database backend of a website, either by using a form field or the URL box in the browser. By doing so, you can ask questions of the database that you really shouldn´t be allowed to ask, such as asking it to tell you all the usernames and passwords in the database. Or more commonly: all the credit card information of every customer in the database. This has been around since 2002 and there are several solutions available that prevent SQL Injection attacks. The fact that this technique is still responsible for the majority of major successful data breaches tells us that not everyone is aware of how proper coding technique can prevent SQL Injection attacks.
Many buffer overflow or buffer underrun vulnerabilities are also caused by not properly setting boundaries, which can be easily prevented by developers being more aware of secure coding techniques. Review of these techniques and code review solutions are what you can expect to learn at “secure coding” courses. We should seriously consider making these courses part of the norm for hiring programmers or developing programming talent. Many people will groan and protest at that statement, because it’s another burden on an already stressed industry. I agree that it is not the easiest way forward but courses and code review solutions may very well be the cheapest method to getting more secure software applications.
A secure coding class is one-off and relatively inexpensive, it beats having to actively hunt for and patch insecure code. Such an effort for secure coding must come from the software development industry itself. The end customer won´t ask secure coding because most look only at software ability cost. The customer trusts us that product is secure, and we as an industry, should accept our responsibility and enforce higher security standards on our products. This starts at practicing secure programming. At the rate we are adopting technology into our daily lives, we should start sooner rather than later.