In addition, if the first priority applications are safety-critical applications, then SeReCP sustains the required availability for up to 50% failures for these applications despite the second and the third priority cases shutting down after 30% failures.
Discussion:In our evaluation, we assess our approach for its ability to provide the re-quired availability for real-time SG applications during the DDoS attack on the pub-sub brokers. We compare our approach with [SK05], which is also proposed to protect the E2E connection of real-time application from DDoS attacks. Firstly, we evaluate our ap-proach in terms of its additional latency and overhead. The results denote that SeReCP’s additional overhead and latency is reasonable for most SG applications. It is worth high-lighting that, although the latency results, obtained the actual Internet infrastructure, are reasonable for most SG application, the ISP connections of the end hosts significantly af-fect the latency. Secondly, we evaluate the normalized throughput of SeReCP and [SK05]
for real time applications. Without duplicate packets, whereas SeReCP can protect the E2E communication up to 30% failure, the connection stalls after 5% failure in [SK05]. This shows that SeReCP preserves the E2E communication even without duplicate packets up to 30% failures. With duplicate packets, SeReCP can maintain the same performance up to 50% failures. In the third evaluation, by employing different duplicate packet rates depending on SG applications’ "priority", while SeReCP can provide the required avail-ability for middle and low "priority" SG applications up to 30% failures, it provides the
required availability for high "priority" appications up to 50% failure. If we consider pub-sub brokers size comparable to a typical Akamai setting (ca. 2500 nodes) [SK05], an attacker coordinating around 1,300,000 zombies can bring down 30% of access brokers.
However, this volume of attacks are a small percentage of the DDoS attacks experienced in the past. Even in this situation, SeReCP can provide the required availability for high priority (safety critical) applications despite the failure of the low and middle priority ones. This substantiates SeReCP to be a promising approach to make the public network usable for SG applications in a secure and reliable manner.
65
Chapter 6
Securing the Cloud-Assisted Smart Grid
To manage millions of SG devices and to handle large amounts of data in a reliable, scal-able, and cost-effective way, the SG utilities increasingly extend their communication-based management system to the advocated cloud computing platform. These cloud platforms enable reliable and on-demand access to varied computing resources [BI14;
BMR15]. Despite the advantages of the cloud, its usage of the public network and shared resources can expose the SG to security risks considering both the cyber and physical sys-tems, e.g., power grid/appliances. In particular, DDoS attacks represent a major threat to the SG applications running in the cloud, considering SG applications’ stringent latency requirements (in the range of 100 ms to 5 s) and reliability requirements (99.00 %–99.99%) [BI14].
As availability constitutes a safety property for SG applications (especially for con-trol functions), deploying proactive defense mechanisms becomes indispensable for SG communication. Proactive defense mechanisms, e.g., moving/hiding the target [Sta+05;
FPT12; Jia+14; DS17b], are introduced as countermeasures increasing the cost placed on the attacker to overwhelm the victim’s resources. However, since these proactive defense mechanisms are mainly designed to mitigate DDoS attacks in typical web applications, they are not suitable for the SG applications’ context due to the SG specific requirements of high availability and responsiveness [SK05].
To fill this gap, we propose a hybrid hierarchical cloud-extension concept (HHCEC), which is a SG-relevant cloud-assisted architecture. HHCEC provides ultra-high respon-siveness and security with its (a) hybrid and geographically dispersed structure, and (b) specialized broker-based publish-subscribe communication system. Second, we propose a novel approach termed Port Hopping Spread Spectrum (PHSS), which acts as a strong defense against transport and application layers DDoS attacks, as well as the volume-based DoS/DDoS attacks, against the broker servers. PHSS is equipped with two distinc-tive features: (1)port hopping, changing the open port of the broker server as a function of the time and a secret shared between the broker server and the publishers1, and (2)packet spreading, diffusing consecutive data packets over a number of broker servers versus a single broker server. This approach enables PHSS to instantiate replica broker servers to take over the attacked broker servers without blocking all traffic by taking advantage of the rapid-elasticity characteristic of the cloud.
1The terms client/publisher and server/broker are interchangeably used in the rest of the chapter. In addition, while every SG device/application server can be a publisher and/or subscriber, the brokers are dedicated servers for their respective roles.
The existingport hoppingapproaches assume that the secret (a cryptographic seed), if compromised, can be renewed by an Authorization Server using a public key-based re-keying approach, which requires high unaffordable computation complexities for differ-ent SG differ-entities (cf. [LT04; FPT12]). Moreover, when using public key-based approaches, if the secret is compromised, the adversary can mount an attack on the broker to render inaccessible them. In such cases, the broker servers become unavailable for all publishers during the re-keying process, which in turn severely impacts the SG applications’ service provision. Accordingly, an efficient reactive mechanism is highly necessary in order to minimize the impact of DDoS attacks against the open ports of broker servers, as a result of compromising the secret.
To address this issue, we introduce (1) a token-based authentication mechanismthat al-lows for a light-weight periodic transmission of the secret to each client (publisher), and (2)a shuffling-based containment mechanismthat quarantinesmalicious clients, without ren-dering the attacked broker server inaccessible. To do this, the containment mechanism repositions/shuffles the clients over the ports of the broker server with a negligible over-head.
To assess the efficiency of the proposed approach, we construct a proof-of-concept prototype using EC2-micro instance [Ama16] and the PlanetLab (http://planet-lab.org) test-bed. We evaluate PHSS’s effectiveness in providing network availability by using the shuffling-based containment mechanism against DDoS attacks using the compromised secret. We also compare our approach with the public key-based re-keying method used by the existingport hoppingmechanisms. Our results show that by containing the impact of the DDoS attack using the compromised secret in a notably shorter time period, PHSS provides high network availability of over 98% during the attack versus the typical ˜60%
availability achieved by using the public key-based re-keying method. Furthermore, af-ter assessing the overhead (in af-terms of broker server throughput and response latency), the experimental results show that our proposed mechanism causes neither significant throughput degradation (i.e. <0.01% throughput degradation) nor additional latency. To summarize, our contributions are:
• A SG-relevant cloud extension, termed HHCEC, which utilizes a hybrid and geo-graphically dispersed structure to meet the responsiveness and reliability require-ments of SG applications.
• A strong proactive DDoS attack defense mechanism, called PHSS, which dynam-ically changes the open ports of the broker servers to efficiently drop the invalid packets in the firewall. Furthermore, PHSS diffuses consecutive data packets over a number of servers versus a single server in order to rapidly recover the attacked system in the cloud.
• A token-based authentication mechanism to prevent secrets from being compro-mised, as well asa shuffling-based containment mechanism to contain the damage of the DDoS attack utilizing the compromised secret in a shorter time.
• A proof-of-concept platform using Amazon’s EC2 [Ama16] and PlanetLab nodes to evaluate our approach in terms of the availability of service provision for the SG applications over DDoS attacks and the overhead imposed by our approach.
6.1. Models, Goals and Assumptions 67
Layer 3, Public Cloud
IaaS, PaaS, SaaS
IaaS System Administrator
& Authorization Server
SG Devices (Publishers/Subscribers)
SG Applications (Publishers/Subscribers) SG Applications (Publishers/Subscribers)
Layer 2, Private Cloud
...
Layer 1, Broker Bundles
...
SG Application ServersBroker Servers