You'll need to be more specific as to what you are looking for, what types of attacks, etc.
These will be somewhat unique to each environment, you could start by defining the use case you are looking to address, for example malicious website visits, or a malware detection. These again will be specific to your installation of controls, and these sources being setup in SIEM.
A use case should start by defining a problem or request, the desired outcome, such as alert, alarm, report, automated action, and notifications. From here you can determine the data sources needed, activities or signatures and then response or outcome.
I will revisit this. I was hoping that there may be some sort of lists out that that could be used "off the shelf". Thanks anyway and I will give this a bit more thought.
The SIEM supports hundreds of use cases of out the box and more by installing content packs. Use cases are ultimately going to be dictated by the unique variety of data sources that are feeding your SIEM. I recommend starting with your most critical area and after your satisfied with the use cases validating the security in that area, you move on to the next one.
For instance, you mention that you're interested in "halting attacks". Is there a particular category of attack you're concerned about? What other devices do you have to aid you in your mission?
I'm generally interested in any sort of attack but I'm particularly interested in those by nation states attempting to steal information. Sorry if that's a bit general. I have IDS and FW's along with Windows/Linux/Unix boses sending through logs.
Exfiltration is a good and challenging use case. If you actually have crown jewels that you can identify, that's a great start. Best practices will have you storing that data in a segregated area with increased scrutiny for anything crossing the boundaries to access it. Each gate should have some sort of limiting qualifier and you need to have some way to measure that. If you data is stored in a database, it might make sense to do query level logging to provide visibility into every time that data is accessed. Then you can validate those transactions against correlation rules and statistical analysis to understand when more investigation is required. Or there might be a need to implement a DLP solution to track documents or enable Windows object logging.
The key is to find ways for the SIEM to validate that your security posture is operating as you designed it. From that perspective, is there a method for the FW or IDS to detect the exfiltration of data that you're concerned about? Are there signatures in the IDS (IPS?) that would detect/stop the data? What if the data transfer is encrypted? Are all possible egress points controlled and monitored? If so, then we feed events from those tools into the SIEM and display the security state of the data based on the logs and visibility provided.
The SIEM is just the smart guy at the party. Someone else needs to bring the party.
You can google SIEM use cases and get a lot of ideas, brainstorming we've come up with 173 total, with some dupes and some we may never get in. you can look at Malware detection's, account lockouts, alternatives to some of the pre-installed or setup options as well. If you use your imagination, as mentioned a few times here, you'll be surprised. Ask your team, or manager what ae their concerns, getting these in dashboards allow for some quick wins. A reference I found handy was an accelops paper, it also talked about value of the data sources you get into the SIEM.