Note: this is the second of a four-part blog series that explores the complexities of securing multiple clouds and the limitations of traditional Security Information and Event Management (SIEM) tools.
With the first post, we discussed the importance of adopting a multi-cloud approach to Observability, centralizing in a single SIEM all the events generated by your infrastructure to enable a more comprehensive analysis of potential security incidents by correlating events independently from their origin. We also hinted to the complexity of such endeavor.
You can read the first post here: Securing the Clouds: Navigating Multi-Cloud Security with Advanced SIEM Strategies - Microsoft Commu...
With this new post, we focus on a different topic: the importance of adopting a threat-based approach. In the process, we discuss how this can be achieved and provide you with a few practical ideas you can apply to your scenarios.
The threat-based approach for creating use cases consists in the identification of potential attacks to the system, considering each Cloud environment, on-prem environment, and then how they interrelate and interact. You then derive attack uses cases which drive the definition of the logic to identify those attacks and then trigger remediation activities. Those potential attacks are also known as threats or, more precisely, as threat events.
The threat-based approach is not the only possibility. Actually, the most common approaches are vulnerability-based. With them, the focus is on the identification of vulnerabilities like the infamous Log4Shell, and consequently on indicators which may identify attacks in progress.
Vulnerability-driven approaches have various shortcomings. For instance, they tend to grow the detection capabilities to respond to known vulnerabilities, and as a reaction to successful attacks. Therefore, they are designed to prevent such attacks from occurring. Conversely, threat driven approaches are based on the understanding of how attacks may happen, and are designed to detect them independently from the presence of specific vulnerabilities. We have chosen to adopt a threat driven approach to improve the detection and response capabilities and to reduce the impact of security incidents and response.
Another advantage of the threat-driven approach is that it is often independent from the existence of specific vulnerabilities. For example, you can analyze the possibility for an attacker to inject code in its requests leveraging some vulnerability to execute such code, without referring to a specific vulnerability. This allows you to design detection mechanisms that are vulnerability independent. Therefore, they would apply to many similar vulnerabilities, including yet undisclosed zero-day vulnerabilities.
A threat-driven approach is a proactive and strategic way of analyzing a complex infrastructure for identifying This approach is much more effective of the corresponding ones based on vulnerability analysis because it takes in account the exploitability of the vulnerabilities. In other words, you determine what a malicious actor can do to compromise your system. This is much more effective than adopting a vulnerability-driven approach because it allows you to discard vulnerabilities that do not matter because they are hardly exploitable.
By adopting a threat-driven approach we started with the following steps:
To apply a threat-driven approach, organizations need to incorporate threat analysis and threat intelligence across their systems development and operational processes.
Now that we have understood what the threat-driven approach is, it is time to get a few ideas about how you can implement it in your organization.
We can consider as an example a Multi-Cloud organization. It is not uncommon for those organizations to adopt identity and security solutions from various vendors. This complicates integration and soars the risk of supply chain attacks due to the lack of comprehensive visibility and increased complexity. To address this situation, it is best to adopt a structured approach based on the following steps:
The “threat modeling” specified in the second point is a security process to understand security threats to a system, determine risks from those threats, and establish appropriate mitigations. There are various ways to perform threat modeling, and all of them are well represented by the Threat Modeling Manifesto. Microsoft has developed one of the first threat modeling processes, called Microsoft STRIDE Threat Modeling. This approach has evolved over the years and is continuously evolving. If you want to learn more, please go to Microsoft Security Development Lifecycle Threat Modelling.
The three steps defined above define the threats for the system. This represents the first phase of our journey. The next one consists of the definition of Use Cases. You will often have a Use Case for each Threat, but this is not an absolute rule. In various situations you will want to cover more threats with a single Use Case. Nevertheless, each Use Cases describes the associated threats as a single story and identifies the events necessary to detect such attacks and where they can be found. The Use Case typically also contains the definition of the actions that can be performed for controlling the risk, and the conditions under which they are triggered. Those actions will be both manual and automated.
It is very important to define automated activities that are executed when a potential attack is detected. This allows you to respond to attacks faster than you could if you rely only on manual response.
Time is a critical factor in the realm of cybersecurity. Let's delve into why swift responses matter:
While automation plays a major role in reducing the time required to respond to attacks, manual remediation activities are still essential. The problem is that automated actions cannot be too drastic: it’s fine to disable an IP address or an account that seems to attack the organization, but you will not want to have some automated procedure to take down the whole infrastructure automatically, even if you detect a possible data exfiltration.
Ultimately, the production of the Use Cases is instrumental in the creation of the rules in your SIEM system to detect attacks, and to configure your SOAR system for automatically respond to them.
Complex Multi-Cloud environments represent a significant challenge when you must create a monitoring infrastructure. Yet, achieving a comprehensive view of what happens in your organization is more important than ever. A structured approach like the Threat-Based Approach described in this post may help you to conquer complexity and get the results your organization needs.
Nevertheless, implementing a Threat-Based Approach is not the end. Organizations face new attacks every day. New software is acquired, extending the attack surface for the Organization. And new vulnerabilities are regularly found. For these reasons, it is essential to adopt a continuous improvement approach. The threat assessment must be regularly reiterated, and new Use Cases must be created. This leads to updating the existing rules in the SIEM or SOAR. If you do so, your Organization will gradually but surely improve its security posture, and will eventually become one of the main tools to guarantee your Business' security.
Future posts in this series will cover the following topics:
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.