Transparency is a common theme in politics and Wall Street these days. The
2008 elections, dealings of TARP, financial institutions run a-muck are all places where we hear the word transparency bandied about on a daily basis. While many security professionals speak about transparency when it comes to information security, very few definitions fit the overarching idea of transparency. I believe that the time has come for information security professionals to both dig deeper and out of the idea of transparency to gain a better understanding of this concept.
What does it mean to be transparent with security?
Textbooks teach us that information security consists of the CIA triad; confidentiality, integrity and availability. When any one leg of this stool fails, then the entire equation falls apart. Transparency implies actions of openness and accountability. Transparency doesn't imply success or failure of information security; it dictates actions at questionable cross roads.
Information security professionals already understand transparency but we don't use the term the same way economists or politicians use the phrase. Information security people use our own synonyms such as disclosure, process and audit. Each of these terms describes how security teams and companies should carry out transparency. When the politician speaks of transparency he, assumes everyone knows what he is speaking about, and to some degree we do all understand the big picture concept of transparency in government. The network security manager, on the other hand, trying to make the same point clear has a different problem. He wants reliable and clear communications too. He relies on always being told the entire truth and needs an open audit trail. Because computer and information security professionals are accustomed to and rely on the transparent standards underlying Internet functionality, these principles have to carry over into every part of their professional lives in order for them to be successful.
The vendor's role in security transparency
A vendor can learn to be transparent, but it's a long process. Transparency is part of the culture, part of every business decision and part of a company's foundation. Microsoft, once viewed as the poster child for insecure software and security opacity, has made great strides towards delivering a more secure and transparent products.
Microsoft's lifecycle with its December out of band patch, MS08-078, represents a classic case of true transparency. On December 9th, the media began reporting active exploitation of a new bug in Internet Explorer. The next day, Microsoft publicly acknowledged these reports by issuing Security Advisory 961051. That advisory included mitigation and workaround information. Microsoft continued to update the advisory another 4 times over the next few days. On December 16th, Microsoft issued a notification that a patch would be released the next day. On December 17th, users received the patch as promised. Throughout that week, Microsoft continued to update the security advisory with a change log and speak with the press about the exploit, the vulnerability and it's recommendations. If you look at that same security advisory today, you will still see the change log history and be directed to the patch information. This was probably Microsoft's shining transparency moment for 2008.
That's not to say that Microsoft is not always a paradigm of virtue in transparency, but they clearly know what they need to do and at least on occasion they act on what they know.
What should other vendors learn from this lesson in transparency?
Acknowledgment
The first thing Microsoft did was publicly acknowledged the vulnerability. You could argue that Microsoft would not have publicly admitted the software fault if it had not already been public, but this misses the larger point. Providing information about a privately held vulnerability when no patch is available only increases the risk to those affected.
Workarounds
The second thing Microsoft did was reduce the immediate risk to affected users by supplying a work around. Those of us in the trenches of information security recognize that risk comes in many forms. Managers always request mitigation provisions, even if they can't be immediately applied because mitigation steps provide other methods to help reduce the risk. Security Advisory 961051 included enough technical details that provided enough information to allow managers to understand the risk and decide which mitigation steps were required at each juncture.
Communications
Starting from the first advisory to the day of the patch release, Microsoft actively participated in public dialog about the vulnerability. They continued to update the security advisory with new information, speak with the press and use their own blogs to help provide awareness of the issues and risks.
The Consumer's Role
Vendors take transparency seriously by treating their consumers with greater levels of respect and consumers also have a responsibility in this marriage. For a vendor to admit a flaw in their software with the potential for catastrophic security failure is very difficult and requires a huge commitment to transparency. It's understandable for consumers to throw stones at vendors for flaws that should have been disclosed but weren't, it's another thing to double penalize them for admitting the flaw. Consumers need to advocate for an active role in vendor disclosure.
This is a cross post from my company blog.