Security in a World of Electronic Commerce  

By Bernie Cowens, CISSP

Sponsored by Rainbow Spectria

Electronic commerce is an inescapable fact of life these days. Connecting businesses, granting your partners and customers wider access to your data and systems, and the need to leverage the Internet to gain and keep competitive advantages are all commonplace facets of today�s business environment. We rely more and more on information systems, inter-connected business models, and on leveraging the Internet to do business. We take advantage of Internet technology in general and World Wide Web systems in particular to empower customers. In this sense, customers are not limited to the traditional retail variety that would ordinarily visit your store or purchase goods from a catalog. Instead, if you consider the interrelationships between businesses today, customers include in many cases your partners, your suppliers, and even your competition. How you use the Internet to take advantage of those relationships determines your success in today�s marketplace. Using the Internet without a clear security plan is fraught with real peril and is certain to fail.

Businesses have always faced risk. Risk is not new. What is new today is the nuance brought about by electronic commerce systems. Computerized systems save us time and money because they perform exceptionally well those mind-numbing, monotonous tasks that none of us cares to do. Conducting transactions using computerized systems via the Internet can transform activities that were once simply a nuisance and not worth anyone�s effort into lucrative criminal endeavors. For example, shaving a fraction of a cent off of an account each day in a manual bookkeeping system is not worth the effort or the risk of detection. However, if you can figure out how to shave that same fraction off of hundreds or thousands of accounts anonymously, in a matter of minutes, from a thousand miles away, well now you�re on to something.

Recent events have shown us just how fragile and vulnerable our information systems really are and, perhaps more importantly, the severe financial impact of compromises. By some estimates, the �Code Red� virus/worm outbreak cost businesses something on the order of $12 billion. More recently, �Nimda,� following on the heels of the September 11 attack, was unique in its multiple entry points into organizations and foreshadowed the increasingly damaging classes of viruses and worms we can expect in the future.

There are a number of studies available that show tremendous growth in spending on security software and technology to combat intrusions, security breaches and virus outbreaks. At the same time, other studies show that while the latest security technologies are widely deployed, companies still get hacked. It is vitally important that we understand why this happens and take steps to prevent it in the future.

Knowledge Implies Responsibility

Increasingly, the government, the courts, and other regulatory bodies are holding boards and corporate officers directly responsible for losses due to security failures. It is therefore imperative that the agenda for security as a corporate priority be given serious, focused attention at the upper levels of corporate governance. In the past, ignorance of risks, threats, and vulnerabilities might have been a plausible explanation for a breach. Today, however, such ignorance is unacceptable. There is a tremendous amount of attention being focused on electronic commerce security and any company that claims they were unaware of the need to protect systems and data is not likely to be believed.

All too often, however, management wants the IT department to handle the job of protecting the organization�s systems and data. They believe�wrongly�that technology will �fix� the problem. This belief is a significant part of the problem. Security is not a project. Projects, by definition, have a defined beginning and end. Security on the other hand is an on-going effort that does not end and requires more than anything a change in perspective. Security is the responsibility of everyone in the organization and that mindset must pervade the organization in order to succeed in the electronic commerce environment.

People, Process and Technology

The key to secure electronic commerce systems today lies in starting at the beginning. Far too many companies simply deploy a firewall and hope for the best. While firewalls are important, deployed out of context, they are merely expensive sieves. This is in essence a case of putting the technology horse before the policy cart. It can be done, but rarely does it get you anywhere that you want to go.

The first aspect of dealing with electronic commerce security is to acknowledge that firewalls, VPNs, PKI systems, and intrusion detection systems are merely technological solutions to people problems. These problems include not only malicious or intentional attacks, but also security issues that arise out of ignorance or by accident.

The best way to address the people part of the equation and to implement an effective, comprehensive information security program is to establish policies. Policies form the building blocks of any system. Without them, no information security program can succeed for long. Policies help a company identify what it needs to protect, from whom it needs to protect it, and to what degree. Further, they describe what company management intends in terms of protecting data and resources. Finally, they assign real responsibility for security and provide a framework for making decisions that impact or are impacted by security.

Many companies shy away from the policy development process because they have been led to believe that policies should be long, detailed documents that consider every possible scenario. Fortunately, the reality is that the best policies are brief, concise statements that describe a particular outcome, but do not give specific step-by-step instructions for achieving that outcome. A company policy on passwords might be a simple statement that passwords must be strong, passwords must not be shared, and that passwords must be changed periodically. This is a perfectly acceptable corporate policy on using strong passwords and should not require a great deal of change. The details of what constitutes a strong password might well change, but these details can be implemented in the context of the specific systems in use. It makes no sense, for example, to require passwords that are ten characters long for a system that is only capable of accepting a maximum of eight characters.

Once policies are developed, business processes that comply with and support those policies can be implemented. Appropriate processes, grounded in business policies form the harness that connects business policies to security technology.

Only after policies and processes are implemented should any organization consider technology solutions. Security technology should be deployed in the context of business requirements driven by the company�s policies. Firewalls require specific rules to be implemented that either block or allow certain types of traffic. You run into security problems that can result in compromises when you expect your IT staff to decide on the rules without clear business reasons for implementing them. Unfortunately, this is exactly how most electronic commerce systems are implemented today. The network engineer knows in general terms what needs to be accomplished but, he or she may not have an appreciation for which data is most critical to the business or the business� tolerance for risk.

Complexity and Lack of Shared Vision

One of the most significant problems faced by companies today when addressing security issues for interconnected systems is the lack of a common language or framework from which to start. On the one hand, companies exist to conduct business. Their technical systems exist or should exist solely to support that effort. However, without a common language and therefore a common vision, business units and IT departments often find themselves at cross purposes with one another. 

While a business unit has one view of the company�s electronic commerce systems, the IT department may well have a dramatically different one. Business today is about opening doors, empowering customers, and bringing partners and suppliers closer together. You have to operate outside the traditional confines of not only your physical office spaces but your typical network perimeter as well. Those charged with operating, managing and protecting the company�s systems and data, on the other hand, are embattled by mounting Internet-based attacks, increasingly damaging virus outbreaks, software glitches, and denial of service attacks, not to mention a whole range of threats from internal users.

Let�s face it � today�s eCommerce systems are more complicated than ever and the trend is that they will continue to become more so in the future. This is especially true as companies transfer a greater and greater share of their core business processes to the Internet in the years ahead.

The result of this complexity and lack of shared vision is that security technologies wind up deployed in the company �just because.� System breaches and compromises continue to occur with alarming regularity in spite of the latest firewalls, intrusion detection systems and virus scanners. Friction between those charged with protecting the network and those who use it to do business grows to unbearable levels. Finger pointing and mistrust ensue.

A Common Language and Framework

The solution must be the establishment of a common approach for discussing, describing and assessing eCommerce security � one that allows management, business units, and technologists alike to view the company�s information systems the same way, while accommodating their unique business roles and requirements.

Spectria uses a proprietary methodology to accomplish just this. Our approach, called Three Layer Analysis�, is a proven, repeatable, comprehensive methodology for analyzing the security posture of complex systems. This methodology results in systems that have proven to be highly-resistant to attack in real world applications. Our analysis of a variety of existing and proposed electronic commerce, transaction, and data delivery systems reveals common errors which result in flawed designs that are vulnerable to attack and compromise. This analysis shows that these errors typically fall into one of three areas:  architecture, protocols, and applications. Three Layer Analysis� (3LA) examines each of these layers to determine business-appropriate levels of security and to establish risk mitigation countermeasures. One of the unique aspects of 3LA, as we shall see, is that a weakness in one layer can be offset by adjustments in the other layers.

For the purposes of this white paper, we will use a bank analogy to describe our approach to assessing and designing secure electronic commerce systems. Now, let�s take a look at each of the three layers.

Architecture

The architecture layer is responsible for implementing high level data for the system. A trust model is applied and �allowed paths� are created to connect components in the data flow. The architecture therefore, should restrict the paths into and out of your systems according to your intentions, based on your business requirements, according to a user�s role and corresponding level of trust. This simple concept is one that is often overlooked in designing and analyzing systems and is easily illustrated using our bank analogy.

Thinking in terms of a bank, the architecture consists of the physical bank building, the doors, the gates, and similar controls. While their money may well sit in the bank�s vault, patrons are not permitted to walk directly into the vault and retrieve it. Patrons must enter the bank through prescribed doorways and may only access specific areas necessary for them to conduct a transaction with the bank. They are prevented from walking directly into the vault or even the back office. A teller window provides an �allowed path� for transacting business with the bank.

Bank employees, on the other hand, may have different access based on the level of trust afforded them. Employees may access the bank lobby and perhaps the back office as well. Selected employees may have even greater access depending upon their roles.

Protocols

Building on the architecture layer, the protocol layer helps ensure that the allowed paths traverse the trust model without increased exposure. The protocols used are examined to evaluate their impact on the overall security model established in the architecture layer. Some protocols are more suitable than others for traversing trust boundaries. For example, HTTP is a ubiquitous yet complex and immature protocol that is inappropriate for carrying transaction requests from an untrusted Internet source into a company�s back end systems. The protocol itself does not enforce size, format, and similar restrictions on transaction messages. In contrast, protocols like MQ Series are mature, better defined, and more appropriate for crossing trust boundaries. To further clarify, let�s return to our bank analogy.

In the case of a banking transaction at the teller window, the protocol layer consists of the withdrawal and deposit forms that must be used to initiate a transaction. A bank patron may not issue arbitrary commands to the teller. Instead, specific, pre-defined messages must be used to conduct the transaction. If the forms are completed improperly, the teller will not accept them and the transaction will not proceed. These forms ensure that the data elements necessary to the transaction are all present, are within expected size and type ranges, and do not include extraneous or unnecessary commands.

Applications

Once the architecture and protocol level decisions have been made regarding data flow and high-level security protections, the ultimate responsibility for protecting data lies within the applications themselves. The security decisions made during the execution of custom code running on a particular architecture component form the heart of the protection on the allowed paths. Assuming that architecture layer and protocol layer combine to deliver data as intended, the application layer performs inspection of �user supplied data� and implements business logic.

Returning to our bank analogy, the patron presents a withdrawal form to the teller. The teller inspects the patron�s form to determine that the request has all of the required information. The transaction does not, however, proceed at that point with the teller handing the patron money. Instead, the teller applies specific business logic to the transaction. For example, the teller will verify the patron�s identity, ensure that the account belongs to the patron, and finally, will ensure that the patron has sufficient funds to cover the withdrawal.

Know Your Enemy

Not insignificantly, in many respects, a similar approach is used by attackers to breach systems. On an architecture level, an attacker will not try to break through your firewall if other paths are open into your system. Modems left connected to workstations are one example of an alternative path. Vulnerable or unprotected partner systems that connect to your systems might be another often overlooked path into your network and systems.

Many of today�s buffer overflow exploits rely on weak, complex protocols that can be made to carry arbitrary commands to web servers and other systems. Attackers can exploit these weaknesses to gain control over systems in your network. Once they do, they will attempt to escalate and extend that compromise to other systems and data. Your systems ultimately could be used as a launching pad for attacks on other companies and organizations. As a result, if appropriate steps to protect systems have not been implemented, your organization might be held liable for such attacks.

Security Becomes a Business Enabler

This approach to addressing security provides a common language for stakeholders on the business side as well as those on the technical side. Both perspectives are represented and both views of the business� systems and transactions can be accommodated. Using an approach like 3LA eliminates complexity, allowing management and staff alike to share a common view of the goals of the company�s systems. The result is that the technical staff can see the impact of deployment of technologies, whether security-specific or not, on the overall security of the system. The business staff can appreciate the impact of granting access or conducting certain transactions on the system�s ability to resist compromise.

Together, stakeholders in the company can partner to develop policies, implement appropriate processes and implement security solutions that enable electronic commerce and help the company succeed in today�s interconnected environment.  

Visit the Authors Web Site