Dealing with Security

In this chapter we'll deal primarily with security of data while in transit. Security of data within your enterprise is certainly very important, but it can involve fundamentally different problems. The scope is different and the mechanisms to enforce security can be different. Referring to one of my observations above, you want to make sure that your system makes it very difficult for both internal and external hackers to steal sensitive information such as credit card data. The mechanisms for ensuring this type of security often involve firewalls, operating system and file system protections , database security, and individual user authentication. As we'll see, these can be very different from the mechanisms commonly used to secure data while in transit. In this chapter we'll focus on what happens between the firewalls, not on what happens within the firewall or how to keep the firewall from being penetrated.

Security Requirements and Exposure

What are we really concerned about when we talk about security? Independent of any technology, including computers, almost everyone agrees that there are certain common security requirements. However, they may not agree on what the specific requirements are. For some guidance about specific requirements we can look to the Information Security Technology Evaluation Criteria recommendation [ITSEC 1991]. It breaks security down into three broad requirements.

1. Confidentiality : Certain types of information must be restricted to only those people who need to know it. Cryptology and encryption first come to mind for most people when they think about computer security.

2. Integrity : Resources must be secure from malicious tampering that would compromise their usefulness . Transactions must be free from fraud.

3. Availability : The resource that we're trying to secure must be available to those who require its use. In computer networks, denial-of-service attacks violate this aspect of security by flooding Web sites with so many bogus requests that they aren't able to service legitimate users. In the physical world, we want our car to be there, in the parking lot, when we're ready to go home.

In conducting electronic commerce we're usually most concerned with the integrity of transactions and next concerned with confidentiality. That isn't to say that availability isn't an issue, but it is such a general issue that it isn't very often a specific concern of electronic commerce (at least the type of business-to-business commerce discussed in this book).

When we speak of risks of any type, we need to put them into perspective not only in regard to what we stand to lose if the worst happens (that is, our exposure) but also in regard to the likelihood that the worst will happen. In common electronic commerce situations we're probably most concerned about fraud or violation of transaction integrity. We could be concerned about processing orders from bogus businesses from which we'll never receive payment or about paying bogus invoices for goods we never received. Some organizations are also concerned about trading partners that deny an electronic transaction took place or dispute the details of a transaction, but this is less common. What is usually at stake in these cases is a specific dollar amount. If we take an objective look at all these things, they really don't happen very much. While the exposure may be moderate, the likelihood is low.

We're also frequently concerned with confidential information getting into the wrong hands. We don't want competitors to know the details of products in development. We may not even want other organizations to know what we buy or sell and the prices involved. However, if you listen to the concerns most voiced by users, fraud is mentioned more than confidentiality.

Countermeasures and Remediation Strategies

There's a class of actions, normally referred to as countermeasures , that are taken in response to security threats. You can think of burglar bars on your windows or shredding your credit card statements as countermeasures. Remediation strategies apply to what you do after your security has been compromised. If we look at attacks on security, what you can do about them is generally determined by the timing of the attack.

• Prevention : Preventing or deterring the attack before it occurs. We buy a home alarm system so that the burglar will hit the house next door rather than ours. We reinforce our door locks to make it harder for thieves to break down the door.

• Detection : Finding out about the attack as or shortly after it occurs. Our home alarm system automatically dials the security company if a door or window is opened.

• Remediation : Choosing what to do after the attack has happened . We assess whether anything has been burgled from our home. If something is missing, we file an insurance claim. We take what we've learned about our vulnerability and apply it as prevention for the next attack.

In all honesty, it seems to me that there has been way too much focus on preventing security breaches that have moderate exposure and relatively low risk of occurring. Resources might be better spent on reasonable detection and remediation. In addition, way too much money is spent on some types of prevention strategies. What is the point of requiring small trading partners to use strong algorithms for encryption and digital signatures if the machines they use to communicate with you are in open offices, left on and logged in 24 hours a day?

The best you can do (if you are given a choice) is to assess what your real exposures and risks are, and then try to strike a reasonable, cost-efficient balance between prevention, detection, and remediation. However, since most of the requirements imposed on you have to do with prevention countermeasures, let's look at some of the options you might be offered .

Is It a Requirement or Is It a Countermeasure?

For those of us who have spent much time studying nonfunctional requirements, it comes as no surprise that there isn't universal agreement about how requirements like security are decomposed. That is why I chose a somewhat authoritative source like ITSEC when I broke down security into confidentiality, integrity, and availability. You may not be surprised, therefore, to know that there is also frequent disagreement about what constitutes a requirement versus a design option or mechanism that satisfies the requirement. For example, many people might regard a password-protected login as a requirement. Others might regard it more strictly as an authentication mechanism for enforcing access control, which ultimately has to do with satisfying the requirements of confidentiality and integrity. In this book I'm not going to split hairs with this type of theoretical debate. To set a frame of reference, I'll try to follow the framework and approach defined in ITSEC. You don't have to agree with it, but it at least will lend some consistency to how we consider the issues.

Prevention Countermeasures

The two countermeasures you are most likely to implement have to do with authentication and encryption.

Authentication

Authentication is the means by which someone can verify that you really are who you say you are. Organizations use authentication to ensure that it is indeed you who has logged into their portal, or it is really your company that has sent them an XML document. Authentication can either be session based, lasting the duration of a communications session, or persistent. Session-based authentication is still most often implemented with user names and passwords. Unless you have significant concerns about someone masquerading as you in order to commit a fraudulent transaction, take this option if it's offered to you. An increasing number of organizations are using X.509 digital certificates with public/private key pairs for session authentication. Certificates are getting much easier to acquire than they used to be a few years ago, and software support for them has matured as well. Session-based security using a certificate at sign-on or session initiation is still a fairly low-cost choice. Many Web browsers support it.

Persistent authentication usually involves placing a so-called "digital signature" on a document. The signature is a string of bits generated by an algorithm that uses your private key and certain information about the document. It can be used to verify not only that the document came from you but also that it hasn't been tampered with. Persistent authentication, as yet, is seldom required in most common exchanges of business documents. We could certainly imagine the day when we might want to apply a digital signature to a legal contract. However, most companies at present don't require this level of authentication for common documents like purchase orders or invoices. Persistent authentication often requires more expensive software and sometimes more complicated management than session-based authentication. If you have a choice between persistent authentication and session-based authentication, again depending on how you view your own requirements, go for the session-based approach since it is generally easier to implement.

Encryption

This is the familiar scrambling of bits that most people first think about when it comes to computer security. What many people don't realize is that encryption, like authentication, can also be session based or persistent. The same X.509 certificates can be used for public/private key pairs. However, network protocols support session-based encryption in which the keys are negotiated dynamically and certificates are not needed. This is how most credit card transactions are conducted when people place orders from Web sites.

With one exception, session-based encryption is sufficient for most common exchanges of business documents. Once the data is behind the firewall, typical operating system, file system, or database access control mechanisms are usually sufficient for ensuring confidentiality. The exception when session-based encryption is not applicable is when using transport approaches like e-mail where there isn't an end-to-end session, as we'll discuss below.

If You're Given Choices

The simplest and lowest -cost strategy for both authentication and security is to log into a Web site using a user name and password and use the browser's built-in support for session security. This method is probably perfectly adequate for most common business document exchanges. If whomever you are trading documents with demands that you use X.509 certificates for this process, it still isn't too bad since most browsers also support them.

The other option is persistent authentication and security. You must have your own public/private key pair for these, and you most likely will need an X.509 certificate. You will also most likely need special purpose software. Your trading partner will probably give you some recommendations.