let me summarize in detail.
1) TIEM has access to the AV engine directly. Therefore the information from the engine is available for TIEM.
2) The TIEM content updates are used to definde which metadata and information about executed executalbe code is collected.
3) Information from the TIE Server e.g. Enterprise count or Reputation score are used to gather additional information.
4) Based on the TIEM policy (System classification e.g. Typical System) this rules are evalutated.
5) If specific rules are triggered a TIESuspect event is generated and sent to EPO.
Anything else missing?? :-)
I think you are correct in spirit, but I would describe it differently. When the TIEm is calculating local reputation for am executable, each rule is evaluated in order, from top to bottom (based on the system classification, as you mention above). Each rule may call out for additional details on the file (which may be local metadata such as the execution directory, or data from the TIE server such as reputation of the signing certificate, prevalence in the enterprise, age in the enterprise, etc). Each rule *may* then attempt to make a local reputation determination. If a reputation is determined, then we're done. If not, then the next rule is executed. If all rules execute and we still haven't finalized a reputation, then we are stuck with "Unknown".
An important distinction is that bits of information are pulled by individual rules. For example, certificate reputation is fairly high in the rule priority (Rule 8...basically first after some housekeeping rules) When this rule executes, TIEm only requests the certificate reputation information from TIE Server. If we get a result here, then TIEm doesn't need to request other information like GTI or Enterprise reputation. The incremental nature of these rules is important for maintaining performance. If the majority of the executables are resolved with early rules, then we don't need to incur network or other resources necessary to resolve the lower priority rules.