I generally don't ask for help in my blog, but writing up my questions here is the easiest way to share via social networks.
I was wondering if anyone could point me at an example or 2 off a formal threat model that was done on some Software Development Kit (SDK), that is a software library. Not a web service API, where the attack surface is more obvious, but a traditional library.
I would like to do one for OWASP ESAPI. The closest I’ve gotten to this in the past was this document I wrote in 2010: OWASP ESAPI for JavaEE 2.0: Design Goals in OWASP ESAPI Cryptography, which had at its roots lessons learned from a proprietary cryptographic key service that I lead my AppSec team to design for a former employer and for which I did a formal design goal, but only a minor part of that was an SDK.
A major reason why I’ve been thinking about it recently is because just last week, I published a new ESAPI Security Bulletin and an accompanying GitHub Security Advisory that had to do with File Uploads and in it, I tried to explain why ESAPI couldn’t do more. In that simplified explanation I tried (and most likely largely failed) to convey some of the major DoS related threats associated that we couldn’t account for unless ESAPI were to enforce particular use cases on developers. And therein lies the problem. I thought, it I had threat model to hold up and share with developers around various file upload use cases, I would have had a shot. But when you have a general purpose library that tries not to impose any specific use case, how do you go about describing a threat model for that? Even drawing a DFD for that is problematic as it likely would only be one of several possible ones. (E.g., for file uploads, authenticated vs anonymous file uploads are 2 very different use cases that in my opinion would have 2 very different threat models.)
I think it is obvious from a library of several general security controls like ESAPI which tries to provide controls that can be used to address most of the OWASP Top Ten, that one would first have to start by decomposing it into basic components such as authentication, authorization, data validation, output encoding, safe logging, cryptography, etc. and likely have to address it as a collection of several separate, much smaller threat models. Otherwise, you would never be able to deal with all the different abstractions in a context level DFD that would be simple enough and concrete enough for it to be comprehensible to anyone, much less developers. Part of the problem in fact is that several of the components (e.g., data validation, output encoders, safe logging to name just three) already deal only with “strings” as input and output and it is extremely difficult to relate a general string to usual concrete asset.
An example of this is ESAPI’s Logger component which attempts to provide “safe logging”, where “safe logging” in meant to 1) prevent “Log Forging” (aka, “Log Injection”), that is CWE-117 as well as 2) provide some level of basic attention against XSS attack strings inserted into logs that may be viewed in via HTML browser. However, one thing that ESAPI’s Logger and its concept of “safe logging” does not address at all is to prevent sensitive / confidential information ending up in log files. Given that the tainted input to the methods are general Java Strings, it is not possible to look at those in the context free manner that ESAPI sees them to know if it is in fact sensitive data that should not be placed into a log. That potentially could be don’t with a slightly different interface or customization by application developers, but seems a stretch for a general purpose security library.
However, I think that a well-developed overall ESAPI threat model would help the ESAPI team communicate to developers to let the know them where the security guardrails are that ESAPI is able to handle and where they are on their own. I have communicated with many application developers using ESAPI who seem to struggle with these basic concepts. Sometimes it is because our Javadoc is sorely lacking or we have little design documents. (I think we only have 2. One for the ESAPI cryptography that I mentioned earlier and a much more basic one that is a half-page covering the Logger that was originally just an email between ESAPI team members.) Similarly, we only have 1 high level user guide for any of the components (for the symmetric cryptography introduced in ESAPI 2.0). I think developers can learn a lot by reading through well-constructed threat models.
But that brings me to main question. How does one construct a threat model for a general library? What does a good one look like and how would one for a library (which may have no specific use cases in mind) different from threat models from applications or overall specific systems.
And my second question (assuming someone can answer the main questions above), is would anyone be willing to assist me in developing a threat model for OWASP ESAPI?
Posts
