Security Analogies

I have a lot of trouble navigating conversations with customers about the need for security. One reason is that it has become too obvious to me that some parts of it are important - I forget that many people haven't started asking the basic quetsions. Another reason is that I don't have a perfect blueprint and I don't believe one exists - every organization and case is different. A third is that peoples' eyes gloss over at the word security. Security, isn't that going to cost a lot for something you can't guarantee anyway? I was advised by a close friend and trusted advisor not to even use the word security!

Maybe the most important reason that I struggle is that I resolved when I started Jemurai not to sell through fear. Don't tell me, you'll be the Nth person to tell me that you have to sell security through fear. I just don't like that approach and I think there are more constructive ways to go about it. (Of course, we'll see if Jemurai survives!)

Anyway, in diving deeper into nuanced discussions with customers about security, I have found that analogies to things in everyday life are extremely valuable. They help to give clients the tools they need to think actively about the problems they are trying to solve. People don't think in black and white about their homes or their bodies, so somehow these analogies make it easier to grasp that they are not going to solve their problem.

Here they are. I hope they help people engage with customers in a more nuanced and constructive way.

Your organization is like a neighborhood

In one case, I started with the analogy that an application is like a house. It has plans, materials, flaws, and an interdependence on water, electric and road services. This seemed appropriate in that you can see certain things based on the exterior of the house - just like you can see things from an application's surface.

In a real client, there are usually many interconnected systems, so let's extend the house analogy to a neighborhood analogy where houses are applications, schools are databases, roads are networks and fences and gates are firewalls etc. A casual observer may have seen the borders of your community and identified some potential issues. Others may have also looked at some of the houses. The google car definitely drove through to take pictures.

A code review is like looking at the plans for the house. A pen test is like trying to break in to the house. Many houses change over time, build additions, add pools, get their roofs fixed, etc. Every one of these might change the quality and attack surface of the house .. er Application. You wouldn't build an addition without planning for a fire exit! (design review) Once you built the fire exit, you would make sure it was locked from the outside. (incremental review) You would communicate how to access it to your family (policy/standards). Also, you instinctively know that the quality of work performed by different contractors is going to vary - and that things break! (testing)

What would happen if you found out the drywall used to make your house had mold? You would replace it ASAP. Think of the Rails libraries widely used to build Ruby on Rails applications! Similarly, when you go to replace the drywall, you would buy it from a place you trust. Maybe a major vendor with a guarantee. Does such a thing exist for obtaining new software libraries (ruby gems)? In fact, with the recent rubygems incident, one wonders if it is in fact even possible to do this. Note also that this is not unique to ruby gems, Node.js had a similar issue when their couchdb instance was publicly listening on the internet. This is like buying stolen goods from your well respected retailer. How can we be sure we aren't buying replicas? Incidentally, please contact me if you think it would be a good idea to explore running a "secure" gem (jar, npm, etc. server).

It is undoubtedly the case that having a prominent resident that is known outside the community (Walter Payton?) may attract attention to the community as a whole. Maybe the teenagers that stop by that house are making the rest of the community nervous. Maybe there are parties or contractors installing fancy equipment. This is the type of attention that a prominent external application may bring to the otherwise quiet neighborhood. Maybe nothing bad will happen...but to say there is no change in risk is blind.

The question for customers is how nice do they want the neighborhood to be? Ultimately, you want to have the right ratio of protection for your lot in life. If the neighboring community is run down and you look like a fancy neighborhood, then you might want to invest a little more in a fence and security cameras. You might become a gated community. If you are mostly a sleeper community without fancy cars to attract attention, then you just want to make sure your fences don't have gaping holes and doors aren't left wide open. Believe me, there are plenty of people trying to sell you fancy alarm systems that may or may not be worth the money!

Now, surely we both realize that there is no way to achieve certainty that the proper controls are in place. To know what the most important steps to take are requires a scoping phase and extensive discussion and negotiation within the customer, let alone with a vendor or third party. Maybe by creating a separate road to the Walter Payton house, or putting up an additional fence around the house, we can substantially limit the level of concern for the neighborhood as a whole without a major project. Maybe not. Surely different residents are going to feel differently about where to build the road and how to pay for it!

The primary goal of the scoping phase would be to build a map and a blueprint for the future: identify the network, data to be protected, practices currently in place and the most efficient way to move forward to the key customer objectives. Just like a community, a customer needs to fund schools, fire departments AND police.

Generally, the key attribute of the way I recommend approaching this is following an agile approach to try to make tangible steps forward, measure, re-evaluate and step forward again. One benefit of this approach is that it can work even with varying levels of investment. Another is that it can adapt as assumptions change, politics emerge (oh my!) or priorities shift within an organization. Community planners rarely set out with guarantees about budgets for the next 10 years - and maybe they shouldn't! Similarly, organizations should plan to engage and manage any security process in their community.

Your organization is like a patient

Another way to look at it is as a patient going to the doctor. You (not *you* but the patient) don't know of any problems, but you are aging and planning to travel to countries where you need vaccinations. The doctor will do a physical and identify a number of things you can do to improve your health. Some of them are cheap and you will do them: take an aspirin pill or drink a glass of wine every day. Others are cheap and you won't do them: exercise 5 times a week and give up smoking. Some are more expensive but are way worth it: certain prescription drugs (ex. lipitor). You can change doctors or get a second opinion when you get a surprising piece of advice. In any case, the worst thing you can do is not do anything and never go back to the doctor!

In some cases, the doctor may send you to a specialist about your heart, colon, skin or what have you. These are analogous to deep dives on applications or networks. Generally speaking, I'm recommending an approach that involves motivating ourselves to do a minimum of exercise and diet (the cheap but hard organizational ways to improve things) with appropriate checks (say a colonoscopy == pen test) according to our age and the circumstances. The goal is to avoid the costly emergency ER visit (Intrusion response) and having to tell friends about a critical health issue.

Changing infrastructure or adding applications is like adding a major organ system to a person. It could be fine, in fact it could improve the quality of life tremendously, but it should be checked. Different processes make sense for different organs and body parts. Different health care systems result in different strengths and weaknesses for their patients just like different security practices result in different results for organizations that employ them. Anyone who is selling one way to manage your security is glossing over something somewhere.

Takeaways

• Using analogies can help to communicate about security.
• It is possible to EMPOWER clients to make their own appropriate decisions about security using proper analogies.
• A client that can build a mental model for why they are doing security can adjust and think on the fly to adapt.
• Every mental model will be flawed. It takes active thinking and honesty on all sides to ensure that it is being used effectively.

If you are interested in engaging with a partner that won't try to scare you and can handle the complexity of nuance and changing priorities - check us out.