SmartAdvice: Customer Education Key Part Of Anti-Phishing Protection

Educating customers to safeguard personal information helps prevent phishing thefts and builds loyalty, The Advisory Council says. Also, test to make sure systems are compatible with upcoming Windows XP Service Pack 2 release; and follow code-review practices to make sure your developers write secure code.

Editor's Note: Welcome to SmartAdvice, a weekly column by The Advisory Council (TAC), an advisory service firm. The feature answers three questions of core interest to you, ranging from career advice to enterprise strategies to how to deal with vendors. Submit questions directly to [email protected]

---

Question A: What can we do to protect our customers from phishing scams masquerading as our Web site?

Our advice: If I were to summarize the response in just two words it would be "customer education." But first ....

What is phishing?
Phishing stands for "password harvesting fishing" and is the luring of sensitive information, such as passwords, Social Security numbers, financial data, account information, etc., from a victim by masquerading as someone trustworthy with a need for such information. The term was coined about 10 years ago by hackers attempting to steal AOL accounts to send out spam. Today, online criminals use phishing for more directly profitable uses, including identity theft, online banking, and online auctions.

Related Links How Not To Get Hooked By A 'Phishing' Scam BBB Phishing Phacts Anti-Phishing Working Group

Why is phishing a problem?
Phishing threatens the very fabric of trust upon which commerce, and Internet commerce in particular, relies every day. Given how easy it is to compromise a user's security simply by posing as a trustworthy company and requesting sensitive information, this raises concerns about the level of trust that users will place on the Internet going forward. However, what's interesting about phishing statistics is that it represents a small percentage of all the "garden variety" identity theft that occurs around us.

What can customers do to protect themselves?
While I'm not going to list everything that the Federal Trade Commission and the Better Business Bureau suggest that consumers should do to protect themselves from phishing, here's the gist of their recommendations:

• Don't give out personal information in a public place (such as a forum or chat room) or to someone you don't know.



• If you receive an E-mail or a message requesting your personal information, don't provide it. Instead call, E-mail or visit (online or offline) the business to check with them to see if they are in fact the ones who sent the E-mail or message to you. In all likelihood it wouldn't be them, since such professional companies should never ask for your personal information unless you've initiated communication with them by visiting their Web site or calling their toll-free number.

Why should companies make efforts to protect their customers from phishing scams?

• Confidence: Companies that go the extra mile to inform, educate, and protect their customers from phishing scams will earn greater levels of trust and confidence and, thereby, more loyal customers.



• Liability: Although it's an immense inconvenience for the consumer to have his or her identity stolen and to subsequently be compromised financially, U.S. law does protect the consumer. In most cases, the consumer isn't liable for the embezzlement and subsequent damage.



• Service: It's the responsibility of companies to serve their customers to the fullest extent possible, and this includes informing, educating, and protecting their customers, to the extent possible, from phishing scams.

What can companies do to help protect their customers?
The No. 1 thing that companies can do is to educate their customers. The reason for this is that almost all the actions that need to be taken to protect customers from phishing scams need to be initiated by the customers themselves. These include:

• Not divulging sensitive data to unidentified people or companies;



• Installing anti-phishing software on their computers; and



• Checking with the companies to see if they really require the requested information, etc.

However, rather than simply expecting customers to do the above entirely on their own, the onus falls on companies to regularly inform their customers about the above recommendations, to periodically educate them about the dangers of phishing, and to repeatedly encourage them to adhere to anti-phishing guidelines published by the FTC, the BBB, and the Anti-Phishing Working Group.

-- Sanjay Anand

Question B: How should we prepare for the release of Windows XP Service Pack 2?

Our advice: This is a "back to basics" question of systems administration best practices. With Windows XP SP2 to be released this month, there's no time to lose. If you haven't done so already, then download and install SP2 Release Candidate 2 (RC2) on test systems immediately, even if you aren't currently using Windows XP. We recommend these priorities for testing:

Related Links Windows XP Service Pack 2 Release Candidate 2 Evaluating Windows XP Service Pack 2 RC2 Justifying Replacement of Windows 98 PCs

• Thoroughly test your publicly accessible and business-to-business extranet web sites from Internet Explorer (IE) with SP2. Even if you don't use Windows XP, many of your customers and business partners probably do, and they may upgrade quickly to get SP2's security improvements, including enhanced IE security. You don't want to be unpleasantly surprised by having some clever dynamic feature of your Web site stop working for your customers.



• If you're using Windows XP, then thoroughly test your PC-based and client/server applications, both off-the-shelf and custom-developed. Although few programs are likely to be broken by the new security features in SP2, you don't want to be surprised by one of yours being among them.
• Thoroughly test your intranet Web sites, for the same reasons as above.



• Have your Windows system administrators review the administration changes in SP2, and plan the roll-out for as soon as practical after your testing of the final release is completed and any problems are resolved. There's no sense in tempting fate regarding the known security issues with Windows.

We strongly encourage companies that are still running obsolete versions of Windows--98, ME and NT 4.0--to plan the migration to Windows XP sooner rather than later. They're sitting ducks for security problems. Even those running Windows 2000 may now want to consider upgrading to XP, since Microsoft is unlikely to retrofit all the new security improvements back to Windows 2000.

-- Peter Schay

Question C: How can we train our application developers to write secure code?

Our advice: Think of "crackers" as expert code reviewers; if there's a security hole in your code, they'll be more than happy to uncover it for you. Even if you're a vendor with a market monopoly, do you really want your customers to learn about your insecure coding practices? Educating your developers in secure coding principles makes good business sense.

Crackers will, of course, happily exploit bugs from other sources, such as typos, but programmers frequently make certain assumptions which create potential security weaknesses that crackers take advantage of. Generally, crackers exploit one of three types of weaknesses:

• Failure to establish, follow or enforce secure conditions, practices, and policies.



• Software features where security consequences haven't been fully considered.



• Software bugs that result from developer's unjustified assumptions.

Related Links Secure Coding: Principles & Practices, Graff and van Wyk

While developers should, as a matter of course, include features that can help users avoid the first weakness (e.g., by including mechanisms for enforcing password policies), eliminating the latter two weaknesses is often more problematic.

To fully consider the security costs of including certain features in software applications, developers need to understand how crackers have been able to use apparently innocuous features in the past. Careful study of books such as Howard and LeBlanc's Writing Secure Code (Microsoft Press; 2002) is the best way for developers to learn about the many common weaknesses that already have been identified and solved.

Often, seemingly reasonable development assumptions can provide a window of opportunity to those with malicious intent. For example, a common source of exploitable bugs is a "buffer overflow" problem. The developer simply assumes that no data input will ever be larger than some, usually very generous, number of bytes. Under normal circumstances the probability of that assumption being violated may well be vanishingly small. However, if a cracker who knows or suspects that assumption exists deliberately includes large amounts of garbage input to exploit this weakness, then the code can be compromised. Data, or even code, placed at the end of the input ends up in memory after the input buffer, changing information to the cracker's advantage. A simple case might be to replace a secret password in memory with one selected by the cracker.

In principle, the solution to this kind of problem is simple: test, and don't assume. In the case of buffer overflow, for example, the developer needs to recognize the problem and to test the length of the input to prevent reading more input than is allocated to the buffer.

This is more easily said than done, however. It requires a conscious effort to recognize that one is making coding assumptions that may not be justified. Encourage your developers to systematically re-examine their own code looking for these assumptions. Since it's often easier to spot other people's assumptions than one's own, a powerful tool for creating secure software is to make extensive use of formal code reviews. Every line of code should be carefully read and checked for unintentional assumptions by at least one developer other than the original creator. This requires management buy-in, but has been shown to provide very high payback, not only in producing more secure code, but code that is generally more reliable, maintainable, and usable.

In conclusion, in today's security-sensitive world, learning what security threats to be on the look out for, constantly questioning assumptions, instituting systematic code reviews, and other secure-coding practices make good sense from technical and business perspectives.

-- Beth Cohen

---

Sanjay Anand, TAC Expert, has more than 20 years of IT and business-process management experience as a strategic adviser, certified consultant, professional speaker, and published author. More than 100 personal clients, both large and small, have included companies from an array of industries and geographies, from academia to technology. He's often referred to as a "consultant's consultant" for training and mentoring skills. He was the creator of Asia's first best-selling computer-assisted learning software package at the age of 17.

Peter Schay, TAC executive VP and chief operating officer, has 30 years of experience as a senior IT executive in IT vendor and research industries. He was most recently VP and chief technology officer of SiteShell Corp. Previously at Gartner, he was group VP of global research infrastructure and support, and launched coverage of client/server computing in the early 1990s.

Beth Cohen, TAC Thought Leader, has more than 20 years of experience building strong IT-delivery organizations from user and vendor perspectives. Having worked as a technologist for BBN, the company that literally invented the Internet, she not only knows where technology is today but where it's heading in the future.