Examples - SmartGrid-related case studies

In the area of SmartGrid, we modeled three scenarios:

• An application that sells normal and special offers, which is published in A Toolchain for Designing and Testing Access Control Policies
• A SmartGrid Bonus application that can show a bonus code after an offer is bought, which is published in Modeling, Enforcing and Testing Secure Navigation Paths for Web Applications.
• The EMS (Energy Management System), which is an appliance that manages energy in a household. This case study is described in the following.

These examples are available as mdzip files for Magic Draw 18.0, using the UWE Profile v3.0: Smart Grid Offers, Smart Grid Bonus application and the Smart Grid EMS, which is described in the following.

EMS Case Study

Environment and Requirements

This section describes the Energy Management System (EMS) case study and in particular the web application of the EMS that controls Smart Homes, which are households with interconnected appliances. We start by introducing Smart Home components, continue by presenting actors and conclude by explaining concrete functionality, before we go into more security-related details in the next section.

Components of Smart Homes

Generally, the EMS is an interface for the SmartGrid customer that displays consumption data. Concrete instantiations can be realized by an application that provides functionality for energy trading or for regulating the current drain. Ideally, most appliances, as e.g., ovens, dishwashers, washing machines or lamps are so-called Smart Appliances (SAs), which means they contain a small embedded-system that receives control commands from the EMS and that informs the EMS about the current status. Additionally, SAs can be controlled by pushing a button or by using an integrated touch screen.

For a household, exactly one EMS and one Smart Meter are installed locally, in a place where they are protected from physical tampering. The Smart Meter is responsible for monitoring the amount of energy that is sold or bought. As the EMS is connected to the web, remote access to its web application allows users to interact with the EMS and to monitor energy consumption from outside their homes.

A possibility to control energy consumption more globally is Demand Side Management. It envisions adapting the consumption level according to messages sent by energy providers. For example, in situations when lots of energy is needed in an area, the energy provider notifies all Energy Management Systems. Consequently, the EMS can send command messages to SAs in order to turn them off. The concrete behavior when receiving a Demand Side Management message can be controlled by user defined policies in the EMS.

Actors

According to the NESSoS project, the prosumer (producer / consumer) is the end customer, who is consuming energy as well as producing energy, e.g., by using photovoltaic or wind energy as decentralized energy resources. Prosumers are also able to store energy, for instance in the batteries of the electric vehicle and to resell the energy later to the so-called microgrid when the prices are higher. We also refer to the prosumer simply as "(private) user" or "customer".

Figure 1 depicts a UML use case diagram, which gives an overview of the actors in our case study and the main functionalities of the EMS. On the left, the private user is shown. Users can create and configure other users, e.g., under-aged family members can be allowed to sign into the EMS web application and to see their energy consumption, but they should not be able to trigger electricity vending or purchasing functions. On the right, the Meter Point Operator (MPO) is depicted, who is responsible for installing, maintaining or replacing the EMS as well as the Smart Meter. The tasks of the MPO are not considered in our case study.

Figure 1 Requirements Overview

Functionality

The main functionalities of the EMS are depicted in Figure 1: a user can buy or sell energy, control local energy consumption by configuring SAs, install plugins to automate tasks or manage other users. These use cases are described in more detail in the following.

Local Energy Control

As more and more Smart Appliances will be added to the home network, their heterogeneous functionality has to be made available to the customer. The EMS web application can present, in a uniform way, a coherent view to the user in the form of a portal, presenting information that the EMS has collected from diverse sources (appliances or external servers). SAs, even new ones that were non-existent when the web application was programmed and deployed, offer their services through a standard interface to the EMS (cf. lower half of Figure 2, use case InteractWithSA, depicted in bold font because it might be used relatively often). Hereby, auto-configuration (in the sense of plug-and-play support) is important, as many customers may not become acquainted with the full potential of the EMS. This case applies particularly to senior citizens.

Figure 2 Requirements of local energy control

Easy access to real-time information supports the users, e.g., to pay attention to their energy consumption, as depicted at the top of Figure 2. Additionally, automatic peak load management provides smart planning for reducing energy consumption. This Smart Planning feature (cf. Configure Smart Planning Policy) can be enriched by plugins, which have to be installed separately. Plugins might also be allowed to access the local usage history from SAs. This way they can base their plan on previous user's behavior. For example, hydronic heating might be reduced automatically at times where usually no great quantity of hot water is needed.

Energy Trading

Selling and buying energy is a critical task, if the user wants the system to perform a trade automatically. Consequently, policies have to ensure that the system acts in the interest of the prosumer. As depicted in Figure 3, the recommendation / trade system can also be enriched by plugins, offering so-called value added services. A value added service, such as a price comparing third party service (e.g., when and who is offering the best conditions for green energy?) works as follows: The third party provides a plugin that obtains current market prices from the third party's server. The plugin compares prices and consumption data locally. The result of the comparison can either be a visual notification in the EMS or a process is started to renegotiate Energy Supplier contracts, in case the prosumer has allowed automatic negotiation. In the latter case, a notification is sent to the user after the (un-)successful provider change.

Figure 3 Requirements of the energy trading system

Plugin Management

As mentioned before, a key functionality is the interplay of the EMS and value added services. Third parties can offer plugins that can be deployed into the EMS to provide further functionality (cf. Figure 4). Plugins are limited, sandboxed algorithms that can enhance the EMS at two predefined interfaces: the interface for smart planning (see local energy control) and/or the interface for energy trading.

Figure 4 Requirements of the plugin management

The customer accesses the EMS as a central administration point. No process should demand direct interaction between the customer and an external third party service. Users can only search for plugins, (un)install or update them (if not done automatically) or access a privacy dashboard for plugins. The dashboard allows the user to restrict personal information a plugin can access and functions it can execute.

User Management

Prosumers can allow other persons to log into the web application by creating an account for them, as depicted in Figure 5. However, not all users have to have the same rights. More details about access control and other security features are given in the next section. Additionally, more comprehensive descriptions of general smart grid functional requirements can be found in NESSoS deliverable D11.2.

Figure 5 Requirements of the user management

Securing the EMS Web Application

This section introduces security features of the EMS, i.e., authentication, panic mode, reauthentication, secure connections, authorization, user zone concept, cross-site-request-forgery prevention, under attack mode and SQL-injection prevention (cf. our SecWAO ontology).

Implementing coherent authentication is a challenge, as users must be able to log-in to their EMS internally, from their home, and externally, using a mobile device, or a public terminal. A two-factor authentication should be employed to access sensitive information of the EMS. Two-factor authentication requires a knowledge factor ("something only the user knows") and either a possession factor ("something only the user has") or an inherence factor ("something only the user is") from the user for the authentication to succeed. For example, a password has to be entered together with a code that the user's smart phone generates.

A feature rarely implemented in current web applications, is the panic mode. When the panic mode is activated, the user interface will be displayed with reasonable information generated by the EMS that does not reflect the user's real information. This is especially needed for coercion situations, where criminals might physically force users to reveal information of themselves or to conclude long-term contracts with certain parties. The panic mode also protects threatened users by pretending to malfunction or to execute functions successfully without any real impact. Therefore, users have to authenticate themselves with predefined credentials which differ from the usual ones: using the same username in combination with a panic mode password loads the alternative user interface.

Besides the first authentication, prosumers can be forced to reauthenticate themselves. This is often the case after a certain time of inactivity (often referred to as "automatic logout" in online banking applications), but it is also common for critical areas. For example, web shops often allow to store cookies to keep the user authenticated while browsing their offers. However, if the last authentication is older than a certain amount of time, the users have to reauthenticate themselves before being able to make a purchase. Regarding the EMS plugin installation functions, the last authentication of a prosumer should not be older than 10 minutes, a typical time threshold also used in online banking. The timeout avoids a takeover of a session by another person who has access to the prosumers browser.

All kinds of authentication are useless, if the login process can be eavesdropped. Secure connections, as e.g., TLS connections can be used to ensure the confidentiality, integrity and freshness of all user's request as well as of all response of the EMS. As encrypting a connection is a time consuming task, it is an important design decision which parts of an application should be secured. In the case of Energy Management, security weights more than speed, even if Demand Side Management and energy trading are very time demanding. Compromises in speed can have impact on economic aspects, but compromises in security could mean a total blackout of the power supply, producing high economic damages.

Apart from secure session management after authentication, a well implemented authorization (access control) concept is needed to satisfy customer needs. There are several roles to be considered, as family members might be involved in the customization of the Smart Home.

Many web applications require a user zone concept. If users are accessing the EMS from the home area, they are permitted to access all prosumer managing functions (depending on their roles). But if they are requesting access externally, stricter policies have to be enforced, depending on the requester's location, i.e. the IP address of the requester's device. To configure this policy, users inform their MPO that they are on holiday and that a certain location is the source of legitimate requests.

A telling example is an attack from a foreign country. An attacker that is mimicking a user will, by policy enforcement, be denied to alter the Smart Appliances' behavior, if he is accessing the EMS remotely from a very far place. This feature will not hold up against versatile attackers, as several proxies or even computers that have been compromised by an attacker, could be available in the desired geo-location. Still, this mechanism represents a filter against unambitious attackers. There are several other mature attacks on web based technologies that also could have an impact on the EMS, mostly related to so-called "common web application vulnerabilities". As the EMS is remotely accessible by means of a web client, there is room for session riding attacks. Depending on the user's browsing application, cross-site-request-forgery (abbreviated "CSRF") might be used by a malicious attacker to trigger actions without the user's consent. For example, an attacker could trick users into interacting with the web server of a Smart Appliance by letting them call an address like: http://EMSremoteIP.com/SmartApplianceName/SmartApplianceFunction This request cannot be called by an unauthorized person due to the policy enforcement inside the EMS, but it can be triggered by means of CSRF.

The under attack mode is a dynamic protection against attempts of compromising the EMS functionality, as the EMS reacts accordingly and reduces the attackers possibilities. An example is the reduced functionality when under denial of service attack. The EMS will try to reduce the number of allowed connections and/or deny any connection from IPs that have exceeded a certain number of requests in a certain time frame. Additionally, CAPTCHA-challenges could be displayed to verify that the requester is a person and not merely a program.

Another feature is the protection of the EMS database. The EMS database should only accept statements that have been generated by the EMS itself. In order to avoid SQL-injection attacks within generated statements, parameterized queries should be used.

Finally, secure downloads are needed for firmware updates from the MPO and for downloading bills from an Energy Supplier. The document representing the bill should be available in the trading system and prosumers should be able to download the bill so that its integrity is preserved. Naturally, confidentiality and integrity are required for the bill's storage.

Modeling the EMS with UWE

This section shows how to model security features of the EMS with UWE model elements. It is structured according to the UWE model types, i.e., the views on the web application.

Content View

When modeling larger systems, such as the EMS web application, it is useful to divide the system into manageably small components. The main characteristic of components is encapsulation, which means that components can only share information using predefined interfaces. Encapsulation is advantageous, because each component can be implemented and tested individually. Regarding modeling, components contribute to a clear structure, as the division of tasks within an application becomes apparent. Consequently, it is easy to define appropriate security properties for each part of a web application.

Figure 6 Content model

In the case of our EMS, a component EMScore is created, which contains components that are built into the EMS system by default, as depicted in the class diagram shown in Figure 6. Smart Appliances (SAs) can communicate with the EMS using the SA interface, shown on the lower left. According to the description in the previous section, plugins are also external components that can enhance the smart planning or the trader / recommender. Some plugins might provide both functionalities (as e.g., PluginA does).

The EMScore contains four internal components that correspond to the main areas we identified in the requirements phase (cf. Figure 1): local energy control, user management, energy trade system and plugin management. As can be seen in Figure 6, the user manager is used by all components, because the system does not allow access without having granted permission first. The interface PluginList publishes the list of installed plugins within the system so that the user can advise the internal components to exchange the planning or trading plugin.

As far as security is concerned, the UWE profile redefines the UML stereotype «component» with the following tags that have been defined in UWE:

• {csrfPrevention} models how CSRF should be repelled. The modeler can choose from the options presented at the OWASP CSRF Cheat Sheet. For the EMS example the most common "Synchronizer Token Pattern" is used, which includes a randomly generated challenge token to all server requests in a web page. An attacker cannot hope to guess a valid token when sending the user a prepared URL.
• {sqlInjPrevention} documents how SQL injection attacks are prevented. In most programming languages, SQL prepared statements shield from SQL injection, but other solutions, as e.g., server-sided stored procedures could also be used.
• {inputValidation explains how the component is shielded from unvalidated input. The most secure way is to whitelist characters and not to accept anything else. In a later phase of development, it could be useful to use this tag for documenting the concrete technique which is used, e.g., a software library.

The tag {usedInStates} is used to denote in which state of the application a certain component is used. Note that it is the modelers' decision which of the features offered by the UWE profile they like to use in a diagram. In some scenarios, the modelers may decide to connect the UWE Navigation model with the Content model using {usedInStates}, in others not.

Figure 7 Content model - bills

Figure 7 exemplarily depicts the storage and the download of a bill, using UWE's «storage» tag on a UML comment and the «file» stereotype to specify that a bill can be downloaded, but only over a secure connection that preserves integrity, as e.g., TLS.

Role and Access Control View

Figure 8 depicts the role model of the EMS. The stereotype «webUser» defines the class that represents a user. It can later be referred to as caller when defining access control. Per default, the DefaultUser plays all roles.

Figure 8 Role model

Figure 9.1 depicts a dynamic view, i.e., individual access control specified by the users themselves. In the EMS system, a user can update or delete an instance of User, as long as it is not the current user. This is expressed by a UML comment that is stereotyped by «authorizationConstraint» and that contains the expression pre: self <> caller. "Self" refers to an instance of the constrained element, like the User class, whereas "caller" refers to the instance of the subject that wants to execute an action. "Pre:" can be used to stress that the expression has to be true before an action is executed.

Figure 9.1 Basic Rights model excerpt and Application States model

Figure 9.2 shows an excerpt of the static Basic Rights model. For example, someone with the role UserManager is allowed to «delete» users, as long as the «authorizationConstraint», which has to be specified in OCL, is fulfilled. The constraint defines that the user instance (referred to as self) is not equal to the caller (referring to the «webUser» who executes this deletion). If the constraint would not be given, users might delete their own accounts accidentally.

Figure 9.2 Basic Rights model excerpt and Application States model

Regarding our security requirements, the UWE Basic Rights model has to be extended to enable the specification of different modes. Therefore, the tags {accessibleInAppModes} and {notAccessibleInAppModes} are added. They allow to choose from a set of states in which a functionality should (not) be available. Please note that these states do not refer to navigational states, but general states of an application. When modeling with a CASE tool aa MagicDraw, the UWE profile with its typed tags makes sure that the value for the tag can only be chosen from all available states that are stereotyped by «appMode». As depicted at the bottom of Figure 9.2, the EMS only allows the installation of plugins when it is not under attack.

Navigation and Process View

User navigation is one of the most distinguished web features. UML state charts are used in UWE to express the navigation possibilities a user has within a certain state of the web application. By default, all states in the UWE navigation model are thought to be stereotyped «navigationalNode». The {isHome} tag refers to the entry point of a web application (cf. Figure 10).

Figure 10 Navigation model overview

The stereotype «integratedMenu» is defined to be a shortcut for showing menu items for all menus of Submachine States, in case the user is allowed to access them (cf. Modeling Secure Navigation in Web Information Systems). Submachine states contain a state machine by themselves, so that more details can be shown in another diagram. Note that transitions that start at the border of a state, leave the state and enter again when triggered. Navigational access control can be specified using a rolesExpression as "caller.roles.includes(PluginManager)".

As shown on the left in Figure 10, a UWE pattern is used for the specification of 2-step authentication. The UWE profile includes such kind of patterns to reduce the amount of modeling effort. In case a pattern should be adapted, it can easily be copied from the profile to the model.

Additionally, we decided to include more implementation-specific details in the navigation model, which are relevant in the late design phase. Thus, HSTS is specified as web security policy mechanism to ensure secure https connections for the whole web application, indicated by the «session»-related tag {transmissionType=HSTS}.

If needed, activity diagrams can be added to detail the process that is executed behind the scenes. For example, Figure 11 depicts what happens internally after the login was completed successfully. For our EMS, this gives a hint to implement the panic mode as well as the restricted access, when accessing the EMS from a distant region.

Figure 11 Process after successful login

Exemplarily, the submachine state diagram of the plugin management is shown in Figure 12. The stereotype «search» denotes that a search is done when using the searchPlugins transition, as searching is a typical process in applications. The stereotype «collection» refers to a list of elements with the given {itemType} tag from the Content model. For transitions, an underscore can be used to denote an element of this type. In our example, the underscore is an abbreviation for p:Plugin.

Figure 12 Navigation model for plugin management

The UWE profile provides a new tag called {reauth} for the stereotype «session» to specify critical areas. In those areas, as e.g., for plugin management, users have to reauthenticate themselves, except when the previous login is not older than the given amount of time. In addition, the tag {notAccessibleInAppModes} is specified for the stereotype «navigationalNode». In our example, this prevents navigating to the interface for (un)installing or updating plugins in the UnderAttack mode.