4

The title should be fairly self-explanatory.

We need to update our coding standards, and as part of this process we've been asked to try and follow an industry standard from a recognised/knowledgeable body rather than just rolling our own. It allows us to demonstrate that we're using widely recognised "best practice" and avoid the accusation that what we've adopted it a pointless waste of time.

I found a few examples, but they mostly seem to be quite loose and generic.

https://security.berkeley.edu/content/application-software-security-guidelines

https://www.securecoding.cert.org/confluence/display/seccode/Top+10+Secure+Coding+Practices

We do both web and desktop development, using the Microsoft stack. So something widely applicable across environments but targeted at MS languages would be especially helpful.

Bob Tway
  • 3,606
  • 3
  • 21
  • 26
  • 1
    [Why is asking a question on “best practice” a bad thing?](http://meta.stackexchange.com/a/142354/218240) – Dan Pichelman Nov 26 '14 at 17:05
  • @DanPichelman Thanks for the warning. But that's kind of why I'm specifically asking for semi-official documents on the subject. If that's still off-topic, is the another SE site where it might be on-topic? – Bob Tway Nov 26 '14 at 17:09
  • 1
    Asking for off-site resources is another problem / reason for closing questions. Why do you need to update your standards? Put another way, what problem does updating your standards solve? – Dan Pichelman Nov 26 '14 at 17:23
  • 3
    How secure is "secure"? Security is a practice in risk management. – Telastyn Nov 26 '14 at 17:24
  • 1
    [Microsoft Security Development Lifecycle (SDL) – version 5.2](http://msdn.microsoft.com/en-us/library/windows/desktop/cc307748.aspx) – JensG Nov 26 '14 at 23:30

2 Answers2

4

Software or system security hugely depends on the type of system being designed, the data it stores and the regulatory/contractual environment it is used in. Most organizations often cannot articulate the level of security required in the systems they produce, either.

Personally, I think about security on three levels. First is the highest level: the business level where management decides the risks to the business, usually referred to as Enterprise Risk Management (ERM) using frameworks like COSO, or IT governance, using frameworks like CoBIT or TOGAF. Organizations do not have to use a recognized framework but it can help ensure issues are not forgotten and help prioritize otherwise easy to dismiss non-functional requirements like security.

This also includes compliance, such as industry-specific law like HIPAA's Security Rule for health information, contractual obligations like PCI-DSS or buyer specifications like FIPS 140-2 or Common Criteria). Each is verified in different ways.

Second is the development organization level: what practices the organization should undertake when developing a system. Several standards or frameworks exist, such as:

  1. The Building Security In Model (BSIMM)
  2. Safecode
  3. Microsoft's Security Development Lifecycle

These recommend different practices to use at different stages of software development. For example, many frameworks recommend threat modelling to detect design flaws early (where they are cheapest to fix), adhering to secure coding guidelines and using static analysis tools to find flaws as code as written then penetration testing afterwards, using tools that emulate common attack methods.

The third is guidance for each of the specific practices. Focusing on Microsoft coding practices, as mentioned by the OP, the challenge with the Microsoft online documentation is, while there is a lot of it, much of it is out of date. Instead, focus on OWASP for the web side. OWASP approaches each vulnerability from a vendor neutral perspective then links to vendor-specific mitigations.

While it focuses heavily on C++, consider Secure Coding (link is to the Amazon page) if for the desktop side and the follow up book on secure coding for Vista. Microsoft's MSDN Security Center collates information on Microsoft tools and libraries.

If you want vendor-neutral training or certification on secure coding, consider the SANS courses or (ISC)2 CSSLP. Remember, security is not just about the code - ensure your operations and IT staff have also considered security in their infrastructure design, your QA know how to test security features and your architects consider security (indeed, IASA considers security as one of the four main groupings of quality attributes).

akton
  • 6,912
  • 31
  • 34
2

Check out the Owasp secure coding guidelines.

and then check out the PCI-DSS standard. While PCI are guidelines for credit card processing, they can be used as a guide for having secure processes and code.

Peter K.
  • 3,828
  • 1
  • 23
  • 34
Rocklan
  • 4,314
  • 1
  • 15
  • 29