Transcript Securing EDI

Securing EDI
Tim Maletic
Friday, Sept 17
Topics





Risks to EDI
Transport security methods
Network design
considerations
Managing cryptographic keys
EDI security policy
Assumptions

Interchange =
–
–

B2B (not B2C)
File transfers
Audience =
–
–
Techies and managers
Mix of small to large sites
My Background



ISSO for a 450,000 member,
West Michigan health plan
40 EDI partners trading 5000
files/month, 14 GB/month,
350,000 claims/month
Experience with multiple “PKI-lite”
solutions: file transfers, file sync,
email infrastructure, certificate
authorities
On build vs. buy
If I sink in a boat, it will be a
boat that I made… because if I
sink in some else’s boat I’ll be
damn mad!
-Branford Marsalis
The Problem
Risks to EDI
Loss of:
 Privacy
 Integrity
 Authenticity
 Availability
Key Point!
We will consider many different
risks to EDI. Some are farfetched and some are not. It’s
up to you to tell the difference
for your environment.
Risks to EDI: Privacy

Malicious attacks
–
–

Eavesdropping admin
Classic man-in-the-middle
Accidents
–
–
Misaddressed message
Encryption snafu
Risks to EDI: Integrity

Malicious attacks
–
–

Data modified by admin
Data modified by MITM
Accidents
–
–
Dropped network packets
FTP ASCII conversion
Risks to EDI: Authenticity

Malicious attacks
–
–

Email header spoofing
Compromised FTP
credentials
Accidents
–
?
Risks to EDI: Availability

Malicious attacks
–

FTP DOS (file bombs,
connection attacks)
Accidents
–
Lack of throttling = selfinflicted DOS
Risks from EDI




Additional firewall holes
Additional file server accounts
Additional trusted keys
Additional vector for
malware
How to Assess the Risks



Traditional risk assessment
3rd party pen test
Attack tree analysis
Attack Trees
Defraud system
Bribe employee
Hack internal system
Insert EDI data
Attack server
Attack client
Attack data in transit
Transport Security Methods

Physical controls
–
–

Private networks
Courier
Logical controls
–
–
–
IP encryption
Session encryption
File encryption
Private Networks

Protect against
–
–
–
–


Eavesdropping
Data corruption/manipulation
Spoofed origin
DOS
Highly expensive
Hard to scale
Virtual Private Networks

Protect against
–
–
–


Eavesdropping
Data corruption/manipulation
Spoofed origin
Susceptible to DOS
Config intensive
Session-level Encryption

Protects against
–
–


Eavesdropping
Data corruption/manipulation
May be susceptible to
spoofed origin
Susceptible to DOS
File-level encryption

Protects against
–
–



Data eavesdropping
Data corruption/manipulation
May be susceptible to spoofed
origin
Susceptible to DOS
May be susceptible to
eavesdropping of auth credentials
The Crypto Zoo







IPSec VPN
SSL VPN
SSH / SCP
SFTP (FTP over SSL)
SFTP (FTP over SSH)
SSL (HTTPS download/upload)
SSL (up-and-coming methods)
The Crypto Zoo II



PGP
AS2 (X.509 over HTTP)
ZIP
–
–
–


Proprietary algorithms
AES
Kohno’s recent paper on WinZip AE-2
Password-protected MS Office
documents
Passphrases vs. public keys
Key Point!
File-level encryption is akin to
wireless networking:
 you’re using it whether or not
you know it or want it
 and there’s a high cost to
doing it wrong.
Which Method is Best?



For session-based
transactions: VPN or SSL
For file-based transactions:
PGP
No method is supported by
everyone, so plan to support
several
Network Design

Where in the network should you:
–
–
–
–
–


Authenticate partners?
Decrypt?
Sign?
Encrypt?
Virus-scan?
What firewall rules are needed?
Should you sandbox partner accounts?
Key Point!
Network design is crucial. The
best solution will have the
network, firewall, server and
application architects involved
from the beginning.
Crypto Key Management: Your keys

Key’s purpose
–
–
–


Key lifetime, rotation, revocation
Protecting private keys
–
–

Decryption
File-signing
Key-signing
Encrypting vs. batch mode
Transporting & backup
Algorithm strength & compatibility
Crypto Key Management: Their
keys




Signing
Dedicated signing key
Verification
Self-service verification
Practical Attacks vs. Public
Keys




Man-in-the-middle
Brute force passphrases
Client-side attacks
Server-side attacks
Key Point!
Don’t allow users or app
support staff to decide the
minutiae of crypto settings –
settle them in advance by
policy.
EDI Security Policy #1
Security agreements with all
partners
All partners shall sign security
agreements before access is
granted.
EDI Security Policy #2
Only IT-approved crypto
No cryptographic processes,
protocols, algorithms, or keys
shall be used without advanced
approval from IT.
EDI Security Policy #3
Private key security
All private keys shall be
encrypted when stored on disk
in untrusted networks (such as
the public DMZ).
EDI Security Policy #4
Verify all partner keys
All partner keys shall be verified
through out-of-band
communication channels (such
as phone or fax).
EDI Security Policy #5
No unencrypted PHI in DMZ
All sensitive data (such as PHI)
shall be encrypted when stored
on disk in untrusted networks
(such as the public DMZ).
EDI Security Policy #6
Use least privilege for partners
All partner accounts shall
possess an absolute minimum
number of privileges (e.g.,
individual, sandboxed accounts
on the FTP server).
EDI Security Policy #7
No public-access FTP
All servers related to EDI
processes shall only allow
Internet connections from
known IP addresses.
Case Study: Priority Health



ISA Forms
OpenPGP via GnuPG
Filemover
Case Study: Issues




Partners’ lack of encryption
experience
Partners who balk at signing
files
Graceful recovery from errors
Responding to near-incidents
References




My Information Security summary:
http://infosecuritymag.techtarget.com/2002/jun/t
echtalk.shtml
NIST’s Security Guide for Interconnecting
Information Systems:
http://csrc.nist.gov/publications/nistpubs/80047/sp800-47.pdf
Attack Trees: Ch 21 of Schneier’s Secrets &
Lies (and p. 104 on passphrases vs. keys)
Kohno on WinZip AE-2:
http://www.cs.ucsd.edu/users/tkohno/papers/Wi
nZip/
Summary





Many ways to do EDI securely
Many ways to do it almost
securely
Step 1 = sound policy
Step 2 = consensus from
architects
Step 3 = implementation, training,
maintenance, …
Thanks!
Send questions/comments to:
[email protected]