f-viktor@github.io%

Better than Best Practices

The Best cats are YOUR CATS

If you work in the security field, you have probably come across lists of best practices and accompanying checklists. They were written to help us get to a good baseline of security, and to show other companies that we did so.

Some of these lists have been written by groups of people much smarter than I, and almost as smart as you, dear reader.
So is it really possible to improve upon them?

Specificity and Universality

The expert committees establishing these guidelines drew from their experience across various companies to create a universal rule set that anyone could use. Their hope was to create a system that can be used to tame the wild variety of real companies. Standardization always seeks to enable scaling by forcing the organic chaos of the real world into manageable uniform abstraction.

However, these committees did not, and could not know the intricate details of your company. Since the goal was to create a guideline that anyone could use, it would’ve been a mistake to create the best practices for you.

Insofar as no two companies are the same, their specific best practices must also differ. Consequently, the so-called “best practices” are only the best for the theoretical uniform abstraction that is the generic company.

“Don’t roll your own practices”

One best practice I often repeat is “Don’t roll your own crypto”. It contains a message of humility: “smart people spent a lot of time creating something good; do not assume that you are smarter than all of them.”

When we learn something new, we are often presented with rules. Music teachers say a certain chord will always sound happy, grammar teachers will say you should always order sentences in a certain way, and chefs will say you should never put pineapple on pizza.

What seem to be absolute laws to the beginner often turn out to be mere suggestions to the expert. The best musicians will throw convention to the wind, the best poets will write without any care of sentence structure, and I will put whatever I please on my own pizza.

These rules are actually simplifications that are generally, but not always, true. To become an expert is to understand why each rule exists in the first place. Once you have full understanding of the mechanism that creates the rule, you will be able to predict when the rule will apply, and when it will be superseded by the underlying mechanism. It is in this latter case where we can improve upon the best.

After all, when an incident occurs, the company will not be able to defer responsibility to the PCI Standards Council or the ISO simply because it met their checklist requirements. Therefore it is up to all of us to take responsibility for the outcomes, and become the experts we claim to be. Only we can deliver what is actually the best for our specific situation. Of course this does not mean that we can ignore standards, but it does mean that we should consider how we meet, or exceed them.

Right Here, Right Now

What makes your company different? We all live in a specific time and place, we work in a specific industry, there is a shifting market environment around us, and we need to take a certain amount of risk. All of that matters, but rarely mentioned are the very people who make up the company.

There is a tendency for corporations to think of our fellow men as interchangeable “human resources” with no differentiating attributes. For someone overseeing an organization with thousands of employees, it is hard to track how many people work in the security department. It is impossible to know their individual strengths and weaknesses. But within lower levels of management and the team itself, people know each other by name, and have a good idea of who is good at what.

Maybe your team has an absolute wizard when it comes to mobile security.

Do you have someone who is good at presenting?

Do you have a large variety of products?

Understanding the individual nature of your coworkers allows you to better allocate resources. Even more importantly, it can turn compliance chores into work that brings real benefits. When individual developers understand that your policies really improve their specific product, that creates strong results. For that to happen, you have to deliberately work to understand each individual situation, and create policy considering the human beings it will apply to. When the reasoning is surface level, such as “do it because it is best practice”, developer motivation falls off a cliff.

Many times people do things out of habit, or because it is the standard, or because that is how others do it. I would like to encourage you to think about why you do what you do. What are you actually trying to achieve, and is the “best practice” really going to get you there?

Key takeaways