The material presented in this section is divided into two categories.  The first category addresses security management issues that apply to all contexts of B2B data exchanges over networks.  The second category specifically addresses security implementation issues for EDI, Internet EDI, and Exchanges.  Security management issues are presented first, then implementation issues for EDI, Internet EDI, and Exchanges are discussed.

SECURITY MANAGEMENT

Implementing security solutions for any system is a complex endeavor.  “Any real-world system is a complicated series of interconnections.  Security must permeate the system: its components and connections.” [Schneier, 2000 p. xii]  As such, security solutions for B2B data exchanges must fit into the general security architecture of an organization and adhere to an organizational information security policy.  Security should be treated as a process, instead of a series of outputs.  And as a process, security must be constantly managed.

Below, several areas of security management are discussed that pertain to all B2B data exchange contexts.  These areas include: security policy, areas of security, security verification of products/services, and major technologies utilized in B2B data exchanges. 

Policy

Every organization engaged in B2B data exchanges should have an organizational security policy.  The security policy is developed through an analysis of business requirements and an assessment of threats, vulnerabilities, and risks.  The resulting policy typically addresses how an organization handles its information, who has access to what information, allowed versus denied behaviors, a list of organizational controls that are in place, as well as who is responsible for what (implementation, enforcement, audit, and review).  Recommended sections for the security policy are:

  • Policy Overview
  • Security Architecture Guide
  • Incident-response Procedures
  • Acceptable Use Policies
  • System Admin Procedures
  • Other Management Procedures [Avolio, 2000]

Areas of Security

There are three general areas of security that must be addressed in a comprehensive security program.  First, data must be protected.  Second, if protection security fails then the failure must be detected.  Third, when protection failures are detected there must be some type of response system in place.  Protection, detection, and response are all needed; without one area of coverage systems of data exchange will not be secure.

Protection

Most security technologies are aimed at protecting data.  In protecting data, five security services can be provided: identification, authentication, non-repudiation, confidentiality, and integrity [Nichols et al., 2000; Sherif, 2000].

  • identification – basically answers the question “who are you?” Usernames are the most common implementation of identification services
  • authentication – once identified, can a party prove they are who they say they are.  Passwords (something you know), biometrics (something you are), and access tokens (something you have) are generally used for authentication services.  At the network layer authentication can be simple (uses on-time password) or strong (uses digital signatures and or certificates signed by a certification authority – requires encryption keys at all network nodes, thereby providing physical protection at all nodes)[Sherif, 2000]
  • non-repudiation – prevents a party that has performed an act from denying it later.  There are two types of non-repudiation services.  Non-repudiation at the origin prevents the sender of data from denying it later, and non-repudiation at the destination protects the sender by verifying receipt of a message.  Cryptographic receipts are created to provide this service.
  • confidentiality – data are kept private; no unauthorized reads.  Encryption is used to provide confidentiality security services.
  • integrity – data remain in the form they were in after the last authorized save; no unauthorized writes.  During data exchanges digitally signed message digest codes provide data integrity services.

Detection

In general, most security programs do not have adequate detection countermeasures in place [Schneier, 2000].  Detection can include the detection of a protection failure or the detection of an attempt to break the protection security of a data exchange.  Detection activities can be structural or operational [Kozubik, 2000].  Structural intrusion detection includes identifying and monitoring unusual actions and objects on the network.  Operational intrusion detection includes identifying intruders using “valid” credentials that would generally go unnoticed by structural detection activities. 

Countermeasures that facilitate structural detection include intrusion detection systems (IDSs), burglar alarms, honey pots, and audit logs.  IDSs can be based on misuse detection or anomaly detection.  Misuse detection systems scan all activity for predefined attacks.  Anomaly detection systems determine normal activity from statistical models and compare actual activity to its calculations.  Burglar alarms are specific mechanisms on a network designed to “go off” if an intruder trips them.  And honey pots are burglar alarms made to look attractive to potential intruders.   Countermeasures that facilitate operational detection are more difficult to implement and are less well developed.  Importantly, all countermeasures must be monitored on a regular basis or else detection, in terms of being able to respond, may not occur.

Response

Once a protection failure is detected, or an attempt to break protection security is detected, the response taken may be critical to data security.  Therefore, it is important to plan for and specify what appropriate response actions will be taken before detections occur.   These responses should be documented in the security policy [Internet Security Task Force, 2000].

Product/Service Verification

The security elements of products and services should be verified.  Security verification can involve evaluation, certification, and accreditation [Nichols et al., 2000 p. 144].

  • Evaluation is determining the extent to which a product or system matches an objective a priori standard for the degree of trust that can be placed in the product or system, and is independent of the specific operational environment.
  • Certification is establishment of the extent to which a particular design and implementation meets a set of specified security requirements developed expressly for the product or system with knowledge of the intended operational environment.
  • Accreditation is the management decision that a system or network is approved to operate in a particular operational environment using a prescribed configuration.

Major Technologies

Encryption and Decryption

Cryptography is the science behind encryption and decryption.  Basically, mathematical algorithms are used to transform plaintext messages into ciphertext messages.  A key, created by the algorithm, encrypts and or decrypts the message.  Key algorithms can be either symmetric or asymmetric.  Encryption protects confidentiality.

Symmetric key algorithms use the same key to encrypt and decrypt a message.  Symmetric key algorithms are fast, but there are two major problems.  The first problem involves making sure all parties share the same key.  There must be agreement on a secret key before any information is exchanged, and somehow the agreement must be gain in a secure manner.  The second problem is that for pairwise security, the number of keys needed exponentially increases with the number of users within a network.

Asymmetric key algorithms use a pair of keys that are created to work together – one key to encrypt a message and a second key to decrypt it.  The encryption key is published making it available to all any and all members of the public.  Anyone can then use this public encryption key to send a message to the person who owns the private key match.  The private key owner then uses this key to decrypt the message.  The major problem with asymmetric keys algorithms is that they are slow. 

Hash Functions

Hash functions can be viewed as digital fingerprints.  A mathematical calculation is applied to data to compute a one-way hash of that data.  Given the content of the data, a unique hash value is created.  When data is transmitted, the hash value is also sent.  The recipient can then use the same hash function to compute a hash value for the data received.  The computed hash value is then compared with the hash value transmitted with the data.  If the values are the same, the recipient knows that the data arrived unaltered.  Hash functions provide authentication and integrity services.

Public Key Infrastructure

Public Key Infrastructure (PKI) is evolving as a security standard for transmitting B2B data over public media.  PKI involves the use of private/public keys, digital signatures, and digital certificates.

Private/Public Keys

Since symmetric cryptography is faster, a symmetric algorithm is used to create a session key that is then used to encrypt the data.  The intended receiver of the data has used asymmetric cryptography to create a pair of keys, one public and one private.  The public key is published and registered with a trusted third party (i.e., certification authority).  The sender of the data uses the recipient’s public key to encrypt the session key.  The encrypted session key is then transmitted along with the symmetrically encrypted data to the receiver.  The receiver uses his or her private key to decrypt the session key, and then uses the session key to decrypt the data. 

Digital Signatures

  • a unique process where a message is hashed using a message digest function then  encrypted with a private key.  The fact that a paired public key will decrypt the message indicates that the message was sent from the person/organization holding the private key.
  • three basic assumptions are made when a message is signed: 1) signature binds you to whatever message states, 2) message will not be changed after it is signed, and 3) signature will not be transferred to another message
  • the Electronic Signatures and Global and National Commerce Act (E-Sign Act) took effect in the U.S. on October 1, 2000, which provides for legal recognition of electronic signatures for binding contracts and agreements.

Digital Certificates

  • a digitally signed data structure defined in the X.509 standard that binds the identify of a certificate holder to his/her public key.
  • certification authorities are used as trusted third parties

Risks have been identified with the use of PKI.  A major risk is that standards for PKI are still evolving and different types of certificates use different standards.  Hence, there can be serious incompatibility problems in B2B data exchanges.  Ten other risks have been associated with the use PKI [Ellison and Schneier, 2000].  Each risk should be considered during the implementation of PKI.

1. Who do we trust, and for what? – certification authorities (CAs) are generally used to certify that a party is associated with a key pair, but they do not certify the specific purpose of the party

2. Who is using my key? – private keys can be stolen or used by unauthorized persons; how is key access managed

3. How secure is the verifying computer? – if a hacker adds a “root” public key to the CA’s computer, the hacker can issue his or her own certificates (that will be treated as legitamate)

4. Which “John Robinson” is he? – public keys are associated to names, and while extenders are generally added to make the name unique to a specific CA…you may not be aware of which CA your “John Robinson” should be coming from

5. Is the CA an authority? – the CA may be an authority on issuing certificates, but not on what information the certificate contains

6. Is the user part of the security design? – some applications using certificates are concerned solely with cryptography and not the user interface in terms of what is communicated to the user regarding the certificate

7. Was it one CA or a CA plus a Registration Authority (RA)? – the CA+RA model is less secure than using either a CA or a RA separately

8. How did the CA identify the certificate holder? – be sure a CA uses adequate means to identify applicants and verify that applicants are actually control the private key corresponding to the public key being certified

9. How secure are the certificate practices? – does the CA have sound reasoning for its practices and how often are those practices reviewed and updated if needed

10. Why are we using the CA process anyway? – be sure your organization has a need for using PKI and understands the technology driving PKI solutions employed

Firewalls

A firewall is a device that keeps intruders out of a network.  The device can be located at the point where a network connection enters a site, or it can be a gateway bridge, router, or front-end processor that limits access between networks.  In either case, a firewall allows specific connections to pass while blocking others based upon security policy.

Virtual Private Networks

Virtual private networks, or VPNs, basically secure a connection between two sites or between an individual and a site (i.e., remote access) over public media.  IP packets are tunneled across the network after being encapsulated in a new packet by the tunnel initiator.  Usually the IP packets are encrypted prior to being encapsulated.  Tunnel endpoints must be authenticated so that only legitimate users can access the tunnel, and if encryption is used, a mechanism for key exchange must be in place [Steinke, 1998].

Placement of a VPN gateway in relation to a firewall is critical.  VPN gateways can be placed 1) in front of a firewall, 2) behind a firewall, 3) on a firewall, 4) parallel to a firewall, and 5) on the firewall side (i.e., on a dedicated firewall interface).  Some general rules for VPN gateway placement include [Nichols et al., 2000, p. 730]:

  • do not compromise the overall network security policy
  • VPN gateway placement must not be a single point of failure
  • the VPN gateway must accept only encrypted traffic from the untrusted network
  • the VPN gateway must accept nonencrypted and encrypted traffic from the trusted network
  • the VPN gateway must defend itself from Internet threats
  • the overall architecture must filter traffic after VPN decryption

VPNs are becoming more popular due increased use of VPN standards, such as IPSec and L2TP.  IPSec is more widely used and many VPN technology vendors are designing their products to be IPSec-compliant.  However, in an IPSec environment is it important that all VPN technologies used in data exchanges be compatible with each other and not just IPSec-compliant.

EDI

The security issues specific to tradition EDI transmission depend upon the EDI standard in use, as well as whether the transmission takes place over a direction connection or VAN.  All EDI standards (e.g., X12, UN/EDIFACT) are implemented with security protocols specific to the general standard and or industry-specific versions of the standard.  Identification, authentication, integrity, confidentiality, and non-repudiation can be ensured through the use of these standards.

When using either a direct connection or a VAN, an important security consideration is access to the media.  With the use of direct connections, the party(ies) responsible for the private media in use must provide and manage their own security to prohibit unauthorized access to the media.  Typically firewalls, intrusion detection systems, and audit logs are implemented for this purpose.

When using VANs, media access security is managed by the VAN provider and is relatively high.  The VAN provider only allows users to send and receive data to and from their own electronic mailboxes.  The provider transmits data from one mailbox to another.  Access to user mailboxes and the central network that connects mailboxes is kept separate.  In most cases the provider will also offer storage and tracking services, which can increase overall data exchange security. 

INTERNET EDI

Although the Internet is reliable, low-cost, highly accessible, supports high bandwidth communications, and is technically mature, there are some concerns relating to the use of the Internet for EDI. A major problem with the use of the Internet for EDI is the inter-operability between vendor products, specifically in the areas of integrity, confidentiality, digital signatures and non-repudiation.  These problem areas lead to difficulties with security, message tracking audit trails, and authentication.  For example, when the EDI interchange is carried using an e-mail transport (SMTP), the message might not be able to be delivered to the final recipient.  Instead, it may be stored at an intermediate node and may be susceptible to security threats.  This is particularly a concern for packets that contain high value or sensitive information.

The trading partners must currently agree upon a number of security issues.  Below are security standards recommended by the Electronic Data Interchange-Internet Integration (EDIINT) working group of the Internet Engineering Task Force (IETF). In the long term, additional Internet EDI standards will need to be developed to simplify the process of establishing a trading partnership, including the acquisition, revocation, exchange and third party authentication of certificates. 

 

Security Area

Security Recommendation from EDI-Internet Integration Group (http://www.ietf.org/html.charters/ediint-charter.html)

Confidentiality for EDI Interchange on the Internet.

For interoperability to occur, trading partners must agree upon a standard encryption algorithm(s) and key lengths. Since public-key encryption algorithms are considerably slower than symmetric encryption algorithms, they generally are not used for large EDI interchanges.  The preferred method is to create a symmetric key, which is used to encrypt the EDI interchange, and the symmetric key is then encrypted using the recipient’s public key. Recommended key lengths of 40, 75 and 128 bits are supported for incoming and outgoing EDI messages when used domestically; RC2 is limited by government restrictions to 40 bits when exported outside the US.  RC2, DES and Triple-DES should be in CBC (Cipher Block Chaining) mode and RC5 in CVC Pad mode.  For EDI Interchanges of minimal value, 40-bit RC2 or 56-bit DES are probably adequate.  For more valuable EDI interchanges, use of Triple-DES, IDEA or 128-bit length RC2 or RC5 is recommended. IDEA’s use in PGP makes it the most widely used encryption algorithm for Internet electronic mail.  Further, a symmetric key can be randomly generated by the software for each EDI transaction between trading partners.

Symmetric  key encryption

Diffie-Hellman is the recommended asymmetric algorithm for managing and distributing symmetric encryption keys when doing EDI over the Internet.  It can be used both within and outside the US.  Both S/MIME v3 and PGP/MIME make use of the Diffie-Hellman encryption algorithm to encrypt/decrypt “session keys.”  For RSA encryption to protect “session keys,” at least a 768 bit key should be used and for high value transactions, a 1024 bit or higher key should be used.

Public key certificate

Public key certificates based upon the X.509 standards are becoming prevalent.  There is a lack of wide-spread use of certification authorities in real world applications. Since there already exits a trust relationship between EDI trading partners, until use of certification authorities becomes more established and better profiling is done with X.509 v3 certificates, it is recommended that the trading partners “self-certify” each other, in addition to acquiring a X.509v3 certificate from a certificate authority trusted by both trading partners using the formats and protocols specified by PKCS7 “certs-only” when using S/MIME, and PGP certificate formats and protocols when using PGP/MIME. Self-certification means that the exchange of public keys and certification of these keys must be handled as part of the process of establishing a trading relationship.

Content integrity

SHA-1 is the recommended Secure Hash Algorithm, a one-way hash function invented by the National Security Authority.  It is recommended by most e-mail security programs and other security specifications. SHA-1 for outgoing messages is recommended for new implementations, while MD5 incoming is continuing to be accepted for incoming messages.  MD5 produces a message digest and is widely used in most e-mail security programs such as PEM, PGP, and S/MIME.

Authentication and repudiation

Both authentication and non-repudiation guarantee the identity of the sender of the EDI interchange.  Non-repudiation of original identifies the original sender, and is the same as authentication when EDI interchange is sent point-to-point (i.e., when no forwarding is involved). The NIST FIPS PUB 186, DSS, signature standard should be used for digital keys.

Signed receipt and non-repudiation of receipt

The signed receipt is an acknowledgment sent by the receiving trading partner to the sending trading partner.  It addresses the following issues when doing Internet EDI:

1.      Lack of wide-spread RFC 1894 mailbox delivery notification implementation within Internet mail infrastructure.

2.      Provides equivalent of VAN mailbox pick-up notification.

3.      Provides equivalent of VAN mailbox pick-up authentication.

4.      Detects when EDI interchanges are maliciously deleted or not delivered by the transport.

The signed receipt can be broadly applied to other MIME encapsulated objects. It must be implemented using a MIME multipart/signed type/subtype with the message disposition notification as the first part of the content of the multipart/signed.

Syntax and protocol for specifying cryptographic services

S/MIME or PGP/MIME can be used.  S/MIME has some signatory problems that PGP/MIME does not have, but PGP 4.5 does not give the user as much flexibility in choosing algorithms and key lengths. A multi-part/ signed is required, and signed DATA is recommended only when sending EDI through known gateways that do not honor 7-bit transfer coding.

Tracking and error handling basics

In order for the Internet EDI be as traceable as VAN EDI, some additional security requirements and support of signed receipts must be implement in EDI UA. The EDI UA must be able to identify the transmission by its message ID and calculated MIC value if desired.  Some tracking is provided by the X12 997 or EDIFACT CONTRL message.

EXCHANGES

The starting point for determining security needs for data transmissions through Exchanges is whether public or private media are being used.  If data exchanges are made over public media, then security issues are generally the same as for Internet EDI.  If data exchanges are made over private media, then security issues are generally the same as for EDI.  In the case of private media use, exchange owners serve as a VAN provider to other exchange participants in the direct connection EDI model or they outsource that function to a third party if using the VAN EDI model.