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: [EMAIL PROTECTED] [EMAIL PROTECTED] 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" <[EMAIL PROTECTED]> 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@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@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@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. _______________________________________________
