Security Patterns

While the design patterns developed by Gamma et al. are intentionally abstract with the goal of being applicable to a wide range of problems, domain-specific constraints need to be considered for the design. In the case of security patterns, threats to a system need to be monitored using specific security mechanisms for the specific context [7]. Following a similar format for describing a design pattern, security patterns are also given a descriptive name, the security problem addressed (e.g., a class of specific threats), a solution strategy to prevent, detect, and/or mitigate the security vulnerability, and a set of consequences [7].

Research in the field of security patterns has been active for almost two decades [17,19,20]. The focus has been on capturing higher level security mechanisms and organizing them into abstract patterns, which has guided cross-application security patterns [21,22]. The aforementioned work underscores the wide use of security patterns throughout different software systems, including distributed systems [23], enterprise systems [7,18], and, more recently, cloud computing systems [7,10], Security patterns apply to all phases of the software development process, such as requirements gathering, design, and implementation [20]. Within a collection of security patterns, several abstract patterns exist, indicating more specializations of patterns (e.g., [7,18,24]). A study by Ito et al. [17] surveys trends in security pattern research over the past decade.

Similar to general design patterns [16], security patterns have been described using specific fields to capture use-cases, consequences of design, etc. We leverage and extend a specific template developed by Wassermann and Cheng [9] and then refined by Konrad et al. [25] that captures important areas of a security pattern, namely: Name, Alias, Intent, Applicability, Motivation, Structure, Consequences, Known Uses, and Related Patterns.

Automotive Communication

The CAN Bus is the major networking communication infrastructure used within an automotive system [27]. It relies on a broadcasting protocol that allows for any ECU attached to the CAN Bus to both send and receive messages as predefined ECU behavior, independent of the CAN Bus [28]. The CAN Bus is designed to be lightweight and fast, and consequently lacks common communication protocol features such as authentication or encryption. While data on a CAN Bus may carry identifying information to be interpreted by the intended receiving ECU, the CAN itself does not identify particular data frames, instead relying on a prioritization scheme of message arbitration to control access to the CAN Bus [29].

Potential security drawbacks to such a communication model include vulnerabilities posed by the lack of message authentication, such as spoofing and injection attacks. An injection attack makes it possible for an adversary to manipulate the functionality of an ECU [30]. Because the CAN Bus has no default protocol for encrypting data frames on the network, the risk of compromising sensitive data poses another security concern [27,28,31,32]. Finally, the CAN message arbitration system can make it vulnerable to denial of service (DoS) attacks through an attacked ECU, such as the tire pressure monitoring system (TPMS) [3,33].

In addition to the CAN Bus, multiple technologies are increasingly being used to handle the growing demands of automotive communication. For example, automotive wired networking technologies include Local Interconnect Network (LIN), Media-Oriented System Transport (MOST), FlexRay, and automotive Ethernet; several recent surveys have overviewed the respective vulnerabilities and research challenges [28,34,35]. Rouf et al. also reviewed security vulnerabilities for in-vehicle wireless networking [33].

Vehicle Ad-hoc Networks (VANETs) make use of a number of wireless inter-vehicle networking, such as dedicated short range communications (DSRCs), long-term evolutionary vehicle (LTE-V), and Worldwide Interoperability for Microwave Access (WiMAX) [34]. With the increasing movement toward vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), and vehicle-to-third-party devices (V2X) communication [36,37], security and privacy challenges correspondingly increase [34,38].

Degree of Access

While numerous automotive threat surfaces have been identified, we broadly categorize them by the type of access an attacker uses: direct (i.e., physical), indirect, and remote [39].

Direct access targets include the CAN Bus, the OBD-2 port, and the media/auxiliary port. The OBD-2 port provides a mechanism for sub-system diagnostics and requires an attacker to be physically plugged in as shown in experimental attacks [3,4,40]. The media player and auxiliary ports in a vehicle are often connected to the CAN Bus; and by physically inserting compromised files into the new media device, an attacker can subsequently inject (malware) code onto the CAN Bus [3].

Indirect access to a vehicle refers to compromising a device that can be used as a medium to attack the vehicle’s sub-systems. Bluetooth networks are commonplace in modern vehicles, and accessing the vehicle’s internal Bluetooth network is feasible through a connected, compromised device [3,4]. Similarly, if a diagnostic device has been compromised and then attached to the OBD-2 port of a vehicle, then the vehicle becomes vulnerable to a malicious attack. [3,4]

Finally, remote attacks have been demonstrated in several scenarios, where the attacker can be physically distant from the target. Through a vehicle’s telematics system, such as General Motors’ OnStar® or Hyundai’s Blue Link®, “white hat hackers”² have shown the ability to attack using only an Internet connection [41]. With more outward-facing communication (e.g., V2V, V2I, and V2X), there is increasing risk for malicious actors to inject malware through VANETs [37,38,42,43].

Automotive Security Pattern Template

The automotive security patterns are described in a template similar to that used by Konrad et al. [25].

• Pattern Name - The name and classification of a pattern as either behavioral or structural.

• Intent - How the pattern can be used and what security problem it addresses.

• Motivation - Background on the security problem, and a mechanism to solve, including examples and security principles that are related.

• Properties - STRIDE properties [14] that are addressed through this pattern.

• Applicability - Indicates the type of solution proposed: prevention, detection, and/or mitigation of a given security vulnerability.

• Structure - Includes the UML class diagram for the pattern and the related descriptions of participants and collaborations.

• Behavior - Includes a UML sequence diagram and descriptions of an illustrative scenario with the pattern.

• Constraints - Denotes constraints placed on the pattern implementation stemming from the limited resources and real-time constraints of the automotive system.

• Consequences - Discusses the effects of the pattern on the areas of Accountability, Confidentiality, Integrity, Availability, Performance, Cost, Manageability, and Usability following the template from Wasserman and Cheng [9].

• Known Uses - Discusses examples of this pattern’s use in an automotive setting.

• Related Patterns - Any design patterns or security patterns that relate to the given pattern.

Intent

Authorization provides a structure that facilitates access control to resources.

Motivation

Many systems need to restrict access to their resources according to certain criteria (e.g., a security policy) [7]. In automotive systems, inadequate authentication and authorization protocols have exposed the system to a variety of security exploits such as attacks on inter-vehicle networks [28], spoofing ECUs [30], and various other exploits [2,3]. In the case of Cranchelli et al. [48], the motivation for developing an authentication protocol for a communications bus, similar to a CAN bus, comes from the potential for ECUs and ECU messages to be spoofed. According to SAE standard J3061, preventing unauthorized access to data as well as controlling component privileges are key principles in developing automotive cybersecurity for a system[11]. According to Viega McGraw [15], the principle of being reluctant to trust improves the systems abilities to mitigate any security exploits a sub-system may have. This is particularly applicable to an automotive system, as many components come from different principle, and increasingly, vehicles have more communication with external entities.

Properties

The Authorization can be used to satisfy the Authentication property, and the Authorization property.

Applicability

Authorization is applicable to attack Prevention.

Structure

The Authorization structure of a system can be captured in terms of their relationships (Figure 1). Active entities are represented by instances of a Subject class and passive resources by instances of a Protection Object class. Between those main participants exists a relation that portrays which Subject is entitled to access certain objects. The properties of this relationship are organized in the association class Rights. The objects of this class define the type of access, transfer conditions, and constraints that restrict the use of Rights.

Figure 1

Class diagram for Authentication Pattern.

Participants

The following section describes the participating classes in the pattern structure:

• Protection Object

  • –

    Represents passive resources of the system that are accessed by Subjects.

• Rights

  • –

    Defines the properties of the authorization rule between Subject and Protection Object.

  • –

    The access type property describes which kind of access of the current Rights object grants. Commonly, this property holds values in the style of read, write, execute, . . .

  • –

    The constraint property is a predicate that describes under which circumstances the current Rights object is valid and may grant a certain privilege.

  • –

    The transferable property determines whether a right is transitive and its connected Subject may grant the right to other active entities.

• Subject

  • –

    Represents active entities that need to access Protected Objects in accordance to their Rights.

Collaborations

Different Subjects in the system want to access Protection Objects. In order to make use of a certain resource they need to request access to it from the responsible controlling instance. This instance will check if an association class between the Subject and the Protected Object exists that justifies the required access request. Depending on this examination, access is granted or not.

Behavior

A Subject wishing to access a Protected Object will request access at a Checkpoint Object (Figure 2). The Checkpoint will request the rights pertaining to the Subject, and if approved, will forward the request to the Protected Object.

Figure 2

Sequence diagram for Authentication Pattern.

Constraints

In an automotive system, example constraints on an Authorization pattern include the performance of the authorization protocol and the amount of resources it may require. Because a vehicle is limited in the resources it has available (e.g., CPU and memory), there is a need to perform authorization efficiently. In addition, the need for real-time execution; where multiple Subjects may be sharing access to a Protected Object, delay is often unacceptable.

Consequences

Table 3 describes consequences in implementing the pattern.

Known Uses

As mentioned in the motivation section, Cranchelli et al. [48] has developed an authorization module for a shared communication bus to authenticate and manage authorized communication between ECUs on the bus [48]. It is able to authenticate ECUs on the bus at system start-up, and by using digital signatures, authorize ECUs’ interactions with one another.

Related Security Patterns

The Check Point pattern can be used to examine requests by using the structure of the Authorization pattern. The RBAC or Roles pattern is an extended version of this pattern.

Supported Principles

The Authorization pattern should be used in combination with Principle 4 (principle of least privilege) to assign the user’s rights. Furthermore, Authorization can be used to compartmentalize (Principle 5) the system and reduce the impact of a security breach. For example, an attacker that illegally manages to authenticate as user A, has only the rights user A would have. Given a restrictive security policy, the enforcement of access rights promotes privacy (Principle 7).

Intent

A firewall allows for network traffic to be filtered by a set of predefined rules to prevent malicious intrusion.

Motivation

Application firewalls allow for control protocols to be placed on traffic accessing specific services in a sub-system. This may be appropriate when system level protocols are not able to capture the requirements of application level control [7]. In an automotive network, unfiltered traffic can result in attacks on system components from malicious traffic, as well as from compromised system components. On a CAN Bus, e.g., externally facing ECUs such as a media player can be compromised and as a result present a threat to other ECUs on the CAN Bus. Rizvi et al. [51] specifically addressed this scenario in their work. As it pertains to SAE J3061, the use of Firewall promotes the principle of practicing defense in depth, by securing ECUs on an individual basis [11]. This pattern also promotes the Viega and Mcgraw principles of Reluctance to Trust and Compartmentalization [15].

Properties

The Firewall can be used to satisfy the Authentication property, the Authorization property, the Integrity property, and the Nonrepudiation property.

Applicability

The pattern is applicable to attack Prevention and attack Detection.

Structure

A Client accesses a Service through a Firewall (Figure 3). The Firewall references the rules which are represented by a Policy Object and aggregated in the Policy Base Object. The Firewall consists of the Policy Authorization Point, where the rules and identities for the Firewall are centrally stored. The Firewall also consists of several Policy Enforcement Points which check accesses to a particular module. The data flowing through the Firewall is checked by the Content Inspector.

Figure 3

Class diagram for Firewall Pattern.

Participants

• Client

  • –

    Actor requesting access through the Firewall.

• Application

  • –

    Module protected by Firewall, composed of Services.

• Firewall

  • –

    Enforcement and access point through which the Client accesses an Application’s Services.

• Policy Authorization Point

  • –

    Central collection of access policies and identities used by the Firewall.

• Identity Base

  • –

    Collection of authorized Identities.

• Policy Base

  • –

    Collection of authorized Policies.

• Policy Enforcement Point

  • –

    Checks access to Applications

• Content Inspector

  • –

    Checks data flowing through Firewall

Collaborations

A Firewall can act as a mediation point for many Applications and many Clients. An Application is composed of Services. A Firewall is composed of a Policy Authorization Point, possibly several Policy Enforcement Points, and a Content Inspector. The Policy Authorization Point is composed of an Identity Base and a Policy Base which are respectively composed of Identities and Policies.

Behavior

A Client begins by requesting a Service from an Application through the Firewall (Figure 4). The Firewall forwards the request to the Policy Enforcement Point where a Policy Authorization Point is asked to check the Client’s access privileges by looking up the Identity and Policies in the Identity Base and Policy Base,respectively. If access is granted, then content of the request is checked by the Content Inspector and finally sent to the Application to service the request.

Figure 4

Sequence diagram for Firewall Pattern.

Constraints

In an automotive system, limited and shared resources limit the extent of Firewall usage. Given the constraints of a real-time environment, overhead incurred by processing messages may affect critical response time. Finally, given a variety of different ECU vendors, there can be difficulty in developing a uniform Firewall system and enforcing the practice.

Consequences

See Table 4.

Known Uses

As described previously, a solution to systemic risk of attack on the CAN network given the compromising of an ECU was proposed by Rizvi et al. Here, firewall-like programs installed on individual ECUs examine incoming packets to determine if the message should pass to the ECU for processing [51].

Supported Principles

Firewall pattern promotes Principle 1 (Secure the Weakest Link), Principle 4 (Least Privilege), and Principle 9 (Be Reluctant to Trust).

Related Security Patterns

The pattern is related Authorization and Role-Based Access [7].

Intent

This pattern is intended to provide a mechanism for handling access in a system with various security classification levels.

Motivation

In many systems integrity and confidentiality of data need to be guaranteed [7]. In an automotive environment, certain resources are critical to system and user safety (e.g., ABS braking and power steering) and must be given a higher degree of access control. Moreover, on an automotive communication network, e.g., some ECUs might be externally facing (i.e., communicating with external entities) and are consequently more susceptible to compromises. By segmenting access by degrees of trust in a multilevel security hierarchy, system critical resources can be given this higher degree of access control, and resources more susceptible to compromise can be given limited trust, thus ensuring a higher degree of overall security in the system. In the work by Wang and Sawhney [52], the researchers address the problem of different levels of access control, differentiating between externally facing ECUs and those that manage more system critical components [52]. According to SAE J3061 Standards [11], key cybersecurity principles include protecting sensitive data, using the principle of least privilege, and applying defense in depth. A Multilevel Security pattern achieves the aforementioned objectives by securing sensitive resources from less trusted entities, giving individual system components privileges to use other system resources only if they are trusted, and finally ensuring that interactions between different components is authenticated on a case-to-case basis.

Properties

The Multilevel Security can be used to satisfy the Authorization property, and the Confidentiality property.

Applicability

The pattern is applicable to attack Prevention, and attack Mitigation.

Structure

To represent the Multilevel Security pattern, for each Subject, there exists an instance of the Subject Classification class and for each Object an instance of the Object Classification class (Figure 5). These instances are used to aggregate a Subject’s and Object’s respective security levels and categories.

Figure 5

Class diagram for Multilevel Security Pattern.

Participants

• Object Category

  • –

    Defines a category to which an Object belongs.

• Object Classification

  • –

    Determines the security classification of an Object (passive resource that is accessed by Subjects).

  • –

    The Object’s security classification is represented by a set of Object Categories and Object Levels.

• Object Level

  • –

    Defines the security level of an Object.

• Subject Category

  • –

    Defines a category to which a Subject has access.

• Subject Classification

  • –

    Determines the security classification of a Subject (active entity that accesses Objects).

  • –

    The Subject’s security classification is represented by a set of Subject Categories and Subject Levels.

• Subject Level

  • –

    Defines the security level of the Subject.

Collaborations

The classes Subject Classification and Object Classification contain a set of Category and Level classes. This set determines the security classification of the respective Object. Access will be granted if the Classification of the requesting Subject dominates the Classification of the Object. The Behavior section explains in detail how to determine whether one classification dominates a second one.

Behavior

In the Multilevel Security pattern, the Subject requesting access to a resource will request access at the Checkpoint (Figure 6). The Checkpoint then obtains the Classification of both the Object and the requesting Subject. If the requesting Subject’s classification dominates the Object, i.e., has an equal or greater security level, then the request is forwarded.

Figure 6

Sequence diagram for Multilevel Security Pattern.

Constraints

In a real-time environment, such as that of an automotive system, verification of clearance must be a quick and efficient process in order to minimize delays in access to resources.

Consequences

Table 5 describes the consequences of using the Multilevel Security pattern.

Known Uses

As mentioned previously, the VeCure system seeks to segregate access to certain ECUs by differential degrees of trust. Using multi-tier trust circles, the system is implemented to keep core systems safe from external facing ECUs on a CAN bus network [52].For example, messages from the externally facing OBD-II port and Telematics systems are considered to be in a lower trust group than the nonexternally facing ECUs of the higher trust group, such as the ABS braking system [52].

Related Security Patterns

The Check Point pattern may be used to enforce the Multilevel Security structure, which can be provided in Session object.

Supported Principles

The Multilevel Security pattern and its mechanism of granting access to subjects implements the principle of least privilege (Principle 4). Furthermore, it facilitates compartmentalization (Principle 5) and reduces the impact of a security breach. Promoting privacy(Principle 7), Hiding secrets is hard(Principle 8), and Reluctance to trust(Principle 9) are key ideas of the Multilevel Security pattern.

Intent

The pattern provides a mechanism for detecting anomalies in network traffic by using a baseline characteristic of the traffic.

Motivation

On an open network, there is a need for detecting malicious traffic as soon as it occurs to prevent damage to a system [7]. In an automotive network such as that used with the CAN, there is no mechanism for detecting malicious traffic in the protocol, such as a spoofed ECU. By detecting deviations from a baseline behavior, such malicious activity can be detected. SAE J3061 emphasizes the need for comprehensive responses to cybersecurity incidents [11]. A component of this response is the ability to detect intrusions and respond quickly. The pattern supports the principle of Reluctance to Trust [15] as authenticity is always verified before a message is allowed to pass.

Properties

The Signature-based IDS can be used to satisfy the Authorization property, and the Integrity property.

Applicability

The Signature-based IDS is applicable to attack Detection, attack Prevention, and attack Mitigation.

Structure

The Signature-based IDS intercepts the access request for a service (Figure 7). The Event Processor processes the request to parse the relevant Signature Information. The Attack Detector then tries to match the Signature Information against the known signature information to determine if the Signature is known. If the Signature is unknown, then the appropriate Response is issued [7].

Figure 7

Class diagram for Signature Intrusion Detection Systems (IDS) Pattern.

Participants

• IDS: Intercepts messages and performs proper action given a Response

• Event Processor: Obtains Signature information from message

• Attack Detector: Checks Signature against known signatures

• Signature Information: Has ID of known actor and the corresponding Signature

• Signature: Identifying characteristic of actor

• Response: Communicates signature results back to IDS for message handling

Collaborations

The IDS has a one-to-one relationship with the Event Processor and forwards requests to be processed. The Event Processor collaborates in a one-to-one relationship with the Attack Detector that obtains processed data from the Event Processor. The Attack Detector includes the Signature Information of known entities. The Attack Detector has a one-to-one relationship with the Response object that formulates the response given the results of the Attack Detector. Finally the IDS has a one-to-one relationship with the Response object that forwards the correct response to the IDS.

Behavior

A message is sent from a source to an intended destination node (Figure 8). The Signature-based IDS intercepts the message and determines if the Signature is known to the system. If the sender is unknown, then an appropriate Response is raised [7].

Figure 8

Sequence diagram for Signature Intrusion Detection Systems (IDS) Pattern.

Constraints

As an IDS analyzes traffic before the messages are sent to the intended receiver, there is overhead incurred when using the pattern. The solution provided by Cho and Shin [46] utilizes a predictive algorithm implemented in hardware to decrease the processing time in order to minimize the overhead.

Consequences

Table 6 describes the consequences of using the Signature-based IDS pattern.

Known Uses

An example of a lightweight IDS for CAN bus was proposed by Cho and Shin [46]. Here, the system used clock-based finger-printing and predictive algorithms to determine expected clock-skews of ECUs, thus enabling the detection of spoofed messages and authentic ones.

Related Security Patterns

The pattern is a specialization of the Abstract IDS pattern and is related to the Firewall pattern, another access control pattern for networks [7].

Supported Principles

Principals supported by the Signature-based IDS include Principle 9 (Be Reluctant to Trust), as the IDS intercepts messages to verify the identity of the sender before allowing it to access protected resources, and Principle 3 (Fail Securely).

Intent

A Tamper Resistance-based module deters unauthorized changing of a system by preventing alterations, or preserving evidence of alteration.

Motivation

In a given system, altering certain modules may lead to unpredictable and potentially dangerous system behavior. In an automotive system, this can result in dangerous vehicle functioning and increased susceptibility to malicious attacks. Work by Wolf and Gendrullis notes the potentially dangerous consequences of alteration to a standard Hardware Security Module [50]. Unchecked alteration of the module can lead to security vulnerabilities for any other vehicle sub-system that relies on the module for cryptography services. As it pertains to SAE J3061, the use of tamper-resistant design can promote the protection of sensitive data, and prevention of unauthorized changes to a vehicle [11]. The pattern also promotes the principles of failing securely [15].

Properties

The Tamper-Resistant Modules can be used to satisfy the Integrity Property, the Nonrepudiation property, and the Authorization property.

Applicability

The pattern is applicable to attack Prevention, attack Mitigation, and attack Detection.

Structure

The Tamper-Resistant Modules structure of a system can be captured in terms of their relationships (Figure 9). The pattern is understood as the Interface, between the Subject and the Tamper-Resistant Object. The Interface has a Working State that abstractly describes the untampered status of the Tamper-Resistant Object. If the Tamper-Resistant Object is altered, the Interface will fail to interact with the Tamper-Resistant Object in the way the Working State predicts, causing the Interface to initiate a tamper response, whether it be disabling itself or changing to an immutable tamper state.

Figure 9

Class diagram for Tamper-Resistant Modules Pattern.

Participants

The following section describes the participating classes in the pattern structure.

• Subject

  • –

    An actor requesting to access a Tamper-Resistant Object.

• Interface

  • –

    Medium for communication between the Tamper-Resistant Object and a Subject.

• Working State

  • Abstractly, the Interface’s working model of using the Tamper-Resistant Object as it was designed.

Collaborations

A given Subject will attempt to communicate with a Tamper-Resistant Object through an Interface. Consequently, there is an association between both the Subject and the Interface and the Tamper-Resistant Object and the Interface. The Interface has an association with the Working State. The Tamper-Resistant Object has an associated Working State.

Behavior

Figure 10 depicts a scenario where a Subject interacts with the Tamper-Resistant Object. The Subject will send the request, prompting the Interface to forward the request to the Tamper-Resistant Object on behalf of the Subject. To do this, the Interface will consult the Working State object for the proper protocol of interaction. When the Interface fails to interact with the Tamper-Resistant Object as tampering has rendered the Tamper-Resistant Object different from its Working State, the Interface will execute its tamper response.

Figure 10

Sequence diagram for Tamper-Resistant Modules Pattern.

Constraints

In an automotive system, additional hardware, like that required to enforce Tamper-Resistant Modules, can be expensive and take valuable space in the system.

Consequences

Consequences for applying this pattern are given in Table 7.

Known Uses

As described by Wolf and Gendrullis [50], a tamper-resistant design achieved by a system-on-chip non-detachable connection with ECU hardware promotes tamper resistance or at least evidence of tampering.

Supported Principles

Tamper-Resistant Modules pattern promotes Principle 3 (Fail Securely), Principle 4 (Least Privilege), J3061 principle 4 (Prohibit Untested Software Changes), and J3061 principle 5 (Prevent Vehicle Owners from Making Unauthorized Changes).

Related Security Patterns

Tamper-Resistant Modules is related to the Secure Logger described by Fernandez [7].

Intent

A Blacklist intends to monitor the traffic of potentially malicious addresses in a network. Nodes in the network use the Blacklist to block traffic originating from the malicious nodes.

Motivation

Communication with external entities is becoming increasingly integrated into modern automotive systems. Today’s cars communicate with smart infrastructure, receive over the air updates from manufacturers, and exchange information with other vehicles on the road. While these technologies allow for improved performance and user experience, the increased reliance on networks leaves a vehicle susceptible to attack from a malicious user on the network. The inability to identify compromised nodes poses a security risk to an automotive system. VANETs allow vehicles and smart infrastructure to share information about current driving conditions within a specific broadcast range. Due to the routing protocols upon which VANETs rely, a malicious node can join a VANET and proceed to attack the network by intercepting the communication between vehicles, dropping packets, and changing or fabricating packets [64]. Applications such as the Post Crash Notification [65] can be deployed on VANETs to detect an attack such as injections of false messages that can lead to potentially dangerous responses by the vehicles on the network.

Properties

The Blacklist can be used to satisfy the Authentication property, the Authorization property, and the Nonrepudiation property.

Applicability

A Blacklist is applicable to the Prevention and Mitigation of an attack.

Structure

The Blacklist structure of a system can be captured in terms of their relationships (Figure 11). An entity sending a message is captured by a Client object. The entity secured with a Blacklist is represented as a Service object. The interface between the two objects is a Checkpoint object. And finally, the Blacklist captured with the Blacklist object.

Figure 11

Class diagram for Blacklist Pattern.

Participants

The following section describes the participating classes in the pattern structure:

• Client: An actor requesting access to a node, or Service object.

• Service: The intended protected object. A Service has access to a system’s message processing.

• Blacklist: The system’s list object for tracking bad addresses.

• Checkpoint: The interface through which all communication with a Service is achieved, and where the Blacklist is checked.

Collaborations

A given Client will attempt to communicate with a Service through a Checkpoint. Consequently, there is an association between both the Service and the Checkpoint and the Client and the Checkpoint that acts as the interface. There is also an association between a Checkpoint and the associated Blacklist.

Behavior

A Blacklist (Figure 12) is a solution that can partially fulfill the relevant security requirements that are unmet in the problem statement. A Blacklist maintains a list of addresses within a network that have exhibited inappropriate behavior. When a packet from a blacklisted address arrives at a node, the node simply drops the packet. In the context of a VANET, nodes will not process or forward any messages that originate from a blacklisted address, and routing algorithms will not include the blacklisted nodes in calculating routes of the packets.

Figure 12

Sequence diagram for Blacklist Pattern.

Constraints

Real-time constraints are important to consider in the context of the Blacklist pattern as message processing incurs overhead as well as consumes additional resources per message.

Consequences

See Table 8.

Known Uses

An example of a Blacklist being deployed in an automotive setting is given by Daeinabi and Rahbar [60]. Here the authors propose a system in which a select number of nodes in a VANET are tasked with monitoring behavior of the other nodes, where the overall network can dynamically change over time. If one of the monitoring nodes detects abnormal traffic from a given node, then it increases a distrust value for that node. Meanwhile, all nodes in the network maintain a Blacklist. If a node is given a distrust value beyond a certain threshold by the monitoring nodes, then that node is reported and blacklisted for the other nodes in the network.

Relevant Security Principles

The Blacklist leverages Practice Defense in Depth, Reluctance to Trust, and Compartmentalize.

Related Patterns

The Blacklist is related to traffic filtering patterns such as the Firewall pattern and the Signature-Based IDS.

Intent

The DDoS Redundancy pattern is intended to make a resource or network more resilient to a DDoS by providing redundant resources in case a resource becomes inundated with service requests.

Motivation

When a service is provided over a network, resources are typically allotted based on estimated average use. A DoS attack seeks to attack a service’s availability to entities that may need to use it by flooding the service with requests. The service will have allocated all of its resources to the attacking node(s) leaving it unavailable to legitimate users. In VANETs, a DDoS attack may manifest as several nodes broadcasting on a frequency used by the VANET and consequently jamming the communication medium [61]. The result is the inability for legitimate applications and nodes to send messages on the VANET which may lead to potentially adverse affects.

Properties

The DDoS Redundancy can be used to satisfy the Availability property.

Applicability

The DDoS Redundancy is applicable to both prevention of an attack, and mitigation of an attack.

Structure

The DDoS Redundancy structure of a system can be captured in terms of their relationships (Figure 13). An entity sending a message is captured by a Subject object. The Subjects pass their request through a Check Point object which manages forwarding the request to the appropriate Resource as well as informing the Resource Manager about the request. The Resource Manager monitors loads of the system’s redundant Resources and orchestrates with both the Check Point and Resources to balance the loads.

Figure 13

Class diagram for Distributed Denial of Service (DDoS) Redundancy Pattern.

Participants

The following section describes the participating classes in the pattern structure.

• Subject

  • –

    An actor requesting to access a Resource.

• Check Point

  • –

    The interface through which all communication with a Resource is achieved, and where the Resource Manager is updated.

• Resource

  • –

    The object requested by the Subject.

• Resource Manager

  • –

    Tracks Resource usage and manages loads through orchestration with the Check Point and Resource objects.

Collaborations

A given Subject will attempt to communicate with a Resource through a Check Point. Consequently, there is an association between both the Subject and the Check Point and the Resource and the Check Point. The Check Point has a one to many relationship with Resources implying redundant resources. There is also an association between a Check Point and the Resource Manager which orchestrates forwarding by the Check Point. The Resource Manager also manages the many Resources by tracking loads and sending drop and accept messages based on Resource loads.

Behavior

The solution provided by the DDoS Redundancy pattern is related to a DDoS defense described by Mirkovic et al. [66] as Resource Multiplication. Many web based service providers deploy this method of redundant web-servers and advanced load-balancers to prevent their web-application from succumbing to a DDoS attack. In the given example of a VANET broadcast frequency being jammed by a DDoS attack, providing several frequencies allows redundant communication mediums for a VANET and consequently allows for a more available service. In Figure 14, a Subject requests a Resource at the Check Point. The Check Point forwards the request to the current Resource as well as an update to the Resource Manager. The Resource will not process the packet until it is signaled to do so by the Resource Manager. The Resource Manager flags the Resource as overloaded, and sends a drop request signal to the Resource and the resource overload signal to the Check Point. The Check Point then switches its forwarding protocol to a different Resource. The Subject will send a request again and this time it will be forwarded to the available Resource.

Figure 14

Sequence diagram for Distributed Denial of Service (DDoS) Redundancy Pattern.

Constraints

Automotive systems are constrained by resource limitations. In the context of DDoS Redundancy, this may mean that switching to another resource may not be possible. In a real-time environment, overhead required to monitor resources may impede the system response speed while also using more resources per request process.

Consequences

Table 9 describes how the DDoS Redundancy pattern affects the following system characteristics.

Known Uses

While DDoS Redundancy is employed widely by web applications today, proposed solutions for DDoS prevention in VANETs are described by Gillani et al. [37]. Researchers proposed switching between communication channels or technologies [67] when one is brought down, while other researchers [61] propose using multiple receivers operating in disjoint frequencies to provide a feasible solution.

Relevant Security Principles

Relevant security principles related to the DDoS Redundancy pattern include Practicing Defense in Depth and Compartmentalization [15]. The automotive security standard SAE J3061 [11] promotes defense in depth as a guiding security principle.

Relevant Security Principles

The DDoS Redundancy leverages Practice Defense in Depth, Fail Securely, and Compartmentalize.

Related Pattern

The DDoS Redundancy makes use of the Checkpoint pattern and the Secure Thread/Process patterns described by Fernandez [7].

Intent

The Multi-factor Authentication pattern is used to provide a redundant security measure in authenticating an actor or a message. By enforcing an additional level of authentication, malicious actors can be prevented from attacking if a node or single credential is compromised.

Motivation

While it is common practice to authenticate messages and actors within a system using passwords or signatures, some highly critical systems that house personal data or handle safety-critical applications may be susceptible to attack if the passwords or signatures are compromised. If an actor’s credentials are compromised, then it is possible to inject false information into a system, steal private data and modify data. In a VANET, if a given node or a vehicle within a smart infrastructure is compromised or an address/signature of the node is replicated (spoofed), the other vehicles in the VANET may be susceptible to a variety of attacks. As an example, in a Sybil attack where a single node sends a message from many fabricated or comprised addresses, applications such as those detecting traffic jams may incorrectly divert other vehicles away from a section of road even though the messages originate from one node [61]. The inability to authenticate these addresses as real vehicles or smart infrastructure could lead to critical safety applications from functioning correctly.

Properties

The Multi-factor Authentication can be used to satisfy the Authentication property, and the Confidentiality property.

Applicability

Multi-factor Authentication is applicable to the prevention of an attack.

Structure

The Multi-factor Authentication structure of a system can be captured in terms of their relationships (Figure 15). An entity requesting access is captured by a Subject object. The entity secured with a Multi-factor Authentication is represented as a Protected Object. The interface between the two objects is a Checkpoint object. The Checkpoint makes use of multiple Authenticators to obtain Credentials from a subject.

Figure 15

Class diagram for Multi-Factor Authentication Pattern.

Participants

The following section describes the participating classes in the pattern structure.

• Subject

  • –

    An actor requesting to access to a Protected Object.

• Protected Object

  • –

    The intended protected object. The entity protected through an authentication Checkpoint.

• Credential

  • –

    Some identifying secret required to access a Protected Object.

• Checkpoint

  • –

    The interface through which all communication with a Service is achieved, and where the Blacklist is checked.

• Authenticator

  • –

    Object tasked with retrieving a credential from a Protected Object.

Collaborations

A given Subject will attempt to communicate with a Protected Object through a Checkpoint. Consequently, there is an association between both the Protected Object and the Checkpoint and the Subject and the Checkpoint which acts as the interface. There is also an association between a Checkpoint and the multiple Authenticators associated with it. A given Authenticator is associated with a Subject which in turn is associated with several Credentials.

Behavior

By enforcing the Multi-factor Authentication pattern, a potential attacker is less likely to compromise an actor within a system as obtaining a single credential will not guarantee access to the actor (see Figure 16). Moreover, other nodes that may communicate with a compromised node are less likely to incorrectly validate spoofed messages given an extra level of authentication. Multi-factor Authentication is used in many web applications where a user is required to enter a password to log in as well as another authentication measure such as a security question the user would know, or a code sent to the user in a separate application such as SMS. In the example given previously, the use of another authenticating measure besides the address of a node would place a greater burden on the attacker using fabricated addresses. The Multi-factor Authentication strengthens an actor’s resilience to compromise by strengthening authentication capabilities, and consequently the system’s ability to promote integrity and privacy.

Figure 16

Sequence diagram for Multi-Factor Authentication Pattern.

Constraints

Automotive systems are limited in the amount of resources that can be provided. By requiring more overhead to authenticate Subjects, resources critical to safety may be affected. Furthermore, in VANET applications where an increased amount of nodes participating improves data collection and ability to route messages, adding additional authentication may prove challenging for some harmless nodes resulting in decreased participation.

Consequences

Table 10 describes how the Multi-factor Authentication pattern affects the following system characteristics.

Known Uses

In the given example of the Sybil attack on a VANET, where a single compromised node can fabricate many messages that appear to be from many nodes[61], a proposed solution to detecting the fabrication through the use of multiple points of message authentication has been developed [62]. Here, researchers propose the use of a GPS as a second form of authenticating a message from a given address. If a single node sends many messages with different addresses, then other nodes will be able to see the messages all originating from one node, implying a Sybil attack.

Relevant Security Principles

The Multi-factor Authentication pattern promotes the principles of Practicing Defense in Depth, Compartmentalization, and Being Reluctant to Trust.

Related Patterns

The Multi-factor Authentication pattern is related to the Authenticator and can make use of the Credential [7].

Intent

Symmetric Encryption is used to encrypt messages so that only a sender and receiver can read the contents.

Motivation

Applications that communicate with external entities may send information that needs to be protected from unintended recipients [7]. In an automotive system that communicates with external entities, such as in a VANET where a vehicle can be communicating with other vehicles and infrastructure, the inability to accept and process only authentic messages may leave a system susceptible to spoofing and dDoS attacks [3]. In the case of the LESPP system, researchers seek to mitigate the authentication and privacy preservation challenges facing VANETs [49]. As it pertains to SAE J3061 [11], the use of Symmetric Encryption aligns with the principles of protecting personal identifiable information and sensitive data. The implementation of the pattern also aligns with the Viega and McGraw principles of promoting privacy and being reluctant to trust [15].

Properties

The Symmetric Encryption can be used to satisfy the Confidentiality property.

Applicability

The pattern is applicable to attack Prevention.

Structure

Both the Sender and Receiver have a Key that allows them to decipher a sent Message (Figure 17). A Sender will give its Key and the Message to an Encryptor object which will use an Algorithm to encrypt the Message. The receiver will give its key and the Encrypted Message to the Decryptor to obtain the original Message.

Figure 17

Class diagram for Symmetric Encryption Pattern.

Participants

• Principal

  • –

    Main actor that may send and receive messages. Can be defined by either of the inheriting classes Sender and Receiver.

• Key

  • –

    Cryptographic key used by the Principal to encrypt and decrypt a message

• Message

  • –

    The information to be sent and received. Has inheriting class Encrypted Message which is the resulting message after a Message undergoes encryption.

• Encryptor

  • –

    Uses a Message and the Sender’s Key to create an Encrypted Message. Leverages the Algorithm Object.

• Decryptor

  • Uses an Encrypted Message and the Receiver’s Key to decrypt an Encrypted Message. Leverages the Algorithm Object.

• Algorithm

  • –

    Given a Message and a Key, either decrypts an Encrypted Message or encrypts a Message.

Collaborations

A Principal has a Key, Messages, and Encrypted Messages. The specialized Principal Sender has Encryptors and the specialized Principal Receiver has Decryptors. A given Message can have up to one associated Encrypted Messages. A Message has one associated Decryptor and one associated Encryptor, thus maintaining consistency in the type of encryption and decryption techniques used. Similarly the Encryptors and Decryptors are associated with a single Algorithm.

Behavior

In the case of sending a Message, a Sender will send a message and Key to a Encryptor (Figure 18). The Encryptor will send the information along to the Algorithm to encrypt. The Encryptor can then create the Encrypted Message object and return it to the Sender.

Figure 18

Sequence diagram for Symmetric Encryption Pattern.

Constraints

In an automotive system where constraints exist on real-time processing and resources, performing the algorithms used in cryptography can be costly in terms of overall system performance. Moreover, overhead is incurred when processing messages to ensure authenticity or to decrypt. In the case of LESPP, computation overhead is reduced by 41.33–77.6% compared to existing public key infrastructures and in simulations, the authors show nearly 0 ms network delay [49].

Consequences

Table 11 describes the consequences of using the Symmetric Encryption pattern.

Known Uses

As described above, the use of symmetric cryptography has been used in the LESPP system described by Wang et al. [49]. By verifying a signature on messages sent over a VANET, LESPP can avoid DDOS and spoofing attacks from unauthenticated nodes.

Supported Principles

Symmetric Encryption supports Principle 7 (Promoting Privacy) as well as Principle 9 (Be Reluctant to Trust).

Related Security Patterns

The pattern is related to Asymmetric Encryption and Digital Signatures [7].

Intent

The Third-Party Validation pattern is intended to provide validation of messages broadcasted in a given network. If a spoofed message is sent to a node and the receiving node cannot validate the message with a trusted node somewhere else in the network, then the receiving node can disregard the message.

Motivation

In many networks that rely on messages being propagated to other nodes, there is concern that a compromised node may alter the message or inject a false message. This type of attack is known as a Masquerading Attack that can lead to fabrication, alteration, and replay attacks [37]. In a VANET, many applications, such as an application that reports traffic jams to other vehicles within the VANET, rely on nodes reporting on current conditions as they perceive them and propagating the messages of the nodes around the VANET to create a consensus for the road conditions. If compromised nodes in the VANET send falsified information to another node in the network, the automotive system could behave in an inappropriate manner and jeopardize safety [37].

Properties

The Third-Party Validation can be used to satisfy the Integrity property, and the Authentication property.

Applicability

Third-Party Validation is applicable to Detection and Mitigation.

Structure

The Third-Party Validation structure of a system can be captured in terms of their relationships (Figure 19). An entity broadcasting a Message is captured by a Sender object. Both the TrustedNode and Receiver actively listen and receive messages on a broadcast network.

Figure 19

Class diagram for Third-Party Validation Pattern.

Participants

The following section describes the participating classes in the pattern structure.

• Sender

  • –

    Broadcasts a given Message.

• Receiver

  • Listens on a network for a broadcasted Message.

• TrustedNode

  • Listens on a network for a broadcasted Message. Responds to verification requests from Receivers

• Message

  • Unit of communication over the network.

Collaborations

A given Sender broadcasts a Message on a network, creating an association with the Message. Meanwhile, the other nodes on the network (Receivers and TrustedNodes) listen for Messages, creating associations with the Messages. Every given Receiver node has a one or more TrustedNodes used for verification.

Behavior

The Third-Party Validation pattern seeks to solve the concerns pertaining to integrity by obtaining information from more than one source. Importantly, if there are more trusted nodes within a network that are more secure, they can be leveraged for performing the validation and thus providing a more robust validation scheme. In the case of an application on a VANET, information received by a node can be compared to information received by some other node(s) in the network. If the information is not within some degree of similarity, then the information can be disregarded (see Figure 20).

Figure 20

Sequence diagram for Third-Party Validation Pattern.

Constraints

Many automotive systems must function in real-time environments to ensure safety. In the context of Third-Party Validation, adding additional overhead in the verification steps of message processing could add an unacceptable degree of delay.

Consequences

Table 12 describes how theThird-Party Validation pattern affects the following system characteristics.

Known Uses

In a proposed solution by Gillani et al. [37], when a node receives a message in a VANET, the node notifies a Road Side Unit (RSU) and requests to check the message correctness. The RSU will contact the RSU closest to the sending node to validate that the message was actually sent, and not spoofed or modified in transit.

Relevant Security Principles

Principles related to the Third-Party Validation pattern include Promoting Privacy, and Being Reluctant to Trust.

Related Patterns

This pattern is related to the Enrolling Using Third-Party Validation pattern described by [19].