how to add 2 different conditions in rule

A couple things I notice in your rule example that may be causing you issues:

1. `$e2.principal.log_type` is not a UDM field. You likely mean $e2.metadata.log_type
2. In the condition section, you cannot`OR` multiple non-existence conditions. Error: 'or' operator is not supported with 'less than' or 'equal to 0' condition yet. As mentioned in docs, !$e3 is equivalent to #e3 = 0 (equal to 0) so this condition cannot be OR-ed.

Based on your description, the condition you want to enforce can be expressed logically as:
($e1 and not ($e2 and $e3)) or ($e2 and not $e3)
This can be condensed/simplified to the logically equivalent:
($e1 and !$e2) or ($e2 and !$e3)

Unfortunately, this still contains an `or` of `equal to 0` conditions though. I was not able to find an equivalent logical expression that does not do this and as such, we will have to use a different approach.

The approach that comes to mind when looking at this simplified form is using Composite Detections. Basically, split your rule into two producer rules, one with a condition of `($e1 and !$e2)` and the other with a condition of `($e2 and !$e3)`, then create a third consumer rule to `or` detections from rule 1 + rule 2. By making your producer rules enabled but not alerting and your consumer rule enabled and alerting, you would achieve alerting on your desired conditions with all the alerts coming from the same rule.

That said, if the alerts all coming from the same rule is not a requirement for your use-case, you can simplify this approach to just the first two rules, both enabled and alerting. This would give you all your alerts, but they would come from two different rules.

If you are able to simplify/loosen your conditions, you may be able to do this in a single rule but given your current set of desired conditions, I do not believe there is a way to do this in a single rule given the present-day conditions section limitations in SecOps. This may change in the future as the product continues to expand though so may be worth a revisit in the future.

If you are able to provide a detailed description of the behaviors you are trying to detect on, how they present themselves in logs, and how they chain together to be malicious vs benign, we may be able to help you modify your rule more holistically such that the condition section does not require such complex logic to achieve your desired detection goal, but at least for now I believe the two approaches I have described above should work for your use-case.

Let me know if you run into any issues or would like me to elaborate on any of the above.