Search for content, post, videos

Insight into Cloud Native Detection and Response

The Managed Security Services (MSS) market has historically been based around a number of enterpriseleading Security Information and Event Management (SIEM) solutions, which enable organizations to harvest and aggregate large amounts of data from servers, networking infrastructure, and systems hosted within the cloud. SIEM technologies and MSS companies then use the data to analyze and identify anomalies and potential cyber-attacks across the networks.

The Problems and Challenges

Some of the problems with historic MSS providers and SIEM technologies is that the alerts generated from SIEM technologies often produced a large volume of incidents that required further investigation by IT teams and often deemed to be false positives. SIEM technologies often do not have the full capability to deliver any response or enrichment function to the events, alerts, and incidents generated; high-alert volumes combined with limited business context can often lead to a perception that the MSS is more of a hindrance than adding value to an organization. This is not strictly true but equally a perception that I have often seen over the recent years.

The other thing about SIEM products is the cost. The enterprise SIEM technologies can often be cost prohibitive for organizations and can introduce the concept of a client being tied to an existing MSS provider, due to all the data residing in a third-party SIEM solution. Many have also fixed licensing costs and dedicated hardware that do not easily scale and which contribute to this feeling of being locked in to a provider.

Introducing Cloud Native – SIEM and Managed Detection and Response

Security technologies monitoring public, private, and hybrid cloud environments are no longer something new. However, what is continuing to evolve are some of the public cloud providers such as Amazon Web Services and Microsoft are building their own security technologies, which are often subscription-based licensing models and place the customer in control of their own destiny. These models enable organizations to rapidly scale up and down to meet their own unique needs without introducing additional upfront costs.

Do these technologies only monitor the cloud? No, the best thing about some of the cloud native security capabilities is that they can monitor hybrid on-premise IT, multi cloudbased infrastructures, Software as a Services (SaaS) systems, in addition to their deep insight into their own cloud technology.

My view at this stage is that Microsoft is the leading cloud native provider for managed detection and response capabilities, which comes in the form of Azure Sentinel and Defender Xtended Detection and Response (XDR) capabilities. For that reason, this article focuses on the Microsoft components that could be leveraged for building a cloud native detection and response capability.

Detection and Response for End-User Devices

What is key to an effective detection and response capability is having insight into end-user behavior activity, which often provides insight into initial attack activity. However, visualization and alerting is not enough, MSS providers or internal security teams need to be able to identify, contain, and respond to early signs of malicious activity being undertaken. The MITRE ATT&CK framework is a great way to identify the key Tactics, Techniques, and Processes (TTPs) to proactively identify various attack methods and put in place controls to mitigate them, but when malicious activities do take place, identifying, containing, and eradicating this as quickly as possible is key.

Microsoft’s product for this is Microsoft Defender for Endpoint (MDE) which provides increased endpoint protection through attack surface reduction, application control, and network protection. Advanced threat hunting, network isolation, and real-time response across enrolled devices is also possible, making this a key weapon to your detection and response capability. One of the most powerful features of MDE is its ability to leverage signals across all of Microsoft’s other XDR technologies and fully automate elements of the incident response life cycle. It is worth noting that this capability is unique to Microsoft. While AWS has great security capabilities, it does not have specific EDR product for end-user devices. However, there are many third-party services available on the AWS Marketplace.

The SIEM Is Dead, Long Live MDR?

Most definitely not, SIEMs are still an integral part of any security operations capability, providing that holistic view that can collect, normalize, and analyze substantial amounts of data to overlay your use cases and alert on the things you care about most. MDR provides the rapid response capability that the SIEM feeds. It is like a police control room (the SIEM) and the rapid response police officers, only instead of cars they have portals that can instantly make them arrive at the scene ‒ that is what MDR provides, the ability to rapidly be at the scene (the laptop, server, cloud infrastructure, SaaS service). When MDR combines the power of User and Entity Behavior Analytics (UEBA), Security Orchestration Automated Response (SOAR), and highly skilled humans with SIEM technology, this is where it begins to disrupt in comparison to more traditional SIEM implementations.

Amazon GuardDuty is the AWS native threat detection service and the dashboard summary with some key areas highlighted can be found here.

Azure Sentinel is Microsoft’s native SIEM solution and has very powerful SOAR capabilities and for me is the leader in cloud native SIEM solutions, bringing in all end-user behavior, devices, applications and both on premise and cloud infrastructure. It also leverages Artificial Intelligence and Microsoft’s own threat intelligence feeds, while supporting integration into other threat intelligence capabilities.

If you are going to leverage Azure Sentinel and part of your cloud native, detection, and response capabilities, be sure to connect the multiple data sources. By leveraging Azure Sentinel connectors you can integrate things like the range of Defender XDR security capabilities, Office 365, Azure Active Directory, and Microsoft Cloud App Security.

When combining all technologies together, it is an extremely powerful capability that can also leverage a proportion of your existing licensing costs where Microsoft E5 licenses are already in use, reducing your overall costs.

In general, Microsoft will not charge you to consume alerts from its own security products which is another additional benefit.

Fusion Technology to Deliver Multi-Stage Attack Detection

If you want to leverage some powerful capabilities to identify complex combinations of potentially malicious activity across the kill chain, then look no further. Enabled by default is Fusion, this low-volume, high-fidelity rule is pre-built within Azure Sentinel and can detect multi-stage attacks across the MITRE ATT&CK Kill Chain, leveraging machine learning. Again, when it comes to enhancing your detection and response capabilities, this type of capability gets you off to a great headstart.

Scheduled Queries

This detection method in Sentinel involves leveraging Log Analytics using Kusto Query Language (KQL) and this can be a very effective way of building upon several great outof- the-box templates Microsoft already has, in addition to a Sigma rule capability converter. You can schedule the queries to periodically run and view previews to ascertain the potential volume of data the rules could create. There is then the ability to map entities, enabling you to utilize them in an investigations graph.

Microsoft Security

Microsoft security detections essentially consume alert and incidents from other Microsoft Security products such as the Defender XDR suite of technologies.

Machine Learning and UEBA

These are essentially the secret sauce Microsoft detections that leverage proprietary machine learning (ML) algorithms. These are behavioral detections that pull and correlate data across a wide variety of data points to uncover malicious activity.

Considerations for Cloud-Native Detection and Response

There is no doubt in the value that having a cloud native capability for detection and response can deliver an effective capability to protect, detect, contain, and respond to threats. Where companies such as Microsoft provide much of this in their existing licensing models and the benefits that also derive from cloud such as no hardware costs and subscription based price models, you can also see the ROI benefits. However, there are some considerations you need to be aware of:

Log Data – How much and for how long?

While some licensing is already included for products such as Azure Sentinel, you may have to pay for log storage costs. This is not just relevant to Microsoft, it is relevant across all SIEM products, which often use this as part of their pricing model but “sometimes free” doesn’t always mean “completely free”. Key decisions around how long data is retained for and whether it is retained in stock from hot to cold and bucket to blob, it all needs careful consideration and ideally before you commence your journey.

Sometimes less is more when it comes to log ingestion

Many organizations want all log data, across all devices and this can really hike up your costs. Analyze log data sources and consider what actual benefit it contributes to use case detection. Ask yourself, what type of things are we trying to identify within this log data? This can be a valuable exercise in ensuring you only ingest data you care about, as not all data is equal, and data storage can be expensive.

Do not end up with a SOAR head, iterate automation

Automation of response is a very powerful and efficient way that can enable your security operations team to focus on the more complex of threats and move more into a proactive, threat-hunting approach to security operations. However, do not go automation crazy as this can often lead to issues impacting user-based or IT operations. I would recommend having an automation roadmap, driven by your analysts. In my view, the security analyst can often be neglected, and they are the ones with all the knowledge of what is going on across the organization. Consult them, listen to them, and work to develop a list of potential automation opportunities. This will yield the best results and get your teams feeling like part of the solution. Equally a good Managed Security Service Provider (MSSP) should have a great library of automation opportunities for you to leverage.

Summary

There is a growing number of MDR products in the market, which all bring a raft of qualities and capabilities to an organization. Anyone operating a traditional SOC/ SIEM approach has to evolve into having a detection and response capability, so that attacker dwell time is minimal, and a response can be delivered as quickly and effectively as possible. This capability not only builds effective response times but equally can reduce administrative burden on IT departments, having to investigate a mass of alerts, often turning out to be false positives. Having these capabilities in a way that can maximize existing technology investments and reduce technical debt is clearly making some of the cloud-native solutions like Microsoft a compelling proposition. However, do not think because the user interface is friendly and there is a lot of “click and go” capability that you do not need experts with the necessary technology and security operations expertise. Technology is only a small proportion of effective detection and response, it is the processes, development expertise, and the ability to interpret, investigate, and act upon results where the real value is obtained and expertise is needed. Whatever you decide to do, spend the time to plan out your journey, capture what you are trying to achieve your “Why?” and go into a process of building this capability with a clear vision. You can always adapt your approach as you move forward and things evolve but trying to deliver without a clear vision will not yield effective results.

Leave a Reply

Your email address will not be published. Required fields are marked *