Getting Started with Secure Coding

...seems like a good January topic, while you are losing weight, biking to work every day, and buying only organic produce, why not improve your company's software security as well? Gary McGraw started a good meme on this getting started topic which I annotated here.

One of the problems is that outside of finance and defense most organizations are still at a Hello World phase of secure coding. They will have some line item that says "Application Security" or Secure coding or some such and then try to lurch enterprisingly towards a solution. This could result in focusing on secure SDL process, static analysis, WAFs, black box scanners, training, xml security gateways, or a whole host of other things. Each of these has some value, but you can't do them all if you are just getting started, and they will all send you down a different path (especially if you lack a framework as Gary suggested in his article (note here is a sample framework I worked on)). So anyhow, instead of just "doing app sec" or somesuch it pays to have a clear set of goals and then choose the tools and processes that align with that.

The choice depends on understanding the value proposition of each of these spaces, the analyst community provides little to no help on app sec, the context that should be provided by a gartner or other firm is often misleading, irrelevant, or reeks of "a firewall and ssl will do ya"-style advice...typically the vendors are no help whatsoever "our product is all you need for security"...so that leaves the auditors to show and pummel people with checkbox Olympics, and a few motivated employees to rise above a identify, define and create something valuable.

It should be easier, because the hard part is still in front of you. What the people in these companies with their hands on the wheel need are indicators for use for software security tools and processes, specifically use this when a,b,c are true and not when x,y,z are true. I took a pass at this in terms of getting started with Phasing security into the SDL and defined four main ways I have seen to get started - top down, testing and validation, start in the middle, and training. I will also post some getting started indicators for use for other domains in future posts. If you have ideas or comments on topics for getting started let me know.

Comments

[dre]

I suggest making changes to the way quality testing is done before you can add in secure coding practices.

For example, adding continuous-prevention into the lifecycle is the number one thing companies can do to increase secure coding practices with very little overhead/cost.

Secondly, changing from hiring/retaining Software Quality Engineers (SQE's) to hiring full-time developer-tester(s) (familiar with continuous integration -- coding standards, unit testing, mock objects, code coverage, static analysis, build servers, integration testing with test harnesses). This is mostly a shift towards test-driven development (TDD) and Continuous Integration (CI). Some may feel that this is too Agile (which I don't see how it's tied to Agile, you can use CI with any development paradigm). Also, besides just TDD, behavior-driven development is also worth a look.

I also feel that CWE-Compatible solutions are very important to the secure coding process, but these are mostly integration phase tools and programming phase tools. Even Fortify SCA and Ounce are mostly required to be used during build-time. There are other developer tools such as DevInspect or AppScan DE, but these are too much for any developer. These sort of tools should be run during integration and have their output verified before release. Putting any tools in the IDE besides developer tools (PMD/FindBugs/EclEmma and PREsharp/FxCop/NCover count as development tools) is likely a mistake. Counting on QA (SQE's) to test for security very much is likely a mistake.

As far as the carrot/sticks argument goes... we need to be getting metrics at integration on every developer's components/code and REWARD the ones that consistently avoid CWE issues. Penalizing any of these people is likely to backfire.

I have started to come about face on secure coding. My new interest is moving towards what can be done before the programming phase and integration phase. During requirements/design (especially HLD), tools and inspection can be done in addition to risk analysis. Choosing a framework such as HDIV is going to go a long way, but I've also come about face on secure frameworks as well. Using an ADL such as UML 2.0 is good, but only works on large projects, where you can accomplish a working model and still take up less than 10% of the time and budget of the overall project. Requirements analysis using NASA SATC's Automated Requirement Measurement Tool (ARM) or IBM Rational RequisitePro is recommended for these types of large projects before HLD or UML modeling begins. Afterwards, using Cigital/BSI Architectural Risk Analysis in the HLD with good requirements is going to help significantly. I prefer looking at tools like PTA, TAM-E, or Octotrike for this purpose. After the UML is built, Klocwork K7 and IBM Rational Rose can be used to perform secure design inspection.

Even this is not good enough for me. Design inspection may eliminate 75% of security-related bugs, but what impresses me today is secure software architecture. Secure software architecture means that not only are components and connectors used (e.g. SOA), but that an existing architecture that prevents, detects, and recovers from design vulnerabilities is utilized for the application by design. Unfortunately, I'm only aware of the OWASP ESAPI Project which attempts to build on some sort of standard secure software architecture model. I'm investigating this concept more in-depth now, as I see it as a better future than secure coding, secure frameworks, and secure design inspection alone.