Is the “problem” many “problems?
As part of our process and strategic approach to the problem it is now time to be sure we totally understand the realities of the total problem space. In other words we don’t want to be looking through a microscope, we want a telescope. We must be sure we have a comprehensive viable solution and we must understand what resources would be required to put that tooling into place.
Having a full, clear mapping and visual understanding of what the totality of the problem is and understanding what technologies are in play that are actually enabling the spread of the problem is a key point of success. This understanding also helps people that are non technical that are both inside and outside the organization quickly grasp the issue.
Here are some questions that should ask as you consider the use of tooling to help you develop a thorough real time understanding of the totality of the problem that you are facing, and to answer the question of “is this actually many problems?”
Is the perceived singular problem actually many, many problems?
The aim here is to drill down to root causes via the application of technology. In cybersecurity this means knowing what fundamental threat vectors are in place and what might help further move the threat lifecycle forward. Ofen once the problem is truly understood and seen the realization is that there is a more complex compilation of problems than we thought. The interconnected nature of these systems is where we suddenly realize one problem is actually many.
Always in the realm of cybersecurity the reality is that one is many and many is even more. Between users, accesses, networks, files, and a variety of other aspects there will never be a singular problem when an issue is identified. That means that one problem is always many problems. It doesn’t mean that we cannot solve those many problems but it means we must deal with that reality as honestly and intelligently as possible.
What technically must be present for a solution to work?
If we dont focus on the actual “physics” of the problem and know what the interconnected nature of those systems imposes for our solution then we basically guarantee failure before we ever put a solution in place. We must know that what we are doing is removing the proliferation of the threat action piece by piece and we must continually apply our tools to further reduce the spread of malicious actions and connections.
What incentives does the solution offer that we need, not want?
The point here is to ensure that the right people are motivated to address the problem and that the right technologies are in place to deal with the needed technical fixes, not the desires we usually confalte with a want for a future capability. In other words we should be able to “see” that our technology is handling the technical need for the adversary to succeed, not enabling a “want” for us to do more interesting technical things. That comes later, after we have fixed the weak points and eliminated the adversaries continued access.
Wasted time, effort, budget, and hours are spent trying to empower “wants” when what is actually truly necessary is to focus first on the “needs” that must be addressed. You know what a “need” is when you approach it from the adversary perspective, not the defender view. Know what the adversary “needs” to continue or launch an attack and deal with that first and foremost.
How do metrics get measured and is that powering success?
Addressing this question forces us to be explicit about how it will evaluate the solutions it receives. Clarity and transparency and technical efficacy that shows visually how a solution is enabling success are crucial to arriving at a more optimal end state while also ensuring that the evaluation process is accurate and the metrics used produce rigorous results. In some cases a “we’ll know it when we see it” approach is reasonable— but when we are solving cyber related issues and risk however, it is a sign that earlier steps in the process have not been approached with sufficient rigor.