5 Cyber Security Myths Believed By Management

A while ago I ran across this white paper from KPMG Netherlands: The five most common cyber security mistakes: Management’s perspective on cyber security.  As I was reading it I found myself making my own list.

My list is called “5 Cyber Security Myths Believed by Management.” Here it is:

MYTH #1: Cyber security is a technical issue for which executive level business management has little or no ability to contribute

This is the number one most frustrating myth that I encounter. It’s never stated, but you see it in behavior.  And it’s not IT management with the problem. It is the highest level of business management.

The most glaring and common indicator of this myth is a lack of a security policy. It is management’s responsibility to define a security policy for the overall organization. Of course, that would require management to accurately understand what a security policy is!

By my sarcasm you can correctly assume that most executive management has no idea that they even need to understand what a security policy is. A security policy should define:

1. What needs to be protected. This includes data, software, hardware, and networks; and
2. What “protected” means for each information security item of value.

An information security asset is properly protected when everyone that should be allowed to manipulate that asset (as defined by the security policy) is able to do so but only in the ways defined by the information security policy. I describe a security policy as defining acceptable (and sometimes unacceptable) behavior of various classes of users with respect to various classes of information security assets.

A security policy does not contain information of a technical nature! Executive-level management provides leadership by defining standards for acceptable behavior across the entire organization. Then it needs to ensure that each sub-organization provides descriptions of the assets and the acceptable uses of that asset by that organization.

In other words, IT should take the security policy and “make it so.” By this, I mean that IT should use the various tools in its security tool belt to configure networks, systems, and data to either prevent or enable inappropriate or appropriate behaviors and/or to detect unsuccessful and successful attempts to behave in a way that is contrary to security policy.

One consequence of this myth is that, without a security policy that defines management’s standards for acceptable and unacceptable behavior, it is impossible for anyone to assess whether or not your business assets are “properly” secured!  By definition, assessments are supposed to test whether or not the network, systems, hardware and software are configured in a way that the company enforces its security policy.

MYTH #2: IT is, and should be, responsible for cyber security

This is a corollary of item #1. The IT organization is NOT responsible for cyber security! IT is responsible only for enforcing, preventing, and/or detecting behaviors defined by security policy. IT should NOT be making decisions about who should or shouldn’t be able to access information security assets.

A vast number of organizations act as if cyber security starts and ends with decisions about “how” to protect assets.  In the absence of a security policy, it is impossible to determine how to protect assets, because neither the assets nor the appropriate manipulation of those assets are defined.

MYTH #3:  Cyber security is like a math problem — there is one right way to configure security for every organization

Executive management on down to lowest levels of IT often think that there is one right way to configure security for information assets. They believe that they need only to find an egghead smart enough to know the secret sauce of security implementation. And worse, they assume that if that person’s “one right way” affects production in any way, then that level of security cannot be achieved in their organization.

All of this is wrong.  There is no one right way to configure security.

Every organization requires and/or prohibits different kinds of behavior for individuals filling various roles within that organization. For every behavior defined in a security policy there are numerous ways to enforce, prevent, and/or detect that behavior. The right way for a specific organization is the way that most accurately and cost effectively enforces the security policy defined by executive management.

MYTH #4: Being compliant makes us secure

Passing a compliance audit says nothing about whether or not your assets are properly secured. It only means that you were able to convince an auditor that you have met the requirements of a particular regulation or standard.

I have worked with companies that passed one audit or another but were not in any better shape than most organizations. I mean really, how can an organization pass an audit if it doesn’t have a defined security policy?  Security policy is a requirement in the PCI DSS standard and I have worked with several companies that had passed a PCI compliance audit and didn’t have a written security policy. I rest my case.

Those who are interested in just “getting the ‘tickie mark’” are doomed to spending money over and over for each audit for each new regulation or standard.  Those who take the time, effort, and money to actually improve their security while achieving compliance will find that they spend much less for subsequent audits.

MYTH #5: We have never been hacked

This is one of my favorites — not because I think most businesses have been hacked. It’s one of my favorites because every time I hear this one, it comes from a company that has no real way of knowing if it has been hacked! They don’t know if their competitor is stealing customers or business secrets. They can’t know because they do absolutely no monitoring or analysis of the data generated by monitoring. They would notice a loss of customers or a competitor copying their business processes, but they would have no way of tying that information back to information security leaks.

The only way to know if you have a security breach is by analyzing the activity on your assets. This almost certainly requires software to automate the analysis. The software should look for anomalies in the activity and notify a human only if an anomaly is found. An anomaly might be, for example, a failed login attempt by a system administrator at 3 am, whereas a failed login at 3 pm might not be worth investigating.

So, there it is. My top 5 list of Cyber Security Myths.  How many of these does your company believe?