[liberationtech] Technical Guidelines for Auditing LibTech Apps

[Tom Ritter]

Hey all, a followup to my mail below.  I got a few offers from folks
and integrated some excellent feedback.  The github repo is now
public, contents licensed BY-SA.  The plan is to put a blog article
into our queue, which will pop up next week.  If you have suggestions,
please reply (off-list or on) and/or submit pull requests.

https://github.com/iSECPartners/LibTech-Auditing-Cheatsheet/

-tom


On 3 January 2013 18:41, Tom Ritter <tom at ritter.vg> wrote:
> Hi all,
>
> I'm working on a checklist/guidelines type document that aims to help
> technical folks new to the LibTech arena audit applications to
> identify weaknesses; and also help app developers look at the various
> ways their application, stack and service providing may be weak. It is
> not a "every box must be checked and then you're secure" document, nor
> could it ever; but I do think there's a lot of domain knowledge we can
> write down to at least jump-start people down the right track.
>
> It is an advanced list targeting technical people.  Meaning entry
> level issues such as application logic bypasses, common web
> vulnerabilities such as XSS and SQLi, or lower level vulnerabilities
> such as memory corruption are explicitly not covered. It is assumed
> that the reader is aware of these and similar vulnerabilities and is
> well trained in their search, exploitation, and remediation. Finally,
> I don't want to say or imply that non-technical evaluation or
> ease-of-use evaluation is less or not important, I'm just saying there
> are multiple things to evaluate, and I am focusing on this particular
> one right now.
>
> I'm seeking folks who are interested to provide editorial feedback:
> things that are unclear or need more explanation, auditing items
> missing from the list, and similar. Please reply to me (off-list
> probably) if you'd like me to send you a copy tomorrow.
>
> The timeline for this work is to collect private feedback, do a 'soft'
> launch on github to this mailing list, and then probably publish a
> 'snapshot' whitepaper pointing to github along with some form of blog
> post.  The work is sponsored by my employer (iSEC Partners, primarily
> a penetration testing company) but will be available freely on github,
> and I (will) encourage people to submit improvements.
>
> -tom