◆ Assessing Smart Grid Security

Alan J. McBride and Andrew R. McGee

The evolution from traditional power networks to smart grid involves many
aspects including data network transformation, distributed functionality, and
two-way information flow between supplier and customer. Networks are
transforming to the use of packet-based communications and the use of
newer networking technologies, including optical, Internet Protocol (IP) and
Multiprotocol Label Switching (MPLS). Functionality is being distributed to
substations, transmission and distribution nodes, and to the customer site.
Information flow evolves to two-way communication of rating, billing, and
usage data between the customer and supplier (including “smart metering”).
These changes introduce new reliability and security challenges for the
power grid utility company. In the security domain, new threat vectors are
introduced, and vulnerabilities and attacks related to data networking and
information technology become more relevant. Security, reliability, and
availability of the management and control network and functionality are
business critical. This paper describes a methodology for assessing smart grid
security, and trends in smart grid security that we have observed while
applying this methodology. © 2012 Alcatel-Lucent.

Introduction depth of experience with assessing the security of prod-

Assessing security for the smart grid is a signifi-
cant challenge for various reasons. Smart grid archi-
tecture includes very many disparate systems, devices,
networking technologies, and other components.
Security requirements for the smart grid are particu-
larly onerous due to the critical nature of the power
grid as a public service and due to the particularly
attractive nature of critical infrastructure targets to
potential attackers with a range of motivations.
This paper describes a methodology used for assess-
ing security for the smart grid, used by Bell Labs in con-
sultative services around the globe, and based on the
security frameworks used within Alcatel-Lucent for prod-
uct and solution development. Bell Labs has a significant
ucts, solutions, enterprises, and networks using method-
ologies and tools that have evolved over many years to
address the target from multiple perspectives.
The paper begins with a brief overview of the
smart grid, before proceeding to discuss relevant secu-
rity challenges and trends. The methodology is then
described, including the use of a threat analysis pro-
cess, and assessment against industry best practices.
Smart Grid Overview
Smart grid applications as well as legacy power grid
applications are concerned with monitoring and control
of power transmission, distribution, and usage. Because of
the critical nature of power grid applications, security is

Bell Labs Technical Journal 17(3), 87–104 (2012) © 2012 Alcatel-Lucent. Published by Wiley Periodicals, Inc.
Published online in Wiley Online Library (wileyonlinelibrary.com) • DOI: 10.1002/bltj.21560
 Panel 1. Abbreviations, Acronyms, and Terms
3G—Third generation LAN—Local area network
3GPP—3rd Generation Partnership Project LTE—Long Term Evolution
AES—Advanced Encryption Standard MAC—Medium access control
AMI—Advanced metering infrastructure MMS—Manufacturing Messaging
AMR—Automatic meter reading Specification
ATM—Asynchronous Transfer Mode MPLS—Multiprotocol Label Switching
BLAS—Bell Labs Advisory Service NAC—Network access control
CCTV—Closed circuit television NAN—Neighborhood area network
CIP—Critical infrastructure protection NERC—North American Electric Reliability
CNCI—Comprehensive National Cybersecurity Corporation
Initiative NIST—National Institute of Standards and
DA—Distribution automation Technology
DES—Data Encryption Standard PTT—Push-to-talk
DHS—Department of Homeland Security SbD—Security by Design
DMZ—Demilitarized zone SCADA—Supervisory control and data
DNP3—Distributed Network Protocol 3 acquisition
DoS—Denial of service SG—Smart grid
DPI—Deep packet inspection SONET—Synchronous Optical Network
DR—Demand response SSL—Secure Sockets Layer
FAN—Field area network TA—Transmission automation
GOOSE—Generic Object Oriented Substation TCP—Transmission Control Protocol
Event TDM—Time Division Multiplexing
HQ—Headquarters TLS—Transport Layer Security
ICCP—Inter-Control Center Communications UMTS—Universal Mobile
Protocol Telecommunications System
ICT—Information and communication U.S. —United States
technology USB—Universal serial bus
IDS—Intrusion detection system VLAN—Virtual local area network
IEC—International Engineering Consortium VLL—Virtual leased line
IED—Intelligent electronic device VPLS—Virtual private LAN service
IP—Internet Protocol VPN—Virtual private network
IPS—Intrusion protection system VPRN—Virtual private routed network
IPsec—Internet Protocol security WAN—Wide area network
ISMS—Information security management WCDMA—Wideband code division multiple
system access
ISO—International Organization for WiMAX—Worldwide Interoperability for
Standardization Microwave Access
ISO27K—ISO 27000 series

a critical requirement, along with reliability and per-
formance (and, indeed, security issues can threaten reli-
ability and performance).
The evolution of the power grid entails upgrad-
ing the infrastructure to a “smart grid” to support
two-way communication between electric genera-
tion, transmission and distribution infrastructure,
and consumers of power [1]. Many utilities are
transforming their networks to accommodate estab-
lished and emerging applications on a common, inte-
grated network based on Internet Protocol (IP),
primarily for reasons of cost efficiency and flexibility.
The use of IP networking brings the security chal-
lenges associated with this technology.

88 Bell Labs Technical Journal DOI: 10.1002/bltj

Smart Grid Architecture
A logical reference architecture for smart grid is
presented in [22], illustrating logical domains of mar-
kets, operations, service providers, bulk generation,
transmission, distribution, and the customer. For our
purposes, we focus on the customer, operations,
transmission, and distribution domains. Figure 1 pro-
vides a simplified abstraction of a smart grid architec-
ture [4].
The architecture includes operational centers and
transmission substations (which may be manned or
unmanned) connected by a wide area network
(WAN). A field area network (FAN) extends the net-
work connectivity to field devices including remote
distribution nodes and meters at customer premises.
In some cases, a local neighborhood area network
(NAN) may be deployed between the FAN and cus-
tomer premises, connecting multiple customers to a
common local network.
Emerging SG Applications
New and emerging smart grid applications such as
advanced metering infrastructure (AMI), syn-
chrophasors, distribution automation (DA), auto-
mated demand response, electric vehicles, and
microgrid management are described in [6].
Advanced metering infrastructure provides two-
way communications for meter reading, remote
management, outage notifications, power quality
information (which can be used for grid control and
anomaly detection), and communication of pricing
information from the smart grid to the meter (which
can be used to inform consumers about the billing
implications of their usage decisions, and in some
cases provide for utility control of consumer load).
Meters may also support connectivity to devices in
the home.
Distribution automation (DA) is concerned with
the remote control of distribution devices including
switches, voltage and phase regulation devices, capaci-
tor banks, and other monitoring and management
functions in the distribution network. Historically,
power utilities have usually managed a limited num-
ber of monitoring and control points—for example, a
limited number of key substations—numbering in the
hundreds for larger utilities. In comparison, DA will
involve connecting tens of thousands of endpoints,
which will be a challenge for the legacy network
infrastructure.
Another key emerging application is demand
response (DR) which aims to affect a degree of control
over customer usage and to adapt demand to supply.
The smart grid may include and/or connect to “micro
grids” which are managed by small organizations or
individuals. A micro grid, with its own generation,
storage, power lines, and loads, is a subsystem of the
larger utility grid.
Established Applications
Among established power grid applications,
supervisory control and data acquisition (SCADA) and
teleprotection are key applications. Teleprotection
typically refers to the use of signal-aided relay-to-relay
communication between adjoining substations (i.e.,
substations connected by a transmission line). If pro-
tection equipment at either end detects a fault, the
other end is notified, and protective actions are taken
(such as tripping a circuit breaker). SCADA for the
power grid involves field data acquisition and transfer
to centralized systems for monitoring and control of
power grid components, including remote actuators
and sensors. An overview of the SCADA architecture
and of security issues associated with SCADA is pro-
vided in [26], including the observation that legacy
SCADA protocols (such as Modbus* or Distributed
Network Protocol 3 (DNP3) for example) do not have
default security features such as authentication or
encryption. A standard is specified in [11] to address
security aspects of SCADA protocols specified in [10].
In addition to the applications discussed above,
[6] provides an overview of other key applications
widely established and used for power grid manage-
ment, including mobile workforce management,
enterprise voice, push-to-talk (PTT), and closed cir-
cuit television (CCTV) for video surveillance and
teleprotection.
Wider Context
There is more to smart grid security than cyber-
security for the smart grid networks themselves. The util-
ity companies are enterprises in their own right,
requiring security governance, including information secu-
rity management systems (ISMS). Security governance
DOI: 10.1002/bltj Bell Labs Technical Journal 89
 Alternate,
renewable
energy
source
To regional
or national grid Transmission
substation
Storage
Large scale
Bulk power Transmission Distribution Large DER
(PV, wind,
generation substation substation business, diesel, UPS,
industrial CHP, …)
Transmission complex

transmission lines
substation

Feeder

Extra high and high voltage

Bulk power Transmission Distribution PV
substation Residence
generation substation

Medium voltage and

(sub)-transmission lines
Transmission
substation
Feeder
Thermal (coal, gas),
hydro-electric, Business
nuclear PHEV
Residence
Wind,
PV, Storage DER
Transformer(s) bio mass, Alternate,
Micro-generation
hydro, renewable
(PV, …)
tidal, energy
Generator source
fuel cell,
…

CHP—Combined heat and power

DER—Distributed energy resource (Hierarchy of)
PHEV—Plug-in (hybrid) electric vehicle micro grids
PV—Photovoltaic (cell)
UPS—Uninterruptible power supply

Figure 1.
Generation, transmission, and distribution in smart grid.
includes policies, training, risk management, compli-
ance, operations security, business continuity plan-
ning, and many other aspects. Developing these
human-focused procedures takes time—and needs to
take time—to ensure that it is done correctly. [7]
Furthermore, many (if not most) of the larger utility
companies will have significant in-house development
or integration—so supply chain security and applica-
tion security are crucial. Many will use data centers
and call centers, and may be consolidating and evolv-
ing to the use of virtualization and migration to cloud-
based deployment models. Utility companies also
have a significant mobile workforce, requiring secure
communications while in the field. The range of secu-
rity aspects to be addressed by a smart grid utility
company are very broad, and some aspects are rela-
tively new and still rapidly evolving.
Smart Grid Security Issues
Security for critical infrastructure (including util-
ity companies) is a very broad concern and involves
many aspects including:
• Physical security of plant, equipment, and net-
works.
• Cyber security for networking and computing.
• Security management for the corporation or
enterprise itself.
• Specific security issues for supervisory and control
applications and networks (SCADA).
• Specific security issues for endpoints (including
intelligent electronic devices (IEDs) and meters).
The evolution to a smart grid increases the focus on
security. The smart grid will be characterized by a two-
way flow of electricity and information [7] and the use
of communications and distributed computing. The
smart grid can also be characterized as “a network of
networks.” These aspects introduce new threat vectors,
compared with legacy electricity networks. The con-
vergence of the information and communications
infrastructure with the electric power grid introduces
new security and privacy-related challenges [23]. As
utilities continue to leverage information technology,
especially for the smart grid, they also expose their
infrastructure to all of the risks and threats associated
with information technology in general. At the same
time, critical infrastructure presents a particularly
attractive target to potential attackers.
The smart grid will bring security benefits as well
as security risks. The smart grid continuously monitors
itself to detect unsafe or insecure situations that could
detract from its reliability and safe operation [7].
Security Goals
Key goals for security include reducing risks and
costs. Generally, security is significantly less costly if it
is addressed at early stages (requirements, architec-
ture, design) of systems development rather than
being added in later stages. The principle of “Security
by Design” (or SbD) is well established, and seeks to
provide a framework for addressing security from the
outset, in the initial phases of development.
Security is essentially about risk management.
The level of security employed should be driven by
the level of risk—where risk includes both the likeli-
hood and the impact of an attack. There are risks asso-
ciated with compromising the confidentiality,
integrity, and availability of information and services.
A key goal of security management should be to
reduce the costs associated with security. This includes
the cost of security itself, and the costs associated with
security breaches. Costs associated with security
include;
• Personnel costs,
• Appliance costs,
• Software costs,
• Administrative costs, and
• Costs associated with security breaches.
Security management involves balancing the cost
of security against the cost of security breaches, based
on risk assessment of breaches, taking into account
their likelihood and impact. Costs increase as com-
plexity increases in conjunction with the prolifera-
tion of equipment and inconsistencies among device
types and software versions.
No security solution can be absolute. There are
always potential ways to contravene any security con-
trol, especially since complex systems can have
unknown as well as known vulnerabilities. To com-
pensate for this, most enterprises (including power
grid utility companies) will generally employ the
“defense-in-depth” principle, and implement multiple
DOI: 10.1002/bltj Bell Labs Technical Journal 91
layers of security to protect their network, systems,
information and enterprise. As such, defense-in-depth
is a goal in its own right. Defense-in-depth involves
layered security controls of different types:
• Physical, including barriers, locks, and CCTV.
• Personnel-related, including screening, security
awareness and training, and organizational
aspects.
• Procedural, concerning policies, internal standards,
and procedures, and
• Technical, for example, access control, firewalls,
intrusion detection and prevention, cryptography
and anti-malware applications.
Defense-in-depth starts with the assumption that
no one control will be adequate to defeat all attacks,
so the attacker is presented with subsequent layers of
security to delay and deter the attack.
Risk Factors
The smart grid represents an increase in com-
plexity compared to legacy power grid systems and
communications networks, including a high degree
of heterogeneity of platforms and devices, and widely
disparate levels of computational power at nodes
throughout the grid (e.g., an IED compared to a
SCADA system). These factors can mean that there is
a higher density of vulnerabilities and more difficulty
in identifying and resolving vulnerabilities.
The smart grid also extends the distributed nature
of the power grid communications network and sys-
tems to include a vastly increased population of end-
points (including meters and remote sensors or
actuators) and a higher degree of interconnectivity.
The distribution of the components of the architec-
ture extends beyond the utility corporation bounda-
ries and onto the customer premises where devices
are deployed in an unsecured environment.
The extended distributed network is used to col-
lect a wider scope of information, including customer
data potentially subject to privacy regulations. There
are risks to the confidentiality, integrity and availabil-
ity of the distributed data in situ and in transit.
Further, the distributed nature of the smart grid attests
to the fact that the utility company’s workforce
includes a mobile population, possibly including con-
tracted third-party personnel, all potentially using
mobile computing devices.
92 Bell Labs Technical Journal DOI: 10.1002/bltj
The smart grid exists in an evolving threat land-
scape where critical infrastructure is an increasingly
attractive target for potential attackers, and where the
utility is exposed to general information and com-
munication technology (ICT) threats (e.g., denial of
service attacks) as well as domain-specific attacks (e.g.,
targeted malware such as Stuxnet). Recent surveys
[3, 20] found that the number of critical infrastructure
companies (which responded to the survey) from
across the globe and in multiple sectors which
reported large-scale DoS attacks increased from 54
percent to 80 percent in one year, and a similar
increase was reported for infiltration attacks.
At the same time, the smart grid architecture itself
is evolving. New applications are emerging and estab-
lished applications continue to evolve, and the degree
of integration between applications may increase.
Newer variants of domain application protocols
(including SCADA and automatic meter reading
(AMR)/AMI protocols) may be introduced while
legacy variants may need to be maintained for a con-
siderable period of time. The mix of legacy technolo-
gies and newer technologies can be a risk factor.
Threats
At a high level, the smart grid may be subject to a
wide range of business threats, of which we present
some examples below.
• Loss of situational awareness. Secure, reliable,
and real time situational awareness is a critical
operational requirement for power grids, due to
the critical nature of the service and the risk of
cascading failures and rapid development of inci-
dents. Loss of this capability is a key high-level
threat that should be considered. Any technical
threat to situational awareness—including delib-
erate or accidental outages—must be understood
and mitigated with appropriate controls. This is
as much a security issue as a reliability issue.
• Theft of service (also known as non-technical losses).
The utility company relies on secure, reliable and
trustworthy metering to be able to correctly bill
for service. Compromise of meters (through hard-
ware tampering or software hacking), of the
metering networking infrastructure, or even of
the metering and billing systems themselves
should be considered. Examples of appropriate
 technical controls are AMI encryption (for
integrity and confidentiality), tamper-proof meter
hardware, device authentication, and hardened
platforms for metering and billing systems.
• Service impairment. This threat includes aspects
such as denial of service, compromise of service,
and corruption of data related to service. Critical
infrastructure utility companies are subject to fre-
quent and increasingly aggressive denial of ser-
vice attacks. These are currently focused on the
Internet interfaces, but in the future they could
potentially be directed at application interfaces or
internal systems using attack vectors such as the
customer meter, employee mobile devices (lap-
tops, USB drives), or wireless FAN nodes. The
Stuxnet [9] malware and the Aurora Test [5]
were graphic illustrations of the potential risk of
impairment of operations and even of physical
destruction of equipment. Forty percent of critical
infrastructure companies which responded to a
McAfee survey [20] reported finding Stuxnet in
their systems, with the number increasing to 47
percent in the electric sector specifically.
• Breach of privacy. Utility companies manage cus-
tomer-related information and other information
that may be subject to privacy regulation which,
if disclosed, could result in punitive penalties or at
least damage the corporate image. Confidentiality
controls for privacy-relevant information are cru-
cial, and should apply to information in situ as
well as in transit.
• Infiltration. This business threat relates to the
penetration of the secure perimeter by an unau-
thorized party, including actions such as scanning,
probing, mapping of networks and systems, and
even taking control of functions. Infiltration is
closely linked to the threat of unauthorized
access, and threat can allow other threats to be
exercised (for example, service impairment).
• Unauthorized access. This is a very broad threat that
can cover a very wide range of specific issues
including access to data, systems, applications,
networks, devices, and physical sites. Appropriate
access controls are required for every type of
access, and in general the principles of least privi-
lege and separation of duties should apply. Access
controls should include strong authentication
(e.g., multi-factor authentication for access to
critical systems and for remote access), role-based
access control, device authentication, and net-
work access control (NAC). Centralized identity
management can reduce administrative costs and
improve security for access control solutions.
Trends and Best Practices
With the emergence of targeted malware such as
Stuxnet, and the widely-reported increase in denial of
service attacks on critical infrastructure companies
(c.f. [3] and [20]), we observe a heightened awareness
of security and an evolution of security posture across
the industry. This can also be driven by regulation. In
some jurisdictions, domain-specific regulations, stan-
dards, and guidelines have begun to emerge. The
North American Electric Reliability Corporation
(NERC) critical infrastructure protection (CIP) stan-
dards in the U.S. [18] offer one example.
The Internet remains a priority threat vector, and
of course de facto controls such as firewalls are widely
employed. Beyond basic firewalling, utility companies
are employing demilitarized zones (DMZs), anti-DoS
and intrusion detection systems (IDSs)/intrusion pro-
tection systems (IPSs) to protect their boundaries.
IDS/IPS capabilities can include deep packet inspec-
tion (DPI) features, and detection algorithms based on
signatures, anomalies, and behaviors. Firewalls and
IDS/IPS systems can include application-aware features
for protocols specific to the critical infrastructure and
control systems domains. Advanced techniques such
as the use of honeypot/honeynet can be used to divert
and observe attacks. Remote access to the WAN
through external networks should be via an encrypted
virtual private network (VPN) with strong access con-
trol including multi-factor authentication.
These controls are also being used on internal as
well as external boundaries. Power grid utility com-
panies generally have a control network (for applica-
tions such as SCADA, AMI, DR, DA and transmission
automation (TA) discussed earlier), and a corporate
network for enterprise applications including customer-
related applications. Just as the corporate network
should be separated from the Internet by a DMZ, so
also should the control network be separated from
DOI: 10.1002/bltj Bell Labs Technical Journal 93
the corporate network. Systems that need to connect
to both the corporate and control networks can be
hosted in this DMZ.
Many utility companies are executing on network
transformation to IP or IP/Multiprotocol Label Switching
(MPLS) and are addressing security as a part of that ini-
tiative. This includes the use of VPNs for network seg-
mentation, where physical network separation may
previously have been used. Traffic separation tech-
niques vary from the physical (e.g., separate lines or
wavelengths) to the logical (e.g., VPNs). Logical traffic
separation can involve virtual local area networks
(VLANs), virtual private LAN service (VPLS), virtual
private routed network (VPRN) or other VPN tech-
niques. Separation of traffic between (logically or physi-
cally) separate networks can involve access control lists,
filters (in routers or firewalls), and intrusion detection/
prevention. Logical separation is more cost efficient than
physical, because it streamlines capital and operational
costs by avoiding multiple instances of physical devices.
One approach is to use IP/MPLS with MPLS VPNs for
traffic separation with overlaid encryption (e.g., using
Internet Protocol security (IPsec) or group-based
encryption). Physically separate networks are not cost
effective (particularly as new applications are added) so
utilities can benefit from converging onto a common
physical network while maintaining the required traf-
fic separation and network segmentation using logical
techniques. MPLS is ideally suited for this, supporting
multiple protocols (e.g., Synchronous Optical Network
(SONET), Asynchronous Transfer Mode (ATM), Time
Division Multiplexing (TDM) and Ethernet) on a com-
mon infrastructure while also supporting multiple
options for virtual networking: virtual leased lines
(VLLs), virtual private LAN service (VPLS) and virtual
private routed network (VPRN). MPLS provides secure
traffic isolation, preventing attacks between VPNs or
from a VPN to the MPLS control network. MPLS secu-
rity also involves device security (physical and logical
access control) including security at the administration
and management interfaces. See [2] for further discus-
sion of the security aspects of MPLS in the context of
use for critical infrastructure.
In general, there is growing awareness of
the weaknesses of de facto access controls such as
94 Bell Labs Technical Journal DOI: 10.1002/bltj
password-based authentication. Password policies are
being strengthened. The principles of least privilege and
separation of duties are being employed to limit the
privileges of individual accounts and to address non-
repudiation risks. Multi-factor authentication, using
tokens or biometrics for example, is being embraced.
The use of cryptography is increasing. WAN/FAN
networks are often encrypted, or encrypted VPNs are
used for critical traffic (e.g., SCADA). Cryptographic
authentication of users, systems, and devices is being
used to a wider extent. Remote access uses encrypted
VPNs. Critical data is stored and transmitted with
encryption. When choosing the right cryptographic
solution (from the range of possible options including
optical layer 1 encryption and IPsec), the delay
penalty must be considered against the latency
requirements for the particular application.
Some utility companies are consolidating their
data and operations centers, and are addressing the
security aspects of such transformations. Data center
consolidation can be an opportunity to employ geo-
graphical redundancy for business continuity and dis-
aster recovery. Data and operations centers require
enhanced physical security including physical and
logical access controls—for example, the use of bio-
metric and/or smartcard authentication. The use of
virtualization, or even cloud computing, techniques in
data centers brings its own security challenges which
may be addressed through secure VLAN configura-
tion, use of virtual security appliances, encryption
(e.g., of virtual machine images) and other technical
controls.
Anti-malware controls are generally used, but are
being strengthened to counter the threats of novel
and stealthy viruses or worms such as Stuxnet. At the
same time, there is heightened awareness of the criti-
cal need to eliminate vulnerabilities, including zero-
day vulnerabilities that such malware can exploit. This
includes aggressive patching (to close known vulner-
abilities as soon as possible) and device or system
hardening (e.g., disabling unused services) to reduce
avenues for attack. There may be particular difficulties
with availability of patches for legacy systems, and in
such cases it may be necessary to consider compen-
sating by installing controls to mitigate vulnerabilities
that cannot be directly removed. All of this is in con-
junction with improvements in incident management
and vulnerability management policies and processes,
as utility companies “catch up” with other ICT com-
panies and enterprises on best practices in terms of
security management.
The fact that Stuxnet was most likely introduced
via a mobile device (USB drive) has focused attention
on mobile device security as a critical dimension.
Utility personnel are often mobile and utilize a range
of devices including laptop computers, USB drives, and
smartphones. Encrypted VPN with access control is
not adequate for full protection. VPN access control
can be breached (particularly if it relies mainly on pass-
word authentication), and mobile devices may be
directly connected to the network when brought on
site. Mobile device security includes hardening, cen-
tralized management, enhanced access control (e.g.,
multifactor authentication), device firewalling, and
anti-virus scans. Enhanced techniques can include disk
encryption and the use of anti-theft mechanisms for
remote disabling or even tracking. All of this must be
done in the context of clear policies and strong aware-
ness and training for personnel on the risks and
responsibilities associated with mobile devices.
Power grid networks include distributed end-
points such as meters and intelligent electronic devices
(IEDs). Endpoint security can include endpoint
authentication, tamper-proofing, use of cryptography,
physical security, software integrity checks, and
remote attestation. Since endpoints are generally
deployed in unsecured or less secure environments
(e.g., customer premises, unstaffed substations), they
should be secured using cryptographic techniques.
This includes cryptographic device authentication,
encrypted data communications, and digitally signed
software for integrity. The smart grid can involve
extending the utility network (even the IP networking)
to the customer premises where the meter is an end-
point deployed in an essentially unsecured environment.
As such, the meter itself must be hardened against secu-
rity threats. Threats can include hacking, tampering, or
cloning. Meters should (mutually) authenticate with
servers, and the cryptographic keys used should be
stored securely in tamper-proof hardware. Ideally the
meter should be remotely manageable, including
upgrades. Secure booting should involve checking the
digital signature of software at boot time. Ideally
the meter should support remote attestation to be able
to securely affirm that it is running a trusted version
of firmware and software (with authentication and
integrity guaranteed by the use of a digital signature).
The use of cryptographic techniques implies that key
management must be achieved in a secure way,
which can be difficult for devices where components
are sourced, assembled, and tested by multiple agents
in the supply chain. These capabilities require sup-
port by meter vendors—however this may be diffi-
cult to achieve consistently across the range of
vendors providing proprietary meters and meter read-
ing implementations.
Optical networks can be vulnerable to eaves-
dropping. This is exacerbated by the wide geographi-
cal distribution, and any use of leased optical lines
where the utility is not entirely in control of security.
For confidentiality and message integrity, the WAN
should be encrypted. The use of optical devices that
encrypt at the optical layer can be considered, but this
may be costly to deploy and may not be applicable
for leased optical lines, so generally the utility will
employ encryption at a higher layer. IP and MPLS do
not natively encrypt traffic. Encryption can be done at
the network layer or at higher layers using IPsec,
Secure Sockets Layer (SSL) or other solutions. IPsec is
a natural choice for IP/MPLS encryption, but the com-
plexity and administration costs do not scale well for
mesh networks.
WAN security depends not only on technical con-
trols applied to the WAN itself (e.g., encryption, access
control, traffic isolation). The security of the WAN
requires “defense-in-depth” and the use of security
controls across the physical, procedural, personnel,
and technical aspects of access. WAN devices and links
should be physically secured. Physical and logical
access controls are required. Overall security should
be grounded in a wider security management system
for the utility enterprise, covering security governance,
policies, compliance, training and awareness etc.
Security for smart grid applications and applica-
tion protocols is an important focus area. For example,
DOI: 10.1002/bltj Bell Labs Technical Journal 95
International Engineering Consortium (IEC) 62351 is
a standard that addresses security aspects of data com-
munication for power systems, including SCADA pro-
tocols such as IEC 61850, as well as Inter-Control
Center Communications Protocol (ICCP) and DNP3.
Authentication is achieved through digital signatures.
For the Transmission Control Protocol (TCP) and IP-
based protocols (e.g., the Manufacturing Messaging
Specification (MMS) part of IEC 61850), confidential-
ity and message authentication can be achieved
through optional use of Transport Layer Security (TLS)
for devices that have the computational resources to
cope with the load, within latency constraints. For
non-routable datagram protocols (e.g., the Generic
Object Oriented Substation Event (GOOSE) part of
IEC 61850) which have low-latency requirements
(e.g., 4 ms), only digital signature authentication is
specified by IEC 62351. A secure transport protocol
for the smart grid is proposed in [16], and [17] dis-
cusses a data-centric architecture for smart grid appli-
cations including aspects of security.
As stated earlier for WAN security, the security of
the field area network requires “defense-in-depth”
and the use of security controls for physical, proce-
dural, personnel, and technical aspects. For wireless
FANs, wireless standards generally cover both authen-
tication and traffic encryption. For example, IEEE
802.16(e) medium access control (MAC) specifies
Worldwide Interoperability for Microwave Access
(WiMAX) security through secure key exchange and
the use of Advanced Encryption Standard/Data
Encryption Standard (AES/DES) encryption. For Long
Term Evolution (LTE), the 3rd Generation Partnership
Project (3GPP) standards specify the same approach
as for third generation (3G) Universal Mobile
Telecommunications System (UMTS) and Wideband
Code Division Multiple Access (WCDMA) systems
using a stream-based algorithm (KASUMI) with regu-
lar changes to the key to ensure the key stream is not
reused. FAN devices and links should be physically
secured. Physical and logical access controls are
required. Overall security should be grounded in a
wider security management system for the utility
enterprise, covering security governance, policies,
compliance, training, and awareness.
96 Bell Labs Technical Journal DOI: 10.1002/bltj
The overall trend is that, as networking and com-
puting are more widely used, utility companies are
implementing ICT security best practices, albeit at a
slow or uneven pace. Sometimes this is driven by
regulation, and otherwise it is driven in the context of
threats and the fact that utilities are under increasing
attack globally. Generally there is an increasing
emphasis on compliance and governance aspects,
with companies starting to consider embracing secu-
rity management techniques from standards such as
the International Organization for Standardization
27000 series (ISO27K), or even seeking formal certi-
fication under such standards.
Methodology
When assessing security for a utility company
embarking on transformation of network and opera-
tions for support the smart grid, the Bell Labs Advisory
Service (BLAS) employs a methodology that is
grounded in the Bell Labs Security by Design (SbD)
methodology used widely for Alcatel-Lucent product
and solution development. The SbD methodology
involves component parts that provide different per-
spectives on security. Similarly, the methodology used
for assessing smart grid security also involves separate
parts that address the target from different perspec-
tives. The main components of the methodology (illus-
trated in Figure 2) are threat analysis, baseline
assessment, tools analysis, and architecture assessment.
Threat Analysis
The purpose of threat analysis is to identify poten-
tial vulnerabilities, and to identify potential counter-
measures for those vulnerabilities. The threat analysis
process is a structured semi-formal top-down assess-
ment based on standards. The Bell Labs Advisory
Service employs an Alcatel-Lucent internal standard
based on approaches described in the literature
(including [8, 13–15, 21, 24]) customized for Alcatel-
Lucent use.
The activities and results of the threat analysis
include:
1. Defining the business risk (in terms of a priori-
tized set of business threats).
2. Identifying the critical assets of the product or
solution.
 Threat analysis
Top-down, structured, standards-based and risk-oriented analysis to
identify and prioritize critical-infrastructure threats, attack vectors,
vulnerabilities and countermeasures

Tools analysis
Architecture assessment
Assess results from
Assess use of technical
test/audit tools, e.g.,
security enablers such as
Utility penetration testing,
firewalls, IPS, AAA,
networks vulnerability scanning,
encryption, DMZ, and
offline configuration,
VPN.
and auditing.

Baseline assessment
Evaluate the target against a range of authoritative standards, recommendations, and
best practices pertinent to the domain, e.g., NIST, ISO, NERC CIP.

AAA—Authorization, authentication, and accounting ISO—International Organization for Standardization

CIP—Critical infrastructure protection NERC—North American Electric Reliability Corporation
DMZ—Demilitarized zone NIST—National Institute of Standards and Technology
IPS—Intrusion protection system VPN—Virtual private network

Figure 2.
Overview of assessment methodology.

3. Understanding the threats that the critical assets
are exposed to.
4. Recognizing potential vulnerabilities and con-
firming known vulnerabilities.
5. Prioritizing the vulnerabilities, based on their
associated risk.
6. Determining the countermeasures needed to
thwart the key vulnerabilities.
7. Performing a business impact analysis to deter-
mine when or if to develop the security features
needed to implement the countermeasures.
The first task that is performed in a threat analysis
is to define the business risk, which is the business
threat environment surrounding a product or solution
when it is deployed in the production environment. A
business threat is defined as an adversary’s goal or
motive for attacking the business or organization. To
prevent the business threat from being realized, pro-
tective measures must be in place. Example business
threats include theft of content, denial of service, eaves-
dropping, and unauthorized disclosure of information.
When defining business risk, it is useful to consider the
threat agents and threat vectors (the avenues by which
a threat may be realized). For critical infrastructure,
potential threat agents could include company employ-
ees, terrorists, espionage agents, extortionists, hackers,
cyber-criminals, customers, and outsourced mainte-
nance staff. Potential threat vectors (or potential chan-
nels of attack) could include the Internet, wireless
access points, the enterprise intranet, mobile devices
(including USB devices), remote endpoints (including
meters), the supply chain, and the company’s own sys-
tems development organization. Several sources may
be consulted to identify business threats that will be
present in the deployed environment. These can
include industry consortia or regulations for the prod-
uct or solution, customer vertical industries (e.g., finan-
cial, healthcare, manufacturing), standards bodies that

DOI: 10.1002/bltj Bell Labs Technical Journal 97

address the technology used or provided by the prod-
uct or solution, and consultations with or historical
knowledge of past targets. The output of this stage is a
set of threats constituting the business risk for the
potential target.
After defining the business risk, the next stage of
the threat analysis involves listing the assets of the
potential target, and determining the level of detail
around which target assets will be defined. Critical
assets could include sites (including headquarters,
datacenters, and substations), networks (including cor-
porate and control networks), systems (including
operations, business, and customer-related systems)
and devices (including mobile devices, remote end-
points, networking devices, security devices, and
smart meters).
Once the information assets are identified, they
are examined for potential exposure to business risk
by associating the applicable business threats to each
asset. The purpose of this is to develop a comprehen-
sive list of assets and the business threats that they
are potentially exposed to; therefore, existing counter-
measures should be temporarily disregarded when
performing this step.
Based on the threat exposures identified above,
the next step is to assess the possible attacks against an
asset in order to realize a threat. In order to perform
risk analysis and vulnerability prioritization, the asses-
sor must consider the target from the perspective of a
potential attacker. The attacker has a high-level goal
or motive in mind—to realize one of the business
threats (e.g., theft of content) against the product or
solution. In order to do this, an attack would be made
against an asset. The objective of the attack is to com-
promise the asset in some way in order to realize the
business threat.
A risk analysis is performed to understand the
urgency of implementing a countermeasure using fac-
tors such as the attractiveness of the target, ease of
attack, and the impact of a successful attack. The attrac-
tiveness of the target considers how motivated an
attacker would be to compromise the target—which can
be related to the potential reward, the geopolitical or
military significance of the target, the value of the infor-
mation and the general public’s interest in information
98 Bell Labs Technical Journal DOI: 10.1002/bltj
on the target (including privacy-related aspects). The
exploitability, or ease of attack, considers how easy it
would be for an attacker to accomplish his objective.
This can be related to the existence of off-the-shelf tools
(even if they are only accessible by the cyber under-
ground), the level of technical expertise required to
exploit the vulnerability, and the attacker’s accessibility
to the target. The impact of a successful attack considers
the cost or amount of damage resulting from a success-
ful attack, including potential revenue impact, regulatory
impact, impact on reputation with customers, impact
on relationship with business partners or impact on busi-
ness model.
At this stage, a set of vulnerabilities has been
established, and prioritized according to risk. The next
step is to propose countermeasures for the vulnera-
bilities (or at least for those that exceed an agreed
level of priority or risk). Potential countermeasures
can be derived from sources including published sets
of controls (for example, [14, 18, 19, 22, 25, 27]), or
through proposals by domain experts and security
experts. In many cases, de facto controls such as fire-
walls, encryption, access control, intrusion detection,
and anti-malware will be obvious candidates as coun-
termeasures. Often, the defense-in-depth principle
may lead to proposal of more than one overlapping
countermeasure.
Once the list of proposed countermeasures is
established, a business decision process is imple-
mented to decide which countermeasures to implement,
taking into account such things as cost, return on
investment, time to market, required resource com-
mitments, and competitive advantage. Risks may be
remediated (by implementing the related counter-
measures), accepted (by choosing not to address
them) or transferred (for example, by investing in
insurance against the risk). Ultimately, the set of
accepted countermeasures become requirements for
the product, solution, or enterprise.
Examples of relevant threats, attacks, and candi-
date countermeasures are illustrated in Figure 3.
Baseline Assessment
The baseline assessment measures the target
against a wide range of best practices. The best practices
 IP/MPLS

Threats/attacks: Eavesdropping, message insertion, breach of privacy

Countermeasures: Encryption, secure traffic separation (e.g., MPLS VPRNs),
firewalling, internal DMZs
OPERATION
CENTER
MICROWAVE
Threats/Attacks: Backdoors, unauthorized
access, malware insertion
+ Countermeasures: Application hardening,
− proactive vulnerability management, multi-factor
ENERGY authentication, host IDS/IPS
STORAGE

GENERATION
OPTIC IP/MPLS Threats/attacks: Eavesdropping,
unauthorized access
Countermeasures: Mutual authentication,
domain-specific protocol security (e.g., IEC
4G-LTE
WiMAX 62351)
INTEGRATED
3G RENEWABLE
TRANSMISSION PMR/LMR

SM
AR
TC
ITY
MICRO
FTTH GENERATION
DISTRIBUTION PLC
Threats/attacks: Unauthorized access
Radio + Threats/attacks: Theft of service, meter hacking, tampering,
Countermeasures: Physical security, secure −
management interfaces, role-based access control ELECTRIC ENERGY cloning
VEHICLE STORAGE Countermeasures: Mutual authentication, tamper-proof
hardware, encryption, secure-boot, remote management,
remote attestation

3G—Third generation IEC—International Engineering Consortium MPLS—Multiprotocol Label Switching

4G—Fourth generation IP—Internet Protocol PLC—Power line communications
DMZ—Demilitarized zone IPS—Intrusion protection system PMR—Private mobile radio
FTTH—Fiber to the home LMR—Land mobile radio VPRN—Virtual private routed network
IDS—Intrusion detection system LTE—Long Term Evolution WiMAX—Worldwide Interoperability for Microwave Access

Figure 3.
Example threats, attacks, and candidate countermeasures.
are derived from authoritative work by industry
bodies (e.g., the National Institute of Standards and
Technology (NIST), ISO, and NERC) and against the
Bell Labs security knowledge base.
Below, we describe some sources of best practices
or baseline security requirements in the public
domain. Some of these are specific to the United
States, but are nevertheless relevant references for
assessments of any target regardless of the jurisdic-
tion of deployment.
In [22], the United States National Institute of
Standards and Technology (NIST) specifies security
controls for Smart Grid Cyber Security, based on secu-
rity controls defined in [25] (originally for U.S. federal
information systems generally, but considered to be
more broadly applicable).
The North American Electric Reliability Corporation
(NERC) specifies a high-level set of security controls in
[18] that are specifically written for critical infra-
structure. Eight security standards are included, with
110 requirements.
A wide-ranging set of 133 security controls for
information security management systems (ISMS) are
specified by the International Organization for
Standardization (ISO) and International Electrotechnical
Commission (IEC) in [12].
The U.S. Department of Homeland Security
(DHS) specified a catalog of controls for critical infra-
structure control systems in [27].
The U.S. Comprehensive National Cybersecurity
Initiative (CNCI) has derived a set of 20 high level
controls based on a prioritization of [25] from NIST.
Bell Labs maintains a knowledge base of security
controls, best practices, and baseline security require-
ments including over 800 at the product level and
over 70 higher-level requirements for solution
deployments. These are a wide-ranging set of best
practices for broad coverage and wide applicability
across all Alcatel-Lucent products, and many are
applicable to products that are relevant for use in criti-
cal infrastructure deployments.
Considered in aggregate, the references above
represent a very large set of potential controls or best
practices to consider, which offer a high degree of
overlap between the sources. Expert judgement can
100 Bell Labs Technical Journal DOI: 10.1002/bltj
be used to select the appropriate sources, to filter the
resources for applicability, and to prioritize the con-
trols. The baseline controls can be used in an explicit
and formal manner, to survey the target for compli-
ance. Alternatively, a less-formal approach can be
taken, using the knowledge base to structure the dia-
logue with the target of the assessment, and as a ref-
erence for grounding findings and recommendations.
Tools Analysis
The tools analysis component of the assessment
methodology involves the use of tools to audit or test
the systems and networks of the target. Tools can be
active or passive, online or offline. A wide range of
potential tools could be brought to bear on the target.
Offline configuration analysis tools can audit the con-
figuration of network devices or systems for vulnera-
bilities. Vulnerability scanning tools can scan and
probe systems and networking devices. Tools can be
used to simulate different types of denial of service
attacks at different layers of the communications pro-
tocol stack. For application layer protocols, whether
domain-specific (e.g., SCADA protocols) or general
(e.g., Web protocols), protocol flooding and fuzzing
tools can be employed to stress the robustness of the
protocol implementation. Protocol fuzzing tools delib-
erately subject the target to malformed protocol mes-
sages to try to provoke errors that may crash the
device, impair its performance, or even potentially
allow execution of arbitrary code for a more precise
attack.
If the target of an assessment is an operational
network or enterprise, there will generally be judi-
cious constraints on the types of tools that can be
employed and the rules of engagement—obviously
any risk to the service should be avoided, and the
tools themselves can be considered a security risk.
When the target is a pre-deployment configuration
in a testing environment, potentially there is scope
for use of a wider range of tools, including more active
and aggressive options that endeavor to actually pene-
trate or impair the target.
Architecture Assessment
The architecture assessment component of the
assessment methodology can be a more informal and
flexible offline assessment of the current and/or pro-
posed architecture of the target. Often, architecture
proposals or even decisions will already have been
made considering factors other than security, and
these will of course have security implications. An
example could be a utility company that proposes to
migrate to a common integrated IP or MPLS network
for its corporate and control networks. The proposal
may originally arise from considerations of total cost
of ownership, performance, quality of service, flexi-
bility and future proofing. Security implications may
or may not have already been factors in the proposal
or decision, so must be assessed—for example, con-
sidering the fact that IP and MPLS do not natively
protect confidentiality through encryption. Other
aspects of architecture to consider include security
zoning (for example, the use of demilitarized zones
(DMZs)), placement of security appliances (including
firewalls, intrusion detection, and hardware encryp-
tion devices), technology choices (e.g., LTE for the
field area network), and deployment models (e.g., the
use of a private cloud deployment model in converged
data centers). Generally, the technical components of
the architecture will have been considered as assets in
the threat analysis component, and they will also map
to controls or best practices considered in the base-
line assessment component of the methodology.
Nevertheless, the architecture assessment component
of the methodology allows for a particular focus on
architectural perspectives, bringing to bear architec-
ture expertise and architectural approaches. Any
overlapping between the components of the assess-
ment methodology should be complementary to
avoid inefficiency.
Conclusion
An overall framework and methodology is effec-
tive in structuring and guiding assessment of security
for power grid transformations towards smart grid.
The methodology described here includes component
parts such as threat analysis and baseline assessment
that provide different perspectives on the target.
Security assessment for smart grid must consider not
only the specific new applications that smart grid
involves, but also established applications (such as
SCADA) and the wider context of the utility company
enterprise that envelops the smart grid network
operation.
Acknowledgements
The authors would like to thank Dr. Jayant
Deshpande and Dr. Frank Feather for their valuable
input.
*Trademarks
Modbus is a registered trademark of Schneider
Automation Inc.
References
[1] S. Acharya and K. C. Budka, “Tele-
communications in Vertical Markets: Challenges
and Opportunities,” Bell Labs Tech. J., 16:3
(2011), 1–4.
[2] A. Akyamac, J. Deshpande, and A. McGee,
“Achieving NERC CIP Compliance with Secure
MPLS Networks: A Bell Labs Memorandum,”
Alcatel-Lucent White Paper, Aug. 2010.
[3] S. Baker, S. Waterman, and G. Ivanov, In the
Crossfire: Critical Infrastructure in the Age of
Cyber War, McAfee, 2009.
[4] K. C. Budka, J. G. Deshpande, T. L. Doumi,
M. Madden, and T. Mew, “Communication
Network Architecture and Design Principles for
Smart Grids,” Bell Labs Tech. J., 15:2 (2010),
205–227.
[5] S. Cunningham, “Cyber Security for Industrial
Control Systems,” Power Engineering, Nov. 1,
2011, <http://www.power-
eng.com/articles/print/volume-115/issue-
11/features/cyber-security-for-industrial-
control-systems.html>.
[6] J. G. Deshpande, E. Kim, and M. Thottan,
“Differentiated Services QoS in Smart Grid
Communication Networks,” Bell Labs Tech. J.,
16:3 (2011), 61–81.
[7] Electric Power Research Institute (EPRI), Report
to NIST on the Smart Grid Interoperability
Standards Roadmap, June 2009.
[8] European Telecommunications Standards
Institute, “Telecommunications and Internet
Converged Services and Protocols for Advanced
Networking (TISPAN), Methods and Protocols,
Part 1: Method and Proforma for Threat, Risk,
Vulnerability Analysis,” ETSI TS 102 165-1,
v4.2.1, Dec. 2006, <http://www.etsi.org>.
[9] N. Falliere, L. O. Murchu, and E. Chien,
“W32.Stuxnet Dossier,” v1.4, Symantec, Feb.
2011.
DOI: 10.1002/bltj Bell Labs Technical Journal 101
[10] International Electrotechnical Commission,
“Communication Networks and Systems in
Substations,” IEC TS 61850.
[11] International Electrotechnical Commission,
“Power Systems Management and Associated
Information Exchange: Data and
Communications Security,” IEC TS 62351, May
2007.
[12] International Organization for Standardization
and International Electrotechnical Commission,
“Information Technology, Security Techniques,
Information Security Management Systems,
Requirements,” ISO/IEC 27001, 2005.
[13] International Organization for Standardization
and International Electrotechnical Commission,
“Information Technology, Security Techniques,
Information Security Risk Management,”
ISO/IEC 27005, 2011.
[14] International Telecommunication Union,
Telecommunication Standardization Sector,
“Security Architecture for Systems Providing
End-to-End Communications,” ITU-T Rec.
X.805, Oct. 2003, <http://www.itu.int>.
[15] J. A. Jones, “An Introduction to Factor Analysis
of Information Risk (FAIR),” Risk Management
Insight White Paper, Draft, 2005,
<http://www.riskmanagementinsight.com/med
ia/documents/FAIR_Introduction.pdf>.
[16] Y.-J. Kim, V. Kolesnikov, H. Kim, and
M. Thottan, “SSTP: A Scalable and Secure
Transport Protocol for Smart Grid Data
Collection,” Proc. IEEE Internat. Conf. on Smart
Grid Commun. (SmartGridComm ’11)
(Brussels, Bel., 2011), pp. 161–166.
[17] Y.-J. Kim, M. Thottan, V. Kolesnikov, and
W. Lee, “A Secure Decentralized Data-Centric
Information Infrastructure for Smart Grid,”
IEEE Commun. Mag., 48:11 (2010), 58–65.
[18] North American Electric Reliability Corporation
(NERC), “Standards: Reliability Standards,”
“Critical Infrastructure Protection (CIP),”
<http://www.nerc.com/page.php?cid=2%7C20
standards>.
[19] SANS Institute, Twenty Critical Security
Controls for Effective Cyber Defense: Consensus
Audit Guidelines (CAG), v3.1, Oct. 3, 2011.
[20] P. Schneck, “In the Dark: Crucial Industries
Confront Cyberattacks,” McAfee Blog, Apr. 19,
2011.
[21] F. Swiderski and W. Snyder, Threat Modeling,
Microsoft Press, Redmond, WA, 2004.
[22] United States, Department of Commerce,
National Institute of Standards and Technology,
102 Bell Labs Technical Journal DOI: 10.1002/bltj
Information Technology Laboratory, Advanced
Network Technologies Division, Emerging and
Mobile Network Technologies Group, Smart
Grid Interoperability Panel, Cyber Security
Working Group, “Guidelines for Smart Grid
Cyber Security,” NISTIR 7628, Aug. 2010.
[23] United States, Department of Commerce,
National Institute of Standards and Technology,
Information Technology Laboratory, Advanced
Network Technologies Division, Emerging and
Mobile Network Technologies Group, Smart
Grid Interoperability Panel, Cyber Security
Working Group, Introduction to NISTIR 7628:
Guidelines for Smart Grid Cyber Security, Sept.
2010.
[24] United States, Department of Commerce,
National Institute of Standards and Technology,
Information Technology Laboratory, Computer
Security Division, “Risk Management Guide for
Information Technology Systems,” NIST SP 800-
30, July 2002.
[25] United States, Department of Commerce,
National Institute of Standards and Technology,
Information Technology Laboratory, Computer
Security Division, “Recommended Security
Controls for Federal Information Systems and
Organizations,” NIST SP 800-53, Rev. 3, Aug.
2009.
[26] United States, Department of Commerce,
National Institute of Standards and Technology,
Information Technology Laboratory, Computer
Security Division, “Guide to Industrial Control
Systems (ICS) Security,” NIST SP 800-82, June
2011.
[27] United States, Department of Homeland
Security, National Protection and Programs
Directorate, Office of Cyber Security and
Communications, National Cyber Security
Division, “Catalog of Control Systems Security:
Recommendations for Standards Developers,”
Sept. 2009, <www.us-cert.gov/control_systems
/pdf/Catalog_of_Control_Systems_Security_Rec
ommendations.pdf>.
(Manuscript approved May 2012)
ALAN J. MCBRIDE is a consulting member of technical
staff in Bell Labs CTO Security Technology
Office in Dublin, Ireland. He is a Certified
Information Systems Security Professional
(CISSP), and holds a B.S. degree in computer
science from Trinity College, University of
Dublin, in Ireland. Mr. McBride has worked in the
telecommunications domain for over 20 years,
primarily in the areas of network management and
security. His current areas of focus include security for
Cloud Computing and for Critical Infrastructure.

ANDREW R. MCGEE is a distinguished member of

technical staff in the Alcatel-Lucent Bell
Labs CTO Security Technology Office in
Murray Hill, New Jersey. He is a Certified
Information Systems Security Professional
(CISSP), a GIAC Certified Incident Handler
(GCIH), and is certified as a GIAC Reverse Engineering
Malware (GREM) analyst. Mr. McGee has over 20 years
of telecommunications experience and is currently
responsible for the development and analysis of
advanced security architectures and security services for
next-generation networks. In this capacity, Mr. McGee
has defined the Alcatel-Lucent corporate-wide threat
analysis methodology, performed threat and
vulnerability analyses, designed security architectures,
and defined detailed security requirements for next-
generation network (NGN) technologies such as
converged IP networks, third generation (3G) and
fourth generation (4G) cellular, Voice over Internet
Protocol (VoIP), Internet Protocol television (IPTV), and
critical infrastructure networks. Mr. McGee is
responsible for key security contributions to the ITU-T
and ISO/IEC standards bodies and holds three patents in
the areas of data networking and cyber-security.
Mr. McGee received a B.S. degree from Michigan State
University in East Lansing, and an M.S. degree from
Rutgers University in New Brunswick, New Jersey, both
in computer science. ◆

DOI: 10.1002/bltj Bell Labs Technical Journal 103