Cybersecurity Applications & Technology Conference For Homeland Security

Virtual Private Groups for Protecting Critical Infrastructure Networks∗

Richard C. O’Brien and Charles N. Payne, Jr.

Adventium Labs LLC
Minneapolis, MN 55082
richard.obrien@adventiumlabs.org
charles.payne@adventiumlabs.org

1. Introduction however, the landscape has changed. Proprietary network

protocols are being replaced by TCP/IP. DCS networks that
In an era when critical infrastructure networks are in- used to be isolated are now frequently connected to com-
creasingly less isolated and more accessible from open net- pany business LANs, perhaps via a firewall, perhaps not.
works, including the Internet, the air-gap security that these These business LANs are, in turn, connected to the Inter-
critical networks once enjoyed no longer exists. Malicious net as shown in Figure 1. SCADA networks that used to
individuals can exploit this network connectivity, in con- run on leased lines, now run over the Internet. As a result,
junction with security weaknesses in widely used, homoge- many critical infrastructure networks that used to be pro-
neous, COTS (commercial off-the-shelf) products, to pene- tected from the outside via an air-gap are now susceptible
trate deep within an organization’s critical networks. Such to remote attacks.
an attack on SCADA (Supervisory Control And Data Ac-
quisition) and Process Control networks could have dev-
astating consequences. This paper describes an approach,
Virtual Private Groups (VPGs), for creating and managing
a virtual air-gap between these networks and the environ-
ments in which they may operate.
After a brief description of the security issues that con-
front these networks, we describe our approach for address-
ing them. Many of the ideas presented here are the result
of work done while implementing a version of VPGs di-
rected towards critical infrastructure networks. In the pro-
cess of doing that work we made a number of advances in
managing policy for VPG and related mechanisms. These
advances are identified in Section 5 and Section 6.

2. Critical infrastructure networks Figure 1. A process control network

The critical infrastructure networks that we focus on in
this paper are SCADA and DCS (Distributed Control Sys-
tems) networks used in industrial process control. Histori-
cally, these networks originated as proprietary, isolated lo-
cal area networks (LANs). They ran their own proprietary
network protocols and remote sites were connected via pri-
vate networks. As such they were not vulnerable to at-
tacks from outside their networks and security of the net-
work was not a major concern. With the advent of the Inter-
net and the trend towards ubiquitous network connectivity,
∗ This work was funded primarily under DHS contract #FA8750-05-C-
0144 and DARPA contract #FA8750-07-C-0017.
While in many ways SCADA and DCS networks are be-
coming more like other Ethernet networks, in some impor-
tant ways, they remain very different. Because of their spe-
cific purpose and critical nature, they usually include a va-
riety of specialized computers and devices that have been
developed and certified to perform very specific processing
with a high-degree of reliability. Many of these devices are
legacy systems that cannot be easily modified. In addition,
the vendors of these devices are usually more concerned
with reliability than security, since security has not been an
issue in the past, and so may be reluctant to add features to
their systems that might affect availability or certification.

978-0-7695-3568-5/09 $25.00 © 2009 IEEE 118

DOI 10.1109/CATCH.2009.14
Reliability is also often supported by the use of redundant
network connections, so that failure of a network compo-
nent (e.g. NIC card or switch) does not prevent the system
from continuing to function.
3. Protecting Critical infrastructure networks
A promising approach to increasing the security of these
networks is to incorporate security features in unobtrusive
bump-in-the-wire devices such as a network interface card
or a network appliance. Such devices can protect the net-
work, without requiring any changes to the operation or cer-
tification of the application nodes they protect, by a combi-
nation of firewalling each critical node and authenticating
(and possibly encrypting) traffic between critical nodes. All
critical network traffic travels authenticated over the net-
work and only authenticated traffic is accepted by a criti-
cal node. In DCS networks that are monitoring and man-
aging local process control systems, authentication of the
traffic and its source, with replay protection, may be suffi-
cient since the actual data that is transmitted would be of
little use to an attacker. In instances, such as large scale
SCADA systems, where the data is being sent over the In-
ternet, encryption might also be used to limit the visibility
of an attacker into the state of the system.
One possibility for providing the authentication and en-
cryption needed with this approach is to use standard IPsec.
The maturity of public key infrastructures (PKI) has encour-
aged the widespread adoption of certificate-based virtual
private networks (VPNs), even when the target networks do
not require that level of assurance, so this often means set-
ting up a Public Key Infrastructure to create and distribute
private keys and certificates for each device. Peer-to-peer
security associations are then negotiated between any two
nodes that need to communicate with each other. While this
approach is workable, it has some significant disadvantages.
It uses a PKI that, in itself, is an additional management bur-
den which may be prohibitive for smaller DCS networks.
The additional overhead of key negotiation between nodes
may also not be desirable, since a node that serves a large
number of clients might spend an unacceptable amount of
time just negotiating keys with them. Moreover, because
there is a unique key for each host, the model does not scale
well to large networks, and redundant communication paths
only exacerbate this problem. Finally, Intrusion Detection
Systems (IDSs) are blinded to any encrypted traffic since
they do not have access to the keys used to do the encryp-
tion.
The underlying reason that IPsec does not fit the pro-
posed approach better is that it is based on a more open
network model where communications might be between
different organizations with different PKI infrastructures. It
cannot assume anything about the security of the endpoints
119
and as a result uses a model where compromise of a key on
one system only affects that system’s security.
The network model for SCADA and DCS networks we
are considering, however, has some additional features that
can be leveraged to provide a simpler solution.
• The network is managed by a single organization and
so does not require the full generality of a PKI infras-
tructure.
• The network devices used to provide the firewalling
and authentication/encryption are special devices that
can be hardened so that they are not easily accessible.
As a consequence they can be trusted to protect any
key material they store.
To take advantage of these network features, we propose
using the concept of virtual private groups.
4. Virtual Private Groups
The key assumption behind the VPG approach is that
when the endpoints are isolated devices that can be hard-
ened because we have control over them, then they can be
trusted to adequately protect the key material with which
they are entrusted, and as a result key management can be
simplified. For SCADA and DCS networks that are pro-
tected by bump-in-the-wire-network devices, this assump-
tion is appropriate so the VPG trust model fits.
VPGs are based on the use of a centralized management
component, the policy server, that creates and distributes
shared keys used by groups of nodes to communicate se-
curely. VPG keys are created, distributed and revoked by
the policy server using secure management channels be-
tween the policy server and each trusted endpoint. This en-
ables simpler key administration for dynamically managing
groups of critical nodes and does not require a supporting
PKI.
A Virtual Private Group (VPG) distinguishes itself from
a Virtual Private Network (VPN) in the following ways:
1. VPGs use a single encryption key for all members of
the same group, rather than a separate key for each pair
as with VPNs.
2. A VPG key can also be shared with a third party, such
as a network intrusion detection device, that is not one
of the protected endpoints. This is very difficult to
achieve in a VPN when the key is negotiated between
those endpoints.
3. A VPG can be defined along any practical criteria that
could define the group, such as a network service in
which the hosts may engage.
 4. Since VPGs are hardware based, they are independent
of the host and cannot be easily turned off from a com-
promised host, as can software based systems, and any
attempt at bypassing the security by removing the de-
vice results in the host no longer being able to partici-
pate in any encrypted communications.
The concept of virtual private groups was first pro-
posed by Carney, Hanzlik and Markham [1] and imple-
mented in the Autonomic Distributed Firewall (ADF) [6,
5], a research prototype of the 3Com Embedded Firewall
(http://www.3com.com). These early investigations defined
the “group” as a group of hosts where all communications
between group members would be fully protected by the
same cryptographic key. The notion that groups could be
defined along a criteria other than host identity, such as the
service to which they engaged, was proposed by Ioannidis
et al [4] in their Virtual Private Services (VPS). However,
VPS relied on traditional certificate-based IPsec to encrypt
that service traffic. VPS were not intended to simplify key
management or to address the sharing concerns targeted by
VPGs.
In summary, VPGs use shared keys among group partici-
pants and a centralized management component that results
in simpler key management and provides flexibility over the
policy specification criteria.
5. Implementation examples
In this section we describe two implementations of VPGs
that we have done at Adventium. The first was based on a
commercial product, the 3Com Embedded Firewall (EFW).
It involved making modifications to the proprietary code
that was running on the EFW NIC under a licensing agree-
ment between Adventium Labs, 3Com and Secure Comput-
ing (the original developer of the EFW), and its focus was
on developing a commercializable version of VPGs for pro-
tecting critical infrastructure networks.
The second implementation was focused on developing
a version of VPGs that was not dependent on a specific pro-
prietary hardware device. It was developed on the DARPA’s
SRS Phase 2 program and was used to restrict and identify
malicious insiders.
5.1. A Proprietary Solution: 3Com EFW
VPG
EFW VPG was developed as an enhancement to the
3Com EFW 2.5 product. It provides endpoint to endpoint
encryption and high-level policy specification integrated
with the EFW filtering and centralized management. EFW
VPG allowed all network traffic between group members
(i.e., protected hosts) to be encrypted and authenticated.
120
VPGs were implemented using the hardware crypto-
graphic support on the 3Com EFW NICs. VPGs were im-
plemented on the NIC and all encryption/decryption was
done on the NIC via crypto hardware on packets as they are
processed. The decision on which packets to encrypt and
which keys to use to encrypt them was determined by the
packet filtering rules. A new key value field was added to
each packet filter rule. If the rule that the packet matched
had an associated key, then the packet was encrypted with
that key using triple DES. IPsec tunnel mode was used,
which encrypted the original packet and added an additional
header to the packet, but the protocol in the new header used
its own protocol number, IP Protocol 174, rather than the
standard IPsec ESP protocol number (IP Protocol 50). On
the receiving side, when a packet with the VPG protocol
number was received, it was decrypted and passed through
the packet filter.
All key management was performed by the EFW Pol-
icy Server. The EFW NICs stored all VPG keys so that
they were not accessible even if the host was compromised.
EFW VPGs could be used to encrypt all traffic between a
group of nodes or just traffic that matched certain packet
filtering rules.
Several fundamental advances were made during this
work that serve as a base for broader use of VPGs.
Service-oriented Policy Management: The traditional
approach of specifying distributed firewall policy exactly as
it is to be enforced, that is, one firewall at a time, is time
consuming and tedious even for small deployments. Our
work resulted in a new approach, called Conversations, that
elevates policy writing to simply specifying which hosts
should be authorized to engage in specific network services.
It then provides a method for translating this higher-level
specification into firewall-specific policies such that consis-
tency between host-based policies is assured. The policy for
a single enforcement point may be composed from several
conversations, and these conversations may be specified by
different authors.
Transparent VPGs: VPGs are associated with conver-
sations. There is no overhead for specifying a VPG; it is
as simple as noting that a particular conversation should be
protected. The same VPG may protect many conversations,
and the required cryptographic keys will be generated auto-
matically and bound to the resulting policy rules.
Enforcement Mechanism Independence: Architec-
tural changes and abstractions implemented during this
work enable a conversation to be agnostic with respect to
its underlying enforcement mechanisms. Hence, by imple-
menting specific translation components that produce low
level policies from the high-level conversation specifica-
tions, the specifications can be used to define policy for a
variety of underlying enforcement mechanisms. To demon-
strate this feature, we implemented a translation component
for a Linux host-based firewall as well as an EFW one.
The VPG concept has been used to great advantage on
a variety of exercises and deployments and has withstood
several Red Team trials. It played a prominent role on the
DARPA OASIS Dem/Val program. Adventium’s work ad-
dressed the lessons learned from the OASIS Dem/Val expe-
rience [7] to develop a commercially viable and industrially
robust VPG functionality.
The 3Com EFW, without VPGs, was successfully used
on the LOGIIC program to help control and identify threats
to a process control network. During that work it became
clear that VPGs could provide a significantly enhanced pro-
tection capability for these networks and that conversations
could be used to easily specify appropriate high-level poli-
cies.
5.2. An Open Solution: IPsec based
DARPA’s Self-Regenerative Systems (SRS) program
gave us the opportunity to build on our earlier work and
develop a bump-in-the-wire VPG solution, whose policies
were controlled by conversations but whose defenses were
based entirely on open standards. This solution, called the
DRED for Detection, Response, Embedded Device, tar-
geted a different type of critical infrastructure, a mission
planning network [2]. While the DRED contained many
network defenses, including packet filters, Ethernet frame
filters and proxies, we focus below on the DRED’s imple-
mentation of VPGs over IPsec.
A traditional VPN is implemented in IPsec using one of
three methods: manual keying, negotiated keying based on
a shared secret, and negotiated keying based on identity-
based certificates. Manual keying is discouraged for any-
thing beyond simple testing because it is difficult to protect
keys that must be distributed over untrusted networks, and
keys must be refreshed often during the lifetime of the VPN.
Negotiated keying schemes provide trustworthy key distri-
bution through the Internet Key Exchange (IKE) protocol
[3], which negotiates not only the initial keys but all future
keys required by the VPN. If both endpoints are controlled
by the same authority, then negotiation based on a shared
secret is often preferred. For large enterprises, though, ne-
gotiation based on certificates scales more effectively. Of
these three methods, only manual keying supports all of the
requirements for VPG implementation. To understand why,
it is useful to review how IPsec actually works and the role
that IKE plays.
An IPsec connection between a pair of endpoints re-
quires two rules, one for each direction, in each endpoint’s
Security Policy Database (SPD) and two security associa-
tions, one for each direction, in each endpoint’s Security
Association Database (SAD). The SPD governs when IPsec
must be used, while the SAD describes how it will be used
121
by naming the necessary Security Policy Identifiers (SPIs)
and the cryptographic keys bound to those SPIs. Outgo-
ing packets are checked against the SPD, and if there is a
match, the SAD is searched for the SPIs and cryptographic
keys that will encrypt the packet. Under manual keying, an
appropriate SAD entry must be found, or IPsec will return
an error. Under negotiated keying, the endpoints use IKE
to quickly define the necessary SAD entries, after first au-
thenticating themselves to each other using either the shared
secret or the certificate.
Thus, IKE is responsible for populating the SAD, as re-
quired by IPsec policy, whenever an appropriate security
association cannot be found. Because the negotiation is
pairwise, the newly created security association is unique
to that pair. As a result, the keys are known only to those
endpoints, which makes it very difficult to share them to the
degree required by a VPG, i.e., within a group of n hosts
and with a third party.
By contrast, VPGs are straightforward to implement us-
ing manually keyed IPsec, because while all SPIs in the
SAD must be unique per peer, there is no requirement that
the cryptographic keys bound to each SPI must also be
unique. Thus, as long as we keep SPIs unique per peer,
we can distribute cryptographic keys in a manner that is in-
dependent of those endpoint identities.
Each DRED’s SPD and SAD was populated automati-
cally from the output of the conversations tool. The con-
versations tool enabled us to specify that the same crypto-
graphic keys could be used across multiple hosts, and other
tools ensured that the SPIs specified in each DRED’s SAD
would be unique. Thus, without altering IPsec, we were
able to populate the DREDs’ SPDs and SADs in a way that
achieved the desired effect of VPGs.
However, while VPGs reduced the keys to manage, they
could not reduce the size of each endpoint’s SAD over what
would have been required using VPNs, because the SAD
entries still had to be pairwise and identity-based. This
highlights an important obstacle using IPsec: it was de-
signed under the assumption that encryption policy would
always be based on the identity of the hosts, so any other
criteria for encryption must first be recast into this identity-
based scheme in order to work.
6. Management approach
Traditional policy management tools focus more on the
rules to be implemented by a particular policy enforcement
device than on the authorizations that will be enabled by
those rules. This can obscure these authorizations, espe-
cially for readers not familiar with the enforcement device.
Separating authorization from enforcement, on the other
hand, clarifies the authorizations and enables them to be im-
plemented more easily by multiple, different devices.
 Adventium developed a novel policy management ap-
proach called conversations that separates authorization
from enforcement. Conversations is a group-based policy
management approach where the groups are related service
instances. Conversations enable policy to be specified at
a very high level (authorizations) and have those changes
propagate automatically into enforcement rules, as shown
in Figure 2. Adventium has applied conversations success-
fully in several problem domains and typically observes a
two orders of magnitude improvement, in terms managed
entities, over writing the enforcement rules directly.
To scale policy specification more effectively, conver-
sations separate the concerns of what must be authorized,
where must each authorization be enforced (i.e., what de-
vice must enforce it), and how must each authorization be
enforced (e.g., what rules are necessary).
6.1. What is authorized?
A service instance is a network service, such as HTTP
or DNS, from a specific provider(s). A conversation autho-
rizes service instances for a set of consumers. The services
may have different providers, but all must share the named
consumers. Formally a conversation is denoted
+
(C, ((S, P ) )) (1)
where C is the set of service consumers, S is a set of ser-
vices, P is a set of providers that all provide S, and + means
one or more. Each (S, P ) defines a service instance. C and
P may represent users, roles, hosts or the EFW or DRED it-
self. If C were a role, then the conversation would resemble
a role-based access control policy, except that conversations
define policy simultaneously for both C and P , not just for
C (i.e., a role) alone. In a single conversation, there may be
multiple consumers, multiple services provided by multiple
(and not necessarily identical) providers.
To enable VPGs, we extend Definition 1 to specify that
all communications authorized must be protected by cryp-
tography:
+
(C, ((S, P ) ))k (2)
where k is the cryptographic protection strategy. In our
case, k names a VPG key that is shared between C and P
for all communications authorized by this conversation.
The Conversation Manager (CM), a MySQL-based ap-
plication, enables the construction and maintenance of con-
versations. It also supports the graphical display of conver-
sations in multiple ways, e.g., by service, by user, by en-
forcement device, etc., according to the needs of the viewer.
6.2. Where is the authorization enforced?
Along with conversations, the CM is used to specify the
bindings that determine which devices are responsible for
122
enforcing the particular authorizations resulting from a con-
versation. Bindings are relationships between a conversa-
tion entity and the enforcement device that protects it. A
binding typically exists between a host and a device, but it
can also exist between a user and a host. In that case, transi-
tive closure helps us determine which device is responsible
for that user.
Under traditional policy management, bindings are im-
plicit because the policy is already being written for a par-
ticular device. Under Conversations, a change in the bind-
ings can result in completely new policies at the enforce-
ment layer, even if the conversations themselves were not
changed. Bindings also clarify relationships that are re-
quired by some defenses. For example, IPsec requires both
the host and device identities in order to specify tunnel
mode encryption policy (where the device is a gateway).
A set of conversations and bindings together determine
the permissions that must be enforced by each device. Dur-
ing the policy translation process, every conversation gen-
erates the following permissions, ∀c ∈ C, s ∈ S, p ∈ P
named in that conversation,
δc : c, sclient , p, k,
δp : c, sserver , p, k
where δc and δp name the enforcement device associated
with c and p, respectively. These expressions mean “δc en-
forces that c is authorized to request s (i.e., be a client of
s) from p and this communication is protected according to
k” and “δp enforces that p is authorized to accept requests
from c on s (i.e., be a server of s) and this communication
is protected according to k”, respectively.
6.3. How is the authorization enforced?
Once we have identified where an authorization is en-
forced, we can turn our attention to how it is enforced. The
enforcement semantics differ greatly depending on whether
the target device is an EFW, a DRED, or something else.
For this reason, the service s has, so far, remained abstract.
The function of service semantics is to bind s to the nec-
essary enforcement rules that will enable s. Service seman-
tics are rule templates whose placeholders (entity identities
and services) are derived from the conversations. Service
semantics are independent of any high-level policy, so once
defined they can be reused indefinitely. Service semantics
are created for each service in a conversation and for each
defense (e.g., IPsec) that enforces its use. More specifically,
the service semantics for each defense are applied to each
permission assigned to the device to generate the necessary
rules for that defense (on that device).
 Figure 2. Conversation specification with translation to device policies.
6.4. Benefits
Separating concerns in this way offers many benefits.
First, conversations clarify sharply what is authorized be-
cause the reader is not confronted with the detailed syntax
of the policy enforcement rule. Second, there is relatively
low cohesion and coupling between conversations, bindings
and service semantics so each can be managed nearly inde-
pendently of the others. This offers significant advantages
for environments where what is to be authorized may be de-
fined by a different authority than where it must be autho-
rized or how it must be authorized. Third, rather than rely-
ing on a single individual with expertise in the chosen policy
enforcement point, conversations may be defined by multi-
ple authors, each with a particular expertise in the named
service and how it should be deployed.
7. Conclusions
Critical infrastructure networks operate under differ-
ent trust assumptions than conventional business networks.
Nodes in these networks are trusted for specific functions,
and the communication paths between them are relatively
limited and static. As a result, using hardware-based so-
lutions that are independent of the protected node and
conversation-based VPGs can provide the necessary pro-
tections in a way that acknowledges the more limited op-
erational and trust models of these networks.
123
References
[1] M. Carney, R. Hanzlik, and T. R. Markham. Virtual private
groups. In Proceedings of the 3rd Annual IEEE Information
Assurance Workshop, 2002.
[2] J. T. Haigh, S. A. Harp, R. C. O’Brien, C. N. Payne, J. Gohde,
and J. Maraist. Trapping malicious insiders in the spdr web.
In Proceedings of the Forty-Second Annual Hawaii Interna-
tional Conference on System Sciences (HICSS-42), Waikoloa,
Big Island, Hawaii, January 2009. To appear.
[3] Internet Engineering Task Force, Network Working Group.
Internet key exchange (ikev2) protocol, December 2005.
http://tools.ietf.org/html/rfc4306.
[4] S. Ioannidis, S. M. Bellovin, J. Ioannidis, A. D. Keromytis,
and J. M. Smith. Design and implemention of virtual private
services. In Proceedings of the 12th IEEE International Work-
shop on Enabling Technologies: Infrastructure for Collabo-
rative Enterprises (WETICE), pages 269–274, Linz, Austria,
June 2003. IEEE.
[5] T. Markham, L. Meredith, and C. Payne. Distributed embed-
ded firewalls with virtual private groups. In DARPA Infor-
mation Survivability Conference and Exposition, 2003, vol-
ume 2, pages 81–83, April 2003.
[6] C. Payne and T. Markham. Architecture and applications for
a distributed embedded firewall. In 17th Annual Computer
Security Applications Conference, December 2001.
[7] P. Rubel, M. Ihde, S. Harp, and C. Payne. Generating poli-
cies for defense in depth. In Proceedings of the 21st Annual
Computer Security Applications Conference. IEEE, 2005.