One of the assets that we need is the official mapping of TeamMentor's WebServices Authorization Rules. This is the mapping according to the 'Business Logic', and must be independent from what actually is happening at the live website (and within the code).
Our current solution is to have a shared GoogleDoc spreadsheet which these mappings.
Here are two screenshots of what it looks like (see the spreadsheet is here)
These mappings represent what is expected to happen, so for example if one of the methods marked with NO (in light red) can be invoked by that type of user (like an Reader), then that is a vulnerability.
What is very powerful about this mapping, is that it allows us (on the security camp) to have a proper 'conversation' with the business owners and key developers/architects (and we will get a lot of kudos if we are the ones that created this (or enabled its creation))
Basically what we are asking them is: Tell me how you expect your app to behave, so that I can tell you what actually happens.
Although this is a great step forward, there is still a lot to do:
- Feed this data to a Dynamic or Static analysis script/tool (so that it takes into account the expected behaviour)
- Once we have results, create a diff view of this data
- Map this script with the actual WSDL so that any WSDL changes can be detected and fixed ASAP (for example when methods are added, edited or removed)
- Find a way to store and map this data over time
These mappings are the key to the discovery of security issues and (in their absence) to provide assurance to the business that the application is behaving the way it should.
The interesting question is: how is it possible to perform an Authorization security analysis without this information? :)
