IT Employment

Secure coding guidelines: Are they the answer to buggy software?

People are using flawed software. And, the bad guys love it. A recently formed group called the Open Web Application Security Project is working to improve secure coding, but is it practical?

The debate rages on as to why software is vulnerable. That's good, but should not overshadow a larger problem: our increased complacency about using flawed software. In a previous article of mine: "Buggy software: Why do we accept it?", I asked several TechRepublic writers why that is.

The people who responded as well as the members who commented offered a wealth of advice. But, how does that get translated into solutions?

OWASP

I recently became aware of the organization, Open Web Application Security Project (OWASP ). If you are not familiar with the nonprofit, here is the group's mission statement:

"OWASP is an open community dedicated to enabling organizations to conceive, develop, acquire, operate, and maintain applications that can be trusted. We advocate approaching application security as a people, process, and technology problem. Because the most effective approach to application security includes improvements in all of these areas."

OWASP has several ongoing projects, all tasked with the following:

  • Protect: Create tools to guard against security-related design and implementation flaws.
  • Detect: Develop tools to find security-related design and implementation flaws.
  • Life cycle: Design tools to add security-related activities into the Software Development Life Cycle.

Secure coding project

The project that caught my attention is the Secure Coding Practices Quick Reference Guide Project. The team's goal is to reduce software vulnerabilities by following best-practice guidelines. To that end, they just published their Quick Reference Guide :

"A technology-agnostic set of general software security coding practices, in a comprehensive checklist format, that can be integrated into the development lifecycle. The focus is on secure coding requirements, rather than on vulnerabilities and exploits.

It includes an introduction to Software Security Principles and a glossary of key terms. It is designed to serve as a secure coding kick-start tool and easy reference, to help development teams quickly understand secure coding practices."

One of the project members, Keith Turpin, gave a video overview of the reference guide and what OWASP is trying to accomplish with it.

Some questions

Since software development is not my forte. I decided to enlist Justin James, TechRepublic's Programming and Development host. Better for everyone, that Justin offers his opinion on what OWASP is trying to accomplish. Here is what he had to say.

TechRepublic: As a software developer, what security practices do you enlist in the writing of software? Justin James: To be honest, I don't have a defined set of security practices. I pay attention to error-density rate. In my opinion, it is what differentiates good programmers from bad programmers. Everything equal, bad programmers have a higher error count. And, that translates into more exploitable vulnerabilities.

The following points are things a security-conscious programmer should do:

  • Writing clear, concise code: If the worst developer on the team cannot understand it, it is too complicated. Being able to understand the code and find/track/fix bugs is critical.
  • Not using C/C++: I've been writing the Patch Tuesday piece for a few years now. I see the security issues that come up. Time after time, the root cause is a buffer overrun issue. Among the first and second tier languages (in terms of usage), only in C/C++ do you have the ability to write code that lets this happen!
  • Stand on the shoulders of giants: I, like the experts, do things like write encryption algorithms, and leverage validated libraries, components, systems, etc.; both open and closed source. I also pick my providers with care.
TechRepublic: What do you look for in software written by other developers? Based on that, what is your opinion of security practices currently being employed by software development firms? Justin James: Most security practices are efforts to mitigate risk and damage introduced by hiring bad developers. Truthfully, the industry is filled with fakes, frauds, and phonies that get hired out of desperation and kept around in the hope that they will improve.

I've been behind the hiring desk, and when you have a critical project waiting on manpower, you don't spend nine months finding a top programmer. I'm not talking about "rock stars" either. I mean plain, old fashioned, excellent programmers. They are rare.

My previous answer addresses this one as well: Can they write efficient, clear, concise code that does exactly what is asked. If the spec is vague, can they competently fill in the blanks?

There's nothing wrong with security practices for code development, mind you. But, they would not be needed if, as an industry, we found a way to have qualified programmers focus on helping less-qualified developers write good code. Right now, programming is still Sanskrit and we don't even know about zero yet.

TechRepublic: What is your perception of OWASP and its role in the software industry? Justin James: I don't really have much of an opinion on them one way or another. But, going to their Web site and looking at their .NET Project, the information is out of date. I sampled about 25% of the articles and they were all at least five years old, which is a lifetime. TechRepublic: Having read the reference guide, what is your opinion of it? Does it touch all the right subjects? Justin James: Nearly all of the guidelines are tactics I hope developers are using anyway. That said, there are some "security theater" items in the list. For example, why say "invalid username/password" to obscure that a username exists, when "forgot password" will tell an attacker if the username is no good?

For the most part, it's a good guide. To implement all of the procedures would require a significant amount of code. Luckily, working within many of the popular frameworks will achieve the same thing.

TechRepublic: The Secure Coding Practices Reference Guide mentions that specific members of the development team should:

"Have the responsibility, adequate training, tools, and resources to validate that the design and implementation of the entire system is secure."

Is this approach currently be used? How important is it to have people with this skill set?

Justin James: Sure, forming a specialized team is possible if you are on a million-dollar project and have plenty of time. That is not the case for most developers. Following the guide would overtax their budgets and schedules.

Furthermore, software packages are increasingly large, complex, and difficult for individuals to grasp the code entirety. So, how are these specific members going to make a difference? What I consider a workable approach is having everyone involved buy into using secure development practices.

TechRepublic: Will software development companies have sufficient interest/motivation to use the check list outlined in the reference manual? Justin James: The key word is "sufficient". The failure of most companies to make security a priority is proof there is "insufficient" motivation. The OWASP list is nice, but it isn't anything we haven't seen before. In fact, I was familiar with the non-web specific material back in high school. TechRepublic: Finally, I wanted to ask if incorporating the checklist into the development process is the answer. If not, what in your opinion is needed? Justin James: I think the check list is part of the short-term answer. But, everyone has to realize something. It will take developers months to determine how OWASP's secure coding practices relate to their frameworks of choice, what changes are needed, and what code is required to address the changes.

In other words, it is difficult to turn this list into a set of recommendations for every situation. What's needed is to cross reference this checklist with system capabilities, using simple checkboxes. That way, the developer knows where they can breathe easy and where they need to work.

Long term, the secure coding checklist by itself, is not the answer. The amount of code needed to cover all the bases is ridiculously high. It would take weeks to get a basic "hello world" application 100% compliant with this list in the average system.

The answer is to have development frameworks and systems secure by design. Then, have developers build on their already-secure framework. Doing so will increase the probability of the entire software package abiding by the secure coding practices guideline.

Final thoughts

As I mentioned earlier, the members have plenty to say about buggy software. Do you think what OWASP is trying to do will gain traction? Is the checklist something you would use?

Thanks are due to Justin for his insight and taking the time to answer my questions about secure coding.

About

Information is my field...Writing is my passion...Coupling the two is my mission.

27 comments
mpollak
mpollak

C was bad programming language from start, trough bad implementation and low dependability as to how long is Long or how long is Short, only thing being certain that Short is shorter than Long. To ask developer to write something resembling Rootkit is insane, and leftover from times MS employed hackers who suceed to crash WINDOWS. That is where all problams started, at MS. Nowadays any good high level language compiler should produce effective machine code, unless it is also full of bugs because it is written in C. Problem of OS security is false one, as there would be enough that OS restrict execution on catalogued programs, that is ones installed by owner of computer. Any code imported from outside should be able to access only data choosen by computer owner as input, if input is not manual and files or databases are required. Server executed code is responsibility of server, just as all CGI scripts and HTML code. Before executing codes imported from outside, OS has to check them for subversive operations such as access of system files, and originator of such subversive codes warned and blacklisted for Internet use. Data about installed programs could be cryptographed with strongest coding so nobody from outside would be able to add their program to this list. End of problems!

mpollak
mpollak

I am IT professional since 1971, from time when anyone delivering buggy program would lose job. Of course that bugs were created, but we had system for testing programs on several levels. In early 80's IBM has developed foolproof coding for ASSEMBLER programmers, that I adapted so it could be usefull for COBOL and any other programming languages. Programs or computer applications really do have logical skeleton that do not change. Once standard is established, certain ready made names have to be used, and system of naming could be extended, specially nowadays when there is no limit on lenght of procedure names. It is true that in that time there were mostly batch processing of data, but I carried it over to interactive data processing over terminals too. Programs made this way could be changed by anyone and they cannot contain bugs, unless it is that nobody tests program before use. Commenting of the code is also mandatory. But real problem is OS that is not made to any standard by showeling code together and looking what would fall out or where would new code break application. According to official reccomendations from MS, if application break, then they repair old parts, instead changing new parts that were added. That is insame. So, first OS has to be made according to standards of programming so there would be no bugs there (OO programming should help a lot as it encapsulates once debugged code and it can be safely reused, unfortunately it seems that still now, 20 years after its appearance, there are still compiler writters that do not understand how to fully implement OO paradigm). Beside this, there is need for ONE programming language that everyone would use, as that way there would be much wider knowledge base and far less to learn (I learned and used 36 programming languages, many on several platforms and in several generations) specially if editor would have some AI built in that would made syntax clear and foolproof tested. It must be planned from start to be able to evolve and even to learn on examples of finalized programs. It has to be OO language to enable code reuse and have classes ready for every function that application would have. Functions or classes should go from simple to complex by nesting classes, For instance there should be Class Window to enable all possible operations that could be done on window, like buttons, menus, child windows, writting text showing pictures or drawing in frames. Window can have slots, that is place holders for its functions, with default name "Absent" if function is not used. Then while describing Window, one can specify: Scroll Horizontally and Vertically, Heading is Common or Heading is Informative or Heading is Active and so on. Menu is multilevel and adaptable (which would mean that lower levels are populated according to choices on upper levels) with choices showing, or Menu is standard..... That way programmer just have to choose what is needed and fill in procedures executed on Button press or last level of Menu choices if they are starting or stopping separate data processing and so on. I plan to make one such Language I would call LAST, that would have all functionality from other programming languages and several levels of programming, starting with assembly language programming, procedural programming, OO programing up to Class level assembly and finishing on top with application generator that would quiz programmer as to what has to be done, and then assemble this from standard program parts. Totally foolproof and bug free guaranteed!

bob
bob

Bravo OWASP! Peer-review in best practices management is the solution and open (creative commons) IT governance documentation a la http://OpenSDLC.org is my contribution. Keep up the good works!

sl174742
sl174742

... and the author is a "security consultant"??

Tony Hopkinson
Tony Hopkinson

standards, ever since I realised that getting called out at 2 in the am by a big hairy bloke losing his bonus was detrimental to my health. :p We are big believers in our team and use the Visual Studio FxCop addin on all our .net stuff, not as a check step either. It's on from the get go, you start coding to the guidelines in self defense after a very short period. You learn a heck of a lot about the language and the framework when it points at your code and tells you you've been a wally as well. If you can find a similar tool for your environment, plug it in and get weaving. Applying it to legacy applicatons is a tad more problematic of course, could turn from a bit of work to impossible, depending on the current code quality. Some security issues, including exploitable flaws, like range errors, buffer overruns, sql injection etc could mean a redesign of critical sectons of the code, and in our world of good enough, business will jib at the cost and find the benefit as hard to swallow as a large insurance premium for a risk they don't comprehend. Appropos of much who thinks the bloke at MS who said "We don't need to check for buffer overruns anymore" is currently looking for the poor twit who last changed that code... Enforced standards are as good a cya for a developer as anything else.

mcgoverntheory
mcgoverntheory

There is a separate OWASP project mapping the simplistic checklists to requirements of frameworks. Check out the OWASP Web Application Framework Manifesto. With that being said, everyone and their grandmother desires not only something unique to their situation but expect someone else to have done the work such that they can pull it off the shelf just in time. This is the mindset that results in insecure software. Don't participate in this way of thinking and instead say that if it doesn't exist, I will participate in creating it and sharing with others... http://twitter.com/mcgoverntheory

bmnfan
bmnfan

Looking at ESAPI it becomes apparent that OWASP provides only hypothetical solutions. ESAPI is too convoluted that nobody sane would implement it. It's an uber cumbersome pseudo security API. And making security features a chore to implement, doesn't exactly help their spread.

Michael Kassner
Michael Kassner

OWASP hopes so. Read about their project to reduce, even eliminate vulnerable software.

apotheon
apotheon

Now we just need to write a new editor from scratch that offers the basic power and flexibility of an extended vi interface and a few minor features from Visual Studio, and write it in Common Lisp to be more configurable and extensible than Emacs ever dreamed of being -- then use it solely to program in Common Lisp. Right? Oh, wait, that won't be sustainable. We need to invent a better LISP first. Maybe we should port CLOS to Logo and build from there.

Michael Kassner
Michael Kassner

I never claimed to be, either. If the article helps, then I see no problem.

Michael Kassner
Michael Kassner

I have written about both of those online tests. I agree they are helpful.

Michael Kassner
Michael Kassner

I definitely will look into it. Can you explain your last comment a bit more. I think I know what you are saying, but not sure. Thanks.

Michael Kassner
Michael Kassner

Perchance, have you looked at the checklist? If so, what do you think about it?

wizard_of_oz
wizard_of_oz

While I agree that C shouldn't be used for web services, it does have a place. Anything in the kernel and most embedded systems are a good example. Check out the CERT C Secure Coding Standard for best practices on reducing defects with security implications. It also really helps if you hire the right people. I know of a company that asks prospective developers to write something resembling a root kit and to find/exploit a buffer overflow as part of the interview process.

sl174742
sl174742

With all due respect (because I really did like most of your articles in the past), your bio at the bottom of this article says "Currently a [..] security consultant". But maybe I exaggerate, "security" is a very wide term. While most people with some interest in software security will have heard of OWASP, you may be specializing in different aspects of security. So sorry for this comment. Concerning OWASP, I'm not involved anyhow, but I'm aware of their efforts, and actually consider them beneficial for the community.

SkyNET32
SkyNET32

If he even does it. He's waiting for any decision on the FBI's proposal to insert backdoors into crypto. He's stated if they do that in such a way that it would put him as a programmer, as liable, he will never write it. :(

lshanahan
lshanahan

I read over it, and to me it seems to conflate application development and system administration. For example, authentication and password management is something that should be handled by a back-end server and the server OS. A front-end application should be responsible for securely handing off user credentials to the server. My point here is that the checklist dumps a lot of responsibility onto the people writing code. It would be better if principles of good system administration were segregated out into a separate checklist.

apotheon
apotheon

Good points. It's worth noting that Justin did not specifically say that C has no place in the world. He just pointed out that, for purposes of security, it is a good idea to avoid it. The unspoken condition there is "if you can". From what I know of Justin James, I'm pretty confident that's how he meant his statement to be taken.

SkyNET32
SkyNET32

Just one side of a multi-facted issue surrounding security best practices. :D

Michael Kassner
Michael Kassner

For straightening me out. What you suggest is plausible.

SkyNET32
SkyNET32

I am referring to a software development company who's management is breathing down their employees necks who code the product's they are selling - I was painting a scenario where management is always stressing out and distracting coders with deadlines and such, which make them rush out software when it hasn't had good ample time to be audited. I wasn't referring to a corporation and their general employees and how their policies are set up to log into the network. -Philip

Michael Kassner
Michael Kassner

A Steve Gibson fan. All he uses is Assembly. His programs are amazingly small for what they do.

Michael Kassner
Michael Kassner

Administration and writing the code are two different things. Are they not? How a user logs on would have to be first implemented in the software development. If I understand correctly.

SkyNET32
SkyNET32

That will teach them! Well, ok, maybe not; humans make mistakes, even writing in Assembly. I agree with Justin though, that more secure languages should be used for coding in, instead of using others, but programmers are under the gun all the time, so I think what should be incorporated is an administrative policy that says essentially, "I will serve no code, before its time". Then, programmers won't make so many mistakes because they won't be distracted by management, the resulting product will be awesome, clean, secure, (or at least MORE clean and secure) and future auditing will be done with minimal effort.......(are you listening Adobe? :D ) Anyway, that's just my two cents.. I'm not a coder but I have a lot of respect for those who do. Until we have machines writing code, humans will always inevitably make a mistake here and there. We should try to minimize those 'bugs' as best we can. Having some fundamental "secure practices" would help, no?

Justin James
Justin James

Yup, that's exactly how I meant it. There's another unspoken rider to that too... anyone who's working on the things where C/C++ is a "must use" tool (kernels, drivers, databases, etc.) should be, by default, a heck of a lot more skilled, experienced, educated, cautious... in a word, "better" than the typical Web developer. At least, I hope so. Then again, I think of all of grad school students who spend time working on these things, and I shudder. While they know more about CS theory, OS design, etc. than I ever will, I have a lot more experience with simply thinking things through and knowing how to write good code as a principle. :) J.Ja