The Power of Asking Why

The 5 “Whys” for Root Cause Vulnerability Analysis

The 5 Whys is a problem-solving method used to identify the root cause of an issue. It's a simple yet powerful technique that involves repeatedly asking "why" to peel back the layers of a problem and get beyond the initial symptoms.? For parents reading this, it will sound familiar if you’ve ever had long car rides with your 5 year old kid. For non-parents, kids will ask you “why” at least 5 times about the world around them.? ;-)??

The 5 Whys method is credited to Sakichi Toyoda, a Japanese industrialist and inventor. He founded Toyota Industries, which later became the Toyota Motor Corporation. While the exact date is unclear, it's believed he developed the technique in the 1930s. The method became popular in the 1970’s and it is believed that Toyota still uses it today.

That begs the question, what makes The 5 Whys, which is a framework to ask “why” five times when analyzing an issue, so powerful that it became? a cornerstone of problem-solving within Toyota's manufacturing methodologies and is still used extensively today? Let's dig in!

Here's how it works:

1. Start with the problem. Clearly define the issue you're trying to solve.
2. Ask "Why?" What caused the problem to occur? Be honest and specific in your answer.
3. Ask "Why?" again. Why did the previous answer happen? This digs deeper into the cause-and-effect chain.
4. Repeat steps 2 and 3. Continue asking "why" for each answer you get, aiming for five iterations in total (though sometimes fewer or more may be needed).
5. Identify the root cause. By the fifth "why," you should hopefully uncover the underlying reason for the problem. This is the root cause you want to address.

Here's an example:

• Problem: The machine stopped working.
• Why? There was an overload, and the fuse blew.
• Why? The bearing wasn't lubricated enough.
• Why? The lubrication pump wasn't pumping sufficiently.
• Why? The pump shaft was worn and rattling.
• Root Cause: The worn-out pump shaft caused the lubrication issue, leading to the machine failure.

By addressing the root cause (replacing the worn shaft), you can prevent similar problems in the future. Had we stopped asking why earlier in the process, we would likely experience the issue again in the future as we solved the wrong problem.

The 5 Whys is a versatile tool applicable in various situations. It's commonly used in:

• Manufacturing (identifying production defects)
• Software development (debugging errors)
• Project management (finding the root of project delays)

Remember, the number "5" is more of a guideline. The key is to keep asking "why" until you reach a clear understanding of the root cause.

How This Methodology Applies to Cyber Security, Vulnerability Management and Testing

A cybersecurity professional can leverage the 5 Whys methodology to effectively identify the root cause of let’s say…SQL injection (SQLi) vulnerabilities in web applications. Here's how it would work:

1. Start with the problem:

Problem: The web application is vulnerable to SQL injection attacks.

2. Why is the application vulnerable?

This initial "why" focuses on the development or configuration flaws that allowed the vulnerability to exist. Here are some possible answers:

• The application directly embeds user input into SQL queries without proper sanitization.
• The application uses outdated libraries or frameworks known to have SQLi vulnerabilities.
• Secure coding practices weren't followed during development, leading to unsafe coding techniques.

We will assume the general response was that user input isn’t being sanitized. This appears to be a purely technical challenge but let’s dig deeper.

3. Why wasn't user input sanitized?

Here, we delve deeper into the development process:

• Developers might not have been aware of SQLi vulnerabilities and proper sanitization techniques.
• Time constraints or lack of resources might have led to cutting corners on security best practices.
• Manual code reviews might have missed the vulnerability.

We will use a combination of input sanitization and best practice awareness due to lack of resources or training as the response. Aha! So now we still have a technical problem but the reason the technical problem exists might not be 100% a technical challenge.

4. Why weren't developers aware or didn't follow best practices?

This “why” focuses on potential knowledge gaps or security awareness issues:

• The development team might not have received adequate training on secure coding practices.
• Security wasn't a top priority during development, leading to a lack of focus on secure coding techniques.
• Automated security scanning tools might not have been used to identify the vulnerability.

It is in this response that we discover that security wasn’t a key requirement in the project development was working on. Now the question is: Why!?!?!?

5. Why weren't developers trained or security prioritized?

This why digs into the overall security culture and processes:

• The organization might not have a strong security culture that emphasizes secure coding.
• Security training might be inadequate or not mandatory for developers.
• Security testing might be an afterthought instead of being integrated throughout the development lifecycle.

This “why” response will give us the true area of investment and change that would have the largest impact.?

PAUSE: It’s important to note that every organization is different and rarely do we find that people intentionally have these gaps. As you leverage the 5 Whys methodology try not to insert bias into the questions or lead the witness. The goal is an objective reason that can be a target of positive change to ensure all future iterations of these checks have a better result.?

Let’s recap what we’ve learned and discuss what the root cause could have been.

Identifying the Root Cause:

By going through these 5 Whys, the root cause could be:

• Lack of developer training on secure coding practices.
• Insufficient security awareness within the organization.
• Absence of a secure development lifecycle (SDLC) that emphasizes security testing.
• A culture that doesn’t positively integrate security as an essential part of the process

Taking Action:

Once the root cause is identified, the cybersecurity professional can recommend solutions like:

• Implementing mandatory secure coding training for developers.
• Integrating automated security scanning tools into the development process.
• Enforcing secure coding practices through code reviews and static code analysis.
• Fostering a security culture within the organization that prioritizes secure development.
• Continuous testing to measure in real-time the effects of fine tuning developer behavior, tool calibration and process improvements.??

The 5 Whys methodology helps move beyond the immediate issue (the vulnerability) and identify the underlying reasons that allowed it to exist. This allows for implementing targeted solutions to prevent similar vulnerabilities in the future.? However, just like when you’re answering the “why” for your 5 year old kid in the backseat, we have to move beyond, “Because I said so!” as our answer if we want to seize the opportunity to bring those around us into a new level of awareness so they too can see the world as you see it.??

To My Subscribers / Readers:

Did you enjoy this article?

Let me know what you thought in the comments and if you implement the 5 Whys make sure to send me a note about the results you saw as a result. We all can help our organizations get better, one “Why” at a time.?