## 3 Application of Generic Patterns for an SOA IDS
### Detection of Anomaly Patterns  
In the following, we describe several considerations to assist in the design of an SOA IDS. Since anomaly-based IDSs are already one of the most efficient solutions for network intrusion detection [52], we focus on anomaly detection in our generic IDS approach. **Transforming SOA communication into a generic feature set:** One challenge in developing a generic approach for SOA IDSs is that the protocols used for implementing the SOA differ [R1]. Often, the _IDS approach is fitted to the protocol_. However, we propose to _fit the protocol to the IDS approach_ and transform all network traffic of the different SOA implementation technologies into a generic feature set. This approach is similar to [58]. However, for SOA communication, we aim to differentiate between publish/subscribe, request/response, and stream communication, whereas [58] differentiates between push, request/response and write or call traffic. In our approach, each packet shall be transformed in a generic _action_ with an _ID_, _type_ and metadata (_time_, _source_ and _destination_). **Identification of Actions:** To be able to identify an action of a service and its client or server uniquely (_ID_), a feature for abstraction has to be created from the data available by the different protocols [R1, R7]. For SOME/IP, this could be a combination of the Message-ID and the Request-ID (see [34]), for example. **Monitor Stationary States:** In case all participants have started and all services are set up, a stationary state for the context is reached. Therefore, some values of states or payloads should remain in a specifiable range [R2, R3, R6]. **Monitor Number of Active Connections:** While for RPC, the number of connections is defined during the development phase, for stream and publish/subscribe service types, this is not applicable. However, an upper and lower threshold for an interval of possible active connections can be defined. If the number of connections during runtime is outside of such an interval, it represents a deviation from normal behavior [R2]. **Service ID-Assignment Check:** At the host level, there are exclusive features that can only be observed with a host-based IDS. As an example, each application is assigned to a specific service ID, which is used by specified request/response IDs. These assignments can be observed by middleware to verify if other combinations exist during runtime [R1, R2, R7]. **Payload Plausibility:** In contrast to the Service ID-Assignment Check, interception based on the service ID and requested parameter (API) is challenging because it requires decoding and plausibility checking of the contained data. Focusing on the payload of the services, these can be analyzed for anomalies in time series, for example, as presented by [PERSON] et al. [59][R6, R8]. Assuming that future architectures will increasingly consider the principle of zero trust, payload plausibility checks can only be performed at the host level, since connections are end-to-end encrypted. **Effect Chains for RPC:** The invocation of RPCs may result in an effect chain because the orchestration of services generally is based upon other services. Thus, a specific service will result in other services being executed and thus can be trained, e.g., according to [60][R9]. Another approach is also to take the timing of the specific services invoked within an effect chain into account. The order of occurrence for RPCs is predictable by the specification within an automotive or medical SOA network, as these are usually fixed for main-services/functions. For each function (e.g., ACC Section 3.1.2), dependencies to required services are defined. The corresponding network behavior (occurrence of the service IDs) can be plotted on a timeline (s. Figure 6). The black bars represent a benign behavior in terms of timing and order of service IDs in an SOA network. In contrast, the gray bars encompass a deviant behavior triggered by an attacker.