In summer 2000, Visa unveiled its "Digital Dozen," a list of securityrequirements calling for firewalls, encryption, testing and accesspolicies that its service providers and merchants must have as acondition of doing business with Visa. That's right--if a bank ormerchant can't play by these rules, they don't play withVisa.
Visa's merchants and service providers must annually demonstratecompliance, through an online self-assessment for Mom-and-Pop shopsand extensive third-party audits for merchants or service providershandling large volumes of cardholder information. And if a merchantrefuses to comply, Visa can fine the bank that processes that store'stransactions. Then it's up to the bank to punish the merchants."Eventually, if we don't have proof from an independent third partythat you qualify with our requirements, we really don't want you totake the card," says John Shaughnessy, Visa USA's senior vicepresident of risk management in Tampa, Fla.
Not everybody is as deadly serious about B2B e-commerce partnersecurity as is Visa. In the stampede to e-commerce, most companieshave disregarded the security of their partners and their role inexerting pressure to make sure they're safe. "My sense is that B2Bsecurity is not a consideration for many organizations," says JamesWade, chief security officer for the Federal Reserve System andpresident of Framingham, Mass.-based ISC2, a training and professionalcertification organization for IT security professionals. Many B2Brelationships spawn from manufacturing, marketing or some other groupwithin an organization without involving IT security.
That may or may not be the case in your company, but regardless, it'syour responsibility to see to the security credentials of your B2Bpartners. "The security of your B2B partner is as important as theircreditworthiness," says Paul Gaffney, CIO of Staples, theoffice-products retailer based in Framingham, Mass.
Indeed, the risks of working with a nonsecure partner are frightening.A partner that fails to secure its own systems could become a launchpad for attacks into your system. Someone could tamper with data in asupplier's system, such as switching a digit in a product SKU number.Or a virus could disable your partner's systems. Either way, yourjust-in-time supply chain operations will grind to a halt. Worst ofall, you might incur legal liability if your partner exposes yourcustomers' data. "Your customer will ask, 'Why didn't you investigatethis partner?' That customer can sue you," says Dorsey Morrow, generalcounsel for ISC2.
Of course, it's not just about the risks. Safe B2B e-commerce carrieshuge business benefits too. In fact, companies can market the securityof their B2B programs to enhance customer confidence and thus attractadditional partners. Safer B2B practices also protect against glitchesand outages, preserving the critical just-in-time nature ofe-commerce, which keeps the revenue flowing.
With so much to lose and to gain, every company should establish a setof security expectations for its B2B partners, drawing from the listthat follows. In addition, take heed of the strategies to counterresistance and enforce compliance since you will be dealing withcompanies that aren't under your control.
Requirements and Expectations
A Documented Security Policy
Security experts say every company should demand to see its B2Bpartners' written security policy. Lee Holcomb, CIO of NASA inWashington, D.C., says that is something he's strict about because heuses online connections to post competition opportunities and payaerospace vendors and contractors. He expects policies to includefirewall maintenance and patch-service provisions and to provide forvulnerability assessment and intrusion detection, as well as atraining program for systems administrators who would have access tosensitive information. "We're dealing with astronauts or pilots inspace," says Holcomb. "Security and safety are synonymous."
The Federal Reserve typically asks for a written description of apartner's security organization, including its rules andresponsibilities and where the security function reports. "If securityis buried in the technical bowels of an organization, it's probablynot having significant influence on senior management," Wadesays.
The policy should also identify individuals managing the partner'ssecurity program, adds Harry DeMaio, a director in Deloitte & Touche'senterprise risk practice in New York City.
Secure Application Development Practices
In most B2B relationships, partners grant limited authority to passinto each other's systems and access critical information. If yourpartner is using proprietary applications that touch your system,security must be built into that application. Your partner must showyou how security is incorporated into its application design,development and deployment plans, says DeMaio. Look for access andauthorization controls built into applications, path isolation toensure that the app's user goes only where he's allowed to go, andlogging and reconciliation to provide a record of where any user hasbeen--matching up with what he's done. "Make sure the applicationdoesn'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 anExcedrin headache. Ray Bedard, a partner in PricewaterhouseCoopers'supply chain practice in Virginia Beach, Va., tells of a company heworked with that failed to terminate a departing employee's access toits B2B applications. Before the employee left, he went into thesystem and ordered a bunch of goods from an online partner. The goodsarrived and nobody could figure out what they were doing there. Ittook several hundred man-hours for the parties to resolvethe mess.
To avoid that sort of tampering, companies should require partners tomaintain strong, active password programs. Measures should includerequirements to change passwords frequently, monitoring and logging ofpassword usage, tools to detect easily guessed passwords and a centralauthority to set access policies. Wade adds that you should forbidyour partner to set up departmental passwords if the partner accessesyour systems through its network. "This is always a sticking point innegotiations," he says. "The partner always wants to use some easierform" of password protection.
For sensitive information, companies should require higher-levelaccess and authorization tools. Ramana Palepu, CTO of the WorldwideRetail Exchange in Alexandria, Va., says his members requirepublic-key infrastructure authentication technology, and will expectdigital signatures for financial settlement and payment services theexchange may offer in the future. But for less sensitive transactions,such as purchase orders, auctions and item tracking, strong passwordand user-name controls suffice.
Encryption
Experts and practitioners say companies should require their partnersto use encryption for any sensitive information--customer data,marketing strategy, labor relations and unreleasedfinancials--transmitted over the Internet. The Federal Reserve isconstantly dealing with financial information, so Wade requiresanything transmitted between the Fed and its financial and bankingpartners to be properly secured.
At J.P. Morgan Treasury Services in New York City, Joe Calaceto, whoheads up security as vice president and technical director, requiresvarying levels of encryption of customer information such as accountnumbers and beneficiary names and addresses.
Gaffney says Staples requires its B2B partners to encrypt all Internettransmissions, but he doesn't require encryption for transmissionssent over private networks. "That would be overkill, since one of thereasons we're paying a premium for a private connection is for itssecurity," he says.
Response Plans
DeMaio says the response plan is where to expect resistance frompartners. Most companies focus on perimeter defense because it's sexy,but once they think nobody can get in, detailed response plans seemlike overkill. That is a mistake, and you shouldn't let your partnersget away with it, says DeMaio. "Too many organizations will simplyfade and say, 'OK, you don't have to do it."
DeMaio adds that partners should provide a detailed description oftheir attack response plan--and it should be designed around specificsystems, not generic boilerplate from books and manuals.
Also, demand that partners notify you of security incidents within thehour. Charles Le Grand, director of technology practices at theInstitute of Internal Auditors in Altamonte Springs, Fla., adds thatyou should ask to see your partners' criteria for notifyingauthorities and how they're monitoring for vulnerabilities. Forexample, if they operate in an NT environment, urge them to keep upwith NT BugTrack, he says.
Segmented Architectures
Some security analysts advocate "segmenting" enterprise architecturesinto smaller networks, all behind separate firewalls. That way, if onepart of the network is compromised, the rest remains safe. Bethesda,Md.-based defense contractor Lockheed-Martin does that--and looks forit in its partners too, says A. Padgett Peterson, Lockheed's seniorsecurity analyst.
Background Checks
If it's standard practice in your own organization to conductbackground checks on employees with access to sensitive data, it'sreasonable to request the same for partners' employees who also haveaccess. Wade declined to say whether he requires background checks ofthe Fed's partners, but he's required it while working at othercompanies. By having business representatives, not just IT people,involved in the negotiations, you're more likely to get your partnerto agree to background checks. "It's difficult for many IT people toappreciate the risks involved in the relationship being established,"he says.
Compliance Audits
Experts and practitioners agree the best way to validate compliance isthrough periodic audits, either by your own auditors or an independentthird-party security company, as Visa requires. Typically the partyrequesting the audit will foot the bill.
The most security-conscious organizations require their partners tosubmit to penetration testing on a regular or random basis. But LeGrand says that is an extreme measure, because there is potential tobring a partner's system down. "If you run a denial-of-service attackjust to see how they recover, the recovery will be expensive," hesays. "So you'd better not do this haphazardly and without agreeing onyour right to do this."
Inducements and Enforcements
The Carrot
If you work for a powerful company with partners that absolutelydepend on your relationship, like Visa, you have the power to makedemands. Unfortunately, most companies don't fit into that category.Instead, they must come up with carrots to entice partners to agree totheir terms and incorporate them into contracts.
For example, if your partner objects to security requirements becauseof cost, offer to share some of the cost. A partner "might balk at anextra 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 moresecure system."
Or you can offer to include your partners in your security softwarelicensing agreements to save them a few bucks, says Le Grand. HereBedard advocates a "matching fund," where a company offers to kick ina dollar for every dollar its partner spends complying with therequirements.
Finally, Gaffney suggests offering discounts or preferred-sellerstatus to partners that accept your requirements. "If a companyassociates economic value [with its requirements], it needs to be partof 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 inyour B2B engagement contract. That provides a specifically delineatedrecourse should the partner fail to implement sound security measures.According to ISC2's Morrow, the ideal recourse against a lax partneris indemnification--an agreement that if you get sued for damagecaused by your partner's breach, the partner will pay you back theamount of the judgment. Of course, that requires proving that yourpartner was truly responsible.
On a case-by-case basis, Staples will provide in its B2B contractsthat the partner will indemnify Staples for damage or legal liabilitystemming from the partner's security lapses. But Gaffney says such aprovision can be tough to secure. "The bigger companies--particularlylarger software providers--tend to stick hard to holding back onindemnification," says Gaffney, adding that smaller companies mightagree to indemnification in return for more favorable pricing orproduct distribution.
Another form of recourse is a liquidated damages clause--a contractprovision stating that a partner that doesn't live up to its securityobligations (resulting in contract cancellation) will pay the otherpartner a set amount of money.
Finally, if a partner violates the contract by, say, failing theaudit, you have the right to terminate it. But think twice aboutapplying these sticks just because your partner has fallen short on anaudit or failed to meet a particular requirement, especially if youhaven't been harmed as a result. The ultimate objective of your B2Bengagement is a productive, profitable relationship. The minute youseek to terminate the contract or collect fines, you've likelydestroyed the relationship. You're much better off working with thepartner to remedy its lapses, ensuring a safer and more profitablepartnership for the future.