Applying these 10 mental models for making decisions daily can help any infosec team (in reality, any team) to accomplish its mission. These mental models are general knowledge and common sense. The difficult thing is not to know them, but to take them into account and apply them every day.

1. Give/Request/Demand

“Give, and you will receive” – Luke 6:38

Security teams have to be excellent at giving, excellent at requesting, and excellent at demanding. In that order. A security team cannot request anything if it has not been excellent at giving, and it cannot demand if it has not been excellent at requesting.

Being excellent at giving means doing active listening, understanding the needs of the person in front of you, and making their need your need before trying to fulfill it as far as it is at your hand. To be excellent at giving you have to go beyond what is expected. You have to put yourself in the shoes of the other person.

For example, imagine that you want to improve the complexity of the passwords used at your organization. You are part of the security team, so you have the option of establishing a security policy that enforces everyone to change their password and to require a complex one. But, enforcing a policy is “to demand”. If you apply the Give/Request/Demand mental model, have you been excellent at giving and requesting first? To be excellent at giving you should have explained to everyone why do we need a more complex password, and why it is important for your organization. You should have researched what is the appropriate minimum complexity. You should have investigated what complexity other similar organizations are requesting or enforcing. Credit cards don’t have complex passwords, just a 4 number pin. Why? Maybe because they are multifactor? Have you considered the possibility of using multifactor authentication and not making the passwords more complex? Have you explained and given options to the users to generate and store those complex passwords? Something like Keepass, for example?

That is what you have to do to be excellent at giving. But, before demanding, you have to be excellent at requesting too. Before enforcing a password change with additional complexity, it could be a good idea to request users to change their password to a stronger one and give them enough time to do it in a planned way. By being excellent at requesting you probably will get feedback about why some accounts cannot have more complex passwords (service accounts whose password cannot be changed, legacy systems…). Listening to the feedback and giving solutions to it is part of being excellent at giving. If you had jumped directly to demanding you hadn’t had this feedback and your project would have caused unnecessary frictions.

Applying the Give/Request/Demand mental model has many many benefits: those around you are happier to help you in response to your help, the communication with those around you improves because you state more clearly why you are trying to establish a policy, your leadership, and authority, increases because people see that you do your part before requesting something, etc.

2. Words convince, but example drags

Lead by example. It is more important what you do than what you say.

If the security team says that some security control has to be implemented, they are the first team that has to implement it. There are sometimes that security teams think that they are especial, than because they are the security team, they don’t need to comply with the same security controls, because they are to be trusted. Other teams probably think the same about themselves, and they are probably right. If you, who are security experts, are unable to implement a security control in your team in an agile way, imagine the problems other teams have. You cannot look the other way.

The security team has “to eat its own dog food”. If you say that everyone on the company has to use strong passwords, all members of the security team has to use strong passwords; if you say that everyone in the organization can only use approved cloud applications, the security team cannot use any non approved cloud application.

Another way of leading by example is being coherent. The security team has to request everyone in the company, without exception, to comply with the security policies. If you think that a security measure is necessary, you have to try to convince the board to comply with it too. It is not naive, it is being coherent. If the company is how it should be, and the security measure is proportional to the risk and makes sense, the board will comply. In the end, the board will decide what they want to do, as they probably have enough power to circumvent the security team’s prescriptions, but the security team should be bold enough to defend their ideas until the end.

3. Nobody’s born knowing

“Everybody’s gotta learn, nobody’s born knowing.” – Harper Lee.

Everyone has to learn before they can do. Don’t expect that the programmers of your organization know how to program securely if they have not been trained in secure programming. Don’t expect that your users use a password manager if they have not been taught how to use it. Don’t expect that your board understand security if you have not trained them.

Even when a highly experienced person joins the security team, they have to be trained before they can perform at their maximum level.

Training someone requires effort and time. This mental model sometimes is worded as “Nobody’s born knowing, and we don’t like the consequences“. The consequences are that we cannot explain something to someone today and expect that tomorrow they will comply perfectly with what you requested. Always there is a time between one person starts to learn and they can apply what they have learned. People need training, repetition, and time. Security teams, and leadership, have to be lighthouses.

4. Everything can be improved

Nothing is perfect as it is. Perfection does not exist. Everything can be changed to be improved. Don’t settle. Always listen to and request feedback. Especially, feedback that points to what you can improve. Avoid the compliments.

Take all ideas into account. When one person expresses their disagreement with anything, many other people think the same, but don’t say it.

Many security controls can be improved to make them more aligned with the business. The security work should be aimed at adding security and also at reducing complexity.

5. The way is made by walking

Don’t let the perfect be the enemy of the good. Think before doing, but do. It is important to do what is necessary to gather information and facts, but we usually are unable to make decisions that are going to be right with 100% probabilities. We always have to accept some risk for taking a wrong decision.

Only by walking you can see results. Experiments are our allies. Don’t enforce a security policy for all the company. Enforce it on a sample of employees and gather their feedback. Don’t try with the more difficult users at the end. Choose a good sample of users at the beginning and extrapolate the results of a such small sample to the whole company. If in a sample of 10 people, 4 didn’t understand what you requested, that’s 40% of the company. If for 100 computers, 5 failed, that’s 5% of the company.

Between you and your objective, there is never a straight line. It is always a zigzag. After you make a decision and start applying it, you may find new information that shows you that your decision was wrong. It’s not unprofessional to stop and say that you were wrong. On the contrary, that’s being intelligent and think what is best for the company. People that fall in love with their decisions and never change their opinion, because they are afraid of showing weakness, are dangerous.

6. Every effect has a cause

If something happens, there is a cause. Don’t fix the symptoms. Find and fix the root cause. If some emails are being blocked by the email gateway, you have to understand why. If not, some important emails will be blocked in the future. If some computer is showing a weird behavior, you have to investigate why. Maybe the computer has been compromised and is waiting to escalate privileges and encrypt your network.

I remember that one day after WannaCry, we saw a malware alert on a computer in a warehouse 8 hours away from our location. One alert on one computer on an organization with more than 100.000 devices. The alert was one custom alert we created specifically for WannaCry. One person from the warehouse took the computer, a laptop, and brought it to us. This happened on Saturday, and he arrived on Saturday night. We started a forensic analysis that we finished at 4:00 am. Luckily, it was a false alarm.

This is an extreme example. But what is important about this is that we cannot look the other way if there is an anomaly. We have to understand everything that could be relevant for security. Never look the other way when you see a sign that indicates that something is happening. Be obsessive with anomalies. Try to understand everything that might be relevant.

Ask “why” 7 times. Usually, we are ok with the first answer we get, but very frequently that is not the root cause. This doesn’t happen because things happen…they happen for a reason. We tend to think that knowing approximately what has happened is enough to do it better next time. That’s not true. If we don’t understand the underlying reasons for something, we are condemned to have the same issue again.

7. Time is limited

“Your time is limited, so don’t waste it” – Steve Jobs

Prioritize. Choose what to do and what not to do.

When a security team does a security audit it can identify many vulnerabilities and risks. Be very specific on what is important and what isn’t. Focus on the important vulnerabilities.

Don’t overcommit. You can’t do everything. Respect your colleagues’ time.

8. Tell me how you measure me and I will tell you how I will behave

People behave differently, depending on how they are measured:

• If people are measured for being fast, they will be fast (although quality may be negatively impacted).
• If people are measured for good quality, the quality will be good (although speed may be negatively impacted).

This is neither good nor bad. What this means is that we have to be careful to measure by the right metrics or we may provoke an unexpected behavior. This is also known as the “Law of Unintended Consequences“. The popular tale says that once upon a time, there was a town with a plague of rats. The local council established that they would pay money to anyone that brings them a dead rat. They wanted people to start killing the rats. Instead of that, people started to breed them. There is a similar story with cobras so this is also called the “Cobra Effect”.

When you interact with other teams be mindful that their behavior may be a consequence of how they are measured. Try to align your requirements and requests with how they are measured and you will get better results.

9. What is not verified doesn’t exist

At security, anything that has not been verified doesn’t exist. Do we have backups? If we have not verified them, they don’t exist. Do we have a contingency play? Are users using strong passwords? Do our default security controls protect against this flaw being exploited to escalate privileges?

Assumptions are frequent in our life. We need to make assumptions to be able to live because verifying everything is not possible. For example, is the food we are going to it poisonous? We have to verify it! That’s not possible. But we have to be aware that in order to say that something is or behaves as we think, we should verify it first.

10. All organizations are assembly lines

Every position in a company receives an input from someone, processes that input somehow, and produces an output that is given to another position.

If we produce a defect in our process, that will affect the next person on the assembly line. It is not very bad to produce a defect, but it is a fact that if the person that receives the deliverable with the defect will need to spend time fixing it, if they detect it, or they will pass it to the next person in the “assembly line”.

When we are mindful of this mental model, we know that if we change something in an organization, it will affect someone in some way. You cannot change a process without thinking about who will be affected, although you are the owner of the process and you have the right to change it. Before changing a process or a policy, think about who is going to be affected, and talk with them before doing it.