Securing Data while it's Crossing Networks
A network connected to public networks only through an adequate firewall and
phone lines between sites,
wire or fiber optic cable within sites,
and gear and software managed by one organization
used to be considered an adequately secure, private, network.
People have used Secure Socket Layer (SSL) to encrypt data, including credit card
numbers when doing e-commerce between a web server and a web browser. With SSL
data can be encrypted until it is received but there's no control over who receives it.
HIPAA, the security standards for e-government, Research Division's desire to run Q5I
over the Internet, and heightened security requirements from the IRS are some of the
requirements and desires of CDSS' businesses. They change the definition of adequate
security for networks and data as it's moved across networks.
This issue papers recommends a way to secure data as it moves over network, what used
to be called private network or network as public as the Internet. An assignment to
design DSSnet for better security has been cancelled.
To secure data being moved across network one has to:
1. Be sure senders of data are who they are representing themselves to be and are the
right source for the data. Be sure the recipients are the right recipients and that they are
who they are representing themselves to be. See the issue paper on Authentication and
Authorization. (Management cancelled their request for that issue paper.)
2. In some cases, make the data understandable to only the right recipients.
3. Prevent anyone else from substituting even some of the right data with wrong data.
4. In some cases, be able to prove the data is what was sent and who sent it.
5. In some cases, hide how much data is being moved between which boxes on the
Solutions in the marketplace include: SSL/TLS, PPTP VPNs, L2F tunneling, L2TP
VPNs and IPSec VPNs. Different encryption algorithms like the new AES standard
under development, DES, 3DES, elliptic curves, etc. are not discussed separately in this
issue paper, though one is recommended. Particular Certificate Authority solutions,
Public Key Infrastructure, key cards, and biometrics are not debated here though
recommendations are offered. Using private keys or public keys or a combination is not
discussed here. A combination of the two is part of this paper's major recommendation.
SSL even version 3.0, which is also called TLS, does not meet security requirements 1, 3,
4 or 5. SSL encrypts data between a web browser and a web server. CDSS needs to
secure more kinds of traffic between software, not just traffic with a web browser, for
example files that are being accessed, moved or copied across network.
SSL has to be coded and tested for each web application and every update of each
application. Each application program and perhaps each update to it could require review
and approval of the ISO. Program areas have to pay for the coding and testing of security
for each application every time it's updated.
Each time an application program has to "drop into" SSL or cease to use it there's a price
to be paid in application performance.
And SSL doesn't offer security.
PPTP VPNs aren't secure.
L2TP VPNs are a Cisco proprietary solution. Cisco's business plans are to support and
expand their offerings of IPSec VPNs, not L2TP VPNs.
IPSec VPNs used with an appropriately secured and maintained certificate authority and
appropriate security policies meet security requirements 1, 2, 3, 4 and 5. They are the
best security available in the commercial marketplace. Major corporations are using
VPN - Virtual Private Network. Has many different meanings. Some VPNs offer no
security. Some VPNs work only with one vendors hardware and software. Let "VPN"
call to mind caveat emptor, buyer beware. Some are standard so many vendors' software
and hardware can work together. If implemented correctly some offer the best security
available for data crossing networks, i.e. a solution likely to be defensible to HIPAA
auditors as the "best practice".
PPTP - Point to Point Tunneling Protocol. Microsoft's proprietary (i.e. only Microsoft
programs can do it) protocol for VPNs. Per security expert Bruce Schneier in "Secrets
and Lies" - don't use proprietary security algorithms, they are not as well tested as those
which make it to being open standards, and nothing remains proprietary.
L2F - Layer 2 Forwarding. Cisco's proprietary protocol for tunneling data across
L2TP - Layer 2 Tunneling Protocol. Cisco and Microsoft joint solution for
IPSec - Internet Protocol Security. The Internet Engineering Task Force, the IETF, has
negotiated and settled on the standards, open to all vendors, that make most of the
Internet and World Wide Web work. For example, the suite of protocols known as
TCP/IP, the main protocols that make the Internet work, is defined is the open standards
of the IETF. Such standards are known by their RFC numbers. RFC stands for Request
for Comments because an IETF publishes a proposed standard, requesting comments.
Comments are used to improve the proposed standards and negotiations for standards can
be intense. Major corporations invest very skilled personnel in the process.
IPSec is reasonably well defined in a collection of RFCs. However there's some "wiggle
room" and any two vendors' IPSec VPN that meets the standards may not inter-operate in
some features. The vendors of IPSec VPNs hold "bake-offs" to test for interoperability.
The particular IPSec VPN being recommended for DSS is implemented in both Cisco
and Microsoft software. They've been tested together and do inter-operate.
State of the Industry:
The IETF crafted standards for IPSec VPNs. They're loose enough that all vendors'
implementations of the standards may not inter-operate. Often a vendor with major
market share will write a solution that meets such loose standard(s) and other vendors
will make their solutions inter-operate, in order to have access to that vendor's major
share of the market.
Cisco has the major market share for network gear and software, e.g. routers. Microsoft
is a major vendor of operating systems, particularly for personal computers, e.g. Win95,
NT and Windows 2000. Cisco and Microsoft offer an IPSec VPN solution that inter-
operates across Cisco and Microsoft product lines.
Almost all of CDSS' current and forecast needs to secure data as it crosses network can
be solved or solved except for "the last wire inside a building" by securing the data
between Cisco and Microsoft boxes. CDSS and HHSDC own and use many Cisco and
Microsoft boxes. CDSS' technical staff will have to learn IPSec VPNs and is already
trained on Microsoft and Cisco software and hardware.
With the Cisco/Microsoft IPSec VPN solution (hereafter shortened to "IPSec VPN")
CDSS' ISO can set policy about what kinds and levels of encryption are required between
what boxes or networks, for what access and have the policy implemented inside
DSSNet. Anyone wanting to connect over secure network from anywhere, inside or
outside of CDSS will have to offer matching security. If someone tries to connect where
security is required, they don't offer the required security, they aren't supposed to get in,
or aren't who they claim to be this is the best solution available for making sure they don't
Program areas will not have to pay application developers to code and test for security as
data moves across network.
One solution for security across network can be maintained on, for example, one laptop
carried by a CDSS Executive. The laptop can be configured once to operate with
appropriate security, like levels of encryption, to whatever CDSS has implemented, per
policy, for all boxes and applications inside CDSS that can be accessed by IPSec VPN.
The same solution does or will soon work for Windows 95, NT and Windows 2000 as
well as for several kinds of Cisco network computers. There are plans to offer small
network boxes to wire with a remote PC using a different operating system or with for
example an Apple computer. The Cisco, Microsoft IPSec VPN solution would be
implemented on that small network box.
The recommended IPSec VPN solution requires processing cycles, particularly many are
used for encrypting and decrypting. The recommended solution may slow response time
experienced by customers or push CDSS to purchase PCs with more processing power.
Personnel using the security won't have to know when to use it, won't have to turn it on or
off or think about it. They'll notice only if things run more slowly or they can't reach
DSSNet because their computer/software is not matching the security required by
SSL/TLS does not provide security. Use of SSL has to be coded and maintained in each
web-based application. It works for web-based applications and not all CDSS'
applications. It takes processing time to drop into and come back out of using SSL. But
SSL doesn't provide security.
IPSec VPNs can secure data as it crosses network, not just data between web servers and
Applications don't have to be coded, tested and maintained do the work to secure data as
it crosses network. IPSec VPN software does the work. A reasonably up to date version
of the IPSec VPN software has to be installed on the sending and receiving boxes. A
sending/receiving box could be a PC, a PC that's a server, a Cisco VPN concentrator or a
Cisco router with VPN software and enough cpu cycles to encrypt and decrypt the traffic.
Each new application could be specified to use IPSec VPNs. Where the IPSec VPN
software will be used, e.g. on remote PCs belonging to CDSS and a network box within
DSSNet will be negotiated for each new application, or increase in number or users, or
volume of work. ISO will determine what encryption, authentication, and authorizations
are acceptable. Those will be implemented as requirements on: network gear by e.g.
CDSS network team or HHSDC network and security teams, or on CDSS servers by e.g.
CDSS' server team. But new IPSec VPN software won't have to be added to e.g. a
remote PC for each application. The IPSec VPN is installed once per remote box. In
most cases the remote box will be a PC.
All CDSS PCs that will use IPSec VPNs will need enough cpu cycles, the IPSec VPN
software, and to be configured to offer/allow up to the maximum security.
An IPSec VPN can be established between a PC in DSSNet and a network computer a
short wire away from a mainframe computer. The short wire could be within a physically
secured space. The IRS may consider this adequate or the best state of the art security for
data moving across network.
Cisco, Microsoft IPSec VPNs
(NOT PPTP VPNs, not L2TP VPNs, not other VPNs, not other IPSec VPNs)
with an appropriately secured certificate authority,
with appropriate procedures and requirements for getting a certificate,
preferably with secure cards (like Secure ID) for private keys,
with appropriate policy and tools to protect:
remote computers accessing DSSNet or DSSNet resources via IPSec VPN
and data while it's on the remote computers.
Where the best security is appropriate and the work can be done this way, use:
tunnel mode and
Last Spring HHSDC offered pilot testing of PPTP VPNs. Once analysis showed they do
not offer the best available security, CDSS kept our participation limited, so few people
would be using network that's not secure enough. Also few people (3) would have to be
moved to better solutions as they are approved by CDSS' ISO and available from CDSS'
ISD and/or HHSDC.
Recently HHSDC announced they're offering VPNs to one of the kinds of Cisco network
computers, a VPN concentrator, that offers several kinds of VPNs. The concentrator can
handle PPTP, L2TP and IPSec VPNs. HHSDC is not yet offering IPSec VPNs to
Windows 95, NT and Windows 2000 PCs.
HHSDC is negotiating with DOIT about offering a certificate authority. IPSec VPNs can
be offered without a certificate authority but to scale to the numbers of users CDSS may
have using VPNs, a certificate authority is recommended.
HHSDC is proposing to use the Microsoft Certificate Authority software. CDSS has
privately shared information gleaned from classes at a Networkers Conference where
organizations that had implemented Microsoft Certificate Authorities said Microsoft
C.A.s were easy to install but lacking in features that are needed to support a whole
HHSDC is not yet offering IPSec VPNs within their network, or across their network
between parts of DSSNet. For example the pilot tests offered today would not secure IRS
data moving between Jeff Adge's desktop PCs on DSSNet in 1700 9th St. and a
mainframe at HHSDC.
HHSDC is offering pilot testing, only between a remote PC and a Cisco VPN
concentrator next to the firewall that is between HHSDC and the Internet.
a) CDSS postpone participation in pilot testing pending approval of one or more
kinds of VPN by CDSS' ISO.
b) If CDSS' ISO is even considering the use of certificate authorities, suggest
CDSS provide support to HHSDC's endeavors to negotiate with DOIT so HHSDC
may offer a certificate authority which CDSS' ISO may approve for use by CDSS.
c) CDSS' ISO determine:
what it will approve CDSS to use in terms of a certificate authority offering,
what forms of id, etc. ISO will require for issuance of certificates,
to whom CDSS would issue certificates,
how CDSS would issue them or arrange for HHSDC to issue them at CDSS
assurance and request, etc.
d) CDSS' ISO determine if it will accept certificates for which people remember
their private keys, or if secure cards or biometrics will be required and accepted.
e) CDSS' ISO determine what levels of encryption, what encryption algorithms,
tunneling or transport mode, etc. the ISO will require as minimum security for
various kinds of data being secured as it moves across network.
f) CDSS' ISO develop and publish any requirements and policies for securing
remote PCs that use IPSec VPNs to access DSSNet.
g) CDSS wait a bit to see if HHSDC offers Cisco, Microsoft IPSec VPNs with
Windows 95, NT and Windows 2000, and a certificate authority.
Waiting a bit could spare CDSS pretending there's adequate security, PPTP VPNs
are not secure enough, and work to upgrade to using IPSec VPNs when they
If possible: do it right, do it once, don't make the application developers do it for
every application, don't make the customers pay attention more than the one time
they get the right solution installed on their e.g. laptop.
ISD has been investing in finding the recommended solution, suggesting it, asking for it
and supporting it's consideration since late Summer of 1999. HHSDC has almost
completed the vast majority of the work for CDSS.