1 Raindrop

Gunnar Peterson's loosely coupled thoughts on distributed systems, security, and software that runs on them.

Recent Posts

  • Security Champions Guide to Web Application Security
  • Security > 140 Conversation with Pamela Dingle on Identity
  • 6 Things I Learned from Robert Garigue
  • The Curious Case of API Security
  • Security Capability Engineering
  • Ought implies can
  • Security > 140 Chat with T. Rob Wyatt on MQ and Middleware Security
  • Privilege User Management Bubble?
  • The part where security products solve the problem
  • Four Often Overlooked Factors to Give Your Security Team a Fighting Chance

Blogroll

  • Adding Simplicity - An Engineering Mantra
  • Adventures of an Eternal Optimist
  • Andy Steingruebl
  • Andy Thurai
  • Anton Chuvakin
  • Beyond the Beyond
  • cat slave diary
  • Ceci n'est pas un Bob
  • ConnectID
  • Cryptosmith
  • Emergent Chaos: Musings from Adam Shostack on security, privacy, and economics
  • Enterprise Integration Patterns: Gregor's Ramblings
  • Financial Cryptography
  • infosec daily: blogs
  • Jack Daniel
  • James Kobielus
  • James McGovern
  • John Hagel
  • Justice League [Cigital]
  • Kim Cameron's Identity Weblog
  • Krypted - Charles Edge's Notes from the Field
  • Lenny Zeltser
  • Light Blue Touchpaper
  • Mark O'Neill
  • Off by On
  • ongoing
  • Patrick Harding
  • Perilocity
  • Pushing String
  • Rational Survivability
  • rdist: setuid just for you
  • RedMonk
  • RiskAnalys.is
  • Rudy Rucker
  • Software For All Seasons
  • Spire Security Viewpoint
  • TaoSecurity
  • The New School of Information Security
  • Windley's Technometria
  • zenpundit
Blog powered by Typepad

Security Engineering and Incentives

"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.

Secframework

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.

Tm

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!

Charlie Munger:

"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?

Five-guys-menu-1

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.

August 17, 2013 in Security Engineering | Permalink | Comments (0) | TrackBack (0)

My Photo

SOS: Service Oriented Security

  • The Curious Case of API Security
  • Getting OWASP Top Ten Right with Dynamic Authorization
  • Top 10 API Security Considerations
  • Mobile AppSec Triathlon
  • Measure Your Margin of Safety
  • Top 10 Security Considerations for Internet of Things
  • Security Checklists
  • Cloud Security: The Federated Identity Factor
  • Dark Reading IAM
  • API Gateway Secuirty
  • Directions in Incident Detection and Response
  • Security > 140
  • Open Group Security Architecture
  • Reference Monitor for the Internet of Things
  • Don't Trust. And Verify.

Archives

  • November 2015
  • October 2015
  • September 2015
  • August 2015
  • July 2015
  • June 2015
  • May 2015
  • April 2015
  • March 2015
  • February 2015

More...

Subscribe to this blog's feed