Degrees of Security

Degrees of Security
There are different ways that you can implement security. There is no law saying that you have to connect your entire network to the Internet. (Although I see a fair number of businesses doing it.) One simple way to reduce your cost is to create only a very limited segment that has connectivity. If your primary concern is receiving customer feedback (and providing some promotional information), there really is no need to connect at all. Certainly, an ISP can host a page (or even co-locate a box) for you.

However, if you are determined to provide dedicated access, with a server under your local control, there are some things you can do to greatly increase security. First, if the only box you are placing out on the freeway is a Web server (and you are concerned about that server being cracked), you can use read-only media. This procedure is admittedly more difficult to implement than a live file system (one that is read/write), but the gains you realize in security are immense. Under such a scenario, even if a cracker gains root access, there is very little that he can do. The downside to this, of course, is that dynamic pages cannot be built on-the-fly, but if you are providing an auto-quote generator or some similar facility (perhaps even interfacing with a database), it can still be done.

Really, the key is to enclose all CGI into a restricted area. The CGI programs read the data on the read-only media and generate a resulting page. This is a very secure method of providing technical support, product lists, and prices to clients in the void. Essentially, so long as you back up your CGI, you could have that identical machine up in one hour or less, even if crackers did manage to crash it. This type of arrangement is good for those who are only providing information. It is poor for (and inapplicable to) those seeking to accept information. If you are accepting information, this might involve a combination of secure HTML packages or protocols, where the information received is written to removable, write-one-time media.

The sacrificial host is really the safest choice. This is a host that is expressly out in the open and that you expect to be cracked. Certainly, this is far preferable to having any portion of your internal network connected to the Internet. However, if you also want your local employees or users to be able to access the Net, this is entirely impractical. It can, however, be implemented where you do not expect much access from the inside out, particularly in commerce situations.

A commerce situation is one where you are accepting credit card numbers over a browser interface. Be very careful about how you implement such schemes. Here is why: There are various paths you can take and some of them represent a greater risk than others. Typically, you want to avoid (at any reasonable cost) storing your customers' credit card numbers on any server connected to the network. (You have already seen the controversy that developed after it was learned that Kevin Mitnik had acquired credit card numbers--reportedly 20,000-- from the drives of Netcom.)

Generally, where you are accepting credit card numbers over the Internet, you will also be clearing them over the network. This typically requires the assistance of an outside service. There are various ways that this is implemented, although two techniques dominate that market.

Local Saves
In a local save scenario, the information is piped through some secure, encrypted HTTP session (SHTTP, for example). Usually, this is done through a form written specifically for that purpose. The form outputs the information to a local disk somewhere, from which it can later be retrieved for verification purposes. Along that journey from the input form to the disk, the numbers may be sent through several processes. One is where the numbers are examined against a common algorithm that determines (first and foremost) whether the submitted credit card number is even a real one. By real, I mean that it is a potentially real one. This is one somewhat flawed version of verification. It basically relies on the same algorithms that are used to generate card numbers to begin with. If the submitted number fails to result in a number that could have been generated by the algorithms, the card number is a dreamt-up number, something that someone randomly guessed. There are two flaws with this type of verification, one in the basic concept and the other in reference to security.

The first problem is this: The algorithms used are now widely disseminated. That is, there are credit card number generators available across the Internet that will resolve numbers to either a state of authenticity or no authenticity. Kids used them for years to circumvent the security of Internet service providers.



--------------------------------------------------------------------------------
TIP: One very good example is utilities that exist for unlawfully accessing AOL. These utilities have, embedded within their design, automatic generators that produce a laundry list of card numbers that will be interpreted as valid. When these programs first emerged, the credit card number generators were primitive and available as support utilities. As using generators of this variety became more common, however, these utilities were incorporated into the code of the same application performing the dial-up and sign-on. The utilities would pop up a window list from which the cracker could choose a number. This number would be sent (usually by the SendKeys function in VB) to the registration form of the provider.
--------------------------------------------------------------------------------

So, at the start, individuals could come forward with at least mathematically sound numbers for submission. Thus, simple algorithm credit card validation subjects the accepting party to a significant amount of risk. For example, if this verification is used in the short run but the cards are later subjected to real verification, the interim period comprises the longest time during which the accepting party will lose goods or services as a result of a fraudulent charge. If this period is extended (and the temporary approval of such a credit card number grants the issuer access to ongoing services), then technically, the accepting party is losing money for every day that the credit card is not actually validated.

Secondly, and perhaps more importantly, storing the numbers on a local drive could prove a fatal option. You are then relying upon the security of your server to protect the data of your clientele. This is not good. If the information is ultimately captured, intercepted, or otherwise obtained, potentially thousands (or even hundreds of thousands) of dollars might be at stake. If there is a subsequent investigation (which there usually is), it will ultimately come out that the seed source for the numbers was your hard disk drives. In other words, after the Secret Service (or other investigating party) has determined that all victims shared only one common denominator (using your service), you will have a problem.

This is especially true if your system administrator fails to detect the breach and the breach is then an ongoing, chronic problem. There is a certain level at which this could raise legal liability for your company. This has not really been tested in the courts, but I feel certain that within the next few years, special legislation will be introduced that will address the problem. The unfortunate part of this is as follows: Such a case would rely heavily on expert testimony. Because this is a gray area (the idea of what "negligent" system administration is, if such a thing can exist), lawyers will be able to harangue ISPs and other Internet services into settling these cases, even if only in an effort to avoid sizable legal bills. By this, I mean that they could "shake down" the target by saying "I will cost you $50,000.00 in legal bills. Is it worth the trouble to defend?" If the target is a large firm, its counsel will laugh this off and proceed to bury the plaintiff's counsel in paperwork and technical jargon. However, if the target is a small firm (perhaps hiring a local defense firm that does not specialize in Internet law), a legal challenge could be enormously expensive and a drain on resources. If you have to choose, try to saddle some third party with the majority of the liability. In other words, don't store those numbers on your drives if you can help it.

Remote Saves via CGI
The second scenario may or may not be preferable. This is where you drop a secure HTML form into the structure of your Web site. (This form is provided by the credit card clearing service.) With this, you will likely also receive customized scripts that redirect the data submitted in that form to a remote server. That remote server fulfills one purpose only: clearing the numbers.



--------------------------------------------------------------------------------
NOTE: There are various methods through which the mechanics of this process are achieved. One is where the credit card clearing company has proprietary software that attaches to a particular port. On both the client and the server end, this port traffics the information (which is encrypted before it leaves the client and decrypted after the arrival at the server). More than likely, the remote server refuses connections on almost all other ports, or the information is filtered through a pinhole in a firewall.
--------------------------------------------------------------------------------

The advantages and disadvantages are diverse in this scenario. First, there is the obvious problem that the accepting party is resigned to traveling blind; that is, they will never have the credit card information within their possession. Because of this, disputed claims are a serious headache.

Here's an example: A kid gets his parent's credit card number and charges up a storm. This information is validated by the remote server, with the accepting party storing no information. Later, the parent disputes the transaction, claiming that he never authorized such a charge. This is okay, and may happen periodically. However, obtaining records and then sorting out that dispute is both a logistical and legal problem. It is not quite as simple as disputing unauthorized charges on one's telephone bill. Because the party that cleared (and ultimately collected on) the charge is a third party (one that has no part in the exchange of goods or services), confusion can easily develop.

Imagine now if you were such a victim. You contact the party that is the apparent recipient of the charge, only to find that the company has "nothing to do with it." When consumers are confronted with this type of situation, they become less likely to do commerce over the Net. And while this is essentially no different than being confronted with unauthorized 900- number charges on your telephone bill, the average consumer will view the Internet with increasing suspicion. This is bad for Internet commerce generally. Despite that fact, however, this method is generally regarded as the most secure.