1 Raindrop

Boring is Good

Whenever you roll out a new security architecture, the collaboration with the architecture and development team is fundamental to success. Push back from those teams can come in all sorts of ways, they may think the security team is over reaching. Development teams justifiably worry that the security requirements will swamp the budget and make them blow their timeline.

I was on a project and we did a review with tech leads and the comment at the end was "I am surprised it was so boring", I said "I take that a compliment." Security architecture shouldn't be about making people's headpsin or trying to be a security rockstar. Just because 80% of the industry does it, doesn't mean its the most effective choice. Make things simple to understand, simple to build, simple to integrate. Boring is good.Better yet, your designs may actually make it into a real, live production system.

On a related note, an interesting company that excels in risk management is Markel (a so called baby Berkshire), and on Markel's Q3 earnings call, Tom Gayner picked up on a similar theme (and managed to work in a Princess Bride reference to boot):

"Prior to this call, I was speaking with one of our long term shareholders about the conference call process. He told me that he has owned the stock for about 20 years and called us boring. He said that he really couldn’t imagine us saying anything in the call that would change his mind about Markel and his long term ownership of the stock. I thank him for his honesty and actually I agreed with him.

Our number one goal is actually to still be here 20 years from now and delivering a report just as boring as this one. I suspect what he told me was true for our loyal and long-term owners to provide us with the capital we need to run this business. I also suspect that it’s true for shorter term followers of the stock that usually issue a sell recommendation immediately following this call.

As the character Inigo Montoya, said in The Princess Bride, "You keep using that word. I do not think it means what you think it does." I will leave it to those of you who would access to the long term part of the Markel to decide which unchanging point of view you wish to embrace. The force that propelled the 27 year line on the chart up into the right cannot be found within the sales of the spread sheet.

Boring works for me when it comes to talking about our financial results. We shouldn’t be that excited. I am all in favor of grinding it out along the same lines that we have through our 27 years as a public company. We’ve looked after the capital that you entrusted to us and we produced wonderful returns for the owners of this company.

Roughly speaking, the longer you run Markel the more money you can make. And by the way while it may look and sound boring, I can promise you that we’re having a lot of fun doing this. There is not a day that goes by when I don’t hear laughter at this office. In addition, they are some days when we are simply stunned by what happens. I promise you that we are not bored."

There's one more Markel story worth sharing, and that is when Tom Gayner, noticed that whenever the phone rang in Steve Markel's office, Steve would wince. Tom asked why and Steve said "there's no such thing in insurance as a good incoming call."

So it is with security, strive for boring.

I went to the Cloud Identity Summit in Napa this year. Just like every year there were great talks that showed new ways to solve old problems. One of my favorite was from Amazon on their cloud identity and security work. It was an incredibly boring talk actually. Watching Amazon's IAM progress can be like watching grass grow.

Too true. So why was the Amazon talk one of my favorites? It was talking about a real system, deployed, at very large scale, that normal users can build, deploy and run. That counts for much, much more. Its substance. Plow horse, not show horse.

Josh Corman's recent tweet is true for sure:

The reverse of that is also true - the difference between doing lots of little things better (checklists) versus el grande silver bullet "solution."

I was talking with someone who spends time on visualization, and I mentioned how helpful better metrics on control efficacy would be, measuring their resilience in different scenarios. The response I got was "that's not sexy" and that it was better to focus on threats and graphics. Lots of people in the industry think that. I do not see that way - that's not engineering and finding and building margins of safety, its a fashion show, tailored for security conferences. 

Security doesn't need new protocols as much as it needs way better integration on the ones we already have. Integration is a slog but the long run payoff of having a more resilient system is worth it. Stay boring, my friends.

(Markel's 27 year stock chart)

Reorienting Towards Security Integration

Yesterday's post makes the case there are no security problems. 

I used to think we had security problems, and then we figured out how to integrate the security solution.

Actually, the security basics are long figured out, its the integration that's killing us. We don't have a security problem with integration requirements. We have an integration problem with security requirements.

The why is pretty easy to understand. 

1. Security is mainly an isolated department. Not really ops, not really arch and definitely not dev
2. Security is audit focused
3. Secuity is swimming in "products"

These problems are a direct result from how most security organizations and the industry as a whole functions. The combined effect leads to security's integration problem. 

Because information security is separate it does not get to collaborate in the key architecture, design, and deployment decisions in an effective way. At best, most groups function like a QA team that runs black box tests for vulns. Its an important activity, but if that is the apex then you are left Security as QA. A point in time activity.

Audit is of course a great example of an important but limited, point in time activity.Its not integrated along process, technology or organizational lines.

And so how does the security industry resolve its tactical role? With a panolpy of products, of course. Sure the security product markets has come a very long way over the last decade, but all the key questions with these tools are not so much on their efficacy, but rather on will they integrate to my process and my architecture? Sure static analysis can generate findings, but how do I parse through them? How do associate countermeasures? And by the way who does this?

Sure a WAF can catch some bugs, but will it work with my session manager? Sure the next great identity protocol can give me more fine grained access control, how do I get it work on iOS? And on it goes.

To resolve these issues, I would suggest we go back to the root of the problem and tackle them head on.

Security is mainly an isolated department. Not really ops, not really arch and definitely not dev

Security is audit focused

Audit will always have a role to play in security, there has to be an objective score card and someone who sets the hurdles. This function will remain, but it needs to be put in the right context to make it useful. The outputs of audit should over time lead to better design patterns that are based in a long term mindset for evolving the security architecture. Not auditor-driven fire drills - "ok quick, we gotta go deal with privileged accounts because even though we have had this problem for 20 years and so has everyone else, the auditor flagged it. Quick I need a seven figure budget authority - Aux Barricades!" 

Secuity is swimming in "products"

The audit focus leads directly to Infosec's product problem. The vendors are nothing if not observant. They know what's on the auditor's checklist this year. They will build products (or at least marketing materials) that will solve those problems or at least enough to get the auditor to cross off the check box.  Besides the obvious cost and resource problem here, there's a quality problem. Audit isn't architecture, its more a fashion show with problems du jour and acceptable modes of solution.

Again audit is not going away and neither are products. But just like audit, products need to be put in the proper context. That context is not what your audit checklist says, its your business process, your users, your customers, your threat model, and your system architecture. 

Reorienting means spending as much time on product selection and architecture on APIs, the integration points, the message flows. When I do Web services security design work, a pattern is almost always the security pipeline pattern. Why? its boring, its where the security enforcement happens. But that's why its important! Its where the security enforcement happens. Not the token or protocol patter, but is it a filter, a container, an agent, a standalone server. That's as critical as any other decision.

Why did Active Directory win? Sure they have smart programmers. So do IBM, so did Sun (Rest in Peace), so did lots of others. AD has connectivity and integration to users, to sessions, to servers and so on. Lots of people tried to get Kerberos to work. The differentiator wasn't Kerberos, Microsoft did the hard, crucial intgeration parts.

Security Token Services (STS) are a subtly powerful use case. Give me a Kerberos ticket, I give you a SAML token. Give me an Oauth token, I give you a SAML token. Support many different clients and keep the back end simple. Integration wins, not slamming pizza boxes in racks and telling scary threat stories.

POCs should never be isolated. They have to be run against as production-like system as possible. Every interface and API needs to be combed over to look for how exactly its integrating with your system. What system has session management? Where are the users logging on? Do they push or pull policies? What tokens are supported? Are agents required? The list of architecture questions is logn, but its path that must be walked. Security projects and security architectures succeed or fail not on the control or solution quality, but on how well the security system integrates with the system as a whole.

Part 3- Boring Is Good

There Are No Security Problems

I used to think that we had security problems to solve, and that the role of a security architect was to identify threats and to design, implement, and integrate controls. I was wrong.

We don't have security problems. Not really. Our protocol life span is measured in decades. SSL, Kerberos, SDSI and SPKI, these have been around for decades. The problem is not the protocols.

The hard part isn't mapping threats to controls either. True the industry as a whole isn't great at this, but it can be learned and its getting better.

No, the problem is integration.

I used to think we had security problems, and then we figured out how to integrate the security solution.

Actually, the security basics are long figured out, its the integration that's killing us. We don't have a security problem with integration requirements. We have an integration problem with security requirements.

When you go to RSA or any security conference, the show floor is awash in products. They all do something other but can you get them to work in your production system? And will you get the same quality as they show in the cooked up demos? Probably not. Why not? It works fine in the demos, aren't those real examples? Sure, but they are not your examples. We can think of a solution, but will it work with Google? Does Websphere support? What about the keystore? Can we bind it to OTA? And on it goes.

Its not just solutions, its threats, vulns and countermeasures too. Go right down the OWASP list.

SQL Injection? Need to integrate input validation to front end handlers and to the data model. Need to integrate prepared statement, parameterized queries, and stored procs to the backend DAO.

CSRF? Need to integrate a nonce to every request. Need to convince the team that spent the last decade keeping state out of the middle tier, that we should put it back in. Need to find a way to reboot a server even with the middle tier state.

Broken authentication? Need higher assurance creds, need to integrate those to session bootstrap mechanisms.

Elevation of privilege? Need to insert a security pipeline to extract the attributes from the signed token and integrate that to the internal authZ code.

The mapping from the problem to solution is figured out, so are the protocol choices, what is left is the hard part - integrating to real systems. The security industry has not really tackled this problem at scale, and that's where we need to go next - security integration patterns - what's necessary for this to collaborate in the system factoring in the first mile and last mile integration, communication protocols, persistence, session state, and interfaces.

The security industry very much wants you to think there are security problems. There aren't. There are integration problems.

I will leave it here with an illustrative excerpt from Brilliant Orange:

"Schipol established itself as the world’s most admired and eagerly studied airport. It grew rapidly and became a central hub of Holland’s economy and transport system. In the late 1980′s, to resolve the problems of ever-growing congestion, architects Jan Benthem and Mels Crouwel were given the job of enlarging and improving Schipol.

The partners have been dubbed ‘the Houdinis of the Polder’ by critic Art Oxnaar for their ability to solve complex architectural problems. They have designed such high-prestige buildings such as the Anne Frank Museum and are now integrating a new subway line and bus station into Amsterdam’s Central Station, a projec likely to change the face of the city…instead of using separate buildings (or parts of buildings) for separate functions (arrivals, departures, shopping, etc.), the architects insisted on just one sleeks grey-white steel and concrete building, in which everything was integrated…’Normally, everything is split up and problems are solved separately,’ says Jan Bentham, the airport’s chief architect since 1985. ‘That makes individual problems easy to solve, but the connections between problems become very complicated and something simple ends up in a real mess. If you integrate it in the first place, that turns out to be the most simple solution.’

Schipol’s integrated structure allows huge volumes of freight and passengers to circulate at high speed and with remarkable precision. The simplicity and flexibility of its basic grid design (the grid is even visible on the airport’s floor tiles) means different elements in the building can be switched around constantly to meet ever-changing needs. The complex and huge flows of people and cargo are shifting constantly. Even small changes in one area will ripple consequences through the entire system. For example, if fewer passenger use one ‘finger’ of the site, the customs desks, shops, or bus station all have to be modified. The key to solving these problems is a mixture of quick thinking and careful preparations. ‘You must have a plan, but you also have to be ready to change it at the last minute or to make a decisive, sudden completely unexpected movement to arrive at the place you want.’ A rigid approach would be doomed. ‘You must never say: “I’ve done my work in advance and nothing will keep me from my path.” We don’t plan the track; but we plan where we want to be. We have several tracks in mind and we are always ready to change track or re-group or have a new solution or be able to react at the last moment. We tried to make Schipol so flexible that you can always change course. You need a simple system where, if something goes wrong, you always have a second, third, or fourth solution at hand. For example, we always insist that the buildings have strong floors. When you build an area you must always expect that it will be used for something else. It starts out as a waiting area, but maybe they want to build shops there. Maybe they want a bank, too, which has a heavy safe in it. When the traffic flow changes, it becomes perhaps a baggage-handling area with heavy machines or a big hole on the floor…no grand visions, but clever solutions’

Schipol, meanwhile is grappling with barely less complex questions of identity of scale. As it grew from seventeen million passengers in 1989 to thirty-eight million a decade later Schiphol mutated into a small city, with burgeoning numbers of offices and cafes and a shopping centre. the airport has become so large – and its attendant congestion and pollution so irksome – that plans even floated (before being rejected as too expensive) to relocate it to an artificial island twenty miles into the North Sea connected to land by a high-speed rail-link. The culture is changing too. “The whole airport environment has changed in the last ten years. From a functional machine for traffic it has become much more of an environment for spending time and and money in.’ says Bentham. ‘Airports of the past were places where you basically didn’t want to be, just a space to pass. It’s nice to make spaces where people enjoy themselves and like to be.’

The authority at Schiphol has come up with a radical new problem. ‘They always said to us: “We want sober and functional.” Now the new manager thinks the time for sober and functional is over. He says he likes the cosy atmosphere of the airport at Christmas. It’s very nice at Christmas. We have lights everywhere, trees every ten metres. The manager said: “We need to have the airport like Christmas all year round.” Well, Holland is an entirely artificial country. You want Christmas all year round? We can fix that, no problem.

The airport has fundamentally altered, though. It makes most of its income form shopping rather than anything related to flying. That means Bentham must juggle totally contradictory imperatives. ‘In an airport you want the best flows, the most obvious route from one point to another. In a shopping centre, you want people to get lost. You let them in and never let them go out again! So you have to combine that in the airport where it is changing from a machine for traffic into a machine to generate money. So you have to have a fine balance between finding your way and losing your way! You have to realize the problem and make the best of both worlds. What is the shortest way from your car to the airport bu that makes it impossible to miss the shops? That’s the clever solution.’

Solutions, solutions. Problems, problems.

In football, Johan Cryuff says, ‘Simple play is also the most beautiful. How often do you see a pass of forty meters when twenty meters is enough? Or a one-two in the penalty area when there are seven people around you and a simple wide pass around the seven would be a solution? The solution that seems the simplest is in fact the most difficult one.’ Benthem takes the idea a stage further: ‘I think it is very Dutch to look for a simple solution. And the biggest thrill in our work is to find an even simpler solution. That is what we like. In the end the most satisfying solution is the one where you have cleared everything away and there is no solution at all anymore but, at the same time, the problem has been solved. That’s the nicest way of doing it.’”

Part 2 - Reorienting Towards Security Integration