[liberationtech] Technical Guidelines for Auditing LibTech Apps

[Tom Ritter]

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