1 Raindrop

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.