What needs improvement with Microsoft Sentinel?

I am not deeply involved with Microsoft Sentinel, so I cannot pinpoint weaknesses. As of now, there have been only benefits. However, I am curious about potential AI integration and whether it will be affordable for us because all the compliance costs are rising with all the new features. I know there is a similar solution inside Defender that you can use with Security Plan 2, but for us, Security Plan 2 is expensive. Currently, we are happy to have a way in the middle with not so much cost, but it would be nice to have the ability to enhance the automation of workflows based on learned incidents.

While I have not used Microsoft Sentinel extensively to suggest specific improvements, there is always room for improvement. The pricing could be improved, as it is considered quite expensive, especially considering the costs for workspace, Sentinel, and storage.

From a client perspective, they'd like to see more cost savings. I'm not sure if Sentinel gives a POC for free.

Microsoft Sentinel's search efficiency can be improved, especially for queries spanning large datasets or long timeframes like 90 days compared to competitors like Splunk. While Sentinel might take several minutes to return results for such investigations, Splunk queries are significantly faster.

One key area that can be improved is by building a strong integration with our XDR platform.

While I appreciate the UI itself and the vast amount of information available on the platform, I'm finding the overall user experience to be frustrating due to frequent disconnections and the requirement to repeatedly re-authenticate. Microsoft needs to address these usability issues to enhance the user experience.

The AI capabilities must be improved. The product must efficiently leverage the AI capabilities for threat detection and response. The product does not provide auto-configuration features. So, we need to do configuration, policy changes, and group policies ourselves. If AI can do these functions, it will be easier for the customers.

I would like Microsoft to add more connectors for Sentinel. Microsoft Sentinel should provide an alternative query language to KQL for users who lack KQL expertise.

The alert response could be better. We'd also like a better ticketing system, which is older.

When it comes to ingesting Azure native log sources, some of the log sources are specific to the subscription, and it is not always very clear. Sometimes, if the individual doesn't know what they are doing, they might enable it only on one subscription and not on everything that they need to monitor.

I'd like to see more integration with other technologies beyond the Microsoft OS. I would like to see more AI used in processes.

Given that I am in the small business space, I wish they would make it easier to operate Sentinel without being a Sentinel expert. Examples of things that could be easier are creating alerts and automations from scratch and designing workbooks. All of those are available as templates and community-produced content, but doing all that from scratch and keeping it up-to-date, is not easy. Because I have lots of other things on my plate, it would really improve things for me if they would make it more accessible for small businesses and non-experts.

Microsoft Sentinel has a lot of out-of-the-box detection rules. Many of these rules have not been tested, they may execute but they have errors or do not work as expected. Due to this I've made more than 80 requests for modifications in Microsoft Sentinel public repository. If you want to ensure that Sentinel detection works, you need to review the logic of the detection rules one by one, and this shouldn't be the case. Sentinel does not seem to have rules by default that check and notify of execution errors. I have had to create custom rules to detect when a log source or automation rule stops working as expected. There can be discrepancies between Microsoft tools. Not all information appears in Sentinel. Sometimes there are items provided in Microsoft 365 Defender that you could search for in Sentinel and you would not find them and therefore assume they do not exist. The solution is powerful but it can be expensive. Other solutions that are on-premises should be cheaper.

I would like Microsoft Sentinel to enhance its SOAR capabilities.

Microsoft Sentinel has improved our entire SOC, like our log system and incident response. So we are able to quickly respond to incidents and take action. Even though Microsoft Sentinel has already improved our system, it should further improve for on-premises systems or traditional systems, especially to get or collect logs from the legacy systems. Also, Microsoft should improve Sentinel, considering that from the legacy systems, it cannot collect logs.

The solution could be more user-friendly; some query languages are required to operate it. A welcome improvement would be integrations with more products and connectors.

For certain vendors, some of the data that Microsoft Sentinel captures is redacted due to privacy reasons. In the future, it would be helpful to have this data unredacted so that we can have a better understanding of it. Microsoft Sentinel is not the most user-friendly tool. Other tools, such as Splunk SIEM or any other SIEM, are better and easier to use. Our threat-hunting capabilities can definitely be improved. We do use workbooks to view incoming data, but threat hunting is where we can really find those underlying issues that may not be immediately visible. We will use these alerts as a starting point for our hunting. If we can correlate two different events and identify the same root cause, it will save us a lot of time and resources.

Microsoft Sentinel needs to be improved on the metrics part. I've had an issue in the recent past while trying to do my metrics from it. It gives me an initial report, but sometimes an incident is created on Microsoft Sentinel, but you realize that when a lot of information is being fed from Microsoft Defender to Microsoft Sentinel, instead of feeding the existing alert, Microsoft Sentinel creates a new alert. So, metrics-wise, it can do better. It can also do better in terms of managing the endpoint notifications. We do have in-built or out-of-the-box metrics that are shown on the dashboard, but it doesn't give the kind of metrics that we need from our environment whereby we need to check the meantime to detect and meantime to resolve an incident. I have to do it manually. I have to pull all the logs or all the alerts that are fed into Sentinel over a certain period. We do this on a monthly basis, so I go into Microsoft Sentinel and pull all the alerts or incidents we closed over a period of thirty days. I then calculate the meantime to detect and the mean time to resolve. I have to check when all the tickets were created, when they were handled by the analysts, and when they were closed. I do a manual metrics calculation after pulling all the data. I believe Microsoft can do better on the metrics side of Sentinel. They can provide monthly reports. If I want to submit the reports to my senior management, it will be much easier for me to pull the data as a report. Currently, you can't pull any reports from Sentinel. It would be helpful if they can build a reporting tool within it and allow me to have my own customization. I should be able to customize the reports based on my needs. For example, I should be able to generate a report only for incidents with high and medium severity. It should also provide information on trends within the platform. There should be reports on specific alerts or security incidents. They should build more analytics rules to assess key security threats. I have had to build a lot of custom analytics rules. There should be more of them out of the box. There should be more information about how to utilize the notebooks. They can have a better approach to enlightening the end-users about the straightforward use of notebooks. The data point analysis rules and automation are straightforward compared to the way you utilize the notebooks. They can do better in terms of sharing how we can utilize the notebooks. We are able to ingest data across all our tenants and on-prem solutions, but we have been chasing Microsoft for the longest time possible for ingesting some data from Microsoft Dynamics 365. The kind of logs that we need or the kind of security monitoring that we need to do on Microsoft Dynamics 365 versus what's available through data connector tools is different. The best advice that they have managed to give us is to monitor the database logs, but we can't go into monitoring database logs because that's a different platform. There are several things that we want to address across Microsoft Dynamics 365, but the kind of logs that we get from the data connector are not of any significance. It would be better if they could give us customization for that one. That's the worst application from Microsoft to add because we can't monitor any business processes in that application, and there's no capability to do even customization. We are so frustrated with that. It's quite comprehensive in threat intelligence capabilities, but it takes some time to establish a baseline. They can also improve the UEBA module so that it can help us address and have an overview of the risk. It's not yet that complete. It can establish a baseline for a user, but it doesn't inform how I can leverage the capability to address risks. We can also have more integrations within Microsoft Sentinel with TI feeds out of the box. Currently, we don't have something out of the box for other TI feeds. Microsoft has its own TI feed, but we aren't utilizing that. Microsoft Sentinel should provide more capability to end-users for customization of the logs they feed into Microsoft Sentinel.

The GUI functionality has room for improvement. The playbook can sometimes be hefty and has room for improvement. The troubleshooting has room for improvement.

My only complaint about Sentinel has to do with how you leverage queries. If you have good knowledge of KQL, things are fine. But if you're looking to use canned queries, the interface could be a little more straightforward. It's not immediately intuitive regarding how you use it. You have to take a canned query and paste it into an operational box and then you hit a button. Then it does the analysis of the telemetry. If things could be improved anywhere, it might be there. They could improve the ease of deploying these queries.

In terms of features I would like to see in future releases, I'm interested in a few more use cases around automation. I do believe a lot of automation is available, and more is in progress, but that would be my area of interest.

The following would be a challenge for any product in the market, but we have some in-house apps in our environment. We were thinking of getting the activities of those apps into Sentinel so that it could apply user behavior analytics to them. But our apps were built with different parameters and the APIs for them are not present in Sentinel. We are working with Microsoft to build those custom APIs that we require. That is currently in progress. We are happy with the product, but when it comes to integrating more things, it is a never-ending task. Wherever we have a new application, we wish that Sentinel could also monitor and investigate it. But that's not possible for everything.

Sentinel should be improved with more connectors. At the moment, it only covers a few vendors. If I remember correctly, only 100 products are supported natively in Sentinel, although you can connect them with syslog. But Microsoft should increase the number of native connectors to get logs into Sentinel. Each time we have a connector, it eases the configuration of Sentinel, and we don't need custom deployments to get the information from a specific vendor. The second thing they should do is create more built-in rules for the dashboard, automation, and hunting. The first time you use Sentinel, it's not easy to use the product because, beyond the dashboards, you need to know the Kusto Query Language (KQL) to create the right requests.

They can work on the EDR side of things. It is already really superb, because of the kinds of features we get with the EDR solution. It's not a standard EDR and they have recently enhanced things. But the problem is with onboarding devices. I have different OS flavors, including a large number of Linux, Windows, macOS, and some on-prem machines as well. Every time we need to onboard these kinds of machines into the EDR, we need to do it with the help of Intune, to sync up the devices, and do the configuration. I'm looking for something on the EDR side that will reduce this kind of work. They can eliminate having to do manual configuration for the machines, and check the different types of configurations for each OS. In some cases, it does not support some OSs. If they could reduce this type of work, that would be really amazing.

There is room for improvement in entity behavior and the integration site. It's a new solution, so it can include different security products in the data connector section. I've also experienced some performance issues with the runbook. It takes a lot of time to load. In the automation section, there are some limitations.

Sentinel could improve its ticketing and management. A few customers I have worked with liked to take the data created in Sentinel. You can make some basic efforts around that, but the customers wanted to push it to a third-party system so they could set up a proper ticketing management system, like ServiceNow, Jira, etc. It would be helpful for incident responders to be able to assign tickets and have permissions assigned to them. Once you have escalated tickets from Level 1 to Level 2, there may be areas where you want to control who has access to the raw Sentinel tool.

Only one thing is missing: NDR is not available out of the box. The competitive cloud-native SIEM providers have the NDR component. Currently, Sentinel needs NDR to be powered from either Corelight or some other NDR provider. It needs a third-party OEM. Other than that, it supports the entire gamut of solutions. Also, we are helping customers build custom data-source integration. Microsoft needs to look at some strategic development on the partner front for out-of-the-box integration.

Microsoft threat intelligence and UEBA still have some room for improvement. There are currently only two connectors available for Microsoft threat intelligence. the threat intelligence platform and the FTIA commander. Sentinel should offer another option for a third-party threat intelligence platform. There are lots of open-source threat intelligence solutions available. Threat handling could be great for our team and for our SOC analyst, but some are unusable depending on our SOC analytics. Sentinel can ingest data from most of our ecosystem, but some data cannot be called up. For example, if an SAP product is hosted, it will do a specific version, but it cannot be called back to Sentinel. It cannot be directly connected to Sentinel.

If we want to use more features, we have to pay more. There are multiple solutions on the cloud itself, but the pricing model package isn't consistent, which is confusing to clients.

There is not much guidance on the in-built SOAR solution that uses Azure Logic Apps as a service. For people coming from traditional SIEM solutions, it is difficult to understand how SOAR works. Because the security teams are not from a programming or coding background, they cannot directly jump into SOAR. For Kusto Query Language within Sentinel, Microsoft provides a lot of documents and articles, and they also have a community, but when it comes to SOAR, other than a few open articles, there isn't much information. The documentation part of SOAR should be improved. The dashboards can be improved. Creating dashboards is very easy, but the visualizations are not as good as Microsoft Power BI. People who are using Microsoft Power BI do not like Sentinel's dashboards.

There are a number of points they can improve. For example, if I see an alert and I want to drill down and get more details about the alert, it's not just one click. In other SIEM tools, you just have to click the IP address of the entity and they give you the complete picture. In Sentinel, you have to write queries or use saved queries to get details. For a security analyst, when there is an incident, it takes a lot of time to write queries, investigate, and then execute. For example, if you want to search a particular entity or an IP address, or search the complete log instead of just the security alerts, it takes time to write a query for that. The MTTR is a little high, as is the mean time to investigate, compared to other SIEM tools. I would also like to have more resources on KQL queries. And using the data connectors is not straightforward when you want to create a use case that is not out-of-the-box. Creating a custom use case is a challenging process. You need to understand KQL queries and the support for regex is limited.

Multi-tenancy, in my opinion, needs to be improved. I believe it can do better as a managed service provider. It's a fairly mature product now. Pricing could also improve, it's a bit expensive.

We'd like to see more connectors. The solution needs to offer a bit more advancement, enhancement, and scalability with other products as well, including the market competitors.

Its implementation could be simpler. It is not really simple or straightforward. It is in the middle. Sometimes, connectors are a little bit complex.

If I can use Sentinel offline at home and use it on a local network, it would be great. I'm not sure if I can use Sentinel offline versus the tools I have.

There are certain delays. For example, if an alert has been rated on Microsoft Defender for Endpoint, it might take up to an hour for that alert to reach Sentinel. This should ideally take no more than one or two seconds. There are a couple of delays with the service-to-service integration with Azure Sentinel as well as the tracking point.

New things are already being incorporated just to improve on the already existing solution. There is a GitHub community for this solution. There are a lot of contributors worldwide and a lot of people building playbooks and building machine learning models. Someone can just build a machine learning model and say, "Okay, just mention in the model, 'Do this,' and it does this." There is room for improvement. However, things are improving in Sentinel with the help of this community. I've seen playbooks where people have pushed to the GitHub repository, and I've been able to make use of one or two of these solutions on GitHub. That said, it may not be possible to eradicate all of the cyber threats. There are webinars going on almost every week. Last week I attended a couple of webinars on Azure security. When you are doing things, you also need to be thinking about the security aspect. You have to be thinking about the security aspect of a cloud. You need to enforce a zero-trust model. You can't assume something cannot harm you, as everybody is a threat to your security. The only issue is that sometimes you can have a false positive alert. For example, sometimes it detects something is happening, however, you're actually the one doing that thing. If someone is trying to sign into their environment and provide an incorrect password, they will try it a few times. The system will look at that event and think it's an attacker and it might be an indication of a threat. However, it's just a user that got the password wrong. I consider that a false positive alert.

The learning curve could be improved. I am still learning it. We were able to implement the basic features to get them up and running, but there are still so many things that I don't know about all its features. They have a lot of features that we have not been able to use or apply. If they could work on reducing the solution's learning curve, that would be good. While there is a training course held by Microsoft to learn more about this solution, there is a cost associated with it.

There is some relatively advanced knowledge that you have to have to properly leverage Sentinel's full capabilities. I'm thinking about things like the creation of workbooks, how you do threat-hunting, and the kinds of notifications you're getting. There are a lot of pieces in motion with Sentinel to use it effectively. It takes time for people to ramp up on that and develop a familiarity or expertise with it. Does it need to be simplified? There is that old saying: "The simpler the front end, the more complex the back end." A novice would probably not be able to effectively use Sentinel unless they were able to ramp up pretty quickly on a lot of its functionality. You need to understand the interfaces and all the components that are part and parcel of the service.

When you ingest data into Azure Sentinel, not all of the events are received. The way it works is that they're written to a native Sentinel table, but some events haven't got a native table available to them. In this case, what happens is that anything Sentinel doesn't recognize, it puts it into a custom table. This is something that you need to create. What would be good is the extension of the Azure Sentinel schema to cover a lot more technologies, so that you don't have to have custom tables. If Azure Sentinel had the ability to ingest Azure services from different tenants into another tenant that was hosting Azure Sentinel, and not lose any metadata, that would be a huge benefit to a lot of companies.

Its documentation is not so simple. It is easy for somebody who is Microsoft certified or more closely attached to Microsoft solutions. It is not easy for those who are working on open-source platforms. There isn't a central point where everything is documented, and there is no specific training or certification.

Azure Sentinel is constantly growing. Throughout the two years we have been using it, we have seen it expand tremendously. A lot of the limitations we had originally seen have already been mitigated. A couple of potential improvements could be: allow for a streamlined CI/CD procedure. Now it's a combination of using API/Powershell and ARM which is not ideal. Also, it should allow us to ingest on-prem logs by using a SaaS platform to ingest CEF/Syslog logs that also allow for prefiltering. This would allow us to minimize the cost of the solution.

Add more out-of-the-box connectors with other SaaS platforms/applications.

They could use some kind of workbook. There is some limitation doing the editing and creating the workbook. That would improve it. Sometimes you will find some network issue, and network error with the Azure Sentinel portal. That's the biggest drawback I found with the Sentinel. It would be great if would provide PIP platforms. They do have PI platforms but they don't have PIP.

We have just recently migrated to this product. We haven't used it long enough to note all of the features. Therefore, it would be impossible to note what is lacking just yet. The interface could be more user-friendly. It''s a small improvement that they could make if they wanted to.

Azure Sentinel, the Microsoft Azure product is, from what I understand, used for the Microsoft applications. I don't know if it works outside of the Microsoft Azure cloud. I would like to be able to monitor applications outside of the Azure Cloud. That is one of the reasons one of the customers has multiple tools.