Concerns and Gotcha with Secure Programming Standards Development

Question

I have recently taken on the responsibility of developing a set of secure programming guidelines. My intention is to provide, using the OWASP Development Guide as a basis, several levels of requirements that correspond to our Sensitive Information Classification levels.

What kinds of issues should I expect to see as the standards gets developed and what have you found, after the fact, didn't actually work?

Answer 1

A few issues I found developing a team's secure programming guide recently:

• How will the guidelines be enforced or encouraged? Who will be responsible for ensuring that products developed in accordance with your guidelines? You need to ensure that this person can:
  • see whether the guides are being adhered. This means they need to look into code reviews and testing results. And that means that the code reviews and tests need to exist and be performed :).
  • "throw an exception" in the development process. They need the authority to say no, this build isn't secure, it can't go out.
  • inspire the team to take security seriously. It sounds like annoying management-speak toss, because it is, but you don't want your developers doing security begrudgingly (not least because they then become disgruntled employees, and you double your security headaches). This is particularly important if the "owner" of the app's security is an outsider to the development team, e.g. if you have a cross-cutting security team who get seconded to dev projects.
• Related to the above, how will management be seen to be taking security seriously? If they aren't then it's a social hint that the employees don't need to either. What are the rewards for committing to the standards?
• What feedback will you get on how the guidelines are working? You really want to understand:
  • What vulnerabilities were discovered during release
  • What vulnerabilities remained in the product, and why
  • The hard bit: what time was spent doing things that meant adhering to the guidelines but didn't impact the security of the product sufficiently to justify their cost? The closest measurable quantity I've found is "are we spending time on mitigating things that aren't in the threat model?", though spending lots of time on low risk items compared with higher risks is another red flag.
• How will such feedback be acted upon? Can the developers make changes themselves if they find an issue, or does it need to be escalated?

Answer 2

@Graham's answer is very good, a few additional points to consider:

• You'll need a different set of guidelines for each programming language / technology / platform. C++ coding guidelines, have a lot in common with .NET guidelines, but even more not in common.
• They should preferably be tailored to your projects context / needs / technology / etc (e.g. everything is client/server on the 2-factor-authenticated intranet, vs everything is only anonymous web-based internet...)
• They need to be detailed and prescriptive enough to provide clear guidance, but on the other should not be felt as onerously specific.
• Code samples are a must.
• Make it clear which items are mandatory, which are recommended but optional, and which are just one of their options. (Using the standard MUST/SHOULD/MAY usually works well here.)
• Related to one of @Graham's points, you need programmer buy-in - that needs to be done (as most things political) delicately. E.g. provide a "draft" version, for dev managers / team leads / etc to review, and give specific feedback on, wrt applicability to "their very special situations" (isn't everyone's?). Also in this way you may actually discover additional technologies in use, that you didn't know about (e.g. MVC, or AOP, or...)
• Training! Don't just dump a thick file on their desktops, go over the requirements with the developers, and explain what they mean, and why they need each one. (This is a good idea in general of course, but it also helps with the previous point of buy-in).
• If you have a solid SDLC, make this a part of it. If the teams are working "Agile", make this a user story. However they're working, you need to get across the message, that this is a deliverable. And it's a required one.
• If you don't have a SDLC, do one now! and make the coding guidelines part of that.
• "Several levels of requirements" - Don't have too many of these. They'll tend to get caught up in selecting the right one, and/or arguing with you about which one they really need (since one is less work than the other), and/or "discussing" which level each item should be required by... I think 2 (at most 3) should work, e.g. "High security" and "Basic security". However you go, ensure that it is super-clear which level they fall under.
• Make room for exceptions - i.e. authorize a specific project to get a pass on certain items, based on circumstances (and compensating controls). Preferably temporary. But well documented.
• Keep it updated, review every so often - with feedback from developers AND metrics, have a new version to meet any new technology they use, etc.