[Previous entry: "Harry Potter and Greyhounds"] [Next entry: "A bug in fread() could lead to a buffer overflow vulnerability"]

04/14/2008: "Are you sure? Surety, integrity, confidentiality and availability"

Whilst researching for couple of papers I've had to write recently, I've been left with the problem of trying to suitably frame risk using "traditional" security models when it comes to client based flaws and felt these models were lacking.

The Federal Information Security Management Act (FISMA) [1] defines three security objectives namely integrity, confidentiality and availability. Federal Information Processing Standards (FIPS) 199 [2] defines three levels of potential impact caused by a security event - i.e. something that leads to a loss of one or more of the three FIMSA security objectives. As is, FIPS199 addresses well the potential impact to the system that actually exhibits the flaw but it's difficult to place a flaw such as cross-site scripting (XSS) in the FIPS199 framework. This is because an XSS flaw typically has no direct impact upon the system that exhibits the flaw - in other words it doesn't really affect that system's integrity, confidentiality or availability but rather it affects the system's clients (nothing new here, of course). The presence of XSS flaws in a system can lead to its users losing confidence in that system's safety - if they use it they could end up being compromised. If enough users feel that they're unsure about the system's security then the loss of consumer confidence can have a much higher potential impact than that derived from FIPS199's "formulae". It is apparent then that a new security objective needs to be defined: surety. Surety can be defined as a degree of assurance or confidence as to the trustworthiness of a system. A loss of surety then is a loss in consumer confidence that can lead to a loss of business.

There is a second aspect to surety to be considered. Whilst the presence of a security flaw such as a buffer overflow can affect a given system's integrity, confidentiality or availability, to the vendor of the vulnerable software the potential impact is a loss of surety in the software. As an example of this, consider Microsoft's Internet Explorer (IE) and Mozilla's Firefox [3]. Rightly or wrongly, as new flaws are discovered in IE more people opt to use Firefox instead - it is perceived to be more secure and thus has greater surety over IE - consumers feel that they're less likely to be owned when surfing the Internet if they're using Firefox instead.

Anyway, back to the papers I mentioned in the intro to this blog entry. When I get around to putting them out, when I start spouting off about a system's surety in them, you'll now know what I'm on about


[1] FISMA
[2] FIPS199
[3] Usage share of web browsers