Privacy Considerations

In some military and other sensitive environments, secure communications are required. The PBX firewall can determine if STU-III encrypted conversations are in process. If communications between two specific numbers are supposed to be always encrypted but are not, alerts can be sent or the calls can be terminated. Another potential privacy enhancement is the ability of two firewalls in separate locations to do end-to-end encryption.

EXHIBIT 1: Example policy setting screen. (Courtesy of SecureLogix, San Antonio, TX.)

For organizations requiring the highest levels of security, PBX firewalls may soon be able to perform word spotting. If, for example, the words "bomb" and "building" are used in a conversation, an alert could be sent to security. Obviously, there are many legal and ethical issues that must be resolved before such capabilities could be implemented, but with very fast chips and increasingly accurate voice recognition software such detection is possible.

Encrypted conversations have long been enabled by such devices as the telephone security device 3600, which use the STU-III government standard. The difficulty with this approach is that it does not scale. Any two users who want to encrypt information must have the same device and go through an encryption session at the beginning of the conversation. If many users need encryption, the solution becomes unwieldy and expensive because STU-III devices can cost several thousand dollars. With a PBX-to-PBX solution (i.e., both have PBX firewalls with encryption capabilities), every conversation from the users on one PBX to the other can be encrypted.

Security for PBXs is often convoluted. Rules may be set in one table but overridden in another.

Details of a PBX Firewall Implementation

The PBX firewall, located between the demarc and the PBX, can look at the traffic going through every trunk in the voice network. After installing a firewall, an organization could specify that any modem traffic other than what is authorized for specific lines (i.e., modem numbers) will be shut down. This eliminates the problem of unknown analog lines and unknown modem traffic. Initially, the organization would set up the logic rules in log or alert mode only and then lock down the network after the environment has been fully "discovered."

A policy screen that allows modem calls for the IT staff and recognized PBX vendors and employees dialing in through the authorized RAS server. If the call falls through these logic rules, it reaches the final "terminate call" action rule. Like the IP firewall, rules, groups, and actions must be set up for the enterprise based on business and security needs.

Because the PBX firewall has access to all the inbound and outbound traffic, including telephone numbers, type of traffic, duration, etc., it can create a plethora of reports showing both security and operationally related information. If it has a large storage capacity, trending reports can be generated. Some examples of possible reports include:

• Source, date, and duration of modem calls into maintenance ports on PBXs, routers, and other network equipment
• Non-fax calls on fax lines
• Number of unanswered calls sorted by phone station, department, office, or enterprise, which can help flag war dialing
• Percent of voice trunk infrastructure consumed by unauthorized modem calls to ISPs from inside the enterprise
• Call volume by source or destination numbers
• War-dialing attacks
• Utilization rates for remote access and fax resources
• Unused, orphaned phone lines showing no traffic activity
• Summary of calls terminated or flagged based on execution of particular rules; for example, the number of calls terminated due to unauthorized call type (e.g., modem or voice on a fax line) over several months can be listed

PBX Firewall Capabilities

The PBX capabilities listed above are, to borrow a term from mathematics, necessary but not sufficient. What is needed is the ability to manage voice enterprise network security functions and set rules without going through the awkward security structures that make up the traditional PBX security system. The PBX firewall, when properly configured, will plug many of the security gaps in the voice network. Although the following discussion of capabilities and related issues is based specifically on SecureLogix's TeleWall product (www.securelogix.com), the general principles will apply to any full-featured PBX firewall. Specific capabilities include:

• Call type recognition. The firewall has the capability to recognize the traffic, including voice, fax, modem, STU-III (Secure Telephone Unit, third generation), video, unanswered, and busy.
• Rule-based security policy. Policies can be constructed by building individual rules in a manner similar to industry-standard IP firewall rule creation. Policies are physically set using logical (GUI) commands across any combination of phone stations or groups.
• Rule-based call termination. Rules can be configured to automatically terminate unauthorized calls without direct human intervention. For example, assume the internal number 281-345-1234 is assigned to a fax machine. An employee decides he needs a modem connection. Rather than going through procedures, he disconnects the fax line and uses it for his modem link. As soon as modem traffic is detected on the line, a rule is invoked that terminates the call—within a second or two.
• Complex rule creation. Rules should be flexible enough to fit business needs. For example, fax machines often have telephones that can be used to call the receiving party to ensure that the fax was received or to exchange some other brief information (and sometimes to help enter codes). The rules associated with that analog line could allow fax traffic for any reasonable duration, prohibit modem traffic altogether, and allow a voice call to last only five minutes.
• Centralized administration. The firewall should be capable of multiple-site links so rules can be administered across the enterprise.
• Real-time alerts. Rule violations can trigger a variety of messages, such as e-mail, pager, and SNMP security event notification. Assume, for example, that highly sensitive trade secrets are part of the organization's intellectual assets. Calls from anywhere in the enterprise to known competitors (at least their published telephone numbers) can be monitored and reported in a log or in real-time. More commonly, employees may occasionally dial up their personal ISP to get sports news, etc., during the day because sports and other non-work-related sites are blocked by the firm's IP firewall. Calls to local ISP access numbers can be blocked or at least flagged by the PBX firewall. This is more than an efficiency issue. A PC on the network that is dialed into an ISP links the outside world to the organization's IT resources directly, with no IP firewall protection.
• Stateful call inspection. Call content can be continuously monitored for call-type changes. Any change is immediately logged and the call is again compared to the security policy.
• Dialback modem enforcement. Security policies can be used to enforce dialback modem operation.
• Consolidated reporting of policy violations. By summarizing the output of multiple PBX firewalls, management can see any overall patterns of security violations, ranging from hacker attacks on specific sites to employee attempts to dial inappropriate, premium-900 numbers or country codes not relevant to the business.

Exhibit 1, adapted from a white paper by Gregory B. White, shows a communications environment with defenses against intruders from the Internet (data) and the public switched telephone network (voice).

EXHIBIT 1: Increased security by combining IP and telephony firewalls

Limitations of PBX Control and Reporting

Virtually all large-scale PBXs come equipped with the capability to report and control traffic to some degree. This capability is needed for capacity planning, day-to-day operations, and security (toll fraud prevention). Some voice network controls over unauthorized use of modems can be established with existing capabilities:

• Report origination and termination of calls. Using a call accounting package, calls can be summarized in various ways (by specific number, area code, country, etc.). Call details must be collected for this reporting to be available.
• Set the class of service on selected analog lines to outbound only.
• Block all calls to and from specific area codes (e.g., 900) or countries.
• Identify calls of long duration, such as those more than three hours.
• Identify calls under ten seconds, an indicator of possible war-dialing activity.

EXHIBIT 1: Smart card for two-factor authentication. (Courtesy of Aladdin, Arlington Heights, IL.)

• Consolidate all dial-up lines to use a centrally controlled modem bank or RAS server.
• Enforce physical security (wiring closets, demarc, etc.).
• Assign dial-up lines to numbers that are outside the range of normal business activity for the location. For example, if the published business voice numbers range from 281-345-1000 to 281-345-2999, then analog circuits might be in a range such as 281-654-2500 to 281-654-3500.
• Disable banner information that provides a hacker with useful information.
• Perform a self-audit using war-dialing software. Independent consultants and audit staff are best used for this effort.
• Use dial-back systems such as CLI identification for a Shiva device.
• Strengthen procedures for provisioning analog lines and charging for their use. Perform periodic inventories.
• Use two-factor authentication systems where practicals. Exhibit 1 shows Aladdin's eToken Pro smart card, which has on-board RSA 1024-bit key operations, enabling integration into publickey infrastructure (PKI) architectures.

According to an Intel support Web site (http://support.intel.com/support/si/library/bi0706.htm), "If the Shiva device is configured for general CLI Authentication (AuthFor DialbackOnly=False), and the remote client's phone number is not in an authorized list of numbers, the call is rejected. As the call never gets answered, unauthorized users are never presented with a username and password prompt".

Deploying Instant Messaging for OWA

A new feature in Exchange 2010 is the integration of Instant Messaging (IM) into Outlook Web App, so your OWA users can see who is online and directly chat with the users without the requirement of installing Office Communicator on their client computer.

Note

IM integration for OWA does not require a UM server role to be installed in your environment; it just requires OCS 2007 R2 to be available. For that reason the feature also does not require an Exchange E-CAL like UM does.

To deploy this functionality, you need to install the OCS 2007 R2 Web Service Provider on all Client Access servers, enable IM on the Client Access server, and configure the OCS 2007 R2 Server to be able to access the Client Access server.

For IM integration you need the following:

• The Firewall configuration between the OCS 2007 R2 and Client Access server needs to allow the following TCP ports: 5061 (SIP), 5075, 5076, and 5077.
• The Client Access server requires a digital certificate that includes the FQDN or Client Access server array name as Subject Name and is from the same CA as the certificate of the OCS server. Certificates from different CAs—even if the CAs are trusted—might cause problems.

You must perform the following steps on every Client Access Server role where users access OWA and want to use IM:

1. Download the Microsoft Office Communications Server 2007 R2 Web Service Provider at http://go.microsoft.com/fwlink/?LinkID=135129 and run CWAOWASSPMain.msi to extract the package:
   1. Run vcredist_x64.exe to install Microsoft Visual C++ 2008 Redistributable.
   2. Run Ucmaredist.msi to install the OCS 2007 R2 Unified Communication Managed API 2.0 Core Redistributable.
   3. Run CWAOWASSP.msi to install the OCS 2007 R2 Web Service Provider.
2. Download and install the API 2.0 Core update for Windows Server 2008 R2 with the file name UcmaRedist.msp at http://www.microsoft.com/downloads/details.aspx?FamilyID=b3b02475-150c-41fa-844a-c10a517040f4.
3. Identify the Client Access server's certificate subject name and thumbprint using the Get-ExchangeCertificate |flcmdlet.
4. Configure the OWA Virtual Directory of the Client Access server to enable IM by running the Get-OwaVirtualDirectory -Server | Set-OWAVirtualDirectory -InstantMessagingServerName - InstantM essagingCertificateThumbprint -InstantMessagingEnabled $true - InstantMessagingType OCS cmdlet, as shown in Figure 1.

   Note

   In Exchange 2010 RTM this task required modifying web.config file located in the \ClientAccess\Owa folder. If you have not installed Exchange 2010 SP1 yet, please follow the instructions to configure the web.config file at http://technet.microsoft.com/en-us/library/ee633458.aspx.

5. Restart World Wide Web Publishing Service to apply the changes. Remember, restarting the service will disconnect all active users.

 

Figure 1: Enabling IM on Client Access server

After you have configured the Client Access Server role, you need to perform the following steps on your OCS 2007 R2 Server:

1. In the Office Server 2007 R2 Management Console, on your OCS 2007 R2 pool, open Front-End properties.
2. On the Host Authorization tab, click Add Authorized Host and configure the Client Access Server or the Client Access Server namespace. In Settings, select Throttle As Server and Treat As Authenticated, as shown in Figure 2.

   Note

   The Server name must be exactly the same as the Subject name of the certificate you have configured on your Client Access server(s).

3. For the settings to take effect immediately, you need to restart Office Communication Server Front-End service. Be aware that this will disconnect any active users.

 

Figure 2: Adding an authorized host in OCS 2007 R2

After you've configured your OCS 2007 R2 and Client Access Server role, your users should see their presence information and should be able to chat with their contacts using OWA as shown in Figure 3.

 

Figure 3: Instant Messaging integration in OWA

Deploying UM and OCS 2007 R2 Integration

If you want to implement OCS 2007 R2 or later into your Exchange 2010 UM, your environment should consider the following requirements:

• One or more OCS 2007 R2 Front-End servers.
• At least one OCS 2007 R2 Mediation server connected to your PBX or phone system.
• UM server roles require a digital certificate that is enabled for UM service on that server.
• One or two phone numbers per OCS Location Profile—at least one for Subscriber Access and optionally one for an UM auto attendant. Particularly if you want to connect multiple office locations, you should consider at least a subscriber access number that is in the local phone range, but you can use a single UM auto attendant for the company.

Follow these steps to install OCS 2007 R2 integration for UM:

1. Create a UM dial plan for each of your available OCS Location Profiles:
   1. The dial plan name should, for example, include information about Exchange UM and only include characters supported by an OCS 2007 R2 Location Profile (such as no spaces).
   2. URI Type = SipName
   3. VoIP security = Secured or SIPSecured (OCS 2007 does not support unsecured VoIP security!)

   Note

   Make sure that your Office Communicator client encryption level reflects the VoIP security setting. If you configure VoIP Security as SIP Secured, you need to set it either to Rejected or Optional. If you use Secured as VoIP Security level, it must be either Required or Optional.

2. Configure your UM dial plan(s) with the correct OCS Location Profile Subscriber Access phone number.
3. Associate the UM server with the UM dial plans and make sure Startup Mode is Dual. If Startup Mode is changed, you need to restart the Microsoft Exchange UM service.
4. Run the ExchUCUtil.ps1 script found in the \Scripts folder. The script will perform the following tasks:
   1. Create one UM IP gateway for each OCS 2007 Enterprise Pool
   2. Create a UM hunt group for each UM IP gateway with their respective Pilot Identifiers
   3. Grant OCS 2007 servers permission to read Exchange UM objects in Active Directory
5. Use the Set-UMIPGateway cmdlet to configure the Port parameter of every created IP gateway to port 5061. You also use this cmdlet to disable outbound calling for all but one UM IP gateway. This is usually the gateway that is likely to handle the most traffic.
6. Run the Get-UMDialPlan -Id |flPhoneContext cmdlet in EMS and remember the PhoneContext property—you'll need to create an OCS Location Profile with that exact name.
7. Create and configure required UM auto attendant(s). Assign them the correct UM dial plan and the access phone number from the OCS Location Profile.
8. On your OCS 2007 R2 Front-End server, create an OCS Location Profile in OCS 2007 R2 for the UM dial plan you created that matches the PhoneContext name.
9. Run the OcsUMUtil.exe tool found in the C:\Progam Files\Common Files\Microsoft Office Communication Server 2007 R2 folder. The tool will verify that OCS Location Profile and UM dial plan names match and allow you to create contacts for your Subscriber Access as well as auto-attendant access numbers.
   
   
   
   
   Notes from the Field—Unified Messaging Transitioning and Extension Dialing
   
   Gary A. Cooper
   Senior Systems Architect, Horizons Consulting, Inc., United States
   Within our organization, we had been utilizing Exchange Server 2007 UM in conjunction with Office Communication Server 2007 R2. This solution worked well, but we required the new features in Exchange Server 2010 UM—specifically RMS-protected Voicemail and Voicemail Preview. When we originally configured Exchange Server 2007 UM, we did not have enough Direct Inward Dial (DID) numbers for each mailbox that was UM-enabled, so we instead configured Exchange Server 2007 UM to use the auto attendant to answer all inbound calls and then to prompt the caller to select the appropriate person to contact. This worked well until we introduced Exchange Server 2010 and DID numbers.
   
   
   To implement Exchange Server 2010, we had to create a new dial plan for OCS to route properly to the new UM server. This now forced each user to have two new EUM address entries after we moved their mailboxes to Exchange Server 2010 and migrated their UM to Exchange Server 2010 UM (by removing their old UM settings and re-provisioning them).
   
   
   • EUM: FirstName.LastName@Contoso.com;phone-context=
   • eum:;phone-context=
     
     
   In testing, what we found was that if a call came into OCS for a mailbox we had already moved to Exchange 2010 UM, the main number would be answered by the auto attendant in Exchange Server 2007 UM; then, when the older UM server tried to route the caller to the Exchange 2010 UM server, it would error and tell the caller "The call has failed, please press '0' (zero) for the operator or dial someone by name or extension to reach them directly." If the caller tried to dial by name or extension number to mailboxes still on Exchange Server 2007 UM, it worked without issue. Behind the scenes, Exchange UM couldn't find the migrated mailbox and would route the call back to OCS 2007 R2, which would route it back to Exchange UM, and so on, and eventually the call failed and the caller was dropped.
   
   
   In working with Product Support Services, we determined that Exchange 2007 was still looking for the proxy address for its dial plan in the following format:
   
   
   • eum:;phone-context=
     
     
   We determined that when the caller entered the extension (such as - 204), Exchange Server 2007 UM would search for the user in the current dial plan (the dial plan associated with the auto attendant that answered the call)—in this case the Exchange 2007 Sip_Name dial plan. It did this search by constructing the EUM address (204; phone-context=.< Exchange 2007 Dial plan GUID>) and then searching all Active Directory users to check whether any user had this stamped in their proxy addresses. However, the migrated mailbox that has been moved to Exchange 2010 UM-has been provisioned on the new Exchange 2010 Sip_Name dial plan, so it no longer has the Exchange 2007 proxy address, and so the user object is not located.
   
   
   The solution we ended up implementing was to add the legacy EUM proxy address back to the mailbox object, thus enabling extension dialing from both Exchange 2007 and Exchange 2010 UM services.