Business of Cybersecurity

I want to ask you a question, and I want you to take a minute to think about it before you answer really. Are you ready?

When you think of security, do you think of it as a business requirement or a business enabler?

There is a right answer, although it may not be what you think. IT security, cybersecurity, whatever we want to call it these days is absolutely a business enabler, yet we treat it like a business requirement. Because, of course, we all love requirements. I don’t know about you, but I wake up every day excited to see what new requirements I need to collect and fulfill. It’s the high point of my day. It’s no wonder security has this dark shadow looming over it. For as long as I can remember, we’ve treated security like this “thing” that we have to do because we are required.

However, what if we change our perspective? Instead of looking at ourselves as enforcers and protectors, what if we looked at ourselves and conducted ourselves as enablers and problem solvers.

Now more than ever security has to be involved in everything we do. We are indeed in the digital age in which every company, no matter how big or small, is a tech company. Where there is tech there are vulnerabilities, where there are vulnerabilities there are risks, where there are risks, there are opportunities. We’ve seen the numbers, reports and all the fear-mongering that comes with today’s cybersecurity landscape. We know it’s important, but how do we make sure that everyone else knows as well? It’s time to change the narrative in security.

We’re Here to Help

We start by engaging with the business — as in, actually engaging with them. For example’s sake, let’s say we are helping a global bread company with their security. We begin by asking them questions about how they do business on a day to day basis. What’s productive for them versus what’s convenient? What can they absolutely not live without, and what is it that they won’t even miss?

Then, together, we decide on how to implement it securely. Now we’ll have to be civil and act like adults and realize that some compromise is going to have to happen, and also respect the boundaries of expertise. We won’t tell them how to bake bread, and they won’t tell us how to implement secure connections for emailing their super-secret bread recipe.

Instead, we’ll understand their needs, implement a solution and then see if it works for them. Yes, we’ll actually solicit feedback from our end users, and we’ll respond.

Security is in the Eye of The User

Next, we’re going to build our security army, much like Dumbledore’s Army, a rag-tag set of users who are eager to learn how to defend themselves against the dark arts, and phishing schemes.

We require a lot from our users, but we don’t take enough time to tell them why, or show them how to defend themselves. Just imagine it, if instead of having a workforce of users who are continually clicking the wrong things, following lousy security practices and installing random software, you had a workforce of users who were reporting phishing emails because they’ve been taught how to spot them and why it’s essential to do so. Users who put in application requests before installing software, because they know the process works and allows them to be productive. Users who teach each other best practices because they feel empowered to do so. Now your security team just went from a handful of soldiers to an army.

This all sounds like a fantasyland doesn’t it? I agree, and if I were on the other side reading this, I’d be the first one to pick up my rocks ready to tear down this glass house of wishful thinking. However, hold onto that rock for just a second. This reality is a lot closer than you might think.

The year of the data breach has had a considerable impact on the way we view technology and security. It’s led to the creation of legislation such as GDPR in the UK, and CCPA in the state of California. At the heart of both of these laws is one loud screaming theme: “Give users control of their data!”

If we think about that for a minute, to actually do what that means, we have to include the user in the process. Huh, novel concept: we should build something for a person by consulting that person and having them be a part of the process.

What comes next?

It’s time to engage with our users as we roll out and create the infrastructure to enable them to do their jobs securely. We’ll do that by doing the following things:

1) Ask questions. Talk with our users and ask how they do their jobs and why they do it in a specific way. We want to understand what enables them to be productive and valuable and then build a security posture around that.

2) Educate them. Plan education and training into our release cycles. Make sure the users know what’s coming, how it will affect them, and how to engage if they have questions.

3) Be responsive. In our world change happens at a blazing fast pace with new vulnerabilities and new attack vectors at every turn. Our tactics are continually being challenged and often need to be adjusted. Users are no different. Often they must adapt the way they work, and if security is a blocker to that, they find another way. We must be responsive in their changing needs and evolve the architecture to accommodate them. Like any good relationship, this takes compromise and communication on both sides.

The moral of the story is this: security is a business enabler, and we shouldn’t position it as merely being a required box that someone must check. On the contrary, it’s an active part in the everyday activities that enable the business to do what they do best while being secure doing it.