Language agnostic secure coding guidelines/standards?

[jsteven at cigital.com (John Steven)]

All,

James McGovern hits the core issue with his post, though I'm not sure how many organizations are self-aware enough to 
realize it. In practice, his philosophical quandary plays out through a few key questions. Do I:

1) Write technology-specific best-practices or security policy?
2) Couch my standards as "do not" or "do"?
3) Cull best practices from what people do, or set a bar and drive people towards compliance?
4) Spend money on training, or a tool roll-out?

See:
http://risiko.cigital.com/justiceleague/2007/05/25/a-mini-architecture-for-security-guidance/
http://risiko.cigital.com/justiceleague/2007/05/21/how-to-write-good-security-guidance/
http://risiko.cigital.com/justiceleague/2007/05/18/security-guidance-and-its-%e2%80%9cspecificity-knob%e2%80%9d/

Though old, these posts still seem to help.

More recently, this argument has most frequently taken the form of "language specific guidance or agnostic security 
guidance?". this has begun to play out in Andrew's post quoted below. Though there's tremendous value in agnostic 
guidance (especially because it applies well to languages for which specific guidance or tool support doesn't yet 
exist, and because it withstands time's test slightly better). But, what OWASP has documented is a false victory for 
the proponents of agnostic guidance--citing  its language independence. It, like any decent guidance, IS 
technology-specific, just not on any particular language. It's closely coupled to both the current web-technology stack 
as well as a penetration-testing approach (though, frankly that is fine). Move outside of either and you're going to 
find the guidance wanting. Saying the OWASP guidance is better than language-specific guidance is like getting caught 
in the rabbit hole of Java's "single language compiled to a virtual machine that runs anywhere" vs. .NETs "many 
languages compiled to a single format that runs one place."

High-minded thought about whether or not one should proceed from the top down (from a strong but impractical to apply) 
governance initiative or from the bottom-up from a base of core scanning capabilities afforded by a security tool has 
won me little progress. it's frustrating and I give up. We needed a breakthrough, and we've gotten it:

As a result, we've built a tool chain that allows us/our clients to rapidly implement automated checks whether they 
have a static analysis tool, rely on penetration testing, or desire to implement their security testing as part of a 
broader QA effort. The 'rub' is that we've stayed technology-specific (to the Java EE platform)--so all the appropriate 
limitations apply... but recently we were able to deploy the static analysis piece of this puzzle (which we call our 
Assessment Factory) and automate 55% of a corporation's (rather extensive) security standards for that stack in 12mhrs. 
That's ridiculous (in a good way).

So, in my mind, the key is to get specific and do it quickly. Deciding whether or not to get language or 
technology-stack specific is a red-herring argument. The question should be: are you going to implement your automation 
with dynamic testing tools, static analysis tools, or say, a requirements management tool such as Archer.

If you're going the dynamic route, focus on technology-specific guidance. Download the OWASP security testing guide. 
Conduct a gap analysis on the guide: what can you automate with your existing test harness? If you don't have a 
harness, download Selenium. Once the gap analysis is done: get to work automating iteratively.

If you're going the static route: focus on language-specific guidance. Begin customizing your tool to find vulnerable 
constructs in your architectural idiom, and to detect non-compliance to your corporate standards/policy.

It's really not as bad as it can seem. You just have to remember you won't achieve 100% coverage in the first month. 
Though, any seasoned QA professional will tell you--expecting to is ludicrous.

----
John Steven
Senior Director; Advanced Technology Consulting
Direct: (703) 404-5726 Cell: (703) 727-4034
Key fingerprint = 4772 F7F3 1019 4668 62AD  94B0 AE7F EEF4 62D5 F908

Blog: http://www.cigital.com/justiceleague
Papers: http://www.cigital.com/papers/jsteven

http://www.cigital.com
Software Confidence. Achieved.

________________________________________
From: sc-l-bounces at securecoding.org [sc-l-bounces at securecoding.org] On Behalf Of Andrew van der Stock

The OWASP materials are fairly language neutral. The closest document
to your current requirements is the Developer Guide.

I am also developing a coding standard for Owasp with a likely
deliverable date next year. I am looking for volunteers to help with
it, so if you want a document that exactly meets your needs ... Please
join us!

On Nov 12, 2008, at 19:21, "Pete Werner" <peter.werner at gmail.com> wrote:

> Hi all
>
> I've been tasked with developing a secure coding standard for my
> employer. This will be a policy tool used to get developers to fix
> issues in their code after an audit, and also hopefully be of use to
> developers as they work to ensure they are compliant. The kicker is it
> needs to cover things ranging from cobol running on a mainframe, in
> house network monitoring software in c and perl through to web and
> desktop applications in java or .net.
>
> I've been doing some searching to see if there is anything similar
> online, but everything i've found is mostly focussed on web
> applications or language/platform specific. Does anyone know of
> something that may be what I'm looking for?
>
> It's basically going to be a checklist where every item will be
> something that can be audited, and the things that aren't relevant to
> a given application can be ignored. The broad sections I have so far
> are:
>
> Input/Output handling
> Session Control and Management
> Memory allocation and Management
> Authentication Management
> Authorisation Management
> Data Protection
> Logging and Auditing
> Application Errors and Exceptions
>
> Thanks in advance
> Pete
> _______________________________________________
> Secure Coding mailing list (SC-L) SC-L at securecoding.org
> List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
> List charter available at - http://www.securecoding.org/list/charter.php
> SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com
> )
> as a free, non-commercial service to the software security community.
> _______________________________________________
_______________________________________________
Secure Coding mailing list (SC-L) SC-L at securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
_______________________________________________