"I think I've been in the top 5% of my age cohort all my life in understanding the power of incentives, and all my life I've underestimated it. Never a year passes that I don't get some surprise that pushes my limit a little farther." - Charlie Munger
In Security Engineering, Ross Anderson describes an analytical framework for examining information security:
"Good security engineering requires four things to come together. There's policy: what you're supposed to achieve. There's mechanism: the ciphers, access controls, hardware tamper-resistance, and other machinery that you assemble in order to implement policy. There's assurance: the amount of reliance you can place on each particular mechanism. Finally, there's incentive the motive that the people guarding and maintaining the system have to do their job properly."
These four pieces describe the security puzzle well. I add two things for projects, the first is Use Cases that describe how the system serves the user.
What you notice here is that the Use Case's job is to describe how the system serves the user, and the security framework's job is to protect, but there is no direct touchpoint to/from functional use cases to non-functional security aspects.
To close out this gap, I use Threat Models. Threat Models turn the system on its head, look at how things can fail not how its supposed to work. Use Cases are great at showing how the system is supposed to work, Threat Models show how they fail, in practice we need both views.
The Threat Model connects the security framework to the usage-
- Threat Models show where the Policy proscribes usage, such as based on handling sensitive data or requiring SoD
- Helping to identity what countermeasure mechanisms are needed and where
- How to test the system and its countermeasures
From my view after using the framework for many years, it was and remains an effective analytical tool as long as its connected to Use Cases. We cannot have to isolated frameworks they have to be connected, Threat Models are that bridge layer. Ok, we need authN, where? Ok, we need to test for Elevation of Privilege, where? Threat Models map to/from security <--> usage.
But as much as the security framework made sense to me when I first read Security Engineering, I thought Ross Anderson was too clever by half putting incentives next to policy, mechanism and assurance. Now I think he ranked it too low!
"From all business, my favorite case on incentives is Federal Express. The heart and soul of their system—which creates the integrity of the product—is having all their airplanes come to one place in the middle of the night and shift all the packages from plane to plane. If there are delays, the whole operation can't deliver a product full of integrity to Federal Express customers.
And it was always screwed up. They could never get it done on time. They tried everything—moral suasion, threats, you name it. And nothing worked.
Finally, somebody got the idea to pay all these people not so much an hour, but so much a shift—and when it's all done, they can all go home. Well, their problems cleared up overnight."
Its clear that incentives drive policy decisions that's business as usual. What was less clear to me years ago was how much incentives drive development and operational behavior. If you ignore that you limit the effectiveness of any security mechanism or assurance activity that you might want to deploy.
Its deceptively simple to think that people will just make rational, informed tradeoff analysis, and risk based decisions, but that's just not how it works. Incentives drive organizational behavior way more than risk.
Incentives need to be factored into all security mechanisms and assurance. Otherwise your security architecture will just be a paper tiger. If you want your designs to see the light of day and meet the metal of production, give a heavy weight to the incentives of developers and ops teams that you need to collaborate with. A big part of this is simplicity, from my keynote at Cloud Identity Summit:
Five Guys is tremendously successful, their menu is dead simple. Cheeseburgers and fries. They have franchisees that beg them to add milkshakes to the menu, but they don't. The reason why is pretty interesting.
Five Guys' marketing budget is zero dollars and zero cents. Think about how many fast food ads you see on a daily basis for McDonald's or Burger King, but Five Guys has grown with a budget of nothing, nada, nyet. How do they get the word out to build such a successful franchise?
They rely on food critics. Go into any Five Guys and its covered in Zagat and every other local and national write up. What does this have to do with a simple menu? Five Guys' founder, Jerry Murrell, explains that critics write about what they like. They also write about what they do NOT like. So the menu is designed to be operated by a 17 year old - simple, simple, simple. Has to be excellent every time.
This is the same reason Five Guys does not offer coffee. People have begged for that too. Jerry Murrell asked a prescient question - have you ever had coffee made by a 17 year old? He ran a test. He made coffee left it out over night, heated it up the next day and served it to his sons, how did you like it? tastes great they said. Presto - still no coffee at FIve Guys.
It may seem far afield to think about cheeseburgers, milkshakes and coffee, but its anything but. We've all had great coffee and milkshakes but can you _operationalize_ it with your developers and operational team? Usability is much more than users, how easy it it to program? Most identity systems aren't
API Gateways are helping here, especially on provisioning. But how easy is to debug? THis is often harder still
What about testing and verification?
Do I hear crickets and curl scripts? Yes.
We need identity systems with better usability. Not just for users, but for developers who have to implement and test them. They need to be brain dead simple.
Developers and Ops folks already have a 40+ hour/week job, everything that we security people ask them to do means they need to stay late, work weekends. I know we all want developers to "do it right" but our incentives are not their incentives, further we should hold ourselves in security to the same standard, find things that are simple enough to mitigate threats and to make it from design through to deployment. To do security well means analyzing not just threats, vulns and mechanisms, it means identifying activites and secruity improvements that align with incentives.