This past weekend I attended ShmooCon. Depending who you talk to, it is a white hat style conference. I suspect, as with any gathering of 1800 computer security people, you may end up with some black hats and some greys but generally speaking the sessions and discussions that I attended were white hat oriented. It was a good couple of days. For personal reasons I could only be there Friday and Saturday but even that short period of time generated lots of ideas.
Two ideas that stuck with me, even after thinking about them some more, are consumer oriented security thoughts. The first is the idea that not all Certificate Authorities (CAs) are created, or operated, equally. I think this is clearly evident in the issues we have seen with some over the last few years where we have had breaches of administrative accounts either due to the back end implementation or due to poor implementation/operations of user administrative accounts (aka Registration Authorities, RAs).
There are many CAs that are out the that are well operated and that are diligent with external audits and security reviews. These CAs implement policies that are at least as strong as the level of assurance that they deliver to their end customers and these policies are shown to be implemented properly through their external reviews. These CAs are listed in the same security store as other CAs that appear to not have the same level of policies, operations control or external review. In any browser, an Entrust or Verisign CA is treated the same as a DigiNotar, or at least they were before the DigiNotar breach. Is that beneficial to the consumer? There has to be a way to grade these CAs, outside of the EV versus standard certificate ideas. I am thinking something ala the FISMA grading mechanisms used in the US Federal government. In the FISMA grading system agencies are penalized for gaps, the bigger the gap in the operations versus policy, the bigger the hit. The grading then looks like the Green, Yellow, Red rating system. If this style of system was implemented in conjunction with Browser vendors the browser could allow a user to define a tolerance level - I will accept yellow and greens without warning, unless there is another issue, and I want to see warnings for red or block red all together. The variations between the levels could be worked through the CA Browser Forum and the determination of what triggers a downgrade or what is needed to bump a CA level back up.
The other thought is in a similar vein. Today when I authorize app access, whether on my phone or through some form of account connect, think Facebook Connect as an example, I see what the application is accessing and in some scenarios I have the option to be selective on if I want the application to have all the privileges it is asking for. For example - do I want the app to post on my Facebook Wall? Or, Do I want the app to have default access to my GPS location? This sort of flexibility may be lost on some but I do appreciate it as I often wonder why an app requires certain access. Now grant it, not all application platforms provide this flexibility but I see more and more doing this. What is interesting is when I access a website with Java code I do not get the same level of control. I can decide to only trust signed code but given the issue I described above is that enough? Do I want my code signed by a CA that I would not normally trust? Since Windows update dumps the full Root trust list to me and I have to manually go through and clean it there seems to be an opportunity here to do some better refinement. Again this would require browser cooperation but the end result could be powerful.
So the idea is two fold: "encourage" app developers to identify, in a standards way, likely in Metadata, the permissions that the app requires. With this definition lets give the user the option of choosing how to operate. Again the browser vendors could default settings but give the user the option of choosing whether he wants to see the data and how they want to react to the data. Settings to allow "application operations for JAVA" for example. If the code has permissions meta data then display that and let the user choose. If not then notify the user of the CA level (see above) that signed the data and make them aware of risk.
I am the first one to realize that the weakness in most of transactions is the end user but I believe that these types of implementations would increase awareness as they are already seeing elements of these in other areas. Of course this will require cooperation between developers and browser companies to implement and likely not a tomorrow thing but I believe something that should be thought about in a broader forum.
No comments:
Post a Comment