journal homepage: www.elsevier.com/locate/infosys

http://dx.doi.org/10.1016/j.is.2015.01.0070306-4379/& 2015 Elsevier Ltd. All rights reserved.

n Corresponding author. Tel.: þ82 2 3408 3840.E-mail addresses: blee@oakland.edu (B. Lee), kim2@oakland.edu (D.-K. Kim), hsyang@sejong.ac.kr (H. Yang), hyuks.jang@gma

Contents lists available at ScienceDirect

Information Systems

Information Systems 53 (2015) 237–249

Role-based access control for substation automation systemsusing XACML

Byunghun Lee a, Dae-Kyoo Kim a, Hyosik Yang b,n, Hyuksoo Jang c

a Department of Computer Science and Engineering, Oakland University, Rochester, MI 48309, United Statesb Department of Computer Engineering, Sejong University, Seoul, South Koreac Department of Computer Engineering, Myongji University, Yongin, South Korea

a r t i c l e i n f o

Available online 30 January 2015

Keywords:RBACSmart gridSubstation automationXACML

a b s t r a c t

There has been an increasing need for accessing data of internal equipment and devices of asubstation system from external systems as power grids evolve. This has also introducedgrowing concerns on data security. In response to the concerns, IEC 62351 has proposedrole-based access control (RBAC) for substation automation. In this work, we present anovel approach for implementing RBAC based on IEC 62351 for substation automationusing eXtensible Access Control Markup Language (XACML). We integrate the approachwith IEC 61850 by extending Abstract Communication Service Interface (ACSI), Manufac-turing Message Specification (MMS), and System Configuration Language (SCL). A majoradvantage of the approach is that it fully conforms to both IEC 61850 and IEC 62351 andhighly compatible with SCL as both XACML and SCL are XML-based. We implement theapproach using OpenIEC61850 which is an open source library for ACSI services anddemonstrate the implementation.

& 2015 Elsevier Ltd. All rights reserved.

1. Introduction

A smart grid is an advanced electrical grid for improved efficiency, reliability, and sustainability of power generation,transmission, and distribution. A key success factor in a smart grid is data collection and analysis which are the basis fordetermining efficient use of power. There has been a growing concern on data security as smart grids gain more attentions. Inparticular, the substation domain, which has been traditionally considered as a closed domain, is now faced to be open toshare the data of internal equipment and devices (e.g., IEDs) with external systems such as SCADA and EMSs. Accordingly,security concerns on data access of internal equipment and devices in a substation have been raised.

IEC 61850 [1] defines classes (data objects) and services needed for substation automation. It covers a wide range ofaspects from substation functions to network performance and its application has been expanding to other domains such asDistributed Energy Resources (DERs) and Electric Vehicles (EVs). As the application of IEC 61850 expands, security concernson data access have gained a great attention. While the current version of IEC 61850 addresses authentication of data transferthrough digital signatures, it does not address authorization which is critical for data confidential and integrity. In response tothis, IEC 62351 [2], a standard for substation security by WG15 of IEC TC 57, has proposed RBAC for substation automationstandardized by IEC 61850 [1]. However, RBAC in IEC 62351 has not been demonstrated for its implementability.

il.com (H. Jang).

Station Bus

IED(e.g., prot) IED

Local HMI

MU

IED

IED(e.g., actuator)

Prosess Level

Station Level

Bay Level

Process Bus

Fig. 1. IEC 61850 network.

B. Lee et al. / Information Systems 53 (2015) 237–249238

There has been some work on access control for substation systems (e.g., [3–5]). Some work uses an RBAC proxy and otherwork uses distributed or spatial RBAC. However, the RBAC models used in the existing work are not compliant to IEC 62351using a non-standardized language for describing RBAC, which may cause interoperability issues among involved systems. Inaddition, the existing approaches are mostly conceptual and it is not clear how they can be actually implemented.

In this work, we present a novel approach for implementing RBAC based on IEC 62351 using XACML [6,7], a standardlanguage for describing access control policies for substation automation systems based on IEC 61850. In the approach, weextend ACSI, MMS, and SCL to support RBAC. We use XACML for describing RBAC policies and managing access requests andresponses. The approach is implemented using the XACML API developed by Sun and OpenIEC 61850, an open source librarysupporting ACSI services in IEC 61850. The approach is that it fully conforms to both IEC 61850 and IEC 62351 and highlycompatible with SCL as both XACML and SCL are XML-based.

This paper is organized as follows. Section 2 discusses the existing work. Section 3 gives a background on RBAC, IEC 61850,and IEC 62351. Section 4 presents the approach for implementing RBAC in IEC 61850. Section 5 implements the approach.Section 6 evaluates the implementation. Section 7 concludes the paper.

2. Related work

There have been some efforts for applying RBAC to power systems. Wei et al. [3,8] present an RBAC proxy at theapplication level for packet filtering in the substation domain using Distributed Network Protocol 3.0 (DNP3). In their work,RBAC is described in XML and roles are represented as numbers. While XML is a standard language for encoding documents,it does not support describing access control polices. Also, the semantics of a role is usually carried in its name and usingnumbers for role names makes role semantics ambiguous.

Wang et al. [4] propose Distributed RBAC (DRBAC) where RBAC entities are distributed over a network in a substation toreduce authorization loads. In their work, roles can be defined locally or globally. A local role is specific to a substation andthere may be many local roles defined in a substation. A global role is also defined for a specific substation, but it allows aremote user activating the role to acquire all the local roles defined in the substation. However, their approach is onlyconceptual without details of implementation.

Rosic [5] presents location-based RBAC for smart grids. Areas are identified in a grid where each area is givenresponsibilities called areas of responsibility (AOR). Access policies are defined in terms of roles and AORs and access isgranted when both RBAC policies and AOR policies are satisfied. Users are assigned roles and AORs and objects are assignedAORs. A user is allowed to access an object if the user has the AORs of the object. Like Wang et al.'s work, Rosic's work is alsoconceptual without implementation.

Nagarajan and Jensen [9] present a generic RBAC model for wind power systems based on IEC 61400-25 [10] (which is anextension of IEC 61850 for wind turbines) and IEC 62351. They introduce actors and roles for wind power systems and relatethem to the attributes of the wind power turbine class and the wind turbine transformer class for read and write access. Theypresent a prototype implementing the RBAC model in a client–server environment. Unlike their work, our work is based onthe roles and operations defined in Part 8 (work in process) of IEC 62351, which gives solid conformance to the standard. Inimplementation wise, our work uses the standard access control policy language XACML to describe RBAC policies, requests,and responses. This enables to take the advantages of ample technologies (e.g., SUN XACML API [11]) supporting theimplementation of XACML specifications.

3. Background

In this section, we give an overview of IEC 61850 and IEC 62351 which are the base in this work.

3.1. IEC 61850

IEC 61850 is a standard for substation automation systems (SASs), defining data models, services, and communicationrequirements. Communication in IEC 61850 is defined in three levels – Station, Bay, and Process. The Station level involvesHuman–Machine Interfaces (HMIs) responsible for communicating with an external system (e.g., EMSs) through a gateway. Italso involves IEDs at the Bay level responsible for receiving and sending data and control from/to HMIs and other IEDs in the

SCA

IrevreStneilC S

M

CS

SMM

SMM

SM

CS

SCA

I

associaterequest

response

Fig. 2. Client–server communication.

Table 1Mapping of IEC 61850 elements and MMS elements.

IEC 61850classes(MMSobjects)

ACSI services (MMS services)

SERVER (virtualmanufac-turingservice)

GetServerDirectory(GetNameList)

LOGICALDEVICE(domain)

GetLogicalDeviceDirectory(GetNameList)

LOGICAL NODE(namedvariable)

GetLogicalNodeDirectory(GetNameList)

GetAllDataValues (read)

DATA (namedvariable)

GetDataDirectory(GetNameList)GetDataDefinition(GetVariableAccessAttributes)GetDataValues (read)SetDataValues (write)

UserA

Control Reporting DatasetReadView

Viewer Operator Engineer

SelectWithV

alueSelect

Operate

Cancle

CreateD

ataSetD

eleteDataSet

GetD

ataSetDirectory

Report

GetB

RC

BV

aluesSetB

RC

BV

alues

GetLogicalD

eviceDirectory

GetLogicalN

odeDirectory

GetServerD

irectory

GetA

llDataV

aluesG

etDataV

alues

UserB

Operation

Right

User

Role

Fig. 3. IEC 62351 role based access control for IEC 61850.

B. Lee et al. / Information Systems 53 (2015) 237–249 239

Process bus. Communication between IEDs is carried out through Generic Object Oriented Substation Events (GOOSE)messages while communication between an IED and an HMI is carried out via MMS [12] messages. The Process level involvesMerging Units (MUs) responsible for digitizing analog data (e.g., voltage, current) from primary equipment (e.g., currenttransformers, potential transformer) and sending Sampled Values (SVs) to IEDs.

Fig. 1 shows the three-level communicationwith two buses – Station bus and Process bus serving communication between levels.The Station bus is mainly used for communicating MMS messages while the Process bus is used for communicating mostly GOOSEmessages and SVs. Both buses use Local Area Network (LAN). However, the Station bus is used for TCP/IP-based client–servercommunicationwhereas the Process bus is for Ethernet-based publisher–subscriber communication. In this work, we focus on accesscontrol for the Station bus.

ACSI in IEC 61850 defines services (e.g., associate, abort, release) for establishing a client–server connection, setting andgetting values, and controlling. It also defines services (e.g., GetServerDirectory, GetLogicalDeviceDirectory, GetDataSetValues)for accessing data in a data object such as IEDs, logical devices, logical nodes, and data sets. Fig. 2 shows the client–servercommunication in IEC 61850. Both a client and a server are implemented in ACSI and communicate each other via MMS. Tosynchronize the communication, a Specific Communication Service Mapping (SCSM) is defined between ACSI and MMS.

Services

LogicalDevice

Server

LogicalNode

DataObject Control

ReportControl BlockReportGetBRCBValuesSetBRCBValues

DataSetCreateDataSetDeleteDataSetGetDataSetDirectory

GetServerDirectory

GetDataValues

Service

GetLogicalNode−Directory

GetAllDataValues

GetLogicalDevice−Directory

Classes

SelectWithValueSelect

OperateCancel

Classes

Fig. 4. ACSI services associated with IEC 61850 classes.

B. Lee et al. / Information Systems 53 (2015) 237–249240

Table 1 shows a partial SCSM of ACSI and MMS [1]. In the table, for instance, the GetLogicalNodeDirectory service of the LogicalNode class in ACSI is mapped to the GetNameList service of the Named Variable entity in MMS. Note that MMS elements are lessdiverse than IEC 61850 elements, which results in one-to-many mappings. For example, the GetNameList service in MMS is mappedto three services GetServerDirectory, GetLogicalDeviceDirectory, and GetLogicalNodeDirectory of ACSI.

IEC 61850 provides SCL, an XML-based language for describing the configuration of an SAS which specifies the overallstructure of the substation. An SCL specification consists of a header describing revision information of the specification, asubstation section specifying the substation structure, a communication section specifying network configuration (e.g.,network addresses, IED access points), an IED section describing services of IEDs, and a data type template section providingthe list of the data objects used in IEDs. In this work, we extend SCL using an XML name space to support RBAC.

3.2. IEC 62351

IEC 62351 is a standard providing security guidelines for data communication of powers systems based on TC 57 standardsincluding IEC 61850. It addresses confidentiality and authentication for Supervisory Control And Data Acquisition (SCADA)and TCP/IP-based telecontrol protocols (e.g., IEC 60870), secure communication of MMS and GOOSE messages, and RBAC. Inthis work, we focus on RBAC for IEC 61850. Fig. 3 shows RBAC entities (users, roles, rights, operations) and their relationships[2]. In the figure, UserA is assigned the Viewer role which has access to only view operations while UserB is assigned theOperator role and the Engineer role which together have access to all the view, read, control, reporting, and data setoperations.

RBAC may be session-based or message-based. Session-based RBAC is concerned with authorization in TCP/IP-basedcommunication while message-based RBAC is concerned with Ethernet-based communication. In this work, we focus onsession-based RBAC for client–server communication in IEC 61850. In session-based RBAC, authentication is considered aspart of authorization. However, per the RBAC model in the NIST proposal [13], authentication should be a pre-process ofauthorization. In this work, we assume that authentication has already been processed.

4. Supporting RBAC in IEC 61850

In this section, we describe an approach for supporting RBAC in substation automation based on IEC 62351 and IEC 61850. In theapproach, we first relate the ACSI services identified for RBAC in IEC 62351 with classes (data objects) in IEC 61850. Then, we extendSCL using an XML name space to support RBAC entities in substation configuration. Lastly, we describe RBAC polices, requests, andresponses using XACML [6] which is a standard language for describing access control models. We choose XACML because not only itis a standard language, but also it provides great compatibility with SCL which is also XML-based.

4.1. Relating ACSI services to IEC 61850 objects

IEC 62351 defines roles and their rights (permissions) for a subset of ACSI services in IEC 61850 as shown in Fig. 3.However, it does not describe the classes that are associated with the ACSI services. The classes are the target resources onwhich the ACSI services are to be performed and thus, to be protected by access control. Based on the description in IEC61850, we associate the ACSI services in Fig. 3 with IEC 61850 classes as shown in Fig. 4. IEC 61850 defines Server,LogicalDevice, LogicalNode, and DataObject classes for capturing the structure of a server (an IED) via a chain of aggregations.That is, a server is composed of a set of logical devices and in turn a logical device is composed of a set of logical nodes and inturn a logical node is composed of a set of data objects. Each class provides certain ACSI services manipulating the dataobjects in the class. For example, the Server class provides the GetServerDirectory service for a client to access the directory ofthe server. Similarly, the LogicalNode class defines the GetLogicalNodeDirectory service for returning the directory of thelogical node and the GetAllDataValues service for obtaining the data associated with the logical node. Other classes can beexplained similarly.

IEC 61850 also defines the ReportControlBlock class capturing control blocks of reports, the DataSet class representinggroups of data objects, and the Control class containing control information. The ReportControlBlock class provides services forcreating control blocks of reports and setting and getting values of grouped data objects when an event is triggered under a

B. Lee et al. / Information Systems 53 (2015) 237–249 241

certain condition. The DataSet class provides services for creating and deleting a data set which is a group of data objects. TheControl class provides services for controlling devices.

4.2. Extending SCL

SCL is a XML-based language for describing the configuration of an SAS. Configuration includes the structure of thesubstation, composing IEDs and their devices and logical nodes with involved data, connection of IEDs to the network(access points), and sending and receiving of data sets between IEDs. SCL should be extended to support RBAC. There arethree ways of extending SCL per IEC 61850 – extending its schema, defining XML name spaces, and using privateelements. Extending the SCL schema is effective when introducing new syntactic elements such as base data types.However, they are subject to syntactic changes requiring changes in the existing parsers. On the other hand, an XMLname space allows us to define elements without changing the SCL schema and thus, the existing parsers may be used asthey are. In this work, we use IED Scout [14] for parsing and validating SCL specifications. Private elements, which areuseful for small extensions, are used to define elements whose data contents should be preserved during data exchangebetween tools. In this work, we use an XML name space for defining RBAC elements. Listing 1 shows the schematicdefinition of the name space. It defines two elements – supportRBAC and RoleBasedAccess. The supportRBAC element is aboolean attribute of an IED indicating that the IED is subject to access control. The RoleBasedAccess element specifies thenetwork address of the RBAC server enforcing access control polices. The tRBAC type, which is used as the type forRoleBasedAccess, has name, availability, and address attributes.

Listing 1 (RBAC scheme definition).

Listing 2 shows the use of the defined RBAC elements. The listing specifies that an IED ied1 is subject to access control bythe supportRBAC attribute set to “true” and that the RBAC server rbacTest is located at 192.10.10.3 which is used by the IED toestablish a connection for access control. The RoleBasedAccess element may be further extended with more attributes such asexpiration date and areas. This specification may use the existing SCL parser without modification as the used RBAC elementsare non-syntactic to the SCL schema.

Listing 2 (SCL specification with RBAC).

4.3. Describing access control policies and requests

We use XACML [6], a standard access control policy language, for specifying RBAC policies, requests, and responses.XACML provides a reference model for implementing an authorization system consisting of Policy Administration Point

B. Lee et al. / Information Systems 53 (2015) 237–249242

(PAP), Policy Decision Point (PDP), Policy Enforcement Point (PEP), Policy Information Point (PIP), and Policy Retrieval Point(PRP). Fig. 5 depicts the reference model. An access request is received by PEP and forwarded to PDP for evaluation based onpolicy sets fetched by PAP using the attributes (subject, object, action) of the request retrieved by PIP. PDP sends back theevaluation result to PEP. Depending on the result, PEP may take obligated actions (e.g., logging) and then sends the result tothe requestor (the requesting IED).

Fig. 6 shows the structure of XACML components. A policy set is a set of policies and each policy consists of a set of rulesfor determining access. A rule is defined in terms of a target, a condition, and an effect (e.g., permit, deny). A target definesconditions on subjects, actions, and resources for a policy set, a policy, or a rule to apply to the request. If there exists a targetcorresponding to the request and the condition is satisfied, the effect takes place. An obligation is a posterior action (e.g.,logging) initiated by PDP after determining access and performed by PEP.

An access request is described in terms of subject, resource, and action. Subject represents a role who requests access to aresource. Resource is data or a service being requested for access. Action defines an action to be performed on the requestedresource. Listing 3 shows an example of an access request where (1) lines 2–7 specify the Operator role, (2) lines 8–13describe the dataset1 resource in the LLN0 logical node of the ied11Device1 device, and (3) lines 14–19 define theDeleteDataSet service to delete dataset1.

Listing 3 (RBAC access request example).

Similar to access requests, a rule is described in terms of subject, resource, and action, defining an access permission.Listing 4 shows an example of a rule. The rule describes that the Operator role has access to the resource ied1lDevice1/LLN0.dataset1 for deletion (DeleteDataSet). A rule may evaluate to Permit, Deny, Indeterminate, or NotApplicable. Permitgrants the access request whereas Deny denies the request. Indeterminate is given when the rule produces an error.NotApplicable denotes that the rule is determined not applicable. In this work, we consider Indeterminate andNotApplicable as denied.

Rules may conflict each other, resulting in different decisions. In such a case, combining algorithms are used to reconciledifferent decisions. Combining algorithms may be defined at the policy set level resolving conflicting policies at the policylevel or defined at the policy level resolving conflicting rules at the rule level. There are seven standard algorithms (e.g., DenyOverrides, Permit Overrides) defined in XACML and they can be used together to build up more complex algorithms. In thiswork, we make use of the Permit Overrides algorithm.

B. Lee et al. / Information Systems 53 (2015) 237–249 243

Listing 4 (RBAC rule example).

A response is given based on the evaluation result of applied rules and combining algorithms. Listing 5 shows an example of aPermit response.

Access Requestor

Subject Object Action

PIP

5. attributes

Obligation Service

PAP

PDP

PEP

4. Attribute Query

7. Repsponse2. Request

3. Policy6. Attribute

8. Obligation

1. Access Request

Fig. 5. XACML reference model [6].

1

Policy Set

Rule

Policy

Conditions

Obligations

Effect

TargetAction

Subject

Resource

1..* 1

1..*

1

1..*

1

0..*

0..*

0..*10..*

1

1 10..11

0..*

0..1

1

Fig. 6. XACML structure [6].

B. Lee et al. / Information Systems 53 (2015) 237–249244

Listing 5 (Response example).

5. Implementation

In this section, we describe an implementation of the presented approach. Fig. 7 shows the architecture of theimplementation. The implementation uses the client–server model in Fig. 2 on both sides of IEC 61850 and RBAC. On theIEC 61850 side, the server is an IED and the client may be an HMI within the substation or an external system such as an EMSand SCADA. On the RBAC side, the server is the XACML server enforcing access control policies and the client is an XACMLinterface between the IEC 61850 server and the XACML server. The RBAC client is responsible for converting the servicerequest received by IEC 61850 server to an XACML request and forwarding it to the XACML server for evaluation. Theseparation of RBAC from IEC 61850 facilitates reuse of RBAC components for other SCSMs (e.g., Web service [15,16]).

Fig. 8 shows RBAC interactions in subsystem automation. The IEC 61850 client establishes a connection to the IEC 61850server with role information passed into the associate service request. Upon receiving the request, the server loads up theXACML client to establish a connection to the XACML server. The IEC 61850 client sends a request containing the target objectand ACSI service to the IEC 61850 server. The server then delegates the request to the XACML client for creating acorresponding XACML request to be sent to the XACML server for evaluation. The XACML server evaluates the request andsends back the result to the XACML client which forwards it back to the IEC 61850 server. If the result is Permit, the serveracknowledges Permit to the IEC 61850 client. For all other results (i.e., Deny, Indeterminate, NotApplicable), the server sendsDeny. IEC 61850 defines a set of error messages for a service failure and we extend the set by adding an error message foraccess denial.

5.1. RBAC-based IEC 61850 client–server communication

We use OpenIEC61850 [17] for client–server communication in IEC 61850. OpenIEC61850 is an open source Java libraryimplementing an MMS server and its client based on Open Monitor Union Control (OpenMUC) [18] which is a software

B. Lee et al. / Information Systems 53 (2015) 237–249 245

framework for developing monitoring, logging, and controlling systems. A TCP/IP connection between a client and a server isestablished using the associate() service defined in the Two Party Application Association (TPAA) class. We extend the serviceby adding a parameter for role information. Listing 6 shows the use of the extended associate() service. In addition to roleinformation, the associate() service also carries parameters of MMS Server IP address, port number, and The third parameteris for authentication.

value

: 61850 Client : 61850 Server

GetServerDirectory ()

logical device list

GetLogicalDeviceDrectory (ied1lDevice1)

logical node list

GetDataDirectory (ied1Device1/MMXU1.TotW)

GetDataValues (ied1Device1/MMXU1.TotW.mag.f)

GetLogicalNodeDrectory (ied1Device1/MMXU1)

data object list

data object list

Fig. 9. Data object retrieval sequence diagram.

IEC61850IEC 61850Client

<import>

Extended SCL

responserequest

request(role, service)

response

ClientXACML (RBAC)

IED

access requestXACML (RBAC)

Server

IEC 61850

RBAC

response

Server

Fig. 7. Client–server model supporting RBAC.

:XACML Server:IEC 61850 Server:IEC 61850 Client

associate()

values[Permit]

[Deny]service error

IED

gen62351Interface()

evaluate(request)

response

generateRequest

response

(role,action,rsc)

:XACML Client

assocaite(role)

alt

evaluate (role, action, rsc)service()

Fig. 8. Interactions of RBAC-based substation automation.

B. Lee et al. / Information Systems 53 (2015) 237–249246

Listing 6 (associate() service extended for role).

The associate() service also has a parameter AuthenticationParameter indicating that if local authentication to the IED isrequired, which uses the password pre-defined in the IED. Note that this authentication is different from the authenticationin the IEC 61850 client. If the parameter is set, server authentication should take place prior to RBAC authorization. In thiswork, we do not consider the parameter and thus, set it to null.

The associate() service uses the constructInitRequestPdu() method in its definition for creating a Protocol Data Unit (PDU)message to establish a connection between the IEC 61850 client and server. We also extend the definition of theconstructInitRequestPdu() method to accommodate role information. Listing 7 shows the extended definition. In thedefinition, the role parameter is added to carry role information and used to create an instance of the InitiateRequestPdu

MMS Client

tm

XACML Sever

ta

MMS Server(XACML Client)

Fig. 11. Time measuring.

Table 2Times measured (in second) for tm and ta.

Service SetDataValues GetDataValues SetDataSetValues DeleteDataSet

Time tm ta tm ta tm ta tm ta

1 0.02 0.20 0.03 0.48 0.03 0.28 0.03 0.272 0.02 0.20 0.03 0.47 0.03 0.26 0.03 0.283 0.02 0.21 0.03 0.41 0.03 0.37 0.03 0.264 0.02 0.30 0.03 0.46 0.03 0.27 0.03 0.265 0.02 0.30 0.03 0.41 0.03 0.28 0.03 0.286 0.02 0.30 0.03 0.43 0.03 0.28 0.02 0.307 0.02 0.30 0.03 0.43 0.03 0.28 0.02 0.308 0.02 0.20 0.03 0.41 0.03 0.27 0.02 0.309 0.02 0.30 0.03 0.40 0.03 0.28 0.02 0.30

10 0.02 0.30 0.02 0.41 0.02 0.21 0.02 0.29

Avg. 0.02 0.26 0.03 0.43 0.03 0.27 0.02 0.30

RequestSender

ResponseReceiver

XACML Client

IEC61850 Serverrequest

response

responseaccess request

IED

Fig. 10. RBAC client.

SampleSever [Java Application] C:\Program Files\Java\jre7\bin\javaw.exe (Jan 30, 2014 5:17:51 PM)17:17:51.311 INFO org.openmuc.openiec61850.SclParser - IED rbac Support::true17:17:51.321 INFO org.openmuc.openiec61850.SclParser - IED rbac Information::name=“rbacTest”

17:17:51.341 INFO org.openmuc.openiec61850.ServerModel - RBAC is added to SERVR 17:17:56.162 INFO o.o.openiec61850.ServerAssociation - XACML Server::192.10.10.317:17:56.162 INFO o.o.openiec61850.ServerAssociation - Role::operator17:17:56.172 INFO o.o.openiec61850.ServerAssociation - Recieve a MMS GetNameList[Domain] request17:17:56.183 INFO o.o.openiec61850.ServerAssociation - Recieve a Get MMS GETNameList[Named VARIABLE] request17:17:56.183 INFO org.openmuc.openiec61850.rbac.Rbac - ied1Device117:17:56.743 INFO org.openmuc.openiec61850.rbac.Rbac - A XACML request is sent to XACML server17:17:56.973 INFO org.openmuc.openiec61850.rbac.Rbac - The XACML response is reveived from XACML server17:17:56.973 INFO org.openmuc.openiec61850.rbac.Rbac - Result::Permit

address=“192.10.10.3” available=“true”

Fig. 12. IEC 61850 server execution result.

B. Lee et al. / Information Systems 53 (2015) 237–249 247

class supporting message formatting in Abstract Syntax Notation One (ASN.1) [19] which is a standard for encoding anddecoding a message at the Presentation layer using basic encoding rules (BER) for network transmission.

Listing 7 (associate() service definition on client).

The InitiateRequestPdu class is also extended to accommodate role information and Listing 8 shows the extendeddefinition.

Listing 8 (InitiateRequestPdu definition extended for RBAC).

RBAC implementation should take into account the hierarchical nature of an IEC 61850 server (see Section 3.1) which affectsthe behaviors of data access. Fig. 9 shows the sequence of data retrieval according to IED data structure. To retrieve data, theclient should first request the list of the devices in the server and selects a specific device from the list. For the selecteddevice, the client requests the list of involved logical nodes and selects a specific logical node. Again, for the selected logical

B. Lee et al. / Information Systems 53 (2015) 237–249248

node, the client requests the list of involved data objects and selects a specific object. A data object may be composite havinga set of attributes from which the requested value can be retrieved. Our implementation supports RBAC at any level in thehierarchy.

5.2. Implementing RBAC client

We use Sun's XACML API [11] to implement the XACML client. Fig. 10 shows the components of the XACML clientincluding Request Sender and Response Receiver. Request Sender is responsible for converting a service request received by theIEC 61850 server into an XACML request. On the other hand, Response Receiver is responsible for receiving an XACML responsefrom the XACML server and converting it into an IEC 61850 response.

Algorithm 1 shows the createXACMLRequest() operation for converting an ACSI service request to an XACML request. AnXACML request is created based on the information of role, action, and resource passed in the ACSI request. Role informationis sent to the IEC 61850 server when a connection is established between the client and the server. Therefore, the rolerequesting the service has already been identified in the server before the service is requested. Action and resourceinformation is sent at the time when a service is requested. Line 1 shows the role information being passed in thecreateXACMLRequest() operation. The getMMSServiceType() and getMMSObjectType() operations in lined 3 and 4 are used toextract the MMS service and object from the received MMS message formatted in ASN.1.

RBAC policies in the XACML server are described in terms of ACSI services and so are the XACML requests created by theXACML client. However, the services received in the IEC 61850 server are described in MMS. This requires the ACSI servicecorresponding to a received MMS service to be identified in order to create an XACML request. Line 5 shows thegetACSIServiceType operation for identifying the mapped ACSI service using the SCSM in Table 1. Due to many-to-onecorrespondence between ASCI services and MMS services, some ASCI services cannot be uniquely identified. To address this,we use the combination of a MMS service and its parameters to single out the corresponding ASCI service. For instance, theMMS service GetNameList with a parameter of an object mapped to a logical node in ACSI corresponds to theGetLogicalDeviceDirectory service in ACSI.

Algorithm 1. createXACMLRequest operation.

1:createXACMLRequestðrole;mmsÞ:XACMLRequest2: {3: String mst ¼ getMMSServiceTypeðmmsÞ4: String mot ¼ getMMSObjectTypeðmmsÞ5: String ast ¼ getACSIServiceTypeðmst;motÞ6: return createðrole; ast;motÞ7: }

6. Evaluation

We carried out an experiment of the implementation presented in Section 5 using a 100 Mbps Ethernet switch which iswidely used for the Station bus communication in IEC 61850. The IEC 61850 server, IEC 61850 client, and XACML server aredeployed on different machines to simulate a distributed network environment as in a production site. We used OracleVirtual Box [20] to simulate a real IED representing a server in a substation. We configure Virtual Box to purposely lower CPUperformance and memory to 400 MHz and 1 Gigabyte, which is a typical specification for nowadays IEC 61850 servers in thefield. The simulation was run on a 32-bit XP Windows machine. For the IEC 61850 client, a 64-bit Windows machine with2.30 GHz dual core and 8 Gigabyte memory is used. The XACML server is run on another 64-bit Windows machine with2.93 GHz single core and 8 Gigabyte memory. The machines are synchronized for time using a Network Time Protocol (NTP)server. IEC 61850 defines three types of messages – Types 1–3 by transmission speed where Type 1 is the fastest, Type 2 ismedium, and Type 3 is the slowest. MMS messages are of Type 3 whose time requirement is 0.5 s for a message to bereceived. We use TCP/IP communication RBAC authorization.

We use four services – GetDataValues, SetDataValues, SetDataSetValues, and DeleteDataSet – in the experiment. For eachservice, we measure the request time (tm) from the MMS client to the MMS server and the response time (ta) from the MMSserver to the MMS client via the XACML server. Fig. 11 illustrates time measuring.

Table 2 shows the results which demonstrate both ta and tm satisfying the time requirement. Due to the internalprocessing latency for RBAC authorization in the MMS server, ta takes longer than tm. The results show that the getDataValuesservice has the longest average (0.43) of ta which is close to the time requirement of 0.5 s. Unlike the time requirement forGOOSE communication which is hard, the time requirement for MMS communication is soft. Thus, even in the case where tais slightly longer than the requirement, that would not be considered critical. We would expect ta to be longer in a productionenvironment than the experiment results due to the slower microprocessor in a real IED and high network traffics. On theother hand, it is equally expected that performance of IEDs is to be improved as power grids evolve.

Fig. 12 shows the execution of RBAC authorization for a request from the Operator role to perform the GetNameList serviceon the ied1Device1 object, which is granted. It also shows that the RBAC client is loaded into the IEC 61850 server based onthe required RBAC authorization of IEDs in the SCL file.

B. Lee et al. / Information Systems 53 (2015) 237–249 249

7. Conclusion

We have presented a novel approach to support RBAC for TCP/IP client–server communication in substation automationbased on IEC 62351 and IEC 61850. We used XACML to describe RBAC policies and extended SCL, ACSI, and SCSM in IEC 61850and MMS, and ASN.1 to support RBAC. The approach separates RBAC from IEC 61850 to minimize required changes in IEC61850. RBAC in IEC 62351 is not fully mature yet and we expect it to evolve with more roles and policies (e.g., role hierarchies,separation of duties) to be added. The presented approach is flexible to accommodate future extensions. The substationdomain is more or less stable in terms of RBAC elements (e.g., users, roles, objects, operations). Thus, from an administrationperspective, minimal changes of access control policies are expected in a runtime environment.

We plan to look into message-based RBAC for GOOSE communication. Unlike the session-based RBAC in this work,message-based RBAC must satisfy tighter time requirement (3 ms) in IEC 61850, which might be a challenge due to therequired evaluation time in RBAC. We shall investigate how RBAC evaluation time can be reduced to satisfy the requirement.

References

[1] IEC 61850, Communication Networks and System in Substation Automation, 2002–2005.[2] IEC 62351, Power Systems Management and Associated Information Exchange—Data and Communications Security, 2007–2011.[3] W. Dong, F. Darie, S. Ling, Application layer security proxy for smart grid substation automation systems, in: Proceedings of the Innovative Smart Grid

Technologies, 2013, pp. 1–6.[4] W. Baoyi, Z. Shaomin, Z. Zhilei, DRBAC based access control method in substation automation system, in: Proceedings of the IEEE International

Conference on Industrial Technology, 2008, pp. 1–5.[5] D. Rosic, U. Novak, S. Vukmirovic, Role-based access control model supporting regional division in smart grid system, in: Proceedings of the Fifth

International Conference on Computational Intelligence, Communication Systems and Networks, 2013, pp. 197–201.[6] OASIS Standard, Extensible Access Control Markup Language (xacml) Version 2.0, 2005.[7] M. Xu, D. Wijesekera, X. Zhang, Runtime administration of an RBAC profile for XACML, IEEE Trans. Serv. Comput. 4 (4) (2011) 286–299.[8] W. Dong, L. Yan, M. Jafari, P. Skare, K. Rohde, Protecting smart grid automation systems against cyberattacks, IEEE Trans. Smart Grid 2 (4) (2011)

782–795.[9] A. Nagarajan, C. Jensen, A generic role based access control model for wind power systems, J. Wireless Mobile Netw. Ubiquitous Comput. Depend. Appl.

1 (4) (2010) 35–49.[10] IEC 61400-25, Communications for Monitoring and Control of Wind Power Plants, 2006.[11] Suns xacml Implementation, ⟨http://sunxacml.sourceforge.net/⟩, 2006.[12] P. Pleinevaux, An analysis of the MMS object model, IEEE Trans. Ind. Electron. 41 (3) (1994) 265–268.[13] D. Ferraiolo, R. Sandhu, S. Gavrila, D. Kuhn, R. Chandramouli, Proposed NIST standard for role-based access control, ACM Trans. Inf. Syst. Secur. 4 (3)

(2001) 224–274.[14] Omicron iedscout, ⟨https://www.omicron.at/en/products/all/secondary-testing-calibration/iedscout/noc/1/⟩, 2012.[15] N.A. Nordbotten, XML and web services security standards, IEEE Commun. Surv. Tutor. 11 (3) (2009) 4–21.[16] Specific Communication Service Mapping (scsm Mappings to Web-Services), Document 57/1181/np, 2012.[17] Openiec61850, ⟨http://www.openmuc.org/index.php?id=35⟩, 2013.[18] Open muc, ⟨http://www.openmuc.org⟩, 2013.[19] International Telecommunication Union, Information Technology Abstract Syntax Notation One (asn.1): Specification of Basic Notation, 2008.[20] Oracle Virtual Box, ⟨https://www.virtualbox.org⟩, 2014.