Thank you for describing your SOC workflow. Yes, that can be implemented. The question remain about your dataset including content of the lookup (whitelist), maybe also the procedure used to produc...
See more...
Thank you for describing your SOC workflow. Yes, that can be implemented. The question remain about your dataset including content of the lookup (whitelist), maybe also the procedure used to produce this lookup. One particular aspect is characteristics of sourcetype="ironport:summary" and sourcetype="MSExchange:2013:MessageTracking". How frequently are they updated respectively? Is one extremely large compared with another? How does each sourcetype, and each lookup contribute to the workflow you are trying to implement? Do they play similar role or differing roles? In other words, describe your workflow in terms available data. Which fields in each are of particular interest to SOC analyst? Which field(s) from which source contains sender domain, which contains known domain, for example? What each of lookups contain? How are they of interest to SOC analyst? There are a lot of miscellaneous fields in the code sample, e.g., file_name. Do they materially contribute to the end results? If so, how? A technical detail is macro `ut_parse_extended()`. What does it do? (Which input fields does it take - explicit inputs are senderdomain and list, obviously but an SPL macro can also take implicit inputs, and which output fields does it produce/alter?) Another macro `security_content_ctime()` also invoked twice. What does this do? Additionally, is your main goal to improve performance (join is a major performance killer as @PickleRick points out), or to improve readability (hence maintainability)? These two do not necessarily converge as join is better understood in many circles.