By Jon William Toigo
If information is as crucial as everyone says it is, controlling who sees it becomes vital. Doing this can be as difficult as it is necessary.
A health care organization seeks to join its hospitals, clinics, laboratories, pharmacies and hospices in an integrated network. The objective: save money and reduce duplication of effort. The obstacle: confidentiality of patient records.
A law firm wants to use public and private networks to transmit legal documents across the U.S. The objective: reduce costs for overnight mail and telephone fax charges. The obstacle: compromise of attorney/client privilege and other confidentiality issues.
A consumer goods vendor would like to sell products over the Internet. The objective: expand market presence and reach millions of potential customers. The obstacle: customer reluctance about confidentiality of credit card information.
As these examples reveal, in this era of enterprise networks and the Internet, confidentiality has become a critical issue. Nearly every company has sensitive information on its systems and wants it restricted from general access. Employees and individuals want their online transmissions of various kinds to be seen only by those for whom they are intended. Without assurances of some level of confidentiality, a company cannot pursue many business opportunities.
But most security experts say that it is impossible to secure any electronically stored or transmitted data sufficiently to absolutely guarantee its confidentiality. To varying degrees, however, it is possible to create an environment in which privileged data can be secured from most unauthorized people who might seek to access it.
In terms of information systems, confidentiality means much the same as it does in general. Unlike privacy, which can be restricted to oneself, confidentiality implies a willingness to share information with at least one other person. There's the rub. "The requirement of confidentiality is to assure that data is available only to authorized parties," says Allan Schiffman, chief technology officer for Terisa Systems, a security technology developer in Los Altos, CA.
Because it is a broad concept even in IS, confidentiality involves other security services whose importance varies with the requirements of a given application. Vijay Ahuja, manager of network security for IBM in Research Triangle Park, NC, describes three of the most common. First is authentication: "I need to prove that I am who I say I am and that you are who you say you are." The second is a data integrity component: "I need some way to ensure that what I say can't be listened to or changed by someone else, possibly encryption." The third is nonrepudiation: "I want to make sure that the person I am talking to cannot claim that I said something else." Yet not every solution needs all of these, at least in the same degree.
For example, Visa International and Mastercard International defined and adopted the Secure Electronic Transactions (SET) protocol solely to enable bank card transactions over the Internet. Terisa Systems collaborated in its development. "The SET protocol addresses security requirements, but confidentiality was not that important," Schiffman says. "It was paramount to provide for authentication of the cardholder. We needed to ensure that the cardholder could not deny that he had made the purchase, so nonrepudiation was also key. There was an integrity element in that we needed to ensure that no one was tampering with card numbers, but confidentiality in terms of what the cardholder was actually purchasing was irrelevant to the protocol."
Ahuja observes that confidentiality requirements differ according to the transaction itself. "For example, if you are sending e-mail over a relatively secure link, you may want encryption for the data that is being exchanged, but you may have no need for nonrepudiation," he says. "On the other hand, if the data is a confirmation of a customer's order for 100,000 parts, you may need nonrepudiation to ensure that the customer cannot say later that he ordered only 10,000 parts."
Most IS professionals acknowledge that today's approaches to security are no more than a perimeter defense against an assortment of unknown-but-assumed-hostile threats from outside. They look forward to the delivery of new technologies, such as virtual private networks, that will enable the creation of secure pipes through public networks such as the Internet. For now, however, perimeter defense seems to be the best that can be done to safeguard sensitive corporate data.
To Cecil Stump, manager of service technology for Picker International, a manufacturer of diagnostic imaging equipment based in Cleveland, the main objective of a confidentiality strategy is to protect product service information from unauthorized disclosure. "Picker International is in a highly competitive industry," he says. "Service is a large part of our business. We need to exercise great care in keeping service information at customer accounts from being disclosed to our competitors."
To Stump, the ideal hedge against the unauthorized disclosure of such confidential information is a secure network. "For our information to be kept confidential, we need to protect the conduit, not just individual e-mail items directed to corporate headquarters," he says. This data comes in from 800 U.S. and 500 international field service engineers. Until technologies for securing the conduit mature, however, Stump must rely on access controls to create an electronic moat around his corporate castle.
Gerard Kiley, director of business development for Siemens Business Services in Burlington, MA, the outsourcing and systems integration arm of the Siemens family of companies, has a different set of confidential information assets but a similar strategy. He is working on behalf of his customers--other Siemens companies and some of their larger clients--to support the use of the Internet as a business medium and to facilitate the deployment of intranets.
Kiley sees little that can be done with current technology to safeguard the network pipe when dealing with the Internet. Again, providing confidentiality currently comes down to authenticating outside users who seek access to internal systems. "Inbound traffic from dial-up or the Internet has to be considered hostile," he says. Judging from specific customer requirements, Kiley believes that a mixture of authentication and encryption is needed to keep data confidential.
Michael Karlin, president of Security First Network Bank in Atlanta, the first federally sanctioned Internet-based savings bank, believes that his venture would be impossible without suitable provisions for confidential electronic transactions. "Deploying adequate security capabilities, in order to prevent theft, is our number one concern," he says. "We aren't talking about securing one transaction. The big threat is having someone gain access to the entire database of the bank."
To Karlin, guaranteeing confidentiality means implementing access controls that prevent unauthorized persons from gaining access to bank systems. Because of the nature of online banking, confidentiality also means deploying a secure operating system that controls what a user can do once the system has been accessed.
Developing and deploying a security solution for enhanced confidentiality can be a daunting task. Obstacles to developing an effective strategy run the gamut from corporate politics and culture, to balancing system performance with security requirements, to integrating a diverse array of products that lack meaningful interoperability standards. Surmounting these obstacles requires a combination of skills, knowledge and imagination.
Given the shifting nature of what an organization may need to do, how can its IS team come up with a technical response to security concerns? Paramount in beginning to answer this question are a sense of the existing IT environment, an understanding of the culture it serves and a will to make the situation clear to nontechnical personnel.
Michael Hulhorst, a systems architect for Applied Cybernetics, a systems integrator in Columbus, OH, has helped clients to formulate security strategies that enhance confidentiality. He lists three basic features of a security system whose goal is confidentiality: It should establish authorization, allow access to those who are authorized, and log accesses for auditability and management. He adds that the system should do all these things easily and quickly.
Identifying current security provisions and assessing their relevance is a common first step in developing a confidentiality strategy, says Hulhorst, and one of the most difficult. The process may be blocked by the first hurdle of strategy formulation: corporate politics and culture. "[At the level of the IS organization,] we often find that people have deployed a set of security tools that are inadequate to the job, but they are hesitant to abandon them," he says. "Just because someone is comfortable with a tool doesn't mean that it is secure. Look at cellular phones."
Another hurdle that must be overcome is determining what needs to be kept confidential. There are often differing views within the company about what data is sensitive and who should be able to access it.
"Confidentiality is subjective," says Hulhorst. "To some within the company, the internal price lists are the most important data. To others, it's the company books. In some companies, there is little concept of confidentiality at all. As a security planner, you have to plant a few seeds of paranoia. Have the decision-makers ponder scenarios you provide, and hope that the pondering bears fruit."
Obtaining senior management backing and cultivating a supportive corporate culture are keys to a successful strategy. When provisions for confidentiality are added to projects that already have acceptable business cases, they are more likely to receive approval than when security is sought as a general principle. "Our concern about confidentiality is seen as a part of our customer support," says Siemens' Kiley. "Our customers want to use the Internet, but they are concerned about its security. By including security and confidentiality components in our network and systems integration projects, we are just being responsive to our users."
Stump, too, has adopted a business case-based approach to garnering support for confidentiality provisions. "We were looking for new ways to connect our field service engineers to the systems at headquarters," he explains. "We previously used electronic bulletin boards, but they were not easy to use and not very expandable. Everyone wanted to look at the Internet or at least at dial-in to our internal systems directly from the field. Both options had significant security issues associated with them. We worked on resolving the security issues as part of the [improved access] project."
In addition to surmounting political obstacles, successful confidentiality strategies must deal with significant performance and interoperability issues. These issues often present themselves when a confidentiality strategy is being formulated and when technologies for providing access control, authentication, encryption and the like are evaluated. The technical elements of a confidentiality strategy include risk assessment, policy and rules formulation, product evaluation and implementation, configuration testing and ongoing reevaluation.
Formal strategy development begins with a risk assessment. Nearly every company has sensitive data or intellectual property that needs to be protected, but identifying them may not be easy. According to Mark Taylor, product line manager for Raptor Systems, a vendor of security products in Waltham, MA, "A planner needs to describe in detail scenarios in which business information assets are placed at risk. Then the planner can identify what kind of security is needed at the aperture to the system or the subnetwork where the information is kept."
"You may find it useful to grade risks [of unauthorized disclosure] from one to five, with one being a minor inconvenience and five being catastrophic loss," says Jeff Kalwerisky, vice president of consulting services for SecureWare, a vendor of security software based in Atlanta. "Understand, however, that some costs are not computable. Exactly how much will someone steal if security at a bank is cracked? What is the dollar value of public embarrassment? Patient records or clinical data may have no dollar value, but their exposure can have horrendous consequences. Establish some means for ranking risks, then create a matrix and average out the exposure."
The ranking of risks assists planners in justifying how much security should be brought to bear on a particular information asset; obviously, the greater the perceived risk is, the more appropriate the asset becomes for protection by security measures. As a general rule, the more security is applied to an information asset, the more difficult it becomes for even authorized users to access the asset.
Risk assessment also focuses attention on the need to balance protective measures and system productivity. All security measures, including those intended to guarantee confidentiality, are achieved at the price of some degradation in system and/or network performance.
For example, the impact of encryption--one possible component of a confidentiality strategy--on system performance can be startling. "Some encryption key-generation processes take between one-half second and two seconds per transaction," Kalwerisky says. "That is not a trivial cost."
Hulhorst of Applied Cybernetics cites examples of 10 to 15 percent data throughput reductions in production networks where firewall and router filtering technologies are deployed to control access to confidential information. He also notes that security can be inconvenient to end users, who must remember passwords and negotiate hardware-based security features to accomplish purposeful work.
"For example, many confidentiality risk assessments identify laptop computers as the big potential leak," he says. "The laptop may have sensitive information stored on its hard disk, such as price lists and bid information. Companies seeking to secure this information need to make sure that the laptops are boot-protected, so that they can't be used by any other person to access hard disk data or the protected corporate network."
At Picker International, Stump confronted just such a challenge as he assessed security risks to internal systems and laptop computer data. "We wanted our field engineers to be able to access the system remotely without having to remember a password," he recalls. "We decided that the first time the user logged on, he would have to enter an assigned password. A new password would be generated automatically by the system and stored in an encrypted form directly in the user hardware. The software on the laptop is non-copyable, so only the user with the laptop could log on, and the login password would be unknown to the user--completely transparent. Of course, this scenario left the system exposed to unauthorized access if the laptop was stolen. So we added a second layer of password protection that required the user to enter a chosen password to access server applications appropriate to his authorization level."
Scenario-based risk assessments such as this one can be useful not only in identifying information assets, threats to those assets and high-level approaches to meeting threats with security, but also in balancing security approaches with production system requirements. Without such analysis, strategies may be forwarded that make sense from the standpoint of security and confidentiality but not from the business standpoint.
Risk assessment should be followed by policy definition. When policies and rules set forth the insights gleaned from analysis, the resulting security measures are both appropriate and manageable.
Policy formulation activities may include defining classes of users and their access privileges. Later these will be translated into rules on an access control server, firewall or router. It is important that the rules be ordered in a hierarchical manner to prevent the exclusion of everyone from access or the momentary inclusion of everyone thought to be excluded.
"Setting up access control rules by groups or classes of users also sets the stage for managing security later on," Hulhorst says. "It is less difficult to manage group permissions than it is to manage individual permissions."
Rules also may be constructed to define the characteristics of protective measures. These can become a checklist for use in evaluating and selecting products that provide certain security functions. One important issue may be spotlighted in this part of the confidentiality strategy-building process: component interoperability.
"Many security products are in an evolutionary period," says Hulhorst. "A vendor may offer a product superior in many regards to the products of competitors. However, it is possible that the product will not become an industry standard and may leave those who buy it with unsupported technology in the future."
Siemens' Kiley is well aware of this problem. "We are waiting for the final adoption of IPsec [an Internet Protocol security standard currently under review by the Internet Engineering Task Force] to facilitate confidential and secure information transactions via encrypted links. Right now, to achieve a secure tunnel or connection, we need to deploy redundant firewalls and do all sorts of kluges to obtain a virtual private network. An IPsec standard will simplify everything by providing a standard way to encrypt and filter transactions between firewalls, routers or other IPsec-compliant security devices."
Elizabeth Kaufman, product manager for IOS security at Cisco Systems in San Jose, CA, tracks the IPsec working group. "IPsec has standardized several methods for authenticating and encrypting IP version 4 packets," she says. "The IPsec standards would provide broad, interoperable authentication, confidentiality and data integrity services for IP networks and applications. The reason you can't buy IPsec products today is that there is still contention over the requirements for public encryption key management. The candidate standards--Simple Key Management for Internet Protocol (SKIP) and Internet Security Association Key Management Protocol (ISAKMP)--have very different capabilities. SKIP is optimized for a workstation/IP environment only, while ISAKMP can build security associations in a multiprotocol environment with low overhead. There is considerable pushing and shoving going on. The only thing preventing their convergence is religion [emotional preference]."
In the absence of standards, companies have little guidance for acquiring security products other than belief in vendor claims. But few vendors offer a range of products broad enough to address all confidentiality requirements. Kalwerisky of SecureWare gives a sense of this divergence. "You will need to consider a combination of hardware and software ranging from secure Web platforms and firewalls to encryption, authentication, virus protection and nonrepudiation software," he says. "Remember that the chain will only be as strong as its weakest link."
Taylor of Raptor Systems suggests that encryption, hardened IP stacks, authentication mechanisms and other strategies may be required to meet security objectives. Companies should also look for "a security management console that will provide a consolidated point from which to configure, monitor and manage security products."
Centralized management and monitoring capabilities are an important stopgap against possible exploitation of security flaws brought about by a lack of interoperability. But Hulhorst of Applied Cybernetics suggests caveats to this approach. "Many companies will be driven to select security devices that conform to their existing network or system platform standards, which may or may not be in line with future standards. This can kill you when technology standards change, and you have to go back to senior management in two years and ask for money to replace what you deployed this year."
In addition, Hulhorst points out that monitoring is effective only if it is used rigorously. "Vigilance in systems administration and monitoring can do a great deal to make up for shortcomings in standards and interoperability gaps. However, most corporations are seeking to get rid of systems administration as a cost center. You will definitely need informed management to ensure that the resources remain available to take this route."
Before any product is deployed, it should be thoroughly evaluated. Customer references should be obtained, and hands-on tests of products should be made where available. In short, the buyer needs to ensure that vendor claims match their confidentiality strategy requirements.
Once implemented, new security configurations should be tested. The criteria used to evaluate products, and the policies and rules themselves, can become the basis for developing a test book: a set of procedures that will be run against the configuration to ensure that necessary security levels have been established and that performance meets expectations.
Performance testing is a validation of the assumptions derived from risk assessment. Planners should measure exactly how much system and network performance degradation occurs when security methods are applied. Testing may also reveal unforeseen political and technical problems with the confidentiality strategy that has been formulated.
"One company for which we architected a confidentiality solution decided to use secure connection modems from a particular vendor," Hulhorst recalls. "Two managers were supposed to communicate with each other via this secure modem link. However, they could not agree on whose modem should be the one to dial back. The problem was entirely ego-based, but it took going to the CEO to work it out."
Other companies have found problems during configuration testing that identified gaps in the integration of their security products. This provides an opportunity to use the results of the tests to define custom application development requirements that can be referred to the vendor or undertaken in-house to close the gap.
Configuration testing never actually ends, experts agree. Ongoing vigilance is required to identify new information assets and new risks, so the existing confidentiality solution can be enhanced as needed to ensure continued efficacy. "In the short term, some fine tuning may be required to find the best mix of technologies," says Hulhorst.
A bigger issue, according to Hulhorst, is the management of changing confidentiality requirements. "Requirement growth is not a linear progression. It has a tendency to grow geometrically or even exponentially. People see the capabilities, then want them for themselves. It is a management challenge, like keeping up with current technologies."
Hulhorst and others recommend engaging a security expert to audit the confidentiality strategy on a routine basis. The objective of this effort would be to identify both the shortcomings with deployed solutions and the opportunities posed by new technologies. However, some consultants have vendor ties, and clients would be wise to constrain them from making specific product recommendations.
It should be apparent by now that there is no short answer to the complexities of ensuring confidentiality. But when an organization's reputation or profits--or even its survival--depend on the way it handles this issue, you can't avoid doing the homework.
Jon William Toigo is an independent writer and consultant specializing in business automation solutions. He can be reached at jtoigo@intnet.net or http://www.intnet.net/public/dolphin.