How to Practise Safe b2b

IT and security leaders spell out their security requirements for their online partners and explain how they make sure their partners comply.

Before swapping information with multiple e-commerce partners, it pays to protect yourself by pushing partners to adopt better security practices.

In the Northern summer of 2000, Visa unveiled its "Digital Dozen", a list of security requirements calling for firewalls, encryption, testing and access policies that its service providers and merchants must have as a condition of doing business with Visa. That's right - if a bank or merchant can't play by these rules, they don't play with Visa.

Visa's merchants and service providers must annually demonstrate compliance, through an online self-assessment for mum-and-dad shops and extensive third-party audits for merchants or service providers handling large volumes of cardholder information. And if a merchant refuses to comply, Visa can fine the bank that processes that store's transactions. Then it's up to the bank to punish the merchants. "Eventually, if we don't have proof from an independent third party that you qualify with our requirements, we really don't want you to take the card," says John Shaughnessy, Visa USA's senior vice president of risk management.

Not everybody is as deadly serious about B2B e-commerce partner security as is Visa. In the stampede to e-commerce, most companies have disregarded the security of their partners and their role in exerting pressure to make sure they're safe. "My sense is that B2B security is not a consideration for many organisations," says James Wade, chief security officer for the Federal Reserve System and president of ISC2, a training and professional certification organisation for IT security professionals. Many B2B relationships spawn from manufacturing, marketing or some other group within an organisation without involving IT security.

That may or may not be the case in your company, but regardless, it's your responsibility to see to the security credentials of your B2B partners. "The security of your B2B partner is as important as their creditworthiness," says Paul Gaffney, CIO of the office-products retailer Staples.

Indeed, the risks of working with a nonsecure partner are frightening. A partner that fails to secure its own systems could become a launch pad for attacks into your system. Someone could tamper with data in a supplier's system, such as switching a digit in a product SKU number. Or a virus could disable your partner's systems. Either way, your just-in-time supply chain operations will grind to a halt. Worst of all, you might incur legal liability if your partner exposes your customers' data. "Your customer will ask: Â'Why didn't you investigate this partner?' That customer can sue you," says Dorsey Morrow, general counsel for ISC2.

Of course, it's not just about the risks. Safe B2B e-commerce carries huge business benefits too. In fact, companies can market the security of their B2B programs to enhance customer confidence and thus attract additional partners. Safer B2B practices also protect against glitches and outages, preserving the critical just-in-time nature of e-commerce, which keeps the revenue flowing.

With so much to lose and to gain, every company should establish a set of security expectations for its B2B partners, drawing from the list that follows. In addition, take heed of the strategies to counter resistance and enforce compliance since you will be dealing with companies that aren't under your control.

Page Break

Requirements and Expectations

A Documented Security Policy

Security experts say every company should demand to see its B2B partners' written security policy. Lee Holcomb, CIO of NASA, says that is something he's strict about because he uses online connections to post competition opportunities and pay aerospace vendors and contractors. He expects policies to include firewall maintenance and patch-service provisions and to provide for vulnerability assessment and intrusion detection, as well as a training program for systems administrators who would have access to sensitive information. "We're dealing with astronauts or pilots in space," says Holcomb. "Security and safety are synonymous."

The Federal Reserve typically asks for a written description of a partner's security organisation, including its rules and responsibilities and where the security function reports. "If security is buried in the technical bowels of an organisation, it's probably not having significant influence on senior management," Wade says.

The policy should also identify individuals managing the partner's security program, adds Harry DeMaio, a director in Deloitte & Touche's enterprise risk practice in New York City.

Secure Application Development Practices In most B2B relationships, partners grant limited authority to pass into each other's systems and access critical information. If your partner is using proprietary applications that touch your system, security must be built into that application. Your partner must show you how security is incorporated into its application design, development and deployment plans, says DeMaio. Look for access and authorisation controls built into applications, path isolation to ensure that the app's user goes only where he's allowed to go, and logging and reconciliation to provide a record of where any user has been - matching up with what he's done. "Make sure the application doesn't turn off or ignore other security controls, like encryption, associated with the [B2B] system," adds DeMaio.

Access Control and User Authentication

Lax access controls within your partner's systems will give you a big headache. Ray Bedard, a partner in PricewaterhouseCoopers' supply chain practice in the US, tells of a company he worked with that failed to terminate a departing employee's access to its B2B applications. Before the employee left, he went into the system and ordered a bunch of goods from an online partner. The goods arrived and nobody could figure out what they were doing there. It took several hundred man-hours for the parties to resolve the mess.

To avoid that sort of tampering, companies should require partners to maintain strong, active password programs. Measures should include requirements to change passwords frequently, monitoring and logging of password usage, tools to detect easily guessed passwords and a central authority to set access policies. Wade adds that you should forbid your partner to set up departmental passwords if the partner accesses your systems through its network. "This is always a sticking point in negotiations," he says. "The partner always wants to use some easier form" of password protection.

For sensitive information, companies should require higher-level access and authorisation tools. Ramana Palepu, CTO of the Worldwide Retail Exchange, says his members require public-key infrastructure authentication technology, and will expect digital signatures for financial settlement and payment services the exchange may offer in the future. But for less sensitive transactions, such as purchase orders, auctions and item tracking, strong password and user-name controls suffice.

Page Break

Encryption

Experts and practitioners say companies should require their partners to use encryption for any sensitive information - customer data, marketing strategy, labour relations and unreleased financials - transmitted over the Internet. The Federal Reserve is constantly dealing with financial information, so Wade requires anything transmitted between the Fed and its financial and banking partners to be properly secured.

At JP Morgan Treasury Services in New York City, Joe Calaceto, who heads up security as vice president and technical director, requires varying levels of encryption of customer information such as account numbers and beneficiary names and addresses.

Gaffney says Staples requires its B2B partners to encrypt all Internet transmissions, but he doesn't require encryption for transmissions sent over private networks. "That would be overkill, since one of the reasons we're paying a premium for a private connection is for its security," he says.

Response Plans

DeMaio says the response plan is where to expect resistance from partners. Most companies focus on perimeter defence because it's sexy, but once they think nobody can get in, detailed response plans seem like overkill. That is a mistake, and you shouldn't let your partners get away with it, says DeMaio. "Too many organisations will simply fade and say: Â'OK, you don't have to do it.'" DeMaio adds that partners should provide a detailed description of their attack response plan - and it should be designed around specific systems, not generic boilerplate from books and manuals.

Also, demand that partners notify you of security incidents within the hour. Charles Le Grand, director of technology practices at the Institute of Internal Auditors, adds that you should ask to see your partners' criteria for notifying authorities and how they're monitoring for vulnerabilities. For example, if they operate in an NT environment, urge them to keep up with NT BugTrack, he says.

Segmented Architectures

Some security analysts advocate "segmenting" enterprise architectures into smaller networks, all behind separate firewalls. That way, if one part of the network is compromised, the rest remains safe. Defence contractor Lockheed-Martin does that - and looks for it in its partners too, says A. Padgett Peterson, Lockheed's senior security analyst.

Background Checks

If it's standard practice in your own organisation to conduct background checks on employees with access to sensitive data, it's reasonable to request the same for partners' employees who also have access. Wade declined to say whether he requires background checks of the Fed's partners, but he's required it while working at other companies. By having business representatives, not just IT people, involved in the negotiations, you're more likely to get your partner to agree to background checks. "It's difficult for many IT people to appreciate the risks involved in the relationship being established," he says.

Compliance Audits

Experts and practitioners agree the best way to validate compliance is through periodic audits, either by your own auditors or an independent third-party security company, as Visa requires. Typically the party requesting the audit will foot the bill.

The most security-conscious organisations require their partners to submit to penetration testing on a regular or random basis. But Le Grand says that is an extreme measure, because there is potential to bring a partner's system down. "If you run a denial-of-service attack just to see how they recover, the recovery will be expensive," he says. "So you'd better not do this haphazardly and without agreeing on your right to do this."

Page Break

Inducements and Enforcements

The Carrot

If you work for a powerful company with partners that absolutely depend on your relationship, like Visa, you have the power to make demands. Unfortunately, most companies don't fit into that category. Instead, they must come up with carrots to entice partners to agree to their terms and incorporate them into contracts.

For example, if your partner objects to security requirements because of cost, offer to share some of the cost. A partner "might baulk at an extra few hundred dollars to pay for the setup of an extra server", says Calaceto. "In some cases we'll absorb it because we want a more secure system."

Or you can offer to include your partners in your security software licensing agreements to save them a few bucks, says Le Grand. Here Bedard advocates a "matching fund", where a company offers to kick in a dollar for every dollar its partner spends complying with the requirements.

Finally, Gaffney suggests offering discounts or preferred-seller status to partners that accept your requirements. "If a company associates economic value [with its requirements], it needs to be part of the negotiation," he says.

The Stick

Enforcement is an issue that companies should plan for in advance, with the hope of never having to exercise the stipulated penalties. The best way to enforce security requirements is to establish them in your B2B engagement contract. That provides a specifically delineated recourse should the partner fail to implement sound security measures. According to ISC2's Morrow, the ideal recourse against a lax partner is indemnification - an agreement that if you get sued for damage caused by your partner's breach, the partner will pay you back the amount of the judgment. Of course, that requires proving that your partner was truly responsible.

On a case-by-case basis, Staples will provide in its B2B contracts that the partner will indemnify Staples for damage or legal liability stemming from the partner's security lapses. But Gaffney says such a provision can be tough to secure. "The bigger companies - particularly larger software providers - tend to stick hard to holding back on indemnification," says Gaffney, adding that smaller companies might agree to indemnification in return for more favourable pricing or product distribution.

Another form of recourse is a liquidated damages clause - a contract provision stating that a partner that doesn't live up to its security obligations (resulting in contract cancellation) will pay the other partner a set amount of money.

Finally, if a partner violates the contract by, say, failing the audit, you have the right to terminate it. But think twice about applying these sticks just because your partner has fallen short on an audit or failed to meet a particular requirement, especially if you haven't been harmed as a result. The ultimate objective of your B2B engagement is a productive, profitable relationship.

The minute you seek to terminate the contract or collect fines, you've likely destroyed the relationship. You're much better off working with the partner to remedy its lapses, ensuring a safer and more profitable partnership for the future.

Maximum Security

Taking no chances, some companies turn to isolated networks and batch processing to protect themselves from their B2B partners Virtually every company engaged in B2B e-commerce gives partners some degree of access to its network. That is a huge mistake, says Evan Kaplan, president, cofounder and CEO of security-services company Aventail. "The whole notion that you need to tie networks together to do B2B business is bad security," he says.

At least a few companies agree with that sentiment and keep their networks in lockdown. Mt Sinai/NYU Health System, a New York City network of six hospitals and two affiliated medical schools, shares medical records with outside medical practices. In the past, doctors and clinics could dial in to the network in an unsecured manner. But no more, says senior vice president and CIO Stuart Sugarman. With HIPAA privacy regulations coming, they're taking no chances. Today, after the doctors enter an order, it's sent back to them with read-only access. They can alter this data only by using the secure portal and with the proper sign-on authorisation and patient access. They can download nothing, and the application shuts down after a certain amount of idle time. And when Mt. Sinai/NYU shares information to complete transactions with insurance companies, there's no real-time connection. Everything is stored and forwarded in a batch environment. "We just don't believe the Internet is secure," says Sugarman.

Similarly, Lockheed-Martin allows no partners beyond its firewalls. The defence contractor may set up separate secure Web sites to do business with certain partners, but there's no access into Lockheed's networks, says senior security analyst A Padgett Peterson. And to further protect classified information, Lockheed maintains a special classified network with no connection to its main networks. "This limits our exposure every time we enter into a contractual relationship with a partner," says Peterson.