From Paper to Electrons: Initiating Safer Electronic Commerce
Articles and Tips: article
Senior Research Engineer
01 Jun 1997
Nervous about the prospect of doing business over the Internet? Learn the critical issues both network administrators and business manager need to understand in order to achieve truly secure electronic commerce.
- Introduction
- E-comm Promises and Pitfalls
- E-Comm Security Solutions
- Security Belongs in the Infrastructure
- Conclusion
Introduction
Electronic commerce, or "e-comm," is a term that is used frequently in today's connected world. Evolving from the field of Electronic Data Interchange (EDI), electronic commerce seeks to allow business applications within different organizations to automatically interchange information, thus relieving humans as much as possible from the drudgery of routine data processing. Proponents of e-comm are quick to point out that electronic commerce is not limited to business transactions alone: it can apply to the exchange of any commodity that can be represented electronically, including reference and training materials, software, entertainment, even ideas and opinions.
While most electronic transactions today occur over dedicated lines or Value-Added Networks (VANs), more and more organizations are looking to the Internet as the ultimate infrastructure for e-comm. This movement underscores the increasing need for effective security for commercial e-comm over the next few years. Companies with extensive knowledge of computer-based commerce will need business managers who understand the advantages and pitfalls of evolving electronic methods. Even if your company is not pursuing an e-comm model today, your customers, suppliers, and contractors may well be, and they may soon demand that you follow suit.
Network administrators and business managers alike have the responsibility to understand electronic commerce and recognize how it affects the security needs within their companies. This is especially true for companies looking to implement their own policies toward electronic commerce. Unfortunately, the processes for initiating secure electronic communication are grossly misunderstood, and corporate plans rarely incorporate even the basic necessities of business operation, such as accountability and liability.
This AppNote looks into some of the security concerns your company will need to address regarding e-comm. In particular, it examines ways security services will likely be implemented, so you can make better decisions with regard to what e-comm applications will run on the networks for which you have responsibility.
E-comm Promises and Pitfalls
Electronic commerce is not new. You may already be aware of specific applications, such as electronic checking via modem, which incorporate electronic transactions. You may even be making electronic purchases via the Internet. But these applications are only a small taste of what is possible with electronic commerce.
The promise of electronic commerce is the potential to be able to transact business electronically anywhere, anytime, with just about anyone who has access to a computing device. Imagine your hand-held Personal Digital Assistant acting as your banking teller machine or interfacing with your stock account at a brokerage firm. In this futuristic scenario, a simple electronic device is capable of representing your wishes and commands electronically, immediately, and with a direct audit trail back to the instigator of the transaction (hopefully you).
E-comm is in many ways synonymous with "workflow." Both encompass the objective and the means to accomplish a given series of tasks. As an example, consider an electronically-based workflow system for an insurance company. This system is capable of some rather sophisticated automation. First, it allows you, as a consumer, to discover an insurance company on the Internet and make inquiries using your browser. Among other things, the insurance company's web site provides quotes for insurance rates based on personal information which you either supply or look up. Of course, you do not want to divulge your personal data over an unsecure infrastructure like the Internet, so you simply look up a prospective rate based on general information.
Next, you decide you want to take out a policy with this company. To do this, you must fill out the online application provided on the web site. However, this time you cannot simply do a look-up. You must supply intimate information about yourself, and naturally you would like this personal data to remain secure and unseeable by prying eyes as you electronically submit the form to the company for approval.
After your application is received, the insurance company software informs you that you will need to take a physical or a blood test. It recommends an appointment with a medical firm, offering the ability for you to make one electronically. You take advantage of this convenience and confirm a date and time to allow for the appropriate medical tests. Once the tests are completed, the medical company performing the test analysis directly transmits the results to the insurance company electronically. If there is due medical reason, the insurance company forwards a copy of the results to your physician. All of this communication is done electronically across publicly accessible media (phone lines and the Internet).
If everything checks out, the insurance company approves your application by certified e-mail, and includes a response form that allows you to pay for the insurance electronically. The policy itself is issued electronically (no paper forms) and stored electronically, becoming part of your electronic persona. You are now insured.
Working from an Incomplete Model
For all its promise, the burgeoning field of electronic commerce is fraught with pitfalls. It would many pages to discuss all the security issues involved in preventing private data from being disclosed in the above scenario. But for the current discussion, it's important to understand the differences between paper-based commerce (including today's use of credit cards) and the paper-less electronic commerce that businesses are actively pursuing for tomorrow.
For years, institutions such as banks have been offering "electronic funds transfers" as a service to their customers. However, these transactions are made across dedicated communications lines and are potentially unsecure in some areas of transmission. All transactions are therefore backed up with a paper trail so they can be reconstructed if necessary.
In many situations, the dedicated line used for banking transactions is about to be replaced by the open and unsecure "line" of the Internet. The motivation behind this for banks to allow their customers increased access to services such as electronic checking over the Internet. However, the underlying technology and business model assumptions still do not allow for complete electronic commerce. A consumer cannot set up a fully operating electronic checking account from his or her computer at home. For actual "money in hand," the individual's presence in person at the bank is still required, and it is still necessary to have a signature recorded on the bank's signature card.
Despite numerous discussions and articles aimed at convincing the world that electronic commerce is "almost here" or even "already here," e-comm is far from having a complete and working commerce model. Electronic checking via the Internet teeters on the edge of acceptable risk-"their" acceptable level of risk; your level of acceptable risk really is yours. If you, as a consumer, find that money is missing from your electronic checking account, you must bear the loss until the circumstance is verified by the bank. The bank will work with you, but if it turns out that you are the only one on the system who claims to have lost money and the bank cannot verify where the money went, your story isn't likely to have a happy ending.
Where Is the Security?
Most of the electronic facility we see today is based on existing assumptions, previously established arrangements, and pending agreements between the parties involved. Assumptions such as paper backup and accounting trails can be seen in electronic transactions between banks or other organizations that know each other or belong to the same community. Even Internet-style electronic transactions-which are done across an "open wire" made up of untrusted processors and switches-usually involve some form of agreed-upon and established transaction service, in an effort to provide real accountability.
For example, you can contact a vendor on the Internet and purchase an item by sending them your (no longer private) credit card number from your computer. The transaction itself usually occurs outside the Internet as the vendor calls the credit card supplier and provides their identity, your identity, the transaction, and the amount. The actual money is transacted using very formalized processes which can be done verbally over the phone, or with dedicated (trusted) hardware specifically tailored to the job.
These formalized processes bring up the notion of process integrity or completeness-"security", if you will, but it might better be called a feeling of "protection." It all comes down to trust in the technology and its infrastructure. Why don't banks move all of their services to the Internet now? Why is the actual money exchange in Internet credit card transactions handled over a different media? The reason is that the Internet, with all of its open, unregulated, and unknown processors, switches, servers and workstations, is unsecureable by technology alone. It is untrustable by its very nature. It is very unreliable for supporting the majority of business needs, especially in light of accountability and liability issues.
Cryptography Isn't Security
Security is often proposed only in the technological terms of cryptography as the single means for "cleaning up" the unsecure Internet. However, this approach entirely ignores the issue of trust as it relates to the use of cryptography, or real security versus the statistical nature of cryptographic algorithms.
For the purpose of electronic commerce, security must provide the ability to keep the fundamentals of business the way they should be. Yet commonly understood business processes, procedures, and models cannot simply be replaced by electronic constructs. For instance, you cannot affix an electronic or digital signature to an electronic document and have it mean the same thing as when you sign a bank's signature card in ink. A lot more is involved than your signature. For instance, when you present yourself at the bank, the bank has a videotaped record of your presence. They cross-check your driver's license and verify your mailing address. All this serves to substantiate the fact that you did indeed sign that card. Recognizing that your risk is higher than the bank's risk, these various incidental proofs provide enough evidence for the bank to legally differentiate you from someone else, based upon your physical signature.
Where are the electronic analogies to pen and ink signatures that will give digital signatures the same or greater level of trustability? Controls guaranteeing that a digital signature is yours are not yet available in the commercial marketplace. Those who insist that these controls do exist at the commercial end-user level are mistaken. Technology cannot currently make up for both trust and liability-two very important business constructs that must be in place before electronic transactions can be performed safely and reliably.
The Challenge of E-comm
Because there are few modeled electronic business processes which can sum up and account for the critical things that paper-based processes have handled for years, there is no agreed-upon structure upon which electronic commerce can be built. Since the electronic medium is different (electrons and magnetic fields instead of paper and ink), the checks and balances used to sum up and account for things are different. The big question e-comm experts, system designers, and programmers are wrestling with is, "How should business fundamentals be represented in this new medium?"
For example, when a bank archives important information such as your signature card, they use micrographics (microfilm or microfiche). In the context of business, law, and governmental regulation, micrographics are the approved medium for document replication and archival. This is an extremely important construct for the business world. Yet there is no standard agreement in the electronic world of e-comm to facilitate or to even substantiate this necessary process. In terms of our insurance company scenario, how does your electronically recorded insurance policy get validated, and how will a claim be paid when the need arises?
This, then, is the biggest challenge of e-comm-to construct a business model or plan that equals or exceeds the business rules that are already in place for paper-based business. To do that, those who are pursuing electronic business must progressively learn all of the reasons why these business rules were established in the first place. That may prove to be very expensive and time-consuming, but it's got to happen if electronic commerce is ever going to be considered on the same footing as paper-based commerce in our society.
E-Comm Security Solutions
Today's limited e-comm and workflow applications are implemented mostly on local area networks (LANs) or on isolated wide area networks (WANs). Since these types of networks are less likely to be the target of an attack by malicious software or individuals with malicious intent, e-comm and workflow applications do not normally expose the customer to inordinate risks. Today's solutions revolve around a combination of paper-based and electronically-based commerce. However, today's solutions may well be inadequate for tomorrow's implementations that will need to consider interconnected networks with public processors and switches, such as the Internet. In that environment, information sharing through nonsecure processors and switches may well present an untenable workflow environment in terms of security.
As the e-comm environment changes, there are alternative options to consider in providing a security-enabled infrastructure. Some of these alternatives are:
Simply ignore the risk and implement applications on an insecure infrastructure.
Have developers formulate their own security infrastructure or incorporate pseudo security services in their applications.
Demand a suitable infrastructure and standardized security services from operating system vendors.
Option 1: No Security Services
To explain the necessity and nature of providing standardized security services for electronic commerce, the critical need may best be exemplified by looking at what would occur if there were no security services at all.
Without reliable, testable (and therefore trustable) security services that can be easily maintained and which are transparently scalable, there is no feasible way a medium- to large-sized corporation can associate an individual's commands, entries, and instructions with the actions carried out by the system. This is known as accountability. While there are various levels of accountability, the underlying assumption is that the computer and the user are synonymous. This association is not always valid. Without security services originating from the operating system and platform hardware, it is difficult to establish and maintain the identity of the user, the integrity of the software, and the confidentiality of the data.
Without a rigorously designed operating system infrastructure-one running on a known platform and providing trustable applications with a specific level of accountability-there is no way to assert that the user of a program is in fact the user of record in the audit log, or that the data used in the application did in fact come from the user of the application. With no direct association and no means to establish the ongoing "true" identification of the user-application association, there is no accountability.
Additionally, without a comprehensive and independently-evaluated security service infrastructure, there can not be any assurance of "real" confidentiality or privacy-not even for the data used in applications control. Even for security-conscious developers-those who are trying to circumvent poor infrastructure with applications-based cryptographic implementation-there cannot be any known level of credibility. Without underlying infrastructure and operating systems controls, there is no way to maintain the integrity of cryptographic constructs such as keys and algorithms. In short, there can be no privacy or confidentiality, nor can there be data integrity.
These are all serious concerns for the application developer. System administrators and business managers must be cognizant of these concerns as well, and they should expect, if not demand, that developers address these security issues appropriately.
Option 2: Developer-Implemented Security
There are significant reasons for developers to consider carefully whether they want to enable security services in the applications software or if they will rely on the operating system infrastructure to provide complete security services. This is not a matter of developer skill or ability, but rather of the inability of operating systems and platforms to provide essential security services and protections.
One of the most glaring examples of the failure of operating systems to provide essential security services lies in the inability to establish ongoing end-user authentication throughout the computer session; there is no way to maintain the established identity of the user. A developer's only option at that point is to provide pseudo security services, or try to design around the lack of operating system-based security. In either case, application-designed security leaves the developer liable and responsible for providing real assurances in the face of hostile environments. Given the number of developers, the variety of methods, and the difficulties of satisfying governmental regulations, this represents a time-consuming, costly, and misdirected endeavor for application developers.
Security is no better than the weakest part of the system. Today, we see individuals attempting the initial forays into electronic commerce over the Internet, which is made up of switches and public lines that are "unsecure" at best. Worse, the media over which data traverses processors and switches are unexamined and uncontrolled, leaving private and confidential data basically open to eavesdropping.
Building applications from a level of incomplete system Identification and Authentication (I&A) and not being cognizant of imposed audit requirements only perpetuates the security flaw, and promulgates the risk of attack on critical systems across the network. In this case, the weak link can be either incorrect identification or low system integrity. In an environment where commercial off-the-shelf software is used, persistent identification of users starts with the client and network operating systems, just above nondedicated commercial hardware whose configuration and processor must at least be known, if not controlled to some degree.
Any monolithic security implementation is broken from the start. Security that does not work in layers and doesn't provide specifically testable interfaces is ineffective. Application security built on top of incomplete, non-assignable client or network session security is worse than no security at all because customers believes they have some level of trustability and accountability, when in fact they have none.
When grappling with a security solution, developers should not resort to merely laying out the security specifications and then implementing them in the application's code. Developers should redesign beyond those underlying premises which must exist for accountability to exist. It is a problem when developers put security in the application, as it leads to architectural mistakes which cannot be corrected even with a complete rewrite of the application's code.
Option 3: Standardized Security Services
There are major pieces of infrastructure which must be available to developers to dissuade them from circumventing operating system level controls. The most basic of security-oriented actions are to restrict access to authorized individuals and roles, and to perform and maintain proper association between the application's activities and the correct source of activity.
It is important to recognize that management's will is implemented and instantiated first by the system software and then by the applications software. This requires three basic services originating from the operating system infrastructure, which can then be used by the applications' infrastructure:
Integrity
Reliable, persistent authentication
Controlled sharing and collaboration
Integrity. Assuming that the systems level architecture is of a known value (ITSEC E2/3 or Class C2+), the next step is to ensure that the software arriving at the computer is the "real" software the user wanted. Neither competitors nor disgruntled employees should be readily able to disrupt the workflow. This is especially true for transportable code and code segments, as well as for the programming tools. Because not all certificates are created equal, the integrity check is of greater value when combined with a certificate denoting both the origin of the integrity-checked code and the quality of the certificate authenticating the code. Beyond fitness of purpose, integrity is the first predicate for application software viability in a "open" marketplace.
Authentication. Persistent authentication means that once authentication occurs, the authentication continues to be attributable to the correct end-user, thus ensuring correct accountability. This is needed since accountability in workflow is dependent on maintaining the individual's real identity. However, methods such as revalidating user IDs and passwords only expose system identification secrets when the machine is no longer in a known and protected state. Additionally, circumvention of system controls allows the possibility of duplicate audit records, potentially abnegating the preponderance of evidence needed for accountability.
Collaboration. Controlled sharing and collaboration are necessary for any workflow-enabled application. The implementation of controlled sharing beyond those attributes given by discretionary access controls will be essential. Yet the means and methods for ensuring the integrity of workflow mechanisms in an open environment are not well defined by vendors or programmers.
It is essential that instructions and information transmitted across open spaces arrive with both correct identity and integrity. They must not be available for inspection by unauthorized individuals. In commercial off-the-shelf environments, this type of protection has typically been handled by discretionary access controls operating across highly controlled media. However, these types of solutions will not be effective in an open environment.
In an open environment where companies have interconnected applications and data, it is essential to prevent the unauthorized disclosure of sensitive information. This is equally true for test implementations of workflow. Such tests must be performed under the exact same circumstances as in a live production system, but without contaminating the real systems. This is an ability of controlled information sharing when properly enabled.
Even if you do not have the test case scenario, information must be protected within a robust information management model: users cannot manage the system themselves. Clearly, the model must be bound to a strong, global, and persistent policy for sharing and collaboration. If a company is to have any means for global information management, the policy must provide the same answers no matter where you are in the organization. Information policies that are global and persistent must be non-discretionary policies; by the very nature of open communications, they will depend on the nature of the authentication.
Security Belongs in the Infrastructure
The logical conclusion is that developers should not build security themselves; the operating system infrastructure must perform the security tasks. This is the same issue for obtaining reliable integrity. It highlights the need for a global registry service which can be applied to application software and reveal the source as well as the grade of validity surrounding the integrity.
If the actions of the individual are to be accounted for, authentication must take place where the flesh interacts with the cold steel of the machine: on a trusted workstation. Such a workstation features selectable mechanisms that offer grades of verifiable authenticity and accountability. Identifications can be persistent from the use of tokens, biometrics, or any of the verifiable requirements for complete identification (something the user knows, something the user has, or something the user is).
Of course, if the individual has significant rights that are high, a simple password may not be enough. By coupling a relatively low level of rights with a keyed-in password, a policy can enforce access to areas where relatively small damage can be done.
Conclusion
Implementing security techniques such as those outlined above will enable businesses to provide an enforceable electronic commerce policy for individuals, roles, and groups. While the methods and infrastructure to allow electronic commerce are complex, developers must have the facility to use standardized security services rather than build security into their products. They must be granted the extra time it will take to produce reliable and secure programs within an infrastructure that provides effective security services. Only ;then will it be possible to achieve true security no matter where applications are run.
* Originally published in Novell AppNotes
Disclaimer
The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.