Security, Fast and Slow

One of the best books I have read in many years is Thinking, Fast and Slow. At the heart of the book is two systems - System One and System Two. They both play into decision making in different ways. For System One, think catching a ball, for System Two think - doing your taxes.

System 1: Fast, intuitive, frequent, emotional, subconscious

System 2: Slow, effortful, infrequent, logical, calculating, conscious

Both systems represent ways of thinking and they are both important, but besides the fact that they both reside inside the same bag of bones, they have little in common.

Naturally, reading Kahneman's work my thoughts turned to security architecture. Software is a System 1, Thinking Fast world, with Agile processes and its ilk, Software development is a 90% System 1 world at least

Conversely, the history of infosec is littered with (failed) System 2 ideas - data classfication, trustworthy computing, end to end security, and on and on. All these ideas have merit, occassionally they even work in some scenarios. What they do not have is - any sort of currency in a System 1 world. that more than anything is infosec' biggest issue, its not "the businesses" fault, its not developer's fault, its not that people do not care about security, its not that the tools suck. All these things play a role, but the biggest factor is that infosec makes 90% of its recommendations assuming a System 2 world while everyone else is busily living in a System 1 world.

It does not have to be this way, though, this is not to say that security has to be 90% System 1, but its critical that security teams know that any recommendations that they make are going to be given to people that operate in System 1 land. To get adoption on any security improvements, where you are relying on some other teams - your guidance absolutely has to match their system and dollars to donuts that system is going to be a System 1 system.

A good example of System 1 Security is SSO. It solves a very specific problem, mostly there is minimal integration, easy to understand, makes things simpler, doesn't block developers or the business, once installed it just works, project measured in weeks.

A good example of System 2 is Provisioning. Process oriented, data cleansing, data mapping, heavy integration, expensive, tradeoff analysis, continual tweaking, projects measured in quarters.

This isn't to say one is more vital than the other. SSO is more or less always going to generate more enthusiasm from developers and users, but that does not lessen the long term importance of provisioning. In fact, if you are going to have users doing SSO, then that increases the importance of a high quality provisioning system.

• System 1 Security: SSO, WAF, Vuln Scanners, Checklists
• System 2 Security: Provisioning, Data classification, SDL, Fuzzing 

Infosec can and should tailor more guidance to System 1 inhabitants. Still its totally acceptable to continue to push for System 2 type capabilities, but, and  this is the key - any System 1 guidance can and should be outsourced to other teams while any System 2 guidance must be owned by infosec throughout its lifecycle as there is no one else who is going to operate in that mode.

Another example, Role Based Access Control, like  many things in infosec it has a foot in both Systems. The enforcement of RBAC is System 1 - access granted or access denied. Classic System 1, boom, go. But what users go in what roles? What level of granularity is right? Who engineers this? That is all System 2. The RBAC tool can get you to a System 1, but you have to get the System 2 stuff working and that is the hard part.

The issue I see is that when infosec teams say "I wish the devs did data classification or threat models or this or that", what they are really saying is- "I wish software was written with System 2."Whether it should be or shouldn't be is an irrelevant question, its not written in System 2, its written in System 1, and infosec has to cope. Your appsec plan has to factor this in.

Fixes must be addressed in a systematic manner too. You can't slam a playbook of System 2 ideas and processes and simply expect it all to "just work" in a big bang. Have to aim for a balance - find things that work in System 1 and be prepared to own anything yourself that is a System 2 assignment.

Most of the tool industry has figured this out, they are already in System 1 land - WAFs are a great example. What you have to watch for in tools, is that vendors create the illusion that you can have System 2 capabilities in the free and easy System 1 world, its not that simple. The System 2 stuff is very valuable, but there are no quick wins. Tools should be evaluated based on whether they are solving a System 1 or System 2 level problem and judged accordingly.

For System 1 solutions, you have to take a sober look not at what it could do in theory but what it can do in practice. Look at WAFs they can do a gajillion System 2 things, but realizing that value in practice means the long hard slog of data classification, URL inventory, and understanding yoru inputs and outputs at a granular level. So WAFs get bought because the demo shows that they can block SQL Injection, CSRF and a whole laundry list of attacks, then in reality when they get turned on they are used to terminate SSL and maybe catch a particularly poorly written XSS attack.  By the way tools, including WAFs, are great, but enterprises have to be aware that tools cannot magically cross the chasm between System 1 and System 2.

There is no sin in solving System 1 problems in fact Infosec should get better at this.  A scenario to avoid is paying a System 2 price for System 1 level capabilities. This happens way more often than people think. Another scenario to avoid is running many different System 2 projects. You have to know going in that these are marathons. If your company has never run a marathon do not sign them up to run three triathlons at the same time. Organizations get exhausted. For most companies a small number of System 2 projects at any given time makes more sense.

The good news is that there is no shortage of security problems. And we do have some solutions, what is important is to maximize the value of the solutions that we have, avoid System 1/System 2 mismatch, and chopping up the possible tools, people, and process solutions in System 1 and System 2, greatly aids the adoption of security improvements.

Comments

[David Shaw]

Gunnar, your infosec blog entries are informative and often thought-provoking. This one triggered my brain's safety pressure relief valve! Your one raindrop is still rippling my ectoplasm.

What a neat, simple way of thinking about the source of frustration experienced by users, business leaders, infosec professionals and tinkers.

It certainly helps to focus thinking about the payback (or lack thereof) we see in projects like some GRC 'automation' implementations (System 2 response paying lip service to System 1 interactions).

I also wonder whether a marker for robust, maturing infosec posture is that any measure introduced that delivers a System 1 outcome should have a System 2 corresponding capability performing analysis on effectiveness, efficiency, relevance.

[gunnar]

Hi David,

You nailed the main action item, there has to be some level of integration between System 1 and System activities. Most of the time they are separate which I think is a major contributing factor to infosec's current state of affairs. Its not that people do not spend money and its not that people are not working hard, but they are not rowing together.

[Jarrod Stenberg]

Great insight.

Now if only I can find a way to attach my System 2 design to a small project that doesn't even want to talk to a security guy in the first place. I think I'll just conclude that they don't care or that they are too stupid to get it when they stop inviting me to their meetings.

[gunnar]

Jarrod,
"System 2 design to a small project that doesn't even want to talk to a security guy in the first place." Says it very well.

When we come in with these uber long list of requirements, it feels like we're telling someone to read War and Peace before they can make a grocery list and dash out to the store

[DanielMiessler]

Interesting thought, Gunnar. This also raises the training point again, though, as the purpose of training is to take a type 2 activity and make it a type 1 activity--like a martial art.

Or do you think this doesn't apply?

[gunnar]

@DanielMiessler - That's a great example. And if you think about it that way, it should mean that most trainings become way more focused, way more practitioner oriented.

A lot security training mirrors the security policy, its a kitchen sink exercise. "Everyone say 'Least Privilege'" but following your logic, then I am going to carve out the bits that I want to transition to System 1. Then the training is more on the lines of why and how to do this instead of a series of System 2 whats.