You don't need to reorder the rule. What is occuring is because you selected generic syslog it is creating a DS rule for each unique syslog entry the receiver receives.
What you need to do is write a custom parser. See - McAfee Corporate KB - Writing Custom Parsing Rules in McAfee ESM PD24926
Make sure the parser is enabled in the policy bound to the data source. Then all events will fire off that parser. (You may need to create more than one parser). But you may want to check the security onion distro, you may be able to set the output to CEF (Common Event Format). IF so, start with CEF and that can help out a lot!
Don't worry about those data source rules, they must have been created by SIEM when you had "create user defined rules" on under Support Generic Syslogs. You can now create your ASP rule or existing custom ASP rule, move them over from unordered rule windows to ordered, left to right. Place them on top and roll out, new incoming events should match these custom ASP rules rather than data source rules.
Auto-learning rules are critical and powerful so understanding how they work is important.
First of all, as has been mentioned, there is an option for "Parse as Generic Syslog" under the Data Source settings. It's really a remnant of an earlier era and should never be used under any circumstances. The reason is that every time a different event is received, it will be learned as its own rule. Almost all events are going to have a timestamp and this will be different with every event leading to the creation of a rule and filing up the rule table quickly (1 million rule limit).
The way to leverage auto-learning to your advantage is when you have events with the same structure and the dynamic piece is finite. For instance, let's say I have the following events:
Nov 4 17:48:47 tecate dovecot: imap(lisa): Disconnected: Logged out in=578 out=75618
Nov 4 17:53:27 tecate dovecot: imap(tori): Disconnected for inactivity in=7875 out=141041
I could write a single parsing rule like this:
and set the Signature Name to: "Linux IMAP: "+1:4
They would show up as:
Linux IMAP Disconnected for inactivity
Linux IMAP Disconnected: Logged out
thus we have two auto-learned rules.
If the vendor has the insight to create their log output with a consistent format, we can parse all of the messages with a small number of rules. Another example would be a device that outputs the facility, e.g. debug, info, error, critical, fatal in that we can use auto-learning to correctly classify and parse the data regardless of the content. This is ideal. This is the case and goal with formats like CEF and JSON.
So the gist is that auto-learning is great for creating parsing rules without the need to create a rule for every single variation. When you see a pattern, make it part of the rule. However, it's important to not include anything in the rule name that shows a lot of variation, like a timestamp, IP address, hostname, etc... lest your rule table fill up. There's nothing wrong with a complex product requiring a large number of rules (BRO, Security Onion, pfSense) so long as you're on top of approximately how many rules are being created, and why.
If you blow up your rules table, you can delete specific auto-learned rules, rules learned for a particular data source type*, rules learned during a particular window or all rules. When you delete auto-learned rules that include existing events, the event name will show up as '0' until the rule is auto-learned again. Be aware of this in the instance where you might change a parsing rule and delete the auto-learned rules. New rules may not ever match the original rule again thus leaving the event name at '0', so do be aware of deleting auto-learned rules that may never be relearned if you are required to maintain that data.
* Notable since I did not say a specific data source, only the type. We're not able to delete rules for a single Data Source unless it is the only one of its type.
There is a bit of nuance in parsing and auto-learning, but it's gratifying once you're able to understand why they work the way they do. Please continue to ask more questions if you have them. Thanks.