Security

Designing an E-commerce Security Architecture

There are no green fields for most companies, so the security architecture must provide a framework for integrating existing products and tools to meet current needs, as well as accommodate migration paths and anticipate future business directions.

By Jody C. Patilla

Table: The Cost of Computer Crime

In the best of all possible worlds, what every CIO wants is a couple of cans of Magic One-Coat-Covers-Everything Security Paint. Corporate Web server? Paint it! Remote access server? Paint it, too! Heck, we can even paint the data center and all the wiring closets. Boy, that was easy.

Alas, in the very real world in which businesses must operate, securing transactions, data, and infrastructure is much more complicated. Although many vendors would like you to believe otherwise, there is no one product or practice that provides 100% comprehensive security-in-a-box for your entire enterprise network. Rather, a successful information security program combines a heterogeneous mix of hardware and software with policies and best practices, and requires the combined efforts and cooperation of everyone in the organization. The blueprint for pulling those products and practices together to meet the standards set forth in the policies is the security architecture.

Developing the Blueprint

How does an organization go about developing security architecture specifically for e-commerce? The word "e-commerce" typically brings to mind the fully online storefront, such as Amazon, or the bricks-and-clicks sites like LL Bean, or the industry exchanges, such as Ariba. These large-scale business models are not representative of most companies' needs, however. In fact, the rush to implement exclusively e-commerce applications and infrastructure solutions has been waning. A recent survey conducted by British research firm Business Intelligence showed that 64% of companies are 12 to 18 months away from a technology infrastructure plan that supports e-commerce.

It's safe to say that most companies are not racing to embrace full-blown enterprise-encompassing e-commerce business models. There are very few e-commerce pure-plays. In fact, most efforts are relatively modest adjuncts to existing models and systems. Often, a company wants to move an existing application to the Internet, perhaps extending its capabilities at the same time. This is usually done for one of three reasons:

• To save datacom costs by using the Internet instead of dedicated circuits or value-added networks (VANs);
• To disintermediate an internal business function (such as customer service) by reaching directly to an audience (having clients update their own records online, for example); or
• Because a business partner or industry group is driving the requirement.

A company may well be planning to do this with several unrelated applications, each as its own project. Unfortunately, it is also not uncommon to find multiple business units within a company that have several similar, parallel projects underway, but there is no communication or coordination going on among them.

Source: Computer Security Institute, CSI/FBI Computer Crime and Security Survey

Cyber vandals are targeting companies' Internet connection as a point of attack, with the percentage of attacks rising steadily over the past five years, while breaches occurring via internal systems and remote dial-in are decreasing.

Capturing Strategic Vision

This is where it is most apparent that developing a coherent security architecture is critical for e-business ventures, whether large or small. The security architecture provides the framework for integrating separate products and tools to meet current needs and anticipate future business directions.

At its highest level, security architecture captures a set of goals that incorporate an organization's strategic vision. This vision serves as a roadmap for the security engineering process. It includes detailed designs, product selection, development, implementation, support, as well as management of an information system and technology infrastructure. This enterprise-wide architecture guides all of an organization's development activities, along with information systems and infrastructure development activities, such as networks, servers, and middleware.

Security architecture functions in a similar way. One of the most important aspects of security architecture is the ability to trace architecture back to an organization's business goals. Basic security goals provide direction for the security architecture.

Some primary security goals include:

• Protecting data confidentiality;
• Making certain that unauthorized persons or systems cannot inadvertently or intentionally alter data without being detected;
• Ensuring that the information accessed is genuine;
• Making the data accessible and usable;
• Logging transactions and data exchanges; and
• Verifying the identity of a person engaged in a business transaction.

The intentional planning process involved in developing the security architecture helps a company avoid "design through accretion." This is what happens when networks grow by adding or absorbing bits of technology as acute needs are perceived—like slapping successive patches on a tire. After a while, it's all patch and no tire, which is not unlike a number of existing enterprise networks that "just grew," without an intentional plan for expansion.

Multiple parallel point solutions breed unnecessary complexity, which is the enemy of security. One of the goals of security architecture development should be to aggregate required functionality into clearly defined, standardized solutions. If possible, IT should consolidate requirements into a workable number of basic types or templates, and offer a menu of options to cover each category. This saves time and money by supporting standard, repeatable solutions, and avoids reinventing the wheel for every new project. For example, the menu could offer two or three authentication options for different levels of assurance. "Prefab" design templates speed the development process and reduce the possibility of introducing new vulnerabilities with each new round of development.

To be effective, the development of the technical blueprint must be accompanied by an explicit business process that ensures the integration of security into e-business projects from their inception. This avoids the last-minute rush to add security controls after the project has been developed. Remember, security must be "baked in," not "bolted on."

Many companies already have a software development, project development, or life-cycle process; this process can be adapted and expanded to include security components in every phase. To date, most security development efforts have focused on infrastructure, such as firewalls, monitoring tools, or network access controls. Although basic infrastructure security is very important, it is by no means the whole picture. Companies need to put just as much effort into securing applications, and in developing and incorporating secure practices into their business cycles. It's also vitally important to put nontechnical controls on an equal footing with technical controls.

The Right Foot

The first step in the process of a new e-commerce project should be to list the business gains versus the known risks and constraints. This involves assessing the risks (business, technical, legal, etc.), which is where many projects get off on the wrong foot. Business unit managers may not understand the risks from a technical perspective, and technical staff may not be focused on the business issues. Education and cooperation are important throughout the process.

During this phase, the initial questions should address the scope of the project. Does it involve a single application (or a single business need), or are there multiple applications? If there are multiple applications, are they interrelated or standalone; that is, will they rely on the same data, or the same participants, or are they functionally independent? Is the application an existing one that is being moved to the Internet, or is it being developed specifically for the Internet? Is it a point application or does it involve redesigning a specific business process, or even overhauling an entire business model?

Once the project team has identified and understands the risks, they can develop a risk mitigation plan, and conduct the cost/benefit analysis. The analysis should culminate with senior management recognition of the residual risk, and a formal acceptance (such as a sign-off) of it.

The development, integration, and implementation phases follow, and should include an emphasis on building secure applications. Training classes for application developers are often a good idea, especially if in-house staff are unfamiliar with Web-based authentication methods, cryptography tools, and general secure coding practices. Preproduction testing should focus on security as well as functionality, perhaps through the use of in-house or external tiger teams. In some companies, internal audit may also be involved in this phase.

Before the new project goes into production, the project team should create a post-production maintenance plan, to cover roles, responsibilities, and priorities for installing vendor patches, creating and installing internal patches, and addressing user issues. Finally, the new project should be added to the enterprise business recovery plan.

Unfortunately for the teams designing and building e-commerce networks, there are no green fields. As it evolves, e-business is becoming just business. Very seldom will anyone have the opportunity to build a new solution from the ground up. Most of the time, there is existing infrastructure in place, and legacy systems and applications with which to interoperate. Part of the role of the security architect is to consolidate internal and external requirements, assess existing capabilities, and build migration paths.

Portal Example

An example application designed and built by METASeS demonstrates how to develop a security architecture. The application is an information portal, in which paying subscribers access a closed Web site to view, upload, and download various types of information. It does not have a transactional component, such as one might find at an online store, but it has many of the same security requirements and components. We won't drill down into specific implementation details here, but this should provide guidance for any project team beginning a similar effort.

The security architecture and design for the portal system comprises two separate but equally important areas. The first is the technical controls, the various hardware and software elements required to secure the overall system. The second is the nontechnical controls, or processes and procedures. These two areas of the security architecture and design—in combination—are implemented to protect the confidentiality, integrity, and availability of the data contained in the portal system per the security requirements captured in the Requirements Document and outlined in the following sections.

METASeS broke the security requirements into four categories:

• Key assets being protected. These included proprietary company information, confidential customer information, internal network assets, and brand reputation.
• Key threats to protect against. METASeS identified the main threat sources as cyber vandals, disgruntled employees (our own or our clients'), industrial spies targeting our clients, and system administrators who might delete information in error, or accidentally leave accounts or files unprotected.
• Key activities to protect against. The activities or actions we were most interested in preventing were unauthorized data access, intentional or unintentional deletion or alteration of data, and denial of services. Other sites with different business goals might identify fraud detection and prevention or transaction security as their primary targets.
• Relative ranking of fundamental security goals. This is an important exercise for every organization as part of the risk mitigation planning process. For this project, the ranking came out like this:
  
  • Confidentiality: high
  • Integrity: high
  • Availability: medium
  • Auditability: medium
  • Nonrepudiation: N/A

The project began with the following list of seven broad technical control areas—the minimum that a security architecture should address. Each category can be further broken down into additional subcategories.

• Hardened infrastructure. METASeS followed standard best practices for hardening all of the servers, including using the lowest privilege possible for services, compartmentalizing functionality, and removing all unnecessary services. The Web server software and other applications run in restricted environments to prevent an attacker from leveraging software flaws to gain privileged access to the operating system or critical services.
• Hardened applications. The application was designed to be stateless—no session information is stored that could be captured or compromised to gain access to the application. There is no mobile code, lessening the risk to both servers and users.
• Access control. The application server controls access by specific users and groups to specific content through a Security Manager component. This obviates the need for user management at the Web server level (thus also making it possible to implement read-only Web servers). Users authenticate with user IDs and passwords, while system administrators are required to use strong authentication. Firewalls restrict access at the network layer.
• Encryption. Requiring SSL connections between the Web browser and the Web server ensures confidentiality of data passed between users and the portal. All administrative remote access to the servers uses an encrypted secure shell (SSH), and all files are encrypted in transfer.
• Auditing and monitoring. METASeS implemented logging at multiple layers, including network, OS, database, and application. Log data is captured and stored on a secure host for processing and retrieval. Use of an intrusion-detection system complements logging.
• Backup and recovery. All the servers are backed up regularly. The saved data is encrypted and copied off-site for redundant storage.
• System redundancy. All major system components are redundant. Use of a load-balancer appliance maintains availability of the Web servers. Load balancing is also being done for the application servers, which provides the added performance benefit of some degree of caching.

METASeS balanced the technical controls with the following list of nontechnical controls. Again, this is a fairly basic list that should apply to nearly every e-commerce project, although the mileage a company derives from each element may vary.

• Secure development life-cycle process. METASeS followed its own methodology for designing security into every phase of project development, beginning with the requirements definition, and continuing through design reviews, implementation, testing, and approval.
• Annual risk assessment process. It was decided that an annual independent risk assessment was sufficient; companies in other industries or with higher-risk applications may decide that semi-annual or quarterly assessment and vulnerability testing is necessary.
• Ongoing vulnerability management process. This is the day-to-day maintenance task of tracking and evaluating bugs and patches. It is closely tied to ongoing configuration management efforts.
• User awareness and training. This is always important, for all communities of users. METASeS provides initial training for clients, and updates for both clients and maintainers as needed.
• User administration. Depending on the type of application, adding and verifying users may be a simple, automated process, or it may require some level of staff intervention, whether initially or later, through customer support.
• Physical access control. Physical security is such a basic requirement that people sometimes take it for granted, yet direct access to servers and network devices practically guarantees access to the data and the configuration information. A secure hosting facility was chosen for this portal project, where METASeS staff have the ability to drop in unannounced to get hands-on access to equipment.
• Real-time monitoring and incident response. Intrusion detection and log monitoring is important, but not worth a hill of beans if an organization doesn't know what they will do when they actually detect an intrusion. METASeS created a flow chart and decision tree of actions, and developed procedures for response.
• Audit/log review. This is another ongoing maintenance activity that must be factored into the cost and upkeep of an e-commerce project.
• Change management. Mainframe system programmers have long had well-established procedures for system and software change management, but these practices haven't always carried over into the arena of Web servers, firewalls, and Unix or NT-based application servers. The need hasn't gone away, however, and every organization should develop processes for approving, testing, and documenting changes to applications, operating systems, access control lists, and configuration files. Using source code control software to maintain router and firewall ACLs is not a bad idea, so an organization can always fall back to the previous configuration, or compare new and old configurations in the event of problems.
• Availability monitoring and system recovery. System availability is monitored at several levels on a regular, automated basis.
• Disaster recovery. METASeS's secure hosting facility has a complete disaster response plan insofar as the physical devices and infrastructure support is concerned, and we have developed our own plan for the applications and data. This is a good time to mention that if an organization chooses to use a hosting facility, that facility should provide documentation covering their call escalation procedures, monitoring methods, and disaster recovery plan.

Full-time Work

Developing a workable security architecture is not a part-time job for one or two people. It's a fundamental activity that requires the participation and cooperation of a number of people from across the organization. But the return on investment for making the effort is significant, too—once the architecture has been defined, it can save money, save time, and maybe save your skin.

Jody Patilla is chief analyst for METASeS, a leading security services company that assists customers in building security architectures, as well as developing best practices for creating secure applications. Patilla has 20 years experience with systems and network architecture, management, and security, as well as database design, quality assurance, and project management. E-mail her at jody.patilla@metagroup.com.

For more information on this topic in the future, register Here.