1 Raindrop

Asleep at the Wheel

For many years in secure coding training, I have used this quote from Gary McGraw- "Software security is the idea of engineering software so that it continues to function correctly under malicious attack."

This simple yet powerful statement encapsulates many of our challenges, however I have one nit to pick, and it makes our job harder. Our job, in my view, is to engineer software so that it continues to function correctly under attack. Note that I left out "malicious." 

Many times we don't care if the attack was on purpose of accidental. If someone types rm -r and the database is gone, on many levels- intent, both going forward and avoiding this mistake, is not the main issue. 

An example I use in training is whether its an actively malicious attacker or a legit employee, say Homer Simpson, falling asleep on his keyboard, if the data is gone its gone.

Looks like the latter has happened:

A German bank employee accidentally transferred 222,222,222.222 euros ($295 million) from a customer's account when he fell asleep at his computer.

The bank clerk had been attempting to transfer just 62.40 euros ($82.80) for the customer, a pensioner, when he dozed off with a finger on his keyboard's "2" key.

The bank did catch the issue on the backend, but its a good reminder that threats and threat intent is of secondary importance when compared to protecting assets.

This makes our jobs harder because we have to work to avoid both malicious acts as well as attempting to anticipate mistakes.

Security > 140 Conversation with Gerry Gebel on XACML and ABAC

Glad to have the chance to talk with Gerry Gebel on current work and trends authorization. To my mind authorization gets nowhere near the attention it deserves in security architecture. For a refersher, here are some previous conversations with Gerry on these topics.  Gerry Gebel was formerly with Burton Group and is now President of Axiomatics (America). Axiomatics focuses on authorization and the XACML standard.  

Gunnar Peterson: The thing that strikes me about XACML and ABAC is that its really different from other security standards. Usually when we talk about an authentication or crypto protocol, we talk about strength, threat models, and the strength of the security service itself. It's inward focused.  It seems to me that the value of XACML and ABAC is really in the use cases that they enable. It's outward focused, and unlocks value through new kinds of services.  What kinds of use cases have you seen recently where XACML and ABAC are enabling companies to build things better?

Gerry Gebel: You are correct to point out that XACML feels different from other identity and security standards. XACML is inwardly focused on the application resources it is assigned to protect through the use of its policy language - there isn't just a schema, token format or DIT to work with. 

There are a couple of recent customer use cases that I'd like to briefly describe as they are typical of the kind of requirements we see. In the first case, the organization holds a lot of data for customers in different industries and they wish to provide access to different slices of data via a combination of APIs and web services. In this case, its API access primarily for mobile devices and web service for other client applications. Specific business rules dictate what data customers can view or what APIs/web services they can call. Integrating an XACML service at the API/web services gateway layer is a non-intrusive way to implement the right level of data sharing and enable new business models for the organization.

The other case study example is for an organization that is building a new data hub service, where certain users can publish data to the hub and others will subscribe to the feeds. Due to the sensitive nature of the information, granular access control was important for the new service. In this case, the designers wanted a flexible policy-based model to control access, rather than hardcoding it into the application. 

 GP: Interesting use cases, let's drill down on these. First as to the gateway - I am a fan of web services gateways, they are a no brainer for implementing identity, access control, dealing with malicious code and so on. Authorization (beyond coarse grained) requires a little bit more thought. How have you seen companies approach getting the right level of granularity to take advantage of the XACML Policies at a gateway level? In other words, given that a gateway has less context than the application layer, what is the hook for the policy to be able to intelligently make authorization decisions outside the app as it were?

GG: You are correct to point out that you can only make as granular an access decision as the context that is provided to the policy decision point (PDP). In this case, the call from the gateway to the PDP may just contain something like: subject: Alice, action: view, client_record: AD345. The PDP can enhance the situation by looking up more information about Alice before processing the access request - her department, role, location, etc. In addition, the PDP can look up information about the client record - is it assigned to the same location or department as Alice. With this approach, you can still make pretty granular access control decisions, even though you don't have a lot of context coming in with the original access request from the gateway.

 GP: Right, so its case of Roles are necessary but not sufficient?

 GG: Roles are usually only part of the equation and certainly not adequate on their own for granular authorization scenarios.

GP: Here is one I wrestle with - naming. On the user Subject side its pretty simple, we have LDAP, we have AD, and everyone knows their user names and log in processes, but what about the resource side? Its seems less clear, less consistent, and less well managed, once you get beyond URL, URI, ARN and  the like. What trends are you seeing in resource naming and management; and how does this effect XACML projects? 

GG:Indeed, naming conventions and namespaces for subject attributes are prevalent and are lacking for other attribute types, in particular for resources. One approach to address naming for resources is to publish an XACML profile, whereby you can establish standard names for at least a subset of attributes. We see this being done today in the Export Control and Intellectual Property Protection profiles. Some firms in the financial services industry are also examining whether XACML profiles can be defined to support certain cross tim interactions, such as trade settlement. 

Otherwise, ABAC implementers should approach this task with a consistent naming convention and process to ensure they end up with a resource namespace that is manageable to implement and operate.

GP: I had always looked at XACML as something that helps developers, but it appears to have a role to play in areas like DevOps too. I have seen a few examples where XACML services delegate some administrative functions, such as spinning up Cloud server instances, and lower level configuration. For decentralized environments where admin tasks (which are very sensitive and need to be audited) can be handled by different teams and even different organizations this kind of granular policy control seems like a very good fit. It gave me a new perspective on where and how XACML and ABAC might fit, have you seen these types of use cases? 

GG: Normally we are dealing with application resources, but we have had cases where IT uses XACML to control access to DevOps kinds of functions. As you have pointed out, the XACML policy language can be quite useful in a number of areas where granular access control is important.

GP: Developers and security people fundamentally lack good (read: any) testing tools for authorization bugs. Static analysis and black box scanning tools are all the rage (and server a useful purpose in security bug identification), when you scan your app they can find all manner of SQL Injection, XSS and other pernicious problems, but at the same time you can cut those same tools loose on an app that's riven with thousands of authZ vulnerabilities and they will often come back green! I am pretty sure this is a major factor contributing to the numerous authorization vulnerabilities we see.

I think even just a first cut, 1.0 implementation with XACML and ABAC is an huge leg up towards formalizing some of the authZ structure so that real test cases can be developed and run. This makes it simpler for the developer to avoid authZ mistakes since they can continually test against a defined policy instead of dumb scanning against something where your tools cannot differentiate between what's authorized versus unauthorized states. What are your thoughts on authZ testing? 

GG: We get a lot of questions about testing the policies in an ABAC system and there are many ways to address this requirement. 

1. At the policy authoring stage, there is the requirement to perform initial unit testing - does this policy I am writing operate the way I expect it to? We provide this simulation capability so you don't have to run the application to see outcome of a policy and it includes a trace facility so you can explore exactly how the policy was evaluated (this is a big help in debugging policies as well). Unit tests can be captured in scripts for future use, such as when the application or access policies change.

2. Positive and negative test cases: You are correct to point out that developers can test against a defined policy, such as: cardiologists can view and update records of heart patients. We refer this as a positive test, that is, does the policy allow doctors that are labeled cardiologists to view heart patients' medical records? But there are other conditions to test for that may be characterized as negative tests. For example, given a set of ABAC policies, is there any way a non-cardiologist can update a heart patient's record? For these kinds of scenarios, you can build additional test scripts or use an advanced policy analysis tool. 

3. Gap analysis testing: Another advanced function is to test for any possible gaps in the policy structure. But again, as you pointed out, having a specific set of access policies to test against makes the process easier. In this manner, you could test for separation of duty scenarios that violate policy: is there any combination of attributes that permits a user to create and approve a purchase order?

GP: In my opinion, there are concrete benefits from being able to make more granular authZ decisions, audit policies and configure rather than code authZ, but as a security guy the testing piece all by itself is a game changer. This is just such a big gap in so many systems today and a large source of "known unknown" kind of bugs, ones that can be but often aren't found and closed.

Ok last question - is XACML dead? This is your cue to tee off.

GG: Far from it. I've witnessed a significant increase in demand for XACML solutions over the last few years, the <a href="https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml">OASIS technical committee</a>  is actively working on new profiles (after version 3.0 of the core spec was formally ratified earlier this year), and seen new vendors enter the market. There is a big emphasis to further improve the standard for consumption by the developer community, a key constituency if the industry is going to escape the cycle of hard-coding authorization inside applications. Some of the standardization efforts worth noting are profiles to define a REST interface for the authorization service as well as JSON encoding of the XACML request and response formats. These two enhancements should greatly broaden the appeal of the XACML authorization standard. Further, Axiomatics recently joined the OpenAz <a href="http://www.openliberty.org/wiki/index.php/OpenAz_Main_Page">OpenAz project</a> to help update and improve this developers' API.

James Lewis on Myths

James A. Lewis on Five Myths about Chinese Hackers hits key points, starting with point 1:

Trying to cram Chinese hackers into antiquated cold war formulas doesn’t help, either. America’s relationship with China is very different from the one it had with the Soviet Union, in which contacts were extremely limited and there was no economic interdependence. The idea of “containment” for China is inane. How would you “contain” a major economic partner?

Any security discussion that glosses over the economics is just armchair general foo fa ra.

Point 4 (emphasis added):

Even when China steals intellectual property, it can take years to turn it into a competitive advantage. The right technical skills and manufacturing base are needed to turn advanced designs into high-end competitive products. China is still lagging in many high-tech arenas, such as semiconductors.

The one area where this is not true is military technology. Chinese espionage has led to rapid improvements in that country’s stealth, submarine-quieting, nuclear weapons and sensor technologies. While the economic risk from cyber-espionage is generally overstated, the United States has probably underestimated the damage to its lead in military technology.

His conclusion should be reflected on. If James Lewis is right, then much of what is bandied about in DC as a solution for cyber smacks of Alice in Wonderland. Consider that we are routinely told that the public sector will ride to the rescue of the Internet. But from where did DC's imprimatur of divine security expertise come from? 

There is no area that I can think of where we automatically assume higher quality products and services simply because the government is doing it. But for some reason we automatically think they will improve and solve cyber? Make no mistake, I am not a government hater by the way, they can do things very well. The CDC is a great example and there are plenty more, what bothers me is the a priori assumption that government involvement automatically makes cyber problems go away.

I don't see it. I don't see that they know OS, apps, data security better than IBM, Microsoft et al. If you agree with James Lewis' conclusion, that public generally lags private in coping with threats. Again, I am not saying that it's impossible for the government to add value, just that its not a given.

When Macondo blew up and BP was leaking oil into the Gulf, the Navy charged. Finally we thought, a group that knows how to operate at a mile below the ocean surface Except they didn't know how to repair oil rigs. I am not sure cyber is all that much different from deepwater drilling. Security knowledge is necessary but not sufficient. Security knowledge helps, but domain specific knowledge is what makes it useful.

Better Metrics

As a general question, we have way more security metrics than we did say 5 years ago, but do we have the right kind of metrics? 

Wade Baker and the Verizon DBIR team performed an exceptionally useful service when they launched DBIR. It was among the first rocks that started tumbling that led an avalanche of de-fudified the infosec industry (ok, mostly def-fudified), before DBIR breaches were discussed in whispers and "if you knew what I know" kind of BS hallway conversations. Afterwards, they are discussed openly and in the spirit of how we can learn. This was a massive change, I am sure not easy one esp at the outset, and they have continued to improve the report every year. Kudos.

Having said that, its time for the industry to move on from data breaches as the central organizing construct. We'd all love to see a John Snow emerge, but unfortunately our Ghost Map does not have clusters around pump handles. The pump handle is the internet and if you are connected to it and you have something someone wants, then you are going to have to deal with breaches. 

Data breach is analysis is threat centric and threat centric thinking is only useful for wowing noobs at confences or getting funding in DC. Whats needed instead are metrics that help us build and deploy more robust applications and make the systems more operationally resilient. In short we need to learn from engineering. 

What difficulties do bridge engineers face and how might we learn from them? With the recent Washington bridge failure, Carl Bialik examines  conflicting reports about the so-called sufficiency ratings of a bridge and the combination of quantitative and qualititative measures.

“It is not an exact science,” said Charles Roeder, professor of structural engineering and mechanics at the University of Washington, Seattle. “The probability of failure depends upon imponderable factors. I don’t think anyone knew that this truck would hit the Skagit River Bridge. Even if by some miracle someone knew that this specific truck would hit this specific bridge, they would not know that the bridge would collapse.”

Sufficiency ratings take into account many characteristics of bridges, including ones not directly related to their chance of failure. But “removal of a single truss member of a truss bridge can bring the full bridge down,” said Robert K. Dowell, Director, Structural Engineering Laboratory at San Diego State University. Even bridges with redundant features, meaning there are backups if one fails, “can collapse if one member is removed, as the redistribution of loads may overload other members.”

Bridges are rated on about 100 data points an 20 factors. What would a sufficiency rating look like for software systems? I do not think it looks precisely like the OWASP Top Ten or SANS Top 20. Could we get to something like how safes are rated (time and tools)? How are threats, vulnerabilities and countermeasures weighted? Where does data classification fit? Improtantly, is the indsutry itself even able to deploy actionable improvements based on such a rating?

Can we use metrics to answer even basic design questions? I like to use the "if you have a $100 to spend" kind of design questions. If you have a $100 to spend and you have a large amount of low assurance endpoints. Should you spend it upgrading them all to medium level of assurance? Or should you keep them all at low assurance level, buy a high assurance gateway/proxy, and run them all through that? Or what middle road would you use? This scenario would have you look at failure modes in addition to the security aspects, too. Its just one scenario, but these are basic questions we have to answer every day and the current data doesn't help us yet. 

A lot of this will just take time, but there are some things that begin to be improved already, structural improvements. I think static analysis and black box vulnerability scanners have a major role to play here from at least two perspectives. One, reporting the attack surface and vulnerability density for systems (this exists on some level today) and two, the efficacy of controls. As to the second point, there is a long way to go, the security industry is so immature at this point in time, it appears that many of the countermeasures actually make things worse. We cannot make real progress in infosec without better measures for both, and these are our best opportunities for improvement over the medium to long term.

Perils of Top Down Thinking

Costco has a P/E ratio of 25. This is hands down better than their peers.

	P/E
Costco	25
Target	15
Dollar Tree	19
Walmart	15

Basically what this is showing is that investors are willing to +60% more to own Costco over its competitors.

Top down thinking can be good because it helps people abstract away some complexity and take shortcuts. On the other hand, top down thinking can be bad, after all its lossy compression and what is lost in the compression algorithm might be quite useful. Assumptions in top down models should always be compared to bottom up findings.

I was thinking this the other day when I overheard this pithy summary of Costco - they have fewer stores, less selection, less ways to pay and pay their employees more.

 If you drew up a business plan saying - I am going into the hyper competitive retail space to compete against the likes of Target and Walmart, I am going to charge people to walk in the door, I am only going to accept one kind of credit card, I will have far less selection, far fewer stores, and I will pay my employees more (plus healthcare benefits!) - you would get laughed out of any business school in the world. But that's what they did and though it flew in the face of any MBA top down model - they beat competition hands down.

Enterprise API Management for Mobile Part 2 - Don't Trust. And Verify

In the previous post we looked at some of the policy zones that an Enterprise API Management has in Mobile security, including:

1. External security policy: for the Mobile device -> API Management Layer message exchanges

2. Internal security policy: for the API Management Layer -> Enterprise backend message exchanges

3. External <-> Internal mapper security policy: to facilitate the right security and identity services for each boundary transition  

Gateways and API Management have many, varied capabilities. They can play several different roles in an enterprise security architecture. To tie this down to something useful for a real world deployment, it pays to be specific - not just a laundry list of WHAT a API Management Layer can do, but WHERE in the architecture it acts. In this post, let's drill down into some specific concerns that can be addressed by the Mobile API Management Layer in these zones. 

Zone 1. External security policy: for the Mobile device -> API Management Layer message exchanges

The old chestnut "trust but verify" is no longer valid, better way to think about this boundary is - "Don't Trust. And Verify."

The API Management Layer should not "trust" that any old client (SSL or otherwise) that sends data is AOK, the communications, user and application should be authenticated and authorized. In addition, the data and usage should be verified. 

Getting down to brass tacks, there's a steady drumbeat towards OAuth as an external protocol for mobile. From Cloud vendors like Salesforce, platform providers like Google and enterprise applications are all moving in this direction - OAuth as a standard token type and protocol for Mobile apps. 

OAuth helps to solve the "Don't Trust" part because now there is a token to authorize against a security policy. Verifying data means looking for malice - SQL and command injections, malicious javascript and so on. Network firewalls won't cut it here, the API Management Layer must verify the inbound data does not contain malicious code before sending the data into the chewy center of the enterprise. 

Lastly, this zone should record (to an audit log monitor and/or SIEM) the details of the transaction.

Zone 2. Internal security policy: for the API Management Layer -> Enterprise backend message exchanges 

OAuth has emerged as a de facto standard for mobile apps, but inside the enterprise you can expect a Noah's ark approach to identity - Kerberos, X.509, SAML, proprietary and custom. The external policy insulates the mobile client from having to deal with these many protocols, but the job falls to the API Management Layer to implement these interfaces. 

This responsibility means many burdens for the API Management Layer including consistent naming, refreshing certificates and connections, protocol specific configurations and mapping, dealing with latency, error correction and retry and a host of other connectivity issues.

As to verification, the malicious code issues should be handled by the upstream (external policy). For most apps its not likely necessary to duplicate these checks, note that there could be some areas like callbacks and asynchronous messaging where further granular checks can only be done after an initial inbound call, though. The main verification step to be aware of at this level is to ensure that the authorization maps from external to internal which brings us to:

Zone 3. External <-> Internal mapper security policy: to facilitate the right security and identity services for each boundary transition  

This mapping keeps the control of the enterprise object mapping on the server side. Abstracting it away from the client is helpful for developers (only having to deal with external API not enterprise hodge podge) and security - avoids vulnerabilities like Insecure Direct Object Reference. This process can be made stronger by having the mapper issue and verify a nonce (unique code) per instance, to defend against replay and other attacks.

In the next post, we will look at client side integration issues - how to communicate with the API Management Layer

Limitations of Statistics on Measuring Risk

For any security project when we're trying to use risk to inform our software development, operational processes, the current state of available data is not particularly helpful. But even if it was better than it is currently (and we had statistics), its not likely to help much when it comes to risk. Good example from  Nassim Taleb in AntiFragile:

"A turkey is fed for a thousand days by a butcher; every day confirms to its staff of analysts that butchers love turkeys "with increased statistical confidence." The butcher will keep feeding the turkey until a few days before Thanksgiving. Then comes that day when it is really not a very good idea to be a turkey."

What we need is something predictive, but currently we cannot really accurately describe the past or present, so we're a ways away. What to do? One way to think about it from Howard Marks - we can't predict the future, but we can at least prepare for it.

A Cloud Risk That Is Different In Kind

The risks in cloud deployments are generally differences of degree rather than different in kind. But there are some risks that are fundamentally new. We saw two examples recently. First was Bloomberg, not a 21st century Cloud for sure, more like 1990s era Cloud but the precedent is right there for anyone using a Cloud application:

In one instance, a Bloomberg reporter asked a Goldman executive if a partner at the bank had recently left the firm — noting casually that he hadn’t logged into his Bloomberg terminal in some time, sources added.

Goldman later learned that Bloomberg staffers could determine not only which of its employees had logged into Bloomberg’s proprietary terminals but how many times they had used particular functions, insiders said.

The matter raised serious concerns for the firm about how secure information exchanged through the terminals within the firm actually was — and if the privacy of their business strategy had been compromised.

“You can basically see how many times someone has looked up news stories or if they used their messaging functions,” said one Goldman insider.

And the second, the Google stalker case

former Google engineer, repeatedly took advantage of his position as a member of an elite technical group at the company to access users' accounts, violating the privacy of at least four minors during his employment, we've learned. Barksdale met the kids through a technology group in the Seattle area while working as a Site Reliability Engineer at Google's Kirkland, Wash. office. 

Cloud apps have to deal with the normal IT risks, but in addition we have the above examples of new risks that are brought on in part by panopticon effects of Cloud apps.

Berkshire Hathaway Annual Meeting 2013 Notes

 

I attended the Berkshire Hathaway annual meeting along with Adrian Lane and 40,000 or so other shareholders. Adrian commented on something that is near and dear to my heart:

I am hooked, but not because I want investment ideas – instead I am fascinated by an incredibly simple investment philosophy, that involves an incredibly complex set of rational models, that forms the foundation of their decision process. Both men are contrarians – they choose to invest in a method that for decades people thought was a fluke. Berkshire has been called a 6-sigma outlier. They have been derided for not investing in tech companies during the tech boom – a profound critique when you consider Apple, Google, and Microsoft are some of the fastest-growing and 3 out of of 5 of the largest companies in the world. They have been mocked in the press as being “out of touch” when the market was going crazy during the whole mortgage/CDO fiasco. But they have stayed the course, despite fickle and fashionable trends, on their way to become the most successful investors in history. Berkshire is now one of the top 5 companies in the world, but ultimately their approach to decisions is what fascinates me.

That captures the essence of what I spoke about last year at the SIRA conference on how related the investing mindset and security mindsets are. People are wired to get excited and rush into things (whether its trying to guess the next Google or cram new features into an app), but a rational decision making process should consider the downside not just the upside. Buffett's teacher, Ben Graham pioneered the approach where you first look at the downside and then only consider the upside potential for those that pass the downside test. This is the exact opposite of how most people invest, or how most people build and deploy software for that matter. But the permutation matters, the discipline of analyzing the downside first leads to a more robust process. 

To me, the practice of information security can be improved by learning from the defensive, value-oriented approach to investing - investors should first make sure the Balance Sheet is safe and not over leveraged before looking at projected future earnings; security people should review the Threat Model before looking at the benefits of the new features the business wants to roll out.

As to the rest of the meeting, there sure is not much technology. Buffett and Munger are pretty technophobic, neither has a computer on their desk, neither runs a computer screen for stocks, Buffett does not even have a calculator on his desk, he does the math in his head.

There was a question on Twitter, and Munger replied that he is avoiding it like the plague, adding that when he observes his grandkids doing social media they are multi tasking and most jobs done as multi tasks are done poorly. There was a question on bitcoin, Buffett disclosed "Of our $49 billion, we haven't moved any of it to Bitcoin."

This year was the first year (and I assume first shareholder meeting ever) that had a bear who was short the stock asking questions. This was a great idea because it showed Buffett and Munger's willingness to challenge their own ideas rather than talk a PR game which is how most every annual meeting operates. Instead they invited a bear, gave him a seat on the panel and mic and let him poke holes in the company, live in front 40,000 people. 

Berkshire owns Business Wire which is a source for public companies making announcement, there was a question about the future of Business Wire with the SEC now allowing for disclosure via Twitter, Facebook et al, Buffett's response was "The key to disclosure is accuracy and simultaneity. If I'm buying Wells Fargo, for example, I do not want to have to keep hitting their web page and hoping I'm not ten seconds behind somebody else." Personally, I was kind of surprised the SEC acted so quickly in letting social media serve as a place to distribute official releases. It will interesting to see what if any impact this has on Business Wire's business.

Munger was asked to sum up Berkshire's competitive advantage in a way the questioner's 13 year old daughter could understand, he said "We've always tried to stay sane when other people like to go crazy. That's a competitive advantage."

There were some mentions of banking practices, Munger continues to be worried by the derivatives used at some financial institutions "The more bankers want to be more like investment bankers and less like bankers, the worse I like it."

Five years ago, Buffett bet a hedge fund called Protege Partners $1M that a plain vanilla S&P index fund would outperform a group of hedge funds. As of now, the S&P is +8.69% vs the group of hedge funds +0.13%. As Jack Bogle says - hedge fund provide excellent hedge against getting capital gains! You can track through longbets. The other lesson is the seductive details of a hedge fund's complex, proprietary models do not necessarily lead to better returns than anyone else can get through a boring index fund, though they certainly lead to higher fees!

On Sunday, we attended another highlight of the weekend - the Markel annual shareholder breakfast. They are a so-called baby Berkshire, a small insurance company that follows a similar approach: conservatively investing insurance float. Markel writes niche insurance policies. They eschew property, casualty and other areas where big name insurers play, Tom Gayner (Markel's CIO) describes their business this way: 

Cocktail party definition of Markel if someone asks about Markel, its an insurance company that they've never heard of. Well an easy way to think about that is if you have an insurance policy that you can get easily and quickly, well we wouldn't do that. We do the sorts of insurance where people go 'Oh no. We've got a problem or we've got a situation' This isn't to disparage the other insurance companies, we all have a role in life. What GEICO says yes to is not going to be the same thing that Markel says yes to. What Markel says yes to isn't going to be the same thing that GEICO says yes to. Its a different organization and orientation.

We do 100 different forms of insurance - everything from children's summer camps that are out in the middle of nowhere, that have teenagers supervising teenagers and no fire departments nearby, kids jumping on trampolines and being out in canoes, all the sorts of exposures that go with that

An ongoing challenge in these arenas is that unlike life insurance where the statistics are "disturbingly known", Markel has to piece together a hodge podge of sources to make decisions on how to write policies, and coming full circle on the theme of this post when Steve Markel was asked for an example of this challenge of managing risk absent optimal data, the example he gave was one of Markel's products - Cybersecurity and Data breach insurance.

Quantifying Risk Tolerance

Depending on how its used "risk" can mean many things, sometimes it means CYA. Infosec mostly informs "the business" as to the nature and severity of risk incurred by the types of things the business wants to do. "The business" side uses the information culled from vulnerability assessments and related activities to decide what countermeasures they want to bring to bear and what risks they are willing to take. Questions worth asking about this include - does the information Infosec teams provide to the business improve their ability to make risk based decisions. And further, is the business really in any position to make a risk based judgement?

Framing infosec threats and vulnerabilities as risk issues is only useful if the business can be relied upon to make smart, risk based decisions (and have the right information to do so). Financial advisers have their clients take a "risk tolerance" quiz, but are people even really aware at how these intersect with their own decision making and incentives? I think that's pretty unlikely on a individual level and often even less likely on a company level, where organizational incentives and bureaucratic processes come into play.

As to a given individual's ability to understand and act upon their own risk tolerance, this is nowhere near as simple as it seems. Most financial advisers will try to quantify your personal risk tolerance, using quizzes that ask how you deal with say volatility, but:

 

That might be useful if your risk tolerance were an integral part of who you are, no more changeable than your IQ or your shoe size. Nothing could be further from the truth. Your behavior isn't determined solely by who you are; it's also a function of the situations you are in.

"You're trying to measure something multidimensional and inherently unstable with a one-dimensional, stable tool," says Rob Brown, chief investment strategist at United Capital Financial Advisers in Newport Beach, Calif. "You're calling it a land animal when in fact it's a creature with wings."

Researchers have shown that how much financial risk people are willing to take is associated with: how an investment has been described to you; whether you are feeling happy, sad, anxious, angry or disgusted; how much money you had between the ages of 18 and 25; whether, if you are a man, a woman recently touched you on the shoulder; whether, if you are a woman, there are a lot of men in the room; how well the market has done lately; which country or culture you come from; how long ago you ate your last meal; whether you smoke; how much you weigh; whether you put your feet up on a table when you were thinking about the risk; whether at least 75 people have died in an airplane crash in the past three days; whether the sun is shining; how urgently you need to go to the bathroom; where you got the money you are investing; whether you smell a pleasant aroma before your decision; how many positive adjectives were in an article you just read; whether you have recently been embarrassed; whether you consumed a sugared drink in the past 10 minutes; what time of year it is; whether your favorite soccer team won or lost the big game; and so on.

Now just imagine that in addition to factors listed above we have work and organizational presssures like project plans, timelines, reporting structures, bonus incentives and on and on. Its just not realistic to expect a rational risk based decision to come out of that most of the time. 

This is not strictly an Infosec problem to solve, but does help explain decisions we'e all seen. Its worth thinking about the limits to what we can reasonably expect for rational behavior, and not to put too much faith in "the business" risk management capabilities.