In the 21st century, any entity that does business or maintains customer data will do it online. The 'e' in eBusiness has already become redundant. There are already well understood practices and standards in place for user authentication, data encryption, and credit card transactions. We will explain what it all means and guide you through the process of deciding which security choices are right for you, not just for selling online, but for any website that handles financial or private data.
Brainstorming points
new definitions for the new millennium
What is E-Commerce: Electronic Commerce may include any computer mediated business process, but a common usage is to use it to describe commerce taking place using the World Wide Web as an enabling transport. For many reasons, including our areas of expertise and experience, we will concentrate on this definition of E-Commerce. The web is the way to do business for many reasons. Thin, ubiquitous clients, the wide availability of access, and consistent interfaces to many different platforms are among the reasons to choose web solutions for many problems. In addition, the limited nature of the HTTP protocol makes security issues simpler. However, any transaction taking place across the public Internet is open to a wide variety of security problems.
B2C vs B2B: B2B or Business to Business involves information (PO Orders, invoices, Sales orders, orders confirmations) exchange between business partners computers (vendors, distributors, merchandisers) who are working closely together. Traditionally industries were performing transmissions using EDI (Electronic Data Interchange) standard. EDI is a set of formats used to describe electronic documents. [Then I will insert something about running EDI via third party companies, how secure it is and how expensive and that now it would be great to go to Internet-based EDI One of examples of an expensive but secure EDI solution may be the way Ford communicates with its suppliers (using BTAM protocol)] Since company decide to save some money and go with Internet solution for EDI they can face some problems. They have to take care about authentication, encryption etc. [then talk about certificates and running secure FTP]. And then continue that may be EDI is not as good and its kind of boring to follow those old-fashioned X.12 standards. And may be its time to try a new cool stuff called XML. There are some attempts to come up with industry standards for XML standards and if I figure out what that TPA thing is (the one I have sent to you) we can mention this. I noticed that there is a build-in reference to certificate authority into XML document that describes a service interface
B2C describes the interaction between a business and the customer. Many of the issues with B2B transactions are shared with B2C, but the interaction is generally more open to abuse, since there is no way to restrict access to secured networks or even VPNs, and many additional issues are added. We will discuss both forms of commerce, because both are very important.
What are clients concerned about?
What do we want to sell?
Security: Securing data requires attention to all parts of the system. A weak link in the chain can provide a opening for a security breach. It is important to consider the security of your operating system, file system, hardware (both server and client), data field encryption, web server, application, browser:
Some of the risks include:
For both client and server:
eavesdropping, fraud
For the end user:
active content, privacy infringement
For the web site:
webjacking, server and LAN break-ins, denial-of-service attacks
Doing a security review: Corporate-wide privacy and confidentiality policies are important. Management must provide sufficient resources to get the job done and back security policies and procedures. Applications must be reviewed for appropriate level of security, responsibilities and authority must be clear, and a direction must be chosen. It is not necessary that the policies used be perfect, but it is necessary that they be well understood and fully implemented.
At Ford, we have developed a number of procedures for making sure our data is secure. One of the most important is called an ACR, or Application Control Review. The data owner must go through a process of deciding how critical, and how confidential his data is, based on easily understood and well-defined terms, like whether it is financial or private, and whether it is confidential or secret. Then he knows exactly what other reviews he needs to do and what controls he needs to put into place for that data... for instance, financial data or password data obviously needs to be encrypted. There are checklists for each kind of application, and it is easy to see whether the required work has been done or not.
Choosing a platform: Our areas of experience cover the gamut, from IBM AS/400 and Sun servers, through Linux to Microsoft and Apple Macintosh platforms. There is no one best answer for every application, much as we may like to recommend Linux to everyone simply because it can do everything and has the advantages of being open source and politically correct. If your data is all on an IBM mainframe, or the data of your business partners, you are naturally going to move in that direction, and you can readily perform web-based E-Commerce on those platforms. IBM has been moving in an open standards direction for at least three years, and Java servlets are the solution that everyone in the AS/400 community seems to want to move towards. Under Linux and Apache, of course, Java servlets are heavily tested and very secure. Open standard, portable solutions are a lot harder to come by in the Microsoft centric world, because of the heavy investment in ASP and non-portable extensions to Java, but there are certainly times when, because of the data you already have, a Microsoft NT based web server may seem to be the least painful way of starting to do web commerce. Going back to the idea of a security review, if the data is not very critical or very private, you can choose the appropriate level of security, and Microsoft products may be just fine for something that you need to roll out quickly which doesn't matter that much, and will not get very much user load. There might even be times when it will stand up to serious load, but the growing pains, possibilities of virus and security problems, and incompatibility with anything else make it difficult to recommend in good conscience. Large commercial UNIX servers from Sun, HP, or SGI are relatively complex to administer, much like IBM servers, but can provide extremely variable configurations, take serious load, give you the vendor's professional support services, and all have interchangeable open standard paths available alongside Linux. Moving from one to the other is the simplest thing in the world, and a small server supported in-house on Linux could be ported to a large server on one of the commercial flavors of UNIX with almost no changes.
Configuring a public server: When a server is connected to the Internet in any way, security immediately becomes a serious concern. When that server contains customer data, financial data, or any other private data, the concern is even more serious. We say that a server like that must meet Properly Administered Host guidelines. For instance, you should use restricted shells when appropriate, to limit command scope. Secure shells should be used when insecure transport or command login from a not totally secure site is necessary. One-time passwords are another option to consider. Accounts should all have valid login shells, or if used for ftp only, a shell can be set to /bin/false. The password files and logs should be regularly reviewed. Umasks should be set appropriately, and accounts should be deleted regularly. Security tools should be used to check typical mistakes like accounts with no or easily guessed passwords. Services like finger, FTP, whois, sendmail, DNS, and WINS should be turned off if not absolutely necessary. On NT, NTFS must be used to format all drives, directories accessible to end-users should not be in the PATH for admins, and all files should be assigned to a valid owner. If FTP is enabled, only anonymous FTP should be allowed and any access by FTP must be limited to read-only. Access via WWW must be limited to read-only.
Basic Cryptography Terminology and Concepts: Cryptogtraphic systems consist of plaintext, the message before it is encrypted, the ciphertext, the message after it has been encrypted, the algorithm, or mathematical operation to obscure the plaintext so that it is unreadable, and the key, a sequesnce that can encrypt or decrypt the cyphertext. The first type of cryptography is called symmetrical, where the same secret key is used to encrypt and decrypt the message. However, symmetric systems pose problems for transactions on the internet. Communications are often spontaneous, so there is often no opportunity to exchange secret keys before the transmission. In addition, one to many communications are often necessary, for example, many people communication with a single server. The secret key would not stay secret for long. In the 1970's, the public key (sometimes called asymmetrical) cryptography was devised. In this system, keys come in pairs, one for encryption and one for decryption. The public key is made widely available so that people can encrypt messages to the owner with it. Then the recipient uses the closely guarded private key to decrypt the message. Public key cryptography also makes it possible to create digital signatures that cannot be forged. Digital signatures use public key cryptography in reverse. Messages are encrypted using a person's private key and can only be decrypted with that person's public key. To prevent someone from cutting and pasting a person's encrypted digital signature, one person sends a challenge phrase, The other person signs the challenge phrase with their private key and returns it. If the challenge decrypts successfully with the other's public key, then the identity is confirmed. Public key encryption is much slower than symmetric key encryption, which makes public key encryption undesirable for large documents. Combining symmetric and public key encryption provides a solution This involves the concept of a digital envelope. A message is encrypted with a session key and a symmetric algorithm. This session key will be used for this transmission only then discarded. The digital envelope is created by encrypting the session key with the recipient's public key. When the message and digital envelope are received, the recipient uses his private key to decrypt the session key. He then decrypts the message using the session key, which is known only to the sender and recipient.
SSL: SSL stands for Secure Sockets Layer. It is an example of a cryptographic protocol that incorporates certain cryptographic principles. It is the most popular protocol for encrypting general communication between a web server and a web client SSL uses both symmetric and public key encryption. SET, Secure Electronic Transactions, on the other hand, is a specialized protocol for safe credit card transactions. In addition to safeguarding communications between the browser and server, SET also checks a credit card number for validity, checks that the customer is authorized to use the credit card number, authorizes the transaction with the customer's bank, and processes the transaction.SET is tied to the credit card system. Since merchants pay a fee for every transaction, it is not cost effective to deal with transactions of less than $10. Micropayment systems such as an Israeli company uses deal with micropayements for vending machines, small food purchases, etc.
Vigilance. Quick response through Symantec, CERT, SANSSecure development techniques (e.g., validating form input to avoid malicious script tags)Resources:World Wide Web Security FAQ http://www.w3.org/Security/faq/Web Security, A Step-by-Step Reference Guide, Lincoln D. Stein, AddisonWesley, 1998Web Security and Commerce, Simson Garfinkel with Gene Spafford, O’Reilly, 1997Web Security, Amrit Tiwana, Digital Press, 1999Digests from SANS (System Admin, Networking, and Security Institute) http://www.sans.org/CERT (Computer Emergency Response Team, though it doesn’t really stand for that) Mailing List http://www.cert.org/
The default standard for customer account names for transaction based e-commerce has become the customer's email address. This is useful in that is something the customer can easily remember and does provide some security if it is used so only a combination of the email address and some other key (i.e., password) are used to allow changes to the customer's account and any such changes are confirmed by emailing a confirmation to the customer. The same sort of activity should happen on purchases and returns on-line confirming the transaction with the customer. Of course by email to the address that information has now been exposed and would any passwords sent. If a password is sent, it is recommended that the customer be strongly encouraged to change it as soon as possible.
Storing private customer data: One of the major problems with commercial sites and the use of credit cards is the break-in to computer systems, not just websites, and the theft of credit card information. Depending on the method of credit card authorization used, as little as the credit card number and the expiration date of the may be enough to allow illegal usage of the credit information. Many sites go beyond this when authorizing transactions over the Internet by requiring name, address, city, state, postal code and country information. Even this can be expand to include postal code and country information. Even this can be expand to include the name and address of the person receiving the goods orders, thus helping to prevent orders to being shipped to address known to have been involved in improper transactions. This is even being expanded on by shipping companies (such as UPS) noting certain problem addresses and alerting the vendor, who can contact the customer about possible misuse of the their credit information. This also implies that customer data on addresses and telephone numbers must be secured as well as any credit card information
credit card authorities: There are over 60 different vendors providing "Payment Systems" over the Internet, including credit card authorization, electronic checks and online wallets. Some of these are affiliates of other "Merchant Services" vendors. Only three of these offer credit card authorization directly to the public. The actual authorization of credit cards may require using one of these services and having a merchant credit card account with a bank or service bureau. Although much press has been given to the security of on-line credit card authorization, in actually, there is little security beyond the https protocol. Most authorization systems only require the card number and expiration date. Even though a customer may provide name, address and telephone information as part of the "Billing Information" on a on-line transaction, most banks do not provide the information needed for the AVS (Address Verification System) even though on-line vendors are usually charged a significantly higher rate than are the so-called "brick and mortar" vendors. On-line vendors are responsible for any fraud that is committed by individuals misusing credit card information and are experiencing a higher rate of fraud than are more traditional merchants who at least have access to the physical card which is more difficult to obtain than is the basic card number and expiration date.