Security analysis

Hello and welcome to the final module in our six-part series on practical cybersecurity. Today, we will discuss security posture analysis and risk assessment: how to manage security gaps and vulnerabilities to derive a solid basis for risk assurance.

In today's module, we will discuss the need for assurance, types of security analysis, outcomes, and reporting, remediation and decision support, budgeting, and GRC, key questions and answers, and we'll recap the entire series at the end. So, stay tuned. What is standardized assurance and why do we need it?

Way back in module number 2, we talked about the need for risk management and risk management rests on the ability to trust the kind of security posture that organizations have, the ability for companies to protect themselves, and the necessity to communicate the standards that we abide by, so that other organizations can make decisions based on our perceived security posture. So, that standardized assurance is illustrated in compliance; it's illustrated in security reporting and the way we do security analysis. Security testing is a way to validate our findings and derive a clear picture of our security stance and the way that we're going to prioritize what remediation steps have to be carried out in order to improve the security posture of the organization. That sounds like a lot of big words, but it really is quite straightforward. Unfortunately, there's a lot of confusion coming out of the media about the different types of hacks, the different types of attacks, and, of course, the different types of security testing. That's why most organizations just instinctively say, well, we need a pen test. We need a penetration test in order to determine whether we are vulnerable. Unfortunately, that part is not so easy and penetration tests are always different. The reason that they're different is because they're carried out by individuals with different capabilities, with different tools, and at different points in time, and everything changes from one day to the next, from one minute to the next, illustrating the need for standardized approaches. Those standardized approaches we talked about before are frameworks. They're methodologies and there are ways to ensure that the way we carry out our work is process-driven and repeatable. Now, it's true there are completely different types of security analyses. There are threat risk assessments which identify threats, calculate risks, and output the impact of whatever adverse effects are carried out during a data breach. There are security reviews, which are high level looks at the way an organization carries out its operations, its processes, and the implementation and enforcement of its procedures. There are vulnerability audits. There are compliance audits. There are internal and external ways to test the organization's security posture so that an organization doesn't have to review absolutely everything all at once because it takes time. These are point-in-time assessments, but they do take a while to complete. So, it makes sense for an organization to split the different tasks and activities it has as part of its risk management program- the different risk assessment activities need to be split up. You can look at the way that an organization is seen from outside. You can look at the way that internal breaches occur and you can focus on different attack vectors. For example, not every attack, not every incident, and not every breach is malicious. Some of them originate inside the organization and pass information to bad actors outside the company, but others occur inside the organization and are literally just human error. Sometimes, there are simply computer glitches. Not every incident is an intentional data breach. However, all of these do have risk factors associated with them. So, calculating the probability of those breaches is important in completing a risk registry. Having a risk registry ensures that an organization has a clear picture of the risks that it is facing. This is a useful exercise because keep in mind we are dealing with intangibles. We're not dealing with tables and chairs and computers that are obvious in the way that they might be compromised. This is information that we're talking about- information that may exist at rest or in transit. So, it makes sense to go through the exercise of imagining and testing the threat scenarios that might unfold.