Toll Fraud | Voice and Telephony Security

Prevention of toll fraud requires unceasing vigilance. Hacking is frequent and can result in large losses. For example, NASA and the Drug Enforcement Agency have both been hacked for millions of dollars. The basic steps for toll fraud prevention include the following:

  • Protect the PBX maintenance port. Use passwords of at least ten characters and change them monthly. This is the absolute minimum protection. Far better is to use a two-factor authentication system, such as verification systems from Axent, CDI's Uniguard, or Avaya's ASG security gateway. Exhibit 1 illustrates a device used to control access to multiple ports, including the PBX. Such a device can be used to manage security for many devices.

  • Exhibit 1: Example of PBX Maintenance Port Protection Device (Uses Two-Factor Authentication)

  • Use common sense calling restrictions. If your organization never makes calls to South America, restrict the calling patterns to eliminate that possibility. The telephone operators can be given a class of service that overrides that restriction on the chance that a legitimate call needs to be made to a restricted location. Calls can be restricted by time of day, day of the week, and location. For example, lobby area telephones should not generally have the ability to make long-distance telephone calls (or at least not international calls). If the organization does not do business on Sunday, restrict outgoing calls on that day. All "common area" telephones, such as those in lobbies, break areas, and conference rooms, may need to have after-hours restrictions. The mechanism for restricting functions on the PBX is the class of service. Many organizations, much to their later regret, have allowed the technical staff to set class of service policy. Because the technical staff is oriented toward pleasing the user, there is often escalation over time in the number of users who have the most powerful class of service. In the absence of policy, if a vice president asks a switch technician to enable dial-tone capabilities from an international location, the switch technician will most likely comply with the request.
  • Use toll fraud insurance. Some PBX vendors and most common carriers will provide toll fraud insurance, as long as basic control mechanisms (that they specify) are in place. Typically there will be a deductible ($5000 to $20,000) per loss, but at least coverage for large losses is available. The carriers have sophisticated monitoring programs that identify an organization's typical usage patterns and flag unexplained and rapid increases in volumes to particular destinations. Also, some international locations are far more likely to be called by hackers than others (actually, hackers typically sell the "service" to individuals on the street, who then tend to call certain locations more than others).

  • It is prudent to keep an up-to-date contact list of those management personnel authorized to make decisions regarding long-distance services. This list should be periodically sent to the vendor (carrier or PBX manufacturer) that is monitoring your traffic. For example, assume that your organization is attacked on a Saturday night. The monitoring service identifies hundreds of calls going to Bolivia and Columbia (countries with which you normally do not do business) and attempts to call a responsible party on your contact list. If they cannot reach someone in authority, they are hesitant to shut down all outgoing international business because you may have essential functions that require outgoing international calls.

  • Put tight controls over tandem trunk calling (going into the PBX, then going to an outside line). DISA — allowing someone to call in, get dial tone, then call out — should be prohibited unless there is some security system in place to control it (e.g., voice verification). Some organizations will allow calls into voicemail, and then a transfer to dial tone (using a password). Given the ease of password cracking techniques now available, this service to employees can be expensive indeed. Better to provide them with calling cards for business-related calls outside the office (or an 800 number to dial into the office). Sometimes, vendors set up a new PBX and voicemail system and leave backdoor passwords as well as voicemail-to-dial tone capabilities (with only a two-digit password). In smaller locations, the organization will be completely dependent on vendor expertise. When a hacking incident occurs, the maintenance vendor may accept the responsibility or may say that the customer never instructed them to eliminate DISA, etc. Caveat emptor!

  • Periodically review forwarding of extensions to dial tone. Any station forwarded to dial tone is "hacker bait."

  • Educate your operators and employees to social engineering techniques. One technique widely practiced is for a hacker to call someone and say, for example, "I'm from PAC Bell and we are testing your system for some reported problems. Would you please forward me to 9011 so we can complete our trace of the system?" Of course, this transfer gives them dial tone. Another scam is for someone dressed in a delivery company uniform to arrive at the receiving desk to deliver a package for "Mr. X." Mr. X is not there and the hacker asks to use the telephone to call his boss. Apparently, he is put on hold and then gets in an involved conversation with his boss about wrong directions, etc. What he is actually doing is dialing a local number that charges a high per-minute charge for services (e.g., $15 per minute); he then gets a kickback from the service provider.

  • Immediately request your local exchange carrier to disallow any third-party charges to the main number. Some prisoners, for example, will make long-distance calls and charge to any organization that allows third-party charges.

  • Do not forget to periodically review your call accounting reports. Are there calls to a location that your organization has no business reason to call? Some hackers will keep the volume of calls sufficiently small to stay below the radar screen of the long-distance carrier's monitoring algorithms. Sort down minutes called by location and also list single calls in descending order of cost. A quick review can spot problem areas — including some that are unrelated to toll fraud (e.g., "stuck" modems).

  • Educate users on the vulnerability of calling card theft. In some airports, "shoulder surfers" observe calling card numbers being keyed in and sell the numbers on the street as fast as possible. Using an 800 number to call back to the office reduces the frequency of calling card calls (as well as reducing the cost). Using a voice verification system to allow secure DISA (see discussion below) also decreases the need for card use. A user, in the interest of expediency, may occasionally give her card number to coworkers. Most carriers, when they detect multiple usage of the same calling card in widely separate geographic areas (e.g., Japan and the United States) within a short period of time, assume fraud. Ensure that all employees who need a card have one.

  • Some organizations, concerned about potential misuse by their own employees, contractors, or temporary workers, use prepaid calling cards. The advantage of this technique is that a stolen card number would be used to its limit and then no further charges will accrue. The disadvantages are that it allows for no internal accounting of what the card was used for and that sometimes the card is not fully used.

  • Monitor your organization's fax-on-demand server. To efficiently serve their customers, many firms will set up a fax-on-demand server that accepts a call from the public network and faxes requested information back to the caller. Hackers have recently begun to exploit this service in the following ways:

    • Repeatedly calling the fax-on-demand service, asking for faxes to be sent to a 900 or 976 number owned by the hacker (these area codes have a special surcharge associated with them). Of course, the information on the fax is not used, but the minutes accumulate and the calling party (i.e., the hacked party) is responsible for paying the toll.

    • Repeatedly calling a fax-on-demand service, merely to harass the organization by running up its long-distance bill.

    • Harassing individuals by sending the fax to a business or residence that did not request it (waking up people in the middle of the night, etc.).

    • One company was hit with over 2000 requests to send a long document to Israel, resulting in a $60,000 telephone bill. [4]

    • Techniques to detect and defend against fax-on-demand abuse include:

      • Check the fax system log (or call detail) for repetitive faxes to the same number.

      • Exclude all area codes where there is no reasonable expectation that the organization would do business.

      • Exclude area codes associated with high fraud incidence (e.g., 767 — Trinidad and Tobago; 868 — Dominican Republic). [5]

      • Monitor overall volume of faxes sent out.

      • Power off and on to clear the queue if it is obvious that the server has or is being attacked.

      • Monitor the fax server over the weekend (particularly long holiday weekends) because that is the favorite time for hackers to start their penetration.

  • Make use of your organization's internal billing system. It is easier to spot unusual activity if long-distance bills are broken down by department. Make the internal reports easy to read, with appropriate summary information (e.g., by international location called), to provide the organization with more eyes to watch for unusual activity.

  • Use appropriate hardware/software monitoring and toll restricting tools. Some features of these tools include:

    • Selectively allow or restrict specific telephone numbers and/or area codes.

    • Allow 0+ credit card access but restrict 0+ operator access.

    • Limit the duration of telephone calls in certain areas.

    • Restrict international toll access.

    • Provide for bypass codes.

    • Report on a daily basis (sent via e-mail) any suspicious activity, based on predefined exception conditions.


No comments:

More?