securing edi tim maletic friday, sept 17. topics l risks to edi l transport security methods l...
TRANSCRIPT
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 far-fetched 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 = self-inflicted 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– Decryption– File-signing– Key-signing
Key lifetime, rotation, revocation Protecting private keys
– 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/techtalk.shtml
NIST’s Security Guide for Interconnecting Information Systems: http://csrc.nist.gov/publications/nistpubs/800-47/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/WinZip/
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, …
