Security program trends tend to move in a cycle. I sit in meetings today and hear people asking the same questions they asked back when I started in the cyber security space, only this time there are slightly different answers and solutions.
I’ve highlighted some of the security program trends that I’ve seen previously to map out where they’re headed now, and how we can use what we’ve learned in each cycle to understand them and make better decisions.
Security Risk Management
The example I like to use when discussing security risk management these days and the cyclic issues associated with it is the experience of going to the doctor for a general checkup.
I ask a few questions:
“Do you think that if you went to schedule this general checkup you would get better information if you could get your appointment in a week or six months?” Of course, the answer is always a week.
“Would you get better information if this doctor could spend five minutes with you, or an hour for the review?” An hour, naturally.
“What if this doctor was the best general practitioner around using the best tools and science available but when he looked at you he only examined your left wrist for this full checkup?”
Most people would say a better full body scope of review.
At the heart of security risk management is the need to use the process to give better information to anyone in an organization to make the best decisions about how to manage risk. Going back to the late 90’s, security risk management really began with a short prescriptive bullet list of things for an organization to do to manage “security risk.” These lists were consumable for business leaders to understand and implement.
Referring back to our example, it’s like going to that doctor’s appointment and only getting asked two questions about what was wrong with you. Not very effective.
HIPAA came in the mid-2000’s and introduced one of the first mandates to use risk management as the primary method for managing compliance. This moved the needle from a short list to a long list of items with one of them being that risk management be used to determine compliance. However, while it said to use risk management, it never defined the method that needed to be used.
As a result, you simply had a longer prescriptive list with an inaccurate risk management methodology. This is like going to the doctor and having her check a longer prescriptive list, followed by her rating your problems, not with science but with any prioritization model she deemed fit. Again, not very effective.
Now, the majority of security frameworks have gone to risk management models to determine how to apply their framework, the latest of which is NIST 800-53.
More quantitative risk methodologies have recently come out that have improved accuracy. The problem, however, is that most organizations now do not have enough time, people, and resources to perform the more input-heavy quantitative risk models. Nor do organizations have the ability to measure and manage risk based on demand.
There are simply too many suppliers to measure, too many projects, and too many threats to keep up with. To make matters worse, there aren’t enough security professionals to go around. Organizations are still failing at risk management, even as the approaches are getting better.
What to do:
Currently, organizations are pushing for more exhaustive risk management techniques and only focus on risk management in its perfect state. Risk management is powerful, but you will be most effective if you do it in balance.
Balance is reached by using a risk methodology that gets you enough accuracy but can also be applied in a practical manner that covers the right scope of measurement in your environment with the resources that you have available.
Further, the more you can make your risk management processes repeatable and efficient, the less skilled, and often more available resources you can find to perform them. I will take a simple, less accurate risk management program with a better scope over an exhaustive perfect state one with bad inputs any day of the week.
The Use of Artificial Intelligence
One of the earliest examples of AI in cyber security was in the late 90s with a firewall application known as Secure Computing Sidewinder. This product had a “strikeback” feature that would automatically attack any systems that it thought were attacking it.
For those of us that lived in this world back then, you may remember it by the awesome dragon-like Sidewinder Snake that was on its interface during login that resembled the logo of Cobra Kai in Karate Kid.
From there, we moved to dynamic application firewalls that would detect attack via Intrusion detection modules and then auto-block the activity. None of these technologies were highly adopted though because they were difficult to configure, and they had many false positives. These are the first examples of skipping the process — more on this later.
But we seem to have forgotten all about that, given that the idea that AI would be the magic bullet for everything cyber security came up again around 2011. Today, there is a lot of false hope as we haven’t addressed the need for configuring these systems, which leads to a lack of effectiveness. This reliance on automation is something that Elon Musk has touched on.
What to do:
AI can and will be important for all of us, but organizations need to focus not on the tools alone, but on building the processes first that these tools will look to automate. Once an organization lays out their processes, then they can be automated with technology or decision-based process steps using AI.
If you skip straight to the tool, it’s impossible for it to be successful without understanding what it’s automating, or the business rules it needs to follow to make decisions.
Security success always starts with understanding, defining, and documenting your process, even if it’s simple and manual in the beginning.
Security Architecture
Architecture is one of the components of a security program that have been spoken about through each cycle as a trend.
We discuss things like the “firewall,” “Crunchy on the outside, soft in the middle,” “no borders,” or the one that just will not die: “defense in depth” — but these are just concepts, not the security architecture itself.
What to do:
For successful security architecture within a program, it needs to align with the organization’s environment and objectives, not just a trendy catchphrase that essentially means nothing.
You need to have a defined security architecture program with defined roles and responsibilities, business rules, and processes. You also need to define the security environment and where specifically data lives in each section of the architecture. This includes all of the preventative and detective safeguards in place that protect this information throughout the environment.
“Should Security fall under IT or Business?”
Security has gone through various organizational reporting cycles, from being part of IT and reporting to a CIO, to reporting to the CEO, to legal, and recently back to the CIO.
What to do:
Whether the security program reports to IT or business or whatever doesn’t necessarily matter — what matters is that the roles in cyber security are clearly defined.
The best place to do this for every role in your program is in your security program charter. The charter should detail any in-scope responsibilities, and as important any out-of-scope programs as well. Only take on program responsibilities where your accountability is in balance with your authority.
An organization should also define what security means in an organization through the programs that the security program leader owns, as well as the security policies and processes that fall under it. Security means different things to different people because it touches everything, so applying a definition will reduce confusion and the conversations about accountability will finally go away.
Security Communication Systems
Communication is incredibly important for a successful security program. The primary goal of a security program is to aid everyone in that business with making informed decisions. The communication system will be the means that people send and receive information regarding the security program, which enables the best decision making.
It’s ironic then that these systems are so important but have been dramatically lacking through each cycle. I’ve seen security programs that don’t present any information to programs that present endless loops of assessment reports and most recently, dashboards that look pretty and present random information but don’t necessarily support decision-making for the people that need it.
What to do:
Organizations need to define all the communication inputs and outputs for their system and make an inventory of decisions that need to be made by everyone involved. If this is your primary driver of requirements, you can ensure that your system communicates in a way that supports the informed decision making your program needs.
I also like to define the communication system in my program charter to help the organization understand what it is and how it supports everyone involved. An effective communication system is different than a dashboard that doesn’t do anything other than look pretty. “Pretty” doesn’t help make decisions, and decisions are what organizations need to make progress.
This article was originally posted as an article on my LinkedIn account.