Applying Model Based Systems Engineering

approach to Smart Grid Software Systems Security

Requirements

Sitaraman Lakshminarayanan 1 and Manyphay Souvannarnarth2

1
Security Architect, Systems Engineering, GE Energy, Atlanta, GA
Email: S.Lakshminarayanan@ge.com
2
Senior Systems Engineer, Systems Engineering, GE Energy, Atlanta, GA
Email: Manyphay.Souvannarath@ge.com

Abstract Smart Grid Systems are a classic example of a System of

Systems. Smart Grid brings intelligence to the existing electric grid
by integrating various software and devices from domains [1] such as
Transmission, Distribution, Customer, Bulk Generation, Operations,
Markets and Service providers. Security is very critical both from a
reliability and compliance standpoint. Smart Grid as a System of
Systems contains various Software Systems that provide the
necessary intelligence and integration.Therfore building security
within software systems is very critical as opposed to bolt on solution
that is often deferred until deployment. System Architects face a
tough challenge in understanding what are the various security
requirements, how such requirements are applied to software systems
at various interfaces, how to capture the system security artifacts and
articulate it better to stakeholders. We describe how various model
based systems engineering concepts are applied in capturing the
requirements and how those requirements are applied to various
components and interfaces and can provide traceability. Figure 1 NIST SP 1108 Smart Grid Domains
Keywords-System security, compliance, interoperability, Total
cost of ownership, software security, NERC CIP, NIST IR 7628,
System Integration and Security, SysML, Model Based Systems Figure 2 describes the various applications in each of those
Engineering. domains described in Figure 1 and how they interact with each
other as a logical reference model. While there are some
I. INTRODUCTION SCADA [2] systems and other devices that are specific to
utility industry is described in Figure 2, there are also
significant software systems that interact with each other. NIST
There are many definitions for Smart Grid. In the context of IR 7628 [3] describes various interoperability and security
Systems Engineering, Smart Grid consists of various Systems challenges for logical interfaces across various Smart Grid
that belong to various domains such as Transmission, domains. The logical connections in Figure 2 describe how
Distribution, Customer, Bulk Generation, Operations, etc. systems within and across the domains interface to provide
While it is common for systems in each of these domains to expected business behavior (e.g. Smart Grid as a whole or one
interact with each other, within the context of Smart Grid, particular system/solution such as a Demand Response
systems often interact across their domain boundaries. Figure 1 Management System). With such highly integrated systems it
[1] describes the overview of interactions between the domains. is important to ensure that only authorized users or systems can
interface with another system and that the Confidentiality,
Integrity and Non-repudiation are not compromised. While
Smart Grid consists of various components, software, devices,
systems and subsystems, in this paper we focus on the System
Security at the Software and services layer for Smart Grid
Systems.

Figure 2 NIST IR 7628 Logical Reference Model
There isexisting literature on software security, system
security, network security, malware analysis, intrusion
detection, etc. but there is a lack of adoption/discussion in
applying Systems Engineering [4] concepts to define or enforce
security. While it is considered as an architecture or design
discussion, utilities (a.k.a. Asset owners who own the software
and systems) typically have software and systems from various
vendors and applying consistent security at the software system
and integration layer is often left to the customers. While
interoperability is a bigger part of the challenge, there are also
industry and regulatory standards that the customers must
comply with. It is a system level problem from the customer
standpoint and hence we discuss how applying system
engineering concepts can help to define a system security
program.
In this paper we describe the security challenges associated
with software systems, various industry and regulatory
compliance standards, interoperability issues, system
integration challenges, etc. We then discuss various systems
engineering concepts and how the requirements are captured
and applied across Smart Grid software systems. Systems
Engineering concepts and SysML [5] tools can provide utilities
a standard way to discuss, design, architect system security
within utility and with their partners and vendors. The next
section will discuss Smart Grid system security challenges in
detail.
II. SMARTGRID SYSTEM SECURITY CHALLENGES
Securing the Smart Grid system and System of Systems at
the software layer is a challenging task given that not all
software and services are from the same vendor. Utilities often
have to deal with interoperability and integration challenges,
and at the same time have to secure the system that addresses
the business risk as well as the regulatory and industry
compliance standards.
When multiple software systems each have a unique
implementation, it becomes challenging for the utilities to
enforce security in a consistent manner and reduce total cost of
ownership. Utilities also have to implement security processes
and procedures to comply with internal security policy as well
as industry and regulatory compliance standards.
Security functions such as authentication, authorization,
confidentiality, integrity, and non-repudiation are very well
documented and are easy to design and implement for a closed
system that is not meant to be part of a larger system. In the
case of Smart Grid systems, the system is made up of various
components, software and services and they are typically from
different vendors. Security should be applied within the
component and at the interface layer and should be
interoperable. In additional to that, software systems shall
interface with external security products and services thus
making interoperability a key criteria in defining systems
security requirements.
Weak or ineffective security at the integration layer, when
misused (hacking, insider threat, etc.) can cause reliability
concerns for the electric grid itself. Interoperability becomes
very critical because of the heterogeneous nature of Software
Systems involved in Smart Grid.
It is important that the security engineering for such a
complex System of Systems be done in a way it is easy to
communicate with various stakeholders. Different stakeholders
may have different interests and it is important to follow certain
formal procedures to make it easy. For instance, a compliance
officer might be interested to find out how various regulatory
compliance standards are being enforced across Smart Grid
systems. A technical subject matter expert might be interested
in how to translate the industry, regulatory or internal security
standards and policy to technical implementation requirements.
In this paper we propose how Model Based Systems
Engineering can be applied not only to define the security
requirements but also to apply such requirements to various
components and services of Smart Grid systems. Smart Grid by
itself is a complicated subject and the focus of this paper is to
show how Model Based Systems Engineering can be applied to
securing the software systems and System of Systems.
This paper is organized in such a way that it describes the
Smart Grid system security challenges, Systems Engineering
process, Model Based System Engineering concepts and how
tools such as SysML can be used to address various security
challenges of Smart Grid systems. Throughout this paper we
describe how applying Model Based Systems Engineering can
be effective in capturing the system security requirements and
applying integrating them with the overall system design
process.
III. SYSTEMS ENGINEERING
The modeling approach used in the systems engineering is to understand the various industry/regulatory or internal
security analysis can be distinguished into three parts which policy and then translate them into various Security functional
are requirements. Then derive technical requirements from the
A. Building the Security Model functional requirements and then apply interoperability
B. Incorporating Security Analysis to SE Projects requirements to define the internal security code. Each step of
C. Extracting Traceability this process is defined in the next sections.

Step A discusses the build-out of the model which is

fundamentally comprised of three core objects (Basic
Function, Security Code, and Industry Standard) and the
connection among each as described in Figure 3.

Basic Security Industry

Function Code Standard

Figure 3 Model Structure Industry Regulatory Internal

Compliance Policy
Standard
Step B, Incorporating Security Analysis to systems
engineering projects, is the step that integrates the Security
Analysis with project specific systems engineering analysis. Security
Functional
This step joins the Basic Object from Step A with the System Requirements
Function as defined by the Project Model and is described in
Figure 4.
Derive technical Requirements to
System Basic Security Industry meet functional need
System
Requirement Function Function Code Standard

Figure 4 Security Analyses in SE Projects Integrate interoperability

with
technical
Step C, Extracting Traceability, goes through the various
analysis and techniques used to query the model for different
traceability as needed by specific stakeholders.
Internal
Security
Codes
each
functional
blocks
A. Building the Security Model
Security requirements often come from various sources
such as internal security policy, industry standards, and
regulatory compliance standards. Most of these are either
policy statements (often the case with internal security policy)
or provides use cases, risk exposure and some
recommendations, but not the technical requirements on how it
should be implemented. The reason for this is that the technical
choices may vary from one organization to another and the
industry or regulatory standards do not enforce one technology
or one particular solution. The intent of these various security
standards is to control the risk in the event if a system is
compromised.
Utilities are often faced with the challenge of adhering to
various security standards and at the same time have to ensure
that the systems from various vendors also interoperate in a
secure manner. The technology choices behind addressing the
security standards are based on the technology readiness level
within the organization and hence the industry standards,
compliance standards, internal policy, etc. should be translated
to technical requirements that can then be implemented or
enforced when the system is deployed. Here we propose one
way of defining the internal security requirements, referred to
as Security Code Analysis.
The Figure 5 describes how internal security codes are
derived from the industry or regulatory standards. The first step
standards
requirements
Generate
for
Figure 5 Security Code Analyses
The first task is gathering the various standards that are
applicable to the system of interest. As mentioned previously,
standards can be in the form of official industry standards,
regulatory compliance and/or internal policy. A SysML
Standard Block is used to capture each of the standards.
Example standard blocks include NIST IR 7628 and NERC
CIP [6].
Often various standards may describe the same risk in
different ways. It is important to understand those requirements
and then group them into various functional blocks such as
Authentication, Authorization, Auditing, Confidentiality,
Integrity, and Non-repudiation. Functional blocks can also be a
set of security functions that can be grouped together such as
Password Management, User Account Management, etc. This
provides a logical method of grouping the requirements from
various industry and regulatory standards, thus eliminating
duplication. SysML Security Function Code Blocks are then
created for each category of the standard requirements.
Associations from Security Function Code Blocks to the
Standard Blocks are then made appropriately resulting in
several diagrams showing security code to standard mapping as
in Figure 6 below.
 Interoperability LDAP is one of the Provides consistency
Standards to interoperable for applications in
integrate with standards used to any platform to
various software authenticate users authenticate against
platforms. against any LDAP any LDAP Server
Server. using a common
interoperable
standard instead of
any proprietary API.
Human Systems Solution could Requires long term
Interaction in the consider using vision and support
context of interoperable for interoperable
authentication. standard such as standards across all
SAML or something the applications.
Figure 6 Security Function Code to Standards Mapping Solutions could similar.
include support for
Single Sign On.
1) Security functions to derived technical requirements

Figure 6 describes how security functions are mapped to Solution could use Only limited to
various standards and this eliminates any duplicate functional products (and not technologies within
requirements across various standards. The next step is to necessarily organization.
derive technical requirements from these functional supporting any
requirements. Technical requirements are the ones that will be interoperable
standard) that
used by system developers, integrators, system administrators, provide single sign
etc. to implement or enforce. on across web
applications.
For instance an Authentication functional requirement may
then be translated into various technical requirements such as: Technology Technology Organization should
Readiness Level Readiness to support be ready to deploy,
System shall support authentication based on username and LDAP for manage, maintain
password or System shall support authentication based on authentication may and train their
Digital Certificates. The technical requirement at this level be higher compared employees in support
still leaves room for interpretation by software developers or to supporting Single of such technology.
system integrators. For instance, there are different ways to Sign on Standards
support username and password based authentication, such as such as SAML.
either against LDAP server or against RDBMS database.
Table 1 Analysis of technology factors and solution options
In defining the security technical requirements, one has to
consider various factors such as security of the technical
solution itself, interoperability standards, human systems The Table 1 describes various factors that influence
technical direction and those factors should be considered in
interaction, technology readiness level, system usage or
deployment model, system administrations, etc. the technical requirements documents. These factors can
influence what solutions will be put in place and how they will
Factors influencing Solution Options Common be developed, managed and integrated with other software
technical advantages or systems.
requirements disadvantages
Each functional requirement should not be mapped only
Username and Store username and Password is stored in into its own technical requirement. In defining the technical
Password password against digest format, unable requirements, the technical solutions for each functional block
LDAP using default to retrieve the
password attribute. plaintext password.
may overlap, and one set of technical requirements may
actually satisfy few functional requirements. For instance the
Store username and Passwords then password management functional requirements can be easily
password against any should be encrypted addressed when LDAP is chosen as technical requirements to
RDBMS database. and stored. address authentication, since most LDAP servers provide the
When encrypted, one capability to enforce complex password policies. Hence the
has to manage the need to break down the functional requirements to low level
encryption keys. technical requirements that can be used as a reference during
During
design, implementation and even during procurement of new
authentication a systems.
common and
proprietary API
should be provided
for authentication. .
Figure 7 Security Codes or derived technical requirements
The Figure 7 describes various security codes that describe
the technical requirements. These security codes are derived
from various industry standards. The security codes described
here are then linked to various components and interfaces to
ensure that the security requirements are developed, deployed
or enforced. It is also important that such requirements
(security codes) include interoperability requirements
There are two main reasons to look at interoperability
requirements. One is to ensure that disparate systems or
subsystems from various vendors can interface securely (e.g.
WS-Security[7] for web services, Kerberos or SAML[8] for
single sign-on) and the other reason is to interface with existing
security infrastructure such as LDAP[9] Server, PKI
[10]Infrastructure, etc.). It is important to envision how various
software systems will be interfaced (message oriented, web
services, FTP, etc.) with each other and with any security
infrastructure (e.g. identity and access management systems,
directory services, PKI, etc.) and then select the interoperability
requirements that apply to the system and which should be
aligned with technology roadmap. Such interoperability
requirements should be added to the technical requirements,
which can then be used during system design, integration and
even during procurement.
The Figure 8 describes how the security functions are then
mapped to the technical requirements. This provides an
overview of how each of the security technical requirements
will meet the functional needs from a systems security
perspective. With the mapping between various standards,
security functions (functional requirements) and technical
requirements, it can now be identified which technical
requirement actually satisfied one or more industry or
regulatory standard.
Figure 8 Security function to Security Code
Using SysML to capture the industry and regulatory
standards and the derived technical requirements provides
traceability and a consistent way to describe the requirements
to the stakeholders. It can be further used to trace where such
requirements are applied. In contrast, the document based
approach as shown in Figure 9 describes mapping between
NIST IR 7628 security guidelines to DHS Control Systems
Security recommendation to the NERC CIP standards. Each
industry or regulatory standards is written to address its
objective but for the utility that is required to comply with
various standards, document based (Word, Excel or otherwise)
may be tedious and there wont be consistent way to describe,
update or apply security requirements across all the
components, subsystem or system.
Now that we have captured or derived various requirements
and described them using SysML, in the next section we
describe how to apply these requirements to various
components and interface, within the context of Smart Grid
software systems.
Figure 9 from NIST IR 7628 Volume1
B. Incorporating Security Analysis into Systems Engineering across all of those interfaces. NIST IR 7628 has documented
Process various logical interface definitions between subsystems or
The next step is to integrate the security model, as described components of Smart Grid as described in Figure 11. In the
Logical interface definition described in Figure 11, it only
in the previous section, with the project model of interest.
describes the functional requirements such as communication
This paper will not go into details on how to build a project
integrity, user identification or authentication, etc.
model but will highlight a few core assumptions about the
model that are necessary to integrate it with the security
model.
It is assumed that the project model contain a set of
requirement diagrams showing decomposition and traceability
among requirements. There are also system functional
diagrams that show decomposition and traceability among
functions. At the granular level, system functions are
decomposed down to a distinct verb and noun phrase.
Examples include Authenticate user login or Encrypt data
message. The system functions are then associated to
requirements to create function to requirement traceability
diagrams as shown in Figure 10

Figure 11 from NIST IR 7628 Interface Category 1

The concept described in this section provides an approach

Figure 10 Security function to system function
Once the security requirements are defined and an overall
system design is represented as components, blocks and
interfaces that connect them, security requirements should be
applied to each one of them. In order to achieve an effective
system security, security should be applied to the component or
individual software itself, interfaces within that software itself
and to the interface that cross the logical or physical boundary
to integrate with another system or subsystems. When you
integrate multiple systems or subsystem to form another system
(as in the case with Smart Grid), system security can be
compromised when there are no adequate security controls at
the interface/integration layer.
to integrate the security code analysis described in Security
functions to derived technical requirements with the systems
engineering process. This provides ability to attach or map the
security requirements to the system (at the component or at the
interface) as described in Figure 12
The project and the security models that are built can be
linked together using Basic Function blocks. Unlike System
Function blocks, these contain just the verb. Examples include
Authentication or Encryption. To create association, a set
of diagrams within the project model will associate System
Functional blocks to these Basic Function blocks which will
create a traceability model from basic function to system
function to system requirement. Similarly, the security model
will take the same set of Basic Function blocks and draw
associations to the appropriate Security Code blocks, which
will create a traceability model from Industry Standard to
Security Code to Basic Function. Figure 12 describes the
completed model that describes System Requirements to be
traced all the way down to a particular Security Standard.

Smart Grid system comprises of various subsystems and

components that are integrated together. Figure 2 describes
various logical interfaces that connect the various components
or subsystems or systems together. Security should be applied

Figure 12 Security requirements and its mapping to system
functions
C. Extending Traceability
Now that the traceability is mapped between the block
objects described in Incorporating Security Analysis into
Systems Engineering Process, we can run various queries
against the model to extract information as it relates to security
standards. We found it much easier to run the queries using
SQL. The data from the model is exported into a RDBMS
database where we can then develop queries to extract the
needed data.
Sample queries include gathering Industry Standards for a
particular System Requirement. Other queries can be
selecting all the Industry Standards as it relates to a particular
Basic Function of interest, like authentication, authorization,
confidentiality, etc. Depending on the stakeholder, the query
needs will vary.
Data results from these queries will normally be very
broad and include a wide range of results. However, as one
goes through several iterations of the Systems Engineering
process, both on the Project Model and Security Model, the
selection of applicable Industry Standards will be narrowed
down to a smaller list. .
IV. CONCLUSION AND FUTUREWORK
In conclusion, creating interoperable security within
complex systems of systems such as the Smart Grid can be a
challenge and requires a consistent way to model the security.
In the paper titled Using SysML to model complex systems for
security [11], the authors describe an approach to use SysML
to model security. In this paper we discussed how to capture
Biography
various security requirements and the source (internal security
policy, industry or regulatory standards) using SysML and
applying Model Based Systems Engineering concepts to
integrate security analysis with the project models. Taking a
strategic approach to the problem and using Model Based
Systems Engineering methodologies provides a logical and
repeatable path to address such complex challenges.
The approach described in this paper started with the
construction of the Security Model which contained various
industry standards, regulatory compliance and internal policy
that were grouped into Security Codes based on functional
requirements. The next step was to incorporate the Security
Model with the Project Model of interest. In complex systems
of systems initiative there can be several projects executing at
any point of time. The uniqueness of this approach is that the
same Security Model can be applied or incorporated into
multiple project models. Once the models have been
incorporated with each other, traceability from project
requirements to industry standards and the related technical
security requirements can be extracted.
We have only discussed the work done so far in
representing various security requirements and their
relationship to industry standards and system functions using
Model Based Systems Engineering. In the future we expect to
extend this work to integrate architecture design, deployment,
validation and verification within our Systems Engineering
process for true Systems Security Engineering.
References:
[1] NIST-SP-1108-
http://www.nist.gov/public_affairs/releases/upload/smartgrid_interopera
bility_final.pdf
[2] SCADA - http://en.wikipedia.org/wiki/SCADA
[3] NIST IR 7628 http://csrc.nist.gov/publications/PubsNISTIRs.html
[4] SystemsEngineeringINCOSE
http://www.incose.org/ProductsPubs/sehandbook.pdf
[5] SysML http://www.sysml.org
[6] NERC CIP - http://www.nerc.com/page.php?cid=6%7C69
[7] WS-Security-http://www.oasis-
open.org/committees/tc_home.php?wg_abbrev=wss
[8] SAML - http://www.oasis-open.org/standards#samlv2.0
[9] LDAP- http://www.ietf.org/rfc/rfc4510.txt
[10] PKI- http://en.wikipedia.org/wiki/Public_key_infrastructure
[11] Cano, L.A.; , "Using SysML to model complex systems for security,"
Security Technology (ICCST), 2010 IEEE International Carnahan
Conference on , vol., no., pp.66-70, 5-8 Oct. 2010
doi: 10.1109/CCST.2010.5678679
URL: http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=567867
9&isnumber=5678668
Sitaraman Lakshminarayanan has over 14 years of Information Technology experience with expertise across Software & System
Architecture and Security. He is currently with GE Energy and working on System Security architecture across Smart Grid and
other system security initiatives. He authored book on Web Services Security (Oracle Web Services Manager- Securing your web
services) June 2008. He also co-authored book on ASP.NET Security (Wrox Publications 2002). He has published papers on
IEEE IT Professional (Cloud computing), IEEE PES. He also co-authored the Security guidelines for Cloud Security Alliance
Version 2.0. He has presented at various conferences on software and systems security. His expertise includes Software and
Systems Security, Identity & Access Management and PKI.

Manyphay Souvannarath is a Senior Systems Engineer at GE Energy. Her current roles include Systems Engineer and Architect
for Smart Grid projects. Ms. Souvannarath earned her B.S. in Computer Science and Biochemistry at Grand Valley State
University. She is in the process of completing her MBA at Grand Valley State University and M.S. in Systems Engineering at
Georgia Institute of Technology.